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.
In den Aufzählungen vermisse ich noch Hinweise auf youtube videos. Teilweise gut gemacht, so das man sogar versteht was man tut ;)
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!
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.