With regards to the devices the support native socket connection; is it true that the TCP (OSI Layer 4) is handled entirely by the the uC?
I prefer to ask not to assume. So if a packet is dropped by a remote host the uC will automatically retransmit it after the timeout has expired correct?
This is a very important and required part of the networking stack.
Which is why wifi to serial bridges just won’t cut it? The message may get corrupted or dropped being sent over the UART/SPI/I2C interface and never retransmitted?
@ andre.m, So the implementation of the protocol on native sockets is the true protocol not some sort of api to the device. Correct.
Whatever component implements the TCP protocol will handle the retransmits. In the case of the WIZ5100, it’s the WizNet module that handles it. In the case of the ENC28J60, I believe the host MCU handles it. Same when you’re using the built-in MAC with an external PHY.
The retransmit is at the TCP level. If the TCP packet is lost, then it will be retransmitted. If you’re using a device that implements the TCP protocol in hardware, and the packet is lost over serial, then it indeed won’t be retransmitted, because the TCP stack has already acknowledged receipt. If you’re using something that leaves the TCP handling to the host MCU, then losing the packet over serial would indeed cause the packet to be retransmitted.
I don’t know why you’d say that wifi to serial bridges “just won’t cut it,” however. The ENC28J60 is an ethernet-to-serial bridge, and it “cuts it”. The RS21 module uses the RS9110-N-11-21-01, which is a wifi-to-serial bridge. Unless you’re using the built-in MAC with an external PHY, you’re using a something-to-serial bridge.
I think he meant that if the data is lost or corrupted on the serial interface from the CPU to the TCP unit, then TCP retransmission will not help if the TCP protocol is not handled by the CPU.
And I think that’s true.
In fact you could switch to UDP and implement your own flow control which includes the serial connection then.
1 Like
Yes that is it exactly. I’ve had to switch to UDP because data wasn’t coming over the UART or SPI interfaces correctly and was therefore dropped. Other times the wifi device would simply drop the tcp packet and not send it at all (most frustrating).
So then for .netmf devices if you can’t use sockets natively on the device then you’re doomed, because the protocol you write on the device has to also be implemented on everything the device has to talk to; which is not practical.
1 Like
I think most of the WiFi solutions around here are of the its-all-on-the-wifi-device variety, so yeah, when the serial link fails, you wouldn’t get a retransmission.
Have you looked into what is causing your serial link to fail? I don’t believe that should be happening often, if ever.
@ godefroi, I think it’s electrical noise causing it to drop; every so often a message that doesn’t pass checksum shows up. This also means that the radio isn’t getting my messages either. It’s either that or Firm Errors 
(thanks fukushima)
Try shorter wires? Cleaner power supply?
The Gadgeteer power modules can be pretty noisy.