new cores on HALMX_Arduino_STM32

Development of new Cores using the STMCubeMX and HAL
stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: new cores on HALMX_Arduino_STM32

Post by stevech » Sun Sep 06, 2015 1:02 am

I'm a well-experienced user of CubeMX and the HAL from ST.
Would you folks like some assistance?

steve

User avatar
RogerClark
Posts: 7177
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Sun Sep 06, 2015 1:10 am

Hi Steve

Yes. I suspect we do need some assistance ;-)

I'm just not sure of what assistance we need at the moment

Perhaps you'd like to have a go at running the HAL MX Core https://github.com/rogerclarkmelbourne/ ... ino_STM32/

Getting USB to work on the F103 would be the first thing I think we'd need to do, as not everyone has STLink.

Then we can use the existing bootloader to upload (after we've worked out the best way to change the CMSIS vector table offset value to move the start offset to 0x2000 (i.e start address of 0x8002000)

To work with the bootloader we'd also need to work out how to monitor the DTR and chars on the USB Serial, as the existing code uses a special sequence to trigger a reboot of the processor (into the bootloader)

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: new cores on HALMX_Arduino_STM32

Post by stevech » Mon Sep 07, 2015 12:03 am

Happy to help.
To calibrate me...
Do I understand the goal of HALMX correctly...

HAL = ST's HAL libraries that replace the SPL (standard peripheral libraries). For STM32F1xx and F4xx?

MX = ST's CubeMX tool. Yes? With CubeMX, an advanced user, perhaps on behalf of beginners or people who want to take a board and the matching CubeMX config. as below, but pre-configure for that type of user. The advanced user's method is...
  • choose the STM32 chip and package type. Or you start with a given/prior CubeMX configuration and alter it to yield a new different one for the current project.
  • choose the on-chip peripherals needed for a certain app. This is independent of how the MCU's pins are wired to any PC board or breadboard. You setup the default system and bus clock modes and dividers and the PLL, using the graphical user interface.
  • For each needed peripheral, you tell CubeMX (via the graphical user interface) what peripheral is mapped to what pins on the MCU's package (still, not board specific).
  • Then for each peripheral, you configure all of its modes and options, e.g., clock speed of SPI, baud rate of UART, GPIO in/out/pullup, external interrupts, etc.
  • Configure the desired modes: polling, interrupt, DMA and other details for each peripheral that you config. And so on. This all done, you choose the target compiler (IAR, Keil, GCC and avoid what the IDE is).
  • Then tell CubeMX to GENERATE PROJECT for the target compiler/IDE. It generates the code to configure the system clock dividers and the PLL. It gathers all the HAL code needed to satisfy the chosen peripherals.
  • It generates code to initialize each peripheral in the chosen modes. It creates interrupt handlers for each peripheral, with optional call-backs to the user app. It creates a main().
  • You code into main() whatever. setup() is not needed for I/O initialization. loop() is within main() that you alter to suit.
From here is where it gets fuzzy for me. Are Arduino's IDE and its GCC compiler command lines incompatible with the above? Arduino's concept of parsing all the .c and .cpp files to auto-generate function prototypes may be contrary to CubeMX and HAL which use traditional .h files. The necessary .h file #includes are auto-generated by CubeMX.

As to board-specific. I did one project where I used CubeMX and HAL and wrote code for some of the wiring calls (digital.write/read) and interrupt vector establishment (attach interrupt). I did that with the "weak" tribute that CubeMX uses for interrupts and other calls - so these weak-functions can be overridden by you by coding a function of the same name, in C (not C++ overloading).

All if this is in C. No C++ required. But can be used. No use of a heap, but can be used.

For me, I've moved on from the Arduino libraries since they are a buggy and small subset of what is in ST's HAL. Freescale has a lesser but similar HAL and CubeMX equivalent.

Doing so, I have been able to focus on the app, not writing drivers and I/O libraries, avoid open source but incompatible myopic libraries, and so on Arduino's libraries are, due their AVR heritage.
==========================

I was able to take the above and integrate the big RadioHead protocols... written for Arduino but substitute HAL libraries for Arduino libraries, targeting STM32F. To include SPI, pin change interrupts, timers, micros(), and so on. This suite of code is heavy C++, but made compatible with a mix of C and C++ HAL and user code.

This says the Arduino IDE gets replaced with a conventional IDE (no .ino, use ordinary methods). These IDEs might be Eclipse (non-intuitive), Free Windows-only VisualMicro+Visual Studio Community edition), VisualGDB or ye ole makefiles for those that prefer that. IAR and Keil are there, but free only for 32KB projects. I've used IAR for years (professionally).

