>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 bytesI 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 :-) Use <same-name>@epost.de instead !
rtos features
Started by ●June 22, 2004
Reply by ●June 23, 20042004-06-23
Reply by ●June 23, 20042004-06-23
On Wed, 23 Jun 2004 05:24:33 GMT, bastian42@yahoo.com (42Bastian Schick) wrote:>>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. 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 by ●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.
Reply by ●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 ●June 24, 20042004-06-24
> >cmx interrupt latency: 1.375us >context switch time: 3.175usAt 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 ●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 ●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 > SagarI'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 ●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 ●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 >SagarBefore 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 ●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 messagenews:<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