ST's (STM32Cube) software ecosystem is terrible - how can we fix it?

[v]

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.

[JohnnyBerg]

tl;dr The STM32/Cube software ecosystem is the worst I have ever seen. Does anyone feel the same?

I do

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

[AndyC_772]

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.

[mikeselectricstuff]

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.
 

[JohnnyBerg]

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.

[dannyf]

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.

- how can we fix it?

by not using it.

The good old standard peripheral library is perfectly fine. Or go to the registers directly.

[v]

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.

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.

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.

[JohnnyBerg]

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.

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.

[dannyf]

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.

[v]

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.

[nerdyHippy]

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.

[dannyf]

The other board works fine with the same code.

that would confirm for you that the issue is NOT with the code.

[diyaudio]

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...   

 
 
 

[v]

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...

[clive1]

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.

[kamtar]

Me too, im using atmel just because of VS IDE. Documentation is pretty good, lots of useful app notes,etc..

[dgtl]

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.

[dannyf]

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.

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.

[andyturk]

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?

[JohnnyBerg]

Clive? *the* Clive from STM32 forums?

When Clive dies, ST ARM dies .. 

[FrankBuss]

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).

[diyaudio]

Clive? *the* Clive from STM32 forums?

When Clive dies, ST ARM dies .. 

Clive deserves an award.

[dannyf]

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.

[donotdespisethesnake]

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.

[dannyf]

I had to trawl through the whole project fixing them.

How did you "fix" it then?

[nazcalines]

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.

[Frank]

Code: [Select]

__weak void HAL_Delay(__IO uint32_t Delay)
{
  uint32_t tickstart = 0;
  tickstart = HAL_GetTick();
  while((HAL_GetTick() - tickstart) < Delay)
  {
  }
}


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)
  {
  }
}


[NF6X]

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. 

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.

[Kjelt]

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.

[hamdi.tn]

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.

[Yansi]

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.

[Narmaraktuk]

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.

[Yansi]

I wouldn't trust any thirdparty multi-vendor library. That smell like a big trouble.

[dannyf]

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".

[dannyf]

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.

[donotdespisethesnake]

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...!

[Dago]

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).

[Kjelt]

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.

[AndyC_772]

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.

[Kjelt]

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 

[Towger]

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.

[Kjelt]

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 

[AndyC_772]

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.

[Kjelt]

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

[dannyf]

-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.

[dannyf]

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.

[FrankBuss]

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.

[NF6X]

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. 

[Lukas]

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>

[poorchava]

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)

[v]

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.

[FrankBuss]

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.

[diyaudio]

MPLAB never hits breakpoints correctly, seriously WTF. when will this mess end?

[Lukas]

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.

[westfw]

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:

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.)

[baoshi]

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/

[dannyf]

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

[baoshi]

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

Right. It helps me to understand how bad it is

[kalhana]

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!
 

[JohnnyBerg]

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 

[v]

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.

[NVIC]

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

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

[hamdi.tn]

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

They added F1 series recently

[yuantuh]

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.
 

[Ribster]

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/

[Joerg]

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 ...

[richardman]

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?

[Ribster]

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

[autobot]

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 

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 ?

[c4757p]

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 ) and time (which bean-counters don't want to pay for) to write non-bloated libraries that aren't total shite.

[Joerg]

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 :-) ...

[FrankBuss]

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.

[Ribster]

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!

[geno86]

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.

 

[gnasirator]

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.

[Sal Ammoniac]

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.

[MobileWill]

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.

[westfw]

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"...

[MobileWill]

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.

[mhelin]

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

[mhelin]

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?

[jeremy]

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 

[Sal Ammoniac]

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.

[savril]

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.

[Kjelt]

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

[dannyf]

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.

[Sal Ammoniac]

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.

[westfw]

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.

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...

 

[Back2Volts]

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

[Kjelt]

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 

[Koen]

ST should buy ChibiOS HAL and work from there. It's clean, practical, efficient, correct and easily understandable.

