Hey guys, I'm having random issues with my PC rebooting after pressing the reset button on the Netduino(Both regular and Plus versions). I usually pin these kinds of things on the USB 5V rail being shorted(high current) to ground from faulty devices and sometimes from plugging USB devices in and out of chassis USB ports(crappy ones). I've looked at the system schematic and can see that the switch is fairly isolated from VBUS. The issues occurs maybe once every 20 resets or so. Haven't had a chance to probe the board yet. Anyone else have any insights to the problem?

Good day everyone.

Any plans to have ParameterizedThreadStart available in the MF?


Thanks

You can use lambda expressions in conjunction with the standard ThreadStart class. It allows you to have type-safe targets as well.

class MyClass
{
     Thread myThread = null;

     public MyClass()
     {
         this.myThread = new Thread(() => MyClass.threadFunc(this));
         this.myThread.Start();
     }

     private static void threadFunc(MyClass myClassObject)
     {
            //do stuff here
     }
}

Target delegate doesn't have to be static either

I'm currently looking into factors affecting the accuracy of Netduino timing. Precision isn't a massive factor, tenths of a second is fine. I've tried two approaches for timing -Using a timer interrupt with constant frequency/Thread.Sleep and then making timing variable adjustments -Implementing Chris Walker's System::Diagnostics::StopWatch and using ElapsedMilliseconds The first approach is the easiest but overhead causes loss in accuracy. The second approach would have the higher accuracy but has a dependency on the framework runtime overhead. System::TimeSpan::TicksPerMillisecond is also fixed at 10,000 instead of being device specific. At the moment, I'm curious as to what factors cause the runtime DateTime clock to slip. I have an application with various medium performance threads running, one being a timing thread. Over a space of 15mins, the timer has fallen more than 10 seconds behind my sports watch and a synchronised timer on a PC application I have running. The Netduino is not being debugged, has release build code deployed to the target board and is broadcasting its time through UART to be observed. Considering the crystal freq of the Netduino Plus, I'm unsure as to the massive accuracy/overhead issues with timing here. I'm currently using the 4.2 framework and firmware associated with that framework.

Hi Nobby,

Is the elapsed time from timers/Stopwatch not matching the increase in DateTime.Now?

Losing 10 seconds in 15 minutes is a lot (~1.1%).

Can you post a quick code snippet showing how you're calculating and writing out the time? We should be able to run it on our Netduinos to reproduce...

Finally...just curious: if you reflash the mainboard with Netduino firmware (instead of Netduino Plus) do you get the same results?

Chris

Hey Chris,

Due to the nature of my project, I can't share code but I have created a new project which is dedicated to the task of timing using Ticks.

