Phillipe, Here's my setup in short.
I have a two-serial port setup where I read at 50 Hz from a sensor task (a navigation sensor) and I send queue messages from that sensor task to log data or CRC/byte errors to two separate log files using lower priority logging tasks. Concurrently, the 50 Hz serial sensor task feeds state data in the form of a struct of mixed types (floats, ints) to a control law loop that runs at 50Hz (potentially asynchronously). That control loop processes the data if available and sends a command at 50 Hz to the second serial device discussed yesterday (a motor controller) running on another task. The motor controller takes in a fixed command packet and responds with a fixed packet usually without delay. If no data is received by the motor controller, it will not send data. If the motor controller doesn't receive data from the control task within 100 msec, the device requires a separate reset packet in order to resume responding to input commands. At that point, I want a timeout to occur on rt_serial read so that the task will send the appropriate reset packet. That timeout caused the queue to overrun yesterday when I tested that function. When everything is working perfectly, there should be no timeouts throughout the system. So essentially, my question is this-- Should I use the queue for all data-logging tasks and use semaphores or rt_task send/receive for the two paths from the navigation sensor to the control loop and from the control loop to the motor controller? Thank you, Joshua Karch -----Original Message----- From: Philippe Gerum on behalf of Philippe Gerum Sent: Tue 5/6/2008 3:46 AM To: Karch, Joshua Cc: [email protected] Subject: Re: [Xenomai-help] rt_queue_alloc and ways to manage queue overruns Karch, Joshua wrote: > > Hello, > > I have tasks that normally run at 50 Hz dealing with serial ports. I > have a command task which sends queue messages to a receive task that > communicates with the serial port. The receive task waits indefinitely > for a message over rt_queue (with TM_INFINITE) and then proceeds to > write to the serial port, then reads a response from the RT serial > port. Occasionally, the device on the receiving end of the port takes > longer than the expected 20 msec,( 50Hz response) as I've set the RTSER > CONFIG struct to look for a 100 msec timeout. As a result, the number > of queued messages quickly build up. After that, I run out of > allocation space with rt_queue_alloc. > > Is there some way to check to make sure I am receiving the most current > message, and if not, flush all of the queued up messages with > rt_queue_free so I can send the latest data to the serial port and not > encounter message "buffer" overruns? With the exception of datalogging > to disk, I'm very interested in getting to the most current message in a > timely manner. Maybe a queue is not the right tool to use in your case, you don't seem to really need message buffering. From your description, I would rather think of some kind of "blackboard" abstraction, something that holds a single data with a validity stamp (time-based or not) for instance. There is no such object available in the native API, but this could be easily built out of a semaphore and common memory, using a shared counter to hold the transmit sequence number. If you actually don't care for buffering, the other way is to use the message passing API (i.e. rt_task_send, rt_task_receive, rt_task_reply) to get synchronous messaging. In that case, the sender would be able to wait for the receiver to get the status from the serial link. The receiver would send that answer back to the initiator using rt_task_reply. This needs XENO_OPT_NATIVE_MPS to be switched on in the kernel config. -- Philippe.
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
