Ich befasse mich gerade mit STM32 und habe die ersten Testprojekte mit Atollic True Studio realisiert Wie es scheint, machen alle Freeware-Tools einen Bogen um C++ when es um STM32 geht. Bisher habe ich nur mitbekommen das scheinbar KEIL C++ unterstützt, dessen Kaufpreis hindert aber daran es zu benutzen. Gibt es irgend ein Tool welches C++ in Verbindung mit der STM32 Cube unterstützt oder einen Workaround um ein C++ Projekt zu generieren? Falls nicht, ist STM32 für mich gestorben bevor ich damit richtig begonnen habe...
:
Verschoben durch Moderator
Johnny S. schrieb: > Gibt es irgend ein Tool welches C++ in Verbindung mit der STM32 Cube > unterstützt oder einen Workaround um ein C++ Projekt zu generieren? Ja, der GCC kann C++ für ARM. Den verwendet das Atollic Studio. Du kannst also in deinem Atollic Projekt direkt C++ verwenden. Du musst nur C++ Source Files anlegen. Die API's der STM32 Cube Libs sind dann natürlich immer noch klassische C API's ohne OOP und so.
Stm32cube IST C (ohne ++). SW4STM32 kann aber das erstellte Projekt AFAIK umwandeln. Wieso aber so ein ++Zwang besteht bei dir erschließt sich mir nicht...
mbed ist ein OS das ein C++ API für die Standardkomponenten bietet. Für die STM32 targets wird intern der aktuelle HAL verwendet und damit kann man Cube Code für speziellere Peripherie einbinden. mbed kann über eine Exportfunktion Projekte für verschiedene IDE genenrieren, Atollic ist allerdings noch nicht dabei. SW4STM32 wird unterstützt, aber beim Import in Atollic gehen einige Einstlleungen verloren, das klappt leider noch nicht. Da ST bei mbed aber sehr engagiert ist und jetzt ja der neue Besitzer von Atollic ist gehe ich davon aus das es den Export zu Atollic auch irgendwann gibt.
Max D. schrieb: > Stm32cube IST C (ohne ++). > SW4STM32 kann aber das erstellte Projekt AFAIK umwandeln. > Wieso aber so ein ++Zwang besteht bei dir erschließt sich mir nicht... Das Problem ist das C keine Klassen kennt. Funktionen wie "sensor.read()" und "anotherSensor.read()" können also nicht realisiert werden. Somit ist das ganze für mich persönlich unbrauchbar Johannes S. schrieb: > mbed ist ein OS das ein C++ API für die Standardkomponenten bietet. Für > die STM32 targets wird intern der aktuelle HAL verwendet und damit kann > man Cube Code für speziellere Peripherie einbinden. > mbed kann über eine Exportfunktion Projekte für verschiedene IDE > genenrieren, Atollic ist allerdings noch nicht dabei. SW4STM32 wird > unterstützt, aber beim Import in Atollic gehen einige Einstlleungen > verloren, das klappt leider noch nicht. Da ST bei mbed aber sehr > engagiert ist und jetzt ja der neue Besitzer von Atollic ist gehe ich > davon aus das es den Export zu Atollic auch irgendwann gibt. Freut mich zu hören, hoffe das es irgendwann so weit ist :) Finde es leider sehr bedenklich das man ein OS verwenden muss nur um C++ Funktionalität zu erhalten..
Johnny S. schrieb: > Finde es leider sehr bedenklich das man ein OS verwenden muss nur um C++ > Funktionalität zu erhalten.. Muss man nicht. Siehe oben.
Johnny S. schrieb: > Finde es leider sehr bedenklich das man ein OS verwenden muss nur um C++ > Funktionalität zu erhalten.. Was ist für dich daran bedenklich? Es ist ein Sammlung von Klassen für die Peripherie, mittlerweile ergänzt um ein RTOS und Features die man nutzen kann aber nicht muss. Nicht benutzten Kram schmeißt der Linker raus. Und die STM32 haben reichlich Speicher, den muss man erstmal voll kriegen.
Johnny S. schrieb: > Das Problem ist das C keine Klassen kennt. Funktionen wie > "sensor.read()" und "anotherSensor.read()" können also nicht realisiert > werden. Doch können sie. Objektorientiertes Programmieren geht auch in C, Das sieht dann halt ein bisschen anders aus und die Namen der Methoden werden länger weil sie keine eigenen Namensräume haben, das ist aber in der Praxis für genau solche simple Sachen wie Du sie hier als Beispiel anführst genauso einfach und obige Aufrufe sähen dann vielleicht so aus: sensor_read(&sensor); sensor_read(&another_sensor); Da führt man dann halt eine sinnvolle Namenskonvention ein so daß alle Methoden der Klasse Sensor mit sensor_ beginnen und in sensor.c/sensor.h zu finden sind und dann geht das auch ganz entspannt. Also wenn du was anführen willst was in C "nicht realisierbar" ist mußt Du Dir schon deutlich mehr Mühe geben. > Somit ist das ganze für mich persönlich unbrauchbar Andere brauchen und nutzen das problemlos jeden Tag. Und der Code sieht genauso sauber aus wie in C++ wenn man es ordentlich organisiert. Das einzige was in C wirklich unhandlich ist ist Vererbung, aber selbst da kann man gangbare Auswege finden wenn man etwas umdenkt.
:
Bearbeitet durch User
Bernd K. schrieb: > Doch können sie. Objektorientiertes Programmieren geht auch in C, Das > sieht dann halt ein bisschen anders aus und die Namen der Methoden > werden länger weil sie keine eigenen Namensräume haben, das ist aber in > der Praxis für genau solche simple Sachen wie Du sie hier als Beispiel > anführst genauso einfach und obige Aufrufe sähen dann vielleicht so aus: > > sensor_read(&sensor); > sensor_read(&another_sensor); Bei simplen Sachen gebe ich dir recht, bei ganzen Abläufen die auf Klassen beruhen macht das kein sinn mehr, das ist dann gleichwertig wie einfach die Routine zu kopieren. Am Anfang einer C++ Klasse steht ja der initializer welcher alle Elemente speichert. Ein einfaches Beispiel: LED ledGrün(LEDPIN1); LED ledRot(LEDPIN1); LED::ledToggle(){ setIO_toggle(theLedPin); } nun kann überall im code z.b. "ledGrün.toggle()" benutzt werden. Bei C müsste man ja überall die Werte mitgeben. Bei der LED funktion wäre das einfach, aber stell dir mal sowas vor read_tag(keyA,keyB,&uid,&block1&block2,hasToReadBlock,tagtyp1_accept,tag typ2_accept) wie wärs denn mit "reader1.readTag();" > Andere brauchen und nutzen das problemlos jeden Tag. Und der Code sieht > genauso sauber aus wie in C++ wenn man es ordentlich organisiert. Das > einzige was in C wirklich unhandlich ist ist Vererbung, aber selbst da > kann man gangbare Auswege finden wenn man etwas umdenkt. Es geht nicht darum ob man es nutzen will oder nicht, aber wenn nur C möglich, dann wird aus "Mikrocontrollerhersteller wecheseln" mal ganz schnell "komplett neue Software machen". Alle bestehenden Bibliotheken sind dann auch nur noch Festplattenfüller
Johnny S. schrieb: > read_tag(keyA,keyB,&uid,&block1&block2,hasToReadBlock,tagtyp1_accept,tag > typ2_accept) > > wie wärs denn mit "reader1.readTag();" so etwa:
1 | reader_read_tag(&reader1); |
reader1 ist ein struct mit allen members der Instanz. Die übliche Konvention ist es daß jede Methode als erstes Argument einen Pointer auf die Instanz erhält, das was bei C++ unter der Haube auch passiert, in C muß man es halt explizit hinschreiben.
GCC und Clang produzieren wunderbaren C++ Code, aktuell sogar schon C++20... Beide sind nicht nur Freeware, sondern sogar Open Source.
Johnny S. schrieb: > Das Problem ist das C keine Klassen kennt. Funktionen wie > "sensor.read()" und "anotherSensor.read()" können also nicht realisiert > werden. Somit ist das ganze für mich persönlich unbrauchbar Johnny S. schrieb: > Falls nicht, ist STM32 für mich gestorben bevor ich damit richtig > begonnen habe... Du hast wirklich komische Prämissen. Abgesehen davon scheinst du nicht mal C zu kennen. Sonst wüsstest du, daß man selbst in simplem C auch Funktionen in einem struct haben kann. Da ist der Schritt zum Implementieren von Objekten leicht, denn man muß lediglich den Bezug der für alle Objekte gleicher Klasse vorgehaltenen Methoden, der bei echten Methoden vom Compiler gemacht wird, zu Fuß hinschreiben. Siehe Lernbetty, aus der du offensichtlich nix gelernt hast:
1 | #define RCST const struct TMenuItem
|
2 | struct TMenuItem |
3 | { struct TRect R; |
4 | usw. |
5 | ....
|
6 | void (*OnKey) (RCST* self, word *aKey); |
7 | void (*OnEvent)(RCST* self, word *aEvent); |
8 | void (*Draw) (RCST* self); |
9 | };
|
Aber wenn du halt derart anspruchsvoll bist, dann sind Mikrocontroller eben für dich gestorben - bevor du überhaupt angefangen hast. Ah ja, ist ja Freitag. W.S.
Johnny S. schrieb: > LED ledGrün(LEDPIN1); > LED ledRot(LEDPIN1); > > LED::ledToggle(){ > setIO_toggle(theLedPin); > }
1 | // Klasse
|
2 | typedef struct { |
3 | uint8_t pin; |
4 | uint8_t mask; |
5 | GPIO_Type* gpio; |
6 | } led_t; |
7 | |
8 | // Konstruktor
|
9 | void led_init(led_t* self, GPIO_Type* gpio, uint8_t pin) { |
10 | self->pin = pin; |
11 | self->mask = (1 << pin); |
12 | self->gpio = gpio; |
13 | }
|
14 | |
15 | // Methoden
|
16 | void led_on(led_t* self) { |
17 | self->gpio->psor = self->mask; |
18 | }
|
19 | |
20 | void led_off(led_t* self) { |
21 | self->gpio->pcor = self->mask; |
22 | }
|
23 | |
24 | void led_toggle(led_t* self) { |
25 | self->gpio->ptor = self->mask; |
26 | }
|
27 | |
28 | |
29 | // Zwei Instanzen davon (statisch allokiert)
|
30 | led_t rot; |
31 | led_t blau; |
32 | |
33 | void main(void) { |
34 | led_init(&rot, GPIOA, 5); |
35 | led_init(&blau, GPIOA, 3); |
36 | |
37 | while("my guitar gently weeps") { |
38 | led_on(&blau); |
39 | led_toggle(&rot); |
40 | delay(); |
41 | led_off(&blau); |
42 | delay(); |
43 | }
|
44 | }
|
:
Bearbeitet durch User
Genauso macht es mbed in der Implementierung, nach außen ist es C++. Die Implementierung wird Targetabhängig dazu gelinkt, dadurch ist es egal ob ich einen NXP, STM, Nordic oder sonstigen Cortex-M benutze. Ohne #ifdef Orgien im Quellcode oder cores die alle inkompatibel zueinander sind. Vom M0 mit 16 kB bis zum M4 mit 2 MB.
Okay, ich versuche mich nochmals anders auszudrücken: Es geht nicht primär darum ob C weniger kann als C++, sondern darum das Software in C++ vorhanden ist, welche komplett geändert werden müsste, was x-Stunden an Zeit vernichten würde. Wenn C++ out-of-the-box laufen würde müssten nur die Hardware-Funktionen angepasst werden. Also das eine Funktion "Output_on();" Nicht mehr z.b. "BSF PORTA,3" enthält sondern das STM equivalent. würde man mit einem C und C++ gleichzeitih bei 0 beginnen kämen sicher beide z Ziel. Aber wenn schon etwas vorhanden ist, lohnt sich der Aufwand nur selten...
Johnny S. schrieb: > Wenn C++ out-of-the-box laufen würde müssten nur die Hardware-Funktionen > angepasst werden Natürlich läuft es out of the box. Wurde doch oben schon gesagt. Der gcc kann selbstverständlich auch c++ und Du kannst das halbe oder auch das ganze Projekt in c++ machen. Mußt halt mit C++ und mit C umgehen können (und mit der Toolchain und wissen wie das eigentlich alles zusammenhängt und funktioniert bis runter zum blanken Silizium, aber das muß man sowieso wissen oder lernen wenn man sich irgendwie ernsthaft mit bare metal beschäftigen will).
:
Bearbeitet durch User
@Johnny S: ich fürchte Du wirfst hier einiges durcheinander und siehst Abhängigkeiten wo eigentlich gar keine sind. Johnny S. schrieb: > Atollic True Studio Das ist eine IDE. Also eine Oberfläche für Debugger, Compiler etc. Laut deren Webseite: "Built on Eclipse, CDT, GCC and GDB" Da steckt also z.B. der GCC drin und der kann schon seit Jahrzehnten C++ kompilieren. Und er kann das auch für ARM-Cortex-M0, -M3 und -M4. > Gibt es irgend ein Tool welches C++ in Verbindung mit der STM32 Cube > unterstützt oder einen Workaround um ein C++ Projekt zu generieren? So, und wie kommt da jetzt das STM32 Cube da ins Spiel? Wenn Du Probleme lösen willst, kommt es darauf an daß Du sie in Teilprobleme zerlegen und diese dann konkreter beschreiben kannst. "alle Freeware-Tools", "Bogen um C++" und "when es um STM32 geht" ist genau das Gegenteil von konkretem Beschreiben des eigentlichen Problems. Also z.B. "Mit STM32 CubeMX erzeugte Projekte lassen sich nicht mit C++ kompilieren". Dann kannst Du Dir überlegen warum. Was für Fehlermeldungen entstehen? Wo rühren die her? Wenn das nicht offensichtlich ist, kann man sich überlegen warum das STM32 CubeMX einem so wichtig ist und ob man das braucht. (Meine Meinung: Nein).
:
Bearbeitet durch User
Johnny S. schrieb: ************************************* > Gibt es irgend ein Tool welches C++ in Verbindung mit der STM32 Cube > unterstützt oder einen Workaround um ein C++ Projekt zu generieren? Die beiden unten aufgeführten Links könnten evt. den Weg weisen: *************************************************************** https://gnu-mcu-eclipse.github.io https://github.com/gnu-mcu-eclipse/eclipse-plugins Sowohl Installation als auch Workflow mit Eclipse war für mich ein gutes Stück Arbeit und erforderte einiges an Durchhalte-Vermögen. Hardware war STM32Nucleo und war nur zuverlässig mit SEGGER J-Link https://gnu-mcu-eclipse.github.io/developer/j-link-stm32-boards/
MitLeserin schrieb: > Sowohl Installation als auch Workflow mit Eclipse war für mich ein gutes > Stück Arbeit Die Installation ist mit den neuen xpm Paketen aber mittlweile wesentlich angenehmer geworden. Bin auch gerade von Win7 nach Win10 umgezogen und musste alles möglich neue installieren, das gnu-mcu-eclipse war in ein paar Minuten installiert.
Bernd K. man kann so wie du das mit dem "objektorientierten C" beschrieben hast sogar noch einen schritt weiter gehen. wenn man mit funktionszeigern arbeitet die in der struct definiert sind. da kann man echt richtig schöne sachen machen.
Rene B. schrieb: > wenn man mit funktionszeigern > arbeitet die in der struct definiert sind. da kann man echt richtig > schöne sachen machen. Genau, z.B. zur Laufzeit einen Treiber einhängen oder ähnliches. So etwas sieht dann im Prinzip wie folgt aus:
1 | typedef struct API_LIST_STRUCT { |
2 | void (*pfEnable) (void); |
3 | void (*pfDisable) (void); |
4 | void (*pfInit) (void); |
5 | void (*pfSet) (int p); |
6 | void (*pfClear) (int p); |
7 | } API_LIST; |
Noch eine GCC IDE die mit C++ funktioniert ;-): https://www.segger.com/products/development-tools/embedded-studio/
W.S. schrieb: > Aber wenn du halt derart anspruchsvoll bist Dann schlag du doch mal den anspruchsvollen Unterschied zwischen #define und typedef nach :-) Johnny S. schrieb: > sondern darum das > Software in C++ vorhanden ist, welche komplett geändert werden müsste, > was x-Stunden an Zeit vernichten würde. C++ ist größtenteils abwärtskompatibel zu C. Man kann nahezu alle C Software, insbesondere auch die STM32CubeF* Pakete, welche von STM32CubeMX eingebunden werden, problemlos von C++ aus nutzen. Die APIs sind zwar C-typisch nicht so schön, aber man kann damit leben.
Gerd E. schrieb: > > Wenn das nicht offensichtlich ist, kann man sich überlegen warum das > STM32 CubeMX einem so wichtig ist und ob man das braucht. (Meine > Meinung: Nein). Zumindest um mal den ganzen Clock-Krempel einigermaßen nachvollziehen zu können, war das Ding sehr hilfreich (im Gegensatz zu dem Bild im Datenblatt). Danach weiß man, wie die Register zu setzen sind. ;) Johnny möchte offenbar seine C++-Libs weiter benutzen. Ehrlich gesagt habe ich noch nicht ganz verstanden, warum das beim STM32 nicht funktionieren soll.
Hallo, das ist ein sehr interessanter Thread (wenn auch schon etwas älter) mit tollen Ansätzen wie man objektorientiert in C programmiert. Ich kann das nur empfehlen! Da gibt es ein sehr gutes Buch zum Thema: https://www.amazon.de/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X/ref=sr_1_fkmr3_1?dchild=1&keywords=tdd+for+embbeded+C+code&qid=1600241049&sr=8-1-fkmr3 Inklusive einer Einführug zum Testen seiner Software (TDD) - auch nicht ganz unwichtig heutzutage. Gruss Peter
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.