Hi Graham you make a very valid point about the expected lifetime of the hardware. I fully expect some of the BBB's will fail over years, but since the project is a highly distributed system, no one failure is critical and is within the error reporting mandate.
you also make a very good point about using the biggest and best SD card. thanks for the help richard On Tuesday, March 10, 2015 at 11:31:31 AM UTC-4, Graham wrote: > > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
