Skip to content

Replace wait_us() calls in ST I2C HAL driver with RTOS-less/pure-C waits #6069

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Replace wait_us() calls in ST I2C HAL driver with RTOS-less/pure-C waits #6069

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions targets/TARGET_STM/i2c_api.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,7 @@
#include "mbed_assert.h"
#include "i2c_api.h"
#include "platform/mbed_wait_api.h"
#include "hal/us_ticker_api.h"

#if DEVICE_I2C

Expand Down Expand Up @@ -754,7 +755,8 @@ int i2c_read(i2c_t *obj, int address, char *data, int length, int stop) {
timeout = BYTE_TIMEOUT_US * (length + 1);
/* transfer started : wait completion or timeout */
while(!(obj_s->event & I2C_EVENT_ALL) && (--timeout != 0)) {
wait_us(1);
int start = us_ticker_read();
while ((us_ticker_read() - start) < 1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few questions about this lines

  • us_ticker_read returns uint32_t - why using start as an int ?
  • what would be the resulting type of (us_ticker_read() - start) and how to make sure that wrap-around case is well covered ? rather than < 1,maybe != 0 would be safer
  • In any case, with current proposal, the start will happen any time between T0 and T0+1, so when ((us_ticker_read() - start) < 1) is true, we have not reached a 1µs time, but rather any time between 0 and 1µs, in random way, so that the result will probably be around 0,5µs in average. The actual measured timeout will be half the expected one. Most probably OK as we take margins in the timeout computation, nevertheless not what we expect to code.

Copy link
Contributor Author

@RobMeades RobMeades Feb 13, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to use uint32_t instead of int, was just being lazy, though actually if they were both signed then at least the wrap-around case would return immediately rather than get stuck. But rather than dwelling here I'll comment on your other remark below.

}

i2c_ev_err_disable(obj);
Expand Down Expand Up @@ -805,7 +807,8 @@ int i2c_write(i2c_t *obj, int address, const char *data, int length, int stop) {
timeout = BYTE_TIMEOUT_US * (length + 1);
/* transfer started : wait completion or timeout */
while(!(obj_s->event & I2C_EVENT_ALL) && (--timeout != 0)) {
wait_us(1);
int start = us_ticker_read();
while ((us_ticker_read() - start) < 1);
}

i2c_ev_err_disable(obj);
Expand Down Expand Up @@ -986,7 +989,8 @@ int i2c_slave_read(i2c_t *obj, char *data, int length) {
if(ret == HAL_OK) {
timeout = BYTE_TIMEOUT_US * (length + 1);
while(obj_s->pending_slave_rx_maxter_tx && (--timeout != 0)) {
wait_us(1);
int start = us_ticker_read();
while ((us_ticker_read() - start) < 1);
}

if(timeout != 0) {
Expand All @@ -1011,7 +1015,8 @@ int i2c_slave_write(i2c_t *obj, const char *data, int length) {
if(ret == HAL_OK) {
timeout = BYTE_TIMEOUT_US * (length + 1);
while(obj_s->pending_slave_tx_master_rx && (--timeout != 0)) {
wait_us(1);
int start = us_ticker_read();
while ((us_ticker_read() - start) < 1);
}

if(timeout != 0) {
Expand Down