I’m using these from a class that can be used by any device, so I would assume that these events will fire regardless of the device, when a cable is attached and detached the same goes for the IP Address change…
The Premium boards do not make use of those events. You’ll want to use the events NetworkInterfaceExtension.NetworkAddresschanged, EthernetENC28J60.CableConnectivityChanged, EthernetBuiltIn.CableConnectivityChanged, or WiFiRS9110.CableConnectivityChanged under GHI.Premium.Net.
you seem to be missing the point…
those events are standard netmf events and they shouldn’t be eaten, it looks like you are not bubbling up the events on the spider… where in fact you should…
I’m creating a CLASS that should work with any Device Premium or NOT… remember the whole purpose of using NetMF and Gadgeteer is the ease of moving code from one board to another without any changes…
so please check your code and make sure you allow the bubbling of the standard events…
again my class will be used by any board and should be able to detect network changes using standard NETMF code…
That’s my Point my class shouldn’t care to know if the device is, Premium, Not Premium, GHI, Mountaineer, Bambino, Wireless, Ethernet and so on… all it cares about is handling those situation when a cable is disconnected and connected to the device… and handle it’s business cleanly…
I really hope you guys review the Network Stack and fix it once and for all… because the more I dig into the more issues I find, and it almost feels like i’m back to where I was 2 years ago…
Sometime to add more features, you can’t be compatible with other systems. We try to stay away from this as much as possible but it is not always an option.
Actually I shouldn’t, since Microsoft Wrote the code to work on any board, so why should I reinvent the wheel, and instead I’d rather rely on the NETMF Code and work in a standard general way… your solution won’t work for a simple fact that we don’t know what future boards be, look like and do…
That’s fine and dandy but don’t break the standards, and add the premium stuff as interfaces or something that won’t effect the regular way we do things…
For instance:
the new way of assigning interfaces on the premium code shouldn’t have broken the standard way of using the network interface… meaning if I only have one interface I shouldn’t have to use and assign that interface just to use it what I should be able to do is copy the code I use for the Hydra, Cerbuino, and past it and done, IF however I have TWO interfaces (Ethernet, Wireless Two Ethernet Modules) than I should go about learning how to use the new interface and use it.
I hope this makes sense…and I hope to see the SDK updated to allow the use of standard NETMF Networking stack on the Premium boards.
I’m not using nor asking to use the premium on OSHS, what i’m asking is to not break standard code that should work OSHS and on Premium just because a board is a premium board… suddenly standard stops working and one would have to do things differently…
adding features to a premium should mean just that ADDING not replacing and breaking existing features to make others…
I hope this helps…
again all of this is just to help GHI realize that it’s been over 2 years now that we don’t have a reliable Networked Device from them…
if these things have any future they should tackle those issues immediately…
The networking stuff is pretty much a shambles at the moment, but, as I understand it, a lot of that is because the underlying network stack changed to lwip in 4.2.
Yes correct. Plus we changed the core to have 3 interfaces. Both are major changes. Things are much better now with couple issues here and there, which we are trying or best to cover. While netmf is open, it seem that we are the only ones working on it, at least currently and this requires s lot of resources. … hang on guys we are almost there.
May I recommend you guys add a couple of properties to the Mainboard Class:
since we know that we have a limited number of TCP, UDP sockets per board and that number differs from one board to another, and we know that the numbers are capped by the firmware and the firmware is tracking how many sockets are being consumed at a giving time and how many are left so why not help us all by introducing a couple of properties to the Mainboard class that would report the number of sockets available at any given time… ex
//Similar to the Mainboard.SetDebugLED() method
//add the following properties:
Mainboard.AvailableUDP
Mainboard.AvailableTCP
//the need for both is because we get a different amount of sockets for TCP and UDP...
//using the above I would be able to check how many sockets are left before attempting to open one.. like this:
if(Mainboard.AvailableUDP>0)
{
Socket mySocket = new Socket(..............);
}
does this make sense?
if the tracking is not done at the framework at least give us the amount of socket the board supports for each protocol…
