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

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

 ______  
(  ___ \ 
| (   ) )
| (__/ / 
|  __ (  
| (  \ \ 
| )___) )
|/ \___/ 
         

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

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

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 (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: <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. :(
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.