Moving home from ST land

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

[voltsandjolts]

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

I rarely need the ARM documentation, when using any decent C/C++ compiler, it just works^TM.
I do PIC32 (MIPS) and some STM32 stuff, and TBH I don't really notice the change in core.
I do appreciate the difference in peripherals and their documentation, where I prefer PIC32..but that's just me.

[Siwastaja]

ARM documentation is fine but not needed that often.

Ignoring full instruction set reference, the most important parts of ARM core documentation could be squeezed in maybe 50-100 pages.

You could never do that for the complete microcontroller, not even near.

There just is more programming complexity in all the peripherals, than the core.

Additionally, because gazillion manufacturers use the same ARM cores and they do not need frequent improvements (Cortex M3 for example introduced in 2004, still just fine), writing coherent documentation and maintaining it is orders of magnitude easier than coming up with a hugely complex part like STM32H7 with 100 different peripherals half of them different to the earlier revisions in some way, competiting who's first on the market with such a part.

[SiliconWizard]

Technical documentation is f*cking hard to get right and very time consuming. So I don't really blame vendors.
Yes modern MCUs are very complex so that makes the job a hell. Add to that the fact most engineers HATE writing docs.

In most cases, modern ARM-based MCUs for which I found the documentation excellent were ones with very few, and simple peripherals.

I think Microchip's documentation has gone "downhill" too as their MCUs started to get more complex. Once all was contained in a single datasheet. Now the docs are all over the place, with often a PDF per peripheral, which in itself wouldn't be a bad idea, except that those PDFs often cover a whole range of MCUs for a given peripheral and differences between MCUs is sometimes not clear, or even plain erroneous.

[Chris Mr]

I have an idea as to what might be behind it..

