Hi, Ich möchte mich nach ersten einfachen Projekten in C auf STM32 Basis etwas einlesen in strukturierte Programmierung von größeren Projekten, d.h. wie ziehe ich State Machines auf, Kommunikation mit ICs, Zeitliche Abläufe, Tasks, Auslagern von Teilprogrammen, Modulare Entwicklung, Libraries etc. Welche Ansätze gibt es, am besten mit Blaupausen oder komplexeren Projekten als Beispielen. Kann jemand was empfehlen?
Speziell für embedded kenne ich kein Buch. Aber ich kann dir ein Stichwort zum Suchen geben: Patterns https://www.amazon.de/s?k=patterns+programming&i=stripbooks
Hyper schrieb: > Hi, > Ich möchte mich nach ersten einfachen Projekten in C auf STM32 Basis > Kann jemand was empfehlen? Learning by doing. Ansonsten ISBN: 978-3897215672, ebenfalls mit der Einschrämkung, das das nicht speziell für embedded geschrieben wurde.
Fpgakuechle K. schrieb: > Ansonsten ISBN: 978-3897215672 Weiss nicht. Ich fand es unterhaltsam, aber nicht besonders lehrreich. Kommt vielleicht daher, dass ich kein Anfänger mehr bin. Das Buch ist sehr allgemein gehalten, also nicht spezifisch für embedded Programmierung. Aber der Titel ist lustig, macht sich gut im Bücherregal.
Stefan ⛄ F. schrieb: > Fpgakuechle K. schrieb: >> Ansonsten ISBN: 978-3897215672 > > Weiss nicht. Ich fand es unterhaltsam, aber nicht besonders lehrreich. Ist halt die Frage, welche Skills einem noch zum Programieren fehlen, das erwähnte Buch ist eben eines der wenigen die auf die - sag ich mal verquast weil mir nicht besseres einfällt - sozio-kulturellen Aspekte des Programmierens ein. Also wie springt man über seinen eigenen Schatten (beim Programmieren), wie schreibt man #cpmments die wirklich hilfreich sind, was schreibt man selbst - was nicht. Wie bringt man anderen neue tools nahe, ... Dann wäre auch noch zu erkläreen, was 'speziell für embedded' überhaupt bedeudet?! Vielleicht bedeudet es, das man die toolchain richtig kennen sollte, nicht nur einen One-Button-Compile. Dann wäre vielleicht ISBN:3-7723-5599-4 einen Blick wert. Wobei IMHO die englischsprachige Literatur aus etablierten verlagen oft den deutschen vorzuziehen ist. Am besten, mal einen Nachmittag Zeit nehmen und die passenden amazon-Kategorien durchsortieren. Wobei Bücher für Embedded gerne im akademischen stecken bleiben. Früher hatten Fachzeitschriften mal gute Kurse, vielleicht findet man ja bei heise.de was passendes: https://shop.heise.de/stm32-umfassende-praxisbuch.
Bei STM32 hast du die größte Auswahl an Konzepten. Von Bare Metall über unterschiedlich bequeme RTOS bis zu Qt Quick. Kannst dich in jedes einzelne Bit einarbeiten oder Liberales verwenden, die das schon irgendwie richtig machen. So wäre ein Vorschlag, du probierst die unterschiedlichen Ansätze mal aus, arbeitest die Tutorials durch.
Die meisten Patterns habe ich von Kollegen gelernt. In aktuell laufenden Projekten können Kollegen viel besser den Nutzen diverser Vorgehensweisen erklären, als es ein allgemein gehaltenes Buch tun kann.
Hyper schrieb: > d.h. wie ziehe ich State Machines auf, Kommunikation mit ICs, Zeitliche > Abläufe, Tasks, Auslagern von Teilprogrammen, Modulare Entwicklung, > Libraries etc. Ich fürchte, Du hast da einen schwachen Punkt getroffen. Deine Aufzählung beinhaltet den Großteil der kritischen Designentscheidungen typischer Embedded-Projekte. Und leider gibt es wenig allgemeingültige Lösungen. Über jedes Thema könnte man ein eigenes Buch schreiben und 90% darin wäre "Thema verfehlt". Für alle gibt es zahlreiche Ansätze, die jedoch nur in ihrem Kontext Sinn machen. Und über allen schwebt das Timing. Von "alles per RTOS machen", über individuelle Interrupts bis zu alles im SysTicker ist die Wahl des Timings bestimmend für die Architektur der Treiber und Libraries. Der Klassiker ist ein Treiber für die serielle Schnittstelle, den man ja schon mal entwerfen kann. Am Besten vom kleinen Pic bis zur Steuergeräte-CPU mit einer Abstraktion. Und sicher findest Du viele hier, die "genau das schon erfolgreich gemacht haben". Vermutlich ist die Aufgabe ähnlich wie ein Buch über mechanisches Design, dass vom Uhrwerk bis zum Verbrennungsmotor die grundlegenden Designdetails erläutern soll.
https://www.wiley.com/en-us/Real+Time+Embedded+Systems-p-9781118116173 Schau dir am besten das Inhaltsverzeichnis im Link an ... Wenn es C++ sein darf ist das Buch Real-Time C++ von Christopher Kormanyos incl. code zu empfehlen.
A. S. schrieb: > Und leider gibt es wenig allgemeingültige > Lösungen. Darum geht es gar nicht. > Über jedes Thema könnte man ein eigenes Buch schreiben und 90% > darin wäre "Thema verfehlt". Nö. Das Ziel ist das Vermitteln von Wissen und Konzepten, nicht die Auflistung von Kochrezepten, die man ohne Nachdenken einfach kopieren kann. Daß man die Konzepte immer an die Aufgabe anpassen muss bzw. durch Erfahrung beurteilen muss, ob es das richtige Konzept ist, ist normal.
Design Patterns for Embedded Systems in C https://www.oreilly.com/library/view/design-patterns-for/9781856177078/ https://www.youtube.com/watch?v=S0ODfxXe2UU Programming Embedded Systems https://www.oreilly.com/library/view/programming-embedded-systems/0596009836/ Building Embedded Systems https://link.springer.com/book/10.1007/978-1-4842-1919-5
Falk B. schrieb: >> Und leider gibt es wenig allgemeingültige >> Lösungen. > > Darum geht es gar nicht. Doch. Während es zu konkreten Aspekten (Kommentare, Coding-Styles, Benamungen, ....) sehr gute und ausführliche Werke gibt, die bekannte Muster vergleichen und Vor-/Nachteile listen, ist dies zu Themen des TO kaum der Fall. Wenn man Glück hat, stellt ein Autor ein gutes Gesamtkonzept (z.B. Aufbau von Modulen, APIs, Schnittstellendesign) vor, dass für seine Welt super ist und benennt vor und Nachteile. Das passt dann für ähnliche Leistungsklassen und Aufgabenstellungen und füllt schon ein ganzes Buch. Es würde auch ein ganzes Buch füllen, die Eigenschaften von Event-Driven und Loop-Design aufzuarbeiten, ganz zu schweigen von den Arten, wie man das dann jeweils umsetzt. Während man für die oben erwähnten guten Bücher oben nur jeweils kleine Codeschnipsel braucht, muss man den Unterschied zwischen Event-Driven und Loop wirklich mal erleben, sonst glaubt man es nicht. Da reichen keine gedruckten Beispiele.
A. S. schrieb: > Während man für die oben erwähnten guten Bücher oben nur jeweils kleine > Codeschnipsel braucht, muss man den Unterschied zwischen Event-Driven > und Loop wirklich mal erleben, sonst glaubt man es nicht. Da reichen > keine gedruckten Beispiele. Dass Problem dabei ist, dass dieses Pattern bei kleinen Hello-World Anwendungen absurd komplex wirkt. Bei großen Programmen (die sich der Anfänger womöglich noch nicht vorstellen kann) ist es hingegen super simpel und übersichtlich. Im Smart Home ist die Event Queue aus gutem Grund der Zentrale Baustein - bei allen Herstellern.
Stefan ⛄ F. schrieb: > Dass Problem dabei ist, dass dieses Pattern bei kleinen Hello-World > Anwendungen absurd komplex wirkt. Bei großen Programmen (die sich der > Anfänger womöglich noch nicht vorstellen kann) ist es hingegen super > simpel und übersichtlich. Genau. Stefan ⛄ F. schrieb: > Im Smart Home ist die Event Queue aus gutem Grund der Zentrale Baustein > - bei allen Herstellern. Und die Loop bei Prozesssteuerung. Und beide mit genügend Ausnahmen im jeweils anderen Paradigma.
> Bei großen Programmen (die sich der > Anfänger womöglich noch nicht vorstellen kann) ist es hingegen super > simpel und übersichtlich. Stimmt. Hier liegt das Henne-Ei Problem. Ein Entwickler muss zunächst mal ein oder zwei Projekte versenken. Bis er versteht, wieso man Doku, Modulstruktur und Interfaces so aufwändig anlegen muss. Wieso man diese Lehrbücher sorgfältig durcharbeiten muss. > Die meisten Patterns habe ich von Kollegen gelernt. Da hast du irrsinniges Glück gehabt. In den meisten Firmen findest du nur zwei Arten von Kollegen. Die einen machen Altlastenpflege. Was die machen, willst du gar nicht lernen. Die anderen haben selbst noch keine Ahnung. Glauben, die bräuchten sich nicht in die ganzen aufwendigen und schwierigen Konzepte einarbeiten. Es würde genügen, wenn sie die simplen Scrum-Regeln befolgen.
Hyper schrieb: > Ich möchte mich nach ersten einfachen Projekten in C auf STM32 Basis > etwas einlesen in strukturierte Programmierung von größeren Projekten,... Der Bogen ist schon etwas weit. Nach meiner Erfahrung sollte man vorsichtig sein mit dem, was in Büchern so angepriesen wird. Allermeistens sind das Ergüsse, die aus akademischer Richtung kommen (weil man dort veröffentlichen muß, um damit Meriten zu sammeln), oder es sind Labereien, die jemand zusammenschreibt, um mal wieder ein Buch zu erzeugen, weil er von sowas lebt. Allgemeiner Rat: Lerne, selbständig und gründlich zu denken und zu planen, denn die Alternative wäre, sich sein Zeugs für künftige Projekte lediglich zusammenzukopieren und dann mit den diversen Unpäßlichkeiten so eines Flickenteppichs zu ringen. Auf welcher Basis du deine bisherigen "einfachen Projekte in C auf STM32" gemacht hast, solltest du zunächst in Betracht ziehen. Wenn du zuvörderst nur mit sowas wie Cube und Konsorten hantiert hast, dann lerne, ohne so ein Zeug auszukommen. Dazu wäre es wohl das beste, einen Controller auf Cortex-M Basis zu nehmen, der nicht von ST kommt. Damit man nicht in Versuchung kommt, der eigenen Faulheit zuliebe doch wieder auf obengenanntes Zeug zurückzugreifen. Ziel der ganzen Übung ist, daß du dir selber Gedanken machst über die Architektur deiner zu planenden Firmware und daß du dabei etwas lernst. Eine etwas andere Sache ist, einmal Beispiele für Detail-Lösungen zu sehen und dann für sich entscheiden zu können, ob davon etwas für einen selbst interessant sein könnte. Aber sowas steht selten in Büchern. Was mich vor Jahren angeregt hatte, ist ein altes in der DDR erschienenes Buch "Algorithmen der Mikrorechentechnik", das zwar den damaligen Z80 bzw. U880 als Prozessorbasis hernahm, aber dabei die Prinzipien und Algorithmen ganz ordentlich erläuterte. Sowas ist dann recht plattformunabhängig, weswegen man daraus etwas lernen kann. Allerdings wüßte ich jetzt kein aktuelles Buch, was so ähnlich aufgestellt wäre. Damit bleibt dir nur das Selberdenken übrig. W.S.
Arbeite dich am besten in freeRTOS ein.
"Structure and Interpretation of Computer Programs" ist da der Klassiker. Nimmt als Beispielsprache LISP her, lehrt aber Grundprinzipien die Programme in jeder Sprache besser machen. https://web.mit.edu/6.001/6.037/sicp.pdf Wenn du eher in den Bereich C gehen willst, gibt auch "The Art of UNIX Programming", welches man auch leicht Online findet. Das zeigt dann auch wie mn Software im natürlichen Umfeld von C (UNIX) strukturiert. Weil ich es gerade oben gelesen habe, die Dokumentation von "FreeRTOS" ist auch lesenswert, da es ein gutes Beispiel für gute Schnittstellen in C ist.
Bränk schrieb: > hier mein Lieblingsbuch zu dem Thema: > > https://www.safetty.net/publications/pttes Kann man in die Tonne kippen... Was will das Buch? Hunderte Seiten wie man eine LED anschließt? Dann noch in der Variation mal ein Relais oder einen Piezo-Summer... Und der Softwareteil? Unmöglich formatierte C-Code-Listings mit jeweils mehreren Kommentarzeilen "Ende der Datei"? Und das wieder und wieder über unzählige Seiten? Und der Abschuss ist ja wohl der "255-Tick-Scheduler", bei dem anstatt 16-Bit-Datentypen nun eben 8-Bit-Datentypen verwendet werden. Dafür ein ganzes Kapitel mit zweistelliger Seitenanzahl... Und so geht es drunter und drüber. Den Inhalt hätte man auf ein 50-Seiten-Maker-Heftchen zusammendampfen können. Vergeudetet Lebenszeit, sich das anzuschauen.
Bratmaxxe schrieb: > Arbeite dich am besten in freeRTOS ein. Witz, komm raus! Du bist umzingelt. Mal im Ernst: Was soll so etwas? Lernt man damit etwa irgendwelche sinnvollen Algorithmen? Oder Herangehensweisen? Nein, es kann einem Leser nur beigebracht werden, wie man dieses spezielle Programm benutzt und was es für ein API hat. W.S.
Da kann man viel lernen: Kommunikation zwischen Prozessen, Resourcen teilen, Deadlocks produzieren und vermeiden, Prioritäten und ihre Fallstricke, und einiges mehr. Halt nicht so low level wie ohne RTOS, aber warum nicht? Nur weil man es selber anders gelernt hat? Grundsätzlich falsch ist die Idee nicht aus meiner Sicht. Das was der TO vermutlich vorhat, ist ja nicht zwangsläufig low level.
es war sicher auch der Programmierstil von FreeRTOS gemeint. Modularisierung und Namensgebung sind gut verständlich. Wenn man allerdings mehrere Libraries verwendet, wird man kaum etwas einheitliches finden. Dann ist doch wieder Toleranz gefragt.
Klaus W. schrieb: > Da kann man viel lernen: > Kommunikation zwischen Prozessen, Resourcen teilen, Deadlocks > produzieren und vermeiden, Prioritäten und ihre Fallstricke, und einiges > mehr. Ja, ein RTOS macht die Programmierung um ein vielfaches komplizierter. Man hat dann keinerlei Kontrolle mehr, wie oft, wie schnell und in welcher Reihenfolge die einzelnen Tasks ausgeführt oder sogar mittendrin unterbrochen werden. Man benötigt daher sehr komplexe und umfangreiche Synchronisationsmechanismen. Es sieht nur auf den ersten Blick leicht aus, einfach Tasks parallel in ein RTOS zu stellen und zu hoffen, daß die sich alle irgendwie miteinander vertragen mögen. Es ist sehr schwer, große RTOS Projekte stabil und zuverlässig zum Laufen zu bringen. Oft nimmt man daher sehr viel Ressourcen, so daß alles weit unter Maximallast läuft und Konfliktsituationen möglichst selten auftreten.
Ist ja alles richtig. Aber was er will ist: Hyper schrieb: > State Machines auf, Kommunikation mit ICs, Zeitliche > Abläufe, Tasks, Auslagern von Teilprogrammen, Modulare Entwicklung, > Libraries etc. Wenn man das alles vorhat, dann ist es zumindest überlegenswert nicht ganz unten anzufangen. Natürlich macht es bei µC Sinn, die Niederungen zu lernen - sehe ich genauso. Danach hat er aber nicht gefragt, sondern seine hehren Ziele genannt. Mag sein, daß er dann merkt ihm fehlt was darunter. Dann hat er was gelernt und muß halt nachbessern. Bis dahin kommt er mit seinen Themen vielleicht schneller voran, wenn er mit einem RTOS einsteigt. Wenn ich komplexere Sachen lernen will, muß ich ja auch nicht unnötig Maschinencode hexadezimal hinschreiben. Es gibt solche Leute ... Es ist gut, wenn man sich in Assembler bewegen kann - und trotzdem ist es effizienter in C oder C++ zu programmieren. Man könnte zu Fuß programmieren, muß aber nicht. Analog würde ich ein RTOS nicht pauschal ausschließen für seine Frage oben. Peter D. schrieb: > Man benötigt daher sehr komplexe und umfangreiche > Synchronisationsmechanismen. Und ohne ein RTOS ist es einfacher, zwischen nebenläufigen Tasks zu kommunizieren und zu synchronisieren? Genau da nimmt ein RTOS einem doch vieles ab. Bei seinen Themen hat er ohne RTOS dieselben Probleme, und muß sie selbst lösen. (Ganz abgesehen davon könnte man alle seine Konzepte auch am PC lernen... Aber auch da wird er wissen, ob er einen Controller nimmt oder nicht.)
Klaus W. schrieb: > Und ohne ein RTOS ist es einfacher, zwischen nebenläufigen Tasks zu > kommunizieren und zu synchronisieren? > Genau da nimmt ein RTOS einem doch vieles ab. Genaugenommen: nein. Ein RTOS nimmt nur dann den Leuten das Denken ab, wenn diese Leute nur geradeaus nach PAP programmieren können. Dann müssen sie nämlich für jede Teilaufgabe auf das Auftreten von Konditionen warten und deshalb wird das dann so gelöst, daß das OS die Rechenzeit aufteilt und der wartende Thread nicht den gesamten µC blockiert. Und genau DA will vermutlich der TO etwas dazulernen, also wie man z.B. blockierendes Geradeaus-Programmieren eben nicht tut, sondern die Angelegenheit anders handhabt. Eben das Lernen von Algorithmen und Herangehensweisen. Und wenn es um das Abnehmen von Denkleistungen geht, dann wäre das Engagieren eines geeigneten Ingenieurbüros der konsequentere Weg. Aber da lernt man fachlich eher nix dazu. Allenfalls betriebswirtschaftlich. W.S.
Peter D. schrieb: > Es ist sehr schwer, große RTOS Projekte stabil und zuverlässig zum > Laufen zu bringen Ein RTOS ist nicht die Lösung aller Probleme aber das ist völliger Unsinn. Es ist überhaupt nicht schwer wenn man das Design richtig macht, genauso wie bei einem großen Programm ohne RTOS. Das Design muss passen. Klaus W. schrieb: > Und ohne ein RTOS ist es einfacher, zwischen nebenläufigen Tasks zu > kommunizieren und zu synchronisieren? > Genau da nimmt ein RTOS einem doch vieles ab. Genau so sieht es aus.
:
Bearbeitet durch User
Peter D. schrieb: > Es ist sehr schwer, große RTOS Projekte stabil und zuverlässig zum > Laufen zu bringen. Oft nimmt man daher sehr viel Ressourcen, so daß > alles weit unter Maximallast läuft und Konfliktsituationen möglichst > selten auftreten. 100 Tasks sind kein Problem, wenn es 100 unabhängige Aufgaben sind. Du meinst vielleicht, wenn man anfängt, auch die Prozesssteuerung (aus einer oder mehreren Loops mit 100 Modulen) in (Event-Driven) Tasks aufzudröseln. Ja, das geht regelmäßig schief.
RTOS verwenden ist nicht die Lösung, aber die Vorraussetzung um an gute Firmware zu kommen. Leitfaden für gute Embedded Firmware: keine globale Variablen keine Annahme machen, wie lange eine Subroutine braucht (Takte zählen, usw..) sondern die verfügbare Rechenleistung durch RTOS verteilen zeitkritische Ereignisse/Datenströme werden über entsprechend der Anforderung in je einem Task abgearbeitet und in das Queuesystem eingeleitet. atomare Funktionen erstellen, die in einem Task laufen Tasks kommunizieren über Queues miteinender (separate Queues für Daten und Kommandos), niemals über Variablen wenn man den Kommando-/Datenfluss der Firmware nicht korrekt auf einem Whiteboard wiedergeben kann hat man kein tragfähiges Konzept bzw. SW Architektur die Firmware hat eine Test-/Debug Schnittstelle, der Test Stimulus/die Testschnittstelle ist der/die gleiche wie für den "Normalbetrieb" die Firmware hat integrierte Benchmarkfunktionen manche goto; und CppCon Videos auf YT sind ganz interessant, viele aber nicht. Um Gold zu finden muss man im Dreck wühlen. Gilt auch für Bücher. Zu Foren hat sich ja wahrscheinlich jeder selbst ein Bild gemacht.
drm schrieb: > RTOS verwenden ist nicht die Lösung, aber die Vorraussetzung um an gute > Firmware zu kommen. Selber schreiben gehört wohl nicht zu deinen Optionen? Naja, und deine seltsamen Regeln kommen mir auch fischig vor. Globale Variablen sind nichts, was es zu vermeiden gilt. Wie stellst du dir denn sonst die Speicherung von Daten vor, die eben nicht nur temporäres Zeug von Fuknktionen sind? Globale Variablen, die man mit einem 'static' versieht? Nee, die sind auch bloß global, aber das sind C-spezifische Angelegenheiten. Die einzige sonstige Variante wäre das Einrichten eines Heaps, aber dann hat man wiederum das Problem, die Zeiger auf dortige Variablen zu speichern. W.S.
>Selber schreiben gehört wohl nicht zu deinen Optionen? Wenn die Aufgabe nicht lautet das Rad neu zu erfinden, dann tue ich das auch nicht. >Globale Variablen, die man mit einem 'static' versieht? Bitte die Funktionsweise von static verstehen bevor man darüber redet. static sorgt dafür das eine Variable bei dem erneuen Aufruf einer Funktion nicht neu initialisiert wird sondern der Wert beim Verlassen der Funktion erhalten bleibt. Ein RTOS Task gibt aber seine Ressourcen nicht frei wenn der Task Manager zu einem anderen Task wechselt im Gegensatz zu einer Funktion, darum kann man im Task Daten "dauerhaft" vorhalten. >Wie stellst du dir denn sonst die Speicherung von Daten vor, >die eben nicht nur temporäres Zeug von Funktionen sind? Die C++ Gemeinde hat da getter + setter Funktionen für die Kapselung von Daten. Aber was wissen die schon ... Daran angelehnt kann man mit C + RTOS einem Task eine Abfrage stellen, der dann den Antwortwert zurückgibt. Um diesen Wert aktuell zu halten ist dann die Aufgabe des Tasks. Z.B. durch das setzen des Werts durch die Zuweisung eines anderen Tasks oder durch Einlesen von der Hardware, wie ADC, GPIIO, usw. Es soll auch nichtflüchtigen Speicher geben, der Daten vorhält, sogar nach einem Powercycle. Aber was weiss ich schon. Womöglich gibt es dann noch einen Task, der sich um die Verwaltung der Daten kümmert und sie strukturiert im nichtflüchtigen Speicher ablegt. Diese Daten könnten dann gezielt abgefragt werden. Klingt verrückt, oder ? Für die anderen Verrückten: C++ Klasse reserviert Speicher für Daten und Code, wird bei Bedarf dynamisch oder statisch verwendet. C + RTOS Tasks und Queues werden für Code und Daten verwendet, wird bei Bedarf dynamisch oder statisch verwendet. @W.S.: du bist in diesem Thread gut aufgehoben, es gibt für dich hier noch viel zu lernen.
als kleiner Einblick: https://techtutorialsx.com/2017/09/13/esp32-arduino-communication-between-tasks-using-freertos-queues/ Der ESP32 in Arduino ist der ideale Einstieg für RTOS und Multitasking + Multithreading, da der ESP32 ja 2 CPU Kerne hat.
oder für den TO mit STM32: https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/FreeRTOS_on_STM32_MOOC.html
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.