Alternativen zu STM32?

RP2040, kostet bei Reichelt in Einerstückzahlen etwa 1 EUR:

https://www.reichelt.de/index.html?ACTION=446&LA=0&nbc=1&q=rp2040

Du musst allerdings noch ein QSPI-Flashrom mit einpreisen. Aber auch das 
bietet Reichelt in ähnlicher Größenordnung, Du liegst auch dann immer 
noch unter 3 EUR.

Beliebiges Beispiel:
https://www.reichelt.de/nor-flash-speicher-4-mb-2-7--3-6-v-spi-50-mhz-so-8-sst-25vf040b-p150726.html?&trstct=pos_11&nbc=1

Der RP2040 hat 264 kiB RAM, zwei M0+-Kerne und läuft mit > 100 MHz.
Im QFN-48 ist er durchaus noch lötbar. 5V-tolerant ist er nicht,

Cyblord -. schrieb:
> Unsinn. LCSC hat zig STM32 auf Lager.

Kann ich bestätigen und sie kommen auch an.

Abgesehen davon dass die Aufgabe wohl ein schneller 8051 wie EFM8LB1 
auch schaffen würde - und der ist lieferbar.

GigaDevice hat uC zu STM pinkompatibel - und funktionieren auch z.B.

https://www.olimex.com/Products/ARM/ST/STM32-H103/

https://www.olimex.com/Products/ARM/ST/STM32-H405/

Max G. schrieb:
> nachdem ST ja mittlerweile durch völlige Lieferunfähigkeit glänzt

Nur mal als Nebenbemerkung: Wenn ST Lieferschwierigkeiten hat, dann 
haben das normalerweise auch alle anderen Hersteller (das ist/war 
aktuell der Fall).

Frag doch mal jemanden der Infineon oder Renesas einsetzt, ob die es 
besser hatten.

Selbst wenn du bei einer Arm CPU bleibst, dann darfst du doch sehr 
vieles neu machen. Denn die HAL eines jeden Herstellers ist doch anders. 
Da fängt man doch bei I2C wieder bei 0 an, und darf sich mit den 
Register-Bits herumschlagen.
Ich habe STM und NXP hier am laufen, nichts von deren IO Subsystemen ist 
annähernd gleich.
Ich würde lieber 2 Monate auf STM warten, als 4 Monate meine Applikation 
auf einen anderen Hersteller portieren. Recompile reicht nicht.

Wühlhase schrieb:
> Wenn ST Lieferschwierigkeiten hat, dann
> haben das normalerweise auch alle anderen Hersteller

Definitiv nicht: Silabs und GigaDevice haben sich wohl rechtzeitig 
Fertigungskapazitäten gesichert und ST und NXP eben nicht.

Konnten SciLabs und GigaDevice denn liefern?

Wir hatten unzählige Threads, wo die Liefersituation bejammert wurde, 
aber ich kann mich nicht an eine einzige Jubelmeldung erinnern, in der 
ein Hersteller in Sachen Lieferfähigkeit irgendwie herausstach.

Auf Lager: 22.162

https://www.mouser.de/ProductDetail/Silicon-Labs/EFM32PG22C200F64IM40-C?qs=eP2BKZSCXI5h7BAxbMC1aw%3D%3D

Auf Lager: 23.946

https://www.mouser.de/ProductDetail/Silicon-Labs/EFM8BB31F32G-D-QFN24R?qs=hd1VzrDQEGiNTV6ET5oDug%3D%3D

Auf Lager: 247.881 :-)

https://www.mouser.de/ProductDetail/Silicon-Labs/EFM8BB10F8G-A-QFN20R?qs=DCjbIwhU0ZvjCZGuyMqPKg%3D%3D

Bei NXP tut sich auch was:

Auf Lager: 57.651

https://www.mouser.de/ProductDetail/NXP-Semiconductors/LPC812M101JDH20J?qs=y2kkmE52mdM7UiGFA28kdw%3D%3D

