Netduino home hardware projects downloads community

Jump to content

The Netduino forums have been replaced by new forums at This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

ericcox's Content

There have been 19 items by ericcox (Search limited from 02-March 20)

By content type

See this member's

Sort by                Order  

#44079 Netduino Plus 2 Firmware v4.2.2

Posted by ericcox on 24 January 2013 - 02:35 AM in Netduino Plus 2 (and Netduino Plus 1)

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? :lol:

#43995 Com2 on the plus 2

Posted by ericcox on 23 January 2013 - 04:44 AM in Netduino Plus 2 (and Netduino Plus 1)

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.

#43965 Multithreading and writing to SD card

Posted by ericcox on 22 January 2013 - 07:27 PM in Netduino Plus 2 (and Netduino Plus 1)

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  :D )

#43916 Multithreading and writing to SD card

Posted by ericcox on 22 January 2013 - 08:14 AM in Netduino Plus 2 (and Netduino Plus 1)

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,


#43694 WiFly Shield code

Posted by ericcox on 18 January 2013 - 09:13 PM in Netduino 2 (and Netduino 1)

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.

#43625 WiFly FTP

Posted by ericcox on 17 January 2013 - 10:49 PM in Netduino Plus 2 (and Netduino Plus 1)

According to the WiFly User Manual, the WiFly module supports FTP out of the box.  Is that not the case?


Looks like you basically set up an ftp connection using the "set ftp *" commands, and then wait for a connection. They probably use PASV transfers so they only need one connection.


I'm going to be needing this functionality for my project so I had planned on adding support for it to the WiFlyGSX class at some point.  If I'm wrong and it doesn't support it, I'm really screwed...









#43619 WiFly with Netduino Plus 2

Posted by ericcox on 17 January 2013 - 09:31 PM in Netduino Plus 2 (and Netduino Plus 1)

If you're willing to share the code, maybe we can help to find out what happens...


Hi Marcus,


I was able to find the problem, and have posted the first Alpha release here:


Let me know if you have any problems with it.



#43618 WiFly Shield code

Posted by ericcox on 17 January 2013 - 09:28 PM in Netduino 2 (and Netduino 1)

Hi all, WARNING: ALPHA CODE AHEAD! For those using the Wifly Shield from Sparkfun, here is a patch against rev 21420 of the netmf toolbox that adds direct support for the WiFly Shield with it's SC16IS750 SPI-To-Uart bridge.  The idea was to utilize the WiFlyGSX class as much as possible and separate the SC16IS750 code from it, so it could be useful in other configurations.  I wanted to make sure that we didn't have two separate WiFlyGSX classes out there - one with SC16IS750 support and one for use with a standard Uart - that we'd continually have to keep in sync. There are four main classes and an interface: WiFlyGSX The original, slightly modified to use ISerialPort, and adds a couple of functions that I needed for my project.    Spi2UartBridge Controls the SC16IS750 SPI-to-Uart bridge chip.  Implements ISerialPort, so should be transparent to the WiFlyGSX code.  It's interrupt driven - no polling - and supports the few GPIO pins on the SC16IS750.  I had some code in here that allowed you to use an in-memory buffer to improve performance, but had to yank it out to simplify debugging when I ran into a data transfer problem.  Assuming that code wasn't the cause of the problem, I'll probably add it back in later. Please note that I've only implemented the members of ISerialPort in Spi2UartBridge that I needed to use the WiFlyGSX code due to time constraints.  That's the reason I'm posting this in patch form rather than giving it to Stephan for inclusion in the Toolbox at this time - it's not a problem if you're just using the WiFly Shield, because WiFlyGSX only uses the implemented SerialPort members.  But someone implementing another SerialPort-using class may need all the members of SerialPort. In other words, this class is not really useful as a generic transparent replacement SerialPort - but that is the goal.  Time-permitting I'll implement all of the ones appropriate for the SC16IS750 on the SerialPortEx class.   WiFlyShield Encapulates the two classes above, and houses functions that require *both* the SC16IS750 and the WlyFly: resetting the WiFly, and resetting to factory defaults, via hardware pins.  Will probably add a method to control the Force Awake pin later. SerialPortEx Virtualizes the SerialPort/Spi2UartBridge by wrapping a real SerialPort and implementing ISerialPort members.  Should be simple/stable enough for developers to use as a target rather than a real SerialPort, so their code could be used with a SerialPort-lookalike in the future.


Basic use:

1. Create an SPI port

2. Create a Spi2UartBridge and pass it the SPI port

3. Create a WiFlyShield and pass it the Spi2UartBridge

4. Reference WiFlyShield.WiFlyGsx to access the WifFlyModule


