Output Pin Requirments(xgate fuel and ignition)

[SleepyKeys]

I would like to summarize the required behavior for bit banged outputs given a scenario.

The following formula will be assumed for the given parameters(decoderInputEdge16, channelNumber16, startTime32, stopTime16).

correctedStartTime = (currentTime - decoderInputEdge) - startTime;
stopTime = correctedStartTime + stopTime;

Having the channelNumber 16 bits is excessive but it doesn't save any room or processing time to change it to an 8 bit parameter. This also gives us *free bits to do special things.

Arithmetic examples using one schedule per output channel:

1. a pulse(10ms,10ms) has been requested and no other events are scheduled on that channel.
______10ms_______|-----10ms-----|____________________________

2. a pulse(10ms,10ms) has been requested but there is an existing event scheduled(20ms, 20ms) that has not started yes.
______10ms_______|-----10ms-----|____________________________ (complete overwrite)

3. a pulse(10ms,10ms) has been requested but there is an existing event(5ms, 30ms) that has been running for 15ms.
__5ms____|-------------25ms------------|____________________________ (event shortened)

4. a pulse(10ms,10ms) has been requested but there is an existing event(5ms, 15ms) that has been running for 15ms.
__5ms____|-------------25ms------------|____________________________ (original event extended)

This allows for both zero and 100% DC. This also allows multiple schedules to share the same pin and will behave as long as you don't achieve 100% DC(fuel purposes).

Examples using multiple schedules per output channel as it is now:

1b. two pulses have been scheduled at the same time (5ms,10ms/10ms,20ms)
__5ms_____|-----10ms-----|__________
15ms will be lost which is improper for fueling

2b. two pulses have been scheduled at the same time (5ms,10ms/20ms,20ms)
__5ms_____|-----10ms----|__5ms__|----------10ms---------|_________

Once I make sure what I have is correct I will add the necessary overhead to correct the example in 1b.

-sean

[Fred]

This thread still needs a major update, but I just found this simple set of tests in the firmware and thought this was the right place for them:

Practical tests to be performed to ensure no regression prior to each release :

Fuel :
1. Increase and decrease of pulse width to extremes both below max pulse width threshold and above.
2. Increase and decrease of timing both when it does and doesn't affect overlap of schedule with or when pulse width is longer than cycle.
3. Increase and decrease of RPM such that pulse widths do and do not overlap, and both.