Question about CMSIS driver
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-08-24 08:42 AM
I've download the CMSIS pack for STM32H7 series. ST implement an I2C driver function like this:
int32_t I2C_MasterTransmit (uint32_t addr, const uint8_t *data, uint32_t num, bool xfer_pending, I2C_RESOURCES *i2c),
but the website,
https://arm-software.github.io/CMSIS_5/Driver/html/group__i2c__interface__gr.html, shows the API should be like this:
int32_t ARM_I2C_MasterTransmit (uint32_t addr, const uint8_t *data, uint32_t num, bool xfer_pending)
Why both the function name and parameters are different?
- Labels:
-
I2C
-
STM32Cube MCU Packages
-
STM32H7 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-08-24 11:50 AM
Seems like the ARM_I2C_MasterTransmit version has no provision for a chip with multiple I2C interface. The I2C_MasterTransmit looks like a rebranded HAL function.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-08-24 05:27 PM
Not just I2C driver, I also check CAN driver, and it is also different.
What I learn is that ARM define the API and IC suppliers implement the API, so they should match each other. Does someone know why they are different?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-08-24 08:08 PM
Because the ARM definition seems a bit naive and isn't handling multiple instances of peripherals in a way C can handle cleanly/efficiently.
Would have been better done in C++ classes.
Don't expect the CMSIS implementation of this to gain much traction here.
Perhaps you can explain to me how this would work? How would the function know what instance I'm using?
drv_info = &Driver_I2C0;
drv_info->MasterTransmit(..);
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-08-24 11:58 PM
@Community member
Thanks for your reply. I understand what you mean. but I have two more questions.
1) Why ARM keeps naive with latest version of CMSIS? No IC suppliers tell ARM this is wrong?
2) IC suppliers is based on which API (or what document) to implement their driver for CMSIS? I checked CMSIS I2C drivers implemented by NXP and ST, The function name and parameters look the same. If ARM definition can not be followed, why IC suppliers can implement the same API (but different from ARM definition)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-08-25 03:41 AM
Asked this on the ARM forum. Lets' see if anybody actually uses this thing...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-08-25 07:52 AM
Most suppliers have already have significant traction with their own hardware abstraction libraries, honestly this is so late to the game that people have already got better solutions, and most people working in this space across multiple platforms already understand how to abstract and port code.
I suspect ST threw this at an intern and told them to try and make this mess work.. and they did.
Sorry, I don't really care what they do.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-08-28 02:21 PM
static int32_t I2C4_MasterTransmit (uint32_t addr, const uint8_t *data, uint32_t num, bool xfer_pending) {
return I2C_MasterTransmit(addr, data, num, xfer_pending, &I2C4_Resources);
}
/* I2C4 Driver Control Block */
ARM_DRIVER_I2C Driver_I2C4 = {
// ...
I2C4_MasterTransmit,
// ...
};
They have a separate wrapper function for each peripheral instance. The wrapper function has an instance number in the name and the callable function has an additional peripheral specific parameter at the end. Crazy!
But I have to say that, while those drivers still use the broken HAL, they seem to be written with at least some actual competence. There can be seen even workarounds for HAL bugs and stupidities. Even the Ethernet on H7 is kind of functional there... The HAL/CubeMX team is not capable of that! So it could be that they are written by some other team.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-08-29 06:20 AM
> They have a separate wrapper function for each peripheral instance.
Aha. This explains it. Then all questions on the design go to Keil (ARM).
It isn't crazy, actually may make sense for rapid integrations with 3rd party drivers.
Just a matter of taste. Like salty-spicy chocolate or Indian candies ;)