AN50987 Getting Started with I 2C in PSoC ® 1 Author: Todd Dust and M. Ganesh Raja Associated Project: Yes Associated Part Family: CY8C21x23, 21x34, 21x45, 22x45,23x33, 24x23A, 24x33, 24x94, 27x43, 28xxx, 29x66 ® Software Version: PSoC Designer™5.4 2 ® 2 AN50987 gives an overview of the I C standard and explains how a PSoC 1 device handles I C communications. 2 After reading this application note, you should have an understanding of how I C works, how to implement it in PSoC 1, and how to choose the correct user module for a design. Example projects demonstrate how to configure 2 2 PSoC 1 as an I C master/slave to communicate with other I C devices on the bus. Contents Introduction .......................................................................2 2 I C Basics ..........................................................................2 The Physical Layer .......................................................2 The Protocol Layer .......................................................2 2 I C in PSoC 1 ....................................................................4 Hardware ......................................................................5 2 I C User Modules .........................................................6 Firmware ...........................................................................8 Slave Operation............................................................8 Master Operation ..........................................................9 Multimaster Slave Operation ...................................... 10 2 I Cm ........................................................................... 11 2 Special I C Considerations .............................................. 12 2 I C Addressing ........................................................... 12 Pull-up Resistors ........................................................ 12 2 I C and ISSP Programming Conflicts ......................... 12 Pin Glitches at Power-up ............................................ 13 Clock Speeds ............................................................. 13 Clock Stretching and Interrupt Latency ...................... 14 Hot Swapping ............................................................. 14 Glitch Filtering ............................................................ 14 2 I C and Sleep ............................................................. 14 2 I C and Dynamic Reconfiguration .............................. 15 2 Dynamic Slave Addressing in I CHW UM .................. 15 The SCL Line Gets Stuck LOW .................................. 15 Summary ......................................................................... 16 www.cypress.com Appendix A ...................................................................... 17 Hardware Registers.................................................... 17 Firmware Requirements ............................................. 17 Arbitration ................................................................... 18 Appendix B ...................................................................... 20 EzI2Cs_ADC_LED_DAC Example Project................. 20 2 I CHW Slave Example Project ................................... 24 2 I CHW Master Example Project ................................. 25 Migrating Example Project ......................................... 26 Worldwide Sales and Design Support ............................. 28 Document No. 001-50987 Rev. *E 1 Getting Started with I2C in PSoC® 1 Figure 2. Open Drain Drives LOW Pin Configuration Introduction Vdd 2 Inter-integrated circuit (IIC or I C) is a common chip-tochip serial communications standard developed by the 2 Philips semiconductor division (now NXP). I C provides a simple way for ICs to communicate on the same printed 2 circuit board (PCB). I C consists of a simple physical layer that requires only two pins and minimal external 2 components. One advantage of I C over a communication standard such as SPI is that it has a built-in communication protocol that allows easy, error-free communication between devices. The Cypress PSoC 1 device offers several choices for 2 implementing I C in a design. These choices come in the form of user modules (UMs) that are found in the PSoC Designer™ integrated development environment (IDE). This application note first describes the basics of 2 I C to help you understand how the PSoC 1 device 2 2 handles I C. If you already have an understanding of I C basics, skip to I2C in PSoC 1. If you are looking for help 2 troubleshooting your I C design, skip to the Special I2C Considerations section. This application note assumes that you are familiar with the PSoC 1 device and PSoC Designer IDE. I2C Basics SDA I2C Master 1 SCL I2C Slave 1 I2C Master 2 I2C Slave 2 Drive Line LOW Receive Data 2 Devices on the I C bus have a master-slave relationship. The master initiates all data transfers on the bus and generates all clock signals. Each slave has a unique address; the master must first address a specific slave and receive an acknowledgment before the data transfer can begin. Multiple masters and multiple slaves can exist 2 together on the same bus. The I C bus operates at a variety of frequencies; typical frequencies are 100 kHz and 2 400 kHz. The I C specification allows higher frequencies of 1 MHz and 3.4 MHz. 2 The Physical Layer 2 2 Figure 1 shows how I C devices connect to the I C bus. 2 The I C bus consists of two physical lines: serial data (SDA) and serial clock (SCL). All devices on the bus must connect to these two physical lines. The only external hardware required are pull-up resistors to VDD (high rail) on SDA and SCL. For more information, see the Pull-up Resistors section. 2 Figure 1. Typical I C Bus The I C bus operates at different voltage levels depending on the individual devices themselves. To determine if two devices can successfully communicate, review their respective datasheets to ensure that the logic levels are compatible. 2 The I C specification offers a solution for bridging between buses of different voltage levels, in the event that the voltage and logic levels of two devices are not compatible. The Protocol Layer 2 Understanding the protocol layer of I C is the next major step in mastering this digital communication technique. Vdd 2 Each I C transaction consists of the following elements: start (or repeated start), address, data, and stop. SDA I2C Master 1 SCL I2C Slave 1 I2C Slave 2 Start or Repeated Start The master device controls the clock line and therefore initiates all communication on the bus. To gain control of the bus and initiate a transaction, the master first sends a start condition; see Figure 3. I2C Master 2 SDA and SCL are bidirectional; the master can communicate data to the slave and vice versa. SDA and SCL have an open-drain drive mode and drive LOW. A device can drive the line to a logic LOW, or it can be highimpedance. Therefore, no device can drive the lines HIGH. This configuration prevents power-to-ground shorts on the bus; see Figure 2. The pull-up resistors on SDA and SCL produce a HIGH logic level. www.cypress.com A start condition signals to every device on the bus that a master has taken control and is ready to send an address. The bus is considered busy, so other masters must wait for the bus to be freed by a stop condition to initiate a transfer. Start = HIGH to LOW transition on SDA when SCL is HIGH Document No. 001-50987 Rev. *E 2 Getting Started with I2C in PSoC® 1 Figure 3. Start Condition Figure 5. 10-Bit Address Start S 11110XX R/W A/N 2 MSBs of Address SDA SCL A repeated start condition is physically identical to a start condition. It gives a signal that the master has maintained control of the bus and that the bus is not free. XXXXXXXX A/N Remaining 8 bits Data After the master has sent the address and the slave has acknowledged it, data can be transferred eight bits at a time. Both the master and the slave can transmit and receive, so together they control the SDA line. Address The address is the first data byte sent by the master after the start condition. Each slave device has a unique 2 address. Most I C addresses are seven bits long. A read/write (R/W) bit completes the 8-bit byte and indicates the direction of communication for the rest of the transaction; see Figure 4. A read signifies that the master wants to read data from the slave. A write indicates that the master wants to write data to the slave. All address and data bytes are sent in the order of most significant bit (MSB). Data on the SDA line must be stable before the rising edge of SCL. Data on SDA can change only when SCL is LOW; see Figure 6. For example, if the 7-bit address is 0x20, the full 8-bit byte for a read will be 0x40; the full 8-bit byte for a write will be 0x41. If the master is performing a write operation, it writes out eight bits of data on SDA and provides eight clock cycles on SCL. After the master sends eight bits of data, the slave must send an ACK or NAK on the ninth clock cycle; see Figure 7. Figure 4. 7-Bit Address ACK SDA D7 D1 R/W SCL 1 7 8 SDA Stable Data SCL 9 ACK/NAK After the master transmits the address, it waits for an acknowledgment (ACK) from the slave. The ACK is an additional status bit at the end of each data byte; thus, 2 each I C transaction is nine bits long. Each slave on the bus is responsible for reading the incoming address and comparing it with its own internal address. If the address matches, the slave must send out an ACK on the ninth clock cycle. If the address does not match, the slave does not acknowledge (NAK). Figure 6. SDA Data Change Data Change ACK = Slave has room for more data NAK = Slave cannot take any more data The alternate condition is that the master wants to read data from the slave. In this case, the master provides the eight clock cycles but the slave transmits eight data bits on SDA. After the eight data bits are transferred, the master must send the ACK or NAK. ACK = Master wants to read more data NAK = Master is done reading Note The slave does not have a way to inform the master that it has no data to send. Figure 7. Eight Data Bits Followed by an ACK Bit ACK SDA D7 D1 D0 SCL 1 7 8 ACK = 0 (LOW logic level) NAK = 1 (HIGH logic level) 1 0 - B i t Ad d r e s s 2 The I C specification also allows for 10-bit addressing; see Figure 5. To accomplish this, the master must send two address bytes to the slave. The first byte, which the slave must acknowledge, contains the sequence 11110 followed by the two MSBs of the address followed by the R/W bit. Next, the master sends the remaining eight bits of the address. Finally, the slave sends an ACK/NAK. www.cypress.com 9 Stop After all bytes are sent, the master sends a stop condition. A stop indicates that the current transaction is complete and the bus is free; see Figure 8. Stop = LOW to HIGH transition on SDA when SCL is HIGH Document No. 001-50987 Rev. *E 3 Getting Started with I2C in PSoC® 1 Figure 8. Stop Condition stop driving the SDA line and must wait until the bus is free before sending data again. Stop As Figure 10 shows, the first master that leaves SDA HIGH while another tries to drive it LOW loses arbitration and must wait. SDA Figure 10. Arbitration SCL SCL The master can send a repeated start condition instead of a stop. A repeated start condition is physically the same as a start. The repeated start allows the master to maintain control of the bus when it wants to address a slave device to start a new transaction or change the direction of data flow. A repeated start is needed when a master wants to write data to a specific slave and then turn around and read data from that same slave. Using a repeated start allows the master to maintain control of the bus. If the master uses a stop, other masters on the bus can gain control. Putting It All Together Figure 9 shows a complete transaction for a master read of two bytes and a master write of two bytes. It also shows a repeated start that first writes two bytes and then reads two bytes. Figure 9. Complete Transaction Device #1 SDA 1 0 Lost Arbitration Stops Driving SDA Device #2 SDA 1 0 0 1 SDA of Bus 1 0 0 1 2 2 2 2 For more information on I C and its protocol, see the I C Specification from Philips (NXP). I2C in PSoC 1 In PSoC 1, a dedicated I C hardware block handles I C transactions, removing much of the processing burden from the CPU and freeing the CPU for important real-time tasks. The basic structure of the block is similar for most PSoC 1 devices; see Table 1 for differences among the part families. 2 Table 1. I C Hardware Block Differences Master Read S Address R A Data A Data N P Master Write S Address W A Data A Data N P Repeated Start Example: Master Write Followed by Master Read S Address Address W A R A Data Data S = Start W = Write R = Read A = ACK N = NAK P = Stop Address = 7-bit Slave Address A A Data Data A S N P Master Slave HW Addr Match Two I2C Blocks 20x34 No Yes No No 20xx6A No Yes Yes No 21x23 Yes Yes No No 21x34 Yes Yes No No 22xxx/21x45 Yes Yes No No 23x33 Yes Yes No No Device 24x23A Yes Yes No No Master to Slave 24x94 Yes Yes No No Slave to Master 27x43 Yes Yes No No 28xxx Yes Yes Yes Yes 29x66 Yes Yes No No Arbitration 2 The I C protocol allows multiple masters to communicate on the same bus. Both masters may start communicating 2 at the same time. To prevent loss of data, each I C master 2 must check the I C bus to ensure that the data on the bus matches what it intended to put on the bus. If the data 2 does not match, the I C master that loses arbitration must www.cypress.com Document No. 001-50987 Rev. *E 4 Getting Started with I2C in PSoC® 1 Table 2. Byte Complete Interrupt Hardware As Figure 11 shows, the hardware block allows Ports 1.5, 2 1.0, 1.7, and 1.1 to connect to the I C bus. Cypress 2 recommends avoiding Ports 1.1 and 1.0 for I C; these lines are used for programming. 2 Figure 11. I C Hardware Block SDA_OUT SDA_IN SDO SDE SCL_IN SCL SDI GPIO I2CEN SDE Transmitter After 8 bits of data + ACK/NAK After 8 bits of data Receiver After 8 bits of data After 8 bits of data + ACK/NAK 2 I2C Bus SDO Slave For more information on the functionality of the I C 2 hardware block, see Appendix A and the I C sections of the PSoC Technical Reference Manual. Port1[5] or Port1[0] I2CBLK SCL_OUT Master SDA SDI GPIO Mode Port1[7] or Port1[1] The hardware block is a simple block that handles all of 2 the status and timing requirements of the I C transaction. 2 This block generates the I C clock when it is in master 2 mode. It also shifts I C data in and out of PSoC 1 and 2 reports the status of I C transactions and errors. Interrupts and Transaction Queuing The block is capable of receiving or transmitting only one byte of data at a time. At each byte boundary, the block will generate an interrupt. The CPU must service the interrupt and provide more data to the block, or it must read the data that the block received. The CPU need not service the block immediately, because the block holds the SCL LOW until the CPU releases it; this process is referred to as clock stretching. For more information, see the Clock Stretching and Interrupt Latency section. The block is capable of queuing only one transaction at a time. Multiple starts cannot be queued in the block. 2 Therefore, user code must ensure that the current I C transaction is complete before another transaction can be initiated. Hardware Blocks in CY8C28xxx 2 Part family CY8C28xxx offers two separate I C hardware blocks, allowing hardware connections to more than one 2 I C bus at a time. In addition, each block provides hardware address matching. The hardware interrupts the CPU only on an address match. However, it does not wake PSoC 1 out of a sleep state. After the address, the hardware interrupts the CPU according to the conditions in Table 2. Each of the hardware blocks in part family CY8C28xxx 2 allows for additional I C pin connections either on Ports 1.2 and 1.6 or on Ports 3.0 and 3.2. 2 Having two I C hardware blocks allows for many powerful applications. Table 3 lists some of the unique applications that can be achieved. 2 Table 3. Two I C Configurations with Common Use Cases Configuration 2 Two I C slaves Common Uses 2 Multi-I C bus systems I2C shared memory device One I2C slave, one I2C master or multimaster I2C bus switch I2C hot-swap controller I2C buffer Debugging The block automatically detects and reports arbitration conditions in multimaster environments. In the case of an arbitration event, the block reports to the CPU that it has lost arbitration. User code checks to see if arbitration has been lost. If so, then the code retries the transfer. 2 Two I C masters or multimasters Increase bandwidth 2 The I C hardware block will generate an interrupt on three conditions: a bus error, a stop, or a byte complete. Bus errors occur when there is a misplaced start or stop on the bus. When this occurs, all devices on the bus must stop their current transfer and return to an idle state. If enabled, the stop interrupt occurs every time there is a stop condition on the bus. The byte complete interrupt is triggered at different points depending on the direction of data flow; see Table 2. This table applies for both address and data transfers. www.cypress.com Document No. 001-50987 Rev. *E 5 Getting Started with I2C in PSoC® 1 I2C User Modules 2 Cypress provides a set of preconfigured and precoded I C user modules (UMs), located in PSoC Designer in the UM Catalog; see Figure 12. 2 Figure 12. I C UMs in PSoC Designer This UM is best suited for situations when PSoC needs to stream data continuously to a master device and when 2 you want to write minimal I C code. For example, the UM ® is popular in CapSense applications. PSoC reads the state of CapSense buttons and the master device communicates continuously with PSoC to see if a button has been pressed. In this situation, expose the CapSense variables to the EzI2Cs and the master can easily read the state of the CapSense buttons. 2 EzI2Cs is patterned after an I C-based memory such as EEPROM. It uses subaddressing to write or read to 2 specific data locations within the exposed I C data 2 structure. For example, consider an I C data structure that appears as follows: When these UMs are placed in a design, you will not see them appear in the chip view within PSoC Designer, because the UMs either use the dedicated hardware block or are a software master. They use digital blocks only with the 28xxx family; in that case, the chip view shows both 2 I C hardware blocks visually so you know which block you have used and how many remain; see Figure 13. 2 Figure 13. Two I C Blocks in 28xxx 2 2 I C UMs, which include EzI2Cs and I CHW, provide a 2 level of abstraction over the I C hardware block. This section briefly describes each UM and explains when it will be needed in a design. For more information, see the specific UM datasheet. EzI2Cs Ezl2Cs operates exclusively as a slave; there is no master 2 version. If a design requires master operation, use I CHW 2 or I Cm. 2 EzI2Cs, as the name implies, is an easy-to-implement I C 2 slave interface. It is a firmware layer on top of the I C hardware block. It implements many of the firmware requirements mentioned in the hardware block description found in Appendix A. EzI2Cs is unique; it requires minimal user knowledge of 2 how the I C bus works. It allows you to set up a data 2 structure in user code and expose that structure to the I C 2 master. All I C transactions happen in the background through interrupts. You need not worry about any of the 2 I C functionality after the UM is started. The application code just needs to update the data structure with data for the master to read and then check and process data that the master writes. www.cypress.com struct MyI2C_Regs { BYTE bStat; BYTE bCmd; int iVolts; char cStr[6]; } MyI2C_Regs The above data will be exposed to the master with the following memory map: 0x00 MyI2C_Regs.bStat 0x01 MyI2C_Regs.bCmd 0x02 MyI2C_Regs.iVolts(MSB) 0x03 MyI2C_Regs.iVolts(LSB) 0x04 MyI2C_Regs.cStr[0] 0x05 MyI2C_Regs.cStr[1] 0x06 MyI2C_Regs.cStr[2] 0x07 MyI2C_Regs.cStr[3] 0x08 MyI2C_Regs.cStr[4] 0x09 MyI2C_Regs.cStr[5] If the master wants to write to iVolts, it first sends the slave address, followed by a subaddress (0x02), which indicates the offset of iVolts in the structure. To calculate the offset, count the number of bytes before iVolts; in this example, the subaddress is ‘2.’ To extend the example, a subaddress of ‘0’ will write to bStat, a subaddress of ‘1’ will write to bCmd, and a subaddress of ‘4’ will write to the first element of the cStr array. Figure 14 shows an example of a master writing data to iVolts in an EzI2Cs UM with a slave address of 0x04. Figure 14. EzI2Cs Example: Write to iVolts S Slave Addr 0x04 WA Subaddr 0x02 A Data to iVolts 0x55 A 0xAA A P If the master wants to read iVolts, it first needs to address the PSoC slave and write the subaddress of ‘2.’ It should then address the slave again and read out two bytes. Document No. 001-50987 Rev. *E 6 Getting Started with I2C in PSoC® 1 Each subsequent read will start at iVolts until a new subaddress is written. Figure 15 shows an example of a master reading the data in iVolts. Figure 15. EzI2Cs Example: Read from iVolts S Slave Addr 0x04 WA S Slave Addr 0x04 R A Subaddr 0x02 2 I2C_Pins: This parameter selects the pins used for the I C clock and data. After the UM parameters are configured, follow these steps to make the EzI2Cs work in firmware. A P Data from iVolts 0x55 A 0xAA 6 MHz, the actual speed of the slave will be 100 kHz. See the Clock Speeds section for more details. 1. A P structMyI2C_Regs { BYTE bStat; BYTE bCmd; int iVolts; char cStr[6]; } MyI2C_Regs Let’s take a look at how EzI2Cs can be implemented in a project. Figure 16 shows the parameters for the project. Figure 16. EzI2Cs UM Parameters 2. Start the EzI2Cs by calling the EzI2Cs_Start function. 3. Enable interrupt by calling the EzI2Cs_EnableInt function. 4. Expose the data structure to the master by using the EzI2Cs_RamSetBuffer function. EzI2Cs_SetRamBuffer(sizeof(MyI2C_Regs), 2, (char*)&MyI2C_Regs); Slave_Addr: This parameter sets the address of the EzI2Cs slave. If the ROM_Registers parameter is disabled, the Slave_Addr is a 7-bit address in the range 0 to 127. If the ROM_Registers parameter is enabled, the Slave_Addr is a 6-bit address in the range 0 to 63. The first parameter sets the size of the buffer. The second parameter sets the write boundary and the third parameter initializes the pointer to the data structure. Address_Type: When the address type is set to static, the address of the EzI2Cs slave is fixed to the value set in the Slave_Addr parameter. If the address type is set to dynamic, the address can be changed in firmware using the EzI2Cs_SetAddr function. This is useful in applications in which more than one PSoC 1 EzI2Cs slave is in a bus and the address of the slaves can be set by configuring GPIO pins. ROM_Registers: By enabling the ROM_Registers parameter, it is possible to expose data stored in a ROM 2 array to an I C master. When this parameter is enabled, the EzI2Cs is exposed to a master with two addresses. If the master wants to access the ROM memory space, it uses a 7-bit address with the seventh bit set. To access the RAM memory space, it uses a 7-bit address with the seventh bit cleared. For example, if the Slave_Addr is set to 0x04, the master addresses the slave with an address of 0x44 to access the ROM registers and an address of 0x04 to access the RAM registers. This is why the Slave_Addr should be a 6-bit address when the ROM registers are enabled. I2C_Clock: This parameter sets the maximum speed at which the slave can operate. Remember that the maximum speed is based on a SYSCLK of 24 MHz. If the SYSCLK is set to 6 MHz or 12 MHz (SLIMO enabled) in the Global Resources, the maximum clock speed will reduce by the same factor. For example, if the I2C_Clock parameter is set to 400 kHz and the SYSCLK is set to www.cypress.com Create a data structure to expose to the master. For example: The EzI2Cs allows defining read/write permissions on the data structure through the SetRamBuffer function. For example, in the code given in step 1, the application sets read/write permission to bStat and bCmd variables and makes all other variables readonly by setting the write boundary to ‘2.’ In this case, if the master tries to write to these read-only variables, the slave will generate a NAK and ignore the data written by the master. 5. In the main loop, keep updating the data structure with process data for the master to read and keep looking for fresh data from the master. Data coherency is an important consideration when using the EzI2Cs UM. In the example, iVolts is a two-byte variable. It is possible that the CPU started to update this variable but only had time to write to one byte before the 2 I C master read both bytes. As a result, the master read incorrect data. For example, suppose that the variable iVolts has a value of 0x01FF. The CPU would have to update this with a new value of 0x0200. The CPU writes 0x02 to the MSB first and 0x00 to the least significant bit 2 (LSB). If the I C read occurs just after the CPU has written to the MSB, but before writing to the LSB, the master will read 0x2FF. To combat this, it is best to use flags or semaphores between the master and slave to indicate when data is ready to be read or written. The EzI2Cs datasheet gives Document No. 001-50987 Rev. *E 7 Getting Started with I2C in PSoC® 1 more details on other ways to ensure that the data is coherent. This application note includes a simple project that demonstrates how to use the EzI2Cs UM. For details on how to use the project, see Appendix B. For a detailed description of how this UM works and how to use it, see the EzI2Cs datasheet. In the master operation, three parameters are available: Read_Buffer_Type, I2C_Clock, and I2C_Pin. Configuration of these parameters is the same as that described for the slave operation below. Multimaster and Slave Operation: Select this option if 2 you need the I CHW as a master and slave in a multimaster environment. Depending on the option you select, the UM parameter window will populate. EzI2Cs Summary and Important Notes EzI2Cs is an easy-to-implement slave-only UM. EzI2Cs exposes a register structure to a master with clearly defined read/write permissions. When ROM registers are enabled, the slave will have two addresses, one for RAM space (seventh bit cleared) and one for ROM space (seventh bit set). For this reason, the slave address is limited to a 6-bit value when ROM registers are enabled. When dealing with multiple byte values in EzI2Cs, take care to ensure data coherency by using flags or semaphores between the master and slave. Slave_Addr: This is the 7-bit slave address. Unlike 2 EzI2Cs, I CHW does not offer dynamic addressing or separate address for ROM buffers. In multimaster and slave operation, Slave_Addr is the address of the device when it is addressed as a slave by another master on the bus. Read_Buffer_Type: When you select “RAM only,” the application will set up the read buffer only in RAM. When you select ”RAM or flash,” the application exposes either a RAM buffer or a flash buffer to the master. 2 Communication Service Type: When you select 2 “Interrupt,” all I C transactions are automatically handled 2 inside the interrupt. When you select “Polled,” I C transactions are handled only when the foreground application calls the I2CHW_Poll function. The hardware 2 keeps the I C clock stretched until the application calls I2CHW_Poll. Cypress recommends the “Interrupt” option. 2 I2C_Clock: This parameter selects the speed of the slave. As explained in the clock parameter of the EzI2Cs slave, the speed is based on a SYSCLK of 24 MHz. I CHW 2 This UM is a firmware layer on top of the I C hardware block and implements all the firmware tasks described in Appendix A. You can use this flexible UM as a slave, a master, or a multimaster slave. I CHW, unlike EzI2Cs, requires more code interaction. 2 Check status bits to see if an I C transaction occurred, reinitialize buffers when a transaction is complete, and clear status bits. Also, check the firmware for error conditions on a transaction. 2 Here’s how to implement I CHW in a project. When you 2 double-click, the I CHW topology selection window opens. See Figure 17. 2 Figure 17. I CHW Topology Window 2 I2C_Pin: This parameter selects the pins for the I C. Options are P1[0]-P1[1] and P1[5]-P1[7] for all devices except for CY8C28xxx. For CY8C28xxx, P1[2]-P1[6] and P3[0]-P3[2] options are also available. Firmware After the topology and parameters are configured, follow 2 these steps to get the I CHW working in firmware. Slave Operation 1. Declare a read buffer in RAM (or flash) for the master to read from. For example: BYTE ReadBuffer[16]; The buffer can also be a structure such as: struct ReadBuffer { BYTE bStatus; int iVolts; }ReadBuffer; Slave Operation: Select this option if you need slave operation. Single Master Operation: Select this option if you need a simple operation in a single master environment. 2. Declare a write buffer in RAM for the master to write to. For example: BYTE WriteBuffer[16]; The buffer can also be a structure such as: www.cypress.com Document No. 001-50987 Rev. *E 8 Getting Started with I2C in PSoC® 1 struct WriteBuffer { BYTE bCmd; int iDACCounts; }WriteBuffer; 3. Enable global interrupts M8C_EnableGInt macro. It is important to check for the RD_COMPLETE flag and reinitialize the buffer. Otherwise, on further reads from the master, the last byte from the buffer will be transmitted repeatedly. by calling the 8. M8C_EnableGInt ; It is important to enable global interrupts, because all 2 of the I C operations take place in the background 2 inside the I C ISR. 4. // Check if a write operation is over if (I2CHW_bReadI2CStatus() & I2CHW_WR_COMPLETE) { // Process data from Master Call the I2CHW_Start, I2CHW_EnableSlave, and I2CHW_EnableInt functions to start the slave. I2CHW_Start(); I2CHW_EnableSlave(); I2CHW_EnableInt(); 5. // Clear the flag I2CHW_ClrWrStatus(); // Re-initialize the buffer I2CHW_InitWrite(WriteBuffer, sizeof(WriteBuffer)); } Initialize the read buffer using I2CHW_InitRamRead. I2CHW_InitRamRead(ReadBuffer, sizeof(ReadBuffer)); 6. It is important to reinitialize the write buffer; otherwise, the slave will not acknowledge any further data from the master. This function initializes a pointer to the read buffer and sets the size of the buffer. Whenever the master tries to read from the slave, data from the buffer is transmitted to the master automatically. If the master tries to read more bytes than the size of the buffer, the last byte of the buffer is transmitted repeatedly. A simple project in this application note demonstrates how 2 to use I CHW as a slave that echoes the data written by 2 an I C master. For details on the project, see Appendix B. Initialize the write buffer using the I2CHW_InitWrite function. Master Operation 1. I2CHW_InitWrite(WriteBuffer, sizeof(WriteBuffer)); This initializes a pointer to the write buffer and the buffer size. When the master writes data to the slave, the data is automatically deposited in the buffer. If the master tries to write a greater number of bytes than the buffer size, the slave will not acknowledge the extra bytes and those extra bytes will be discarded. 7. Call the function I2CHW_bReadI2CStatus and check for the I2CHW_WR_COMPLETE flag. If this flag is set, it means that the master has completed a write transaction. Process the data, clear the flag, and reinitialize the write buffer. Call the function I2CHW_bReadI2CStatus and check for the I2CHW_RD_COMPLETE flag. If this flag is set, it means that the master has completed a read transaction. Clear the status flag and reinitialize the read buffer. // Check if a read operation is over if (I2CHW_bReadI2CStatus() I2CHW_RD_COMPLETE) { // Prepare fresh data for Master BYTE ReadBuffer[16]; The buffer can also be a structure similar to the one discussed in the slave operation section above. 2. www.cypress.com Declare a write buffer in RAM for data that will be 2 written to the I C slave. For example: BYTE WriteBuffer[16]; 3. Enable global interrupts M8C_EnableGInt macro. by calling the M8C_EnableGInt; It is important to enable global interrupts, because all 2 of the I C operations take place in the background 2 inside the I C ISR. 4. // Clear the flag I2CHW_ClrRdStatus(); // Re-initialize the buffer I2CHW_InitRamRead(ReadBuffer, sizeof(ReadBuffer)); } Declare a read buffer in RAM (or flash) where data read from the slave will be stored. For example: Call the I2CHW_Start, I2CHW_EnableMstr, and I2CHW_EnableInt functions to start the master. I2CHW_Start(); I2CHW_EnableMstr(); I2CHW_EnableInt(); 5. To write to a slave, use the I2CHW_bWriteBytes function. Document No. 001-50987 Rev. *E 9 Getting Started with I2C in PSoC® 1 I2CHW_bWriteBytes(0x50, WriteBuffer, 16, I2CHW_CompleteXfer); The first parameter is the slave address; use the 7-bit slave address. The bWriteBytes function automatically adds the read/write bit to the 7-bit address before 2 transmitting the address on the I C bus. The second parameter is the pointer to the buffer that has the data for the slave. The third parameter is the number of bytes to be written to the slave. The fourth parameter is the transaction type and can have three different values: I2CHW_CompleteXfer, I2CHW_NoStop, and I2CHW_RepStart. I2CHW_Start(); I2CHW_EnableMstr(); I2CHW_EnableSlave(); I2CHW_EnableInt(); 3. The slave mode operation is similar to the single slave operation, but the function names are different. Allocate read and write buffers; call these functions to initialize: I2CHW_InitSlaveRamRead and I2CHW_InitSlaveWrite. Call I2CHW_bReadSlaveStatus. Check for I2CHW_RD_COMPLETE and I2CHW_WR_COMPLETE flags. If these flags are set, reinitialize the buffers. 2 When you use I2CHW_CompleteXfer, one full I C transaction is completed, which includes the start bit, the address byte, the data bytes, and the stop bit. When you use I2CHW_NoStop, the stop is not generated after writing the data. A transaction with a NoStop can be followed by a transaction with the I2CHW_RepStart. Usually, Cypress recommends I2CHW_CompleteXfer for most I2C transactions. 4. The I2CHW_bWriteByte function initializes a pointer to the buffer, sets a count value, and initiates the start bit 2 in the I C hardware. After this, all the operations take 2 place inside the ISR. The I C hardware generates an interrupt on every byte complete; the ISR takes care of incrementing the pointer to the buffer, transmitting the next byte to the slave. When all the bytes are transferred, the ISR generates a stop. 6. Use the I2CHW_bReadI2CStatus function to check that the write operation is complete, and then clear the flag. For example: The firmware for the master side of the operations has to deal with some special cases. In a multimaster environment, when a master (let’s call this Master 1) tries to initiate a transaction to a slave, there are three different scenarios depending on the activities of other master(s). (Assuming that there is another master in the bus, let’s call it Master 2.) a. The bus is free and Master 1 initiates and completes a read or write transaction. b. Master 2 had already initiated a transaction with another slave on the bus; because of this, the bus is busy. Master 1 must wait until the bus becomes free and then initiate the transaction. c. Master 1 initiates a read or write transaction at the same time Master 2 initiates a transaction. In this situation, arbitration occurs. If Master 1 wins the arbitration, it completes the transaction. If Master 1 loses arbitration, it must retry the transaction after Master 2 completes its transaction. Appendix A gives details about arbitration. while(!(I2CHW_bReadI2CStatus() & I2CHW_WR_COMPLETE)); I2CHW_ClrWrStatus(); The above code waits until the WR_COMPLETE flag is set. You can use an “if” condition instead of a “while”; the processor can do other things when the 2 I C transaction takes place in the background. 7. 2 I CHW provides separate functions for the master for handling the multimaster environment. 5. Use the I2CHW_fReadBytes function to initiate a read from the slave. Use the I2CHW_bReadI2CStatus function and check for the I2CHW_RD_COMPLETE flag; then clear the read status. I2CHW_fReadBytes(0x50, ReadBuffer, I2CHW_CompleteXfer); while(!(I2CHW_bReadI2CStatus() & I2CHW_RD_COMPLETE)); I2CHW_ClrRdStatus(); 16, while(I2CHW_bWriteBytesNoStall(0x50, WriteBuffer, 16, I2CHW_CompleteXfer) == 0xFF); Multimaster Slave Operation You can use an “if” condition to check the return value instead of using a “while” loop, which is blocking. If the return value is 0xFF, you can retry the transaction after a fixed time interval. 2 In the multimaster slave mode, the I CHW can act as both master and slave in a multimaster environment. 1. Call the I2CHW_Start function. 2. Call I2CHW_EnableMstr and I2CHW_EnableSlave functions to enable both master and slave modes and the I2CHW_EnableInt function to enable interrupt. www.cypress.com To write to a slave, call I2CHW_bWriteBytesNoStall. To read from a slave, call I2CHW_fReadBytesNoStall. These functions check if the bus is busy before initiating the transaction. If the bus is busy, these functions return 0xFF. The firmware should check the return value and retry the transaction if the return value is 0xFF. For example, the following code loops until the I2CHW_bWriteBytesNoStall returns a value other than 0xFF. 6. When a read or write operation is started without a bus busy error, the firmware should next check if the Document No. 001-50987 Rev. *E 10 Getting Started with I2C in PSoC® 1 operation is completed or if the master lost arbitration. Following is an example code that does this. while((!(I2CHW_bReadMasterStatus() & I2CHW_WR_COMPLETE)) && (!(I2CHW_bReadBusStatus() & I2CHW_LOST_ARB))); if (I2CHW_bReadMasterStatus() & I2CHW_WR_COMPLETE) { // Write is completed successfully. // Clear flag I2CHW_ClrMasterWrStatus(); } if (I2CHW_bReadBusStatus() & I2CHW_LOST_ARB) { // Master lost arbitration. Retry later } The first line loops until either the write is completed or the LOST_ARB error flag is set. If the “while” loop terminates, the code checks to determine which condition caused the loop to terminate. If the WR_COMPLETE flag is set, then clear the flag. If the LOST_ARB flag is set, then retry the transaction later. This application note includes a simple project that 2 demonstrates how to use the I CHW UM to read a standard EEPROM. For details, see Appendix B. 2 For more information, see the I CHW UM datasheet and 2 the I C section of the Technical Reference Manual. 2 I CHW Summary and Important Notes 2 I CHW can operate in single master, single slave, or multimaster slave modes. In slave mode, when a master completes a read or write, the buffers must be reinitialized for the next transaction to take place. In the master mode in a multimaster environment, the firmware must check the return value of the bWriteBytesNoStall and fReadBytesNoStall functions to know if the bus is busy, and must retry the transaction. In the master mode in a multimaster environment: When a read or write transaction is initiated, the firmware checks if the transaction has completed successfully or the master has lost arbitration to another master. If the master lost arbitration, the transaction must be retried. I2Cm 2 2 I Cm, another UM in PSoC 1, implements an I C master through software manipulation of GPIO port pins. This UM 2 2 does not use the I C hardware block. There is no I C software slave user module. 2 The advantage of this UM over I CHW is that it can be used on any pair of pins instead of just P1.5, P1.7 or P1.0, P1.1. One drawback is that it requires more CPU www.cypress.com overhead and does not support multimaster operation. It 2 requires 100 percent of CPU during I C transactions. A second disadvantage is that it is limited to bus frequencies of 100kHz. 2 I Cm is best for applications in which multiple masters are needed in a single chip or when the pins that connect to 2 the I C hardware are not available. Cypress recommends 2 using I CHW for master operations if only one master is needed and if P1.5, P1.7 or P1.0, P1.1 are available. Following are the steps to get this UM running in a project. 2 1. Start the UM using the I Cm_Start function. 2. To write data from a RAM buffer (or a ROM buffer) to a slave, use the I2Cm_bWriteBytes function. This function accepts the slave address, pointer to the source data in RAM (or ROM), and the number of bytes to be transferred. 3. To read data from a slave, use the I2Cm_fReadBytes function. This function accepts the address of the slave, pointer to destination buffer where the read data must be saved, and the number of bytes to be read. This UM works by manipulating the drive mode (PRTxDMx) and data registers (PRTxDR) of the port on which it is operating. For this reason, take care when 2 manipulating data registers in user code; otherwise, I C traffic is affected adversely. The best way to avoid issues is to use shadow registers when writing to the drive mode 2 and data registers associated with the I Cm pins. 2 When I Cm is placed in the project, PSoC Designer automatically creates shadow registers for the data register and the two drive mode registers PRTxDM0 and PRTxDM1. Because the UM does not affect PRTxDM2, a shadow register is not created for this register. These shadow registers are defined in psocconfig.asm 2 and psocgpioint.h files. For example, if I Cm is placed in Port0, the following variables are defined in the psocconfig.asm file. ; write only register shadows _Port_0_Data_SHADE: Port_0_Data_SHADE: BLK _Port_0_DriveMode_0_SHADE: Port_0_DriveMode_0_SHADE: 1 BLK 1 BLK 1 _Port_0_DriveMode_1_SHADE: Port_0_DriveMode_1_SHADE: The following definitions are placed in psocgpioint.h. extern BYTE Port_0_Data_SHADE; extern BYTE Port_0_DriveMode_0_SHADE; extern BYTE Port_0_DriveMode_1_SHADE; The application code uses these shadow registers to write to the data and drive mode registers. For example, if the application wants to set P0[0], use the following code: // Write to PRT0DR through shadow register Port_0_Data_SHADE |= 0x01; Document No. 001-50987 Rev. *E 11 Getting Started with I2C in PSoC® 1 PRT0DR = Port_0_Data_SHADE; I2C Addressing 2 To set P0[0] to strong mode using the PRT0DMx registers: // Write to PRT0DM0 through shadow register Port_0_DriveMode_0_SHADE |= 0x01; PRT0DM0 = Port_0_DriveMode_0_SHADE; // Write to PRT0DM1 through shadow register Port_0_DriveMode_1_SHADE &= ~0x01; PRT0DM1 = Port_0_DriveMode_1_SHADE; There are two common ways used to describe the I C slave address. One uses the seven bits of address and not the read/write bit (for example, 0x42). This is how 2 Cypress’s UMs treat the I C slave address. The other way is to include the read/write bit as part of the address (for example, 0x84/0x85). Make sure that you know which addressing method the devices you are working with use. // Write to PRT0DM2 directly PRT0DM2 &= ~0x01; At this time, Cypress does not support 10-bit slave addresses. For more information on the need to use shadow registers, refer to the Shadow Registers Database. For more 2 information on this user module, see the I Cm datasheet. Pull-up Resistors 2 I Cm Summary and Important Notes 2 2 I Cm is a software implementation of I C master and 2 does not occupy the I C hardware resource. 2 Another common design consideration with I C is the value of the pull-up resistors. The selected value of the resistors depends on the communication frequency and the bus capacitance. A larger bus capacitance and pull-up resistor size causes longer rise time on the clock and data 2 lines. The I C specification provides a maximum rise time. 2 2 I Cm uses all the CPU resources while reading or writing to a slave. If the application code has to write to the data or drive 2 mode registers of the port in which I Cm is placed, take care to use the shadow registers to avoid problems with 2 the I C interface. If the rise time on the bus exceeds the maximum, I C 2 communication does not occur properly. The I C specification offers the graph shown in Figure 18 to determine the value of the pull-up resistors. RS is a series 2 resistor; the I C specification defines the maximum RS. Pull-up resistors between 2.2 k and 4 k work for most systems. Figure 18. Pull-up Resistor Value Special I2C Considerations 2 I C offers an easy way for devices to communicate with one another. As with any design, problems may occur during the design process. This section seeks to answer common questions and prevent problems that may occur 2 when designing with I C. It includes the following topics: 7-bit and 10-bit addressing Pull-up resistor consideration 2 Sharing I C and ISSP pins Glitches during power-up 2 SYSCLK versus I C clock speeds Clock stretching and interrupt latency I2C and ISSP Programming Conflicts Hot swapping One common consideration when using I C with PSoC is the choice of which pins to use. When using the hardware 2 block, there are two pairs of fixed pins available for I C: P1.5, P1.7 and P1.0, P1.1. (In the 28xxx family, you can also use P1.2 and P1.6 or P3.0 and P3.2.) You can also use pins P1.0, P1.1 to program PSoC. Pull-up resistors on these lines can cause in-system programming failures. 2 Glitch filtering 2 I C and sleep 2 I C and dynamic reconfiguration Dynamic addressing in I2CHW www.cypress.com During programming, P1.0 uses the resistive pull-down drive mode to force a logic level LOW on the line. The pulldown resistor is approximately 5.6k. This internal pull2 down resistor and the external I C pull-up resistor create a Document No. 001-50987 Rev. *E 12 Getting Started with I2C in PSoC® 1 voltage divider. The voltage divider applies an indeterminate or HIGH logic level on the line, which the programmer does not recognize as the desired LOW logic level. This causes programming to fail. See the DC programming specifications and GPIO logic levels in the device specific datasheets to determine which voltage levels are appropriate. The best solution is to use P1.5, P1.7. Only use P1.0, P1.1 when it is necessary. Another option is to change the drive mode in PSoC to pull up for P1.0, P1.1, instead of using external pull-up resistors. The internal pull-up resistors are approximately 5.6 k. Pin Glitches at Power-up After the part is released from reset, P1.0 drives out a 2 strong HIGH. This will cause issues if one of the other I C devices on the bus is driving the line LOW. P1.1 drives out a resistive LOW. As stated earlier, this will create a voltage divider and an intermediate voltage on the bus, which other devices may not recognize. After a set amount of time, P1.0 transitions to a resistive LOW, causing an intermediate voltage on that line. 2 Be aware of this behavior and how it will affect I C devices 2 on the bus, if other I C devices are powered and connected to P1.0 and P1.1 when you start PSoC. 2 To avoid this issue, use P1.5 and P1.7 for I C communications. Or take steps to minimize the impact of the pin behavior on P1.0 and P1.1 during reset. This can be as simple as keeping all other devices in reset until PSoC has started up. Or implement a more complicated solution such as gating the output of PSoC with a transistor or logic gates. See Figure 19. Figure 19. Isolating PSoC S D Set pin X to strong and write a ‘1’ to it to connect to 2 the I C bus. Clock Speeds 2 As stated earlier, the I C hardware is responsible for generating the clock on SCL when it is in master mode. 2 The available I C clock frequencies in PSoC 1 are 50 kHz, 100 kHz, and 400 kHz. These frequencies are based on hardwired clock dividers of the system clock (SYSCLK). These clock dividers produce sampling clocks that 2 oversample the I C lines 16 or 32 times. Table 4 lists the internal sample rate. Table 4. Internal Sampling Rates As already stated, P1.0 and P1.1 are used for programming, which means that these pins behave differently at power-up than other pins. I2C SDA PSoC Pin 1_0 Clock Rate SYSCLK Pre-Scaler Internal Sampling Clock Frequency (SYSCLK=24 MHz) Samples Per Bit 50 kHz /16 1.5 MHz 32 100 kHz /4 1.5 MHz 16 400 kHz /16 6 MHz 16 The internal sampling clocks assume that SYSCLK is at 2 24 MHz. If SYSCLK is slower than 24 MHz, the I C clocks are slower. For example, if SYSCLK is 12 MHz, then the available speeds are 25 kHz, 50 kHz, and 200 kHz. If 2 SYSCLK is 6 MHz, the available I C speeds are 12.5 kHz, 25 kHz, and 100 kHz. (See Table 5.) Table 5. Actual Frequency versus IMO and UM Setting IMO (SYSCLK) Setting UM Setting 24 MHz 12 MHz 6 MHz 400 kHz 400 kHz 200 kHz 100 kHz 100 kHz 100 kHz 50 kHz 25 kHz 50 kHz 50 kHz 25 kHz 12.5 kHz BSS145 G D I2C SCL S Note SYSCLK is separate from CPU_Clock. Pin 1_1 When operating in slave mode, the same rules apply for 2 the highest clock speed that the I C block can read. The 2 oversample clock is used to monitor the I C lines. Setting the speed in slave mode indicates how often the clock and data lines are oversampled by the hardware. BSS145 G Pin X (to enable I2C) 100k Notes 2 It is important to place the N channel FETs used in this block so that the source of the FET is attached to the PSoC GPIO pin. The FETs must be N channel and must have a VGSTH rating of ≤ PSoC Vdd. For example, if the PSoC Vdd = 3.3 V, choose an N channel FET with a rating of VGSTH ≤ 3.3 V. www.cypress.com If the I C clock frequency is 400 kHz and the hardware is configured for 100 kHz, the hardware will not receive data 2 properly. One common mistake is to set the I C slave clock frequency in PSoC Designer to 100 kHz and SYSCLK to 6 MHz. The assumption that the slave will operate on the 100 kHz bus is incorrect. Because SYSCLK is at 6 MHz, the slave can only operate on a 25kHz bus. Therefore, to operate on a 100-kHz bus with a 2 SYSCLK of 6 MHz, choose 400 kHz as the I C speed in the user module properties. Document No. 001-50987 Rev. *E 13 Getting Started with I2C in PSoC® 1 The frequency of SYSCLK depends on the supply voltage for PSoC. If the supply voltage is above 3 V, then most devices have a 24-MHz SYSCLK. If the supply voltage is below 3 V, then many devices have a 6-MHz SYSCLK. Several devices have a 12-MHz SYSCLK option. Further, the value of SYSCLK can be changed within PSoC 2 Designer. When using I C, do not change the frequency of SYSCLK or the CPU_CLK; this can cause glitches on the 2 I C lines. For more information on clocks, see the clock section of the Technical Reference Manual. Figure 21. Byte Complete Interrupt Timing Max 4 Cycles Internal Sampling Clock SCL Interrupt Transmit: Ninth positive edge SCL Receive: Eighth positive edge SCL When using an external clock, be sure to use the correct 2 I C clock speed. Clock Stretching and Interrupt Latency Clock stretching is the process in which a slave device holds the clock line LOW, thus stalling further communication on the bus by the master. The slave device typically stretches the clock so it can process information it is receiving from the master or prepare more data to send to the master. This stretching can be done at any point of the transaction. PSoC stretches the clock after the byte complete interrupt. See Figure 20. 2 The I C specification indicates that this is an optional 2 feature; not all I C devices need to support clock 2 stretching. However, all Cypress PSoC 1 I C slave UMs stretch the clock. If you use a master that does not support clock stretching, the bus can lock up and fail to reset. Figure 20. Clock Stretching Example START 7-Bit Address R/W ACK 1 7 8 Using this information, you can determine if the clock will be stretched and for how long. However, if there are other interrupts in the system, the time spent in those interrupts must be considered. To minimize clock stretching in PSoC, the first step is to 2 run the CPU at 24 MHz. Next, the I C clock speed must be 100 kHz or lower. Last, having minimal interrupts reduces clock stretching. Hot Swapping Hot swapping is the process of attaching powered devices 2 to an unpowered PSoC. I C in PSoC is not designed to be hot swappable. There are several factors to consider when hot swapping PSoC. The first issue is back powering. If PSoC is not powered but one of the external pins is at a high voltage level, then there is a possibility of back powering the PSoC device. This is not a desirable situation, because PSoC may execute in unexpected ways 2 and the I C lines may be adversely affected. Glitch Filtering 9 The input of the SCL has a glitch filter, which Figure 22 shows. Clock Stretching The time the PSoC slave spends stretching the clock depends on whether the master is reading or writing to the slave and whether other interrupts occur in the system. It also depends on the CPU speed. Figure 22. SCL Glitch Filter SCL Pin INPUT 0 PSoC 1 devices will stretch the clock a majority of the time 2 for I C bus speeds of 100 kHz or greater. The ISR code in the EzI2Cs and I2CHW UMs contain 150 to 300 CPU instruction cycles. With a 24-MHz CPU clock, the ISR takes approximately 6 to 13 µs to execute. The SCL line is released at the end of the ISR code. The ISR is triggered three or four internal sample clock periods after the rising edge of SCL; see Figure 21. This is due to an internal glitch filter on SCL; see Figure 22. Refer to Table 4 for the frequency of the sampling clock. For 100 kHz, the sample clock is 1.6 MHz, which means that the ISR will fire ~2.5 µs after the rising edge of SCL. The nominal period of a 100-kHz clock is 10 µs. If it takes 2.5 µs for the ISR to be triggered and the ISR takes 6 to 13 µs, the clock will be stretched in most cases. 1 SAMPLE CLK The input is double-synchronized to the sample clock, and then it is glitch-filtered. The raw input and the delayed input must match for a signal to pass through. Because the sample clock is either 1.5 MHz or 6 MHz, glitches less than 666 ns and 166 ns are suppressed. I2C and Sleep 2 When using I C in designs that enter and exit sleep mode, you need to take special design considerations into account. 2 First, it is important that all I C transactions are complete 2 before the I C enters sleep mode. Otherwise, when the 2 part wakes up, the I C block can erroneously interpret data www.cypress.com Document No. 001-50987 Rev. *E 14 Getting Started with I2C in PSoC® 1 2 as an address or vice-versa. After confirming that all I C traffic has stopped, follow these steps: Configure the I C pins in a HIGHZ drive mode. Clear any pending I C interrupts. 2 Figure 23. I CHW UM Slave Address 2 2 Disable the I C block. This is generally done by calling the stop() API of the UM. 2 After these conditions are met, PSoC can be put to sleep. When the part wakes from sleep, follow these steps to 2 ensure proper I C operation after sleep: 2 Ensure that no I C activity is occurring on the bus. Call the appropriate start API. Follow these steps to replace the constant with a RAM variable: 1. 2 Configure I C pins for open-drain drives LOW. Enable interrupts. Create a RAM variable to hold the dynamic slave address. In the I2CHW_1int.asm file, just below the variable allocations, is a custom user code area. Under the custom declaration area, add this code: If you follow these steps, you can avoid most errors when 2 using I C in conjunction with sleep. export _I2CSlaveAddress export I2CSlaveAddress I2C and Dynamic Reconfiguration Under the variable allocation area, add the following: 2 I C UMs should never be loaded or unloaded through dynamic reconfiguration. They should always be present. 2 If they are loaded and unloaded, I C errors will occur. Area InterruptRAM(ram) _I2CSlaveAddress: I2CSlaveAddress: BLK 2 The I C UMs should be located either in the base configuration or in a separate overlay that is always loaded. Dynamic Slave Addressing in I2CHW UM The variable with the ‘_’ allows you to modify this in C code. 2. 2 In the I CHW UM, the address from the master is processed inside the I2CHW_1int.asm file. The following code does the address matching. A, reg[I2CHW_1_DR] F, 0xF9 A A, I2CHW_1_SLAVE_ADDR www.cypress.com A, reg[I2CHW_1_DR] F, 0xF9 A A, [I2CSlaveAddress] Because this code is inside a custom user code area, changes to the UM library file are preserved during application generation. Note that if you rename the UM, changes will be lost and must be made again. 3. When the address is received from the master, it has a 7-bit address and the read/write bit. The ‘rrc A’ drops the read/write bit and compares the 7-bit address with the constant I2CHW_1_SLAVE_ADDR, which the device editor creates according to the Slave_Addr set in the UM 2 parameters for the I CHW. This constant is located in the I2CHW_1.inc file. Modify the code that does the address comparison. mov and rrc xor The EzI2Cs UM allows you to programmatically change 2 the I C slave address on the fly. However, this functionality 2 is not available in the I CHW UM; to achieve the same functionality, do the following: mov and rrc xor 1 2 Add a reference to the I C slave address variable that is defined in the I2CHW_1int.asm file by adding the following code in main.c (or any other C file). extern BYTE I2CSlaveAddress; The SCL Line Gets Stuck LOW 2 A common issue with I C is the SCL getting stuck LOW. Follow these guidelines for debugging and fixing this issue with PSoC 1 devices: 1. Are you using EzI2Cs with PSoC Designer 5.0 SP5? If yes, there is a known bug with this version of the UM that causes the SCL to be stuck LOW. Update to the latest version of PSoC Designer to fix this issue. 2 See the article I C Clock Permanently Stuck to Logical LOW. 2. Are you using PSoC Designer version prior to PD5.0? If yes, then there are glitches on P1.5, P1.7 at startup. Document No. 001-50987 Rev. *E 15 Getting Started with I2C in PSoC® 1 This issue has been resolved in the latest version of PSoC Designer. For more information, see the article 2 Glitch on the I C Lines During Power-Up. 3. Does the master device support clock stretching? If no, then the communication between the slave and master will become unsynchronized and undesirable behavior may occur, including the SCL being stuck LOW. If the master does not support clock stretching, there is no guarantee of PSoC functioning properly on the bus. 4. Does the CPU clock or SYSCLK change dynamically during code execution? If yes, this can cause glitches on the SCL and SDA. To avoid this problem, do not change clock speeds in code. 5. Are you enabling and disabling I C interrupts in your code? If yes, make sure you are using the ResumeInt API and not the EnableInt API, which clears the 2 interrupt. If there is a pending I C interrupt and you clear it, SCL will be stuck LOW forever. 6. 7. 2 2 Can there be other I C traffic on the bus when PSoC starts up? If yes, then there is a known bug that has been fixed in the latest version of PSoC Designer. If you do not have the latest version and cannot update, use the following workaround: In the chip editor, set 2 the drive mode of the I C pins to analog High-Z. In the 2 main code, enable the I C UM. Then set the drive 2 mode of the I C pins to open-drain drive LOW. Summary 2 I C is a simple two-wire chip-to-chip digital communication protocol. The protocol is master oriented but allows bidirectional communication on just two communication lines. The Cypress PSoC offers several user modules for 2 the implementation of I C in a design that includes 2 slave, master, and multimaster configurations. I C communication in PSoC is easy and reliable if you follow the considerations that Cypress recommends. About the Authors Name: Todd Dust Title: Application Engineer Background: BSEE Seattle Pacific University Name: M. Ganesh Raaja Title: Application Engineer Principal Background: Ganesh earned his Diploma in Electronics and Communications Engineering at Motilal Nehru Govt. Polytechnic in Pondicherry, India. He has about 20 years of experience in analog circuit design and microcontrollers. He also writes the blog PSoC Hacker on the Cypress website. Is sleep being used in the project? If yes, follow the steps in the sleep section to avoid any issues. The latest version of PSoC Designer has fixes and workarounds for a majority of the issues discussed above. Cypress always recommends using the latest version of PSoC Designer. www.cypress.com Document No. 001-50987 Rev. *E 16 Getting Started with I2C in PSoC® 1 Appendix A This appendix is for users who are curious about the 2 detailed operation of the I C hardware block in PSoC. Hardware Registers 2 Several registers control the I C hardware block and report its status. 2 I2C_CFG Register: Controls the configuration of the I C hardware block. It controls the clock speed and the pins being used, and it indicates if the slave or master functionality is enabled. It also enables support for interrupts on stop conditions and bus errors. 2 I2C_SCR Register: Returns status flags from the I C hardware block. It reports if a full byte (byte complete) is sent or received. This register indicates if a bus error has occurred or if arbitration is lost. It also determines if the last transaction was an address. I2C_DR Register: This register holds the value of data sent or received. It shifts data in only if the data is an address, if the hardware block is configured as a slave and is addressed, or if the master has initiated a read. I2C_MSCR Register: This register controls the master 2 portion of the I C transaction. It holds the bit that allows generating a start. The enable master bit in the I2C_CFG register must be set for this register to be available; otherwise, this register is held in reset. Firmware Requirements This section describes the operation of the hardware block for different configurations. Note that wherever the text 2 mentions a requirement of firmware, all PSoC I C user modules run this code. Start Generation If the start gen bit is set in the master status and control register, the hardware block generates a start condition and sends out the address in the data register. However, the hardware recognizes if another device has taken control of the bus. If an external start condition is detected, the hardware queues the current start until the bus is free. The start bit is not cleared until the hardware has successfully sent out a start condition or the firmware has cleared it. Only one start can be queued at a time. If the master attempts to send two starts while the bus is busy, the hardware sends only the last address. As stated earlier, the user code must ensure that this situation does not occur. Master Operation In master mode, after the start and address are sent, the hardware waits until the ACK/NAK bit from the slave is received. On receiving the ACK/NAK bit, the hardware interrupts the CPU. Firmware then determines if the slave acknowledged or did not acknowledge the address. It does so by reading the last received bit (LRB) in the www.cypress.com I2C_SCR register. If the bit is a zero, then the slave has acknowledged; if the bit is a one, then the slave has not acknowledged. Take appropriate action depending on this condition. Firmware is also responsible for setting the direction of communication. This is done by setting the transmit bit in the SCR register. If a zero is written to the bit, the block is placed in receive mode. In this mode, the hardware interrupts the CPU when it receives eight data bits. After this interrupt, the firmware must determine if an ACK/NAK needs to be sent. If a ‘1’ is written to the transmit bit, the block is placed in transmit mode. In this mode, the hardware interrupts after the ACK/NAK is received from the slave device. The firmware again handles these cases. When the SCR register is written, the master will start to generate clocks to either send or receive more data. S l a ve O p e r a t i o n When the hardware detects a start condition in slave mode, it shifts the next eight bits of data into the I2C_DR register. On receipt of the eighth bit, the hardware block interrupts the CPU and causes the address bit in the I2C_SCR register to go HIGH. When the interrupt is posted, the hardware holds the clock line LOW. It is then the firmware’s responsibility to read the incoming address and acknowledge whether the address is its own. The firmware must set the ACK bit in the SCR register appropriately. The firmware should also read the read/write bit of the address. If the bit is a ‘1,’ then the transmit bit in the SCR register is changed to a ‘1.’ After the CPU writes to the SCR register, the hardware releases the clock line, which allows the transaction to continue. If the slave is configured as a transmitter, firmware must load valid data into the DR register before writing to the SCR register and releasing the bus. After the bus is released, the hardware shifts data out to the SDA line on the clock edges provided by the master. The hardware waits until it receives an ACK/NAK from the master and then interrupts the CPU. The firmware then must load new data or do nothing. If the slave is configured as a receiver, the hardware interrupts after the eighth bit of data is received. The firmware then decides if it can receive more data. It must then set the ACK bit appropriately. Stop Condition When a transaction is completed in master mode, the hardware block generates a stop condition to indicate that the bus is free. In slave mode, the reception of a stop puts the hardware block into an idle mode until it receives a new start condition. Document No. 001-50987 Rev. *E 17 Getting Started with I2C in PSoC® 1 Interrupt Sources In the earlier examples, the hardware block interrupts on a byte-complete condition. The occurrence of this interrupt depends on the direction of communication. Arbitration The hardware block can also indicate if the master loses arbitration. This is necessary when operating in multimaster mode. Arbitration occurs when two masters start writing at the same time. The hardware monitors the SDA line. If the master attempts to leave the bus HIGH but another master pulls it LOW, the master signals that it has lost arbitration. After the arbitration condition, the hardware does not control the SDA line but continues to clock the SCL line. On a subsequent byte-complete interrupt, it is the firmware’s responsibility to view the lost arbitration bit to see if arbitration was lost during the previous transfer. Transmit: Byte Complete Interrupt = Ninth bit Receive: Byte Complete Interrupt = Eighth bit The hardware block allows two additional interrupt sources. Setting the appropriate bit in the I2C_CFG register enables these interrupts. The hardware is capable of interrupting on a stop condition. This is useful when operating in slave mode; the interrupt alerts the firmware that the current transaction is complete. The next available interrupt is on a bus error, which is a misplaced start or stop on the bus. If the hardware detects the interrupt, it stops its current activities and posts the interrupt; the firmware then decides what to do with this situation. 2 Basic I C Flow 2 Figure 24 and Figure 25 show the basic flow for I C transactions. This is the basic flow needed to implement 2 I C in PSoC 1 successfully. The provided UMs follow this flow with added overhead. Figure 24. Flow Diagram for a Successful Slave Transmitter/Receiver Master transmits another byte CPU writes (ACK) to I2C_SCR register. An interrupt is generated on byte complete. START 7-Bit Address 7 8 ACK = Slave OK to receive more. Master may send more or issue stop. STOP Write (RX) ACK/ NAK 1 7 8 CPU reads the received byte from the I2C_D register and checks for “Own Address” and R/W. 9 NAK = Slave says no more. CPU reads the received byte from the I2C_D register. Read (TX) 1 R/W SCL line is held LOW. CPU issues ACK/ NAK command with a write to the I2C_CSR register. 8-Bit Data ACK A byte interrupt is generated. SCL line is held LOW. CPU writes the byte to transmit to the I2C_D register. CPU writes (ACK | TRANSMIT) to I2C_CSR register. An interrupt is generated on a complete byte + ACK/NAK. SCL line is held LOW. 8-Bit Data ACK ACK/ NAK 9 1 7 8 NAK = Master says end of data. STOP 9 ACK = Master wants to read another byte. CPU writes a new byte to the I2C_D register and then writes a TRANSMIT command to I2C_SCR to release SCL. www.cypress.com Document No. 001-50987 Rev. *E 18 Getting Started with I2C in PSoC® 1 Figure 25. Flow Diagram for a Successful Master Transmitter/Receiver CPU issues ACK/ NAK command to the I2C_SCR register. An interrupt is generated on byte complete. An interrupt is generated after the ACK is received. 7-Bit Address R/W ACK STOP ACK/ NAK 1 7 8 9 Read (RX) START 8-Bit Data CPU issues a command to the I2C_CSR. CPU issues GENERATE START command to I2C_MCR. ACK = Master wants more. CPU reads the received byte from I2C_D register. NAK = Master indicates end of data. 1 CPU writes address byte to the I2C_D register. 7 8 9 Write (TX) CPU checks Read/ Write Bit CPU issues TRANSMIT command to the I2C_SCR register, starting the transfer. CPU writes a byte to transmit I2C_D register. An interrupt is generated on completion of the byte + ACK/NAK. 8-Bit Data ACK/ NAK 1 7 Master wants to send more bytes. www.cypress.com Document No. 001-50987 Rev. *E 8 CPU issues STOP command NAK = Slave says no more. STOP 9 ACK = Slave says OK to receive more. Master can send more or Stop. 19 Getting Started with I2C in PSoC® 1 Appendix B This appendix describes various example projects that 2 demonstrate the use of the I C UMs. written to the variable ADCValue. A master device can read this variable. EzI2Cs_ADC_LED_DAC Example Project In firmware, a local copy for LEDValue and DACValue are created. The values of LEDVAlue and DACValue in the 2 I C register structure are continuously compared with the local copies of these parameters. When the master writes a different DAC value or LED value, then the LED ports (P0[0] to P0[3]) and DAC are updated with the new values. The DAC output is available on P0[5]. This project demonstrates how to configure the EzI2Cs 2 UM. The project configures PSoC as an I C slave and may 2 be considered as an implementation of an I C-controlled analog peripheral device and port expander. This project creates the following data structure: Testing the Project Figure 27 shows the setup for project testing. Use a CY3210 PSoC 1 evaluation board to wire the setup. struct I2CRegs { BYTE LEDValue;/* Updates LEDs */ BYTE DACValue;/* Updates DAC */ BYTE ADCValue;/* Reads ADC value */ }I2CRegs; Figure 27. Schematic for EzI2Cs_ADC_LED_DAC_Project 2 The structure is exposed to the I C master through the following API call: EzI2Cs_1_SetRamBuffer(sizeof(I2CRegs), (BYTE *) &I2CRegs); 2, The first parameter sets the size of the structure. The second parameter sets the number of parameters that have read-write permission. Parameters beyond this boundary are read-only. In this structure, LEDValue and DACValue are read-write and ADCValue is read-only. The final parameter is the pointer to the structure itself. Configure the EzI2Cs UM in the chip view as shown in Figure 26. Figure 26. EzI2Cs UM Configuration P0[0] to P0[3] are connected to the LED1 to LED4 signals on J5. P0[7] is connected to the variable resistor VR. A digital multimeter is connected to P0[5] to monitor the DAC output. The LCD is connected to the LCD connector J9. A CY3217 MiniProg1 or CY8CKIT-002 MiniProg3 can be used to program the device using the ISSP header on the CY3210 board. See Table 6. 2 A CY3240 USB-I C Bridge PSoC Development Kit or 2 MiniProg3 may be used as I C master. Figure 28 shows the CY3210 board with the project in action. The CY3240 2 I C-USB bridge is used here. Table 6. Setup on the CY3210 Evaluation Board Set the slave address to 0x04; set the address type to static; disable the ROM registers; set the clock speed to 2 400 kHz, fast mode; and use P1[0] and P1[1] as I C pins. P1[0] and P1[1] are used in such a way that the ISSP port on the CY3210 PSoC 1 evaluation board can also be used 2 to connect the I C master. PSoC 1 Pins CY3210 Connections P0[0] to P0[3] LED1 to LED4 Connect P0[3:0] to the 4 LEDs P0[7] VR Potentiometer input P0[5] - Connect multimeter - ISSP header (J11) Connect MiniProg1 or MiniProg3 for programming - ISSP header (J11) Connect Cy3240/MiniProg3 for I2C communication to PC Description In firmware, an ADC is used to read the voltage on P0.7. You can simulate different voltages by connecting a potentiometer to this pin. The value read by the ADC is www.cypress.com Document No. 001-50987 Rev. *E 20 Getting Started with I2C in PSoC® 1 Figure 28. Test Setup for EzI2Cs Example Project Figure 29. Bridge Control Panel Command Window Status/Response Window There are two methods for testing the project. You can use Bridge Control Panel software or an external MCU. Using Bridge Control Panel Software to Test The Cypress Bridge Control Panel software acts as a 2 graphical front end to communicate with PSoC I C slave devices. It is useful for testing, tuning, and debugging 2 programs that have an I C slave interface. You can install the Bridge Control Panel with PSoC Designer and PSoC Programmer™. After programming the device, connect the CY3240 or MiniProg3 to the ISSP connector. The CY3240 and the MiniProg3 have the pull-up resistors required for the SDA 2 and SCL lines of the I C. The following steps show how to use the Bridge Control Panel to read the value of ADC and to control the LED and DAC outputs of the EzI2Cs_ADC_LED_DAC project. 1. Open Bridge Control Panel from the Windows start menu. It is located in the Cypress folder. 2. Select the MiniProg3 or the CY3240 from the device list and click the Connect button. 3. Next, click the Power button to supply power to the CY3210 test setup. (See Figure 29.) Power Button 4. Connect Button To write to the LED and DAC parameters, type the following command in the command window of the Bridge Control Panel: w 04 00 03 80 p ‘w’ is the write command. ‘04’ is the slave address. ‘00’ is the subaddress where the values have to be written. ‘03’ is the value for LED. For a value of 03, LED1 and LED2 will be turned on. ‘80’ is the DAC output. The output of the DAC is about 2.09 V for this value. When you enter this command in the command 2 window and press Enter, the I C master transmits the command to the EzI2Cs slave. Observe the state of LED and the output on P0[5] in the results window. (See Figure 30.) w 04+ 00+ 03+ 80+ p A ‘+’ sign after each byte indicates that the EzI2Cs slave acknowledged the byte. A ‘−’ sign indicates that the byte was not acknowledged. For example, try the following command: w 04 00 03 80 55 p The response would be: w 04+ 00+ 03+ 80+ 55- p Because we have set the third byte in the EzI2Cs register structure as read-only, the slave will not acknowledge (NAK) the write to this register. www.cypress.com Document No. 001-50987 Rev. *E 21 Getting Started with I2C in PSoC® 1 Figure 30. Write LED and DAC Values This write command sets the subaddress in the EzI2Cs. Any further read operation will take place on subaddress 0x0, which is the ADC value. Next, type the following command and select the Repeat button. Observe only the ADC value being read. r 04 x p Figure 32. Read Only the ADC Register 5. To read the ADC result, type the following command in the command window: r 04 x x x p ‘r’ is the read command. ‘04’ is the slave address. The three ‘x’s indicate how many bytes to read from the slave. Now click the Repeat button in the Bridge Control Panel and observe the result in the results window. (See Figure 31.) 2 Figure 31. Read All of the I C Registers Using an External MCU to Test You can also test the project with another microcontroller 2 2 acting as an I C master. This section demonstrates the I C interface with an Arduino Duemilanove board configured 2 as an I C master and assumes that you are familiar with the Arduino prototyping platform. For more information on this board and the Arduino platform, visit www.arduino.cc. Refer to Getting Started with Arduino for instructions on connecting the Arduino board to the PC and uploading the program. 2 The Arduino device is configured to have an I C master interface on the dedicated pins (AIN4, AIN5) and one PWM output on pin 11. 2 The CY3210 is configured as an I C slave having a 4-bit digital display (four LEDs), one analog output (DAC), one analog input (potentiometer connected to analog input pin), and an LCD display. The last byte in the response is the ADC result. The second and third bytes show the values of the LED and DAC parameters respectively. 6. If you want to read only the ADC value and not the LED and DAC values (see Figure 32), first execute the following command: w 04 02 p www.cypress.com 1. Program the CY3210 board with the example project. 2. Open the included Arduino project “Arduino_I2C_Master_PSoC1_Slave.ino” using Arduino software. 3. From Tools, select Board and then the Arduino Duemilanove option. 4. From Tools, select Serial Port and then the port on which the board is connected. 5. Download the program to the board using a USB A-B cable. Detach the USB cable after programming is complete. 6. Make hardware connections according to Table 7. Document No. 001-50987 Rev. *E file the 22 Getting Started with I2C in PSoC® 1 Table 7. Hardware Connections Figure 33. Arduino-to-PSoC Interface Connections on Arduino Duemilanove Pin Connection Pin 11 (PWM) Connect an LED Description PWM output on Arduino Connections on CY3210-PSoC Evaluation Board Pin Connection Description P00 LED1 on J5 Digital output Bit 0 P01 LED2 on J5 Digital output Bit 1 P02 LED3 on J5 Digital output Bit 2 P03 LED4 on J5 Digital output Bit 3 P05 Multimeter/Scope Analog output (DAC) P07 VR on J5 Analog Input (ADC) CY3210 to Arduino Connections Arduino Pins PSoC 1 Pins Description Analog in 4 (A4) P10 on J7 SDA for I2C Analog in 5 (A5) P11 on J7 SCL for I2C 5V VCC on J5 Power PSoC 1 board using Arduino 5 V GND GND on J5 Ground 7. Connect a CY3217 MiniProg1 or CY8CKIT-002 MiniProg3 to the ISSP header on the CY3210 board. After programming, remove the programmer from the ISSP header. 8. Reattach the USB cable to the Arduino board. This will power both the Arduino board and the CY3210 board. Figure 33 gives a snapshot of the setup. PSoC reads the voltage on P07 (connected to potentiometer) and stores the value in ADCValue. Arduino 2 reads this value using the I C and controls the PWM output on pin 11. Turning the potentiometer on the CY3210 varies the brightness of the LED on the Arduino board. 2 Arduino continuously sends a 4-bit pattern over the I C interface. PSoC reads this value and writes to Port0 pins, which are connected to the four LEDs. Arduino also continuously sends an 8-bit digital value, which is converted to an analog voltage by the PSoC DAC. The DAC code sent is an incremental value from 0 to 255. Figure 34 shows the DAC output waveform on the PSoC pin (P05) when viewed on an oscilloscope. This example thus shows how an external MCU can 2 interface with a PSoC device using I C. www.cypress.com Document No. 001-50987 Rev. *E 23 Getting Started with I2C in PSoC® 1 Testing the Project Figure 36 shows the setup for project testing. Figure 34. DAC Output Waveform on P05 2 Figure 36. Schematic for I CHW_Slave Project The only connections required to test the project are the ISSP connections. The same ISSP connector is also used 2 to connect the I C master. (See Table 8.) I2CHW Slave Example Project Table 8. Connections for Project Testing 2 This project demonstrates how to configure I CHW as a slave. 2 In this project, the data that is written to the I CHW slave is echoed back to the master. This is done by configuring the read and write buffers as the same buffer. To do so, use the following API: /*When master writes data it will write to rxtxBuffer*/ I2CHW_1_InitWrite(rxtxBuffer, 10); /*When master reads data it will read from rxtxBuffer*/ I2CHW_1_InitRamRead(rxtxBuffer, 10); The main code checks to see if a master device has read 2 or written to the I CHW slave. If it has, then the code will reset the buffers and clear the appropriate status flags. 2 Figure 35 shows the configuration of the I CHW UM. The slave address for the device is 0x04. 2 Figure 35. I CHW UM Slave Configuration PSoC 1 Pins CY3210 Connections Description - ISSP header (J11) Connect MiniProg1 or MiniProg3 for programming - ISSP header (J11) Connect Cy3240 or MiniProg3 for I2C communication to PC 2 You can test the I CHW slave project using the CY3210 PSoC 1 evaluation board. Use a CY3217 MiniProg1 or CY8CKIT-002 PSoC MiniProg3 to program the device, using the ISSP header on the CY3210 board. 2 2 Use a CY3240 USB-I C Bridge or MiniProg3 as the I C master. Figure 37 shows how to use the Bridge Control Panel to 2 write and read values from the I CHW slave. Refer to the EzI2Cs_ADC_LED_DAC example project for a brief description of how to set up the Bridge Control Panel. 1. Type the following commands in the command window of the Bridge Control Panel: w 04 00 01 02 03 04 05 06 07 08 09 p r 04 x x x x x x x x x x p w 04 0a 0b 0c 0d 0e 0f 10 11 12 13 r 04 x x x x x x x x x x p 2. Select the “Send all strings” option and click the Send button to execute all of the commands in sequence. Observe in the results window that the same values written using the write command are being read back while executing the read command. www.cypress.com Document No. 001-50987 Rev. *E 24 Getting Started with I2C in PSoC® 1 2 Figure 37. Writing and Reading the I CHW Slave When the slave generates an ACK, the master exits the while loop. Next, the master reads the data that it just wrote to the EEPROM. This is done by first writing the two subaddress bytes and then reading out 64 bytes of data from the EEPROM. The master then compares the read data with the written data. When all 64 bytes match, an LED is turned on. To test this project, connect P1.5 and P1.7 to the SDA and 2 SCL of an external I C EEPROM. Make sure that you have external pull-up resistors on those lines. Connect an LED with a series resistor to P0_7. You can test the project using a CY3210 PSoC evaluation board. (See Table 9.) Table 9. Connections for Project Testing PSoC 1 Pins I2CHW Master Example Project P1[5] 2 This project demonstrates how to use the I CHW UM in master mode. Specifically, it demonstrates how to use the 2 2 I CHW UM to read and write to an external I C EEPROM. 2 P1[7] P0[7] CY3210 Connections 2.2-kΩ pull-up to VDD 2.2-kΩ pull-up to VDD LED1 Description Connect to SDA of 24C256 IC Connect to SCL of 24C256 IC LED indicator Figure 38 shows how to configure the I CHW UM. 2 Figure 38. I CHW Master Configuration Figure 39 shows the setup for project testing. Figure 39. I2CHW_Master Test Schematic 2 In the main code, the I CHW UM is initialized. After that, it writes out 66 bytes to the EEPROM from the RAMBuffer array. The first two bytes are the subaddress where the data is written in the EEPROM. This project is tested with a 32Kb EEPROM, which has a page size of 64 bytes. When writing to smaller EEPROMs, limit the write to the page size of the particular EEPROM. When data is written to the EEPROM, the EEPROM enters a write cycle. During this time, the slave does not 2 generate an ACK to any I C transaction. Any further operation can be done only when the EEPROM completes the write cycle. To detect this, the master enters a “while” loop in which it continuously sends a start and checks the ACK status. while(!(I2CHW_fSendStart(0x50, I2CHW_READ))) { I2CHW_SendStop(); } www.cypress.com Document No. 001-50987 Rev. *E 25 Getting Started with I2C in PSoC® 1 Figure 40. Migrate Project Migrating Example Project The projects can easily be migrated to other devices using the built-in cloning feature of PSoC Designer. For example, to migrate the EzI2Cs_ADC_LED_DAC project: 1. Open PSoC Designer and create a new project. 2. Select the Clone option in the Project Creation parameter. 3. In the “Clone from Project” parameter, browse and select the EzI2Cs_ADC_LED_DAC.cmx file in the project folder of the EzI2Cs_ADC_LED_DAC project. Then choose the device that you want to run this project on by clicking the Device Catalog button. 4. After selecting the Device, click OK; PSoC Designer will migrate the project to the new device. (Refer to Figure 40.) www.cypress.com Document No. 001-50987 Rev. *E 26 Getting Started with I2C in PSoC® 1 Document History 2 ® Document Title: Getting Started with I C in PSoC 1 – AN50987 Document Number: 001-50987 Revision ECN Orig. of Change Submission Date Description of Change ** 2641969 TDU 01/21/08 New Application Note *A 3147658 TDU 01/19/2011 Updated Title to read “PSoC® 1 I2C Overview.” Updated Abstract section. Updated I2C and Sleep section. Minor edits. Specified PSoC 1 parts this Application Note is applicable too. *B 3427861 TDU 11/11/2011 Updated to New Template Modified Title Added 3 example projects Added Hardware Blocks in CY8C28xxx Updated sections I2CHW, Clock Speeds, and Clock Stretching and Interrupt Latency Added sections Glitch Filtering, I2C and Dynamic Reconfiguration, The SCL Line Gets Stuck , and Basic I2C Flow *C 3672732 GRAA 07/11/2012 Improved the flow in EzI2Cs section Added a section explaining the EzI2Cs parameters and steps to get it working in a project Added summary and important notes section for EzI2Cs Added sections explaining in detail the hardware and firmware configuration for the I2CHW in slave, master, and multimaster modes. Added summary and important notes section for I2CHW Added section explaining how I2Cm may be incorporated in a design. Added more details about using the shadow registers when using I 2Cm Added summary and important notes section for I2Cm Modified the I2CHW example project to interface to 24C256 EEPROM and updated Appendix D with the operation of the project. *D 4078726 GRAA 07/26/2013 Minor modifications throughout document. Updated the example projects. *E 4682397 GRAA 03/10/2015 Updated the example projects to PSoC Designer 5.4 Updated template Sunset review www.cypress.com Document No. 001-50987 Rev. *E 27 Getting Started with I2C in PSoC® 1 Worldwide Sales and Design Support Cypress maintains a worldwide network of offices, solution centers, manufacturer’s representatives, and distributors. To find the office closest to you, visit us at Cypress Locations. PSoC® Solutions Products Automotive cypress.com/go/automotive psoc.cypress.com/solutions Clocks & Buffers cypress.com/go/clocks PSoC 1 | PSoC 3 | PSoC 4 | PSoC 5LP Interface cypress.com/go/interface Lighting & Power Control cypress.com/go/powerpsoc Memory cypress.com/go/memory PSoC cypress.com/go/psoc Touch Sensing cypress.com/go/touch USB Controllers cypress.com/go/usb Wireless/RF cypress.com/go/wireless Cypress Developer Community Community | Forums | Blogs | Video | Training Technical Support cypress.com/go/support PSoC and CapSense are registered trademarks and PSoC Designer is a trademark of Cypress Semiconductor Corp. All trademarks or registered trademarks referenced herein are the property of their respective owners. Cypress Semiconductor 198 Champion Court San Jose, CA 95134-1709 Phone Fax Website : 408-943-2600 : 408-943-4730 : www.cypress.com © Cypress Semiconductor Corporation, 2009-2015. The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted or intended to be used for medical, life support, life-saving, critical control, or safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a personal, nonexclusive, nontransferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom software and/or firmware in support of licensee product to be used only in conjunction with a Cypress integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source Code except as specified above is prohibited without the express written permission of Cypress. Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’s product in a life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. Use may be limited by and subject to the applicable Cypress software license agreement. www.cypress.com Document No. 001-50987 Rev. *E 28