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

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

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");
        }
    }
}

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.

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

Yes the shield pings just fine. >ping 192.168.11.98 Pinging 192.168.11.98 with 32 bytes of data: Reply from 192.168.11.98: bytes=32 time<1ms TTL=128 Reply from 192.168.11.98: bytes=32 time<1ms TTL=128 Reply from 192.168.11.98: bytes=32 time<1ms TTL=128 Reply from 192.168.11.98: bytes=32 time<1ms TTL=128 Ping statistics for 192.168.11.98: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms I should add that I am using the original Arduino shield with no SD card.

Probably not the way to do it, but I got it to accept multiple connects by moving these 2 lines of code inside the while(true) loop in the Main()

Socket listenSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
listenSocket.Bind(ep);

So the listening socket gets created and bound every time it finished a connection
No I can connect as many times to the Netduino as I want.

I would never have thought to do it that way. I am used to using sockets under WinSocks and you would not normally have to recreate the socket to get a new connection. It looks to me like it is not dropping the connection when I close the socket. Your solution causes the socket to be desposed and that may explain why it works.

Ooh, we always love volunteers

Let's keep the Wiznet drives in C# for now, and then translate them to C++ later. They'll be faster as native code, but there are fewer "gotchas" and somewhat more portability if we create them in C#.

If you'd like a copy of the Wiznet communication spec, just PM me your e-mail address and I'll send over a copy. We could create a CodePlex project pretty easily.

All that said, finishing the Wiznet drivers will probably take about 5-10 more days of work. The easiest/fastest solution is probably to have us focus on fleshing out the implementation next week...and to have you and hari test and help resolve any bugs... Interested?

Chris

