STM have developed a HAL MX core

Information on the latest releases
fpiSTM
Posts: 22
Joined: Fri Sep 16, 2016 12:33 pm
Location: Le Mans, France

Re: STM have developed a HAL MX core

Postby fpiSTM » Fri Sep 16, 2016 1:04 pm

Hi,

Nice to see this announcement and "release" create as much of comments :)

I would like thanks a lot Roger for his involvement and his feedback.

For you interest, we will deploy soon some other family:
- STM32F091RC-Nucleo
- STM32F303RE-Nucleo
- STM32F429ZI-Nucleo
- STM32L053R8-Nucleo

Roger, we will deliver them as one single repo for each family (Arduino_Core_STM32XX), as suggest. Maybe directly on stm32duino.

Tried to answer some questions:
GrumpyOldPizza wrote: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/)

Indeed, wi6labs do the porting with ST support but it do not own the code. Code could be used or modified freely as explicitly wrote at the top of each file.

RogerClark wrote::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


Yes, hope I do not a mistake. It sounds good to create a dedicated section. This will be more easy to follow the support.

As already told to Roger by mail, I will probably be out of office during 2 weeks soon. My wife is pregnant and should give birth to my 2nd son soon.
So if I do not answer, don't worry ;)

Fred

Freakeyyy
Posts: 5
Joined: Sat Sep 10, 2016 8:42 pm

Re: STM have developed a HAL MX core

Postby Freakeyyy » Fri Sep 16, 2016 1:39 pm

fpiSTM wrote:As already told to Roger by mail, I will probably be out of office during 2 weeks soon. My wife is pregnant and should give birth to my 2nd son soon.
So if I do not answer, don't worry ;)


First of all congratulations man :D

I wanted to ask you if you were planning on providing some of the missing USB device capability like HID, just like the arduino leonardo or Due does ?

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 » Fri Sep 16, 2016 2:03 pm

Freakeyyy wrote:
fpiSTM wrote:As already told to Roger by mail, I will probably be out of office during 2 weeks soon. My wife is pregnant and should give birth to my 2nd son soon.
So if I do not answer, don't worry ;)


First of all congratulations man :D

I wanted to ask you if you were planning on providing some of the missing USB device capability like HID, just like the arduino leonardo or Due does ?


Nucleo board do not have USB accessible. They have a UART passthrou to the ST-Link dongle chip on the board, which deals with the debugging aspect and the USB/MSC flashing service.

User avatar
zoomx
Posts: 366
Joined: Mon Apr 27, 2015 2:28 pm
Location: Mt.Etna, Italy

Re: STM have developed a HAL MX core

Postby zoomx » Fri Sep 16, 2016 4:17 pm

fpiSTM wrote:As already told to Roger by mail, I will probably be out of office during 2 weeks soon. My wife is pregnant and should give birth to my 2nd son soon.
So if I do not answer, don't worry ;)

Fred


congratulations !!!!!

I have some questions but I will wait!!

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 » Fri Sep 16, 2016 5:38 pm

A few items for discussion:

1.) This line looks funny, it is an odd address and it isn't at the top of ram, shouldn't it be 0x5000 ?

https://github.com/stm32duino/Arduino_C ... ASH.ld#L49

2.) If you are using STLINK and want to do some debugging, you probably want to comment out this line:

https://github.com/stm32duino/Arduino_C ... fig.c#L151

3.) Porting to other variant boards seems like we will need to either create multiple libs or provide a way to use different clocks. The Nucleo F103 is using the HSI instead of the HSE and that is baked into the libxxx.a file you link with. Seems like the clock setting might best be done in the variant directory.

-rick
-rick

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

Re: STM have developed a HAL MX core

Postby sheepdoll » Fri Sep 16, 2016 5:46 pm

Wow. Thanks fpiSTM.

I am still working on some automation scripts written in postscript(Ghostscript) that can read the *.ioc file generated by STM32CubeMX and generate some of the code directly such as the pin description global g_APinDescription[] in variant.cpp for new boards. I have been working with the STM32F74G-Discovery board which has a lot of options choices.

