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

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