This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

i2c: mange the protocol in the sw work cycle.

Other Parts Discussed in Thread: MSP430F5438A, ADS1115

Hi,

 

I work with the msp430f5438A.

And I ( the cpu is the master)  communicate by I2c protocol to read from external ADC ( ads1115 component as a slave) .

And the sw is run in infinite loop. Each loop is of 100usec period (which will call from now "work cycle").

I have some option to manage the I2c protocol (single master two slaves).

  1. by polling.( take too much time to wait to the rising tx or rx flag, Beyond time that the work cycle allow )
  2. by interrupt. (Interrupt on each on byte transmision)

 

I implement both of them and it work fine.

In order to keep the CPU load as low as possible. I am considering a third option.

To send each one of the cycle work only one byte through the i2c

 

e.g:

the 1st work cycle : send the start bit , with address , with R/W.

2nd work cycle: send the first data ( in case that the master write data)

3rd work cycle : send the second data

last : stop the transaction .

 

but it not work.

And I suspect that the protocol time constraints or the device time constraint are the source of the problem.

So my question:

  1. if someone work in this method (send one byte in each of the work cycle ), is it possible?

 

Thanks.

Asher.

  • Asher,

    So the MSP430 is operating in I2C slave mode? Does the CPU master hold the clock line (SCL) low between these work cycles? If not the MSP430 may need to hold the SCL low to avoid timing confusion. If you have a logic analyzer on hand this would be a good way to visualize the I2C lines to see where communication is being hindered.

    Regards,
    Ryan
  • Hello,

    Sorry for the misunderstanding
    the msp430 ( is the cpu)  is the master ,
    and the ADS ( external ADC device) is the slave.
    there are one master and 2 slaves ( ADS devices).

    1. I take your advise , and observe the line with scope.

    2. I also understand, that by the I2C protocol
    Nothing prevented holding the line as necessary.
    In other words, it is possible to send each cycle of the SW
    only one word and it is not conditional for cycle time (period).

    Thanks.
    Asher.

  • Asher,

    Thank you for the setup clarification. It should be possible to send one byte per work cycle, once again I would consult an o-scope or logic analyzer to see what could be causing the communication confusion.

    Regards,
    Ryan
  • Ryan,

    The following scenario, in case I want to transmit a series of character.
    1st transaction : I set the start condition, R/w. ט the cpu send the address, R/W and wait for ack.
    2nd transaction: I send each Sw work cycle one character.
    ..
    N last transaction: send the stop bit.

    My question, how do I make the last transaction, in practical terms?
    1. If I set the stop bit in the N-i transaction ( one or more byte before the last ) ,then the N-i byte will not transmit ( in the user guide , slau208o.pdf, 38.3.4.2.1 , write “Data is transmitted or the bus is held, as long as the UCTXSTP bit or UCTXSTT bit is not set. “).
    2. If I set the stop bit during the N transaction ( is the last transaction) , I need to used polling, and that Delaying the program cycle and increases the CPU load, and I want to minimize CPU load.

    So , How I build program that in each work cycle make one action , like to assign the data in the TxBuffer, and without polling ?

    Asher.
  • Asher,

    I apologize for the confusion but I do not see the problem in setting the UCTXSTP bit during the N work cycle which should not require polling. What are you polling for after setting the UCTXSTP bit? To confirm that the UCTXSTP bit is sent before going back to LPM? Considering that there should be several characters sent between the start and stop conditions I do not see the last transaction as loading the CPU for very long.

    Regards,
    Ryan
  • Ryan,

    I understand that the correct way to transmit the last byte ( and is should work) is by the following procedure:

    1. UCBxTXBUF = data. //( the last data)
    2. UCBxCTL1 = UCTXSTP; //( set the stop bit)
    3. while (UCBxCTL1 & UCTXSTP) ; // this is optional, to wait here until the stop bit is transmitted but in case that I have about 100usec ( the cycle work time ) between each access to the I2C. then the third step is unnecessary

     

    Is it correct?

    Asher.

     

     

  • asher bara said:
    while (UCBxCTL1 & UCTXSTP) ; // this is optional, to wait here until the stop bit is transmitted but in case that I have about 100usec ( the cycle work time ) between each access to the I2C. then the third step is unnecessary

    And what happens when the Slave is Stretching the clock and delay the Acknowledge?

  • The third step is a check to make sure that UCTXSTP has been sent but in the interest of time you can skip this step and trust that the stop bit is sent. This should only be done if the UCBx module is still operable in the LPM mode with which you are entering, otherwise the bit might not be sent after all.

    Regards,
    Ryan
  • Leo Bosch said:

    And what happens when the Slave is Stretching the clock and delay the Acknowledge?

    i can check in the next cycle work if the stop bit transmitted.

    Then decide what I do and how I continue

**Attention** This is a public forum