FreeRTOS

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anyone here have experience with FreeRTOS in a large commercial application? Or perhaps with one of the other RTOS packages? Opinions, experiences, reasons for choosing one in preference to the others, etc would be most helpful.

The intended applications centre around instrumentation and system control.

Thanks

Roger

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

laserman wrote:
Does anyone here have experience with FreeRTOS in a large commercial application?

Large Commercial Application - IMO, means no freeware in the target because there's no support in the life cycle.

Also Large Commercial Application - IMO, often means no RTOS at all in an 8 bit micro, to save memory costs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:

Large Commercial Application - IMO, means no freeware in the target because there's no support in the life cycle.

Also Large Commercial Application - IMO, often means no RTOS at all in an 8 bit micro, to save memory costs.


1. Mostly agree, but what about winavr(GCC) for example?
2. "often" is way too strong. I'd say occasionally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FreeRTOS comes in two flavours:
1) Modified GPL
This version has special exemptions that allow you to keep your application code private even though you're linking against the GPL'ed RTOS kernel and modules. However, you required to provide credit to FreeRTOS.org (a link to their website will suffice) in your product documentation. Guaranteed support doesn't exist; you must rely on the peer review system (such as it exists) through the rest of the user community on a volunteer basis.

As well, if you have to modify the internals of any FreeRTOS modules, those changes must be open-source. (That is to say, new modules that you write as add-ons or processes can be closed source, but modifications to existing modules must be open source.) And, as a distributor of binaries which are based on FreeRTOS, you must also become a free (or at most at-cost) distributor of the FreeRTOS source code.

2) Commercial license
This version of FreeRTOS can be distributed as a closed-source project. That is, you don't need to credit FreeRTOS.org in the documentation, and you don't need to propegate any modifications you make to the RTOS kernel. You don't need to become a seed for FreeRTOS source code propegation. It is still royalty-free, but you must negotiate licensing rates and support contracts on a case-by-case basis. Commercial support packages are available, currently underwritten by WITTENSTEIN high integrity systems ( http://www.highintegritysystems.com ).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Define "large". "Large" meaning lots of code (i.e., using an ATMega2560 or its kin) or "Large" meaning lots of units out the door to eager customers? Or "Large" meaning both of these?

I have a "large" (first meaning - I have about 48,000 lines of code) commercial application, but the number of units is small (in the rough 100s per year). I'm using FreeRTOS on an ATMega2560 along with the WinAVR/gcc 4.1.1/AvrStudio 4 toolset.

I agree with Lee about the licenses -- for our application, the Modified GPL is sufficient, but you need to judge that for your own situation.

There are also plenty of other RTOSes out there - I chose FreeRTOS because I didn't need much horsepower in the RTOS (no network stacks, etc).

That's the quick intro.

Stu Bell

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks guys.

Yes, ongoing support is a consideration, but I believe that we (with help from the general user community) could maintain it **at a defined level**. This will be one of those cases where there will need to be tight control over the extent of development growth. Just look at my current situation - from something 'just for us' in an 8215 7 years ago to a product being sold worldwide with capabilities that were never remotely considered in the initial design. My home-grown RTOS does everything that I require of it, but I groan mentally every time I have to squeeze a new feature into it. My hope is that if we reach the limits of the standard RTOS that I select (be it FreeRTOS or some other RTOS) we will be mentally prepared to recognize that fact and upgrade to the next step, whatever that may be.

I cannot see memory capacity being a consideration for our application. Technology is advancing sufficiently fast that I imagine that new chip capabilities will outstrip our requirements.

Lee, thanks for enumerating the license considerations. I was aware of most of it in general, but we would have to examine it in detail. My personal feeling regarding freeware is that if I create something of use to others, then fine, go for it. Bean-counters often see things differently, but I don't think there will be any problems.

Stu, large as in lots of code. I am around 34000 lines now (of assembler), but the product volumes tend to be in the 10's - 100 over several years. I want to keep the present product approximately where it is, in terms of its capabilities, but simply make it easier for others to maintain when I pull the pin. Further development to make use of 3rd generation mobile comms etc shouldn't just be an extension of the present product - it needs a back-to-basics re-evaluation of the whole system, and should be implemented quite differently.

I would therefore be very interested in your impressions of FreeRTOS - general ease of use, any particular sticking points, etc. Problem areas may well not be a deficiency of the system, but due to something unusual the user wants to do. It's all useful information, so please don't be backward in coming forward, Stu.

Thank you, all

Roger

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm in the minority of opinion in not using public domain tools in developing for-profit applications. I never want to explain to the boss that my app didn't work correctly because of a tool bug (e.g., subtle incorrect code generation or a faulty library function). Not that Microsoft et al don't have tool bugs, but when the lawyers engage, if they do, I can step aside and let them go at it. Not so with public domain tools. This is serious business when you work for a fortune 100 company. They get pretty anal about such things.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure you are in a better position getting software from "for profit" companies. If you look at their fine print, they generally say "our stuff isn't guaranteed to work".