namespace WiFlyTest{	public class Program	{		public static void Main()		{			var configuration = new SPI.Configuration(Pins.GPIO_PIN_D10, false, 0, 0, false, true, 4000, SPI.SPI_module.SPI1);			var spi = new SPI(configuration); 			using (var bridge = new Spi2UartBridge(spi, Pins.GPIO_PIN_D7))			{				bridge.DebugMode = true;				bridge.TestPin = 2;				bridge.BaudRate = 9600;				var shield = new WiFlyShield(bridge, debugMode: true);								shield.ResetToFactoryViaHardware(); 				shield.WiFlyGsx.SetAntenna(Antenna.Internal);				shield.WiFlyGsx.EnableDHCP();				shield.WiFlyGsx.JoinNetwork("testw", Authentication: WiFlyGSX.AuthMode.WPA2_PSK, Key: "<key>"); 				while (shield.WiFlyGsx.LocalIP == "")				{					Thread.Sleep(1000);				} 				Debug.Print("Success!");			}		}	} }


Disclaimer: This code is, of course, posted with no guarantees of any kind.  If it works for you, great!  If not, send me a detailed description of what's going on and I'll try to fix it.  (If you have the time to debug and send a patch, that would be great)  Please note that if you change any of the register-manipulation code for the SC16IS750, you're on your own  :P  

