[info] rusEfi Scheduler Performance & Accuracy

It's all about the code!
Simon@FutureProof
contributor
contributor
Posts: 413
Joined: Tue Jul 24, 2018 8:55 pm
Github Username: Orchardperformance
Slack: Orchardperformance

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Simon@FutureProof »

That's not actually surprising.

When I raised the question of timing accuracy at work the consensus was 0.5 degree at 6000 was plenty good enough and that anything tighter may just be a statistical improvement and little gain in practice.
Now keeping MRE in stock in the UK - https://www.FutureProofPerformance.com
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

On the dyno, .5 is about 1%, maybe a bit less....depending on the engine. Older stuff that wants 30-35 degrees, .5 degree matters less. Modern stuff that might want 15-20 degrees, 0.5 matters a lot more.

That said, the 0.5 average error isn't the big issue, it's the 3.5 degree random max error...that is unhelpful and its very hard to get rid of those "clunker" points using SW instead of dedicated hw....but for most a few points of retarded timing costing under 1% hp is a few price to pay for a low cost, high feature ecu option.

Then the Bosch number....that would be max worsted case...so rapid accel of delec at 12k, and the is also total, so mostly lag with the repeatability probably much better and closer to 1/10th the max total....they are rock stable.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

Question.

The timer(s) that you use, how many bits are they? Just talking with another guy about the S12/S12x stuff being 16 bit vs the newer gens of OEM chips with time coprocessors (eTPU or GTM), both I think using 24 bit timers....which made be realize I had no idea what you guys have? 16? 32?
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by AndreyB »

Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mck1117 »

The size of the timer counter isn't particularly important. The rollover logic to "extend" the timer is pretty straightforward. It's only complicated if you need to schedule events multiple rollovers in the future. Our 1mhz, 32 bit timer rolls over every 71 minutes, so that's not a concern.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

Thanks. Sadly the code means nothing to me....I can read very basic math functions, that's about it so thank you for the simple answer too :oops:

Ok, so with a fixed 1Mhz clock, and a common 36 tooth wheel, say cranking at 250 rpm = 9000 teeth/min = 150 teeth/sec = 6666 clock tic/tooth I think?

Across the missing tooth that is double so 13333....which puts you at about the same resolution an S12 can achieve with its 16 bit timers if I did that right?

....or about 1/255 the resolution an OEM ecu can achieve, again if my math is right? that's the answer right there I think, the best you can ever do with that scheme is equal a something like a MS but but you'll never quite get there because every now and then a point will hit while something else is finishing and add a touch more lag. With less than a 36 tooth wheel you wold kick their butts, more then 36 they beat you if they are adjusting the timer clock speed to match the trigger wheel and cranking rpm, if not you probably beat them with every setup.

Probably all most people need but also probably well short of OEM. When I was playing with the eTPU there were tables in the ref manual to help set the optimal clock speeds so I have to assume the OEMs do that, I know near the end I coded the basic math for it into o5e so the clock speed was optimized based on the specific engine setup and it wasn't that hard....not sure it's possible for you guys? With just 1 timer it I assume it needs to be able to time the entire cycle not just 1 tooth? The eTPU used 2 timers so the tooth time could run a lot faster.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

mck1117 wrote:
Tue Jun 16, 2020 9:14 pm
The size of the timer counter isn't particularly important. The rollover logic to "extend" the timer is pretty straightforward. It's only complicated if you need to schedule events multiple rollovers in the future. Our 1mhz, 32 bit timer rolls over every 71 minutes, so that's not a concern.
The 24 bit eTPU or GTM tooth timers are set to rollover between the missing tooth at something like 2/3 normal crank speed.....so their tooth timer is running a LOT faster. To match their resolution you need to run the timer at more like 100Mhz or higher, and with your 32 bit register that should still prevent rollover withing a cycle.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mck1117 »

