STM have developed a HAL MX core

Information on the latest releases
User avatar
Rick Kimball
Posts: 754
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: STM have developed a HAL MX core

Postby Rick Kimball » Thu Sep 15, 2016 4:33 pm

Some quick observations:

o Just 2 boards for now STM32F103RB-Nucleo and STM32L476RG-Nucleo.
o Flashing is accomplished by using the Mass Storage feature of the Nucleo boards, 64 bit exec for Linux, .bat file for Windows and a 64-bit Mac OS exec. Source code for the Linux and Mac versions of the flasher provided.
o HAL routines provided as a lib file with no source code. HAL headers provided.
o Seems to be a straight forward wiring implementation
o AsciiTable compiles to ~8k
o I only see one file with the name usb in it .. system/Drivers/STM32F1xx_HAL_Driver/Inc/stm32f1xx_ll_usb.h

I don't see a source version of this anywhere just the resultant package.

-rick
Last edited by Rick Kimball on Thu Sep 15, 2016 5:11 pm, edited 1 time in total.
-rick

User avatar
martinayotte
Posts: 1163
Joined: Mon Apr 27, 2015 1:45 pm

Re: STM have developed a HAL MX core

Postby martinayotte » Thu Sep 15, 2016 4:35 pm

Watch List : Me too ... ;)

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

Re: STM have developed a HAL MX core

Postby Rick Kimball » Thu Sep 15, 2016 5:17 pm

I took a peek at the core api source files. It seems instead of calling HAL routines directly they have created wrapper functions that are binary only object code in the libstm32f1_nucleo-f103rb_gcc_rel.a file. I took a look at the object code generated for Blink.ino sample and disassembled the digitalWrite call. The core wiring_digital.c calls a function called digital_io_write()

Code: Select all

08001b8c <digital_io_write>:
 8001b8c:       b508            push    {r3, lr}
 8001b8e:       b289            uxth    r1, r1
 8001b90:       4b02            ldr     r3, [pc, #8]    ; (8001b9c <digital_io_write+0x10>)
 8001b92:       b102            cbz     r2, 8001b96 <digital_io_write+0xa>
 8001b94:       2201            movs    r2, #1
 8001b96:       4798            blx     r3
 8001b98:       bd08            pop     {r3, pc}
 8001b9a:       bf00            nop
 8001b9c:       08001939        .word   0x08001939

That calls the code at 0x8001939 which is the real HAL routine

Code: Select all

08001938 <HAL_GPIO_WritePin>:
 8001938:       b902            cbnz    r2, 800193c <HAL_GPIO_WritePin+0x4>
 800193a:       0409            lsls    r1, r1, #16
 800193c:       6101            str     r1, [r0, #16]
 800193e:       4770            bx      lr


The uart code is handled the same type of way. I wonder if they are going to provide source code to all the wrapper functions.

-rick
-rick

edogaldo
Posts: 215
Joined: Fri Jun 03, 2016 8:19 am

Re: STM have developed a HAL MX core

Postby edogaldo » Thu Sep 15, 2016 5:30 pm

@Rick
Curiosity: did you check the size of an empty sketch?

Cheers, E.

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

Re: STM have developed a HAL MX core

Postby Rick Kimball » Thu Sep 15, 2016 5:32 pm

Compiling the BarMinimum code:

Code: Select all

$ arm-none-eabi-size -A BareMinimum.ino.elf
BareMinimum.ino.elf  :
section              size        addr
.isr_vector           268   134217728
.text                6824   134217996
.rodata               144   134224824
.init_array             8   134224968
.fini_array             4   134224976
.data                 948   536870912
.bss                  464   536871860
._user_heap_stack    1536   536872324
.ARM.attributes        41           0
.comment              184           0
.debug_frame           44           0
Total               10465


$ arm-none-eabi-size BareMinimum.ino.elf
   text      data       bss       dec       hex   filename
   7236       960      2000     10196      27d4   BareMinimum.ino.elf
$
-rick

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

Re: STM have developed a HAL MX core

Postby RogerClark » Thu Sep 15, 2016 9:01 pm

Interesting

I have not heard from ST for 2 days, so I wasnt aware that they were uploading.

To be honest, I thought they would create a new repo the source files.

The BoardsManagerFiles is a repo that I created ages ago, in preparation for using @ddrown's BoardsManager package files, for libmaple.

But it looks like ST have decided to use the existing repo, as it suits the purpose.

I dont know how they are creating the boards manager package, or what numbering scheme they are using.
I suspect the numbering scheme will need to be changed, to the date based schema that was discussed in a previous thread.

Anyway, it looks like Im going to be busy with this over the weekend ;-)

User avatar
GrumpyOldPizza
Posts: 170
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM have developed a HAL MX core

Postby GrumpyOldPizza » Thu Sep 15, 2016 9:36 pm

Just out of curiosity ... there is this all over the place: "@author WI6LABS". Does that mean WI6LABS wrote the code and owns it ? (http://www.wi6labs.com/)

madias
Posts: 812
Joined: Mon Apr 27, 2015 11:26 am
Location: Vienna, Austria

Re: STM have developed a HAL MX core

Postby madias » Thu Sep 15, 2016 10:00 pm

Ok, I took out my rusty Nucleo F103RB board.
Compiling seems to be ok (little warnings) but upload failed totally.
At first in platforms.txt the path is wrong and must be (under windows)

Code: Select all

# Uploader tool
# -------------------

tools.nucleoFlasher.path={runtime.hardware.path}/tools/nucleoFlasher
tools.nucleoFlasher.cmd.linux=nucleoFlasher
tools.nucleoFlasher.cmd.windows=nucleoFlasher.bat
tools.nucleoFlasher.cmd.macosx=nucleoFlasherMacOsX


Second:
Upload fails, because of:
NODE_F103RB not found. Please ensure the device is correctly connected


I installed the latest ST-Link 2.1 driver, updated the firmware, nothing helped. I should wait a while before doing beta testings :)

Edit:
Got it: Just in line 8 of nucleoFlasher.bat change to

Code: Select all

   VOL %%I: 2>NUL | FIND "NUCLEO" >NUL && SET DEST=%%I:

this line didn't work:

Code: Select all

VOL %%I: 2>NUL | FIND "%TARGET%" >NUL && SET DEST=%%I:


Edit2: "Blink" and "AnalogSerial" are working out of the box.

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

Re: STM have developed a HAL MX core

Postby RogerClark » Thu Sep 15, 2016 10:44 pm

I just compared a blink sketch file size (and ram use)

HAL core

Code: Select all

Sketch uses 11,936 bytes (9%) of program storage space. Maximum is 131,071 bytes.
Global variables use 5,888 bytes (28%) of dynamic memory, leaving 14,591 bytes for local variables. Maximum is 20,479 bytes.


LibMaple (Selected F103RB which only has STLink upload)

Code: Select all

Sketch uses 7,260 bytes (6%) of program storage space. Maximum is 108,000 bytes.
Global variables use 1,968 bytes of dynamic memory.


So RAM usage is significantly more with the HAL Core (same for the Flash usage)

I don't have @sheepdoll's / vassilis's HAL MX core installed at the moment to compare its footprint, but I recall it did take more resources than LibMaple

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

Re: STM have developed a HAL MX core

Postby RogerClark » Thu Sep 15, 2016 11:10 pm

:lol:

I just realised that the online help link in the json file (Boards manager) is to this forum

I guess I should probably create a separate section so that it can link directly to that section


Return to “Builds and Announcements”

Who is online

Users browsing this forum: No registered users and 2 guests