Oh, also - this was developed on a Netuino Plus.  Not sure if their are any changes necessary for the NP2.  But the NP2 is my eventual target, so if you can wait, the code will be modified as appropriate in a future release (another reason it's not quite ready to be in the Toolbox).

Attached Files

#43557 WiFly with Netduino Plus 2

Posted by ericcox on 16 January 2013 - 09:44 PM in Netduino Plus 2 (and Netduino Plus 1)

Did you had any luck to get the Wifly module to work on your Netduino Plus 2 yet?

Hi Tenback,


I have had some success. I'm currently grappling with some sort of flow control/interrupt problem so it isn't ready yet.  Basically, it either works perfectly, or fails waiting for a response to a command.  :( Still trying to figure out what the cause those two results is.


At least the proof-of-concept is complete, so I know that if I can get this problem worked out, it should be useful for my project.

#43403 WiFly with Netduino Plus 2

Posted by ericcox on 14 January 2013 - 06:32 PM in Netduino Plus 2 (and Netduino Plus 1)

Never mind, I found a way to do it - it's a bit messy but compiles and should work.

#43399 WiFly with Netduino Plus 2

Posted by ericcox on 14 January 2013 - 05:47 PM in Netduino Plus 2 (and Netduino Plus 1)

When setting up the toolbox I actually considered to make interfaces for the serial port, so you're doing a great job :D


Unfortunately, I didn't think this through very well. There is no way for me to make SerialPort class implement my interface.  Which means that I can't create a common interface for the SPI Serial port class and the original SerialPort class.


Any ideas?

#43394 WiFly with Netduino Plus 2

Posted by ericcox on 14 January 2013 - 05:08 PM in Netduino Plus 2 (and Netduino Plus 1)

Hi Stefan,


Things rarely go according to plan.  :lol:


Apparently, the Microsoft NETMF team didn't want anyone to subclass the SerialPort class, and the SerialDataReceivedEventHandler and SerialErrorReceivedEventHandler classes both have internal constructors.  I wish the MS team hadn't made those choices.  So unfortunately I'm having to re-write part of the WiFlyGSX class to use a SerialPort-like interface, ISerialPort.


Thankfully only about 6 SerialPort members are used in the WiFlyGSX code, so it won't be too bad. If someone wants to come along and implement the rest of the ISerialPort methods/properties later, to make it a fully-functional SerialPort implementation, they're more than welcome.


I'll send a patch against rev 21420 of the toolbox code when I'm done. I'm hoping to have it functional today, and then get the code cleaned up and "presentable" afterward.


#43204 .NET MF 4.3 RTM ... Where's the new SDK?

Posted by ericcox on 12 January 2013 - 04:38 AM in Beta Firmware and Drivers

You could also install the 4.3 SDK which includes 4.2 and 4.1 assemblies, without need for VS2010 :)

Heh - yeah I realized that about 5 minutes after I wrote it.  Tried to delete my post, so as not to lead anyone down the wrong path but I couldn't figure out how to do that...

#43203 WiFly with Netduino Plus 2

Posted by ericcox on 12 January 2013 - 04:36 AM in Netduino Plus 2 (and Netduino Plus 1)

Hi mav29x,


I'm also using the WRL-09954 shield.  If you're using this driver, and unless I'm completely mistaken, it won't work directly with a Wifly shield.  It's designed to work with a WiFly module connected directly to a SerialPort.  But the WiFly shield does not connect the WiFly directly to a serial port, it connects it through a SC16IS750 SPI-to-Uart bridge. 


Today I started working on a driver class for the SC16IS750 that I'm hoping will perform all of the bridge-setup code, and return a descendent of SerialPort that you can pass into the Toolbox driver. (The Toolbox driver will require a small modification - a new constructor - but I think it should work)


I'll post here when I've got something to show - right now it just contains code to define all the registers and read and write them (didn't know what SPI was until today :lol:)


#43115 .NET MF 4.3 RTM ... Where's the new SDK?

Posted by ericcox on 10 January 2013 - 04:23 PM in Beta Firmware and Drivers

Thanks for the confirmation, guys - turns out another problem was causing my inability to use vs2012 with 4.2.  It's working for me.


Note: in order to setup a new dev environment, you need to install vs2010 - at least temporarily - because the installer for the .Net Micro Framework SDK 4.2 requires it. Bleh.   Thanks alot Microsoft!

#42937 Wifi timeout

Posted by ericcox on 07 January 2013 - 09:54 PM in Netduino Plus 2 (and Netduino Plus 1)

Hi Donovan,


1. According to http://www.sparkfun..../rn-131-ds.pdf, the WiFly module has a reset pin, have you tried pulling that low to reset it?

2. In sendHTTP_Request(), it looks like there's a loop for sending the request, but the socket is being closed within that loop.  So if for any reason IsConnected is still true for a few milliseconds after the call to Close(), it will attempt to send the request again on a closed socket.  I'd move that Close() outside the loop.



My advice:

Simplify your sendHTTP_Request() method so it only manages the lifetime of the Socket, using a try/finally to clean up after any exceptions.  Then manage all of your exception/retry logic in a calling method, so it will be easier to see.  Managing logic that is shared across two or more methods will make it confusing.  Since an http request requires a socket to function, the method responsible for sending the request should create/destroy the socket.  (Personally I would build the request in there as well, but that's just me)


So it would be something like:


	    private static string strSocketHostname;	    private static WiFlyGSX WifiModule;	    private const decimal moduleResets = 10;	    private const decimal SocketRetries = 3;	    private const decimal ModuleRetries = 5;	    private static void updateDatabase(string tsData)	    {		    bool requestSent = false;		    for (int moduleResetCount = 0; moduleResetCount < moduleResets && !requestSent; moduleResetCount++)		    {			    try			    {				    for (int moduleRetryCount = 0; moduleRetryCount < ModuleRetries && !requestSent; moduleRetryCount++)				    {					    try					    {						    for (int socketRetryCount = 0;								 socketRetryCount < SocketRetries && !requestSent;								 socketRetryCount++)						    {							    try							    {								    sendHTTP_Request(tsData, WifiModule);								    requestSent = true;							    }							    catch (Exception e)							    {								    // Log the error								    throw;							    }						    }					    }					    catch (Exception)					    {						    WifiModule.Dispose();						    connectToWifi();					    }				    }			    }			    finally			    {				    WifiModule.Dispose();				    ResetWiFlyModule();				    connectToWifi();			    }		    }	    }	    private static void sendHTTP_Request(String tsData, WiFlyGSX WifiModule)	    {		    String request = "GET /default.aspx?" + tsData + " HTTP/1.1rn";		    request += "Host: " + strSocketHostname + "rn";		    request += "Connection: Closern";		    request += "rn";		    WiFlySocket socket = null;		    try		    {			    socket = new WiFlySocket(strSocketHostname, 80, WifiModule);			    socket.Connect();			    socket.Send(request);		    }		    finally		    {			    socket.Close();		    }	    }

So essentially, if at any time the requestSent flag is set to true, we're done. I haven't tried this code, you may have to tweak it to get it to work.


#41252 .NET MF 4.3 RTM ... Where's the new SDK?

Posted by ericcox on 09 December 2012 - 06:59 AM in Beta Firmware and Drivers

Bump. I use VS2012 at work every day - it's killin' me to use VS2010 when I get home :(

#37881 Out of Memory - Debug.GC(true) says I'm not?!

Posted by ericcox on 23 October 2012 - 07:36 PM in Netduino Plus 2 (and Netduino Plus 1)

If you post some code and the actual error message you might get better insight into the problem. I would note that some .Net out-of-resource exceptions give the impression of an out-of-memory state, when in fact it's socket/filesystem handles, or some more obscure resource.

#37461 Running out of memory

Posted by ericcox on 20 October 2012 - 08:17 AM in Netduino Plus 2 (and Netduino Plus 1)

Hi Patrick,

I don't know that this is the problem, but in your original post, I noticed this line:

stOut = new StreamWriter(req.GetRequestStream());

This line allocates a Stream object, and then wraps that into a StreamWriter. The StreamWriter is being disposed, but it's possible, since the Stream is not being explicitly closed and disposed, that something is holding a reference to the underlying Stream.

You could try managing object lifetime with using() statements:

using ( Stream responseStream = req.GetRequestStream() )
    using ( stOut = new StreamWriter(responseStream ) ) 

Using is the equivalent of try {...} finally { <dispose object> }. So even if an exception is thrown, the object will be disposed, and the exception re-thrown.
It also makes it easier to see when objects are created/destroyed.

Hope that helps...

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.