[info] rusEfi Scheduler Performance & Accuracy

It's all about the code!
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

[info] rusEfi Scheduler Performance & Accuracy

Post by mck1117 »

This thread was prompted by some questions asked in this thread: https://rusefi.com/forum/viewtopic.php?f=13&t=816&start=90

Background

For nearly all outputs, rusEfi uses a single global scheduling queue. This includes injectors, ignition coils, and PWM (idle, ETB, etc). When we decide that we know when an event will happen in the future, we schedule it to occur later. Scheduling an event inserts it in to a priority queue of all future scheduled events, and sets a timer to expire when the first item in the list should occur.

What does "Scheduler Performance & Accuracy" mean?

The scheduler's job is to provide precision scheduling for outputs and other events. Ultimately, if the scheduler is doing its job, the following will be true:
  • Injections will be of the correct duration (fuel quantity)
  • Injections will begin/end at the correct engine phase (SOI/EOI timing)
  • Ignition events fire at the correct time (is ignition timing correct? This one makes power!)
  • PWM duty cycle & frequency are correct
  • MAP sensor windowing is measuring manifold pressure over the correct interval
How do you measure the scheduler?

I made measurements by "running an engine" on the bench. I connected together a pair of STM32 F4 Discovery boards: one simply generating a trigger at 5000 rpm, and the other "running the engine". A Saleae logic analyzer was then connected to monitor the trigger input, and a few each ignition and injection outputs. Logic analyzer data was exported to Excel, where analysis was performed.

Findings are presented are in the following posts.

tl;dr: As-is performance was okay, but not great. A few relatively straightforward changes improved accuracy by an order of magnitude.
Last edited by mck1117 on Fri Jan 10, 2020 9:30 pm, edited 1 time in total.
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 »

Here's what the world looks like today.

Both this test and the next were performed under identical conditions, only swapping out the code running on the mcu. The ECU was running a v8, sequential ignition and fueling, at 5000 rpm and 30 degrees of ignition advance. That equates to around 60-70 total events scheduled per revolution, or an average of one event every several hundred microseconds.

5000rpm/30 deg means that we would expect the ignition coil to fire (falling edge) 1 millisecond before top dead center. The actual value was measured with a Saleae logic, and the delta from target computed for around 3000 samples (approx 1 minute).

Here are the results for the current scheduling:

Image

These numbers are advance error, so negative values indicate that the event occurred late (retarded ignition timing). The earliest event (most ideal, in this case) was 1.4 degrees late, and the latest was 2.6 degrees late. Average and median were both right around 2 degrees later than planned.

These data indicate that at 5000 RPM your timing could vary up to ~1.5 degrees between ignition events.

Even more interesting is the shape of the histogram.

Image

(x-axis are bins of different amounts of error, retarded timing towards the left. y-axis are count of events within that bin)

A normally distributed error (like one would expect from random variation) would be shaped like a bell curve. However - the histogram shows three distinct peaks, with gaps of 12-14us between them. In reality the ignition timing isn't well centered around the average, but is instead likely to occur near one of three conditions: 49us late, 61us late, or 75us late (1.5, 1.8 or 2.3 degrees retarded, respectively).

Instead of random noise, this is correlated noise. This indicates that something of fixed time (likely an interrupt) is getting stuck before the scheduling of the event, causing unpredictability in when it will occur.

There is a positive kernel here: Even though the distribution looks pretty bad, the distribution within each of the three bumps above is actually pretty good. Each bump is only about 5-6us wide (<0.2 degree). Foreshadowing: This means that if we can avoid whatever is causing the three distinct buckets, our whole distribution should end up only 5-6us wide.
Last edited by mck1117 on Fri Jan 10, 2020 11:34 pm, edited 2 times in total.
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 »

Okay, now for the data after I implemented some improvements in these three pull requests:

https://github.com/rusefi/rusefi/pull/1090
https://github.com/rusefi/rusefi/pull/1091
https://github.com/rusefi/rusefi/pull/1092

