www.allpcb.com

Author Topic: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?  (Read 55551 times)

0 Members and 2 Guests are viewing this topic.

Offline v

  • Contributor
  • Posts: 7
tl;dr The STM32/Cube software ecosystem is the worst I have ever seen. Does anyone feel the same? How can we fix it?

Here is my war story...

PS. I am new to embedded dev coming fresh from web-frontend/backend/iOS. Feel free to point out obvious rookie mistakes!

3 weeks ago I was tasked with porting custom firmware (developed with the Standard Peripheral library - now replaced by the HAL/Cube) from an custom STM32F407 board, to a new custom board with the STM32F411CEU chip. The program simply dumped data from the IMU and GPS onto an SD card when a button was pressed.

Everything went *relatively* smoothly apart from the fact that the GPS unit on 2 separate devices was destroyed. You can imagine how difficult that was to work out, but hey - welcome to embedded dev! Our office whiteboard is now covered in ESD warnings and every morning when I get out of bed I put on my ESD band around my ankle - lesson #1 :).

Then I needed to pull the IMU data from the I2C2. Sounds simple, right?. I told my colleagues it would be less than a day of work. The I2C1 worked perfectly on a Nucleo board, but I2C2 did not work on either board. After a long process of debugging, probing, endless Googling, scouring forums I concluded that the I2C2 was broken. Lots of people had reported problems. I tried nearly everything, and each time I would try something I found that the darn BUSY_FLAG was set. The general sentiment seems to be that the I2C bus on STMFx series was very broken. I only recently heard about the infamous CPAL library, which seems to have been created because ST messed up so badly. But nowhere do they tell you. I came across the CPAL in a single Stack Overflow post where somewhere mentioned this library they had used long ago but could not remember the name. I had a [Wisdom of the Ancients](http://xkcd.com/979/) moment. This comic pretty much sums up my entire three weeks programming STM32. I found myself constantly wishing I could read German with so many Google journeys leading to [http://www.mikrocontroller.net/forum]. I even considered asking my friend's Polish girlfriend to translate a forum for me because I saw a couple of interesting keywords in English popping out of a search result snippet.

I then verified that the I2C2 worked with the new HAL drivers from the Cube in a blank project. With no way to fix it, no other pins available to use other I2C peripherals, I had to move to the HAL drivers. I initially tried to just replace the I2C with the HAL I2C. After many hours of fixing compile errors, it did not work. Same BUSY_FLAG problem. Then I tried replacing the entire Standard Peripheral folder of drivers, and everything else. This was an insane amount of work and I eventually had to give up. So many wacky configurations, etc.

So now I was staring down the barrel of an entire rewrite of a perfectly working, well-tested codebase (the code and drivers were battle-tested many times in industrial projects), all because of a single I2C bus not working. I thought - OK, the HAL drivers will have bug-fixes moving forward, have support for my MCU (STM32F411CEU, which is not supported by StdPeriph), this rewrite would probably have been neccessary anyway. And every page on the ST website prophesizing that "the Cube" is the way of the future and I should migrate.

I was quite excited about the prospects of the Cube. Supposedly it would let me configure all my pins, check conflicts, generate code for all my protocols (a checkbox for DMA - woohoo!), FreeRTOS, USB virtual com, etc. I budgeted three days to port the code.

Holy fuck was I wrong. I have never used such poor quality software in my life. Nothing works out of the box at all. The examples don't cover any of the actual ways you would use the drivers. A virtual com example only available for the STMF429 chip, and only as a USART to VCP bridge. FreeRTOS integration not even a 1/4 finished - but with no note to the user that it is not implemented. USART examples for polling, interrupt driven and dma, but only for a contrived example of sending messages back and forth between two boards. I must have tried all the examples and nothing worked. The generated code is messy with pin configurations strewn all over the place, starting your project off with nice spaghetti code before you write a single line.

I would be so much better off *without* the cube.

Every single perhiperal was a *huge* battle with so many little bug fixes, workarounds, and hacks to the Cube's generated code along the way. When I finally got the USART working, it was by removing a the enormous interrupt routine that the Cube had generated which was causing over-run errors.

When I look back on the codebase I now have, it feels like the aftermath of a warzone. So many bandaids, patches, configuration settings that *just* work. I have a code base which I do not dare to change a line without flashing to the device and checking everything still works.

Icing on the cake for ST is if you look at the back of an STM32F4 Discovery kit ($15 USD - oo so cheap!) it mentions four "Development Toolchains": Altium Tasking, Atollic TrueSTUDIO, IAR EWARM, Keil MDK-ARM. Minimum price: $3000. Wow. What a joke.

After this experience I would never use STM32 for a new project again. Atmel looks like where its at. Big long datasheets, a free IDE (visual studio based!), cross platform support, a nice library with 1000s of examples, an ecosystem to share code, etc, etc. I am aware that it might seem like the grass is always greener, but when you are in a landfill the greeness of the grass is less of a concern.

So...am I alone? And how can we fix it?

STM32 make cheap, powerful chips, and have a lot of smart developers in their ecosystem, but I think the Cube has too much momentum right now (and is in too many powerpoint slides) to prevent it from collpasing in on itself and forming a singularity.

I have some ideas about how to fix this ecosystem which I will outline later.
 

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 429
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #1 on: March 06, 2015, 10:25:08 PM »
tl;dr The STM32/Cube software ecosystem is the worst I have ever seen. Does anyone feel the same?

I do :P

Quote
How can we fix it?

You can't.

The story gets worse if you start looking for updates for the libraries. The version hell implemented :)
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 2790
  • Country: gb
  • Will design for cookies
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #2 on: March 06, 2015, 10:36:54 PM »
You've come to pretty much the same conclusion I did about the libraries; they're little more than an obfuscation layer between application code and hardware.

I do use Cube to generate the start-up code that configures peripherals. And then, one device at a time, I comment it out and initialise the peripheral myself by poking its registers directly, until there's almost nothing of ST's code left.

You've not mentioned whether the I2C bug turned out to be faulty hardware (ie. a chip bug), or faulty software. I know there are people who steadfastly refuse to read the data sheet for the chip, and to check and program register values directly, and this is precisely why I'm not one of them. You absolutely do need to know what the underlying hardware is doing, and using a library only makes this more difficult.

It's not like, say, a graphics card, which is an extraordinarily complex device that's totally reliant on a high level API. With a device like that, you need functions to do things like draw a line, or a triangle, or whatever.

With I2C you're much closer to the hardware. You need to know what the state machine is doing, what conditions exist on the line, and which device is doing what... and I've yet to ever come across a more precise, efficient or reliable way to do this than to read the registers.

Once I figured this out, programming the STM32 got a whole lot easier.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 9443
  • Country: gb
    • Mike's Electric Stuff
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #3 on: March 06, 2015, 10:44:00 PM »
IME driver/config libraries just add more scope for errors.
 For simple stuff like I2C, instead of spending  time learning and debugging other peoples' code, it's often quicker to just write your own code, which is specific to your needs, not some generic mess that tries (& fails) to do everything.
e.g.  a UART is a very simple peripheral but there are lots of different ways it can be used, it is hopeless for anyone to try writing a library to cover all possibilities.
Manufacturers try to push this crap as making things "easy". If they spent the same amount id time writing clear datasheets and error-free header files , and providing some tested example code as a base to work from, we'd all be a lot better off.
 

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 429
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #4 on: March 06, 2015, 10:48:03 PM »
For simple stuff like I2C, instead of spending  time learning and debugging other peoples' code, it's often quicker to just write your own code, which is specific to your needs, not some generic mess that tries (& fails) to do everything.

I agree.
However, for not such obvious stuff like USB or build in Ethernet, thinks get really nasty.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #5 on: March 06, 2015, 11:13:58 PM »
Quote
ST's (STM32Cube) software ecosystem is terrible

I have been saying that for a long time. STM32Cube is essentially a half-assed attempt by ST at PE.

Quote
- how can we fix it?

by not using it.

The good old standard peripheral library is perfectly fine. Or go to the registers directly.
================================
https://dannyelectronics.wordpress.com/
 

Offline v

  • Contributor
  • Posts: 7
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #6 on: March 06, 2015, 11:26:04 PM »
Quote
by not using it.
The good old standard peripheral library is perfectly fine. Or go to the registers directly.

I wish I didn't have to use it! I had such a battle-tested codebase before but the I2C thing and lack of support for STM32F411xE forced me to update. If the I2C had worked I would have never been stuck outside in this storm.

I regret not bit-banging the I2C 2 weeks ago.

Quote
You've not mentioned whether the I2C bug turned out to be faulty hardware (ie. a chip bug), or faulty software.

There is lots of errata surrounding I2C and it seems like its a problem on the silicon and they have implemented a collection of software workarounds. I only got it working a few days ago, and I'm still finding it hangs after multiple debugging sessions without disconnecting the board power.

Quote
IME driver/config libraries just add more scope for errors.

I see the benefits of working close to the hardware, but I do believe that if there was a well-defined high-level Arduino/mBed style library it would reduce the surface area for bugs and make it easier for them to test the library.

They could easily create a sample project which calls all the methods of these high level libraries and when something didn't work it would be obvious.
 

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 429
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #7 on: March 06, 2015, 11:29:46 PM »
The good old standard peripheral library is perfectly fine.

Hmm .. also had some bad experiences there, again with usb and ethernet :(
Also, a lot of different versions out there.


Quote
Or go to the registers directly.

Probably best, but it takes a lot of time. One must be really anxious (or being forced) to go that path.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #8 on: March 06, 2015, 11:41:09 PM »
Quote
I regret not bit-banging the I2C 2 weeks ago.

F4's i2c is fine, both hardware and standard peripheral library drivers. The i2c issues are limited to F1 and STM8 - there the hardware is kind of fine, and the datasheet is fine, but the standard peripheral library drivers are incorrectly coded.
================================
https://dannyelectronics.wordpress.com/
 

Offline v

  • Contributor
  • Posts: 7
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #9 on: March 06, 2015, 11:53:22 PM »
Quote
I regret not bit-banging the I2C 2 weeks ago.

F4's i2c is fine, both hardware and standard peripheral library drivers. The i2c issues are limited to F1 and STM8 - there the hardware is kind of fine, and the datasheet is fine, but the standard peripheral library drivers are incorrectly coded.

How do you know it is fine on the F4? And how do you know its limited to the F1 - do you have a link to an errata sheet?

If you have a Nucleo-F411RE, try and use I2C1 with the StdPeriph (it should work), then try use I2C2 and you will see the busy flag.

I've heard from many sources that there are problems, and experienced them myself so I have to disagree.


 

Offline nerdyHippy

  • Contributor
  • Posts: 37
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #10 on: March 07, 2015, 12:20:50 AM »
I think I've run into the same BUSY_FLAG issue that you have on a pair of 32F4 Discovery boards. I am using Cube and all its generated code, and one board simply refuses to reset the busy flag, so I2C comms never initiate. The other board works fine with the same code. Very odd, and rather irritating.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #11 on: March 07, 2015, 12:37:31 AM »
Quote
The other board works fine with the same code.

that would confirm for you that the issue is NOT with the code.
================================
https://dannyelectronics.wordpress.com/
 

Offline diyaudio

  • Frequent Contributor
  • **
  • Posts: 579
  • Country: za
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #12 on: March 07, 2015, 12:53:54 AM »


STM32 make cheap, powerful chips, and have a lot of smart developers in their ecosystem, but I think the Cube has too much momentum right now (and is in too many powerpoint slides) to prevent it from collpasing in on itself and forming a singularity.

I have some ideas about how to fix this ecosystem which I will outline later.

 The same story applies to Microchip (even worse IMHO), None of these companies are prefect at their embedded software line or even close to it. Companies just spend effort customizing rewriting (and getting good C/C++ developers NOT summer interns) or buying software layers they need its called R&D and its integrated into the cost of a product. Small companies or hobbyist like us are left to dwell at the bottom of barrel.

Ti stuff looks promising...   

 
 
 
 

Offline v

  • Contributor
  • Posts: 7
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #13 on: March 07, 2015, 02:06:19 AM »
Quote
None of these companies are prefect at their embedded software line or even close to it.

Atmel looks like they are. Free VS based IDE. Arduino mindset. Big ecosystem. Good documentation. Does anyone have experience with Atmel, I'm thinking of switching, would love to hear if it is a good as it sounds...
 

Offline clive1

  • Newbie
  • Posts: 1
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #14 on: March 07, 2015, 04:48:12 AM »
The Atmel IDE is slow but the community is great and the lib is limited to bugs which are fixable within 15minutes.
Trick#1: TurnOff online spellcheck - saves much ressources.

ST has a good commercial support, the HAL & CUBE was the biggest misstake of their own ecosystem roadmap.

 

Offline kamtar

  • Contributor
  • Posts: 14
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #15 on: March 07, 2015, 05:09:30 AM »
Me too, im using atmel just because of VS IDE. Documentation is pretty good, lots of useful app notes,etc..
 

Offline dgtl

  • Regular Contributor
  • *
  • Posts: 83
  • Country: ee
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #16 on: March 07, 2015, 10:01:48 AM »
I feel the same about STM32. The chips are nice, documentation is not the best and the code is terrible. I've done a number of projects with different STM32 chips recently and looked into their std periph lib, st cube, usb dev lib, lwip hal lib etc. So far, what I've encountered is terrible and I've had to write almost everything from scratch.

The embedded software development on microcontrollers is different than application programming on top of an os. For embedded programming, usually the task is controlling hardware (at least controlling the communicating interfaces) and although it may have multiple layers, the bottom layer of the software is quite hardware-related. The uC's are not so often used for generic data-processing that is hardware-independent. This makes it difficult to have generic HAL implementations and stable HAL API like OS'es can provide; the hardware is not abstracted away like on generic OS'es.

In such case, the HAL library can only be a collection of frequently used snippets to do common tasks. The programmer programs the HW, the library can only help the programmer. The HAL does not have to be something readly-made one-size-fits-all complete product. For me, the HAL library is most useful, if I can get some pieces that I need without writing them from scratch. If the functionality I need is something special and uses the HW in some clever way (ie some strange protocol-dependent implementation of DMA-based triple-buffered high-throughput or timing-critical communication), I'll write it myself anyway. But if I need to configure a GPIO or to perform a simple blocking SPI write etc, it would help to have a ready-made function, that is simple and does just that. I'll prefer multiple small functions that I can choose the ones that I need as opposed to a large configurable mess, that needs to be cut apart and put back together if something is not like I need.

For ST's case, the HAL is a monster by itselt. I need to understand the HW anyway. So I'll need to read the DS to figure out what needs to be configured in which way. But then I need to figure out, how to do it using the HAL. So there are 2 things to know instead of one now. The HAL takes register bits in variables, so there is just register API wrapped into HAL API. In case of simple interfaces like SPI/I2C/UART, the configuration of the peripheral for simple non-DMA operation is writing a couple of config registers. Filling out a huge struct, where most of the parameters do nothing in my case, is just not justified. I'd be much more happy when having some simple commonly used functions, ie for calculating and setting USART baud rate divider. I would appreciate, when the resulting code is written in a sane way so it would get optimized back to just a couple of register writes, not a huge amount of run-time calculating of already-known values that could be pre-calculated compile-time or a read-modify-write for every regiter bit changed. (I've seen runtime calculation of log2 to determine bit field offset in register from mask!) The complicated use cases can not be covered anyway, so leave them out or implement multiple copies of different approaches, I'll use what I need.

Even when leaving the HAL aside, the troubles are not over yet. Even the header file containing the register definitions is a mess. Most of the bit fields at nonzero offsets do not have their offsets defined. Then some HAL peripheral c/h files define them locally there. A lot of the enum-style bit fields do not have the options defined (ie if there is a bit field MODE, that has possible values of MODE_A, MODE_B etc, then these values should be defined as well. In ST's case, usually MODE_0, MODE_1 bits are defined, that is almost as useless as nothing at all). The USB controller register definition is a total mess. So even if I write all my code myself and do not use ST's std periph library or cube, I still need to keep local in-house copies of the header files that are improved; spreading all of those missing defines in a number of different source files in a lot of projects would just make a bigger mess.

There are some open-source alternatives to ST HAL library. For example, libopencm (was libopenstm32). Of course, they are licensed in such way, that may not be acceptable for commercial non-opensource projects. But if the open-source developers can re-use some common pieces of code and contribute them back, it will only benefit them. Without the vendor support, this will be limited to what was needed for some developers who cared to contribute their code back and the quality may vary in different places. I do not expect that it would help commercial developers nor that commercial code developers would contribute back a lot to such projects. So only ST can make our life easier; either they will or not.

The IDE and compiler wars should be kept separate of the HAL library issues. Different developers have different preferences. The ARM Cortex chips are giving us a great ecosystem of different tools, that can be operated on almost any vendor's chips. For most of the cases, the tools are quite equal; what really matters is what the developer is used to and feels most comfortable with. I like linux+eclipse+gcc, but for most of the major development tools, the result of the work is not that much limited by the tools, but by the engineer doing the work.

I've had my own issues with Atmel, that's why I converted to ST. At this moment, I would not go back.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #17 on: March 07, 2015, 10:33:53 AM »
Quote
I feel the same about STM32.

I would venture to say that many of your comments are understandable, but probably attributed to the wrong party (ST).

You shouldn't think of an OEM library as something that your code interfaces with directly. As you pointed out, quite correctly, that those are simply versatile snippets - designed to be all-inclusive for all user applications. Because of that, they can be too scattered and too overwhelming - they are so many of them to learn and to remember. And in any given application, you are only using a small portion of the chip's and library's functionality so that kind of "capabilities" seems too much.

I would suggest that you consider the concept of "middleware": a layer of your code that performs some of the most frequently used functions in a way that you feel comfortable. Your code doesn't directly call the OEM library, instead, it calls the OEM library through the middleware.

Quote
Filling out a huge struct, where most of the parameters do nothing in my case, is just not justified. I'd be much more happy when having some simple commonly used functions, ie for calculating and setting USART baud rate divider.

For example, in this case, you can write a routine that calculates the baud rate and set up the usart for you in a way that you feel like it.

The beauty of this approach is that in the future, if you were to switch the underline libraries, from standard peripheral library to Cube, from calling registers directly to calling them through OEM libraries, or to even go from one processor to another processor, you can simply link in the appropriate middleware and your user code remains unchanged.

In my case, I can write a piece of code for STM32 for example on turbo C or Keil C51 and then compile it later on with the right middleware for CoIDE or Keil or IAR, using this approach.

To my code, the OEM libraries do not exist, even if my code eventually relies heavily on them.
================================
https://dannyelectronics.wordpress.com/
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 647
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #18 on: March 07, 2015, 01:31:24 PM »
The Atmel IDE is slow but the community is great and the lib is limited to bugs which are fixable within 15minutes.
Trick#1: TurnOff online spellcheck - saves much ressources.

ST has a good commercial support, the HAL & CUBE was the biggest misstake of their own ecosystem roadmap.
Clive? *the* Clive from STM32 forums?
 

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 429
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #19 on: March 07, 2015, 07:57:28 PM »
Clive? *the* Clive from STM32 forums?

When Clive dies, ST ARM dies ..  :-DD
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 1608
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #20 on: March 07, 2015, 09:46:41 PM »
Icing on the cake for ST is if you look at the back of an STM32F4 Discovery kit ($15 USD - oo so cheap!) it mentions four "Development Toolchains": Altium Tasking, Atollic TrueSTUDIO, IAR EWARM, Keil MDK-ARM. Minimum price: $3000. Wow. What a joke.
The free version of Atollic TrueSTUDIO has 32kB code limit, which is sufficient for simple projects.

But you are right, I had some problems with CubeMX, too. I started with the latest CubeMX version and tried to generate a project. It didn't work, ran into this problem. The answer didn't really help, but after starting TrueSTUIDO once (was a fresh installation) suddenly CubeMX worked. Maybe they need the TrueSTUDIO workspace or some settings, which is strange for a simple code generator.

Another problem was when I tried to save the project. It said something about "no drive c: found" (don't remember the exact wording). But after the TrueSTUDIO project files were generated, this problem disappered, too, or maybe it was some problem with spaces in filesnames.

Then I tried to open a customer CubeMX project which was created with an older version of CubeMX, to change the CPU type so that I could test it with my Discovery board. It didn't work. Lots of configuration warnings and errors, impossible to fix.

And the code quality of the HAL library is not good. Take a look at this function:

Code: [Select]
__weak void HAL_Delay(__IO uint32_t Delay)
{
  uint32_t tickstart = 0;
  tickstart = HAL_GetTick();
  while((HAL_GetTick() - tickstart) < Delay)
  {
  }
}

I guess that's the way it was implemented in Windows 98, which hangs after running 47.9 days.

When I tested my Discovery board first some years ago, I used the STM32 standard peripherals library, a plain Makefile process and a GCC ARM cross compiler. Sure, you have to read the datasheet and do all the initialization yourself, but it worked without problems. No fat IDE and no code size limitations. If you are using Linux, then you can use some of the nice tutorials how to build your own cross compiler, and ready to use templates for your STM32 board, see for example this article.

But I have to admit, sometimes a big IDE and a debugger is nice. I tried Rowley CrossWorks (the free version has a 16k code size limit) and with ST/Link (integrated in my Discovery board) you can see realtime updates of variables while the program is running, single-step debugging it etc. At least single-step debugging is possible with Eclipse and gdb, too, but needs some work to install and configure all the required software. CrossWorks works out of the box.

Does the Discovery board work with mbed? I used this framework for a LPC microcontrollers and the C++ class library makes it really easy to write programs for it. Code generators like CubeMX are terrible, compared to a well designed object oriented framework like mbed. Take a look at this code for a fully working example of a virtual USB COM port. All default initializations etc. are encapsulated in the classes and you can derive and overwrite your functions. This makes it even easy to develop your own USB device with it.

And you can install the mbed toolchain locally on your PC, too, no need to use their online project management and compile system, if you don't want your code get wet in the cloud (see this description how I did it for Windows).
quadro copter flying, electronics, retro computing and other geeky things: http://www.youtube.com/user/frankbuss/
 

Offline diyaudio

  • Frequent Contributor
  • **
  • Posts: 579
  • Country: za
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #21 on: March 08, 2015, 10:18:10 AM »
Clive? *the* Clive from STM32 forums?

When Clive dies, ST ARM dies ..  :-DD

Clive deserves an award.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #22 on: March 08, 2015, 10:47:42 AM »
Quote
I guess that's the way it was implemented in Windows 98, which hangs after running 47.9 days.

Such implementation isn't meant for long delays - there are far more efficient ways to do that.

The implementation is the right way for short delays - most programmers actually use it without understanding its virtue.
================================
https://dannyelectronics.wordpress.com/
 

Offline donotdespisethesnake

  • Frequent Contributor
  • **
  • Posts: 402
  • Country: gb
  • Embedded stuff
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #23 on: March 08, 2015, 12:18:37 PM »
Quote
I guess that's the way it was implemented in Windows 98, which hangs after running 47.9 days.

Such implementation isn't meant for long delays - there are far more efficient ways to do that.

The implementation is the right way for short delays - most programmers actually use it without understanding its virtue.

Nevertheless it contains a nasty bug, definitely wrong way to write it even if it is supposed to be inefficient.

We had similar code in one of our projects, it caused mysterious timing errors. Since the same lines had been copied several times, I had to trawl through the whole project fixing them.
Bob
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #24 on: March 08, 2015, 02:26:46 PM »
Quote
I had to trawl through the whole project fixing them.

How did you "fix" it then? :)
================================
https://dannyelectronics.wordpress.com/
 

Offline nazcalines

  • Contributor
  • Posts: 22
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #25 on: March 08, 2015, 03:46:50 PM »
Quote
None of these companies are prefect at their embedded software line or even close to it.

Atmel looks like they are. Free VS based IDE. Arduino mindset. Big ecosystem. Good documentation. Does anyone have experience with Atmel, I'm thinking of switching, would love to hear if it is a good as it sounds...

I just switched from atmel to st... My background is in AVRs with WinAVR and then the Atmel Cortex M3 chips with Atmel Studio.  I find st's standard peripheral library to be quite good and there are loads of examples online (people's personal blogs, my.st.com).  I have not tried STM32Cube and hopefully will never need to.  The community around Atmel ARM is way behind, imo.  I also much prefer a minimal dev setup to Atmel's sluggish Studio IDE.  I've never used Arduino (AVR or ARM versions), so those might be better supported.

When I was researching ARM chips I went with Atmel because I was used to their documentation and thought it would be nice to not put any work into the tool chain.  It turns out I really dislike Atmel Studio (I run it in a VM, and it is soooo slow).  My only regret is that I didn't switch to st sooner.

There are also some minor details with stm32 I prefer, for example, the DAC outputs swings full range vs Atmel's and the power supply setup is simplified.
 

Offline Frank

  • Contributor
  • Posts: 9
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #26 on: March 08, 2015, 06:34:19 PM »
Code: [Select]
__weak void HAL_Delay(__IO uint32_t Delay)
{
  uint32_t tickstart = 0;
  tickstart = HAL_GetTick();
  while((HAL_GetTick() - tickstart) < Delay)
  {
  }
}
Quote
I had to trawl through the whole project fixing them.

How did you "fix" it then? :)

I have the same doubt :)

Maybe I'm missing something, but isn't the above code correct? It will work even when the Tick count overflow, or the delay is 0xFFFFFFFF.

In fact, the old way that the library did the delay was wrong:

Code: [Select]
void HAL_Delay(__IO uint32_t Delay)
{
  uint32_t timingdelay;
   
  timingdelay = HAL_GetTick() + Delay;
  while(HAL_GetTick() < timingdelay)
  {
  }
}
 

Offline NF6X

  • Supporter
  • ****
  • Posts: 87
  • Country: us
    • Mark's Green Pages
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #27 on: March 08, 2015, 07:30:14 PM »
I view STM32FCube is more of a pile of evaluation code than something I'd expect to use as-is for serious projects. I've recently started a quick hack of a project using an STM32F051, and I've been using the STM32FCube stuff for it so far. It's not anything I'll be very proud of when it's done, and I don't think I'd use the HAL code as anything more than example code if my project was more demanding and/or I was getting paid to do it. :)

