XMK eXtreme Minimal Kernel experiences?

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

Translate This Thread From English to

Threaded View
I'm evaluating small RTOSes for an H8/300 or H8S project.  After rounding up
all the usual suspects (CMX, ThreadX, RTXC, eCos, etc.) I happened across
XMK: http://xmk.sourceforge.net/xmk/docs/index.html

The feature list matches my needs nicely.  The website is clean and
organized.  The header files look good.  (I haven't looked at any of the C
source yet.)  The licensing terms are acceptible.

Anybody tried it out?   Care to comment?

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: XMK eXtreme Minimal Kernel experiences?
Quoted text here. Click to load it

After reading Your posting i was curious and downloaded
the first version(the ZIP-file). When looking over
the serial communication routines, i found busy waiting
loops. For me this looks like a fundamental misunderstanding,
what a preemptive kernel is good for :-(((

Just my 2 (euro)cents..

Klaus



Re: XMK eXtreme Minimal Kernel experiences?
Quoted text here. Click to load it

Yes, on the Hitachi H8 platforms, busy-wait loops are used when
intialization the UART hardware.  The wait loops are to let the
baudrate generate settle-out before transmitting and/or receiving.

However, reading the documentation (snippet below) for the functions
in question, these functions can be called *before* the kernel has
been started. Without the kernel running, there is no option of
'sleeping' vs. a busy-wait.

/** This method initializes the primary onboard uart with the
    specified framing and baud rate.  This method disables, and leaves
    disabled, the transmitter, receiver, as well as all UART
    interrupts.
    NOTES:
        o This method MAY be called before Xmk_initialize() and/or
          Xmk_start().
        o This method can be called multiple times to
          reset/re-initialize the UART.
        o When baud-rate 115200 is select, the edosk2674 board's
          external clock is used as the baud rate source.
 */
void Xmkdrv_hitachi_edosk2674_uartAInitBaudAndFrame( XMK_BYTE
baudrate, XMK_BYTE frameConfig );

Re: XMK eXtreme Minimal Kernel experiences?

Quoted text here. Click to load it

If the only busy-wait is in the init routines, that's probably OK.  What
I've sometimes done in the past in that situation is to have a way for
application/driver code to find out if the scheduler is running so that it
can busy/wait or block as appropriate.  It increases complexity a bit, but
it tends to only happen in initialization code.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: XMK eXtreme Minimal Kernel experiences?
On 27 Oct 2003 05:23:46 -0800, jtaylor@shift-right.com (John
Quoted text here. Click to load it

I was talking about the putstring-routine in SCI3.C. I did
not realize, that it was used only during initialization ;-)

The whole story is, i opened two arbitrary C-files and found
routines for locking interrupts in the first file and
a busy waiting loop in the second file. As i regard
both techniques as "bad practice", i immediately lost
patience for further exploration and wrote my posting.
So i am guilty of impatience.

In general, i am highly interested in a small kernel
like XMK, but in particular i need realtime behaviour
and XMK does not seem to deliver this.

Regards
Klaus

P.S. My favourite is still Gordon Deinstadts nanokernel,
which avoids priority inversion, but it's COP8 assembler only.



Re: XMK eXtreme Minimal Kernel experiences?

Quoted text here. Click to load it

Yes, there is a nasty busy-wait loop in PutChar() routine in the SCI3.C
file.  The PutChar() polls to determine with the transmit character has
completed - YUK!

However, the SCI3.C file is *not* part of XMK.  The XMK distribution
contains third-party code as well as non-XMK example projects for target
boards that XMK is currently ported to. Here is a snippet from the XMK
documentation page (http://xmk.sourceforge.net/xmk/docs/directories.txt)

    xsource/
        Contains third-party source code, libraries, etc. Typically, any
source or
        libraries supplied by a chip/compiler/platform vendor is located
here.


The guilty file in question , SCI3.C is locate at:
    xsource/hitachi/hew2/edk3664/rommonitor/sci3.c
    xsource/hitachi/hew2/edk3664/standalone/sci3.c




Re: XMK eXtreme Minimal Kernel experiences?
On Tue, 28 Oct 2003 09:43:41 -0500, "John Taylor"

Quoted text here. Click to load it

Hi John,

many thanks for clarification. Like Grante Edwards i was
overwhelmed by the number of files (friendly word
for loosing overview!), so i started to read the textfiles
available. Although i got a nice general impression, what
XMK should be, i was was missing a general overview,
how XMK is organized in reality. So i opened several
arbitrary files for inspection, just to get an impression.
You know the result. I will be very happy to be proven
wrong, because XMK is coming very close to what i am
looking for.

Regards
Klaus



Re: XMK eXtreme Minimal Kernel experiences?

Quoted text here. Click to load it

On many processors, it's quite simply not possible to impliment many sorts
of required operations (mutex, semaphore, etc.) without disabling interrupts
around critical bits of code.  Some processors have better support for
atomic operations than others, but on all processors I've used there were
situations where interrupts had to be disabled if any sort of multi-tasking
was going to be usable.

Quoted text here. Click to load it

In what way does it not deliver "realtime behavior"?

Quoted text here. Click to load it

IMO, priority inversion is an application design fault.  Some kernels do try
to salvage the situation, but it's best avoided by proper design.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: XMK eXtreme Minimal Kernel experiences?
[snip...snip]
Quoted text here. Click to load it

I suppose i am having here the same POV as You have with
priority inversion. I try to avoid this situation by design
an use processors, which do have the atomic instructions
which i need ;-).
50% of my applications simply can't tolerate disabling
interrupts, because interrupt jitter is critical.


[snip...snip]
Quoted text here. Click to load it

Please note the useage of the word "seem". I am a very
suspicious guy and do not claim anything working well
until i am really convinced.


Quoted text here. Click to load it

In reality i never had any problems with priority
inversion because i always was able to avoid shared resources.
But if i ever _have_ to use a shared resource, will You call
this "bad design" or do You know some nice trick to avoid
priority inversion without OS support?

Regards
Klaus



Re: XMK eXtreme Minimal Kernel experiences?

Quoted text here. Click to load it

I over-simplified a bit when I wrote that "priority inversion is a design
fault".  What I meant was that one should design the application so that
priority inversions cause by resources shared between threads do not cause
violations of timing requirements.  IOW, the mere existence of priority
inversion isn't a design fault. If those inversions cause problems, then
that is the design problem.  This attitude is probably only practical in
fairly simple systems with few shared resources (which is what I usually
deal with).

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: XMK eXtreme Minimal Kernel experiences?
Quoted text here. Click to load it

IMHO busy waiting is not per se bad.
If the loop is shorter than the cost for calling an OS function to
sleep (which mostly locks interrupts), I'd go for busy loop.
---
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: XMK eXtreme Minimal Kernel experiences?
On Tue, 28 Oct 2003 05:34:19 GMT, snipped-for-privacy@yahoo.com (42Bastian

Quoted text here. Click to load it

Of course i agree :-)

OTOH i am living in a world, where locking interrupts is as
bad as busy waiting loops :-))) And where i sometimes
have to print out 30 lines of 20 chars at 300 baud and
where i can't waste 16 seconds in busy waiting loops as
did the putstr-function of XMKs first version, which i was
looking at.

As XMK does not claim to be a RealTimeKernel, i was simply
expecting too much, my fault, sorry.

Regards
Klaus


Re: XMK eXtreme Minimal Kernel experiences?

Quoted text here. Click to load it

I downloaded the source tree and was a bit overwhelmed.  It looks like it's
way overkill for what I need.  The downloaded directory tree contains 1896
files in 881 directories.  That seems like a lot, but it includes
documentation, sample programs and some other stuff.

However, the src/xmk directory tree contains 339 files in 190 directories.
That still seems like a lot. And it all seems to be somehow married to a
cross-platform build-environment and/or project-management system called
BENV (which I guess is included in some of the "other" 1500 files).

All I want is a simple preemptive kernel with a few primitives like mutexes,
semaphores, and maybe timers and event flags...

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: XMK eXtreme Minimal Kernel experiences?
Quoted text here. Click to load it

Having been associated with the XMK author (John Taylor)
for some years and sharing many of his philosophies and
techniques, I can say a few words about your discoveries.

The intent of the source code organization is to
promote software reuse, where the term "reuse" has a very
specific definition. In this case reuse means that many
projects use the same source code and the source code
lives in a single repository. The "traditional" use of
the pre-processor for conditional compilation
(a la #ifdef) as a means of "reuse" is, contrary to
an interpretation/extension of the "Open/Closed Principle"
of software reuse.

http://www.objectmentor.com/resources/articles/ocp.pdf

Instead, those parts of a program which are different
for different types/platforms/environments
are seperated into different files. The result is a
proliferation of files.

The "build environment" (BENV) is designed to "eliminate"
makefile maintenance, and to support the shared reuse
file organization. (I hate f*cking with makefiles :-)
BENV is intended to support statically linked systems
such as those found in most embedded systems.
(no DLL hell:)

The need for an automated build environment grew out
of the "proliferation of files" in persuit of reusable
software. Observation: Developers hesitate to
create new source files because of the makefile
maintenance overhead, laziness prevails, code gets
really ugly and software rots. Of course, ugly is
in the eye of the beholder ;-)

