_       
( (    /|
|  \  ( |
|   \ | |
| (\ \) |
| | \   |
| )  \  |
|/    )_)
         

 ______
|___  /
   / / 
  / /  
./ /___
\_____/
       
       

         
         
 ##  ##  
 ######  
 ######  
 ##  ##  
 ##  ##  
         

______ 
|  _  \
| | | |
| | | |
| |/ / 
|___/  
       
       

         
     ##  
         
     ##  
     ##  
     ##  
     ##  
  ####   

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''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: <code> make varstr.h compile_time.h make etc/thermfactor.h etc/matfactor.h etc/airdenfactor.h make etc/barofac4115.h etc/barofac4250.h etc/kpafactor4115.h make etc/kpafactor4250.h </code> Compilation of emulator: <code> make -f EmuMakefile </code> You must configure your LCD as with: <code> lcd_offs[0]=FF </code> 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.'''
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.