graham_k wrote: > [Threads v processes] > Sounds riskier, but probably easier to implement. If one crashes, it takes > out the whole system. But, well, if they have separate address space, if one > crashes you still ought to detect it and restart either the process or the > device.
Indeed, it's a significant complexity reduction. If you are sure that your application is written carefully enough to not need robust segregation between processes, you don't need an OS that provides it and all the attendant complexity. If you can reduce your code size, this might mean you need a smaller flash part, less SDRAM, a less powerful CPU core: save a few cents in your bill of materials, which in turn translates to a huge saving in a mass-produced consumer device. > In practise, we just tend to test to death & hope that this sort of thing > never happens ;-) In eCos, everything runs in supervisor (kernel) mode. You can take 42, cast it to a char* and write to the memory it now points to, if that's somehow a useful thing to do on your hardware. To abuse a certain phrase, the gun is not so much pointed at your feet, but continually tracking your feet wherever you may run to. Practice good code hygiene, carefully define your internal interfaces, and always check for errors; for example, malloc() can - in an embedded target, most likely will - return NULL at some inconvenient moment. Keep It Simple, too; you can always go back and optimise later if you find you need to. If something goes particularly wrong - what one might think of as segfault or application-error territory on a desktop OS - you might cause a CPU exception or trap, which your hardware might well allow you to set up a handler for. But you might not; as memory protection is usually turned off in eCos, you could (for example) scribble all over the C stack and drop the CPU into an infinite loop. For this reason, watchdog timers have their proponents. In any event, hypothetically, if a thread has crashed badly and your RAM contents are potentially corrupted, how practical is it to attempt a recovery short of rebooting anyway? In short: With the power comes responsibility! :) Ross -- Embedded Software Engineer, eCosCentric Limited. Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK. Registered in England no. 4422071. www.ecoscentric.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
