Products > Embedded Computing

Moving home from ST land

(1/4) > >>

Chris Mr:
Hi Everyone,

I've been trying to use STM32 now for ages.  Mostly, in the end, I get it to work.

The main problem is how long it takes to get to the end.

The documentation is .. is .. well, we all have our own description, but it's far from great.

The "example code" is .. is .. well, we all have our own description, and i'll leave mine out!

The last straw happened today.  I was using the "STMCU finder" to find something that had, Ethernet, USB HS, SDIO, and it turned up with the STM32F723 which actually has a USB HS phy ON BOARD!  I never knew they even did one with the HS PHY.

I got really excited, for quite a while, and then, after reading about the HS PHY looked at the reference manual to find it doesn't have Ethernet at all.  The MCU finder even shows you a NUCLEO board with Ethernet on it, but the F723 doesn't have Ethernet.

It's all a bit like the episode of BlackAdder, where he follows Raleigh's example to become an explorer, and they give him a map prepared by the foremost cartographers of the land - a blank sheet of paper.  It you could fill it in as you go along, that would be really helpful.

So, I think this is the last straw.  It has pointed me to the airport, where I hope to find a new place to live, where there are maps, street signs, and so on.

Does anyone have any suggestions as to where to move house to?

I've been stuck in here for quite a while so there will hopefully be some options I know nothing about.

Siwastaja:
We all hate STM32 documentation, examples, libraries, appnotes, erratas, support, and so on.

It doesn't get magically much better elsewhere, though. The grass is green but sometimes mouldy everywhere.

The underlying problem is, these parts are awfully complex - mostly in a good way, i.e. advanced high-tech we couldn't even dream of just 2-3 decades ago, - yet extremely low cost, and designed by human beings with tight schedules.

If you find a better documented and supported product family, the chances are, it's even more difficult to fulfil lists of requirements such as Ethernet, USB HS, SDIO...

The large number of parts each boasting wide range of peripherals at low cost is something ST is quite good at.

By all means look elsewhere; if you already do the Right Thing and write in bare metal with bare GNU tools, the threshold to go to other vendors is very low since you don't need to re-learn any new tool. Just pick another ARM Cortex family, download the manuals and start writing some code. Nothing prevents you from surfing between manufacturers.

Chris Mr:
Many thanks Siwastaja,

I  thought about your reply for quite a while and am wondering about "the underlying problem"...

Has anyone had any bad experiences with the ARM documentation?

From my own perspective I have found it to be very good.  Not necessarily easy to read, but complete and accurate.. good reference material.

If the ARM documentation is good, then that might explain why so many semiconductor companies use ARM.  For example, imagine <insert micro controller manufacturer here> ST providing cores for other manufacturers to use given their standard of documentation - would that ever catch on  :-//

There are some interesting anomalies in this.  For example, if you look across ST reference manuals at, say the Ethernet peripheral, you find that whilst there is zero difference between them in terms of the registers, description etc, someone has re-formatted bits of it.  Eg, some registers have been expanded on (put onto two lines), but have the same contents, or areas that are reserved go from saying "res" to being highlighted out (dark grey), or bits of drawings are bigger.

All that takes time, from people who ought (as you say) to have tight schedules.  So if that's the case, then whoever is re-formatting the manuals isn't one of the busy people.. which kind of explains it.


Price’s law says that 50% of the work is done by the square root of the total number of people who participate in the work.

Berni:
Companies love to make ARM MCUs because they want to be in the ARM ecosystem.

They just buy a ARM core design and stamp it onto some silicon, no need to develop your own core. At the same time the ARM instruction set is incredibly well supported by compilers. There are multiple offerings out there that generate very good and efficient code. The MCU vendor technically doesn't even need to make a IDE since there already are lots of third party or open source IDEs out there. Even if they do make there own IDE they will generally just take Eclipse or something similar and slap it onto the GCC compiler because both are free, granted you do usually get some extra vendor specific creature comforts, but that's it. No need to develop a custom compiler for your proprietary special snowflake CPU architecture.

As for the peripherals they are a mix if bought IP and in house developed IP. This is usually where the most crap comes from. They tend to throw together peripherals and then start using the same peripheral on pretty much all of the MCUs. In a way this is good because drivers are much more cross compatible, but it also means they don't fix there peripherals at all. You see the same silicon bugs repeat again and again in the errata and the same poorly thought out operation. They mostly have a motivation to pump out new chips that are basically the same chip with the new ARM core slapped on, then make 100 variants of that with slightly different amounts of peripherals and memory.

In the old days MCUs ware indeed more thought out, but at the same time also simpler, so it was easier to design and document.

Chris Mr:
But the ARM ecosystem didn't get to be an ecosystem from nowhere.

I think the question is, do you have bad experience with ARM documentation?

Navigation

[0] Message Index

[#] Next page