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?

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

This is a similar thread to the one I posted earlier about free memory. This time I'm looking at writing thread-based diagnostics. Due to the Process class not being relevant for .Net MF, is there a way of getting a list or a count of threads that are in any possible state within the application domain or "process"? Secondly, if I have a stray, unreferenced thread floating around, does the GC gobble it up if it's in a non-idle state or when IsAlive is true?

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.

Does the call to s.Send() block indefinitely or does an exception get thrown? It's odd that the router permits the outbound socket connection but not the underlying data. I'm 50/50 about Tenda. I've bought quite a few different products of theirs. I use a 16 port gigabit switch at home but I've bought wireless gear as well in the past and thrown it in the bin out of frustration.

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

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

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.

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.

The first thing to change on the PC end is your calls to Socket.Recieve(). Since you aren't specifying how much data to read on each call, it will try to read enough data to fill the array and will block until it does unless

• You close the socket
• Have a ReadTimeout value set on the socket

Either way, an exception will be thrown on the PC application. Make the buffer smaller to match the length of the data or provide an amount to read. In your case, the PC application will try to read 1000 bytes all-up.

On the Netduino side of things, I never simply use Socket.Send(). I always tell it was data range to use from the array so that I know I have full control over safe execution. This doesn't mean that the Netduino exception is being caused by this.

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.

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.

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

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?

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

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.

You're going to find that most wireless comms use a burst approach for data transfer. The hardware protocol will usually try to send a data burst of a minimum to maximum size and at deterministic intervals. This is because free-space(air) is an indeterministic transmission medium which causes time varying scew in the carrier and data(phase distortion) and all sorts of other nasties. It places a constraint on the continuous length of time you can transmit data before the probability of data error becomes too high. So essentially synchronised, continuous data streams between wireless devices is impossible without substantial overhead. There is also a fair amount of overhead for sending/receiving data in general, especially with multiple devices which places a constraint on optimal minimal packet size as well as burst interval. Having said all of this, it's still quite possible to achieve a ping of under 5ms. I have a wireless bridge in one of my outdoor systems which is line-of-sight and spans 400m with a ping of no more than 1ms. -It runs at 5GHz instead of the 2.45GHz band -The devices don't use a proprietary protocol -They have adjustable high-gain antennae and high base power level -Can operate at up to 75km appart Those are the kind of extents you have to go to in order to meet requirements. You're going to have to dodge 2.45GHz devices unless you know your operating environment is going to be well shielded from other terrestrial noise. If you live in america, they're laws permit 2-3 times the maximum broadcast power of 2.45GHz transmitters than a lot of other countries so your signal-to-noise ratio(SNR) can suffer a lot more increasing overall latency. Once you've got a decent wireless architecture then you can start looking at .Net runtime overheads etc etc.

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.

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