kiso icon indicating copy to clipboard operation
kiso copied to clipboard

Add STM32 I2C DMA support for large data transfer

Open HansUweRempler opened this issue 5 years ago • 2 comments

Issue by khalifima Friday Jun 21, 2019 at 16:31 GMT Originally opened as https://github.com/Bosch-AE-SW/cddk-oss/issues/106


I2C Write register sequence can be as the following: |start|slaveAddress+RWbit|SlaveAcknowledge|RegisterAddress|SlaveAcknowledge|registerData|stop| This scenario handles Register Address as the first element of the data buffer to be sent which is fine. Some I2C device Manufacturers (e.g. BST ) provide drivers that expect the user to provide functions to readRegister(slaveAddress, Register, data, length) writeRegister(SlaveAddress, register, data, length) which is BTW not standard I2C. This has the consequence that we should recompose the sending operation in order to prepend the register address and send it before the data to be written. In STM32 Library this is not easy because there is no way the library provides which allows you to select which start/termination for the data you are going to send.

in essentials we have the APIs MCU_I2C_ReadRegister() and MCU_I2C_WriteRegister() which have been implemented in STM32 for polling mode, for interrupt mode (with some active waiting for register address transmission), and not for DMA mode because no way to do it other than not using STM32Cube library and writing owns IRQ handlers.

HansUweRempler avatar Jan 17 '20 10:01 HansUweRempler

Comment by HansUweRempler Sunday Nov 17, 2019 at 09:37 GMT


@khalifima What's the status of this issue? I found it while filtering for issues that have not been assigned to our "Eclipse Kiso" project.

HansUweRempler avatar Jan 17 '20 10:01 HansUweRempler

Comment by HansUweRempler Wednesday Nov 20, 2019 at 08:28 GMT


@khalifima I removed your newly created label for now. I don't see a need for this additional type right now (maybe later). Also, I only see a single issue labeled with it. That one, or this one here, respectively, I would label as a missing feature, i.e., "Type: Feature". And, if we add such a new structure element it should be also inherited in the corresponding structure and orga documentation. For now, let's stick to the existing structure and sync in person about the need of additional elements.

HansUweRempler avatar Jan 17 '20 10:01 HansUweRempler