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.

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.

I recently moved to 4.2 RTM to take advantage of the reduced networking byte-code size which I read about in a forum post on here somewhere. Where does general information about new microframework footprint sizes come from?

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

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

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 haven't done an investigation yet but I had memory issues when calling three lines of StreamWriter.WriteLine(long) to save three numbers to a config file on an SD card. My netduino would report at least 21kB free mem with GC(true) then the three calls to WriteLine(long) would spew out failures to assign blocks of various sizes in the visual studio debug window before crashing from OOM exception. All I changed in the code was calling long.ToString() on all the numbers before parsing the data to the stream writer. I'm using 4.2.

Hi Guys,

As I have exhausted all the Digital Pins for all my pulse counter and communication, now only left with the Analog pins untouched. May I know is there any way I can use the Analog pins for driving a LED (for machine status) purpose? also can it be configure to use to detect button press input?

Thanks in advance.

I have recently used a few of the analog pins for similar reasons as yours. I can confirm you can use them as TTL output pins and almost certainly as TTL inputs.

Just ensure the maximum forward current through each LED doesn't exceed 25mA(maximum pin current).

You haven't made a mistake but have accidentally hooked it up the right way http://www.datasheet...o1rgkyk7ucy.pdf is the datasheet for the IC. If you go to page three you can see the circuit diagram for the output pins and the driver logic. There's two MOSFETs driving the output and they call that a totem-pole driver. With the way you've hooked it up, current flows from the 5V rail, down through the LED and resistor and then into the IC pin. The totem pole has bi-directional current flow capabilities and the current flows into the IC when the bottom MOSFET is switched on. Current flows through the MOSFET and then into GND(ground). The I/O register has an inverter which turns the MOSFET on when it's logic level is zero so that your software logic matches up with the circuit configuration. This is usually how you drive LEDs and 7 segment displays and the ICs are commonly refered to as the "sinks". Of course, you can hook it up so that current flows out of the IC, through the LED -> resistor -> GND by simply changing your circuit configuration. The switching logic levels will be opposite to how you have them already though.

I was about to start prototyping code in my existing product to use SSL for client authentication. Haven't written I line of code yet but I've read through the framework API for supported functionality. http://msdn.microsof...y/hh401316.aspx is where most of what you need can be read. I'm not sure if this component of the .Net Microframework is part of the build for Netduinos.

The basic run-down is that your device can be a client or a server as far as SSL is concerned so technically you can pull off HTTPs. If you're using basic HTTPS then you only need to store one or two certificates. One to certify your netduino as a secure server and possibly another certificate/cert chain that points to a publicly trusted certification authority(CA). If you don't care about the certificate being trusted and you just want secure communications it's pretty simple.

• Generate and store the SSL certificate for your netduino into RAM at run-time via the CertificateStore class. Put the cert on an SD card and read it off each time you boot up
• Use the SSLStream class for reading and writing data instead of a NetworkStream with the client socket.
• Server authentication via the netduino certificate is mandatory but client authentication with a separate certificate is optional. Use the SSLStream.AuthenticateAsClient and AuthenticateAsServer functions.
• Once authenticated, you use the streams like normal HTTP

Hi Nobby,

wonderful... That clears my doubts.
Just for knowledge, how can I configure PIND7 as RTS, do you have the code for it?

Thanks in advance.

Sorry I've never needed CTS or RTS in any application. I'm fairly sure its only modern use is for UART communications which have multiple devices on the shared three-wire interface and have an address they respond to. There are still some ancient RS232 devices out there which require CTS & RTS for end-to-end comms.

From what I have seen with the .Net framework though, you need to specify hardware flow control on the SerialPort object. It supports XOn/XOff and RequestToSend or a hybrid. You do this through the SerialPort.Handshake property at runtime. I believe once you configure your serial port this way, it will configure the RTS and CTS pins to function with the serial port.

Hi Nobby,

Below is my statement.
m_objCommMgr = New cCommManager("COM2", 9600, Ports.Parity.None, 8, Ports.StopBits.One)

so far, I have not connected RTS and CTS since i am only using 3 wire interface. Since on the board layout, for COM2 it comes with RTS and CTS (derived from GPIO pins), I just wonder if we can disable these RTS and CTS when using COM2. Thus giving my project the much needed GPIO to measure the pulse input.

Care to share how do you initialise your COM2 without RTS & CTS?

Thanks in advance.

The general rule-of-thumb with microcontrollers is that pin assignments aren't always restricted to their architectural labelling. For example, a pin maybe labelled as PWM(Pulse Width Modulator) which would normally tie-in with a hardware clock and hardware interrupts. By default, the pin doesn't function as a PWM unless you actually configure it to be.

Much the same with the CTS and RTS pins, you can configure them as OutputPorts or InterruptPorts. If you try to use them for two purposes, you'll get a runtime exception when trying to initialise the pin for a second use. Example of using the RTS pin as a GPIO pin

