ericcox

Finally, try rebooting your PC. I know that that sounds silly, but it's amazing how helpful that can be sometimes.

Anyone else old enough to remember a time when that was the first thing you tried?

Are you using flow control? What's the state of /CTS when you do the SerialPort.Write()?   What kind of camera?

Try placing a try...catch around the SerialPort.Write(), very rarely I've seen this trap an exception that the debugger's unhandled exception trap did not.

I think in your shoes I would try capturing the last few serial interactions on a scope, using both the N+1 and the N+2 and examine them side by side. If you see a difference in the two traces, that would at least give you a starting point.

Good luck to you, I hope you're able to track down the problem.

Pretty nice piece of code Eric, I think I will give this a try sometime.

Do you know  if the AutoResetEvent is in the .Net MF too? This multi-threading-mechanism is pretty cool.

 

Greets, Markus

Thanks Markus.

Yep, AutoResetEvent and ManuResetEvent are in the NetMF.  IIRC, in the full framework it's a single class called EventWaitHandle with the ability to set auto or manual at will.

Couple more things I thought of:

  1. try to keep the code within your lock statements as small as possible.  Rule of thumb in the full framework is 5 IL instructions, that's usually 1 or 2 lines of code.

  2. If your system is designed to run forever, then this code should work, but if you build in the concept of a shutdown/restart or start/stop kind of thing, then you will have to manage the shutdown properly to avoid losing any data. Basically you send a signal to all threads to shutdown, then kick the dataIsAvailable handle (tricking the logger thread into emptying the queue), Then you have to wait for the logger thread to send a signal that it is done before shutting down.  I usually just use "volatile bool" variables for all these signals.  Of course, if a few lost sensor readings or GPS don't matter, then the point is moot  )

Here's how I usually implement this problem on the full version of .NET on the PC: use one thread for the GPS data, one for the sensor data, and a third thread to send the data to the SD card.  You could use a Queue object to manage the data flow.  Your worker threads would stuff the data into the queue, using a locking object to eliminate collisions. I haven't used this kind of thing on the NetMF however - there may be threading idiosyncrasies on NetMF for which I haven't accounted.

object lockObject = new Object();Queue queue = new queue();AutoResetEvent dataIsAvailable = new AutoResetEvent(false);public static void Main(){  ... Create Logging Thread   (Make sure to start this one first)  ... Create GPS Thread  ... Create Sensor Thread  Thread.Sleep(Timeout.Infinite);}public void GPSThreadStart(){   while (true)   {     .... raw GPS data received     ... create data object from raw GPS data     	 lock (lockObject)     {         queue.Enqueue(data);     }	 dataIsAvailable.Set();   }}(Sensor thread is the same basic idea)public void LoggingThreadStart(){   while ( true )   {	  dataIsAvailable.WaitOne();	  while (queue.Count > 0 ) 	  {		 object data;         lock (lockObject)         {           data = queue.DeQueue();         }		 ... Write data to SD card	  }   }}

The AutoResetEvent allows the threads to wait until data is available without using any CPU cycles.  The lock() statements make sure the Dequeue/Enqueue calls are completed before a thread context switch is allowed, avoiding collisions.  Using this scheme, you can enqueue sensor data inside interrupt handlers, and even write the logging data to the same file if you like.  When I do that, I usually use a base class to enforce a common record format, then derived classes for each different type of record.

Hope that helps,

Eric

Thanks Stefan.  Any feedback you can give is appreciated.

By the way I made an easy but fairly important change already: I now create the WiFlyGSX instance at first use, rather than in the WiFlyShield constructor.  I found that by far the most problematic portion of working with the WiFly module (as with any async serial device) is baud rate mismatch. This allows you to put the WiFly module into a known state before working with it.