89 replies to this topic

[klotz]

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

[klotz]

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

[SupraBitKid]

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

Sure. I'm glad to help. Is there any effort going into DHCP?

Kai

[Chris Walker]

Sure. I'm glad to help. Is there any effort going into DHCP?

Kai,

DHCP for Wiznet was not in our roadmap. Have you written DHCP code before? Perhaps that would be a good place to contribute?

Chris

[Chris Walker]

I got the Netduino along with Ethernet Shield and a Netduino Plus talking to each other via Ethernet, but it fails after the fourth communication because Socket class in System.Net.Socket does not implement Close() yet and we only have four sockets in Wiznet5100 implementation.

Hi hari,

We've updated the experimental Wiznet drivers. You can now close your TCP connections

Updates:
1. Socket.Close() and Socket.Dispose() have been implemented
2. Some UDP code has been added; SendTo(...) and ReceiveFrom(...) will be supported soon

We've also pared down our large DNS implementation to about 1500 lines of code. It'll take a few hours to port it to .NET Micro Framework and pare it down to the appropriate smaller size. More to come...

I'm also looking at what it would take to put this up on CodePlex...

Chris

[hari]

Hi hari,
We've updated the experimental Wiznet drivers. You can now close your TCP connections

Updates:
1. Socket.Close() and Socket.Dispose() have been implemented
2. Some UDP code has been added; SendTo(...) and ReceiveFrom(...) will be supported soon

We've also pared down our large DNS implementation to about 1500 lines of code. It'll take a few hours to port it to .NET Micro Framework and pare it down to the appropriate smaller size. More to come...

I'm also looking at what it would take to put this up on CodePlex...

Chris

Oh Thank you! I'll play with it soon.
I think anyone can start a CodePlex project and approve check-ins. They have TeamExplorer support that is fully integrated to VS.

[Chris Walker]

Also, UDP is now supported. Updated drivers are in first post of thread. I also updated the same code with an official Secret Labs-issued MAC address, so that it should play well with all routers.

[hari]

Hi hari,
We've updated the experimental Wiznet drivers. You can now close your TCP connections

I can confirm that Close() now works. My test code has been opening and closing connections every 3 seconds for about 20 minutes.
Thanks Chris!

[Chris Walker]

I can confirm that Close() now works. My test code has been opening and closing connections every 3 seconds for about 20 minutes.
Thanks Chris!

Ah, great news... Just FYI, I just posted one more small update which fixes some issues in the optional "interrupt mode" and adds protection for a potential connection failure mode.

Chris

[klotz]

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.

Attached Files

•  MyFirstWebPage.zip   80.87KB   95 downloads
•  Wiznet5100v2.zip   17.35KB   101 downloads

[Chris Walker]

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.

Nice. Thanks for posting these!

Chris

[RvBCrS]

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.

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

[klotz]

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.

[hari]

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

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.

[klotz]

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.

[RvBCrS]

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.

Hi thanks for your reply! I changed the ip address to match my network to 192.168.1.220, gateway 192.168.1.1 and then did a request from a browser to 192.168.1.220, I knew it would not return a result because the code kept looping until it would return a result connected, witch it never did.

[RvBCrS]

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.

Hi I have a DFRobot shield, that is a pretty common one isn't it? When I connect the ICSP header to the Netduino where do I connect it to on the shield? i don't see a ICSP header on the DFRobot shield..

[RvBCrS]

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.

There are 2 jumpers on the DFRobot board.. the INT jumper and a WP jumper and a two pinheader one "PROG" I really have no idea

[Chris Walker]

There are 2 jumpers on the DFRobot board.. the INT jumper and a WP jumper and a two pinheader one "PROG" I really have no idea

The current DFRobot Ethernet shield does not require an ICSP header. If you melt the INT solder bridge you'll enable use of the more efficient "interrupt" mode but lose the use of one digital pin.

[Chris Walker]

RvBCrS: Also, what MAC address have you set on the Wiznet shield? Chris