Slashdot Mirror

• eCOS http://ecos.sourceware.org/
• RTEMS http://www.rtems.com/
• FreeRTOS http://www.freertos.org/

but most of the embedded systems I have work on require hard-realtime and I tend to choose very conservatively on embedded projects.

To mention another, RTEMS is a open-source real-time OS with a decent pedigree and commercial support available. (The page is a shameless rip-off of GCC's.)

There's also Red Hat's eCos but I don't think they support it anymore.

The people who make RTEMS, Online Applications Research Corporation are a very cool bunch who were early adopters in the real time operating system space. They have worked very closely with RMS on licensing in the mid 90's and were one of the first groups using GCC as a cross compiler. Their business model is support oriented plus government contracts.

(I have no financial stake in OAR or RTEMS, other than having good feelings about their involvement in OSS)

If an open-source implementation of ITRON did exist

eCos and RTEMS both claim to support uITRON 3.0.

Furthermore, even that "open" specification appears to be tied in with privileged access if you want to see anything resembling actual code APIs or architectural details at a finer level than boxes, lines and clouds.

You mean this? The English version of the spec seems to adequately document the system; it's at least on par with your typically set of manpages. Considering that there's no actual system involved, some vagueness can be excused.

The possibility always remains that we simply don't see all the detailed material because of the language barrier

That does seem to be the case, regardless of what you may believe. I've been trying to gather information about TRON for some time, and have come across great heaps of documentation going back years, all unfortunately in Japanese.

TRON is a set of standards. I know of two free implementations of the microITRON standard -- eCos and RTEMS. --joel sherrill

A real time operating system is of great use in robotics.

I am actively working toward the completion of several autonomous systems.

RTEMS (by OAR) is available as well as RTLinux (by FSMLabs) for those interested in developing robotics software using GPL. Big boys buy vxWorks or something from WindRiver (Asimo by Honda).

It may have been done to force a separation of blocks of code, so that the compiler wouldn't optimize them together (though I don't know how MSVC's optimizer works).

If I remember correctly there are similar tricks used in the Linux kernel to prevent out-of-order evaluation in places like interrupt handlers where it can cause problems.

There are also cases where do {...} while(0) is used in macros. See this thread of a mailing list discussion describing such usage.

I wonder if SCO is claiming ownership of tricks like these, or common code patterns. Or, maybe, they're saying, "Hey look! Their PCI code accesses the PCI bus! Their register write/reads look awfully similar to ours! There's no way they could be accessing the PCI bus without copying our code! The fact that the same registers have to be used no matter the OS is insignificant!"

I know I'm a day late (and probably a dollar short) on this, but I thought a note from someone who is familiar with the subject matter in the report might be of value.

Personally, I think its a rather shoddy bit of work.

First off, and most importantly to the Slashdot crowd, last I checked MODSAF was not OpenSource, by the OSI defintion. See section 5: "No Discrimination Against Persons or Groups". MODSAF is freely available to anyone working on a DoD job, but so is just about any other DoD-bankrolled software ever written.

Secondly, he actually did a study and found that using translators to automaticly turn Fortran into C, is a bad idea (created unmaintainable crap that ran slower). I suppose there may be some PHBs out there who need to hear this, but for the rest of us...DUH!

Thirdly, he kept talking about C++ like its the paragon of OO-ness, and implicitly calling Ada a non-OO language. Both horribly wrong. The only bright spot I saw here was the use of Java for a new IOS. Java's actually a really good fit for an IOS (Instructor/Operator Station), as they are all about GUIs and network communications. I just hope the component library they used isn't "disappeared" by Sun on them. These Sims need to be maintained for decades.

I think the subject of OSS in the military is a really good topic. But MODSAF is not an example. Instead, look at Gnat (GPL), CLIPS (public domain), and RTEMS (Modified GPL). All were originally sponsored by the DoD, but now have lots of users outside the military and commercial companies supporting them. The DoD should be doing more such projects.

Such as RTEMS?

Some data about FedSat, a Scientific R&D microsatellite that's due for launch on the next H-2A from Tanegashima:

Firstly, the on-board software is in Ada-95, using the 3.13p version of GNAT as the compiler and RTEMS as the Run-time Kernel. Both Open-Source, and the 'p' in "3.13p" means public, free-as-in-beer. The on-board software was developed mostly by Software Improvements, a bunch of software professionals who are heavily into SLCMs, CMM, etc. And lo, it worketh, on-time, under-budget.

The ground station is another matter. OASIS was tried, but couldn't do all that was required. In a spectacular case of less-than-wonderful-judgement, VB on Windows was used for development. After a while, they got some software pros to work on that one too, rather than the hack'n'slash electronics engineers. Well, it partially works - enough so that a few months or years after launch, it will do most of what's wanted.

Moral: if it's important, and has to work first time, every time, do it in Ada and open source, and use the principles described in the parent article. If it's not so important, and can be fixed up afterwards, you're still better off using Ada, though Java's a good second choice. The only reason Ada's so good is that it makes it easy to adhere to good software engineering principles, such as teamwork, smart design, and open standards.

• Separate Public view and private view -> Interfaces between teams made easier
• High-level (generics, tasks etc) and low-level (address clauses) features ease design task
• Standardised - Ada-83 was standardised as Mil-Std-1815A in January 1983 and later as ISO/IEC 8652:1987, Ada-95 as ISO/IEC 8652:1995.Copies of the LRM (Language Reference Manual), style manual etc are all freely available on the web.

A.Brain, Rocket Scientist

RTEMS is maintained by Online Applications Research Corp. You can find more info at OARCorp or RTEMS.com. The first incarnation was Real-Time Executive for Missile Systems, then Real-Time Executive for Military Systems. That second name still applies to the Ada implementation, but the C implementation now goes by Real-Time Executive for Multiprocessor Systems. The current license is basically LGPL. -- Chris Caudle

My embedded projects usually don't need virtual memory or processes, just memory protection and threads. So Linux is overkill as well as being too slow.

On the other hand, the driver sources, the libm and libc, have all been useful starting points for either roll your own, or extending another RTOS.

If this sounds appealing, and you need an RTOS, look at RTEMS an open source RTOS with many ports.

Oh the sad irony that the figures are in format based upon a software patent. See the FSF's Why no GIFs? for details. As an aside there is an open source OS that supports the uITRON 3.0 API and POSIX -- RTEMS. Congratulations to all recipients. The projects are definitely worthy. --joel

I guess he's never heard of/used QNX, ChorusOS Nucleus, or ThreadX. I did however like the gadgets, but taking a look at the last week, with all the Linux related companies going to the dogs , and 4 distributions going "kaput" within less than 6 months time, I would be looking at other alternatives to Linux, especially if my business were going to depend on them.

Of course you could look at RTEMS. The longstanding (1988, way before Linux existed) Open Source real-time operating system. It is as good as (many say better than) vxWorks, ChorusOS, Nucleus and ThreadX. http://www.rtems.com

The one thing you wont get with RTEMS is the hype and geeky admiration of Linux geeks (or vxWorks, QNX, Windows CE, PalmOS,etc luvvies). You just put it in things you *REALLY* want to work.

For embedded work, there's ECOS already.

between ECOS, GNU HURD, RTEMS and others, there is a plethora of open-source hard real-time and microkernel systems available to the open-source hacker. closed source systems may be slick, but you will always be at the mercy of the closed-source owners.

I think you will find more embedded systems devoplers going to X because is allow them to remotly display debugging back to the desktop.

microwindows has a client / server network transparent architecture, similar to X. it's a heck of a lot smaller than X, too.

there is also RTEMS, which is a real-time multiprocessor-supporting OS, if you ever want to ditch vxworks... (there is also ecos which looks interesting. but this is getting off topic.)

• Pricing.

  It is notoriously difficult to get pricing information for QNX.

  I have heard differing reports on comp.os.qnx, including that it is "very expensive, hundreds of dollars per system," or, on the other hand, the vague answer of "you can license it reasonably economically." (With no definition of what "reasonably economical" means, of course.)

• If people should start thinking of QNX, then they should also start thinking of:
  • VSTa

    A copylefted system that "lifts" ideas from QNX and Plan 9

    It looks like development has not been terribly active lately.

  • MIT Exokernel

    Again, not terribly active, but an interesting OS kernel.

  • EROS

    Eric Raymond thinks it's mindblowing, so the Eric Raymond Personality Cult should all be preparing to drop Linux in favor of EROS. (Of course, it isn't yet capable of self-hosting, which indicates that it's not all that useful at this point. But, to cultists, usefulness is irrelevant...)

  • Possibly even Hurd

    It's different from the other options; certainly not a tiny OS option...

  • eCos
  • RTEMS

    Which, like QNX, appears to be used in some reasonably critical system environments...

  • Fiasco

    Which is a "lighter microkernel than Mach"...

  • On Linux, people interested in QNX should almost certainly look at SRR -- QNX API compatible message passing for Linux

    This is the critical programming abstraction that QNX uses heavily which isn't all that widely used on traditional UNIXes, namely asynchronous messaging.

  These are all interesting alternatives, albeit not all being of identical levels of interest.

Have you looked at RTEMS lately? It is real time, has a TCP/IP stack, and all source is available (although I'm not sure if it's "open source"). It is maintained by the Army so it's pretty much public domain. It compiles under gcc nicely. The EFI332 group is using it to build a fuel-injection system.

-tim

The really cool thing about Pathfinder was the hack they did to patch the statically linked operating system (vxWorks - yukk, they should have used RTEMS) to fix it's priority inversion problem...on Mars!

See here and here. What's really funny is that this problem was reported by somebody from Microsoft - problably the least Real Time aware company (after Sun and Oracle) on the planet.

I researched replacing our current product with VxWorks to use either Linux or eCos. Neither would be an effective solution. eCos is far too limiting. The last I checked it didn't even have TCP/IP support, nor support the Mips processor (which is extremely popular for embedded environments [eCos does have an eval version for the NEC VR4300]). Another problem with Linux is the GNU public license. In an embedded environment it is often necessary to hack the kernel or pieces of it to do what you need.

I found RTEMS http://www.rtems.com is an excellent solution. It is open source and has the latest BSD TCP/IP stack. The license also allows us to hack up parts of the kernel without having to release the source code back.

For our current product, any RTOS we use we need to make some custom changes to the TCP/IP stack (which involve changes that would NOT be of benefit to the open source community unless the company wanted to compete with us). The eCos license would let us do this, Linux does not.

Don't get me wrong. I support open source and feel that any changes that enhance a product, fix a bug, or whatever that are not proprietary to one specific application certainly deserve to be released back to the community.

Another problem with the Linux kernel is that it is far too bloated. It would take a lot of work to bring it down to size. For example, everything we have is in flash. There is no file system. Our current image, symbols and all, is around 1.25MB compressed (using Zlib, which incidently is much faster than Gzip). We have a lot of code and not a lot of room. Having a small kernel is often necessary. We don't need a file system, virtual memory, security, loadable modules, or many of the other features of the Linux kernel. In fact, due to the fact that everything must be physically linked to the kernel, this totally rules out Linux. The 1.25MB is EVERYTHING, all of our code, protocol snooping, debugger, routing, console, SNMP, and firmware for supporting a second CPU (which runs our custom RTOS which is only a few pages of code).

eCos and RTEMS fill the void nicely in that one can pick and choose which features get compiled in. Unfortunately eCos is missing some very important pieces (i.e. TCP/IP).

VxWorks is a pain in the *ss since it has numerous bugs (i.e. improper cache operation on the NEC VR4300 CPU) and has terrible support (after paying thousands of dollars a year it's not unusual to have to wait weeks or months for a response). Not only that, but we had to buy their networking source code which costs many thousands of dollars (it's mostly just the BSD 4.3 TCP/IP stack, nothing special, and various daemons).

I am seriously looking at moving to RTems in the future. They have always responded promptly and have the features we need. My boss was all for Linux until I told him about what was involved to use it, and the GPL immediately killed it.

If we do move to RTems, I would certainly make a number of the changes we would make available back to the source code, but there are a number of others that we cannot release (since there's competition).