There are systems like RTEMS that have proven their mettle and are free. FreeRTOS is sufficiently small and simple that I think a user could maintain it.

A tool's user community is a good source for help when things go wrong. I might be more uncomfortable using an expensive "professional" tool that had a tiny user community than a free open-source tool that had a huge one.

I have several products in production based on WinAVR, with no bugs yet. That's much better than my experience with IAR C years ago.

I don't think there is a right or wrong way to approach this. We each make the best choices we can.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
I'm in the minority of opinion in not using public domain tools in developing for-profit applications.

FreeRTOS is most decidedly *not* in the public domain. Anything released under the GPL (or any of its derivatives) *MUST* be copyrighted, and responsibility for authorship/modification of each module of code must be tracked.

The major difference is that the holder(s) of the copyright of GPL'ed material explicitly allows modification, derivative works, redistribution, etc provided the licensee adheres to a set of restrictions.

Quote:
I never want to explain to the boss that my app didn't work correctly because of a tool bug (e.g., subtle incorrect code generation or a faulty library function). Not that Microsoft et al don't have tool bugs, but when the lawyers engage, if they do, I can step aside and let them go at it. Not so with public domain tools. This is serious business when you work for a fortune 100 company. They get pretty anal about such things.

Ditto on the remark that even commercial compilers generally have a "This product is not guaranteed for suitability for any particular task whatsoever" disclaimer attached to them.

But if you see the feature set of FreeRTOS as desirable, but you must have some ongoing support guarantees, then there are commercial support contracts available.

And there is a commercially licensed derivative work available (called SafeRTOS) whose design, maintenance, and performance practices have been documented to comply with IEC 61508 for SIL 3 safety-critical applications.

(Note that Atmel doesn't usually license its microcontrollers to be used under those circumstances unless special prior arrangements are made...)

(BTW, I'm not Lee; I'm Luke.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lfmorrison wrote:
(BTW, I'm not Lee; I'm Luke.)

:oops: Ooops. Sorry, Luke. I have trouble with names.

laserman wrote:
would therefore be very interested in your impressions of FreeRTOS - general ease of use, any particular sticking points, etc. Problem areas may well not be a deficiency of the system, but due to something unusual the user wants to do. It's all useful information, so please don't be backward in coming forward, Stu.

Ya know, I've spent the last 10 minutes trying to come up with something that was really a problem with FreeRTOS. For my application, there hasn't been one. Of course, I'm not using real "high powered" OS services like network stacks, USB, video subsystems, or the like. This is an embedded controller application, the system is piped in to various analog spigots from the device, and my code talks to the outside world through an RS-232 interface. Not hard stuff.

I use the semaphores, queues, and tasks quite heavily. I don't use the new co-routine capability, partly becuase I started before they were added to FreeRTOS and partly because I don't need them. I've never come across a case of task lock-out (where the "wrong" task has control of the machine for too much time), however the operation of the device is divided well enough that I don't have a lot of concurrent processing that needs to be done.

My only real complaint is that Atmel doesn't make an AVR that runs at 10X the current speed of the ATmega2560, but then we programmers are always asking for more power! :wink: Speaking of power, power usage is not an issue in this application.

I haven't been reluctant to edit the FreeRTOS code, but then I haven't really had to do it. For my purposes, it just works.

The only serious "gotchas" I've found are cases where I've called a non-ISR routine from an ISR (REAL no-no!). If you find the system magically rebooting on its own, look for that!

That's all for now. I may add some more if I get a chance.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, all.

Luke - sorry, I picked up the 'Lee' from some other post...

Stu, thank you for your comments, it's certainly an encouraging start even if you are the only user-respondent. You mention using the 2560, which is a fairly new device, and that you started out using an earlier version of FreeRTOS (before co-routines). Can you tell us how long you have been using it, and if on multiple projects or devices?

Thank you,

Roger

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

laserman wrote:
You mention using the 2560, which is a fairly new device, and that you started out using an earlier version of FreeRTOS (before co-routines). Can you tell us how long you have been using it, and if on multiple projects or devices?

I started work a little less than a year ago. I've only had the current project/device with FreeRTOS. The ATMega2560 is even newer - we got our first parts as samples from Atmel sometime in February, I think.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
laserman wrote:
Large Commercial Application - IMO, means no freeware in the target because there's no support in the life cycle.
I've run into this problem several times with commercial software.

In one case (not RTOS), a company decided to get out of business area and left me without any support.

In another case (this one was RTOS), a different company moved to the next major version and wouldn't support the older version. My only option was to license the new version, port my embedded software and re-qualify - all at significant expense (the re-qualification being the largest portion of the cost).

Don