new cores on HALMX_Arduino_STM32

Development of new Cores using the STMCubeMX and HAL
madias
Posts: 813
Joined: Mon Apr 27, 2015 11:26 am
Location: Vienna, Austria

Re: new cores on HALMX_Arduino_STM32

Post by madias » Wed Aug 26, 2015 9:12 pm

hm, Rick: You got an answer on 8/11/15:
Hi Rickta59,

This issue is fixed with current SW4STM32 version available in AC6 site.
Code generated by CubeMX as well as the examples available in the STM32CubeXX packages will not contain such restriction sentence in coming versions.

-Mayla-
https://my.st.com/public/STe2ecommuniti ... tviews=191

Sounds ok for me - or? (But we have to wait IF/WHEN it will happen ;) )

User avatar
mrburnette
Posts: 1803
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: new cores on HALMX_Arduino_STM32

Post by mrburnette » Wed Aug 26, 2015 11:51 pm

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

Many of us members probably have some apprehension as we realize that building a core using vendor tools for low-level functionality is a 2-edged sword:
1) We benefit from the expertise of the company that designed the chip and wrote the reference manual,
2) We find ourselves beholding to the chip company for backward compatibility across a product line: understanding/accepting that retired products can seriously disrubt supportability under the Arduino umbrella.

Just to remind myself and other readers, this forum is titled: STM32duino.com and I personally have some concerns that HAL/MX is both yin & yang. The Arduino layers of core, libraries, and user-code could easily break with the next+best version of the HAL/MX strategy. But, the STM32Fxxx product line is complex and manual core development is slow and error prone - we are not in the simple 8-bit world here. Knowing this, we still have to provide guarantees to library developers that this essential and often unappreciated work will not be disrupted by STM (in this specific case.) This could be an interesting balancing act.

If we are not careful, we may find ourselves beholding to STM just as some of us are beholding to Microsoft in the workstation OS space with XP unsupported, Win Vista no longer mainstream, Windows 7 no longer mainstream, ... you can see a pattern, surely.

Opinion by Ray

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

Re: new cores on HALMX_Arduino_STM32

Post by stevech » Thu Aug 27, 2015 6:47 am

I may be able to help some with the use of CubeMX + HAL and its target tool chains.
IAR (and Keil) are best of breed but free only up to 32KB of code.

Lots of experience with it and F4's and IAR. I see that CubexMX now targets more compilers.

Arduino - for AVR and Teensy3. Time to move on. ST gives us HAL (or the depreciated Std. Periph. Libs) which is a big superset of what ARM M0/M4 people are trying to reinvent from regurgitated Arduino 8 bit stuff.

User avatar
mrburnette
Posts: 1803
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: new cores on HALMX_Arduino_STM32

Post by mrburnette » Thu Aug 27, 2015 1:11 pm

stevech wrote:I may be able to help some with the use of CubeMX + HAL and its target tool chains.
<...>
Arduino - for AVR and Teensy3. Time to move on. ST gives us HAL (or the depreciated Std. Periph. Libs) which is a big superset of what ARM M0/M4 people are trying to reinvent from regurgitated Arduino 8 bit stuff.

Sheepdoll has been active in this space, too (Rick Kimball had more than a passing interest but may be in the TI arena too deep att.) I quite agree that for most of us who migrated here from Arduino.cc that 8-bit is of a declining interest in a forward-looking play space. However, 8-bit certainly has some good uses in low-end and low-power computing and it is well-supported and understood.