SerialPort comPort = (SerialPorts.COM2, 9600, Parity.None, 8, StopBits.One); //Initialise COM2
OutputPort oPort = new OutputPort(Pins.GPIO_PIN_D7, false); //initialise the RTS pin as an output port with logic low as initial value;

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?

Hi!

Thanks for help! Finally I found the problem with Nobby's tip. I changed the base resistance from 1k to 6k and it works now in every variations. However I don't understant totally because I think that the relay's inner resistance limits the current to 70mA. So I don't know why is it a problem if the transistor's gain is too high. By the way I use a BC327-40. As I checked the datasheets its gain is above 250.

Now it works, so thank you!

Awesome work!!


250 gain is pretty high for low power circuits and 6k would be a lot better than 47k in your case. When you design in the future, transistor parameters are important. High gain will usually mean a higher forward-bias base current and larger voltage drop from base to emitter which means you'll choose a smaller base resistance etc.


As for the relay, devices like that don't have the capability to regulate/limit current unless they switch off from over-current(built in protection) so it's important to do power calculations for your transistor circuits. The current in simple circuits like this are always determined by the voltage level of your power source (i.e. 5V) and the total resistance/impedance of the circuit path the current is travelling along. If you follow those fundamental rules in design then your systems will function predictably and safely.

As CW2 mentioned, a short could be occuring. Do you have a series resistance on the transistor collector or emitter? Another cause could be your base resistance. 1kOhm is too small. Assuming you don't use an emitter-follower BJT configuration, the base current into your BJT is 3.3V/1kOhm = 3.3mA. This current might seem small but BJTs have a current gain of at least 50 for common BJTs. When your control pin goes high, the BJT will try to draw 165mA from the 5V regulator. When you try to pull too much current from a supply, the voltage of the supply will dip and cause a reset of the Netduino. You should find out what the gain of your transistors are and calculate the base resistance to work well with your relay. For example, you need about 60mA to operate the relay and your BJT has a gain of 100. The base resistance needs to be in the ball-park figure of 55kOhms. Actual(peferred) values you can buy close to that at 56k and 47k. 56k will give you less than 60mA so I'd choose 47k in this case. For saftey, you probably have or should have a series resistor connected to the BJT collector or the emitter. If you drive a BJT hard enough, it's collector-emitter voltage can go down to 0.3V. If you don't have the series resister in there, you can virtually short the 5V rail and cause the Netduino to reset and possibly damage the board. Since your relay runs on 5V, you have to have a small series resistance so that the drop across it when you draw 60mA is small. Secondly, you don't need the anti-parallel diode since it's only for dealing with protection against negative voltages.

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 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.

There's no protocols(in the traditional sense) or encryption with devices like this. They're brutally simple. The three key bits of info there are carrier freq, freq tolerance and modulation type. The modulation type is ASK. Ideally you'd use an ASK demodulator with a center frequency of 319.5MHz(the carrier freq) which will give you the analog envelope as an output. You then process the signal here which could be nasty. The device obviously transmits a serial/unqiue ID number but the PDF indicates that you need to hook it up to an ITI security panel(whatever that is). You'd be hard-pressed getting the information to interpret the signals sent by the device but if you've got a good CRO/scope and a lot of time, you could figure it out.... or just find a generic product if they exist.

another nice trick is the following

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

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.

Have you tried to power the Netduino with a DC power pack? Does the light turn off with a power pack plugged in and no USB?

I hadn't up until you suggested it. I thought I could power it with simply the USB connection. Now that I have added the external power source, the board seems to behaving as expected.

Is there a 'theory of operation' or any documentation around how the systems works together? I seems like the blue led on the board corresponds to the time when the bootloader is available vs when the CLR is running.

Thank you for the suggestion!

According to the Netduino schematic, the USB socket is essentially electrically and logically isolated from the button and LED. My best guess is that you possibly have the Netduino plugged into a standard USB port and there is some sort of power management policy under windows or possibly your BIOS that is cutting power to the Netduino for being idle or some other reason.

Although, I've never come across this problem before except with some models of USB powered hard disc drives. I also connect my Netduino to my PC via a self-powered USB hub and I also have no power management enabled under windows except for turning my screen off after 10 minutes(Performance power profile with hibernation/sleep disabled).

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!!

Technically you can do this. The first problem I thought of that would make me abandon the project would be that setting the alarm time would be a pain in the butt. Changes to the time are always relative to the previous alarm time so unless your netduino knows the previous alarm time, it is impossible to set a new alarm time. Unless of course you reset the power to the clock before the alarm time is set. Unfortunately, you'd have to setup the clock time as well as the alarm time. Secondly, you might have rate and synchronisation issues. For example, you know that if you mash the buttons as fast as you can, the clock will only change the values so quickly. The clock circuitry most likely polls for button presses as well and it's likely that you will occasionally have an adjustment pulse missed and the time you set will be incorrect. These are problems that I came up with before even considering the rediculous amount of electrical interfacing you need to do with the clock. If you're doing it for fun or learning, I reckon it would be great but practically, it would be a nightmare.

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.