news: Arduino STAR OTTO development board

Any other STM32 based boards
User avatar
RogerClark
Posts: 6118
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: news: Arduino STAR OTTO development board

Post by RogerClark » Fri Jun 17, 2016 3:57 am

GrumpyOldPizza wrote: F4 and L4 are not that different. Only DMA and I2C come to mind as biggies..
Well, Arduino.org may be in touch ;-), but I suspect that its a ST approved project, they'll probably want to use the Cube :-(

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

Re: news: Arduino STAR OTTO development board

Post by sheepdoll » Fri Jun 17, 2016 6:37 am

I made some comments to the article "STMicroelectronics Seeks Revival" on EETimes under the heading "ST has potential, will they listen?"
The subhead "Giant seen as 'adrift' and 'a survivor'" is also an interesting way of looking at things.

Like the AVR forums, there was some negativity regarding Cube. Equating it to a two year train wreck. The same commenter was also not too kind when they wrote "The Maple board design was disappointing..."

I am not direct linking this as I am not sure how long EETimes morgues the articles. This used to be a print magazine that went totally digital. So the articles are a bit topical and ephemeral. So dear reader, you will have to use your favorite search engine to pull up the above titles.

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

Re: news: Arduino STAR OTTO development board

Post by RogerClark » Fri Jun 17, 2016 8:06 am

Thanks Julie

I found it by googling "STMicroelectronics Seeks Revival", albeit, I seemed to go straight to the comments page, and had to click to get back to the initial article.

I don't have much experience of using the Cube, but at the moment the jury is out for me, because I've had a number of problems with it, including

* Projects that were updated, seem to have files missing and would no longer compile.
* Corresponding files for different MCU series, seem to have different level's of bug fixes and enhancements applied to them (case in point was the F3 was missing a guard #ifdef around the Vector offset, but the same file for the F0 had the guard code.
* Plus a few more minor problems that I can't recall at the moment.

I get the feeling that they don't spend a lot of time supporting the cube, and consequently each MCU series series doesn't get the same bug fixes and enhancements.

I suppose ST's goal was not to write a tool that would generate code so that users could upgrade from one processor series to another (which is what we need to build a unified "core")


Also, I tend to agree with @clive1's posting in to the story. I don't know if the upper levels of STM understand Open Source.
Case in point is the code license on their CMSIS etc, prior to the Cube.
I cant see how it benefited them, to have a non-redistribution clause on their code, apart from stopping people using it in any publicly available project (hence any Open Source project), and hence limiting their visibility in the market place

Its not was if you had to sign a NDA etc to get the Standard Peripheral Library, it was freely downloadable.


Speaking to the reps at Maker Faire, they told me that ST was not just interested in mass / commercial market, but I find it hard to reconcile their actions.

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

Re: news: Arduino STAR OTTO development board

Post by GrumpyOldPizza » Fri Jun 17, 2016 12:38 pm

RogerClark wrote:Thanks Julie

I found it by googling "STMicroelectronics Seeks Revival", albeit, I seemed to go straight to the comments page, and had to click to get back to the initial article.

I don't have much experience of using the Cube, but at the moment the jury is out for me, because I've had a number of problems with it, including

* Projects that were updated, seem to have files missing and would no longer compile.
* Corresponding files for different MCU series, seem to have different level's of bug fixes and enhancements applied to them (case in point was the F3 was missing a guard #ifdef around the Vector offset, but the same file for the F0 had the guard code.
* Plus a few more minor problems that I can't recall at the moment.

I get the feeling that they don't spend a lot of time supporting the cube, and consequently each MCU series series doesn't get the same bug fixes and enhancements.

I suppose ST's goal was not to write a tool that would generate code so that users could upgrade from one processor series to another (which is what we need to build a unified "core")
Don't really wan't to say bad things about the CubeXX stuff. I use it a lot for quick and dirty prototyping, and then rewriting from scratch after I figured out the nuts and bolts. My experience in general has been that simple things work, and complex ones fall apart (CRC16 on SPI above 10MHz SPI clock for example). That points to a lack of testing, but to give them credit it's tricky to do. Overall I found the HAL too restrictive with certain design decisions, and to invasive (I want my code drive the look and feel of the project and don't want to be slave to an infrastructure that might not be well suited).

The reason why the STM32L4 core does not use the HAL (except for the USB part) comes really down to a bad fit for the problem. To do low power you need to do certain things that either require a good RTOS locking strategy, or use a non-locking atomic primitive based scheme (clock gating and such). The HAL cannot do that, It's correct that one could patch the HAL into submission, but who is maintaining that then ? For implementing an Arduino core it's just a bad fit. The I2C code for example has no "sendStop" parameter, which led even ST to implement code outside the HAL for MBED (which has a similar problem). Guess the maintainers of the HALMX core ran into similar issues.

But what other solution is out there other than either a homegrown system backend or the ST HAL ?

libmaple ? Not a good fit, because it uses it's own CMSIS header replacement. That's a maintainance nightmare going forward for new hardware.

