I2C timeout for STM32F103C8

Post here all questions related to LibMaple core if you can't find a relevant section!
Blosso
Posts: 8
Joined: Mon Feb 15, 2021 4:11 pm

Re: I2C timeout for STM32F103C8

Post by Blosso »

The idea is that every 20ms, the loop will repeat itself, if processing time is much longer than this, it could just repeat right away without any delay.
Yes, I have modified the code accordingly, to print the string as above, it takes 0ms processing time. However, it still freezes after awhile. This happens when I just connect a blue pill with HC05. Did you come across this before?
stevestrong
Posts: 502
Joined: Fri Dec 27, 2019 4:53 pm
Answers: 8
Location: Munich, Germany
Contact:

Re: I2C timeout for STM32F103C8

Post by stevestrong »

I ran the sketch on a bluepill board and I got 1 ms processing time.
This is only possible because the serial transmission is actually non-blocking.

The user should check before sending the data that there is enough space in the Tx buffer, otherwise Tx data overflow will occure.

If you insert this to your code after sending a data train before measuring the processing time

Code: Select all

while ( Serial3.availableForWrite() < (USART_TX_BUF_SIZE-1) ); // wait for buffer empty
you will realize that the processing time will change.
Blosso
Posts: 8
Joined: Mon Feb 15, 2021 4:11 pm

Re: I2C timeout for STM32F103C8

Post by Blosso »

Sure I will try that out. To my guessing, I feel that the processing time might not be an issue. Every time I run the code, i flush the serial right at the beginning, to make sure all data has been sent through, while the string size is smaller than the set buffer size 256. Would this avoid the overflow?
stevestrong
Posts: 502
Joined: Fri Dec 27, 2019 4:53 pm
Answers: 8
Location: Munich, Germany
Contact:

Re: I2C timeout for STM32F103C8

Post by stevestrong »

To guarantee that the amount of data is less than the buffer size is not enough. You also have to make sure that the buffer will be emptied within a specified time.
Basically, if the value indicated by available for write is (<buffer size>-1) then theoretically no overflow should occur.
In this case flushing is not needed.

Code: Select all

void loop()
{
  if ( (millis()-lastTime) < printDelay )
    return;
  lastTime = millis();

  Serial.print("************\nAvailable for write: "); Serial.println(Serial3.availableForWrite());
  //Serial3.flush();
  ...
  Serial.print("Processing time: "); Serial.println(millis()-lastTime);
}
If you need to flush to empty the buffer, it is a sign that you will not reach the wanted throughput.

This effect is visible if you reduce the Baudrate to 57600, the processing time will increase to 21ms, which means that it is impossible to send all data within 20 ms, even if all data fits into the buffer.

This is my output (disabled flush):

Code: Select all

************
Available for write: 63
Processing time: 10
************
Available for write: 55
Processing time: 11
************
Available for write: 49
Processing time: 12
************
Available for write: 43
Processing time: 13
************
Available for write: 38
Processing time: 14
************
Available for write: 32
Processing time: 15
************
Available for write: 26
Processing time: 16
************
Available for write: 20
Processing time: 17
************
Available for write: 14
Processing time: 18
************
Available for write: 9
Processing time: 19
************
Available for write: 3
Processing time: 20
************
Available for write: 0
Processing time: 21
************
Available for write: 0
Processing time: 21
************
...
You can see how slowly the buffer cannot keep a stable level, because the data comes faster than it can be sent.
This happens even if you set the buffer size to a larger value, juts that it takes a bit more time at the beginning till available for write becomes 0.
However, it still freezes after awhile. This happens when I just connect a blue pill with HC05. Did you come across this before?
I have seen no hangup during my experiments using the test sketch, not even if at low Baudrates. I have nothing connected to the board, but that should make no difference since there is no serial input. Unless the HC05 pulls the serial pin low (to indicates something?).
How do you detect the freeze? You better insert some code to blink the LED.

EDIT
I was previously wrong, the serial transmission is actually blocking! This is why the processing time increases from each loop iteration to the next, because it needs to wait more and more time till the buffer has some free space where to write the data.
At steady state (available = 0) the software actually waits for each byte to be pushed to the buffer. In this case the processing time is the time needed to send the data from the buffer.
Post Reply

Return to “General discussion”