[technix]

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.

[dannyf]

"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.

[eck]

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.

[jnz]

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!

[janoc]

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.

[stmdude]

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..

[dannyf]

"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.

[epv]

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.

[dannyf]

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,

[epv]

And it seems they've carried over that nonfunctionality into CubeMX, too! 

[eck]

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.

[janoc]

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.

[splin]

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

[dannyf]

it seems they've carried over that nonfunctionality into CubeMX, too!

No wonder that Cube sucks,

[splin]

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.

[janoc]

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.

[autobot]

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.

[neslekkim]

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.

[splin]

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.

[splin]

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.

[jnz]

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.

[westfw]

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

[jnz]

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)

[richardman]

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 :-)

[Kjelt]

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.

[dannyf]

"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.

[Sal Ammoniac]

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.

[janoc]

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. 

[andyturk]

[...] 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!

[dannyf]

" 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.

[dannyf]

"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.

[jnz]

"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.

[Kjelt]

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.

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.

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.

[Sal Ammoniac]

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.

[Sal Ammoniac]

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.

[dannyf]

" 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.

[dannyf]

" 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.

[westfw]

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...  https://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/msg522553/#msg522553 )

[westfw]

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...)

[Kjelt]

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.

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 
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. 

[Kjelt]

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.

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.

[richardman]

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.

[Kjelt]

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.

[Kjelt]

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;
}


[dannyf]

" 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.

[Kjelt]

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   */


[Sal Ammoniac]

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.

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.

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...

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. 

[Kjelt]

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:

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.

[westfw]

#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;
}

[Sal Ammoniac]

But here: I'll throw up the clock initialization function, which I think is really hard to justify...

Barf!    My code, which does essentially the same thing, is 25 lines of code.

[jnz]

Barf!    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...

[Koen]

Yes, ChibiOS and libopencm3 would surely welcome patches from such incredibly talented programmers who write improved libraries from scratch !

[richardman]

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...

[Kjelt]

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.

[richardman]

Most M0 only has 32K...

[Sal Ammoniac]

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?

[dannyf]

" 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.

[westfw]

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.

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. :-(

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.)

no one ever posts up their code.

I did.  https://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())

[richardman]

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.

[JPortici]

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

[obiwanjacobi]

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.

[richardman]

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 :-)

[westfw]

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?)

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.

[Kjelt]

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.

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  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!  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! 
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.

[westfw]

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?

[Kjelt]

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    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.

[Kjelt]

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.

[westfw]

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.

[Kjelt]

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.

[obiwanjacobi]

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...

[dannyf]

"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.

[JPortici]

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)

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.

[Kjelt]

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.

[Kjelt]

PS: not want to offend you but if this is what you are now already facing and having problems with:
https://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.

[obiwanjacobi]

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]

[JPortici]

PS: not want to offend you but if this is what you are now already facing and having problems with:
https://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

[autobot]

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) ?

[dannyf]

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.

[westfw]

Over in another thread: https://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...)

[richardman]

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"

[Kjelt]

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:

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.

[Sal Ammoniac]

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.

[westfw]

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."

[westfw]

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;
  }
}


[captbill]

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 

[captbill]

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.

[captbill]

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.

[dannyf]

#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.

[captbill]

#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

[westfw]

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...

[captbill]

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.


[jnz]

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.

[westfw]

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.")

[captbill]

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.

[Kjelt]

@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 

[richardman]

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

[Kjelt]

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.

[obiwanjacobi]

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]

[richardman]

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.

[bazsa56]

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.

[dannyf]

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.

[Koen]

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).

[markone]

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 ?

[andyturk]

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.

[MT]

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?

[jnz]

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.

[Karel]

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...

[Sal Ammoniac]

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.

[dannyf]

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.

[captbill]

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

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

[richardman]

"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.

[Karel]

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.

[dannyf]

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".

[Kjelt]

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 
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.

[dannyf]

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.