Lothar schrieb:

> GigaDevice hat uC zu STM pinkompatibel

Wie sieht's auf Softwareseite denn aus? Auch kompatibel?

Lothar M. schrieb:

> Ich sags mal so: du wirst in deinem STM32-Code mit hoher
> Wahrscheinlichkeit unsauber programmierte Stellen finden.

OK, also wenn man sich tatsächlich ans Datenblatt gehalten hat, dann 
funktioniert es auch?

PittyJ schrieb:
> Ich habe STM und NXP hier am laufen, nichts von deren IO Subsystemen ist
> annähernd gleich.

Ach wo. Ein Gegenbeispiel: die SDIO-Cores sind gleich. Allerdings 
vermute ich, daß die meisten Leute hier, die STM32 benutzen, von dem 
eigentlichen Chip nichts sehen wollen und nur das benutzen, was ihnen 
Cube,HAL&Konsorten liefern. Und sowas ist von Hersteller zu Hersteller 
eben recht ungleich, sonst könnte ja ein Kunde zu leicht wechseln.

Tja, ich hab ja schon vor Jahren gepredigt, daß man sich eben nicht an 
die Galeere irgend eines Herstellers selbst annageln sollte. Jetzt 
jammern all die herum, die es damals besserwissen wollten.

W.S.

Lothar schrieb:
> [..]

Ok, aber ich meinte eigentlich so den Zeitraum von vor einem Jahr. Jetzt 
entspannt sich der Chipmarkt ja wieder.

Zum Wechseln hift es, nicht die stm hal zu nehmen.
Mal abgesehen davon das ich die hal schrottig finde und die stl besser 
fand,aber das ist ja nicht das Thema.
LibOpenCM3 oder so hilft beim wechseln zwischen unterstützten Typen.

Wühlhase schrieb:
> Wir hatten unzählige Threads, wo die Liefersituation bejammert wurde,
> aber ich kann mich nicht an eine einzige Jubelmeldung erinnern, in der
> ein Hersteller in Sachen Lieferfähigkeit irgendwie herausstach.

Darüber jammert man nicht.

>Anforderungen sind eher simpel: zwei serielle Schnittstellen (alternativ
>SPI + seriell), so ab 64 kB Flash, wenigstens 8 kB RAM und ein paar
>Timer.
Da wird es höchstwahrscheinlich auch ein 8-Biter machen.
(32MHz bedeuten nicht unbedingt schneller in der Abarbeitung)

Max G. schrieb:
> Ich habe einmal von
> zwischen zwei verschiedenen MSP430-Familien zu Fuß portiert. Das brauche
> ich nicht noch mal, dann lieber HAL-Funktionen.

Wenn du so denkst, dann würde ich dir vorschlagen, ein passendes 
Ingenieurbüro zu beauftragen. Dann brauchst du dich nur um die 
kaufmännischen Dinge zu kümmern.

Max G. schrieb:
> Es scheint mir dennoch einfacher zu sein, mich in eine
> neue HAL einzuarbeiten als neue Register zu lernen.

Ich hab da so den Eindruck bei dir, daß du dich scheust, ins Manual zu 
schauen und daß du es bislang nicht geschafft hast, die verschiedenen 
Schichten (von den Algorithmen bis zu den untersten Peripherie-Treibern) 
zu trennen. Und daß du bei anderen Plattformen erwartest, die gleichen 
Dinge wie bei ST in der jeweils mitgelieferten Lib zu finden.

So etwa wie "ich suche einen beliebigen µC, aber er soll genauso 
aussehen und genauso funktionieren wie das, was ich bisher benutzt habe. 
Und das Pinout sollte am besten ebenfalls genauso sein".

W.S.

Max G. schrieb:
> Es scheint mir dennoch einfacher zu sein, mich in eine
> neue HAL einzuarbeiten als neue Register zu lernen.

