STM32 programieren mit platformio und mbed

[alexander_ro]

Also was Du mit dem Core meinst kann ich mir zwar etwa vorstellen. Genau weiß ich das aber nicht. Ich würde mal vermuten das sind dann die Definitionen mit den Registern, Portnamen und vielleicht Memorymapping oder so ähnlich. Vielleicht auch ein paar Grundlegende Programmteile.

Ich finde das ganze egal ob nun mit Arduino oder mbed sehr unübersichtlich es gibt alle möglichen Programmmodule die dann wieder nur mit bestimmten anderen zusammen funktionieren. Aber es wird nicht wirklich angegeben welche das genau sind und es gibt auch oft mehrere die den gleichen Namen haben. Auch bei Header Files habe ich oft das Problem das es nicht gefunden wird. Eine Suche zeigt dann es gibt 5 verschiedene Programmbibliotheken mit dem Filenamen ... welcher ist dann der richtige?

Das Platinchen habe ich im Rahmen dieser "Elektor Board Games" bekommen deshalb muss ich das da verwenden. Es heißt ja eigentlich das man da auch Support dazu bekommt aber bei der genannten Mailadresse und bei der Elektor bekommt man keine Antwort auf Fragen ... aber bis Ende des Monats soll man fertig sein ... die Platine ist vor einer Woche bei mir angekommen.

Das Beispiel oben geht nach dem was ich gefunden habe nicht mit diesem Platinchen. Das liegt daran das die von ST gemachte Unterstützung scheinbar für das verwendete WLAN Module die (was auch immer) WiFiInterface nicht implementiert. Nach längerem suchen habe ich ein Beispiel für einen WebServer gefunden: https://os.mbed.com/teams/ST/code/DISCO_L475VG_IOT01-wifi_http_server/

Irgendwie fehlt beiden Projekten ... Arduino und mbed ... eine Instanz die die Entwicklung koordiniert und dafür sorgt das die Dinge kompatibel sind. Würde man den Linux Kernel genauso Planlos entwickeln gäbe es einen Kernel der zwar viele schöne Teile hat aber nichts passt wirklich zum anderen.

[HaWe]

ja, mit cores hast du Recht, es ist all das, was unter packages\company\hardware\cpu\version\cores\ zu finden ist, eigentlich meinte ich aber sogar auch alles übrige in den speziellen cpu packages, mit Dateien zu Bootloaders, drivers, cpu-spez. libraries, tools, variants...
Wenn es dich interessiert, installiere mal Arduino IDE und dann ein ARM-Zusatz-package, dann siehst du, was alles dabei ist.

Wenn du bei deiner cpu-Platine bleiben musst und da keine Wahl hast, hat sich ntl alles zu anderen M4s erledigt.

was du aber mit "Instanz die die Entwicklung koordiniert und dafür sorgt das die Dinge kompatibel sind" meinst, verstehe ich nicht:
Die übergreifende Kompatibilität aller Boards und cpus (AVR, ARM, ESP, Intel) innerhalb des hierarchischen Arduino APIs stellt die Arduino IDE her, auf der Basis von "Processing", das vorher bereits entwickelt wurde (Ben Fry,Casey Reas) und des Java-basierten "Wiring" Konzepts, das von Hernando Barragán / AG von Massimo Banzi entwickelt und zur eigentlichen Grundlage von "Arduino" wurde - aber das führt hier zu weit.
Immerhin sorgen alle Arduino Entwickler dafür, dass die neueren Erweiterungen immer rückwärts-kompatibel zu allen anderen cpu-Plattformen bleiben, was auch manchmal etwas hinderlich, und teilweise auch recht bizarr und lähmend gegen grundlegende Verbesserungen ist (z.B. dass die Funktion für pwm-write auf digitalen Pins "analogWrite" heißt) .
Oder welche "kompatiblen Dinge" meintest du?

Wie auch immer, wenn du mit deinem STM32L4 bleiben musst und die Arduino IDE benutzen willst, dann kannst du nur hoffen, ein passendes package samt cores dafür zu finden, das sich per Boardmanager einbinden und installieren lässt.

Arduino nimmt einem jedenfalls sehr schön alle hässlichen low-level-Details ab, man muss sich nicht um fuses, Monster-IDEs oder -Frameworks, makefile, Pfadverwaltung, linker u.v.a. kümmern: wäre es anders, hätte ich nie mit diesen cpus jemals angefangen, und so kann man sich von Anfang an um seine Projekte kümmern, ohne sich mit der Hardware herumkloppen zu müssen (so wie du in deinem TOP-Post zu mbed und platformio beispielsweise).
Arduino hat dazu gewissermaßen ebenso ein internes und externes Regelwerk wie Linux mit seinem kernel und seinem devtree, nur kann man das nicht recht vergleichen, weil ja ein multiuser-multithreading-multitasking-OS dahinter steckt.
Bei MCUs für Arduino und avrstudio gibt es aber ja noch nicht mal ein File System und daher auch kein C/C++ nach Posix Definitionen mit einem Datentyp FILE* und z.B. einer stdio.h Lib mit fopen und fclose usw.