It wasn't easy, but I actually got STM32CubeMX working on my Mac along with a free open source toolchain. ST doesn't appear to advertise support for any platforms but Windows, but both the STM32FCubeMX installer are Java apps that can be run on the Mac by installing Java (don't forget to de-select the "Install Spyware Toolbarz!" option) and renaming the installer and the app it installs from *.exe to *.jar.

I'm using the toolchain provided by the arm-none-eabi-binutils and arm-none-eabi-gcc packages from MacPorts. The arm-none-eabi-gdb port is presently broken, but there's an unofficial patch to make it build. I've patched/installed it, but so far I've found it easier to debug with a couple of LEDs than to re-learn how to use gdb. It's rumored to be possible to get everything working under Eclipse, but I'm not especially fond of Eclipse so I haven't tried.

STM32CubeMX spit out an empty linker script for my project. Maybe it's because none of the toolchains it understands are installed, or maybe it's just buggy. I wrote my own linker script. I also found that the "only spit out referenced files" option prevented it from spitting out startup code. The combination of ST's startup code and gcc's libc resulted in an undefined reference to _init() which can be fixed by manually cramming an empty _init() function into the project code. I also had to write a Makefile for my project. I'm using texane's stlink utilities for flashing.

I spent many hours trying to figure out why the DAC wasn't working, only to figure that I needed to include another HAL code file to get the actual DAC support code, rather than just __weak stubs to the needed functions that prevented the linker from helpfully telling me that I was linking against thin air.  |O

Now I'm wrestling with keeping the DAC from jumping to the negative rail at the end of each prerecorded sound sample that my application needs to periodically spit out. I haven't figured out yet whether it's buggy HAL code, a limitation of how the DAC works in DMA mode, or PEBCAK. My application is un-demanding enough that I may just avoid the issue by pushing out single-sample conversions in a timer interrupt handler rather than using DMA.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #28 on: March 08, 2015, 08:39:56 PM »
Only way to fix it is to give negative feedback on their forums and customer service so they might spnt more effort making something usefull.
 

Offline hamdi.tn

  • Frequent Contributor
  • **
  • Posts: 549
  • Country: tn
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #29 on: March 08, 2015, 09:16:44 PM »
Cube and HAL drivers are simply rubbish ... the only thing i find useful in cube is pin assignment for my application it save time when choosing peripheral pin and alternative function ... the code that generate is trash.

for the i2c, i experienced that busy bit problem days ago and simply my initialisation was wrong.
for the i2c in f4 it's totally fine , the f1 may cause problem , i used the f1 with ic eeprom no problem at all but true f1 may have a hardware problem, the source : a guy working for st.

you can't fix it , just use the standard library.

The example that you find with ST library may help , but the negative point about them is that all the example are linked together and linked to a hardware of a specific evaluation board , so you can't really open files for i2c example and read a stand alone application there is always some undefined word that you have to look for in others files ... really pain in the ass.

usually example given by forums like stm32f4-discovery.com are better and code work out of the box.

 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #30 on: March 08, 2015, 09:24:35 PM »
Quote
I regret not bit-banging the I2C 2 weeks ago.

F4's i2c is fine, both hardware and standard peripheral library drivers. The i2c issues are limited to F1 and STM8 - there the hardware is kind of fine, and the datasheet is fine, but the standard peripheral library drivers are incorrectly coded.

No they arent, F4 uses same I2C peripheral as F1 does. So does L1 and L4 I think.

I'd suggest to use ST CPAL library for I2C, instead of trying to write anything from scratch. You can't cover all the shit happening in that poor peripheral so CPAL was done for you to solve almost all problems with I2C exclusively. (but I admit the CPAL lib is pissfully complicated to understand and use aswell)

Simply there is no solution for the  crippled peripheral. You must be lucky if it works.
« Last Edit: April 25, 2015, 06:16:00 AM by Yansi »
 

Offline Narmaraktuk

  • Contributor
  • Posts: 20
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #31 on: March 08, 2015, 10:11:35 PM »
tl;dr The STM32/Cube software ecosystem is the worst I have ever seen. Does anyone feel the same? How can we fix it?

Agreed in full. Cube is handy to look at pin assignments, and doing a java -jar STMCube.exe is a quaint way to support linux/mac users.

As to how can we fix it; my take is to walk away from ST's libs, and only use their hardware. I like libopencm3 a lot, this is a minimal open source library to get at the peripherals. Functions make sense, source can be quickly looked at (what register is tweaked why). A new project is only a Makefile, a stm32fx.ld depending on backend and a
Code: [Select]
git submodule add https://github.com/libopencm3/libopencm3.git away.

libopencm3 has "support" for efm32, lm3s, lm4f, lpc13xx, lpc17xx, lpc43xx, sam, stm32, vf6xx. I have not looked at others than stm32 at this point, but it is nice to know that other ppl are working on this. Naturally this library is not made by the manufacturers, and though I have not found any missing so far for stm, that might not hold for all backends.
 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #32 on: March 08, 2015, 10:16:21 PM »
I wouldn't trust any thirdparty multi-vendor library. That smell like a big trouble.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #33 on: March 08, 2015, 10:29:59 PM »
Quote
Maybe I'm missing something, but isn't the above code correct? It will work even when the Tick count overflow, or the delay is 0xFFFFFFFF.

Absolutely correct.

That piece was specifically coded to avoid the roll-over. Many people use it without understanding that, and many people criticize it without understand it either.

Anyway, I am quite interested in the supposedly superior "fix".
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #34 on: March 08, 2015, 10:37:35 PM »
Quote
Only way to fix it is to give negative feedback on their forums and customer service so they might spnt more effort making something usefull.

Or don't use their products at all -> that is the only one that ST (or any other company) cares about.
================================
https://dannyelectronics.wordpress.com/
 

Offline donotdespisethesnake

  • Frequent Contributor
  • **
  • Posts: 402
  • Country: gb
  • Embedded stuff
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #35 on: March 09, 2015, 07:33:35 AM »
Quote
Maybe I'm missing something, but isn't the above code correct? It will work even when the Tick count overflow, or the delay is 0xFFFFFFFF.

Absolutely correct.

That piece was specifically coded to avoid the roll-over. Many people use it without understanding that, and many people criticize it without understand it either.

Anyway, I am quite interested in the supposedly superior "fix".

Ah, my bad. I mistook the good version for the faulty one  :-[

That will teach me to read more carefully...!
Bob
 

Offline Dago

  • Frequent Contributor
  • **
  • Posts: 654
  • Country: fi
    • Electronics blog about whatever I happen to build!
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #36 on: March 09, 2015, 06:12:46 PM »
I agree with the OP. I haven't actually used the cube stuff specifically but just the ST headers (not sure how closely they are related) and they are just an inconsistent mess. Seemed like something made by a summer worker or something.

I wrote my own headers from scratch (made to resemble more recent Atmel headers like for the xmega series which are very well made) but I can't say that was a good solution either. You need to implement so much stuff. It also felt like the actual hardware is poorly designed, they have not thought about how the user will use the hardware and how you could design the hardware so that implementing code that would be easily modifiable or portable would be easy to make.

Good example were the comparators in the part I used, there was like 8 different comparators which had exactly one configuration register each. The only difference between those was which signals you could route to the comparators and which signals you could route out. So the logical solution would be to have identical configuration registers for all of them and then some (identical) routing blocks (with their own configuration) for the inputs and outputs and the connections could be easily be expressed as some kind of a chart on the datasheet? But nope, STs solution was to make 8 different configuration registers that are enough inconsistent between eachother that you just have to rewrite them for each of the comparators. And this was one of the smaller problems... Also all of the pins are laid out in the package like almost 100% randomly. Absolutely no sense in the way the pins are laid out. Parallel buses where like... none of the bits are adjacent to eachother etc.

I guess the problem is that there is no competition. At least I am not aware of any ARM-families that would be considerably better (in hardware design and in software side).
Come and check my projects at http://www.dgkelectronics.com ! I also tweet as https://twitter.com/DGKelectronics
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #37 on: March 09, 2015, 06:59:44 PM »
I guess the problem is that there is no competition.
No in contrary to what many here think the core business of ST is silicon design, manufacturing and selling. Not writing support software for their silicon.
You can stand to differ and discuss the need to have supporting software but lets face it the businesses that buy a million STM32 a quarter from them write their own software anyway. They also have their private lifelines directly in the ST company to sort out problems (been there done that  ;) )
Only thing of ST what I do not understand is that they sell these incredible cheap discovery boards thereby attracting the hobbieist community while not being able to properly support that community. That I really do not understand, perhaps a futile attempt by some rookie product manager too sell even more without thinking.
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 2790
  • Country: gb
  • Will design for cookies
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #38 on: March 09, 2015, 07:03:03 PM »
It just makes trying an ST device a no-brainer. I can order a £10 board without a moment's hesitation, but, say, a £100 board needs justification.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #39 on: March 09, 2015, 07:18:12 PM »
It just makes trying an ST device a no-brainer. I can order a £10 board without a moment's hesitation, but, say, a £100 board needs justification.
Oh from the buyers point of view I get it. But from ST point of view, they don't make money on their discovery boards. And they don't have the newbie easy starter software suite to accompany it. So  :-//
 

Offline Towger

  • Super Contributor
  • ***
  • Posts: 1012
  • Country: ie
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #40 on: March 09, 2015, 07:37:45 PM »
And that newbie starter in ten years time becomes the designer of the million units a quarter product.  But the now designer does not use ST chips due to their previous experience with them.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #41 on: March 09, 2015, 07:43:39 PM »
And that newbie starter in ten years time becomes the designer of the million units a quarter product.
Yeah but the newbie has gotten a real rotten startup experience with the ST chips so decided to switch to another manufacturer so the million parts will be for some other company  ;)
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 2790
  • Country: gb
  • Will design for cookies
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #42 on: March 09, 2015, 07:47:05 PM »
I DO use ST parts (commercially) because of my previous experience with them. The fact that the Discovery boards are cheap and readily available is a nice bonus.

In terms of development tools, CrossWorks for ARM is just US$150 for a hobby licence, so you can hardly complain that there are no inexpensive options available. Even the commercial licence is, at $1500, a great deal less than most alternatives.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #43 on: March 09, 2015, 07:49:44 PM »
You loose 90% of your target audience if the $10 board needs a $150 hobby license toolsuite  ;)
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #44 on: March 09, 2015, 10:34:35 PM »
-I guess the problem is that there is no competition. At least I am not aware of any ARM-families that would be considerably better (in hardware design and in software side).-

The -mass produced high end- vendors would be freescale and ti.

I don't quite understand your problem - if you specify the part it may help. In general setting up the project in most IDE is fairly easy and largely consistent. Tedious it is.

So part of the difficulty people encountered on those parts is user driven.
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #45 on: March 09, 2015, 10:39:15 PM »
And other times it's fad. A couple years ago, our experts here didn't know the i2c issues on some st parts. Now everyone has issues with st i2c modules, even on those st parts that don't exhibit i2c issues.
================================
https://dannyelectronics.wordpress.com/
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 1608
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #46 on: March 09, 2015, 11:06:28 PM »
I have the same doubt :)

Maybe I'm missing something, but isn't the above code correct? It will work even when the Tick count overflow, or the delay is 0xFFFFFFFF.

In fact, the old way that the library did the delay was wrong:
You are right, I quoted the new code without thinking, because it is tricky to see that the new code is correct for any C compiler, because overflows are undefined with signed integers, but defined for unsigned integers, as described here. Good to see that they fixed it.
quadro copter flying, electronics, retro computing and other geeky things: http://www.youtube.com/user/frankbuss/
 

Offline NF6X

  • Supporter
  • ****
  • Posts: 87
  • Country: us
    • Mark's Green Pages
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #47 on: March 10, 2015, 01:15:29 AM »
You loose 90% of your target audience if the $10 board needs a $150 hobby license toolsuite  ;)

They could address that by adding support for plain Makefile based projects for gcc to STM32CubeMX (and I wish that they would). But then, based on how their headers are written, I bet it would be a ghastly mess that would make automake-generated makefiles look simple by comparison.  ::)
 

Offline Lukas

  • Frequent Contributor
  • **
  • Posts: 300
  • Country: de
    • carrotIndustries.net
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #48 on: March 10, 2015, 03:56:32 AM »
I guess ST autogenerates the register definition header files from the SVD XML document. SVD is a part of CMSIS describing which there are in a device. A while back I wrote a small application that parses the SVD and allows you to do point-and-klick register manipulation by connecting to openocd. When I find some time, I'll clean it up and put it on github.

SVD allows to specify enumerated values for bitfields. Unfortunately ST completely missed that one, so you've got to look up in the datasheet which value you've got to write in the bitfield. Atmel got it right...

Just to give you an idea how SVD looks like:

Code: [Select]
<register>
          <name>CMR1</name>
          <description>Channel Mode Register (channel = 1)</description>
          <addressOffset>0x00000044</addressOffset>
          <size>32</size>
          <access>read-write</access>
          <resetValue>0x00000000</resetValue>
          <fields>
            <field>
              <name>TCCLKS</name>
              <description>Clock Selection</description>
              <bitOffset>0</bitOffset>
              <bitWidth>3</bitWidth>
              <access>read-write</access>
              <enumeratedValues>
                <enumeratedValue>
                  <name>TIMER_CLOCK1</name>
                  <description>Clock selected: TCLK1</description>
                  <value>0x0</value>
                </enumeratedValue>
                <enumeratedValue>
                  <name>TIMER_CLOCK2</name>
                  <description>Clock selected: TCLK2</description>
                  <value>0x1</value>
                </enumeratedValue>
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1474
  • Country: pl
  • Troll Cave Electronics!
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #49 on: March 10, 2015, 04:11:24 AM »
Cube sucks. The only thing i find it useful for is planning pin usage in a processor.

I keep a policy of not using anyone elses code, only using my own. I have made exceptions from this for really atrocious stuff (USB, TCP, Modbus...) where i focused on getting somebody elses shit to work, but in general I only use my own code. I do use helper libraries like the ST's SPL, but only after i review the code line by line. I work from plain register definitons if need be. Save the "one code fits all" stuff for linux users with GHz's and GB's.

I have learned this while working with Mircochip's pic24f library, which gave me a week of hair-pulling because the library was not compatible with the mcu I was using (despite it claiming to be)... and the mcu had an extra configuration bit.

As for general quality:
ST: very good silicon, good documentation, SPL is ok, CUBE is shit
Atmel: silicon is ok, documentation is generally ok although sometimes lacking (mostly manageable after examining the examples provided), IDE is shit, or rather adapted to MCU use in a shitty way (no 'binary' display in debug mode? - come on!)
NXP: good silicon, good documentation, crappy policy towards low volume users, hobbyists and open source crowd (eg. they won't disclose the debugger protocol to OpenOCD people)
TI: good silicon, good documentation, ok libraries, but chips are expensive and they do not cover the lower range too well
Microchip: silicon=mostly shit, documentation os ok, compilers and IDE are shit. $40 genuine debugger is an example to show to other manufacturers
Freescale, Silabs/EnergyMicro, Cypress: can't say, I've never had much practical experience with them (i serious project I mean, I dabbled a bit with some low-end devboard)

I love the smell of FR4 in the morning!
 
The following users thanked this post: technix

Offline v

  • Contributor
  • Posts: 7
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #50 on: March 10, 2015, 04:18:18 AM »
When I find some time, I'll clean it up and put it on github.

That would be awesome! Please let me know when you do.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 1608
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #51 on: March 10, 2015, 04:41:42 AM »
When I find some time, I'll clean it up and put it on github.

That would be awesome! Please let me know when you do.
I did something similar for my Kerberos project. The file regs.xml is the description and regs.py generates the VHDL code, the assembler inc files and the C header files from it. (see regs.h, regs.inc and main.vhd). But it needs some more features and cleanup.

Is SVD an industry standard and easy to use for own projects? I thought BSDL would be the standard way to describe registers and pins, but never found the time to learn how it works.
quadro copter flying, electronics, retro computing and other geeky things: http://www.youtube.com/user/frankbuss/
 

Offline diyaudio

  • Frequent Contributor
  • **
  • Posts: 579
  • Country: za
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #52 on: March 10, 2015, 04:49:20 AM »
MPLAB never hits breakpoints correctly, seriously WTF. when will this mess end?
 

Offline Lukas

  • Frequent Contributor
  • **
  • Posts: 300
  • Country: de
    • carrotIndustries.net
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #53 on: March 10, 2015, 06:12:38 AM »
Is SVD an industry standard and easy to use for own projects? I thought BSDL would be the standard way to describe registers and pins, but never found the time to learn how it works.
SVD is defined by ARM, so you may call it industry standard for ARM µCs. SVD is fairly reasonable self-explaining XML, I managed to implement my SVD register manipulator without looking at any sort of spec or documentation.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #54 on: March 10, 2015, 10:46:04 AM »
I don't think that ST understands C-level software, which is pretty bad considering that they're writing documentation and libraries in C these days.   Consider the fractional divisor for the USART, documented as: baud = Fck/(16*BRRGEN)
Excellent, I say to myself.  Shift to create the fixed-point fraction, divide, done.  BRRGEN = FCK/baud;  That's ... almost elegant the way the 16 multipliers cancel out!

But the documentation goes on to explain how it SHOULD be done.  In great detail:
Quote
Example 2:
To program USARTDIV = 0d25.62
This leads to:
DIV_Fraction = 16*0d0.62 = 0d9.92
The nearest real number is 0d10 = 0xA
DIV_Mantissa = mantissa (0d25.620) = 0d25 = 0x19
Then, USART_BRR = 0x19A hence USARTDIV = 0d25.625
Example 3:
To program USARTDIV = 0d50.99
This leads to:
DIV_Fraction = 16*0d0.99 = 0d15.84
The nearest real number is 0d16 = 0x10 => overflow of DIV_frac[3:0] => carry must be added up to the mantissa
DIV_Mantissa = mantissa (0d50.990 + carry) = 0d51 = 0x33 Then, USART_BRR = 0x330 hence USARTDIV = 0d51.000
WTF?  Surely the people who wrote the standard peripheral library noticed that it was simpler than that?   Nope (this is the STP library):
Code: [Select]
  /* Determine the integer part */
  if ((USARTx->CR1 & CR1_OVER8_Set) != 0)
  {
    /* Integer part computing in case Oversampling mode is 8 Samples */
    integerdivider = ((25 * apbclock) / (2 * (USART_InitStruct->USART_BaudRate)));   
  }
  else /* if ((USARTx->CR1 & CR1_OVER8_Set) == 0) */
  {
    /* Integer part computing in case Oversampling mode is 16 Samples */
    integerdivider = ((25 * apbclock) / (4 * (USART_InitStruct->USART_BaudRate)));   
  }
  tmpreg = (integerdivider / 100) << 4;

  /* Determine the fractional part */
  fractionaldivider = integerdivider - (100 * (tmpreg >> 4));

  /* Implement the fractional part in the register */
  if ((USARTx->CR1 & CR1_OVER8_Set) != 0)
  {
    tmpreg |= ((((fractionaldivider * 8) + 50) / 100)) & ((uint8_t)0x07);
  }
  else /* if ((USARTx->CR1 & CR1_OVER8_Set) == 0) */
  {
    tmpreg |= ((((fractionaldivider * 16) + 50) / 100)) & ((uint8_t)0x0F);
  }
 
  /* Write to USART BRR */
  USARTx->BRR = (uint16_t)tmpreg;

Wow.  That was so convoluted that I lost confidence in my own simple code.  So I wrote a test program to confirm that it produced the same results as the STP code.  Yep.   Wow.

It got a little prettier in the Cube HAL driver.    Now it's all put in a macro, instead:
Code: [Select]
/* stm32f1xx_hal_usart.c  */
    husart->Instance->BRR = USART_BRR(HAL_RCC_GetPCLK1Freq(), husart->Init.BaudRate);
It looks nice and clean.  But the macro is still calculating fraction and integer parts separately:
Code: [Select]
/* stm32f1xx_hal_usart.h */
#define USART_DIV(__PCLK__, __BAUD__)                (((__PCLK__)*25)/(4*(__BAUD__)))
#define USART_DIVMANT(__PCLK__, __BAUD__)            (USART_DIV((__PCLK__), (__BAUD__))/100)
#define USART_DIVFRAQ(__PCLK__, __BAUD__)            (((USART_DIV((__PCLK__), (__BAUD__)) - (USART_DIVMANT((__PCLK__), (__BAUD__)) * 100)) * 16 + 50) / 100)
#define USART_BRR(__PCLK__, __BAUD__)                ((USART_DIVMANT((__PCLK__), (__BAUD__)) << 4)|(USART_DIVFRAQ((__PCLK__), (__BAUD__)) & 0x0F))
Those are NOT likely to be calculations that resolve to constants at compile time, given the layers of abstraction and indirection that appear to be standard for using these libraries.

So... just "wow."   There goes my confidence in libraries from ST.  It's not like I hunted through massive amounts of code looking for a bad example - the USART is about the third peripheral to deal with in the blink, hello-world progression.  (and then there's the reference back to that first peripheral - the rcc.  They derive, programaticaly and at significant expense, the clock frequency to divide.  I dunno.  That's not the way I would do things if I was writing the code.  Not close.  Bigger, slower, more obscure, harder to understand, and ... without obvious benefits.   Sigh.)
 

Online baoshi

  • Regular Contributor
  • *
  • Posts: 162
  • Country: sg
    • Digital Me
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #55 on: March 11, 2015, 09:22:41 PM »

You loose 90% of your target audience if the $10 board needs a $150 hobby license toolsuite  ;)

They could address that by adding support for plain Makefile based projects for gcc to STM32CubeMX (and I wish that they would). But then, based on how their headers are written, I bet it would be a ghastly mess that would make automake-generated makefiles look simple by comparison.  ::)

I made one.
http://www.ba0sh1.com/stm32cubemx-gcc-makefile/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #56 on: March 11, 2015, 10:32:42 PM »
I don't quite understand why anyone would want to waste time on Cube.
================================
https://dannyelectronics.wordpress.com/
 

Online baoshi

  • Regular Contributor
  • *
  • Posts: 162
  • Country: sg
    • Digital Me
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #57 on: March 11, 2015, 11:20:09 PM »

I don't quite understand why anyone would want to waste time on Cube.

Right. It helps me to understand how bad it is ;)
 

Offline kalhana

  • Contributor
  • Posts: 16
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #58 on: April 01, 2015, 12:06:08 PM »
Cube sucks. The only thing i find it useful for is planning pin usage in a processor.

I keep a policy of not using anyone elses code, only using my own. I have made exceptions from this for really atrocious stuff (USB, TCP, Modbus...) where i focused on getting somebody elses shit to work, but in general I only use my own code. I do use helper libraries like the ST's SPL, but only after i review the code line by line. I work from plain register definitons if need be. Save the "one code fits all" stuff for linux users with GHz's and GB's.

I have learned this while working with Mircochip's pic24f library, which gave me a week of hair-pulling because the library was not compatible with the mcu I was using (despite it claiming to be)... and the mcu had an extra configuration bit.

As for general quality:
ST: very good silicon, good documentation, SPL is ok, CUBE is shit
Atmel: silicon is ok, documentation is generally ok although sometimes lacking (mostly manageable after examining the examples provided), IDE is shit, or rather adapted to MCU use in a shitty way (no 'binary' display in debug mode? - come on!)
NXP: good silicon, good documentation, crappy policy towards low volume users, hobbyists and open source crowd (eg. they won't disclose the debugger protocol to OpenOCD people)
TI: good silicon, good documentation, ok libraries, but chips are expensive and they do not cover the lower range too well
Microchip: silicon=mostly shit, documentation os ok, compilers and IDE are shit. $40 genuine debugger is an example to show to other manufacturers
Freescale, Silabs/EnergyMicro, Cypress: can't say, I've never had much practical experience with them (i serious project I mean, I dabbled a bit with some low-end devboard)



Definitely agree with you about the STMCube. It's such a mess. I started with the STM32 back in 2009 when there was none of this complexity with massive levels of code abstraction. I still prefer to go down to register level custom code when it comes to STM32 and its peripherals.
I got a shock when I first installed Cube and the horrible code that it generated.   :--
I think I'm sticking to register level coding.

On the other hand, TI Hercules series MCUs have an excellent graphical code generator (HALCOGEN). That's a good example of how ST should have done it. HALCOGEN generates very clean code and very easy to follow, pretty much all the registers are assigned hard values when you click the generate code button rather than the MCU doing 20 lines of code to find 1 register's value.

I just wish that TI made M3/M4/M7 CPUs that had similar performance to what ST and NXP offer (fast clock speeds) aimed at multimedia type devices in addition to the industrial/automotive controller types that they currently do. And if they implemented HALCOGEN for M3/M4/M7, that would be awesome!
 ^-^
 

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 429
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #59 on: April 01, 2015, 05:16:50 PM »
I don't quite understand why anyone would want to waste time on Cube.

As pointed out before, it is handy for figuring out pins when designing a board.

I have never used the software before. As it turns out, Cube is not implemented for the F1 series  |O
 

Offline v

  • Contributor
  • Posts: 7
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #60 on: April 02, 2015, 01:47:24 AM »
The Cube looks like it has involved huge amount of work, and as @JohnnyBerg has mentioned it is great for board design.

It is such a shame that the code generation is so poor.

If you look in `Program Files (x86)/STMicroelectronics/STM32Cube/STM32CubeMX/db` you can find hundreds of XML files including: MCU pin mappings, all configuration options for peripherals for each different MCU, and all the file templates (`.ftl`) used to generate the code.

Collecting all the data in these XML files is awesome. If someone wanted to make a better Cube, all the data required is there.
 

Offline NVIC

  • Newbie
  • Posts: 2
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #61 on: April 02, 2015, 02:37:05 AM »

I have never used the software before. As it turns out, Cube is not implemented for the F1 series  |O

It exists.  Link at bottom of the page. 
http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF260820?icmp=pf260820_pron_pr_feb2015&sc=stm32cubef1-pr
 

Offline hamdi.tn

  • Frequent Contributor
  • **
  • Posts: 549
  • Country: tn
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #62 on: April 02, 2015, 04:49:56 AM »
Quote
I have never used the software before. As it turns out, Cube is not implemented for the F1 series

They added F1 series recently
 

Offline yuantuh

  • Newbie
  • Posts: 1
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #63 on: April 22, 2015, 09:47:07 PM »
I generated sw4stm32 project for stm32f427 (144 pins) prototype board using STMCubeMX 4.7.0 and imported it to Eclipse, working straightaway. Absolutely it is a great tool. So far I tested SDRAM (64MB), Ethernet (RMII), USB host (MSC using two pins), USB device (VCP using two pins), SDIO (1 bit), USART1, 2, 3, SPI 1, 3, 4, 5, I2C3, CAN1, and many EXTIs using generated HAL library. USART 6 and SPI6 are not tested due to no chip in it. All are working fine with minor HAL code modifications.

It is strange to say HAL is terrible. I am confident that ST will enhance and improve HAL in the future. Also sw4stm32 will be integrated into Eclipse better and better. Currently sw4stm32 project under Eclipse has some broken problems when changing properties, but it can easily be fixed by modifying the .cproject/.project files.

I used to write code for PIC8/16/24/32, MSP430, MC16, SAM7, ARM9 chips by accessing registers directly. Now it seems STMCubeMX and HAL make my life much easier.

The wonderful thing is that STMCubeMX can help me to figure out much more peripherals to be used.
 
 
The following users thanked this post: Vasi, thm_w

Offline Ribster

  • Regular Contributor
  • *
  • Posts: 148
  • Country: be
  • Electronics enthousiast. Mostly on STM32
    • Robbe's Workshop
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #64 on: May 20, 2015, 07:56:41 PM »
I tried the open STM32 stuff, but i find it not easy. From a perspective of an OS X user.
They support linux, maybe the toolchain is better there.
My experience with the GNU ARM eclipse plugin is much much better.
http://sourceforge.net/projects/gnuarmeclipse/
Veni Vidi Vagina - Ik kwam, en zag dat het kut was.
 

Offline Joerg

  • Newbie
  • Posts: 3
  • Country: de
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #65 on: November 07, 2015, 01:52:47 PM »
tl;dr The STM32/Cube software ecosystem is the worst I have ever seen. Does anyone feel the same? ...

Yes, I do :-) ... very much so indeed !! Actually I went through the same hell at the same time ... and now I'm back in it again :-(.

I'm into embedded development since the 1980s ... went through all of it, Intel, Motorola, Ti, Pic, ATmega, ... you name it. Thought nothing about it when I saw that a client had used the Stm32F4 for something which I needed to take and extend ... made the schematic, made the board, got it back and ... bang, hit my head in that unbelievable mess. For me the worst part ist that the internet is full of information and a lot of it is outdated but you don't know which part ... Everybody and his dog make their own stuff and it's all combined in every which way, IDEs, compilers, libraries, ... it never ends. The more I read about the possibilities the more confused I become. It's like Linux - instead of all people working by one consistent plan to achieve a single truly great product everybody does his own wrecked partial solution. I hate it (the STM stuff, not Linux as that started as a "hobby" so it has the right to develop however it wants to). I got a chance to work on something "more important" for half a year but now I'm back and wonder again what to use ... unbelievable. If there is a truly good solution which doesn't cost an arm and a leg ... let's hear it :-) ... I need to communicate with 3 chips over SPI at high speed, handle some ADC stuff in parallel and some RS485 too ... my main problem at the moment is the chip select of the SPI as that has to "flank" at the right bit at ~20MHz because these sensor chips otherwise can't talk straight. I thought that /CS (or /SS as they call it) had hardware support - which is true, but not for the usual case, only when the controller is the slave ... right ...
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #66 on: November 08, 2015, 11:40:54 AM »
my main problem at the moment is the chip select of the SPI as that has to "flank" at the right bit at ~20MHz because these sensor chips otherwise can't talk straight. I thought that /CS (or /SS as they call it) had hardware support - which is true, but not for the usual case, only when the controller is the slave ... right ...

Joerg, not entirely sure of your application, but you can use software slave management (which is what we use in the JumpStart API, for maximum flexibility in terms what pins to do), and you should be able to clock the GPIO pin as fast as you like. Certainly, ST claims up to 50 MHz (has not tried it myself).

// EDIT: Do you really mean CS at 20 MHz? How fast are you running the SPI?
« Last Edit: November 08, 2015, 11:55:08 AM by richardman »
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Offline Ribster

  • Regular Contributor
  • *
  • Posts: 148
  • Country: be
  • Electronics enthousiast. Mostly on STM32
    • Robbe's Workshop
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #67 on: November 08, 2015, 07:02:12 PM »
Joerg,

I think you need to make the /CS purely software based and use DMA.
The half transfer complete / transfer complete interrupts will let you know when the DMA is done, and then you can change the /CS.
Hope it helps..

Greetings
Veni Vidi Vagina - Ik kwam, en zag dat het kut was.
 

Offline autobot

  • Regular Contributor
  • *
  • Posts: 65
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #68 on: November 09, 2015, 10:01:46 AM »
How can  we fix it ?

Today, many large companies don't care much about such libraries - because it's more efficient to write from scratch - and at their volumes - it makes sense. Sadly they hold all the power in the market. we just eat their leftovers  :palm:

But if it was as efficient to use higher level libraries , while remaining as efficient - it would be great for those companies - faster time to market is very valuable. If it was possible - those big companies would pressure ST and others on their libraries , and we would get better libraries.

That's one thing. The second thing is , unlike the situation with TI's good tools(halcogen) - which don't push the market towards tools , because TI sells chips for more money because of the tools/libraries - we need high quality tools to be availble to many companies. , so we need to make it much easier than today to build those tools.

Well it's actually possible to build extremely efficient libraries relatively easily - using compile-time compute (using c++11 's constexpr keyword). Here's a blog post with an example:

http://blog.xpcc.io/2015/06/08/computing-and-asserting-baudrate-settings-at-compile-time/

Using such advanced c++ and a few other tricks, a german robotic club , written , as a side effort - an extremely efficient mcu library for a variety of mcu's. it's called xpcc:

example of efficiency:
http://comments.gmane.org/gmane.comp.hardware.arm.cortex.xpcc.devel/16