[splin]

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:

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.

[Sal Ammoniac]

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.

[jnz]

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.

[westfw]

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...

[richardman]

I feel that this thread has spawned many arms and approaching thread-death ;-P

[jnz]

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.

[dannyf]

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.

[richardman]

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.

[donotdespisethesnake]

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. 

[richardman]

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...?

[richardman]

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 

[Sal Ammoniac]

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.

[richardman]

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

[dannyf]

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,

[Sal Ammoniac]

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?

[obiwanjacobi]

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]

[JPortici]

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

[Kjelt]

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.

[dannyf]

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.

[dannyf]

"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.

[jnz]

• 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.

[markone]

• 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. 

[Jeroen3]

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.

[Sal Ammoniac]

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.

[MT]

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.

[dannyf]

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.

[jnz]

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?

[Chris Mr]

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.

[dannyf]

That sounds like a lot of work,

It does and is totally unnecessary with a modern ide.

[Chris Mr]

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 

[dannyf]

"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.

[Kjelt]

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.

[obiwanjacobi]

"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.

[Chris Mr]

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 

[Kjelt]

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.

[Chris Mr]

Ah, why ST get so much bashing is because they were the first to do it - years ago!

[mark03]

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.

[Sal Ammoniac]

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.

[dannyf]

"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.

[Chris Mr]

"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.

[Kjelt]

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.

[Chris Mr]

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.

[Kjelt]

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?

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.

[Chris Mr]

Clock and power are also peripherals, sometimes they change with processors, most often not 

[dannyf]

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.

[Kjelt]

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.

[dannyf]

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.

[Gibson486]

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).

[Sal Ammoniac]

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).

[Gibson486]

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.

[janoc]

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.

[Gibson486]

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....

[Gibson486]

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.

[picdev]

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.

[TinkeringSteve]

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.

[mrm2007]

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.

[FrankBuss]

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.

[picdev]

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 

[picdev]

I start  reading mastering stm32

[poorchava]

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.

[janoc]

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 

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.

[krho]

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.

[FrankBuss]

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.

[Kjelt]

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?

[janoc]

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.

[thm_w]

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.

[Kjelt]

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.

I wonder if this is the debug size eg the optimizer is off than I understand.

[obiwanjacobi]

I finally am taking my first hands-on steps in the ARM domain (blinky led for the win ) using a cheap STM32F103C8 ebay board.

Roaming the interweb for some coding relief I found Kvasir: http://kvasir.io/
It is a bit old-ish but still has some recent commits...

I like this! It is not a full solution - seems to only cover the registers and fields etc - but it's on the right track.
Does anybody know any other meta-programming libraries that make good use of the modern C++ features (and templates)?

[krho]

Like I said Its Os aka optimize for size.
And Like I said. I was hoping to use this IAP (except frertos this one was added just because). And was hoping this would fit into 32k.
Hell nuttx is with all that drivers and some more! is that size and it's fully fledged OS.

And I still haven't find the time to check the sizes of modules sorry other things have higher priority. Maybe I'll find some time on friday.

[janoc]

I finally am taking my first hands-on steps in the ARM domain (blinky led for the win ) using a cheap STM32F103C8 ebay board.

Roaming the interweb for some coding relief I found Kvasir: http://kvasir.io/
It is a bit old-ish but still has some recent commits...

I like this! It is not a full solution - seems to only cover the registers and fields etc - but it's on the right track.
Does anybody know any other meta-programming libraries that make good use of the modern C++ features (and templates)?

This is pretty neat! I haven't seen this library before.

If you are looking for C++ then there is https://github.com/andysworkshop/stm32plus
That one is pretty exhaustive, but be prepared for some C++ template voodoo.

[obiwanjacobi]

Thanx for the link. A quick look at its HD44780 (LCD) implementation reveals he didn't separate the protocol from the hardware connections. So I think my library is better 

