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

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.

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

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?

D'oh! Dumb mistake - I was just selecting the "Deploy Solution" menu option from the Build menu. I needed to select "Start Without Debugging" from the Debug menu to get the solution to actually run.

Now both programs work as expected.

Move along, nothing to see here...

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

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?

Just curious...when you received and opened your Netduino, what were your first impressions?

Anything we can do better to improve the "unboxing" experience?

I just received mine this weekend from the Maker Shed. I'm not sure exactly when it arrived, since I was out of town this weekend, but it was waiting patiently for me in the mailbox when I got home Sunday evening.

Around 9:00 PM I finally got a chance to open the box. I had ordered another item from Maker Shed, and at first I thought the Netduino had been back-ordered. After looking closer, I saw its little black anti-static bag with the blue label.

It's a little smaller than I expected (exact same footprint as Evil Mad Science's Diavolino board). I also found the little rubber feet and the tag, but I don't have a phone that will read it

I got VS2010 Express installed on my machine, then the .NETMF, and finally the Netduino package. I jumped right into the blinkenlight tutorial, and plugged in the Netduino. FWIW, mine didn't come with the micro-USB cable, but I have plenty from other devices, so it wasn't a show stopper for me.

At first, Win7 didn't install the driver - then I closed VS2010, unplugged and re-connected the Netduino, and the drivers installed fine.

Then I deployed the project to the board, and basked in the glow of the blinking blue light .

I must say, it's a better OOBE than my recent foray into the Arduino world (about a month ago). Arduino is cool and all, and I'm sure in many ways it made the Netduino possible. But the Arduino tools feel hacked together, and I've spent way more time futzing around with the tools than actually working on hardware.

This is what Arduino should have been, IMO. Leveraging Visual Studio, .NET MF, and C# was an inspired choice. It puts professional-quality development tools in the hands of hobbyists and startups.

This is very cool, and I can't wait to spend more time playing with it.

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

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

I quite like flying things. Will it be a flying rug? Only time will tell

Flying rugs are so old world. I vote for flying cars

Removing the rest of the evidence

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

Sorry, I'm voluntarily deleting my previous remark, since it was somewhat inappropriate. I don't mean to detract from the Secret Labs announcement.

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

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.

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

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

Did you look at Fritzing? It's what I use to document schematics for my projects.
And CW2 already created Fritzing part for Netduino.

Thanks, Szymon. I'll take a look at Fritzing - it looks interesting.

Hi folks,

Some the little sample projects that I've been sharing over on the Project Showcase are getting large enough that it would be helpful to post a schematic along with the code. I expect the circuits will only get bigger as time goes on.

I've been out of the electronics hobby for a while, so I'm curious what kind of schematic capture software is hobbyist-friendly. Basically, this means free (or cheap), and easy to learn.

It looks like Eagle supports schematic capture as well as PCB layout, and has a limited freeware version.

I've also heard some recommendations for KiCad (open-source).

Are there any others I should look into? I'm on the Windows platform, BTW.

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

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!

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.