site:xpcc.io

So relatively easy to write , very efficient tools/techniques are possible. What's needed in extent (not sure) is to raise awareness ,and maybe port the technique to where it would be most effective to push vendors, etc.

Sounds reasonable ?


« Last Edit: November 09, 2015, 10:25:41 AM by autobot »
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #69 on: November 09, 2015, 11:16:56 AM »
Well it's actually possible to build extremely efficient libraries relatively easily - using compile-time compute (using c++11 's constexpr keyword). Here's a blog post with an example:

http://blog.xpcc.io/2015/06/08/computing-and-asserting-baudrate-settings-at-compile-time/

Using such advanced c++

C++ is not even required and this is nothing new :-+

It just takes skilled developers (who tend to get better jobs than writing ST's HAL :P) and time (which bean-counters don't want to pay for) to write non-bloated libraries that aren't total shite.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Joerg

  • Newbie
  • Posts: 3
  • Country: de
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #70 on: November 09, 2015, 03:51:42 PM »
my main problem at the moment is the chip select of the SPI as that has to "flank" at the right bit at ~20MHz because these sensor chips otherwise can't talk straight. I thought that /CS (or /SS as they call it) had hardware support - which is true, but not for the usual case, only when the controller is the slave ... right ...

Joerg, not entirely sure of your application, but you can use software slave management (which is what we use in the JumpStart API, for maximum flexibility in terms what pins to do), and you should be able to clock the GPIO pin as fast as you like. Certainly, ST claims up to 50 MHz (has not tried it myself).

// EDIT: Do you really mean CS at 20 MHz? How fast are you running the SPI?

Thank you Richard and also Ribster,

yes, I guess I have to "bit-bang" that line ... Problem is that when I designed the board I only read the spec of the STM32 and they describe the SPI as having hardware support for the NSS ... so my whole plan about how much the chip would be busy with that task is now in doubt ... I really have many things to do in "real time" (its a racing telemetry application) and it's battery driven. I thought I could just set up there two channels, connect them to the DMA and be done ... now the processor has to da that but then that will increase the jitter of other stuff and some of that is highly time critical. Sorry about the 20 MHz ... these sensor chips run slower, but must be timed exactly in sync - the 3rd SPI has to run like hell @ maximum speed ... I'll see what I can get in reality. Right now I still struggle with the darn tools :-) ... Thought we live in the digital millenium and all but my speed would not have been much less had I just started to write assembly the first day I got confronted with all this and made m own symbols for the register addresses ... or at least that's how it feels at the momen :-) ...

 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 1608
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #71 on: November 10, 2015, 01:41:54 AM »
But if it was as efficient to use higher level libraries , while remaining as efficient - it would be great for those companies - faster time to market is very valuable. If it was possible - those big companies would pressure ST and others on their libraries , and we would get better libraries.
I really like the mbed library, because it is very object oriented and easy to use. STM32Cube and other graphical code generation tools help you to create the initial boilerplate code and to manage the modules on a chip and the GPIO pins, but if using the serial module is just a one liner for a class-instantiation (with sensible default initialization), you don't need such tools. embed is already ported to a lot of platforms, see here. Besides the online IDE you can download it for offline compilation, too.

It might not be as fast as possible (I don't think it uses C++11 features for compile-time baud rate rate devider generation and the like), but with modern chips some overhead doesn't matter, if it greatly simplifies programming. And it has a lot of additional high-level stuff for reading sensor etc., too.
quadro copter flying, electronics, retro computing and other geeky things: http://www.youtube.com/user/frankbuss/
 

Offline Ribster

  • Regular Contributor
  • *
  • Posts: 148
  • Country: be
  • Electronics enthousiast. Mostly on STM32
    • Robbe's Workshop
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #72 on: November 14, 2015, 10:20:19 PM »
so my whole plan about how much the chip would be busy with that task is now in doubt ... I really have many things to do in "real time" (its a racing telemetry application) and it's battery driven. I thought I could just set up there two channels, connect them to the DMA and be done ... now the processor has to da that but then that will increase the jitter of other stuff and some of that is highly time critical.

I don't think it is an issue here..
Use timers. Let those timers interrupt the CPU at a fixed rate.
If you make sure that this timer has the highest interrupt priority, it will be reliable.
At each interrupt, do the necessary telemetry stuff, and poll the sensors if necessary.
This also has the advantage that you get an exact timestamp of sampling. This can be valuable for logging.

A seperate timer interrupt that handles the sensor readout over SPI via DMA is possible as well.
I don't see any issues as to what you want to do, just make sure you prioritize the right things and all will be okay.
Good luck!
Veni Vidi Vagina - Ik kwam, en zag dat het kut was.
 

Offline geno86

  • Newbie
  • Posts: 1
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #73 on: December 03, 2015, 03:04:01 AM »
I have spent hours of frustration with the STM32 Cube like most people here. My solution may seem a little crazy, but it works.

I wrote all the hardware drivers and a lot of the upper level software myself. I used the reference manual, datasheet, and the Cube as a guide. For the past couple of years it seems to work well. I got many peripherals on the STM32F4 working, and relatively quickly. For the most part, do what the reference manual says, look at the Cube as a guide on how to go about it.

The ARM Cortex M4 is a really good series of chips. Very powerful. But sometimes its easier and faster to reinvent the wheel than use someone elses code with 100 bandaids.

 
 

Offline gnasirator

  • Contributor
  • Posts: 21
  • Country: nz
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #74 on: February 18, 2016, 11:58:05 AM »
I do quite like the Cube. Works flawlessly for me. I'm using Atollic TrueStudio Free together with it and a discovery board as programmer. Works a treat and is cheap.
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #75 on: February 20, 2016, 03:20:56 AM »
I wrote all the hardware drivers and a lot of the upper level software myself. I used the reference manual, datasheet, and the Cube as a guide. For the past couple of years it seems to work well. I got many peripherals on the STM32F4 working, and relatively quickly. For the most part, do what the reference manual says, look at the Cube as a guide on how to go about it.

This.  :-+

Most vendor libraries are bloated and bug-ridden and not worth using for anything except perhaps a simple application. I always write my own low-level drivers at the register level and only include the functionality I actually need rather than implementing everything the chip supports like the vendor libraries do.
Never trust a government that doesn't trust you.
 

Offline MobileWill

  • Regular Contributor
  • *
  • Posts: 59
  • Country: 00
    • Mobilewill Blog
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #76 on: February 27, 2016, 07:59:21 AM »
I am working on a STM32 project and dumped CubeMX for ChibiOS. It has its own HAL, support for many STM32 micros and others, and many examples. Sorry if someone mentioned it, I didn't read all the posts. A bit late to the party here. Its been smooth sailing since I dumped STM32CubeMX.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #77 on: February 27, 2016, 02:31:55 PM »
Does ChibiOS for XXX actually include things like peripheral drivers?  I would have expected "ChibiOS over CUBE" to be equivalent to "Unix instead of assembler"...
 

Offline MobileWill

  • Regular Contributor
  • *
  • Posts: 59
  • Country: 00
    • Mobilewill Blog
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #78 on: February 27, 2016, 02:44:27 PM »
Does ChibiOS for XXX actually include things like peripheral drivers?  I would have expected "ChibiOS over CUBE" to be equivalent to "Unix instead of assembler"...

Yes! Has support for lots of stuff, even SDIO, and LTDC. Also uses DMA where possible.
 

Offline mhelin

  • Contributor
  • Posts: 6
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #79 on: April 01, 2016, 06:18:03 PM »
I have found CubeMX quite useful now as it's integrated to SW4STM (Eclipse), though I don't like the idea of adding own implementation between some special comment lines - it would be nice to have Java annotations in C to markup own code snippets. Regarding the snippets, there are the STM32 Snippets (library/interface) for L0 and F0 which allow for using direct register access (without HAL layers, though being able to co-exist with the HAL libraries). It would be nice to have the Snippets for F1 .. F7 families as well.

Snippets: http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1898/PF260157


 

Offline mhelin

  • Contributor
  • Posts: 6
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #80 on: April 01, 2016, 06:34:59 PM »
Actually I don't know if all HAL implementations (for different families) are equal. For an example the STM32CubeL4 page (http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF261908) says:

"STM32Cube includes the STM32CubeMX which is a graphical software configuration tool that allows generating C initialization code using graphical wizards. It also comprises the STM32CubeL4 platform composed of the STM32Cube HAL and the Low Layer (LL) APIs, plus a consistent set of middleware components (RTOS, USB, FatFS, graphics and STM32 touch sensing). All embedded software utilities come with a full set of examples running on STMicroelectronics boards.

The STM32Cube HAL is an STM32 embedded software stack that ensures a maximized portability across STM32 portfolio, while the LL APIs make up a fast, light-weight, expert-oriented layer which is closer to the hardware than the HAL. HAL and LL APIs can be used simultaneously.

Both the HAL and LL APIs are production-ready and have been developed in compliance with MISRA-C guidelines and ISO/TS 16949. On top of that, ST specific validation processes add a deeper-level qualification.

STM32CubeL4 gathers in one single package all the generic embedded software components required to develop an application on STM32L4 microcontrollers. Following STM32Cube initiative, this set of components is highly portable, not only within STM32L4 series but also to other STM32 series. In addition, the Low Layer APIs provide an alternative, high-performance, low-footprint solution to the STM32CubeL4 HAL at the cost of portability and simplicity."

Maybe it's just that F4 family is missing the LL API?


 

Offline jeremy

  • Frequent Contributor
  • **
  • Posts: 695
  • Country: au
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #81 on: April 01, 2016, 07:42:46 PM »
I've had bad experiences with the library since the very first discovery board, and when you still had to compile your own gcc to get hard float support. Dropping to the register level makes it better (as others have mentioned)

On the other hand, the TI Tiva devices are absolutely excellent, with a great library and great documentation. But the trade off there is the price  :(
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #82 on: April 02, 2016, 02:20:29 AM »
The Freescale Kinetis devices used to have good documentation. Now it reads like it was written by someone for whom English is a second or third language.
Never trust a government that doesn't trust you.
 

Offline savril

  • Regular Contributor
  • *
  • Posts: 60
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #83 on: April 02, 2016, 07:35:43 AM »
Actually I don't know if all HAL implementations (for different families) are equal. For an example the STM32CubeL4 page (http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF261908) says:

...
Maybe it's just that F4 family is missing the LL API?

This document from ST show the roadmap (p. 12) : http://www.st.com/st-web-ui/static/active/en/resource/sales_and_marketing/presentation/product_presentation/stm32_embedded_software_offering.pdf
So LL is scheduled for January 2017.
 
The following users thanked this post: jnz

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #84 on: April 02, 2016, 08:25:18 AM »
The Freescale Kinetis devices used to have good documentation. Now it reads like it was written by someone for whom English is a second or third language.
Very well possible since they have been bought by nxp
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #85 on: April 02, 2016, 08:49:08 AM »
Quote
So LL is scheduled for January 2017.

What they don't understand is that if they don't stick to ONE library, people will not invest in their code thus their chips. No one in his/her right mind will use a library knowing that it is going to be gone, or be changed out soon.

ST's problem from day one has been its incompetent software developers.
================================
https://dannyelectronics.wordpress.com/
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #86 on: April 02, 2016, 09:02:12 AM »
The Freescale Kinetis devices used to have good documentation. Now it reads like it was written by someone for whom English is a second or third language.
Very well possible since they have been bought by nxp

The first language I had in mind is Chinese, not Dutch.
Never trust a government that doesn't trust you.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #87 on: April 02, 2016, 04:24:57 PM »
Quote
What they don't understand is that if they don't stick to ONE library, people will not invest in their code thus their chips. No one in his/her right mind will use a library knowing that it is going to be gone, or be changed out soon.
Amen!  It's not even clear that one of the earlier libraries couldn't be fixed, rather than replaced.

Quote
ST's problem from day one has been its incompetent software developers.
I dunno.  ONE bad library can be blamed on incompetent/inexperienced (intern?) developers.  By the time you get to four or five different poor sets of libraries, it might be time to move the blame to management.  (Is there any sign that ST has been listening to the nature of complaints from the users?)

And where is the OSSW community?  You'd think that by now at least some of the "problems" (initial chip/peripheral configuration, say) would have been solved by some snazzy chip-agnostic code generator...

 
 

Offline Back2Volts

  • Supporter
  • ****
  • Posts: 322
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #88 on: April 03, 2016, 06:16:24 AM »
tl;dr The STM32/Cube software ecosystem is the worst I have ever seen. Does anyone feel the same? How can we fix it?

Send a link to this thread to ST public relations
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #89 on: April 03, 2016, 07:38:29 AM »
Quote
So LL is scheduled for January 2017.
What they don't understand is that if they don't stick to ONE library, people will not invest in their code thus their chips. No one in his/her right mind will use a library knowing that it is going to be gone, or be changed out soon.
I tend to agree with you however reading their library philosophy (if you may call it that) it looks like:
- the (old) peripheral libraries were not very good and incompatible with newer ones so strike those, they are there only for backward compatibility.
- the Cube HAL libraries are intended for (non embedded) SW engineers without HW (register) knowledge, API in C++ OO style. It is in progress but if you ask me that project is overambitious, in the sense that through a GUI you can autocally create all the code including third party (bloat)middleware and it should work? That would be great if they can pull it off, from what I read in this thread they are not succeeding. Maybe one day...
- the Cube LL libraries are the next gen of the old peripheral libraries more intended for embedded SW C programmers and are compatible with the Cube HAL libraries.
It looks like they have some sort of plan, not to phase out anything before a new replacement is there, but dunno if the quality is bad people will not invest to start with  :-//
 

Offline Koen

  • Frequent Contributor
  • **
  • Posts: 294
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #90 on: April 03, 2016, 08:34:48 AM »
ST should buy ChibiOS HAL and work from there. It's clean, practical, efficient, correct and easily understandable.
 

Online technix

  • Super Contributor
  • ***
  • Posts: 1359
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #91 on: April 12, 2016, 10:40:09 PM »
If you feel adventurous you can throw the STM32Cube software itself out of the window, keeping its libraries and headers, but use your own IDE and toolchain.

When I researched the WCH CH563 chips their libraries are Keil-only, using their proprietary format. I borrowed a friend's Keil installation to transcompile all their libraries into GCC-compatible ELF format (with optimization cranked to max,) and on my own computer (OS X, not even compatible with Keil) I set up clang/LLVM (GCC-compatible) and OpenOCD as my own development toolchain.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #92 on: April 12, 2016, 11:05:02 PM »
"Reply #90   by Koen on 03 Apr, 2016 08:34
ST should buy ChibiOS HAL and work from there. It's clean, "

Probably not.

The proven solution in this space is freescales PE.

RTE from Keil is pretty good but too new at this point . but is does provide a cross platform solution.
================================
https://dannyelectronics.wordpress.com/
 

Offline eck

  • Contributor
  • Posts: 15
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #93 on: April 12, 2016, 11:19:26 PM »
The proven solution in this space is freescales PE.

... which seems to be on the way out as KSDK 2.0 isn't supporting PE anymore.
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #94 on: April 13, 2016, 12:53:20 AM »
I guess the real crime I'm seeing is that despite their new LL being far simpler than the HAL, they have some versions that are out this month and some that will be out in 2017 :/

It's just a mild difference in headers and some work arounds for each chip - what could possibly take so long!?

Why would anyone use the LL lib for the L4 chips if it doesn't exist yet for the chips people actually buy like the F1/F2/F4!? Damn ST... Get it together!
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1578
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #95 on: April 13, 2016, 01:56:00 AM »
I just gave up on Cube/HAL and only using Cube to for pin planning and perhaps calculation of the some of the register values (like clock dividers).

For the rest - it is either ChibiOS or libopencm3  (http://libopencm3.org/) when I don't need the RTOS. Especially the latter has a fairly small footprint. A bonus is that there are tons of examples that just work out of the box, even for complex things like USB.

 

Offline stmdude

  • Frequent Contributor
  • **
  • Posts: 260
  • Country: se
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #96 on: April 13, 2016, 01:59:54 AM »
Regarding the LL libs..

There's no way in a very warm place I'll even attempt to use that.
If it's just the lower parts of the HAL, it _will_ suck, as the HAL was, by far, the buggiest vendor-library I've had the misfortune of trying to use in production..

I'll keep using StdPeriph for all the chips that it works on, and bang on the hardware directly for the chips where it doesn't..
Sure StdPeriph isn't ideal (functionality differs between STM32 chip families), but it does work.

I really like working with the STM32 chips (heck, see my nick on the forum), but somehow I find myself using them less and less these days.. They simply don't fit my designs any more. And, it's not because of software. There's no integrated RF connectivity, very high cost, and can't go low enough in power-consumption (for most of the STM32s).

The designs where I used to use the STM32s in were projects where you needed a beefy MCU to drive a display or similar. However, for the price of (for example) an STM32F429, I can easily get a Cortex-A7+RAM+PMIC these days..  Sure, larger footprint, but usually not an issue if you have a design with a display in it.

For low-power stuff, with small footprint, ST is at least one generation behind people like Silicon Labs EFM32, Nordic Semi and Dialog. Nordic and Dialog even have built-in radios...  And, they're still cheaper than the low-power variants of STM32s..
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #97 on: April 13, 2016, 02:46:38 AM »
"Damn ST... Get it together!"

That can be hard to do. I think St is rub by a nxp guy in disguise. Otherwise how do you explain their I cohrent software strategy? And a website that makes it impossible to use.

As to criticizing at software, be careful here. I got banned for simply pointing the apparent struggles some ST software developers had communicating to a wireless module over spi - check out that thread for your self. After that I wonder no more why St software sucks big time.

As to stdperipheral libs, I continue to use then to get thing up and running - I find them generally free of bugs. But I do rewrite my own when time permits.

Cube and Hal? I wouldn't touch it. I figured that when stdperipheral no longer works for my chip, I just go to rte.
================================
https://dannyelectronics.wordpress.com/
 

Online blueskull

  • Supporter
  • ****
  • Posts: 6136
  • Country: cn
  • Final year EE PhD
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #98 on: April 13, 2016, 06:47:37 AM »
I'm happy with STM32CubeMX for now. At least with MDKv5 and Nucleus. BTW, MDKv5 is free is you use only CM0 and CM0+ devices form ST -- ST has already paid for the license.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline epv

  • Newbie
  • Posts: 2
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #99 on: April 15, 2016, 05:59:58 AM »
I registered just to whine here about it, too. I do like the java app for setting up pin assignments, clocks, and initialization stuff. I don't like the buggy code and hideously overcomplicated APIs that obfuscate basic functions and that you have to use in ways nobody would ever actually use a peripheral.

The stm32f1 USART stuff is espcially awful. And if you try to write code for the USB peripheral on a computer with a case sensitive filesystem, you discover that Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Src/usbd_cdc.c inexplicably uses an all uppercase filename for one include file, which happens nowhere else. I guess someone's caps lock key got stuck on.

I spent a few hours banging my head against i2c on f103 last night, and it still won't even toggle the clock line in master mode. I'll probably end up just writing a bitbanged version and not use the hardware. I assume the f103 has bogus i2c stuff that needs workarounds and the HAL libraries do it wrong, or something?
Anyway, sigh. I'm thinking about moving to other hw.
« Last Edit: April 15, 2016, 06:03:31 AM by epv »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #100 on: April 15, 2016, 07:45:31 AM »
Quote
banging my head against i2c on f103 last night, and it still won't even toggle the clock line in master mode.

That has been a very well known problem on some STM32/8 parts. The stock STM i2c examples do not work on those parts.

However, the datasheet is ABSOLUTELY right: if you code to the datasheet, it will work. The problem is that the ST StdPeriph library developers did not follow their own datasheets on those parts, :)
================================
https://dannyelectronics.wordpress.com/
 

Offline epv

  • Newbie
  • Posts: 2
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #101 on: April 15, 2016, 01:56:34 PM »
And it seems they've carried over that nonfunctionality into CubeMX, too!  :)
 

Offline eck

  • Contributor
  • Posts: 15
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #102 on: April 15, 2016, 05:23:07 PM »
Anyway, sigh. I'm thinking about moving to other hw.

Try the EFM32 family from SiLabs, you'll be pleasantly surprised. Both HW and SW just works.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1578
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #103 on: April 16, 2016, 12:29:25 AM »
Quote
banging my head against i2c on f103 last night, and it still won't even toggle the clock line in master mode.

That has been a very well known problem on some STM32/8 parts. The stock STM i2c examples do not work on those parts.

However, the datasheet is ABSOLUTELY right: if you code to the datasheet, it will work. The problem is that the ST StdPeriph library developers did not follow their own datasheets on those parts, :)

Yep, be very very careful to read both the datasheet and the errata for f103 parts. Otherwise you could end up banging your head against a wall for weeks only because there is an interrupt with higher priority messing things up due to a bug in the silicon :(

Otherwise, both libopencm3 and ChibiOS have a working I2C driver along with some examples, so you could have a peek at their code and check what values are set in the registers. Both STDPeriph and HAL had bugs that either set some values wrong or did not set some bit and then the hw just doesn't work, so I am not surprised that you have issues.

I2C on these chips is fairly non-trivial, you must wait for various flags to be set and states reached, otherwise the whole thing just hangs and does not work right.


« Last Edit: April 16, 2016, 12:32:47 AM by janoc »
 

Online splin

  • Frequent Contributor
  • **
  • Posts: 382
  • Country: gb
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #104 on: April 16, 2016, 10:53:20 AM »

I2C on these chips is fairly non-trivial, you must wait for various flags to be set and states reached, otherwise the whole thing just hangs and does not work right.

So, I guess the next question has to be does bit-banging code take fewer bytes of code space than a proper H/W I2C driver if speed is not an issue?

[EDIT] typo
« Last Edit: April 17, 2016, 01:31:48 AM by splin »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #105 on: April 16, 2016, 11:06:19 AM »
Quote
it seems they've carried over that nonfunctionality into CubeMX, too!

No wonder that Cube sucks, ;)
================================
https://dannyelectronics.wordpress.com/
 

Online splin

  • Frequent Contributor
  • **
  • Posts: 382
  • Country: gb
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #106 on: April 17, 2016, 02:52:08 AM »
For low-power stuff, with small footprint, ST is at least one generation behind people like Silicon Labs EFM32, Nordic Semi and Dialog. Nordic and Dialog even have built-in radios...  And, they're still cheaper than the low-power variants of STM32s..

Not sure what you mean by one generation behind? As far as I can see the STM32L4 devices have similar, if not lower core power consumption to any of the Silicon Devices Geckos including the latest Jade and Pearl products which are much slower, have only 32K RAM and have less comprehensive peripherals apart from the crypto unit. The L4's ADC is much faster and uses rather less power (at the same speed), but I've not looked at the power consumption of other peripherals.

Neither Nordic or Dialog publish power consumption for their latest devices but Nordic are claiming 58 coremarks/mA for the nRF52 which is impressive - twice as good as the L4 (though reduced from the 90 they originally claimed). However mAs aren't mWs - they could be quoting 3.3V figures rather than 1.8V. Dialog use the M0 core so probably nowhere near as good as the L4 for mW/MHz.

The L4 parts are expensive but I assume that is because they are higher end parts and targetting a different market with USB and LCD peripherals in some parts. I would guess that the range will be extended to cheaper, lower end parts eventually but I've no idea if they will get cheap enough for the wireless sensor market.

As for the packaging - the smallest currently offered is WLCSP72, 4.4 x 3.75mm compared to the smallest pearl/jade devices which are 5mmx5mm.

ST don't yet offer integrated radio but they have licensed Semtech's LoRa sub GHz radio technology but I've no idea when they will come to market. Another thing the L4 lack are built in DC-DC convertors, unlike the others, which saves board space for battery powered devices.

For low power I doubt that Ambiq Micro can be beaten - they are claiming a breakthrough 35uA/MHz for their sub-threshold technology which is way better (3 to 4X) than any other Cortex product that I've heard of. Definately one to watch and probably worrying ST and Silicon Labs.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1578
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #107 on: April 17, 2016, 05:55:20 AM »

I2C on these chips is fairly non-trivial, you must wait for various flags to be set and states reached, otherwise the whole thing just hangs and does not work right.

So, I guess the next question has to be does bit-banging code take fewer bytes of code space than a proper H/W I2C driver if speed is not an issue?

[EDIT] typo

Well, I dare to say that if you bitbang it, it will likely take less code, at least for the most common use cases. The setup and babysitting you need to do during transfer using the I2C hardware are fairly non-trivial. However, you lose things like DMA if you bitbang, so it is not so clear-cut.

 

Offline autobot

  • Regular Contributor
  • *
  • Posts: 65
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #108 on: April 17, 2016, 07:26:02 AM »

For low power I doubt that Ambiq Micro can be beaten - they are claiming a breakthrough 35uA/MHz for their sub-threshold technology which is way better (3 to 4X) than any other Cortex product that I've heard of. Definately one to watch and probably worrying ST and Silicon Labs.

Ambiq wants to license their sub-threshold design platform, which is the secret behind this chip, so ST and Silicon Labs don't need to worry, just collaborate.
 

Offline neslekkim

  • Super Contributor
  • ***
  • Posts: 1218
  • Country: no
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #109 on: April 18, 2016, 02:23:33 AM »
ST don't yet offer integrated radio but they have licensed Semtech's LoRa sub GHz radio technology but I've no idea when they will come to market. Another thing the L4 lack are built in DC-DC convertors, unlike the others, which saves board space for battery powered devices.

STM32W?, seems like some radio there, but havent found them in an discovery kit yet.
 

Online splin

  • Frequent Contributor
  • **
  • Posts: 382
  • Country: gb
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #110 on: April 18, 2016, 08:32:04 AM »

For low power I doubt that Ambiq Micro can be beaten - they are claiming a breakthrough 35uA/MHz for their sub-threshold technology which is way better (3 to 4X) than any other Cortex product that I've heard of. Definately one to watch and probably worrying ST and Silicon Labs.

Ambiq wants to license their sub-threshold design platform, which is the secret behind this chip, so ST and Silicon Labs don't need to worry, just collaborate.

That's great news - much better for us all that exciting new technology gets thoroughly and rapidly exploited rather than the inventors drip feeding it to the market agonizing slowly because they don't have sufficient funding, resources or because it suits their business plan.
 

Online splin

  • Frequent Contributor
  • **
  • Posts: 382
  • Country: gb
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #111 on: April 18, 2016, 08:37:53 AM »
ST don't yet offer integrated radio but they have licensed Semtech's LoRa sub GHz radio technology but I've no idea when they will come to market. Another thing the L4 lack are built in DC-DC convertors, unlike the others, which saves board space for battery powered devices.

STM32W?, seems like some radio there, but havent found them in an discovery kit yet.

Your right, I'd forgotten their Zigbee device - though it was somewhat stymied when they appear to have lost the rights to use the Zigbee stack software when Silicon Labs bought out Ember, the company that wrote it.
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #112 on: May 17, 2016, 08:32:31 AM »
This document from ST show the roadmap (p. 12) : http://www.st.com/st-web-ui/static/active/en/resource/sales_and_marketing/presentation/product_presentation/stm32_embedded_software_offering.pdf
So LL is scheduled for January 2017.

Page12.... Anyone want to guess when the L0, F0, F3 actually come out? Because my guess is not last month, this month, next month :\


Does anyone have an couple libs or drivers for specific peripherals where they used the HAL as legit headers - but then wrote their own register level and not-garbage functions instead using ST's? Because while I'm waiting for the LL drivers and code snippets to come into existence, it seems this is my only logical option.  Use the HAL where I have to but not waste all of my time trying to poorly replace ST's bloated code with my sub-par code.

So, any examples of this being done correctly would be helpful! Anyone?

EDIT: Current plan is to examine the STM Snippets and see how they're laid out.
« Last Edit: May 17, 2016, 09:00:53 AM by jnz »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #113 on: May 17, 2016, 01:05:44 PM »
Did you see the "one minute one dollar ARM" thread a while back?  Summary, some code, and pointers here: https://github.com/WestfW/Minimal-ARM
 
The following users thanked this post: jnz

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #114 on: May 17, 2016, 02:47:27 PM »
Did you see the "one minute one dollar ARM" thread a while back?  Summary, some code, and pointers here: https://github.com/WestfW/Minimal-ARM

Thanks for the idea, but assembly is a no-go (too hard to glance and see what it's doing) and libs exist for a reason. In my specific needs, I have an RTOS and interrupts, if I make my peripheral functions in assembly I'd be shooting myself in the foot later on. (At least for me that's likely true)
 
The following users thanked this post: gbyleveldt

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #115 on: May 17, 2016, 06:56:02 PM »
Another question is: perhaps other vendors have better library support? I love the STM32F for many reasons, but surely some NXP or Atmel parts may serve your needs as well, and might have better library support for what you need? Some times switching may be easier than fighting bad software :-)
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #116 on: May 17, 2016, 07:43:40 PM »
In all fairness, STM32F 1,2,3,4 uC's are sold in the hundreds of millions, in devices that operate 24/7.
So if many companies are able to launch decent products with the same libraries why can't someone else?

My guess is that its not only the STM libraries at fault although an easy target and must say I have problems with them myself. But at least I admit I don't spent enough time to dig in and get it done.
Something you would do if you were paid for it by a company, you would dig in and solve it.

The ARM 32 bit world is just a very large step up from the 8 bit world (have that experience myself) and it takes a lot more time and effort to get things going and feel comfortable.
Esp. if you take on extra heavy software stacks like TCP/IP it can be overwhelming.
But there is not that much difference between all the controllers and manufacturers out there.
Yeah NXP has this code red thing but your hardware locked and the controllers are more expensive and less choice, but if you go that way, and it works than you should definitely do it.

But just to blame the libraries could be an excuse not to invest more time to get things going.
The same problem will be encountered by other manufacturers ARM chips or one should buy an all in one package with middleware etc. and the already finished project so you just have to press the compile button. So yeah it is not plug and play but it definitely is also not Mission STM Impossible 6.

BTW: if it was easy to fix, someone here would have already done it.
« Last Edit: May 17, 2016, 07:48:34 PM by Kjelt »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #117 on: May 17, 2016, 10:24:07 PM »
"But just to blame the libraries could be an excuse not to invest more time to get things going. "

You are spit on on many fronts.

Those chips are considerably more complex to get going. Many aspects of embedded programming that are taking for granted on the 8bit chips have to be taken care explicitly here.

Because of the complexity, more is required out of the user as well as the software.

Programming takes more and more a tone of software engineering: more modulized approach, more data structures, more thoughts on the overall system architecture that are minimal to non existent on 8bit machines.

All of that translates into considerable pains for an average Joe to transition into an 32bitbchip than for a formally trained programmer.

================================
https://dannyelectronics.wordpress.com/
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #118 on: May 18, 2016, 03:32:30 AM »
My guess is that its not only the STM libraries at fault although an easy target and must say I have problems with them myself. But at least I admit I don't spent enough time to dig in and get it done.
Something you would do if you were paid for it by a company, you would dig in and solve it.

I've worked in the embedded industry for over 30 years and for many companies, and never have I worked at a company that used vendor libraries. We always wrote our own peripheral driver code.

We did this for several reasons. First, vendor code is often bug ridden to the extent that it takes almost as much time to debug it than it does to write custom code. Second, vendor libraries have to accommodate every feature of every peripheral for all of the MCUs in a particular family. This makes the libraries very large and convoluted in the vendor's attempt to cover all of these cases. When we wrote drivers, we only wrote code that addressed the specific features we needed on the specific MCU we were using. Our code was cleaner, neater, and considerably more bug-free than any vendor library code I've ever seen.
Never trust a government that doesn't trust you.
 
The following users thanked this post: Xenoamor

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1578
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #119 on: May 18, 2016, 03:38:12 AM »
All of that translates into considerable pains for an average Joe to transition into an 32bitbchip than for a formally trained programmer.

Trust me, I have a PhD in computer science and "upgrading" to ARM from an 8bit AVR or 18F PIC series was quite a bit of a learning curve even for me. Being formally trained does not make you immune to the all the crappy tools relying on broken GUIs and impenetrable libraries with poor/no documentation.

E.g. nobody heard about a make/CMake in this world? No wonder people don't want to use for example Eclipse, because using the default project-based system with it takes almost 2 hours of clicking to get a basic project set up ... Having the same generated from CMake makes it a breeze. 


 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 647
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #120 on: May 18, 2016, 04:15:22 AM »
[...] vendor libraries have to accommodate every feature of every peripheral for all of the MCUs in a particular family. This makes the libraries very large and convoluted in the vendor's attempt to cover all of these cases.
Bingo!
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #121 on: May 18, 2016, 05:18:28 AM »
" never have I worked at a company that used vendor libraries. "

Not sure how statistically true that is. In my experience, it is largely true, or at least frequently true.

However, I have seen thebuse of vendor libraries in real commercial projects. I think keil had some launch customers liked forbits rte as well.

================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #122 on: May 18, 2016, 05:20:55 AM »
"When we wrote drivers, we only wrote code that addressed the specific features we needed on the specific MCU we were using."

That kind approach works if cost or time isn't an issue. For 99.99 percent of the applications, that's not the case.
================================
https://dannyelectronics.wordpress.com/
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #123 on: May 18, 2016, 05:48:57 AM »
"When we wrote drivers, we only wrote code that addressed the specific features we needed on the specific MCU we were using."

That kind approach works if cost or time isn't an issue. For 99.99 percent of the applications, that's not the case.

I'm not following how that costs more. I read that as we made an UART library that works for us, didn't add anything to do with LIN and won't until we need that feature for a future project.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #124 on: May 18, 2016, 07:33:57 AM »
First, vendor code is often bug ridden to the extent that it takes almost as much time to debug it than it does to write custom code.
All software has bugs also if you write the custom code. The difference is that the vendor libraries are open source and youre not the first and only customer. If there are major bugs you will read about it and also if there is a solution, if not you can always comment out the buggy stuf and write that part on your own.
In your custom code bugs can stay hidden for years and make life miserable for your customers.

Quote
Second, vendor libraries have to accommodate every feature of every peripheral for all of the MCUs in a particular family. This makes the libraries very large and convoluted in the vendor's attempt to cover all of these cases.
Come on, if you do not use a certain peripheral you don,t include it in your project, it costs nothing.
There is some overhead yeah but it often outweighs starting from scratch.
Also you can use the vendors code pure as guideline for a custom rewrite, still you will use it somehow, somewhere.

Quote
When we wrote drivers, we only wrote code that addressed the specific features we needed on the specific MCU we were using. Our code was cleaner, neater, and considerably more bug-free than any vendor library code I've ever seen.
How many man months did it take? How much did it cost? How do you know for certain it has less bugs than the vendor code if you not even used it in the first place?
I am not saying it was not a good decision for your example since i do not know the facts but i have been a SW engineer for over 20 years and I have met lots and lots of colleagues that are suffering from the so called "not written by me or us" syndrome that costs companies an enormous amount of money and in the end does not always deliver a better end result.
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #125 on: May 18, 2016, 08:36:01 AM »
Quote
Second, vendor libraries have to accommodate every feature of every peripheral for all of the MCUs in a particular family. This makes the libraries very large and convoluted in the vendor's attempt to cover all of these cases.
Come on, if you do not use a certain peripheral you don,t include it in your project, it costs nothing.
There is some overhead yeah but it often outweighs starting from scratch.
Also you can use the vendors code pure as guideline for a custom rewrite, still you will use it somehow, somewhere.

I'm not talking about having to use code for peripherals I don't need, I'm talking about drivers for peripherals that support every single feature that peripheral has, including ones that I don't use. It's hard to exclude that code because a lot of the vendor libraries I've seen have large functions that handle every single option a peripheral device has, often in a huge switch statement. To exclude the functions I don't need would require editing the code, which can be problematical because a lot of this code is pure spaghetti.

It's often been speculated here that vendor libraries are written by summer interns. Based on most of this code I've seen, I believe it. While there may be exceptions that I haven't seen, what I have seen I would classify as utter crap.
Never trust a government that doesn't trust you.
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #126 on: May 18, 2016, 09:05:32 AM »
When we wrote drivers, we only wrote code that addressed the specific features we needed on the specific MCU we were using. Our code was cleaner, neater, and considerably more bug-free than any vendor library code I've ever seen.
How many man months did it take? How much did it cost? How do you know for certain it has less bugs than the vendor code if you not even used it in the first place?
I am not saying it was not a good decision for your example since i do not know the facts but i have been a SW engineer for over 20 years and I have met lots and lots of colleagues that are suffering from the so called "not written by me or us" syndrome that costs companies an enormous amount of money and in the end does not always deliver a better end result.

It probably cost less than using a buggy vendor library would have. I'm willing to bet that our code had fewer bugs than typical vendor code. We did thorough code reviews with people familiar with our hardware and our application--I doubt you can prove to me that generic open source code perused by Larry, Daryl, and Daryl out on the Internet is in any way better.
« Last Edit: May 19, 2016, 02:25:17 AM by Sal Ammoniac »
Never trust a government that doesn't trust you.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #127 on: May 18, 2016, 10:50:47 AM »
" ome on, if you do not use a certain peripheral you don,t include it in your project, it costs nothing"

I think this fear of "excessive" code come from people who are stuck in the stone ages. Modern compilers have the ability to trim unused code from the executable, and such ability has existed for decades.

A typical hobby project for me includes my application specific code, my own library, vendor library and my own substitutes, and cmsis for for the arm chips. The libraries covers all peripherals whether I use them or not - I don't want to spend my time trimming the code when the computer can do it for me.

A work project would be quite similar.
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #128 on: May 18, 2016, 10:52:56 AM »
" It's often been speculated here that vendor libraries are written by summer interns"

It is probably not terribly smart to make decisions on speculation shared with you by unknown strangers on the internet.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #129 on: May 18, 2016, 04:58:17 PM »
Quote
Modern compilers have the ability to trim unused code from the executable
One of the specific complains against the vendor libraries is that they've been written in a way that makes this sort of code-trimming nearly impossible.
Fancy macros?  Nope.  Static inline functions that rely/count on constant parameters cause most of the code to "drop out"?  Nope.  Separate functions for wildly separate modes?  Hmm - maybe (it looks like Cube/HAL could be a bit better at that than some other libraries I've seen (looking at the UART/USART code.  The RCC (clock control) code is still really sucky, with a single OscConfig() function that handles ALL possible clock setups...)

People aren't looking at the source and saying "OMG this is so huge!", they're looking at their binaries, scratching their heads "Why is this so big?", and THEN looking at the source code and gagging.   The lack of some of the "tricks" mentioned above is also one of the clues leading to the "written by interns" suggestions - too many school-like "mannerisms" and not enough signs that the author has any experience writing code for smallish systems.


(there was an earlier thread where I cut down code size significantly just by #including the C code instead of (in addition to) the .h files (allowing the compiler to "see" more optimization possibilities.)  IIRC, that was with the older ST "Standard peripheral library", though.) (Umm...  http://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/msg522553/#msg522553 )

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #130 on: May 18, 2016, 05:00:23 PM »
BTW, it IS really nice to have the source code of the various vendor libraries to look at, even if I don't like it.  It's probably even better to have the several different versions to look at...)
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #131 on: May 18, 2016, 05:26:20 PM »
I don't need, I'm talking about drivers for peripherals that support every single feature that peripheral has, including ones that I don't use. It's hard to exclude that code because a lot of the vendor libraries I've seen have large functions that handle every single option a peripheral device has, often in a huge switch statement.
So to put it sarcastically: actually you are complaining that a peripheral has too many functionality that you don't need/use but then blame the vendor for supporting all these functions?
Either you have less functionality (different uC, different peripherals) or you support what is available from a vendor POV.

Yes sure you can write your own peripheral or just delete the part of the "spaghetti" you don't use but as Danny said the compiler can do this for you.
The risk you take is that you have a non-feature complete peripheral driver.and that a few years from now you do need some of that peripheral functionality you have not supported and someone in the company again has to dive in the datasheets to see how this is done. Probably the person who skipped it in the first place and at that time does not have room in his agenda to again spent time on this ;)
A good practice if you want company (vendor independent) HAL is to write a company defined glue layer on top of the vendors HAL, but that will cost additional codesize.

Quote
It's often been speculated here that vendor libraries are written by summer interns. Based on most of this code I've seen, I believe it. While there may be exceptions that I haven't seen, what I have seen I would classify as utter crap.
Sure and risk the companies net worth on a couple of interns? That sounds what a billion$ company would do  :scared:
No, what I could believe is that some of the early libraries from ST were build by HW engineers that have learned to write software instead of software engineers. Probaly the same team as responsible for part of the HW itself. The good thing is that at least they know how their peripheral should be configured to operate as expected so you can use at least this code as example.
BTW I have also seen HALs from experienced software engineers where most HW engineers/embedded SW engineers could not work with. To give an example we had this new uC prototype from the vendor (so nothing of any kind of SW available)  and it had tiny ROM so each byte counted.
What a 20 yr experienced EE educated embedded SW engineer did was write the entire peripheral/clock/interrupt configuration in a very elaborate X-macro.
Actually this was mis using the X-macro principle to its fullest but hey the result was tiny!
Now this worked great if you did exactly how it was supposed to work.
Then came these SW educated SW engineers and all they did was complain because they could not understand the concept of the X-macro, the SCA tool could not understand it and if you made a tiny mistake (a ,  or ; missed) the whole x-macro would explode but did not show exactly where the problem occurred in that macro. So brilliant, but a nightmare to work with unless you knew exactly what you were doing.

IMO SW is a field of work where you can bitch about much more than HW.
In SW it is very easy to change things, get used to a specific style of coding you personally prefer and if you put 5 SW engineers in a room and tell them to write a simple program they all do it their way and if you ask them to choose the best one there will be a catfight. There are lots of "best practices" some contradicting eachother, newer insights and on and on. If you are used of working in a 30 man SW team you are tired of the coffee corner discussions about this. 
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #132 on: May 18, 2016, 05:46:50 PM »
It probably cost less than using a buggy vendor library would have. I'm willing to bet that our code had fewer bugs than typical vendor code.
As said all code has bugs, the statistical chance that a bug will be found, reported and fixed in an open source software project is many times larger than in own closed source code unless the company has a strict code analysis and review strategy in place.

Quote
We did thorough code reviews with people familiar with our hardware and our application--I doubt you can prove to me that generic open source code perused at by Larry, Daryl, and Daryl out on the Internet is in any way better.
Neither can you prove that yours is better since there is no absolute way of comparing.
I can ask you some SW quality questions that give me a good gutfeeling about your code quality, for instance do you Lint the code and run additional SCA tools on your code like HP Fortify or Coverity?

Anyway we are living in a century where a single company is not able to produce all its software itself neither is it necessary. We don't write our own email and wordprocessor software now do we? Why because some other company does that for us. So why would you for instance still write your own TCP/IP stack or TLS stack. You buy it or take an opensource version like OpenSSL. The most important thing left and forgotten by a lot of companies becomes SW lifecycle management, you should keep track of found bugs, updates on parts of the code and update your product.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #133 on: May 18, 2016, 07:20:26 PM »
For an example of ST's HAL code, I give you this ... well, take a look:

#define __HAL_DMA_GET_TC_FLAG_INDEX(__HANDLE__) \
(((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA1_Stream0))? DMA_FLAG_TCIF0_4 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA2_Stream0))? DMA_FLAG_TCIF0_4 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA1_Stream4))? DMA_FLAG_TCIF0_4 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA2_Stream4))? DMA_FLAG_TCIF0_4 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA1_Stream1))? DMA_FLAG_TCIF1_5 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA2_Stream1))? DMA_FLAG_TCIF1_5 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA1_Stream5))? DMA_FLAG_TCIF1_5 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA2_Stream5))? DMA_FLAG_TCIF1_5 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA1_Stream2))? DMA_FLAG_TCIF2_6 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA2_Stream2))? DMA_FLAG_TCIF2_6 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA1_Stream6))? DMA_FLAG_TCIF2_6 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA2_Stream6))? DMA_FLAG_TCIF2_6 :\

