Richard: I am going to talk about a question you didn't ask.
What is the life of a BBB in continuous operation, such as a commercial process controller? The BBB is a teaching, learning and experimenting platform. It is powerful and an amazing value for the cost in this application. It will last more than long enough to get the students graduated and eventually become technologically obsolete. However, the (low cost) eMMC on the BBB is a life limited part. It may or may not become an issue in a heavily used, continuous service application that is expected to run for 15 or 20 years, that is typical of an industrial environment. The life limit is the number of writes. And it has write leveling built-in, so that heavily written areas of the eMMC memory will get remapped and distributed around the physical memory space. How long it will last depends on how much of the memory space you are using, how much you leave free for memory leveling, how many times you write to the eMMC, and the size of the executing program in RAM, and the resulting page swapping activity. You may get a longer life product by not using the eMMC and instead using a very large (high quality, with good leveling algorithms) microSD card, so that there is a tremendous amount of unused memory space for memory leveling. Just saying ... --- Graham == On Tuesday, March 10, 2015 at 10:09:46 AM UTC-5, Harvey White wrote: > > 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.
