On Wed, Jul 28, 2021 at 03:58:02PM +0200, Didier Kryn wrote:
>     With all respect due to your work, I tend to think that with such
> expensive and dangerous machines, more investment should be put into
> hardware so as to get controllers with a decent ram. And maybe the
> firmware could take safety action when software crashes.

Sure, but I'm not the boss :-)

>     Similarly, more investment should be put in software so as to make a
> review of available languages suited for mssion-critical applications
> and invest in learning the chosen language. C and C++ are so error-prone
> that they are really not suited.

Well, you can implement bugs in any kind of language. To be honest,
crashes are the most easy ones to find. I know there are other languages
outside but here applies the same as above: I'm not the one to decide.

I can just give hints and try to push in some direction. But embedded
software development is still driven by myths like "C is faster than C++"
and its hard overcome these. Maybe a generation thing.

My personal way to push through this is to run as much (automated)
firmware tests in our hardware-in-the-loop test system as possible. And to
have a testcase for every single requirement, situation, sequence or ever
seen bug in the software. We end up to have 20-30 testruns a day
distributed among different test setups, SoC cpu generations, operating
systems. The only missing thing is kind of developer slap robot to punish
the developer who made the bad commit automatically :-)


>     This went far off topic. I have more on the initial topic but am
> getting tired (~:

Haha, sure :-)

cheers,
Andreas

--
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51