Could they have written it as a switch? Probably. A jump table? May be. A mapping table? For sure! A 12 nested conditional that depends on all sort of optimizations to make it into efficient code?!! Sure, why not, if you are ST.
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #134 on: May 18, 2016, 08:07:22 PM »
But what is the problem if it works? You just use the macro with the correct handle and it solves it for you. I have seen worse VHDL code but then it is ok?  ;)
It looks more neat than if you wrote it in a function with al if()'s explicitly but then I am used to macros and a lot of people hate them so that is a personal preference.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #135 on: May 18, 2016, 08:11:44 PM »
An alternative would be something like this which you need three parameters and other stuff but if you only want to know the single thing as in your code I could live better with that solution.

Code: [Select]
/**
  * @brief  Checks whether the specified DMAy Streamx flag is set or not.
  * @param  DMAy_Streamx: where y can be 1 or 2 to select the DMA and x can be 0
  *          to 7 to select the DMA Stream.
  * @param  DMA_FLAG: specifies the flag to check.
  *          This parameter can be one of the following values:
  *            @arg DMA_FLAG_TCIFx:  Streamx transfer complete flag
  *            @arg DMA_FLAG_HTIFx:  Streamx half transfer complete flag
  *            @arg DMA_FLAG_TEIFx:  Streamx transfer error flag
  *            @arg DMA_FLAG_DMEIFx: Streamx direct mode error flag
  *            @arg DMA_FLAG_FEIFx:  Streamx FIFO error flag
  *         Where x can be 0 to 7 to select the DMA Stream.
  * @retval The new state of DMA_FLAG (SET or RESET).
  */
FlagStatus DMA_GetFlagStatus(DMA_Stream_TypeDef* DMAy_Streamx, uint32_t DMA_FLAG)
{
  FlagStatus bitstatus = RESET;
  DMA_TypeDef* DMAy;
  uint32_t tmpreg = 0;

  /* Check the parameters */
  assert_param(IS_DMA_ALL_PERIPH(DMAy_Streamx));
  assert_param(IS_DMA_GET_FLAG(DMA_FLAG));

  /* Determine the DMA to which belongs the stream */
  if (DMAy_Streamx < DMA2_Stream0)
  {
    /* DMAy_Streamx belongs to DMA1 */
    DMAy = DMA1;
  }
  else
  {
    /* DMAy_Streamx belongs to DMA2 */
    DMAy = DMA2;
  }

  /* Check if the flag is in HISR or LISR */
  if ((DMA_FLAG & HIGH_ISR_MASK) != (uint32_t)RESET)
  {
    /* Get DMAy HISR register value */
    tmpreg = DMAy->HISR;
  }
  else
  {
    /* Get DMAy LISR register value */
    tmpreg = DMAy->LISR;
  }   
 
  /* Mask the reserved bits */
  tmpreg &= (uint32_t)RESERVED_MASK;

  /* Check the status of the specified DMA flag */
  if ((tmpreg & DMA_FLAG) != (uint32_t)RESET)
  {
    /* DMA_FLAG is set */
    bitstatus = SET;
  }
  else
  {
    /* DMA_FLAG is reset */
    bitstatus = RESET;
  }

  /* Return the DMA_FLAG status */
  return  bitstatus;
}
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #136 on: May 18, 2016, 10:36:16 PM »
" Could they have written it as a switch? "

Sure. But there are many roads one can take. Had it written as a switch, or any other implementation, I'm sure someone somewhere would ask if it could be implemented in their favorite way.

End of the day, we just need to realize that any implementation decision we make is a compromise. Unless you can articulate why the said implementation is bad, it is best to just learn to use it.

In this particular case, the implementation is quite clear to me.
================================
https://dannyelectronics.wordpress.com/
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #137 on: May 18, 2016, 11:43:36 PM »
Exactly and what you did not show is that there is also comment, which is of the utmost importance and everyone that ever coded knows what it does.

Code: [Select]
/**
66   * @brief  Returns the current DMA Channel transfer complete flag.
67   * @param  __HANDLE__: DMA handle
68   * @retval The specified transfer complete flag index.
69   */
 
The following users thanked this post: jnz

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #138 on: May 19, 2016, 02:20:47 AM »
I don't need, I'm talking about drivers for peripherals that support every single feature that peripheral has, including ones that I don't use. It's hard to exclude that code because a lot of the vendor libraries I've seen have large functions that handle every single option a peripheral device has, often in a huge switch statement.
So to put it sarcastically: actually you are complaining that a peripheral has too many functionality that you don't need/use but then blame the vendor for supporting all these functions?

No, I blame the vendor for implementing these libraries as collections of huge, monolithic functions instead of modular code that handles peripheral functionality in small, modular pieces.

Quote
Yes sure you can write your own peripheral or just delete the part of the "spaghetti" you don't use but as Danny said the compiler can do this for you.

Sure, the linker can exclude functions in a library that you don't call, but how does it exclude code in a huge monolithic function that implements support for every possible option a peripheral has? How does the compiler know what code will execute at runtime? Answer: it doesn't and it can't. The linker pulls this entire huge function into your binary even if you use just a tiny piece of it. Clock initialization code is a good example. This is typically implemented as a huge function that handles every possible clock configuration option, which on a modern ARM MCU, for example, can run to dozens of different combinations.

Quote
The risk you take is that you have a non-feature complete peripheral driver.and that a few years from now you do need some of that peripheral functionality you have not supported and someone in the company again has to dive in the datasheets to see how this is done. Probably the person who skipped it in the first place and at that time does not have room in his agenda to again spent time on this ;)

This is one of the most ridiculous arguements I've ever seen and I'm not going to spend another second addressing it...

Quote
Probaly the same team as responsible for part of the HW itself. The good thing is that at least they know how their peripheral should be configured to operate as expected so you can use at least this code as example.

This is another bone I have to pick with MCU vendors. Sometimes you are forced to look at their library source code to figure out how a peripheral works because it's not properly documented in the datasheet, user guide, and/or errata. This drives me nuts and makes me want to immediately look for a better part. Trouble is, it's such a common practice in the industry that it's hard to avoid.  |O
Never trust a government that doesn't trust you.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #139 on: May 19, 2016, 02:51:31 AM »
This is one of the most ridiculous arguements I've ever seen and I'm not going to spend another second addressing it...
You will think back of it (and spent time) when someone after a long period asks a new feature or update where you will need a certain configuration of one of the peripherals that was not implemented the first time, been there  :)
And then you will probably again go through:
Quote from: Sal Ammoniac
Sometimes you are forced to look at their library source code to figure out how a peripheral works because it's not properly documented in the datasheet, user guide, and/or errata.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #140 on: May 19, 2016, 03:04:43 AM »
Quote
#define __HAL_DMA_GET_TC_FLAG_INDEX(__HANDLE__) \
(((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA1_Stream0))? DMA_FLAG_TCIF0_4 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA2_Stream0))? DMA_FLAG_TCIF0_4 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA1_Stream4))? DMA_FLAG_TCIF0_4 :\
((uint32_t)((__HANDLE__)->Instance) == ((uint32_t)DMA2_Stream4))? DMA_FLAG_TCIF0_4 :\

That would be acceptable, or even desirable, if it's used in a context where __HANDLE__ and __HANDLE__->Instance are constants and the whole expression resolves to a constant at compile time...

But here: I'll throw up the clock initialization function, which I think is really hard to justify...
Code: [Select]
/**
  * @brief  Initializes the RCC Oscillators according to the specified parameters in the
  *         RCC_OscInitTypeDef.
  * @param  RCC_OscInitStruct pointer to an RCC_OscInitTypeDef structure that
  *         contains the configuration information for the RCC Oscillators.
  * @note   The PLL is not disabled when used as system clock.
  * @note   The PLL is not disabled when USB OTG FS clock is enabled (specific to devices with USB FS)
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_RCC_OscConfig(RCC_OscInitTypeDef  *RCC_OscInitStruct)
{
   uint32_t tickstart = 0;
 
  /* Check the parameters */
  assert_param(RCC_OscInitStruct != NULL);
  assert_param(IS_RCC_OSCILLATORTYPE(RCC_OscInitStruct->OscillatorType));
 
  /*------------------------------- HSE Configuration ------------------------*/
  if(((RCC_OscInitStruct->OscillatorType) & RCC_OSCILLATORTYPE_HSE) == RCC_OSCILLATORTYPE_HSE)
  {
    /* Check the parameters */
    assert_param(IS_RCC_HSE(RCC_OscInitStruct->HSEState));
       
    /* When the HSE is used as system clock or clock source for PLL in these cases it is not allowed to be disabled */
    if((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_SYSCLKSOURCE_STATUS_HSE)
       || ((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_SYSCLKSOURCE_STATUS_PLLCLK) && (__HAL_RCC_GET_PLL_OSCSOURCE() == RCC_PLLSOURCE_HSE)))
    {
      if((__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) != RESET) && (RCC_OscInitStruct->HSEState == RCC_HSE_OFF))
      {
        return HAL_ERROR;
      }
    }
    else
    {
      /* Reset HSEON and HSEBYP bits before configuring the HSE --------------*/
      __HAL_RCC_HSE_CONFIG(RCC_HSE_OFF);
     
      /* Get Start Tick */
      tickstart = HAL_GetTick();
     
      /* Wait till HSE is disabled */ 
      while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) != RESET)
      {
        if((HAL_GetTick() - tickstart ) > HSE_TIMEOUT_VALUE)
        {
          return HAL_TIMEOUT;
        }
      }
     
      /* Set the new HSE configuration ---------------------------------------*/
      __HAL_RCC_HSE_CONFIG(RCC_OscInitStruct->HSEState);
     

       /* Check the HSE State */
      if(RCC_OscInitStruct->HSEState != RCC_HSE_OFF)
      {
        /* Get Start Tick */
        tickstart = HAL_GetTick();
       
        /* Wait till HSE is ready */
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) == RESET)
        {
          if((HAL_GetTick() - tickstart ) > HSE_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }
      }
      else
      {
        /* Get Start Tick */
        tickstart = HAL_GetTick();
       
        /* Wait till HSE is bypassed or disabled */
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) != RESET)
        {
           if((HAL_GetTick() - tickstart ) > HSE_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }
      }
    }
  }
  /*----------------------------- HSI Configuration --------------------------*/
  if(((RCC_OscInitStruct->OscillatorType) & RCC_OSCILLATORTYPE_HSI) == RCC_OSCILLATORTYPE_HSI)
  {
    /* Check the parameters */
    assert_param(IS_RCC_HSI(RCC_OscInitStruct->HSIState));
    assert_param(IS_RCC_CALIBRATION_VALUE(RCC_OscInitStruct->HSICalibrationValue));
   
    /* Check if HSI is used as system clock or as PLL source when PLL is selected as system clock */
    if((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_SYSCLKSOURCE_STATUS_HSI)
       || ((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_SYSCLKSOURCE_STATUS_PLLCLK) && (__HAL_RCC_GET_PLL_OSCSOURCE() == RCC_PLLSOURCE_HSI_DIV2)))
    {
      /* When HSI is used as system clock it will not disabled */
      if((__HAL_RCC_GET_FLAG(RCC_FLAG_HSIRDY) != RESET) && (RCC_OscInitStruct->HSIState != RCC_HSI_ON))
      {
        return HAL_ERROR;
      }
      /* Otherwise, just the calibration is allowed */
      else
      {
        /* Adjusts the Internal High Speed oscillator (HSI) calibration value.*/
        __HAL_RCC_HSI_CALIBRATIONVALUE_ADJUST(RCC_OscInitStruct->HSICalibrationValue);
      }
    }
    else
    {
      /* Check the HSI State */
      if(RCC_OscInitStruct->HSIState != RCC_HSI_OFF)
      {
       /* Enable the Internal High Speed oscillator (HSI). */
        __HAL_RCC_HSI_ENABLE();
       
        /* Get Start Tick */
        tickstart = HAL_GetTick();
       
        /* Wait till HSI is ready */
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSIRDY) == RESET)
        {
          if((HAL_GetTick() - tickstart ) > HSI_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }
               
        /* Adjusts the Internal High Speed oscillator (HSI) calibration value.*/
        __HAL_RCC_HSI_CALIBRATIONVALUE_ADJUST(RCC_OscInitStruct->HSICalibrationValue);
      }
      else
      {
        /* Disable the Internal High Speed oscillator (HSI). */
        __HAL_RCC_HSI_DISABLE();
       
        /* Get Start Tick */
        tickstart = HAL_GetTick();
       
        /* Wait till HSI is disabled */
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSIRDY) != RESET)
        {
          if((HAL_GetTick() - tickstart ) > HSI_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }
      }
    }
  }
  /*------------------------------ LSI Configuration -------------------------*/
  if(((RCC_OscInitStruct->OscillatorType) & RCC_OSCILLATORTYPE_LSI) == RCC_OSCILLATORTYPE_LSI)
  {
    /* Check the parameters */
    assert_param(IS_RCC_LSI(RCC_OscInitStruct->LSIState));
   
    /* Check the LSI State */
    if(RCC_OscInitStruct->LSIState != RCC_LSI_OFF)
    {
      /* Enable the Internal Low Speed oscillator (LSI). */
      __HAL_RCC_LSI_ENABLE();
     
      /* Get Start Tick */
      tickstart = HAL_GetTick();
     
      /* Wait till LSI is ready */ 
      while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSIRDY) == RESET)
      {
        if((HAL_GetTick() - tickstart ) > LSI_TIMEOUT_VALUE)
        {
          return HAL_TIMEOUT;
        }
      }
      /*  To have a fully stabilized clock in the specified range, a software temporization of 1ms
          should be added.*/
      HAL_Delay(1);
    }
    else
    {
      /* Disable the Internal Low Speed oscillator (LSI). */
      __HAL_RCC_LSI_DISABLE();
     
      /* Get Start Tick */
      tickstart = HAL_GetTick();
     
      /* Wait till LSI is disabled */ 
      while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSIRDY) != RESET)
      {
        if((HAL_GetTick() - tickstart ) > LSI_TIMEOUT_VALUE)
        {
          return HAL_TIMEOUT;
        }
      }
    }
  }
  /*------------------------------ LSE Configuration -------------------------*/
  if(((RCC_OscInitStruct->OscillatorType) & RCC_OSCILLATORTYPE_LSE) == RCC_OSCILLATORTYPE_LSE)
  {
    /* Check the parameters */
    assert_param(IS_RCC_LSE(RCC_OscInitStruct->LSEState));
   
    /* Enable Power Clock*/
    __HAL_RCC_PWR_CLK_ENABLE();
   
    /* Enable write access to Backup domain */
    SET_BIT(PWR->CR, PWR_CR_DBP);

    /* Wait for Backup domain Write protection disable */
    tickstart = HAL_GetTick();
   
    while((PWR->CR & PWR_CR_DBP) == RESET)
    {
      if((HAL_GetTick() - tickstart ) > RCC_DBP_TIMEOUT_VALUE)
      {
        return HAL_TIMEOUT;
      }     
    }
   
    /* Reset LSEON and LSEBYP bits before configuring the LSE ----------------*/
    __HAL_RCC_LSE_CONFIG(RCC_LSE_OFF);
   
    /* Get Start Tick */
    tickstart = HAL_GetTick();
   
    /* Wait till LSE is disabled */ 
    while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSERDY) != RESET)
    {
      if((HAL_GetTick() - tickstart ) > RCC_LSE_TIMEOUT_VALUE)
      {
        return HAL_TIMEOUT;
      }
    }
   
    /* Set the new LSE configuration -----------------------------------------*/
    __HAL_RCC_LSE_CONFIG(RCC_OscInitStruct->LSEState);
    /* Check the LSE State */
    if(RCC_OscInitStruct->LSEState != RCC_LSE_OFF)
    {
      /* Get Start Tick */
      tickstart = HAL_GetTick();
     
      /* Wait till LSE is ready */ 
      while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSERDY) == RESET)
      {
        if((HAL_GetTick() - tickstart ) > RCC_LSE_TIMEOUT_VALUE)
        {
          return HAL_TIMEOUT;
        }
      }
    }
    else
    {
      /* Get Start Tick */
      tickstart = HAL_GetTick();
     
      /* Wait till LSE is disabled */ 
      while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSERDY) != RESET)
      {
        if((HAL_GetTick() - tickstart ) > RCC_LSE_TIMEOUT_VALUE)
        {
          return HAL_TIMEOUT;
        }
      }
    }
  }

