Hallo Leute, ich beschäftige mich schon seit ein paar Jahren mit µC und co, habe auch schon einige Projekte umgesetzt und ein paar Spielerein gemacht. Teilweise mit AVRs auf Arduinos, AVRs ohne alles mit eigener Platine, MSP430 mit einem Dev-Board. Aus der Anwendungsprogrammierung vom PC her, benutze ich sehr viele fertige Bibliotheken, da es einfach schnell geht und bewährt ist. Bei der µC-Programmierung habe ich bisher auch viele fertige Funktionen benutzt. Mir stellt sich jetzt die Frage, wie weit sollte man fertige Bibliotheken verwenden und wann ist es sinnvoll das selber einzuhacken? Wie sind da eure Erfahrungen? Alex
Peripheriebibliotheken/HALs zu nutzen find ich recht sinnvoll. Einerseits erspart es dir die Arbeit und Zeit alle peripheriebausteien in einem µC manuell über die Register an zu sprechen, also du kannst dich mehr um dein eigentliches Projekt kümmern und schaund das du ans Ziel kommst. Andererseits bietet es dir eine Abstraktionsschicht, also du könntest eventuell den µC darunter wechseln, aber deine Applikation weiter nutzen. Dies wär ein netter Nebeneffekt bei manchen RTOS Systemen wie NUTTX. Um auf NUTTX ein zu gehen; du kannst deine Applikation schreiben und sie auf deinem x86 Rechner laufen lassen sowie auf einem stm32 board. Soweit meine meinung. eine universelle Antwort wirds ned geben. In manchen Fällen ist es sicher auch angebracht die Peripherie direkt an zu sprechen oder es gibt keine lib dafür. Dann könnt man sich eine lib auch selber schreiben. Dazu muss man natürlich noch auf die Lizenzen auf passen :)
Ääääähhhmmm... Meiner Erfahrung nach, sollte man die Dinge selber erledigen, wenn einem der vorgefertigte Kram aus irgendwelchen Gründen nicht behagt. z.B. bin ich mit meinem Rädern an meinem Fahrrad recht zufrieden. Das war schon mal anders, dann habe ich das Vorderrad ausgewechselt. Aber selbst eins geschnitzt, habe ich noch nicht. Naja... In Sachen Arduino, kann man schon einiges "besser" machen, als die vorhandenen Bibliotheken/FrameworkFunktionen. Ins Besondere in Punkto "lernen" ist das selberbauen sehr hilfreich. In Punkto "fix fertig werden" eher nicht. ohne Gewähr
Um einen Punkt in einen String einzufügen, printf o. Verwandte einzusetzen, halte ich für übertrieben faul. Das ist in 5-6 Zeilen erledigt. Oder gleich eine Kopie von utoa umstricken, sowas is ja nich verboten. :)
Bibliotheken sollte man sich sehr sorgfältig aussuchen. Meist passiert das leider nicht, sondern es wird was genommen weil es einem gerade vor die Füße fällt. Der Hersteller legt es kostenlos bei, alle Welt nimmt es, muss gut sein? Dabei gibt es Bibliotheken und Bibliotheken ... Bibliotheken für Basisfunktionen als Teil der Sprache: In C habe ich überhaupt keine Hemmungen die C Standardbibliothek zu nehmen. Immer. Genauso, wenn POSIX-Bibliotheken vorhanden sind. Die werden immer genommen. Ich ziehe diese Bibliotheken immer irgendwelchen Spezial-, Super-Sonder-, Framework-, Vereinfachungs-Bibliotheken vor, die nur einen Wrapper um Standard- oder POSIX-Bibliotheken bilden, weil irgend ein Kid oder Hipster es schöner haben wollte oder eine Standardfunktion nicht verstanden hat. Ich schreibe lieber drei Zeilen mehr mit der Standardbibliothek, egal wie "altmodisch", "verkrampft", "uncool" das API ist. Diese Bibliotheken sind normalerweise am besten getestet, und haben die wenigsten Fehler und damit die wenigsten Überraschungen. Auch wenn die Fehlerdichte im Embedded-Bereich höher als im Desktop-Bereich ist. Hinzu kommt, dass sich die Software so erstmal auf einem PC testen und debuggen kann. In C++ würde ich auch gerne die C++-Standardbibliotheken nehmen. Viel von der Leistungsfähigkeit von C++ steckt in den Bibliotheken, nicht in der Sprache selber. Die ist nur unnötig kompliziert. Leider geht das im Embedded-Bereich häufig nicht, da die C++-Standardbibliotheken zu groß sind und es häufig keine Portierungen für eine Plattform gibt. Dann degeneriert C++ schnell zu C mit syntaktischem Zucker. Den brauche ich aber nicht. Anwendungsbibliotheken als Teil der Sprache: Moderne Sprachen enthalten neben Basisbibliotheken auch Anwendungsbibliotheken. Nicht selten gehen die APIs in die 10000. Anwendungsbibliotheken die als Teil der Sprache mitkommen ziehe ich normalerweise immer Spezialbibliotheken oder Herstellerbibliotheken vor. Auch wenn letztere (angeblich) "viel bequemer" sind. Ausnahme: Z.B. wenn die Performance einer Spezial-Herstellerbibliothek um den Faktor 10 größer ist und ich die Performance brauche. Hier gilt aber bereits das für C++ gesagte. Vieles was im Sprachstandard steht bekommt man im Embedded-Bereich nicht. Plattformbibliotheken, Anwendungsbibliotheken von MCU Herstellern: Ja, wenn sie ein echtes Problem lösen. An einem I/O Pin zu wackeln ist kein echtes Problem. Die eingebaute USB-Schnittstelle nach einem USB-Standard zu bedienen ist eins. Wenn viel Code zu schreiben ist oder der Code kompliziert ist, dann Plattformbibliotheken. Von der Qualität her sind viele richtig Scheiße (Chiphersteller können keine Software). Man muss bereit sein Zeit in das Debugging der Bibliotheken zu stecken. Daher nie für triviale Probleme nehmen. Leider versuchen viele Hersteller mit ihren Bibliotheken ein Lock-In. Willst du ein Teil, musst du alles nehmen. Dann eher drauf verzichten. Unabhängige 3rd Party Bibliotheken: Auch hier, nur wenn sie ein echtes Problem lösen, zum Beispiel ein IP-Stack. Zum Konvertieren von int nach Chars brauche ich keine 3rd Party Bibliothek. Wenn nichts in der Standardbibliothek ist, dann mach ich es min ein paar Zeilen selber. 3rd Bibliotheken von Toolherstellern, Middleware, etc. Nein. zu 99% zielen solche Beigaben, z.B. zu kommerziellen Entwicklungsumgebungen auf ein Lock-In ab. HALs und Betriebssysteme: Das ist eine Entwurfsentscheidung, die am Anfang kommt. Damit ändern sich die Spielregeln. Mit HAL oder Betriebssystem wechselt man APIs aus. Daher nie leichtfertig nehmen. Und schon gar nicht, wenn es sich um Kinder-HALs wie Arduino handelt.
Alex Z. schrieb: > Bei der µC-Programmierung habe ich bisher auch viele fertige Funktionen > benutzt. Mir stellt sich jetzt die Frage, wie weit sollte man fertige > Bibliotheken verwenden und wann ist es sinnvoll das selber einzuhacken? Ich bin der Meinung, dass man die grundlegenden Dinge einmal selbst gemacht haben sollte, um dann fertige Bibliotheken zu benutzen. Denn dann hat man genug Fachwissen, um die Qualität der Bibliothek einigermaßen einschätzen zu können, bzw. um sie zu debuggen, falls nötig. Es gibt aber Grenzen, ab denen das nicht mehr sinnvoll ist.
Wenn ich fremde Bibliotheken benutze, sehe ich die Gefahr, sie im Problemfall nicht zu beherrschen. Ich wäge daher ab, wie schlimm dieser Fall wäre. Handelt es sich um ein Produkt, das zuverlässig funktionieren muss, nutze ich Bibliotheken eher nicht. Das führt oft dazu, das gewisse tolle Features (z.B. USB Anschluss) dann lieber entfallen oder durch separate IC's realisiert werden, denen ich vertraue (z.B. CP2102). Bei Spielereien, wie z.B. eine Wetterstation oder eine "bessere" Uhr, habe ich Hemmungen, fremde Codes/Libraries zu benutzen. Mit diesem Thema habe ich beruflich im Umfeld der Java Enterprise Programmierung (also ganz andere Baustelle) mehr Erfahrung. Einzelne Libraries, wie zum Beispiel ein sftp Client machen selten Probleme. Umfangreiche Frameworks (ich nennen sie Eierlegende Wollmilchsäue), die wiederum auf zahlreiche Libraries aufbauen, machen hingegen viel öfter Probleme. Letztendlich sind die Frameworks selten direkt Schuld, sondern eher mangelhafte Kenntnis wie man sie richtig einsetzt oder Schnittstellen, die sich nicht 100% an Standards halten. Je weniger fremden Code ich einsetze, umso schneller kann ich Probleme lösen. Aber man sollte (wenn Zeit=Geld ist) nicht vergessen, wie aufwändig es ist, das Rad neu zu erfinden. Je spezieller das Framework ist, dass ich verwende, umso größer ist die Gefahr, dass meine Nachfolger damit nicht klar kommen. Softwareentwickler kennen sich immer nur mit einem winzigen Bruchteil der gängigen Frameworks/Libraries aus. Man kann alles lernen, aber auch das kostet Zeit und Geld. Deswegen lieber Libraries benutzen, die einen überschaubaren Funktionsumfang haben.
Alex Z. schrieb: > Bei der µC-Programmierung habe ich bisher auch viele fertige Funktionen > benutzt. Das ist schlau und richtig, so kommt man effizient vorwärts. In einigen Beiträgen hier erkennt man das NIH-Syndrom: Es wird von Fehlern im fremden Code gesprochen. Dabei wird übersehen, dass jeder mindestens auch so viele Fehler macht. Nur nehmen die meisten ihre eigenen Fehler nicht wahr und sind viel nachsichtiger mit sich selbst als mit anderen. Und schon schnappt die Gedankenfalle zu, der eigene Code wäre besser als fremder Code.
Erfahrener Entwickler schrieb: > Es wird von Fehlern im fremden Code gesprochen. Dabei wird übersehen, > dass jeder mindestens auch so viele Fehler macht. Das ist schon ein großer Unterschied. Bei Fehlern sucht man zuerst im eigenen Code. Daher verbraucht man viel Zeit, ehe man in der Fremdlib sucht und dann muß man sich ja erst auch in den Fremdentwickler hineinversetzen, ehe man da durchsieht. Eine fehlerhafte Fremdlib kann also richtig viel Zeit kosten. Ein Kollege hat auch mal ewig gesucht, warum sich ein Portbit nicht setzen lies. Es war ein C&P Fehler in der LPC-Lib.
Erfahrener Entwickler schrieb: (viele fertige Funktionen benutzt...) > Das ist schlau und richtig, so kommt man effizient vorwärts. Ach herrje, und du meinst das womöglich ernst? Wenn ich hier in diesem Forum sehe, wie all die Leute für den simpelsten Zweck fleißig eine "InitStructurXYZ" nach der anderen füllen, dann kommt mir das große Kopfschütteln. Nee, mit fleißigem Benutzen von Funktionen in dargebotenen Bibliotheken kommt man eben niemals effizient vorwärts, sondern steckt hoffnungslos fest, ohne dabei etwas gelernt zu haben. Was ich vorziehe, sind selbst er- und mit der Zeit umge-arbeitete Quellen, die man selber versteht und die man sich so geschieben hat, daß man sie möglichst gut wiederverwenden kann. Damit schafft man sich im Laufe der Zeit ein eigenes Portfolio, auf das man sich verlassen kann. W.S.
W.S. schrieb: > ohne dabei etwas gelernt zu haben. Warum mach ich denn den ganzen Scheiß hobbymäßig? Sonnst kauf ich fertig und gut. Aber Heute wollen alle Erfolgserlebnisse ohne was wirklich dafür zu tun. :( Das is wie mit blinkenden Bauklötzchen spielen. W.S. schrieb: > Wenn ich hier in diesem Forum sehe, wie all die Leute für den simpelsten > Zweck fleißig eine "InitStructurXYZ" nach der anderen füllen, dann kommt > mir das große Kopfschütteln. Bis ich da durchsteige und dann trotzdem noch unsicher bin, ob ich das alles richtig interpretiere, hab ich das meiste selbst geschrieben. OK, ist dann halt keine Eierlegendewollmichsau. :)
ich benutze gerne fertige Bibliotheken, wenn ich etwas selber schreibe heisst das ja nicht das ich keine Fehler mache. Hut ab vor den Göttern hier die ein DaBla nur überfliegen müssen und dann alles fehlerfrei und perfekt implementieren. Genial finde ich die Plattformen wie Github und Co., da findet man Unmengen an Code. Es ist natürlich durch die Menge mittlerweile nicht mehr ganz einfach Qualität zu finden, da muss man eben etwas suchen. Ich sehe mir den Code aber auch an und wenn es zB um irgendwelche Sensoren oder andere schlaue Teile geht schaue ich ins DaBla um zu sehen welche Features unterstützt werden. Durch Github bilden sich auch schnell Communities die gemeinsam Fehler ausmerzen und bessere Funktionen liefern. Ich arbeite fast nur noch mit Cortex-M, da kann ich einfach durch die Quellen steppen um Abläufe zu verfolgen und zu sehen ob wirklich das passiert was sich der Autor gedacht hat. Da habe ich allerdings schon viele Fehler gefunden, ich weiss nicht warum immer noch so viele einen Debugger für überflüssiges Hexenwerk halten. Und auch bekannte Namen wie Adafruit sind nicht immer garant für guten Code, letztens habe ich zB Code für einen SHT31 gesucht und die Adafruit Lib genommen. Da wird beim Auslesen des Wertes aber brutal 500 ms gewartet obwohl lt. DaBla der Messwert nach 12 ms ansteht. Und blöderweise mit doubles gerechnet obwohl ein AVR das mit seinen GCC Libs garnicht unterstützt. Auf meinen Cortex-M0 portiert wurde das dann zum Flashfresser weil der dann double Mathe gelinkt hat.
Hallo, Teo D. schrieb: > Warum mach ich denn den ganzen Scheiß hobbymäßig? > Sonnst kauf ich fertig und gut. > Aber Heute wollen alle Erfolgserlebnisse ohne was wirklich dafür zu tun. > :( > Das is wie mit blinkenden Bauklötzchen spielen. alles als Hobby selber zu machen würde vieles für mich auf "blinkende Bauklötzchen" reduzieren. Als Beispiel: Web-Streamplayer mit ESP32, SD-Card, Touch-LCD, I2S-Ausgabe. Ohne fertige WiFi-Lib? Ohne fertigen TCP-Stack? Ohne fertige Display-Lib? Ohne fertigen SD-Card/Filesystem-Lib? Ohne fertigen MP3-Software-Decoder? Gestaltung der Bedienoberfläche, Bufferverwaltung, Organisatio, Verwaltung der Abläufe, Stationsliste, SD-Card-Inhalt usw. beschäftigt mich durchaus ausreichend. Dazu kommt: diese Bibliotheken habe auch schon andere benutzt, da sind viele Fehler schon gefunden, zumindest bekannt, meist schon behoben. Außerdem liegt ein großer Teil dieser Bibliothene im Sourcecode ja vor und man kann reinschauen und notfalls oft auch eingreifen. Viles habe ich irgendwann früher selbst genacht. Meist reines Interesse und fehlende Verfügbarkeit. TCP/IP-Stack auf AVR ind ASM incl. ENC28J60 Treiber. Es war noch nichts wirklich da, der LAN-Chip gerade verfügbar. Andere waren da schneller und letztlich war meine Entscheidung dann, mich lieber mit C auseinanderzusetzen. Display-Treiber war wohl der T6963C die letzte ASM-Übung, Funk die RFM-Module als die gerade auf den Markt kamen und das Datenblatt mehr den Namen Rätselheft verdient hätte. Ich hätte den ESP32 wohl kaum angefasst ohne Bibliotheken und Beispiele wenn ich da nur mit dem IDK alles hätte selber machen müssen. Gruß aus Berlin Michael
:
Bearbeitet durch User
Michael U. schrieb: > alles als Hobby selber zu machen würde vieles für mich auf "blinkende > Bauklötzchen" reduzieren. Wollen wir mal die Kirche im Dorf lassen. Ich sprach von weit weniger komplexen Dingen und das dürfte wohl Jedem klar gewesen sein. :) Ein paar Sachen aus deiner Liste würde, bzw. habe ich, selbst geschrieben. Darum gehts mir ja. Platinen komplett selbst herstellen (nein Kupferfolie u. Trägermaterial stelle ich nicht selbst her) und sich dann beim Programmiren einen Wolf ärgern. :) Andre Puzzlen lieber oder spielen Adventure Games.
Hallo, Teo D. schrieb: > Michael U. schrieb: >> alles als Hobby selber zu machen würde vieles für mich auf "blinkende >> Bauklötzchen" reduzieren. > > Wollen wir mal die Kirche im Dorf lassen. es war absichtlich etwas überspitzt, weil in eineigen Posting die Meinung rüberkam, daß man sich besser nur auf sich selber verläßt und wenig bis keine fremde Bibliotheken benutzt. Das geht meiner Menung nach schon lange nicht mehr, wenn man eine Sache in absehbarer Zeit realisierbar sein soll. Fertig wird es ja sowieso nie. ;-) > Ein paar Sachen aus deiner Liste würde, bzw. habe ich, selbst > geschrieben. Darum gehts mir ja. Platinen komplett selbst herstellen > (nein Kupferfolie u. Trägermaterial stelle ich nicht selbst her) und > sich dann beim Programmiren einen Wolf ärgern. :) Ich gabe zu, daß eigene Platinen für meine Sachen inzwischen sehr lange zurückliegen. Inzwischen endet es bei Kombinationen aus fertigen Modulen, eigenen Teilschaltungen und Lochraster... Gruß aus Berlin Michael
Base64 U. schrieb: > Einerseits erspart es dir die Arbeit und Zeit alle peripheriebausteien > in einem µC manuell über die Register an zu sprechen, Das spart weder Zeit noch Arbeit. In Deinem Fall muß man nämlich neben der Dokumentation der Hardware (die man sowieso lesen muss im überhaupt irgend etwas damit zu machen) auch noch zusätzlich die Dokumentation des HAL lesen, also doppelter Aufwand. Und wenn man sich anschaut wie der Code hinterher aussieht kann man schön erkennen wie man im Falle von HAL mindestens genausoviel Code (und in der Regel hässlicheren, unleserlicheren Code) hinschreiben muss, als hätte man die paar Register von Hand gesetzt.
:
Bearbeitet durch User
Hallo, zum Thema Hardware-Doku stimme ich Dir voll zu. Zu "paar Register von Hand gesetzt" hätte ich eine Frage: von welcher Hardware reden wir? Ein paar Register können ja auch schnell mal 50 oder mehr sein incl. diverser Abhängigkeiten der Werte. Da bin ich eigentlich meist froh, wenn ich ich da schon was vorgefertigtes finde. Gruß aus berlin Michael
kommt darauf: 1. Wenn man die µC-Hardware oder Peripherie verstehen will, macht man es zu Fuss und baut sich daraus seine Bibliothek 2. Geht's nur darum es zum laufen zu bringen ohne die Funktion zu verstehen dann sind vorgefertigte natürlich nicht verkehrt. Macht dann aber die Fehlersuche schwierig da man sich dann so oder so in die Bibliothek reindenken muss bzw ob man aus seinem Code die Bib richtig angespochen hat....
Michael U. schrieb: > Ein paar Register können ja auch schnell mal 50 oder mehr sein incl. > diverser Abhängigkeiten der Werte. Bei z.B. 10 Peripherie Bausteinen sind das 5 Register pro Peripherie. Das ist doch nicht viel? zumal man die im Manual oft auf einer Seiter findet. Manual Seite auf dem linken Bildschirm offen, Quellcode auf dem rechten. 5 Minuten pro Peripherie (vorausgesetzt man hat Übung, indem man das immer so macht und nie HAl verwendet) und man alles zu Fuß selber ohne HAL programmiert. Bei HAL hingegen hast du keinen Plan, was passiert. Oder duhast die HAL studiert und kennst all ihre Fehler und Overheads ;)
A. schrieb: > Bei z.B. 10 Peripherie Bausteinen sind das 5 Register pro Peripherie. > Das ist doch nicht viel? zumal man die im Manual oft auf einer Seiter > findet. Beim CC430 waren es 47 Register allein für die Funk-Geschichte, wenn ich mich richtig erinnere... MfG Elux
Ich freue mich über USB und Netzwerk Libraries. Einwaches Pin-Wackeln und Timer programmiere ich jedoch lieber selbst anhand des Datenblattes (+ ggf. Referenzhandbuch) .
A. schrieb: > Bei z.B. 10 Peripherie Bausteinen sind das 5 Register pro Peripherie. > Das ist doch nicht viel? Für die üblichen Verdächtigen, also UART-SPI-I2C-GPIO-Timer-ADC kommt das hin. Bei komplexen Timer- oder ADC-Modi und DMA kann das schon etwas haarig werden, ist aber noch machbar. Ein USB-Device mit einem Atmega32U4 programmierst du aber nicht "mal eben so" hin. Die meisten Registerwerte sind dabei auch nicht statisch, und wenn du den Normalfall einigermaßen funktionierend hinbekommen hast, fehlen noch die eher schlecht testbaren Randfälle (Standby-Modi, Strom-Limits, Error-Handler, etc). Die Kompatiblitätsmatrix (Host-Chips x USB-Stacks) wird auch schnell unübersichtlich.
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.