5 ms·

CPUs in the automotive space are primarily chosen for being cheap, and with the right number/kind of IO. If you do enough stuff¹, it's certainly possible to rea

CPUs in the automotive space are primarily chosen for being cheap, and with the right number/kind of IO. If you do enough stuff¹, it's certainly possible to reach the CPU load limits of a single core CPU, and it might cheaper to upgrade to a dual core than put in another ECU (also, faster ECUs with the same IO/arch might not be available). I've also seen arrangements where the dual-cores have separate memory spaces, and one core acts like a safety processor/monitor while the other is the main compute module. 1: examples of CPU intensive stuff include active damping, active aero (spoilers), active rear steering, steer by wire, etc. You may think these things are irrelevant w.r.t. an engine ECU, but if the engine ECU is responsible for producing torque, then systems like traction control, stability control and etc are all directly related to torque production

rurban 5y ago
I've worked in the field, even with the biggest and fastest ECU's in existance, Formula 1, with 10Khz cycles on 4Ghz CPU's we never saw the need to use the other cores. the CPU is a few million times faster than the cycles, if there is a problem it's a HW IO or blocking driver. even with normal 500Hz ECU's you can always upgrade the CPU freq to run faster, than needing more cores. even better would be to use better drivers with zero copy and MMU access. it's nice that threading got better recently in embedded Realtime OS's, HW always gets better, but certainly drivers not and SW not. and developers even less. maybe they think rust will help, but then they should chose a proper concurrency-safe system. certainly not rust, which only lies about it. also this thing is only simulation verified, not formally verified.
- koollman 5y ago
  which systems would you consider "proper concurrency-safe" ?
  - WJW 5y ago
    Not GP, but something generated by CoPilot (https://hackage.haskell.org/package/copilot https://hackage.haskell.org/package/copilot) would generate constant-time constant-memory C code from a specification written in a DSL. That is what I would start to consider "proper" safe for stuff where it is really important. It depends on what you consider to be absolute requirements for proper concurrency safety of course, and how much of the hardware is allowed to fail before it starts impacting the software.
- murderfs 5y ago
  > it's nice that threading got better recently in embedded Realtime OS's, HW always gets better, but certainly drivers not and SW not. I hate to break it to you, but hardware is basically always broken, and it's all "fixed" in software (especially in embedded, where some vendors don't even bother with steppings to fix errata).

rurban 5y ago

I've worked in the field, even with the biggest and fastest ECU's in existance, Formula 1, with 10Khz cycles on 4Ghz CPU's we never saw the need to use the other cores. the CPU is a few million times faster than the cycles, if there is a problem it's a HW IO or blocking driver. even with normal 500Hz ECU's you can always upgrade the CPU freq to run faster, than needing more cores. even better would be to use better drivers with zero copy and MMU access. it's nice that threading got better recently in embedded Realtime OS's, HW always gets better, but certainly drivers not and SW not. and developers even less. maybe they think rust will help, but then they should chose a proper concurrency-safe system. certainly not rust, which only lies about it. also this thing is only simulation verified, not formally verified.

koollman 5y ago
which systems would you consider "proper concurrency-safe" ?
- WJW 5y ago
  Not GP, but something generated by CoPilot (https://hackage.haskell.org/package/copilot https://hackage.haskell.org/package/copilot) would generate constant-time constant-memory C code from a specification written in a DSL. That is what I would start to consider "proper" safe for stuff where it is really important. It depends on what you consider to be absolute requirements for proper concurrency safety of course, and how much of the hardware is allowed to fail before it starts impacting the software.
murderfs 5y ago
> it's nice that threading got better recently in embedded Realtime OS's, HW always gets better, but certainly drivers not and SW not. I hate to break it to you, but hardware is basically always broken, and it's all "fixed" in software (especially in embedded, where some vendors don't even bother with steppings to fix errata).