#if defined(RCC_CR_PLL2ON)
  /*-------------------------------- PLL2 Configuration -----------------------*/
  /* Check the parameters */
  assert_param(IS_RCC_PLL2(RCC_OscInitStruct->PLL2.PLL2State));
  if ((RCC_OscInitStruct->PLL2.PLL2State) != RCC_PLL2_NONE)
  {
    /* This bit can not be cleared if the PLL2 clock is used indirectly as system
      clock (i.e. it is used as PLL clock entry that is used as system clock). */
    if((__HAL_RCC_GET_PLL_OSCSOURCE() == RCC_PLLSOURCE_HSE) && \
        (__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_SYSCLKSOURCE_STATUS_PLLCLK) && \
        ((READ_BIT(RCC->CFGR2,RCC_CFGR2_PREDIV1SRC)) == RCC_CFGR2_PREDIV1SRC_PLL2))
    {
      return HAL_ERROR;
    }
    else
    {
      if((RCC_OscInitStruct->PLL2.PLL2State) == RCC_PLL2_ON)
      {
        /* Check the parameters */
        assert_param(IS_RCC_PLL2_MUL(RCC_OscInitStruct->PLL2.PLL2MUL));
        assert_param(IS_RCC_HSE_PREDIV2(RCC_OscInitStruct->PLL2.HSEPrediv2Value));

        /* Prediv2 can be written only when the PLLI2S is disabled. */
        /* Return an error only if new value is different from the programmed value */
        if (HAL_IS_BIT_SET(RCC->CR,RCC_CR_PLL3ON) && \
          (__HAL_RCC_HSE_GET_PREDIV2() != RCC_OscInitStruct->PLL2.HSEPrediv2Value))
        {
          return HAL_ERROR;
        }
       
        /* Disable the main PLL2. */
        __HAL_RCC_PLL2_DISABLE();
       
        /* Get Start Tick */
        tickstart = HAL_GetTick();
       
        /* Wait till PLL2 is disabled */
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLL2RDY) != RESET)
        {
          if((HAL_GetTick() - tickstart ) > PLL2_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }
       
        /* Configure the HSE prediv2 factor --------------------------------*/
        __HAL_RCC_HSE_PREDIV2_CONFIG(RCC_OscInitStruct->PLL2.HSEPrediv2Value);

        /* Configure the main PLL2 multiplication factors. */
        __HAL_RCC_PLL2_CONFIG(RCC_OscInitStruct->PLL2.PLL2MUL);
       
        /* Enable the main PLL2. */
        __HAL_RCC_PLL2_ENABLE();
       
        /* Get Start Tick */
        tickstart = HAL_GetTick();
       
        /* Wait till PLL2 is ready */
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLL2RDY)  == RESET)
        {
          if((HAL_GetTick() - tickstart ) > PLL2_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }
      }
      else
      {
       /* Set PREDIV1 source to HSE */
        CLEAR_BIT(RCC->CFGR2, RCC_CFGR2_PREDIV1SRC);

        /* Disable the main PLL2. */
        __HAL_RCC_PLL2_DISABLE();
 
        /* Get Start Tick */
        tickstart = HAL_GetTick();
       
        /* Wait till PLL2 is disabled */ 
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLL2RDY)  != RESET)
        {
          if((HAL_GetTick() - tickstart ) > PLL2_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }
      }
    }
  }

#endif /* RCC_CR_PLL2ON */
  /*-------------------------------- PLL Configuration -----------------------*/
  /* Check the parameters */
  assert_param(IS_RCC_PLL(RCC_OscInitStruct->PLL.PLLState));
  if ((RCC_OscInitStruct->PLL.PLLState) != RCC_PLL_NONE)
  {
    /* Check if the PLL is used as system clock or not */
    if(__HAL_RCC_GET_SYSCLK_SOURCE() != RCC_SYSCLKSOURCE_STATUS_PLLCLK)
    {
      if((RCC_OscInitStruct->PLL.PLLState) == RCC_PLL_ON)
      {
        /* Check the parameters */
        assert_param(IS_RCC_PLLSOURCE(RCC_OscInitStruct->PLL.PLLSource));
        assert_param(IS_RCC_PLL_MUL(RCC_OscInitStruct->PLL.PLLMUL));
 
        /* Disable the main PLL. */
        __HAL_RCC_PLL_DISABLE();
       
        /* Get Start Tick */
        tickstart = HAL_GetTick();
       
        /* Wait till PLL is disabled */
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLLRDY)  != RESET)
        {
          if((HAL_GetTick() - tickstart ) > PLL_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }

        /* Configure the HSE prediv factor --------------------------------*/
        /* It can be written only when the PLL is disabled. Not used in PLL source is different than HSE */
        if(RCC_OscInitStruct->PLL.PLLSource == RCC_PLLSOURCE_HSE)
        {
          /* Check the parameter */
          assert_param(IS_RCC_HSE_PREDIV(RCC_OscInitStruct->HSEPredivValue));
#if defined(RCC_CFGR2_PREDIV1SRC)
          assert_param(IS_RCC_PREDIV1_SOURCE(RCC_OscInitStruct->Prediv1Source));
         
          /* Set PREDIV1 source */
          SET_BIT(RCC->CFGR2, RCC_OscInitStruct->Prediv1Source);
#endif /* RCC_CFGR2_PREDIV1SRC */

          /* Set PREDIV1 Value */
          __HAL_RCC_HSE_PREDIV_CONFIG(RCC_OscInitStruct->HSEPredivValue);
        }

        /* Configure the main PLL clock source and multiplication factors. */
        __HAL_RCC_PLL_CONFIG(RCC_OscInitStruct->PLL.PLLSource,
                             RCC_OscInitStruct->PLL.PLLMUL);
        /* Enable the main PLL. */
        __HAL_RCC_PLL_ENABLE();
       
        /* Get Start Tick */
        tickstart = HAL_GetTick();
       
        /* Wait till PLL is ready */
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLLRDY)  == RESET)
        {
          if((HAL_GetTick() - tickstart ) > PLL_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }
      }
      else
      {
        /* Disable the main PLL. */
        __HAL_RCC_PLL_DISABLE();
 
        /* Get Start Tick */
        tickstart = HAL_GetTick();
       
        /* Wait till PLL is disabled */ 
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLLRDY)  != RESET)
        {
          if((HAL_GetTick() - tickstart ) > PLL_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }
      }
    }
    else
    {
      return HAL_ERROR;
    }
  }
 
  return HAL_OK;
}
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #141 on: May 19, 2016, 04:25:33 AM »
But here: I'll throw up the clock initialization function, which I think is really hard to justify...

Barf!  :palm:  My code, which does essentially the same thing, is 25 lines of code.
Never trust a government that doesn't trust you.
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #142 on: May 19, 2016, 04:43:31 AM »
Barf!  :palm:  My code, which does essentially the same thing, is 25 lines of code.

While I largely agree with you... My issue with statements like this is no one ever posts up their code. No one puts their money where their mouth is.

It's not like peripheral libs are some dangerous proprietary code...
 

Offline Koen

  • Frequent Contributor
  • **
  • Posts: 294
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #143 on: May 19, 2016, 05:59:54 AM »
Yes, ChibiOS and libopencm3 would surely welcome patches from such incredibly talented programmers who write improved libraries from scratch !
 
The following users thanked this post: jnz

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #144 on: May 19, 2016, 06:21:45 AM »
Ha ha, OK, now we know you guys have not looked at assembly code much or efficient coding in C ;-)

Yes, in theory, a compiler should "do what I mean" but...
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #145 on: May 19, 2016, 06:23:03 AM »
Quote
But here: I'll throw up the clock initialization function, which I think is really hard to justify.
Been awhile since i worked with those but what i remember is that if you want to switch between the clocks external / internal /   high speed / low speed you can,t just flip a bit and be done or things go terribly wrong. You have to wait for certain conditions with the pll to arise etc and then switch.
When you only want to use one clock source like the HSE then you can delete all the rest or better add some #ifdefs  to loose it through a user config file BUT again if some requirements change like say you need to power down in low power mode till some interrupt occurs or some requirement like that, you again need that code.
So the code is there to be tweaked but at least it is complete. I would be much more upset if they would have given the HSE as example and left the rest for the user to figure out.
So yeah you can tweak it if you like to save 50 bytes of code or so, then I do wonder with a 128kB ROM to even 1MB of ROM who cares that much about that. Did you ever take a look at OpenSSL or CYASSL(WolfSSL) how much that costs?
And please do give us a better rewrite of that code but mind it should still work and be complete.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #146 on: May 19, 2016, 06:31:49 AM »
Most M0 only has 32K...
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #147 on: May 19, 2016, 06:37:37 AM »
All software has bugs also if you write the custom code. The difference is that the vendor libraries are open source and youre not the first and only customer. If there are major bugs you will read about it and also if there is a solution, if not you can always comment out the buggy stuf and write that part on your own.

OpenSSL is open source. How long was the heartbleed vulnerability in that code before someone exploited it? Why didn't all of those hoards and hoards of eyes looking at it day and night find and fix it before it became a major headache?
« Last Edit: May 19, 2016, 08:32:43 AM by Sal Ammoniac »
Never trust a government that doesn't trust you.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #148 on: May 19, 2016, 07:07:24 AM »
" When you only want to use one clock source like the HSE then you can delete all the rest or"

Precisely. I have a set of routines that would switch me to hsi, HSE, hsipll and hsepll, among others. Then I write a routine that switches me to any of those based on the clock configuration. With that, the code is tight if you wish to a known target clock, or easy to read if you wish to retain the flexibility if run time user configurable clock.

St simply messed up the layering of their clock modules and tried to write an all encompassing module in one function. Total incompetency if you ask me.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #149 on: May 19, 2016, 10:11:59 AM »
Quote
if you want to switch between the clocks external / internal /   high speed / low speed
Because doing that is SO common?  I don't think so!  (that's one of the big objections.)  Average use case is that you set up the clock at startup and it stays at that rate, and/or stops completely in low-power sleep modes.


Quote
at least it is complete. I would be much more upset if they would have given the HSE as example and left the rest for the user to figure out.
I can agree with that.  And it's pretty readable, too.  It might be an interesting exercise to "fix" the HAL code to the point where it's someone more acceptable, without descending into "maximally efficient by incomprehensible" status.   Separate init routines for each clock type and a "static inline" wrapper would help a lot.

It also bothers me that the clock function is NOT easy to use.  It's pretty much "fill in a data structure with a bunch of obscure parameters that you'll have to study the datasheet to understand", and then we'll copy those into the appropriate registers."  All the cost of abstraction with none of the benefits. :-(


Quote
So yeah you can tweak it if you like to save 50 bytes of code or so
It's not a "50 byte" savings.   More like 1000 bytes.  For code that SHOULD be about 50 bytes.  My most recent experience is with Atmel ARM chips and their ASF library (which is very similar.)  The clock initialization code was about 1kbytes.  This was for a SAMD10 that only had 16k, so that was particularly depressing, but it's a pretty significant hit even on a 128k part.  (I checked: The SAMD10 "Blink an LED" example program has 1072 bytes of system clock functions.)


Quote
no one ever posts up their code.
I did.  http://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/msg551553/#msg551553
(Implements: static inline void SimpleClockInit(long cpuspeed, long xtalspeed);  Use xtalspeed=0 for the internal oscillator, doesn't currently handle low speed oscillators (but could.)  It does rely on the compiler being pretty intelligent about compile-time evaluation of constant expressions to get full 'efficiency')

There's also an assembler macro here: https://github.com/WestfW/Minimal-ARM/blob/master/inc/WestfwMacros.S

Mind you, I don't have the evangelistic energy to re-write that for a dozen different chip variations, do the requisite testing for all the possible cases, and push it into various OSSW projects or at vendors...  And vendors/ OSSW administrators have a (justifiable) resistance to importing new code that is "merely faster and smaller" if it's less general (witness the failure of Arduino to adopt any of the "fast" versions of digitalWrite())
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #150 on: May 19, 2016, 03:17:39 PM »
I can see why people would want to switch between HSE/HSI etc. For example, one might want to use HSE, but then if the crystal fails somehow, it should drop back down to HSI.

re: system clock setup function
On fear that someone will accuse me on "spamming" again, it does not have to be hard to define a simple to use function API. I am on the road, but our clock function is as simple as

jsapi_clock.setSystemClock(unsigned hsi_mhz, unsigned hse_mhz, unsigned pll_mhz, int wait_states);

if hsi_mhz is non-zero, it is forced to whatever HSI is for that series, e.g. 8 for F0xx and 16 for F4xx etc. Otherwise, hse_mhz should be non-zero. If pll_mhz is non-zero, the function computes the PLLx values and set them up for you.

It is not rocket science to write simple API that works for 90% of the people 90% of the time (or whatever the percentages are). I call it the Steve Jobs' principles.
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 1389
  • Country: it
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #151 on: May 19, 2016, 04:27:26 PM »
Quote
It's pretty much "fill in a data structure with a bunch of obscure parameters that you'll have to study the datasheet to understand", and then we'll copy those into the appropriate registers."  All the cost of abstraction with none of the benefits.
Thak god now cube mx is multiplatform and you can get it to write for you the startup code, then you give it the middle finger and just write the registers as they are after the code
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 749
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #152 on: May 19, 2016, 05:04:19 PM »
It is not rocket science to write simple API that works for 90% of the people 90% of the time (or whatever the percentages are).

Yes, that is how I approach it also (80% is good enough). If you make sure your library code can be replaced and/or extended in a simple way, this is the way to go, otherwise you'll spend 80% of the time on 20% of the exceptions.

Writing good libraries is hard. You'll have to find a pattern for each peripheral that makes sense for that subject and structure it in a way that allows the flexibility, extensibility and efficiency you need. My weapon of choice is to use a sub-set of C++ (templates) but not all chips support that (only have experience with AVR - see signature). The C language is sub-optimal for writing reusable code IMHO. Some may be remidied with naming and coding conventions though.

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #153 on: May 19, 2016, 05:16:21 PM »
In my experience, templates would be too hard for general embedded users. Sure I am sure there are EEVBlogger who can write turing complete templates in their sleep, but a lot of embedded programmers are actually traned in... hardware and such. So getting them to write in C is already a challenge. One might argue whether a company should only hire certain people with certain background, but we just sell tools. We don't care who buy them, as long as they buy them :-)
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #154 on: May 19, 2016, 05:26:46 PM »
Quote
then you give it the middle finger and just write the registers as they are after the code
I've been waiting for one of the GUI startup-code generators to produce a table of address/value pairs (or something like that) and some minimal code that loops through them, instead of generating "real code" that calls a bunch of bloated library functions...  Of course, a vendor would still need to provide the code libraries as an example of how the peripheral works.  Or improve the data-sheet documentation a lot.  (Is that what we're really talking about?  Peripherals so complex and datasheets so bad that most people can't figure out how to make anything work without example code?)

Quote
templates would be too hard for general embedded users. Sure I am sure there are EEVBlogger who can write turing complete templates in their sleep, but ...
Vendor-provided templates would only have to be "readable", which I don't think is TOO difficult - in some ways templates are more like assembler macros than C macros ever were.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #155 on: May 19, 2016, 05:41:38 PM »
Because doing that is SO common?  I don't think so!  (that's one of the big objections.) 
Average use case is that you set up the clock at startup and it stays at that rate, and/or stops completely in low-power sleep modes.
If I recall correctly (has been some time ago for me these uCs) in those stop conditions the MCU switches to the LSI to be able to auto wake up. So you do switch clocks.
But the point is that ST does not know if you and your company will use an external crystal / oscillator or use the internal etc. so they do have to deliver all the code examples, but I agree there could have been a better sw design made where you can configure it.

Quote
It's not a "50 byte" savings.   More like 1000 bytes.  For code that SHOULD be about 50 bytes. 
Ok i just checked on one of our products and they use ST's HAL libraries but a different one (for STM32F2) the module is called stm32f2xx_rcc and has seperate functions for each clock and configuration.
Compiled (after configuration for our product) it takes only 16 bytes in the end product (release mode optimized IAR compiler) which is good enough don't you think?   
.data             inited   0x20003820     0x10  stm32lib_rcc.o [98]

So not sure whats going on with your hal libs if they are screwed up by ST or you have looked at debug mode no optimization or whatever has went sour but the standard ST hal libraries can be pretty lean and mean. Not all off them though and it is not my point defending all the code ever written by them.
My mistake  |O see below.

I also have had my share of problems with some of their stuff and HW but I just wanted to make a point that some people look at things from a perspective that might be not compatible with working with ARM32 microcontrollers, so to generalize and make the point these persons IMO better not start with the ARM32 stuff unless they want to change their WOW:
1) the new generation Arduino users : " if it does not work within 1 hour, it sucks! Where is my ready to go code?"
2) the dinosaurs (70s assembly generation): " 200 bytes for one function!  :wtf: we wrote an entire OS in 200 bytes in the good 'ol days"  (BTW I do admire those guys, real heroes but sometimes they forget they are in the 21th century and we have evolved in platforms).
3) the HW engineer that barely manages to write C code for an 8 bitter: "I want to directly peek and poke the registers, what is all this classes and abstraction nonsense doing here?"
 ;)

OpenSSL is open source. How long was the heartbleed vulnerability in that code before someone exploited it? Why didn't all of those hoards and hoards of eyes looking at it day and night find and fix it before it became a major headache?
Because it is a tough domain, there are (relatively) little experts and each code change can have severe impacts. Still you can argue that if it was closed source the bug would not have been found and still exist. So yes there are always vulnerabilities in large software codes, take for instance linux, it is swamped with bugs because they sometimes add a Mloc in 1 year!  :scared:
Noone can review that! The same for other OSs like MS Win which is closed source, so they depend on those bounty programs to help them find the vulnerabilities. In any case, open source is not holy but statistically the chances that bugs will be found and solved are larger than with company proprietary software. At least that is my opinion.
« Last Edit: May 24, 2016, 09:13:28 PM by Kjelt »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #156 on: May 19, 2016, 05:49:22 PM »
Quote
Compiled (after configuration for our product) it takes only 16 bytes in the end product which is good enough don't you think?   
.data             inited   0x20003820     0x10  stm32lib_rcc.o [98]
Well, that's in ".data" - it doesn't include code.   Where's the code?
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #157 on: May 19, 2016, 05:57:26 PM »
Quote
Compiled (after configuration for our product) it takes only 16 bytes in the end product which is good enough don't you think?   
.data             inited   0x20003820     0x10  stm32lib_rcc.o [98]
Well, that's in ".data" - it doesn't include code.   Where's the code?
Damn what a mistake  |O  sorry about that, I do this in between on the job (shouldn't be doing this actually),
Indeed the codesize is about 400 bytes (394) which indeed is pretty big for something trivial like this.

 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #158 on: May 19, 2016, 06:06:11 PM »
I was used to Keil, now we use IAR haven't worked with it actually since I switched jobs, but they also have this overview of the entire library and ok I can see that it can become large.
This is the entire library usage for our product:

Module                                       ro code  ro data  rw data  ro data
stm32lib.lib: [98]
Total:                                         5 546      398       28

But mind this is for one of our products that has a 512kB ROM size and is filled about 87%, so in this case the overhead for the st lib is about 1,5% if indeed as someone mentioned you use a 32kB version it will be a significant portion. Still you do need (at least part of) the code and as you states yourself rewriting it yourself entirely is not much of an option, and leaving things out is also not an option.
So tweaking with custom defines seem to be a way to go.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #159 on: May 19, 2016, 06:30:13 PM »
Quote
1) the Arduino users
2) the dinosaurs
3) the HW engineer
4) The new breed: "it fits in the chip, so who cares if it's a lot bigger than it needs to be."
The sad/frustrating part is that I'm not sure that the "type 4" people aren't correct!  Just like I'm not sure I shouldn't send GHz RPi's at embedded problems where a 50MHz CM3 probably would have worked.   Sigh.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #160 on: May 19, 2016, 07:12:00 PM »
4) The new breed: "it fits in the chip, so who cares if it's a lot bigger than it needs to be."
The sad/frustrating part is that I'm not sure that the "type 4" people aren't correct!  Just like I'm not sure I shouldn't send GHz RPi's at embedded problems where a 50MHz CM3 probably would have worked.   Sigh.
All in perspective ofcourse but it is a balance between the BOM and the NRE in the end. And for a hobbieist unless you get a kick out of reducing the codesize which can be a legitimate goal an sich, I think they also rather spent their hours on the challenging puzzle then to rewrite low level libraries for each and every uC they have.
So yeah my colleagues sometimes still end up rewriting part of some code to fit a too small indesigned uC (which can be a curse also) but it is not as when I started and my first asignment was to add a small feature to an 8bit uC and I had 18 bytes to do it in, ending up rewriting the ADC module which was written in C to assembly in order to shave off another 10 bytes of code. That probably won't happen anymore in todays companies. And I think that is a good thing.

 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 749
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #161 on: May 19, 2016, 07:20:57 PM »
In my experience, templates would be too hard for general embedded users.

To my eyes, this is very easy code to use and read back / maintain. (AVR)
Code: [Select]
void Globals::OpenMidiPort()
{
    UsartConfig config;
    config.InitAsync(MIDI_BAUDRATE);
   
    MidiInOutPort1.OpenAsync(config);
    MidiInOutPort1.Receive.setEnable();
    MidiInOutPort1.Transmit.setEnable();
}

ISR(USART0_RX_vect)
{
    Globals::MidiInOutPort1.Receive.OnIsCompleteInterrupt();
}

ISR(USART0_UDRE_vect)
{
    Globals::MidiInOutPort1.Transmit.OnAcceptDataInterrupt();
}

The flexibility and complexity is in the type definitions:
Code: [Select]
template<const UsartIds::type UsartId>
class MidiOutPort : public MidiWriter<UsartOutputStream<UsartTransmit<UsartId>, RingBufferFast<uint8_t, MidiTransmitBufferSize> > >
{ };

template<typename StateT>
class MidiInOutPort1T : public Usart<UsartIds::UsartId0, MidiOutPort<UsartIds::UsartId0>, MidiReader<MidiMessageHandler<StateT> > >
{ };

Without going into what everything does, every piece of code is pluggable and can be replaced if needed. But there are typical typedefs novice user can use to get things going fast.

If you complain about code structure and code (design) patterns and you really want a solution, you must be willing to look further outside your comfort zone...
 
The following users thanked this post: Skashkash

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #162 on: May 20, 2016, 04:37:44 AM »
Quote
"I want to directly peek and poke the registers, what is all this classes and abstraction nonsense doing here?"

I'm actually quite fond of those classes and abstraction / layering as long as they make my life easier.

It is reasonable to think that in performance driven environment where the hardware is pushed to its limit and beyond this could be a problem. but for most of other applications, you rarely run into a case where you are so constrained as to having to deal with this manually.

My philosophy has always been: letting computers do those low value-add stuff and let humans do those high value-add stuff.
================================
https://dannyelectronics.wordpress.com/
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 1389
  • Country: it
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #163 on: May 20, 2016, 04:37:12 PM »
Is that what we're really talking about?  Peripherals so complex and datasheets so bad that most people can't figure out how to make anything work without example code?
Yes, or that at least is what i would want, but for the moment i have to do whatever works best (= whatever makes my chip m3 arm chip have at least the same performance as a dspic)

Quote
the HW engineer that barely manages to write C code for an 8 bitter: "I want to directly peek and poke the registers, what is all this classes and abstraction nonsense doing here?"
Yes that's me :) I remember at the first programming course in uni, our teacher on the first day warned us "and if i see any of you microcontroller freaks declare a variable "char" instead of "int" because you want to spare three bytes of memory.." We are writing computer software.

As dannyf said, it's okay to have abstraction. it's useful for a number of situations for a number of reasons. It's nice sometimes to just select a different chip in the project configuration, compile and all is good... but when the generated code is that? on a cortex, which is not that complex? come on, that's just garbage.
« Last Edit: May 20, 2016, 04:52:54 PM by JPortici »
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #164 on: May 20, 2016, 05:14:42 PM »
but when the generated code is that? on a cortex, which is not that complex? come on, that's just garbage.
IMO it is only garbage if it does not work.
No-one is stopping you from using the working example code as a reference and code your own HAL.
If not tweaked to a single configuration it will still be too large.
Then you need another approach that ST took , the Cube, build a GUI so the user can configure the exact pinout and peripheral setup he wants and generate the end result setup code (at least I think that is what it should do since I have no experience with it).
That seems not too work to well as I read and heard and the major problem AFAICS is that you can not easily switch some settings to another setup without that GUI .
This means that you have to maintain the GUI in your project as well (version control, OS control etc.)

My point is not that the HAL is extremely well written, it is that it works but generates (as we seen) some overhead. So you end up with 5kB of configuration code which is the direct result of general software configuration options, the enormous amount of options and peripherals and that configuring these peripherals sometimes almost needs a statemachine to execute correctly.

Most people that make comments that ST is garbage will be better off with mbed kind of P&P environments but also those generate enormous amount of waste code so that comment is not justified then.
If you like to peek and poke the registers directly, fine do it, but it takes more (a lot of) time to do it that way and the end result is the same except you perhaps saved 2kB or so, that is a choice everyone has to make for himself.

 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #165 on: May 20, 2016, 05:17:59 PM »
PS: not want to offend you but if this is what you are now already facing and having problems with:
http://www.eevblog.com/forum/beginners/problems-with-stm32-spi-and-chip-select/msg940835/#msg940835
then I would suggest make a project work first with the out of the box ST code and then start tweaking it.
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 749
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #166 on: May 20, 2016, 05:40:22 PM »
My goal when writing a library is to make the API as self explanatory as possible. The Intellisense (code completion) should give the dev all the ques necessary to work with the peripheral successfully - with minimal effort. Ideally a similar 'way of doing things' would be used throughout the library to minimize the learning curve.

In big(ger) systems -with more code- abstraction does make a lot of sense. With abstractions comes overhead - optimize only where needed. If it's a small code base on hardware the barely fits, hand optimized assembly may be needed, but if you take that approach for a new project - you're doing it wrong IMO. So some devs may get away with just poking the registers and (re-)reading the datasheets for every project they do. For others this approach may come with a too high a price tag. Developing software takes a long time. The faster you can get it working the better. Over-specing the hardware a bit may make perfect sense in some cases.

If you prefer to poke at the registers directly, then this discussion is of no interest to you, you do not need anything to do that. If you're serious about building a stable code base and reusing your code across multiple projects, then you will need something that fits your bill. What that is, is dependent on the type of projects, the complexity of the code involved and the level of the devs. There is no silver bullet, no 'one shoe fits all'.

[2c]

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 1389
  • Country: it
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #167 on: May 20, 2016, 09:20:05 PM »
PS: not want to offend you but if this is what you are now already facing and having problems with:
http://www.eevblog.com/forum/beginners/problems-with-stm32-spi-and-chip-select/msg940835/#msg940835
then I would suggest make a project work first with the out of the box ST code and then start tweaking it.

