Forum: Mikrocontroller und Digitale Elektronik Alternativen zu STM32?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Max G. (l0wside) Benutzerseite


Lesenswert?

Hallo zusammen,

nachdem ST ja mittlerweile durch völlige Lieferunfähigkeit glänzt, ist 
die Entwicklung auch mit der schönsten STM32Cube-Oberfläche eher sinnlos 
geworden. Ich suche deswegen nach einer Alternative und bitte um 
Empfehlungen, die Liefersicherheit explizit beinhalten. Es geht 
voraussichtlich um ein paar hundert Stück, beim Hersteller direkt 
brauche ich also nicht anzufragen. Eine brauchbare 
Entwicklungs-/Debuggingumgebung wäre auch extrem hilfreich.

Anforderungen sind eher simpel: zwei serielle Schnittstellen (alternativ 
SPI + seriell), so ab 64 kB Flash, wenigstens 8 kB RAM und ein paar 
Timer. Die Anwendung ist eher zeitkritisch, deswegen wenigstens 32 MHz. 
Und weil einschlägiges Tooling schon vorhanden ist, wäre mir ein 
Cortex-M ganz recht (M0+ oder M3/M33). Package in der Größenordnung 
QFN32 bis TQFP48, bitte kein BGA. Preislich liegt die Schmerzgrenze so 
bei 3 EUR in 1000er-Stückzahlen (falls es kommerziell besser läuft als 
gedacht).

Im Auge habe ich aktuell:
* Renesas R7FA2E1A93CFJ#AA0. Gigantisches Preis-/Leistungsverhältnis, 
und bei Mouser in sinnvollen Stückzahlen vorrätig.
* EFM32PG22 Gecko. Auch wenn ich die Low Power-Möglichkeiten nicht 
brauche, sieht der ganz nett und lieferbar aus
* Infineon XMC1100-T016F0064.

Hat jemand Empfehlungen?

Gruß und danke, Max

von DerEgon (Gast)


Lesenswert?

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,

von Cyblord -. (cyblord)


Lesenswert?

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

Unsinn. LCSC hat zig STM32 auf Lager.

von A. (Gast)


Lesenswert?

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

Kann ich bestätigen und sie kommen auch an.

von Markus M. (adrock)


Lesenswert?

TME hat z.B. den STM32G030F6P6 > 1000 Stück am Lager. 1,06 EUR/Stück

von Cyblord -. (cyblord)


Lesenswert?

A. schrieb:
> Cyblord -. schrieb:
>> Unsinn. LCSC hat zig STM32 auf Lager.
>
> Kann ich bestätigen und sie kommen auch an.

Ich habe eine größere Anzahl davon bei JLCPCB in meinem Bauteillager 
liegen. D.h. die meisten werden bestückt bevor sie zu mir kommen. Aber 
natürlich liefert LCSC zuverlässig.

von Lothar (Gast)


Lesenswert?

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/

von Wühlhase (Gast)


Lesenswert?

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.

von PittyJ (Gast)


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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.

von Wühlhase (Gast)


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?


von Nop (Gast)


Lesenswert?

Lothar schrieb:

> GigaDevice hat uC zu STM pinkompatibel

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Nop schrieb:
> Auch kompatibel?
Ziemlich...  ;-)

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

BTW, nicht dass da ein Verdacht aufkommt: ich bin nicht der einzige 
Lothar hier im Thread.

: Bearbeitet durch Moderator
von Nop (Gast)


Lesenswert?

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?

von Ben K. (bkaiser)


Lesenswert?

Wie schon erwähnt. Schau bei LCSC. Die haben massig da und liefern.

von Rudolph R. (rudolph)


Lesenswert?

ATSAMD21G17D-AUT
Digikey hat gerade 11400 Stück auf Lager, Mouser hat 2700.
Cortex M0+ 48MHz, 48 Pin, 128kiB Flash, 16kiB SRAM, 6 SERCOM 
(UART/I2C/SPI)
Unter 3 Euro das Stück bei 100 Stück.

von W.S. (Gast)


Lesenswert?

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.

von Wühlhase (Gast)


Lesenswert?

Lothar schrieb:
> [..]

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

von Peter (Gast)


Lesenswert?

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.

von Äh (Gast)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

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

von Max G. (l0wside) Benutzerseite


Lesenswert?

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

Markus M. schrieb:
> TME hat z.B. den STM32G030F6P6 > 1000 Stück am Lager.

Abgesehen davon, dass Cyblord mal wieder unfreundlich werden musste: 
danke für die Hinweise. Auch wenn LCSC nicht eben billig ist.

PittyJ schrieb:
> 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.

Das ist richtig. Es scheint mir dennoch einfacher zu sein, mich in eine 
neue HAL einzuarbeiten als neue Register zu lernen. Ich habe einmal von 
zwischen zwei verschiedenen MSP430-Familien zu Fuß portiert. Das brauche 
ich nicht noch mal, dann lieber HAL-Funktionen.

Den Renesas oder den EFM32 hat niemand im Einsatz und kann über das 
zugehörige Tooling berichten?

von W.S. (Gast)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

