This driver seems harder to use than some other drivers?
Different TCP/IP stacks take different approaches and our driver has been deliberately designed to give programmers low level access to all functionality. By their nature TCP/IP stacks are complex and when implementing them on 8, 16 and 32 bit microcontrollers we prefer to be able to program “to the metal” to obtain optimum performance and versatility. This means that to carry out an operation like sending a UDP packet for instance, you may need to do slightly more work than if using some other drivers, but with the advantage that you know exactly what is happening, rather than it being hidden “under the hood”, and your not wasting memory or resources using a higher level function designed to cover all sorts of eventualities not relevant to your application.
Can a low end microcontroller really provide full TCP/IP functionality?
Yes. The real issue around TCP/IP functionality for embedded applications is typically not the capability of the microcontroller to provide the required functionality in a timely manor, but is the code space required for it. As microcontroller memory sizes get bigger and bigger this is no longer an issue even for really low cost devices. Here at embedded-code our engineers have designed many devices that use a simple 8 bit microcontroller and communicate using TCP/IP without any problems.
Is TCP/IP communications hard?
Absolutely not. Getting a communication link between two devices or PC’s using UDP is incredibly simple and very much like getting a communication link between two devices using RS232 serial ports. There’s a couple more things to setup and understand but other than that its simply a case of outputting some data byte by byte and at the far end receiving it byte by byte. However unlike RS232 your communicating over Ethernet, which means your two devices or PC’s can be in the same room or across the world from each other with no additional work required by you (well OK, you’ll have to setup your router to allow the incoming connection, but other than that there’s nothing more you have to do!).
TCP / UDP – Which Is Best?
You’ll probably come across programmers who say this isn’t even a question – use TCP because all the hard work is done for you. In many applications this is true and using TCP can make your life as a programmer very easy. However TCP has one very big drawback in embedded applications – when a packet gets lost or a remote device doesn’t respond you have to wait for the TCP stack to retry the communication several times, each after successively longer delays before it finally gives up. This is TCP’s big advantage and drawback at the same time. With UDP there is no re-try – if a packet gets lost you need to notice that you’ve not had a reply and send it again. To the hardened PC programmer this is task often not worthy of their genius, but to an embedded programmer this is something that can make UDP incredibly powerful and fast in time critical applications. Was it ever really a problem having to notice that a remote device hadn’t responded when talking to it using RS232? Well its no different when talking using UDP and you can use the same simple approaches to defining your communications link. UDP also has one other great advantage – it allows you to broadcast packets so that every device on the local network or in the devices sub net receives them – you can’t do that with TCP.
So the answer is, it depends on what you are doing. In terms of how the packets of data travel over the Ethernet links and Internet there is no difference – both get routed in exactly the same way. TCP is fantastic at offloading work from you as a programmer for many applications, but UDP is the obvious choice in a great many other applications where you need that raw control of what you are sending and receiving.
Can I Open And Use Multiple Sockets At The Same Time?
Yes. You specify the maximum number of UDP and TCP sockets that the driver will provide.
Is the driver suitable for 64 bit architectures?
The driver uses structures to efficiently match the layout of several TCP/IP packet headers. The contents of all the structures that can be read or written using pointers by the driver are correctly aligned for 8, 16 and 32 architectures, except the ARP packet structure (which the driver reads and writes per variable and avoids using pointers or sizeof() for 32 bit compilers that typically insert padding). The structures used are not however safe for 64bit architectures unless you compiler provides the option to force structures to not be padded. This is not an ANSI requirement, however many compilers will provide this option.
What’s Difference The Between Ethernet Switches & Hubs
First there we’re Ethernet hubs, then came expensive switches and now you are hard pushed to find a hub! Ethernet hubs are simple dumb devices. A transmission from a device on any of its ports is ‘seen’ by every other device. This is fine as Ethernet is designed based on this, with your nic dealing with detecting packet collisions etc. However it can start to be inefficient if you have a lot of devices all connected by hubs. Ethernet switches on the other hand are intelligent. A switch learns (or is configured to know in the case of managed switches) what devices are connected to each of its ports and when a device transmits if the switch knows on which of its ports the device that the packet is intended for is, it only sends the packet to that port. This means that all the other ports are not blocked because one device is transmitting and they can transmit themselves at the same time with the switch handling buffering of packets if need be. In terms of improving a networks bandwidth switches are great. However they have two drawbacks.
Firstly when debugging you may want to monitor the traffic being transmitted between other devices. You can’t do this using a switch, unless the packets are broadcast UDP packets. However with a hub every device see’s everything being sent so any device can monitor the traffic. Incidentally this is why many hotels are a hackers paradise as often cheaper or older hubs are installed so connecting a sniffer in any room allows you to see everyone else’s traffic. The same is true of public WiFi hotspots and its why if you are doing anything at all sensitive on public Internet connections (even just checking your email) you should use https or a VPN service to encrypt your traffic.
Secondly switches often have to buffer packets. This means that an element of uncertainly can be introduced in very time critical applications as a busy switch may buffer a packet for an unknown amount of time before it is finally passed to the remote device.