new cores on HALMX_Arduino_STM32

Development of new Cores using the STMCubeMX and HAL
User avatar
sheepdoll
Posts: 232
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

new cores on HALMX_Arduino_STM32

Post by sheepdoll » Sun Aug 16, 2015 9:17 pm

I made some revisions to https://github.com/sheepdoll/HALMX_Arduino_STM32 to add support for F0 Discovery and a start at frameworks for the F429I Discovery.

Also added some documentation relating to running STM32CubeMX on OS X and guidelines for setting up new CubeMX projects.

This distribution also includes a few example sketches collected from some of the threads here on http://stm32duino.com.

Currently the generic blink sketch has been tested with the Nucleo F1, Nucleo F4, and the F0 Discovery.

Serial stream writes seem to work on the Nucleo F1 and Nucleo F4 through the CDC device on the STLink-V2.1

The F0 board requires a bridge to a serial monitor as the STLinkV2 does not enumerate as a CDC device. The datasheet DM00050135.pdf which relates to the F0 board has suggested Arduino mapping. While outside the cores normally discussed here on Arduino for STM32 the advantage of using HAL and a common low level API.

An added bonus on the Nucleo F1 is the F1SerialStats sketch which was posted here some time ago. This shows the ram size and a unique Id when run on the Nucleo F1. On the Nucleo F4 it just returns 0xFF values. Not sure where these pointer values come from. There is a lot of docs to read just to get this far.

The real power of using the HAL low level access is that the API can be called directly inside the sketch. Several examples are in this distribution. By using CubeMx to configure the peripherals, these are enabled and ready to access as soon as the Arduino setup() and loop () callbacks are activated.

Even though this branch is in early stages. I wanted to share the work with others. There is a lot still needed to get most of the basic example sketches to work. Many AVR sketches and libraries take advantage of direct hardware access. With this system it is better to let the CubeMx tool do the gruntwork.

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

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Mon Aug 17, 2015 5:42 am

Thanks for the update.

I'm sure your core will be invaluable as we move forward.

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

Re: new cores on HALMX_Arduino_STM32

Post by madias » Mon Aug 24, 2015 8:40 pm

thank you sheepdoll, you brought the the whole project into a new perspective (at least for me).

I've played with the mcu/board Configurator and it's really easy and fast to get an exactly setup for all the special needs.
As a side project I tried to get I2S working with the F1 series - without luck, because there is not even a skeleton in the libmaple api for this.
Furthermore there are a lot of up to date bugfixes inside the HAL drivers (i2c,spi...) so remember: The libmaple is about 3 years old and no one of the original developer is programming one line of code anymore.
So my hard verdict, especially for F103RC and up and every F2-F7: libmaple is dead and every further development is a waste of resources.

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

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Mon Aug 24, 2015 9:44 pm

Matthias,

I have raised the issue about what core we should be using, on several occasions, but no one seemed interested in trying to write a new core until @sheepdoll got involved,

I did look at Koduino and MakerLabMe ( see my other postings), but neither of them were particularly usable as a whole, for different reasons.

I think Koduino has some libs, which could probably be pulled over and converted to @sheepdoll's core.

And moving to a new core probably something that the community, needs to actively work on.
Unfortunately I'm really busy with work at the moment, on 3 or 4 simultaneous projects, and I dont have time to do much but maintenance on the current cores ;-(

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

Re: new cores on HALMX_Arduino_STM32

Post by madias » Tue Aug 25, 2015 7:38 pm

I know, I know... the main thing is that things for us are totally changed: At the beginning we played around with maple mini clones, real maples, nucleo (my baby) not thinking about that even the F1 line is much more powerful as we imagined those days :) Now every week a new cool board appears for even more less bucks on several platforms making it nearly impossible to create for each one a new "variant".
And for sure switching to a new core *must* be a community project but it will be necessary in the future to get all those STM32Fx under a hood. ST is going into the right direction with the licenses, so we should follow them....
...and BTW: the STM32cubeMX IOconfigurator is really a fancy tool :)

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

Re: new cores on HALMX_Arduino_STM32

Post by zmemw16 » Wed Aug 26, 2015 9:48 am

a couple of questions:-)

just how is the Cube generated code used?
to produce a skeleton for a variant or does it usage go further than that?
could the F4 code be back-ported to F1?
F1<==> F4 hardware, usart/adc/pin/spi/i2c/dac; is the F1 SPI different in some way from a F4 SPI ?
different in some way other than the physical pins & addresses?
do ports have 'same' set of register and usage mechanisms?

as the base generating mechanism is currently 'Cube',
can we replicate that functionality with open source?
should we?
to what extent?

alas one possibility is being locked into Cube, apologies for my u$ syndrome.
i'm primarily 103 based(TOTT) as i suspect the majority might be
with a couple of (x)nucleo's and a 429 discovery (lcd one) on way.

stephen

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

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Wed Aug 26, 2015 11:18 am

The files that the cube generated is basically open source, in that it's license allows for redistribution etc.

Prior to the Cube, STM's source code files for the F103 etc had a license which prevented re-distribution, hence why Leaflabs has to write their own core from scratch in order to keep it open source.

The one drawback with the with the Cube is that its a proprietary piece of software, and I'm not sure it runs on all OS's

