Hallo, kann jemand Beispiele nennen wo eine externe Library schwer einzubauen war in das bestehende Projekt. Z.B. für einen Sensor-Chip der an einen µC angebunden werden muss. Danke
Merkwürdige Frage, nein, gibts es nicht. Genau dafür packt man Code in eine Library, um das Anbinden eines Sensors/Aktors/Display/whatever einfach zu machen.
Moin, Vor Jahren haett' ich mal die libdvbpsi brauchen koennen, ging aber nicht, da (damals nur) GPL. Gruss WK
Das hängt stark vom know-how ab, was wiederum von Dokumentation abhängt. Was erwartest du, wenn ich dir eine loser-story aus meinem Leben erzähle? Ich erwarte, dass dann die Hyänen des Forums über mich herfallen. Nee, darauf habe ich keine Lust. Bloß keine Schwäche zeigen!
gerold s schrieb: > kann jemand Beispiele nennen wo eine externe Library schwer einzubauen > war in das bestehende Projekt. > Z.B. für einen Sensor-Chip der an einen µC angebunden werden muss. Suchst du eine Ausrede weil du irgendwas verkackt hast?
Ich verstehe die Frage nicht so richtig. Was willst du genau wissen, und was ist 'schwer'. Ich habe z.B. eine externe Library, der muss man noch Callbacks implementieren für Memory Allocation und SPI-Transfer. Je nach Prozessor-Typ geht das sehr anderes. Das ist dann nicht eine Sache von 5 Minuten. Aber Callbacks benutze ich seit 30 Jahren, also Standard-Technik. Und ich habe in den letzten Jahren ca 20 Chips angebunden. Mal geht das so und mal etwas leicht anders. Aber die Hersteller möchten ja auch, dass du das Ding benutzt, und dann kommt einiges an Beispielcode mit. Mein Fazit: nichts ist schwer. Manche Dinge sind nur etwas aufwändiger.
Was mir manchmal den Nerv raubte, waren unterschiedliche Definitionen/typedefs in 2 libs. Also z.b. true mal als #define, Mal als enum. Oder ohne guard.
A. S. schrieb: > Also z.b. true mal als #define, Mal als enum. Deswegen mache ich das gar nicht mehr. Wenn man schon nicht die stdbool.h benutzen will, sind 0 und 1 auch gut. Jeder versteht das ohne großartige Erklärungen.
Hannes J. schrieb: > Suchst du eine Ausrede weil du irgendwas verkackt hast? Ja genau. Wäre ich schlauer gewesen hätte ich die Toolkette und HW/SW-Architektur schneller durschaut und hätte die Bibliothek schneller verwenden können. Z.B war der vorgeschlagene Speicherort auf dem Chip einfach zu klein für die Bibliothek. Habe das ganze dann einfach auf einem anderen Speicherort getestet und da ging es.. Dann wurde eine Struktur nicht richtig beschrieben, ohne das ein Fehler angezeigt wird. usw.
gerold s schrieb: > Hallo, > kann jemand Beispiele nennen wo eine externe Library schwer einzubauen > war in das bestehende Projekt. > Z.B. für einen Sensor-Chip der an einen µC angebunden werden muss. > Danke Generell nimmt man ja libraries, damit sie einem den Aufwand abnehmen. Klassiker wäre bspw. FatFS für die FAT32 Implementierung für SD Karten etc. Diese Library ist imho sehr schön. Gute Doku, klare Schnittstellen, kein komischer Hokus-Pokus Anders ah es da schonmal auf der Arbeit aus: Da hatten wir einen Protokoll-Stack für ein Bus-Protokoll gekauft (weil Safety zertifiziert etc.). Der war absolute Grütze. Teilweise waren die Funktionen nur unzureichend beschrieben oder hatten gruselige Seiteneffekte, die niergends dokumentiert waren. Alles in allem eine furchtbare Erfahrung. Das hätte man in der Zeit auch selbst geschrieben bekommen. Erschwert wurde das ganze dadurch, dass es sich um closed-source Objektdateien gehandelt hat, in die man nicht reinschauen konnte.
Toll sind Bibliotheken mit undokumentiertem delay/sleep in den Funktionen. Gerade im Arduino-Bereich usus. Verhageln einem das schönste Timingkonzept in kooperativen state machines ... LG, Sebastian
A. S. schrieb: > Was mir manchmal den Nerv raubte, waren unterschiedliche > Definitionen/typedefs in 2 libs. Bei mir wars das Gegenteil - USB Highspeed und USB Fullspeed Library für STM32F4 mit den gleichen Namen für alles, das sich dann beharkt hat. Endete damit, das ich eine der beiden dann komplett umschreiben musste auf unique, damit sie koexistieren können.
BTW Arduino: Die Lib hier "https://github.com/me-no-dev/ESPAsyncWebServer"; stürzt über kurz oder lang unter Last ab. Die hier "https://github.com/yubox-node-org/ESPAsyncWebServer"; hingegen läuft stabil. Da hat sich im Nachhinein jemand die Mühe gemacht, ein eigentlich nicht mehr gepflegtes Projekt noch einmal zu überarbeiten.
Euro schrieb: > Da hat sich im Nachhinein jemand die Mühe gemacht, ein eigentlich nicht > mehr gepflegtes Projekt noch einmal zu überarbeiten. Das zeigt den größte Vorteil von Open Source. Dort kann man so etwas machen.
Vor einiger Zeit integrierte ein Kunde einen Sensor in seine Hardware. Der Vertriebler des Distributors lieferte dabei eine vorkompilierte Bibliothek mit, die "ganz einfach" zu integrieren wäre. Es handelte sich zwar um Code für irgendeinen ARM-Prozessor, der mit irgendwelchen Einstellungen für irgendein Betriebssystem kompiliert wurde, aber mehr erfuhren wir nicht. Der Projektleiter (Hardwareentwickler des Kunden) hatte von Software so richtig gar keine Ahnung, aber davon ziemlich viel. Deswegen verstand er auch nicht im Ansatz, worin das Problem bestand. Aber schon bei der Auswahl des Prozessors war es so, dass (derselbe) Vertriebler mit einem Demoboard angekrochen kam, auf dem irgendein Linux-Kernel gerade so bootete, dass man die ganzen Meldungen auf der seriellen Konsole sah. Angeblich müsse man "nur noch" schnell die Applikation schreiben und wäre fertig. Hierfür würden höchstens zwei Personenwochen an Arbeit benötigt; als erfahrener Entwickler verdreifachte er sicherheitshalber den Ressoucenbedarf auf sechs Personenwochen. Insgesamt erbrachten wir jedoch 4,5 Personen*jahre* an externer Entwicklungsleistung. Weiterhin waren zwei von deren eigenen Softwareentwicklern auch jeweils ca. drei Jahre in Vollzeit mit der der Entwicklung befasst. Aus den o.a. 2-6 Personenwochen waren also mal schnell zehn Personenjahre geworden. Ach, und der o.a. Sensor funktionierte trotzdem noch nicht richtig, weil der Hersteller keine Quellcodes oder weiteren Informationen zur Integration des Sensors herausrückte.
Stefan ⛄ F. schrieb: > Das zeigt den größte Vorteil von Open Source. Dort kann man so etwas > machen. Schade hier: Suchst Du als Anwender im Netz nach dem Fehler, findest Du hunderte von Mäkelstellen und nur an einem Ort die Lösung. (Das Google immer noch nicht die "Richtige Lösung zu meinem Problem"-Schaltfläche kennt, liegt allerdings wirklich nicht an Open Source)
Euro schrieb: > Suchst Du als Anwender im Netz nach dem Fehler, findest Du > hunderte von Mäkelstellen und nur an einem Ort die Lösung. Das liegt zu einem nicht unwesentlichen Teil auch daran, daß Problemlösungs-Sucher zwar sehr gut darin sind ihre Frage in allen möglichen Foren breit im ganzen Internet zu verstreuen, aber bei der Verbreitung der letztlich gefundenen Lösung viel zurückhaltender agieren.
Ja, dat is so. Der hier z.B. "https://www.roboternetz.de/community/threads/76871-SLAM-auf-dem-ESP32"; hats aber nach einem Monat gemerkt und auch am 03.01 propagiert (es geht also auch anders).
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.