Main Site Documentation

Only 2 Network Sockets on Cerbuino and ENC28

#1

Hello guys,
this is rather disappointing to know that I only have TWO network sockets available on the Cerbuino and ENC28, I mean how can we call these IoT when you can’t even have what wiznet used to offer on PANDA which was 4 Sockets… what gives…???

here is a test code:



                ArrayList jayc = new ArrayList();

                var SCount = 1;

                while (true)
                {
                    Thread.Sleep(10);
                    try
                    {
                        jayc.Add(new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp));
                        Debug.Print("********** Socket Test " + SCount++ + " **********");
                        Thread.Sleep(10);
                    }
                    catch (Exception)
                    {
                        Debug.Print("********** Constaint Exception on Test " + SCount + " **********" + jayc.Count);
                    }

                }

here are the results of the above code:


********** Socket Test 1 **********
********** Socket Test 2 **********
A first chance exception of type 'System.Net.Sockets.SocketException' occurred in Microsoft.SPOT.Net.dll
An unhandled exception of type 'System.Net.Sockets.SocketException' occurred in Microsoft.SPOT.Net.dll

and the cerbuino device info:


DeviceInfo:
  HAL build info: 4.2.0.0, Copyright GHI Electronics, LLC
  OEM Product codes (vendor, model, SKU): 255, 0, 65535
  Serial Numbers (module, system):
    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  Solution Build Info: 4.2.6.0, Copyright (C) GHI Electronics, LLC

Now how can we increase the count to at least match the smaller chips… 4 Sockets…

Jay.

#2

no really!
since USBIZI back in the day could provide 4 using Wiznet…

so I would expect the Cerbuino family to provide at least that if not more…

Edit: the mountaineer Ethernet give the following results:


********** Socket Test 1 **********
********** Socket Test 2 **********
********** Socket Test 3 **********
********** Socket Test 4 **********
A first chance exception of type 'System.Net.Sockets.SocketException' occurred in Microsoft.SPOT.Net.dll
An unhandled exception of type 'System.Net.Sockets.SocketException' occurred in Microsoft.SPOT.Net.dll

as you can see it does provide 4 Sockets…

Cheers,
Jay.

#3

We will look into this.

#4

We took a look at the code and UDP sockets on the Cerberus are currently capped at 4. When I tested, I was able to create 3 UDP sockets as expected. Mountaineer, on the other hand, raised their limit to 5 UDP sockets from the default of 4, which is why you were able to create 4 sockets on there. We will look into raising our UDP limit from 4 to 5 in a coming SDK so that you have access to 4 UDP sockets.

As for why you can only create two, have you tried on a freshly flashed device? Is there any other code on the device beyond what you provided? Any services running that might consume a UDP socket? Perhaps Time Services?

#5

I thought TimeService wasn’t implemented in the OSHW products?

#6

brand new project, nothing but the test code… just to remove any doubts I kept the same project and replaced the board in the designer with the Mountaineer and got the 5 UDP on that board :frowning:

#7

In any case, or firmware has more features so more ram is used. Still, we are trying to squeeze in few more sockets as we speak.

#8

@ Gus -

Thank you :slight_smile:

#9

I know, but I think it’s unimplemented (as in, not included) in the OSHW products? I’d love to be wrong about that…

See, for example, this post: https://www.ghielectronics.com/community/forum/topic?id=10294&page=3#msg102648

#10

Pretty much any feature in NETMF can be “stubed” out. Meaning your managed code that uses the feature will compile, but at runtime you will get “not implemented” exception.

#11

If you’ve ever built the firmware using the PK, you know that there’s a very large list of major components that can be enabled and disabled.

This is necessary to make it possible to keep the size small enough for flash-limited devices.

#12

I would guess that it would, at least, I don’t know why it wouldn’t. The purpose of that class, however, I believe, is as an alternative to TimeService that works around some bugs.

What ought to happen is someone submits a patch to the core NETMF that fixes those bugs.

#13

Since there’s no money in NETMF for Microsoft (and never likely to be any), it’s not a priority.

#14

Right, because (as far as I know), as you said, there are no FTEs whose job it is to work on NETMF. It’s a side project for them, that they work on when they get around to it.