Hadie: a new, free RTOS

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello,

we are working on a free portable RTOS. A first release, showing the core
functionality, has been published. This version 0.1 only supports the
simulator target (libc-linux), ports to real systems will follow soon.

Homepage: http://hadie.sf.net
Download: http://sourceforge.net/project/showfiles.php?group_id83%983

Any comments ?

greets
Marc

Re: Hadie: a new, free RTOS
Quoted text here. Click to load it

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

Wumpus


Re: Hadie: a new, free RTOS

Quoted text here. Click to load it

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




Re: Hadie: a new, free RTOS
Quoted text here. Click to load it

Also:   http://www.FreeRTOS.org
&
http://www.micrium.con (only free for non commercial).

Re: Hadie: a new, free RTOS

Quoted text here. Click to load it

When I attempted to view this with Netscape 4.7, it complained that
http://hadie.sourceforge.net/hf.css could not be found and refused to
show the page.

Thad

Re: Hadie: a new, free RTOS

Quoted text here. Click to load it

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

Re: Hadie: a new, free RTOS

Quoted text here. Click to load it

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.

---
42Bastian
Do not email to snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: Hadie: a new, free RTOS

Quoted text here. Click to load it

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

Re: Hadie: a new, free RTOS

Quoted text here. Click to load it
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.


Quoted text here. Click to load it

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

---
42Bastian
Do not email to snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: Hadie: a new, free RTOS
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Hadie: a new, free RTOS
Quoted text here. Click to load it

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

---
42Bastian
Do not email to snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: Hadie: a new, free RTOS
Quoted text here. Click to load it

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.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Hadie: a new, free RTOS
Quoted text here. Click to load it

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".


--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: Hadie: a new, free RTOS
Quoted text here. Click to load it

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".

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Hadie: a new, free RTOS
Quoted text here. Click to load it

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
www.software-integrity.com



Re: Hadie: a new, free RTOS

Quoted text here. Click to load it
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().


Quoted text here. Click to load it
Hadie's implementation of malloc() is realy _simple_; plans are to
switch to a "binary buddy block allocator" system as described in
http://en.wikipedia.org/wiki/Real-time_operating_system#Memory_allocation .

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).

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Karsten Laux
TU Kaiserslautern



Re: Hadie: a new, free RTOS
Quoted text here. Click to load it

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.
---
42Bastian
Do not email to snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: Hadie: a new, free RTOS

Quoted text here. Click to load it

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


Site Timeline