If a serious effort is desired, then formalizing a small paper on the goals and approaches would be a likely first step (I'm a retired computer architect in the Enterprise space and had responsibilities for vendor liaison activities with $1M+/annual spend companies.) Sheepdoll has already shown it is possible in her proof-of-concepts. If the questions of Open Source are answered in the next CubeMX release, then this seems to be a home-free approach.

However, I see no reason that goals, approaches, and issues could not be started with the assumption (based on the eMail I read here from STM) that the linker scripts will be Open Source and redistributable, too.

So, Roger stated that a decision to move in this direction needs to be a forum decision; therefore, I defer to Roger on how he wants to vote on this subject... perhaps the forum has a voting engine. After that, the working members need to meet formally online (we have IRC: http://www.stm32duino.com/viewtopic.php?t=50#p214) and then do some housework and agree on roles, approaches, etc.

Roger - ball is in your court.


Ray

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

Re: new cores on HALMX_Arduino_STM32

Post by zmemw16 » Thu Aug 27, 2015 2:22 pm

oh i wish i'd replied last night!

is it a question of how much arduino-i-ness needs to be retained?
is it worth proceeding at risk?

i can see a declining 'arduino' set, the switching from 328p in an uno to a stm32 didn't work
for the maple(ok, prob it wasn't just that), i was never tempted or thought about switching except
maybe to a mega. (following the brand maybe)
then again i'm used to linux and new hardware, wait a bit and it'll start working:-)

for me, i'd proceed at risk, next question is
can it be done in such a way that even if ST back tracked it wouldn't create a problem?
stephen

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

Re: new cores on HALMX_Arduino_STM32

Post by Rick Kimball » Thu Aug 27, 2015 3:25 pm

madias wrote:hm, Rick: You got an answer on 8/11/15:
Sounds ok for me - or? (But we have to wait IF/WHEN it will happen ;) )
Very interesting, I hadn't been back to the forum site since I got a response from my support trouble report. I just checked out the latest eclipse jar files and compared the june version to the july one and they do seemed to have changed the legal statement. Here is a diff:
$ diff STM32F103X6_FLASH.ld ../../../../../resources/builtin/linker/stm32f1/
21,27c21,45
< ** (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.
---
> *****************************************************************************
> **
> ** <h2><center>&copy; COPYRIGHT(c) 2014 Ac6</center></h2>
> **
> ** Redistribution and use in source and binary forms, with or without modification,
> ** are permitted provided that the following conditions are met:
> ** 1. Redistributions of source code must retain the above copyright notice,
> ** this list of conditions and the following disclaimer.
> ** 2. Redistributions in binary form must reproduce the above copyright notice,
> ** this list of conditions and the following disclaimer in the documentation
> ** and/or other materials provided with the distribution.
> ** 3. Neither the name of Ac6 nor the names of its contributors
> ** may be used to endorse or promote products derived from this software
> ** without specific prior written permission.
> **
> ** THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\"
> ** AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> ** IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> ** DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
> ** FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> ** DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> ** SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> ** CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
> ** OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> ** OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
I guess I should have checked back, but I thought I had heard the final word.

Thanks,

-rick
Last edited by Rick Kimball on Thu Aug 27, 2015 6:37 pm, edited 1 time in total.
-rick

User avatar
mrburnette
Posts: 1803
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: new cores on HALMX_Arduino_STM32

Post by mrburnette » Thu Aug 27, 2015 5:58 pm

zmemw16 wrote:<...>
is it a question of how much arduino-i-ness needs to be retained?
is it worth proceeding at risk?
<...>
can it be done in such a way that even if ST back tracked it wouldn't create a problem?
stephen
Well, I think if Roger sets up a working group, then that would be their choice to make a recommendation which would be voted upon (I assume) although maybe the rank 'n file members just defer the decision making for F2 - F4 (maybe the F1, too) to a committee that oversees the working group - maybe one in the same. I think messing around with F1 is OK if the current core is maintained until the time of cut-over if that is the way to go.

I do not have a preference, it is about time for me to bounce from the ESP8266 as I work up my last post @ https://www.hackster.io/rayburne for the WiFi chip and then I think I am going to bridging what has happened in the last year to the PSoC world. So, nothing going on in the STM32 world will affect me at the moment ... likely it will all be finished by the time I swing back into things... I have 20 of the Maple Mini boards and most of the major STM32 core releases from the past 6 months. Right now, I am using a nightly version of Arduino 1.6.6 and it is working great.

Ray

User avatar
mrburnette
Posts: 1803
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: new cores on HALMX_Arduino_STM32

Post by mrburnette » Thu Aug 27, 2015 6:10 pm

Rick Kimball wrote:<...>

I guess I should have checked back, but I thought I had heard the final word.

Thanks,

-rick
:lol:
I think "final word" is an oxymoron unless the speaker has ceased to breath and the death certificate issued... then, maybe (unless a lawyer is involved) then maybe the final word can be written.

Ray

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

Re: new cores on HALMX_Arduino_STM32

Post by zmemw16 » Fri Aug 28, 2015 9:05 am

ok this is probably way too early, but

is there a way to leverage what has been learnt in 'getting F103 to functionality' in the move to HAL?

currently is it rather simplistically from clicking on 'compile&link' :-
'arduino' => generate code for each device/variable, setup and loop => compile & link against the std lib's & 'our wrapper/version of 'libmaple' => hex

is our wrapper/version of libMaple wrapper the current 'HAL'?
where does 'CubeMX/CubeFX' fit in?
can't see it being 'called' on switching device to generate boiler plate as required?
is it to be used outside of 'compile&link'' to generate boiler plate source ( maximum functionality for each stm32FXXX) to be inserted at the generate code stage, the linker will then simply ignore unused code?

is CubeMX in effect equivalent to <CubeF1xx+CubeF2xx+ ... +CubeFnxx>

stephen

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

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Fri Aug 28, 2015 10:13 am

Guys,

I'll try to compose a long answer to these complex points at the weekend.

But here are a few points to bear in mind in the meantime.

IMHO creating a full new core including the core libraries is non-trivial. Several other sites have tried it, with only limited success.
I'd recommend you read my postings on the 2 main alternative Arduino cores for STM32 (i.e MarkerLabMe and Koduino), and take a look to see if you think these are suitable for what you want to do.

Personally, I feel that moving away from Arduino / Wiring compatibility, is not a good idea, this includes compatibility with existing libraries where possible.
There are plenty of other IDE's and methods to compile code for the STM32 e.g. Eclipse, but beauty of Wiring is that people without a huge amount of programming skill can at least get something simple working, which may spur them on to greater things (not necessarily within the Arduino family)

Extending the Arduino / Wiring API e.g. to include some event driven stuff etc, would be useful as long as it doesn't break any existing Arduino core functionality. e.g. We have already extended the SPI API to include DMA, as this has no impact on any existing code e.g. libraries as these are new functions.

I personally don't have much spare time to help develop a whole new core, as I can guarantee you I will still get at least 20 questions a week either on this forum or github or directly emailed to me, which I'd be remiss if I didn't at least answer by referring people to the forum.
I suspect most people are in a similar position with also work and home life, competing for their precious time.

Post Reply