I2C implementation for STM32

[drgnz]

Hi all.
drgnz
1 - there is no 8bit API. 7bit notation used because datasheets contain it much often than 8bit. You can write simple wrapper if need 8bit.
2 - I am not understand your desire. Can you explain it in detail? Provide example?

Regards.

1 - I don't mind. I was wondering about the convention which seems to be 7 bit.
2 - I was asking. It seems that the there are ACK options in the I2CConfig but they are ignored in the code. (Never used)

[barthess]

2 - I was asking. It seems that the there are ACK options in the I2CConfig but they are ignored in the code. (Never used)

This is rudiment of the slave part of the driver.

[Giovanni]

I think we could remove any provision for a slave mode.

Giovanni

[barthess]

Fixed in rev.3454
API broken. To migrate you must remove 6th field from I2CConfig init code.

[Badger]

It turns out the chip + packaging only weighs 16g, so it cost less than £1 in total to send airmail! hopefully it will arrive some time next week

[barthess]

Thanks. I will notify you when receive it.

[stewo]

[Sorry if I jump in here late. I have not read the past 20 pages of this thread, so maybe the following has been discussed already.]

Recently I tried to use the new I2C support with an STM32 in the "2.3.3 unstable" version. Apparently something is wrong in either the communication between the I2C partners or some hardware problem as the I2C_SR2_BUSY bit does not go away on me.

But that is not actually the important part here.

What bothers me is that as a result, i2c_lld_master_transmit() hangs completely. Since it is called with interrupts disabled, i.e. from within chSysLockFromIsr() context, the whole system hangs up!

The reason for the hangup is the following interrupt-related code:

Code: Select all

void i2c_lld_master_transmit(...) {
...
  i2cp->id_i2c->CR1 |= I2C_CR1_START;
  while (!(i2cp->id_i2c->SR1 & I2C_SR1_SB))
    ;
  i2cp->id_i2c->DR = i2cp->slave_addr1;
  while (!(i2cp->id_i2c->SR1 & I2C_SR1_ADDR))
    ;
  while (!(i2cp->id_i2c->SR2 & I2C_SR2_BUSY))
    ;
...

This code does not seem to have the same quality as all the other ChibiOS kernel code I have seen so far. Relying (i.e. "active waiting") on any external event to happen within interrupt-related context can (and will) break the robustness of the whole system.

Just my 2 cents.

Stephan

[barthess]

The reason for the hangup is the following interrupt-related code:

Code: Select all
void i2c_lld_master_transmit(...) {
...
i2cp->id_i2c->CR1 |= I2C_CR1_START;
while (!(i2cp->id_i2c->SR1 & I2C_SR1_SB))
;
i2cp->id_i2c->DR = i2cp->slave_addr1;
while (!(i2cp->id_i2c->SR1 & I2C_SR1_ADDR))
;
while (!(i2cp->id_i2c->SR2 & I2C_SR2_BUSY))
;
...


This code does not seem to have the same quality as all the other ChibiOS kernel code I have seen so far. Relying (i.e. "active waiting") on any external event to happen within interrupt-related context can (and will) break the robustness of the whole system.

That code relay on synchronous driver model with active waitings. Synchronous mode currently does not work. Set I2C_SUPPORTS_CALLBACKS to TRUE in your halconf.h to use interrupt based driver. Also, add

Code: Select all

#define STM32_I2C_I2C1_USE_GPT_TIM          GPTD1
#define STM32_I2C_I2C1_USE_POLLING_WAIT     FALSE
#define STM32_I2C_I2C2_USE_GPT_TIM          GPTD2
#define STM32_I2C_I2C2_USE_POLLING_WAIT     FALSE

to your mcuconf.h to completely disable waiting. Replace GPTDx with your unused timers.

[drgnz]

BTW I got I2C working beautifully. Thanks a lot. If I want the latest greatest update, where should I get it from? 2.3.3?

[Giovanni]

Hi,

The latest code is always on the repository, latest released version (including I2C) is 2.3.3.

Giovanni