Zumindest bei ST kann ich dir versichern dass man mit den Registern und 
dem Reference Manual vertraut sein sollte, bevor man sich mit der HAL 
beschäftigt. Denn die Doku der HAL setzt das voraus. Du verstehst sonst 
nur Bahnhof.

W.S. schrieb:
> daß du bei anderen Plattformen erwartest, die gleichen
> Dinge wie bei ST in der jeweils mitgelieferten Lib zu finden.
>
> So etwa wie "ich suche einen beliebigen µC, aber er soll genauso
> aussehen und genauso funktionieren wie das, was ich bisher benutzt habe.
> Und das Pinout sollte am besten ebenfalls genauso sein".

Wenn das so ist, dann ist Arduino für ihn richtig. Das abstrahiert noch 
weiter als die sonst üblichen HAL Bibliotheken.

Max G. schrieb:
> Es scheint mir dennoch einfacher zu sein, mich in eine
> neue HAL einzuarbeiten als neue Register zu lernen.

Wenn Du Dich für den RP2040 entscheiden würdest, könntest Du auch mit 
der Arduino-IDE starten und die zeitkritischen Dinge auf Registerebene 
programmieren. Das ist ähnlich einfach, wie mit einem ATmega.

Um Das zu probieren reicht eine kleine Platine zum Spielen aus: 
https://www.reichelt.de/fr/de/raspberry-pi-pico-rp2040-cortex-m0-microusb-rasp-pi-pico-p295706.html?&trstct=pos_3&nbc=1

Max G. schrieb:
> Den Renesas oder den EFM32 hat niemand im Einsatz und kann über das
> zugehörige Tooling berichten?

Ich hab mal was mit dem Gecko gemacht. Die Entwicklungsumgebung und HAL 
würde ich als "problemloser" als bei STM32 bezeichnen. Das läuft 
irgendwie "flüssiger".

Man hat aber kein grafisches Tool wie STM-Cube.

Markus

Ulrich P. schrieb:
> Genauso wie der TO kann ich auch nicht auf einen RP2040 ausweichen.

Wo hat er das denn geäußert?

> Das Modul ist schon fast doppelt so groß, wie mir an Fläche
> zur Verfügung steht.

Es erleichtert den Einstieg, hindert aber niemanden, sich ein passendes 
Board für den Chip nebst Flash-ROM zu machen.
Derzeit ist das eine realisierbare Lösung.

> Ich hatte gehofft ...

Viel Erfolg beim Warten ;-)

Der Konjunktiv ist schon eine feine Sache ;-)

Ulrich P. schrieb:
> Ich suche ein Pendant mit
> 64kB Flash, ein paar kB RAM, min. 2x 12bit ADC, gerne auch gemultiplext,
> dazu 2x DAC mit 12-bit

Lieferbar:

https://www.silabs.com/mcu/8-bit-microcontrollers/efm8-laser-bee

https://www.silabs.com/mcu/8-bit-microcontrollers/efm8-busy-bee

Lothar schrieb:

> GigaDevice hat uC zu STM pinkompatibel - und funktionieren auch z.B.
> https://www.olimex.com/Products/ARM/ST/STM32-H405/

Wie ist das eigentlich mit Overclocking? Den STM kann man problemlos von 
den spezifizierten 168MHz auf 240MHz übertakten, und das ohne 
zusätzliche Flash-Waitstates (relativ zu denen für 168MHz).

Geht das auch mit dem Teil von GigaDevice?

Nop schrieb:
> Den STM kann man problemlos übertakten

Mit solchen Aussagen würde ich vorsichtig sein. Die Angaben im 
Datenblatt haben einen guten Grund. Wenn du sie ignorieren willst ist 
das ganz alleine deine persönliche Sache, aber empfehle es nicht 
anderen, denn du willst für entsprechende Folgen nicht haften.

Steve van de Grens schrieb:

> Die Angaben im Datenblatt haben einen guten Grund.

