I'm interested in using the VLCD6 because I like the small compact form factor (and my motor came with one). I like the flexibility of setting things via display, but I'm willing to set them via programming the controller instead in exchange for the form factor I prefer.
So, given that, I was reading through the earlier conversation between you two and thinking about how to integrate marcoq's work into the main project in a way that makes everyone happy.
Reading through marcoq's code now, it's all done with #ifdefs which I think doesn't satisfy casainho's desire that a single firmware binary will work with either display (if I understood his desire correctly).
casainho, I assume that both the LCD3 and 850C are using the same package encodings so nothing on the controller side needs to change to support the 850C? So we have one pair of encodings (to controller and to display) for the 'open' displays (KT-LCD3, 850C, etc), and another for the 'oem' displays (VLCD6, etc)?
What if we have the controller side detect whether it's an 'open' display or an 'oem' display rather than using #ifdefs? Maybe that's as simple as checking the uart buffer length since I see casainho is already using an 8 byte buffer and OEM is using 6. Presumably casainho's isn't going to get smaller, and OEM isn't going to get bigger (since they want to maintain compatibility with the motors and displays already in the field). If that's too hacky, maybe we could add a magic number to the 'open' display package sent from the display. Maybe even a version number for more future flexibility.
So anyway, then, once we can dynamically detect if the package came from an oem or open display: we have one uart tx encoder function for the oem displays, and another for the open displays, and same for rx decoders. On rx, we populate whatever values we got from the display, and any that didn't get populated (because open displays support them but not oem), we fall back to using values from what's on the eeprom. On tx, we use the encoding corresponding to the last package we received (i.e., if we got an 'open' package from the display, encode an 'open' package to send back, etc).
As far as how we get those values to eeprom, either way already discussed seems fine -- the user writes them to either the hex file or directly to the controller.
Does that sound good to you both? If so, I think a good path would be:
1. Change to make the controller firmware to detect 'open' displays (and maybe change the 'open' displays to identify themselves).
2. [If necessary; I haven't checked closely] Refactoring to make the controller read display-derived values from a data structure that can be populated from either an open display, or from oem + eeprom values.
3. Define encoding / location in eeprom for writing config values needed for oem displays.
4. Add oem encoding / decoding functions (marcoq has already done the heavy lifting).
Skimming through marcoq's code, I think for this first set of changes it'd be better to leave walk assist out, since that's a good chunk of the code and complexity and it'll be simpler to separate the two things.