You don't need to do the whole IrDA thing. We've done physical layer IrDA with PocketPC/Windows Mobile/Palm and you get transfer data at the byte level and then implement your own protocol on top of that. It's probably faster than trying to figure out IrDA. Each handheld will have a raw interface available to the IrDA UART and you can then just open the COM port on the handheld using Win32 API (CreateFile, etc). Just like sending a byte out the UART on a PC or 8051 (except you will need a good protocol because some of the bytes WILL be lost or bruised badly). The whole IrDA stack is way overkill.

The only trouble we ever had was with Palm units containing the TI OMAP proccessors. The UART in them implemented the IrDA packet framing in hardware, so you couldn't turn it off. We had to add IrDA framing to our protocol at the bottom, but it was pretty easy. It was just a buch of preamble and postamble bytes and a checksum or CRC that was never validated.

The microsoft.public.pocketpc.* newsgroups and the similar palm developer forums have TONS of information about it. See Google Groups.

The biggest hurdle is learning the WinCE tools and installation tools if you've never done handhelds before. The Win32 is exactly the same as on a PC. I use pretty much the same routines in CBuilder on the PC, including the threads, as in the handheld with Embedded Visual Tools . Most PC motherboards already have IrDA on them (check your motherboard manual). Theoretically you could prototype your firmware on a PC. Or if your handheld has a physical COM port and you have an RS232 cable, you can start there, work out the basics, then move up to over-the-air.

GB