Reply by Mike July 16, 20042004-07-16
"Nigel Day" <nigel.day@polyhedra.com> wrote in message news:<ccdmpg$nsh$1@news.freedom2surf.net>...
> have you considered OSE (www.ose.com)? Their OSE Delta product runs on ARM - > as does their lower-footprint variants. > > Nigel Day > > "Sagar" <mailsagr@yahoo.com> wrote in message > news:b0a2c083.0406221507.3175ce4a@posting.google.com... > > 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 > > (www.segger.com) 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 > > > > mailsagr@yahoo.com (Sagar) wrote in message > news:<b0a2c083.0406212038.1c80d905@posting.google.com>... > > > 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
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 www.segger.com/download.html. Mike
Reply by Mike July 16, 20042004-07-16
"Nigel Day" <nigel.day@polyhedra.com> wrote in message news:<ccdmpg$nsh$1@news.freedom2surf.net>...
> have you considered OSE (www.ose.com)? Their OSE Delta product runs on ARM - > as does their lower-footprint variants. > > Nigel Day > > "Sagar" <mailsagr@yahoo.com> wrote in message > news:b0a2c083.0406221507.3175ce4a@posting.google.com... > > 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 > > (www.segger.com) 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 > > > > mailsagr@yahoo.com (Sagar) wrote in message > news:<b0a2c083.0406212038.1c80d905@posting.google.com>... > > > 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
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 www.segger.com/download.html. Mike
Reply by Nigel Day July 6, 20042004-07-06
have you considered OSE (www.ose.com)? Their OSE Delta product runs on ARM -
as does their lower-footprint variants.

Nigel Day

"Sagar" <mailsagr@yahoo.com> wrote in message
news:b0a2c083.0406221507.3175ce4a@posting.google.com...
> 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 > (www.segger.com) 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 > > mailsagr@yahoo.com (Sagar) wrote in message
news:<b0a2c083.0406212038.1c80d905@posting.google.com>...
> > 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 by Ken Lee June 28, 20042004-06-28
On 21 Jun 2004 21:38:25 -0700, mailsagr@yahoo.com (Sagar) wrote:

>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
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 by Sagar June 24, 20042004-06-24
the clock speed is 40 mhz. i compared these latency figures with other
rtoses running at the same clock speed.

Sagar

bastian42@yahoo.com (42Bastian Schick) wrote in message news:<40daacc4.1034954626@news.individual.de>...
> > > >cmx interrupt latency: 1.375us > >context switch time: 3.175us > > At what CPU clock ? 1MHz, 10MHz, 100MHz ? > > I'd not go for pure context switch-time, rather for a IPC sequence.
Reply by Tom Taylor June 24, 20042004-06-24
Sagar wrote:
> 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
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 by 42Bastian Schick June 24, 20042004-06-24
> >>>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 >> >>I doubt that these figure are true. It may represent the bare OS >>without message-queues and semaphores or whatever. > >Apart for the low per task RAM for a modern processor with multiple >registers, those figures looks quite reasonable.
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 :-) Use <same-name>@epost.de instead !
Reply by 42Bastian Schick June 24, 20042004-06-24
> >cmx interrupt latency: 1.375us >context switch time: 3.175us
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 :-) Use <same-name>@epost.de instead !
Reply by Sagar June 23, 20042004-06-23
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


mailsagr@yahoo.com (Sagar) wrote in message news:<b0a2c083.0406221507.3175ce4a@posting.google.com>...
> 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 > (www.segger.com) 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 > > mailsagr@yahoo.com (Sagar) wrote in message news:<b0a2c083.0406212038.1c80d905@posting.google.com>... > > 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 by Not Really Me June 23, 20042004-06-23
David Brown wrote:
> "Not Really Me" <scott@exoXYZtech.com> wrote in message > news:RMXBc.17$7e3.7669@news.uswest.net... >> Sagar wrote: >>> 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 >> >> 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. >> > > 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)?
The license is $2750 for a unlimited number of copies for a single product. Contact Jean Labrosse at Micrium for details.