The IrDA stack is like TCP/IP or USB. Lots of overhead that once you master it, lets you move your data around. In all cases, your data is only a small portion of the bytes going back and forth. When doing IrComm, everything appears like a (virtual) serial port. Send a byte on one end and through the magic of the protocol it sooner or later shows up at the other end. The cost for this is either writing your own implementation of the IrDA stack, including the IrComm "class" or buying one (hardware such as the Microchip part, or software).

What we did instead was just use the IrDA LEDs (so to speak). People often call this raw IrDA. Hardware-wise the Tx UART connects to the IrDA LED and basically just sends the byte out (simplification). On the other end, the Rx UART receives the byte, sometimes whole, sometimes mangled. So what you do is packet-ize your bytes with some start characters, maybe a sequence number, checksum or crc and then an end character. Then the receiver acknowledges the transmitter when it gets a good packet and the transmitter moves to the next one, or if the ack is missing, resends the same one. You can imagine it takes a bit of work to come up with a good protocol or scheme. My point was that it was faster for us to make our own than build up the IrDA one from scratch. The IrDA one is quite complex because it's general purpose, do-it-all. For experienced hands making your own is pretty easy. If you are a rookie it will be a larger (longer) task either route.

To get at the raw IrDA on the handheld, you simply open up the physical COM port associated UART connected to the LEDs. On som units you may also need to EscapeCommFunction(hComPort, SETIR) if the UART is shared.

Check those newsgroups I mentioned. The topic is covered extensively there.

GB