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,
:
Verschoben durch Moderator
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!
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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. ;-)
Ach ja, viele werden das sicherlich schon kennen, aber für den Rest, und da Freitag ist: "how to write unmaintainable code" https://github.com/Droogans/unmaintainable-code
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.