Ich hab wieder einmal etwas zum vorstellen. vorab erstmal die URL zu weiteren Infos: http://www.ullihome.de/index.php/Hauptseite#SD-OS Es ist eine Art Treiberlayer für Microcontroller das ursprüngliche Ziel war es meine Software die auf einer Hardwareplattform läuft auf eine andere zu portieren die den selben Zweck erfüllt jedoch komplett anders aufgebaut ist. Stück für Stück wurde ein Treibersystem daraus das ich letztendlich ziemlich Unix kompatibel gemacht hab. Grundsätzlich kann man mit open read write / ioctl auf jede Hardware zugreifen. Nach aussen läuft das genauso ab wie im unix z.b. f = open("/dev/i2c0",0); ioctl(f,I2C_SLAVE,0xff); write(f,&mybuffer,4); würde jetzt 4 byte aus mybuffer an i2c gerät mit der adresse 0xff senden. Das Treiberlayer selbst ist dabei recht schlank (~1k) und da die Treiber ja jetzt recht abgeschottet sind kann man diese auch sehr effizient gestalten. Z.b. könnte man die Treiber allesamt durchaus in Assembler schreiben. An eure hardware anpassen könnt ihr das System einfach über 3 Files ich hab das mal auf der Seite beschrieben wenn dazu Fragen sind einfach mailen. Die avr-lib anbindung ist auch recht gut so dan man auch fopen / fprintf und co benutzen kann mit einem einfachen stdout = fopen("/dev/lcd0"); z.b. (kann auch in der plattform deklaration stehen) kann man im hauptprogramm einfach printf mit all seinen spielereien benutzen. Ich erhoffe mir daraus das damit mit der zeit eine recht große Treiberbasis entsteht. Bibliotheken für einzelne Hardware findet man ja genug aber so hat man alles unter einem Hut. Anfänge haben so z.b. mit einem Schlag Routinen für LCD,UART,I2C und co. Anwendungen lassen sich recht einfach auf andere Hardwareplattformen portieren u.s.w. Ich hab auf dei Schnelle mal Treiber für LCD (HD44780), die AVR adc, Hardware I2C, Hardware U(S)ART dazugepackt. würd mich interessieren was Ihr von der Idee haltet.
> würd mich interessieren was Ihr von der Idee haltet. Ich hatte gelegentlich auch schon mal daran gedacht, habs aber dann verworfen weil soetwas zuviel Resourcen verbraucht. > fopen("/dev/lcd0"); So kostet dich das doch jedesmal unnoetigerweise 10Byte Ram. Schlimmer noch ist einbaute Funktionalitaet welche garnicht benoetigt wird. Sowas kostet dann Ram/Rom und Rechnenleistung. Ausserdem gibt es manchmal fuer dasselbe Problem verschiedene Loesungen die beide gebraucht werden. Ich hab z.B mal eine Routine fuer RC5 Empfang geschrieben die nur im IRQ laeuft und eine andere die nur im Hauptprogramm ohne IRQ laeuft. Oder einmal SPI/I2C welches eingebaute Hardware benutzt, und einmal alles in Software macht. Eine SPI Funktion die nur 8Bit kann, eine andere die auch mit 16 oder mehr Bits klarkommt. Man wuerde also einen Prozessor verwenden muessen der erheblich ueberdimensioniert ist und ganz besonders dann wenn man glaubt solche Libaries verwenden zu koennen damit man nicht verstehen muss was drin steckt. :-) Olaf
Jain, wie schon geschrieben das layer an sich ist nur 1k groß und ich weiss nicht wen die 10 byte Ram stören also mich jedenfalls nicht. der Vorteil dabei ist ja eben das man sich jedenfalls nicht mit jeder Hardware so gut auskennen muss. Und wenn sich jemand hinsetzt und z.b. nen LCD Treiber in Assembler schreibt dann hast das eine K fürs Layer mal schnell wieder raus. Das ist alles relativ. Da ist mir die portabilität wichtiger dafür kann ich das Programm halt mal schnell aufm PC ausprobieren oder dort schreiben und später erst aufn MC flashen. Ausserdem verwenden die meißten Leute heute eh überdimensionierte Controller entweder weils gar keine kleinen mehr gibt oder weil der Kostenunterschied so minimal ist das sich das gar nicht mehr lohnt. Ich sehs bei mir auf Arbeit täglich vor n paar jahren haben wiur uns noch mit 57er Pics rumgequält und Tagelang versucht 2-3 byte zu sparen. heute sind die Flashauslastungen der Controller irgendwo bei 50-70%
@ Olaf "damit man nicht verstehen muss was drin steckt" Manchmal will man das gar nicht mehr wissen. Wenn du ein Software-Projekt (z.B. mit Java oder C++/C#) hast und dann eine Klasse nach der anderen schreibst dann willst du nicht mehr wissen was da drin steht, sondern nur noch was du damit machen kannst. Es ist gut wenn man etwas auf die einfache Art und Weise machen kann, wenn man 100% Performance braucht kann man das dann direkter machen oder wenn es noch nicht reicht in Assembler.
> heute sind die Flashauslastungen der > Controller irgendwo bei 50-70% Flash ist nicht das Problem, sondern RAM. Die paar Bytes für die Sprungtabelle von read/write/ioctl kann man evtl. noch opfern. Der String für open() eher nicht. Alternative, anstatt: fd = open("/dev/i2c0"); wäre fd = open_i2c0(); vermutlich besser. Dazu noch ein kleines Framework a la: fd = open_handler( readfunc, writefunc, ioctlfunc ); Dazu noch einen Type fd_t definieren, der auf einem Mikrocontroller zu int8_t wird und in einer Posix-Umgebung zu int. Damit sollte das alles recht problemlos zu portieren sein.
damit geht aber die ganze Unix Kompatibilität flöten, dann muss man wieder für jedes Gerät nachschlagen wie es zu benutzen ist usw. Im jetzigen Stand ist jeder Treiber und das Treiberlayer komplett Unix komaptibel. Du kannst das Programm 1:1 auf nem Linux kompilieren und testen. Was dabei aber wichtiger ist das sich Leute die im Unix schonmal PC programmiert haben kein Stück umgewöhnen müssen.
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.