The driver consists of the TWI Interrupt Service Routine and six functions. All functions are available for use outside the driver file scope. However, some of them are also used internally by the driver itself. All functions in the driver are listed in the following table.
Function Name | Description |
---|---|
void TWI_Master_Initialise( ) |
Call this function to set up the TWI master to its initial standby state. Remember to enable interrupts from the main application after initializing the TWI. |
|
Call this function to send a prepared message. The first byte must contain the slave address and the read/write bit. Consecutive bytes contain the data to be sent, or empty locations for data to be read from the slave. Also include how many bytes that should be sent/read including the address byte. The function will hold execution (loop) until the TWI_ISR has completed with the previous operation, then initialize the next operation and return. |
void TWI_Start_Transceiver( ) |
Call this function to resend the last message. The driver will reuse the data previously put in the transceiver buffers. The function will hold execution (loop) until the TWI_ISR has completed with the previous operation, then initialize the next operation and return. |
unsigned char TWI_Transceiver_Busy(
) |
Call this function to test if the TWI_ISR is busy transmitting. |
unsigned char TWI_Get_State_Info(
) |
Call this function to fetch the state information of the previous operation. The function will hold execution (loop) until the TWI_ISR has completed with the previous operation. If there was an error, then the function will return the TWIState code. |
|
Call this function to read out the requested data from
the TWI transceiver buffer. I.e. first call
TWI_Start_Transceiver to send a request for data to
the slave. Then run this function to collect the data when they have
arrived. Include a pointer to where to place the data and the number of
bytes requested (including the address field) in the function call. The
function will hold execution (loop) until the TWI_ISR has completed with
the previous operation, before reading out the data and returning. If
there was an error in the previous transmission the function will return
the TWI error code. |
ISR(TWI_vect) (For
GCC) /
|
This function is the Interrupt Service Routine (ISR), and is automatically called when the TWI interrupt is triggered; that is, whenever a TWI event has occurred. This function should not be called directly from the main application. |
The following table consists the description of the driver register byte containing status information from the last transceiver operation. Available as bit fields within a byte.
TWI_statusReg |
Description |
---|---|
TWI_statusReg.lastTransOK |
Set to 1 when an operation has completed successfully. |
The following figure shows a flowchart of the process of sending and requesting data over the TWI interface through the drivers. Data is passed through parameters to the functions while the status of an operation is available trough a global status variable.
The following figure shows a flowchart, which contains the description of TWI Driver itself . The Transceiver function copies the complete message into the transmission buffer. Then it enables the TWI Interrupt to initiate the transmission. The Interrupt then takes care of the complete transmission and disables itself when the transmission is completed, or if an error state occurs. This way the driver can poll the interrupt enable bit to check if a transmission is ongoing. The main application is only allowed to access the global transceiver variables while the TWI transceiver is not busy. The interrupt stores eventual error states in a variable that is available for the main application through a function call.
The following flowchart shows a more detailed description of the actions for each event/state in the TWI Interrupt Service Routine. The left column contains the different states/events the TWI state machine can be in when entering the Interrupt. A case switch executes the different actions dependent on the cause of the interrupt call.