I updated my code to call the reset() method every time I need to clear the LCD, and that has worked all day today with 1,000+ screen updates an no garbage.  Seems like bruit-force approach but is seems to be working for now.

 

I also posed the driver code if anyone is interested.

Thanks for the quick replies.

 

I wrote a reset() method in the driver, and I have attached it to the onboard switch.  Hitting the switch resets the screen.  Seems like there should be a better way...

 

Maybe I will remove the i2c interface and go to a native HD4478 8 bit driver...

My holiday present to myself this year was the following 4X20 LCD: (link)

 

It is based on the HD4478 LCD driver chip, front ended with an I2C interface, popular because it only uses two ports on your MCU.

 

The information provided by the vendor is sparse, and in some cases incorrect.  The address of the device is listed as 0X27 but is actually 0x3F.  I was able to locate the Arduino (C++) driver for the I2C interfaced version, so I translated the Arduino driver into C#.

 

I then integrated Stefan Thoolen�s (http://www.netmftoolbox.com/) MultiI2C class to drive the I2C port.

 

After playing with the timing on the initialization a bit, it seems to be working well.  I added some text management methods to the driver to simplify displaying text on four lines.  The LCD is set up in such a way that it is actually driving two 40 character lines of text, wrapped on the screen.  This made it confusing for me to keep straight, so these new methods made it easier to keep track of the text.

 

Hardware connection is a snap.  Netduino (running 4.2) connected with 5v, ground, A4, and A5 to the LCD module.  This LCD is using an I2C interface, so you need pullups on the A5 and A4 wires.  I used 2.2k (corrected to 1.8k below) resistors on the 3V3 port.  Worked great.

 

One nagging issue is that after running for some time, the screen will start displaying garbled data.  I have not been able to pinpoint the reason; maybe bus speed, bad data wires, poor power?  If I figure that out, I will post an update.***

 

Thanks to everyone on the forum for inspiration and ideas to get this working; especially Stefan for a great toolbox.  Let me know what bugs you find or ideas on improvements.

 

***UPDATE: The garbage issue is resolved: I think.

Problem was that my pullup resistors were too high of a value (changed for 1k8.  I remembered my analog circuit class I took 30 years ago and realized these resistors are part of a RC circuit that affect the signal shape on the wire.  To high = smaller slope.  There was also a small bug in the code that was not sending the initialization bytes correctly (I will upload the working copy.  I also moved some of the text management methods out of this class into a separate display class)

Any idea on what I should try next? I hit a wall with the serial port problems in this 4.2 build and really can't move forward until they are working.

zajda:

Welcome. You can find a good review of bread boarding here:Bread Board They will also cover your question about LEDs. The wires used for bread boards will work nicely to connect to your Netduino.

Good luck and have fun.

Hear, Hear...

The BSOD is in the VM. My host is fine. The Service reads "WinUsb" and the Hardware ID is "USB\VID_22B1&PID_1001&REV_0100"

Chris: I just confirmed that the same serial port issue exists in the latest 4.2 build (posted three days ago) If I use any flow control, I lose data. If I don't use flow control, I have to make sure to read data fast enough.... This happens with one ND, COM1 to COM2 or two netduinos connected with null-modem cable.

I use Windows 7 Ultimate hosted on a local VM through VMWare Player as my dev environment and had the same issue until I re-flashed my Netduino BIOS. There was an issue with the earlier version of SAM-BA 2.11 that had a problem with slow deployments that may be related to this. Using the new 2.12 version of SAM-BA and flashing the latest 4.2 firmware solved the problem for me. (I do, however, still get BSOD if I hit the reset button on the ND during deployment)

Arbiter: When I do that, all works well. I am trying to abstract the hardware later from the rest of my code. I need to know what pin was used later because I share interrupts and what to know which pin caused the interrupt.

Great News! I was able up update my ND/ND+ and everything went really well! Easy.... Thanks for the updates!

Chris:
Thanks for the feedback. Here is how I spent my morning.

I used one ND with COM1 hooked to COM2 and got exactly the same results. All works fine as long as I can read the data fast enough. If not, there are very unpredictable results including crashing the ND. If I use any type of handshake; all bets are off and data is lost. I will eagerly await the RC6 build and re-test.

(I have not ported this back to 4.1 to see what happens there, that would require reflashing my NDs. and I am basically lazy that way! )


Here is another very peculiar thing related to serial ports. I posted about this in an earlier thread concerning 'System.InvalidOperationException' in the 'System.IO.Ports.SerialPort.HandlePinReservations' call. I am wondering if my 4.2 implementation is FUBAR? Here is the scenario:

Running a simple test application:

using System.IO.Ports;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;


namespace NetduinoApplication2
{
    public class Program
    {
        public class netduino
        {
            //Changing from const to static causes the sp.Open() method to throw a 'System.InvalidOperationException' Exception
            public const Cpu.Pin SomePin = Pins.GPIO_PIN_A4;
            //public static Cpu.Pin SomePin = Pins.GPIO_PIN_A4;
            public InterruptPort SomeInterrupt = new InterruptPort(SomePin, true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);
        }

        protected static netduino MCU = new netduino();

        public static void Main()
        {
            SerialPort sp = new SerialPort("COM2", 9600, Parity.None, 8, StopBits.One);
            sp.Open();
            Debug.Print("finished OK!");
        }
    }
}

Notice the definition for SomePin. If I define SomePin as static, the debug trace looks like this on the sp.Open() call:

Step into: Stepping over non-user code 'System.IO.Ports.SerialPort.Open'
Step into: Stepping over non-user code 'System.IO.Ports.SerialPort.Open'
Step into: Stepping over non-user code 'System.IO.Ports.SerialPort.HandlePinReservations'
Step into: Stepping over non-user code 'Microsoft.SPOT.Hardware.HardwareProvider.HwProvider.get'
Step into: Stepping over non-user code 'System.IO.Ports.SerialPort.HandlePinReservations'
Step into: Stepping over non-user code 'System.IO.Ports.SerialPort.HandlePinReservations'
A first chance exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.dll
Step into: Stepping over non-user code 'System.IO.Ports.SerialPort.HandlePinReservations'
A first chance exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.SerialPort.dll
An unhandled exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.SerialPort.dll

If I define as a const, all is good and no exception.

Not to make this even more confusing, but when I run the debugger and step through the code, when I get to the call for 'HandlePinReservations' I get a dialog box asking me to locate the following file:
C:\Documents\Secret Labs\Projects\Production\SecretLabs.NETMF.Hardware.Netduino\NetduinoHardwareProvider.cs (See attachment SourceScreen.jpg)

Any ideas on what is going on and where I might go next? The loss of data part is really the troubling part. I need to have an effective handshake so I can read and process larger chunks of data.

Hi AxelG,

Just to confirm... You're connecting two Netduinos together and are using flow control...and are losing data?

Yes, that is the scenario. Using no flow control works well as long as I can read data fast enough. I am going to play with various baud rates and see what changes.

If that's the scenario, does the same thing happen when you connect two serial ports together on one Netduino?

I will try that.

P.S. RC6 should be shipping in a few days. There is a serial port bugfix that recently made it into the NETMF core...so we may want to hold off digging in for a few days and see if the bugfix is related.

Cool. I will try that as well.

I have NGO and no SD card yet

Maybe you could update the driver to send data out a serial port to some receiving system as it is read from the camera. You could get fancy and maybe perform a post to a waiting web server; assuming you have an Ethernet or wifi shield.

You have 2 projects and the ND startup is 'referencing' your library?

Yes, one project is what you have today (Production) and one new one (debug) that just references the library as a standard .dll

Your deployment grabs the library project and loads it to the flash chip? How are you referencing the library at this point? Standard reference or reflection?

Standard reference, just like any other .dll you include. Yes, at deploy time the .dll will be sent to the flash at the same time as your exe because it is just another .dll.

(At the risk of confusing the issue: an alternative approach might be..)
To make it easier to code, another alternative is to add a "library" subdirectory in this new (call it debug) project and add your library source as links into this subdirectory. That way the compiler knows to recompile the changed "library" code along with your program on any changes at build time. This way you are not dealing with two projects (one to build the dll and one to build your debug program) The downside is that you have to manage "who is calling who" to make sure you don't break your dll by referencing something that will become out of scope in your production build.

What exactly are you doing here differently in your calling startup assembly?

Nothing different. I am sure you are doing this now. I just load the assembly and call the starting method.

I may not understand the question, but I have done this in the past to help debug: I create a simple program that includes the .dll as a library. I then flash this to the ND as a single program (no loading assemblies from sd) I do all of my debugging there as normal. When I am ready to deploy in Production, I just deploy the obj/Release/le/*.pe (Associated to my .dll) to SD and load my "bootloader" program through regular deployment. There is about 3k to 4k of overhead for doing it this way (including a .dll with your main program) until you load your final assembly. Maybe?

Testing scenario for Serial Ports in 4.2 RC5

Scenario:

• Hooked up a ND to ND+ on COM2 (TX to RX)
• ND was sender, ND+ was reader
• ND had no flow control, ND+ was set to Handshake.RequestToSend
• Logic Analyzer was hooked to RX, TX and RTS/CTS pins on ND+
• Wrote two applications, Reader and Sender (Projects.zip)
• Sender running on ND sends 200 byte packages to reader running on ND+
• Reader reads the 200 byte blocks and reports on whether it got all of the data.

Outcome:

• Handshake.RequestToSend seems to have no affect on the hardware.
• Sending the data slowly enough for the reader to stay caught up with the writer works fine.
• When the reader goes off to do something else (simulated by a Thread.Sleep()) the SerialPort.Read() method throws “System.ArgumentException” (Debug 2.txt)
• If the writer sends data to the buffer (SerialPort.Write() method) too fast, the “SerialErrorReceivedEventHandler” handler fires with “SerialError.TXFull”

One Solution Idea:

• Use XON/XOFF flow control.
• Set no delay in reading the data.
• Set one second delay between sending packages.

Outcome:

• Lost data. Reading the packages as fast as possible shows lost data (Debug 3.txt) This happens even when sending data in 200 byte packages with a delay between packages.
• Turning off flow control, fixes the problem at slow speeds, until you set a read delay which causes data loss.

Any ideas on how I can send large blocks of data without losing bytes?

Hi AxelG,

From the logic analyzer...can you tell where the data is being lost? Is it being lost on the Netduino (i.e. buffer overflow)?

Chris

If you look at the data in Data.jpg, that is the data coming from the XBee into the ND, and all of the bytes are in that stream. I can only assume the data is getting lost after it enters the Netduino. I am working on a Netduino to Netduino set of applications to reproduce. So far I am able to force the same exception I was seeing in the 4.1 release:

"A first chance exception of type 'System.ArgumentException' occurred in Microsoft.SPOT.Hardware.SerialPort.dll
Exception: Exception was thrown: System.ArgumentException param name stack System.IO.Ports.SerialPort::Read
NDPlusSerialReader.Program+DoReader::Serial_DataReceived
System.IO.Ports.SerialPort::DataEventHandler"

I will post more later today.

Unusual behavior with Serial Ports in 4.2 RC5 on ND and ND+ (Losing data…)

I have a project that requires two XBee/ZigBee modems to communicate and transfer large (for Zigbee) data packets from 1k to about 100k in size.

My plan is to use SD cards to buffer data as it come in and goes out the modems, stitching the packets together as they come in. Simple enough….

I am using the Grommet (Copyright © 2009 http://grommet.codeplex.com) drivers for the low-level networking, which I really like because they started out very light-weight and I made them lighter by removing some methods I will not need.

The project is too large to post the entire code base in this thread, but I plan to post later on as an extension of these drivers.

Here is my trouble: I am losing data after the receiving XBee passes it to the ND/ND+ and when it is read out of the serial buffer. Attached is the Logic trace showing data leaving XBee #1, and being passed from XBee #2 into the ND. The data loss happens at different places at different times. If I slow the transmissions way down (one message every two seconds) I get nearly zero lost bytes. As soon as I remove this delay; lost data.

Here is the setup:

• ND with XBee1 and SD shield on SPI
• ND+ with XBee2 and SD card installed
• Both ND/ND+ share common XBee drivers codebase (All XBee and serial port code is shared)
• I have tried hardware flow control on both ND/ND+ and is enabled on XBee.
• (As a footnote, CTS never de-asserts on either XBee, it always remains low, and never goes low on ND)
• I have SerialErrorReceivedEventHandler enabled, and it never fires.
• Everything is running at 9600 baud, 8N1. (I want to try faster speeds to see if that makes a difference, but CTS flow control should handle buffering data for me?)

Attached is a far-away view of the data in the LA. The left side is showing the modem setup exchange, and the right side is showing the data packets: you can see the packeting leaving one XBee and arriving at the other… These are two messages with 200 byte packages.

Also attaching a zoomed in view to compare with what I am reading out of the Serial Port buffer.

Here is the code that is reading the buffer. Fairly simple. Called by the SerialDataReceivedEventHandler event:

private void Serial_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {

            //One at a time please....
            lock (readLock)
            {
                Debug.Print("Read unlocked with " + SerialPort.BytesToRead + " bytes to read");

                //FIXIT - May not need, but for some reason the event fires with nothing to read....
                int timeout = 100;
                while (SerialPort.BytesToRead <= 0 && timeout-- > 0) Thread.Sleep(10);

                byte[] buf = new byte[1];
                if (SerialPort.BytesToRead > 0)
                {
                    try
                    {
                        while (SerialPort.BytesToRead > 0)
                        {
                                
			   //If there is data, there is a incomplete frame, and we have a complete header
                            while ((SerialPort.BytesToRead > 0) && 
                                  (!frameBuilder.IsComplete) && 
                                  (frameBuilder.HeaderIsComplete)))
                            {
			       //Don’t forget about the checksum byte…  The + 1
                                byte[] buffer = new byte[frameBuilder.dataNeeded + 1];
                                //reading the data frame and the checksum byte
                                int bytesRead = SerialPort.Read(buffer, 0, frameBuilder.dataNeeded + 1);
                                Debug.Print("Read chunk of " + bytesRead.ToString() + " f: " + buffer[0].ToString() + " l: " + buffer[bytesRead-1].ToString() + " need " + (frameBuilder.dataNeeded + 1).ToString());
                                //Add the newly read data to the framBuilder buffer
                                frameBuilder.Append(buffer, bytesRead);
                            }
                            if (frameBuilder.IsComplete)
                            {
                                // got a frame, do something
                                ReceivedApiFrame(frameBuilder.GetApiFrame());
                                // Create a thread, launch fire event, etc
                                frameBuilder.Reset();
                            }
			    //Check to see is a header needs to be read (first three bytes)
                            if ((!frameBuilder.HeaderIsComplete) && (SerialPort.BytesToRead > 0))
                            {
                                SerialPort.Read(buf, 0, 1);
                                Debug.Print("Read byte for header " + buf[0].ToString());
                                frameBuilder.Append(buf, 1);
                            }
                            //Don't beat a hasty retreat after reading the frame…
                            timeout = 100;
                            while (SerialPort.BytesToRead <= 0 && timeout-- > 0) Thread.Sleep(10);
                        }
                    }
                    catch (Exception ex)
                    {
                        Debug.Print("Error reading data from serial " + ex.Message);
                    }
                }
                else Debug.Print("Nothing to read");//FIXIT – Get rid of this if() in production, ignore

                Debug.Print("Ending read " + local.ToString());
            }
        }

Here is the relevant Debug file to try and convince myself I am not going nuts... The data is really not there...

Read byte for header 126 <- good
Read byte for header 0 <- good
Read byte for header 212 <- good
Allocated 212 bytes to API Frame <- reading 200 bytes plus Zigbee frame
Read chunk of 16 f: 144 l: 52 need 213 <- extra room for checksum byte
Read chunk of 16 f: 34 l: 109 need 197
Read chunk of 15 f: 101 l: 109 need 181
Read chunk of 14 f: 32 l: 50 need 166
Read chunk of 15 f: 48 l: 87 need 152
Read chunk of 15 f: 97 l: 100 need 137
Read chunk of 14 f: 60 l: 48 need 122
Read chunk of 15 f: 54 l: 48 need 108
Read chunk of 15 f: 58 l: 99 need 93
Read chunk of 14 f: 114 l: 100 need 78
Read chunk of 15 f: 97 l: 49 need 64
Read chunk of 14 f: 32 l: 97 need 49
Read chunk of 15 f: 114 l: 105 need 35
Read chunk of 17 f: 99 l: 100 need 20
Read chunk of 3 f: 97 l: 110 need 3 <- finished, without checksum error!
Resetting frame
Staring processing thread… <- thread off to process the packet
(Here is where it goes horribly wrong….)
Read byte for header 126 <- good, found header start byte
Read byte for header 162 <- BAD! This is NOT a valid high-byte length
Error in length: 162
Resetting frame
Read byte for header 0
ERROR!!! Expected start byte: 0
Read byte for header 64
ERROR!!! Expected start byte: 64
Read byte for header 141
ERROR!!! Expected start byte: 141
Read byte for header 28
ERROR!!! Expected start byte: 28
Read byte for header 195
ERROR!!! Expected start byte: 195
…

The serial buffer contained the following bytes: (Refer to the attached LA image)
126(~), 162, 0, 64(@), 141, 28, 195…
But the XBee sent the following to the ND:
126(~), 0, 212, 144, 0, 19, 162, 0, 64(@), 141, 28, 195…
MISSING BYTES

Any ideas are welcome. I need to get some sleep!

HI AxelG,


Can you post a small repro app for us to look at? Generally speaking, NETMF 4.1 code should run as-is under NETMF 4.2.

Chris

I wound up flashing my ND+ to 4.2 anyway and noticed a couple things:
1) My USB is a lot more stable - no more BSODs (I also removed a bluetooth driver that may have been causing problems)
2) The extra code space is nice! Thanks.
3) I am seeing strange behavior with the Serial Port - losing data. (Posting a separate thread)
4) The COM2 problem went away (ArgumentOutOfRange no longer happens when opening the COM port.

I've attached the project. Any help much appreciated.

My ND+ is in use, so I could not run this code. Reading it, I suspect this {below} part of the code might be causing your trouble. From what I can gather in reading the source, this code gets called once to start flashing, and then again to stop flashing. That will create two threads for blinky: once when it gets the "on" command, and then creates a new thread when it gets the "off" command. I suspect that the "off" command does kill the thread started by the "off" command, but the "on" command thread is still running. If you look at the debugger output, you can see when the threads terminate to verify; compare that to when new threads start.

Look for something like the following: "The thread '<No Name>' (0x14) has exited with code 0 (0x0)." in your debug output.

One way to deal with this is to use managed threads and then you can tell which threads are running. {great way to learn about thread pools!} An alternative is to store the state of blinky in a static variable in main() so you can do two things: 1) make sure two "on" commands are not called without first calling an "off", 2) verify blinky is running before you try and kill it. (This will also require that blinkyobject be declared as static in main() as well so you can kill in one thread what was started in another)

[Disclaimer: There will be various opinions as to the best solution; I am just suggesting a couple that come to mind at the moment ]

Happy blinking! I hope this blurb helps get this solved for you.

               case "flashled":
                    {
                        
                        bool state = (e.Command.Arguments[0].Equals("on") ? true : false);
                        {
                            blinky blinkyobject = new blinky();
                            Thread blinkythread = new Thread(blinkyobject.blinkygo);

                            if (state == true)
                            {
                                Debug.Print("blinky start");
                                blinkythread.Start();
                                e.ReturnString = "<html><body>You called FlashLed with argument: " + e.Command.Arguments[0].ToString() + "</body></hmtl>";

                            }
                            if (state == false)
                            {
                                //Debug.Print("blinky stop");
                                blinkyobject.RequestStop();
                                Thread.Sleep(500);
                                blinkythread.Join();
                                Debug.Print("main thread: Worker thread has terminated.");
                                e.ReturnString = "<html><body>You called FlashLed with argument: " + e.Command.Arguments[0].ToString() + "</body></hmtl>";
                            }
                        }

Ok! Thank

I can confirm that these drivers work very well. Easy to use and bug free (so far ) I trimmed them up a bit as I did not need all of the features written in the driver. Took me about a hour to get everything hooked up and running.

You must also have a ND with a SD card to use the drivers. That means either a ND+ or ND flashed to 4.2 and a SD shield of some kind. If you use the latter, you will have to add the mount and unmount commands to the driver.

Hope you enjoy; I know I did!

... So I did. But when I run blinkythread.abort

it throws an exception. Maybe I'm going about it all the wrong way. What I'm hoping to achieve is to be able to send a get

request through a browser like http://ipaddress/setbath/36 .

Hi Grant:
Maybe instead of just aborting the thread you could signal the Blinky thread to shutdown more gracefully. One way is to set up a simple event and trigger that event from your main code. This way the Blinky thread will close and perform any cleanup. You could put a timeout waiting for that thread to end before forcing the abort. Also, make sure the thread is still alive before calling the abort.

This tutorial may be helpful: Events
And this one on threading: Threading

Both of these helped me understand .NET threads and events.

HI AxelG,


Can you post a small repro app for us to look at? Generally speaking, NETMF 4.1 code should run as-is under NETMF 4.2.

Chris

I will try to later this week, but this is part of a larger program and I will need to create a smaller app to reproduce. Basically, I am defining the port, then assigning some interrupts and event handlers, and then opening the port - which is where I get this failure; but only on COM2. COM1 works fine...

I was also dealing with BSODs yesterday and just decided to update all my NDs to 4.2. That helped a lot; but still getting them on reboots.

I finally got around to upgrading to 4.2 to enable the SD card on my ND. Worked great. Took a bit of "translation" for the pinouts as it seems that nobody calls SPI pins the same thing. After getting that to function, I updated my code to 2.4 libraries, recompiled and now I am throwing the following error when opening up COM2: A first chance exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.dll A first chance exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.SerialPort.dll An unhandled exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.SerialPort.dll I change to COM1; everything is fine. I tried forcing Handshaking to be none (I am not using pins 7 or 8 for anything else, nor am I using pins 2 or 3 for anything else) Any ideas where I should look next? Runs fine on my ND+ under 4.1 (I am sure it is something obvious)