Netduino home hardware projects downloads community

Jump to content


Photo

Netduino.IP Technical Preview (Build 6)


  • Please log in to reply
11 replies to this topic

#1 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 28 June 2015 - 06:02 AM

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!

Chris

P.S. Netduino.IP source code has been checked into the Netduino repository at GitHub.
https://github.com/n...ino/Netduino.IP

Attached Files



#2 mupedrozo

mupedrozo

    New Member

  • Members
  • Pip
  • 3 posts

Posted 29 June 2015 - 07:18 AM

Hi Chris, 

 

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.

 

Thanks and regards,

 

Muller

Bytte



#3 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 29 June 2015 - 04:09 PM

Hi Bytte,

Thanks for your help!
 

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.

Attached Files



#4 JoopC

JoopC

    Advanced Member

  • Members
  • PipPipPip
  • 148 posts

Posted 30 June 2015 - 05:40 AM

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.

#5 NameOfTheDragon

NameOfTheDragon

    Advanced Member

  • Members
  • PipPipPip
  • 112 posts
  • LocationCanterbury, Kent, UK

Posted 02 July 2015 - 10:04 PM

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?

 

--Tim Long



#6 NameOfTheDragon

NameOfTheDragon

    Advanced Member

  • Members
  • PipPipPip
  • 112 posts
  • LocationCanterbury, Kent, UK

Posted 02 July 2015 - 11:22 PM

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:

https://github.com/N...CommandProtocol

 

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.

 

Looking good so far!

--Tim Long



#7 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 July 2015 - 07:01 PM

Hi JoopC,

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.

Chris

#8 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 July 2015 - 07:07 PM

Hi Tim,

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.

Chris

#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 July 2015 - 07:11 PM

Hi Tim,

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

Chris

#10 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 04 July 2015 - 12:11 AM

Hey JoopC,

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 have posted a debug build of Netduino.IP firmware over on the Netduino.IP v1.0 thread...
http://forums.netdui...plus-2/?p=63371

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

Chris

#11 NameOfTheDragon

NameOfTheDragon

    Advanced Member

  • Members
  • PipPipPip
  • 112 posts
  • LocationCanterbury, Kent, UK

Posted 04 July 2015 - 03:33 AM

Note: I had not yet updated to the May 2015 SDK (4.3.2) - perhaps that explains my difficulty with the GoBus assembly?

--Tim



#12 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 04 July 2015 - 03:43 AM

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.

Thanks Time!

Chris




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.