Hacker News Reader

Hacker News

Comment by rurban | Hacker News Reader

Parent Full thread

rurban

Trivial ECU's run at 500Hz, better ones at 1kHz, the very best (Formula 1) at 10KHz. (fixed typos)

There's for sure no dynamic memory, no recursion, only fixed memory slots.

View on HN

Rurban wrote: "the very best (Formula 1) at 10 KHz".

how much of the above is a typo and how much is real?

I'm pretty sure 'KHz' is a typo which maybe should be kHz as in the start of the sentence. But even then, why are the very best running 50x slower than the trivial ones? Or did you mean MHz?

Do you have a link to an example of an F1 ECU with the clock rate specified?

Oops, big typos. Factor 1000 slower, fixed in parent. Thanks

Sorry, no links afaik. Internal knowledge.

To me it looks like the frequency of the control loop, not the cpu core frequency was meant? 1kHz is typical for i.e. steering or abs control loops.

Sure. The cpu's are normal Intel 4GHz. The control loop is 10Khz. In space the CPU's would be radiation hardened and throttled, somethink like 250Mhz. Still enough.

The bottleneck is not the CPU, nor the model running in the loop, but the IO devices and driver's costing latency. In real-time latency kills you. Which turns out to be bended cables, missing resistors, broken filters, or such. A simple cycle-miss in real-time means reboot or worse.

With a (conservative) 10k RPM limit, you get a 6ms per rotation. But I would imagine the control must run many times per rotation, so it has a chance to do something different depending on the angle, like a physical camshaft would do. Say you have to re-calculate everything at every 1 degree of rotation, that would give you a 60kHz calculation rate or about 16 microseconds per iteration. I guess that's much more than even the best case in OP's example; I wonder what the compromises are then. Surely they don't punt on the granularity and (say) only do something every 10 degrees? Or worse?

About every microcontroller has hardware timer devices that can be set to trigger a signal change with N-nanosecond resolution (N from say 5-50), and even interrupt the core when it is done. The only sharply timing-sensitive bit would be ignition firing, so maybe control those with a hardware timer.

Thing is, you can use the whole repeating schedule, parameterized with adjustments to instantaneous RPM, for many cycles before there is need to check for e.g. throttle input changes.

In between, it is a dance -- shoot some fuel into 1, wait a bit, stop shooting fuel, wait a bit, start closing a valve, wait a bit, schedule a spark, wait a bit, ...

All the settings are chosen, whenever input changes, by table lookup. So tuning means fooling with table entries.

Reply on news.ycombinator.com