Announcement: there is an English version of this forum on Hallo und guten Abend, ich bin aktuell auf der Suche nach einem günstigen Evalboard mit Debugging Interface. Gibt es für die STM32 Controller eine fertige API Bibliothek, zum Beispiel um einen One-Shot Timer oder Periodic Timer aufzusetzen? Auf eine Rückmeldung würde ich mich freuen.
Zo R. schrieb: > Gibt es für die STM32 Controller eine fertige API Bibliothek, zum > Beispiel um einen One-Shot Timer oder Periodic Timer aufzusetzen? Konfigurationscode für STM32-Boards (und deren Timer etc.) kann man wunderbar über STM32CubeMX erstellen. Man sollte sich aber trotzdem mit dem Reference Manual auseinandersetzen.
>ich bin aktuell auf der Suche nach einem günstigen Evalboard mit >Debugging Interface. Es kommt ein wenig darauf an, was du machen willst. Für 10-15€ gibt es die Hardware z.B. bei Mouser das Nucleo G474. Mit der Arduino API ist der Softwareeinstieg am einfachsten. Hier werden auch die unterstützten Boards aufgelistet: https://github.com/stm32duino/Arduino_Core_STM32 Und hier ist das Timer-Beispiel: https://github.com/stm32duino/STM32Examples/blob/main/examples/Peripherals/HardwareTimer/Timebase_callback/Timebase_callback.ino Und hier die gesamte Timer API: https://github.com/stm32duino/Arduino_Core_STM32/wiki/HardwareTimer-library
Zo R. schrieb: > ich bin aktuell auf der Suche nach einem günstigen Evalboard mit > Debugging Interface. Überlesen: NUCLEOs Die haben fast alle einen ST-Link zum Programmieren und Debuggen integriert. Christoph M. schrieb: > Es kommt ein wenig darauf an, was du machen willst. > Für 10-15€ gibt es die Hardware z.B. bei Mouser das Nucleo G474. > Mit der Arduino API ist der Softwareeinstieg am einfachsten. Und in einer gewissen Weise eine Sackgasse. Arduino ist praktisch, wenn man auf unterschiedlichen Controllern die gleiche Software laufen lassen will.
Christoph M. schrieb: >>Und in einer gewissen Weise eine Sackgasse. > Wieso? Hast du schon mal versucht, einen Debugger mit der Arduino-IDE zu betreiben?
wo ist das Problem? Mit der Arduino IDE 2.x geht das schon seit ein paar Jahren. Und besser noch wenn man Arduino Code mit PlatformIO nutzt. Ansonsten ist das schon eine komische Frage von jemandem der seit 2005 angemeldet ist. STM32 ist ja so ein Exot...
J. S. schrieb: > Ansonsten ist das schon eine komische Frage von jemandem der seit 2005 > angemeldet ist. STM32 ist ja so ein Exot... Hast du sonst irgendwas sinnvolles beyutragen? Die Arduin IDE 2.0 war lange nicht besonders funktionsfähig. Deswegen sind viele doch noch bei der 1.. verblieben.
Witzbold, wenn man debuggen möchte muss man eben auf die 2.x umsteigen weil es in der spartanischen 1er nie vorgesehen war. Wasch mich aber mach mich nicht nass, oder was? Und PIO gab es schon lange vor der 2er, mit funktionierendem Debugging.
J. S. schrieb: > Witzbold, wenn man debuggen möchte muss man eben auf die 2.x > umsteigen Oder, wenn man sowieso nur den STM32 verwenden will, gleich die passende IDE verwenden. > weil es in der spartanischen 1er nie vorgesehen war. Wasch mich aber > mach mich nicht nass, oder was? > Und PIO gab es schon lange vor der 2er, mit funktionierendem Debugging. Zu dem Zeitpunkt gab es schon diverse (kostenfreie) IDEs (AtmelStudio etc), die Debugging unterstützten. Wie gesagt: Arduino ist praktisch, wenn man (regelmäßg) den Controller wechselt, aber nicht das Programm.
>Wie gesagt: Arduino ist praktisch, wenn man (regelmäßg) den Controller >wechselt, aber nicht das Programm. Das ist zu einfach gedacht und hängt vom Anwendungsfall ab. Will man z.B. in einer großen Automotive Firma ein Steuergerät mit Stückzahl >100000 entwickeln, wird man noch nicht mal eine Mikrosekunde an den Einsatz von Arduinos denken. Will man in der selben Firma aber Laboraufbauten für einfache Mess- und Steuerungsaufgaben wie z.B. die Schrittomotorsteuerung eines Testaufbaus machen, dann verwenden solche Firmen bisweilen Arduino's und ähnliches. Der Vorteil des Arduino-Frameworks ist seine Einfachheit und dass auch Nicht-Software Kollegen die Firmeware warten können ohne riesen Toolchains zu installieren. Das oben gepostete Beispiel in seiner Einfachheit wirst du mit der STM-Cube-Umgebung nicht hinbekommen (alleine schon aus Bedienbarkeitsgründen). https://github.com/stm32duino/STM32Examples/blob/main/examples/Peripherals/HardwareTimer/Timebase_callback/Timebase_callback.ino Deshalb gilt folgendes: Um die passende Umgebung für den TO zu finden, muss man seine genauen Randbedingungen kennen.
Früher was es sehr schwierig, einen Mikroprozessor zu programmieren. Heute besteht die Kunst eher darin, die optimalen Arbeitsmittel auszuwählen.
Christoph M. schrieb: > Das oben gepostete Beispiel in seiner Einfachheit wirst du mit der > STM-Cube-Umgebung nicht hinbekommen (alleine schon aus > Bedienbarkeitsgründen). Es ist schon eine gewagte Aussage, dass ich das nicht hinbekäme. Woher willst du das wissen? Arduino ist gut für den Einstieg. Will man Dinge machen, die controllerspezifisch sind, kann man auch gleich was anderes nehmen. Das Gedöns, was der Arduino-Wrapper im Hintergrund für Entwicklungsboards macht, kann man auch mit STM32CubeMx erledigen, wenn man dort das Board als Plattform auswählt.
Hallo, ich danke euch für die vielen Informationen. Ich denke ich werde folgendes Board kaufen: NUCLEO F767ZINucleo-144, ARM Cortex M4F, STM32 F7-Serie Wird dieses Board auch von der Software STM32CubeMx unterstützt?
Nucleo Noards sind praktisch der blanke MC mit einem zweiten drauf, der als Programmer dient. Discovery Boards haben oft noch interessante Peripherie drauf und kosten auch nicht viel. Wie beim Nucleo ist hier auch der zweite MC drauf, der fürs Programmieren sorgt (ST-Link). Ich habe mit dem VL Discovery, dem F429 Dicovery und dem F407 Discovery schon viel Spaß gehabt.
:
Bearbeitet durch User
>Es ist schon eine gewagte Aussage, dass ich das nicht hinbekäme. >Woher willst du das wissen? Wenn du es nicht in 10 Minuten in dieser kurzen Form hinbekommst ist die Umständlichkeit schon bewiesen, da es das Arduino-Beispiel gibt.
>ich danke euch für die vielen Informationen. Ich denke ich werde >folgendes Board kaufen: Beschreibe doch mal deine Anforderungen etwas genauer. Was ist das Ziel?
Zo R. schrieb: > Ich denke ich werde folgendes Board kaufen: > STM32 F7-Serie Fange mal lieber mit einem weniger komplexen Modell an: F0, L0, G0 oder F3.
Zo R. schrieb: > NUCLEO F767ZINucleo-144, ARM Cortex M4F, STM32 F7-Serie Vieeel zu komplex, sowohl vom Controller her als auch vom Board. Monk schrieb: > Fange mal lieber mit einem weniger komplexen Modell an: F0, L0, G0 oder > F3. Jawoll. Es gibt so viele schöne kleine Nucleos, so richtig schön handlich. Da kann man es lernen bevor man sich spezialisiert und weiss auf welches STM32 Monster man losgeht. 30 Euro für einen Controller mit angeschlossenem Debugger, was will man mehr? https://www.reichelt.de/de/de/nucleo-64-arm-cortex-m4f-stm32-f4-serie-nucleo-f411re-p154272.html?PROVID=2788&gad_source=1&gclid=EAIaIQobChMI4Mf2oe7xiAMV3paDBx0LngfuEAQYASABEgJXNfD_BwE&&r=1
Christoph M. schrieb: > Wenn du es nicht in 10 Minuten in dieser kurzen Form hinbekommst ist die > Umständlichkeit schon bewiesen, da es das Arduino-Beispiel gibt. Als würde die Arduino-Lib in 10 Minuten geschrieben...
Ein Evalboard mit Ethernet wäre nicht schlecht. Ich möchte mein Wissen wieder etwas auffrischen. Hab mit STM32 schon 6 Jahre lang nichts gemacht. Applikation mit einem oder mehreren Periodic Timer mit callback function. Dann möchte ich das Thema Ethernet und Uart Kommunikation wieder aufgreifen.
:
Bearbeitet durch User
Zo R. schrieb: > Ein Evalboard mit Ethernet wäre nicht schlecht. Wenn du schon soweit bist, dann das F429. Es ist das "kleinste" Board mit LAN-Verbindung aus dem Hause STM: https://www.reichelt.de/stm32-nucleo-144-arm-cortex-m4f-stm32f429zit6-nucleo-f429z-p379677.html?PROVID=2788&gad_source=1&gclid=EAIaIQobChMIyNzOtfHxiAMVq5eDBx1BYDCsEAQYAiABEgLWI_D_BwE
Ok dieses Board wird auch von der Arduino Software und Stm32CubeMx unterstützt?
Zo R. schrieb: > dieses Board wird auch von der Arduino Software und Stm32CubeMx > unterstützt? Google wurde schon erfunden.
Zo R. schrieb: > Ok dieses Board wird auch von der Arduino Software und Stm32CubeMx > unterstützt? CubeMX unterstützt alle STM-eigenen Boards. Zu Arduino-Support kann ich dir nichts sagen. Aber mit Arduino wirst du irgendwann in einer Sackgasse landen, und du wirst deine Hardware nie richtig verstehen werden.
Vor wenigen Jahren brachte STM ja den H743 heraus, mit 400 bis
480 MHz möglicher Taktrate und LAN/Ethernet. Da gab es dann auch
Meldungen dass "man" damit eine TCP-Anwendung nicht einwandfrei
zum Laufen bringen konnte. Hier im Forum gab es dazu auch
Diskussionen.
Jetzt sehe ich dass man diesen Controller offensichtlich hat
sterben lassen ("obsolete"), waren wohl noch einige Bugs drin die
es nicht lohnten sie auszumerzen.
https://www.st.com/en/evaluation-tools/nucleo-h743zi.html
Quintessenz:
"We recommend you that replacement part: NUCLEO-H753ZI"
:
Bearbeitet durch User
Der H753 ist der gleiche wie der H743, nur mit zusätzlicher Crypto Einheit. Sogar der Code ist komplett binärkompatibel solange man dieses eine Device nicht benutzt. Ethernet funktioniert mit dem H743 wunderprächtig, die H Serie ist nur mit DMA und Caches recht komplex. Und auch der Cube generierte Code braucht manuelle Nacharbeit. Ob es aktuelle Cube Versionen jetzt besser machen weiß ich nicht.
Ok das betrifft aber nicht das Nucleo Evalboard: NUCLEO F429Z STM32 Nucleo-144 ARM Cortex M4F STM32F429ZIT6
J. S. schrieb: > Ethernet funktioniert mit dem H743 wunderprächtig Wenn ein Hersteller einen Chip als obsolete kennzeichnet dann wird der nicht mehr produziert, und das aus triftigen Gründen. Nachweisen kann ich das nicht, aber es wird wohl so sein.
Zo R. schrieb: > Ok das betrifft aber nicht das Nucleo Evalboard: Du musst schon sagen auf was sich dein "das" bezieht.
Zo R. schrieb: > Bezüglich Probleme mit der Ethernet - Konfiguration und Nutzung. Das F429 Nucleo lief bei mir mit TCP/lwIP auf Anhieb problemlos. Was ich vom H743 nie behaupten werde ....
:
Bearbeitet durch User
Das Nucleo Board mit H743 mag obsolet sein, die MCU ist active im Status. https://www.st.com/en/microcontrollers-microprocessors/stm32h743-753/products.html Und beim Board stört es nicht wenn der 753 drauf ist, weil sowieso kompatibel. In der der Corona Zeit waren die H743 schnell nicht mehr lieferbar, wir konnten gerade noch 753er bekommen und der Code läuft ohne Anpassung oder neu kompilieren. Da ist man gleich beim großen Nachteil von CubeMX: ein Wechsel auf einen anderen Controller ist eine Sysiphus Arbeit und wird nicht von der IDE unterstützt. Code wird aus Templates gebaut und die selber zu machen hat nichts mit programmieren zu tun. Da ist Arduino mit seinen Komponenten schon deutlich professioneller, gute Komponenten sind auf verschiedenen Controllern oder gar Platformen gleich zu verwenden, die Abstraktion geschieht in der Komponente und/oder dem Buildsystem.
Wastl schrieb: > Wenn ein Hersteller einen Chip als obsolete kennzeichnet dann > wird der nicht mehr produziert, und das aus triftigen Gründen. > Nachweisen kann ich das nicht, aber es wird wohl so sein. Dann sollte der Hersteller das gelegentlich seinen Web Designern sagen, die glauben immer noch, dass die H743 noch bis 2034 gebaut werden. https://www.st.com/content/st_com/en/about/quality-and-reliability/product-longevity.html#10-year-longevity§ion=FM141-10-year
Zo R. schrieb: > ich danke euch für die vielen Informationen. Ich denke ich werde > folgendes Board kaufen: > > NUCLEO F767ZINucleo-144, ARM Cortex M4F, STM32 F7-Serie Hier liegt noch ein Nucleo F746ZG, was ich absehbar nicht mehr brauche. Für einen Zehner+Versandkosten und wir könnten tauschen?
Zo R. schrieb: > Hallo Mi, verkaufst du dein Nucleo Board? Mi N. schrieb: > Für einen Zehner+Versandkosten und wir könnten tauschen? Sieht so aus, oder?
Zo R. schrieb: > ich danke euch für die vielen Informationen. Ich denke ich werde > folgendes Board kaufen: NUCLEO F767ZINucleo-144 Als Einstieg ein F7?
von Zo R. (hsch1978) >NUCLEO F767ZINucleo-144, ARM Cortex M4F, STM32 F7-Serie >Ok dieses Board wird auch von der Arduino Software und Stm32CubeMx >unterstützt? Die List aller von STM32Duino unterstützten Boards ist hier (oben schon mal geschrieben): https://github.com/stm32duino/Arduino_Core_STM32 Dort findet sich auch das NUCLEO F767ZI. Zo R. schrieb: > Ich denke ich werde folgendes Board kaufen: > STM32 F7-Serie >>Fange mal lieber mit einem weniger komplexen Modell an: F0, L0, G0 oder >>F3. Die Komplexität der Boards ist bei Benutzung des Arduino-Frameworks ziemlich egal. Im Gegenteil, bei den großen Boards kann man den Speicher und die hohe Geschwindigkeit ohne irgend einen Zusatzaufwand benutzen. Hier sind die Ethernet-Treiber: https://github.com/stm32duino/STM32Ethernet Und hier ein Beispiel wie beim Arduino-Framwork üblich auf's wesentliche, reduzierte, einfache Beispiel: https://github.com/stm32duino/STM32Ethernet/blob/main/examples/WebServer/WebServer.ino Wastl >CubeMX unterstützt alle STM-eigenen Boards. Zu Arduino-Support >kann ich dir nichts sagen. Aber mit Arduino wirst du irgendwann >in einer Sackgasse landen, Was genau ist eine "Sackgasse" bezüglich Mikrocontroller? >und du wirst deine Hardware nie richtig verstehen werden. Hast du die mehreren hundert Seiten des 767ZI alle durchgelesen und verinnerlicht? Kennst du alle Erratas und weißt wie man diese umgeht? Benutzt du die DSP-Hardwarebeschleunigung dieses ARM-Kerns? Um die maximale Performance zu erreichen, ist es am besten, den passenden Assemblercode von Hand zu optimieren (wobei das selbst bei Benutzung des Arduino-Framworks ginge) Ab wann hat man die Hardware des 767ZI richtig verstanden und muss man das überhaupt für jedes beliebige Projekt? Sollte man überhaupt ein Auto benutzen, wenn man die Hardware der Motorsteuerung und der Softwareabläufe nicht genau kennt oder kann man sich einfach rein setzen und trotzdem fahren?
Christoph M. schrieb: > Was genau ist eine "Sackgasse" bezüglich Mikrocontroller? Da muss irgendwer eine Bibliothek für die neue Controller erstellen. Arduino ist relativ abstrakt und nicht unbedingt optimal programmiert, wodurch man immer von dessen (Weiter-) Entwicklung abhängig ist. Die LowLevel- und HAL-Libraries von ST werden vom Hersteller der Controller gepflegt - wer das bei Arduino ist, weiß ich nicht. Das können auch Drittanbieter sein, die u.U. auch die Lust und Zeit an dem Projekt verlieren.
>Die LowLevel- und HAL-Libraries von ST werden vom Hersteller der >Controller gepflegt - wer das bei Arduino ist, weiß ich nicht Den Lead hat Frederic Pillon ( Kürzel "fpistm" in Github ) von STMicroelectronics in Le Mans, da STM vor einigen Jahren beschlossen hat, für den Arduino-Support extra einen Mitarbeiter abzustellen: https://github.com/fpistm Das Diskussionsforum zu den technischen Angelegenheiten des STM32Duino Probjektes findet sich hier: https://www.stm32duino.com/
STM32duino verwendet intern die HAL, wenn das nicht 'optimal programmiert' ist dann liegt es größtenteils an der Herstellerlib HAL. Dank Communities wie Arduino oder Mbed die eben die HAL verwenden wurden auch einige Probleme im HAL Code gefunden und gefixt. Dann sind gute Komponenten wie eTFT_SPI vom Bodmer schon extrem gut optimiert, da werden schnelle Schnittstellen mit DMA und beim RP2040 auch mit dessen PIO genutzt. Da steckt viel know how von vielen Leuten drin, über die Einzelkämpfer die meinen alles besser zu können kann ich da nur müde schmunzeln. Natürlich gibt es auch viel Murks in der Arduino Welt weil viele die es geschafft haben als Einstieg einen Klimasensor zu bauen gleich einen Blog und YT Videos dazu veröffentlichen und so das Internet mit der 1001. 'Lösung' fluten.
Christoph M. schrieb: > Den Lead hat Frederic Pillon ( Kürzel "fpistm" in Github ) von > STMicroelectronics in Le Mans, da STM vor einigen Jahren beschlossen > hat, für den Arduino-Support extra einen Mitarbeiter abzustellen: > > https://github.com/fpistm > > Das Diskussionsforum zu den technischen Angelegenheiten des STM32Duino > Probjektes findet sich hier: > https://www.stm32duino.com/ Dann ist ja alles gut.
Wastl schrieb: > Vor wenigen Jahren brachte STM ja den H743 heraus, mit 400 bis > 480 MHz möglicher Taktrate und LAN/Ethernet. Da gab es dann auch > Meldungen dass "man" damit eine TCP-Anwendung nicht einwandfrei > zum Laufen bringen konnte. Hier im Forum gab es dazu auch > Diskussionen. > > Jetzt sehe ich dass man diesen Controller offensichtlich hat > sterben lassen ("obsolete"), waren wohl noch einige Bugs drin die > es nicht lohnten sie auszumerzen. > > https://www.st.com/en/evaluation-tools/nucleo-h743zi.html > > Quintessenz: > "We recommend you that replacement part: NUCLEO-H753ZI" Nur das Nucleo Board mit dem ST-Link V2 und der 400MHz (Y) Version stirbt aus. Das H753ZI Board hat ST-Link V3 und die neue Revision (V) mit 480 MHz drauf. Den H743ZI (V) Chip gibt es immer noch. Siehe: AN5312 Migration from RevY to RevV for STM32H743/753 und ES0392 Errata Aber der H7 ist manchmal eine zickige Diva ;-) Dann solltest du auf jeden Fall die aller neueste CubeMx Version nehmen. Das erzeugte Linker-Script stimmt immer noch nicht, da fehlt das RAM in der D2 und D3 Domain. Wenn du DMA verwendest schalte auch erst einmal den I und D Cache aus. Den F476 gibt es auch als Nucleo144 mit Ethernet.
Beitrag #7747586 wurde von einem Moderator gelöscht.
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.