I read (and watched) more about the Kvasir library. It is gold! Perhaps I change my mind when I start working with it, but this guy knows his templates and has a good grasp of embedded programming problems (as far as I can tell) and knows how to build a public API too - in that you don't want to expose your users/devs to the hard-to-understand/learn stuff.

[Kjelt]

(as far as I can tell) and knows how to build a public API too - in that you don't want to expose your users/devs to the hard-to-understand/learn stuff.

My 18+ years of embedded programming experience tells me:
- sooner or later you encounter a problem where you do have to understand the stuff below the HAL, the "hard to understand stuff" as you call it. Read the datasheets and be done with it.
- C++ nice for larger (embedded) systems, not so nice if you have limited RAM in your system, C still rules.

[FrankBuss]

- C++ nice for larger (embedded) systems, not so nice if you have limited RAM in your system, C still rules.

That's wrong, a C++ program doesn't need more RAM. E.g. if you use objects, it would be the same as if you implement the same with structs in C. The only difference is that in C it is horrible to implement an object oriented system (I used to work on a system written in C, which had a macro named CLASS and other such things). But it is true that some standard C++ libraries are not optimized for embedded systems and if you use them, it might result in more RAM and ROM requirements compared to a C program which does the same, but which would require much more source code to be written by the application developer.

[obiwanjacobi]

My 18+ years of embedded programming experience tells me:
- sooner or later you encounter a problem where you do have to understand the stuff below the HAL,

Perhaps, perhaps not. If so, you can always go deeper. Meanwhile, the one using a good library will be more productive earlier.
Also note that this particular library does not abstract the registers (afaics). It just makes sure you cannot do it wrong and the code generated is optimal.

the "hard to understand stuff" as you call it. Read the datasheets and be done with it.
- C++ nice for larger (embedded) systems, not so nice if you have limited RAM in your system, C still rules.

With the 'hard to understand stuff' I meant the C++ meta programming template stuff. 

If you think C still rules, fine use that - and perhaps look into meta programming on the weekends.
Meanwhile I use what I think is best. I do not fancy discussing that again...

[janoc]

With the 'hard to understand stuff' I meant the C++ meta programming template stuff. 

I am writing C++ for perhaps 15 years now and still find C++ templating a horrid kludge trying to plaster over the lack of proper macros in C/C++. I know how the template metaprogramming stuff works but I am avoiding that like a plague - it is the perfect way to produce "write-only" unmaintainable code, especially if you are not the only person dealing with it.

On the other hand, it still beats the half-assed generics in C# that look like C++ templates, but you can't do anything more advanced with them

[obiwanjacobi]

On the other hand, it still beats the half-assed generics in C# that look like C++ templates

Templates != Generics. You cannot use your C++ template mindset and expect to understand generics...

When I first learned C I thought how on earth could someone understand this jibberish: as with anything, understanding the rules, logic and patterns behind it helps a lot. 

The Kvaris library shields you from having to know or even see the template implementation (the 'hard to understand stuff').

[janoc]

Templates != Generics. You cannot use your C++ template mindset and expect to understand generics...

Eh, no worries, I think I have a fairly good grasp of what the generics do and how they work. The problem is that they are so limited that many common situations cannot be done without duplicating code. Which kinda defeats the purpose. I am not speaking about any fancy metaprogramming, just completely bog standard generic code that needs to be polymorphic depending on the type passed.

For me it is one of the many stupid things in C# that are driving me up the wall (like compilation error because of a name clash if you define a variable outside of a scope and then redefine a local one inside of it -  ).

But I don't want to hijack the thread with rants on C#

The Kvaris library shields you from having to know or even see the template implementation (the 'hard to understand stuff').

Yes, it seems to be sensibly designed. Debugging that code could be "fun" though - as pretty much always with templates. Few if any debuggers handle them in somewhat sensible way.

[obiwanjacobi]

Yes, it seems to be sensibly designed. Debugging that code could be "fun" though - as pretty much always with templates. Few if any debuggers handle them in somewhat sensible way.

