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

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

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!

Chris,

I have no microSD atm, so will need to buy one. Could you post a list of cards that are known to work?

I bought this one today, and it seems to work (well, I can read the directories and file names, but there seems to be a problem with reading file contents).

SanDisk Mobile microSD Card 2GB

$9.99 at Office Depot in the US.

Hi Shane and welcome!

The Debug.Print will appear in the Output window within Visual Studio or Express.

Cheers,
Matt.

And you need to have the debugger attached. In VS2010, go to Debug | Start Debugging, which will run the solution in the debugger.

If the debugger isn't attached, the Debug.Print() statements will have no effect.

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

On second thought...

fileLocation += fStream.Read(buffer, fileLocation, System.Math.Min(128, (int)(fInfo.Length - fileLocation)));

fileLocation is 128 on your second loop--too high of an offset in your 128-byte buffer array. Did you want to pass 0 as your second parameter?

Chris

Also, it looks like you can just use 128 for the 3rd parameter to FileStream.Read()...if it reads less than 128 bytes, then it should be OK (the method will return the actual number of bytes it read).

We are working on a USB HID (driverless) communication channel...and are looking at CDC as well. We're not sure if we'll be able to enable CDC _and_ USB debugging at the same time--but we're looking at it.

Pardon my ignorance, but what's CDC (besides the Centers for Disease Control )?

I use one of the FTDI USB cables that has the FT232R built in.

Works great with the Netduino (make sure to get the 3V3 version).

There is a .NET Micro Framework extension library project on the Codeplex called Grommet [^] that contains 'Asynchronus API XBee library' to communicate with XBee modules. I have not used it personally, though.

Cool, thanks for the tip!

I'm in the same boat. This book has been fan-freakin-tastic: Make: Electronics

Stacy

+1 on Make: Electronics. Very fun and easy read, with clear explanations and experiments that demonstrate the principles well.

Some of the old Radio Shack books by Forest M. Mims are also quite good. I believe you can still get his classic "Getting Started in Electronics", as well as reprints that combine several of the small "Engineer's Mini Notebook" titles in one book.

Hi folks,

I'm also very excited about the Netduino and the .NET goodness that it brings to the AVR microcontrollers .

Along the same lines as nirav's question - is there (or will there be) support for the XBee wireless Arduino shields?

For example:
http://www.sparkfun....roducts_id=8664

Thanks, and I can't wait until my Netduino board arrives!

Here's another little sample that I put together called BlinkyTimer.

This basically does the same thing as the Blinky tutorial, but it uses a Timer object with a callback method to turn the LED on and off.

Here's the code. If you think of any cool variations, please share.

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

namespace BlinkyTimer
{
    public class Program
    {
        const int blinkPeriod = 250;
        static bool ledState;
        static OutputPort led;

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

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

            // Create a System.Threading.Timer instance and pass it the timer callback method.
            Timer blinkTimer = new Timer(
                new TimerCallback(BlinkTimerCallback),
                null,
                blinkPeriod,
                blinkPeriod);

            Thread.Sleep(Timeout.Infinite);
        }

        public static void BlinkTimerCallback(Object obj)
        {
            // Invert the previous state of the LED.
            ledState = !ledState;

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

    }
}

