Re:The Migration Of Engine ECU Software From Single-Core To ...
by murderfs on Saturday March 19, 2022 @06:31AM
(#30732656)
> 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).
Re:The Migration Of Engine ECU Software From Single-Core To ...
by koollman on Saturday March 19, 2022 @05:33AM
(#30732404)
which systems would you consider "proper concurrency-safe" ?
Re:The Migration Of Engine ECU Software From Single-Core To ...
by WJW on Saturday March 19, 2022 @09:25AM
(#30733527)
Not GP, but something generated by 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.
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.