None taken, that problem came from misunderstanding the documentation.
What i'm doing now is writing software with the HAL and whenever it works cut all the shit out and just read/write the register (which is what is actually done, but in a convoluted way that could/should be done more efficiently as people have pointed out.. and at least between the various stm32 chips there is consistency between the registers names and bits)
Peripheral initialization, that's another mistery: a problem i had (which i wrote in the other topic) was that i could not properly set up the peripheral. Looking at the code that the hal generated i saw i had also to write values in the i2s configuration registers.. which was not written in the "how to set up the peripheral in spi master mode". How fool of me to think that all the info was in one place :) So maybe the probem comes even before the hal?
Yes there are many  people that in spite of this were able to put out functioning product but this is not the way of working i'm used to (and probably not the one for many people in this thread) so it can be very frustrating at times
 

Offline autobot

  • Regular Contributor
  • *
  • Posts: 65
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #168 on: May 20, 2016, 10:56:09 PM »
In my experience, templates would be too hard for general embedded users...So getting them to write in C is already a challenge
but we just sell tools. We don't care who buy them, as long as they buy them :-)

:)

But didn't the Arduino proved that a subset of c++ is usable by beginners, while still letting the grown ups write powerful and reusable libraries(together with a lot of crap, of course) ?
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #169 on: May 21, 2016, 12:38:20 AM »
Quote
I would suggest make a project work first with the out of the box ST code and then start tweaking it.

That's the general approach I take as well. Top-down, outside-in. I typically dice up my projects into small pieces and write those empty pieces with known behaviors: many times those pieces return a pre-determined value / values so that I can tweak the structure the projects. I also don't link in the actual hardware until i'm happy with the overall architecture of the project. Lots of software i2c/spi/uart for example.

Then hardware modules are dropped in gradually to replace the software modules, starting with hardware modules I have used before that are proven. If I have to use a new hardware peripheral, I would start / debug it in a simple environment and not integrated it until it is reasonably reliable.

This approach allows multiple individuals to work on the same project at the same time and generally gives a smooth integration phase. It is slow to get going but it gets to the end typically faster.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #170 on: May 21, 2016, 11:44:35 AM »
Over in another thread: http://www.eevblog.com/forum/microcontrollers/uart-echo-code-outputs-alternate-characters/ , we seem to be discovering that the HAL UART library does a lot of things, but ... not the most common use case for a UART in an embedded system (ie a ring buffer.)

Also, it sure looks like 8bits with parity is broken, and 9bits is either broken or really weird.  And (as I've mentioned previously) the baud rate divisor generation is much more complex than it needs to be (it is in the reference manual too...)
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #171 on: May 21, 2016, 02:14:35 PM »
That's because ST's philosophy seems to be "thin (obfuscating) layer on top of the hardware registers". e.g. all the functions are no more than "things to poke or peek the I/O registers". It's not a functional API.

There is no ring buffer because the hardware has no such things. The Baud rate code is broken because the hardware guy documents how the state machine works, and forgot to comment that, "Oh, BTW, FUNCTIONALLY speaking, you just do BRR = baudrate. Yes, seriously"
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #172 on: May 21, 2016, 09:31:55 PM »
have not read the thread but a ring (circular) buffer is something (if not available in HW) that should be implemented by your own utility layer.
This software module could simply be configured for uint8_t till uint32_t and have any size (restricted by available RAM ofcourse).
HW can be nice but is always limited, if in software you can make it whatever you need.

Some peripherals like the Ethernet MAC interface has dedicated DMA circular buffers, and if I am not mistaken if you use the DMA controller to handle the USART (not sure if this is possible) on the APBx bus, the DMA controller does have some circular buffer capacity:
Quote
The devices feature two general-purpose dual-port DMAs (DMA1 and DMA2) with 8
streams each. They are able to manage memory-to-memory, peripheral-to-memory and
memory-to-peripheral transfers. They share some centralized FIFOs for APB/AHB
peripherals, support burst transfer and are designed to provide the maximum peripheral
bandwidth (AHB/APB).
The two DMA controllers support circular buffer management, so that no specific code is
needed when the controller reaches the end of the buffer. The two DMA controllers also
have a double buffering feature, which automates the use and switching of two memory
buffers without requiring any special code.
« Last Edit: May 21, 2016, 09:34:14 PM by Kjelt »
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #173 on: May 24, 2016, 02:12:23 AM »
have not read the thread but a ring (circular) buffer is something (if not available in HW) that should be implemented by your own utility layer.

IMO the ring buffer should be implemented as close to the hardware as possible.
Never trust a government that doesn't trust you.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #174 on: May 24, 2016, 03:22:38 AM »
Quote
a ring (circular) buffer is something (if not available in HW) that should be implemented by your own utility layer.
I don't disagree, but I think it is a good example of the original subject "STM32Cube Sucks" that the HAL library for the UART peripheral provides three separate APIs for accessing the UART (Polled, Interrupt, and DMA), and as far as I can tell, all three are essentially USELESS for implementing a ring buffer (nor do they use a ringbuffer internally to provide those APIs.)   So we're right back at "ignore the vendor library and write it yourself."
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #175 on: May 24, 2016, 04:09:13 AM »
Code review!  This is ONE function from stm32f1xx_hal_uart.c (v1.0.1, July 2015)
My comments preceded by the triple-semicolons: ";;;"
Code: [Select]
HAL_StatusTypeDef HAL_UART_Receive(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
  uint16_t* tmp;
  uint32_t  tmp_state = 0;

  tmp_state = huart->State;
  if((tmp_state == HAL_UART_STATE_READY) || (tmp_state == HAL_UART_STATE_BUSY_TX))
;;; Why are there states?  There is no documentation for what the states
;;; are supposed to accomplish...
;;; I suppose we're using tmp_state because huart isn't "locked" yet?
;;; Does this allow polled, DMA, and ISR based uart IO to occur
;;; "simultaneously" (or "not occur" as the case may be)?
;;; How are those supposed to interact?
  {
    if((pData == NULL ) || (Size == 0))
    {
      return  HAL_ERROR;
    }

    /* Process Locked */
    __HAL_LOCK(huart);
;;; locked against what?

    huart->ErrorCode = HAL_UART_ERROR_NONE;
    /* Check if a non-blocking transmit process is ongoing or not */
    if(huart->State == HAL_UART_STATE_BUSY_TX)
    {
      huart->State = HAL_UART_STATE_BUSY_TX_RX;
    }
    else
    {
      huart->State = HAL_UART_STATE_BUSY_RX;
    }
;;; Now we've changed state.  Perhaps this does "real" half-duplex?

    huart->RxXferSize = Size;
    huart->RxXferCount = Size;
;;; Maybe we copy these so that we can do polled and interrupt driven
;;; IO at the same time?  Maybe the states help with that?  Oh well,
;;; a few extra copies won't hurt anything, right?
    /* Check the remain data to be received */
    while(huart->RxXferCount > 0)
    {
      huart->RxXferCount--;
      if(huart->Init.WordLength == UART_WORDLENGTH_9B)
      {
        if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
;;; So where are we now? huart->RxXferSize and huart->RxXferCount
;;; are intermediate values, and we didn't change the state to reflect
;;; that we aborted the input.  Doesn't this mean that we'll fail all
;;; subsequent attempts at input?
;;; We also didn't unlock anything!
        }
        tmp = (uint16_t*) pData ;
;;; for 9bit data, we recast our pointer.  Ok, I guess.  Since we're
;;; so casual with ASSERT, shouldn't we ASSERT word alignment too?
        if(huart->Init.Parity == UART_PARITY_NONE)
        {
          *tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x01FF);
          pData +=2;
;;; OK, we recieved 9bit data and put it in our 16bit buffer.
;;; (uint16_t)0x01FF seems silly.  Doesn't it subsequenlty get promoted
;;; to uint32 to match DR?
        }
        else
        {
          *tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x00FF);
          pData +=1;
;;; But WTF did this do?  If parity is turned on, we'll just throw
;;; away that 9th bit and store 8bits instead?  Doesn't the uart do
;;; 9 bits PLUS parity (10bits total)?  If I put it in 9bit mode, don't
;;; I probably want to receive 9bits for each input?
        }
;;; Did I mention how great I feel that my program will be cluttered with
;;; (broken?) 9bit UART code even though I'm unlikely to ever use it?
      }
      else
      {
        if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
;;; more returing without updating State or lock
        }
        if(huart->Init.Parity == UART_PARITY_NONE)
        {
          *pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x00FF);
;;; OK. masking unnecessary, but probably optimized anyway.
;;; casting "0x00FF" to uint8_t seems particularly silly.
        }
        else
        {
          *pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x007F);
;;; This is OK for 7 databits + parity, and in fact is necessary since the
;;; UART hardware is documented as leaving the parity bit in DR instead
;;; of stripping it as with many other UARTs.
;;; However, this seems like it's substantially broken for any word size
;;; OTHER than 7 bits.  8 databits+parity will only return 7bits to the user,
;;; databits less than 7 will fail to strip the parity bit.
        }

      }
    }

    /* Check if a non-blocking transmit process is ongoing or not */
    if(huart->State == HAL_UART_STATE_BUSY_TX_RX)
    {
      huart->State = HAL_UART_STATE_BUSY_TX;
    }
    else
    {
      huart->State = HAL_UART_STATE_READY;
    }
    /* Process Unlocked */
    __HAL_UNLOCK(huart);
;;; more state stuff.

    return HAL_OK;
  }
  else
  {
    return HAL_BUSY;
  }
}
 

Offline captbill

  • Contributor
  • Posts: 37
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #176 on: May 24, 2016, 11:39:22 AM »
Hi all,
I found something that might interest you. JoeNintey, from the Astrobe.com forum, is working on an Oberon compiler for the STM32. I can assure you your 'software ecosystem problems' will be a thing of the past if he is successful. I would think/hope that it will be made available with Astrobe. Worth a watch for sure.

http://www.astrobe.com/forum/viewtopic.php?f=2&t=497&p=1193 
 
The following users thanked this post: cfbsoftware

Offline captbill

  • Contributor
  • Posts: 37
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #177 on: May 24, 2016, 12:12:39 PM »
Hi all,
I found something that might interest you. JoeNintey, from the Astrobe.com forum, is working on an Oberon compiler for the STM32. I can assure you your 'software ecosystem problems' will be a thing of the past if he is successful. I would think/hope that it will be made available with Astrobe. Worth a watch for sure.

http://www.astrobe.com/forum/viewtopic.php?f=2&t=497&p=1193

I guess I read the thread too fast. Looks Like the STM32 is up and running on Astrobe. Looks to be going commercial by months end.
 

Offline captbill

  • Contributor
  • Posts: 37
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #178 on: May 24, 2016, 12:23:50 PM »
Code review!  This is ONE function from stm32f1xx_hal_uart.c (v1.0.1, July 2015)
My comments preceded by the triple-semicolons: ";;;"
Code: [Select]
HAL_StatusTypeDef HAL_UART_Receive(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
  uint16_t* tmp;
  uint32_t  tmp_state = 0;

  tmp_state = huart->State;
  if((tmp_state == HAL_UART_STATE_READY) || (tmp_state == HAL_UART_STATE_BUSY_TX))
;;; Why are there states?  There is no documentation for what the states
;;; are supposed to accomplish...
;;; I suppose we're using tmp_state because huart isn't "locked" yet?
;;; Does this allow polled, DMA, and ISR based uart IO to occur
;;; "simultaneously" (or "not occur" as the case may be)?
;;; How are those supposed to interact?
  {
    if((pData == NULL ) || (Size == 0))
    {
      return  HAL_ERROR;
    }

    /* Process Locked */
    __HAL_LOCK(huart);
;;; locked against what?

    huart->ErrorCode = HAL_UART_ERROR_NONE;
    /* Check if a non-blocking transmit process is ongoing or not */
    if(huart->State == HAL_UART_STATE_BUSY_TX)
    {
      huart->State = HAL_UART_STATE_BUSY_TX_RX;
    }
    else
    {
      huart->State = HAL_UART_STATE_BUSY_RX;
    }
;;; Now we've changed state.  Perhaps this does "real" half-duplex?

    huart->RxXferSize = Size;
    huart->RxXferCount = Size;
;;; Maybe we copy these so that we can do polled and interrupt driven
;;; IO at the same time?  Maybe the states help with that?  Oh well,
;;; a few extra copies won't hurt anything, right?
    /* Check the remain data to be received */
    while(huart->RxXferCount > 0)
    {
      huart->RxXferCount--;
      if(huart->Init.WordLength == UART_WORDLENGTH_9B)
      {
        if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
;;; So where are we now? huart->RxXferSize and huart->RxXferCount
;;; are intermediate values, and we didn't change the state to reflect
;;; that we aborted the input.  Doesn't this mean that we'll fail all
;;; subsequent attempts at input?
;;; We also didn't unlock anything!
        }
        tmp = (uint16_t*) pData ;
;;; for 9bit data, we recast our pointer.  Ok, I guess.  Since we're
;;; so casual with ASSERT, shouldn't we ASSERT word alignment too?
        if(huart->Init.Parity == UART_PARITY_NONE)
        {
          *tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x01FF);
          pData +=2;
;;; OK, we recieved 9bit data and put it in our 16bit buffer.
;;; (uint16_t)0x01FF seems silly.  Doesn't it subsequenlty get promoted
;;; to uint32 to match DR?
        }
        else
        {
          *tmp = (uint16_t)(huart->Instance->DR & (uint16_t)0x00FF);
          pData +=1;
;;; But WTF did this do?  If parity is turned on, we'll just throw
;;; away that 9th bit and store 8bits instead?  Doesn't the uart do
;;; 9 bits PLUS parity (10bits total)?  If I put it in 9bit mode, don't
;;; I probably want to receive 9bits for each input?
        }
;;; Did I mention how great I feel that my program will be cluttered with
;;; (broken?) 9bit UART code even though I'm unlikely to ever use it?
      }
      else
      {
        if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
;;; more returing without updating State or lock
        }
        if(huart->Init.Parity == UART_PARITY_NONE)
        {
          *pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x00FF);
;;; OK. masking unnecessary, but probably optimized anyway.
;;; casting "0x00FF" to uint8_t seems particularly silly.
        }
        else
        {
          *pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x007F);
;;; This is OK for 7 databits + parity, and in fact is necessary since the
;;; UART hardware is documented as leaving the parity bit in DR instead
;;; of stripping it as with many other UARTs.
;;; However, this seems like it's substantially broken for any word size
;;; OTHER than 7 bits.  8 databits+parity will only return 7bits to the user,
;;; databits less than 7 will fail to strip the parity bit.
        }

      }
    }

    /* Check if a non-blocking transmit process is ongoing or not */
    if(huart->State == HAL_UART_STATE_BUSY_TX_RX)
    {
      huart->State = HAL_UART_STATE_BUSY_TX;
    }
    else
    {
      huart->State = HAL_UART_STATE_READY;
    }
    /* Process Unlocked */
    __HAL_UNLOCK(huart);
;;; more state stuff.

    return HAL_OK;
  }
  else
  {
    return HAL_BUSY;
  }
}

Just for a comparison, here is the COMPLETE In.Mod for Astrobe Oberon (UART input module/library). It compiles to 364 BYTES!

Code: [Select]
MODULE In;
(* ========================================================================= 
   Astrobe Library Functions for Formatted Input 
   Ref: Programming in Oberon - Reiser & Wirth, ACM Press 1992

   (c) 2010-2013 CFB Software   
   http://www.astrobe.com 
   
   ========================================================================= *)

IMPORT Convert;

CONST
  CR = 0DX;
  LF = 0AX;
 
  (* Possible result values *)
  noError* = Convert.noError;
  overflow* = Convert.overflow;
  syntaxError* = Convert.syntaxError;
 
TYPE
  GetCharProc* = PROCEDURE (VAR ch: CHAR);
 
VAR
  GetCh: GetCharProc;
  result*: INTEGER;

PROCEDURE* UndefinedGetCh(VAR ch: CHAR);
BEGIN
  ASSERT(TRUE, 20)
END UndefinedGetCh;

 
PROCEDURE* Init*(g: GetCharProc);
BEGIN
  GetCh := g
END Init;


PROCEDURE Char*(VAR ch: CHAR);
BEGIN
  GetCh(ch)
END Char;


PROCEDURE String*(VAR s: ARRAY OF CHAR);
VAR
  i: INTEGER;
  ch: CHAR;
BEGIN
  REPEAT GetCh(ch) UNTIL (ch > " ");
  i := 0;
  WHILE (ch > " ") & (i < LEN(s)) DO s[i] := ch; GetCh(ch); INC(i) END;
  IF i < LEN(s) THEN s[i] := 0X END
END String;


PROCEDURE Int*(VAR n: INTEGER);
VAR
  buffer: ARRAY 12 OF CHAR;
BEGIN
  String(buffer);
  Convert.StrToInt(buffer, n, result)
END Int;


BEGIN
  Init(UndefinedGetCh)
END In.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #179 on: May 24, 2016, 12:25:10 PM »
#your 'software ecosystem problems' will be a thing of the past if he is successful. #

Writing bug free software is super easy: everyday, millions of programmers try to do it.

================================
https://dannyelectronics.wordpress.com/
 

Offline captbill

  • Contributor
  • Posts: 37
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #180 on: May 24, 2016, 12:38:21 PM »
#your 'software ecosystem problems' will be a thing of the past if he is successful. #

Writing bug free software is super easy: everyday, millions of programmers try to do it.

True...but how many are succeeding?

(This is the one and only post in the bug tracker: )

http://www.astrobe.com/forum/viewtopic.php?f=5&t=452
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #181 on: May 24, 2016, 01:29:11 PM »
Quote
Just for a comparison, here is the COMPLETE In.Mod for Astrobe Oberon
Code: [Select]
Astrobe Library Functions for Formatted Input 
Since I'm being fussy (what else IS a "code review:!), I feel compelled to point out that the code you quoted does entirely different stuff ("formatted input") than the code/module that I quoted (HW level driver.)  The equivalent driver-level code would all be hidden in the "GetCharProc" procedure, and the quoted portion only provides a "dummy" version thereof (assuming that I'm reading the unfamiliar language correctly.)


On  a somewhat related note, does anyone know if ST pays attention to bug reports and/or code suggestions on the Cube/HAL libraries?
I'm not really inclined to spend a lot of time contributing to libraries with objectionable licenses, but since I've essentially already written up several bugs, I might as well send them somewhere...
 

Offline captbill

  • Contributor
  • Posts: 37
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #182 on: May 24, 2016, 01:47:36 PM »
Quote
Just for a comparison, here is the COMPLETE In.Mod for Astrobe Oberon
Code: [Select]
Astrobe Library Functions for Formatted Input 
Since I'm being fussy (what else IS a "code review:!), I feel compelled to point out that the code you quoted does entirely different stuff ("formatted input") than the code/module that I quoted (HW level driver.)  The equivalent driver-level code would all be hidden in the "GetCharProc" procedure, and the quoted portion only provides a "dummy" version thereof (assuming that I'm reading the unfamiliar language correctly.)


On  a somewhat related note, does anyone know if ST pays attention to bug reports and/or code suggestions on the Cube/HAL libraries?
I'm not really inclined to spend a lot of time contributing to libraries with objectionable licenses, but since I've essentially already written up several bugs, I might as well send them somewhere...

Yes, actually, the In.Mod and Out.Mod work in conjunction with an mcu specific Serial.Mod for the complete UART functionality. I was just giving an idea of some actual code. Here is the Out.Mod and Serial.Mod for the LPC1769:

Code: [Select]
MODULE Out;
(* ========================================================================= 
   Astrobe Library Functions for Formatted Output 
   Ref: Programming in Oberon - Reiser & Wirth, ACM Press 1992

   (c) 2008-2011 CFB Software   
   http://www.astrobe.com 
   
   ========================================================================= *)

IMPORT Convert;

TYPE
  PutCharProc* = PROCEDURE (ch: CHAR);
 
VAR
  PutCh: PutCharProc;

PROCEDURE* UndefinedPutCh(ch: CHAR);
BEGIN
  ASSERT(FALSE, 20)
END UndefinedPutCh;

 
PROCEDURE* Init*(p: PutCharProc);
BEGIN
  PutCh := p
END Init;


PROCEDURE Char*(ch: CHAR);
BEGIN
  PutCh(ch)
END Char;


PROCEDURE String*(s: ARRAY OF CHAR);
VAR
  i, sLen: INTEGER;
BEGIN
  i := 0;
  sLen := STRLEN(s);
  FOR i := 0 TO sLen - 1 DO PutCh(s[i]) END;
END String;


PROCEDURE Ln*();
BEGIN
  PutCh(0DX);
  PutCh(0AX)
END Ln;


PROCEDURE Int*(n, width: INTEGER);
VAR
  buffer: ARRAY 12 OF CHAR;
  i, bLen: INTEGER;
BEGIN
  Convert.IntToStr(n, buffer);
  bLen := STRLEN(buffer);
  FOR i := 1 TO width - bLen DO Char(" ") END;
  String(buffer)
END Int;


PROCEDURE Hex*(n, width: INTEGER);
VAR
  buffer: ARRAY 12 OF CHAR;
  i, bLen: INTEGER;
BEGIN
  Convert.IntToHex(n, buffer);
  bLen := STRLEN(buffer);
  FOR i := 1 TO width - bLen DO Char(" ") END;
  String(buffer)
END Hex;


BEGIN
  Init(UndefinedPutCh)
END Out.

 

Code: [Select]
MODULE Serial;
(** ========================================================================= 
   Astrobe Library Functions for Serial IO via UART0/2/3
   
   Target: LPC176x family microcontrollers
   
   Refs:
     NXP LPC176x/5x User Manual UM10360

   (c) 2012-2015 CFB Software   
   http://www.astrobe.com 
   
   ========================================================================= *)

IMPORT MCU, SYSTEM;

CONST
  UART0* = 0;
  UART2* = 2;
  UART3* = 3;
 
  (* Parity *)
  none*    = {};
  odd*     = {3};
  even*    = {3, 4};
  forced1* = {3, 5};
  forced2* = {3, 4, 5};
 
VAR
  URBR: INTEGER;
  UTHR: INTEGER;
  UDLL: INTEGER;
  UDLM: INTEGER;
  UIER: INTEGER;
  UIIR: INTEGER;
  UFCR: INTEGER;
  ULCR: INTEGER;
  ULSR: INTEGER;
  USCR: INTEGER;
  UACR: INTEGER;
  UICR: INTEGER;
  UFDR: INTEGER;
  UTER: INTEGER;
 
PROCEDURE* TxReady*(): BOOLEAN;
  RETURN SYSTEM.BIT(ULSR, 5)
END TxReady;


(** Send a single character using polling *)
PROCEDURE* PutCh*(ch: CHAR);
BEGIN
  REPEAT UNTIL SYSTEM.BIT(ULSR, 5);
  SYSTEM.PUT(UTHR, ch)
END PutCh;


PROCEDURE* RxReady*(): BOOLEAN;
  RETURN SYSTEM.BIT(ULSR, 0)
END RxReady;


(** Receive a single character using polling *)
PROCEDURE* GetCh*(VAR ch: CHAR);
BEGIN
  REPEAT UNTIL SYSTEM.BIT(ULSR, 0);
  SYSTEM.GET(URBR, ch)
END GetCh;


PROCEDURE* SetUartNo(uartNo: INTEGER);
VAR
  UBase: INTEGER;
BEGIN
  CASE uartNo OF
    UART0: UBase := MCU.U0Base
  | UART2: UBase := MCU.U2Base
  | UART3: UBase := MCU.U3Base
  END;
  URBR := UBase+000H;
  UTHR := UBase+000H;
  UDLL := UBase+000H;
  UDLM := UBase+004H;
  UIER := UBase+004H;
  UIIR := UBase+008H;
  UFCR := UBase+008H;
  ULCR := UBase+00CH;
  ULSR := UBase+014H;
  USCR := UBase+01CH;
  UACR := UBase+020H;
  UICR := UBase+024H;
  UFDR := UBase+028H;
  UTER := UBase+030H
END SetUartNo;


PROCEDURE* ConfigurePins(uartNo: INTEGER);
VAR
  pconp, select: SET;
BEGIN
  SYSTEM.GET(MCU.PCONP, pconp);
  SYSTEM.GET(MCU.PINSEL0, select);

  IF uartNo = UART0 THEN
    pconp := pconp + {3}; 
    (* P0.2 Bits 5:4 = 01 TXD UART0 *)
    (* P0.3 Bits 7:6 = 01 RxD UART0 *)
    select := select - {5, 7} + {4, 6}
  ELSIF uartNo = UART2 THEN
    pconp := pconp + {24}; 
    (* P0.10 Bits 21:20 = 01 TXD UART2 *)
    (* P0.11 Bits 23:22 = 01 RxD UART2 *)
    select := select - {21, 23} + {20, 22}
  ELSIF uartNo = UART3 THEN
    pconp := pconp + {25}; 
    (* P0.0 Bits 1:0 = 10 TXD UART3 *)
    (* P0.1 Bits 3:2 = 10 RxD UART3 *)
    select := select - {0, 2} + {1, 3}
  END;
 
  (* Power on *)
  SYSTEM.PUT(MCU.PCONP, pconp);

  (* Assign UART function to GPIO port *)
  SYSTEM.PUT(MCU.PINSEL0, select)
END ConfigurePins;


PROCEDURE* SetFormat*(wordLength, stopBits: INTEGER; parity: SET);
VAR
  ulcr: SET;
BEGIN
  ASSERT(wordLength IN {5..8}, 20);
  ASSERT(stopBits IN {1, 2}, 21);
  ASSERT(parity - {3..5} = {}, 22);
  SYSTEM.GET(ULCR, ulcr);
  ulcr := ulcr - {0..5} + parity + BITS(wordLength - 5);
  IF (stopBits = 2) THEN ulcr := ulcr + {2} END;
  SYSTEM.PUT(ULCR, ulcr)
END SetFormat;


PROCEDURE* SetFDR(udlm, udll, mulVal, divAddVal: INTEGER);
CONST
  divisorLatchAccess = {7};
VAR
  ulcr: SET;