You will not see most of it (my guess), that is the whole idea of figuring things out at compile time.

[janoc]

You will not see most of it (my guess), that is the whole idea of figuring things out at compile time.

Yes, of course - which is the entire problem because it is going to massively throw you off when single-stepping through code.

[WalkOver]

Hello picdev

Is it possible to have more info about mikroc pro ARM ?
You said it's crap but why ?

I worked a little with mikroc pro AVR and I found the IDE light but enough powerfull to me.

Im interested to have info from advanced users

Thank you.

[picdev]

I am writing desktop application with java, and I came accros with this http://www.microej.com/resources/supported-platforms/
Is there any free development platform with java for stm32 ?

[janoc]

I am writing desktop application with java, and I came accros with this http://www.microej.com/resources/supported-platforms/
Is there any free development platform with java for stm32 ?

AFAIK, no.

I don't think I have seen Java offered for any micro whatsoever, it is just too much of a resource hog for the small chips. You may be able to get the Java SE/ME Embedded from Oracle, but that has to be licensed and I believe that works only on higher end SoCs, not microcontrollers.

[Jeroen3]

I've seen Java on a PIC16... 
Anyway, if you think java on an small mcu is a good idea, your software development permit should be revoked.

[Koen]

If you think using the language Java means running applications on the JVM, your software development permit should be revoked.

It's a language. It's plain-text. Anything can be made out of it. Including bare-metal firmwares for the STM32.

[andyturk]

It's a language. It's plain-text. Anything can be made out of it. Including bare-metal firmwares for the STM32.

Really? Java? Got a link?

[Koen]

picdev's link above is Java on STM32.

[newbrain]

picdev's link above is Java on STM32.

From that very "2.0" (==information hiding) website:

MicroEJ OS Core provides a secure engine that can run multiple applications. It is based on an optimized – for performance – and compact – for footprint: down to 30 KB – Java virtual machine (JVM)

If they have something bare-metal, I was not able to find it.

[Koen]

Well, what do you think that is ?

[newbrain]

Well, what do you think that is ?

Running applications on the JVM.
So maybe my SW development permit should be revoked. Or theirs.

Or I misunderstood your point:

If you think using the language Java means running applications on the JVM, your software development permit should be revoked.

[blkdev2]

I am writing desktop application with java, and I came accros with this http://www.microej.com/resources/supported-platforms/
Is there any free development platform with java for stm32 ?

The .NET Micro Framework is pretty similar and appears to have a maintained port for STM32F4.

For other garbage collected OO languages take a look at MicroPython or the various JavaScript offerings. Java is just disastrously out of fashion these days, I'm afraid.

[Koen]

Yes, you misunderstood my point and misunderstood what their JVM is. It's marketed for current desktop/server developers. If your questions are serious, things are explained in http://developer.microej.com/index.php

[technix]

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)

This is mostly true for me too, although I do accept the use of hardware header file, CMSIS basic headers and a third party C library (newlib.) Here is an example of what I am talking about.

Cube for me is only an interactive part selector and pin planner, occasionally a clock tree reference.

Vendor HAL is crap from my perspective (be it ASF, MCC or Harmony from Microchip or Cube from ST) so I am avoiding those as much as possible. A good HAL need to be platform and vendor agnostic, so those "vendor HAL" flat out does not meet this criteria. A good example of a good HAL would be the Arduino API.

In my own code I do use HAL - a mix of POSIX API and Arduino API for features not exist in POSIX.

[Kjelt]

A good HAL need to be platform and vendor agnostic, so those "vendor HAL" flat out does not meet this criteria. A good example of a good HAL would be the Arduino API.
In my own code I do use HAL - a mix of POSIX API and Arduino API for features not exist in POSIX.

Any peripheral differs from vendor to vendor. So the layer above the peripheral  that handles the init and all the tweaks and quircks , flags and interrupt etc from that peripheral ,usually called the HAL is and will always be vendor specific.