Here's the statistics from a capture under identical conditions to the previous post, but with modifications to how we schedule ignition events:

Image

And a comparison between old and new (in microseconds):

Image

Standard deviation decreased by a factor of 13, and average accuracy improved from 62us (1.9 degrees) to 5us (0.16 degree).

Most importantly, the histogram now looks correct:

Image

(note: it looks light its right biased, because it is. That just means that events never arrive early, but sometimes arrive late.)

Also note that the bump at the right side is only 2-3us wide, commensurate with the standard deviation of just less than 1us.

So why did it get so much better?

Previously, during the trigger event, we decided what spark events needed to be scheduled before the next trigger tooth, then scheduled them. That scheduling spaced the event out from whenever the actual call to schedule was made, not from the trigger tooth. The 3 above changes take a timestamp very very early in the process, then reference everything to that timestamp. We're not even in a rush to get the processing done, because we know when to reference our timing from, and aren't re-measuring it later.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

That looks a LOT better, well done!

A single mode shift of 0.2 deg is really not an issue, it will be adjusted for in the tuning. My only slight concern is it really looks like the 0,1us bucket is much bigger than it should be....suggesting a bi-modal distribution.

Do you have an software to run a normally test on the data? Looking at it I'm pretty sure it would fail for skew (there is only 1/2 a bell curve and the tail is extremely long) and that almost always mean there are at least 2 significant factors driving the distribution. This isn't really a concern a lot of the time but most statistics assume a normal distribution and can't be used......like you can't just say average +/- some number of SDevs = capability. ....so there is still something there driving the skewed distribution and its probably worth hunting for because if you can find it you'll have a really good setup.

Have you looked at the time it takes the processor to calculate the fuel and spark info maybe say as RPM changes? That would be the only other metric it would be nice to have. This is way less important that what you've already done but it would be nice to see the processor isn't being buried in interrupts and never finding time to do normal business...maybe run with TS connected and data logging so at full load.

Edit: it might also be worth repeating the you did at several rpm settings....you have 5k and below is probably only better but maybe 2500, 7500, 10000? if the error/lag is time based then the error should be linear with rpm and .2 deg at 5k should become 0.4deg at 10k which would be good to know but again as long as the distribution is tight then it will wash out in the tuning but if the distribution grows then it becomes an increasing concern I think.
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:
Mon Jan 13, 2020 6:53 pm
A single mode shift of 0.2 deg is really not an issue, it will be adjusted for in the tuning. My only slight concern is it really looks like the 0,1us bucket is much bigger than it should be....suggesting a bi-modal distribution.
I completely agree - the distribution absolutely is NOT normal, for good reason.

The one-sided distribution occurs because:
  • Sometimes we have a global system lock taken, which (effectively) disables interrupts until unlocked
  • Interrupt latency can vary slightly depending on whether the processor is in another interrupt, asleep, or not in an interrupt.
Note that neither of these things can accelerate the passage of time, which is why the distribution is one sided. It's physically not possible for us to be early (if the math is correct, which it is). This is sort of good that the long tail is in the late direction, since an early spark is very bad, but a late spark is sort of okay (but loses you some power, whatever).
mk e wrote:
Mon Jan 13, 2020 6:53 pm
Have you looked at the time it takes the processor to calculate the fuel and spark info maybe say as RPM changes? That would be the only other metric it would be nice to have. This is way less important that what you've already done but it would be nice to see the processor isn't being buried in interrupts and never finding time to do normal business...maybe run with TS connected and data logging so at full load.
We have perf tracing to look at exactly what the processor is doing in each interrupt/thread. Here's an example trace:

Image

The trigger interrupt (ISR 45 above) takes only around 100us total. That includes trigger decode, rpm calculation (those two are actually the cheap part), fuel scheduling, and ignition scheduling. This was captured on the same setup as I used for the testing above, which is a worst-case scenario. It has a large number of cylinders and a small number of trigger teeth, so on average it has to schedule a lot of events every tooth. One of our stm32f7 ECUs will be slightly faster, probably around 70us.

