embOS anyone?

Micrium's uC/OS-II is better.

now, apparently, one is not allowed to

Without comparing it to any others, I can say that I looked at it and I was not impressed.

--
Scott
Validated Software
Lafayette, CO

I am not sure from the licence page if this restriction is valid - it looks like you can consider FreeRTOS as pure GPL if you are not interested in the exception, and then there is no restriction on how you use the software. However, the name "FreeRTOS" is trademarked, so then you could be restricted from publishing comparisons that use the name.

There is certainly nothing to stop you doing your own private comparisons - it's only publications that bother people. As it says on the FreeRTOS website, such restrictions are very common - it is too easy to make a product look bad (intentionally or by mistake) through odd configurations, alternative choices of compilers, synthetic benchmarks, etc. Additionally, there is no "better" for software like an RTOS - it depends entirely on *your* needs, so *you* are the only one who can make a sensible comparison.

This should be an indication of something...

As to which RTOS is better, it depends on your needs. You must first decide if it has the features you need - do they support your devices and your tools? Pricing and licensing are important too - embOS looks like it is licensed per developer for a given target and toolset, while FreeRTOS uses a modified GPL or a paid (per project, IIRC) version.

FreeRTOS is very popular, and the author posts regularly in this newsgroup. I'm sure he'll be able to give you more information here.

Yes - I saw the post but considered myself to bias to provide a reply (btw Scott from Validated Software sells products based on uCOS/II).

Although, actually, I tend to be quite honest in responses as I'm not trying to sell you anything :o)

--
Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.

I'd imagine you get many more OpenRTOS and SafeRTOS customers from happy FreeRTOS users, than you would from trying to sneak in adverts in c.a.e!

You are biased, but honestly and openly so.

mvh.,

David

.

btw

rying

ignore this bitching

ntroller_Systems

tos_license_fee...

You did not state what kind of application, what kind of bisness, what processor, your connection to the project (in-house developer? project manger? consultant?).

emBos is good for genral perpose embedded, IAR resell this as =91PowerPac=92.

I think then choosing an RTOS to fit an application there are three things to check:

1. Ecosystem available
2. Technical ability/performance
3. Licensing Note that cost should not be considered at this point.

So to start:

1. Ecosystem available: Use an RTOS, not just for the API but so you can quickly snap in code modules that work alongside. Take advantage of Ports (BSPs) that are off the shelf. Consider the middleware services available from the RTOS provider and the services you will need now AND in the FUTURE. For example: you do not need a USB Host for now, but the marketing department is playing with the idea of adding USB memory stick uploading, USB Host is not the kind of software you want to write or have to integrate a non-matching stack by hand as it could take weeks. Your check list might go:

*RTOS *File system in FAT 16 for SD card *USB device in HID class *TCP/IP with FTP service only *Graphics lib available for possible qVGA LCD that boss wants me to add in v2.0

1. Technical ability: Check if the stacks and RTOS services live up to the performance you need. Some TCP/IP stacks work better then others, some USB are =91good enough=92. You will find the actual footprint of the RTOS on most good quality ones pretty much the same and 2k bytes will be the least of your worries

1. Licensing: Different products have different licenses: GNU, Per product, Per developer seat. Understand what is required by the GNU license when you incorporate this and country restrictions, Select per product for a single product being developed by a large number of developers (such as a large medical device), select per developer seat for a wide product range from a few developers (such as industrial PID controllers or something).

I will do some evaluation for you:

1. Micrium, Very good ecosystem from Micrium, very wide range of ports and BSPs many components (USB, TCPIP, CAN, Modbus, FS, LCD so on) and support from third parties, per product licenses, reasonable technical performance (read the book)
2. emBos, reasonably good ecosystem from Segger, many ports and BSPs, some third party support a lot of components, per seat licenses , very good technical performance
3. GNU based offerings very poor ecosystem, inconsistent ports or services, licenses can be very restrictive, some good technical ability from the kernel but middleware service vary widely.

Note that all of these RTOS are only for low availability applications. For high end see products with MMU support and process/ message based operation.

It is pretty easy to clear to say that GNU offerings are free but you spend a week or more getting BSP and middleware services in place and possibly futher in the future

Yes, I do and I apologize for leaving off the disclaimer. I try to include it when a question like this comes up.

(Disclaimer: Validated Software is a supplier of Safety-critical Validation Suites for uC/OS-II and other embedded products)

--
Scott
Validated Software
Lafayette, CO

ha ha. i understand Richard's response and also understand that Scott really believes.

thank you,

Aaron

