www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik [ANN] SD-OS Vorstellung


Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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%

Autor: Atmega8 Atmega8 (atmega8) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.