BEGIN
  SYSTEM.GET(ULCR, ulcr); 
  SYSTEM.PUT(ULCR, ulcr + divisorLatchAccess);
  SYSTEM.PUT(UDLM, udlm);
  SYSTEM.PUT(UDLL, udll);
  IF (mulVal # 0) OR (divAddVal # 0) THEN
    ASSERT((mulVal >= 1) & (mulVal <= 15), 23);
    ASSERT((divAddVal >= 0) & (divAddVal <= 14), 24);
    SYSTEM.PUT(UFDR, LSL(mulVal, 4) + divAddVal)
  END;
  SYSTEM.PUT(ULCR, ulcr - divisorLatchAccess);
 
  (* Enable and clear FIFOs *)
  SYSTEM.PUT(UFCR, {0, 1, 2})
END SetFDR;


PROCEDURE InitEx*(uartNo, udlm, udll, mulVal, divAddVal: INTEGER);
BEGIN
  ASSERT(uartNo IN {UART0, UART2, UART3}, 20);
  SetUartNo(uartNo);
  ConfigurePins(uartNo);
  SetFormat(8, 1, none);
  SetFDR(udlm, udll, mulVal, divAddVal)
END InitEx;


PROCEDURE Init*(uartNo, baudRate: INTEGER);
BEGIN
  InitEx(uartNo, 0, MCU.PCLK DIV (16 * baudRate), 0, 0)
END Init;


END Serial.
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #183 on: May 24, 2016, 01:57:10 PM »
Hi all,
I found something that might interest you. JoeNintey, from the Astrobe.com forum, is working on an Oberon compiler for the STM32. I can assure you your 'software ecosystem problems' will be a thing of the past if he is successful. I would think/hope that it will be made available with Astrobe. Worth a watch for sure.

http://www.astrobe.com/forum/viewtopic.php?f=2&t=497&p=1193

I guess I read the thread too fast. Looks Like the STM32 is up and running on Astrobe. Looks to be going commercial by months end.

Cool? I guess this might be an option if I wanted to abandon my all tools and buy something new? AND CODE IN AN OBSCURE LANGUAGE...

This is no better than the other "buy our tools and we'll give you a library" that is really just probably as bad as any other mfgs lib, the only difference is now you're locked into a new tool as well.

I'm just not impressed when everyone thinks they can do a better job - yet almost no one seems to be able to prove it... Less impressed when the solution isn't in C.
« Last Edit: May 24, 2016, 02:31:12 PM by jnz »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #184 on: May 24, 2016, 02:30:14 PM »
Code: [Select]
        if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
;;; So where are we now? huart->RxXferSize and huart->RxXferCount
;;; are intermediate values, and we didn't change the state to reflect
;;; that we aborted the input.  Doesn't this mean that we'll fail all
;;; subsequent attempts at input?
;;; We also didn't unlock anything!
Ah well, it turns out that I'm wrong and this code isn't as broken as I thought.
UART_WaitOnFlagUntilTimeout() resets huart->state and does the unlock operation.  (I find that a bit surprising, but I'll take "surprising" over "broken.")

 

Offline captbill

  • Contributor
  • Posts: 37
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #185 on: May 24, 2016, 03:19:49 PM »
Hi all,
I found something that might interest you. JoeNintey, from the Astrobe.com forum, is working on an Oberon compiler for the STM32. I can assure you your 'software ecosystem problems' will be a thing of the past if he is successful. I would think/hope that it will be made available with Astrobe. Worth a watch for sure.

http://www.astrobe.com/forum/viewtopic.php?f=2&t=497&p=1193

I guess I read the thread too fast. Looks Like the STM32 is up and running on Astrobe. Looks to be going commercial by months end.

Cool? I guess this might be an option if I wanted to abandon my all tools and buy something new? AND CODE IN AN OBSCURE LANGUAGE...

This is no better than the other "buy our tools and we'll give you a library" that is really just probably as bad as any other mfgs lib, the only difference is now you're locked into a new tool as well.

I'm just not impressed when everyone thinks they can do a better job - yet almost no one seems to be able to prove it... Less impressed when the solution isn't in C.

Gee, I don't know. Show me a language that you can stare at for 20 minutes and already see a working UART stack for an STM32.

The only file that needs modifications is the Serial.Mod, which will be STM32 specific. Most of the code will remain intact even here. This is mostly initialization, which of coarse everyone can see by a casual read of it.

How is that an OBSCURE language? Could you write a full UART stack for a uC on a whim with your tools? Hey, I'm a newb to all this low level uC stuff too and even I feel confident I could do this in a couple of hours, assuming the MCU.Mod is complete and no newbie gottchas happen to me.
« Last Edit: May 24, 2016, 03:30:16 PM by captbill »
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #186 on: May 24, 2016, 03:31:17 PM »
@westfw  its 7 and i am just awake so a d don,t feel like taking a code review but before you judge code think about some things, like that stm32 are mostly run with an rtos onboard and if you see "locks" and sm's,  think about semaphore and re-entrant code.
Life is a box of chocolates but some other routine can be eating them while your routine was still busy choosing  ;)
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #187 on: May 24, 2016, 03:35:31 PM »

This is no better than the other "buy our tools and we'll give you a library" that is really just probably as bad as any other mfgs lib, the only difference is now you're locked into a new tool as well.

I'm just not impressed when everyone thinks they can do a better job - yet almost no one seems to be able to prove it... Less impressed when the solution isn't in C.

In case I am implicated ;-P This just came in our mailbox, unedited:


//start review
I used arduino for quite a few years tinkering and building projects. Recently, I decided to take an idea out of the world of arduino and into the world of true embedded systems. I started my search for a simple way to create an embedded system that i could put into a commercial product. I found the answer and then some by using Jumpstart microbox from Imagecraft. I found Imagecraft originally by searching for a compiler to use with avr MCUs but after a month and a half of reading and looking at code. I was no closer to my goal of creating a commercial MCU. Then Richard at Imagecraft suggested i try their Jumpstart Microbox with the Jumpstart API. After looking at a few examples, I knew this was going to be a much easier and faster way for me to get my code onto a micro controller. I ordered a Jumpstart Microbox kit, and it was at my door a few days later. I had their example programs running within 30 minutes. A 32 bit 84 MHz micro controller was under my control (a mechanical engineer with little c programming experience). The example code and documentation from Imagecraft was very easy to follow and understand. I was able to use a 32 bit micro controller just like i would an arduino. I couldn't be more impressed with this product. If you are interested in making a commercial product or learning more about micro controllers, and you want or need to use a powerful micro controller. Jumpstart microbox is the answer period. The last thing and probably the best thing about this product is the customer service. The guys at Imagecraft would answer any question i had within minutes no kidding. They even answered questions i didn't know i would need to ask. Excellent job Imagecraft.
//end review
-- Wesley Roberson
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #188 on: May 24, 2016, 04:59:35 PM »
In case I am implicated ;-P This just came in our mailbox, unedited:
This Jumpstart microbox from Imagecraft is your product right?
First I want to say that I personally welcome alternatives. For the quick get going, prototyping and non SW engineers this could be a viable way to go.
Then, what is the overhead of your product in codesize because all the people here are ranting about how large the ST libs are, but what I think I am reading 1,2,3 on your website is that you have added another gluelayer on top of the ST libs, or did you indeed rewrite them?
So can you give some ballpark figures in k ROM , RAM it ads up to?
Are you forced to use the API or can you write your own c-code functions and integrate seamlessly?
Do you run an RTOS , can users use it directly or again through the forced API?
Is there a 100Mb/s IP stack available OpenSSL interface compatible?
Perhaps start another topic since it is going a bit offtopic here.

 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 749
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #189 on: May 24, 2016, 06:36:05 PM »
Ring/CircularBuffer: I am not intimately familiar with the STM32's but I think I read somewhere (DMA?) that it has hardware ring buffers? Not sure, though...
[2c]

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #190 on: May 24, 2016, 06:38:18 PM »
This Jumpstart microbox from Imagecraft is your product right?
First I want to say that I personally welcome alternatives. For the quick get going, prototyping and non SW engineers this could be a viable way to go.
Then, what is the overhead of your product in codesize because all the people here are ranting about how large the ST libs are, but what I think I am reading 1,2,3 on your website is that you have added another gluelayer on top of the ST libs, or did you indeed rewrite them?
...

I will just make some quick answers here. If there are further discussions, I will make a new thread (or anyone else is free to create a new one). Our main product is the JumpStart C for Cortex-M compiler. It's C90 with most useful C99 features (lacking variable sized array as the main missing feature) and basic C++ class support. JumpStart API is a functional API (i.e. not just a thin layer on top of the hardware), currently available for STM32F0xx, F4xx, and soon F7xx series. It does NOT sit on top of the ST lib, although we do use their header files. It is possible to mix and match code from ST's lib and JSAPI, and in fact, until we fill out more of the API, it would be required for more in-depth stuff. You can also write your own.. Basically, JSAPI does not takes over per se, it's just a set of C functions using C++ style classes.

As for other middleware, we are busy working on porting the most popular ones, resource permitting, but it's almost certainly that we will write our own message passing RTOS (we have one but with limited functionality for the AVR that was written a number of years ago) with dual licensing: basically free and Open Source for non-commercial use, and very reasonable fee for commercial use (e.g. much more reasonable than other dual license RTOS) and the goal is definitely to make it compatible with most Open Source middleware stacks.

// ADDED
The JumpStart MicroBox is our complete hardware/software kit particularly suitable for students/hobbyists and engineers new to the Cortex-M world to get started, especially for folks with only familiarity of 8-bit MCU or Arduino.
« Last Edit: May 24, 2016, 06:41:01 PM by richardman »
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Offline bazsa56

  • Contributor
  • Posts: 24
  • Country: hu
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #191 on: May 24, 2016, 08:31:07 PM »
Ring/CircularBuffer: I am not intimately familiar with the STM32's but I think I read somewhere (DMA?) that it has hardware ring buffers? Not sure, though...
[2c]

Indeed, configuring a circular buffer is very easy with an STM32F1 using DMA, probably the same for other types of mcu's as well.

Just about to finish a product that uses the SPL with GCC + eclipse, 48 pin STM32F1. So far things have been going smoothly. No major issues or problems or anything. The cheap st-link v2 also worked fairly well. The code is mostly finished. Very happy with the end result, especially since this is the first time we ended up using a 32 bit mcu in a product.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #192 on: May 24, 2016, 08:48:02 PM »
Quote
The JumpStart MicroBox is our complete hardware/software kit particularly suitable for students/hobbyists and engineers new to the Cortex-M world to get started, especially for folks with only familiarity of 8-bit MCU or Arduino.

The STduino (arduino on STM32F1 boards) would be a much better alternative for the Arduino folks, for its source level compatability: just copy-and-paste your AVR source code, and compile / upload in the same IDE.

Plus its ability to go native, all in the comfort of gcc-arm.

Nothing beats that.
================================
https://dannyelectronics.wordpress.com/
 

Offline Koen

  • Frequent Contributor
  • **
  • Posts: 294
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #193 on: May 24, 2016, 09:02:18 PM »
On  a somewhat related note, does anyone know if ST pays attention to bug reports and/or code suggestions on the Cube/HAL libraries?

I've submitted bug fixes on ST's forum and they've always made it to the next release (months later).
 

Offline markone

  • Frequent Contributor
  • **
  • Posts: 367
  • Country: it
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #194 on: May 24, 2016, 10:33:19 PM »

I will just make some quick answers here. If there are further discussions, I will make a new thread (or anyone else is free to create a new one). Our main product is the JumpStart C for Cortex-M compiler. It's C90 with most useful C99 features (lacking variable sized array as the main missing feature) and basic C++ class support. JumpStart API is a functional API (i.e. not just a thin layer on top of the hardware), currently available for STM32F0xx, F4xx, and soon F7xx series. It does NOT sit on top of the ST lib, although we do use their header files. It is possible to mix and match code from ST's lib and JSAPI, and in fact, until we fill out more of the API, it would be required for more in-depth stuff. You can also write your own.. Basically, JSAPI does not takes over per se, it's just a set of C functions using C++ style classes.
-snip


"Code size limited to 128K bytes of flash"

https://imagecraft.com/index.php?option=com_opencart&Itemid=148&route=product/product&product_id=55

Is it a commercial decision ?
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 647
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #195 on: May 25, 2016, 12:22:19 AM »
Yes, actually, the In.Mod and Out.Mod work in conjunction with an mcu specific Serial.Mod for the complete UART functionality. I was just giving an idea of some actual code. Here is the Out.Mod and Serial.Mod for the LPC1769:
I'm sure Oberon is an interesting language, but I wouldn't want that UART code in my system. First, it's got scoped variables that must be initialized each time you want to use a different UART (see SetUartNo(...)). What if you want to use two UARTs? Do you really want to keep re-initializing all the time?

And calculating those register locations (e.g., "ULCR := UBase+00CH;") involves hard-coded hex constants mixed in with the rest of the driver code. All those constants should be defined somewhere else, preferably with no code/behavior attached, and be generated from a .svd file (in the case of ARM).

The Oberon page on wikipedia mentions garbage collection as a feature of the language. Nope, I don't want that either.
 

Offline MT

  • Frequent Contributor
  • **
  • Posts: 421
  • Country: fo
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #196 on: May 25, 2016, 12:41:42 AM »
I found something that might interest you. JoeNintey, from the Astrobe.com forum, is working on an Oberon compiler for the STM32. I can assure you your 'software ecosystem problems' will be a thing of the past if he is successful. I would think/hope that it will be made available with Astrobe. Worth a watch for sure.

Yes , he might have a peculiar name, situated on strange planet Astrobe and working on top elite project Oberon but one question remain, is he a super hero?
« Last Edit: May 25, 2016, 12:45:26 AM by MT »
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #197 on: May 25, 2016, 12:45:02 AM »

Gee, I don't know. Show me a language that you can stare at for 20 minutes and already see a working UART stack for an STM32.

The only file that needs modifications is the Serial.Mod, which will be STM32 specific. Most of the code will remain intact even here. This is mostly initialization, which of coarse everyone can see by a casual read of it.

How is that an OBSCURE language? Could you write a full UART stack for a uC on a whim with your tools? Hey, I'm a newb to all this low level uC stuff too and even I feel confident I could do this in a couple of hours, assuming the MCU.Mod is complete and no newbie gottchas happen to me.

"PROCEDURE* TxReady*(): BOOLEAN;" is not showing me a working UART code, regardless of how many minutes you stare at it. If anything, what you posted is worse than the topic at hand. You posted someone else's atrempt of a "universal" library that removes what the processor is actually doing in order to dumb it down - but also in a "new" language that is wholly incompatible with any existing code, libraries, third party middleware, operating systems.

Yes, I can write a full UART stack in Keil for the STM32. That's what we're all talking about here, is that many of us have done just that becsause of preferences in the way we want to write vs what STM provides as vendor libraries. It's not the difficulty I care about, it's the duplication of work that is stupid.

If you are a newb, using "simplified" / "opaque" libraries that hide all the scary code from you are a sure way to make sure you'll never learn what's really going on with embedded programming. Doing it in some obscure (yes, definitely) language is also a surefire way to make sure you'll only have one avenue of help with it as well. I can imagine nothing worse for a newb than to use a solution like that.
 

Offline Karel

  • Frequent Contributor
  • **
  • Posts: 913
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #198 on: May 25, 2016, 01:05:10 AM »
If you are a newb, using "simplified" / "opaque" libraries that hide all the scary code from you are a sure way to make sure you'll never learn what's really going on with embedded programming.

I couldn't agree more.
I wrote all libraries myself (SPI, I2C, UART, FAT32, SD-card).
For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...
The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #199 on: May 25, 2016, 02:09:45 AM »
I couldn't agree more.
I wrote all libraries myself (SPI, I2C, UART, FAT32, SD-card).
For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...

 :-+ :-+ :-+
I do the same, but wrote my own TCP/IP stack. I do draw the line at USB, however.
Never trust a government that doesn't trust you.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #200 on: May 25, 2016, 02:17:21 AM »
Quote
For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...

Do you write your own Linux? Do you want your own word processor? Do you want your own compiler? Do you want your own Android? Do you write your own Windows? Do you write your own ECM / infotainment in your car? ...

At some point, you have to stop. The fact that you made your stop differently from others doesn't by itself make your stop right for them.

You don't have to agree with the compromise they made but you have to appreciate the compromise they made.
================================
https://dannyelectronics.wordpress.com/
 

Offline captbill

  • Contributor
  • Posts: 37
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #201 on: May 25, 2016, 03:47:04 AM »
If you are a newb, using "simplified" / "opaque" libraries that hide all the scary code from you are a sure way to make sure you'll never learn what's really going on with embedded programming.

I couldn't agree more.
I wrote all libraries myself (SPI, I2C, UART, FAT32, SD-card).
For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...

With Oberon you not only can work at the "bare metal" but you can literally carve the metal yourself, if you like, just like Magnus has done here:

https://github.com/Saanlima/Pepino/blob/master/Projects/RISC5Verilog_Pepino_I2C/src/I2C.v

How is this not the OPPOSITE of 'obscure'? Where do you see any code being hidden behind 'unknowns'?

Seeing is believing...here is the thread where you see a complete I2c get built in 2 days...and adapting it for Astrobe was a 40 minute task:

http://saanlima.com/forum/viewtopic.php?f=14&t=1289

Quote
Fantastic work - I can hardly believe it! I have just completed the following:

•Uploaded your bitstream to the Pepino
•Connected an HMC6352 I2C Compass chip to the Pepino
•Modified two Oberon source code files to port the code from ARM Cortex-M3 to RISC5 using your I2C register addresses.
•Fixed a number of compilation errors
•Uploaded the compiled modules to the Pepino
•Executed the application

and it worked first time!!!!!

Not only that, the whole process only took 40 minutes from start to finish...

_________________
Chris Burrows
CFB Software
http://www.astrobe.com/RISC5
« Last Edit: May 25, 2016, 04:01:01 AM by captbill »
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #202 on: May 25, 2016, 04:23:34 AM »
"Code size limited to 128K bytes of flash"

https://imagecraft.com/index.php?option=com_opencart&Itemid=148&route=product/product&product_id=55

Is it a commercial decision ?

The refers to a specific version, we sell different versions. Our most expensive version though (PRO), at $499, is less than what other commercial compiler vendors charge for their annual maintenance. The non-commercial version is just $50, for example.
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Offline Karel

  • Frequent Contributor
  • **
  • Posts: 913
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #203 on: May 25, 2016, 05:13:29 AM »
Quote
For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...

Do you write your own Linux?

Your kidding, right? No need to write my own Linux. The average code quality of Linux kernel is much better than
what STM (or Microchip & Atmel for that matter) provides.
The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #204 on: May 25, 2016, 05:16:40 AM »
Quote
No need to write my own Linux. The average code quality of Linux kernel is much better than
what STM (or Microchip & Atmel for that matter) provides.

So you agree that there are bugs in Linux? Since you didn't write Linux, you are living with other people's bugs by using Linux.

I was simply pointing out the hypocrisy of your supposedly "not living with other people's bugs".
================================
https://dannyelectronics.wordpress.com/
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #205 on: May 25, 2016, 06:44:32 AM »
Linux has a tremendous amount of bugs, vulnerabilities are reported weekly and that is not so strange with up to 1Mlocs code change a year  :wtf:
No one can review or certify that, compared to Linux the ST std peripherals are easy to check and certify that it works and as long as people report bugs on their forum it will be ok-ish.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #206 on: May 25, 2016, 07:24:12 AM »
Quote
Linux has a tremendous amount of bugs,

Absolutely true.

Unless you are a caveman living in the stone ages, you live in an environment operated by countless lines of code written by others and definitely full of bugs. And your life depends on it.

It is just non-sense to think at this time and age anyone can live in a world of your own bugs.

:)
================================
https://dannyelectronics.wordpress.com/
 

Online splin

  • Frequent Contributor
  • **
  • Posts: 382
  • Country: gb
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #207 on: May 25, 2016, 08:36:55 AM »
Code review!  This is ONE function from stm32f1xx_hal_uart.c (v1.0.1, July 2015)
My comments preceded by the triple-semicolons: ";;;"
Code: [Select]
      if(huart->Init.WordLength == UART_WORDLENGTH_9B)
       {...}
      else    /* is 8 bit data - 8 bit no parity OR 7 plus parity */
      {
        if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
          return HAL_TIMEOUT;
        if(huart->Init.Parity == UART_PARITY_NONE)
          *pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x00FF);
        else
        {
          *pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x007F);
;;; This is OK for 7 databits + parity, and in fact is necessary since the
;;; UART hardware is documented as leaving the parity bit in DR instead
;;; of stripping it as with many other UARTs.
;;; However, this seems like it's substantially broken for any word size
;;; OTHER than 7 bits.  8 databits+parity will only return 7bits to the user,
;;; databits less than 7 will fail to strip the parity bit.
        }
      }

Actually that code looks OK to me - the STM32F1 UART only supports 8 or 9 bit data. If you enable parity it replaces bit 7 or 8 with the parity. You don't have the options of 9 bit + parity or 7 bit no parity.

From the reference manual describing USART_DR:

Quote
When transmitting with the parity enabled (PCE bit set to 1 in the USART_CR1 register),
the value written in the MSB (bit 7 or bit 8 depending on the data length) has no effect
because it is replaced by the parity.
When receiving with the parity enabled, the value read in the MSB bit is the received parity
bit.
 
The following users thanked this post: jnz

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #208 on: May 25, 2016, 09:01:52 AM »
You don't have to agree with the compromise they made but you have to appreciate the compromise they made.

I do appreciate the compromise some people make by choosing to use vendor libraries.

I'd appreciate it even more if I were still doing commercial development. Sure, they'd get products to market faster, but mine would be more robust and less buggy and, despite the proliferation of Wal*Mart and other retailers that cater to those to whom price is the only thing that matters, there are still enough people around who value quality to ensure that I'd do well.
Never trust a government that doesn't trust you.
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #209 on: May 25, 2016, 03:27:28 PM »

With Oberon you not only can work at the "bare metal" but you can literally carve the metal yourself, if you like, just like Magnus has done here:

How is this not the OPPOSITE of 'obscure'? Where do you see any code being hidden behind 'unknowns?


A. Unless this magic language and lib turn the STM32 into an FPGA, you are WILDLY mistaken about what "the metal" is, and what "literally carve" it would mean.

B. I think you are mistaken about what OBSCURE means. Your wonder-language is obscure, it's not well known.

C. Yes, I posted it already. TX.READY*() is some opaque nonsense. You posted compared to STM's HAL that bad or terrible - is actual detail code. And not just the highest level call that has the guts somewhere else.

I'm not trying to pick on you, but that's great that you like this obscure language and trust that someone else wrote very complex code to make it easy on newbs... But that is NOT a winning strategy when you are dealing with micros. That's how PC programmers with Ghz/Gigs get by.

Trust me, you are on the wrong path if you are interested in embedded.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 2203
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #210 on: May 25, 2016, 03:49:20 PM »
Quote
the STM32F1 UART only supports 8 or 9 bit data. If you enable parity it replaces bit 7 or 8 with the parity. You don't have the options of 9 bit + parity or 7 bit no parity.
I guess that would explain it.  What a weird UART implementation!
So all the bugs I thought I saw have been shown to be OK after all.  I can deal with that...
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #211 on: May 25, 2016, 04:46:09 PM »
I feel that this thread has spawned many arms and approaching thread-death ;-P
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #212 on: May 26, 2016, 01:42:48 AM »
I feel that this thread has spawned many arms and approaching thread-death ;-P

Agreed, and while I have nothing against your wares, if you could slow your roll / stay in your lane on injecting your sales pitch of your JumpStart API that is dependent on using the tools your are selling in a discussion of HAL and how it can be fixed, that would be a helpful start.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #213 on: May 26, 2016, 02:35:45 AM »
I for one don't mind knowing about alternatives, commercially or otherwise. And I think especially in the context of hal not working, having an alternative from imagecraft is a welcome.

What I'm interested in is people's perspectives on such alternatives. For example, I don't know why imagecraft offering is superior to an arduino user, given the free and unlimited alternative of stmduino, it's vast cost baase, user familiarity with tools and code libraries, etc.

================================
https://dannyelectronics.wordpress.com/
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #214 on: May 26, 2016, 04:25:08 AM »
In terms on "how to fix ST's software ecosystems", nothing ever written will be of use unless a) ST adopts it, or b) a user community builds around an alternative. No one has suggested on how to achieve either so anything said here is "useless" for the general users in that sense. Sure, we want to be #2, as would ChibiOS HAL, or Oberon HAL etc. The fact is that there is currently no Open Source alternative free to use with no restrictions from anyone, which I believe is what jnz is looking for. Obviously many people who have commented on the thread could do so, based on what they have said, but no one steps up.

As for describing the specifics of our advantages, I would be happy to answer any further questions via PM, email, or on a separate thread.
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Offline donotdespisethesnake

  • Frequent Contributor
  • **
  • Posts: 402
  • Country: gb
  • Embedded stuff
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #215 on: May 26, 2016, 06:40:50 AM »
I feel that this thread has spawned many arms and approaching thread-death ;-P

Yes, you managed to turn it into an advertising thread for your products, well done sir.  :-+
Bob
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #216 on: May 26, 2016, 07:38:12 AM »
Bob, how about addressing my last post? What's YOUR contribution to solving the "ST's terrible ecosystem problem"? I see westfw putting out some code on public domain. Danny is writing some blog with code examples, and you...?
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #217 on: May 26, 2016, 07:45:09 AM »
BTW, the MAIN IDEA that I am promoting is the concept of FUNCTIONAL API, and not just a simple layer of hardware register access, which is what ST's SPL and HAL are. The Ring buffer, the easy to use I2C objects etc. are just concepts. If anyone chooses to write an API replacement, just I would advise them to look into that direction. So anyone who wants such replacement, please go on and contribute  >:D
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #218 on: May 26, 2016, 08:20:04 AM »
Bob, how about addressing my last post? What's YOUR contribution to solving the "ST's terrible ecosystem problem"? I see westfw putting out some code on public domain. Danny is writing some blog with code examples, and you...?

Why does he need to contribute anything? Maybe he doesn't even use the STM32...

We all welcome your contributions to this topic, Richard, but I'll echo what Bob said: Please tone down the commercial for your product. It's getting a little overripe in the sun.
Never trust a government that doesn't trust you.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 331
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #219 on: May 26, 2016, 08:29:07 AM »
We all welcome your contributions to this topic, Richard, but I'll echo what Bob said: Please tone down the commercial for your product. It's getting a little overripe in the sun.

Noted :P
// richard http://imagecraft.com/
JumpStart MicroBox, the quickest way to get into Cortex-M C programming with the ST-Nucleo and ACE Shield.
JumpStart C, the Better Alternative for Atmel AVR and Cortex-M
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #220 on: May 26, 2016, 08:29:33 AM »
For the record, I was never bother by the layering in STD periph library. Layering comes to me as AA huge advantage, as I most worked in a corporate environment where layering is a requirement for certification and documentation purposes.

I never thought the STD periph library is meant to be used without a user layer - to me it is nothing but a C representation of hardware registers. As such, it is meant to be layered, or customized, by the user in a way that suits his or her programming style.

That applies to even simpler things like port operations. Even on an 8bit mcy, I have never written a line like

PORTD |= portVal;

Instead, I have always used

IOSET(TXPORT, portVal);

With layering, I can write code that is almost entirely hardware dependent - for someone who sells code that runs on user-specified hardware, that's a must.

Taking on a new project for me many times is mostly redefining pins, or settig some macros, and linkingnin the right modules for the target, hit compile and I'm mostly there.

I charge lots of money, without ever worrying about lossing business to someone on prices, because I can deliver quality code quickly, thanks to layering.

Si layering to me is a huge competitive advantage, a huge asset. To me, if you cannot afford to layering, you are in the wrong business.

I often laugh, silently, at those fools who brag abbout writting hardware specific code to shave off 18 bytes. The more code like that you write, the more time you have to spend deciding if you should pay your rent or your cable bills, :)
================================
https://dannyelectronics.wordpress.com/
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #221 on: May 26, 2016, 09:01:59 AM »
With layering, I can write code that is almost entirely hardware dependent - for someone who sells code that runs on user-specified hardware, that's a must.

Freudian slip?
Never trust a government that doesn't trust you.
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 749
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #222 on: May 26, 2016, 04:24:51 PM »
So...
Perhaps if we first concentrate on the what and not the how...?
What requirements would a ideal HAL have to meet?
(be specific)
[2c]

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 1389
  • Country: it
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #223 on: May 26, 2016, 08:37:16 PM »
i can usually achieve the same just by using defines.. and when i port to another mcu i just adjust the defines.
i suppose you could use a function that then call the hal for the specific hardware.. but the hal has no need to be another subset of functions in almost all the cases
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #224 on: May 26, 2016, 08:49:52 PM »
What requirements would a ideal HAL have to meet?
I guess that differs per user. I do really think that we never can accomodate or satisfy the "Arduino style" copy,paste,compile&play group unless STM Cube becomes much much better.
As you saw in this topic some companies answer is to abstract the lower levels and creating a thick fancy gluelayer, taking care of a lot of stuff but also adding to the program size and if there is something not working properly you depend on that company.
Personally i prefer the ST stdperipheral lib and think that is good enough for any reasonably experienced embedded software engineer to get going, as numerous succesfull examples were also mentioned by many users in this topic.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #225 on: May 26, 2016, 08:55:17 PM »
I think the future is likely programming by GUI, as shown by cypress. Just need to figure out the packaging of it so you can build with layers or modules.
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #226 on: May 26, 2016, 09:03:15 PM »
"i prefer the ST stdperipheral lib and think that is good enough for any reasonably experienced embedded software engineer to get goin"

I agree.

I think their mistake is not understanding how people use such libraries. Akin to the mistake that Microsoft made in mobile, in its frequent change overs from since to Windows phone too win 10 mobile, etc., with the hope to enhance its Apple penetration.

Well,, who the hell is going to constantly po4ing the same app over each time Ms abandons the previous OS?

Thee same thing with stm. As long as they keep changing libraries with thee hope of making then better, no one is going to invest in those libraries until the stabluze at some point.

