Hacker News Reader

Comment by ourlordcaffeine | Hacker News Reader

Nah man python powered ECU is the way it's going to go.

The engine stalling whenever the GC runs is a bonus feature.

Don't give Hacker News any ideas, or we'll end up with an Electron-based ECU (as-a-service).

I know you're joking, but I bet it'd be possible to make a python-powered ECU these days. It's not that hard to make non-allocating code in the first place, but even then the amount of data is so small that a GC cycle could be done in a ms or so at most.

An engine running at 3000 RPM is only doing 50 rotations per second, so you have a 20 ms budget to calculate whatever you want, hit whatever spark plug timing you need and then GC.

Engines can turn faster than 3000rpm, even in the general case. Car engines are 4 strokes, so you're probably interested in collecting data and issuing control signals through those 4 strokes. I believe my small car redlines at 7,000rpm, so that leaves roughly 2ms per stroke (for all 4 cylinders).

Also, the ECU does more than just the cylinder values, it's monitoring other systems as well, such as the transmission, traction control, &c which also have hard deadlines.

I don't think there is enough time to garbage collect, and as other gave stated, there should be little to no need to allocate in this type of code anyway.

> It's not that hard to make non-allocating code in the first place

It sure is in cpython. `a = 1` may need to allocate/reallocate the dict holding the local/global variables. If an integer exceeds 256 or goes below -5 you're getting an allocation for the object - regardless of whether that number has been seen before or not. Of course you can forget about floating point and function calls - maybe even function calls to C functions.

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.

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.

> An engine running at 3000 RPM is only doing 50 rotations per second, so you have a 20 ms budget to calculate whatever you want, hit whatever spark plug timing you need and then GC.

The engine should still work at redline, so lets go for a conservative 6000 RPM, or 10ms budget. The spark plugs don't fire at the same time either, but (as far as I know) every second rotation in a staggered manner. So with a 4 piston engine you'd have 5ms (one firing every 180 deg) to do calculations, check for failure conditions and run the gc, with the latter one needing to finish in time.

It might be possible to do a proof of concept, but I don't think its that easy.

It's even worse considering all of the conditions being controlled for and the precision expected. Spark timing needs to fall within a degree of rotation. Modern cars get direct injection of fuel into the cylinders, which needs to be provided at a precise volume at somewhat less precise timing. Continuously variable valve timing and lift control cylinder conditions for improved burn efficiency while preventing an environment that encourages preignition, at the same time providing as much volumetric flow as possible. All of this needs to account for airflow, altitude, intake air temperature, variations in fuel quality, hiccups in fuel supply, engine temperature, over the entire range of possible engine load and speeds, and transitions throughout all of these states.

It's a seriously hard optimization problem, one that's not yet up to the task of providing reliable engine management quickly enough to also provide throttle-by-wire response in general production cars that isn't as spongy as an old Mercedes diesel sedan. I mean, if Mazda could provide throttle response for the new throttle-by-wire Miata that was remotely similar to a 30 year old model, I think they would.

Reply on news.ycombinator.com