I2C implementation for STM32

[Giovanni]

Those wait loops into an interrupt handler are really bad, we should try hard to avoid that. Even if the handler has the lowest priority the flyback time of any tread in the system would suffer. I think the loop would last one bit time, even at maximum speed we are talking of many microseconds.

The I2C cell in the STM32 does not seem to have a interrupt associated for that, what other options we have? I can think to someworkarounds:
1 - No not wait at the end of an operation but check for STOP when starting the next one.
2 - Use EXTI in order to wait the rising edge on SDA.
3 - Use a timer to get a delayed interrupt.

All are tricky.

Giovanni

[Giovanni]

Of course there would also be the solution of moving away from a callback based driver to a synchronous API, but that would mean surrender the driver design because a specific STM32 limitation, not acceptable IMO.

Giovanni

[barthess]

Hm... there is 19 uS in worst case.

1 - No not wait at the end of an operation but check for STOP when starting the next one.

Looks most acceptable for my opinion. Low level function starting transfer calls from user space. We can use slipping in it, right? Does it make sense to insert such a short sleeps, or better to use while() waiting not in ISR?

[Giovanni]

19uS is totally unacceptable.

I would remove the wait in the ISR and would add a check at the beginning of each "start" type function. If the STOP flag is still set then we have 2 options:

1) Wait there using a loop (not that good as solution, you can start an operation from a callback so still in an ISR).
2) Use a timer to insert a delay with a callback, if could use both an HW timer directly or refer an external instance of a GPT driver referred in configuration (complex to implement).

Giovanni

[Badger]

According to this page it is necessary to have the i2c interrupts at the highest priority; is this possible within chibios?

In particular, the correct generation of the stop bit relies on the I2C IRQ running immediately and not being held off for any reason.

[Giovanni]

Yes, it is possible but this makes the problem even worse.

[barthess]

The I2C interrupts should have the highest priority in the application in order to make them uninterruptible.

but now in driver realized

Method 2: This method is for the case when the I2C is used with interrupts that do not have
the highest priority in the application or when the I2C is used with polling.

I decide to further develop method 2 with intensive stress testing.

[barthess]

About timers.
Using a dedicated hardware timer is wasting of peripherals. On the other hand, virtual timer gives only (1/CH_FREQUENCY) seconds resolution and depends on project settings, and default value 1000 seams too much. I will realize both variants with ability to switch between they by setting flag in halconf.h.

[Giovanni]

I agree that VTs are not sufficient, you may consider using a GPT driver initialized externally and referenced by the I2C configuration. This way the timer can be reused when the I2C is not required.

Anyway the main problem here is that the STM32 I2C cell is "problematic" because its timing constraints and various problems. We may consider switching to a synchronous driver model (no callbacks at all) and just insert the wait loops where required. Less elegant for sure but much less troublesome implementation.

If we decide to go for a synchronous driver then we could also consider implementing a soft I2C driver bit-banging the protocol on a couple of PAL pins and using GPT delays for timings, this soft driver would have the advantage to be immediately available on all platforms already supporting PAL and GPT.

Note, not a decision, it is a proposal.

Giovanni

[matis]

First of all, great work on the I2C development.

Currently I'm developing ChiibiOS for a STM32F103VET6 (100 pins, 512 Kbytes). The original code was developed with ChibiOS 2.2.1. Everything worked, but now we want I2C support within ChibiOS. Therefore a unstable version is required.
When we switch from 2.2.1 to another version, we need to put effort in rewriting some bits and pieces, that's no problem.
I want to make a deliberately choice so that, when a stable version with I2C support is released, the switch from the unstable to a stable version comes with the least amount of work.
I2C support is not needed at the moment, but will be in the near future.

So which unstable branch/version do you guys suggest in my case?

Thanks in advance,

Matis