2022-05-18 08:41 AM
My background is in hardware, but I have extensive experience writing "bare metal" code (C) for 8-bit MCUs, mostly for AVRs. In the past, I have used AVR Studio (now Microchip Studio), starting with version 4.18 down to present versions. Tool chain was avr-gcc, followed by whatever Atmel eventually wrote and integrated into their later IDEs. I am starting a few new projects built around STM32G071 chips. While waiting for hardware, I am trying to come up to speed with software creation using a NUCLEO-F103RB. My end application (for now) requires interfacing to another MCU and controlling a BLDC motor.
This is my first foray into 32 bit MCUs and ARM. What is the best IDE/tool chain for me to use? My head is currently spinning with options. I have looked at STM32CubeIDE, but have read horror stories online about deleted code, etc. I have also read about Keil and IAR. I am reasonably familiar with makefiles, but would like to avoid a pure command line/script/text editor approach, and would prefer a more integrated solution (something similar to Atmel Studio with editably makefiles). Due to my hardware background, my coding style is to be as close to the hardware as possible (configuring peripherals by manually setting registers, etc.). Does this impact my choice? Should I use CMSIS or HAL (not sure how...)?
Any advice would be greatly appreciated.
2022-05-23 04:22 PM
#define STM32F103xB
#include "stm32f1xx.h"
RCC->CR |= RCC_CR_HSEON;
while (!(RCC->CR & RCC_CR_HSERDY));
2022-05-23 10:14 PM
Bit late, but here goes. I use Keil. I write straight to the registers and develop my own hardware. The simulator is good and I have debugged multiple projects with just a simulator. For a long time I was persisting with an old version of Keil that would work on Windows XP (I work at several locations, and sometimes on old computers). I have recently used the latest version of Keil on a laptop - I actually prefer the old version of Keil. The old version was faster and less bloated. As long as you have the appropriate header file with all register definitions you can get most things done. There are probably better things out there but I have to find the time to evaluate the alternatives.
2022-05-24 01:01 PM
Thanks for the pointer. When I dig into stm32f1xx.h, it looks like I also need to include stm32f103xb.h and system_stm32f1xx.h.
stm32f103xb.h includes core_cm3.h. It appears that this header is necessary for the __IO/__I/__O types used in stm32f103xb.h. However, including core_cm3.h opens up a rabbit hole going down to many cmsis header files. To include use stm32f1xx.h, do I need to incorporate the entire CMSIS library into my design?
Also, if I want access to those register definitions from multiple places, I think I would need to include stm332f1xx.h from multiple places. However, I must be doing something wrong, because the compiler is complaining that it I haven't defined my device (getting the error from line 141 of stm32f1xx.h). Short of using #ifndef/def pairs every time I include the header file, is there a better way?
2022-05-24 01:22 PM
> To include use stm32f1xx.h, do I need to incorporate the entire CMSIS library into my design?
Usually, yes. But this isn't evil and no reason to avoid it.
The CMSIS convention (invented by Keil, or ARM) requires that for each cortex-M chip the vendor provides a .h file which defines all vendor-added stuff and also includes generic stuff for its ARM core.
ST implements this with two levels of .h files: family-common and more specific, selected by a preprocessor define (#define STM32F103xB). You'll get used to it.
2022-05-25 10:40 AM
You have to define STM32F103xB at a higher level, at the project level, eg in the CFLAGS, so il will be known of every source file.
2022-05-25 11:09 AM
That worked - thanks.
2022-05-25 05:18 PM
Defining it on a project level is kind of even safer, but defining it in some "main.h" file, which is included everywhere, is also fine.
> do I need to incorporate the entire CMSIS library into my design?
Only the folder with core and compiler definitions and a few useful functions for a core peripheral management. You can find it also in ST's firmware package, but they ship old versions.
2022-05-29 03:49 AM
[shameless self-promotion] Maybe tangentially relevant writeup. Comments welcome. [/shameless self-promotion]
JW