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

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

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

         
|\     /|
| )   ( |
| (___) |
|  ___  |
| (   ) |
| )   ( |
|/     \|
         

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

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:
'''Developer information about modeling camsync''' '''Why''' To make a more general dual-trigger implementation that has improved support for camsync: * remove the angle-limitation GenBoard/Manual/InputTriggerCamSync * support odd-V6 * support rotary trailing plugs * time everything from last-tooth for best possible resolution. no compromises Also, * '''improved trigger interrupt''': eliminate processing in interrupt by passing captured times to userspace. This requires an improved scheduler: OnlineCourse/Modeling/Scheduler * '''timing from last-possible cranktooth''', as the brainstorming section on InputTrigger/MultitoothTriggerWheel ---- '''How''' I '''started skeleton''' in JTune CVS, ''package org.vemsgroup.firmware''. The idea '''for now''' is very simple: '''only model the PrimaryTrigger interrupt'''. This means we don't schedule events (or handle concurrency in any way), just step over the teeth that would generate interrupt (35 for a crank rotation of a 36-1 trigger). * PrimaryTrigger asks engine_t about engphase and related variables * engine_t delegates this to MultiToothGenerator * MultiToothGenerator works the same way as the mst.. msp.. in dispatcher.c * yeah, PrimaryTrigger could ask MultiToothGenerator directly What can be checked? * just print what would be scheduled * or make some helper classes to "measure" longest dwell, timing-error amplitude and such * check the double-buffering. This is very important, as the variables change we want consistent behavior. Updating trig2dwell and trig2spark (from the backend buffer) might need to be done at the same time. * check the tooth-calc (if missing tooth is handled properly) * check the condition (make condition first) to switch between 3 strategy (InputTrigger/MultitoothTriggerWheel) Idea is to * make it work for some condition even if it involves a little cheating (like wiring in some not finalized condition). * Than the cheats can be eliminated so more and more cases are covered. * Than verification is added so we are not verifying manually by the printouts. ---- OnlineCourse/Modeling/EventQueue Currently the Java EventQueue (that was written in 190 seconds) works with ''double'' -based time-storage (and not the most efficient sorting of events, but who cares?). I think it will be enough to convert the time to firmware-format (4 usec, 32 bit integer split to 2 words) in some code-sections - so it's not worth to use a TimeInstance object (am I wrong?). The idea is to generate cam and crank-tooth events that are captured by PrimaryTrigger and SecondaryTrigger and passed to userspace, where the Scheduler notices there is some work to do and instructs the detection code to find out engine phase: * extract time of TDC-s and matching cyls * find last-tooth to do timing from (which the primary-trigger can watch and really insert the event when needed) * find out any trigger problems That's all
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.