Serial Port Processing, polling mercilessly

NETMF & Gadgeteer
1

I am looking for some design guidance for processing data through a serial port. I am using a Fez Panda to connect via TTL serial lines to another micro controller. Baud rate is 912,600bps and the instructions for communication state: [quote]Commands should be sent via standard serial port communication 8-N-1. Don’t use wait states, delays, or anything like that. Spew bytes/strings to the port, and poll the port mercilessly for responses. You shouldn’t see lag any more than 10-20 mS at the most[/quote]

My searching has brought up a couple things including an example of using events for serial communication:
http://www.tinyclr.com/downloads/Extension/FEZ_Extensions_GPS.cs

And i’ve seen some posts regarding polling in the main thread and information on a Serial Buffer.
http://www.fezzer.com/project/130/serialbuffer-simple-fast-way-to-read-serial-data/

With this project will also be writing to an SD card. Essentially I will sending a serial command to the micro controller that says give me some data. It will then start firing data to me, data that could continue for an hour or longer, and I will need to capture that data and write it to an SD card.

Thus my challenge here is there are so many options, I’d just like to get some input from those that went before on where I might want to start looking.

thanks

2

Although everyone says you should handle things in events, I always recommend using a thread that loops and fetches as much serial data as it can in every loop. The receive method will block and run other threads if there is no data in UART so you will not waste processor time and if you are not running fast enough, your thread will never sleep but you will have round-robin between threads.

It all depends on what the end application does. IS UART most important? Yes? Then give it its own execution thread and let it get plenty of processor’s time…

3

@ Gus. I agree with you.

4

Actually, I may think to go backwards on this, on primay thread, read uart, and cache. If output is ready for data, spin up a thread for that, since it sounds like that is the lower of the two processes, and leave the primary to check for data.

When the child thread is waiting, it can terminate and leave it’s handler vacant. So your primary thread can check child thread status, and queue up new thread if vacant.

I know I am wierd like that. :slight_smile:

5

I appreciate the input and hope to get some time over the holidays to play with some strategies. I have 2 Panda’s to play with so I think I will try a couple different strategies with some different message lengths and see the impact that each has on total performance.