HALMX project templates with Codeblocks

I created a repo with some small programs running under HALMX using Codeblocks IDE.
The important is the use of HALMX as library for specific stm32 variants (eg f103xb, f401xe, l476xx, etc). Unfortunately the halmx can’t be used 100% as general library because some configuration variables are passed as defines in the core like xtal speed. In the predefined targets 8MHz xtal is defined, any other speed requires rebuilding of the library (it is very easy as the HSE_VALUE is passed as define in command line of gcc and is not hardwired in the code). All the latest halmx sources are used untouched from ST zip files without any cubemx generated files.
For correct compilation a newer gcc v5 is required. (Edit:this is not correct, seems that V4.8 builds the targets correctly)
For now, there are some very small examples of code. The important is to keep the source the same and to build the binary with all supported libraries. To achive this goal I have reorganize the halmx sources, but this is my testbed for halmx and prepare to see many changes in the tree.

I think that this will help anyone to start with halmx/codeblocks.
The repo is here : https://github.com/evark/cbp-halmx

Slammer wrote:
I think that this will help anyone to start with halmx/codeblocks.
The repo is here : https://github.com/evark/cbp-halmx

I will try to complete a short guide about compiler setup and integration to codeblocs in windows/linux as soon as possible. Is not so difficult, actually is much easier than eclipse.

@slammer

Can you confirm that the output from the cube now needs gcc 5 to compile correctly, or is it just codeblocks that needs gcc 5?

If the Cube needs gcc 5, a Boards Manager package would be needed for the IDE to install gcc 5, and I think it could have side effects for other boards.

I remember installing a repo from RedBearLab which installed a different gcc and I think the IDE started to use that version of gcc for all ARM boards.
I dont know why, perhaps it was an error in the Boards Manager package

gcc 5 is not a strict requirement, I just test the code with 4.8 and runs OK, at least for the functions used.
I remember that the mbed code which is also using HALMX requires V5, but until know I don’t have problems with 4.8.
I will switch the default compiler to 4.8 in the projects (libhal and tests) as this is our default tool.
Codeblocks can handle many different versions of compilers and can assign different gcc versions to different targets, is very versatile. In my C::B setup I have defined more than 16 compilers (various versions, various targets, eg, sdcc, gcc-avr, gcc-mingw32, gcc-mingw64, gcc-arm-linux, gcc-xtensa, gcc-mips, gcc-mipsel, etc…).

OK

Thanks

Now is possible to play with HALMX from Arduino IDE.

While the building of libhal requires Codeblocks, I have included in the repo the binary form of libraries. The libraries support only boards with 8MHz external Clock or XTAL (this is a limitation of HALMX, as the HSE_VALUE must be defined in compile time) and all modules of HALMX are included.
I played also with the arduino building system and after a directory reordering it is now possible to build plain HALMX applications by “Arduino Way” (no arduino core, only the IDE).
I manage to hide most of halmx oddities, for example the typical blink example (with delay-Systick interrupt working by default) is like this (no includes/no other files required):

#ifdef STM32F103xB
/* BLUE PILL */
#define LEDPORT GPIOC
#define LEDPIN GPIO_PIN_13
#else
/* NUCLEO */
#define LEDPORT GPIOA
#define LEDPIN GPIO_PIN_5
#endif

/// GPIO macros for maximum speed
///
#define gpio_toggle(GPIOx, GPIO_Pin) ((GPIOx)->ODR ^= (GPIO_Pin))
#define gpio_clear(GPIOx, GPIO_Pin) ((GPIOx)->BSRR = (uint32_t)(((uint32_t)GPIO_Pin) << 16))
#define gpio_set(GPIOx, GPIO_Pin) ((GPIOx)->BSRR = (uint32_t)(GPIO_Pin))
#define gpio_write(GPIOx, GPIO_Pin, val) ((val) ? gpio_set(GPIOx, GPIO_Pin) : gpio_clear(GPIOx, GPIO_Pin)

