I2C implementation for STM32

[barthess]

I need I2C support in my project but can not find any low level drivers, only some templates. Does somebody work in this direction? If yes, than I will join to developer(s). If no, then I will realize (...at least try) driver myself and send patches.

[Giovanni]

Hi,

There are no implementations yet and even the template is not complete, the slave I2C part is missing from the API, I was not sure about the best way to abstract it.

You may also read the following threads in the old forum, there is an I2C implementation for STM32 that does not use the template:
https://sourceforge.net/projects/chibio ... ic/3904825
https://sourceforge.net/projects/chibio ... ic/3763912

My idea is to release 2.2.x without I2C and then complete it in the next development branch. Of course any help would be appreciated.

Giovanni

[barthess]

Thanks for useful links.

I still have some questions after looking in sources and documentation. Why some drivers have I-suffixed functions (for example UART) and some drivers (SPI) have not?

[Giovanni]

The SPI driver does have I-class APIs in 2.1.x but implemented as macros for efficiency, some drivers do not have them (MAC, CAN, Serial) and some others have only the I-APIs (UART).

It depends mainly on how the driver is meant to be used; synchronously, asynchronously or a mix of the two. The SPI driver is one of those offering both modes.

It is possible that the asynchronous APIs will be added to the CAN and MAC drivers too. All new driver models (USB, I2C etc) will have it. The HAL is moving to an asynchronous model with a synchronous APIs built on top. This has the advantage to not require necessarily threads for I/O tasks and to save space if the synchronous API is not required.

Giovanni

[barthess]

Hi, Giovanni

Finally I was able to write draft of lowlevel part. There is no DMA, no interrupt and error handling, no documentation, lots of hardcoding in it, but it can write and read data. I plan to polish it further.

I can submit patch here, but better for me is to have separate branch in your svn repo. Is it possible?

[Giovanni]

Hi,

I added you as developer, now you should have write access to the repository, I suggest you create an i2c_dev branch and work there.

About the I2C driver, IRQ support is pretty much mandatory because callbacks, DMA support would be nice too on platforms that support it. Please keep in mind that the I2C generic driver is not finalized so the API will probably change during 2.3.x. My idea is to make a generic API supporting both master and slave modes.

Giovanni

[Giovanni]

Created a branch here: https://chibios.svn.sourceforge.net/svn ... es/i2c_dev

Giovanni

[barthess]

Thanks for help.

IRQ support is pretty much mandatory because callbacks, DMA support would be nice too

IRQ and DMA support first in my plans.

Please keep in mind that the I2C generic driver is not finalized so the API will probably change during 2.3.x.

Does this mean that I am free to create API from scratch? My idea is to create driver structures for slave devices too, not only for I2C interface.

My idea is to make a generic API supporting both master and slave modes.

This is good idea, but my board have only 1 master (stm32 MCU) and I can not test slave mode. May be in future I'll make second board for tests, but can not guarantee this.

[Giovanni]

You can propose changes to the API, but I have some requirements:
- It must be consistent with the other drivers as style and organization.
- It is required to work asynchronously with callbacks much like the SPI driver does.
- It could also offer an optional "wait" variant of the I/O functions like the SPI/ADC drivers do.
- It must support 10 bits addressing even if implementations could not support it.
- It must be "low level" and not targeted to a specific class of I2C devices, device protocols will be built on top of the low level I2C driver. As example I2C EEPROM drivers, I/O expanders drivers, RTC drivers and so on.
- The driver should be able to support a slave mode even if specific implementations could be master-only. I2C supports devices that are both masters and slaves.
- Of course it is supposed to abstract the device so it must not be STM32 specific.

I delayed the work on this driver and not pushing it because I am not sure how to put all the above requirements together in a portable driver model. It is more complicated than it looks, any suggestion is really welcome, it is more matter of design than implementation.

Giovanni

[barthess]

Hi, Giovanni.

Whats done:
- Only low level calls.
- Hi level driver will be "low level" by design. Slave device drivers (for now named configs) contain only data buffers, slave address, callback pointer, and some flags.
- Driver runs asynchronously with callbacks. For now transmitting works fine, but receiving cause strange infinite interrupt calls (I'm working on it).
- User may (and must) realize device specific actions (stop, restart, etc.) in callback function.
Other requirements I will try to realize too.

I need some explanations. Whether there is an API mechanism in ChibyOS that allow to share one DMA channel between two or more devices? May be any guidelines?