123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105 |
- 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.
|