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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
