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

 _   _ 
( ) ( )
| |_| |
|  _  |
| | | |
(_) (_)
       
       

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

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

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

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:
Event Queue is a way of scheduling events precisely with little overhead. Read OnlineCourse/TimedEvents first if you haven't read yet. ---- '''Event execution precision''' Event Queue '''implementation precision is 4 usec, average unexpected delay is around 7 usec late''' (never advanced). '''You get 3 assembled boards for free from Marcell if you can repeatably measure the difference in engine output caused by the rare event-delay because of conflicting events.''' You get 7 boards if you also post a reasonable improvement. (it's very unlikely that you pass the first requirement, even if you have an F1 laboratory, it would take horrible amount of statistics to show any difference in engine output when such precise timing is further improved). The precision is so nice even at 10000..20000 RPM that the resulting engine-output decrease (compared to optimum 0.000000sec precision) means the same as a few 0.1C difference in intake temp (MAT). If you have the time, it's better to decrease intake temp 0.2C or analyse lotsof logs and try to tune more precisely ( possibly with WideBand, DetonationDetection or IonSense), as that will bring you much more benefit than improving what is already very close to perfection. ---- '''How does it work?''' The idea is using the OnlineCourse/HardwareCounters and OutlineCourse/OutputCompareRegisters as an alarm clock, so frequent no-op interrupts are eliminated. It is based on a well known OnlineCourse/HeapStructure. '''If you understand the heap, you basically understand eventqueue. Any tricks that were applied earlier (to get the max timing capability into the future doubled to 262msec) are gone now, the alarm2core() became trivial.''' ---- '''TPU is an alternative for eventqueue''' Sequential injection and precise ignition timing would not be practical otherwise, it requires timing solution, eventqueue or TPU. The EFI332 uses a TPU unit, with it's own price, footprint and programming problems (EFI332 is about 3 times more money and work than GenBoard/VerThree, still only about 1/3 of the functions; megasquirt is of comparable price and about 1/5 of the functions; both - like most commercial ECM's - are lacking many tuner-friendly functions, like the WBO2 and fast WBO2-based closed-loop EGO-correction ). One can learn some from efi332 software though, the fuel calc is a typical implementation). AtMega128 is clever enough to perform just as well (in ECM application) without a TPU for a fraction of the price and headaches. ---- '''more details''' - of all kind Latency: Interrupt latency has an affect on timing. If an interrupt is running when another interrupt is due or another interrupt is also flagged, it will be delayed. OCR1 interrupt (used for eventqueue timing on GenBoard/VerThree while OCR3 is used on GenBoard/VerTwo) is high priority, so other flagged interrupts are not a major concern. (but INT6 is higher...) A former running of event handler could delay it, that is of most concern. (comm.c is using ringbuf.c) Since the actual time and needed events are rechecked, and necessary actions are taken without the need of an additional interrupt if events are very close one after another. * We dropped the earlier dual-heap approach: now there is only one heap, referred to as heap_normal * Dispatcher uses an address lookup from flash (not switch-case). * handler2k() still exists (might be dropped one day), but very slim already: handler2k() is run every 1024 usec, takes care of ADC (except WBO2 sampling) and some administration tasks. *comm handler + INT6 handler runtimes must be added for worstcase. INT6 is not used now, comm was enhanced. * timing.c primary and secondary (especially multitooth) trigger is the main source of potential delay ---- '''input capture precision is just as important''' - as that is the reference for timing If you are using an interrupt to capture the time of the incoming trigger (eg. use INT6 instead of IC3 input), the worst case of delay would be approximately doubled. That would still not make any measurable change in engine performance. The trigger signal processing in timing.c will be made simpler, some parts moved to userspace. The motorola megasquirt uses interrupt to capture the time of input trigger. Also, it is a slower processor. GenBoard uses IC3 / IC1 to capture input trigger, because that is the better solution. [http://www.x-dsl.hu/genboard/eventqueue/ old info about the eventqueue] The time-triggered OS at http://www.osek-vdx.org/ must be something similar.. They have CAN stuff too.
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.