Besides, each interrupt/thread has its own priority, and they're ordered such that things like USB, Tunerstudio, the onboard LCD, LED blinking and even CAN bus will die so that the engine can keep running.
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:
Mon Jan 13, 2020 6:53 pm
Edit: it might also be worth repeating the you did at several rpm settings....you have 5k and below is probably only better but maybe 2500, 7500, 10000? if the error/lag is time based then the error should be linear with rpm and .2 deg at 5k should become 0.4deg at 10k which would be good to know but again as long as the distribution is tight then it will wash out in the tuning but if the distribution grows then it becomes an increasing concern I think.
I didn't try it at any other engine speeds, but this behavior is time dependent, not angle dependent, since it has to do with other interrupts/uncertainties getting in the way of flipping the pin. So 0.2 degree at 5k would be 0.1 degree at 2500, and 0.4 degree at 10k.
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by puff »

great work!
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by kb1gtt »

What is this picture that note the isr45? I don't see x numbers or units for either axis. I'm not sure what it is trying to convey.
Welcome to the friendlier side of internet crazy :)
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

mck1117 wrote:
Mon Jan 13, 2020 8:19 pm

Note that neither of these things can accelerate the passage of time, which is why the distribution is one sided. It's physically not possible for us to be early (if the math is correct, which it is). This is sort of good that the long tail is in the late direction, since an early spark is very bad, but a late spark is sort of okay (but loses you some power, whatever).
Well.....for sure its physically impossible to have the mean at 0 but you'd still expect a normal distribution, at say 0.2 deg lag. The distribution is a function of the logic you're using and as I understand it all the time events in a single que. If there is nothing happening when an interrupt comes in its acted on in about 03us, if there is a list it might be 17us. Is the crank a higher priority?


mck1117 wrote:
Mon Jan 13, 2020 8:19 pm
Besides, each interrupt/thread has its own priority, and they're ordered such that things like USB, Tunerstudio, the onboard LCD, LED blinking and even CAN bus will die so that the engine can keep running.
Does the priority scheme ensure all interrupts are process? The ones (is in 1) I've worked with was setup so no interrupt could be skipped...if there was a list higher priority moved up but but only a couple times then it would run so the more you add the more all are affected, Yours doesn't work that way?

As rpm goes up the number of interrupts/sec goes up.....I would be surprise if at say 10k you measure the expected 0.4 deg......guessing I think I I would expect about double that, probably worth the bother to at least test 1 more rpm.
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 »

