| CONTENT: |
| |
| i2c.h |
| i2c1.c |
| i2c2.s |
| |
| WHAT ARE THESE FILES: |
| |
| These files contain MPC8240 (Kahlua) I2C |
| driver routines. The driver routines are not |
| written for any specific operating system. |
| They serves the purpose of code sample, and |
| jump-start for using the MPC8240 I2C unit. |
| |
| For the reason of correctness of C language |
| syntax, these files are compiled by Metaware |
| C compiler and assembler. |
| |
| ENDIAN NOTATION: |
| |
| The algorithm is designed for big-endian mode, |
| software is responsible for byte swapping. |
| |
| USAGE: |
| |
| 1. The host system that is running on MPC8240 |
| shall link the files listed here. The memory |
| location of driver routines shall take into |
| account of that driver routines need to run |
| in supervisor mode and they process I2C |
| interrupt. |
| |
| 2. The host system is responsible for configuring |
| the MPC8240 including Embedded Utilities Memory |
| Block. All I2C driver functions require the |
| content of Embedded Utilities Memory Block |
| Base Address Register, EUMBBAR, as the first |
| parameter. |
| |
| 3. Before I2C unit of MPC8240 can be used, |
| initialize I2C unit by calling I2C_Init |
| with the corresponding parameters. |
| |
| Note that the I2CFDR register shall be written |
| once during the initialization. If it is written |
| in the midst of transers, or after I2C STOPs or |
| REPEAT STATRs, depending on the data written, |
| a long reset time may be encountered. |
| |
| 4. After I2C unit has been successfully initialized, |
| use the Application level API to send data or |
| receive data upon the desired mode, Master or |
| Slave. |
| |
| 5. If the host system is also using the EPIC unit |
| on MPC8240, the system can register the |
| I2C_ISR with the EPIC including other |
| desired resources. |
| |
| If the host system does not using the EPIC unit |
| on MPC8240, I2C_Timer_Event function can |
| be called for each desired time interval. |
| |
| In both cases, the host system is free to provide |
| its own timer event handler and interrupt service |
| routine. |
| |
| 6. The I2C driver routines contains a set |
| of utilities, Set and Get, for host system |
| to query and modify the desired I2C registers. |
| |
| 7. It is the host system's responsibility of |
| queueing the I2C I/O request. The host |
| system shall check the I2C_ISR return code |
| for I2C I/O status. If I2C_ISR returns |
| I2CBUFFEMPTY or I2CBUFFFULL, it means |
| I2C unit has completed a I/O request |
| stated by the Application API. |
| |
| 8. If the host system has more than one master |
| mode I2C unit I/O requests but doesn't want |
| to be intervented by being addressed as slave, |
| the host system can use the master mode |
| Application API with stop_flag set to 0 in |
| conjunction with is_cnt flag set to 1. |
| The first API call sets both stop_flag and |
| is_cnt to 0, indicating a START condition |
| shall be generated but when the end of |
| transaction is reached, do not generate a |
| STOP condition. Once the host system is |
| informed that the transaction has been |
| completed, the next Application API call |
| shall set is_cnt flag to 1, indicating a |
| repeated START condition shall be generated. |
| The last Application API call shall set |
| stop_flag |
| to 1. |
| |
| 9. The I2C_Timer_Event function containes |
| a user defined function pointer. It |
| serves the purpose of providing the |
| host system a way to use its own event |
| handler instead of the I2C_ISR provided |
| here. |