In the original BENV, the developer adds the
name of the new C/C++/asm source file to a
file named "sources.b" in the same directory
where the source file lives. In John's version
you don't even have to have a "sources.b" file.
The build system generates/checks dependencies
and builds a library (library.a) for that
directory in a parallel derived object tree
associated with the project being built.
Its MUCH easier to use than it is to describe.

Hope this helps.


Quoted text here. Click to load it


--
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: XMK eXtreme Minimal Kernel experiences?
Quoted text here. Click to load it
directories. That still seems like a lot.

The short answer is YES there are a lot of files and directories.
However, when compiled, XMK is small.  For example for
Hitachi's/Rensas's H8/SLP (38024) microcontroller with the minimum set
of kernel services, the ROM footprint is 336 bytes, and the RAM
footprint is 18 bytes + 3 bytes/thread (sans the actual thread
stacks). For more details see
http://xmk.sourceforge.net/xmk/docs/example-ram.txt.

The long answer.  All of the source code for XMK is under the src/xmk
directory tree. The other directories/files can be consider
"non-essential", that is they are not needed to compile and link your
application with XMK.   The source code for the kernel itself (sans
developer tests, UART drivers, and documentation) is 177 files and 71
directories (approx 4K lines-of-code).  Still appears to be a lot of
files.

<more weaseling> The majority of above 177 files and 71 directories,
deal directly with handling platform, chip, processor mode, and
compiler differences between the various supported platforms.  Instead
of using #ifdef statements through out the code, XMK is organized to
have separate files to handle the differences in platform, chip,
processor mode, compiler, etc.   So removing the "platform specific"
files (which accounts for about 15% of ROM size of the compiled
kernel), the file count is 50 files, and 16 directories, or about 2.6K
lines-of-code. </more weaseling>

Quoted text here. Click to load it
build-environment and/or project-management system called BENV.

Yes XMK uses BENV as its "native" development environment.  HOWEVER,
XMK is not dependent on BENV and does not require BENV to build the
kernel.  Nothing prevents XMK users from using their own
favorite/IDE/make build environment - they just have to set it up
themselves.  It is an acknowledge deficiency in the distribution of
XMK that is does not use "traditional" open-source approach of a using
'autoconfig' and 'make'.

<shameless sales pitch> I started using a variant of BENV over 5 years
ago while working on a mid-to-large embedded telecom project.  For
embedded development, it rocks.  More info on BENV can be found here
http://www.shift-right.com/openrepo/benv-introduction.htm </shameless
sales pitch>


Quoted text here. Click to load it
mutexes, semaphores, and maybe timers and event flags...

XMK supports all of the above except for event flags (it's on the todo
list).  And I not sure what you mean by "timers".   XMK has a
thread-sleep call and a system tick timer.  But there is no generic
"timer" support where the application can register for call-back when
a timer expires.

Re: XMK eXtreme Minimal Kernel experiences?

Quoted text here. Click to load it

Certainly.  I wasn't doubting the footprints.

Quoted text here. Click to load it

The main impediment to understanding is that the organization of the source
is different than what I'm used to.  At first glance it appears complex.
There advantages to finer-grained file directory/file layouts, but it takes
some getting used to.

Quoted text here. Click to load it

I don't think I've ever seen embedded code that used "autoconf", but "make"
has certainly been the de-facto standard for the past 20+ years.

Quoted text here. Click to load it

Interesting.  It sounds like a useful system, but I think you're going to
have a tough time convincing people to take the effort to switch.

Quoted text here. Click to load it

In the past there have been two sorts of timer support that I've found
extremely useful:

 1) One-shot, countdown timers that count down to 0 and stop.  An optional
    callback when they hit 0 is handy.  The application code needs to be
    able to reset the value while they are running.

 2) Cyclic tasks: a simple way to make a task wake up at fixed frequency
    with zero drift.

If there's a system tick ISR to which one can attach code, both of the above
can be implimented easily in application code -- though there can be (small)
efficiency gains by moving those features closer to the kernel/scheduler.
    
--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: XMK eXtreme Minimal Kernel experiences?
Quoted text here. Click to load it

Let me preface my post by saying the external review of XMK has been
honestly appreciated you can't fix something till you know it broke.
 I also apologize for posting out-of-order.

The most glaring defect uncovered in this thread is the sheer number
of files in the XMK distribution.  In fact there are so many files,
" you can not see kernel through the trees " ;-).

