rtel wrote on Sunday, October 15, 2006:
> Misc topics, here:
> 1) As far as I can tell, the semaphores really just wind up creating queues
> - is that correct? If so, if I have a semaphore of 10,000 units, that runs me
> out of memory quite quickly. Is there any way around this?
The semaphore implementation is a set of macros that demonstrate how a binary semaphore can be implemented using the existing queue implementation. A queue is created that has one space, of zero length. The length is zero as you never actually post or receive anything from the queue/semaphore, all you are interested in is whether space would be available or not.
Using macros to implement binary semaphores over an existing feature in this manner, rather than having a separate semaphore module, maintains the low ROM footprint and minimises source code to facilitate testing. The binary semaphore implementation is however limited. If you were wanting to implement a counting semaphore you could write a simple function API that uses the macros. The function would keep track of the count value, causing calling tasks to block only when the count reached zero. I think this implementation would then only take a couple more bytes of RAM over that used by the binary semaphore - the extra bytes being used to maintain the count value.
> 2) I’ve worked with ThreadX in the past and they had a great concept of “event
> flags”. That is, it’s a UINT32 that you can block on, with other trigger points
> - inside or outside an ISR, and it can unblock multiple waiting threads. There
> doesn’t appear to be any way to do this in FreeRTOS. Anyone interested in getting
> them added?
This is a topic that came up a while back. Somebody was implementing event flags, but this was some time ago and I have not heard anything since. Can you explain a little more of their functionality, how you want them to work. It’s about time we added some more functionality. Unblocking multiple tasks on an event should not be too much of a problem, but having a single task block on multiple events could be.
> 3) There are currently APIs that are to be used outside and inside an ISR. Isn’t
> it possible to make the core routine (e.g. QueueSend/QueueReceive) just know
> when it’s in an interrupt, especially on an ARM platform? I have a procedure
> that’s sometimes called from an ISR and sometimes from foreground code, and
> I need to manually manage which context I’m in. It would be nice if FreeRTOS
> did that automatically.
To do this you would require one of four things (correct me if I’m wrong).
1) A portable way of detecting when you are in an ISR (something that could be implemented outside of the portable layer).
2) A (non portable) way of detecting when you are inside an ISR for every architecture that FreeRTOS.org executes on, i.e. a call to the port layer would be made by the API functions to determine if you were inside an ISR or not.
3) A function that the user would have to call on entry and exit of every ISR to let the kernel know when it was in an ISR.
4) A much more heavy weight interrupt management scheme for the kernel - this might be nice but would be a problem for maintaining so many different architectures.
The abcFromISR() versions of the API functions basically do not cause a context switch automatically, but instead return a value to the caller to indicate whether a context switch should be performed or not. This allows the caller to control when the context switch occurs, and thus ensure the interrupt is cleared prior to the context switch occurring right at the end of the ISR. Again, each architecture handles this in a different way.
My design goal is to make writing ISR’s as easy and light weight as possible, and where possible allow them to be completely written in C. This is more successful using some tools than others. It is a compromise of coarse.
Also, to choose whether the context should be saved on entry to every ISR, whether or not a switch actually takes place, or whether to just save the context should a switch be required.
> 4) I’ve done a port to the Atmel SAM7S256 using the ARM SDT 2.51 - more specifically,
> an Olimex SAM7P256 board. Is anyone interested in the source code?
Is this the Keil IDE with the ARM compiler? I am having a problem with these tools when using the demo version. The demo is limited to 16K, but it seems to take the RAM image into account when calculating the size - which is a problem when using the heap_1 or heap_2 implementations. Just setting the configTOTAL_HEAP_SIZE up can cause the ‘object code too large for demo version’ error, whereas it should not alter the object code size at all.
It’s very late and my head is fuzzy - so I hope this makes sense.