Pre compiling the library into a *.a archive is something I had considered. I was not sure if this was against the Arduino methodology. In theory this should allow the gcc linker to optimize a lot of the dead code. Which is the point in high level systems of dynamically linking libraries.

The real trick is how to configure a git tree so that each variant it it's own repository. At present the way I have to do this is to stage the whole project and manually move the changes to private build trees outside the IDE paths.


-julie (Sheepdoll)

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 » Fri Sep 16, 2016 8:55 pm

Julie

Re:variants as separate repos

Each variant would could be a git submodule. However this has been a problem with the libmaple reoo, as if download the repo as a zip, the submodules come in as empty directories.

However if the primary delivery method will be the Boards Manager, I think this is something we could live with, as anyone wanting to compile from sources would need to clone the git repo to their machine and then also run the commands to get all the submodules.

Perhaps I better make this change today, so we have a good structure from the start

Re:variants as compiled libs

AFIK Arduino.cc do use libs for platform specific code, but perhaps not down to variant level.

However I dont think there is a reason why we cant do this.

I didnt get chance to try it last night, but I will try uninstalling the boards manager package and manually copy the repos into my hardware folder, to see if it is possible use the source files directly in the IDE.

BTW.

i also started refactor the tools, as all OSs were in the same single folder and in the longer term the each OS can have its own separate tools as part of the boards manager package download. ( this will hopefully help Linux 32 vs Linux 64 as well)

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 » Fri Sep 16, 2016 9:24 pm

Rick Kimball wrote:A few items for discussion:

1.) This line looks funny, it is an odd address and it isn't at the top of ram, shouldn't it be 0x5000 ?

https://github.com/stm32duino/Arduino_C ... ASH.ld#L49

2.) If you are using STLINK and want to do some debugging, you probably want to comment out this line:

https://github.com/stm32duino/Arduino_C ... fig.c#L151

3.) Porting to other variant boards seems like we will need to either create multiple libs or provide a way to use different clocks. The Nucleo F103 is using the HSI instead of the HSE and that is baked into the libxxx.a file you link with. Seems like the clock setting might best be done in the variant directory.

-rick


Umm. I presume that stack address works because its less than 0x5000 but it seems to be an odd location for the stack and probably causes loss of ram space due to fragmentation


Re:Different code per variant lib.

Oddly the way the Nucleo uses HSI, seems out of step with virtually all other boards.
I guess it was a minor cost saving, and they dont need a stable clock as the board does not connect to USB.

However I think with this core, like Julie's HAL based core, each variant is going to need to have a lot if unique files.


Probably the next step is to try to create a BluePill variant, and see what problems are encountered.



Note. We will need to wait for confirmation from STM, but my understanding was that they will just produce cores for some Nucleo boards, and if we want other variants, its up to the community to do that.

However it would be good if STM could create variants for the Discovery range as well, and ideally do all of their boards ( but I don't think Laurent's team they have the remit to do very much more)

Perhaps if there is a lot of buzz and interest in the wider Arduino community, it may however change their mind.

User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: STM have developed a HAL MX core

Postby Slammer » Fri Sep 16, 2016 9:37 pm

The Nucleo F103RB board uses 8MHz HSE EXT (External Input Clock) generated from the other MCU on board. It is possible to change a bit the clock initialization function to use both HSE sources, eg. to try first with HSE_EXT and if this fails to try again with HSE_XTAL, with this trick the same code will work in Nucleo and other F103 boards with external crystals.
The Nucleo L476RG is different story. The HSE_EXT connection is disconnected on the board, the MCU uses the new internal clock MSI (it is like HSI but much more stable and accurate) at 4 MHz.
Last edited by Slammer on Fri Sep 16, 2016 9:39 pm, edited 1 time in total.

zmemw16
Posts: 1066
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: STM have developed a HAL MX core

Postby zmemw16 » Fri Sep 16, 2016 9:38 pm

the command line for me to clone the libopencm3-examples is

Code: Select all

git clone --recursive https://github.com/libopencm3/libopencm3-examples.git

this pulls the sub module of libopencm3

as an aside the F1 Wire examples seems to have slave receiver and slave sender code, at least directories, content may vary

stephen


Return to “Builds and Announcements”

Who is online

Users browsing this forum: No registered users and 1 guest