Porting Built-in Ethernet and I2C bytes sent

can you share or zip your whole project?

@Dat_Tran Did you get my email with the zipped project?

Not yet. Did you send to me directly ot somewhere else?

I replied to the support@ghielectronics.com email address with a link to google drive (can’t send .dlls with G Suite). This was at 9 pm wed night central time (just to help you find it). Is there a better way to get things like this to you?

Probably they are busy.
Just text directly to my message inbox in this forum the link.

Got it, support team sent to us. I will check and tell you result soon.

Hello, I just tried your example.

  1. Your MAC doesn’t work on mine. So you may need to change your MAC.
  2. in NetworkController_NetworkAddressChanged, where
linkReady =  true;

replace by:

linkReady = address[0] != 0 ? true : false;

MAC seems to the the issue. Next issue: It seems like not all the common socketoptions are functioning. Specifically, I get an exception on:

serverSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.DontLinger, true);

You can see the others I use in the example I sent. All of those at least dont through and exception. Need to do more testing to see if they are functional.

1 Like

Okay, I got all my code ported over and I wired the board into my system. However, the way data is being delivered to the NetworkStream from a socket is strange. It looks like the Nagle algorithm is causing some havoc.

I use an ASCII-based command structure to tell my device what to do from a PC-based program. I just use a plain socket protocol, so nothing fancy. This means that frequently my packet’s payloads are not full. If I watch the network with WireShark, I can see my commands being sent and ACK’d by the embedded side. The problem is, I have to send multiple commands before networkstream.read will return. I have set the NoDelay socket option to true on both the server and client sockets. I need the system to return data after every packet and not try to bundle it. Can you see why this is happening?

There is 2 versions of preview2, v2.0.0.20000 and v2.0.0.21000.

If v2.0.0.20000 is running correctly (but slow) then I know why.

But both has same issue then I have no idea yet.

I am trying some different network configurations to see if it is somehow the gear. I’ll get back to you after some more troubleshooting.

Hi Dat,
I looked into this a bit more. Here is my receive code:

        try
        {
            while ((read = ns.Read(buffer, readAll, buffer.Length - readAll)) > 0)
            {

                readAll += read;
                //ReadBytes = readAll;
                string rawMessage = new string(Encoding.UTF8.GetChars(buffer));
                response = processData(buffer);
                return response;
            }
            Thread.Sleep(20);
            return response;
        }

Now, the buffer is 100 bytes. The ns.Read won’t return until > 100 bytes have been received. For example, I have a command that is 38 bytes. I have to send this 3 times before ns.Read returns the first 100, then the second iteration of the loop immediately returns the last 14. This behavior is quite bizarre. Any ideas? Tried this on different networking kit as well. It looks like the signalling for this is suspect.

very short so I am not sure if I understood correctly.

But as I see no matter read > 0 or read <=0, it is always return 100 bytes in first loop, if 38 * 3 = 114 bytes are ready.

so second loop will get 14 bytes left.

your “while loop” is useless since you always return, but not sure if I am reading correctly.

Also, there is 2 version, can you please just download the older one.

The code around the ns.Read doesn’t really matter (it is a direct copy from functional code on a G120E using ethernet). The issue is that I MUST send >100 bytes for ns.Read to return. ns.Read is a blocking call, so in each iteration of the loop, it will block till data is received. Now, I can send the data in 38 byte chunks with infinite time between them and ns.Read will not return until at least 100 bytes (the size of the buffer) have been received. It will then return the first 100 and any leftover data. This is not how ns.Read should behave. It should routinely pump data on each packet received (so every 38 byte command sent). I will try to roll back to the older version shortly and see if that modifies the behavior at all.

how much for the timeout?

Infinite. I want the system to block till something comes in.

And same behavior on the preview1 package.

Thank you, we will check

Hi Dat. I went back to just my naked network test (that I sent you) and it does not show this behavior. I also used reflector to take a look up to the device firmware code and I can’t see any way that the system would know what size my buffer is. I will go through and disable portions of my larger project until I find what is causing the conflict and report back. This is very strange.

1 Like

Hi, can you verify preview3 ns.Read(…) is working as you expected ?