Ja, z.B. im Hinblick auf den vollen Temperaturbereich.

> Wenn du sie ignorieren willst ist
> das ganz alleine deine persönliche Sache

Klar sollte man das nicht machen, wenn da wirklich was Ernsthaftes 
dranhängt. Ist ja bei Overclocking am PC auch nicht anders. Aber um zu 
sehen, was die Teile abkönnen, finde ich das durchaus interessant, 
einfach weil's geht.

Ulrich P. schrieb:
> die 8051 Derivate würde ich da eher am Limit einschätzen

"the EFM8 powers through with brute force — its 72 MHz core simply 
overwhelms other parts, pulling in an impressive 265 ksps performance. 
The penalty it pays is in power consumption — a massive 14.15 mA"

https://jaycarlson.net/pf/silicon-labs-efm8/

Max G. schrieb:
> gibt es den bei weitem besten
> und objektivsten Vergleich von µC-Architekturen, den ich bisher gesehen
> habe.

Ist ja alles ganz nett. Die ersten Kommentare sind fünf Jahre alt und 
zeigen damit, daß der Vergleich nicht mehr aktuell sein kann.

Deine Schmerzgrenze gibts Du mit drei Euro an und sondierst jetzt nach < 
1 € Teilen? Das finde ich zumindest 'ungeschickt', da die Einarbeitung 
in eine andere Architektur den meisten Aufwand bereiten wird.

So, hab jetzt mal mit dem Gigadevice GD32F405 rumgespielt, allerdings nur GPIO / ADC / DAC. Abgesehen von dem kleinen Stolperstein mit der Abfrage des voltage scaling (s.u.) lief das auf Anhieb, programmiert nach Datenblatt vom ST. Knaller!

Positiv:

Die Performance ist etwa 20% höher als bei ST, weil das Spiegel-SRAM wirlich keine waitstates hat - STs Caching kann mit der Holzhammermethode von GD nicht mithalten, solange man sich auf die ersten 512k beschränkt.

Übertaktung von 168 MHz auf 240 MHz geht genauso wie beim ST, und die Skalierung ist dieselbe: +43% Performance bei +43% Takt. Also, wenn man beim ST keine zusätzlichen Waitstates einstellt. Natürlich nicht über den gesamten Spannungs- und Temperaturbereich garantiert.

Waitstates kann man einstellen, es gibt aber ein separates Key-Register, ohne das die Einstellungen wirkungslos bleiben. ART-Caching kann man auch einstellen, was mangels ART-Cache folgenlos ist, aber es verursacht auch keine Probleme. Beides ist gut, weil es Binärkompatibilität sicherstellt.

Die Leistungsaufnahme im Betrieb ist vergleichbar mit ST.

Die Registerbelegung ist kompatibel mit ST.

Wenn man kurze taktunabhängige Delays braucht: DWT mit CYCCNT geht genau wie bei ST.

Flashen geht mit OpenOCD und OCD-JTAG-Adapter (Linux Mint 21 / Ubuntu 22.04), aber auch mit Segger JLink. Nicht getestet mit ST-Link, wird wohl eher nicht gehen.

Das Manual ist gut. Das Englisch ist manchmal ein bißchen off, keine Muttersprachler halt, aber dem Verständnis tut es keinen Abbruch.

Bei der GD32-Version der SPL habe mal reingeguckt, sieht im Sinne von Beispielcode nicht schlecht aus. Tatsächlich verwenden würde ich das natürlich ebensowenig wie die ST-SPL/HAL.

Verfügbarkeit!

Negativ:

Die Startup-Zeit ist nicht instantan, sondern braucht 140ms, bis die ersten 512k des SPI-Flash ins Spiegel-SRAM kopiert wurden.

Zugriff auf die anderen 512kB des Flash ist relativ langsam, weil die nicht gespiegelt werden. Die +20% schneller gelten nur, wenn man die anderen 512k nicht oder kaum braucht.

