Netduino home hardware projects downloads community

Jump to content

The Netduino forums have been replaced by new forums at This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.


Member Since 14 Jul 2011
Offline Last Active Feb 05 2014 05:37 PM

Topics I've Started

Task Parallel Library support

29 January 2014 - 02:59 PM

Anyone know if there are any plans to support the Task Parallel Library in NETMF? I ask because I think this could be a tremendous productivity boost with hardware programming, because hardware programming very naturally lends itself to the Task Asynchronous Pattern that's implemented by the Task Parallel Library.

Using the TLC5940 on .NETMF 4.2

25 January 2014 - 11:04 PM

I have been scouring the deepest reaches of the internet for about a week trying to find a working example for using the TLC5940 16-channel PWM driver chip for dimming LED strips, but without any luck. Most of the examples are either incomplete (missing the wiring diagram) or just don't work. Here's a few examples that I couldn't get to work: 


1. http://forums.netdui...c/4123-tlc5940/

2. http://forums.netdui...940-pwm-driver/


All of these are old, so I'm fairly certain they target .NETMF 4.1. The first one didn't work (http://forums.netdui...c/4123-tlc5940/) because it uses PWM.SetPulse from .NETMF 4.1 which I tried to convert the code to 4.2, but it's still not working.


Here is my request: Can someone help me out with a program that simply fades an LED from 0 to full brightness and back to 0, and then repeats, using the TLC5940? 


Once I can get a single LED to PWM using the TLC5940, the rest of the work is already done and I have the high-power drivers for the LED strips already built. Thanks for the help.

PWM.SetPulse equivalent in .NETMF 4.2

25 January 2014 - 10:25 PM

Is there a standard way of upgrading the PWM.SetPulse method from .NETMF4.1 to the newer "channel-based" PWM in .NETMF 4.2? I'm trying to port the following code:

public Tlc5940New(PWM gsclk, PWM blank, OutputPort xlat, OutputPort sin, OutputPort sclk)        {            GSCLKPin = gsclk;            BLANKPin = blank;            XLATpin = xlat;            SINPin = sin;            SCLKPin = sclk;            // Clear the channels, and disable the output            GSCLKPin.DutyCycle = 0;            BLANKPin.DutyCycle = 0;            XLATpin.Write(false);            SINPin.Write(false);            SCLKPin.Write(false);            GSCLKPin.SetPulse(gsclk_period, 1);            BLANKPin.SetPulse((gsclk_period * 4096), 1);                }

The error is happening on the lines GSCLKPin.SetPulse(gsclk_period, 1); and BLANKPin.SetPulse((gsclk_period * 4096), 1); because SetPulse is not supported by the new 4.2 libraries so I have to come up with equivalent code. I took this code from somewhere else so I do not know how exactly I should use the 4.2 PWM in place of this 4.1 code.


Any help is greatly appreciated.

Proper way to multithread on Netduino

08 July 2013 - 05:40 AM

I have seen a few ways to do multithreading, and after reading a few posts on here I'm still unsure of what is the "correct" way to do multithreading. Specifically, I'm concerned with threads that will be monitoring inputs by constantly reading them and updating some output (like a brightness meter). 


Way 1 is to have a thread and have a while (true) loop in there with a Thread.Sleep(1) and the polling code. I have noticed that if I don't put a Thread.Sleep(1) in there, the debugger stops responding and there's no way to get Visual Studio to attach to the debugger without erasing the current program. (My guess is that the main CLR thread doesn't get enough time to both interrupt VS while it's waiting for the CLR debugger and receive the attach message from VS. But if we put Thread.Sleep(1) in the polling thread, the main CLR thread would get a lot more time to run while the polling thread is sleeping and is able to interrupt VS and also receive the attach message (or debugging symbols).)


Way 2 is from http://forums.netdui...ring-whileloop/. One of the responses was as follows:



[color=rgb(164,164,164);font-family:helvetica, arial, sans-serif;]Posted [/color]21 February 2013 - 09:18 AM

Hi Ties,

The way that threads work in NETMF is that each thread gets up to ~10ms to execute before the thread scheduler pulls the execution to another thread. In order to make sure that interrupts are fired in sequence, NETMF queues and timestamps them...and then fires them off in order.

In multi-threaded and interrupt-driven apps, we generally avoid loops or any action that ties up the processor for long periods of time. But if you'd like to run long loops for threads, you'll probably want to create a thread and launch it there. With the newer versions of .NET MF, you can even use anonymous methods to launch code on another thread "in-line" in your code.

You can also create background threads for each of your tasks and then have them wait on an AutoResetEvent waithandle. Then when your interrupt gets fired, just Set the waithandle and your background thread will come to life. This also helps keep thread count down and prevent unintentional re-entry.

There are a massive number of powertools available in the C# language and NETMF, so there should be one that's great for the application at hand. We're happy to help guide the selection process.



My question is what does "background threads" mean in the context of this message? I cannot find the class BackgroundThread in NETMF, so was wondering if setting the priority of the thread to BelowNormal or Lowest makes it a background thread? Would a background thread also require a Thread.Sleep(1) in its while loop? (Side question: How do you create a thread "in-line", as mentioned in the quote above?)


Those are the two ways that I'm aware of. I'd love to hear more suggestions, and also thoughts about which threading methods are suited for what applications (polling an input, blinking an LED, etc.)

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.