On Fri, 30 Jul 2021 16:35:52 +0200, Didier wrote in message
<74e5400a-5e8c-4a22-d673-5f181644e95c@???>:

> 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.

...or walk out the door and Blow The Big Whistle in Prime Time Media
if said Twin Haired Bosses don't wanna get it.
Or defect to a Safe country where such whistles Can be blown.

> >
> >>     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.

..2 lists on these 2 kindsa programming languages would be nice.

> > 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.

..it did work pretty well for Stalin until March 1'st 1953. ;o)

--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.