what types of codes are written in CMSIS files and peripheral drivers file. How can I distinguish them? any example would be more helpful. Thank you.
Overview. The CMSIS-Driver specification is a software API that describes peripheral driver interfaces for middleware stacks and user applications. The CMSIS-Driver API is designed to be generic and independent of a specific RTOS making it reusable across a wide range of supported microcontroller devices.
The Common Microcontroller Software Interface Standard (CMSIS) is a vendor-independent abstraction layer for microcontrollers that are based on Arm Cortex processors. CMSIS defines generic tool interfaces and enables consistent device support.
Introduction. This is the MSP430 Peripheral Driver Library. This peripheral driver library's intent is to allow application development at an API level instead at the device register level. Allowing developers to concentrate on their applications instead of the nuances of the particular MSP430 device they are using.
CMSIS-Pack is an effective packaging technology that currently supports close to 9,000 different microcontrollers. They provide a delivery mechanism for software components, device parameters, and evaluation board support. A Software Pack (file collection) includes: Source code, header files, and software libraries.
"CMSIS" is the Cortex Microcontroller Software Interface Standard. It's an ARM standard, so the code should be more or less portable between Cortex implementations.
Peripheral libraries generally are more vendor-specific, since there's no standard for how two different vendors will implement e.g. a timer or a UART block.
At least, that's my basic understanding from working (mostly) with ARMs in the STM32 family. However, I notice on that CMSIS page that the scope for CMSIS is actually larger:
CMSIS-Driver: defines generic peripheral driver interfaces for middleware making it reusable across supported devices. The API is RTOS independent and connects microcontroller peripherals with middleware that implements for example communication stacks, file systems, or graphic user interfaces.
That sounds like it'd do things that I associate with vendor-specific code, but perhaps not all vendors actually use CMSIS-Driver yet.
UPDATE: On the STM32:s I've worked with, GPIO is managed using only ST's peripheral library.
It's pretty easy, really:
RCC_AHB1PeriphClockCmd()
to enable the GPIO peripheral's clock. There are many clocks so make sure you do it right. I think all the GPIO is on AHB1.GPIO_InitTypeDef
by calling GPIO_StructInit()
on it to get the defaults.GPIO_InitTypeDef
, overriding the defaults as needed.GPIO_Init()
on the proper port, also passing it the GPIO_InitTypeDef
with your actual settings. This will poke registers in the peripheral.GPIO_SetBits()
, GPIO_ReadInputDataBit()
et cetera to actually use the GPIO pin.If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With