[alexander_ro]

was du aber mit "Instanz die die Entwicklung koordiniert und dafür sorgt das die Dinge kompatibel sind" meinst, verstehe ich nicht:

Beim Linux Kernel gibt es immer Betreuer für ein Subsystem das die Entwicklung koordiniert und dafür sorgt das z.B. Schnittstellen zum Netzwerk (WLAN, I2C, SPI, USB, Display) oder Speicherverwaltung definiert und eingehalten werden. Bei Arduino und mbed gibt es zahlreiche nicht kompatible Bibliotheken die immer wieder das gleiche tun auf andere Art meist schwer zu erkennen welche man braucht. In einem älterem Thread hier habe ich schon mal für den Arduino Due was gesucht für parallel Verarbeitung und Timer. Da war das ganze Arduino Zeug aber auch nur Mäßig hilfreich. So lange man nur das machen will was Presse und Buchautoren in dem Endlosen Gelaber für Einsteiger verbreitet ist alles gut. Sicher das ist wichtig aber man sollte nicht vergessen das die ganze Technik erst Nützlich wird wenn man mehr tut als am Terminal "Hello World" ausgeben und eine LED blinkt. Es gibt nicht nur Einsteiger aber vermutlich kann man mit denen leichter Geschäfte machen weil ihnen noch das wissen fehlt Müll von gutem zu trennen.

C/C++ Code ist ja an sich bereits recht Plattform unabhängig. Man darf nicht die stdc++ mit C++ verwechseln. In der Standardbibliothek gibt es selbstverständlich Dinge die nicht auf beliebig kleiner CPU oder MCU laufen können. Die ARM Cortex M4 sind ja untereinander sehr ähnlich nur die darum gebaute Hardware unterscheidet sich stärker. Was dann für die Entwicklung für verschiedene Vertreter ihrer Klasse eine deutlich Vereinfachung ist. Nur kann ich das noch nicht erkennen das man das auch in der Praxis über blink und serial hinaus anwendet. Ein bisschen Low Level nehmen einem die schon ab aber nur solange man dem Mainstream folgt. Eigene Vorstellungen sind in der Welt noch nicht erwünscht.

[HaWe]

Beim Linux Kernel gibt es immer Betreuer für ein Subsystem das die Entwicklung koordiniert und dafür sorgt das z.B. Schnittstellen zum Netzwerk (WLAN, I2C, SPI, USB, Display) oder Speicherverwaltung definiert und eingehalten werden. Bei Arduino und mbed gibt es zahlreiche nicht kompatible Bibliotheken die immer wieder das gleiche tun auf andere Art meist schwer zu erkennen welche man braucht. In einem älterem Thread hier habe ich schon mal für den Arduino Due was gesucht für parallel Verarbeitung und Timer. Da war das ganze Arduino Zeug aber auch nur Mäßig hilfreich. So lange man nur das machen will was Presse und Buchautoren in dem Endlosen Gelaber für Einsteiger verbreitet ist alles gut. Sicher das ist wichtig aber man sollte nicht vergessen das die ganze Technik erst Nützlich wird wenn man mehr tut als am Terminal "Hello World" ausgeben und eine LED blinkt. Es gibt nicht nur Einsteiger aber vermutlich kann man mit denen leichter Geschäfte machen weil ihnen noch das wissen fehlt Müll von gutem zu trennen.

C/C++ Code ist ja an sich bereits recht Plattform unabhängig. Man darf nicht die stdc++ mit C++ verwechseln. In der Standardbibliothek gibt es selbstverständlich Dinge die nicht auf beliebig kleiner CPU oder MCU laufen können. Die ARM Cortex M4 sind ja untereinander sehr ähnlich nur die darum gebaute Hardware unterscheidet sich stärker. Was dann für die Entwicklung für verschiedene Vertreter ihrer Klasse eine deutlich Vereinfachung ist. Nur kann ich das noch nicht erkennen das man das auch in der Praxis über blink und serial hinaus anwendet. Ein bisschen Low Level nehmen einem die schon ab aber nur solange man dem Mainstream folgt. Eigene Vorstellungen sind in der Welt noch nicht erwünscht.