mk e wrote:
Tue Jun 16, 2020 9:32 pm
With less than a 36 tooth wheel you wold kick their butts, more then 36 they beat you if they are adjusting the timer clock speed to match the trigger wheel and cranking rpm, if not you probably beat them with every setup.
I think you're slightly missing the point. Timer resolution and rollover behavior don't have much to do with your actual scheduling precision. 1us timing resolution gets us 0.036 degree of resolution at 6000 RPM, which is more than you could possibly need. If the timer were run faster, as it is on some ECUs with hardware accelerated timing/crank decode/etc, you don't necessarily actually get any better precision of when your events happen relative to the engine position. You might get some easier math to do (so that things happen at a fixed timer count, instead of angle), but it's not going to be a huge difference.

The actual limitations all come from CPU contention (multiple interrupts fire near one another, or if a global lock is held by another process), interrupt jitter (depending on if we're awake/asleep/in another interrupt, the latency can vary slightly, but only by a few cycles), trigger jitter (hardware and software), and output hardware jitter (the smallest of any of these factors).
mk e wrote:
Tue Jun 16, 2020 9:32 pm
but but you'll never quite get there because every now and then a point will hit while something else is finishing and add a touch more lag.
While a technical limitation, this isn't actually a concern while running an engine. Simple events like setting/clearing a pin only take 5-8us to execute, so you can get two pin sets as close as 5-8us together. But on a real engine, that can't actually happen for any pair of events that are both important: ignition happens every 60 degrees worst case (v12, 6 hits per rev), so they're guaranteed to not be super close to one another. The timing of anything other than firing ignition isn't nearly as sensitive to precise timing.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

maybe.

no doubt 1Mhz is .036 degree at 6k and if you are servicing the interrupt at that and getting the item processed before the next clock tick then I guess its a real number. The concern is that error propagates. The general rule of thumb is that if you want to pass a gauge R&R the gauge need to read 10 times the required resolution...so .036 becomes .36 for a 95/95 confidence, 95/90 you're probably around 0.1....the HW is not perfect, the signal has noise, all that adds up. In my o5e testing I found most commercial type sensors had to much noise to be used at all because the eTPU code was error checking the input and getting the sensor to trigger within the error window meant opening the window beyond the missing tooth window so find the tooth but miss the gap or find the gap and mis teeth, and you need resolution to detect the error and you need resolution to detect accel and decel, OEMs use that for mis-fire detection for example. I had a couple sensors I got from a big MS supplier, "we've never had a problem"....they were total sh!t so I know there was no way MS was error checking anything and more likely doing a running average of some kind.

Then you still need to service and process it....and you get the data you've posted in the past.

They aren't bad numbers and I am in no way saying they are...but they are far from OEM numbers. For sure you have lag. I think we talked about lag earlier in this thread, and all agree lag can be tuned out so its really not an issue if its repeatable. that is the discussion about accuracy vs precision, accuracy is how close you are the the accepted value and lag hurts accuracy but that tunes out. Precision is how repeatable it is and that is where the clunker points you had in the data sets you post just slam you statistically....they just blow the curve, the distribution become non-normal and you fail validation.

So what to do? Well, run everything faster so the clunker points are much closer to average points and even though the distribution is still non-normal it no longer matter and you pass validation. That is the brute force method and it works, that is a part of what the OEMs are doing running the tooth timers as fast as they do. The other part, which is also brute force, is divide and conqueror with multiple timers and multiple co-processors they all but eliminate clashing tasks. They get TOTAL crank error in the ECU itself to within 0.1 degree at all crank to redline (the eTPU code was validated to 0.1 up to 24000 rpm). Then when you add in the senor noise, trigger signal processing and circuits on the input and out put and Bosch says total SYSTEM error is within 0.75 degree max error...error multiples at every step.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

Thinking a bit more....I suspect the OEM need for crank position accuracy (not just precision alone) is about misfire. I'm not really sure there is another answer. For sure error multiplies but even then....I don't know.

Spark timing at all rpm and and fuel pulse duration at low power they also care a lot about....but you're numbers do seem fine for that. I know the older motecs were 0.2 degree timing steps and the newer 0.1 and I usually do 2 degree, then 1 then .5 then .2 steps when tuning but as pointed out, some engines the .5 step does nothing, so set it in the middle and call it done, others you do see a repeatable change at .2 so I know the ecu was in fact making the change and it mattered but I don't know how wide the distribution or the true accuracy. I never tried to measure it.....I did't know better back then I guess and just trusted them....I do know I had a haltech that would lose its mind and advance the timing enough to cause pretty bad detonation even sitting at idle so for sure bad stuff goes out the door sometimes (they recalled and replaced them).

I don't know.....but looking forward to seeing just how good you can get this!
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

It been a long time since I've touched the o5e stuff but I know I have a 5634 demo board loaded that will run when powered up. It has an eTPU crank/cam generator that we then jumper back into the ePTU crank/cam inputs for testing. The freescale engineer told me the demo eTPU code we used is the exact code they developed for F1 teams and later OEM use so it should represent what OEM ECUs do, or did 15 years ago. If you are interested in a comparison point I could send the board to you guy, its just sitting here.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

AndreyB wrote:
Sun Jun 14, 2020 2:16 am
Funny that you've asked today since we are working on a yet another improvement today, after being happy with scheduler for a while :)
Ok...so...its been a little over 3 weeks...did the changes help or weren't really needed and more trouble than they were worth? or???????

Inquiring minds what to know! :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by AndreyB »

That change did help but we definitely have a couple issues here and there. https://github.com/rusefi/rusefi/issues/1488 for example
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
ptnicu
Posts: 6
Joined: Sat Nov 14, 2020 7:40 am
Location: Bucharest

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by ptnicu »

Hi All,
I will like to place here some of my idea of improving scheduler an signal generation accuracy.

On the forum I've found different suggestion to use HW methods to generate signal injector and ignition signals.
MCU with dedicated IP to generate signals and capture trigger signal, FPGA with custom design, all these are adding cost and complexity.

My idea is based on several Application Notes of different MCU vendors STMicro, NXP, MICROCHIP.

[1] https://www.nxp.com/docs/en/application-note/AN4419.pdf
[2] https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-products-stmicroelectronics.pdf
[3] https://ww1.microchip.com/downloads/en/AppNotes/00003312A.pdf

The main idea is described from the [1] to generate PWM signal using DMA and timer.
For HW scheduling we can use an array of predefined GPIO port register values and program the DMA to increment source address from RAM
and to not increment destination address to write in peripheral register for each triggered transfer.
The accuracy of using DMA to generate signal will be dependent on the congestion of the AHB bus accessing CPU and DMA the RAM and Peripherals at the same time.
The delay should be minimal in the range of 4-10 clock periods from one event to the other.

The HW scheduler should work together with the SW scheduler. The SW scheduler will hold events that needs to be executed at specific position of the crankshaft in degrees 0..360(720?).
The HW scheduler will be started at the each detected tooth with values prepared at previous tooth.
The conversion from degree to timer ticks should be made at the time of programming the HW schedule table after the previous tooth was detected.
The HW scheduler will use double buffering schema to prepare next HW event table while first is executing.

Steps to follow
Before detecting 0 degrees at the crankshaft:
1: prepare SW scheduler with events for the next cycle in degrees.
2: prepare first HW scheduler buffer with events from the SW scheduler to execute during the first tooth in timer ticks. Take care of the events on boundary edges close to the next tooth(due to acceleration)

After detecting 1st tooth in Trigger ISR context:
1. Update DMA with buffer addresses from the first HW scheduler table.
2. Start the HW scheduler timer
3. Prepare second HW scheduler table for next tooth based of the current captured trigger signal.

After detecting 2nd tooth in Trigger ISR context:
1. Update DMA with buffer addresses from the second HW scheduler table.
2. Start the HW scheduler timer
3. Prepare first HW scheduler table for next tooth based of the current captured trigger signal.

After detecting 3rd tooth in Trigger ISR context:
1. Update DMA with buffer addresses from the first HW scheduler table.
2. Start the HW scheduler timer
3. Prepare second HW scheduler table for next tooth based of the current captured trigger signal.

...repeat

These are requirements that you may find on many modern age(>2010) MCUs :

1. Capability to set/reset/toggle pins with a single write to a register(no Read/Modify/Write).
2. Timers with output compare with counter Auto reload feature (these are usually used to generate PWM signal for electric motors).
3. The timer output compare channel should be able to trigger a DMA transfer request (this feature usually is used to update timer output compare register).
4. Sufficiently flexible DMA controller to configure triggering of the DMA from different sources or chaining of the DMA channels.

Focusing on STM32F4XX series we can use following:
1. GPIO
For changing port pins use the write only GPIO port bit set/reset register (GPIOx_BSRR).
Writing 0 to this registers will not change the value of the pin.
The values of this register will be stored in separate array for each port.
A dedicated DMA channel will be used for each port.
4 DMA channels for cover 64 pins sufficient for 16 cylinder engine.

2. Timer
Use TIM1 or TIM8 as trigger generation to the DMA.
Use Auto reload register for updating the counter with next the event timeout value.
Program DMA update counter value for the timer.
Configure the timer in counting down mode.

3. Output compare registers
Configure 4 compare channels to trigger separate DMA stream for each GPIO port.
Program output compare with 0 to trigger DMA transfer from GPIO pin array to GPIOx_BSRR register

4. DMA
Select DMA2 controller since in has 5 separate streams configurable to TIM1 or TIM8 OC and update triggers.
1 DMA channel will be used for transferring timer auto reload register values triggered by the update trigger of the timer.
4 DMA channels will be used for each GPIO port triggered by the output compare channels of the timer.

Advantage of this method is ability to execute update of all pins in one event.
Remove handling of near future events. No busy loops in ISR context.

To reduce jitter induced by the DMA transfer move stack and other variables in CCM RAM, use SRAM1 for first HW scheduler buffer
and SRAM2 for second HW scheduler buffer. So the DMA will have exclusive access the RAM. Configure DMA with priority higher than CPU on the BUS.
Those that know, do. Those that understand, teach.
Aristotle
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by AndreyB »

This is extremely cool but what kinds of practical differences would it make?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
ptnicu
Posts: 6
Joined: Sat Nov 14, 2020 7:40 am
Location: Bucharest

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by ptnicu »

This approach will reduce jitter induced by overlapping ISR (Trigger detection ISR, and scheduler execution timer ISR).
Only one interrupt will be needed Trigger detection ISR.
Removing of Critical sections while executing the events will increase accuracy of the Trigger detection, the CPU is not stuck while executing events. Removing of the busy loop placed for the near future events inside the Critical section will increase precision of the Trigger detection.
The events can be processed faster with 10 times much less delay between events( 4-10 clock cycles).

Biggest practical value will bring in engines with fast rate of acceleration since the event timer period value is calculated before the next trigger tooth. This will bring accurate ignition time.
To test this the simulator will need to generate crankshaft signal with reducing period time for each tooth in a cycle.

Also with 64 pins dual injectors and dual spark plug per cylinder(water/methanol) is possible for a V16.
And also DI is possible with multiple injection.

Thank you.
Best regards.
Those that know, do. Those that understand, teach.
Aristotle
ptnicu
Posts: 6
Joined: Sat Nov 14, 2020 7:40 am
Location: Bucharest

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by ptnicu »

Another reason for using HW event execution is to make the trigger decoder deterministic and make the last chart from the https://rusefi.com/forum/viewtopic.php?p=35366#p35366 post flat and under 1uS.
Removing uncertainty will make system resilient to spontaneous malfunction in the systems.
Those that know, do. Those that understand, teach.
Aristotle
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

HW......
Attachments
Mandalorian-This-Is-The-Way-Quote.jpg
Mandalorian-This-Is-The-Way-Quote.jpg (83.66 KiB) Viewed 13549 times
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by AndreyB »

With stm32 we are at the edge of RAM and DMA channel utilization, my fear is that adding DMA scheduler would have to go at the cost of removing something. (we kind oт should work on RAM usage reduction regardless)

Also a reminder that we have rusEFI working on Cypress and Kinetis, some of these HW platforms could be more suited for ECU but really M4 is just fundamentally not a platform designed for EFI.

I would love to see a PR for the prototype but I am not sure if practically it's worth the efforts - in my opinion at the moment same amount of efforts could bring more value in other areas of rusEFI.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mck1117 »

As interesting as it sounds, I have to agree with Andrey that it probably isn't feasible for us right now. The DMA controllers are already both quite loaded - 3 ADCs, UART, SPI (SD card logging!).

I just don't think it's necessary. The jitter requirements of an engine are actually pretty generous. Even at 10k rpm, 1 degree is still 17 microseconds. If you want to do hardware accelerated scheduling, you better also do hardware accelerated trigger decode, since that's actually more expensive than driving the outputs.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mck1117 »

oh - and even if it did work (which I think it could be made to), we'd lose some features like the engine sniffer that rely on being able to run code when we set/clear a pin.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

mck1117 wrote:
Sun Nov 15, 2020 12:08 am

I just don't think it's necessary. The jitter requirements of an engine are actually pretty generous. Even at 10k rpm, 1 degree is still 17 microseconds. If you want to do hardware accelerated scheduling, you better also do hardware accelerated trigger decode, since that's actually more expensive than driving the outputs.
1 degree is COMPLETELY unacceptable on a performance engine..

If you can hold 0.1 you're good to go. If you can hold 0.2 its acceptable. 0.5...yeah, getting close at least, 1 degree..... its a lawnmower controller.
The last data you guys posted was getting close....
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mck1117 »

mk e wrote:
Sun Nov 15, 2020 12:41 am
1 degree is COMPLETELY unacceptable on a performance engine..

If you can hold 0.1 you're good to go. If you can hold 0.2 its acceptable. 0.5...yeah, getting close at least, 1 degree..... its a lawnmower controller.
The last data you guys posted was getting close....
I agree - 1 degree is not acceptable. But at most engines running in the 7000 rpm range, 0.1 degree is a little over 2us. I've since made some other improvements since that last round of testing, so it's probably a little better than it was then. Back in january the stdev was just under 1us, aka 0.03 degree at 5k rpm.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

mck1117 wrote:
Sun Nov 15, 2020 12:50 am


I agree - 1 degree is not acceptable. But at most engines running in the 7000 rpm range, 0.1 degree is a little over 2us. I've since made some other improvements since that last round of testing, so it's probably a little better than it was then. Back in january the stdev was just under 1us, aka 0.03 degree at 5k rpm.
I agree that the last data you posted was very close but be careful with StDev on a non-normal distribution, which you have, as its undefined. Step 1 is a normality test, 2 step 2 is calculate StDev. I guess this is the next step....right now rusEFI is a very affordable ECU of hobby use, get to .1 degree TOTAL error to whatever rpm you define and its an ECU with no excuses to that rpm.

edit: just to be clear I recommended rusEFI to someone I like a couple weeks ago so I'm not hating on this project, I like it......I'd just like it more if it had 0.1deg total error :)

