Nevermind, I figured out that I can just use the NetduinoPlus.Pins struct.

I'm putting together a simple class to handle multiple port interrupts through a single event handler. .Net microframework says that data1 can be the port number. I setup an experiement to evaluate data1 with two different buttons. I used D6 & D10(PWM1 & PWM3). PWM3 came up as data1=54 and PWM1 came up as data1=52. Comparing those to the Netduino schematic, the difference in the two numbers matches the difference in pin numbers(diff of 2) but the numbers don't match the schematic pinout. PWM3 is 67 and PWM1 is 65. Regardless of whether this is an error or not, I still need to build a relationship table. I would like to know if these are going to change in the future though for whatever reason. Is there an error in the designation of pin numbers/labelling on the ARM7 netduino schematic?

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?

Hi Nobby,


There appears to be a bugfix in lwIP to correct this type of issue. .NET MF 4.3 is getting an lwIP upgrade, so we're hoping to have a fix for this soon. [lwIP is a big complicated project and 10,000s of boards rely on it working properly...so introducing the update in beta firmware should help it get some good in-field testing.]

Chris

Thanks for the information Chris

I'm also having ethernet issues with the latest firmware. Although, I can't confirm if the issue exists with older versions. I discovered that the ethernet interface never works at all if a network connection doesn't exist on boot. I made a thread here: http://forums.netdui...h__1#entry32165 Nobody has shared any discussion on the matter. I'm using static IP in this case and absense of network connectivity is fine as long as it occurs after boot/powerup.

I don't seem to be able to find the 30cm go!cable's for sale anywhere. Does anyone have a source? I need the length for the location of the touch screen in this project.

You can make these kinds of things really easily. They require no soldering and you only need tools to do it if you want to make it easy for yourself. The Netduino Go uses standard 10-way header sockets(5x2 pin array) that have locator notches. The items you need to make cables are:

• 10-way plugs (one per end if required)
• Ribbon cable (grey or multi coloured are fine)
• Clamping tool (less than $10 and reduces chance of mistakes)

You can get all of these from electronics hobby shops and electronics parts retailers/suppliers. The 10-way plugs usually come packaged individually with three parts to them. The larger part has sharp contacts that pierce the ribbon cable wires when you clamp it. The other two pieces clip into the main piece. One is smaller than the other. The smaller one is used to clamp the ribbon into the sharp contacts. Line the ribbon up with the contacts and push down hard with the second piece(using the clamping tool makes this really easy). Once clamped, fold the ribbon back over the plug and use the final piece to brace the ribbon. It prevents tugging from ripping the ribbon out of the plug.

The ribbon cable can be bought in lengths you require. If you can't get ribbon with 10 wires in it, just buy anything larger than that. I personally have a massive roll of 16-way that I use for everything and strip off what I don't need for a particular cable. Sometimes you can buy bundles from electronics hobby shops which have breadboard wires and ribbon cable in them with other junk if they don't sell ribbon cable.

Not sure what country you live in but I've never seen these cables pre-made purely because they're not used in consumer electronics for external purposes. I have read that packs of 10-way cables for the Netduino will be sold soon within the USA for people who aren't hardware savey. Not sure what the status on that is.

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

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?

sorry, the topic is not going to be that interesting.

I've got my NP hooked up to a serial camera and i want to take a pic and then push it on a webserver.

By the looks of it im getting a outofmemory exception. Is there any efficient way of do this with out using lots of memory?

Is the camera data compressed into JPEG or is it full-frame RGB/YUV pixel data? Either way, image resolution of most cameras these days will exceed the runtime RAM of the Netduino. To test the full functionality of your project(i.e. take pic, get data from camera, post to webserver), try and set the camera to its lowest resolution if possible.

If you don't have those kind of configuration options for your camera, you'll have to go the whole-hog from the beggining. Adopt a block-data processing model. Take the picture and read small amounts of data from the camera at a time. You'll have to send or store(SD card) that data then leave it for the GC to pick up or force the GC to free the memory. Read the next block of data, rinse and repeat.

