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
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,
Max G. schrieb: > nachdem ST ja mittlerweile durch völlige Lieferunfähigkeit glänzt Unsinn. LCSC hat zig STM32 auf Lager.
Cyblord -. schrieb: > Unsinn. LCSC hat zig STM32 auf Lager. Kann ich bestätigen und sie kommen auch an.
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.
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?
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
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?
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.
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)
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?
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: > 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
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: > nachdem ST ja mittlerweile durch völlige Lieferunfähigkeit glänzt Das scheint langsam besser zu werden. Reichelt hat wieder einige Typen am Lager.
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
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.
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
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.
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 ;-)
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.
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
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.
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!
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/
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...
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.