Nothing is stopping you from writing a proprietary userHAL on top of the vendors HAL, but saying that all HALs from all vendors should be equal is waiting for utopia.

[technix]

A good HAL need to be platform and vendor agnostic, so those "vendor HAL" flat out does not meet this criteria. A good example of a good HAL would be the Arduino API.
In my own code I do use HAL - a mix of POSIX API and Arduino API for features not exist in POSIX.

Any peripheral differs from vendor to vendor. So the layer above the peripheral  that handles the init and all the tweaks and quircks , flags and interrupt etc from that peripheral ,usually called the HAL is and will always be vendor specific.

Nothing is stopping you from writing a proprietary userHAL on top of the vendors HAL, but saying that all HALs from all vendors should be equal is waiting for utopia.

So far the Arduino folks have been doing a good job keeping AVR8, SAM3X and SAMD21 in the ropes, and TI folks is looping in MSP430 too.

In fact the sole point for me to bring up POSIX is because itself is too a HAL and have been used to abstract away platform differences on a good multitude of hardware platforms: the same POSIX API works on things from PC (Linux) to Mac (macOS) to embedded systems (uCLinux) to smartphones (iOS) to game consoles (OrbisOS.) What I am trying to say here is maybe we can try make some parts of POSIX API work on STM32 without an operating system kernel.

[blkdev2]

Various RTOSes are taking up the challenge of providing a vendor-neutral API. I can verify that the STM32 port of Zephyr is usable, although lacking some drivers: https://www.zephyrproject.org/doc/api/api.html

Problem is, designing a flexible vendor-neutral API with low overhead is fundamentally hard, and they all end up as lowest-common-denominator solutions to some extent. Zephyr needs to attempt this because it is ultimately trying to enable composable systems where the software components (e.g. network stacks) may come from different vendors, while mediating concurrent access to hardware.

For many applications it's better to write an application-specific HAL that contains precisely the functionality you use and port that between vendors on an as-needed basis.

So far the Arduino folks have been doing a good job keeping AVR8, SAM3X and SAMD21 in the ropes, and TI folks is looping in MSP430 too.

There's already a port to STM32 that works with the common F103 boards https://github.com/rogerclarkmelbourne/Arduino_STM32. I don't personally feel the Arduino hardware abstractions qualify as "good" but that's a matter of opinion.

[technix]

Various RTOSes are taking up the challenge of providing a vendor-neutral API. I can verify that the STM32 port of Zephyr is usable, although lacking some drivers: https://www.zephyrproject.org/doc/api/api.html

Problem is, designing a flexible vendor-neutral API with low overhead is fundamentally hard, and they all end up as lowest-common-denominator solutions to some extent. Zephyr needs to attempt this because it is ultimately trying to enable composable systems where the software components (e.g. network stacks) may come from different vendors, while mediating concurrent access to hardware.

For many applications it's better to write an application-specific HAL that contains precisely the functionality you use and port that between vendors on an as-needed basis.

So far the Arduino folks have been doing a good job keeping AVR8, SAM3X and SAMD21 in the ropes, and TI folks is looping in MSP430 too.

There's already a port to STM32 that works with the common F103 boards https://github.com/rogerclarkmelbourne/Arduino_STM32. I don't personally feel the Arduino hardware abstractions qualify as "good" but that's a matter of opinion.

In my opinion for a POSIX-style HAL the only thing that can muddy things up is open(2). I am talking about using GCC toolchain, and make use of linker garbage collection here to keep the final image size down. Since for embedded systems there is no vfs the traditional vfs-based open(2) either loops in too much drivers (making the final binary too large,) or makes implementing a VFS troublesome (difficult to patch,) I usually go for a driver-specific open(2), kind of like the socket(2) and pipe(2) calls. This allows the GNU linker garbage collection to throw out unused drivers, while still keeping a POSIX-like semantic. Here is the code used to set up the stdin, stdout and stderr streams in my code:

