casainho said:
I wish you could help on the LCD / controller communication interface. TSDZ2 firmware is almost done, I would say it is at 80% and LCD3 firmware is very complete by now but lacks a good interface specific for sending configuration data. All the LCD menus are now implemented and well structured in the code so it is easy to expand.
Both TSDZ2 and LCD3 firmware take currently about 18kbytes flash memory while the limit is 32kbytes, so there is opportunity to improve much more, mainly on LCD side.
The concept here is to collect and move all the configuration and run time variables into a big structure and let it be managed entirely by Modbus. So all those magic constants like angle correction and limits and magnet numbers from config.h, and all the read outs from the ADC and the brake switches and PAS sensor and all the messages to the LCD would all be handled via Modbus.
Modbus is a master slave system, the master asks for values, the slave replies, The master commands new settings, the slave sets them. There can be one master, but many slaves. Inside a slave there are what they quaintly call "coils" and "registers". A coil is one bit corresponding to a switch or relay. A register is 16 bits, Some are inputs, ie data the slave collects from sensors fore example battery voltage, some are settings, ie commands or configuration value, for example low battery limit.
In operation when the controller comes up it is a Modbus slave. It initializes all the state with defaults and as it runs it updates the live values, ie adc readings. If there is another device, like an LCD display, or a PC serial, or a custom control unit (like I want for drop bars) then that is the Modbus master. It can read any information it wants via Modbus query. It can also set configuration via Modbus set commands.
As a Modbus master, the LCD or PC program would just loop using Modbus queries to ask for whatever information it wants and displaying it. Commands, eg LCD button presses, or settings updates from the PC are just Modbus set commands to the controller.
By putting all the configuration and all the data into theMmodbus accessible data area we can see any detail we like about the operation of the controller and make changes to any setting on the fly. For example, when bringing up a new motor there seem to be a few settings that have to be discovered by trial and error. With config under Modbus control, this could be done from a connected laptop or something while the motor is running and the resulting currents, rpm, and voltages, phase angles read back in real time. No need to edit files, recompile, or re-flash. We could even have a binary distribution and let people configure it to a new setup without having to build the firmware at all. Someone could even sell pre-flashed controllers should there be any interest in such a thing.
Since Modbus is very simple it would not take much code space. The configuration, (writable) Modbus registers could go in the EEPROM and the run time (read only) register would be in RAM. As I understand it, we are mostly short of flash, not RAM or EEPROM.
The other component is the Modbus Map. This is basically a text file or dictionary defining all the Modbus registers. The C language definition of how to access these in the controller, ie the replacement for config.h could be generated from the map file.
Here is a sample Modbus slave implementation for small systems. We could adapt this, or one of several similar projects:
https://github.com/FxDev/PetitModbus. Take a look at the code just to get an idea of the size.
Here is a generic Modbus gui for Windows and Linux, pretty basic, but shows the idea:
https://sourceforge.net/projects/qmodmaster/. I'm sure there are nicer ones available, but this should serve to test against.
And here is a giant PDF with the Modbus map documentation of a line of industrial standby power generation systems:
https://www.ccontrols.com/support/dp/modbus2300.pdf Basically every configurable or observable about this equipment is in the Modbus map and so is by default remotely controllable and viewable. Just skip the first few pages to get an idea of the kinds of items it handles. Our system is much simpler but the same sort of meta-data driven approach will give us a well defined and extendable interface between the controller and displays other devices.
If we do this, I plan to make a fully fly by wire bike, all control going over two wires as Modbus messages from a MCU on the bars to the controller near the cranks. PAS/Torque and rear wheel speed would go to the controller. Throttle, display, brake levers, handlebar buttons would go to the handlebar MCU, just data tx+rx would connect the two. No wire rats nests, no wet shorted throttle connectors just one thin four conductor cable.