-- { trusting the airlink fully. playing games. violations of one person's privacy is unfair }

good evening Sirs:

thank you for the many resp> You did not state what kind of application, what kind of bisness, what

i apologize. i cant give too many details. its part of a storage processor. i think that LSI HBAs also use ARMs. i am an engineer of Arystor Limited

did all that. now making the final selection. problem is that not many opinions are available on embOS and FreeRTOS. i know that Micrium uC/ OS-II and ThreadX are respected.

good useful information. thank you.

interesting because its vital. there's the GPL. most commercial RTOSs have no royalties but licenses depending on how many pieces the RTOS is used in. can be quite expensive. embOS is different because its a per-developer license.

that is very kind of you. we reached similar conclusions, but more specific to our application.

with GNU, you are on your own. unless you choose the excellent Crossworks Tasking Library (CTL) from Rowley. even Raisonance uses GNU.

exactly. you develop everything. FreeRTOS has a port for GNU on STR75x. if there is no direct port for your MCU, you will have a tough time porting the assembly language parts and linker scripts from RVDK/ IAR to GNU.

GNU has an advantage: you can easily transfer Das UBoot with its inbuilt GNU Makefile system. with IAR/RVDK, changing Das UBoot is tricky. i like GNUARM

which is great and easier to use than other GNU ARM toolchains.

has anyone heard or used Fusion RTOS from Unicoi? its completely license free, tiny, ported to ARM7 and seems to be great.

Operate Free: Unicoi Systems Eliminates Licensing Fee From its Leading Fusion RTOS

Fusion RTOS

Unicoi State Park and Lodge

thank you once again,

Aaron

-- { Garbage In, Garbage Out }

RTOS licensing varies widely - there are several common models and none that are followed by "most commercial RTOSs". The four most common models are royalties on shipped products, licenses per developer (or site), licences per projects, and various open source licenses. Some of these open source licenses (such as pure GPL) are very restrictive in practice, others are much more friendly (such as FreeRTOS's GPL + exception).

With GNU tools, you are on your own - if you want to be on your own. If you want help, there are plenty of free sources. If you want commercial-level support, there are plenty of companies offering such support (at an appropriate price, of course). Support options for GNU tools are not really that much different from support options for commercial tools - there is a variety available, at varying prices, and varying quality. One plus side is that for popular tools there are often several support suppliers - a down side is that it is not always as easy to find them as for commercial tools.

So is SCIOPTA, but different architecture (Direct Message Passing).

(Disclaimer: I work for SCIOPTA, and yes I want to sell it :-) though I am one of their code-slaves)

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @monlynx.de instead !

ntroller_Systems

tos_license_fee...

A short answer. I have used embOS in the past and it is a fine RTOS. I also dare to disagree with Scott about uCOS-II being better, have looked into both and embOS appeared to be more feature rich. Ecosystem: it is definitely true that uCOS has a good market acceptance in the US, embOS "home market" is Europe and it is used by many major companies. There are all kind of drivers for uCOS, such as Ethernet - TCP/IP, USB-HS, CAN, File System, USB-Host, USB-device, LCD some are developed by Micrium, others are 3rd party implementations (e.g. uC/GUI and emWin seem extremely similar).

As for embOS, TCP/IP, FS, LCD, USB-device are all developed by Segger, so the know how is inhouse.

Going with embOS would also give you a very good support person located in MA assuming you are actually in the US yourself.

Hope this helps, an Schwob

In message , ArystorAaron writes

It is very widely used in Europe.

Better in what way? Swings and roundabouts. It depends what you are doing

There is no mystery here....

I have lots of people using it. All very happy with it. The trouble is they are all working on projects in companies they are not likely to talk about.

Being free FreeRTOS has a community of students and hobby people who do talk about it.

That is why you see more chatter about freeRTOS.

That is a set of questions from a company selling RTOS so it will be biased to their own RTOS

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message , An Schwob in USA writes

I have had no complaints from my users and they often use embOS on new targets once they have tried it on one.

This is true. embOS is German in origin so it started in Europe. It is very well engineered and reliable. Just as you would expect from German Engineering. It has been used in all sorts of things from Aircraft and medical to cars and washing machines...

Also a very good Graphics system and they are expanding their range of modules for the RTOS

It does everything including making the coffee... there is a high end coffee maker that uses Segger SW.

That would be Shane. He is good.

So don't let the lack of chatter about embOS put you off. The engineers using it tend not to chatter in Usenet. Try the demo version,.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

That's new to me. AFAIK emBos has no own TCP/IP. They _had_ a third party stack.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @monlynx.de instead !