STD periph is far from being perfect. But it works. Rather than abandoning it, they should have refined it.
================================
https://dannyelectronics.wordpress.com/
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #227 on: May 27, 2016, 12:56:42 AM »
  • First off, I just started a new project and have to use Cube/HAL. The actual app, is actually pretty awesome! Setting pins, the clock, initial IRQ and settings per peripheral, and the power management all actually work really well. The clock section specifically saves a TON of time. The code generation actually works well too, minus the issues I have with some aspects of HAL, but...
     
    "SPL isn't perfect but it works"... I hate to tell you this, but HAL works too.


  • You know... It's actually not that bad. Yes, HAL does some things that look really goofy. Most of them aren't as bad as they look at first, most things resolve down to addresses fairly quickly. I think most of the fear from this is the look and style it was coded in (I'll call it Abstract-C). It's not efficient, aside from some long ways to just end up poking a single register. It does weird things like all IRQs for some peripheral all end up calling that peripheral's handler which then has a some of code to sort through just do what you already know needs to happen. For example, UART_TX and UART_RX ISR both call the same Uart_Handler() which then checks to see what interrupts are enabled and flagged / need handling, but you already knew what had to happen because you WERE inside that specific interrupt before you left only to consult a confusing looking map of where you just were.
     
     
  • The love affair with SPL is funny because it also did some dumb things... But... FWIW, the new LL / Low Layer line are almost exactly like SPL. The HAL is for all devices, the LL is SPL that uses the same conventions. So it's SPL with HAL-compatiblity. There are also CodeSnippets which seem to be specific examples of how you would most efficiently do one thing, like check the UART fifo or start the ADC, these are supposed to be even lower level and more chip specific than LL Libs/Drivers. I haven't peeked at these yet but my guess is it's calling registers directly from C/asm without defining headers... So, I think STM does get it, they're showing three options. Some people may be fine with HAL, some fine with LL, and then also the Snippets.
     
     
  • I have almost no issue with using the HAL to start a project, get up and running, and work towards efficiency when it's working. For this project I have to use HAL, I'll try it. I'll let it configure everything and even run the Inits(), then when I need to do simple things like pull a buffer or start/stop a PWM or ADC, I'll do that quickly with a few register pokes. I have preciously little time. Yes, the HAL will add a little bloat like this, but the alternative is staying on the SPL which has its own issues and bugs that will never be corrected and won't work with new middlewares, write my own which is all duplication of work I don't have time for - putting my project further behind, or stomp my feet and complain on the Internet... Sometimes you just need to get shit done.
     
     
  • If LL was available for my chip, I'd use it. STM appears to be behind on all things all the time. Their roadmap for LL releases is already a month, almost two off. But here is the thing; LL (new SPL) has HAL compatibility, like it or not, the HAL isn't going away. It's like CMSIS. How many people threw fits about that, and it's largely fine now. Just some perspective. If you really don't like HAL... Best to get on board and submit fixes and efficiencies to it, because it doesn't seem to be going away.
     
     


EDIT: I should note that LL is not nearly complete even on the device it's been released for. In fact, the F4 has some weird peripherals initially supported by LL (USB, SDMMC)... I have to figure that they're going to support the more basic peripherals later.
« Last Edit: May 28, 2016, 04:23:00 AM by jnz »
 

Offline markone

  • Frequent Contributor
  • **
  • Posts: 367
  • Country: it
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #228 on: May 27, 2016, 11:27:18 PM »

  • First off, I just started a new project and have to use Cube/HAL. The actual app, is actually pretty awesome! Setting pins, the clock, initial IRQ and settings per peripheral, and the power management all actually work really well. The clock section specifically saves a TON of time. The code generation actually works well too, minus the issues I have with some aspects of HAL, but...
     
    "SPL isn't perfect but it works"... I hate to tell you this, but HAL works too.

    -snip
Similar experience here, i agree with all your statements :-+

Time ago, when i first faced the STM32 platform i was initially scared by the complexity of the configuration registers structure, quite far from what i was used to (devices like DSPIC33), but thanks to the stm32cubemx / AC6 i was able to build a working setup with running freertos and some code managing communication on uart port within the first day of work, from scratch, almost impossible otherwise.

Sure i'm not a lover of code abstraction, but i think that the ST tools are a great aid to take confidence with the platform and build the initial development "scheleton" on new boards.

I'm now wondering if other players in ARM Cortex arena are now offering, for free, a similar toolset with all the features of above mentioned tools. 
« Last Edit: May 27, 2016, 11:29:09 PM by markone »
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 2140
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #229 on: May 27, 2016, 11:43:35 PM »
I'm really happy with the HAL. It prevents the magic numbers:
Code: (random example of magic number initialization) [Select]
// Timer 2 for adc
TMR2L = 0x3F;
TMR2H = 0xA2;
TMR2CN = 0x04;
It just is really big and contains a lot of files. Which scares the new people, because it requires more knowledge about your toolchain and C.

On the downside is that you inherit the bugs.
If only it came as GIT repo so you could perform easy upgrades and make pull-requests.
« Last Edit: May 27, 2016, 11:45:25 PM by Jeroen3 »
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #230 on: May 28, 2016, 12:31:25 AM »
I'm really happy with the HAL. It prevents the magic numbers:
Code: (random example of magic number initialization) [Select]
// Timer 2 for adc
TMR2L = 0x3F;
TMR2H = 0xA2;
TMR2CN = 0x04;

There's no reason why you have to use the "magic numbers" approach when writing your own bare metal peripheral drivers! I certainly don't.
Never trust a government that doesn't trust you.
 

Offline MT

  • Frequent Contributor
  • **
  • Posts: 421
  • Country: fo
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #231 on: May 28, 2016, 01:37:52 AM »
Nor do i, nothing particular wrongly with the smallest number expressible as the sum of two cubes in two different ways:
Code: [Select]
TIM2->PSC = 1729;  //Tim2 prescaler ratio.
« Last Edit: May 28, 2016, 01:40:51 AM by MT »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #232 on: June 11, 2016, 08:29:24 PM »
Quote
That has now been removed as that bug has since been fixed :)

The best way to remove bugs: remove the bug tracker.

If you don't know you have bugs, you have no stinky bugs.
================================
https://dannyelectronics.wordpress.com/
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #233 on: June 12, 2016, 01:39:16 PM »
The best way to remove bugs: remove the bug tracker.
Better than removing bugs is to prevent them from occurring in the first place.
1. Design them out
2. Use a reliable development system
3. Perform thorough pre-release functional and regression testing.

Seriously... Please get out of this thread. Start a new thread about your language and tools if you like, but unless you have something on topic about STM's HAL... Best to keep moving.

The tolerance for people pushing their own stuff is very high here, so let's not push the boundaries... Yea?
 

Offline Chris Mr

  • Regular Contributor
  • *
  • Posts: 112
  • Country: gb
  • Where there's a will there's a way
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #234 on: June 13, 2016, 06:49:37 PM »
Back to the point

When you have to program peripherals to do things you need to know what order things have to be done in, what to expect, what the errors are etc.

What the st libraries do is hide all that lovely information in lots of different files and under many layers.

So what I do is get the top level code and insert all the lower layers by copying the code (that includes all the defines and macros too) from the other files into one file and then start pruning it until you end up with very few lines of code.  You can then read it to see what the order of programming is and so on.

That sounds like a lot of work, and it is, but without it your code is very hard to maintain and to me that's precious (being able to maintain it).


How to fix it?

You could start with a document that explains your methodology so that someone reading the code 'gets it' from that document.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #235 on: June 13, 2016, 07:57:01 PM »
Quote
That sounds like a lot of work,

It does and is totally unnecessary with a modern ide.
================================
https://dannyelectronics.wordpress.com/
 

Offline Chris Mr

  • Regular Contributor
  • *
  • Posts: 112
  • Country: gb
  • Where there's a will there's a way
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #236 on: June 13, 2016, 08:49:02 PM »
Quote
That sounds like a lot of work,

It does and is totally unnecessary with a modern ide.

Not if you want to _understand_ it quickly the next time you come to look at it.

A 'moodern ide' does not provide understanding, it shows you what's underneath but if that hides the understanding too then its no help.  In this I am referring to the lack of _understanding_ the st libraries provide.

To put it another way, if the st libraries provided _understanding_ this thread wouldn't be here and certainly not 10 pages long  |O
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #237 on: June 13, 2016, 08:56:28 PM »

"Not if you want to _understand_ it quickly the next time you come to look at it."

A modern library certainly doesn't get you to understand the code, nor does manually merging tthee code into one file and then trimming it.

A modern idde doees provide conscience so you can navigate through the code att ease, thus facilitate your understanding of the code.
================================
https://dannyelectronics.wordpress.com/
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #238 on: June 13, 2016, 08:58:29 PM »
Not if you want to _understand_ it quickly the next time you come to look at it.
So comment or doxygen your own calling code extensively and explain what you found out, next time you know in little time what you know now.
Changing/replacing the code means you will have a very hard time to update to new releases because then you have to do the same exercise again.
Anyway give a programming asignment to 5 sw engineers and you get 5 different working implementations, give one of the implementations to another sw engineer to review and you get a lot of comments.


 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 749
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #239 on: June 13, 2016, 09:10:13 PM »
"If a method is more than 5 lines, you need to extract some code into a new method"

This guideline will make you write code that almost reads like pseudo code, drastically cutting down on the amount of comments you need to write.
When you do write comments, think of what you would like to know if you would see this code for the first time...

Write code that is easy to read - not only when you're neck deep into it, but also when you see it for the first time. Code is written once, but read (by humans) many times.

Offline Chris Mr

  • Regular Contributor
  • *
  • Posts: 112
  • Country: gb
  • Where there's a will there's a way
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #240 on: June 13, 2016, 09:39:48 PM »
Sorry, I don't understand what you mean by "conscience" dannyf

The st code we are referring to is for their (st) peripherals, its nothing more.  The data sheet doesn't explain how they work properly and the code doesn't either.

So you are left with working it out for yourself.

For example, have you written an interrupt based I2C routine for STM32? there is no example (or at least wasn't last time I looked which was quite a while ago) and the data sheet doesn't tell you the vital things you need to know in order to do so; but there is a way to do it.

I agree Kjelt, but this is not a programming assignment, it's a data sheet which is complete that's lacking  |O
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #241 on: June 13, 2016, 10:30:34 PM »
I2C is one of the problem peripherals of ST, well noted for years, there is some strange statemachine driven "working" code lib called Cpal.
All the other peripherals and dma etc. just work fine, they don't sell hundred of millions of CPU's to fortune 500 companies that put them in their hot selling connected products if the CPU or datasheets or code would not be able to make working.
They would be bankrupt.
As said earlier, ARM32 can be a time consuming hill to climb for a one (wo)man hobbieist wanting to upgrade from 8 bit to 32 bits and gets thousands of pages of datasheets to cope with.
Don't blame the product or show/give me another manufacturer that has hassle free 32 bits ARM CPU's with libraries that work straight out of the box, you never have problems or errata sheets:
NXP fail
TI fail
Atmel fail
?
All have their issues and problems AFAIK and all can be made to work after some workaround. Why ST gets so much bashing is really a big question for me, their CPUs have been used in the millions for over 5 years in our company and we keep on using them, but then we have 50 software engineers working on the platform.
 

Offline Chris Mr

  • Regular Contributor
  • *
  • Posts: 112
  • Country: gb
  • Where there's a will there's a way
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #242 on: June 13, 2016, 10:50:19 PM »
Ah, why ST get so much bashing is because they were the first to do it - years ago!

 

Offline mark03

  • Regular Contributor
  • *
  • Posts: 211
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #243 on: June 14, 2016, 03:07:35 AM »
A modern library certainly doesn't get you to understand the code, nor does manually merging tthee code into one file and then trimming it.

Au contraire, this is precisely the method I must often resort to in order to understand the code.  When the reference documentation is insufficient, how else are you going to understand the peripheral except to start with the multi-layered ST spaghetti and, step-by-step, distill it into its essence?  Testing as you go to make sure you haven't removed something essential.
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #244 on: June 14, 2016, 03:55:27 AM »
For example, have you written an interrupt based I2C routine for STM32? there is no example (or at least wasn't last time I looked which was quite a while ago) and the data sheet doesn't tell you the vital things you need to know in order to do so; but there is a way to do it.

I have, and using only the user's guide. I've done this for the STM32F3, F4, and now F7 and I haven't had any problems getting it working. I'll agree that the datasheet/user manual is sometimes vague, but all the info is there--you just have to put all the scattered little pieces together.
Never trust a government that doesn't trust you.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #245 on: June 14, 2016, 08:21:12 AM »
"Changing/replacing the code means you will have a very hard time to update to new releases because then you have to do the same exercise again."

Depending on how the code is structured. I have code that were originally written forr SPL 1 and now runs on SPL 3.5, with minimal changes.

The complaints about SPL is driven by a few factors, in no particular order.

1. The quality isn't that great and the documentation is poor. Sometimes the errors are rudimentary, like the defines on HSE_VALUE for both stm32 and stm8.

I remember someone who boasted to be a St software engineer here and had trouble getting a wireless modules to work. If that's representative of St software engineers, what we see in their products isn't surprising.

2. Chip complexity and peripheral complexity. Those are complex chips and tht takee inordunary amount of effort to get going. For people coming from the 8bit world, that can be a shock.

3. User mentality: I rarely hear people talking about layering in work places or conferences because that's expected in most places. Layering is your friend.

4. Different clientele. In terms of complexity,  those luminary chips are far more complex than the stm32 chips, and stellarisware is worse in terms of documentation. Yet you rarely hear people complaining about those chups, because amaturers rarely had a chance to use those people. Stm32, given it s low prices, is popular with amaturers who tend to have the requisite experience dealing with those chips.

================================
https://dannyelectronics.wordpress.com/
 

Offline Chris Mr

  • Regular Contributor
  • *
  • Posts: 112
  • Country: gb
  • Where there's a will there's a way
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #246 on: June 14, 2016, 05:21:30 PM »
"Changing/replacing the code means you will have a very hard time to update to new releases because then you have to do the same exercise again."

If ST change the peripheral then you would have to go through the process again anyway.  If they don't change the peripheral then the code would stay the same.  ST don't go around changing the peripheral as it is very expensive.

There are other examples of how, by going through methodically / rigorously, you find other ways - you can use bit-banding to alter a pin state in a single instruction; no calls to routines etc so if timing is important there's a way of doing it.  Same thing for checking busy flags - without reading status registers.

None of this would be apparent to someone who simply uses the st library.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #247 on: June 14, 2016, 05:41:45 PM »
This was my reaction on someone who rewrote the entire library himself stripping it of loose ends and extra's he did not need.
The reaction was you have to do that every time again per processor which is still valid.
ST has changed the peripherpal lib interface once from if I recall correctly from the F1 to the F2. It took a couple of manweeks work to adjust the platform.
Still if you then again have to do this exercise of stripping of the "useless code-fat" that someone did , he had to do that all over again.
 

Offline Chris Mr

  • Regular Contributor
  • *
  • Posts: 112
  • Country: gb
  • Where there's a will there's a way
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #248 on: June 14, 2016, 06:30:26 PM »
You do not have to do that on a per processor basis, just when an individual peripheral changes; and then its just that peripheral - all the common stuff stays the same.

Sometimes the base addresses of the peripheral change on a different processor but that's all.  I have the base addresses in a separate file (that's all that's in there, the base addresses) so no problem using a different processor.  Go to the memory map in the data sheet and type in the new base addresses to a file (using an old file as a template) - 10 minutes work maybe.

If you stop looking at the st code as a complete solution (which it isn't, and isn't intended to be) and start looking at the issue of being able to use the peripherals, things change.

The OP (which I can just see in the far distance using my high power binoculars) asked how to fix it.  If you think the st library is fine then why comment?

I don't quake in fear thinking about using a new ST processor, I just use it.  Alter a few addresses and away I go.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #249 on: June 14, 2016, 06:33:52 PM »
The OP (which I can just see in the far distance using my high power binoculars) asked how to fix it.  If you think the st library is fine then why comment?
;D
yes if you look at it on a module per peripheral basis and keep the config , init of the clocks and power in a seperate module initing the peripheral modules , so actually layering a bit more , you could make a nice workable solution for yourself.
 

Offline Chris Mr

  • Regular Contributor
  • *
  • Posts: 112
  • Country: gb
  • Where there's a will there's a way
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #250 on: June 14, 2016, 06:44:04 PM »
Clock and power are also peripherals, sometimes they change with processors, most often not  8)
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #251 on: June 14, 2016, 08:28:15 PM »
Quote
The reaction was you have to do that every time again per processor which is still valid.

It depends on how the person integrated the library into his code.

I use SPL in my code but looking at it you wouldn't know at all that SPL is used and the same user code works on different chips from ST and even with other vendors libraries. For example, to send a byte over spi, I always use spi_write(), regardless of platforms, or even if there is no spi hardware on a chip. On a PiC, that can be done via registers, or via plib; On a LM3S, that can be done via stellarisware; On a STM, different versions of SPL....

If ST changes its SPL, I just need to deal with the middleware and my user code remains the same.

Obviously, it can get more complex and less portable when fancier features are dealt with but that's the general idea.

That's pretty much true, in terms of how libraries are incorporated.
================================
https://dannyelectronics.wordpress.com/
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #252 on: June 14, 2016, 09:21:04 PM »
That is indeed how we in our company do it also, the SPL for different ST uC's and even other manufacturers HAL's are again abstracted to a company standard API (platform).
Takes some time but when finished a joy to work with and you can choose from different vendors and or uC series.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #253 on: June 15, 2016, 07:55:38 AM »
That's not surprising. Coding approaches are a compromise, many times between hardware and software costs. On a limited mcu, you may want to squeeze out every last bit of processor cycles or RAM byte. You often  sacrifice readability, portability or readability in order to get the code to fit in a particular budget.

For bigger chips, getting more performance isn't as interesting, and software costs matter more and more so you use more and more structured approaches. You abstract and sacrifice performance. And hardware to minimize software costs.

Personally I view layering as a bug plus. It allows me to produce a robust produce within a short period of time, and charge a lot of money for that.
================================
https://dannyelectronics.wordpress.com/
 

Offline Gibson486

  • Contributor
  • Posts: 38
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #254 on: June 21, 2016, 04:04:34 AM »
I am new to this....

I had to go through and choose between Freescale (now NXP) and ST.

At first, I was 100% on Freescale. Their IDE made everything *almost* easy.

When I first tried ST Micro (year ago), the whole flow was a cluster. It was just mounds of documentation that lead no where and the CubeMX barely worked. It felt like getting a LED to blink was a non trivial task. Also, it seemed like using the HAL was pretty difficult, but using the standard library was even worse.  And then trying to get it working with Atollic.....aw man (it basically a paid version of Eclipse!).With freescale, I was able to get the HAL or the standard lib blinking a light easily (although, their IDE needed to updated a few times).

Fast Forward to today, ST did something. The whole GUI works well now and they seemed to neaten up where to get documentation. I still think the standard library is easier on the Freescale for some reason, but the GUI makes up for it so I do not need to use the standard library. Also, last I tried, you could not use PE with those Freescale Freedom boards (tried 6 months ago and it did not work, so they could have fixed it now).
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #255 on: June 21, 2016, 04:19:08 AM »
I had to go through and choose between Freescale (now NXP) and ST.

Using a tool chain not tied to a particular vendor certainly helps.

For commercial use, I'd recommend Keil or IAR--they both support almost all Cortex-M vendors and have a consistent interface to all of them.

For hobbyist use, I suggest using Eclipse/CDT/GCC to build your own tool chain. It's vendor independent and works well with most Cortex-M parts (as long as you can find .h header files).
Never trust a government that doesn't trust you.
 

Offline Gibson486

  • Contributor
  • Posts: 38
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #256 on: June 21, 2016, 04:39:46 AM »
I had to go through and choose between Freescale (now NXP) and ST.

Using a tool chain not tied to a particular vendor certainly helps.

For commercial use, I'd recommend Keil or IAR--they both support almost all Cortex-M vendors and have a consistent interface to all of them.

For hobbyist use, I suggest using Eclipse/CDT/GCC to build your own tool chain. It's vendor independent and works well with most Cortex-M parts (as long as you can find .h header files).

That was the other big plus....

Programmer for ST - $20.
Programmer for Freescale - at least $250 unless you buy some cheap Chinese knock off.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1578
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #257 on: June 21, 2016, 06:47:35 AM »
Programmer for ST - $20.
Programmer for Freescale - at least $250 unless you buy some cheap Chinese knock off.

Doesn't Freescale support standard JTAG/SWD? If it does, you should be able to use a generic JTAG/SWD dongle + OpenOCD instead of shelling out for the official programmer. ST's micros certainly can be programmed and debugged like that, no need for ST Link.

 

Offline Gibson486

  • Contributor
  • Posts: 38
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #258 on: June 24, 2016, 11:44:47 AM »
This is interesting....

I was trying to get PWM to work with my micro....

The compare register function for the PWM value is from a macro....

Also, it is not in there user manual/API...I had to find it online.

I am sort of tempted to make my own library....
 

Offline Gibson486

  • Contributor
  • Posts: 38
  • Country: us
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #259 on: June 24, 2016, 11:50:53 AM »
Programmer for ST - $20.
Programmer for Freescale - at least $250 unless you buy some cheap Chinese knock off.

Doesn't Freescale support standard JTAG/SWD? If it does, you should be able to use a generic JTAG/SWD dongle + OpenOCD instead of shelling out for the official programmer. ST's micros certainly can be programmed and debugged like that, no need for ST Link.

Very true, but that is freescale's fault for not telling me. ;)
 

Offline picdev

  • Newbie
  • Posts: 4
  • Country: gr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #260 on: February 11, 2017, 05:18:30 AM »
I am working with 8 and 16bits MCUs write now and I want to start with ARM, but I don't now where to start  :-//
One solution is mikroc for ARM , but its crap , and the ide its horrible if you write big projects.
 

Offline TinkeringSteve

  • Regular Contributor
  • *
  • Posts: 97
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #261 on: February 11, 2017, 06:37:42 AM »
Hey picdev,

one very affordable way to have a modern IDE and do ARM cortex M debugging is:
- use (e.g. the community edition of)  Visual Studio 2013 / 2015
- spend 70,- EUR on the non-commercial license of the VisualGDB plugin

I have done projects with ST stuff and got some impressions from the Kinetis branch of NXP.
(can't comment on the native NXP stuff (they did cortex M stuff before buying kinetis I think)

The Kinetis devboard + libraries I used seemed less of a hassle to get to work (more than just toglging a pin) than the ST stuff, and many people agree the ST libs are bad.
But the Kinetis libs were also not quite perfect, it's probably also not a high prio project at NXP / former Kinetis, similar to ST.
But... when using just CMSIS (register definitions etc) and the reference manual of an MCU, ST stuff works fine.

OR: if strictly non-commercial, and you'd like a library, perhaps http://libopencm3.org/ could be a nice alternative .

I like ST's nucleo and discovery dev boards, debugger is already on those. Connect USB and you're done. (others are doing it this way too these days). I like the discovery more, while nucleo is geared towards arduino shield compatability, the discovery have the direct MCU pin names written besides the header pins instead stupid arduino pin names which I don't care about ;)

If you did pic before, maybe start with a smaller MCU. E.g. the stm32f100 discovery, or stm32f0 discovery. The larger ones like F4 or L4 can be even more overwhelming.
 
The following users thanked this post: picdev

Offline mrm2007

  • Contributor
  • Posts: 24
  • Country: 00
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #262 on: February 11, 2017, 07:09:28 AM »
I am working with 8 and 16bits MCUs write now and I want to start with ARM, but I don't now where to start  :-//
One solution is mikroc for ARM , but its crap , and the ide its horrible if you write big projects.

Hi,

 If you want to start with ARM, i can recommend this setup :

 IDE/Compiler : embitz : https://embitz.org , FREE IDE , based on Code-Blocks, compiler is GCC-ARM Embedded with debug capabilities.

 Board : STM32 Discovery or Nucleo board. Cheap and with installed ST-Link Programmer/Debugger on-board.

 
The following users thanked this post: picdev

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 1608
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #263 on: February 11, 2017, 09:00:14 AM »
I am working with 8 and 16bits MCUs write now and I want to start with ARM, but I don't now where to start  :-//
One solution is mikroc for ARM , but its crap , and the ide its horrible if you write big projects.

For starting you could use the Keil uVision IDE, which I tried for some time now. It is free for up to 32 kB binary size, with which you can do a lot. An example: A 10 voices polyphonic synthesizer with MIDI-in and I2S realtime out to the audio DAC at 48 kHz/24 bit on the Discovery board, and ADSR volume envelope, all calculated in float, needs 15 kB, hardware setup code created with CubeMX. It supports ST-Link, works with no problems with my STM32F4 Discovery kit with the integrated ST-Link, and there are many tutorials how to use the IDE.

PS: after removing all the CubeMX code-bloat and optimizing it a bit, the binary size was 2 kB for my synthesizer, with the same functionality. Would be nice if the code generator would at least create better and more optimized code, and not all these run-time algorithms just to set some fixed register values, this makes no sense.
quadro copter flying, electronics, retro computing and other geeky things: http://www.youtube.com/user/frankbuss/
 
The following users thanked this post: picdev

Offline picdev

  • Newbie
  • Posts: 4
  • Country: gr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #264 on: February 11, 2017, 08:07:34 PM »
Thank for your suggestions , libopen its nice suggestion, because you can have an alternative from Hal library.
I am not going to use SPL ,I think that is useless because it Doesnt support newer MSUs
Also I dont like code generators , microchip also now has code generator instead of libraries  :-- :palm:
« Last Edit: February 11, 2017, 08:12:45 PM by picdev »
 

Offline picdev

  • Newbie
  • Posts: 4
  • Country: gr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #265 on: February 12, 2017, 08:35:04 AM »
I start  reading mastering stm32
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1474
  • Country: pl
  • Troll Cave Electronics!
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #266 on: February 12, 2017, 11:51:29 PM »
I have recently had to use an STM32 model which is not supported by old SPL and I was forced to use CubeMX. For my development I use EmBitz IDE.

If you want to use a completly free IDE (EmBitz) which doesn't totally suck (like Atollic Truestudio does) and uses CubeMX for code generation, and the re-generation of hardware config files in Cube still works, it can be done and is perfectly usable.

Obviously, if you're aiming at achieving maximum performance or doing something unusual with any peripheral you'll need to write code on your own.

I think I'm gonna do a tutorial on how to mix CubeMX and EmBitz, because I see many people bringing the topic up.

Btw. I think that Cube implementation of freertos sucks. It's much better to use vanilla FreeRTOS installation base on sources available from their website.
I love the smell of FR4 in the morning!
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1578
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #267 on: February 13, 2017, 12:00:37 AM »
Thank for your suggestions , libopen its nice suggestion, because you can have an alternative from Hal library.
I am not going to use SPL ,I think that is useless because it Doesnt support newer MSUs
Also I dont like code generators , microchip also now has code generator instead of libraries  :-- :palm:

I can only recommend libopencm3. Between that and ChibiOS you don't need to touch HAL nor SPL at all. Just be aware of the licenses of both - it may or may not be suitable for your project.

 

Offline krho

  • Regular Contributor
  • *
  • Posts: 80
  • Country: si
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #268 on: February 13, 2017, 04:18:25 AM »
Is there a library for STM32F4 that has a permissive licensing or at least an linking exception. It's nice that there is a lot of GPLed ones but are completely useless for anything but home usage or school use.

I did a quck test a few days ago with STM's HAL and Os compiled binary with freertos+fatfs + sdio i2c and USB msc driver was 114k... and before trying I thought I could do a bootloader (IAP) with it. Will try without freertos but IMO it won't go below 100k. And I was all optimistic and thought that it will fit into the 32k with couple of kB to spare.
« Last Edit: February 13, 2017, 04:24:10 AM by krho »
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 1608
  • Country: de
    • Frank Buss
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #269 on: February 13, 2017, 04:36:51 AM »
Is there a library for STM32F4 that has a permissive licensing or at least an linking exception. It's nice that there is a lot of GPLed ones but are completely useless for anything but home usage or school use.

I just noticed that mbed has support for a board with an STM32F4:

https://developer.mbed.org/platforms/ST-Nucleo-F401RE/

I have used mbed for another microcontroller (LPC series) and it is a really nice and clean C++ framework, as easy to use as an Arduino, but more powerful and extensible (e.g. for implementing your own USB device you can derive from C++ classes and just redefine the necessary methods like for the device descriptor and the endpoint data transfer). Haven't tried it for the STM32F4 platform, but it is not difficult to create support for a similar board. When I tried it there was no support for the special version of my microcontroller, but I could create a new configuration with a different linker settings (other flash and SRAM configuration). And it is all on github, you can install it locally and don't need to use the online service, but it is nice and easy to use, too, if you do.

PS: most of mbed is Apache 2 license, similar to BSD.
quadro copter flying, electronics, retro computing and other geeky things: http://www.youtube.com/user/frankbuss/
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #270 on: February 13, 2017, 07:48:38 AM »
Is there a library for STM32F4 that has a permissive licensing or at least an linking exception. It's nice that there is a lot of GPLed ones but are completely useless for anything but home usage or school use.
I did a quck test a few days ago with STM's HAL and Os compiled binary with freertos+fatfs + sdio i2c and USB msc driver was 114k... and before trying I thought I could do a bootloader (IAP) with it. Will try without freertos but IMO it won't go below 100k. And I was all optimistic and thought that it will fit into the 32k with couple of kB to spare.
RTOS is only around 10k no idea where you are burning the other 100k, how big is the fatfs?
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1578
  • Country: fr
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #271 on: February 13, 2017, 09:46:48 PM »
I just noticed that mbed has support for a board with an STM32F4:

https://developer.mbed.org/platforms/ST-Nucleo-F401RE/

I have used mbed for another microcontroller (LPC series) and it is a really nice and clean C++ framework, as easy to use as an Arduino, but more powerful and extensible

Be very very careful here. mBed works great on the LPC series because that one is the best supported (the original mBed boards were LPC1768 based). However STM32 support is spotty at best, so before deciding to invest the time and effort in mBed, do verify that the features you need are actually supported on the hw you are planning to use!

In my experience on STM32 the support was often in name only - aka it compiles and you can do some really basic stuff like twiddling an I/O pin. More complex peripherals like USB are often not supported at all or only on some chips and not others, for no apparent reason and with no known roadmap when they could be supported. Or only very limited support is available, missing most of the features of the hw (timers are a typical example), so if you want to use it you have to resort to register programming - all the while paying the mBed/STM32 HAL (which is what mBed uses on STM32) "bloat & bug" tax.

If you are working with NXP LPC series, mBed can be a great option but I would hesitate to recommend it for any other hw platform.
 

Online thm_w

  • Frequent Contributor
  • **
  • Posts: 305
  • Country: ca
Re: ST's (STM32Cube) software ecosystem is terrible - how can we fix it?
« Reply #272 on: February 15, 2017, 09:38:23 AM »
RTOS is only around 10k no idea where you are burning the other 100k, how big is the fatfs?
Fatfs about 10kB for basic implementation.
SDMMC 10kB as well.

100kB is not unreasonable as that is what I am taking (HAL, fatfs, sd, i2c, uart, etc.). But I have not bothered to look to optimize as the uc has plenty of flash.
Maybe he can post the memory listing.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 3426
  • Country: nl