nobody wrote on Sunday, October 22, 2006:
> The second is a commerical project (sorry, under NDA, can’t mention what, but
> it’s a video game) that I’m porting from another RTOS that is long since dead
> (almost 10 years now) and with no rights to use.
A ten year old video game - sounds fun.
>I’ve done a mapping of functions
> between FreeRTOS, the old operating system, and the actual function calls used,
> and there are holes that simply aren’t there in FreeRTOS:
First - in the queue wait forever thread I have detailed what I think (without yet having studied it in great detail) is a two line change that permits wait forevers.
In software I have a philosophy of minimalism and simplicity. I don’t like to see features that are duplications, surplus or implemented in a more complex manner than necessary. The problem is though that how features are categorised is a philosophical question - John and yourself are both experienced engineers so I respect your view point - even if I don’t always agree. In an ideal situation new features will utilise the services already present - and I suspect that many commercial offering use 95% the same code for say mutex’s and counting semaphores.
> 1) Counting semaphores
I think these could be simply implemented by having a simple P and V wrapper around the exiting semaphore macros. Each counting semaphore would consist of a count value, and a handle to a semaphore as per the exiting implementation. When the count was zero the queue and even mechanism of the semaphore would be used - otherwise the count would be simply incremented and decremented.
I think this would be a good thing for me to add as it is something that has come up more than once.
As an aside, I originally had the plan of not using any #ifdef’s for conditional compilation as it does nothing for code readability. This ambition went out the window some time ago, so new features like this can be added but by default not be compiled into the code to maintain backward compatibility (wrt code size).
> 2) Event flags
This is an interesting one. There is not a quick solution that I can think of yet.
> 3) Mutexes
Why can the existing binary semaphore implementation not be used for this?
> 4) Timers
In what sense? Tasks can easily have them selves scheduled with a fixed period.
> 5) Task sleep/delay (this code suspends other tasks that are running for periods
> of time)
A task can sleep and delay itself for a fixed time, or until an absolute time. A task cannot do the same to another task - but implementing this would be straight forward. All you would need to do is pass in the handle to the task you wish to sleep and have the sleep performed on that handle rather than the handle of the calling task. This is similar to vTaskSuspend, which passes in NULL to suspend itself, or the handle of a different task if it wants to suspend a task other than itself.
One other point is that FreeRTOS is never intended to compete with, for example, real time versions of Linux. It is intended for small systems. ARM7, 9 and Cortex-M3
> BSPs are a long haul. As long as there are sufficient proven examples to work
> from, that should be enough. There are always going to be people saying “Do
> you have a FreeRTOS port for chip x on compiler y?” and you’ll spend a lifetime
> trying to support them all. As long as support for free tools like GCC is availalbe
> and there’s at least one port for any given type of chip, that’s most of what
> you need right there.
I agree! You would not believe the number of conversations I have that go something like:
Q - Oh, I see you support the SAM7S64, do you also support the SAM7S128?
A - What is the difference between the two.
Q - The 128 has more flash memory.
A - Yes FreeRTOS.org supports the 128 also.
Q - Where are the files in the download, I cannot find them.
A - Use the 64 files.
Q - But then I’m not using all the flash.
A - Change the linker script.
Q - How do I do that?
A - Read a book, search the WEB, go back to school, etc.
> There’s another apsect of this that ties in to board support packages. That
> is, FreeRTOS is great, but it won’t initialize memory controller x on CPU y
> unless you use one of the examples. I see this as a separate, but also important,
> task, especially when it comes to CPUs with network interfaces and peripherals
> built in to them (Intel IXP425 for example). Then you can go on and on with
> things like flash drivers. All of that is a big job.
Yes. There is a definite trend in the silicon market for vendors to provide source code. For example, I have just been working with the STR750 - which comes with a complete software library (even if I don’t like its style). Likewise the Cortex M3 offerings from Luminary. This is fine, provided people have the initiate to find it and understand it (ref the comments above).