Le 29/07/2021 à 20:10, Andreas Messer a écrit :
> 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 :-)
    Your boss is the ultimate responsible person in case of human
hazard, at the condition s?he is properly educated, and it might be your
responsibility to educate her/him.
>
>>     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.
    Not all language are equal. Some really discourage bad programming,
meaning it takes a big effort to actually program badly/unsafely, while
it is still possible. Others open traps under your feet everywhere.
>
> 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.
    Myths actually. The advantage of C and C++ is to be easily portable
to every paltform since the compiler and runtime are always available by
default. But, when you develop a private application, you can invest in
building the necessary environment.
>
> 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 :-)
>
    Not sure that works (~:  Would make the programmers nervous.
Stress-based human management causes bad surprises.

--     Didier