Hi, ich habe bisher immer all meine Projekte ohne Code-Generator zu ende gebracht. Jetzt stell ich mir die Frage ob ich mir damit selbst ein Ei lege oder das tatsächlich viele so machen... Meiner Erfahrung nach ist der generierte Code oftmals schlecht lesbar, weshalb ich zwar manchmal den Code generieren lassen habe, diesen jedoch dann in ein anderes Projekt kopiert und stark verändert habe, sodass er mehr meinen Vorstellungen entsprach. Ist aber auch schon ein weilchen her (3 Jahre minimum), dass ich einen Code-Generator verwendet habe. Ich rede hier vorallem von Microchip Code-Generatoren (andere kenne ich nicht). Harmony ist zwar ok, aber zumindest bei mir seeeeeeeeeeehr langsam. Zumteil muss ich mehr als eine Minute warten, dass Änderungen übernommen werden. Bis dahin bleibt die IDE eingefroren. - Also benutzt ihr oft Code-Generatoren? - Wenn ja wie sind eure Erfahrungen mit Code-Composer (Microchip) oder Harmony (auch Microchip)? - Oder verwendet ihr keine Code-Generatoren? - Welche Gründe habt ihr dafür? Danke für eure Antworten Gruß P.S.: Programmieren macht auch einfach etwas mehr Spaß, wenn man nicht nur Knöpfchen drückt, sondern im Datenblatt selber nachlesen muss und man lernt mehr ;)
:
Bearbeitet durch User
Aabeku K. schrieb: > - Also benutzt ihr oft Code-Generatoren? Ja, wenn du mich meinst..... Und zwar den ein C++ eingebauten Codegenerator. Ich nenne sie mal "Die Template Engine"
EAF schrieb: > Aabeku K. schrieb: >> - Also benutzt ihr oft Code-Generatoren? > > Ja, wenn du mich meinst..... > Und zwar den ein C++ eingebauten Codegenerator. > Ich nenne sie mal "Die Template Engine" Hilft ihm jetzt bei µPython oder Rust wenig.
Ja sry. Habe ich vergessen explizit zu sagen es geht um C. Im Bereich embedded (µController).
Aabeku K. schrieb: > Ich kann dir nicht folgen. Was meinst du? Dito. Also bezogen auf den Eröffnungspost. "Codegeneratoren" ist ein weites Feld. Und ich kenne das MCP-Gerümpel, das du explizit nennst, nicht. Ich nehme an, es geht dir um ein (im weitesten Sinne) HAL. Also generierte Komfortfunktionen, um on-Chip Hardware benutzen zu können, ohne jedes Hardware-Register kennen zu müssen? Das verwende ich eher selten. Aus folgenden Gründen: 1. Die versprochene Einfachheit in der Anwendung ist oft nicht gegeben. Stattdessen muß man die Register trotzdem kennen, um aus den Parametern der HAL schlau zu werden. Mit HAL ist es also komplizierter als ohne. 2. Software tendiert dazu, Fehler zu haben. Generierter HAL Code ist leider oft buggy. Zum Debuggen von Fremdcode ist mir meine Zeit zu kostbar. 3. Erweiterbarkeit durch den User ist oft nicht gegeben. Wenn ich z.B. bei der Clock-Initialisierung etwas eigenes hinzufügen will, ist das nach dem nächsten Lauf des Generators weg. 4. Portabler Code wird zwar versprochen, aber nicht geliefert. Mit Glück läßt sich funktionsgleicher Code für einem anderen µC des gleichen Herstellers generieren (aber siehe 3.). Aber herstellerübergreifend? Fehlanzeige. 5. Vendor Lock-In. Wenn man sich auf ein HAL eingeschossen hat und seine Macken kennt, fällt der Wechsel noch schwerer. Gerade in der momentanen Verfügbarkeitssituation ist das nicht das, was man will. Aber das sind alles keine harten, absoluten No-Go's. Punkt 4. und 5. kann man z.B. mit libopencm3 umgehen. Punkt 3. tritt manchmal einfach nicht auf. Und bei Punkt 1. fällt für komplexe Periperie (z.B. USB) die Abwägung anders aus. Aber das sind meine Gründe. YMMV.
Aabeku K. schrieb: > - Wenn ja wie sind eure Erfahrungen mit Code-Composer (Microchip) Meinst du vielleicht den Code Configurator? Habe ich noch nie benutzt. > oder Harmony (auch Microchip)? Habe ich auch noch nie benutzt. Ist das nicht eher eine Bibliothek? > - Oder verwendet ihr keine Code-Generatoren? Mir reicht der Code-Generator, der Bestandteil eines jeden Compilers ist. Den benutze ich sogar sehr oft.
Axel S. schrieb: > Aabeku K. schrieb: >> Ich kann dir nicht folgen. Was meinst du? > > Dito. Also bezogen auf den Eröffnungspost. > > "Codegeneratoren" ist ein weites Feld. Und ich kenne das MCP-Gerümpel, > das du explizit nennst, nicht. > > Ich nehme an, es geht dir um ein (im weitesten Sinne) HAL. Also > generierte Komfortfunktionen, um on-Chip Hardware benutzen zu können, > ohne jedes Hardware-Register kennen zu müssen? Ja du hast absolut recht. Hätte ich mehr eingrenzen sollen. Aber deine Annahme ist goldrichtig. Es geht mir um die HAL-Generatoren. Gibt es von verschiedensten Herstellern. Ich kenn leider nur Microchip. Dein Antworten sind genau was ich gesucht habe. Gründe für und wider HAL-Code-Generatoren. In diesem Fall tendeziell eher gegen die Verwendung solcher Generatoren. Was wären den Gründe für einen solchen Generator? Man hört oft, es wäre schneller mit ihnen ein Programm zum laufen zu bekommen. Dem Stimme ich aber nur zu 50% zu. Klar hat man schneller funktionierende Resultate, aber der Overhead den man im nachhinein hat mit anpassen, debuggen, sichern bevor man den code neu generiert und einarbeiten in die IDEs, rechnet sich in meinen Augen nicht. Wofür sie meiner Meinung nach Super sind, vor allem als Anfänger oder beim Einarbeiten in eine neue Architektur/Hersteller, erspart man sich jedoch einiges an Kopfweh. Aber wie seht ihr das? Ist man wirklich so viel schneller mit einem Generator oder gibt sich das nicht viel? Gruß Vielen Danke!
:
Bearbeitet durch User
Yalu X. schrieb: > Aabeku K. schrieb: >> - Wenn ja wie sind eure Erfahrungen mit Code-Composer (Microchip) > > Meinst du vielleicht den Code Configurator? Habe ich noch nie benutzt. Jap. Sry mein Fehler :(
ich benutze lieber (RT)OS und setze den Code selber aus Komponenten zusammen, was mit C++ auf Anwendungslevel für mich übersichtlicher ist. Es gibt viele OS die ein umfangreiches API und gute Buildsysteme haben um Code für verschiedene Prozessoren zu bauen. Wenn etwas fehlt dann hilft der Codegenerator um eine Basis für eine eigene Komponente zu bekommen, da benutze ich aber nur CubeMX aus der Cortex-M Welt.
Aabeku K. schrieb: > Wofür sie meiner Meinung nach Super sind, vor allem als Anfänger oder > beim Einarbeiten in eine neue Architektur/Hersteller, erspart man sich > jedoch einiges an Kopfweh. Ja, man kann den generierten Code als Lernbeispiel für ein individuelles Problem ansehen und danach immer noch entscheiden, ob man ihn direkt übernimmt, anpasst oder mit dem daraus Gelernten seinen eigenen Code schreibt. Ist denn der vom Code Configurator generierte Code kommentiert und wenn ja, wie ausführlich? Nur wenn die Kommentare eine gewisse Qualität haben, kann man etwas aus dem generierten Code lernen. Ist dies nicht der Fall, würde ich mir die einführenden Beispiele woanders suchen, oder gleich das Datenblatt lesen (was man früher oder später sowieso tun sollte) und den Code komplett selber schreiben. Das ist dann zwar anfangs etwas mehr Aufwand, allerdings lernt man dadurch auch nachhaltiger.
Um sich in fremden Quelltexten zurechtzfinden, sind UML Systeme / Generatoren gar nicht schlecht, wenn sie in beide Richtungen funktionieren, also reverse engineering zulassen. Für den AVR ist zum Beispiel "Visualstate" nicht schecht, damit kann man unter anderem state machines visuell entwickeln, und sich daraus dann c-Quellcode generieren lassen. Für den PC ist "Sparx Enterprise" geil, daes UML in C++ und Pascal erstellen und reverse engineeren kann. Für ein Anfänger, der mal ein C-Hater werden will, sind Generatoren weniger geeignet, man begreift einfach besser, wenn man von der Pieke aus lernt. mfg
Oha, schönes Thema. Ich bin jemand der sich über den Code Generator in der STM32CubeIDE freut. Auf der einen Seite kann man Startup Code für unterschiedlich große STM32 Controller erzeugen. Was aber mein Herz höher schlagen lässt, ist, dass man seine eigenen Code Generator Templates einbauen kann. Man bekommt eine Oberfläche in der man seinen eigenen Code Generator integrieren kann. Ob man die HAL Module nutzt oder ob man sich auf diesen Weg eigene Treiber baut, steht einen offen. Und wenn man eine eigene Abstraktionsschicht für die Hardware hat, kann man höhere Protokolle eben auch Hardware unabhängig implementieren. Also, die Welt der Code Generatoren ist viel größer als man es von den Hersteller als "Appettithappen" bekommt. Wenn der Generator richtig arbeitet und man mit dem generierten Code richtig umgeht, gehen auch keine Anpassungen verloren. [Ich muss meine STM32Cube ExpansionPack endlich mal aufräumen, damit man es zeigen kann]
Ich benutze den MCC Code Generator sehr oft und mittlerweile funktioniert der ganz gut und man hat ratzfatz einen neuen Microcontroller auf einer neuen Leiterplatte am laufen. Allerdings ist es schon so, dass der generierte Code nicht immer optimal zum Projekt passt. So ist es bei mir ganz oft so, dass ich den MCC nur am Anfang nutze, damit schnell was funktioniert und nach und nach der Code in meine eigenen Funktionen kopiert und geändert wird. Da habe ich glaube für mich eine recht effiziente Lösung gefunden, mit der ich aktuell sehr zufrieden bin. Ich nutze den MCC also mehr als Sprungbrett ins neue Projekt und entferne es dann nach und nach wieder.
Toni schrieb: > Ich benutze den MCC Code Generator sehr oft und mittlerweile > funktioniert der ganz gut und man hat ratzfatz einen neuen > Microcontroller auf einer neuen Leiterplatte am laufen. Allerdings ist > es schon so, dass der generierte Code nicht immer optimal zum Projekt > passt. So ist es bei mir ganz oft so, dass ich den MCC nur am Anfang > nutze, damit schnell was funktioniert und nach und nach der Code in > meine eigenen Funktionen kopiert und geändert wird. Da habe ich glaube > für mich eine recht effiziente Lösung gefunden, mit der ich aktuell sehr > zufrieden bin. Ich nutze den MCC also mehr als Sprungbrett ins neue > Projekt und entferne es dann nach und nach wieder. Genau!! Ich les zum Beispiel ne in Object-Pascal geschriebene Komponente, die meine Nanny verbrochen hat, in UML ein, importiere dann in ein UML C++ Projekt diese wieder rein und optimiere / ergänze dann. So lern ich beide Sprachen in abenteuerlicher Weise- C++ und Pascal. Und manchmal funktioniert es dann... ;-))) mfg
Das Projekt an dem ich sitze nutzt Python zur Generierung von tausenden Konfigurationswerten. Theoretisch könnte dies in C++ via constexpr Funktionen erfolgen, leider sind die Interpreter in den verwendeten Compilern (GCC/Clang) aber zu langsam und haben die Compilezeiten zu stark beansprucht. Eventuell schau ich mir das nochmal an wenn Modules sinnvoll einsetzbar sind, dann müsste man den Preis zumindest nicht in jeder TU bezahlen...
Aabeku K. schrieb: > Also benutzt ihr oft Code-Generatoren? Generierter Code kommt bei mir nicht ins repo rein (wobei ich schon manchmal was generieren lasse, als teil des build prozesses). Und sozusagen code templetes wie hier gemeint zu sein scheinen, nutze ich auch keine. Jedes meiner Projekte ist wieder etwas anderes, und ich passe meine Pattern ein wenig an, mache vieles anders. Manchmal kristallisiert sich zwar schon ein Style heraus, aber es geht immer noch besser. In java ist so ein generator ja nützlich, mit all dem boilerplate. Aber in C kommt man in der regel direkt zur Sache, und macht keine unnötige dekoration.
Vincent H. schrieb: > Das Projekt an dem ich sitze nutzt Python zur Generierung von tausenden > Konfigurationswerten. Theoretisch könnte dies in C++ via constexpr > Funktionen erfolgen, leider sind die Interpreter in den verwendeten > Compilern (GCC/Clang) aber zu langsam und haben die Compilezeiten zu > stark beansprucht. Eventuell schau ich mir das nochmal an wenn Modules > sinnvoll einsetzbar sind, dann müsste man den Preis zumindest nicht in > jeder TU bezahlen... Huch ?!?! Tausende Configurationswerte? Kann Python nicht C-Objekte einbinden? Einfach die Funktion in c kompilieren und die obj in Python einbinden, ewentuell mit ner "Wrapperklaasse", drumrum, würde das nicht gehen? Dann ist python der "glue code" deiner kompilierten Konfogurationsfunktion... mfg
Was verstehst du unter Code-Templates? Von einem HAL-Generator generierten Code?
Aabeku K. schrieb: > Was verstehst du unter Code-Templates? Von einem HAL-Generator > generierten Code? Genau!! @Vincent: Bitte, Du mußt schon genauer werden, wenn das Forum hier brainstorming für Dich machen soll, :-P Wie progge ich? hat echt zu wenig Daten. ;-) mfg
Normlerweise verwende ich keine Codegeneratoren. Da ich aber mit Microchip PIC's arbeite, komme ich oft nicht am MCC vorbei, da die PIC's oder zumindest eine Teilfunktion schlecht dokumentiert ist. Da kann man sich dann vom MCC-Generierten Code was abschaun.. Gruß
Aabeku K. schrieb: > Was verstehst du unter Code-Templates? Von einem HAL-Generator > generierten Code? Bei manchen Codegeneratoren kann man selbst definierte Templates hinterlegen, die dann entsprechend mit automatisch generiertem Code gefüllt werden, z.B. bei STM32CubeMX.
Franko P. schrieb: > Normlerweise verwende ich keine Codegeneratoren. Da ich aber mit > Microchip PIC's arbeite, komme ich oft nicht am MCC vorbei, da die PIC's > oder zumindest eine Teilfunktion schlecht dokumentiert ist. Da kann man > sich dann vom MCC-Generierten Code was abschaun.. Du sprichst mir aus der Seele. Genau für solche Zwecke habe ich den Code-Composer oder Harmony verwendet. Was bei PIC respektive Microchip hilft, ist das anschauen der (ich nenen sie jetzt mal) Subdatasheets auf welche in dem µC-Datenblatt referenziert wird. Das beschreibt ein Modul deutlich detailiertert. Aber selbst dort fehlen manchmal Informationen.
Jens R. schrieb: > Ich muss meine STM32Cube ExpansionPack endlich mal aufräumen, damit man > es zeigen kann Würdest du es bitte hier zeigen? Ich z.B. wäre an sowas interessiert, gerade wenn sich jemand schon etwas länger damit beschäftigt hat :). VG Paul
🐧 DPA 🐧 schrieb: > Generierter Code kommt bei mir nicht ins repo rein (wobei ich schon > manchmal was generieren lasse, als teil des build prozesses). Und > sozusagen code templetes wie hier gemeint zu sein scheinen, nutze ich > auch keine. Das sollten die absolute Dogmen in der Entwicklung sein: 1) Nur Code-Generierung, die auch eine CI (kontinuierliche Integration)-Pipeline stemmen kann (OpenSource-Generatoren) 2) Quellformat als lesbare ASCII, damit's man per Revisionskontrolle auch die Aenderungen nachverfolgen kann 3) Sicherstellen, dass es die naechsten 10 Jahre bauen kann, Abhaengigkeiten von Firmen oder Webtools: No go. Der Grund dafuer ist einfach: Die Folgekosten, wenn das Projekt nach Abschluss nochmal angefasst werden muss, sind schnell mal hoeher als die Zeit, die man mit dem Generieren einspart. Ansonsten: Python ist die Generatorsprache schlechthin. Wir nutzen generell gerne entsprechende HAL-Konzepte, die aus Registertabellen und Abstraktionen die Treiberschichten wie auch die Low-Level-Doku dazu generieren.
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.