This is developer hardcore area
Firmware experiments by compiling and running the firmware on PC.
The code can be found in CVS as of today (050113). It's been tested by compiling both the emulator and the firmware. But no further testing is done! Don't use this firmware for other than testing until someone removes this note!!!
The CVS is tagged before this commit, so one can always back out...
Compiling the firmware is done using make -f EmuMakefile. Connect to it with MegaTunix using the serial port called /tmp/tty.
Next action is:
- Engine simulator to inject data to the emulator. We have a simple multitooth wheel generator in JTune CVS (easy to move to C). The other sensors are not too hard either (maybe WBO2 is an exception).
The overall plan is to:
- compile the GenBoard firmware for x86 done
- connect MegaTunix to the fake GenBoard done
- and than feed the emulator data (such as 'resistance increasing on Pin xx') and then see the result in MegaTunix (coolant temperature rising).
This is a good way to get an understanding of:
- internals of the firmware,
- MegaTunix
- AVR's HW and usage of it from firmware
This is a wonderful plan. It will be especially nice when we have very complex network of powerful ARM computers.
The hard part is to split low level functions (such as those tweaking AVR's registers) from calculations.
Let me show an example: firmware should use getters to read sensor data like
- getSensorFiltered(MAP) instead of sensors[MAP] although reading the prepared (by other process) array would work in the PC too
- getSensorRaw(MAP) - instead of ADC[MAP] which would not work on the PC.
Get the emulator running...
Today, it's not painless to get the emulator running smoothless.
The instructions provided make the transition a little smoother:
Before compiling the emulator:\nÿ1ÿ
Compilation of emulator:\nÿ2ÿ
You must configure your LCD as with:\nÿ3ÿ
Otherwise, you will get LOTS of LCD out of bounds messages. A few (~4) is Ok.
Yes; 100% CPU is normal. :(