EnableStaticIP() not implemented in NetworkInterface class about netduino.ip HOT 27 OPEN

Thank you Techno GUy for reporting this. I reported it on the Netduino forums in May and have been waiting for a solution. I really need to get Static IP's working on the N3 or I won't be able to port my current products that a built on the N2+ to the N3.

from netduino.ip.

@mbeilste Have you found a solution?

from netduino.ip.

You can set up a Static IP address on a Netduino 3 manually, using the .NET Micro Framework Deployment Tool (MFDeploy). It just can't be done programmatically at run time (i.e. using the EnableStaticIP() method). This is in contrast to a Netduino 2 (with the original networking stack), where it can be done using the tool or at runtime.

It's not a matter of "finding a solution". The solution would be for the board's developer (or a member of the community) to step in and implement the missing functionality.

What I've described is a workaround.

from netduino.ip.

Actually, we have problems programmatically changing the IP information in the project. I understand that this model is not suitable for the project. Is not it ?

from netduino.ip.

No, as TheTechnoGuy said, it is an issue with the board's firmware and the developer stepping up and finishing the software to allow the IP's the be programatically set. I still have hope that will happen but am getting dangerously low on my stock of Netduinio 2 Plus's. If the Netduino 3 gets an update that would be fantastic, otherwise I'm worried I'll be porting a substantially sized project to another platform. :(

My application depends on reading the IP from the microSD card in a config file and setting up the IP of the Netduino. I'm aware MFDeploy will allow setting up IPs but my application requires that to be configurable on the fly.

@TheTechnoGuy , do you know who the developer is? Have you been in contact? Thanks!

from netduino.ip.

This is something we're looking into fixing. It's a bit complex, though. It's a combination of poor design in the .NET MicroFramework, and the decision made by Secret Labs to deal with it.

The issue (as I understand it), is this; when you set the IP at runtime, it actually gets written to flash. You can write to flash no problem, but you can only erase it in blocks, or maybe even just the whole card (research needs to be done here). There's not a ton of flash on these boards, so if you boot the board, and then write the IP every time the app starts, you start to eat up space. Eventually, you'll run out, and your app will just stop working (potentially in the field), with no warning or information whatsoever.

Secret Labs made a decision to prevent users from shooting themselves in the foot with this behavior by disabling the API in a later firmware. My understanding, is that if you update your N2 to the latest firmware, you'll lose the API there, too (though again, I'm not 100% sure).

Unfortunately, the correct way to fix this, is to write some sort of manager that will reserve an erasable block in the flash to store config values like this, and then erase and write as needed. Note that is not a trivial problem to solve; first, it would have to be written in C/C++ because the .NET code that runs on the device is interpreted and can't actually do this. Second, it would lower the total amount of available flash space (potentially, by a lot). Third, making it reliable might prove difficult; what happens if the board resets during, etc.

I think the right path forward for now, is to re-enable the API, and put a big compiler warning explaining the issue, so that folks can use the API at their own risk. Then we can recompile the firmware and release it as an update.

However, I'm waiting on some clarification from chris on some of the code. I believe this is the new code:

https://github.com/netduino/Netduino.IP/blob/master/Microsoft.SPOT.Net/NetworkInterface.cs#L156

This (I believe) is the old code where it works (possibly):

https://github.com/netduino/Netduino.IP_CC3100/blob/master/Microsoft.SPOT.Net/NetworkInterface.cs#L156

Anyhow, stay tuned, I know this is a frustrating issue.

from netduino.ip.

Thanks for the update and the explanation Brian. I appreciate it. Is Chris still around? The Netduino forum where I brought up this issue has gone dark. I haven't seen Chris on there in a long time. I along with some others figured he moved on from Secret labs.

As a software engineer I hate this question, but any idea when a solution might be ready?

Thanks again Brian!

from netduino.ip.

Chris is not. I purchased the Netduino IP (brand, designs, etc.) from Secret Labs and am working on re-launching it.

No date on a fix for this yet, as I'm still not sure actually how to. There are also other complications; evidently, to actually build the firmware, you have to use the commercial version of the Keil build tools which are now $5k. :) Otherwise, if you try to build the way the NetMF team describes, with GCC, it won't actually fit on the board or something.

Anyhow, all hopefully solvable. Stay tuned.

