Hallo zusammen,
bin wohl einer der älteren Leser hier im Forum (Ü50) und habe daher eine
Frage, im weitesten Sinne zur (Aus-) Weiterbildung. Großgeworden bin ich
mit einer Lehre und einer Technikerausbildung im Elektronikbereich, als
der PC noch in den Kinderschuhen steckte. In meiner beruflichen Laufbahn
habe ich gefühlte fünfzig Mikrocontrollersysteme (8051, NEC Prozessoren,
R8C, ATMEL) mitentwickelt und war dabei neben der Hardware auch für die
Software verantwortlich. Das waren aber alles Projekte in denen die
Software ein, ich nenne es einmal, einfaches, überschaubares Programm
benötigte (while (1)) und war im weitesten Sinne in der
Steuerungstechnik angesiedelt. Die Software wurde anfänglich in
Assembler die letzten 20 Jahre in C geschrieben und bewegte sich im
Umfang so bis 100 kB. Zwischenzeitlich wird dies aber wie ich meine viel
Komplizierter und Informatik orientiert und mir fehlen schlichtweg die
Basics. Ohne Betriebssystem läuft selbst bei einfachsten Anwendungen
nichts mehr, die Software ist durch Schichtenmodelle und Layer
gekennzeichnet und noch vieles mehr, was mir letztendlich wie böhmische
Dörfer vorkommt. Wenn ich die Aufgabe auf die bisherige Weise lösen
dürfe, dann wäre auch dafür weiterhin nur 20-30k C-Code notwendig, aber
das ist heute einfach nicht mehr angesagt und die Programme benötigen
mehrere 100kB. Das führt dazu, dass ich im Moment Teilaufgaben
programmiere, der Gesamtzusammenhang aber auf der Strecke bleibt. Wenn
ich in Fachzeitschriften etwas lese, dann bleibt auch da vieles unklar
und es gelingt mir eben nicht daraus ein tragfähiges know how Fundament
zu erarbeiten. Gibt es vielleicht ein Buch, Skript oder sonst etwas wo
man sich die Grundlagen der heutigen Softwaretechnik erarbeiten kann?
Habe den Eindruckt, dass ich da gerade gewaltig den Anschluss verpasse.
Hoffe nicht, dass der Zug schon ganz abgefahren ist,
Wenn du verstehen moechtest, warum man heute sehr viele
Layer/Abstraktionsschichten in die Software einzieht, dann kann ich dir
das Buch "Clean Code" empfehlen.
https://www.amazon.de/Clean-Code-Refactoring-Patterns-Techniken/dp/3826655486/
Das Buch zielt zwar mehr auf Java ab, das macht aber nichts.
Am Ende musst du nur in der Lage sein 2 Quelltexte (vorher und nachher)
miteinander zu vergleichen, und fuer dich bestimmen koennen, ob das neue
lesbarer ist als das alte.
Am Anfang erschliesst es sich nicht unbedingt, warum man jeden
Firlefanz in eine eigene kleine Funktion verpacken sollte. Lies das
Buch, und wenn du wirklich offen fuer was neues bist, dann wirst du
recht schnell verstehen, weshalb man heute so viele Layer in der
Software hat.
Voraussetzung fuer das Verstehen ist aber, das du wirklich offen bist.
Wenn du jetzt schon Vorurteile hast, von wegen
"Ist doch alles Bloedsinn, hat schon immer so funktioniert!", dann wird
das ein erfolgloses unterfangen.
Auch Buecher/Artikel/etc. zum Thema "Unit Testing" und "Test Driven
Development" (TDD) koennen hilfreich sein, um zu verstehen weshalb man
heute gewisse Dinge so macht, wie man sie macht.
Bei meinem alten Arbeitgeber gibt es Code, da sind einzelne Funktionen
teilweise 1.000 Zeilen lang. Natuerlich kann man so programmieren,
funktioniert auch, aber schoen ist das nicht. Das ist fuer neue
Mitarbeiter weder lesbar noch wartbar.
Da haetten Schulungen zu Themen wie Refactoring, Unit Testing, Clean
Code, etc. dringend not getan, aber die "Alten", die seit > 20 Jahren in
der Firma sind wehren sich halt gegen diesen "neumodischen
schnickschnack".
Potenziell entsteht durch heutige Techniken mehr Code (aufgrund der
ganzen Abstraktionsschichten), aber es sind (wenn es richtig gemacht
wird) viele kleine Codehaeppchen, die viel besser greifbar sind, und
dadurch auch leichter zu verstehen und leichter zu warten sind.
Ich wuensche dir viel Erfolg, auf das Du den Zug wieder einholst!
Hallo Michael,
Ich habe vor 2 Monaten ein Buch auf den Markt gebracht, das auf dem
Stand "RTOS als Grundlage, Netzwerk- und Dateisystemmiddleware und den
Rest per Hand dazu gebaut oder aus speziell für Embedded zugeschnittenen
Softwarebasen dazu gekauft oder adaptiert" aufsetzt
(http://www.springer.com/de/book/9783658148492). Nach Besten Wissen und
Gewissen ist das der in meinem Wirkungskreis aktuelle Stand der Technik,
zumindestens im Industrial Bereich.
Allerdings wirst Du feststellen, das es auf dem Markt eine extrem
agressiv propagierte "Gegenwelt" gibt, in der Entwicklung für Embedded
nicht mehr von PC/Tablet/Mobil Entwicklung unterscheidbar ist. In dieser
Welt bestehen Embedded Systeme aus Standardbauteilen (so nach dem Motto
Hardware auf Arduino Basis mit Herstellergelieferten BSPs,
Betriebssystem Linux oder Android, sämtliche Kommunikationsinterfaces
auf SSL oder SSH basierend), und der Rest kann in Java programmiert
werden.
Ich vermute, dass sich so in spätestens 5 Jahren herausgestellt hat, wie
stark diese Gegenwelt zur Realität wird (bis dahin kommst Du mit RTOS
und co noch recht weit). Meiner Einschätzung nach wird sich die Embedded
Welt weiter in zwei Unterwelten aufspalten; überall dort, wo
Ressourenschonung, Echtzeit- und Stabilitätsanforderungen im kritischen
Pfad liegen und HMIs keine primäre Rolle spielen, werden sich
RTOS-basierte Systeme noch eine zeitlang halten können, aber der Rest
wird in der High Level Welt aufgehen. Viel wird auch davon abhängen, wie
stark der Preisverfall in der Hardware von Statten geht, also ob es sich
lohnt, eine massgeschneiderte Hardware für die Anforderung zu entwickeln
statt auf Masse von der Stange zuzukaufen.
Zweifellos wird nichtsdestotrotz auch die "Nischenwelt" in Richtung
Standardisierung gehen, vor Allem was Kommunikationsinterfaces angeht.
Entwicklungskosten SIND zu hoch, Time-To-Market Zeiten auch, und
Interoperabilität wird zunehmend zum Killerkriterium.
Es ist extrem schwierig, den pasenden Einstieg zu finden, weil sich zur
Zeit enorm viel auf dem Markt tut und m.M. nach eine grosse Schere
zwischen Marketingvisionen und dem wirklichen Leben in den
Entwicklungsetagen besteht. Wenn Du nach dem Buch- und
Fachartikelangebot gehst, magst Du auch den Eindruck bekommen, dass ohne
Modellierungswerkzeuge nichts mehr geht, aber das scheint mir extrem
übertrieben.
Ich würde Dir empfehlen, zu Fachtagungen und Kongressen wie der Embedded
World zu gehen, Dir Vorträge von case studies und wirklichen
Entwicklungsfirmen mit echten Produkten anzuhören (Werbevorträge von
Supplier Firmen sind meistens Zeitverschwendung) und danach mit den
Vortragenden ins Gespräch zu kommen bzw. Dir genau anzuhören, welche
Fragen an die Vortragenden gerichtet werden.
Viel Glück!
Michael schrieb:> bin wohl einer der älteren Leser hier im Forum (Ü50) und habe daher eine> Frage, im weitesten Sinne zur (Aus-) Weiterbildung.
Laß dich nicht irre machen von Leuten, die immerzu nur "höher, weiter,
und mehr Bässe" predigen. Das ist zum Teil Selbstdarstellung und zum
Teil heiße Luft. Oder jemand will Tantiemen für völlig überteuerte
Bücher, von denen es in den letzten 30 Jahren schon zuviel gegeben hat
-> Makulatur.
Guck lieber mal, wie sich die Verkaufszahlen von µC darstellen. Da gibt
es massenhaft Chips, die mit Flash-Speicher bis zu 64 K daherkommen, ein
Großteil hat nicht mal so viel - und diese Chips tun ihren Dienst in
ganz vielen Anwendungen.
Es wird also durchaus nicht mit Tablets, Java, Betriebssystemen, RTOS
und dergleichen um sich geworfen, sondern die tagtägliche Realität sieht
weitaus bescheidener und biederer aus.
Bei den heutigen Chips sieht das so aus, daß bei deren Firmware ein
großer Teil eben in C geschrieben wird (weil es kaum was anderes mehr
gibt) und nur noch recht kleine Systeme komplett in Assembler sind
(Beispiele: ganz kleine PIC's, auch ich bin da eher
Assembler-Programmierer, aber das beschränkt sich eben auf kleines Zeug
und Details bei größerem Zeug).
Michael schrieb:> Ohne Betriebssystem läuft selbst bei einfachsten Anwendungen> nichts mehr, die Software ist durch Schichtenmodelle und Layer> gekennzeichnet
Das kann ich wirklich NICHT bestätigen. Mag sein, daß es bei deinem
Arbeitsumfeld so ist, aber das gilt nicht allgemein.
Eines predige ich aber den Leuten ständig: Zerteilt eure Firmware
sorgfältig in hardwareunabhängige Teile und hardwareabhängige
Low-Level-Treiber. Das schafft einem auf lange Sicht die besten
Konditionen (Übersichtlichkeit, Portabilität usw.).
W.S.
Kaj G. schrieb:> Bei meinem alten Arbeitgeber gibt es Code, da sind einzelne Funktionen> teilweise 1.000 Zeilen lang. Natuerlich kann man so programmieren,> funktioniert auch, aber schoen ist das nicht. Das ist fuer neue> Mitarbeiter weder lesbar noch wartbar.> Da haetten Schulungen zu Themen wie Refactoring, Unit Testing, Clean> Code, etc. dringend not getan, aber die "Alten", die seit > 20 Jahren in> der Firma sind wehren sich halt gegen diesen "neumodischen> schnickschnack".
Extrem kurze Funktionen sind nicht unbedingt übersichtlicher. Wenn in
der Funktion dann nichts weiter als der Aufruf einer anderen Funktion -
möglichst noch in einer anderen Sourcedatei - steht, dann ist es mit der
Übersichtlichkeit schnell vorbei. Wenn ich mich, um zum Kern des Pudels
zu kommen durch ein Dutzend Dateien hangeln muß, dann ist das nicht mehr
übersichtlich und auch nicht gut zu warten.
Ich muß mich gerade mit einem Vertreter dieser ultrakurzen Funktionen
herumschlagen und das macht wirklich keinen Spaß. Selbst derjenige der
es verzapft hat mittlerweile Schwierigkeiten sich da durch zu finden.
Kaj G. schrieb:> dann kann ich dir> das Buch "Clean Code" empfehlen.
Das Buch ist nicht schlecht. Aber vieles darin sind Binsenweisheiten,
die ein langjähriger Programmierer schon selber erfahren haben sollte.
Einem Anfänger wiederum könnte es schwerfallen, sie einzusehen.
Michael schrieb:> Wenn> ich in Fachzeitschriften etwas lese,
was gibt es denn noch an Fachzeitschriften die ernst zu nehmen sind?
Der Zeitschriftenmarkt ist doch im Laufe der letzten 10 Jahre ganz
kräftig zusammengeschrumpft und in die Qualität gesunken.
Wo früher noch echte Produkttests gemacht wurden, wird heute von nem
externen Redakteur im besten Fall mal kurz drübergeschaut, meist eher
aus Handbuch und Datenblatt abgeschrieben.
Oder dann werden irgendwelche neuen Entwicklungsmethoden beschrieben,
aber von Leuten die die ganz toll finden, dafür bezahlt werden oder sie
gar mitentwickelt haben. Ein ehrlicher Vergleich zu klassischen oder
konkurrierenden Methoden fehlt dann oft.
Herzlichen Dank für Eure Infos und Ausführungen. Sie spiegeln recht
genau mein Empfinden/Problem wieder.
Danke für die beiden Büchertipps. Genau so etwas habe ich gesucht und
werde damit die Sache versuchen anzugehen.
Herzlichen Dank
Kaj G. schrieb:> Potenziell entsteht durch heutige Techniken mehr Code (aufgrund der> ganzen Abstraktionsschichten), aber es sind (wenn es richtig gemacht> wird) viele kleine Codehaeppchen, die viel besser greifbar sind, und> dadurch auch leichter zu verstehen und leichter zu warten sind.
Was aber bei jedem Call ein Lookup in der vtable braucht. Für High
Performance Software nicht brauchbar.
Für die Wartung auch nicht wirklich. Man muss sich durch den Code surfen
und debuggen.
Es gibt keine All-in-one Lösung.
Grüsse,
René
Ruediger A. schrieb:> Ich vermute, dass sich so in spätestens 5 Jahren herausgestellt hat, wie> stark diese Gegenwelt zur Realität wird (bis dahin kommst Du mit RTOS> und co noch recht weit). Meiner Einschätzung nach wird sich die Embedded> Welt weiter in zwei Unterwelten aufspalten; überall dort, wo> Ressourenschonung, Echtzeit- und Stabilitätsanforderungen im kritischen> Pfad liegen und HMIs keine primäre Rolle spielen, werden sich> RTOS-basierte Systeme noch eine zeitlang halten können, aber der Rest> wird in der High Level Welt aufgehen. Viel wird auch davon abhängen, wie> stark der Preisverfall in der Hardware von Statten geht, also ob es sich> lohnt, eine massgeschneiderte Hardware für die Anforderung zu entwickeln> statt auf Masse von der Stange zuzukaufen.
Bei der Aufspaltung stimme ich Dir zu. Wo man früher für Highlevel einen
ganzen Steuer-PC hätte hinstellen müssen, tut es heute ein kleines
Prozessormodul. Damit vereinfacht man sich die Entwicklung, sobald es um
eher hardwareferne Probleme geht. Da muss man sich jetzt nicht mehr ins
Korsett "kleiner µC" zwängen, sondern kann nen kräftigeren
Embedded-Prozessor mit z.B. Linux nehmen.
Aber es gibt dennoch massenweise Stellen, an denen nur ganz einfache
Programmlogik benötigt wird. Status-LED, Taster, Sensor und Relais etc.
Da ein Embedded-Linux für zu nehmen dürfte auch in Zukunft mehr Aufwand
als andere Lösungen erfordern. Denn da brauchst Du erst mal nen Treiber
für jeden Deiner Peripherie-ICs, musst die per DeviceTree oder UEFI
einhängen, und dann muss Dein eigentliches Programm die
Kernelschnittstelle ansprechen.
Im Upstream-Kernel können sich nur einigermaßen allgemeine
Schnittstellen durchsetzen, es gibt da nicht für jeden IC
Sonderlösungen. Das heißt es sind unter Umständen erst mal nicht alle
Features jedes IC direkt ansprechbar. Da muss man dann wieder selber
entwickeln, patchen,...
Auch wenn ein Hersteller da eine Lösung "aus einem Guss" anbietet,
dieses Problem wird nicht einfach so verschwinden oder gelöst werden
können.
Eine µC-Lösung, klassisch mit einer Main-Loop und Statemachine, sowie
nem fertigen HAL um z.B. die I2c-Hardware anzusteuern, ist da schneller
entwickelt. Und gleichzeitig auch noch billiger und braucht weniger
Platz. Das wird garantiert auch in 5 Jahren noch so sein.
Wenn man möchte kann man natürlich auch nen RTOS auf dem µC dafür
verwenden. Das läuft auch schon auf nem kleinen Atmega wenn man möchte.
Aber die zusätzliche Komplexität des RTOS lohnt sich erst ab nem
bestimmten Level an Komplexität und Anforderungen der Aufgabe.
Die ganzen nebenläufigen Threads, Messages und Locks im RTOS können ganz
eigene Gruppen von Problemen hervorbringen. Ein erfahrener Entwickler
holt sich die nicht ins Projekt nur weil das jetzt "in" ist und er ein
paar neue Buzzwords für sein Projekt braucht, sondern weil die Aufgabe
das RTOS erfordert oder vereinfacht.
Ich sehe daher Rüdigers "RTOS-basierte Systeme noch eine zeitlang halten
können" etwas anders: µC-Systeme mit und ohne RTOS wird es noch sehr
lange geben. Genauso wie Embedded-Linux-Systeme.
Heißt halt für den Embedded-Entwickler daß er noch mehr verschiedene
Systeme beherrschen muss oder eine noch weitere Spezialisierung
gefordert wird.
Zeno schrieb:> Extrem kurze Funktionen sind nicht unbedingt übersichtlicher.
Früher hatte man nicht so die Ressourcen für viele Schichten, das führte
zu Spaghetti-Chaos. Heute hat man die Ressourcen, das führt zu
Lasagne-Chaos.
Michael schrieb:> Das führt dazu, dass ich im Moment Teilaufgaben> programmiere, der Gesamtzusammenhang aber auf der> Strecke bleibt. Wenn ich in Fachzeitschriften etwas> lese, dann bleibt auch da vieles unklar und es> gelingt mir eben nicht daraus ein tragfähiges> know how Fundament zu erarbeiten.
Hmm.
Kennst Du Dich mit objektorientierter Programmierung aus?
Es gab schon lange eine aufteilung in User Interface und
Prozesssteuerung. Manche haben sie noch auf demselben Device gemacht.
Heutzutage, falls das Userinterface besser daherkommen muss nimmt man
dafuer ein Tablet, Aber eine Prozesssteuerung muss auf einem einfachen
Controller laufen.
Sonst kriegt man den Code nie sicher und zuverlaessig. Es gibt
Anwendungen, die muessen zuverlaessig laufen. 24/7, ohne Unterbruch. Das
geht auch mit fehlerfreiem Code. Nur darf der eben nicht zu gross sein.
Und er muss uebersichtlich sein. Also nix mit OS, nix mit GUI.
Gerd E. schrieb:>> Die ganzen nebenläufigen Threads, Messages und Locks im RTOS können ganz> eigene Gruppen von Problemen hervorbringen. Ein erfahrener Entwickler> holt sich die nicht ins Projekt nur weil das jetzt "in" ist und er ein> paar neue Buzzwords für sein Projekt braucht, sondern weil die Aufgabe> das RTOS erfordert oder vereinfacht.>
100% ACK. Mein Mantra ist, dass man kein Vakuumschweissgerät braucht, wo
eine Briefklammer reicht, aber umgekehrt auch nicht versuchen sollte,
mit einem Aldi Phasenprüfer eine Zylinderkopfdichtung zu wechseln. Zu
jeder Aufgabe das passende Werkzeug!
Ich widme dem Thema "Warum und wann RTOS?" auch einen Abschnitt in ...
Wie Du richtig schreibst, gibt es legitime Anwendungsfälle ohne RTOS.
> Ich sehe daher Rüdigers "RTOS-basierte Systeme noch eine zeitlang halten> können" etwas anders: µC-Systeme mit und ohne RTOS wird es noch sehr> lange geben. Genauso wie Embedded-Linux-Systeme.>
Das würde ich selber sehr begrüßen, da ich aus verschiedenen Gründen mit
der Welt "unter dem Deckel" wärmer bin als darüber. Allerdings werden es
nicht nur technische Gründe sein, die die Entwicklung bestimmen. Wenn
sich z.B. das Modell "Daten sind die Währung der Zukunft" durchsetzt,
werden wir auch in baldiger Zukunft Android-basierte (also mit H-Bomben
auf Spatzen schiessende) Stromzähler ins Haus kriegen, für die wir oder
der Energieversorger nicht mit Geld zahlen, dafür aber in Kauf nehmen,
dass alle Verbrauchsdaten auch gleich in die Cloud mitgehen. Und
umgekehrt wird natürlich auch die Hardware um so billiger, je mehr
Hosenknöpfe damit ausgestattet werden, also könnte dann in einer Spirale
immer mehr Android/Jave basierte HW den Markt penetrieren (abgesehen von
Anwendungen, wo es technisch nicht geht, z.B. aus
Stabilitätsanforderungs-,Stromverbrauchs- oder
Wärmeentwichlungsgründen).
Ausser es finden sich genügend Verbraucher, die das nicht wollen. Liegt
an Jedem Einzelnen, das als gottgegeben anzunehmen oder jetzt
gegenzusteuern, bevor es zu spät ist...
> Heißt halt für den Embedded-Entwickler daß er noch mehr verschiedene> Systeme beherrschen muss oder eine noch weitere Spezialisierung> gefordert wird.
Ich vermute eher, dass deine zweite angedeutete Möglichkeit eintreffen
wird (eine stärkere Ausdifferenzierung). Ich kann mir Wenige Leute
vorstellen, die nebenläufig an Android- und QMX basierten Systemen
arbeiten (die Idee hinter der Javaisierung der Embedded Welt ist ja u.A.
gerade, dass man an Systemarchitekturen nicht interessierte
Anwendungsentwickler daran lassen kann).
Hallo, an den Basics kann es schwer fehlen wenn du bereits jede Menge
uC's und Assebler und C programmiert hast.
Aber es stimmt ich kenne auch Programmierer denen dann doch etwas in
Informatik fehlt zB objektorientiertes Programmieren und funktionale
Programmiersprachen. Wo genau jetzt dein Problem liegt kann ich auch
nicht sagen und wenn du auch uC's programmierst dann ist der Umfang ja
noch nicht so groß. Bezüglich Betriebssystem, ja die werden notwendig da
Nebenläufigkeit sonst nur mit Statemaschinen und Eventhandlern
realisiert werden kann, dabei hat man aber keinen Codefluss.
Auch auf uC's wird zb FreeRTOS, CibiOS verwendet. Das Problem sehe ich
eher das alle selber herumstricken, fast alle Firmen machen die selbe
Scheiße doppelt und eher schlecht als recht, anstatt das man sich
zusammentut und eine solide Basis erarbeitet wird halt herumgebastelt.
Im Prinzip hätten die meisten Firmen a kein Interesse die Grundlagen zu
Programmieren sondern einte funktionierenen Basis würde jede Menge
Arbeit und Ärger ersparen.
Das was eine Firma interessiert ist doch die Anwendungssoftware.
Problematisch ist meistens das halt viele verschiedene Faktoren
zusammenkommen und so jeder selber bastelt.
Also das Problem ist nicht die Abstraktion, die ist notwendig und damit
solltest du dich beschäftigen.
Fange an mit Multitasking, zB the XINU Abroach und verwende mal ein
RTOS.
Dann lerne objektorientiert zu Denken, nur so kann Software strukturiert
werden die dann im nach hinein auch noch geändert werden kann,
verschachtelte Statemachinen und switch cases über zig tausend Zeilen
Code sind unwartbar und führen eben dazu das man den Code nicht mehr
versteht sondern sich nur mehr einen case heraus nimmt und da was
ändert.
Nur das Problem fängt ja schon bei Kommunikation der Menschen an.
Auf jeden Fall empfehle ich dir dich auch mit Linux und open source zu
beschäftigen und für objektorientiertes Programmieren ist Java ganz gut
zum Lernen. Die Basics hst du damit solltest du in der Lage sein dir
alle Anderen Themen selber beizubringen und das Internet ist sehr
hilfreich dabei.
LG
Possetitjel schrieb:> Hmm.> Kennst Du Dich mit objektorientierter Programmierung aus?
Das gleiche hab ich mir auch schon gedacht. Wenn er im ganzen
Berufsleben nur auf Mikrocontrollern ohne Betriebssystem gearbeitet hat,
kann es gut sein, dass er mit Objektorientierung nie wirklich in
Beruehrung gekommen ist. In diesem Fall wuerde ich als Training ein
groesseres GUI-Projekt auf dem PC vorschlagen. Das zwingt einen zur
Abstrahierung und zur Objektorientierung. Learning by Doing ist
immernoch am Effektivsten.
Ist natuerlich eine groessere zeitliche Investition, aber er scheint ja
motiviert zu sein.
Auch wenn OOP in seinem Bereich nicht angewand wird, zeigen seine
Beschreibungen, dass die eingesetzten Methodiken doch in Richtung
PC-Programmierung gehen.
>>Possetitjel schrieb:>> Hmm.>> Kennst Du Dich mit objektorientierter Programmierung aus?>Das gleiche hab ich mir auch schon gedacht. Wenn er im ganzen>Berufsleben nur auf Mikrocontrollern ohne Betriebssystem gearbeitet hat,>kann es gut sein, dass er mit Objektorientierung nie wirklich in>Beruehrung gekommen ist.
So ist es.
>In diesem Fall wuerde ich als Training ein>groesseres GUI-Projekt auf dem PC vorschlagen. Das zwingt einen zur>Abstrahierung und zur Objektorientierung. Learning by Doing ist>immernoch am Effektivsten.
Diesen Spagat von PC auf Mikrocontroller stelle ich mir jetzt auch nicht
so einfach vor, zumal ich noch nie eine richtige Software für PCs
erstellt habe.
Habe jetzt aus Euren ganzen Antworten doch schon einiges entnehmen
können, wenn ich auch nicht alles genau einordnen kann. Herzlichen Dank.
Objektorientiert Programmierung scheint aber der erste Schlüssel zu
sein. Da müsste/könnte ich mich mit C++ probieren, richtig? Da könnte
ich mir Unterstützung besorgen. Irgendwie gefallen mir die beiden
anfangs genannten Bücher auch ganz gut? Denke, da kann ich nicht viel
falsch machen, wenn ich mir die zulege und durcharbeite, wobei mir das
Embedded Controller Buch vom Asche gefühlt näher liegt, da es vielleicht
näher an den Mikrocontrollern ist.
>> Habe jetzt aus Euren ganzen Antworten doch schon einiges entnehmen> können, wenn ich auch nicht alles genau einordnen kann. Herzlichen Dank.> Objektorientiert Programmierung scheint aber der erste Schlüssel zu> sein. Da müsste/könnte ich mich mit C++ probieren, richtig? Da könnte> ich mir Unterstützung besorgen. Irgendwie gefallen mir die beiden> anfangs genannten Bücher auch ganz gut? Denke, da kann ich nicht viel> falsch machen, wenn ich mir die zulege und durcharbeite, wobei mir das> Embedded Controller Buch vom Asche gefühlt näher liegt, da es vielleicht> näher an den Mikrocontrollern ist.
Würde mich natürlich riesig freuen, wenn es Dir hilft... Du kannst ja
mal in Leseproben reinschnuppern:
https://books.google.de/books?id=8ra8DQAAQBAJ
Ausserdem gibt es auf der Anfangs erwähnten Seite von Springer unter
"Zusatzmaterialien" völlig offen die zugehörigen Beispielapplikationen
zum Herunterladen. Kannst auch gerne per PM Fragen stellen!
Herbärt schrieb:> Aber es stimmt ich kenne auch Programmierer denen dann doch etwas in> Informatik fehlt zB objektorientiertes Programmieren
Was auf µCs im Wesentlichen "C mit Klassen" heißt, weil sehr viel mehr
kaum umsetzbar ist.
> und funktionale Programmiersprachen.
Auf µCs?! Äußerst unwahrscheinlich. Funktionale Programmiersprachen sind
zwar derzeit in Szenekreisen gehyped, an Unis seit jeher beliebt, aber
die typischen embedded-Anwendungen drehen sich exakt um die Manipulation
von Zuständen.
Allein schon z.B. sowas wie ADC-Einangswerte sind zustandsbehaftet, und
zwar mit dem, was draußen passiert. Der DAC-Ausgang ist in sich
ebenfalls schon ein Zustand.
> Bezüglich Betriebssystem, ja die werden notwendig da> Nebenläufigkeit sonst nur mit Statemaschinen und Eventhandlern> realisiert werden kann, dabei hat man aber keinen Codefluss.
Doch, hat man - schwierig wird aber alles, was blockiert. Man kann da
auch ohne RTOS-Wait herumprogrammieren, aber es wird unangenehmer.
Spätestens, wenn die Anforderung lautet, daß das Ding IP sprechen soll
und auch noch einen embedded Webserver haben soll, ist das Ende der
Fahnenstange erreicht. Das will man nicht mehr selber zusammenstricken.
> Dann lerne objektorientiert zu Denken, nur so kann Software strukturiert> werden die dann im nach hinein auch noch geändert werden kann,
Das ist völliger Unsinn. Wurde vor 20 Jahren mal vertreten, als OOP die
"magic silver bullet" war, aber Fakt ist, daß sich das nicht
bewahrheitet hat. Man kann sowohl prozedural als auch OOP gut wartbaren
Code schreiben.
Allerdings ergibt OOP Sinn, wenn es um Dinge geht, die sich als Objekte
wirklich gut modellieren lassen, besonders GUIs und Simulationen (da
kommt OOP ja her). Nur, das Mantra "OOP ist das einzig Wahre" ist
Unsinn.
> verschachtelte Statemachinen und switch cases über zig tausend Zeilen> Code sind unwartbar
Zigtausende Objekte, die alle irgendwie miteinander verflochten sind,
sind auch unwartbar. Was die Spaghetti in der prozeduralen
Programmierung sind, das ist Ravioli in OOP. Schlechter Code ist halt
schlechter Code, egal in welchem Paradigma, und es gibt kein Paradigma,
welches das grundsätzlich verhindern könnte.
Abgesehen davon ist der eigentliche Clou bei OOP auch nicht das, was man
heute oft darunter versteht (und was Alan Key nie gemeint hat), also
Strukturen, die Daten und Funktionen enthalten. Sondern Entitäten mit
Eigenintelligenz, die miteinander über definierte Messages
kommunizieren.
Das können beispielsweise in prozeduraler Realisierung einzelne Tasks
sein, die Inboxen und Outboxen haben und auch nur über diese
angesprochen werden. Das sind Objekte, ohne daß es was mit OOP-Sprachen
zu tun hätte. Man kann derlei im Extremfall sogar ohne RTOS machen mit
Aufrufen der Taskfunktionen aus der Hauptschleife (ohne blockierende
Operationen).
Der wesentliche Unterschied zu einer funktionsbasierten API ist hier,
daß es eben nicht Aufrufe einzelner Funktionen sind, sondern man
beliebige Aktionen sntoßen kann. Bis dahin, daß das Empfängerobjekt
aufgefordert wird, dem Senderobjekt periodisch irgendwelche Nachrichten
zu schicken. Oder auch nur auf bestimmte Ereignisse hin. Oder einmalig
nach dem request/response-Muster.
Damit kriegt man komplexe Systeme echt gut unterteilt.
> Auf jeden Fall empfehle ich dir dich auch mit Linux
Als Musterbeispiel, daß man große, langfristige Projekte nur mit OOP
hinbekommt? ;-)
> beschäftigen und für objektorientiertes Programmieren ist Java ganz gut> zum Lernen.
Würd ich eher gleich C++ nehmen, wenn es auch auf µCs mal sein soll.
Zumal, wenn man C schon kann.
Ruediger A. schrieb:>> Ich sehe daher Rüdigers "RTOS-basierte Systeme noch eine zeitlang halten>> können" etwas anders: µC-Systeme mit und ohne RTOS wird es noch sehr>> lange geben. Genauso wie Embedded-Linux-Systeme.>> Das würde ich selber sehr begrüßen, da ich aus verschiedenen Gründen mit> der Welt "unter dem Deckel" wärmer bin als darüber. Allerdings werden es> nicht nur technische Gründe sein, die die Entwicklung bestimmen. Wenn> sich z.B. das Modell "Daten sind die Währung der Zukunft" durchsetzt,
Das funktioniert nur, wenn die Daten so viel Wert sind, daß das den
Aufpreis für die dickere Hardware und deren Entwicklung überkompensiert.
Denk z.B. an ne Mirkowelle. Früher reichte da eine mechanische
Zeitschaltuhr, heute nimmt man halt nen µC weils billiger ist. In
Zukunft ersetzt man halt das Magnetron durch SiC-FETs und deren
Ansteuerung kommt in den µC mit rein.
Aber was soll ne Mikrowelle mit Internetanschluss mir bringen? Die
benutze ich nur wenn ich eh im Haus bin, wenn die nach 5 minuten fertig
ist kann sie mich problemlos durch Piepsen aus dem Nachbarraum holen.
Das ist viel einfacher als jede App.
Ist es irgendeinem Datenbroker wirklich viel wert zu wissen, wie häufig,
wann und wie lange meine Mikrowelle läuft? Da hab ich so meine Zweifel.
Wenn man an den Thermomix denkt, ist sowas bei anderen Küchengeräten
natürlich schon denkbar und manche Leute halten das auch für sinnvoll.
Aber es hat dennoch seine Grenzen.
Außerdem gibt es noch das ganze große Feld von einfachen µCs für
dedizierte (Echtzeit-)Aufgaben in an sonsten von Prozessoren,
Embedded-OS etc. dominierten Systemen.
Neulich erst meinen Fernseher repariert. Neben dem Hauptprozessor mit
Embedded-Linux gibts einen dedizierten µC auf dem Frontpanel für
Fernbedienung und Touch-Tastenfeld, einen auf dem Netzteil für die
Standby-Schaltung und noch einen weiteren auf dem Haupt-Board dessen
Zweck mir nicht sofort ersichtlich wurde. Alles kleine 8-Bitter mit
wenig Flash, höchstwahrscheinlich ohne RTOS.
Wie ich in meinem letzten Post schon ausgeführt habe, sind bestimmte
Aufgaben in einem echten Embedded-OS wie Linux komplexer umzusetzen. Die
verlagert man dann lieber in einen einfachen, billigen µC und
kommuniziert z.B. per UART mit dem. Eine solche definierte Schnittstelle
vereinfacht auch die Aufgabenteilung innerhalb des Entwicklungsteams
oder zu externen Entwicklern.
Bei sinkenden Preisen für einfache µC wird das im Vergleich zu jetzt
eher noch zunehmen.
> Ich vermute eher, dass deine zweite angedeutete Möglichkeit eintreffen> wird (eine stärkere Ausdifferenzierung). Ich kann mir Wenige Leute> vorstellen, die nebenläufig an Android- und QMX basierten Systemen> arbeiten
Du meinst QNX, oder? Das kenne ich jetzt nicht und weiß nicht wie
komplex das ist. Aber ich selbst wechsle je nach Anforderung zwischen
Bare Metal, RTOS und Linux. Und im Android-Bereich hab ich das zumindest
soweit gebändigt, gepatcht und angepasst, daß mein Smartphone auf
Cyanogenmod/Linage macht was ich will.
Genauso wie es üblich ist, daß ein ein Programmierer im Lauf seines
Arbeitslebens mit verschiedenen Programmiersprachen arbeitet, halte ich
es nicht für unrealistisch daß er auch auf verschiedenen Plattformen mit
den jeweils dort passenen Paradigmen arbeitet und zwischen denen nach
Bedarf wechselt.
Michael schrieb:> Diesen Spagat von PC auf Mikrocontroller stelle ich mir jetzt auch nicht> so einfach vor, zumal ich noch nie eine richtige Software für PCs> erstellt habe.
Dann wirds doch jetzt langsam Zeit ;-)
Nur keine Angst davor, ist auch nicht schwieriger.
Was den Spagat anbelangt sehe ich es eher so, dass die
Embedded-auf-RTOS-Entwicklung eine Mischung aus der hardwarenahen
Schiene und der Anwendungsprogrammierung ist. Wie Vanilleeis mit heissen
Himbeeren. Das Vanilleeis kannst du schon zubereiten, warum dann nicht
die heissen Himbeeren erstmal getrennt lernen? Wenn du das hast, lernst
du die Spezialitaeten in der Kombination dann nebenher. Die Boehmischen
Doerfer werden dann als Bretterverschlaege enttarnt.
> Objektorientiert Programmierung scheint aber der erste Schlüssel zu> sein. Da müsste/könnte ich mich mit C++ probieren, richtig?
Wuerde ich definitiv so sehen. Es geht aber nicht darum, nachher im
Embedded-Bereich Klassen einzusetzen, sondern eine neue Art der
Abstrahierung kennen zu lernen. Und keine Angst vor OOP, in der
GUI-Programmierung ist es ohne (Hirn-)Verrenkungen sinnvoll einsetzbar,
es schreit fast danach, und dadurch leicht zu erschliessen. Also gleich
mit GUI-Programmierung einsteigen und nicht versuchen ueber so
Konstrukte wie Klasse Tier/Saeugetier/Maus versuchen die OOP zu
verstehen.
C++ ist in deinem Fall wahrscheinlich eine gute Wahl, obwohl ich eher zu
C# oder Java tendieren wuerde.
Normalerweise bin ich der Meinung, dass man sich in seiner Freizeit
nicht fuer die Arbeit weiterbilden muss. In diesem Fall denke ich aber
lohnt es sich schon fuer dich selbst.
Peter D. schrieb:> Aber vieles darin sind Binsenweisheiten,> die ein langjähriger Programmierer schon selber erfahren haben sollte.> Einem Anfänger wiederum könnte es schwerfallen, sie einzusehen.
Einem absoluten Anfänger (Studienabgänger, weniger als 1 Jahr erfahrung,
etc.) erschliesst sich das alles tatsächlich nicht. Aber das ist der TO
ja nicht.
Aber auch erfahrene Programmierer beachten vieles davon nicht, und
denken teilweise auch nicht dran. Gerade die mit viel Erfahnunrg sehen
vieles davon nicht alleine, da viele "betriebsblind" und/oder stur
geworden sind.
"Hab ich doch schon immer so gemacht. Ich kann das alles lesen und
komme damit klar."
Beide Seiten, die Jungen und die Alten, muss man an der einen oder
anderen Stelle manchmal erst auf etwas neues stoßen, sei es auch noch so
simpel.
Ich hatte auch Kollegen, die das seit gut 20 Jahren machen, aber sich
weigern Funktionen wie memset/memcpy zu nutzen... "Da weiß ich ja nicht,
was da passiert." Vielen danke auch...
Nur weil jemand etwas lange macht, heißt das nicht, dass er gut darin
ist oder es richtig macht. Man kann auch etwas 20 Jahre lang falsch
gemacht haben, wenn es einem keiner sagt. "Hat doch schon immer so
funktioniert..."
Das Buch und dessen Inhalt als "Binsenweisheiten" abzutun finde ich
deshalb unfair. Denn das trifft auf so ziemlich jedes Buch zum Thema
Programmieren/Softwareentwicklung zu. Am Ende sind es alles "nur"
Binsenweisheite. Zum Beispiel das Thema Testing. Jeder
Softwareentwickler sollte wissen, wie wichtig es ist, Software zu testen
(z.B. durch Unittests, so dass man wiederholbare Tests hat). Und
trotzdem machen es die wenigstens, wenn sie nicht gerade mit der Pistole
auf der Brust dazu gezwungen werden.
Auch das erschließt sich einem Anfänger nicht unbedingt, jemand mit
erfahrung sollte da schon von alleine draufgekommen sein und das von
sich aus machen...
Nop schrieb:> Nur, das Mantra "OOP ist das einzig Wahre" ist Unsinn.
Jap, da kann ich nur zustimmen. Man sollte weder das eine noch das
andere verteufeln, aber auch nicht als das "einzig wahre" hinstellen.
Ich hab grad letzte Woche eine Firmware von einem ehemaligen Mitarbeiter
erweitern müssen. Sie bestand aus zwei Funktionen: Init und main. Die
main Funktion war über 3000! Zeilen lang und enthielt die gesamte Logik
in einem riesigen switch case Block mit drei oder mehr state machines
ineinander verschachtelt. Das war das Schlimmste was ich je gesehen
habe. Unwartbar.
Man selbst sieht bei so einem brainfuck vielleicht noch beim
Programmieren durch. Aber mit Sicherheit nicht mehr nach ein paar Jahren
und andere Kollegen schon gar nicht.
Ich sags immer wieder zu unseren neuen Programmierern. Programmieren
muss genau wie jedes andere Handwerk gelernt werden. Dabei muss man
nicht mal alle Details von Entwursmustern auswendig kennen. Schon ein
paar einfache Regeln helfen enorm weiter Code wartbar zu gestalten.
Und high level Programmierung mit wartbarem sauberen Code schließt sich
nicht aus mit resourcensparender Programmierung. Man muss nur wissen was
man tut. Sauberer Code kann auch in C programmiert werden.
Zeno schrieb:> Extrem kurze Funktionen sind nicht unbedingt übersichtlicher. Wenn in> der Funktion dann nichts weiter als der Aufruf einer anderen Funktion -> möglichst noch in einer anderen Sourcedatei - steht, dann ist es mit der> Übersichtlichkeit schnell vorbei.
Eine Wrapper-Funktion ist ja ein Sonderfall. Natürlich gibt es dafür
sinnvolle Anwendungsfälle, aber das heißt ja nicht dass man ständig
alles wrappen soll.
In meinem Berufsleben habe ich jedenfalls schon oft viel zu lange
Funktionen gesehen, und eher selten viel zu kurze.
Nop schrieb:> Herbärt schrieb:>> Auf jeden Fall empfehle ich dir dich auch mit Linux>> Als Musterbeispiel, daß man große, langfristige Projekte nur mit OOP> hinbekommt? ;-)
Ja. Der Linux-Kernel benutzt viele objektorientierte Entwurfsmuster,
obwohl er in C implementiert ist. Siehe dazu [1,2] und die Folgeartikel.
[1] https://lwn.net/Articles/444910/
[2] https://lwn.net/Articles/336224/
Feldstecher schrieb:> Und keine Angst vor OOP, in der> GUI-Programmierung ist es ohne (Hirn-)Verrenkungen sinnvoll einsetzbar,> es schreit fast danach, und dadurch leicht zu erschliessen.
Alternativ kann man auch mal versuchen, älteren Code zu finden, wo
GUI-Programmierung noch in reinem C gemacht worden ist. Spätestens dann
weiß man, wieso man das nicht will. BTDT.
> nicht versuchen ueber so> Konstrukte wie Klasse Tier/Saeugetier/Maus versuchen die OOP zu> verstehen.
Ja, schon deswegen, weil dieser Hierarchie-Ansatz in Lehrbüchern toll
funktioniert, aber in der Realität nicht unbedingt. In der
(Software-)Realität gibt es nämlich Katzenhunde, und Taxonomie
funktioniert oftmals nicht besonders gut.
Sheeva P. schrieb:> Der Linux-Kernel benutzt viele objektorientierte Entwurfsmuster
Das schon, und daß man structs auch mit Funktionszeigern ausrüsten kann,
ist bekannt. Dennoch ist "objektorientierte Entwurfsmuster" nur mit viel
gutem Willen als Beispiel für "objektorientierte Programmierung"
tauglich.
Sonst gäbe es nämlich kein C++.
Ruediger A. schrieb:> Ich würde Dir empfehlen, zu Fachtagungen und Kongressen wie der Embedded> World zu gehen, Dir Vorträge von case studies und wirklichen> Entwicklungsfirmen mit echten Produkten anzuhören (Werbevorträge von> Supplier Firmen sind meistens Zeitverschwendung) und danach mit den> Vortragenden ins Gespräch zu kommen bzw. Dir genau anzuhören, welche> Fragen an die Vortragenden gerichtet werden.
Konferenzen sind auf jeden Fall ein guter Tipp! Die Embedded World
Conference würde ich aber auf keinen Fall wieder besuchen. Ich war da
letztes Jahr und es war die mit Abstand schlechteste Konferenz, auf der
ich je war. Es waren fast ausschließlich Werbeveranstaltungen. Die
Vorträge haben sich zum Teil sehr stark überschnitten und die
Vortragslänge (30 Minute) war so kurz gewählt, dass eh kein tieferes
Eintauchen in die Materie möglich war.
Meine Tipps wären z.B.: Meeting C++, emBO++ und parallel
... schrieb:> Sie bestand aus zwei Funktionen: Init und main. Die> main Funktion war über 3000! Zeilen lang und enthielt die gesamte Logik
Die objektorientierte Version hierzu wäre dann das "god object" gewesen.
Idealerweise mit der kompletten Logik im Konstruktor. ;-)
