SLAA202B February   2005  – December 2018 MSP430F149 , MSP430F149 , MSP430F2252-Q1 , MSP430F2252-Q1 , MSP430F2272-Q1 , MSP430F2272-Q1 , MSP430F2274 , MSP430F2274 , MSP430FG4619 , MSP430FG4619

 

  1.   Implementing IrDA With MSP430™ MCUs
    1.     Trademarks
    2. 1 Introduction
    3. 2 Hardware Description
      1. 2.1 Hardware Overview
      2. 2.2 Circuit Description
    4. 3 Software Description
      1. 3.1 Implementing IrPHY Layer Using Timer_A
        1. 3.1.1 Transmission
        2. 3.1.2 Reception
      2. 3.2 Implementing IrPHY Layer using USCI_A0
      3. 3.3 Implementing IrLAP
        1. 3.3.1 Discovery Services
        2. 3.3.2 Connect Services
        3. 3.3.3 Data Services
        4. 3.3.4 Disconnect Services
      4. 3.4 Implementing IrLMP
        1. 3.4.1 Discovery Services
        2. 3.4.2 Link Connect and Connect Services
        3. 3.4.3 Data Services
        4. 3.4.4 Disconnect Services
      5. 3.5 IAS Implementation
      6. 3.6 TTP Implementation
      7. 3.7 IrCOMM Implementation
      8. 3.8 Application Layer
    5. 4 PC Demonstration Application
    6. 5 IrDA Protocol Basics
      1. 5.1 Physical (IrPHY) Layer
      2. 5.2 Link Access Protocol (IrLAP) Layer
      3. 5.3 Link Management Protocol (IrLMP) Layer
      4. 5.4 Information Access Services (IAS)
      5. 5.5 Tiny Transfer Protocol (TTP)
      6. 5.6 IrCOMM
    7. 6 IrDA Communication Diagram
    8. 7 Frame Exchange Log
    9. 8 References
  2.   Revision History

5.6 IrCOMM

IrCOMM is serial and parallel port emulation over IR, also known as wire replacement. It provides four different services: 3-wire raw, 3-wire cooked, 9-wire, and Centronics. For this application, the IrCOMM 3-wire services are implemented. 9-wire services are needed to communicate with Windows. Because the Windows IrDA stack does not actually handle the control channel, it is possible to achieve communications with Windows by the same means as 3-wire cooked as long as the 9-wire service is advertised.

The 3-wire cooked service class makes use of TTP flow control, so that it may coexist with other connections that employ a higher level (not IrLAP) flow control (including other cooked IrCOMM connections). Therefore, it is not limited to a single IrLMP connection. It also supports a control channel for sending information like data format. Because of the need for flow control and the use of the control channel, the 3-wire service type uses a more elaborate frame format.

IrCOMM introduces a new service hint bit to indicate that the device supports IrCOMM services. The IrCOMM IAS entry is IrDA:IrCOMM with the following attributes: LsapSel and Parameters. The LsapSel attribute is needed to make a connection. The Parameters attribute allows the client application to distinguish among multiple IrCOMM services, because many different applications can use serial and parallel ports to communicate. It has at least the service-type parameter with at least the 3-wire cooked-bit set. The LsapSel attribute is also the unique address of the service within the context of one device and is needed to connect to that service. If the IrDA:IrCOMM IAS entry is for 3-wire cooked service, then the format to be used is IrDA:TinyTP:LsapSel.

The Parameters attribute contains one or more values which characterize the IrCOMM service being provided. The attribute Parameters is mandatory, and it is to have a value type of octet sequence (002h). Each parameter in the Parameters attribute consists of tuples of 3 (PI, PL, and PV). The parameters that can be set are service type, port type, and fixed port name.

3-wire connections can coexist with other nonexclusive IrLMP connections. This is because 3-wire cooked uses TTP flow control, a method which allows various connections with their own flow control to exist concurrently. Despite the presence of a control channel, 3-wire cooked cannot emulate hardware handshaking, because nondata signals are not emulated. If hardware handshaking is required, then the 9-wire or Centronics service type is necessary.

In 3-wire cooked, the control channel is used for three purposes:

  • Selecting the service type
  • To exchange port communication settings (data rate, data format, and flow control information) when emulating a serial port
  • For certain Type 2 devices to deliver port line status (overrun, parity, and framing errors) back to Type 1 devices