Thanks, Chris, I'll take a look at the mftoolkit. Worst case, I suppose it probably wouldn't be too difficult to port an existing Arduino XBee library (although I haven't seen the source code). Thanks!

This is a timely topic . It would nice to make this a sticky thread for future reference (and a place to point somebody to when they ask where to find things).

I'll add a couple more:

• Evil Mad Science Shop: This is the companion store for the Evil Mad Scientist Laboratories blog. A smaller but more eclectic shop. They mainly sell kits of their own design, and also have some good deals on components (like RGB LEDs). Also check out the EggBot.
  
• Adafruit Industries: The companion store for the LadyAda.net blog (aka Limor Fried). Like Evil Mad Science, the store carries a lot of kits designed by LadyAda, as well as lots of Arduino boards and shields. There's some overlap with MakerShed and SparkFun, but a lot of cool stuff.

Thanks Chris! And thanks for moving it to the new forum.

One quick note: you don't need to put the infinite sleep inside a loop. It will only execute once...so they while(true) is redundant...

Yeah, I keep meaning to fix that. It was in a sample program from the book "Embedded Programming with the Microsoft .NET Micro Framework", but I agree it seems redundant. It might also make the code a little smaller by removing the while loop(?).

I just updated it for you. Please let me know if you'd like me to change it back.

You beat me to it. Thanks again, Chris!

(And get some sleep, OK?)

As a follow-up to the PwmSample, CW2 suggested extending it to address the non-linear response of the LED.

After a bit of research, I found that this is referred to as "gamma correction", and even found an application note that discusses using gamma correction with PWM:

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

So, here's an update to PwmSample that uses a pre-computed LUT (lookup table) for the PWM output values. These are the gamma-corrected values (for gamma = 2.5) that produce a brightness ramp that looks linear (more or less) to our eye.

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 PwmGamma
{
    public class Program
    {
        const int pwmPeriod = 50;

        // Lookup table for the LED brightness.  The table contains the 
        // gamma-corrected values (for gamma = 2.5).  This approximates
        // a linear increase in the perceived brightness.
        static uint[] gammaTable = {
             0,  0,  0,  0,  1,  1,  1,  2,  2,   3,
             4,  5,  6,  7,  9, 10, 12, 14, 16,  18,
            20, 22, 25, 28, 31, 34, 37, 41, 45,  49,
            53, 57, 62, 67, 72, 77, 82, 88, 94, 100,
        };

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

        public static void Main()
        {
            pwmIndex = 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.
                led.SetDutyCycle(gammaTable[pwmIndex]);
                pwmIndex += pwmIncrement;

                Debug.Print(gammaTable[pwmIndex].ToString());

                if (((gammaTable.Length - 1) == pwmIndex) || (0 == pwmIndex))
                {
                    // 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();
        }

    }
}

I think we'd need to see the rest of the code in order to find the problem. Can you post the complete source code?

Nice! I'm glad I brought a Netduino with me on vacation so I can play with this

You mean you actually take vacation?

I'd say it also depends a lot on the type of solder you're using. I learned to solder back when Pb/Sn solder wasn't considered hazardous , so my soldering habits have developed around that. I've found that about 350C works well for eutectic (63% Sn, 37% Pb) solder. I just recently started using lead-free solder, and found that I had to kick the temperature up to nearly 400C to get it to melt in a reasonable amount of time, and for it to wet/flow well. Maybe I just haven't gotten used to it yet, but I find the lead-free stuff harder to work with, and the joints never look nice and shiny like Pb/Sn. Instead, the joints have that slightly dull finish, which always makes me worry that I've got a cold solder joint.

Hi,

I decided to try modifying the ButtonApp sample to use interrupts instead of polling the state of the pushbutton switch.

I found an example in the book "Embedded Programming with the Microsoft .NET Micro Framework", and kinda mashed up my own ToggleButton app.

The basic idea is to have the pushbutton switch "toggle" the LED on and off with each successive press (i.e., the first time the button is pushed and released, the LED turns on, and the next time the button is pushed, the LED turns off, etc.).

Here's the code that I came up with. There's probably some unnecessary code in here, since I was trying various ways to make it work.

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 InterruptPort button;
        static OutputPort led;
        static bool ledState;

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

            led = new OutputPort(Pins.ONBOARD_LED, ledState);
            button = new InterruptPort(Pins.ONBOARD_SW1, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeLevelLow);

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

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

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

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

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

            button.EnableInterrupt();
            button.ClearInterrupt();
            Debug.Print("-SwitchInterruptHandler");
        }

    }
}

The problem is that the code seems to run fine under the debugger, but doesn't work as expected when it's not running in the debugger.

Can anybody spot what I'm doing wrong here?

Thanks,
-David

I decided to try modifying the ButtonApp sample to use interrupts instead of polling the state of the pushbutton switch.

Gaah, never mind. I just found that the Event Handlers tutorial has been posted in the Projects section.

I'll take a look at that...

I think you guys need a facebook page...

Gaah, never mind. I just found that the Event Handlers tutorial has been posted in the Projects section.

I'll take a look at that...

Hmm, I seem to have the same issue with the AdvancedButtonApp tutorial. Works as expected under the debugger, but not when I just deploy the solution to the Netduino.

Is there some kind of timing issue that's causing this? Has anybody else got this working outside the debugger?