Code: [Select]

void __attribute__((constructor)) _stdio_init(void)
{
    int usart_fd = open_uart(USART1, O_RDONLY, 115200, 8, 0, 1); // This function calls open_device, which actually allocates the file descriptor.
    dup2(usart_fd, STDIN_FILENO);
    if (usart_fd != STDIN_FILENO) close(usart_fd);
    usart_fd = open_uart(USART1, O_WRONLY, 115200, 8, 0, 1); // Have to close and open again to reset the permissions.
    dup2(usart_fd, STDOUT_FILENO);
    dup2(usart_fd, STDERR_FILENO);
    if (usart_fd != STDOUT_FILENO && usart_fd != STDERR_FILENO) close(usart_fd);
}This code opens USART1 for stdin, stdout and stderr at 115200bps 8/N/1. THis is usually a good starting point for application code.

[Gibson486]

A good HAL need to be platform and vendor agnostic, so those "vendor HAL" flat out does not meet this criteria. A good example of a good HAL would be the Arduino API.
In my own code I do use HAL - a mix of POSIX API and Arduino API for features not exist in POSIX.

Any peripheral differs from vendor to vendor. So the layer above the peripheral  that handles the init and all the tweaks and quircks , flags and interrupt etc from that peripheral ,usually called the HAL is and will always be vendor specific.

Nothing is stopping you from writing a proprietary userHAL on top of the vendors HAL, but saying that all HALs from all vendors should be equal is waiting for utopia.

So far the Arduino folks have been doing a good job keeping AVR8, SAM3X and SAMD21 in the ropes, and TI folks is looping in MSP430 too.

In fact the sole point for me to bring up POSIX is because itself is too a HAL and have been used to abstract away platform differences on a good multitude of hardware platforms: the same POSIX API works on things from PC (Linux) to Mac (macOS) to embedded systems (uCLinux) to smartphones (iOS) to game consoles (OrbisOS.) What I am trying to say here is maybe we can try make some parts of POSIX API work on STM32 without an operating system kernel.

I applaud Arduino for doing it, but if you ever dug under the hood, you will see the pain they went through to get it to work. In my experience, just from going from a Freescale m4 to a St Micro m4 is a lot of work because the peripherals do not work the same way. The closest thing to to what you want is mbed. Essentially, took the vendor HAL and put their own API on top of it. 

[blkdev2]

The closest thing to to what you want is mbed. Essentially, took the vendor HAL and put their own API on top of it.

mbed lost me with the transition from mbed 2 to mbed OS 5, but I believe they've abandoned the lightweight event driven concurrency model for a full RTOS based on CMSIS-RTOS... and have renamed/rewritten all the tooling.

[Gibson486]

The closest thing to to what you want is mbed. Essentially, took the vendor HAL and put their own API on top of it.

mbed lost me with the transition from mbed 2 to mbed OS 5, but I believe they've abandoned the lightweight event driven concurrency model for a full RTOS based on CMSIS-RTOS... and have renamed/rewritten all the tooling.

This is probably the right move in the long run. After trying to help out a few newcomers I feel like an RTOS is what most people want. Try explaining the concept of hardware timers and interrupt handlers to someone who just wants their project to do the equivalent of walk and chew bubble gum. Not fun. They can spare a few KB though, no problem. Arduino is utterly deficient.

I have not used it the past 2 years. That is sad that they did that.

[duparq]

I started a project of a HAL a few years ago when I wrote my first program for an STM32F103. I have called it HWA.

The goal was to get very readable and concise source code producing fully optimized binaries. I think I have reached it.

HWA is still at the beginning concerning the STM32, but the support of a few Atmel AVR8 chips is more mature and a bunch of examples demonstrate what can be done with it.

It is free software: https://github.com/duparq/hwa

You'll find a documentation here: http://duparq.free.fr/hwa/index.html

The way it works is very different of all others I have seen so far.

Any comment on HWA would be greatly appreciated!