kb1gtt wrote:
Mon Jan 13, 2020 11:40 pm
What is this picture that note the isr45? I don't see x numbers or units for either axis. I'm not sure what it is trying to convey.
It's a CPU usage visualization called a flame chart. Each horizontal row represents one process or thread (in our case, each row is one interrupt). Time progresses from left to right (there's a scale up top that I accidentally clipped off). Each brick represents the execution of one function, with the width corresponding to the execution time. Bricks located below a brick are functions called from that function. Clicking on a brick lets you view the total elapsed time for that brick, in addition to (that brick's time) - (sum of all child bricks) to see how much that brick did itself excluding its children.

So in our case, the function mainTriggerCallback called functions handleFuel and onTriggerEventSparkLogic, and so on.

It's generated by logging timestamps (along with what event they are) to a buffer on the MCU for a short period of time, then pulling that buffer out and converting it to a json file that can be opened with Chrome's trace viewer (intended to profile javascript or Chrome itself - but can also load traces from elsewhere).
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:
Mon Jan 13, 2020 11:57 pm
but you'd still expect a normal distribution, at say 0.2 deg lag. The distribution is a function of the logic you're using and as I understand it all the time events in a single que.
Not necessarily - the (improved) data show that the best possible event was 2.92us us late. That means that if everything is optimal (no other interrupts in the way, caches are hot, optimal celestial alignment, etc), we can't do better than 2.92us, because that's roughly how long it takes to service the timer interrupt and read/dequeue/execute the event. Since we we can't get interrupted by a negative period of time, there's a hard stop that we can't be earlier than (2.92us late). That's why the distribution HAS to be one sided.

Also - some of that ripple in the histogram is actually aliasing from the way it was sampled. I had my Saleae logic analyzer set to only 12msps, so those 100ns wide bins will get some aliasing even with a uniform or normal distribution.

If you look at it without manual scaling turned on, it does look more like half of a normal-ish distribution:

Image
mk e wrote:
Mon Jan 13, 2020 11:57 pm
Does the priority scheme ensure all interrupts are process? The ones (is in 1) I've worked with was setup so no interrupt could be skipped...if there was a list higher priority moved up but but only a couple times then it would run so the more you add the more all are affected, Yours doesn't work that way?
I think the Cortex-M4f NVIC will allow starvation of low priority interrupts if there are many at higher priority, but don't quote me on that.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

I was misreading the histogram :P ....now I'm most confused. Where is the data -2.9 - -4.8?

Can you include crank teeth? Are they on the same priority or higher than what you're showing?

If the higher priority choke out the low maybe worth logging something like TS that should be relatively low priority at 5k and 10k.....I really think you are going to find a non-linear relationship. I suspect that at lower rpm it will be linear because as you say there is a min reaction time, but as rpm goes up the dead time will vanish, the response will become quite poor and non-interrupt items never done at all. If that point is 30k then who cares, but if its 10k it would be important to know.
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Rhinoman »

The main problem is that the code uses the ST like a PC rather than as a microcontroller. If you implement input capture and output compare as it is intended then the amount of jitter you get is limited to two clock cycles because it is independant of the main processor core.
Unfortunately what you have now is a very powerful processor that can't match the precision of a 1980s ECU running at 0.5MIPS.
User avatar
Dron_Gus
contributor
contributor
Posts: 450
Joined: Wed Nov 13, 2013 1:11 pm
Location: S-Pb
Github Username: dron0gus

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Dron_Gus »

Rhinoman wrote:
Tue Jan 14, 2020 8:41 am
The main problem is that the code uses the ST like a PC rather than as a microcontroller. If you implement input capture and output compare as it is intended then the amount of jitter you get is limited to two clock cycles because it is independant of the main processor core.
Unfortunately what you have now is a very powerful processor that can't match the precision of a 1980s ECU running at 0.5MIPS.
STM32 does not have timers with such advanced logic.
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by puff »

Isn't it a tradeoff for simplification of software development?

anyways, it would be nice to have same data at least for another test with higher RPM, and I missed - what was the trigger-wheel in this setup?
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

I think you said any PWM is also in this interrupt "line" but at a lower priority so as RPM increases at some point the lower priority PWM and SPI many not work......it would be very bad to leave the throttle on. Probably best to figure out where that happens so it can be avoided. The point will change with configuration so the output probably needs to be a table of some sort....2, 4, 6,8 cyl with a, b, c, 36, 60, trigger teeth, with x, y, z, optional outputs and gives the max recommended rpm.

From a purely safety perspective doing a FMEA would pretty much force you into finding another way to do time based control. Whether its adding a more sophisticated timer (The oem path) or just offloading critical things like ETB to a stand alone chip or unit.

But first things first.....best to collect a bit more data and figure out what is happening with each item as a function of time. If a V8 with a 60 tooth wheel is all good with everything is the system working and the fuel/spark calc complete at least every 20msec to say 15k and a 4 cyl to 20k then you're probably ok as is. Everything has a spec....spark the angle needs to within x deg, fuel the pulse time needs to be within y usec, SPI bus needs to be serviced at 8khz +/- ?msec...something like that so you know when its not working as planned. I work in medical and by law the specs need to be approved BEFORE product testing is done so its clear the specs are based on what is needed and not what the product can do....now development work doesn't count so what can be done does creep into specs but in general there would be a report that looks at say SPI buss frequency and jitter and recommends specifications.

Then in product testing we'd need to confirm the specs are being met. During verification each and every spec is tested and must pass with statistical confidence base on a risk assessment so a safety item like ETB would get a 95/99 or higher requirement but ignition that is performance not safety would get maybe 95/95, PWM for optional outs maybe 95/90 and user instructions maybe a 95/70....something like that.....but everything needs to work.

This is the suck part of development for sure but its pretty important.
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Rhinoman »

Dron_Gus wrote:
Tue Jan 14, 2020 9:37 am
STM32 does not have timers with such advanced logic.
Almost every microcontroller built since 1978 has these timers, the STM32F407 has 14 IC/OC channels although they may not all be usable if the parent timer is being used for a seperate function.
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Rhinoman »

puff wrote:
Tue Jan 14, 2020 9:57 am
Isn't it a tradeoff for simplification of software development?
I think its more a trade off of accuracy versus flexibility.
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Rhinoman »

mk e wrote:
Tue Jan 14, 2020 12:05 pm
From a purely safety perspective doing a FMEA would pretty much force you into finding another way to do time based control. Whether its adding a more sophisticated timer (The oem path) or just offloading critical things like ETB to a stand alone chip or unit.
Safety analysis would force you to use an automotive processor with support for ISO26262, in which case there are a large number of single and multi-core processors with advanced timers and many other features that are specifically designed to support engine management functions.
User avatar
Dron_Gus
contributor
contributor
Posts: 450
Joined: Wed Nov 13, 2013 1:11 pm
Location: S-Pb
Github Username: dron0gus

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Dron_Gus »

Rhinoman wrote:
Wed Jan 15, 2020 1:01 pm
Almost every microcontroller built since 1978 has these timers, the STM32F407 has 14 IC/OC channels although they may not all be usable if the parent timer is being used for a seperate function.
Unfortunately no one of this timers can be used to decode trigger wheel.
Ok, we can do SW decode. Let HW timer count tooths and start ignition/injection timer on N-th tooth.
Ups, timer input has no glitch filtering. So HW timer can loose sync on noise.
Ups, stm32 has no event distribution system to kick one timer from another.
So timer can be used to injection/ignition event generation with precise duration.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

Rhinoman wrote:
Wed Jan 15, 2020 1:09 pm
Safety analysis would force you to use an automotive processor with support for ISO26262, in which case there are a large number of single and multi-core processors with advanced timers and many other features that are specifically designed to support engine management functions.
I don't think so. If you're an OEM then you have no choice but to comply with any and all applicable standards but as a hobby yo have a lot more flexibility....as long as you've made an honest effort to go through and look at what could go wrong and addressed any that are a safety related I'd say you're good.

I think this is a GREAT project but I also think the path chosen has some limitation that should be understood. Any aftermarket ECU has a limited number of functions that can be used at the same time, limited I/O, and an rpm limit. With open source anyone can setup of change anything with is a double edge sword because it normally means people running stuff that has never been properly tested. In the closing o5e days we were talking about and did lock down the main repository so people like me who make mostly mistakes didn't make changes to well tested code.

HW is a bit harder to control but controlling it is necessary. This code on that HW has been verified, any changes you decide to make have not been verified....and I ended up taking a pretty hardline on unofficial SW/HW discussion and gave them their own section on the forum where no support was given. That upset a lot of people but its not a doorbell, its an ECU that needs to work, which means it needs revision control not just a repository to track, but actual control on how a new version is allowed and needs to include a documented verification....and having people read about options that were not tested and mostly couldn't possibly work was not helpful and cause me and a couple others to burn a lot of time putting out fires.....much like russian is pretty strict about what processor should be used....but that probably needs to be extended to a "these are the supported boards" not just processors.

This thread shows that what was ASSUMED to be accurate spark timing control left a bit to be desired in actual testing. It was functional and fine for a demonstration (which is no small thing to achieve and deserves a WELL DONE!!!) but is now much better and pretty close to where it should be.....at 1 somewhat softball test condition and only spark timing was verified so its unknown if all the other functions are acceptable or where the system limits are. One set at a time.....
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Rhinoman »

Dron_Gus wrote:
Wed Jan 15, 2020 2:00 pm
Unfortunately no one of this timers can be used to decode trigger wheel.
Ok, we can do SW decode. Let HW timer count tooths and start ignition/injection timer on N-th tooth.
Ups, timer input has no glitch filtering. So HW timer can loose sync on noise.
Ups, stm32 has no event distribution system to kick one timer from another.
So timer can be used to injection/ignition event generation with precise duration.
The 'old fashioned' way to achieve missing tooth without a linked timer was to run two timers, if an input capture event didn't occur within a fixed period, ie 150% of the previous time then the second timer would time out and generate an interrupt which is the sync. You're missing the point that input cature properly used is much more accurrate.
Timer input shouldn't need much in the way offiltering it is effectively a digital signal, filtering indicates poor hardware design. A small amount of filtering is usually an option on the input capture setting, its a fixed number of cycles and is automatically compensated for in the value returned.
You don't need event distribution, again you're missing the point, proper use of IC/OC means that high speed processing of the interrupts is not required, the values only have to be updated/read before the next event occurs.

Have you ever studied any OEM code?
Rhinoman
contributor
contributor
Posts: 256
Joined: Thu Sep 24, 2015 2:14 pm
Location: Wiltshire, UK

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Rhinoman »

mk e wrote:
Wed Jan 15, 2020 2:24 pm
I don't think so. If you're an OEM then you have no choice but to comply with any and all applicable standards but as a hobby yo have a lot more flexibility....as long as you've made an honest effort to go through and look at what could go wrong and addressed any that are a safety related I'd say you're good.
The legal term is Ignorantia juris non excusat - ignorance of the law is no excuse. If you're a hobbyist building an ECU for yourself then you don't need to go through all the OEM stuff, at least in the EU there is an exemption, but you are still held responsible if anything goes awry. as soon as you start selling stuff then you are responsible. If you include an ETC then you should be at ASIL B minimum.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

Rhinoman wrote:
Thu Jan 16, 2020 1:22 pm
mk e wrote:
Wed Jan 15, 2020 2:24 pm
I don't think so. If you're an OEM then you have no choice but to comply with any and all applicable standards but as a hobby yo have a lot more flexibility....as long as you've made an honest effort to go through and look at what could go wrong and addressed any that are a safety related I'd say you're good.
The legal term is Ignorantia juris non excusat - ignorance of the law is no excuse......
That doesn't apply to what I said. First, a standard is not a law, at least not in the US, unless its been adopted as a code of some kind. Then I said there is no requirement to follow any standard (because its not a law, its considered guidance), I did not say there is no requirement to do a safety assessment and whatever testing follows from that assessment. Standard are often a great place to start and any honest assessment would need to include and evaluation of the relevant standards...but there is no requirement to follow them. In business and perhaps in hobbies it is harder to explain an injury that occurred when standards are not followed, but following the standard does not remove liability of any kind so it always comes back to the safety assessment and the testing.

This is a open source hobby not for profit project....use at your own risk so the ultimate responsibility is with the end user, I just not 100% convinced the majority of end users fully understand that or what the risks actually are and that is were a thread like this that starts to lay out what testing has been done and what testing hasn't comes into play....and to your point clear more hasn't been tested than has. I would call it concept demonstration level, which is a great start but not an endpoint.
User avatar
Dron_Gus
contributor
contributor
Posts: 450
Joined: Wed Nov 13, 2013 1:11 pm
Location: S-Pb
Github Username: dron0gus

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Dron_Gus »

Rhinoman wrote:
Thu Jan 16, 2020 12:58 pm
The 'old fashioned' way to achieve missing tooth without a linked timer was to run two timers, if an input capture event didn't occur within a fixed period, ie 150% of the previous time then the second timer would time out and generate an interrupt which is the sync. You're missing the point that input cature properly used is much more accurrate.
Timer input shouldn't need much in the way offiltering it is effectively a digital signal, filtering indicates poor hardware design. A small amount of filtering is usually an option on the input capture setting, its a fixed number of cycles and is automatically compensated for in the value returned.
You don't need event distribution, again you're missing the point, proper use of IC/OC means that high speed processing of the interrupts is not required, the values only have to be updated/read before the next event occurs.

Have you ever studied any OEM code?
Ok. We can capture tooth time with high precision using timer. But scheduling injection or ignition pulses still need SW intervention. I see no advantage at this point. At least with STM32.
If we had some kind of free-runnig multichannel timer that captures trigger events and generate output pulses using same counter - yes, this will be more precise. But stm does not have such advanced timers. May be it is possible by using timer synchronization.

Yes. I dig few OEM implementation. But they designed for one type of trigger wheel. Also some use ASICs for time-critical stuff.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by mk e »

Dron_Gus wrote:
Thu Jan 16, 2020 2:13 pm
... But stm does not have such advanced timers. ....
[/quote]

hence the fpga thread
https://rusefi.com/forum/viewtopic.php?f=13&p=35305#p35305
User avatar
Dron_Gus
contributor
contributor
Posts: 450
Joined: Wed Nov 13, 2013 1:11 pm
Location: S-Pb
Github Username: dron0gus

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by Dron_Gus »

mk e wrote:
Thu Jan 16, 2020 2:23 pm
hence the fpga thread
https://rusefi.com/forum/viewtopic.php?f=13&p=35305#p35305
I'm following this thread. I like SmartFusion2 SoC. But I'm not a FPGA/CPLD developer. :) So I'll keep playing with STM.
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 »

