Question about CMSIS driver

[JLee.32]

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?

[TDK]

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.

[JLee.32]

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?

[Tesla DeLorean]

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(..);

[JLee.32]

@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)?

[Pavel A.]

Asked this on the ARM forum. Lets' see if anybody actually uses this thing...

[Tesla DeLorean]

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.

[Piranha]

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.

[Pavel A.]

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