OK... is this the goal for HALMX_arduino? I guessing the answer is no. But for me, projects are done much faster with CubeMX and the vast amount of supported code in HAL. (happily, I rarely have to look inside of HAL's code) .. just the APIs.

User avatar
Rick Kimball
Posts: 1040
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: new cores on HALMX_Arduino_STM32

Post by Rick Kimball » Mon Sep 07, 2015 1:22 am

stevech wrote:For me, I've moved on from the Arduino libraries since they are a buggy and small subset of what is in ST's HAL. Freescale has a lesser but similar HAL and CubeMX equivalent.
All frameworks/API are buggy. I guess each person has to pick their preferred poison.

I've been tracking the HAL stuff. First thing I noticed was a bogus Stack Pointer Address in the generated ld script, I had to fix myself. It got me thinking, if they can't that something as basic as that right, what else is lurking. Then I started watching complaints on the forum and there are plenty. My take is that It seems like it is too early to jump on the HAL bandwagon unless you want to be fixing their bugs.

-rick
-rick

User avatar
sheepdoll
Posts: 236
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: new cores on HALMX_Arduino_STM32

Post by sheepdoll » Mon Sep 07, 2015 1:29 am

Hi Steve;

Have you taken a look at the rough documentation text files I placed in the HALMX_Arduino_STM32 lashup I provided Roger? There are direct links to these, which Roger is placing in the project wiki.

The goal of all this was to make something that could be setup quickly and be understood by someone with one of the Arduino primers. A number of us are using *nix systems, OS X, Linux rather than window$. The alternative for non M$ users is to use eclipse.

I use a similar method to your advance user outline. In my case I am focused on the Nucleo, and discovery kits. I choose these from the board setup. Configure and map the pin functions where there are conflicts with the more expected functions. Then generate the code for the GCC compatible Systems Workbench.

There does not seem to be any issue with the use of the traditional .h file under the Arduino IDE. The Arduino compiler is just GCC, the board.txt file in coordination with platforms.txt setup the GCC compiler options. the .ino file can contain any HAL API callbacks as the .h files are included through these scripts.

The goal was to sort of "float" the arduino API on top of the HAL API. Most of this has been done by using simple "glue" code and some defines where the functions were virtually the same. So far the only hooks I have needed are in main.c and main.h. Like you, I rarely look inside the HAL code, I do however refer extensively to the .pdf that describes the API. I also find that the examples contained in the STMCube/repository "Firmware" examples folder to be most instructive. See the examples folder in the HALMX_Arduino_STM32, where this was done to do a blinky and a simple serial sketch.

I like to use git to contain the CubeMX .ioc, I was reading on the STM forums, that someone else though this is a good idea. This way it is easy to create new variants as branches. It is also good for rolling back the auto generated code if something breaks. I use a differencing editor, git provides this same information as part of the git status reports.


One big difference between STM and Arduino approach, that may also lead to some of the fuzzyness is the way that the code is loaded onto the silicon. I come from the 8051 and AVR worlds, and prefer jtag dongles to do the upload/debug. There does seem to be a desire to make the bootloader work as it does, transparently on an Arduino through the DFU CDC. That seems to be where some minor changes to the CMSIS core might need to be changed, to allocate the boot space.

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: new cores on HALMX_Arduino_STM32

Post by stevech » Mon Sep 07, 2015 1:39 am

I've not used HAL/CubeMX with GCC; only IAR.
I found no problem with the linker script for IAR - but I edited it to avoid using some areas of flash so I can use that for read-mostly memory, like 64KB since the '415 has 4x16KB and the rest of 1MB is 64KB sectors.

I've found only two or so bugs in the HAL drivers - and they are for esoteric drivers (half duplex mode of UARTs).
The app I have is about 35 C files, all the HAL libraries for
UART half duplex; UART normal full duplex, both interrupt driven, one at 250Kbaud, the other at 115K
SDIO and FATFS, 16GB uSD, DMA for both read and write
Two SPI channels, DMA
External pin interrupts
two timers
systick 1mSec (built into HAL)

The HAL drivers are actually wrappers on the SPL drivers.

bookerh
Posts: 4
Joined: Mon May 09, 2016 3:31 pm

Re: new cores on HALMX_Arduino_STM32

Post by bookerh » Mon Aug 01, 2016 12:04 am

Hi Roger:

I download the HALMX_Arduino_STM32. and get some error with build Blink sketch at arduino ide 1.6.5.
below the error message:

C:\Users\booker\AppData\Roaming\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-ar rcs {archive_file_path} r:\TEMP\build2787883865254039219.tmp\WString.cpp.o
C:\Users\booker\AppData\Roaming\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++ -Os -Wl,--gc-sections -mcpu=cortex-m3 -TC:\Users\booker\Documents\Arduino\hardware\HALMX_Arduino_STM32-master\HALMX\variants\MXBluePillF103C8/SW4STM32/MXBluePillF103C8/STM32F103C8Tx_FLASH_0x2000.ld -Wl,-Map,r:\TEMP\build2787883865254039219.tmp/Blink.cpp.map -LC:\Users\booker\Documents\Arduino\hardware\HALMX_Arduino_STM32-master\HALMX\variants\MXBluePillF103C8/ld -o r:\TEMP\build2787883865254039219.tmp/Blink.cpp.elf -Lr:\TEMP\build2787883865254039219.tmp -lm -lgcc -mthumb -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -Wl,--start-group r:\TEMP\build2787883865254039219.tmp\Blink.cpp.o r:\TEMP\build2787883865254039219.tmp\startup_stm32f103xb.S.o r:\TEMP\build2787883865254039219.tmp\system_stm32f1xx.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_adc.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_adc_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_cortex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_dma.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_flash.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_flash_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_gpio.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_i2c.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_pcd.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_pcd_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_pwr.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_rcc.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_rcc_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_spi.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_spi_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_tim.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_tim_ex.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_uart.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_ll_usb.c.o r:\TEMP\build2787883865254039219.tmp\usbd_cdc.c.o r:\TEMP\build2787883865254039219.tmp\usbd_core.c.o r:\TEMP\build2787883865254039219.tmp\usbd_ctlreq.c.o r:\TEMP\build2787883865254039219.tmp\usbd_ioreq.c.o r:\TEMP\build2787883865254039219.tmp\adc.c.o r:\TEMP\build2787883865254039219.tmp\gpio.c.o r:\TEMP\build2787883865254039219.tmp\i2c.c.o r:\TEMP\build2787883865254039219.tmp\main.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_hal_msp.c.o r:\TEMP\build2787883865254039219.tmp\stm32f1xx_it.c.o r:\TEMP\build2787883865254039219.tmp\tim.c.o r:\TEMP\build2787883865254039219.tmp\usart.c.o r:\TEMP\build2787883865254039219.tmp\usbd_cdc_if.c.o r:\TEMP\build2787883865254039219.tmp\usbd_conf.c.o r:\TEMP\build2787883865254039219.tmp\usbd_desc.c.o r:\TEMP\build2787883865254039219.tmp\usb_device.c.o r:\TEMP\build2787883865254039219.tmp\_spi.c.o r:\TEMP\build2787883865254039219.tmp\variant.cpp.o r:\TEMP\build2787883865254039219.tmp/core.a -Wl,--end-group
arm-none-eabi-g++: error: r:\TEMP\build2787883865254039219.tmp/core.a: No such file or directory
Error compiling.

User avatar
sheepdoll
Posts: 236
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: new cores on HALMX_Arduino_STM32

Post by sheepdoll » Mon Aug 01, 2016 2:27 am

Hi bookerh

It looks like you may not have installed the g++ from the Due Boards manager. Run the Board manager and select Due. The arm-none-eabi tools are not installed by default.

The other issue is there seems to be some windows paths with the '\' slash. Most of the HalMX stuff is developed on unix or linux. Windows is not really supported. The workaround would be to change a local copy of platform.txt where the unix path is being generated to use the windows '\' separator.

-julie
bookerh wrote:Hi Roger:

I download the HALMX_Arduino_STM32. and get some error with build Blink sketch at arduino ide 1.6.5.
below the error message:
...
arm-none-eabi-g++: error: r:\TEMP\build2787883865254039219.tmp/core.a: No such file or directory
Error compiling.

bookerh
Posts: 4
Joined: Mon May 09, 2016 3:31 pm

Re: new cores on HALMX_Arduino_STM32

Post by bookerh » Mon Aug 01, 2016 1:25 pm

Hi sheepdoll :

Thank you for your reply. I forgot to install the due package.
I try that again.

Thank you, sheepdoll .

Post Reply