Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001268
--- Comment #5 from Mike Jones <[email protected]> ---
Created attachment 2151
--> http://bugs.ecos.sourceware.org/attachment.cgi?id=2151&action=edit
Update STM32 I2C Support
I tried to contact Martin to see if he had updated code he was willing to
contribute, etc, but so far no reply. I am posting a patch. The patch contains:
- Updated init function and base defines so that the I2C support works on a
STM3240G-EVAL and should work for other STM32F4XX devices.
- Attempted to preserve STM32F1XX support but have no means to test
- Added support for SMBus timeout
- Fixed fast mode clock calculation
- Tested with PMBus/SMBus application consisting of three devices
- Tested with polling and interrupt driven modes
- Added loopback test for others to use
Some areas that may warrant change.
- The alternate pin assignments are set to the other two pins, but this is not
flexible in that it will not adapt to a custom design. It could be improved to
enter arbitrary pins in the CDL.
- The second I2C is not set to any particular pins of importance and could use
the same flexibility.
- The ACK portion of the I2C API is not active in the code. This prevents
lockups. If there is ever a reason to allow control it could be added, but it
needs some thought as to how to prevent lockup.
- The clock speed is ignored if changed in the instantiation of the i2c struct.
A code override may be added in the future if desired.
There is an inconsistency with the Kinetis driver. Kinetis I2C takes a period
in the CDL. I think this should be changed to frequency and will change it when
other work by Ilija completes.
On the eval board this code was reliable in with a real application. Overtime
it will get more use and I will fix anything I find. I would not hesitate to
use the patch if you need I2C on this platform. However, if anyone has a board
with STM32F1XX it would help to test this patch to ensure that version still
works. The difference between F1 and F4 is in the GPIO configuration registers.
I made almost no changes to the core code, so if it does not work, it is almost
certain to be in the init code.
I believe Martin has an assignment. I have one. So we should be able to get
this into the codebase.
--
You are receiving this mail because:
You are on the CC list for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.