edit2; almost remember the point of statistics is to use a mall sample size to predict the larger population, when you already have thousands of data points you know the larger distribution so tools to help predict the distribution, list StDev, are irrelevant and all you need to do is look at the distribution to know exactly what you have.
ptnicu
Posts: 6
Joined: Sat Nov 14, 2020 7:40 am
Location: Bucharest

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by ptnicu »

Greeting!
Glad to see that i have raised interest in considering some change.
I am still new the rusEFI firmware so i do not know a lot on it current development plans.

Related to proposed HW scheduler:
I want to add that the TIM1 timer that drives the HW scheduler could be triggered via external pin directly from crank senzor programmed with [Polarity selection, Edge detector, Input filter], so that will bring actual of 4-10 clocks(160nS) accuracy from crankshaft to pin update, no more latency from the Trigger ISR to start the timer.

I am proposing a flexible way to add the HW scheduler and create a HAL for it so it can be implemented on any platform.
These features are available on any modern MCU that can do Audio DAC output.

Also wanted to mention RAM usage issue. For finding the pieces that consume a lot of RAM i suggest to place vars and code in separate sections for each file, then in the map file we can check what pieces consume a lot of RAM and optimize that code. Maybe the reason could be that using C++ increases the RAM consumption.

I do not know exact number of DMA used currently, but 16 channels should cover 3ADC, UART, SPI, and 5 HW event scheduler.
The DMA also can be prioritized with HW scheduler channels being the highest. Still it will not overload the bus since on each event it will do 5 transfers. That is for a V12(please correct if i am missing events): 12*(2inj + 2ign)*5(DMA channels)=240/cycle @12kRPM that is ~50 transfers/ms. Far less than the ADC or SD card. There is plenty of room for increasing the number of events.
Removing the scheduler timer ISR will free up a lot of CPU time that can be used for decoding the trigger.