If you are a company who needs say 10 million micros, say for the auto industry, then you would probably be visited by people from the semiconductor manufacturers or even have a bat-phone direct line (which might explain why you can't easily get in touch with the semi manufacturer). When you place orders for devices it would be on the condition that the supplier provided all the "driver" code in a working state; it may even be that the large manufacturer gives the whole thing, as a project, to the semi manufacturer.  This is great for the semi company because in one deal it pays for most of the setup (maybe even all of it), and given that they are talking to all the other large manufacturers they can combine these big orders into single, common peripheral, devices.  In part this would explain why they mostly have CAN bus, or even as we see these days CEC (telly makers).

Then, they think to themselves, now we paid for the setup, and made some money, we could sell these to everyone else, but we need some documentation, and we can't sell the drivers we did for <x> so we'll get someone else to provide all that.. SiliconWizard quite rightly said that most engineers don't like writing data sheets etc.  The someone else then has the only interest of finishing, rather than doing a good job.

In part this might also explain why we find such tiny packages as the only option for FPGAs, and some micros, because they are being used in mobile phones where a single order pays for all the setup and makes a profit.

To put it another way, it's like the semi manufacturers have become field sales people that go into large companies, who know how to get micros made.  Documentation and good customer service to everyone else is not very important because it doesn't help the core business.

[harerod]

Quote from: Siwastaja on March 14, 2021, 04:07:06 pm

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

Amen to that. On the other hand, back in the day I outright hated Atmel for their bad docu. I wrote whole AT91RM9200 errata pages with my own time and money and AVR32AP was even more expensive. However, Atmel's docu improved mightily after the take-over.

And about ST - I really like to look at some documents and ask myself: "was this translated from a French original or was the original in some North African lingo and translated into English via a French". Great fun, for a hobby linguist.
To be fair - for the more mature chips the docu is mostly there(*) and mostly accurate.

(*) somewhere, just crawl through all the documents for that chip, its family, unrelated chips - you get the idea.

[rsjsouza]

Technical documentation is f*cking hard to get right and very time consuming. So I don't really blame vendors.
Yes modern MCUs are very complex so that makes the job a hell. Add to that the fact most engineers HATE writing docs.

I can vouch for that; it is very hard to properly gauge the documentation to get a smooth progression and consistency across the board - special points when the core is just a part of a much more complex device (Wi-Fi, BLE, etc.), a heavy protocol or layered software. In this case, the various components (RTOS, driver layer, protocol layer, interprocessor communication) are all created by various teams on the company and sometimes the only point where they all intersect is a simple example code. Drift too far away from them and you are navigating unchartered waters. Unfortunately you end up specializing in a specific manufacturer/device family, unless there is a very strong push to change. 

[technix]

I'd like to defend ST for not including the USB HS PHY on chip - it will need to have at lease two 480MHz capable I/O pads on the chip, which is expensive. The fastest pad on most ST chips are only up to 100MHz or lower, so using external PHY means even USB HS Only needs 60MHz pads.

Since you need USB HS + SDIO + Ethernet, let me see... STM32F407ZGT6 (LQFP144) + USB3300 (+ 74LVC1G04) + LAN8710A, hopefully that would work for you.

[Berni]

I'd like to defend ST for not including the USB HS PHY on chip - it will need to have at lease two 480MHz capable I/O pads on the chip, which is expensive. The fastest pad on most ST chips are only up to 100MHz or lower, so using external PHY means even USB HS Only needs 60MHz pads.

Since you need USB HS + SDIO + Ethernet, let me see... STM32F407ZGT6 (LQFP144) + USB3300 (+ 74LVC1G04) + LAN8710A, hopefully that would work for you.

ST already has STM32 chips with 1Gbit MIPI display interfaces.

I think its more that USB pins need to be fast but at the same time pretty resilient to damage since its a connection that goes outside of the device (Rather than MIPI that goes from CPU to LCD). There is a lot more ESD happening there and occasionally a connector or cable failure might send 5V into the data lines.

[technix]

ST already has STM32 chips with 1Gbit MIPI display interfaces.

I think those chips came after they had USB HS parts that required external PHY: STM32F207 and STM32F407 both already have USB HS when paired with external PHY. Then we have this thing called historic baggage forcing subsequent chips to support it, even though some newer chips like STM32F733 now comes with internal HS PHY.

I think its more that USB pins need to be fast but at the same time pretty resilient to damage since its a connection that goes outside of the device (Rather than MIPI that goes from CPU to LCD). There is a lot more ESD happening there and occasionally a connector or cable failure might send 5V into the data lines.

This too. It is much cheaper to hot air replace a USB3300 than the main MCU itself. High speed and high voltage tolerant are kind of in conflict. You just can't have both.

[SiliconWizard]

It's always a good idea to add protection on USB lines anyway instead of directly connecting the IO pins to the USB connector and call it a day. But to save a few cents, I guess many will be tempted to just do the later if there's an embedded PHY, and that might give ST a bad rep if too many MCUs get fried in the field due to this. And yes, properly protecting those pads from inside the IC is costly.

Also, it's all a matter of market. I guess MIPI interfaces give them a lot more market than integrated USB HS PHYs.

[Bassman59]

I'm not sure how helpful this is, but ...

1. The NXP LPC546xx Cortex-M4 devices have on-chip HS USB PHY and 10/100 Ethernet MAC. You need an Ethernet PHY, though.

2. The TI Tiva TM4C and MSP432E Cortex-M4 devices have on-board FS USB PHY with an ULPI interface to a HS PHY, as well as on-board 10/100 Ethernet PHY and MAC. (I have not gotten a straight answer out of TI what the real differences are between the TM4C and the MSP432, as both have the same processor core, run at the same clock rate, and have generally the same mix of peripherals.)
 
I found it reasonably easy to extend the TM4C's USB library to implement support for a classes not in their library (USB-MIDI). Other stuff is straightforward, too; their libraries are easy to understand, and they even have this neat but simple graphics library for building touch-screen interfaces.

I gave up trying to extend NXP's library to do the same (implementing a different USB class). Their tech support was basically, "Start by copying an example and modifying it" and it's a fucking mess. But the other stuff is pretty easy to do. The serial peripherals are all FLEXCOMMs, which can each be configured for any of the usual things (UART, USART, I2C, SPI, I2S).

TI's support for Ethernet is with either LwiP or their NetSDK (through TI-RTOS). There's a divergence between the TM4C and MSP432 devices in terms of their software support. I was originally interested in the TM4C because -- I admit to being lazy -- they had an understandable example of how to control peripherals (blink LEDs, read ADC, send characters on a UART) from a web page.

NXP has LwiP and Free-RTOS, that I remember.

I kinda wish Silicon Labs would come out with an ARM with High Speed USB support. Last time I used their USB library, it was really easy to extend and understand. They did it right: you get USBD_Read() and USBD_Write() functions, and you get an interrupt when there's new data on any endpoint, and it's a matter of just checking which endpoint interrupted and writing new data or fetching what's in the endpoint buffer. The "other guys" have overly-complicated examples. They all have implementations of things like CDC and MS and HID, but doing something else is painful.

Anyway, good luck.

[fourtytwo42]

Unfortunately this is not just an ST problem except I would say they are one of the worst offenders, in there case they try to hide behind there horrible software obfuscation layer to avoid the need for documentation. There peripheral documentation is all but non-existent and I suspect is bought in lumps of IP from here there and everywhere, it is bug ridden and functionally incomplete to boot. However if you are trying to use a modern MCU from practically anybody that relies on the details of peripheral implementation they all seem the same and support is non-existent. Personally I gave up on ST and returned to Microchip who I thought were getting pretty bad till I got subjected to ST's vacant market speak.

[technix]

Unfortunately this is not just an ST problem except I would say they are one of the worst offenders, in there case they try to hide behind there horrible software obfuscation layer to avoid the need for documentation.

I wouldn't touch their software layer with an eight-foot pole. Instead I write my own drivers and characterize their hardware myself, using whatever docs they have and some tinkering.

There peripheral documentation is all but non-existent and I suspect is bought in lumps of IP from here there and everywhere, it is bug ridden and functionally incomplete to boot.

Well ST is still holding on to some of their decades-old STM8 peripherals on their latest STM32 chips. It is likely that they just invented an APB to STM8 bus bridge and bought ARM cores, then their whole chip is basically STM8 with a 32-bit core.

Personally I have up on ST and returned to Microchip who i thought were getting pretty bad till I got subjected to ST's vacant market speak.

I went the other way: gave up on SAM and LPC, stayed for STM32.