- Netduino Forums
- → AxelG's Content
AxelG's Content
There have been 52 items by AxelG (Search limited from 27-April 23)
#29351 DHCP issues with Netduino Plus
Posted by AxelG on 17 May 2012 - 10:06 PM in Beta Firmware and Drivers
#29505 First chance Socket Exception on socket.Accept()
Posted by AxelG on 22 May 2012 - 02:35 AM in Netduino Plus 2 (and Netduino Plus 1)
Sometimes, Socket.Accept will throw an Exception. It's only sometimes, and it's immediately after the program starts.
I do have a busy loop in to wait for an IP to be assigned, but otherwise I can't figure out what going on here. Ideas?
Chris:
The only way I can get Sockets to work is to catch the 10053 exception, sleep for 100ms and immediately try again. Sometimes it works on second or third try; sometimes more. I am not sure you are getting the same error code; can you post the debug?
#33120 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 04 August 2012 - 07:08 PM in Beta Firmware and Drivers
#33161 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 06 August 2012 - 12:30 PM in Beta Firmware and Drivers
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.
#33169 multi threaded webserver
Posted by AxelG on 06 August 2012 - 03:09 PM in Netduino Plus 2 (and Netduino Plus 1)
... 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.
#33180 Camera Modules for any Netduino
Posted by AxelG on 06 August 2012 - 09:38 PM in Netduino Plus 2 (and Netduino Plus 1)
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!
#33219 multi threaded webserver
Posted by AxelG on 07 August 2012 - 01:29 PM in Netduino Plus 2 (and Netduino Plus 1)
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>"; } }
#33347 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 10 August 2012 - 02:28 AM in Beta Firmware and Drivers
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.
#33348 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 10 August 2012 - 02:51 AM in Beta Firmware and Drivers
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!
#33370 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 10 August 2012 - 01:02 PM in Beta Firmware and Drivers
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.
#33377 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 10 August 2012 - 03:54 PM in Beta Firmware and Drivers
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”
- Use XON/XOFF flow control.
- Set no delay in reading the data.
- Set one second delay between sending packages.
- 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?
Attached Files
- Debug 2.txt 4.05KB 1 downloads
- Debug 3.txt 4.05KB 1 downloads
- Projects.zip 110.49KB 3 downloads
#33378 Debugging Assemblies loaded via Reflection
Posted by AxelG on 10 August 2012 - 04:17 PM in General Discussion
#33383 Debugging Assemblies loaded via Reflection
Posted by AxelG on 10 August 2012 - 06:24 PM in General Discussion
Yes, one project is what you have today (Production) and one new one (debug) that just references the library as a standard .dllYou have 2 projects and the ND startup is 'referencing' your library?
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.
Nothing different. I am sure you are doing this now. I just load the assembly and call the starting method.What exactly are you doing here differently in your calling startup assembly?
#33402 Camera Modules for any Netduino
Posted by AxelG on 11 August 2012 - 05:35 AM in Netduino Plus 2 (and Netduino Plus 1)
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.I have NGO and no SD card yet
#33447 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 11 August 2012 - 03:54 PM in Beta Firmware and Drivers
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.
I will try that.If that's the scenario, does the same thing happen when you connect two serial ports together on one Netduino?
Cool. I will try that as well.
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.
#33454 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 11 August 2012 - 08:43 PM in Beta Firmware and Drivers
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.
#33874 Announcing: .NET MF 4.2 upgrade for all Netduino hardware
Posted by AxelG on 18 August 2012 - 04:55 PM in General Discussion
#33881 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 18 August 2012 - 10:43 PM in Beta Firmware and Drivers
#33882 Diagnosing slow deployment with VMware using WinUSB
Posted by AxelG on 18 August 2012 - 11:20 PM in General Discussion
#33883 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 18 August 2012 - 11:24 PM in Beta Firmware and Drivers
#33885 Diagnosing slow deployment with VMware using WinUSB
Posted by AxelG on 19 August 2012 - 04:28 AM in General Discussion
#33919 Love for Chris Walker
Posted by AxelG on 19 August 2012 - 09:29 PM in General Discussion
#33957 Several stupid questions
Posted by AxelG on 20 August 2012 - 05:03 PM in Netduino 2 (and Netduino 1)
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.
#34567 Netduino Firmware v4.2.0 RC5 (Netduino + Netduino Plus)
Posted by AxelG on 02 September 2012 - 04:28 PM in Beta Firmware and Drivers
#42715 4X20 LCD display with I2C Interface
Posted by AxelG on 04 January 2013 - 02:58 PM in Project Showcase
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 Thoolens (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)
Attached Files
- LiquidCrystal_I2C.cs 14.96KB 600 downloads
- Netduino Forums
- → AxelG's Content
- Privacy Policy