3 Replies Latest reply on Nov 27, 2018 6:34 AM by xahuc_3536641

    Implementing I2C (EZI2C) Slave Sub-address Read/Write

    xahuc_3536641

      Hi All,

       

      I am currently trying to implement an I2C Slave on my PSoC5LP and I am having a bit of trouble. I have to implement the I2C commands in the fashion of an eeprom, where each address corresponds to a single byte. From some research, using the EZI2C slave is a straightforward way to do this. It even has read and r/w sections and built in sub-addressing. This is the exact memory implementation I am hoping for.

       

      However, my small embedded system needs to be able to trigger functions upon the read and write of certain locations in memory. For example: upon a write to I2C address 0x70, memloc 0x34, it should trigger a stepper motor to step CW if a 0x01 is written to that memloc and CCW if a 0x00 is written. As far as I can tell, there's no way for the EZI2C implementation to tell WHICH addresses were written to or read from only that a read or write did occur. This becomes an issue because simply copying the readbuffer array to a new array and comparing the values wouldn't be good enough. I would need to trigger the stepper motor every time a 0x01 is written even if the previous value was already a 0x01.

       

      I initially tried doing this with the standard I2C component, but sub-addressing with that component seemed very difficult if not impossible.

       

      I am at a loss on the direction to go here and would like appreciate any guidance!

        • 1. Re: Implementing I2C (EZI2C) Slave Sub-address Read/Write
          BragadeeshV_41

          Hi,

           

          Please let me know if I have understood your requirement:

           

          You have a master device and a slave PSoC 5 (EZI2C). You need to find out to which location the master writing to in the slave and also perform tasks every time based on what is written.

           

          "my small embedded system needs to be able to trigger functions upon the read and write of certain locations in memory".

          Which memory are you talking about?

           

          Regards,

          Bragadeesh

          • 2. Re: Implementing I2C (EZI2C) Slave Sub-address Read/Write
            BragadeeshV_41

            Hi,

             

            Can you try this following implementation?

             

            EZI2C_GetActivity(void) : use this API and check if a write has been done, by checking the return value of this API. If it is EZI2C_STATUS_WRITE1, it means a write has been completed. Now inside this condition block, check if the buffer value equals your variable that points to the memory location and perform your application accordingly.

             

            If at all there any many other similar variables in  your design which the master can write to, then you can send one more control byte from the master something like if data is 01 then it is motor command, and then send your actual data. You can implement this using normal I2C also.

             

            Also sub addressing means, the maximum data buffer size that can be accessed by the master. If it is 8 bits, it means the master can access 256 locations in the slave. If it is 16 bits, then it means it can access 65536 locations in the slave.

             

            I recommend you to read functional description in the EZI2C component datasheet for more information on the buffers.

            http://www.cypress.com/file/139206/download 

             

            Regards,

            Bragadeesh

            1 of 1 people found this helpful
            • 3. Re: Implementing I2C (EZI2C) Slave Sub-address Read/Write
              xahuc_3536641

              That is essentially what I ended up implementing. I set a default value to the written arrays and just checked whether it had changed. I initially thought that was a bit inelegant, but it seemed to be the only direction to go.

               

              A small point about the EZI2C though: when the flag queried by GetActivity() is raised, that does not mean that the data has been fully copied into the buffer. There is a small amount of delay during which the data is moved into the buffer. This means that trying to read the data in the buffer as soon as the GetActivity() flag is raised will result in reading old data. Unfortunate that this is not listed as part of the data sheet.