Hallo zusammen, seit einiger Zeit beschäftige ich mich mit dem STM32F107 uC und habe bereits einige kleine Programme zur Ansteuerung von ein paar Peripherien wie z.B. Ethernet, GPIO oder Timern bzw. PWM geschrieben. Dies gelang mir eigentlich relativ einfach da ich die Standard-Peripherial-Library und das Reference Manual des STMs zur Hilfe hatte, doch wie entwickelt man für viel komplexere Peripherien wie z.B. USB-(OTG) einen Treiber wenn man nur das Datenblatt bzw. Reference Manual zur Verfügung hat? Also schreiben die Entwickler solcher Treiber, die Treiber für z.B. den STM32 nur mithilfe des Datenblatts? Und wie genau entwickeln sie diese, erstellen sie sich z.B. vorher einen Programmablaufplan (Flowchart) oder progammieren sie einfach drauf los?
Lukas T. schrieb: > die Treiber für z.B. den > STM32 nur mithilfe des Datenblatts? Was heißt hier "nur"? In den Datenblättern von ST steht doch (fast) alles haarklein drin, da weiß man nach genauer Lektüre doch schon was man zu tun hat. Viel interessanter ist das doch bei undokumentierter Hardware, wie z.B. Grafikkarten, für die mittels Reverse Engineering Treiber entwickelt werden. Außerdem gibts im Falle von USB ja auch noch den USB Standard. Lukas T. schrieb: > Und wie genau entwickeln sie diese, erstellen sie sich z.B. vorher einen > Programmablaufplan (Flowchart) oder progammieren sie einfach drauf los? Die Methoden des Software Engineering helfen auch bei der Treiber-Entwicklung... Und einfache Programmablaufpläne sind nur eine davon.
Lukas T. schrieb: > progammieren sie einfach drauf los? Das würde ins Chaos führen. Der Anfang ist ein Lastenheft. Es wird genau aufgeschrieben, was alles gebraucht wird. Dann zerkleinert man das große Problem in kleinere Häppchen und arbeitet sich Stück für Stück weiter. Da gibt es dann zwei Philosophien, von oben nach unten oder umgekehrt. Jedes Teilproblem wird ausgiebig getestet. Und zum Schluss wird alles integriert und man hofft, dass es auch funktioniert. Aber noch einmal: Saubere Dokumentation ist die halbe Arbeit. Erst denken, dann Abläufe festlegen. Das eigentliche Kodieren ganz zum Schluss ist der einfachste Teil.
Georg G. schrieb: > Der Anfang ist ein Lastenheft. Es wird genau aufgeschrieben, was alles > gebraucht wird Beim V-Modell oder Wasserfall ja. Es gibt aber auch andere Prozessmodelle... Georg G. schrieb: > Das eigentliche Kodieren ganz zum Schluss ist der einfachste Teil. Hehe, aber nur in einer Welt in der es keine Hardware Bugs gibt, alles sich wie vorgesehen verhält, und niemand jemals Fehler macht.
Dr. Sommer schrieb: > Hehe, aber nur in einer Welt in der es keine Hardware Bugs Ich schrieb nicht, dass es problemlos sei. Aber jeder Fehler, jede Nachlässigkeit, die in den Stufen davor gemacht wurde, rächt sich am Ende bitter. Das gilt umso mehr, wenn mehrere Leute an einem Projekt gleichzeitig arbeiten. VHIT machen nur Anfänger und lernresistente Leute.
es gibt genug Vorlagen, wie man Treiber bzw. Software allgemein entwickeln sollte, in der Praxis gibt es aber einen enormen Wildwuchs. Die Informatik hat ein Qualitätsproblem, das so groß ist, das niemand es mehr sehen kann. Nur die Auswirkungen wie: alles ist hackbar, es gibt nach x Jahren keinen Support mehr für "veraltete" Software, Kompatibilität über alles, aber jetzt ist mal Zeit für was neues, aus dem Ruder laufende Projekte wegen ständig wachsender Komplexität der Komponenten. Die größten Fortschritte in der Informatik wird man die nächsten 30 Jahre machen können im Bereich Qualitätsbewusstsein und Normierung incl. verpflichtender Einhaltung selbiger. Aber da damit kein Geld kurzfristig zu verdienen ist wird das noch auf sich warten lassen. Und die neuen Informatiker lernen weiter von den alten wie es bisher gelaufen ist. Prio 1. Deadline halten. Prio 2. den eigenen Stil pflegen
Lukas T. schrieb: > Also schreiben die Entwickler solcher Treiber, die Treiber für z.B. den > STM32 nur mithilfe des Datenblatts? > > Und wie genau entwickeln sie diese, erstellen sie sich z.B. vorher einen > Programmablaufplan (Flowchart) oder progammieren sie einfach drauf los? Nein, das Datenblatt ist meistens nicht ausreichend, weswegen unsereiner das zugehörige Referenzmanual zuerst gründlich durchliest. Oftmals sind dort einige Details un- oder mißverständlich, weswegen man es nach einiger Zeit eben nochmal durchackern muß. Als nächstes kommt das Nachdenken dran, wie man die Schnittstelle zwischen Treiber und höheren Programmschichten gestaltet, so daß die zugehörige .h den Rest der Firmware nicht zumüllt und man sich an anderen Stellen der Firmware nicht mit den Details der Treiber-Innereien herumplagen muß. Wer einfach drauflos programmiert, macht sich nur das eigene Leben schwer - aber das sind viele, die so tun. Auch Leute, die mit Programmieren ihre Brötchen verdienen. Die Frage ist also nicht "Wie machen es die Anderen?" sondern eher "Wie sollte man es sinnvollerweise machen?" W.S.
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.