Dron_Gus wrote:
Thu Jan 16, 2020 2:13 pm
If we had some kind of free-runnig multichannel timer that captures trigger events and generate output pulses using same counter - yes, this will be more precise. But stm does not have such advanced timers. May be it is possible by using timer synchronization.
The stm32 can do a little bit of this, but not very much. The HRTIM on the stm32f334/g4/h7 can do a lot of this (but still not very many channels). However, the described timer is extremely easy to implement on even the smallest FPGA. As many input capture channels as you want, and as many output compares as you want, all with a shared time base.
essess
Posts: 13
Joined: Thu Aug 10, 2017 7:12 pm

Re: [info] rusEfi Scheduler Performance & Accuracy

Post by essess »

mck1117 wrote:
Thu Jan 16, 2020 7:44 pm
Dron_Gus wrote:
Thu Jan 16, 2020 2:13 pm
If we had some kind of free-runnig multichannel timer that captures trigger events and generate output pulses using same counter - yes, this will be more precise. But stm does not have such advanced timers. May be it is possible by using timer synchronization.
The stm32 can do a little bit of this, but not very much. The HRTIM on the stm32f334/g4/h7 can do a lot of this (but still not very many channels). However, the described timer is extremely easy to implement on even the smallest FPGA. As many input capture channels as you want, and as many output compares as you want, all with a shared time base.
and/or angle clock.
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 »

essess wrote:
Thu Jan 16, 2020 11:07 pm
and/or angle clock.
sure, you could do it completely angle based in an FPGA, but that makes it significantly more complicated to integrated in to the existing firmware, without really any added benefit. So long as the MCU can keep up with the interrupt rate from the FPGA (easy) and can schedule future events in time (also relatively easy), the FPGA doesn't really need to do that work internally. It's significantly more area and power required for not really any real performance benefit.
Post Reply