Suche Literatur für strukturierte Embedded Programmierung

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.

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.

Hi,
hier mein Lieblingsbuch zu dem Thema:

https://www.safetty.net/publications/pttes

Gruß

> 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.

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.

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:
> 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. 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