On Tue, 10 Mar 2015 01:45:18 -0700 (PDT), you wrote: > >> >> Sadly, the modern software technology ( and i daresay the modern software >> coders' mindset ) is responsible for the shoddy and error-ridden code i see >> almost everywhere.
In software, you either look for the errors yourself and protect against them by coding, or you let the compiler/runtime find them (error checking, bounds checking, bad pointers). We won't even go into good testing methodology, which can take a substantial fraction of the time it takes to develop the code itself. >> >I can only partitally follow you. The problem is not the tool. The problem >is the people using it!! The more sophisticated the tool the more ways to >use it wrong. The more automatisation in the tool the more likely that some >fools use it w/o knowing what they do. And in big projects with many people >involved you will have a combination of both... >But I know what you mean with mindset. eg. introducing a garbage >collection... my mindest is that my code produces no garbage! ;-). >Nevertheless high reliability is less a matter of the programming language >than of the SW concept! And of OS. If the language has no error checking built in, and permits escaping from every structure there is, then you have more of chance of generating and not finding errors (and writing structurally bad code), than if the language has the tools and structure to either enforce writing good code, or do error checking itself during runtime. You pay for some of that with increased code size, complexity, and slower performance. Compare C against Pascal, for instance. >Anyway I get the feeling you are more concerned about crashes caused by the >OS than caused by your program. >Maybe the correct order to start would be > >1) Choose OS (Startup time? Latency? GUI? long term support? supporting >community?) add hardware support for your processor and/or OS. >2) Define needed supporting functionallity (math, graph, I/O, protocols...) >3) Think about programming language available for 1), able to interface 2) And the same things that influence the OS support also influence the language support. > >I'm not sure if you have covered all points from 1), yet. >If you talk about process control I would immediately opt for an RT OS. But >since you want to replace an old hardware Debian is very, very likely fast >enough w/o any RT patches -see toyooka_LCJ2014_v10.pdf ><http://events.linuxfoundation.org/sites/events/files/slides/toyooka_LCJ2014_v10.pdf> > . >Nevertheless, you should think about RT OS: I would expect that RT OSs are >not only built for low latency but also for highest reliability -but I'm no >expert on that. > An RT OS has a maximum defined time from an event to responding to it. Nowhere is it defined how much that time is, but that it is a maximum. FreeRTOS is available for the BBB processor, should you need to consider it. It also comes in a high reliability version. An RT OS is no guarantee of reliability, one way or another. Note that in terms of latency, if you want millisecond responses, that's one thing. If your application is to log data every 10 seconds, then an RT OS needs to take less than 10 seconds to do all of its stuff. Clearly not the same thing, but it fits the definition. Harvey >Chilli > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