The project has three threads. The main program thread, aka Main(), sits in a for(; loop with a Thread.Sleep(500) call. It does this after it initialises a class that manages the time measurements.

The second thread is fed a time object and reduces its time until it reaches zero or less. The thread is executed with default priority through a lambda expression.

 private static void timerFunc(Clock clock)
        {
            if (clock == null) return;

            long startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
            long endTicks, delta;
            while (clock.time > 0)
            {
                endTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
                delta = (endTicks - startTicks) / m_tick; //where m_tick is System.TimeStamp.TicksPerMillisecond

                clock.time -= delta;

                startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
                Thread.Sleep(50);
            }            
        }

The third thread is one that runs in the clock class. It sleeps for 100ms and then uses COM1 to write, in ASCII text, the value of the time of the format "mm:ss.f".

I just started a 15min test against my sports wristwatch and PC application. 10mins into the test, clock.time is eight seconds higher than the timer on my watch.

I haven't tried flashing my Netduino Plus with the Netduino firmware. I have a regular Netduino to use and a handfull of Netduino Plus devices I can downgrade if necessary.

Currently, I'm stuck with the newest firmware for my commercial project. Purely because of the Socket runtime code footprint providing a much needed 10K.

Thanks for having a look at this

Another observation I have made recently in the Netduino plus was similar to this issue. It was before I had upgraded the firmware so it was still running 2.1.xxxxx and .Net Framework 4.1. I had a TTL VGA board and I was displaying the value of DateTime.Now on a screen directly from the Netduino through COM1. On startup, the Netduino would perform a one-time synchronisation of Date & Time from my PC with the help of an application I had wrote to communicate with the Netduino. It had millisecond percision. After about 5 minutes or so, I noticed that DateTime.Now had lagged behind my PC by a few seconds. After leaving it there idle for nearly a day, it was a long way behind. Initially I beleived the discrepency to be with flucutations of time data when my PC was synchronising with my Domain Controller time server until I disabled time synchronisation on my PC and had the same result as well as using my stopwatch as a reference. I'm about to try this project on a standard Netduino running 2.1.xxxx

Hey Nobby,

Thank you for the additional information. Let's boil it down a bit more, to isolate any potential code or threading issues...

Can you please try creating an app which simply does the following:

• Create and open an instance of the SerialPort class
• In a loop: write the current time to the serial port and then sleep 500ms

And then share that code along with your results? If that basic case is losing 1+ seconds per minute...or if it's not...then we'll have a good basis for diagnostics.

Thank you, Nobby.

Chris

Getting onto that right now.

I setup and experiment that follows the guidelines you provided. I created a simple PC app to track any time slip over an elapsed time. Each experiment itteration was roughly 4 mins long. Attached are images showing the differences between different timing strategies.

-mainThread.png shows your experiment rules. Over four mins, there is no clock drift between PC and Netduino DateTime.Now

-threadedMachineTime.png shows the same experiment except data transmission is done every 100ms on one thread and the current machine time is stored in clock.time on another thread every 50ms. There is no drift apart from 100ms synchronisation conflicts between threads every now and then which go back to zero anyway.

-stopwatch.png System.Diagnostics.StopWatch approach shows a drift of about 200ms every two minutes. Clock.time is incremented by stop_ticks - start_ticks after a thread.sleep(50). The itterative code is shown below. It should essentially always match the netduino machine time. There is only 1 line of code overhead separating

for(;;)
{                
                endTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
                delta = endTicks - startTicks;
                startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;

                clock.time += delta;  
                //clock.time = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks; //this was used in the second experiment
                Thread.Sleep(50);
}   

-internalDrift.png shows how clock.time drifts away from the Netduino system time. The netduino experiment code was modified to only transmit the drift between Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks and clock.time(shown in the Current Column for Netduino). The results show that the Netduino clock doesn't drift compared to the PC clock rather clock.time is drifting behind the Netduino clock. As you can see from the code above though, there's nothing to it. Certainly no reason for such a rediculous lack of accuracy. Even if I changed the code so that start_ticks = end_ticks after calculating delta, it doesn't make much of a difference. I did notice that if I reduce or increase the sleep time from 50 down to 25 or up to 100, the accuracy of timing was affected but minimally.

What can you tell me about operations and overhead with large datatypes such as System.Long? Could it be significant?

I will restructure this experiment to perform stopwatch-based approach in the main thread and see what results I get.

I've nailed the culprit on this one but no explaination as to the adverse result obtained. Take the code snipet below:

            long startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks, endTicks=0, delta=0;                        
            int sleepTime = 50, choice=1;
            
            clock.start = startTicks;

            for(;;)
            {
                if (choice == 0)
                {
                    Thread.Sleep(sleepTime); //Sleep to regulate timing intervals. 50ms here.

                    endTicks = Utility.GetMachineTime().Ticks; //Get the current Netduino time
                    delta = endTicks - startTicks; //Calculate the time difference
                    startTicks = endTicks; //Assume significant overhead from the previous line of code

                    clock.time += delta; //Increment instance member time value
                }
                else if (choice == 1)
                {
                    Thread.Sleep(sleepTime);

                    endTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
                    delta = endTicks - startTicks;
                    startTicks = Utility.GetMachineTime().Ticks; //Assume no overhead from the previous line of code and this line as well

                    clock.time += delta;
                }
                else if (choice == 2)
                {
                    //Choices 2 & 3 just involve a different order of operations but have the same logic as 1 & 2
                    endTicks = Utility.GetMachineTime().Ticks;
                    delta = endTicks - startTicks;                    
                    startTicks = endTicks; //Assume overhead from the previous line of code

                    clock.time += delta;

                    Thread.Sleep(sleepTime);
                }
                else if (choice == 3)
                {
                    endTicks = Utility.GetMachineTime().Ticks;
                    delta = endTicks - startTicks;
                    startTicks = Utility.GetMachineTime().Ticks; //Assume no overhead from last and this line of code

                    clock.time += delta;

                    Thread.Sleep(sleepTime);
                }
            }

I performed some optimisations on my original timing code which was not optimised at the time. There was still drift. The results were fairly conclussive though. Choices 0 & 2 provided identical and ideal results. There was no slip between clock.time, the Netduino time and the PC time.

Choices 1 & 3 resulted in the slip of 100ms every 30seconds. The only difference in code was using startTicks = Utility.GetMachineTime().Ticks vs startTicks = endTicks. The previous line of code, delta = endTick - startTicks and the alternative code in choices 1 & 3 were resulting in what appears to be significant overhead. Based on the results and a loop interval of roughly 50ms, it works out to be roughly 166us of slip per itteration.

Not being a huge fanatic of investigating the inner workings of the micro framework, I'm just going to accept that I can't be lazy in design with respect to these things. Failing longer duration tests for choices 0 & 2, There's no evidence of any chronic issue with timing accuracy.

Hi,

Just wondering if anyone can recommend an RFID reader that is compatible with the Netduino. I need one that can read from at least 30cm.

Can anyone help?

Thanks

I've used the Texas Instruments RFID readers in the past with AVR based projects. Unfortunately, there's no way you're going to get 30cm read range out of most units. Purely because the most available and popular units are High Frequency RFIDs(used in keycard access etc).

All the long range options are the low frequency devices(cattle tags, anti-theft etc). I can't remember off-hand what those are but the high freq devices operate at 6MHz and the low frequency devices are in the hundreds of kHz.

Either way you go, all communications are TTL/RS232 with a possible USB option.

The final observation I made with time slip came down to precision rather than accuracy. Initially my timing precision was in milliseconds. Naturally I elected to just utilise TimeSpan.Ticks/TicksPerMillisecond. The major issue with cumulative timing measurements here is a significant degree of time slip due to rounding-down. The slip increases as the sampling frequency increases. An example of slip due to measurement error was about 100ms every four mins for a interval measurement frequency of 20Hz. I still only require millisecond precision but now use 100 nanosecond precision for higher frequency timing intervals.

TCP sockets consist of remote and local endpoints by design so naturally you'd assume the state of the connection is managed by TCP but it isn't. The only way to determine the current state of the socket is: -Enforce an activity timeout -Attempt to read from the socket -Attempt to write to the socket In the first case, simply enforce a timeout of a desired interval. If no communications occur within a certain time-frame, forcefully terminate the socket. In the second case, the operation will block indefinitely if no deterministic data stream exists(i.e. client isn't required to send data regularly). If you set a read timeout on the socket, it will throw an exception but this is a false-positive in terms of detecting a client disconnecting. The best method is to write to the socket. This is commonly refered to as Keep-Alive. If the client has closed their socket at the remote endpoint, a socket exception will be thrown at the local endpoint and you can remove the client. Send a single byte or an appropriate byte pattern to the client. They can either absorb the data or make an appropriate response if required. The problem with this approach is that the client is required at at least monitor for this incoming Keep-Alive data. End-to-End data transfer with TCP is fully-interlocked. Even if you perform a write operation on a socket asynchronously, the data backs up in the server's memory(in the netduino RAM in this case) until the client reads all pending data. This is dangerous to server stability. If you are creating an HTTP server, the HTTP specification covers the aspect of Keep-Alive and the client notifies the server through GET/POST methods whether or not they would like the connection to remain open. Even then, this is usually in the order of minutes. HTTP is typically not used for persistent connections though except in the case of data streaming. Good luck

I use the DFRobot GPS shield based on the UBlox GPS unit but interfacing is the same. The first change you'll want to make is how you read the data. The GPS unit will constantly send NMEA and UBX packets to you. It could also send packets of other GPS protocols. With UBX in particular, the packets start with a deterministic pattern.

Sometimes the data can contain characters which are non punctuation, letters, numbers etc because certain bytes are acutally bit-fields of configuration and satelite data. String constructors might return NULL based on these non-alpha numeric characters. Instead, make a string, use a for/foreach loop and append each byte onto the string but cast it as a char.

change this

Debug.Print(new string(Encoding.UTF8.GetChars(buffer)));

to this

string dataString = "";
foreach(byte b in buffer) dataString+=(char)b;
Debug.Print(dataString);

Good luck

The most notable contrast between Netduino and Arduino is that the Netduino's arcitecture is based around the Microsoft .Net Microframework where as Arduino's are programmed with machine-code(C code interpreted then compiled) targetted at the cpu instruction set of the Arduino. Essentially the Netduino and Arduino are the same connectivity-wise, they just have different development platforms. The biggest issue you are having with LCD stuff usually stems from bandwidth limitations of the bus technology you use to communicate with the LCD. For example -I2C/TWI is limited to 100kHz -SPI is somewhat similar -7/11 Pin interfaces to LCD controllers. These are usually text LCDs though -UART/TTL/RS232 have good bandwidth but devices are rare Most LCDs are SPI or I2C/TWI. For large numbers of pixels, clearing a screen, pixel-by-pixel, is slowed down by the bandwidth of your interface. That's why most devices have a single instruction for clearing a screen with an optional colour. If you need to do large rectangle fills etc, it's painfull. You could look at the Gameduino which is designed for doing complex/detailed video operations on a severely band-limited interface. It only has a VGA output on it though and it's pretty much useless for anything but making video games. I tried to use one for displaying a GUI but the API is too high level to do simple things outside the scope of sprite rendering. Another option to consider is the emergence of many colour LCD controllers. They're intermediate devices that have larger bandiwdth but consume quite a few pins on the AVR. With the way these consumer development platforms are diversifying these days, you have so many options. Unfortunately, unless you have experience with the devices and their APIs, it takes a very long time to find what you want through research without having to spend money. In your case, I could heavily recommend the Netduino plus for your LCD, SD card and other needs. The only problem is you might find .Net framework/C# development a pain in the arse compared to AVR studio, Codevision AVR or some other ANSI C compiler and IDE.

Not sure if this is an issue or not but I'm looking at trying to get around a certain type of behaviour with the NIC. -If I boot/power up the device with the netduino connected to a switch/router everything is fine -If I boot/power up the device with the netduino initially unplugged, I run into issues. -Currently using static IP Plugging the device into a network after startup negotiates fine with the hardware. I cannot ping the netduino at its IP address though. I can ping it if I hit the reset button or re-power the netduino My software binds a listener which constantly throws socket exceptions when calling Socket.Accept() while it is disconnected(as expected). When the exception occurs, I close the listener, rebind the socket(using IPAddress.Any) and retry to called Socket.Accept(). When I plug the netdunio into a switch, the socket rebinds and stops throwing socket exceptions from calls to Accept(). I still can't ping the Netduino or make a TCP connection to the device unless I reboot/re-power the netduino with the network cable plugged into a switch. I've tried various things such as reseting the static IP settings once the netduino is plugged into a switch, before and after binding the listener to 0.0.0.0:portNum. Anyone else had similar behaviour?

another nice trick is the following

string fileLine = "";
while((line=sr.ReadLine())!=null)
{
     Debug.Print(fileLine);
}
sr.Close();

Hey crawf, I'm about to head to bed so I'll read this thread tomorrow. Judging by your code, the methodology is fine. I use I2C comms with a GPS unit and i've tried various approaches to see how flexible the API is. The main points you need to know: -When you perform a write operation, .Net will ALWAYS provide the device address in the transaction, you don't have to add this to the byte[](not that you are but just so you know) -When you perform any transaction, if zero actions are returned from Execute(), this means that communication to the device failed completely. This has nothing to do with register addresses -.Net handles all ACK & NACK signalling(comms interlocking). The number of ACKS & NACKS returned by the slave device determines the return value of Execute(). -You can't simply read a single byte in a transaction. The data you read from a target register needs a destination array large enough to fit it. If you don't know the size required, give one sufficiently large enough. The remaining bytes in the array are set to zero(or a value defined in the device documentation).

Having a look at that LCD, it is indeed a parallel interface and requires a butt-load of pins. It does afford the ability to drive the display faster than TWI/SPI. There are available devices called LCD Backpacks. They're designed to connect to parallel LCDs like this and you can interface with the backpack via UART/TWI/SPI depending on the archtecture of the backpack. The other option you have is something like Codevision AVR. I starting using this about ten years ago as it was probably the best prototyping IDE around at the time(productivity-wise). They have lots of advanced LCD libraries now and broad support for various LCD models. The code generation engine can create a base-code project for you to get started quickly with your LCD. You can designate the ports you want to use on the AVR either for direct connection or connection via a backpack. They even have an IDE for creating bitmaps, controls and icons to embed in your projects. Even though I still use Codevision AVR for various small things, I've moved all prototyping for commercial products to Netduino products. It's cheaper for me to buy netduino and spend a fraction of the time developing. You might want to check out the Netduino Go as well. They designed it with the purpose of exposing more connectivity and memory than the Netduino Plus. Once they have developed the RJ-45 module I'll most likely move to that platform.

Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks has 100ns precision(0.1us) but the accuracy is skewed by +- a few hundred microseconds due to the runtime overhead. If you need to measure an interval less than one millisecond, you end up with an error of about 20% but this error is negligable for slightly larger intervals. The 100ns precision is definitely usefull for cumulative timing functionality. Are you using the timer as a measurement interrupt?

I saw this issue with an attached debugger in this thread http://forums.netdui...tartup-problem/ .

There's two ways you can do this. -As linked by Hanzibal, you can use lambda expressions to parse the Servo objects to a function as a parameter when creating the thread. -Create a class which encapsulates the Servo objects as members. You can create regular threads for each servo and address the servo objects as this.servo1 and this.servo2. Your example code executes within a static function so it's not possible to use servo objects initialised in that function unless they are parsed to another static function or class method as parameters. Using option two makes it easier to manage your objects and use them across threads.

I finally found some time to create analysis tools to investigate NIC behaviour. The initial results were fairly conclusive.

---Netduino Software---

A threaded socket listener accepting TCP connection requests. It's a non-blocking approach utilising Socket.Poll to check for pending connection requests before calling Socket.Accept. Detection of NIC being up or down is monitored using the WinSock socket exception code 10050. Once the network status is up, I tried two methods that involve either retaining the existing listening socket object or recreating the listening socket.

• Netduino is using static IP and gateway (192.168.1.95, 255.255.255.0, 192.168.1.1)
• Experiment involved starting a debugger on the netduino with the network cable plugged in or unplugged
• A separate thread does a Debug.Print of the current IP address and default gateway of the Netduino every three seconds

---PC Software---

A simple app which allows you to enter an ip address and port number. A "Connect" button which attempts to create a TCP connection to the remote host at the defined address and port. A "Ping" button which broadcasts an IMCP echo request to the defined address. All connection and ping results displayed in a listBox.

---Results---

Starting the debugger with the network cable initially plugged in produces positive results. The device is pingable and TCP connections can be made. Unplugging the device from the network results in WinSock 10050 exceptions on Socket.Poll as expected. Plugging the Netduino back into the network and recreating the listener socket resumes desirable behaviour. The device is pingable and TCP connections can be made.

Starting the debugger with the network cable initially unplugged is where it all goes wrong. The frequently displayed IP address of the Netduino is correct. After any length of time, the netduino is plugged in, all related link/activity etc lights come on. WinSock 10050 errors cease to occur when calling Socket.Poll as expected. However, the device is unpingable and TCP connections cannot be made to 192.168.1.95. No amount of time changes the conditions of connectivity without restarting the device.

Is anybody familiar with the inner workings of the .Net Microframework runtime startup in the Netduino and how NICs are affected by it? Fortunately, the only vulnerability of the product I'm developing is that it must be plugged in and active at both ends of the network cable before the product is powered up. I would like that to not be a requirement.

This thread http://forums.netdui...?showtopic=3420 alerted me that sometimes the Netduino needs to be rebooted. Is there any other functionality that isn't as brutal as a reboot?

I'm now using Socket.Poll to detect the initial NIC connection state and rebooting the device upon the NIC status changing to up, if it was originally down. I can't exactly do this if the product is in the middle of being used.

I have a project which utilises both UARTs and I also have RTS0 & CTS0 configured as either interupt ports or output ports with no issues. Can you please post your initialisation code for COM2?

If you mean you would like to create projects which are code libraries you would like to use in other projects, that's pretty easy.

• Add a new project to solution
• Choose "Class Library" instead of "Netduino Plus Application" under Visual C# -> Micro Framework. This what you mean by DLL?
• Write the code in your class library
• Go to your Netduino Plus application project, choose to add a reference
• In the projects tab, choose your new class library as the reference
• You can now use your class library in the Netduino Plus application!!

Your file creation and streamwriter code looks fine. The code will throw an exception though if

• The file test.txt already exists on the SD card
• The name of the root directory isn't \SD\

It may seem long-winded but I always query

VolumeInfo[] drives = VolumeInfo.GetVolumes();

It serves to ensure there is an SD card inserted(there are also other ways to check this). The objects also indicate the name of the root directory.

I haven't looked up the reference to Directory.GetCurrentDirectory for Micro Framework. It's standard usage is to return the current working directory which only applies to application domains running normal .Net Framework applications on a PC etc. Since the Netduino executes code from Flash rather than a virtualised application domain run from media, it doesn't use working directories.

The most common options are UART(RS232 or RS485 from the PC to the netduino) or TCP/UDP network stream/packets. The second option requires either a Netduino Plus or a Netduino with an Ethernet Shield. You can also use I2C(TWI) and SPI but you need to build interfaces at both ends. I'm not even sure you can get something like USB->TWI or USB->SPI(apart from microcontroller programmers) that you can put at the PC to send data to the Netduino. As far as I know, you can't utilise the USB socket for runtime applications but I could be wrong about that. For the 7-Seg display side of things, the serial drivers are usually the best option. They require minimal GPIO pins from the netduino compared to other options. You need to make sure the current capacity of the drivers exceeds the rating of the 7-seg displays as well otherwise they'll heat up and die fairly quickly