Datasheet

Table Of Contents
171
ATmega32A [DATASHEET]
Atmel-8155D-AVR-ATmega32A-Datasheet_02/2014
21.6 Using the TWI
The AVR TWI is byte-oriented and interrupt based. Interrupts are issued after all bus events, like reception of a
byte or transmission of a START condition. Because the TWI is interrupt-based, the application software is free to
carry on other operations during a TWI byte transfer. Note that the TWI Interrupt Enable (TWIE) bit in TWCR
together with the Global Interrupt Enable bit in SREG allow the application to decide whether or not assertion of the
TWINT Flag should generate an interrupt request. If the TWIE bit is cleared, the application must poll the TWINT
Flag in order to detect actions on the TWI bus.
When the TWINT Flag is asserted, the TWI has finished an operation and awaits application response. In this
case, the TWI Status Register (TWSR) contains a value indicating the current state of the TWI bus. The application
software can then decide how the TWI should behave in the next TWI bus cycle by manipulating the TWCR and
TWDR Registers.
Figure 20-10 is a simple example of how the application can interface to the TWI hardware. In this example, a mas-
ter wishes to transmit a single data byte to a slave. This description is quite abstract, a more detailed explanation
follows later in this section. A simple code example implementing the desired behavior is also presented.
Figure 21-10. Interfacing the Application to the TWI in a Typical Transmission
1. The first step in a TWI transmission is to transmit a START condition. This is done by writing a specific
value into TWCR, instructing the TWI hardware to transmit a START condition. Which value to write is
described later on. However, it is important that the TWINT bit is set in the value written. Writing a one to
TWINT clears the Flag. The TWI will not start any operation as long as the TWINT bit in TWCR is set.
Immediately after the application has cleared TWINT, the TWI will initiate transmission of the START
condition.
2. When the START condition has been transmitted, the TWINT Flag in TWCR is set, and TWSR is updated
with a status code indicating that the START condition has successfully been sent.
3. The application software should now examine the value of TWSR, to make sure that the START condition
was successfully transmitted. If TWSR indicates otherwise, the application software might take some spe-
cial action, like calling an error routine. Assuming that the status code is as expected, the application must
load SLA+W into TWDR. Remember that TWDR is used both for address and data. After TWDR has been
loaded with the desired SLA+W, a specific value must be written to TWCR, instructing the TWI hardware
to transmit the SLA+W present in TWDR. Which value to write is described later on. However, it is impor-
tant that the TWINT bit is set in the value written. Writing a one to TWINT clears the flag. The TWI will not
start any operation as long as the TWINT bit in TWCR is set. Immediately after the application has cleared
TWINT, the TWI will initiate transmission of the address packet.
START SLA+W A Data A STOP
1. Application
writes to TWCR
to initiate
transmission of
START
2. TWINT set.
Status code indicates
START condition sent
4. TWINT set.
Status code indicates
SLA+W sent, ACK
received
6. TWINT set.
Status code indicates
data sent, ACK received
5. Check TWSR to see if SLA+W was
sent and ACK received.
Application loads data into TWDR, and
loads appropriate control signals into
TWCR, making sure that TWINT is
written to one
7. Check TWSR to see if data was sent
and ACK received.
Application loads appropriate control
signals to send STOP into TWCR,
making sure that TWINT is written to one
TWI bus
Indicates
TWINT set
Application
Action
TWI
Hardware
Action
3. Check TWSR to see if START was
sendt. Application loads SLA+W into
TWDR, and loads appropriate control
signals into TWCR, making sure that
TWINT is written to one, and TWSTA
is written to zero