libopencm3 ? They also try to reinvent the wheel there with implementing CMSIS ...

mbed ? Would have a good underlying own hal, but the more interesting things are not supported by the ST implementation


So it's a quandary where to start. I agree there that ST (or arduino.org) will not pick up the STM32L4 core just for the reason that it did not use the ST HAL.

Ollie
Posts: 169
Joined: Thu Feb 25, 2016 7:27 pm

Re: news: Arduino STAR OTTO development board

Post by Ollie » Fri Jun 17, 2016 3:34 pm

Perhaps, it is a time for Linux moment. That means that all the true believers will create a lean and orthogonal library directly on top of STM32 register sets. This can be done even without using SPL.

I have seen so much bloatware in MBED, CMSIS, CubeMx, and even in SPL that it has been disgusting. The libraries that Paul has created for Teensy are an example of more professional design.

Cheers, Ollie

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

Re: news: Arduino STAR OTTO development board

Post by RogerClark » Fri Jun 17, 2016 9:51 pm

Sounds like the HAL may be the least bad of the available options, based on the features Arduino users probably want.

* Specifically, support for MCU specific peripherals across the wide variety of STM32Fx series MCUs

* Free bug fixes of the HAL etc, when STM releases updates.

* Ability to use STM example code and libraries ( ones that use the HAL )

* Ability to reuse other open source code that uses the SPL, albeit this requires porting to the HAL.


@ollie.
IMHO, Unfortunately, the user base is simply not big enough to support the development of a cleanroom API.
Also, in some respects libmaple can be viewed as a cleanroom API, but a common complaint is that either it doesn't support a particular processor variant, or specific built in hardware, or allow use of STM examples , that use the SPL or HAL.

People are time poor, which limits their ability to contribute, and consequently the changes to the libmaple core are normally limited to bug fixes, rather than support for built in peripherals like CAN and SDIO, or modifying libmaple to work with other processor variants e.g. F0

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

Re: news: Arduino STAR OTTO development board

Post by RogerClark » Sun Jun 19, 2016 7:58 am

I had another look at the Core that is in github, (for the STAR OTTO), and it does use the HAL after all (for some things)

I'm not sure why the core seemed to compile when I removed the HAL, but when I looked again, its definitely needed.

What Francesco has done, is to use use both libmaple and the HAL at the same time.

The HAL seems to be use for features which are not supported by the F4 version of LibMaple.

Specifically Hardware SPI and also Hardware I2c (Wire)

SPI and Wire are not done as separate libraries, but have been put inside the core. (I'm not sure why this is)


Of course the drawback of using both libmaple and the HAL is it appears to double the code size (for a blank sketch), and increase the amount of RAM used

e.g.

STAR OTTO

Code: Select all

Sketch uses 27,180 bytes (1%) of program storage space. Maximum is 2,097,152 bytes.
Global variables use 14,680 bytes of dynamic memory.

Libmaple - Discovery F407 - Blank

Code: Select all

Sketch uses 15,116 bytes (1%) of program storage space. Maximum is 1,048,576 bytes.
Global variables use 13,504 bytes of dynamic memory.
Libmaple - Maple mini - blank

Code: Select all

Sketch uses 11,300 bytes (10%) of program storage space. Maximum is 110,592 bytes.
Global variables use 2,560 bytes of dynamic memory.

User avatar
leavesw
Posts: 20
Joined: Fri Jun 24, 2016 2:25 am

Re: news: Arduino STAR OTTO development board

Post by leavesw » Fri Jun 24, 2016 2:32 am

It took me a while to find this thread - and enjoy your discussion here.

I have asked engineers at STM in one of their recent webinars about Arduino library support and I am under the impression that they are not behind the scene doing the work for that board.
With nucleo, they just have the board and claim the pin compatibility, and there is definitely no desire to provide library for it.
As for licensing issues with Cube code, HAL drivers are under BSD license and the source is redistributable.
But any vendor peripheral libraries sucks - because they do not take application into consideration and they do not push the codes to limit and fixing the bugs.
So, personally, I believe it should always be good to come up with your own peripheral libraries for your specific application ^.^

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

Re: news: Arduino STAR OTTO development board

Post by RogerClark » Fri Jun 24, 2016 3:04 am

@leavesw

Welcome...

From what I understand, Arduino.org are doing all the S/W dev, by taking the libmaple core and using the HAL to add peripheral support for the MCU they are using. In my email conversions with STM, they (STM) didn't seem to be devoting any resources to doing Arduino "core" development.

I know other people have asked about Arduino support why at STM32F7 seminars, and have been met with blank faces.

The STM guys at the Bay Area Maker Faire, were much more in turn to this market, but I think they are the exception to the rule.

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

Re: news: Arduino STAR OTTO development board

Post by Slammer » Fri Jun 24, 2016 10:58 am

leavesw wrote: But any vendor peripheral libraries sucks - because they do not take application into consideration and they do not push the codes to limit and fixing the bugs.
This is true...
As I learn more about HalMX, I dislike more this library..... and I do like more the libopencm3.....

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest