klotz,

Try the following MAC address; it's an official Secret Labs MAC address (and one we use for testing).
5C-86-4A-00-00-09

Chris

Thanks alot Chris, That was the ticket! It works now. When I get to work in the morning I will get a MAC address from my allocation.
Just out of curiosity, any idea why the default one in the test code would not work?

I fixed that error by updating PhysicalAddress initialization in the sample program with the MAC address printed on sticker on the back of my Ethernet Shield.
Replace the bytes in red with your actual MAC address.

networkInterface.PhysicalAddress = new byte[] { 0x01, 0x23, 0x45, 0x67, 0x89, 0x01 };

Good luck!

I have an Arduino Ethernet shield and there is no MAC address printed on it anywhere. Does the Wiz5100 have one "programmed" into it? If so how do I get it?

EDITTED---
I purchased an AdaFruit Protoshield and that's all build and piggybacking my Netduino. What's not clear to me is how the various buttons on the shield relate to the Netduino. For example, I have two LEDs on the protoshield and two buttons. How are these addressable through code (given that the Netduino only has one of each)?

EDITTED AGAIN--
What I'd like to do as a next step is control a 5v motor, attached to the shield, and have its speed adjusted with a photoresister. Pretty basic, eh? :-) I'm not clear on how/where I'd hook up the motor to the shield (which pins) and also where the photresistor fits into the picture (on the shield in series with the motor, presumably, but what voltages should I use)?

And again
Thanks.

Mark

I hope you don't mind I didn't quote your entire post since I am going to start by answering the easy parts . But here goes:

One of the buttons (the one labeled RESET) is tied to the reset on your board and that is all it can do for you.
The other button and the two LEDs are not assigned to any function instead they are tied to ground on one end and the other is to a pad you can route to any of the DIO ports. The LEDS have a current limiting resister on them so they are safe. You just have to make sure you define the DIOs used with the LEDs as outputports and the button as an input port with a pullup. You can view the schematic here: http://www.ladyada.n...v5schematic.png

On the memory issues:

1. We haven't found any memory leaks...this is good.
2. The FAT file system was creating up to about 8 2KB caches when data was read. We're tuning this down quite a bit. The memory was reclaimed when the SD card was unmounted--but a total cache size of 2KB is probably more appropriate for this type of device.
3. The StreamReader uses 4KB buffers by default; we're tuning these down to 512 bytes. ReadToEnd() and ReadLine() read data in chunks of 4KB -- and had to create new buffers of at least 8KB whenever they needed to read more data.

We'll post a beta update for the Netduino Plus firmware (v4.1.0.4 beta 1) with these changes by the end of the week.

Chris

If we get SDHC support the buffers may need to be at least 1024 since that is the sector size of the HC device.

Ok, I just got up and tried my driver on the Netduino. In fact I used my latest demo program I use for debuging driver improvements and the only thing I had to change was a few "using" statements and references.
If you start from "New project" paste the embedded code to you programs.cs, you would only have to add a reference to the Newhaven Displays class.

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

namespace Netduino_With_Newhaven_Display
{
    public class Program
    {
        private static NewhavenDisplay.SerialLCD display;
        private static I2CDevice bus;

        static void sendFunction(byte[] data)
        {
            I2CDevice.I2CTransaction[] xAct = new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(data) };
            int bytes = bus.Execute(xAct, 1000);
        }
        public static void Main()
        {
            bus = new I2CDevice(new I2CDevice.Configuration(0x50 >> 1, 100));
            display = new NewhavenDisplay.SerialLCD(sendFunction);
            display.Clear();
            display.Write("Well did it work?");
            display.Write("Lets see what happens with this one");
        }
    }
}

So we have a good start on solving the problem. We have two of four things verified. 1. The display works, this was demonstrated by the successful use of the display with serial connections. 2. The driver on Fezzer works as it has been successfully used with SPI, I2C and Serial be several people with the Newhaven serial displays. This leaves us with just two things to verify: 1. The shorting block on the Newhaven display is correctly soldered. 2. The connections for I2C between the Netdiuno and the display are correct. Since the thread does not specifically identify the Netduino, I will go with the assumption that we are talking about a Netduion classic. So the connection between the Netduino and the Display would be as follows: Netduino Pin -> Display 5vdc -> 10 Gnd -> 9 A4 -> 8 A5 -> 7 I did not show a picture of the R1 jumper, because it is clearly displayed in the manual. However, I have attached a picture of the display working and its connections.

I have a Newhaven display running in .NETMF, you can look a working code on http://www.fezzer.co...ial-lcd-display . While this was done FEZ Panda, the code should work on Netduino. Give it a look. I will try it with the Netduino tomorrow morning myself so I can post a demon with the Netduino

I found that when using the tactile miniswitches, http://www.sparkfun.com/products/97 , if I add a 0.1 mF cap from the signal line to gnd and enable the pull-up resistor cleans up the interupts just fine.

R.I.P.

But now you have a perfect board to practice SMD reworking (assuming you've burnt just the micro)

Now there's a good suggestion.Since I am normally a software guy, where would be the best place to get a replacement Atmel? Digikey is asking $20+shipping handling tax. Almost the price of a new Netduino.
Any suggestion where else I should look?

Unfortunately, the Atmel chip is about a $20 chip (of course unless it is purchased in quantity). I'd say digikey is your best bet.

Just be lucky it isn't a ~$150 chip

In either case logic dictates that I order a new Netduino. $20 + shipping and handling and frustration of removing the old and adding a new > 34.95 + shipping and handling.

I ALWAYS triple check my connections. So far, I have not fried even a single component.

I have gotten quite close though Just ask my temp sensor that had a backwards pinout to the dumb datasheet....

I guess I shouldn't try to work on my board with distractions. Just did not notice the pins that were not in their sockets.

Hi klotz,

No fun at all. It sounds like it got fried, but you may want to try erasing the Netduino (using the ERASE) pad and seeing if you can reprogram it. It's probably fried--but there's a small possibility of recovery...

Chris

P.S. Reverse power protection and a resettable fuse are built into the Netduino. And the odd pin spacing for shields helps keep pins in the right place. But while Netduino is designed to take a certain amount of abuse, it is possible to fry a pin (or in more extreme cases, to fry a whole Netduino). Most users will be fine--but it makes me sad to see one get electrocuted...

He's dead Chris.
No amount of protection can survive an unattentive user. Just got to excited about testing my two ethernet shields and didn't notice I had plugged it in wrong. The Seeeduino shield is wider than most so it is not as easy to see the pins if you don't pick it up and inspect it.
And of course I was convince I had checked it so I let it cook while I trouble shot the failure to connect. The Atmel was way hot, and I can't get any response from it at all except a very bad smell and lots of heat.
(Kind of reminds me of like Washington D.C. or Springfield, IL)
I'll mount this one on the wall with a note "CHECK THE SHIELD" hanging from it.
That's what overconfindence will get you.

I unfortunately plugged my shield in off key without noticing it and when I powered my Netduino it failed to connect. I tried to find the software reason it wouldn't connect rather than what could be wrong with hardware. Once I notice the shield was not plugged in correctly, I disconnected the power removed the shield and allowed the duino to cool. TOO LATED Well live and learn. From now on, I won't power-up without checking the connections. Oh well now I have to order a new one Just had to get that off my chest.

And then here is my solution to the Sparkfun keypad

using System;
using System.Collections;
using System.Threading;
using Microsoft.SPOT.Hardware;


namespace Sparkfun_12_key_keypad
{
    public class Keypad
    {
        private InterruptPort Col1;
        private InterruptPort Col2;
        private InterruptPort Col3;
        private OutputPort Row1;
        private OutputPort Row2;
        private OutputPort Row3;
        private OutputPort Row4;
        private uint column1 = 0;
        private uint column2 = 0;
        private uint column3 = 0;
        private uint recieveKey;


        void Col_OnInterrupt(uint whichCol, uint data2, DateTime time)
        {
            recieveKey = 0xFFFFFF;

            for (uint Row = 0; Row < 4; Row++)
            {
                switch (Row)
                {
                    case 0:
                        Row1.Write(false);
                        Row2.Write(true);
                        Row3.Write(true);
                        Row4.Write(true);
                        break;
                    case 1:
                        Row1.Write(true);
                        Row2.Write(false);
                        Row3.Write(true);
                        Row4.Write(true);
                        break;
                    case 2:
                        Row1.Write(true);
                        Row2.Write(true);
                        Row3.Write(false);
                        Row4.Write(true);
                        break;
                    case 3:
                        Row1.Write(true);
                        Row2.Write(true);
                        Row3.Write(true);
                        Row4.Write(false);
                        break;
                }
                if ((whichCol == column1) && (Col1.Read() == false))
                {
                    recieveKey = (Row*3);
                    break;
                }
                else if ((whichCol == column2) && (Col2.Read() == false))
                {
                    recieveKey = (1 + (Row*3));
                    break;
                }
                else if ((whichCol == column3) && (Col3.Read() == false))
                {
                    recieveKey = (2 + (Row * 3));
                    break;
                };
            }
            Row1.Write(false);
            Row2.Write(false);
            Row3.Write(false);
            Row4.Write(false);
        }

        public Keypad( Cpu.Pin Col1, Cpu.Pin Col2, Cpu.Pin Col3, Cpu.Pin Row1, Cpu.Pin Row2, Cpu.Pin Row3, Cpu.Pin Row4)
        {
            this.Col1 = new InterruptPort(Col1, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow);
            this.Col2 = new InterruptPort(Col2, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow);
            this.Col3 = new InterruptPort(Col3, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow);
            this.column1 = (uint)Col1;
            this.column2 = (uint)Col2;
            this.column3 = (uint)Col3;

            this.Row1 = new OutputPort(Row1, false);
            this.Row2 = new OutputPort(Row2, false);
            this.Row3 = new OutputPort(Row3, false);
            this.Row4 = new OutputPort(Row4, false);

            this.Col1.OnInterrupt += new NativeEventHandler(Col_OnInterrupt);
            this.Col2.OnInterrupt += new NativeEventHandler(Col_OnInterrupt);
            this.Col3.OnInterrupt += new NativeEventHandler(Col_OnInterrupt);
        }

    }
}

You just have to make sure that the pins you use for Columns are interrupt pins.

I did a 4x4 keypad decoder as well. In my case I used a 8574 chip and the I2C bus, but the basic idea is the same. You may get some ideas from the code I wrote for that, see http://www.fezzer.co...-port-extender/

The ammount of current being dumped into the interrupt is not a issue, what you should be worried about is the ammount of current being drawn on the outputport driving the columns. Even in that case, the ammount of current is negligable. Worstcase for any one driver would be 4 keys. If you are seriously worried about it you can mitigate the problem by driving the 4 rows and have the Columns as the interrupts, in that case the worse case would be 3 keys.

I built my own imediately after getting my 'duino and FEZ domino. I had the box in my scrap box and added the breadboard and a 5volt regulator. I have a chassis plug on the back of the box to connect VIN.

Nice, at least someone got some use out of it! Yeah, this class has been used and tested extensively, so it's all worked out. I will be updating the class in just a sec, too.

I just tried to use the class from the post, and I get an error while compiling "Error 1 The type or namespace name 'Cpu' could not be found (are you missing a using directive or an assembly reference?)"

While I am new to using C# this is not the first class library I have made so I am a little confused about why I am getting the error. I did copy and pasted the file from the post.
Any suggestion?

Did you include the Microsoft.SPOT.Hardware reference? You probably also need SecretLabs.NETMF.Hardware and SecretLabs.NETMF.Hardware.Netduino

So it was a problem with the way I created the project, not the source at all. Once I went to References under the solution explorer and added the Microsoft.SPOT.Hardware, it build just fine.
Like I said I am still a nubie when it comes to C#.

BTW: That and SecretLabs.NETMF.Hardware. Oops.
Thanks.

I just got my Netduino, what I don't understand is the purpose of the little colorful stamp/piece of paper. Also is there a summary of the netduino sdk anywhere. I am an old guy who is used to having a reference other than the code.

You can step the voltage all you want, but it will come as a cost of current. 6V probably would power the Netduino, not 100% on that though, I haven't looked at the schematics yet.

I have run the Netduino, and Parallax boe bot chassis on 4 AA batterys. ( 4 x 1.5 = 6Vdc)
I have been using the same batteries for over a week and had several test runs of the chassis. So I would say, 6VDC will just make it.
Remember you lose about 0.6-1.0 volts to a regulator and the Netduino wants a solid 3.3 Vdc for main power and 5Vdc +- 10% so your can get by.

If available and if the distance is not too great I would prefer I2C over SPI.

Could you break this down a bit more? Distance being what? If I have a central Netduino in the house, and several scattered around the property, what's the prefered for 50 -200 ft, CAT5 cable?

I would not use I2C or SPI for those distances. In the first case, one should not think of I2C or SPI as a protocol for anything say outside the box. Both are intended for communication between ICs or small peripherals, like ethernet chips, lCD displays and the like.
If I have to go more than a couple of feet, then I would start to concider one of the interconnect serial protocols like Async (TTL, RS232, or RS485.)
Then if we are in the range of Room to Room or greater I would concider ethernet.
So in answer to you direct question. At 50-200ft, especially if you have already installed CAT5, go ethernet. The shields for 'duinos are cheap and .NETMF makes it easy to program.

What are the differences between SPI and the other thing that uses TX and RX? I understand that SPI has a clock so the shift register (lets use that as an example) knows when to read the other pin for a HIGH or LOW. but then how does the TX and RX communicate? how does it know when to get the data? Are they both Serial types of communication or not? Any info is appreciated, links are good too. Thanks!

I don't know how much time you have to read stuff, and we could spend a lot of time asking and answering questions so I thought that it may be helpful to supply you with a link to the Wikki page that describes SPI. This may be way more than you wanted to know but there are nuances to using SPI that are not immediately apparent and which many of us take for granted. So here is the Wikki link ( and yes I read it and it is a good description on Jan 2, 2010 You know how Wikkipedia can be )
http://en.wikipedia....l_Interface_Bus

What are the differences between SPI and the other thing that uses TX and RX? I understand that SPI has a clock so the shift register (lets use that as an example) knows when to read the other pin for a HIGH or LOW. but then how does the TX and RX communicate? how does it know when to get the data? Are they both Serial types of communication or not? Any info is appreciated, links are good too. Thanks!

Tx and Rx are used for Asynchronous Serial communication which is sometimes described as "self clocking". This is misleading to most users in that the data rate must generally be agreed upon before hand as Chris has stated, the selfclocking come from the method for detecting the begining of the data octet or byte. Here is the Wikkipedia page that describes this http://en.wikipedia....ver/transmitter as before I can only vouch for the correctness as of Jan 2, 2010 when I read it.

If I had a choice, I would use SPI over TX/RX because it is easier for me to use. If available and if the distance is not too great I would prefer I2C over SPI.

Just a quick note for anyone who may want to use the SparkFun Electronics Joystick Shield, DEV-09760 http://www.sparkfun....oducts_id=9760. I bought mine to use for experiments with my Netduino. While it worked fine after I built it, I did find the there were problems with the analog reading for the X and Y pot on the joystick. Following the information I saw here I had added a patch wire from the 3.3 Vdc to Vref. But noticed that the center readings were 66% of full scale. which meant that the min to center would have twice the resolution of the center to max. I am a software engineer not a hardware engineer so it took me a full half hour to realize that the problem was that the pots were biased using 5 Vdc. I change the jumper for Vref to the 5 V source. This did a find job of centering the signal, but the max values were very unstable. I guess I was over driving the A/D. So I cut the trace from 5 V to the joystick and added a wire from 3.3 to the joystick and Vref. Now every thing works just fine. See the attachment.