IR serial comms with an 8051

How it's done depends largely on what the other end of the link requires. Does the other end support IrDA at some level?

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.

If you need anything above IrPHY (e.g., IrLAP, IrLMP, IAS, etc.) things get ugly in a hurry. One easy way out is to use something like a Microchip MCP2150. This device interfaces between your UART and the IR transceiver, but at the top layer, implements IrCOMM (9-wire "cooked" service class), so takes care off all the big and messy lower layers.

You can also purchase IrDA stacks. For example, http://www.extendsys.com has an IrOBEX component that they claim fits in memory constrained devices (~8K code, ~200 bytes data).

I haven't looked, but maybe there are 8051 derivatives that have some IrDA built in, much like some do for USB.

I guess the best place to start is http://www.irda.org. The specs are all there free for downloading.

Hope this helps.

--Dan Henry

Maxim Application Note 631 illustrates the physical-layer only "IrDA" serial interface.

MCP2155 is the latest Microchip IrDA chip.

EMBEDnet have an 8051 IrDA stack; I think it comes to about US$8k
http://www.embednet.com/

There are various websites which deal with the TV-type remote control protocol, RC5; eg,
http://www.ustr.net/infrared/infrared1.shtml

For certain, the MCP2155 is the latest Microchip IrDA chip insofar as it was introduced later than the MCP2150.

I don't think Andrew was suggesting that the '2155 supersedes the '2150, but just to avoid any possible confusion, I should add that the '2155 is a complementary device to the '2150. The important distinction is that the '2155 supports DCE applications, whereas the '2150 supports DTE applications.

Thanks for the replies, couple of questions/ideas:

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

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

You may of guessed but I am looking for a low cost (money & program) solution.

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

Your PC will have "virtual" LPT and COM ports which use the IrDA link.

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

What do you mean by "IRDA tx/rx device?" are you thinking of those Microchip devices which embed the protocol in hardware? If so, then yes - I think that's the idea.

But if you're thinking of just replacing your MAX232 with an IR emitter & detector - well, you would get something, but it wouldn't be IrDA!
(this approach is used in Vending machines)

"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).

http://linux.alina.te.net.ua/hardw/irda/irda.html

Hello. I have the following scenario: a input data terminal (keyboard, display) and a colector device. Both use a PIC18F8720 microcontroller. My question is: Can I add to both card the combination encoder/transceiver (like TIR1000) attached in the uC UART, and any of then can act as primary device? In reality, TIR1000 can act as a primary IRDA device?
Tanks

"Both use a PIC18F8720 microcontroller"

So what does this have to do with Keil Software Tools, then?

http://www.keil.com/forum/