Hadie: a new, free RTOS

In what is it better/different from eCos, ucLinux or friends?

Wumpus

One of the main differences is the wide range of target plattforms (8-32bit).

But have a look at the small introduction on the our homepage.

Marc

When I attempted to view this with Netscape 4.7, it complained that

Thad

fixed it. Haven't tested with netscape before. Marc

Yes.

malloc/free does not seem to be suited for real-time as it is not deterministic esp. because you are locking the timer during these systemcalls. This might not be relevant for slow system-ticks and/or fast CPUs, but can cause a lost interrupt on slow systems.

It has been an design decision to lock the timer-interrupt while entering kernel functions. We don't have any experience on "real-hardware" yet. But we will concider this on testing.

Do you know a better solution?

Marc

Aaargh! Malloc and free. Those puppies have NO place in 90% of the code I write (they're OK in pc hosted test programs & stuff, but not in most microcontroller apps). When you have a limited number of bytes of RAM available, hard coded static allocation is usually the way to go.

-- Alf Katz snipped-for-privacy@remove.the.obvious.ieee.org

Also:

Or to put it another way, you have to have spare memory to have a heap at all. One of the bigger problems in small uCs is knowing when your stack crashes into the rest of the "proper" memory, let alone the heap.

My approach has been to write a minimal time slicer, accept the limitations that imposes (like not knowing when an X millisecond hiatus will happen in a routine), and be VERY careful when allocating dynamic memory.

Paul Burke

That is a very coarse locking. It might work now, but if you like to add pre-emption you'll get into trouble.

You'd better go for a interrupt locking in the kernel when you enter a critical section rather locking only the system tick.

Yes. . . . A fixed buffer-size allocator without merging. A. Tanenbaum describes it in his OS book. And it has been also explained here.

That's not all! I haven't looked to see whether Hadie is pre-emptive. If so, it'll probably have to disable *all* interrupts during malloc and free because these, in most C library implementations, are not re-entrant. (I take it that no-one in his right mind would use either of these in the ISR itself!).

And there's more! Heap allocation leaves the system open to memory fragmentation, which is a big no-no in most real-time systems. Any self-respecting RTOS has to have its own memory management scheme which allocates blocks of fixed size (though there can be several pools with different block sizes) to avoid fragmentation. Safer still: avoid dynamic memory allocation altogether. This is particularly desirable (but also easiest) in small embedded systems with limited memory. Also, dynamic allocation is often (always?) disallowed in safety-critical systems.

Writing an RTOS (or, rather, just the kernel) is easy; designing one properly is not!

-- Peter Bushell

There is at least one allocation algorithm which works fine for RAM that is not too limited (speeking of min. 2KB RAM).

In fact Hadie uses pre-emptive scheduling and malloc's implementation surely is not reentrant. From my point of view, however, only those interrupts need to be disabled, which could cause a concurrent call to malloc().

Hadie's implementation of malloc() is realy _simple_; plans are to switch to a "binary buddy block allocator" system as described in

With this scheme, fragmentation will be dramatically reduced and the runtime behavior will be more deterministic - more realtime ;)

Dynamic memory allocation was chosen by design: Hadie is targeted for a large range of embedded systems (8bit ... 32bit) and for larger targets dynamic memory management is obligatory (well, at least in my eyes).

Yes, definitely. Hadie's main feature is its portability; avoiding in-efficiences at both ends of the scale of target systems is probably impossible.

Karsten Laux TU Kaiserslautern

Excessively dogmatic. malloc/free can make better use of the available memory in many cases. The thing to watch out for is fragmentation, and this can be handled by restricting the use to one size of allocation. There are other memory management techniques also.

And how is it that having a single size of allocation for all mallocs is a better use of available memory? Yes, there are other memory managment techniques, but using anything other than "single-size" malloc/free leads to fragmentation and compromised resource determinism in systems that must be up "forever".

Better: because memory not in use is available. This allows a higher throughput, but can lead to overall failure at some point. So can the pre-allocated system, but the failure condition is more easily analyzed.

Fragmentation: isn't that what I just said? At the same time I have implemented better systems with non-constant allocation sizes by imposing rigid restrictions on the use of pointers (basically making them handles) and creating a well defined continuous GC mechanism. These ran "forever".

From this page: "All the buddies of a particular size are kept in a sorted linked list " ^^^^^^

IMHO, sorting a list is never deterministic. You are not able to give a max. time for a free or a malloc.

Depending on the allocated size you have to split different numbers of chunks.