The irony is that using DMA for ADC, UART, SPI, Logging and other non critical regions in the firmware is fine, but using it for critical and main feature of the ECU is viewed with scepticism.

Offloading the event execution to HW definitively will bring accurate trigger decoding. Since the event execution is triggered directly by the crank signal(not by SW), the decoding of the current tooth is decoupled from the execution of the scheduled event table computed in at the previous tooth.
Also in order to have accurate decoding there should be no disabling of the interrupts. And the Trigger decoding ISR should be with the highest priority.

How I see the HW decoding of the crank signal:
Use 32 bit timer with input capture with triggering on both edges, and filtering! like TIM2 and TIM5.
32 bit is needed for reliable slow cranking trigger detection.
Configure the Timer in PWM capture mode see chapter 18.3.6 PWM input mode from Reference Manual ().
image.png
image.png (40.71 KiB) Viewed 13493 times
Generate ISR after both values are captured, the last captured period should be the active signal.
In the ISR read the values from registers, store them in a table.
Process the values and find if the engine is accelerating/decelerating based on the previous read values.
Calculate probable time for the next tooth period.
Adjust the next event table timings based on the next tooth period time and fill the HW schedule buffer.
For logging purposes you can store updated event times values in a separate table.

Decoding of the signal is done outside the ISR since there is no need for this information at this time.
Filling the SW event table also is done outside of the ISR for the next cycle.

