Only 2 Network Sockets on Cerbuino and ENC28

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.

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.

We will look into this.

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?

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

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:

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.

1 Like

@ Gus -

Thank you :slight_smile:

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

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.

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.

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.

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

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.