eCos 2.0 Released

Jonathan Larmour points out the "release of eCos 2.0, the configurable RTOS for the deeply embedded market. This release features a new licence based on the GPL, but with an exception to make it more suitable for embedded use. It's also now an independent free software project from the original developers Red Hat (which bought Cygnus Solutions) after the development team was canned. Most of the team still work on eCos but for different companies. It also has a wide range of ports but has managed to keep a low profile, which should now change with the new stable release. More at http://ecos.sourceware.org/ "

Comments

C++ and Kernel Coding

[Markus Registrada]

eCos serves as elegant proof that, even in the Free Software world, C++ is a practical language to use for even the lowest-level kernel coding.

Re:RTOS

[Markus Registrada]

Nowadays (what with Wince out there) we have to say "hard real time". It delivers to-the-nanosecond latency maxima, making it suitable for controlling million-dollar machines that would break, and maybe kill somebody, if it missed. It might be annoying enough if it kept dropping your cellphone connection -- those have hard-real-time constraints, so when Wince runs a cell phone, there's a separate CPU running a real-time kernel.

There are hard-real-time kernels that will run underneath Linux (or NetBSD) so you don't have to choose, you can have both. Sometimes, though, you need networking but can't afford the extra RAM and whatnot to run a whole Unixy environment. Anyway the minimalism can be heady, too, like the thin cold air on a mountain you've just climbed.

Re:More TRON!

[torpor]

I've followed iTRON since the 80's, and am an embedded systems programmer who has worked in the States, and I can tell you that iTRON has been promptly forgotten and resurrected in the US embedded world plenty of times. Every few years it is mentioned, or some trade group announces an implementation of an iTRON-derived embedded spec, etc. But it'll never go mainstream in the US.

The primary reason for US resistance to implementing any of the iTRON protocols is defense. The US embedded market is still dominated by defense contracts and government spending - iTRON is a big no-no in those realms.

Still, I see the intent of iTRON being accomplished in other ways these days - combine some of the work done on uClinux for example, to get the linux kernel running in MMU-less processors, with a little of the open source zeroconf effort, and its feasible to build iTRON-like devices.