IR serial comms with an 8051

"1. Is is possible to use an IRDA port on a PC in the same way as a RS232 port?"

If, by PC, you mean one running one of Microsoft's desktop OS's, I think the answer is no. On these systems, I believe MS has wrapped up IrDA into the Winsock API and your device would have to use one of the aforementioned IrCOMM devices.

If your "PC" can be a PC-like host running Microsoft's Windows CE or a PDA (e.g., Palm, Handspring, etc.), I think the answer is yes. These systems allow "raw" IR (please don't confuse this use of "raw" with IrCOMM's raw modes). What I mean by raw, is what I think you want -- the ability to talk through a UART, but have the UART's output routed to an IrDA encoder/decoder and IR transceiver (IrPHY SIR) instead of routed to the RS-232 driver. These OS's give you the ability to select where the UART's output goes; RS-232 or IR. In this raw IR configuration, you would be using a non-IrDA-compliant method, but for some applications, this is just fine.

"2. Can an IRDA tx/rx device be put in place of a RS232 driver (MAX232)?"

Yes, this is what I was referring to in my original answer, which I have included again here.

If you can get by with the IrPHY (physical) layer only, on the 8051 side you need an IrDA transceiver module (LED & photodetector) at a minimum. Then either add a standalone IrPHY encoder/decoder between the 8051 UART and the transceiver, or implement the pulse encode/decode in firmware.

The "standalone IrPHY encoder/decoder" would be something like a Microchip MCP2120, Texas Instruments TIR1000, Vishay TOIM4232, etc. Use these devices between the 8051 UART and the IR transceiver module. You can also substitute the "standalone IrPHY encoder/decoder" with firmware that implements their functionality and using this method, all your so-called serial I/O does not go through the UART, leaving the UART free for normal RS-232 comms if you wish. Having done this myself with another (non-8051) microcontroller, I can say that if you go this route, you would probably want to select an 8051 derivative with timer capture/compare capability for anything 9600bps or higher (YMMV).

"1. Is is possible to use an IRDA port on a PC in the same way as a RS232 port?"

If, by PC, you mean one running one of Microsoft's desktop OS's, I think the answer is no. On these systems, I believe MS has wrapped up IrDA into the Winsock API and your device would have to use one of the aforementioned IrCOMM devices.

If your "PC" can be a PC-like host running Microsoft's Windows CE or a PDA (e.g., Palm, Handspring, etc.), I think the answer is yes. These systems allow "raw" IR (please don't confuse this use of "raw" with IrCOMM's raw modes). What I mean by raw, is what I think you want -- the ability to talk through a UART, but have the UART's output routed to an IrDA encoder/decoder and IR transceiver (IrPHY SIR) instead of routed to the RS-232 driver. These OS's give you the ability to select where the UART's output goes; RS-232 or IR. In this raw IR configuration, you would be using a non-IrDA-compliant method, but for some applications, this is just fine.

"2. Can an IRDA tx/rx device be put in place of a RS232 driver (MAX232)?"

Yes, this is what I was referring to in my original answer, which I have included again here.

If you can get by with the IrPHY (physical) layer only, on the 8051 side you need an IrDA transceiver module (LED & photodetector) at a minimum. Then either add a standalone IrPHY encoder/decoder between the 8051 UART and the transceiver, or implement the pulse encode/decode in firmware.

The "standalone IrPHY encoder/decoder" would be something like a Microchip MCP2120, Texas Instruments TIR1000, Vishay TOIM4232, etc. Use these devices between the 8051 UART and the IR transceiver module. You can also substitute the "standalone IrPHY encoder/decoder" with firmware that implements their functionality and using this method, all your so-called serial I/O does not go through the UART, leaving the UART free for normal RS-232 comms if you wish. Having done this myself with another (non-8051) microcontroller, I can say that if you go this route, you would probably want to select an 8051 derivative with timer capture/compare capability for anything 9600bps or higher (YMMV).