Wenn man festcodierte Warteschleifen verwendet, kann die höhere Performance sogar zum Problem werden.

Das voltage scaling hat GD nicht vom STM32F405 übernommen, wo das nur 1 bit hat, sondern von F42X, wo es zwei Bit hat. Bezüglich der Einstellung ist es immer noch kompatibel, aber bei der Status-Abfrage nicht. Beim GD32 ist das genau wie beim 42X nicht als Vorab-Check vor dem Scharfschalten der PLL zu gebrauchen, sondern höchstens nach dem Scheitern, um die Fehlerursache rauszubekommen. Fragt man das vorher ab und wartet auf ready, hat man eine Endlosschleife gebaut. Das ist aber auch beim STM32F42X so nicht dokumentiert und nur mit Rumprobieren oder Googeln rauszubekommen.

Die Wertebereiche der PLL-Register sind leicht anders, aber im Normalfall kein Problem. Trotzdem sollte man das gegenprüfen.

ADC-Impedanz scheint etwas anders zu sein. Sollte man prüfen, wenn man schnell wandelt, insbesondere wenn ein Spannungsteiler verwendet wird. Bei langsamer Wandlung kein Unterschied.

Man liest von Problemen bei nicht-ganz-trivialen Features wie I2C. Habe ich nicht getestet, sollte man aber prüfen.

Die zulässigen Spannungsbereiche sind leicht anders - der GD32 verträgt nicht soviel Unterspannung, Brownout wäre woanders. Aber wenn man das braucht, sollte man sowieso Input-Sense und Buffering beschaltungsmäßig trennen.

Steve van de Grens schrieb:

Wenn das so ist, dann ist Arduino für ihn richtig. Das abstrahiert noch weiter als die sonst üblichen HAL Bibliotheken.

Ja, da ist sogar was dran. In meinen Augen haben die Arduino Leute keinen schlechten Job gemacht. Zumindestens was die Schnittstellen betrifft. Wo es erheblich klemmt ist die Zwischenschicht der verschiedenen Plattformen. Die eigene Schiene (avr, sam) ist noch ziemlich schlank. Die ESP-Ports sind schon deutlich aufgeblähter, da ist es aber auch nicht anders möglich wegen der binären Libs. Der STM32 Port schlägt aber dem Fass den Boden aus. Wieso man da die ganze STM32 HAL Schiene selbst für die einfachsten Sachen dazwischen schiebt erschließt sich mir nicht. Das bläht den ganzen Code auf ein fast unerträgliches Maß auf. rp2040 liegt so etwa in der Mitte, aber auch da steckt unter Arduini-Schnittstelle noch das rp2040-Sdk obwohl man da natürlich auch gleich die Register benutzen könnte. Aber wahrscheinlich muss man sich damit abfinden dass die Welt so ist. Und wenn mann sich mal so ansieht wie das bei irgendwelchen Libs aussieht kommt man an Arduini kaum noch vorbei. Wenn Hersteller xy einen neuen Sensor auf den Markt bringt z.B. dann sind die Beispiele zum Code zu 99% Arduino-Libs. Mit steigender Tendenz.

temp schrieb:

Ja, da ist sogar was dran. In meinen Augen haben die Arduino Leute keinen schlechten Job gemacht. Zumindestens was die Schnittstellen betrifft. Wo es erheblich klemmt ist die Zwischenschicht der verschiedenen Plattformen. Die eigene Schiene (avr, sam) ist noch ziemlich schlank. Die ESP-Ports sind schon deutlich aufgeblähter, da ist es aber auch nicht anders möglich wegen der binären Libs. Der STM32 Port schlägt aber dem Fass den Boden aus. Wieso man da die ganze STM32 HAL Schiene selbst für die einfachsten Sachen dazwischen schiebt erschließt sich mir nicht