This is more of a high view of the trigger detection.
The main idea is to deffer calculation to a later time.
Use HW timers for capturing and filtering the signal.
This is also can be done on any MCU with electric Motor control feature.

All these changes may be seen as huge change but in reality it will bring simpler code, and determinism for future developments.

The only reason the change the CPU should be the RAM capacity, for adding more features.
Maybe add some cheap SPI NVRAM like 48LM01 for less critical storage/debugging.
Kind regards,
Nicu.
Those that know, do. Those that understand, teach.
Aristotle
Gepro
Posts: 100
Joined: Sun Nov 01, 2020 2:15 pm
Location: France

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Gepro »

mck1117 wrote:
Sun Nov 15, 2020 12:08 am
As interesting as it sounds, I have to agree with Andrey that it probably isn't feasible for us right now. The DMA controllers are already both quite loaded - 3 ADCs, UART, SPI (SD card logging!).

I just don't think it's necessary. The jitter requirements of an engine are actually pretty generous. Even at 10k rpm, 1 degree is still 17 microseconds. If you want to do hardware accelerated scheduling, you better also do hardware accelerated trigger decode, since that's actually more expensive than driving the outputs.
If CPU is busy, is it possible to put 2 STM32 by ECU ? They are cheap, and some values can be send via canbus, I don't know how many resources take canbus, but there is not a lot of important value.
VR/hall, MAP and TPS are the only importants values for injection, I believe. (and maybe knock, I am not totally sure about it)
For control, there is ignition for sure, and injection (that can be delayed, but not that much)

