I2C implementation for STM32

[barthess]

Hi, Roberto.
There is no docs and examples of I2C code in the branch.
I planed to create them later, when hi level API will done.
For a moment I can provide test code of my project -
that implement connection with accelerometer LIS3LV02DQ.

I use ChibiOS (and I2C bus) as base of autopilot for UAV.
Base hardware is Olimex STM32F103-STK board with
DIY sensing modules.

[redfox74]

Hi,
Thank you very much for your example ... i need to do some configuration ind mcuconf.h or in other file for use this demo ? Or the branch is yet ready to work ...
Regards
Roberto

[barthess]

Yes, I have forgot about mcuconf.h. Add following lines:

Code: Select all

/*
 * I2C driver system settings.
 */
#define STM32_I2C_USE_I2C1                  TRUE
#define STM32_I2C_USE_I2C2                  FALSE
#define STM32_I2C_I2C1_IRQ_PRIORITY         11
#define STM32_I2C_I2C2_IRQ_PRIORITY         11
#define STM32_I2C_I2C1_DMA_PRIORITY         4
#define STM32_I2C_I2C2_DMA_PRIORITY         4
#define STM32_I2C_I2C1_DMA_ERROR_HOOK()     chSysHalt()
#define STM32_I2C_I2C2_DMA_ERROR_HOOK()     chSysHalt()

[barthess]

Hi, Friends.
Finally I have build all my I2C hardware and can test driver.
Hardware consist of LIS3LV02DL accelerometer on channel #1 and
MAX1236 ADC, TMP75 thermometer, 24LC512 EEPROM IC on channel #2.
Perfunctory tests revealed no serious problems.

You can propose changes to the API, but I have some requirements:
- It must be consistent with the other drivers as style and organization.

I'm not sure, but mostly is true.

- It is required to work asynchronously with callbacks much like the SPI driver does.

Done

- It could also offer an optional "wait" variant of the I/O functions like the SPI/ADC drivers do.

Not done. In my project I use separate sleeping thread and wake them up from callbacks.
May be wait thread is better. I can realize this feature in future.

- It must support 10 bits addressing even if implementations could not support it.

Done, but not tested.

- 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.

Done.

- 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.

Not done, because I can not test this mode.

- Of course it is supposed to abstract the device so it must not be STM32 specific

Done. Code split to STM32 specific part and device independent part.

In the nearest plans - write documentation in i2c.dox and create some examples.

Giovanni, what to do with my old synchronous code that do not use any interrupts?
Delete it or leave as alternative to asynchronous (some small fixes need)?

Code need much of criticism and testing by other users.

Regards.

[Giovanni]

Hi barthess,

Good job, tomorrow I will give a try to the code and post my comments. Today I have a cold that is killing me, I am not sure to be fully awake.

Don't worry about the slave part, we must just plan to be able to extend the driver with that functionality, it does not have to have it initially. Most users want I2C master anyway.

A working starting point is perfectly fine.

thanks,
Giovanni

[Giovanni]

Hi, is there any use example on the repository? I haven't found any.

Giovanni

[barthess]

There is no examples for a moment. I will add them at this evening.

[barthess]

Example code commited into testhal\STM32\I2C directory.

Also I have "state machine" written by hands on the sheet of paper.
Quoted because I don't know how to properly represent some
state changes.

It is not so good like your drawings, but I can take a photograph of
them and post it here. May it will be useful.
http://img850.imageshack.us/i/img5183.jpg/

[Giovanni]

I don't do those drawings , download and try graphviz, it is great.

Giovanni

[zyp]

I'm trying to use the code in the i2c_dev-branch for reading an ITG-3200 on a bus shared with BMA-150 and AK8975. However, it does not work; the system just locks up.
I'm performing the read in a similar manner to the lis3 example code, first writing one byte, then reading six bytes.

I scoped the bus to see what's going on, transmission of the register address is fine, repeat start is fine, then the six bytes of data, still looking good, then the end:

(Yellow is SCK, blue is SDA.)
The first cursor marks the ACK after the fifth byte, the second cursor marks the NACK after the sixth and last byte, and everything is fine until this point.
Then, instead of issuing a STOP, it continues to pulse the clock for another byte.