Was merkt man daran? Sie haben doch einen schlechten Job gemacht. Schaut man sich zum Beispiel an, wie das ganze bei Zephyr gelöst wird, dann merkt man, dass die Lösung mit hierarchischen device trees viel besser skaliert. Das ganze war einfach nicht für verschiedenste Plattformen gedacht.

temp schrieb:

Wenn Hersteller xy einen neuen Sensor auf den Markt bringt z.B. dann sind die Beispiele zum Code zu 99% Arduino-Libs. Mit steigender Tendenz.

Vielleicht irgendwelche Modulhersteller. Von reinen Sensor-ICs kenne ich das nicht.

temp schrieb:

Der STM32 Port schlägt aber dem Fass den Boden aus. Wieso man da die ganze STM32 HAL Schiene selbst für die einfachsten Sachen dazwischen schiebt erschließt sich mir nicht.

Das kann ich dir erklären. Es gab mal einen schlanken Port von Leaflabs für das Maple Mini Board. Da war nur das nötigste drin, was man zur Implementierung der Arduino API benötigt. Als die Firma das Projekt aufgab führte Roger Clarks es unter dem Namen "STM32Duino" weiter. Sein Projekt unterstützt nur wenige STM32F1 und STM32F4 Modelle.

Danach hat ST einen neuen Arduino Core veröffentlicht, der auf HAL basiert, der auf CMSIS basiert. Zuerst hatte dieser Core noch einen eigenen Namen (den ich vergessen habe). Später haben sie ihn in "STM32Duino" umbenannt. Offenbar haben sie die Rechte an dem Namen gekauft. Indem ST die HAL als Basis nahm, konnten sie auf einen Schlag fast alle ihrer STM32 Modelle unterstützen.

Wem das alles zu schwerfällig ist, den möchte ich ermuntern, die Software von Roger Clarks zu benutzen. Sie ist alt, aber funktioniert gut. Ab und zu wird sogar noch nachgebessert. Support für weitere µC Modelle ist da aber wohl nicht zu erwarten.

Anleitung: http://stefanfrings.de/stm32/stm32f1.html#roger

temp schrieb:

Aber wahrscheinlich muss man sich damit abfinden dass die Welt so ist.

Auf der Arbeit entwickle ich Java Enterprise und Go Cloud Anwendungen ganz ähnlich. Da baut Bibliothek auf Bibliothek auf, teilweise hast du sogar einen Stapel von Frameworks übereinander. Eine durchschnittliche Anwendung kommt da schnell auf 100-300 Bibliotheken. Man freut sich, dass man den Auftrag schnell und preisgünstig erledigt bekommt und hofft, dass das Kartenhaus nicht irgendwann zusammen fällt oder außer Kontrolle gerät. Jedoch kann ich in meinem Job nicht darauf bestehen, diese Räder neu zu erfinden. Niemand würde das bezahlen.

Im Mikrocontroller Umfeld sind die Aufgaben oft klein genug, dass man noch alles oder fast alles selbst machen kann. Aber wie du siehst, ändert sich das gerade. Die Chips werden immer spärlicher dokumentiert, dafür werden sie mit einem Softwarepaket ausgeliefert das man verwenden muss. Ich denke, dass die Entwicklung weiter in diese Richtung gehen wird.

Für die Hersteller ergibt sich dadurch eine wunderbare Kundenbindung. Denn ein Mikrocontroller ist sehr viel leichter durch einen anderen austauschbar, wenn man den ganzen Programmcode selbst geschrieben hat. Sobald du dich aber z.B. von der HAL abhängig gemacht hast, kannst du nicht mehr den Hersteller wechseln ohne quasi alles neu zu schreiben.

Da scheint der Einsatz eines weiteren Abstraktionslayers attraktiv, aber wie du bei Arduino siehst, hat das auch Nachteile. Je mehr Layer übereinander liegen, umso schwieriger wird es, die nicht vorgesehenen Funktionen zu ergänzen. Insbesondere dann, wenn der Chip selbst nur lückenhaft dokumentiert ist.