gemellocattivo.com

Read in the thread they are only using a 4us (250Khz) timer as well? Presumably this has improved with the Teensy, but still, measurement accuracy matters a lot when you are trying to calculate crank accelerations between teeth accurately.

Processor speed definitely matters very little for high precision timing accuracy. The timer peripheral itself is a big deal here.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke

It says


I didn't take that the timer is running at 4uS, but instead to mean they can only respond to the timer within 4uS......but he doesn't say why so that may or may not have improved with a faster processor I guess.

I chuckle a little here in that the eTPU inputs that they say they can hold are uS, so nS accuracy. Lots of talk in the spec sheets about crank position max error never exceeding 0.1 degree. Eginelab recently switched to mS inputs to make the user interface simpler but, it used be 0.1 uS and still accepts 0.0001mS, which seem comparable to the eTPU specs.

That is the accuracy dedicated HW produces with no "most" outputs are within x but some are 10x

The accuracy of the eTPU is a direct function of engine speed, TCR1 rate, and crank interpolation ratio (angle ticks between physical teeth). During transients you can also get acceleration errors, but at some point you're only going to get so accurate with the number of teeth you have. But, you are always certain what your error is and can tweak the TCR1 rate and interpolation ratio to get a happy balance for your operating speed range and number of crank teeth.

My interpretation was they are prescaling the timer to 4us and that 1 tick = 4 us, but you are right it could be a deficiency in their calculations or interrupt handling latency. If they are relying on an interrupt handler to actually set the output pins, then they will always have latency issues. On an atmega chip, they may be limited by the 16-bit counter not having enough range for a higher speed counter without causing overflow at low engine speed, assuming they calculate timing events every tooth or rotation or something engine-synchronous. The 24-bit eTPU counter has 255x the range, and even then we can see counter rollover in ~3/4 second @ 10Mhz. That's enough that a normal TCR1 timer could overflow before one full engine cycle at low cranking speed.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke

I think you hit the, I'll call it concern not issue, on the head. They only have a couple or handful of timers so interrupts are the only way to do it. The rusefi guys were talking about time stamps and and believed that was helping, not sure what the speeduino guys are doing but I assume something similar....but they lost my confidence at interrupts.....bad points. Lag is ok really when its repeatable it washed out in the tuning, when its repeatable. Interrupts are by definition interrupting normal operated and therefore will never be a normal and not repeatable....mostly it happens within a set time window but not always. That is why OEMs don't do it that way.

Then the 16 bit thing....MS is 16 bit and I assume, and its just an assumption, that they are doing all the timing stuff with 16 bit, and as you point out if you set it to not rollover through the missing tooth at cranking then you end up without a lot of clock ticks between teeth at redline. The eTPU went to 24 bit (and I think the bosch gtm is also 24 bit )because they had to and have 255x the resolution. That is just simple math.

So there it is....o5e existed to try to get OEM level accuracy in a user configurable and mostly open platform that was affordable. Projects like speeduino and rusEFI exist to get a low cost user configurable platform that works well. Different goals, and as a result different HW. My first introduction to an opensource ECU was freeEMS (s12) and it quickly became clear it was way to limited for what I had in mind. The S12 chips have gotten better and the I'd guess the ARM based projects are generally not far off what the S12 delivers accuracy wise.....but neither option gets you to OEM quality timing control because the HW is fundamentally not capable of that level of performance.

I asked on the rusefi forum ...they run 1 32bit timer at 1Mhz. If my math is right that gives them just about exactly the resolution possible in a S12 with a 36-1 wheel, they do better for lower tooth wheels, worse with higher tooth wheels.....and 1/255 modern OEM resolution.

Multiplexing a lot of high speed IO on a smaller number of timers is a recipe for disaster if they ever happen to overlap or be close to overlap.

Timestamps can help with inputs (where the hardware timestamps the pin transition, then an interrupt does computation) but they can't really help with outputs if you don't have enough timers to allocate one per output. The eTPU internally timestamps events before running microcode, although I've seen some less experienced eTPU programmers read the timer value in thread instead of the timestamp, and I've also seen less experienced eTPU programmers set output pins in thread instead of using the match opac. You can still mess up code in the eTPU.

I don't do piston engine work any more (and turbines are.. stupid simple to control), but the user adaptability of open software is also really useful for people doing more exotic projects where 'racing' ecu features just don't help. Some of the usefulness is reduced if it's too difficult to modify.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke

1 timer is what they have, so its a SW solution for what most consider a HW application.

I would argue ALL the usefulness is gone when its too difficult to work with.....and most car guys have little to no C or any other programming experience which is why the commercial replacement ECUs are pre-setup for most applications these days....plug and play which includes a base tune. The setup needs to be simple....then there are people who can do more, but I couldn't actually program much beyond basic math functions which is why something like enginelab works for me.

tubines huh? .....constant flow, no time critical anything other then measure rpm I guess.....yeah, must be nice

To me, easy to modify was easy to add little bits of code here and there to deal with unforeseen or unusual conditions. Sometimes we also wrote custom CAN code to interface to an existing gauge or relay module or something like that. Touching the core engine control code was rare once it was written, although some emissions controls would adjust fuel/air or spark. It was also very handy to deal with non-engine-related things in the existing ECU, where a very small amount of code was needed (i.e. on one vehicle we would read in buttons and use that to map to servo PWM signals to control a shift motor controller). None of this requires modifying the low-level code, but having a user space for user code is nice on an ecu.

Turbines are very simple to control until they go wrong. Given a fixed fuel flow, they will reach some steady state power setting, so the only challenge is changing that fuel flow without melting anything. They still have a happy fuel/air ratio range, and disturbing that can cause instability.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke