search

ekoeppen / stm32tl

STM32 C++ Template Library
MIT License
14 stars 4 forks source link

Which CMSIS files to use? #1

Open RickKimball opened 6 years ago

RickKimball commented 6 years ago

Which CMSIS headers and which arm-none-eabi-g++ was used to compile with an STM32F103?

I'm getting constexpr errors while compiling using the latest CMSIS headers from STM32Cube and arm-none-eabi-g++ version: arm-none-eabi-g++ (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622

I also tried with a gcc 6.x something same problem.

ekoeppen commented 6 years ago

The problem seems to be not the CMSIS files used, but that it's not proper C++ code to assign the result of a reinterpret_cast to a constexpr. This worked with GCC 4.8 by accident. The proper fix would be to assign the address of a peripheral to the constexpr, and to move the peripheral via a linker script to the right address.

tufty commented 4 years ago

Hi Eckhart.

Another long-time Newton user here :)

I see you've gone with the re-hard-coding of addresses approach in your peripherals-mem-fixed branch. I don't particularly like that approach, or the alternate one of using linker scripts, it duplicates the magic numbers from CMSIS all over the place, and needs to be done on a per-CPU basis.

I have an alternate approach, see f1/gpio.h in my fork, which is as follows:

1 - #undef the stuff from CMSIS which incorporates casts - in gpio terms that's GPIOA, GPIOB, etc. Not absolutely necessary, but cleans up the namespace. 2 - instead of using CMSIS' _TypeDef , use uintptr_t, and assign from the …_BASE defines. This avoids the "not a constexpr" issues 3 - reinterpret_cast the uintptr_t to _TypeDef at runtime.

Now, I'm guessing you won't like the reinterpret_cast at runtime bit, and the way I hacked it in via copy-pasta clutters the code, but from my testing it seems this changes nothing in the generated object code. Obviously, this is trusting the compiler to "do the right thing", but we're already doing that, right?

ekoeppen commented 4 years ago

Thanks for using the code as a basis! I think your approach is as good as mine... In the end, maybe it would make sense to switch to something SVD based and let a tool generate the correct types.

I'm mostly working with Ada these days, where svd2ada generates the needed packages: https://github.com/ekoeppen/STM32_Generic_Ada_Drivers