When designing the debug communications for exchanging debug information between the TIDE and the target, we had two important goals:
Allow maximum flexibility for your application and occupy minimum resources on the target.
Allow for fast and efficient debug communications.
The resulting debug communications system:
Does not even require a "proper" IP address on the target side.
Allows you to freely change the IP address of the target while debugging.
"Occupies" a single UDP port (65535) on the target, and even this port can be used by your program in most cases.
Your PC running TIDE sends debug messages as UDP datagrams, to target's port 65535. These messages include the MAC address of the target on which you are debugging your application.
The UDP port 65535 can still be used by your BASIC application. The target recognizes a datagram received on this port as a debug command only if this datagram starts with an underscore (_).
UDP datagrams received on UDP port 65535 that do not start with an underscore are not interpreted as debug commands by the target. Such datagrams are sent to your application for processing.
There are two slightly different communication modes for Tibbo devices. You can select them in the Project Settings dialog, from the transport drop-down list.
UDP broadcast transport
With this selection, debug commands are sent through the Ethernet network as UDP broadcasts. They are, therefore, received by all devices on your local network segment. Only the addressed Tibbo device will respond to the command. This is because each debug command contains a field specifying the MAC address of the target device. This method unnecessarily burdens all devices on the local network segment with having to "look at" all debug commands being transmitted. Also, some network equipment limits the amount of UDP broadcasts that can pass through it in one second. This may slow down your debug comms with the target.
With this selection, debug commands are sent through the Ethernet network as unicast UDP datagrams — the target device is addressed directly. This method is the preferred way of communicating with Tibbo devices. The method relies on a WinPCap library that must be installed together with TIDE software. You must have seen the request for this during TIDE installation. With WinPCap transport, only the target device receives the debugging commands, and there is no issue with slow comms because of restrictive network equipment.
In most cases, debugging commands sent by TIDE cannot go across gateways (routers). This means the target and TIDE must reside on the same network segment — remote debugging is not possible.
Also, debugging is not possible via Wi-Fi ports of Tibbo devices.