Hello everybody! It’s a good week of production so far and I am happy to announce the release of the fully working CMSIS & FWLib KEIL ARM-MDK project template.

 

Upon the rival of my STM32 Mini I have been struggling to get CMSIS to play nicely with ST’s firmware libraries which provide a standardized function set to using their on board peripherals. Using the firmware library is important to me because this is not a simple AVR or PIC microcontroler here, their can be a dozen 32bit registers for a periphearal and when you start dealing with DMA and the NVIC working at the register level becomes very tedious and error prone. Those who have used Procyon AvrLibC know that having a standard function set for each peripheral can cut down development time substantialy. ST’s firmware library is quire similar to Procyon’s in the fact they are an assortment of source and header files that you can selectively include yourself or use their global configuration file. The major difference between ST’s version and other micro libraries I have seen is it is MUCH simpler to compile in piece meal form; you can simply select the SPI library for example and you only need to include a few other files to provide lower level functions and your ready to go.

 

I have created a simple project standard that has all the include paths and folder structures arranged in a clear manner with the files you should not be modifying set with the appropriate read only file permissions. The KEIL uVision IDE provides the bulk of the setup through their project configuration menu as I assume if you are using KEIL your not going to be using just the command line compiler. If their is interest in using the KEIL command line tools I might add a makefile to the project at a later date.

 

The relevant files to you, the user who is starting a new project are these:

FWLib_INCstm32f10x.h

  • Library_configuration_section
  • Use the peripherals drivers
  • External High Speed oscillator (HSE)
  • (HSE) Startup Timeout value

These options may be set by modifying the header file or by adding the defines to the project via Project Options -> C/C++ -> Defines. I perfer to leave the header untouched and just use the defines as that way you can leave a clean firmware library that you never need to worry about their being an error in. After all the who point of portability is to never modify the middleware.

My template includes these defines: 

  • STM32F10X_MD
  • USE_STDPERIPH_DRIVER

As simple as that. I have never needed to modify the HSE settings as you will use an 8MHz crystal on any of the STM32 chips except the connectivity line and ST has taken care of modifying the HSE values automatically when you select STM32F10X_CL as your chip type.

To include specific library componets such as GPIO, SPI, RTC etc their is a handy file called FWLib_INCstm32f10x_conf.h with this file you simply comment out the features you do not wish to use and the compiler will automatically include them in the project for you. Their is nothing else you need to do to get off the ground with CMSIS & FWLib. 

One thing I should mention is their is a rule in the STM32 documentation that the first 15 interrupts in the negative range must have prototypes even if they are empty. I’m not sure why this is so but as its their standard we must do as we are told. In the FWLib_SRC folder their is a file called stm32f10x_it.c that handles all this for you and if you wish to add a delay function via SysTick this is where the SysTick_Handler() ISR resides. You will notice that all the other files in the FWLib_SRC folder have little gold keys next to them and the stm32f10x_it.c file is the only one without one; this is because it is the only source file in the firmware library you should ever have the need to modify.

 

I have compiled the documentation for both CMSIS and the Firmware Library from Doxygen in compressed HTML format, also known as  Windows help files and I believe they turned out quite nicely. The stylesheet is quite ugly and I am working on my own version but they give a very clear presentation of the available functions and what the initializing structures contain. I plan on writing a post on how to navigate the documentation to find out what options are available to the initialization structures such as how to find out that GPIO_InitStruct.GPIO_Mode  = GPIO_Mode_Out_PP; also has the GPIO_Mode_AF_PP mode available. 

 

So what does the future of this project hold? Well my goal is to provide a much more useful firmware lib package than ST has with examples of real world devices such as LCD’s, TFT’s, touch panel controlers and SD cards. To compare the current SPI examples in the firmware library use code that sends on SPI1 and recieves on SPI2 of the same chip, this is great if you want to see if the peripheral even works but when you need to initialize it for the real world and handle NSS pins in software their is no examples to be found. My end goal is to use the STM32 Mini as a template and have each piece of hardware as a separate example and then combined together to make a complete project. In this way I hope to instruct not only myself but anyone else who finds the world of ARM quite daunting.

I do need some input from the community on this project, mostly regarding what compilers and IDE’s I should be developing on. I started with KEIL because of their peripheral view during debugging but after this template was complete that feature is no longer necessary. Should I focus on GCC with a makefile, KEIL command line maybe, or focus on Rowley CrossWorks? I wish to support whichever is more popular.

 

For version 1.2.0 my goals include compiling the entire CMSIS & FWLib into a library file and only leave the files mentioned above available to the user so as to remove the temptation to modify and to clean up the project inclusions.

Download v1.1.0 now from: SourceForge

Advertisements