void gpio_setup_output(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
{
GPIO_InitTypeDef GPIO_InitStruct;
HAL_GPIO_WritePin(GPIOx, GPIO_Pin, GPIO_PIN_RESET);
GPIO_InitStruct.Pin = GPIO_Pin;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(GPIOx, &GPIO_InitStruct);
}

/******************************************************************/

int main(void)
{
/* GPIO Ports Clock Enable */
__HAL_RCC_GPIOA_CLK_ENABLE();
__HAL_RCC_GPIOC_CLK_ENABLE();

gpio_setup_output(LEDPORT, LEDPIN);

while (1)
{
gpio_toggle(LEDPORT, LEDPIN);
HAL_Delay(50);
}
}
/******************************************************************/

Now the Templates are enriched with some advanced features:

• – Startup in plain C (no assembly .S file) thanks to gnuarmeclipse project and Liviu Ionescu’s cortexm-startup (https://github.com/micro-os-plus/cortexm-startup). With this way the startup is cleaner and offers flexibility and reduced size as the standard c library functions are not called.

  – Support for semihosting (very useful for debugging). Offers stdio-like functions on debugger before any initialization of peripherals.

  – some standard library’s functions (stdio) are reimplemented for semihosting support and/or size reduction.

  – Dynamic vectors in RAM. No need to declare as interrupt vectors global functions known at compile time, it is possible to redirect any vector to any function or class method any time. Vectors are stored in the beginning of RAM at 0x20000000 and are taking the required space (Vectors number X 4 bytes).

  – Unified linker script. Only the memory sizes are declared on dedicated files.

  – HALMX sources untouched, compiled as library (there are binary versions on repository for some boards)

  – Arduino IDE integration

  – Arduino-like core as example. Is not a complete core but I am working on it to make it better. For now, timing and digital functions supported. I will try to include/convert all working functions of Arduino_HALMX shortly ( I hope that Vassilis will give some help).

  – Library binaries and working examples for BluePill, NucleoF401RE and NucleoL476RG. (No need to rebuild anything with Codeblocks, use directly Arduino IDE)

  – RTX RTOS integration optionally. Very thin cmsis based RTOS for CortexM MCUs (Work in Progress) starting before main (the main is just a thread).

Slammer wrote:Now the Templates are enriched with some advanced features:

OpenCM3 and UniMX are a thin wrapper on registers not a hal, actually there is no abstraction, user still must know how to do things almost on register level in each family variation, furthermore, the naming and interface of functions is not unified making the development of cross-family applications a real nightmare. I hope that UniMX will improve OpenCM3 work but it is very early yet.

HALMX, is ugly and sometimes bloated but is the only solution if you want something stable (officially supported), unified (as possible) and available for any STM32. Other options are mbed (low level API on top of HALMX), Chibios hal and Standard Peripheral Library of ST (deprecated, no support for new MCUs).

I’ve taken your latest cbp-halmx, placed in hardware folder (IDE 1.6.10, Win7).
Board F103CB_BluePill chosen, your blink demo above.
While linking I get:
Linking everything together...
..
C:\Users\pito\MyCode\Arduino\hardware\cbp-halmx\stm32\cores\stm32hal/main.cpp:31: multiple definition of `main'
..

Pull the latest sources, I tested every example, except Digital2 (needs definition of a BUTTON) on BluePill
In adruino IDE use only the examples from Libraries folder (Examples>CBP_HALMX_EXAMPLES>) not the sources from test….

Ok understood..
FYI – getting a lot of warnings eg with Blink2

Linking everything together...
"C:\Users\pito\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-gcc" "-LC:\Users\pito\AppData\Local\Temp\buildb289e2be8bfe67184059a3c0081fb0d2.tmp" -Os -Wl,--gc-sections -save-temps "-Tstm32f103xb.ld" "-Wl,-Map,C:\Users\pito\AppData\Local\Temp\buildb289e2be8bfe67184059a3c0081fb0d2.tmp/Blink2.ino.map" --specs=nano.specs -mcpu=cortex-m3 -msoft-float -mfix-cortex-m3-ldrd -mthumb -Os -nostdlib -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,-static "-LC:\Users\pito\MyCode\Arduino\hardware\cbp-halmx\stm32\system/lib" "-LC:\Users\pito\MyCode\Arduino\hardware\cbp-halmx\stm32\system/ld" -o "C:\Users\pito\AppData\Local\Temp\buildb289e2be8bfe67184059a3c0081fb0d2.tmp/Blink2.ino.elf" "C:\Users\pito\AppData\Local\Temp\buildb289e2be8bfe67184059a3c0081fb0d2.tmp\sketch\Blink2.ino.cpp.o" "C:\Users\pito\AppData\Local\Temp\buildb289e2be8bfe67184059a3c0081fb0d2.tmp\core\rcc.c.o" "C:\Users\pito\AppData\Local\Temp\buildb289e2be8bfe67184059a3c0081fb0d2.tmp\core\usart.c.o" "C:\Users\pito\AppData\Local\Temp\buildb289e2be8bfe67184059a3c0081fb0d2.tmp\core\variant.cpp.o" -Wl,-whole-archive "C:\Users\pito\AppData\Local\Temp\buildb289e2be8bfe67184059a3c0081fb0d2.tmp/core\core.a" -lhal-f103xb-8m -Wl,-no-whole-archive -lstdc++ -lsupc++ -lm -lgcc -lc -lnosys
c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .vfp11_veneer by 2 bytes

c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .v4_bx by 2 bytes

c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .iplt by 2 bytes

c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .rel.dyn by 2 bytes

c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .vfp11_veneer by 2 bytes

c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .v4_bx by 2 bytes

"C:\Users\pito\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-objcopy" -O binary "C:\Users\pito\AppData\Local\Temp\buildb289e2be8bfe67184059a3c0081fb0d2.tmp/Blink2.ino.elf" "C:\Users\pito\AppData\Local\Temp\buildb289e2be8bfe67184059a3c0081fb0d2.tmp/Blink2.ino.bin"
c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .iplt by 2 bytes

c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .rel.dyn by 2 bytes

c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .vfp11_veneer by 2 bytes

c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .v4_bx by 2 bytes

c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .iplt by 2 bytes

c:/users/pito/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .rel.dyn by 2 bytes

Sketch uses 3,158 bytes (2%) of program storage space. Maximum is 131,072 bytes.
Global variables use 24 bytes of dynamic memory.

These warnings are harmless, normally the arduino building system ignores them by setting the appropriate -W flag.