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:
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??
visi.com
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
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 );
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??
visi.com
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 bastian42@yahoo.com, it's a spam-only account :-) Use @epost.de instead !
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
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.
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
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
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.
In what way does it not deliver "realtime behavior"?
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??
visi.com
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??
visi.com
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.
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.
-- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 "... abstractions save us time working, but they don't save us time learning." Joel Spolsky, The Law of Leaky Abstractions The Beatles were wrong: 1 & 1 & 1 is 1
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
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.
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.
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'.
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
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.
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
On 28 Oct 2003 16:59:16 GMT, Grant Edwards wrote: [snip...snip]
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]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.
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
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??
visi.com
Certainly. I wasn't doubting the footprints.
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.
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.
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.
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??
visi.com
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
Comments, criticism, suggestions, additions, deletions, etc. about the Compact Release will be greatly appreciated.
On 29 Oct 2003 20:06:04 -0800, snipped-for-privacy@shift-right.com (John Taylor) wrote: [snip...snip]
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.
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.
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.
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,
Not at all. And besides, I eventually recycle my XMK support/help emails/postings into documentation :).
On Fri, 31 Oct 2003 10:58:11 -0500, "John Taylor" wrote: [snip...snip]
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 :-)
Thats just the information i wanted to find :-)))
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.