FIFO semaphore quickie
coyoteboyuk at hotmail.com
Fri Jun 10 17:54:41 CEST 2005
I'm trying to use a pair of rtai FIFOs, created in a kernel module, with a
second interface application. Kind of like an incoming and outgoing buffer
of new data. The kernel module has absolute priority over the system and
every time a packet arrives on a seperate serial link it checks to see if
there is any new data to go in either direction. The kernel module basically
keeps sending data as required by the hardware, even if its the same data as
last cycle, or sends the next data from the FIFO queue if there is any
there. At the end of every packet recieved it also transmits the latest data
from the hardware back to the UI through the second FIFO.
I implemented this without semaphores and got a rather 'jerky and random'
response from the hardware - telling a joint angle to go from A to G through
B C D E and F often went A -> E -> G despite the UI having supposedly
written all intermediate steps to the FIFO. I assumed this is due to lack of
control over who has access to the FIFO at what time.
So i created FIFO semaphores, as described in the documentation, in the
module, testing to see if its free or not before attempting to access it 16
bytes at a time.
My question is now - when i run the UI side it locks the PC completely, i
assume because im not checking the semaphore from in the UI and re-posting
it when finished with it. Do i just use the FIFO name as in the module for
Can you think of a better way of implementing a queueing system that might
avoid any issues like this? The kernel module must always have priority or
the serial comms will timeout on the hardware, but the UI needs to have
sufficient calculation time to work on a few complex calculations.
More information about the Rtai