Information for developers about comm.c and related code
Read comm.c comments.
comm.c uses a buffer of commands to be sent out via serial port, and another buffer for the incoming bytes.
The buffer of "commands" contains struct cmd_queue_t elements, see comm.h, so they point to a function that will be called every time when a character can be written to the empty transmit buffer: for example when megatune requests the 22 byte datastructure (classical 'A' megatune command) uint8_t MTsendRTvar(uint8_t i) will be called with parameter 0,1,2,...21 respectively, and will return the megatune compatible byte-value (sometimes it needs small conversion, in the case msavr has different - eg. more precise - internal format). It's that simple.
The private is a pass-on value that is specified from pushfuncpar() and the function cmd_queue_t points to can use it whatever he wants. Private is mostly used to store pointer to string. TableDump() and ConfigDump() are a bit special, since they play a bit with the private and len variables. First see the table and config that they print (InitialConfig) and you will understand why it's done that way. Btw. it's very efficient.
More UART channels should be relatively easy to add. This brings up a small architectural question. We have a 2nd UART on AfreshBoard and all the future boards, so software must support it. It will be the 3d input via msavr can be controlled or configured (even simultaneously, see GenBoard/MenuSystem !).
Unfortunately comm.c is a little mix:
- the underlying comm routines: irq handler, pushfuncpar() and friends
- megatune compatibility
- other routines, like printing mct and mcd on rs232 (any rs232port, since these are simple "char func(char) " functions)
For making the 2nd UART work, you need:
- copy the irq handler and make obvious changes
- either make pushfuncpar() parametrizable with the comm-port-selector (this would require to touch several files, sticking in the selector, I'd rather leave them alone)
- or make a clone of pushfuncpar() that is parametrizable (I prefer this) or
Model of megatune protocol
MembersPage/MichaelKristensen implemented an almost complete model of the MegaTune protocol in bin/emu_genboard.pl (yes, in perl, it runs on linux or win32 PC and acts as if it was a GenBoard).
- useful for testing (or debug) MegaTune or MegaTunix, especially when several pages of configuration is involved: whenever there is a question if a particular incompatibility is caused by firmware or MegaTune (possibly configuration) issue it's just a matter of some prints to find out
- it can read config from mtt file
- the example shows a redirect using no serial-port at all (that is tested on linux), but it can also be used with 2 serial ports (between 1 or 2 computers, with possibly different OS, each of which could run the tuningsoftware or the model).
There should be a separate page to CAN (page-name?), which is planned. See: http://www.can.bosch.com/content/Literature.html