On Fri, 30 Jul 2021 16:35:52 +0200, Didier wrote in message <74e5400a-5e8c-4a22-d673-5f181644e...@in2p3.fr>:
> 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