Da war halt das Programm schlecht und die Hardware nicht gut von der 
Anwendungslogik getrennt.
Das sind dann solche Meisterwerke, die an tausenden Stellen im ganzen 
Code direkt in den Registern rum schreiben und lesen.
Daraus kann man auch lernen.

: Bearbeitet durch User
von Steve van de Grens (roehrmond)


Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

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.

: Bearbeitet durch User
von Stefan K. (stk)


Lesenswert?

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

Das scheint langsam besser zu werden. Reichelt hat wieder einige Typen 
am Lager.

von m.n. (Gast)


Lesenswert?

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

von Ramachandran B. (ramachandran_b)


Lesenswert?

PSoC6 (Arm-m4 mit 150 MHz) ist auch noch relativ gut verfügbar. Habe ich 
selber vor kurzem in einem Projekt genutzt.
Grafische Konfiguration über Modus-Toolbox, Beispielcodes und HAL würde 
ich dort ähnlich gut wie bei ST einschätzen.

von Volker B. (Firma: L-E-A) (vobs)


Lesenswert?

DerEgon schrieb:

> 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

Sicher, dass das ein QSPI-Flash ist? Im Datenblatt kann ich nichts dazu 
finden.

Dann kannst Du sicher weitere QSPI-Flashs aus dem aktuellen 
Reichelt-Lieferprogramm nennen, ich finde leider keines.

Grüßle,
Volker

von Ulrich P. (uprinz)


Lesenswert?

Genauso wie der TO kann ich auch nicht auf einen RP2040 ausweichen. Das 
Modul ist schon fast doppelt so groß, wie mir an Fläche zur Verfügung 
steht.

Da hänge ich mich an die Frage mal mit dran. Ich suche ein Pendant mit 
64kB Flash, ein paar kB RAM, min. 2x 12bit ADC, gerne auch gemultiplext, 
dazu 2x DAC mit 12-bit. Schön wäre eine interne Ref, eventuell digital 
abgleichbar. Das ganze im 48 pin Leadless Gehäuse.

Ich hatte gehofft das Projekt auf einem STM32F410C8U6 umsetzen zu 
können, aber der ist seid Monaten auf 0. Auch bei LCSC.

von Markus (Gast)


Lesenswert?

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

von m.n. (Gast)


Lesenswert?

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

von Ulrich P. (uprinz)


Lesenswert?

Man kann den RP2040 auch als Chip kaufen, aber eben nur den 2040. Ich 
bräuchte einen RP2044, besser RP2048. Am RP2040 benötigt man einen 
externen Flash, wenn ich das richtig verstehe und selbst dann fehlt mir 
für das zweite Projekt noch DAC, der im STM32F410 drin gewesen wäre.

Ein CPLD wäre für das Projekt mit dem DAC auch eine Lösung gewesen, da 
man das ganze auch in einem kleinen TTL-Grab abbilden könnte. Aber auch 
die sind entweder Obsolet oder Bestand 0. Man bekommt nur noch Flag-Ship 
FPGAs und das ist völlig übertrieben.

von m.n. (Gast)


Lesenswert?

Der Konjunktiv ist schon eine feine Sache ;-)

von Frank K. (fchk)


Lesenswert?

Ulrich P. schrieb:

> Da hänge ich mich an die Frage mal mit dran. Ich suche ein Pendant mit
> 64kB Flash, ein paar kB RAM, min. 2x 12bit ADC, gerne auch gemultiplext,
> dazu 2x DAC mit 12-bit. Schön wäre eine interne Ref, eventuell digital
> abgleichbar. Das ganze im 48 pin Leadless Gehäuse.

Gibts zu kaufen.

https://www.digikey.de/de/products/detail/microchip-technology/DSPIC33CH128MP505T-I-M4/9657559

fchk

von Lothar (Gast)


Lesenswert?

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

von Nop (Gast)


Lesenswert?

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?

von Steve van de Grens (roehrmond)


Lesenswert?

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.

von Nop (Gast)


Lesenswert?

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.

von Ulrich P. (uprinz)


Lesenswert?

Danke für die Auswahl an ADC / DAC Chips. Ich hatte vergessen zu 
erwähnen dass da eine kontinuierliche FFT laufen muss. Der dsPIC könnte 
das leisten, die 8051 Derivate würde ich da eher am Limit einschätzen. 
Das Master-Slave Konzept ist da ebenfalls interessant. Und der kleine 
502 würde vermutlich ausreichen. Ich bestelle mir mal ein 
Entwickler-Kit, falls ich jetzt von ST keine vernünftige Antwort 
bekomme.

Danke!

von Lothar (Gast)


Lesenswert?

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/

von Max G. (l0wside) Benutzerseite


Lesenswert?

Lothar schrieb:
> https://jaycarlson.net/pf/silicon-labs-efm8/

Vielen Dank für diesen Link! Unter 
https://jaycarlson.net/microcontrollers/ gibt es den bei weitem besten 
und objektivsten Vergleich von µC-Architekturen, den ich bisher gesehen 
habe. Zeit mitbringen ist hilfreich...

von m.n. (Gast)


Lesenswert?

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.

von Nop (Gast)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von avr (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.