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 (2005-01-13). It's been tested by compiling both the emulator and the firmware. But no further testing is done! Use released firmware from GenBoard/UnderDevelopment/FirmwareChanges unless doing tabletesting!!!
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.
Unsolved today: async executing of eventqueue events from heap. This is not high priority, as it is not strictly needed to test userspace calcs (and most stuff is moving to userspace, even trigger processing maybe).
- One way is to check in mainloop scheduler (as highest prio task), but that couldn't catch any race condition errors.
- Other way is to check it from a gdb hook
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. :(
Any instructions / tips / known tricks to run it in gdb (ddd / whatever)? It might be a good idea to do prototyping in C instead of JAVA in the future, if we can conveniently work with it. This is how I've done most of my firmware work. 'gdb ./vems' and you should be up and running. If you uncomment the compiler lines with '-pg' in EmuMakefile, you will add profiling also, not very useful ATM though. ddd is only a FE to gdb, so it should also work straight out of the box. I've tried to link it with 'efence', but that wouldn't work.