Reply by 42Bastian Schick●March 17, 20092009-03-17
On Mon, 16 Mar 2009 21:54:08 -0700 (PDT), An Schwob in USA
<schwobus@aol.com> wrote:
>
>As for embOS, TCP/IP, FS, LCD, USB-device are all developed by Segger,
>so the know how is inhouse.
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 <same-name>@monlynx.de instead !
Reply by Chris H●March 17, 20092009-03-17
In message
<5483f3d1-4026-4916-82e8-c2a52d038a14@r15g2000prh.googlegroups.com>, An
Schwob in USA <schwobus@aol.com> writes
>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.
I have had no complaints from my users and they often use embOS on new
targets once they have tried it on one.
>acceptance in the US, embOS "home market" is Europe and it is used by
>many major companies.
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...
>As for embOS, TCP/IP, FS, LCD, USB-device are all developed by Segger,
>so the know how is inhouse.
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.
>Going with embOS would also give you a very good support person
>located in MA assuming you are actually in the US yourself.
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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by Chris H●March 17, 20092009-03-17
In message
<c277a859-57e6-4969-981d-c91dc641df6f@t7g2000yqa.googlegroups.com>,
ArystorAaron <arystor.aaron@gmail.com> writes
>hello:
>
>has anyone used embOS? i have searched high and low and did not find
>any good reviews of the very interesting RTOS.
It is very widely used in Europe.
> also, anyone know which
>is better, embOS or FreeRTOS?
Better in what way? Swings and roundabouts. It depends what you are
doing
>very difficult to find any good reviews of embOS.
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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by An Schwob in USA●March 17, 20092009-03-17
On Feb 26, 7:59=A0pm, ArystorAaron <arystor.aa...@gmail.com> wrote:
> hello:
>
> has anyone used embOS? i have searched high and low and did not find
> any good reviews of the very interesting RTOS. also, anyone know which
> is better, embOS or FreeRTOS? now, apparently, one is not allowed to
> compare FreeRTOS with any other RTOS, so, i dont want anyone to
> violate any licenses.
>
> FreeRTOShttp://en.wikipedia.org/wiki/FreeRTOS
> [...]
> The exception also prevents users from comparing FreeRTOS with other
> RTOSs, except with permission from the author.
> [...]
>
> very difficult to find any good reviews of embOS.
>
> Segger Microcontroller Systemshttp://en.wikipedia.org/wiki/Segger_Microco=
ntroller_Systems
>
> thank you every time to everyone who helps, i am simply humbled by
> their generosity, spending time in unselfish fruitful activities.
>
> Top Questions to Ask your Supplier Before Choosing an RTOS (PDF)http://ww=
>
> Aaron
> --
> {
> =A0 Don Henley, Dirty Laundry: i could have been an actor but i wound up
> here...
> =A0 mobile, streaming, web, inet, voip: Microsoft Silverlight bad
> Macromedia/Adobe Flash YouTube FLV dies
> =A0 OSI CHILL: simple, true protocols with no overhead
> =A0 idea for Ireland: fone receiving multi-vendor satellite cellular Sky
> etc TV based on Fusion RTOS
> =A0 optimized solid-state RAID bypassing disk interfaces.
> =A0 full-speed cacheless CPU.
> =A0 self healing networks, multi-vendor universal CPU 2000.
> =A0 thick pipes into homes 2002.
> =A0 SDLC Loop simulation in PowerPoint.
> =A0 client-srver relay chat from Psion PDA serial to PC UDP to notebook.
> =A0 ptr offset manipulation in C++ avoiding unnecessary class overhead.
> =A0 voice over data CMC 1989
> =A0 2D Bresenham's in assembly optimized to use XOR instead of ADD.
> ]
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
Reply by 42Bastian Schick●March 4, 20092009-03-04
On Mon, 2 Mar 2009 15:30:10 -0800 (PST), ArystorAaron
<arystor.aaron@gmail.com> wrote:
>> 3. Licensing:
>
>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.
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 <same-name>@monlynx.de instead !
Reply by David Brown●March 3, 20092009-03-03
ArystorAaron wrote:
>> 3. Licensing:
>
> 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.
>
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).
>> I will do some evaluation for you:
>
> that is very kind of you. we reached similar conclusions, but more
> specific to our application.
>
>> 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.
>
> with GNU, you are on your own. unless you choose the excellent
> Crossworks Tasking Library (CTL) from Rowley. even Raisonance uses
> GNU.
>
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.
Reply by ArystorAaron●March 2, 20092009-03-02
good evening Sirs:
thank you for the many responses. anyone know Fusion RTOS?
On Feb 28, 1:31 pm, bigbrownbeastiebigbrownf...@googlemail.com wrote:
> 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 (http://www.arystor.com/).
> I think then choosing an RTOS to fit an application there are three
> things to check:
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.
> So to start:
good useful information. thank you.
> 3. Licensing:
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.
> I will do some evaluation for you:
that is very kind of you. we reached similar conclusions, but more
specific to our application.
> 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.
with GNU, you are on your own. unless you choose the excellent
Crossworks Tasking Library (CTL) from Rowley. even Raisonance uses
GNU.
> 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
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 (http://www.gnuarm.org/) 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
http://www.unicoi.com/press_center/unicoi_eliminates_rtos_license_fee.htm
Fusion RTOS
http://www.unicoi.com/free_rtos.htm
Unicoi State Park and Lodge
http://www.gastateparks.org/info/unicoi/
thank you once again,
Aaron
--
{ Garbage In, Garbage Out }
Reply by ArystorAaron●March 2, 20092009-03-02
good evening Richard:
On Feb 27, 4:15 pm, "FreeRTOS.org" <noem...@given.com> wrote:
> 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).
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 }
Reply by Not Really Me●March 2, 20092009-03-02
FreeRTOS.org wrote:
>> 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)
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
Reply by ●February 28, 20092009-02-28
On Feb 27, 2:59=A0am, ArystorAaron <arystor.aa...@gmail.com> wrote:
> hello:
>
> has anyone used embOS? i have searched high and low and did not find
> any good reviews of the very interesting RTOS. also, anyone know which
> is better, embOS or FreeRTOS? now, apparently, one is not allowed to
> compare FreeRTOS with any other RTOS, so, i dont want anyone to
> violate any licenses.
>
> FreeRTOShttp://en.wikipedia.org/wiki/FreeRTOS
> [...]
> The exception also prevents users from comparing FreeRTOS with other
> RTOSs, except with permission from the author.
> [...]
>
> very difficult to find any good reviews of embOS.
>
> Segger Microcontroller Systemshttp://en.wikipedia.org/wiki/Segger_Microco=
ntroller_Systems
>
> thank you every time to everyone who helps, i am simply humbled by
> their generosity, spending time in unselfish fruitful activities.
>
> Top Questions to Ask your Supplier Before Choosing an RTOS (PDF)http://ww=
>
> Aaron
> --
> {
> =A0 Don Henley, Dirty Laundry: i could have been an actor but i wound up
> here...
> =A0 mobile, streaming, web, inet, voip: Microsoft Silverlight bad
> Macromedia/Adobe Flash YouTube FLV dies
> =A0 OSI CHILL: simple, true protocols with no overhead
> =A0 idea for Ireland: fone receiving multi-vendor satellite cellular Sky
> etc TV based on Fusion RTOS
> =A0 optimized solid-state RAID bypassing disk interfaces.
> =A0 full-speed cacheless CPU.
> =A0 self healing networks, multi-vendor universal CPU 2000.
> =A0 thick pipes into homes 2002.
> =A0 SDLC Loop simulation in PowerPoint.
> =A0 client-srver relay chat from Psion PDA serial to PC UDP to notebook.
> =A0 ptr offset manipulation in C++ avoiding unnecessary class overhead.
> =A0 voice over data CMC 1989
> =A0 2D Bresenham's in assembly optimized to use XOR instead of ADD.
> ]
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
2. 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
3. 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