In response, I have created a "Compact Release" format for XMK in
addition to the current "full" format.  The Compact release only
includes the kernel code, drivers, and a very small set of example
programs for a very small set of the supported platforms.  The Compact
release also uses traditional GNU Makefiles (in place of BENV) for the
few example projects it contains.

The Compact Release for the latest XMK release can be downloaded at
http://sourceforge.net/project/showfiles.php?group_id73%662 .
Download the file: xmk-0.0.8a-compact.tar.gz

Comments, criticism, suggestions, additions, deletions, etc. about the
Compact Release will be greatly appreciated.

Re: XMK eXtreme Minimal Kernel experiences?
On 29 Oct 2003 20:06:04 -0800, jtaylor@shift-right.com (John
[snip...snip]
Quoted text here. Click to load it

Thanks a lot, John ! Fast reaction !

As i get closer, the whole ting looks better. What i am still
missing is an overview of *how* XMK is done, because at the
moment i am getting a bit lost due to the use of indirections.

For me a short description of the basic data structures (TCB?)
and a list of the routines to be used by user tasks in the
bare minimum would be a great help. At the moment i have to
use "grep" with some buzzwords to find the pearls in
all the indirections, which is a very timeconsuming process.
If You are in a foreign city, a city map helps a lot!

I hope it's not too unkind to ask for this help.

Thanks for Your work
Klaus

P.S. As i have to go to Italy for one week, i will
quit the discussion and come back later.



Re: XMK eXtreme Minimal Kernel experiences?

Quoted text here. Click to load it
I have planned for an overview description and/or document for XMK (there is
even a 'link' for it on the web page), but I never seem to do it :(.  One
problem I have with writing the overview, is "who is the target audience?"
Is the software architect who needs to know all of the gory details of what
is included in the system? Is it the application developer who doesn't
really care what inside, but just needs kernel services to get his job done?
Is it a marketing brochure (I hope not)? Is it a "crayon view" for manager
types who are responsible for signing off on using XMK in their products?
The list goes on....  Any suggestion on this are welcome.


Quoted text here. Click to load it
The TCB is not really "publicly" documented anywhere since it is strictly an
internal data structure. Once again, who is the target audience? Here is
quick description:  The TCB consists of a pointer to the thread's stack, and
one additional byte that is a collection of status/state flags for the
thread.

Quoted text here. Click to load it
The short answer, is that the header files in the src/xmk  directory contain
the "public" interfaces, i.e. the routines available for use by the
developer in threads and in interrupt service routines.  Assume all routines
can only be used at the thread level unless explicitly stated otherwise.
XMK uses a naming convention of Xmk_isr_xxxx() to mark what functions can be
used in interrupt service routines.   There are additional public interfaces
for the hardware drivers, but they are located in several places.  The web
page, http://xmk.sourceforge.net/xmk/docs/doc.htm (or if you have downloaded
the source src/xmk/docs/doc.htm) contains links to all of the public header
files and/or interfaces.   There is not much "textual glue" on the
documentation page to help sort out the different interfaces.  Suggestion
are welcome.


Quoted text here. Click to load it
Not at all.  And besides, I eventually recycle my XMK support/help
emails/postings into documentation :).



Re: XMK eXtreme Minimal Kernel experiences?
On Fri, 31 Oct 2003 10:58:11 -0500, "John Taylor"
[snip...snip]
Quoted text here. Click to load it

Its good enough to do it just foe me ;-)))

But honestly, what i am looking for, is like an abstact of
a paper.
Instead of a complete description, just a short summary. I am
already very happy with Your description of the design goals,
where You describe what XMK is and what it is *not*
(very important and mostly omitted). Absolutely perfect!
Now a second page, *how* the goals are achieved :-)

Quoted text here. Click to load it

Thats just the information i wanted to find :-)))


Quoted text here. Click to load it

What i am asking for is a lot shorter. Something like:

begin--------------------------------------------------------

XMK is basically constructed as an array of TaskControlBlocks
and n??? basic routines.

The TCB consists of a pointer to the task stack and a status
byte for various flags.

The priority of a task is its offset into
the array, the first entry has the highest prio, the last entry
the lowest prio (thats the idle task). The scheduler scans the
array of TCBs from high to low prio and makes the first
task with READY-status running.

The scheduler is invoked whenever ....???

Statically defined task have to be declared ....???

Dynamically created tasks can be declared ....???

The following services are available optionally:
semaphores, mutexes, timer  ???
end------------------------------------------------------------

Once again, i am not asking for a description of all routines,
i am asking for an abstract, for a short description of the
design ideas to get an overview or perhaps better: a skeleton
of knowledge.

Thanks for Your patience

Klaus

P.S.That's my last posting for a while


Site Timeline