IrDA on 2.1 Devices (Part 2)
The most important missing parts of the Newton’s IrDA stack are TinyTP, IrCOMM and IrOBEX. Today, I’ll explain briefly TinyTP. TinyTP is the simplest protocol of the missing ones and is required for IrCOMM and IrOBEX. It ensures flow control by using so called credits that are exchanged between the peers. One single credit entitles a party to send one more IrLMP frame to the peer. If you run out of credits, you cannot send any packets any more and have to wait for a packet giving you fresh credits. The credits which are advanced to the peer are stored in the first byte of an IrLMP frame.
Implementing TinyTP on the Newton is not too difficult. It requires two things: One, the packet size has to be known to locate the credit byte (it’s always at the beginning of the packet), and two, we have to be able to send the initial credit when opening a connection. The first task is achieved by getting the packet size via the kCMOIrDAReceiveBuffers option. The second task is being done by using the kCMOIrDAConnectUserData option to pass in a single byte in the connect frame. It sets the initial credits for the peer and is typically set to 14.
A read via a TinyTP endpoint has to always request the full packet size. If there is not enough data, the endpoint will simply return a smaller packet. If we want to read more data, we have to do that in chunks the size of a packet. So some buffer management is needed. Of course also the TinyTP credit management, which comes into play when we want to send something or the peer has run out of credits while sending. But basically, as soon as we have the packet size and can send initial connection data, TinyTP can be implemented. I have put together a small test application that verifies this and it does look promising. Of course all the implementation work will be in C++ since we want to get down to the actual endpoint interface!
Next will be an explanation of IrCOMM…