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