A strength of Cortex-M based MCUs is that the core CPU is designed by ARM Inc., while silicon vendors license the core design and then put their own I/O peripherals around it. With all major MCU vendors supporting the Cortex MCU, embedded designers have a large number of MCUs to choose from, while able to reuse their existing knowledge of the CPU information.
To make the software a bit more manageable, ARM has published the CMSIS (Cortex Microcontroller Software Interface Standard). CMSIS addresses the issues of portable macro defines and intrinsic functions common to the Cortex-M CPU cores. As each MCU has its own set of I/O peripherals, silicon vendors provide header files and sometimes C source files which let a user access the peripheral I/O registers and functions.
Unfortunately, there is no standard on how a vendor may name the defines or functions, and no standard directory structure for these files. Acquiring the correct files from the vendors’ sites can be an exercise in frustration. Moreover, some vendors(e.g.: ST in particular) have multiple releases of the support libraries. This situation makes it difficult for an engineer who is new to Cortex-M development to get started, and was part of the impetus for ImageCraft to design JumpStart API. However, JSAPI cannot not solve all possible problems, and there are still many reasons to access the peripherals directly.
To this end, JumpStart C++for Cortex also installs peripheral header and source files for the most popular MCUs. We have standardized the directories as follow:
- <install root>\VendorSDK\<vendor>\<device series>\inc for header files
- <install root>\VendorSDK\<vendor>\<device series>\src for source files
- <install root>\VendorSDK\<vendor>\<device series>\CMSIS\inc for CMSIS header files.
- <install root>\VendorSDK\<vendor>\<device series>\CMSIS\src for CMSIS source files.
The reason a separate CMSIS subdirectory exists is that some vendors (perhaps taking advice from ARM),separate out certain CMSIS-like information, e.g. the interrupt number macro defines (TIM1_IRQn, USART2_IRQn, etc.), the peripheral base addresses, etc.into files usually with the names <device series>.h and <device>.h,e.g. stm32f7xx.h and stm32f746xx.h. However, the use of the CMSIS subdirectory is not mandated or standardized, and some vendors just ignore differentiation between CMSIS-like information and device peripheral information, and provide only one flat directory.
The consistency of where ImageCraft locates these files makes it easier for a user to start working with the supported Cortex MCUs (see below). This seems to be an obvious organizational strategy for a tool vendor, but most tool vendors just use the files and file structures from the silicon vendors, and sometimes they can be incredibly inconsistent. For example, another tool vendor keeps the file structures from NXP, and these are some of their file directories:
Why the inconsistent naming scheme with the intermediate directories? This is unclear, and certainly has no benefit to the user. Moreover, these intermediate directories most often serve no function whatsoever. To wit, they also have:
Again, it is unclear why there is an extra “CMSIS”. It would be acceptable if the users don’t deal with the files directly and everything is hidden behind a GUI or other tools, but as embedded developers, the users need to know where to find these files and examine the files to see what functions are defined and how they are to be used.
Currently, files from the following vendors are included:
- Freescale (Kinetis series; Freescale is now part of NXP)
- Maxim (MAX Darwin series)
- Microchip (Atmel SAM series)
- NXP (LPC series)
- SiLabs (Energy Micro series)
- STM (STM32 series)
These files will be updated as new MCUs are released. Some MCUs – the NRF series from Nordic Semiconductor in particular – can only be programmed using the entire NRFstacks and therefore do not fit in this model. Similarly, advanced stacks such as USB and ethernet stacks exist for some MCUs and are provided by some of the vendors. They can be downloaded from the vendors’ sites as needed.
How to Use
To use, add these lines to the include paths in the Build Options:
If you use any of the I/O peripherals, then you should add the relevant include files in your source files as #include, and then add the source files in the src directories to your project file list. You will need to study the vendor header files to see what functions are provided,and their function signatures. It is beyond the scope of this documentation to describe all the vendor files. Web search should also provide you with additional information and examples.