from netduino.ip.

Bryan,

That's for the info. That's very helpful. I was about to start working on porting my customer's projects to another platform but have been dragging my feet due to the amount of work.

In the meantime any source for Netduino 2 Plus boards while I wait for the Netduino 3 firmware?

Thanks!

from netduino.ip.

They're in assembly right now. My guess is that they'll be on Amazon and Mouser in a monthish.

from netduino.ip.

That's fantastic news. So what is the roadmap for the N2+? Will they be available in the future alongside the N3 or will they be discontinued?

from netduino.ip.

Not sure yet. They're basically the same board as the N3 Ethernet, but with a smaller MCU/RAM/etc. They're $10 cheaper at MSRP but basically cost the same to manufacture (we have almost zero margin on the N2+ at this point). There does seem to be a lot of pent-up demand for them though, so I have no near-term plans to discontinue.

What makes you want an N2+ over an N3E? Is it just the IP/Firmware issue?

from netduino.ip.

Yep. Firmware on the N2+ supports the software projects I'm shipping now and the N3 doesn't yet support them. Good news they will be available for the near term.

Thanks again!

from netduino.ip.

If the N3E supported the IP API, would you use them, or is the $10 price point a deal breaker?

FYI, I have 600 of them (N2+) in assembly at the present moment.

from netduino.ip.

It's a cost I would have to see if I can pass onto my customers that are using these systems. I would guess that would be alright with them but usually they want new features with increased cost. If the N2+ would remain available at the same cost that would be awesome. I have used a ton of them and been happy with them.

That's great news. Thanks Bryan (sorry - realized I spelled your name wrong above. :( ).

from netduino.ip.

Understood. Thanks for the feedback.

No problem on the name. Everyone gets it wrong. :D

from netduino.ip.

@bryancostanich we also bought the board but want to change some hardware properties of the board(adding can bus etc ) in hal level.do we need to compile new firmware using keil or can we do it writing .net microframework code...

from netduino.ip.

for this ip initiliazation problem there are alternatives for writing to flash memory of the controller.from schematics we saw that there is i2c board.you can provide i2c functions in firmware for reading ip info from i2c eeprom. (the board owner has to find i2c eeprom and solder is properly).also you can do the same thing from sd card or since the board can be usb host you can do it with a usb flash drive...

from netduino.ip.

@anilozbakir - I suspect that CAN support would have to be done at the c++ level, but i'm not sure, i'm still learning the internals myself. GHI supports CAN, so you may want to take a look and see if they've open sourced their code. I did a google search and some of it is here: https://bitbucket.org/ghi_elect/netmf-open-firmware/src/354380aac50987e62774a4db591cd10c35af8bbd?at=master

As for as alternatives to the IP config, I think the solution needs to be universal and simple. Shouldn't require external eeprom, etc. We're looking into some things right now. Stay tuned.

from netduino.ip.

actually CAN support is just an example.the problem is reaching to the special function registers of the microcontroller.if this can be done directly from hal you'll have a fully .net solution without creating a new firmware using c++.

if you want an independent solution for ip saving i think it is using a limited amount of microcontrollers memory as fat32

from netduino.ip.

@anilozbakir i see. well, i'm pretty sure anything in that arena will require c++ modifications. the things that are available via .NET MF are pretty minimal.

from netduino.ip.

dear bryan since the project is open source can anyone modify the source for minor changes?if so can you provide drivers for ax88796 and cc3100 which are missing in firmware source code?we'll try our changes on keil for modifications including the "EnableStaticIP() not implemented in NetworkInterface " issue

from netduino.ip.

i'm not sure what drivers you're referring to. everything we have (sans the compiler) is in that repo.

in any case, we're actively working on a fix for the IP stuff. stay tuned. :)

from netduino.ip.

i've checked couple of times for this drivers but check it again.thanks again.

from netduino.ip.

Bryan,

Any updates on this?

Thanks,

~Matt

from netduino.ip.

We've been working on it as part of our 4.4 firmware upgrades. You can follow the work in this branch. Unfortunately, no fix yet, but we've at least gotten to a point where we can build and debug the network stack.

from netduino.ip.

When will this be released? It has been a few years and no progress.
I have a code but I cannot use N3E. It was a waste of money!

from netduino.ip.