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

3.3 Implementing IrLAP

The approach for the implementation of the IrLAP layer was to develop functions performing all the tasks described in the primitives that also behave according to the state tables found in the IrDA Lite documentation. This layer depends on the services provided by the IrPHY layer to function properly. This layer provides a reliable connection for data transfer.

To process the frames correctly, first it is necessary to know which of the three classes of frames is being handled. The three types of frames in IrLAP are supervisory (S), information (I), and unnumbered (U). The most effective way to identify the frame is through parsing of the bytes. As soon as the byte pattern that identifies a certain type of frame is found, the program jumps to the routines responsible for its handling. Then, as the bytes are identified and decoded, actions are taken depending on the primitive to which they correspond as shown below in a code excerpt from the application. This routine is called IR_MSG_PROCESS, and it is the piece of code responsible for parsing of the frame and sending the data to the right primitive for processing.

It is simple to identify which type of frame was received, given the bytes used to identify each command. It is enough to check one or two bits of the byte which are in a certain position to identify the IrLAP command that was received. After the command has been identified, the proper response is generated and sent through the IrPHY layer to the transceiver. After this, the program goes back to the main loop and waits until the next frame is received from the primary.