rtos features

hello,

i am evaluating various rtos for on of our products based on arm7. i have been looking at Nucleus, embOS, Rtxc, Threadx and MicroC os-ii. Of the lot Threadx and embOS seem to be good. Although i believe that the others are just as good. It seems hard to zero in one choice. I have been searching for reviews in the newsgroups. I have found some scattered info for nucleus and threadx (threadx apparently seems to be better).

I am primarily looking at these features: Scheduling, events, queues, low interrupt latencies, small mem footprint, fast context switching, ....

I would appreciate if somebody could post their views/experiences on these rtos'.

Thank you Sagar

Reply to
Sagar
Loading thread data ...

You maybe should consider Sciopta as well :-) 100% Assembly. Designed for low-mem to high-speed applications.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

I have direct experience with ThreadX (in a source level license) and found it to be solid, well debugged, and the support to be outstanding. It has been excellent to us (we've shipped about 30 products with it).

-->Neil

Reply to
Neil Bradley

Did you consider VxWorks? VxWorks has been around for a long time and is quite stable.

Sandeep

--

formatting link
EventStudio 2.0 - Real-time and Embedded System Design CASE Tool

Reply to
EventHelix.com

You should take a look at CMX-RTX from CMX Systems (

formatting link
) also. CMX-RTX has all the features you are looking for and no royalties! CMX-RTX runs on the ARM7 and about 30 other microprocessors including DSPs.

Paul Bosselaers

Reply to
Paul J. Bosselaers

I am very partial to MicroC/OS-II. It offers all the features you list including fast context switching. It has been ported to all kinds of chips based on ARM7 and ARM9 cores and the ports are available freely from Micrium's web site. Jean Labrosse published a book on the OS (available on their web site or from Amazon) and the book includes a CD with all of the source code. You can have it all for about US$70. A production license is under $3000.

MicroC/OS-II has also been tested extensively for use in safety critical systems.

--
Scott
ExoTech R&D, Inc.
Reply to
Not Really Me

What about Real-Time Linux? There's a free version available that I've used for years in pseudo PCs but they also have versions for a variety of uPs.

Norm

Reply to
Norm Dresner

chips

on

is

When you say a production license is under $3000, what sort of quantities is that for? Do they make a distinction between a product with, say, 50 units a year, and one with several thousand? And do you need a seperate license for different products (or different versions of the same product)?

Reply to
David Brown

Sadly it's too expensive for me, I'll have to stick to ecos! I do a lot of small quantity products, and while I suppose I could argue that all my products are just variants, I can't afford to get into an argument, so that's that.

Paul Burke

Reply to
Paul Burke

Thanks guys for the feedback. I should have mentioned the chip specs earlier: it is an arm7tdmi-s with: 512 KB program flash, 32KB data flash, 32 KB ram.

with these tiny resources, I am begining to feel that embOS

formatting link
may be my choice. All other RTOSes that i had mentioned before seemed to occupy too much space in flash or they needed more resources in RAM.

for eg: for the features that i mentioned before, embos requires: kernel space in flash: 6.4 KB kernel ram usage: 51 bytes ram per task: 32 bytes

the only apparent negative aspect to it compared with other RTOSes like threadx seems to be the context switch time(18us vs 1.9us of threadx) and interrupt latency (max 6us vs 1.8us of threadx). but threadx uses more ram per task. maybe threadx stores a lot of process info in ram and hence has to save less while switching.

Regards Sagar

Reply to
Sagar

I doubt that these figure are true. It may represent the bare OS without message-queues and semaphores or whatever.

Sciopta e.g. needs with full functionality 15KB flash and about 2K of kernel-ram. 128Bytes per task. _But_ this includes already timeout-servers, message-queues.

Ask them to give the maximum numbers.

BTW: We have Sciopta+webserver+tcp/ip+PPP running in 512K Flash/64K RAM on a Coldfire 5282.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

Apart for the low per task RAM for a modern processor with multiple registers, those figures looks quite reasonable.

Essentially in a small RT kernel, you need a per task stack (in addition to the stack needed for the actual task execution with return addresses and HLL variable storage) that is capable of storing the task context, which at least consists of the processor registers. _If_ a message queue is used, some pointers to the actual message blocks.

In the days of 8 bit processors, there were a lot of company specific RT kernels requiring 2-4 KiBytes. With a 6809 kernel I once worked with, in addition to the per task stacks only has 3 bytes of kernel RAM per task, two bytes containing the saved stack pointer for not currently running tasks and a third byte to hold some task state information bits :-).

Paul

Reply to
Paul Keinanen

The license is $2750 for a unlimited number of copies for a single product. Contact Jean Labrosse at Micrium for details.

Reply to
Not Really Me

hello,

we got some good numbers from cmx-rtx as well. it seems to be faster than embos and also doesnt seem to use as much ram as other rtoses.

cmx interrupt latency: 1.375us context switch time: 3.175us

kernel ram usage: 180 to 200 bytes.

anybody have any good experiences with cmx-rtx. what kind of timer funcitionality do they support.

Regards Sagar

Reply to
Sagar

At what CPU clock ? 1MHz, 10MHz, 100MHz ?

I'd not go for pure context switch-time, rather for a IPC sequence.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

I just wonder, why they give an odd number for the kernel-ram usage. It seems to me that these are maybe 8bit/16bit figures.

Also, I think they don't count the registers for the per-task RAM.

This normaly include task-state, time-out values, stack-pointer etc..

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

I've worked with Nucleus PLUS on a number of Intel and Motorola platforms since it came out around 10 years ago. I've been very satisfied with it. I particularly like the dual-level interrupt system that permits the use of asynchronous procedure calls to process high-priority events with interrupts enabled.

Advantages are a source license with no royalties, ala carte selection of only the synchronization primitives you want, portability of code, and good coverage of many processor families, particularly ARM.

Disadvantages are that the license is getting a bit pricey and is for one product. Use of resources is more than some of the tighter, less general systems.

Tom Taylor

Reply to
Tom Taylor

the clock speed is 40 mhz. i compared these latency figures with other rtoses running at the same clock speed.

Sagar

Reply to
Sagar

Before embarking on this quest you might want to ask yourself the following questions as this might help in reducing the likely RTOS candidates.

  1. Do you require source code?
  2. How do you want to pay for it: a) free b) one-off licence c) royalty per unit sold
  3. What type of support do you want: a) none b) internet/email c) phone d) local rep
  4. What compiler tools are you going to use. Will the code be written in C, C++ or Ada?
  5. What debugging tools are you going to use? If you're using an in-circuit emulator do you want it RTOS-aware?
  6. Are you likely to use other micros apart from the ARM7 in the future?
  7. What is your test strategy? Is it required to have a variant of the RTOS run on a PC for executing test vectors?
  8. Is the intended product of High Criticality? Is it a medical device?
  9. Does the RTOS need to comply with certain API's such as POSIX, pSOS, uITRON, OSEK.
  10. Is a filesystem required?
  11. Is there networking, TCP/IP stack?
  12. Is there a large LCD type display?
  13. What is the level of expertise of the software developers? Do they need training in the RTOS?
  14. Does it worry you that some RTOS vendors may not be around in 5 years time?

Anyway something to think about.

Ken.

+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com
Reply to
Ken Lee

We really made good experience with the Segger Tools (embOS/emWin). We used it on a different CPU but will need an ARM chip for a new application for which we will choose their system again. It inlcudes a start project and the viewer (included) is very helpful. The best way to find out if it is suitable for your application is to download the trial version. Just go to

formatting link

Mike

Reply to
Mike

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.