The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
The Netduino.IP Technical Preview is now feature-complete. We are now focused on full-stack testing.
To use Netduino.IP, simply write standard code using standard System.Net.Sockets classes.
This build includes the following features:
New: TCP sockets
UDP sockets
DNS support
Dynamic IP (DHCP) configuration support
Static IP configuration support
ICMP (ping) support
IPv4 and ARP support
Link detection support (and NetworkAvailability event)
ENC28J60 network chip driver
Retrieval of network configuration from NETMF configuration sector
For this test, please:
Run the attached Netduino Update app to reflash your Netduino Plus 2 with Netduino.IP Preview firmware.
Deploy and run the attached sample app--or test out your own existing TCP or UDP networking code
I have attached a sample project which requests the Netduino homepage and also retrieves the current time from an Internet time server.
If you run into any troubles, please let me know. Once we know that everything is working well here, we'll move Netduino.IP into release mode.
The main goals for Netduino.IP (for Ethernet) v1.0 are reliability and protocol compliance. As we move forward to Netduino.IP v1.1 and beyond we will focus in on performance enhacements, potential support for additional IP protocols/features, etc.
Thank you for taking the time to help us test out Netduino.IP!
Excelent news I want to test it, but I need your help, In the Netduino-IP source the Netduino_IP_Interop_Netduino_IP_Interop_NetworkInterface.cpp and the Netduino_IP_Interop_Netduino_IP_Interop_Wireless.cpp files does not have the code that implements the Interop, could you please add those files to the repository, also those files are missing in the Netduino.IP_CC3100 source.
Excelent news I want to test it, but I need your help, In the Netduino-IP source the Netduino_IP_Interop_Netduino_IP_Interop_NetworkInterface.cpp and the Netduino_IP_Interop_Netduino_IP_Interop_Wireless.cpp files does not have the code that implements the Interop, could you please add those files to the repository, also those files are missing in the Netduino.IP_CC3100 source.
Sorry for the confusion there. The managed code for Netduino.IP.Interop is in the Netduino.IP repo, but the native code gets compiled into the native code firmware (BSP). [So it should go over in the NETMF Interpreter branch.] We'll get that checked into the appropriate place with the NETMF 4.4 code--but in the meantime here is a copy of the native interop source to get you up and running.
Chris
P.S. The interop assembly is there to read the network config from the ER_CONFIG sector (i.e. the network configuration that is written with MFDeploy). The network stack itself is 100% managed code.
I think the best way to test is a working solution with all the written source code included. Then we can debug low level and find out what's wrong when a error pops up.
I've just flashed my N2+ with Netduino.IP build 6, and am trying out the stack tests. First observation is that the reference to GoBus.dll must be removed from the project before it will deploy to the N2+ hardware.
The stack tests worked flawlessly but yielded a question.
I noticed that at startup there is no activity on the network status LEDs, this is different behaviour to before when the network was active pretty much from powerup - but thinking about it it is to be expected.
Single stepping through the code, the line that seems to make the network interface wake up is where it subscribes to the NetworkAvailabilityChanged event. It seems pretty unusual to have such a massive 'side effect' depend on an event subscription. Am I just seeing a timing coincidence? What is it that actually triggers the network stack?
I have the TCP sockets implementation working pretty convincingly in my own app now. The app I'm testing is a robotic focuser for a telescope and is based on this network server:
I had to add some extra code to wait for the network to become available and to get its IP address from DHCP, along the lines of what was done in the stack tests. I didn't have to do that before but I probably should have been. Other than that, the rest of the sockets code seems to be working unchanged. Very encouraging!
One problem I had with the lwip stack is that it caused my application to freeze whenever it received data. The delays were long enough to cause me timing issues particularly with stepper motors, which would hesitate noticeably. I have yet to assess whether Netduino.IP will be any better in that respect, because I've misplaced the power supply that I use to power the motors. I probably need to acquire a new one - as soon as I do I'll assess the timing impact.
I think the best way to test is a working solution with all the written source code included. Then we can debug low level and find out what's wrong when a error pops up.
Great idea. I'll post a "debug" version with the new build. Then you can just add the source projects from the GitHub repo and debug interactively in Visual Studio.
I've just flashed my N2+ with Netduino.IP build 6, and am trying out the stack tests. First observation is that the reference to GoBus.dll must be removed from the project before it will deploy to the N2+ hardware.
Hmm, that shouldn't happen. With the new Netduino Universal app template, your Netduino Plus 2 should work fine with the GoBus assembly referenced. I'll check this out... Thanks for the bug report!
I noticed that at startup there is no activity on the network status LEDs, this is different behaviour to before when the network was active pretty much from powerup - but thinking about it it is to be expected.
Single stepping through the code, the line that seems to make the network interface wake up is where it subscribes to the NetworkAvailabilityChanged event. It seems pretty unusual to have such a massive 'side effect' depend on an event subscription. Am I just seeing a timing coincidence? What is it that actually triggers the network stack?
Netduino.IP includes some early power management functionality. Depending on how the board is configured, it will either initialize the networking chip when your app starts...or it will initialize the networking chip when the first networking code is executed. This new behavior is both a little different and a little smarter than lwIP; but if you have been using Netduinos for years then it might take a little while to get used to the improved system.
I had to add some extra code to wait for the network to become available and to get its IP address from DHCP, along the lines of what was done in the stack tests. I didn't have to do that before but I probably should have been. Other than that, the rest of the sockets code seems to be working unchanged. Very encouraging!
Oh yes... That's best practice and, really, should be done in every app. With lwIP you should do this too. In some ways I am glad that this best practice is now more apparent because with other stacks it could work when you wrote the code...and then just "not work correctly" in other circumstances.
And... Awesome! The goal here is to improve quality, increase functionality and maintain backwards compatibility. So I'm really happy to hear that your existing code is working unchanged so far.
One problem I had with the lwip stack is that it caused my application to freeze whenever it received data. The delays were long enough to cause me timing issues particularly with stepper motors, which would hesitate noticeably. I have yet to assess whether Netduino.IP will be any better in that respect, because I've misplaced the power supply that I use to power the motors. I probably need to acquire a new one - as soon as I do I'll assess the timing impact.
Some good news: this problem should now be gone. Native lwIP code could basically block the NETMF interpreter's thread switcher. With Netduino.IP the networking stack is under the managed runtime's control. Woot
I think the best way to test is a working solution with all the written source code included. Then we can debug low level and find out what's wrong when a error pops up.
Just add the two assemblies (Netduino.IP.csproj and Netduino.IP.LinkLayers.ENC28J60.csproj) to your solution, add them as references to your main project, and debug
Note: I had not yet updated to the May 2015 SDK (4.3.2) - perhaps that explains my difficulty with the GoBus assembly?
Ah, could be. When you get a chance, grab the 4.3.2 SDK and the Netduino.IP v1.0.0 firmware...and see if everything is linking up properly for you now.
NetduinoIP_StackTests.zip 4.06KB
22 downloads