nun, ich kann und will jetzt hier nicht für Arduino und seine Kompatibilität die Lanze brechen, aber doch:
Jeder kann seine eigenen Libs und Codes entwickeln, und/aber es macht niemand jemand Vorschriften, zu welchen anderen 3rd Party Libs sie kompatibel sein müssen oder nicht.
Das ist für C/C++ für den Raspi nicht anders, auch hier gibt es welche, die zusammenpassen, und andere, die es nicht tun, das ist nunmal in C/C++ so, auf jeder Plattform: erlaubt ist alles, was der Programmierer will, es gibt fast nichts was die Programmiersprache vorschreibt.
Die Grundfunktionen bei Arduino sind nun mal neben digital und analog Read/Write noch Serial() und Wire(), der Rest ist ziemlich frei verfügbar.
Und wir sprechen ja hier nicht über RaspberryPi.org, was die für devtrees und GPIO- und kernel-Funktionen vereinbaren, und nicht über die Organisation, die C/C++ Standards allgemein erarbeitet. Obwohl alles legaler C/C++ Code ist, heißt das ja auch nicht, dass Code vom Raspi auf dem Bananapi laufen muss und umgekehrt, selbst wenn alle GCC 5.x oder 6.x oder 7.x oder 8.x verwenden.
EDIT: Ich erinnere mich beim Raspi auch an ein paar Beispiele, wo i2c-Libs für TFTs, die bcm-Funktionen verwendet haben, nicht mit wiringI2c kompatibel waren.
Der Due ist bei Arduino nun gerade ein schlechtes Beispiel für crossover-Plattform-Kompatibilität, das stimmt, er wurde auch in der Vergangenheit sehr vernachlässigt und seine Libs wenig weiterentwickelt.
Teensy macht das angeblich deutlich besser, was ich hier bereits las, und Adafruit auch, mit nur wenigen Einschränkungen. Für alles andere gibt es die Helpdesks der Hersteller und die github-Repo "issues".
Im Großen und Ganzen kann man aber schon sagen: was mit Arduino-Sketch-Code auf Arduino AVRs läuft, läuft auch auf supporteten ARM Cortex M0, M3, M4, Intel Galileo, ESP8266 und ESP32: Du wirst kein Framework finden, dass mehr fertige Libs zur Verfügung stellt als Arduino für verschiedensete cpu-Boards, und zu 99,9% alles kompatibel zueinander - und alles mit legalem, frei mit eigenem Code erweiterbarem C++ .

[alexander_ro]

Du vermischst da jetzt etwas die Bereiche Hardware und Anwendung beides braucht Software. Bei Linux kann jeder beliebiges an Libs Programmieren für seine Anwendungen. Er kann auch beliebiges im Kernel umbauen oder neu machen. Er kann aber nicht "wichtig" seine Kernel Änderungen nach belieben auf kernel.org und in den offiziellen Kernel Sourcecode verbreiten. Bei Arduino und mbed ist das anders dort wird alles in einem unübersichtlichem Wust auf der Projektseite angeboten. Mein aktuelles Beispiel mit dem oben genanntem Platinchen ist: der Compiler Meckert ein WiFi.h an aber der sagt nicht die Lib heißt DISOCO_STM32.xyz. Eine Suche nach der Datei liefert 5 Libs die diese enthalten. Welche ist es jetzt? ... Antwort gar keine weil der Hersteller sein eigenes Süppchen kocht und diese Beispiel auf dem Platinchen alle nicht gehen. Es gibt ein eigenes Beispiel dafür das geht. Aber erkennen kann man das nur als Insider der Entwicklungsabteilungen nicht als Programmierer der für eine Lib ja der Anwender ist.

Was mir fehlt ist eine klarere Linie zwischen Hardware, Anwendung bzw. Softwareschnittstellen die z.B. Timer oder ähnl. immer gleich zur Verfügung stellen. Auch die Trennung zwischen offiziellem von Arduino oder mbed und dem was von dritten Programmiert ist muss leichter zu erkennen sein.

Wenn Du mit dem Raspi Programm unter Linux nichts tust was der Bananapi wegen Hardware die ihm fehlt nicht kann läuft es auf beiden. Kann wegen verschiedener Linux und Lib Versionen sein das es neu übersetzt werden muss. Das es läuft stellt der Kernel und seine Schnittstellen bzw. die der glibc sicher.

Soll ja nicht heißen das die da was schlechtes machen ... nur das man vielleicht noch ein bisschen Ordnung rein bringen muss

[HaWe]