Wideband / AIT / CLT are already laggy, so can be send to canbus. With ETB, it's the same, the throttle become laggy and TPS can be send via can.
The boost control can also be done by the second stm, it just a have to use his proper map sensor.

I speak of can, but maybe SPI is faster ? If spi is even faster, maybe we can have a CPU only for ignition control ? If the response time is fixed, it isn't a problem for injection.

I don't know if the H7 is good for rusefi, and if it's planned, but I believe the 2 cores version can be use in the future.

Personnaly, i don't see any problem on the accuracy, 1° is fine, and the fuel is not always the same too, the octane can vary a lot at the pump.
In france, for exemple, the E85 vary to 85% in summer, to 65% in winter, and we don't have any values on the real octane after that.
That the same for LPG, there is 112 octane for propane and 94 octane for butane, the mixture changes in summer and winter.

When we are complaining about accuracy, I think that we must have a real reason with a precise tuning, that means precise "filling table" by cylinders, with perfect tune by air temperature and baro value.
For now, I haven't see tuning by injector in tunerstudio with rusefi. That show the RusEFI is not a Formula 1 ECU, and for the price and the possibility, I really don't care.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mck1117 »

Played with the scheduler a bit tonight. Used a fast interrupt (can preempt even the kernel) to get the trigger input timing measurement jitter down to essentially zero, completely redid how time is sampled, switched event scheduling to use the same timer as time measurement, and it makes a big difference:
image.png
image.png (83.65 KiB) Viewed 13467 times
Sampled for 3 minutes in each case at ~5800rpm, that's a histogram of how late the ignition event was vs. nominal (microseconds). Notice that the scales are identical in both histograms. The grouping in the right hand side case is 0.16 degree wide at 5800 rpm.

