Professional Documents
Culture Documents
00245a PDF
00245a PDF
00245a PDF
Keypad
INT (optional)
SDA
SCL
S P
Start Change Change Stop
Condition of Data of Data Condition
Allowed Allowed
FIGURE 3: REPEATED-START
CONDITION
SDA = 1,
SCL = 1
1st Bit
SDA
SCL
Sr = Repeated START
DS00245A-page 4
AN245
SCL S 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 P
Data on GP0
DATA VALID
tGPV0
Data on GP1 VALID
DATA
t GPV1
TYPICAL I2C™ WRITE TRANSMISSION FORMAT
Start
SCL S 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9
S 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 P
When the master is receiving data during read mode Although reading data from the slave by the master is
(Figure 8), it generates an acknowledge signal for each very simple, some safeguards need to be
received byte of data except for the last byte. To signal implemented.
the end of data to the slave-transmitter, the master gen- To ensure proper functioning of the device, follow the
erates a “not acknowledge” (NACK) condition master reading sequence flowchart shown in Figure 9.
(ACK=1). This is very important for proper functioning
of read mode. The slave then releases the SDA line so
the master can generate the STOP condition. If the
slave needs to delay the transmission of the next byte,
it may hold the SCL line low to force the master into a
wait state. Data transfer continues when the slave
releases the SCL line. This allows the slave to move
the received data or fetch the data it needs to transfer
before allowing the clock to start again. This wait state
technique can also be implemented at the bit level.
The protocol used to communicate with the MCP23016
for a read operation is as follows: A START condition is
generated, followed by the slave address with the
LSb=0 (R/W=0 to indicate a write condition). The com-
mand byte is then transmitted (the command byte is
like an address pointer. It gives the address of the reg-
ister to read from). This is followed by a REPEATED-
START condition. The slave address is transmitted
again but with the LSb=1 (R/W=1 to indicate a read
condition). The master waits for the slave to release the
SCL before beginning to clock the first data byte. After
receiving the first data byte, the master waits again for
the SCL to be released before clocking the second data
byte. This can be followed by more data bytes as long
as the master keeps acknowledging after each data
byte. At the end of the last data byte, the master needs
to generate a NACK before issuing a STOP or
REPEATED-START condition.
Load SSPBUF with MCP23016 Note 1: The master needs to wait for
address (lsb=0) I2C bus idle to indicate that
the MSSP module has fin-
ished its last task. The
Wait for I2C bus to be Idle: SSPIF interrupt could be
ACKEN=RCEN=PEN=RSEN=SEN=R/W=0 used instead of the wait for
Command
following a STOP or a
Read
REPEATED-START. This
Load SSPBUF with MCP23016 would cause the MCP23016
address (lsb=1) to lock up.
Read SSPBUF
Issue an acknowledge:
BCF SSPCON2.ACKDT
Wait for I2C bus to be Idle: Note 1: The master needs to wait for
ACKEN=RCEN=PEN=RSEN=SE=R/W=0 I2C bus idle to indicate that
Then wait 12 µs. (Note 2) the MSSP module has fin-
ished its last task. The
SSPIF interrupt could be
Set Receive Enable Bit used instead of the wait for
BSF SSPCON2.RCEN idle (the interrupt is not used
in this application note).
2: A 12 µs delay is inserted, as
stated in the MCP23016
Read SSPBUF datasheet. If a 12 µs delay is
not inserted, it can lead to
Data2
Wait for
Yes
MCP23016
While (I<=128)
{check_CCP_status(); FIGURE 13: CHECK_CCP_STATUS()
write I and J to MCP23016; SUB-ROUTINE
DelayMs(100);
Shift I to the left;
FLOWCHART
Shift J to the right;}
No
Is Flags=0x01? Return
While (I<=1)
{check_CCP_status(); Yes
write I and J to MCP23016;
Call GetNewValue()
DelayMs(100);
sub-routine
Shift I to the right;
Shift J to the left;}
Save LSB_old,
Save MSB_old
Yes
Read new LSB, and MSB Is RC1=0 (is the interrupt still set?)
DelayUs(250);
Yes No
Is LSB_old=LSB: Yes
and Is RC1=0 (is the interrupt still set?)
MSB_old=MSB;?
No
No
VDD
270 Ω 270 Ω
GP
LED
SWITCH
VDD
4.7 kΩ
DS00245A-page 14
PU1
GP0.0
GP0.1
GP0.2
GP1.0 GP0.3
GP1.1 GP0.4
GP1.2 GP0.5
GP1.4 GP0.7
GP1.5
GP0.1
GP1.6
GP1.7
GP0.2
INT GP0.3
GP0.4
GP0.5
GP0.6
SCL
GP0.7
SDA
GP1.0
GP1.1
GP1.2
PU1
PU2
PU3
GP1.3
GP1.4
GP1.5
GP1.6
MCP23016 I/O EXPANDER SCHEMATIC (SHEET 1 OF 2)
GP1.7
PU2
PU3
RD7_2
RD6_2
RD5_2
RD4_2
RD3_2
RD2_2
RD1_2
RB0_2
RD0_2
RB1_2 RB1_2
RB2_2
RB3_2 SDA
RB2_2
RB4_2 SCL
RB5_2
RB7_2
RB4_2
OSC1_2 RB5_2
RB6_2
RB7_2
RD0_2
RD1_2
RD2_2
RD3_2
OSC1_2
RD4_2
RD5_2
RD6_2
MCP23016 I/O EXPANDER SCHEMATIC (SHEET 2 OF 2)
RD7_2
PU4
AN245
DS00245A-page 15
AN245
APPENDIX B
I/O EXPANDER INTERFACE CODE
Master Firmware
The master firmware initializes the variables, ports,
A/D module, I2C module and CCP module of the
PIC16F877A, then waits for the MCP23016 Power-On-
Reset to initialize the I/O Expanders registers. The
code enters an infinite loop which checks if a CCP2
interrupt has occurred, then transmits two bytes (“i” and
“j”) which implement an “LED chaser” type of pattern.
If an interrupt occurs, the code jumps to the interrupt
subroutine which clears the CCP2 interrupt flag
(CCP2IF=0) and sets a software flag (Flags=0x01) so
that the interrupt can be serviced later. When the
Check_CCP_status() routine is called, it checks the
software flag. If the software flag is clear, the code
returns to the “main”. If the software flag is set, the code
jumps to GetNewValue() routine which reads the port
values from the slave device and displays the read
values on PORTB (LSB) and PORTD (MSB).
The firmware is setup to read from and write to the
same address. It is possible to have the MCP23016
connected with another I/O Expander device on the
same address and write to both of them at the same
time. A second MCP23016 with a different address can
be added with some code modification.
• Microchip believes that its family of products is one of the most secure families of its kind on the market today, when used in the
intended manner and under normal conditions.
• There are dishonest and possibly illegal methods used to breach the code protection feature. All of these methods, to our
knowledge, require using the Microchip products in a manner outside the operating specifications contained in Microchip's Data
Sheets. Most likely, the person doing so is engaged in theft of intellectual property.
• Microchip is willing to work with the customer who is concerned about the integrity of their code.
• Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their code. Code protection does not
mean that we are guaranteeing the product as “unbreakable.”
Code protection is constantly evolving. We at Microchip are committed to continuously improving the code protection features of our
products.
12/05/02