Hi Chili you are mostly right - the problem is not solely the tool - it is mostly the people. Sadly, however, many of the 'modern' tools are equally flawed for exactly the same reason - very few people today do real design - they just code away until something sort of works.
I'm concerned about crashes of any kind ( hardware, OS, code ), and your selection order makes sense. However , I have started one step earlier by selecting BBB as the hardware, and that somewhat limits the choice of OS which further limits the choice of language. I'm very impressed with the level of advice I've been getting in this discussion, and I"m sure it will eventually help me make the right choice. thanks again richard On Tuesday, March 10, 2015 at 4:45:18 AM UTC-4, Stephan Mulacz 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. >> > 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. > 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?) > 2) Define needed supporting functionallity (math, graph, I/O, protocols...) > 3) Think about programming language available for 1), able to interface 2) > > 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://www.google.com/url?q=http%3A%2F%2Fevents.linuxfoundation.org%2Fsites%2Fevents%2Ffiles%2Fslides%2Ftoyooka_LCJ2014_v10.pdf&sa=D&sntz=1&usg=AFQjCNEn3RoWYw4_A016tvNK68msEiGfNA> > . > 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. > > 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.
