CMSIS-Driver peripherals

1
votes

I was wandering, why there are no implementations of the devices written in CMSIS-Driver?

I mean that I have few peripherals: LCD, temperature and pressure sensor, current meter etc. - all of them very popular used in arduino and learning sets. Each of these devices uses some protocol to communicate with the uC. some are for i2C, some communicate by SPI, some by UART. I was wondering if there are drivers that handle those devices, and as a backend use CMSIS-Driver API.

I think that it is a decent api, and after all standard develop by ARM, so why I can not find any drivers using it?

For example when I was looking for s18b20 (temperature sensor for 1-wire), I was easily able to find driver for this device written in RUST language, but I was not able to find any implementation for C that would use CMSIS. (in this case compare to rust is quite solid, because Rust has nice embedded API, and you can easily use the driver on multiple targets, just like CMSIS-Driver is spouse to work) I was able to find some projects using this peripheral, but they all operated on HAL that is different for every uC, so the implementation is not portable ( unlike RUST, and potentially CMSIS-Driver)

So my main questions are:

Why there are so little implementations based on CMSIS-Driver? Maybe there is some hidden implementation repository that I do not know about?

Am I missing something? Is the CMSIS-Driver not designed for the casual developers? Who is it designed for then ?

1
carmembeddedcmsis
arduino is one thing cmsis is another, arms attempt to deal with the issue of their cores being used in different chips with different IP. a few seconds of googling CMSIS-driver appears to be just that, for the gpio, and other items on these chips. if you want to talk to something off chip then you have the tools you need to write that code. - old_timer
some arm based mcus have arduino support and others have mbed support which is also an arm thing and closer to what you are asking for. - old_timer
understand that arm doesnt make chips it makes IP. these are not arm chips they are arm based chips, the bulk of the chip is made up of IP from someone else and varies widely from other chips based on the same cores, thus the problem for software developers that are used to say a pic or msp430 or something avr based or writing code that runs on an operating system. the illusion that because it has the same processor then the code should be portable when that makes no sense at all. - old_timer
Well, CMSIS-Driver is just a standard interface. It means, that every platform has to have its own implementation. This is made to guarantee uniform API. This means that I can write a piece of software that will handle some sensor using this standard API (by handling I mean, that the uC need to send specified set of commands to init the device, and another command to read/write interesting data) By implementing the driver using this standard communication api, I can use it on every platform that have implementation for the CMSIS-Driver interface. - Robert Gałat
In my opinion it is great feature, that someone could write a piece of code that would fully handle some peripheral on one simple condition - you would have to have implementation for CMSIS-Driver (if it is not officially provided, you could make it on your own). But currently I do not see anything like that. Everyone writes the implementation using HAL - why ? Why would anyone want to rewrite the same code, that someone else could have written (possibly better) - Robert Gałat

1 Answers

2
votes

CMSIS is not concerned with external devices, it deals primarily with interface drivers for interfaces on the microcontroller die. So if you have an SPI device, you might use the CMSIS. SPI driver for that part, but it is then your responsibility as a developer to write the higher-level driver for the external device.

Higher-level software platforms such as ARM's embed, or ST's CubeMX use CMSIS interface drivers, and include drivers for common higher level devices. They tend to be for more complex devices related to networking, filesystems and displays. I would not expect much support for such trivially simple devices such as a temperature sensor.