Du vermischst da jetzt etwas die Bereiche Hardware und Anwendung beides braucht Software. Bei Linux kann jeder beliebiges an Libs Programmieren für seine Anwendungen. Er kann auch beliebiges im Kernel umbauen oder neu machen. Er kann aber nicht "wichtig" seine Kernel Änderungen nach belieben auf kernel.org und in den offiziellen Kernel Sourcecode verbreiten. Bei Arduino und mbed ist das anders dort wird alles in einem unübersichtlichem Wust auf der Projektseite angeboten. Mein aktuelles Beispiel mit dem oben genanntem Platinchen ist: der Compiler Meckert ein WiFi.h an aber der sagt nicht die Lib heißt DISOCO_STM32.xyz. Eine Suche nach der Datei liefert 5 Libs die diese enthalten. Welche ist es jetzt? ... Antwort gar keine weil der Hersteller sein eigenes Süppchen kocht und diese Beispiel auf dem Platinchen alle nicht gehen. Es gibt ein eigenes Beispiel dafür das geht. Aber erkennen kann man das nur als Insider der Entwicklungsabteilungen nicht als Programmierer der für eine Lib ja der Anwender ist.

Was mir fehlt ist eine klarere Linie zwischen Hardware, Anwendung bzw. Softwareschnittstellen die z.B. Timer oder ähnl. immer gleich zur Verfügung stellen. Auch die Trennung zwischen offiziellem von Arduino oder mbed und dem was von dritten Programmiert ist muss leichter zu erkennen sein.

Wenn Du mit dem Raspi Programm unter Linux nichts tust was der Bananapi wegen Hardware die ihm fehlt nicht kann läuft es auf beiden. Kann wegen verschiedener Linux und Lib Versionen sein das es neu übersetzt werden muss. Das es läuft stellt der Kernel und seine Schnittstellen bzw. die der glibc sicher.

Soll ja nicht heißen das die da was schlechtes machen ... nur das man vielleicht noch ein bisschen Ordnung rein bringen muss

sagen wir mal so:
bei Arduino funktioniert alles sicher, was von Arduino bei der Standard-Installation dabei ist - für alles andere keine Garantie, funktioniert aber meist doch.
bei Banana und Raspi aber stimmt es oft nicht, denn beide haben verschiedene devtrees und auch andere kernel, selbst wenn beide unter Debian laufen (Raspbian ist ja zwar Debian, aber eben auf Raspi angepasst und nicht für Bananapi).
Es stimmt noch nicht mal für ausschließlich Raspis untereinander, einmal mit Raspbian und einmal mit Debian ev3dev distri, ebenfalls wegen unterschiedlichem devtree - - und das obwohl alle legalen C/C++ Code verwenden.
Und wie gesagt, noch nichtmal i2c-Code, einmal per bcm und einmal per wiringI2c sind miteinander (gleichzeitig) kompatibel, selbst wenn beide Raspis das gleiche Jessie oder Stretch verwenden.

Dass also immer C(++) Code auf allen Plattformen läuft, ist eine oft gelesene Mär...

[alexander_ro]

Vielleicht funktioniert das was Arduino bei der Standard Installation dabei hat. Das ist aber selbst bei deren eigenen Platinchen nur ein Bruchteil dessen was deren Hardware kann. Schon kurz nach überschreiten der Komplexität einer seriellen oder Blink Anwendung ist man dann wieder Hardware naher Programmierer der in Registern gräbt und Bits verschiebt. Ob das den Aufwand dann wirklich so stark verringert wie die Fachpresse gerne glauben macht? Entspricht zumindest nicht meiner Erfahrung.

Das C/C++ immer läuft habe ich nie behauptet. Devtree und das sonstige von Dir genannte ist jetzt aber Hardware. Hardware Zugriffe die hatte ich ja eingeschränkt. Hardware muss vorhanden sein ... es muss einen Kerneltreiber geben ... die lib die Du benutzt darf nicht am Kernel vorbei auf die Hardware zugreifen. Device Namen können abweichen weil das die Hersteller der Platinchen unterschiedlich realisieren. Aber der Device Name ist kein C/C++ Code. Neu übersetzen muss man den so meistens weil Versionen unterschiedlich sind oder gleich die ganze CPU anderen Code ausführt (siehe Intel und ARM). Meine Programme konnten das zumindest immer wechseln zwischen Intel und ARM. Ich habe in meinem Git Repo auf meiner Internetseite ein Programm das ohne Desktop auf dem Raspi (ARM) und meinem Alien (Intel) läuft und OpenGL Grafik auf das Orginale Raspi Display oder den Notebook Bildschirm aus gibt. In dem Sourcecode wird nicht mit irgendwelchen gruseligen ifdef Plattform hingebogen. Der Compiler übersetzt immer den gleichen Sourcecode.