Yep, generally PC fans are available in the following flavors:

2 wires: Constant speed
3 wires: Constant speed w/ tachometer output
4 wires: Variable speed w/ tachometer output and speed input (PWM)

I recently saw an article on the Make: blog where a guy had connected a 3-wire fan to an Arduino and it displayed the fan's speed on 7-segment displays. I think that would be a good re-make with the Netduino.

http://blog.makezine...th_arduino.html

You can also view the Debug.Print statements through MFDeploy. If you're not running the app from Visual Studio, press F5 in MFDeploy to hook into the Netduino's Debug output.

Chris

Oh, cool - I didn't know that. Thanks for the tip!

Quick update... We found the problem. A single line of code in the GPIO debouncer code was causing the glitch in the glitchfilter.

We have implemented the GlitchFilter fix in the v4.1.0.2 (4.1.0 patch 2) update along with the AnalogInput bugfix. The updated firmware will be posted by tomorrow.

Chris

Cool, I'll be sure to try it out (tomorrow).

Shouldn't the SW1 button act like all the other GPIO's?

If you start out by using the SW1 for input, but later on decides to use another pin for the button, it wouldn't be good to require further code changes.

The way the button is wired (Pull-Up scenario) is pretty common, and having all GPIO's "inverted" wouldn't be fun is you ask me.

I'd say that a LOW signal on a pin should be FALSE, and a HIGH signal should be TRUE - Including the SW1 input.

Just my 5 cents...

/Thomas

You can make a good case for either option. I think the real problem is that a Port is fairly generic, while connecting a switch to an input port is a specific use case.

A couple of suggestions:

1. Define a new switch-specific enumeration, so that ON corresponds to boolean false, and OFF corresponds to boolean true.

2. Derive a Switch class from the InputPort class, and give the Switch class semantics that make sense for a switch (reading the state as being On/Off, Open/Closed, etc.).

Option 1 is probably simpler, while option 2 may be a "next version" type of thing.

Thanks,
-David

Hi Chris,

Yeah, I know how delegates and events work. I've been coding professional for 10+ years. I found out why my InterruptPort wasn't working!! It was the glitchFilter, I set it to true. I remember reading it somewhere that if you set the glitchFilter to true, that will automatically handle switch debouncing for you. Could you clarify the use of this parameter for me as I am confused now. And thanks for the quick reply. You guys are doing great job helping the Netduino community to get started.

xc2rx

Hi xc2rx,