Are you using a POST method to a web URL? If so, you can define the Content-Length HTTP header property before you stream the data to the webserver(only if you know the datasize of the image before-hand). This will allow you to block process the data, as long as you don't exceed the webserver's timeout. If you can't determine the size of the pic data before you read it from the camera, stream it to a file on an SD card in the Netduino and then read the file-size.

Good luck

Thank you Mario for your response.

I know that the framework slows things down..But most of teh time the developper is the problem!

But I know that on a PC, the differences is sometimes hard to see..
The conversion time of an ADC can be less than 5 Microseconds..
A simple loop with simple calculation run very fast.
It is the call to the ADC which goes wrong.
Usually, it is possible to start conversion, than to read the result later.
With NetDuino, it seems that we have to start and wait conversion..
Even though, response time is very long...

What I want to to is to store data from 1khz ->10khz signal into memory, and dump it from a PC.
It works fine for 100hz signal..


I will work on it...

If you configure the ADC to operate in free-running mode, the contents of the ADC register is constantly changing for you at the maximum rate the ADC will operate at. This kinda eliminates conversion times from a hardware interrupt. There are two probelms with a free-running ADC.

If you strobe multiple pins you run into parallel operation errors. I haven't checked the SAM7 architecture but most AVRs only have 1 ADC but have 5+ pins you can strobe off. When you change the ADC strobing register to select another pin, it might be impossible to determine which pin the ADC data register contents belongs to if you read it immediately or shortly after. Some AVRs don't allow free-running with strobing.

The other issue you have is when you read a sample from the ADC register in free-running mode, you don't know how "old" the data is. When you take two readings, there will always be a degree of skew in your measurement windows which increases with a slower ADC sampling rate.

Those two issues aside, it's also a tall-order to measure a time interval less than 1ms accurately.

Hello Alex,

Sound a typical field instrumentation problem.

Use a 250ohms in parallel to 4-20mA signal. Remember V=IR .... V=(4/1000)(250) = 1V...do similar
operation for 20mA and you get 5VDC...right in the acceptable voltage range of the Analog inputs...

Hope helps.

You can't measure the current of a circuit using a parallel impedence, that's only appropriate for voltage measurements(scale conversion). Parallel impedence splits the current through branched paths and it also alters the characteristics of the circuit in a large way(unless the impedence is essentially infinite, 250ohms is very low).

The current transducer circuit has to run in series and have a negligable impedence.

Hi Guys,

Separately, do you have any sample circuit to connect to N+ for measuring 4-20mA Analog input?
Together with sample code will be great. Currently I am using VB.net to handle the 12V pulse input through opto-coupler circuit.

Thanks in advance.

I don't think you can measure current with a microcontroller. You need to transduce the current to a voltage.

The most accurate method is getting a transducer which uses electromagnetic coupling. It's also the most expensive method.

The easiest method is to use a really small series resistance (1-5 ohms, whatever you can get your hands on) with the circuit you are measuring current. Measure the voltage across the resistance and divide that by the series resistance in your netduino code. The result has errors obviously. Adding resistance to the circuit changes the current. You might also get non-negligable current flow into the analog pin even if it has a high impedence characteristic during analog sampling.

The other consideration you need to be aware of is that 4-20mA is a rather small current to transduce. Mostly because ADC(Analog to Digital Conversion) usually has a precision relative to the operating voltage of the microcontroller(AVR/Netduino) and the value of AREF(usually set to zero volts or Vcc/2). A current that small will produce a voltage so small it will appear as zero after ADC. You'll need to amplify the transduced current signal significantly, especially if you are working in a narrow measurement range (4-20mA).

You can make a simple voltage amplifier with two resistors and an op-amp package.

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

The program is stored in non-volatile Flash memory(EEPROM). I haven't looked the modern longevity but you can expect roughly fifty years of reliable program storage in the device under desirable environmental conditions. Static electricity causing a wipe is a lot less likely with today's microcontrollers but still possible. It's more likely physical damage would occur before program erasure. The only controlled method of non-software executed erasure is from connecting a positive voltage(3.3V+) to the little gold square on the board. This configures the board for firmware operations until you repower the device. I'm not sure if this actually erases the program Flash though.

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;

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

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.

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

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?

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.

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 saw this issue with an attached debugger in this thread http://forums.netdui...tartup-problem/ .

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?

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.