IrDA on 2.1 Devices (Part 1)
There seems to be a certail level of confusion about the actual IrDA capabilities of the MP2000, MP2100 and eMate, i.e. devices running NewtonOS 2.1. To make things short: OS 2.1 implements an almost complete IrDA stack up until IrLMP.
Now the long version of the story: IrDA support can actually mean a lot of things. In practice, an IrDA stack usually consists of at least three layers: IrPHY, IrLAP and IrLMP. Since it is a stack, these are layered on top of each other, meaning that for example IrLMP sends and receives data via IrLAP but adds its own control data to it. Other interesting layers are TinyTP, IrCOMM (both used for simple data transfer) and IrOBEX (exchange of structured objects).
IrPHY is the lowest layer and handles access to the send/receive hardware. In the case of the Newton, it is most likely a serial chip of some sorts connected to the IR diode. Meaning that you send data one byte at a time. On top of IrPHY sits IrLAP, the Link Access Protocol. It introduces the notion of a frame which contains three parts: An address field to specify who is the recipient, a control field that defines the purpose of the frame and a payload area that contains the data to be transmitted.
Now to IrLMP, the Link Management Protocol. It is of special interest to us since this is what we can use on the Newton. IrLMP is probably the most complex layer in the whole stack. Among other things, it introduces the Link Multiplex Sevice (multiple logical connections over one physical connection) and the Information Access Service (what services are offered by a specific device, e.g. IrCOMM or IrOBEX). The IAS can be seen as a simple directory that can be queried to find out more about the capabilities of the peer. Is organized in key/value pairs (so called Parameters) which are associated with a specific service (aka Class).
But what do we now do with all this? Simple: The IrDA stack on the Newton can be used to connect to any other IrDA-compatible device. No exceptions. Sounds nice, doesn’t it? But there is a catch: Other devices may have difficulties initiating a connection to the Newton and requesting a service other than TinyTP and IrOBEX. The reason is that the Newton’s IrDA stack can associate only one parameter with each service it provides. And some services require more than one parameter. Also, the service that the other device may connect to must be known beforehand. But overall, this is not a total catastrophy I would say, since actively connecting from the Newton side should still work (it definitely does for TinyTP, IrCOMM and IrOBEX).
More to follow…