I found the same thing that you did with the glitchFilter parameter. (BTW, I'm the guy who posted the ToggleButton sample that Chris referred to).

In the ToggleButton sample, if I set the InterruptPort's glitchFilter parameter to true, it seems that the interrupts don't fire (or the event associated with the interrupt doesn't fire - not sure which one).

@Chris - is there a way we can investigate this further?

Perhaps we could "dedicate" bug fixes to our community members?

Or maybe you could award Fabulous Prizes^TM to the top bug finders (like a Netduino board or a trip to Hawaii).

OK, here's my ToggleButton sample from the other thread "Using InterruptPorts".

This is basically like the Event Handlers tutorial on the Projects page. The main difference is that the pushbutton acts like a toggle - push once to turn off the LED, then push again to turn it back on.

Another slight modification - the interrupt handler method calls DisableInterrupt() at the start of the method, and EnableInterrupt() at the end. This seems to fix an issue where pressing and holding the button would sometimes cause the LED to change state when the button was released.

I think this might be due to switch bounce, so multiple interrupts were getting "stacked up" and handled after the first interrupt method returned.

Anyway, here's the code. Let me know if there's interest in posting the entire VS solution. Enjoy!

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace ToggleButton
{
    public class Program
    {
        static bool ledState;
        static InterruptPort button;
        static OutputPort led;

        public static void Main()
        {
            // Set the initial state of the LED to on (true).
            ledState = true;

            led = new OutputPort(Pins.ONBOARD_LED, ledState);

            button = new InterruptPort(
                Pins.ONBOARD_SW1, 
                false, 
                Port.ResistorMode.Disabled, 
                Port.InterruptMode.InterruptEdgeLow);

            // Bind the interrupt handler to the pin's interrupt event.
            button.OnInterrupt += new NativeEventHandler(SwitchInterruptHandler);

            while (true)
            {
                Thread.Sleep(Timeout.Infinite);
            }
        }

        public static void SwitchInterruptHandler(UInt32 data1, UInt32 data2, DateTime time)
        {
            button.DisableInterrupt();

            // Invert the previous state of the LED.
            ledState = !ledState;

            // Set the LED to its new state.
            led.Write(ledState);

            // Un-comment the following line if using level interrupts.
            // button.ClearInterrupt();

            button.EnableInterrupt();
        }

    }
}

I have playing with the example on my silly emulator and works great

http://forums.netdui...indpost__p__277

Cool, thanks! I've been meaning to try out your emulator. So many projects, so little time...

Have you tried to enable glitch filter: button = new InterruptPort(..., true, ...) ? The debouncing time is controlable via CPU.GlitchFilterTime [^] property.

I haven't tried the Glitch filter yet, thanks for the suggestion.

Do you happen to know what the default glitch filter time is (or what value is appropriate to debounce a pushbutton)?

And if you have any questions about the PwmSample, please feel free to post them here or in the Project Showcase forum (I posted the sample code). Let us know when you get the Cylon / Knight Rider circuit working (and share the code if you don't mind).

ummmm didnt think about that.... I dont really know. I guess what I'm asking is what can I do to get a battery with high amps and at least 9V... cuz they sell them for RC model airplanes, but those are crazy expensive

Well, you could put two of the 6V batteries in series to get 12V.

With a regulator, it's fairly easy to *decrease* the voltage. But, in general, it's not easy to increase the voltage of a DC source.

Increasing the voltage generally involves converting DC to AC (or a DC square wave), passing it through a step-up transformer, and converting back to DC.

But if you do that, then the current will decrease proportionally with the voltage increase (actually, you'll lose even more current due to losses in the transformer, etc.).

You'll probably need three resistors--one for each of the Red, Green, and Blue elements.

Chris

1K is probably too high a resistance if you're driving LEDs from the Netduino output pins (3.3v).

Something like 100 ohms is probably more appropriate for Red or Green LEDs. I think Blue LEDs generally have a higher forward voltage, so you may need an even smaller resistor (or maybe no resistor at all). Best bet is to buy a resistor assortment, and save yourself some frustration.

Also, you'll probably want a potentiometer to attach that knob to .

If you're just getting started in electronics, I'd highly recommend the Make: Electronics book. It's a great hands-on introduction to basic electronics. It doesn't cover Arduino/Netduino specifically, but it's a good learning guide.

Thanks David for the reference to the Make: Electronics book. Exactly what I'm after!! (now to find someone in Australia that sells them!)....

You can also get the eBook version for US $27.99.

A more advanced exercise might use a lookup table to compensate for the non-linear response of the LED.

BTW, does anybody happen to know what the response curve of a typical LED looks like? I'm curious if it's a logarithmic function (like audio), or if it's something completely different.

I did a little research to answer my own question.

It appears that LEDs have a gamma relationship between the voltage and perceived brightness. I found this application note that explains it nicely:

http://www.maxim-ic....dex.mvp/id/3667

So, I've posted an updated version of the PwmSample (under the "PwmGamma" topic in this forum) that uses a LUT (lookup table) to implement the gamma correction.

The PwmGamma sample ramps the LED brightness in a way that looks more linear (still not perfect, but much better than before).

Nice usage of interrupt handler parameter (data2) to get the pin/button state.

Thanks, Chris. To give credit where it's due, I plagiarized copied that from the Event Handlers tutorial.

TBH, I couldn't find much in the way of documentation of how data1 and data2 are used in the callback. The .NETMF documentation mentions that data1 is the port, and data2 is the state, but "state" in this context was a little unclear. Apparently it refers to the logic state of the pin that generated the interrupt, but having that documented explicitly might be a good thing

Hi Netduino fans,

Here's a little sample that uses a PWM pin to control the brightness of an LED. I like to call it PwmSample, for lack of a better name.

What it does:
When you press and hold the pushbutton, a connected LED will gradually brighten and dim. If you release the pushbutton, the LED stays at its current brightness. Pushing the button again will resume the brighten/dim cycle from the current value.

How it works:
This sample combines several techniques from the previous samples. It uses an InterruptPort for the pushbutton input; the SwitchInterruptHandler() method is called when the InterruptPort detects a rising or falling edge due to the pushbutton.

The sample also uses a Timer callback to do the actual LED brightness control. Every 20 milliseconds, the PwmTimerCallback() method is called. This method checks whether the pushbutton is closed (the buttonState variable). If so, then it increments (or decrements) the PWM pin's duty cycle.

Circuit:
Note that you'll need to connect an external LED to the Netduino board (it won't work with the built-in LED, since it's not connected to a PWM-enabled pin).

I used Digital Pin 5 in the sample; you can use any PWM-enabled pin (5, 6, 9, or 10), but make sure to change the Pin definition on line 34.

I don't have a schematic editor handy, but the circuit is simple enough. Just connect one end of a 100-ohm resistor to Digital Pin 5. Connect the other end of the resistor to the anode (+) lead of your LED. Then connect the cathode (-) lead of the LED to one of the GND pins on the Netduino Power header.

Here's the code:

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace PwmSample
{
    public class Program
    {
        const int pwmPeriod = 20;
        const uint MaxDutyCyle = 100;

        static bool buttonState;
        static int pwmDutyCycle;
        static int pwmIncrement;
        static InterruptPort button;
        static PWM led;

        public static void Main()
        {
            pwmDutyCycle = 0;
            pwmIncrement = 1;
            buttonState = false;

            // NOTE: You will need to connect an LED to Digital Pin 5 on the Netduino board.
            // Use a 100-ohm (brown-black-brown) resistor between the LED anode (+) and Digital Pin 5.
            // Connect the LED cathode (-) to one of the GND pins on the Power header.
            //
            // You can use any other PWM-enabled pin (5, 6, 9 or 10), but also remember to change
            // the Pin parameter in the PWM constructor below.

            led = new PWM(Pins.GPIO_PIN_D5);

            button = new InterruptPort(
                Pins.ONBOARD_SW1,
                false,
                Port.ResistorMode.Disabled,
                Port.InterruptMode.InterruptEdgeBoth);

            // Bind the interrupt handler to the pin's interrupt event.
            button.OnInterrupt += new NativeEventHandler(SwitchInterruptHandler);

            // Create a System.Threading.Timer instance and pass it the timer callback method.
            Timer pwmTimer = new Timer(
                new TimerCallback(PwmTimerCallback),
                null,
                pwmPeriod,
                pwmPeriod);

            Thread.Sleep(Timeout.Infinite);
        }

        public static void PwmTimerCallback(Object obj)
        {
            // Only change the LED brightness when the button is pushed (true).
            if (true == buttonState)
            {
                // Set the pin's new duty cycle.
                pwmDutyCycle += pwmIncrement;
                led.SetDutyCycle((uint)pwmDutyCycle);

                Debug.Print(pwmDutyCycle.ToString());

                if ((MaxDutyCyle == pwmDutyCycle) || (0 == pwmDutyCycle))
                {
                    // The duty cycle has hit the min or max value.
                    // Start ramping in the other direction.
                    pwmIncrement = -pwmIncrement;
                }
            }
        }

        public static void SwitchInterruptHandler(UInt32 data1, UInt32 data2, DateTime time)
        {
            button.DisableInterrupt();

            buttonState = (0 == data2);

            button.EnableInterrupt();
        }

    }
}

Just out of curiosity, do you plan to extend PWM control to compensate the LED brightness non-linearity?

Hi CW2,

Thanks for the suggestion - I think that would be a good follow-on sample. For the time being, I just wanted to create something equivalent to the Arduino "Fading" sample, but showcase some of the Netduino / NETMF features (like timer callbacks, and a "real" Sleep() function).

The Arduino sample also just folows a linear PWM ramp, which as you mention, doesn't correspond to a linear brightness at the LED

A more advanced exercise might use a lookup table to compensate for the non-linear response of the LED.

BTW, does anybody happen to know what the response curve of a typical LED looks like? I'm curious if it's a logarithmic function (like audio), or if it's something completely different.

Oooooooooooooo... button-controlled fading. Pretty!

Now to get my head around the code and get it doing something useful.

dab, thanks for publishing useful example. How do you suggest I get a relevant basic command reference? I hate reading (and writing) documentation as much as the next guy but there are times when it really helps...

The community (including me ) would probably benefit enormously from some pointers on how to research the command syntax.

Hi FastEddy,

Thanks for the kind words - I'm glad you find the sample code helpful .

You raise a good point about getting up to speed on the technology. I consider myself pretty much a newbie to C# and the .NET framework (until relatively recently, I was a C++/Win32 API kind of guy).

For me, the biggest challenge is the .NET framework itself. It's huge (even .NETMF), and a lot of classes aren't very discoverable. I always find myself thinking "I know there's a class/method to do 'x', but where?".

Here are some things I've found helpful:

• Sample code. Find something here in the Project showcase that looks interesting to you, get the source code, and play with it. Look up the classes / methods that you're not familiar with. Try making small changes to the code and see what happens. Don't be afraid to experiment.
  
• Online documentation. Currently, the best available documentation is at the MSDN library site. But be aware that even that is sometimes wrong, or slightly out-of-date for the .NETMF libraries.
  
• Books. There are a couple of books that I've found sort of useful. One is "Embedded Programming with the .NET Micro Framework", by Donald Thompson and Rob Miles. The other is "Expert .NET Micro Framework" by Jens Kuhner. Both of these are a bit dated, but have some useful sample code. There's also quite a bit of stuff in both books that I didn't find that useful, but they're worth reading for a couple of chapters (I'd recommend borrowing them if you can find a library that has them, or buy used copies).
  
• Community. Right here is a good resource - it's a fairly small (but growing) community, and people I've seen are eager to share and swap advice and ideas. And the Secret Labs folks here are also super-helpful.

I hope that helps get you started.

We have posted updated firmware to address the SD card mounting and memory allocation issues.
http://forums.netdui...patch-4-beta-1/

SD card-related updates in the firmware update:
* Mounting invalid MicroSD cards now throws an exception
* Reduced memory usage when accessing SD cards

Please let me know if this new firmware fixes things for you...

Chris

Cool - thanks for getting the new firmware out so quickly!

This seems to fix the problem I was having with the StreamReader.ReadLine() method yesterday:

Current directory: \
dir: \SD
file: \SD\FOO.TXT
The quick brown fox jumps over the lazy dog.

Now I need to figure out what to do with 1.83 GB of storage.

Chris,
Thanks for looking into this. If you change to use ReadToEnd() the behavior is the same. So this might be memory leak inside the StreamReader itself.

I'm getting exactly the same error as Szymon when I try to read a file from the SD card. I actually wrote my sample before I saw this thread, but my code is almost the same.

Here's the sample code where I use a StreamReader object to get the first line of a text file:

using System;
using System.IO;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace SDCardSample
{
    public class Program
    {
        public static void Main()
        {
            string currentDir = Directory.GetCurrentDirectory();
            Debug.Print("Current directory: " + currentDir);

            string[] dirs = Directory.GetDirectories(currentDir);
            foreach (string d in dirs)
            {
                Debug.Print("dir: " + d);
                string[] files = Directory.GetFiles(d);
                foreach (string f in files)
                {
                    Debug.Print("file: " + f);
                    StreamReader reader = new StreamReader(f);
                    Debug.Print(reader.ReadLine());
                    reader.Close();
                }
            }
        }
    }
}

And the exception that gets thrown:

Current directory: \
dir: \SD
file: \SD\FOO.TXT
Failed allocation for 685 blocks, 8220 bytes

Failed allocation for 685 blocks, 8220 bytes

    #### Exception System.OutOfMemoryException - CLR_E_OUT_OF_MEMORY (1) ####
    #### Message: 
    #### System.IO.StreamReader::ReadLine [IP: 000a] ####
    #### SDCardSample.Program::Main [IP: 005e] ####
A first chance exception of type 'System.OutOfMemoryException' occurred in System.IO.dll
An unhandled exception of type 'System.OutOfMemoryException' occurred in System.IO.dll

Note that this happens for both ANSI and UTF-8 encoded files (I created the files on the PC).

Do you intend for this forum to be used as a place for examples or mostly just troubleshooting of the main board? Cause I'm always writing and posting my *duino examples and I'd love to post them here (once my netduino shows up) if there were some Examples/Tutorials section that users could post to. Thanks, the product sounds like it should be a hoot and a half.

+1 to this suggestion. I think a place to share code and examples would be a good idea.

How about a "Netduino Projects" forum where users can showcase their projects?

And then the Sandbox would be perfect for posting code snippets?

Sounds good!

That is pretty cool. Small and cheap enough to install in a dedicated project . This definitely gives me some ideas. Watch out

klotz,

A bit of both. But mostly a software limitation. If there's interest, we can start a community project to expand this to 4GB or beyond (for MicroSD cards that support SPI).

Chris

As a member of the community, I'd be interested in the project to expand the microSD capacity...

Would you be interested in helping implement (Micro)SDHC libraries using SPI?

Sure.

Helping lead the team?

Uuhm, depends on what you mean by "team".