EssEss wrote:the flag represents when a 'hard' tooth edge arrives ? or is set whenever a position prediction is made (btwn hard edges) ?
also, the position value will never 'miss' locations ? as in, it's guaranteed to cnt up 0 to 65535 and never skip ?
I'd spec those two things
Is there an overall 'sync/unsync' flag ? or is this the WHEEL_DATA_GOOD flag ?
since this is for a 4-cycle operation only, I didn't see any spec which specifies a cam sync input to know which phase the motor is on. Along with that, I'd spec the decoder behavior to specify what state to expect (as a consumer of the decoder) until the decoder figures out what phase its on (is it simply 'unsynced' until phase info arrives ?)
how will you handle cam decoding ? is it just another 'instance' of a decoder ? this decoder would also have to handle 0-360 only since 0-720 dosen't make sense for a cam decoder. at that point a universal decoder spec might not be possible unless it handles both 0-360 or 0-720.
I have lots more questions. But I don't want to overload you
I have a couple of prop devboards and wouldn't mind testing anything as it pops up.
The NEW_WHEEL_POSITION flag is set every time a 'hard' tooth arrives, is found to be valid, and its position is written to LAST_KNOWN_POSITION
The LAST_KNOWN_POSITION is nothing more than the position of the last tooth to arrive; if NEW_WHEEL_POSITION is cleared, LAST_KNOW_POSITION has no meaning. By definition it will always skip.
The WHEEL_DATA_GOOD is an overall 'sync' flag.
Actually there is a madness to my method of not specifying whether there is a cam sync input or not: the actual "decoder object" will be completely different code depending on the crank/cam input configuration. I am actually mulling over specifying two extra flags called ENGINE_PHASE_0_TO_359 and ENGINE_PHASE_360_719 that will be used to determine whether the cam sync signal has arrived yet, and dropping the LAST_KNOWN_POSITION variable to only 0-359 degrees. Short of writing a lengthy spec, i'll try to explain in a nutshell: if ENGINE_PHASE_0_TO_359 is set, the injection and ignition logic will fire all channels associated with that phase at their respective angle. Same with ENGINE_PHASE_360_TO_719. The hidden advantage is if the actual phase is unknown, BOTH flags can be set and the associated injection and ignition channels will fire during both phases. Simple logic in the "injection" and "ignition" objects can detect this and drop the fuel pulse width by 50%. If a cam input is never specified, the engine always runs as wasted spark and two fuel pulses per full-cycle per channel. I think 2-cycle operation is not out of the question: just never set ENGINE_PHASE_360_TO_719 and only configure the required ignition and injection channels to fire on the first phase.
Another important aspect to understand is by "object" I don't mean "core" or "Cog". I specified one or two cogs, which are contained and started by the "object", depending on how the programmer wants to tackle a given wheel setup. For example, for Subaru 6/7 only one Cog would be needed to monitor both the cam and crank signals, as they never have the risk of occurring simultaneously. However, for a generic missing tooth crank wheel in conjunction with an arbitrarily-phased cam trigger one may want to dedicate one core for the crank input and one for the cam in case they occur at the same time or within one processing loop. How the two cogs interact with each other in memory to set/clear the required flags and variables is up to the programmer. As long as the proper memory locations are written to with correct information, the remainder of the firmware doesn't care.
Another key aspect: absolutely *no* angle prediction is done by this object. It just "drops new
known position and speed information off" to the "simulator object" that I am working on the next section of the spec on my website. LAST_KNOWN_POSITION is definitely not directly referenced to time the fuel injection or ignition. That is the role of CURRENT_POSITION, a globally-accessible integer stored in Port B, and written to by the "simulator object".
Remember, we have 8 cores that we can dedicate to different functions, and slower, less time-critical operations will be done on a second chip
A summary of all the cores I predict on the "Coordinator" chip:
1 Cog: Main Object (bootup operations, watchdog, timeout, etc)
2 Cogs: Comms Object (duplex high-speed serial chip-to-chip)
2 Cogs: Decoder Object (crank and/or cam inputs)
1 Cog: Simulator Object (predicts and increments engine position, sets flags on rollover)
1 Cog: Injection Object (starts injection based on crank angle + flags, ends injection based on time + flags)
1 Cog: Ignition Object (start dwell based on crank angle + flags, fires coils based on crank angle + flags)
Total 8 Cogs
The "Supervisor Chip" will do all of the math and send the resulting pulse widths and angles back on the high-speed comms bus.
8 Cogs I haven't sorted out yet.
Perhaps this image will help: