multiple parallel pulse measurements and generation

[efiLabs]

i have a particular automotive tuning application where i have to deal with ignition and fuel injection timing (old stuff in the new e-mobility time)

here are some loose specs

a single injector has a min on time of about 1 ms at a min repetitive period of 7 ms and i need to support a minimum of 4, reading 4 input timings and outputting 4

the crank sensor can have a min pulse timing of 300 us, one timing in and one out

and i need to shift them all around and make them longer or shorter individually

i have done this many times before having plenty of timer cap-comps available which work directly off pins

also what's the absolute max time the softdevice is stealing from my high priority intrs ... i read something about 235 us, which means to me that i can't respond faster than, let's say 270 us, if i have to do some simple number crunching on timer capture input timing measurements versus outputting the change

i would need to have the crank sensor on timer cap/comps supported by gpiote and ppi which eats up at least one gpiote channel since this is a timing sensitive signal

now i'm short one at least to support reading 4 injector in timings and outputting them with a changed timing using gpiote channels

i think i absolutely need some of the remaining gpiote channels for the input timing measurements using timer cap regs and ppi

is there any way to hijack other peripherals pin support to link the timer comp event to it to flip the pins ... i was thinking about the pwm or similar ... you guys know your peripherals best

i was initially very happy counting all timer cap/comps totalling 20 (2 x 4 + 2 x 6)

now is the wakeup from this timer dream and it seems that the 8 gpiote channel limitation renders the vast amount of timer cap/comps a waste

maybe i'm missing something but how can all these cap/comps be used without i/o support

injector timing :

there is a total of 4 (desirable 6) injectors and their timing is independent of each other

t-period times are different on all periods due to rpm variations

the inj-in on-time needs to be stored for 2 reasons

one being that the inj-out on-time is a const t-dly time delay later output

second being used for the inj-in t-on duration measurement

the inj-out t-on duration is calculated based upon t-on in and some adjustment from an rpm / maf-sensor map

the inj t-period will vary between 7 ms to 200 ms

the shortest t-on time is about 1 ms

t-adj is about the shortest t-on duration, 1 ms

crank sensor timing : only one sensor

t-period times are different on all periods due to rpm variations

the only important timing is the pulses leading edge time which is to be output at a delayed time later based upon a calculation from the crank sensor t-period which is a fraction of the engine rpm and an ignition data map value

there is usually one tick for every 360 deg missing to provide a crank position indication

the shortest crank sensor t-period is about 300 us at max rpm

this is a new pict of the injector timing relations ... please find the description below the pict

inj-timings.pdf

inj-timings.jpg

1. gpiote-ch0 and timer1-cc0 are being set up for capturing the leading edge-on inj0-in event

2a) capturing isr for item 1 (leading edge-in cc) sets up the capture of edge-off inj0-in on the same gpiote and timer1 cc0 ... this ties up one gpiote channel and one timer1 cc reg

2b) it also sets up the leading edge-on inj0-out delayed on-time on gpiote ch1 and timer1 cc1

now totaling 2 gpiote channels and 1/2 timer1 (cc0 for iput capture and cc1 for output compare) for a single injector

3a) there are now 2 scenarios possible ... capture edge-off inj0-in event (end of input pulse) happens before expiration of time delayed leading edge-on inj0-out event (start of output pulse)

capturing isr for edge-off inj0-in event will overwrite the already setup delayed inj0-out time to a bit more than the possible max softdevice isr latency time after the current timer value ... this will define the final leading event-on inj0-out time

since this isr captured the edge-off inj0-in event, it now also sets up for the next leading edge-in inj0-in event capture at item 1

3b) afterwards, the new time delayed edge-on event inj0-out isr will set the edge-off inj0-out time

3c) second scenaro is that the time delayed leading edge-on inj0-out event happened before the edge-off inj0-in event

this event sets a flag for the edge-off inj0-in isr to indicate that the delayed out event already happened

4. the edge-off inj0-in isr has the flag and the inj0-in pulse duration and can now set the edge-off inj0-out time, it also sets up for the next leading edge-on inj0-in event capture at item 1

any thoughts and help are always highly appreciated

cheers Klaus

timings.pdf

[MartinBL]

I'm not sure if I fully understand your use case and reasoning.

1. Is it so that you have 4 asynchronous input signals and you need to measure frequency or ducy cycle, etc. on each signal?
2. Do you need 4 asynchronous outputs? What kind of waveforms should these produce?
3. Here you can see overviews over how much time the Softdevice might steal from your CPU in various roles and states: Bluetooth low energy processor usage patterns
4. If you are generating some sort of square waves then maybe you can use the PWM?

[efiLabs]

hi Martin :

thanks, i have updated the questions and added an timing.pdf file

[MartinBL]

I'm still not sure if I completely understand your use case. I suppose you have an engine of some sort with four cylinders. Then based on the crank position you need to time the fuel injection? And you have 4 inputs from crank position sensors and four outputs controlling fuel injection? Do you need more than 8 GPIOTE channels to control 4 output and 4 input pins?

[efiLabs]

the firmware captures injector pulses and outputs them a defined delay time later with a change in the pulse length (shorter or longer)

i need to capture the leading edge of the inj pulse and the end of this pulse in "capture regs" ... now i have the pulse start time and pulse length time

i need to output an inj pulse starting a defined delayed time after the leading input edge of the input pulse with a changed pulse time length calculated from the input pulse time length and some math ... and this all times 4 for individual injectors ... there is no correlation between them, they are treated individually

it looks to me that i need 4 gpiote input channels for the edge detect being handed via ppi to 4 timer capture regs which eats up timer 1

a capture leading edge interrupt (of some sort) provides the cpu with the pulse in start time for setting up the delayed pulse out time generated by a timer compare event setup by this isr ... the compare event via ppi will flip the leading edge of the output pulse

a similar mechanism can be used for the trailing edge of the output pulse

now another 4 compare regs of timer 2 are used up as well as 4 more gpiote channels are used by the injector output pulses

result : timer 1 is all used up for 4 inj capture events

timer 2 is all used up for 4 inj compare events

4 gpiote channels are used for inj input edge detection and 4 more for inj output generation

the crank sensor (only one, but faster pulses) works in a similar manner, where only the leading pulse edges need to be output with a variably time delayed ... the pulse duration can be used in a constant way

well, there are 2 more timers with capture and compare support

however, how do i feed them (edge detect and flipping output bits) if all 8 gpiote channels are used up

i do not see a way to still serve the crank sensor delayed pulse output

i have not used timer captures or gpiote or ppi channels at this time ... i'm still trying to find out how much functionality can be provided by the 52832 mcu

a change in engine rpm will be reflected in the changing total pulse period times

[MartinBL]

Ok, I think I get it. Sounds like a challenge. So referring to your diagram,

1. t-delay depends on t-period? I guess that shorter t-period -> shorter t-daly?
2. Does t-on also depend on t-period?

I are some thoughts:

What kind of latencies can you tolerate?

Maybe it is possible to reconfigure GPIOTE channel 0 in the interrupt and use the same channel, but a different pin and configuration, to toggle inj-out. Then you would need a second interrupt to configure the GPIOTE channel back to inj-in configuration though. If this is possible I think you can get away with a single timer and a single GPIOTE channel per injector.

Since the injectors are asynchronous I'm pretty sure you will need a sepparate timer for each injector. No way around that I think.