Chris add me to your list of volunteers. I have worked on a project were we implemented uIP on an HC12 using the enc... chip so I have some experience with networking in sockets. (though I will admit to being a newbie at C# I have extensive experience in C++). I just spent the last 2 hours getting bind and listen implemented and ran into a glitch on accept so I do want to help.

Some routers don't like the one from the test code--which is interesting. We'll start using a "reserved test MAC address"--probably the one I just posted--in test code going forward.

Chris

I did a quick check of the standard, maybe the problem is that the first byte has the least significant bit set which means broadcast. Routers generally will not propagate a broadcast by default, for many good reasons. I don't know why I didn't notice it before, must be because it is getting late.
Since my network here at home is three tiered, my first jump would have been blocked. I was just luck that my pc and the 'duino were on the same segment(switch).

klotz--any interest in helping get uIP up and running on the Netduino Plus? I might be able to get you one of the lab units. We only have a few, but if you were serious about helping... pascal06 is leading the project.

Chris

Sure. I would be willing. I did want to get around to a Neduino plus when they start shipping again and if this is a way to make sure the network is up and running I'll do my part.
Just need some pointers to the code base and away we go

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?

I think this is the proper close code

        internal void Close(int socketIndex)
        {
            UInt16 socketBaseAddress = (UInt16)(0x400 + (socketIndex * 0x100));

            // issue command to close the socket
            // socket n command register (Sn_CR)
            WriteRegister((UInt16)(socketBaseAddress + 0x0001), 0x10);
            while (ReadRegister((UInt16)(socketBaseAddress + 0x0001)) != 0) ; // wait to process the command
            lock (m_SocketsLock)
            {
                m_Sockets[socketIndex] = null;
            }
        }

Hi klotz!

I'm trying to get your test project to run, but I must be doing something wrong, because it never gets past this "do loop":

do
{
socketStatus = ReadRegister((UInt16)(socketBaseAddress + 0x0003));
} while (socketStatus != (byte)WiznetStatus.SOCK_ESTABLISHED);

It never returns:
WiznetStatus.SOCK_ESTABLISHED

Do you have any idea what can be wrong?

Thanks,

Ramon

I can't be sure without more details, so I appologize for asking the obvious question, 1) do you have the board connected to a 192.168.11.x network? 2) Have you posted a request from a client computer, "http://192.168.11.98"?
The code waits for a connections from the client, the loop you mentioned so is blocked.

I am having the same results. 10060 when running the wiznet test app from here. I am sure we are missing something basic but have no clue what it could be.

updated the code. I found I was not doing the bind/listen/accept cycle correctly. Not sure I have it right yet, I still can't connect more than once. Hope someone could tell me where I am going wrong.

I don't understand it, but it ALSO works when I use the physical address of my PC!? So you can try that.
Open a command prompt on your PC, type ipconfig /all
You should see Physical Address listed for each ethernet card on your PC, it should look like XX-XX-XX-XX-XX-XX, pick one, and convert it to 0xXX, 0xXX, etc.

Also confusing is that my NKC Ethernet Shield does not seem to care what I put as Physical Address. It works even with the physical address of the Arduino Ethernet shield.

That is a good suggestion. However, you may want to be careful about using an address that will be on the same network segment as the shield. Some ethernet devices count on all the addresses on the same segment being unique.
Another good source of unique mac addresses would be defunct or dead network devices you may have laying around. MAC addresses are generally printed on the serial number label and if they are truly defunct/dead you can be certain that the address is unique.

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?

Well after killing one of my Netduino's, I have managed to add listen, bind and accept to the experimental drivers. I think there is a disconnect between the implementation in the Wiz5100 chip and WinSock or Berkley Sockets. So based on my implementation you can only receive one connection request. Maybe someone can find where I am going wrong and post an update. I have changed the namespace so I could keep my changes separate from the original SecretLabs implementation. EDIT KLOTZ: Update the implementation of the bind/Listen/accept code based on some more reading. Also change the test code. Still does not reconnect.

Looking at your error code again... DNS is not supported yet. We put that in the release notes next to the download link, but maybe we need to make that more obvious. Can you try connecting via direct IP and see if that works?

Chris

I had read that DNS was not working, but I thought that was the purpose of the proxy in the following segment from the Wiznet test posted in this forum.

            string url = "http://www.secretlabs.com/default.htm";
            // NOTE: since this experimental release does not support DNS yet, we must use the IP address of the web server as the proxy address.
            string proxy = "174.143.45.105"; // ip address of secretlabs.com

            // If the device must go through a proxy server, then set proxy to the 
            // fqdn or ip of the proxy server.
            try
            {
                String html = GetWebPage(proxy, url, 80);
                Debug.Print(html);
            }
            catch (SocketException se)

BTW I don't require a proxy server to access the net.

Ramon,
While I'm unfamiliar with this particular code, I've seen that behavior before and in my case it was because my Ethernet Shield (NKC and authentic Arduino Ethernet Shield) require the 6 pin ICSP header. Both shields were stuck waiting until I solder the ICSP header on the Netduino. You might be running into the same issue.

That is a very good point. I did have a problem with my Seeeduino Ethernet board, it would not accept any of the commands. It turned out that I could do one of two things, add an ICSP connector to my Netduino or change some soldered jumpers on the board.
You may want to check to see if the enthernet board has jumpers. The best place to look would be on the schematic.

I have had some success using I2C and I have the data sheet for the MCP23017 here in front of me so I think you are doing things right. I will have to get my hands on one the the chips to be sure.

First, the address should be in the range of 0x20 - 0x27. With the way it is wired, assuming the drawing is correct, the address of the configuration should be 0x20.
It appears that you have this right, but let me explain for those who may not be aware. The I2C address as used by the I2CDevice.Configuration is the 7-bit address. With some other interfaces for I2C, it is common to list two addresses for a device, one write address and one read address. The two addresses differ only in the lsb, where an even number is the write address and an odd number is the read. In the case of those interfaces, the address would be 0x40 for Write and 0x41 for Read.
This gets more confusing since some datasheets list the addresses as the Read/Write address, for instance Newhaven displays and the Sparkfun MPR121 use this method. In those cases to use the device you will often see

new I2CDevice.Configuration(ADDR >> 1, 100);

Second, according to the data sheet, when using the I2C device the speeds are 100kHz, 400kHz and 1.7 MHz so that is correct.

Now for the final point. I will admit that at this time I am just a compitent C# programmer. But I generally avoid using "var" when I know the data type. So, I would avoid using:

var setIOCON = I2CDevice.CreateWriteTransaction(new byte[] { IOCON, 0x24 }); 

instead I would have used:

I2CDevice.I2CTransaction setIOCON = I2CDevice.CreateWriteTransaction(new byte[] { IOCON, 0x24 }); 

Other than that I will see what I can do about duplicating you hardware and see if I can find something else.

I got your latest code to work by adding a pull-up resister on ~RESET(pin18). Not too obvious in the description in table 1-1 "Hardware reset. Must be externally biased" I sort-of had it working without the pull up but it was not reliable. Once I put the resister in there, it became extreemly reliable. Sorry I didn't notice this before. And by the way, I had it working without any of the code changes I suggested. http://www.vimeo.com/20357391