Hallo zusammen,
ich habe mal eine grundsätzliche Frage:
Ich steige ja nun so nach und nach ein in die AVR-Programmierung wie es
die Zeit zulässt. Nun ist es für mich mit dem AVR-GCC gefühlt aber sehr
aufwendig Standardaufgaben zu lösen (beispielsweise UART, DHT22,
LCD-Nutzung). Also muss man das immer selbst programmieren, oder gibt es
wie bei dem Arduino auch Libs, die man so nutzt? Mir ist schon klar,
dass gerade durch unterschiedliche Portnamen dies natürlich nicht immer
geht.
@ Gerrit (Gast)
>die Zeit zulässt. Nun ist es für mich mit dem AVR-GCC gefühlt aber sehr>aufwendig Standardaufgaben zu lösen (beispielsweise UART, DHT22,>LCD-Nutzung).
Der avr gcc hat für sowas keine Bibliotheken, das Internet schon.
Zum Thema UART und LCD (HD44780) gibt es gute Sachen von Peter Fleury.
>dass gerade durch unterschiedliche Portnamen dies natürlich nicht immer>geht.
Die Portnamen kann man bei gescheiten Libs sehr einfach auf verschiedene
Controller anpassen, der Rest bleibt wie er ist.
Falk B. schrieb:> Die Portnamen kann man bei gescheiten Libs sehr einfach auf verschiedene> Controller anpassen, der Rest bleibt wie er ist.
wobei man sagen muss, das das meist keine LIBs sind, sondern nur
Quellcode. Bei wirklichen LIBs ist das mit den Ports nicht mehr so
einfach.
Alles was Grundfunktionen betrifft und einfache Peripherie, wie USART,
selber machen. Das sind nur ein paar Zeilen und dann weiß man was
passiert, im Gegensatz zu dubiosen Bibliotheken.
Bei dem DHT22 1-Wire würde ich mir sehr intensiv Inspiration von
vorhandenen Bibliotheken und Treiber holen. Der Grund dafür ist, dass
das Protokoll ziemlich schlecht dokumentiert ist. Implementieren würde
ich allerdings was eigenes, da das Timing kritisch zu sein scheint und
man das besser schön sauber in den gesamten Zeitablauf der Anwendung
einbaut.
Für HD44780 gibt es mehr als genug fertige Bibliotheken, allerdings auch
ziemlich viele schlechte, bei denen das Timing oder die Sequenz der
Kommandos nicht stimmt oder nur für Clones funktioniert. Also sucht man
sich eine heraus und wenn man mit ihr zufrieden ist, bleibt man dabei.
Alles was komplizierter ist, wie ein IP-Stack oder USB: Da muss schon
sehr viel passieren bevor ich so etwas selber mache. Fertige Bibliothek
und Daumen Drücken.
Man merkt da schon deutlich, dass in der Elektronik eben hauptsaechlich
Elektroniker unterwegs sind und nicht Informatiker, da ist es mit dem
Softwareengineering nicht so weit her. Reusability, Libraries, Module
sind da wenig verbreitet und die Bereitschaft, das zur Verfuegung zu
stellen, auch nicht. Natuerlich gibt es Ausnahmen, aber das ist eben
nicht die Regel.
Früher wollte ich alles selbst machen. Alles was über die mitgelieferten
Bibliotheken hinaus ging. Besonders da es im C++ Bereich für
Mikrocontroller fast nichts gibt. Hab viel Zeit versenkt um mir z.B.
einen eigenen Ethernetstack halbwegs zusammen zu basteln. Aber
angesichts dessen was heute ein WIZNET oder ESP8266 Modul kostet war der
eigentliche Lohn nur noch der Lerneffekt was Netzwerkprotokolle angeht.
Heute suche ich mir Bibliotheken wo es geht. Aber die
Qualitätsunterschiede sind gigantisch - unabhängig von der Größe des
Teams / Unternehmens das die Bibs zur Verfügung steht. Häufig muss man
dann doch wieder selbst Hand anlegen, weil die Qualität oder
Portabilität mangelhaft ist. Im Sourcecode erkennt man das z.B. an der
häufig fehlenden Behandlung von Fehlerzuständen. Aber auch eine gute,
umfassende Dokumentation ist Pflicht.
Jodel schrieb:> Man merkt da schon deutlich, dass in der Elektronik eben hauptsaechlich> Elektroniker unterwegs sind und nicht Informatiker, da ist es mit dem> Softwareengineering nicht so weit her. Reusability, Libraries, Module> sind da wenig verbreitet und die Bereitschaft, das zur Verfuegung zu> stellen, auch nicht. Natuerlich gibt es Ausnahmen, aber das ist eben> nicht die Regel.
Besonders in der Arduino Community scheint sich jeder der gerade das
Arduinotutorial abgeschlossen hat, dazu berufen zu fühlen "etwas
zurückzugeben". Einerseits ist das toll, andererseits ist die Qualität
des Codes häufig unterirdisch (Fehlerbehandlung, Dokumentation ...). Man
in dem Bereich häufig lange suchen um was brauchbares zu finden.
Meistens reicht es dann doch nur zur Inspiration für eigenen Code.
Professionelle Bibliotheken fehlen leider - insbs. für C++ auf kleinen
uCs.
Zusammengefasst: Man muss ein Problem halbwegs selbst verstehen, damit
man eine gute Bibiliothek finden kann - oder sich auf die Stimmen im
Forum verlassen.
Jodel schrieb:> ... da ist es mit dem Softwareengineering nicht so weit her.> Reusability, Libraries, Module sind da wenig verbreitet
Du vergisst, das es hier oft um kleine Mikrokontroller geht. Da fehlt
dann einfach der Abstraktions-Layer oder der Speicher, um groß nach o.g.
Kriterien zu entwerfen. Klar man kann überall einen ARM Prozessor oder
größer rein bauen, aber das will man nicht immer.
Die Blüten die o.g. Vorgehensweise bei PC Softwarepaketen mit z.T. GByte
Größe treibt, funktioniert auf kleinen µC nun mal schlecht.
Tom Thomsen schrieb:> Jodel schrieb:>> ... da ist es mit dem Softwareengineering nicht so weit her.>> Reusability, Libraries, Module sind da wenig verbreitet> Du vergisst, das es hier oft um kleine Mikrokontroller geht. Da fehlt> dann einfach der Abstraktions-Layer oder der Speicher, um groß nach o.g.> Kriterien zu entwerfen.
Man kann auch klein nach diesen Kriterien entwerfen. Ich vergesse da
nichts.
Es gab hier mal interessante Diskussionen, wie man mit C++ eleganten,
wiederverwendbaren und vor allem auch effizienten Code schreiben kann.
An der Masse der Entwickler hier ging das wohl voellig vorbei. Da wird
stur weiter elegante Elektronik mit 70er-Jahre-Software verbunden.
> Die Blüten die o.g. Vorgehensweise bei PC Softwarepaketen mit z.T. GByte> Größe treibt, funktioniert auf kleinen µC nun mal schlecht.
Wir sind nicht in der Politik, es ist nicht noetig, immer gleich nach
Extremen als Argumentationshilfe zu greifen.
Jodel schrieb:> Man merkt da schon deutlich, dass in der Elektronik eben hauptsaechlich> Elektroniker unterwegs sind und nicht Informatiker, da ist es mit dem> Softwareengineering nicht so weit her. Reusability, Libraries, Module> sind da wenig verbreitet und die Bereitschaft, das zur Verfuegung zu> stellen, auch nicht. Natuerlich gibt es Ausnahmen, aber das ist eben> nicht die Regel.
Das hat aber auch einen ganz pragmatischen Grund: Bei einem embedded
Device ist der Hersteller, egal ob er eigenen oder fremden Code
verwendet, voll haftbar, d.h. er muß für fremden*) Code genauso
Qualitätssicherung betreiben wie für eigenen. Und da die
Qualitätssicherung (Test/Validierung/Codeaudit) oft mehr Aufwand als die
eigentliche Implementierung ist, implementiert man es halt selbst. Da
kennt man den Code, mit dem man arbeiten muß, wenigstens.
*) Bei Code vom Zulieferer kann man die Haftung per Vertrag übertragen.
Aber das geht bei "freien" ("nimm's Dir und Du bist selbst
verantwortlich, was Du damit machst") Lizenzen ja genau nicht.
Jodel schrieb:> Elektroniker unterwegs sind und nicht Informatiker, da ist es mit dem> Softwareengineering
Weiter braucht man nicht zu lesen. Software-Engineering ist die
gescheiterte Disziplin der Informatik in der seit 50 Jahren verzweifelt
versucht wird aus der Informatik eine Ingenieurwissenschaft zu machen,
weil die Informatiker Ingenieure sein wollen. Die einzige noch dubiosere
Disziplin der Informatik ist die KI.
Charakteristisch für das schöne akademische Software-Engineering ist,
dass alle paar Jahre die selbe Sau, unter neuem Namen, durch Dorf
getrieben wird, zum Beispiel der heilige Gral der Informatik: Malen nach
Zahlen. Charakteristisch ist, dass das Software-Engineering nicht merkt
wenn sie einen Loser haben (wie Malen nach Zahlen). Vielleicht noch
schlimmer, dass sie nicht merken, wenn sie einen Gewinner haben. Wobei,
ehrlich gesagt, die Gewinner, wie Versionsmanagement und -Tools kommen
meist aus der Praxis und nicht vom akademischen Software-Engineering.
> Reusability, Libraries, Module
Der finanzielle Aufwand Komponenten von vorne herein wiederverwendbar zu
gestalten und ein ein vernünftiges Management für Wiederverwendbarkeit
zu betreiben steht, so die Erfahrung in der Praxis, in den meisten
Fällen in keiner Relation zum Gewinn.
Da haben wir eine weitere Charakteristik des akademischen
Software-Engineerings: Fehlende Praxisbezogenheit. Hier haben
Informatiker auch den Engineering-Mindset nicht verstanden. Es muss in
der Praxis funktionieren, aggressiv vorgetragene Theorien mit leeren
Versprechungen alleine reichen nicht.
Übrigens widerspricht das Planen von Wiederverwendbarkeit einem anderen
Trend der Informatik, der momentan als die Silberkugel verkauft wird:
Agil, genauer das aus XP übernommene YAGNI (you aren't gonna need it).
Auch bekannt als DTSTTCPW (do the simplest thing that could possibly
work) oder KISS (keep it simple, stupid).
Das ist dann die nächste Charakteristik des akademischen
Software-Engineerings: Nicht Widerspruchsfrei und keine brauchbare,
abgeschlossene Systemtheorie dahinter.
> sind da wenig verbreitet und die Bereitschaft, das zur Verfuegung zu> stellen, auch nicht. Natuerlich gibt es Ausnahmen, aber das ist eben> nicht die Regel.
Wenn der ganze akademische Software-Engineering Krempel so gut
funktionieren würde, warum machst du keine eigene Firma auf? Die
versprochenen Produktivitäts- und Qualitätssteigerungen sind ja enorm.
Da wird schon mal der Faktor 100 genannt. Eine Firma die 100 Mal
produktiver arbeitet als der Rest der Branche müsste die Welt mit
atemberaubender Qualität erobern können. Komisch, dass das bis heute
keiner Informatiker-Firma gelungen ist. Nicht mal Apple (und die wurde
sowieso nicht von Informatikern gegründet).
Jay schrieb:> Weiter braucht man nicht zu lesen.
Hast du offensichtlich auch nicht. Deswegen bezieht sich 99% von deinem
Text auf Dinge, die im Thread nicht mal erwaehnt wurden.
Jay schrieb:> Weiter braucht man nicht zu lesen. Software-Engineering ist die> gescheiterte ...
Laberlaberlaber.*gähn*
> Wenn der ganze akademische Software-Engineering Krempel so gut> funktionieren würde, warum machst du keine eigene Firma auf?
Wenn du doch so gut weiss wie es funktionieren soll, warum machst du
dann keine eigene Firma auf? Mit deinem Wissen müsstest du doch
kürzerhand die ganze Welt mit Software atemberaubender Qualität erobern
können!