This was on a 4cyl, USB connected and TS running (and data logging at ~150hz!).

There's still plenty of room left in the software implementation :) If I pulled the same trick on the scheduling side as I did on the trigger input side, it'd probably chop the jitter in half again.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mck1117 »

Developed with this definitely-not-sketchy setup:
image.png
image.png (6.77 MiB) Viewed 13465 times
2x STM32F405RG (functionally identical to F407VG on microRusEfi/Frankenso/F4 Disco and the F429ZG on Proteus), top one running rusEfi and the bottom one generating a 60-2 trigger signal.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

mck1117 wrote:
Sun Nov 15, 2020 1:49 pm

Sampled for 3 minutes in each case at ~5800rpm, that's a histogram of how late the ignition event was vs. nominal (microseconds). Notice that the scales are identical in both histograms. The grouping in the right hand side case is 0.16 degree wide at 5800 rpm.
Much improved! nice work!

Let me check the math though...its a bit hard to read but it looks like the 1sr bucket is 1.9ms, the last at 4.2?, so 2.3us difference?.

5800(rpm)=96.667(rps)=0.0348(deg/usec)
.0348(deg/usec) x 2.3(usec) =.08 (deg), twice as good as you're claiming and quite excellent!

Are there some points hiding further to the right? Or is my math wrong?
ptnicu
Posts: 6
Joined: Sat Nov 14, 2020 7:40 am
Location: Bucharest

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by ptnicu »

Great results!
mck1117 wrote:
Sun Nov 15, 2020 1:49 pm
Sampled for 3 minutes in each case at ~5800rpm, that's a histogram of how late the ignition event was vs. nominal (microseconds). Notice that the scales are identical in both histograms. The grouping in the right hand side case is 0.16 degree wide at 5800 rpm.
Could you simulate rapid change of RPM from 1000 to 5000 in less than 100ms and decelerate with the same rate?
To simulate fast gear change.
Those that know, do. Those that understand, teach.
Aristotle
Post Reply