Actually, when I said the Cube generates re-usable code, this isn't 100% true. The linker script files seem to have license issues, however I suspect this was an omission by STM i.e I doubt they intended to use non-redistributable linker files.

So for any core that is generated by the Cube to be effectively free of license constraints, the linker files need to be rewritten.

I found a replacement linker file for the F103 but have not found one to replace the F4 linker file.
So some clever person would need to write a new one for the F4.

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

Re: new cores on HALMX_Arduino_STM32

Post by Rick Kimball » Wed Aug 26, 2015 2:23 pm

RogerClark wrote:Actually, when I said the Cube generates re-usable code, this isn't 100% true. The linker script files seem to have license issues, however I suspect this was an omission by STM i.e I doubt they intended to use non-redistributable linker files.
I had the same questions Roger, so I made a post on a the ST forums, weeks went by and no one answered. At that point, I submitted a trouble request on the ST support page. Here is the question and the response I got from ST support. Bottom line, they have no intentions of releasing an unhindered linker script even for their OpenSTM32. In my view their thinking is flawed, the linker script is something that is going to look the same on any configuration that is using the linaro arm-none-eabi-gcc. This is one of the main reasons I've backed off from using stm32 stuff and you see me posting less here. I thought ST was moving in the right direction with regards to opensource, but I now see they have no clue what open source is all about. They force you to register to download the IDE/compiler and then created bizarre legal text on stuff that should be open while claiming the HAL stuff is open source friendly.

See below:
Rick Kimball / STM support wrote:Description: I'm trying to decide if I want to use the STM32CUBE HAL code in my open source projects. Because I'm on linux, stm32cubemx doesn't run well, so I used the windows version and generated some code to use with openstm32 ( which also doesn't run well with linux ). I ignored all the openstm32 projects it created and just created a new C project in standard eclipse. I setup all the include paths, symbols and compiler settings by hand.

I was feeling happy that I got it going without too much trouble and then I noticed this header in the linker script:

/*
*****************************************************************************
**
** File : LinkerScript.ld
**
** Abstract : Linker script for STM32F103C8Tx Device with
** 64KByte FLASH, 20KByte RAM
**
** Set heap size, stack size and stack location according
** to application requirements.
**
** Set memory bank area and size if external memory is used.
**
** Target : STMicroelectronics STM32
**
**
** Distribution: The file is distributed as is, without any warranty
** of any kind.
**
** (c)Copyright Ac6.
** You may use this file as-is or modify it according to the needs of your
** project. Distribution of this file (unmodified or modified) is not
** permitted. Ac6 permit registered System Workbench for MCU users the
** rights to distribute the assembled, compiled & linked contents of this
** file as part of an application binary file, provided that it is built
** using the System Workbench for MCU toolchain.
**
*****************************************************************************

Questions I have:

1.) Is this intentional or just an overly cautious template in the cubemx code generator?

2.) Are their other legal landmines lurking in the generated code that I should be aware of if my intent is to use this with open source code projects?

-rick


Resolution Summary: SOLUTION PROPOSED BY SUPPORTER - 13/7/2015 19:45:06 :
Hello Rick,

The Cube HAL and other CubeMX generated code is distributed under a BSD-like license and you should be fine using these files in open source projects.

In terms of the linker file, it is specific to SW4STM by AC6 software. It may or may not work within your own development environment. However, you should be able to find an equivalent linker file for your specific compiler, with its own licensing statement which may be more suitable.

Best regards,
ST MCU Tech Support

More Info:
I think I'll just use opensource stuff with Texas Instruments CCS and not have to play games with stupid legal crap.

-rick
-rick

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

Re: new cores on HALMX_Arduino_STM32

Post by zmemw16 » Wed Aug 26, 2015 3:15 pm

the java used is jre1.8.0_51 and as mentioned in the HALMX docs
java -jar SetupSTM32CubeMX-4.9.0.exe

installs under Debian 8, wants root though.

java -jar STM32CubeMX.exe from the right place seems to run happily

do i need to install the STM32Cube_FW_F1_V1.2.0 & STM32Cube_FW_F4_V1.7.0
directories somewhere or are they already embedded / installed?

my world turned red pill in the post, long 6-7 weeks
seems to be better silk screen printing than the blue & the baite, overhangs a bit on
each side as a result
no sign of the OLS as yet

stephen

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

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Wed Aug 26, 2015 8:53 pm

Rick

I agree that STMs strategy in relation to open source and their licenses in general seems somewhat confused.
I posted to their support forum, about the license on the old standard peripheral lib, over 6 months ago, but didn't get a response either.

But...

i don't find TI etc much better when it comes to open source.

I'm working on some BLE stuff at the moment and TI's BLE stack is closed source and they don't support any open source compilers on their cc254x series BLE devices :-(
Which basically rules these devices out for any non large scale commercial development, as only companies with $$$$ to spend on the IAR compiler can effectively use these devices.

Likewise the new STM32F411 based wifi device, EMW3165, uses Broadcom Wifi SDK (WICED) which you have to register to download.

AFIK, The core lib on the ESP8266 is not open either; though there is no need to register to download it.

The GD32F103 docs require registration just to download them

etc
etc

Although I am not capable of rewriting the linker script at the moment, as i have no experience in this area; I think that this is a lesser hurdle than most other embedded stuff I've seen recently.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest