12 Replies Latest reply on Dec 7, 2014 8:48 AM by DaKn_263916

    Interrupt based I2c communication

       I am develloping an application to read from multiple sensors using the I2c API on PSoC 5LP. I know the API functions such as I2C1_mstrWrBufIndex use interrupts to write multiple bytes. The usual way to use this function is to poll MasterWriteBuf to know when all data has been sent. What I would like though is to be able to send multiple byte to multiple devices (and rstarts) by constructing a queue (liked list) and uses interrupts to send new packets with minimal CPU intervention.

         

      I prefer not to modify the interrupt functions used by the API (I could call a function from this interrupt). My question is if there is a way to trigger an interrupt from the MasterStatus value. This trigered interrupt would then use the API to send a new packet. Or if there is a way to use directly the I2C API to send multiple packets without having to wait for each of them to be sent.

        • 1. Re: Interrupt based I2c communication
          JoMe_264151

          The I2C protocol does not allow to send data merged to different slaves. Each transmit has to be started with Sendstart() and will be ended by a SendStop(). In between no other slave can be addressed.

             

           

             

          Bob

          • 2. Re: Interrupt based I2c communication

            I am aware that the I2c protocol does not allow to merge slave slaves. What i want in fact is to issue multiple transmits sequentially to different slaves, but with minimal CPU intervention. I could make multiple calls to the I2c API, but this requires the CPU intervention during the whole transmit procedure.

               

            I've read discussion about using a DMA module to transfert data from SRAM to I2c, but i believe the I2c interface requires too much intervention for this. 

            • 3. Re: Interrupt based I2c communication
              JoMe_264151

              I checked the I2C sources but there is no chance for the original code to perform what you want.

                 

              You may always copy the original component including code, modify to your needs and use it instead of the original, but that's some work that's not done within 5 minutes.

                 

               

                 

              Bob

              • 4. Re: Interrupt based I2c communication
                DaKn_263916

                This is a stretch but makes me wonder if DFB engine + Assembler could

                   

                be used coupled with register writes to implement a parallel process to do

                   

                what you want. Torturous way to accomplish this but maybe possible ? I

                   

                am not sure the documentation is there to get this understood and done.

                   

                But food for thought as DFB runs independently from CPU and can handle

                   

                both DMA and general memory/register writes.

                   

                 

                   

                Regards, Dana.

                • 5. Re: Interrupt based I2c communication

                  Thank you for your answers!

                     

                  The DFB module sound interesting, but since I am not really familiar with it, I won't try for now (I might try eventually in an attempt to speed up the code). I am thinking of modifying the I2c module code.

                     

                  In the interrupt function, I believe I found where the stop condition is handle. I will add a call to a function where I feed new data (if any) using the API function (I2C1_MasterWriteBuf and I2C1_MasterReadBuf). In the interrupt function, something like this :

                     

                  if(I2C1_CHECK_STOP_STS(tmpCsr))

                     

                              {

                     

                                  I2C1_mstrStatus |= I2C1_GET_MSTAT_CMPLT;

                     

                                  I2C1_DISABLE_INT_ON_STOP;

                     

                                  I2C1_state = I2C1_SM_IDLE;

                     

                                  myFunction();

                     

                              }

                     

                  I will use in my code and the function mentioned above a linked list made of request, containing the slave address, a pointer to the data (read or write), the length and a flag whether I want to read or write to the slave.

                  • 6. Re: Interrupt based I2c communication
                    JoMe_264151

                    @Dana

                       

                    Couldn't we start with 24 UDB programmed ALUs connected to a DMA-machine life-calculating a trajectory to phobos using quaternions while the ARM M3 scans the TV-program for educational broadcasts ;-)

                       

                     

                       

                    Bob

                    • 7. Re: Interrupt based I2c communication

                      I succeeded to implement the I2c module using a queue as planned. The problem I encountered is when I try to use more than one I2c module at the same time (using UDB bloc implementation in creator), one of them will crash soon enough (related interrupts stop happening). Since I use interrupt, both mudole work in parallel. I can't find figure out what resource could be shared between different I2c module, although everything tend to show there is. Any idea?

                      • 8. Re: Interrupt based I2c communication
                        JoMe_264151

                        Two scenarios possible: Issue in I2C module or issue in programming. To check the later, upload your project and we will have a look at. To do so, use
                        Creator->File->Create Workspace Bundle (minimal)
                        and attach the resulting file.



                        Bob
                         

                        • 9. Re: Interrupt based I2c communication

                           Here it is!

                             

                          You may notice I programmed the majority of the code in C++ ...

                          • 10. Re: Interrupt based I2c communication
                            JoMe_264151

                            Yes, I did notice. Since the IDE does not (yet) support C++ there is no chance for helping you from my side. Maybe somebody else jumps in and checks your code.

                               

                             

                               

                            Bob

                            • 11. Re: Interrupt based I2c communication

                               Actually, It does support C++ with a stretch (not officially though), I even found an article on the subject!

                                 

                              http://www.mbedded.ninja/programming/microcontrollers/psoc/using-cplusplus-with-psoc-creator

                                 

                              (But that is out of the subject)

                                 

                              Thank you Bob for your time.

                                 

                              I am considering merging all I2c requests in a single queue so that no communication happens in parallel, but I won't know why it doesn't work in parralel...

                              • 12. Re: Interrupt based I2c communication
                                DaKn_263916

                                You appear to be working in an older version of Creator, 3.0 SP2 is

                                   

                                current version, and each new version fixes bugs, adds capability,

                                   

                                so recommended you update Creator.

                                   

                                 

                                   

                                I attempted build, you have quite a few simple warnings, errors you

                                   

                                should address.

                                   

                                 

                                   

                                Regards, Dana.