The latest difficulty (as if there haven’t been enough) was to find a place where to handle the IrCOMM specific data in the regular IrDA data flow. My first idea was to use the StartOutput and GetComplete funcitons as hooks. But again, the NewtonScript layer caused some trouble. To get it working anyway, the inner workings of the TIrDATool had to be exposed a bit more.
The TIrDATool class is derived from TAsyncSerTool. TAsyncSerTool provides asynchronous serial I/O via two ring buffers (TCircleBuf class), one for reading, one for writing. On the MP2x000, the ring buffers are filled by the Voyager chipset using DMA.
The two scenarios that had to be investigated further are reading and writing. In the TIrDATool class, this involves copying data from the ring buffers to the buffers used by the comm layer (and thus by the NewtonScript layer). These buffers are parameters to the StartInput and StartOutput functions. They are instances of the CBufferList class and are directly linked to the parameters given to the Input and Output functions of the associated NewtonScript endpoint. And this is also the reason why hooking into StartOutput and GetComplete doesn’t work quite well: These buffers do not reflect any of the packet-related characteristics of the IrDA data flow, they are merely holding the final streams of data.
So there has to be a way to get into the data flow from the ring buffers to the target buffers. This data transfer is done in the DoOutput and DoInput methods of TIrDATool. In fact, these methods are called for any IR data transfer, including the low level IrLMP and IrLAP packets. Quite handy.
Since there is some protocol overhead and logic for IrDA, the TIrDATool uses a number of helper classes. The most important one is TIrSIR. TIrSIR uses TIrLAPPutBuffer for any outgoing requests and contains a CBufferSegment for the incoming data. The task is now to put the IrCOMM data into the TIrLAPPutBuffer before sending and removing the IrCOMM data from the CBufferSegment after receiving.