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.

BQ76952: Long wait problem between SPI communication data frames of BQ76952

Part Number: BQ76952

Tool/software:

Hello, I have encountered some problems that are not clearly explained in the manual when using bq76952. I need your help

As shown in the picture,When using SPI communication, for example, to obtain the cell voltage data  with address 0x14 from bq76952, I need to send (the register address (0x14)+data+CRC) twice, and obtain the voltage data of 0x14 on the second attempt.There is a problem that after the host sends the register address (0x14)+data+CRC once, it must wait for a certain time (500us) before sending the second time, otherwise it may encounter bq76952 returning 0xFF. One byte requires waiting for 500us, and there is a lot of data to be obtained from bq76952, which can cause significant blocking.

I understand that RTOS can avoid this problem.but I am using a bare computer device and cannot handle anything else while waiting. My following question is also based on using bare computer

Therefore, I have the following questions that I need your answers to. Thank you very much

1. If using IIC communication, does it also require a long wait to obtain data? In other words, can switching to IIC communication solve this problem?

2. Do you have any recommended solutions to solve this problem

3. To solve this problem, I have come up with a solution. May I ask if this approach is already the best solution?

As shown in the figure, I use a timer to trigger an interrupt, and then enable DMA in the interrupt. Each DMA will complete a data transmission(register address (0x14)+data+CRC)

In this method, communication with bq76952 is completed by a timer and DMA, avoiding useless CPU waiting

Looking forward to your reply

  • Hi,

    Today and tomorrow (Nov. 28-29) are U.S. holidays. The team will be back in office on Monday, and will get back to you then.

    Thank you for your patience.

    Regards,

    Max Verboncoeur

  • Hello User,

    Thank you for your patience.

    I2C on our part is faster than SPI even if the frequency is slower. There are fewer transactions required and I2C supports block reads/writes, so I2C may work better for you. 

    Your solution could work; however, we have not seen anyone try that yet.

    Best Regards,
    Alexis

  • As shown in the figure, the fundamental reason for blocking caused by SPI communication is the necessary waiting between each frame. Is there still such waiting when switching to IIC. For example, when block reads/writes, does it also need to wait between the returned data bytes

  • Hello,

    We have received your request and will work to answer it as soon as possible. 

    Our normal support team is OOO and will be returning 12/10 to help with any ongoing inquiry. 

    We appreciate your patience and understanding.

    Best, 

    -Luis Torres

  • Hello User,

    Thank you for your patience.

    I2C will have the same if not similar wait between each frame, however, I2C you can do more with 1 frame (up to 32 bytes) compared to SPI.

    Best Regards,
    Alexis