Hi, vorweg: ich hab keine Ahnung von Linux! Linux ist ja prinzipiell erstmal nur ein Betriebsystemkern, von dem es viele Variationen gibt. Nun.. warum schafft man es so "einfach" Linux auf soo vielen µC-Boards und auch auf vielen Routern, und whatever zum Laufen zu bringen. Muss für jedes Board eine gesonderte Linux-Distribution vorhanden sein? Oder gibt es da ein paar Distris, die einfach fast überall laufen, denen man nur sagen muss, welche Architektur das entsprechende Board hat? Und wie schaut es z.B. mit den Schnittstellen wie Audio, USB, Ethernet, IR?, I²C aus? Es gibt viele Möglichkeiten diese an einen µC anzubinden. Ich kann dafür interne µC-Peripherie nutzen sofern vorhanden, oder ich nehme externe Bausteine die per SPI angesteuert werden. Wird da genau wie beim PC einfach für alles einen Treiber geschrieben, der dann die Kommunikation zwischen dem Betriebsystem bzw. der Software und der Hardware auf low-level Ebene regelt? Gibt es da irgendwie ein riesiges Arsenal an Standard-Treibern und Spezifikationen, wie und wo man was wie anzuschließen hat damit alles schön funktioniert? Oder wird da einfach jedes mal das Rad neu erfunden wenn man ein neues µC-Board entwickelt? Wie kann man das ganze Zeug überhaupt installieren, wenn man gar keine Schnittstellen für Eingabegeräte hat? Kein Tastatur/Maus/Bildschirm. Welche Programme lassen sich ausführen? Sehr vieles an (nützlicher Software) ist ja auf die Bedienung per GUI ausgelegt. Was aber, wenn das Linux gar keine GUI besitzt? Ist die Software dann nicht ausführbar oder läuft sie einfach ohne GUI und ist dann einfach nur nicht bedienbar? Wie werden Kommandozeilenprogramme gesteuert? Kann man denen Befehle senden und auf deren Ausgabe (automatisiert) reagieren? Ist jedes Linux prinzipiell auf Multitasking ausgelegt? Sorry für die immens vielen Fragen aber ich brauch da mal ein bisschen Klarheit. Die ganzen Infos könnte ich mir auch Googeln aber.. ihr wisst ja wie das ist... Student.. Klausuren.. Hobbys.. Keine Zeit.. danke! lg PoWl
Falls es dich wirklich interessiert kann ich dir nur "Modern Operating Systems" von Andrew S. Tanenbaum empfehlen, das gibt es bestimmt auch bei euch in der Uni-Bibliothek.
MicroKernel ist da so ein Stichwort, bei Linux ist das halt besser umgesetzt als bei NT z.B. Um den Kernel rum sind die Device Treiber und Module für Systemfunktionen. Wenn man das schön schichtet wird das auch portabel, QNX ist auch ein gutes Beispiel dazu. Es gibt aber einige min. Anforderungen, z.B. eine Memory Management Unit, deshalb ist ein Linux für die kleinen AVRs zu fett. Dazu kommt das der gcc als Standardcompiler sehr weit ist und viele Plattformen unterstützt, das macht die Portierung ebenfalls deutlich einfacher.
Paul Hamacher schrieb: > Nun.. warum schafft man es so "einfach" Linux auf soo vielen µC-Boards > und auch auf vielen Routern, und whatever zum Laufen zu bringen. Muss > für jedes Board eine gesonderte Linux-Distribution vorhanden sein? Nein > Oder > gibt es da ein paar Distris, die einfach fast überall laufen, denen man > nur sagen muss, welche Architektur das entsprechende Board hat? Also es gibt eigent lich nicht viele Distries die auf Microcontrollern laufen... Architekturen währen: ARM, ARMEL, MIPS, SH, PPC, 68K Linus bietet den vorteil, das sogenannte einheitstreiber existieren, sprich, Treiber werden für Chips und Funktionen geschrieben und nicht für Produkte... Sprich, wenn Du unter Windos zwei Grafikkarten mit dem Radeon 9600 Chip past, benötigst Du zwei Treiber, unter Linux nur einen > Und wie schaut es z.B. mit den Schnittstellen wie Audio, USB, Ethernet, > IR?, I²C aus? Es gibt viele Möglichkeiten diese an einen µC anzubinden. Gibt es nicht. Für Audio gibt es I²S/PCM, für USB ben USB, Ethernet R/MII, IR ist UART, I²c/SPI entsprechend. Wobei I²C/SPI auch per bigbanging ealisert werden kann, wennd er µC keine entsprechende schnittstelle hat. i22_bitbang.ko ist der Linux-Treiber. > Ich kann dafür interne µC-Peripherie nutzen sofern vorhanden, oder ich > nehme externe Bausteine die per SPI angesteuert werden. Wird da genau > wie beim PC einfach für alles einen Treiber geschrieben, der dann die > Kommunikation zwischen dem Betriebsystem bzw. der Software und der > Hardware auf low-level Ebene regelt? Solche Treiber sind bereits in Linux vorhanden, allerdings wiest Du Dir ein eigenes Modul schreiben müssen welches die anderen Module/Funktionen einbindet, wenn Du externe selbstentwickelte Hardware verwendest. > Gibt es da irgendwie ein riesiges > Arsenal an Standard-Treibern und Spezifikationen, wie und wo man was wie > anzuschließen hat damit alles schön funktioniert? 1) JA :-D über 300 MByte 2) Dokumentation? LOL Kauf Dir ein Buch über Kernal-Hacking und lese die LKM liste. Eventuel auch die linux-arm-kernel liste > Oder wird da einfach > jedes mal das Rad neu erfunden wenn man ein neues µC-Board entwickelt? Nee danke, sowas brauchma unter Linux need... Sowas muß einmal programmiert werden und dann MUSS es passen. Alles andere ist ineffizient > Wie kann man das ganze Zeug überhaupt installieren, wenn man gar keine > Schnittstellen für Eingabegeräte hat? Kein Tastatur/Maus/Bildschirm. UART/Seriell? JTAG? USB? > Welche Programme lassen sich ausführen? Sehr vieles an (nützlicher > Software) ist ja auf die Bedienung per GUI ausgelegt. Was aber, wenn das > Linux gar keine GUI besitzt? Ist die Software dann nicht ausführbar oder > läuft sie einfach ohne GUI und ist dann einfach nur nicht bedienbar? Kommt auf die Software drauf an... > Wie werden Kommandozeilenprogramme gesteuert? Kann man denen Befehle > senden und auf deren Ausgabe (automatisiert) reagieren? Funktioniert wie auf einem PC... > Ist jedes Linux > prinzipiell auf Multitasking ausgelegt? Ja sicher, kommt aber auf den µC an, denn auf einem ARM7 wirste ein paar probleme bekommen... Auf nm Marvel Armada 1000 (1200MHz Dual-Core) oder Armada 300 (2000MHz Singel-Core) oder Samsung (2500MHz Dual-Core) kannste tonneweie Programme parallel haben und auch PCIe Grafikkarten anstecken > Sorry für die immens vielen Fragen aber ich brauch da mal ein bisschen > Klarheit. Die ganzen Infos könnte ich mir auch Googeln aber.. ihr wisst > ja wie das ist... Student.. Klausuren.. Hobbys.. Keine Zeit.. danke! :-P Faule S..! - und das am Sonntag morgen! :-P Grüße Michelle
JojoS schrieb: > MicroKernel ist da so ein Stichwort, bei Linux ist das halt besser > umgesetzt als bei NT z.B. Linux ein Microkernel? Naja...
Das beste OS ist und bleibt VxWorks! http://de.wikipedia.org/wiki/VxWorks http://www.windriver.com/products/vxworks/ Das setzen wir hier ausschließluch ein!
Moin nun erst mal solltest du dir den unterschied zwischen Linux und Linux klar machen. Verwirrt? Den Linux wird einerseitzt für "Linux Distributionen" verwendet, andererseits nur für den "Linux Kernel". wenn du bei arm oder embedded von Linux sprichst, dann immer von letzterem. es gibt zwar auch distributionen, aber nicht ganz so verbreitet / unterscheiden sich aber doch mächtig von dem was du vom PC her kennst. CD rein und installieren ist da nun mal nicht. Embedded Linux Systeme werden im normalfall corss compiliert. Du hast nen Linux pc mit der passenden ARM LInux Toolchain und übersetzt den Kernel, und das was man dann sonst noch so braucht und haben will, schnürt dann sein image, und bringt das dan irgend wie auf das system. das irgend wie hängt immer stark vom System selber ab. Booten von SD-Card netzwerk on board nand flash spi flash .... Meist hat man ein Dreistuffiges boot system. Stufe 1. Bootcode vom SOC Hersteller Stufe 2. BootCode wie z.B. U-Boot Barebox Readboot/ ... Stufe 3. Linux Kernel. Stufe 2 ist für die grundlegende HW initallisierung wie z.B. SD-RAM und das laden des kernels verantwortlich . Woher der dann genau kommt ob über TFTP NFS oder von SD Flash hängt vom funktionsumfang des booters ab. Thema Treiber für ARM SOCs in Linux. Ein Thema das auch schon Linus beschäftigt hat und aktuell auch tut. Gab vor kurzem ne böse klatsche wegen dem wildwuchs, den die ganzen arm leute in der linux treiberlandschaft verursachen. Im prinzip ist es so, das es wie für die normale PC hw für jeden SOC block jedes SOC herstellers einen treiber gibt. Resultat ist, das das jede menge treiber sind, die von den verschiedensten leuten gewartet werden, und jeder schreibt von jedem ab, und kopiert dabei natürlich auch die Fehler der Anderen. ( Wieso braucht man x treiber um nen GPIO zu schalten. Egal welcher Hersteller / welcher SOC es läuft zum schlus auf einen einzelnen Speicher zugriff raus, der dann den Port pin schaltet. das soll / kann man sicher vereinfachen) Für vielen im Kernel unstarstütsen SOCs gibt es nur eine grundlegende Treiberversorgung. Sprich UART und GPIO tun, der rest kommt dann nach und nach dazu, je nach dem wer sich drum kümmert oder nicht. Das nächste problem ist, das so ein SOC ja auf irgend einem Board verbaut ist, und die beschaltung vom Board ja die eigenschaften des SOCs beiflusst. Aktuell sind es glaubich an die 3500 bis 4000 ARM systeme die zumindest eine Kernel ID haben. gruss
A. K. schrieb: > JojoS schrieb: > >> MicroKernel ist da so ein Stichwort, bei Linux ist das halt besser >> umgesetzt als bei NT z.B. > > Linux ein Microkernel? Naja... ok, Monolithischer Kernel. Auf jedenfall gut gschichtet mit Portierbarkeit als Entwurfsziel. Passt das so besser?
Deutlich besser. Denn ein Microkernel sieht völlig anders aus.
Der Wildwuchs von tausenden verschiedener Konfigurationen von Devices und daraus entstehenden Systemen wird nicht nur positiv gesehen: http://www.theinquirer.net/inquirer/news/2102909/arm-hodge-podge-linus-torvalds
Mein ich doch linus war kurz davor keine änderungen aus dem arm tree mehr in den kernel zu pullen. man muss aber auch zugeben das die hersteller es einem nicht garade einfach machen. Es ist nicht gerade einfach ist herauszubekommen, von welchem SOC der hersteller den funktionsblock jetzt abgeleitet / kopiert hat. und wenn er abgeleitet hat, wie man jetzt version x von y unterscheiden kann. Schön wenn es ne HW versionskennung für den funktionsblock gibt. blöd nur wenn sie nicht immer an der gleichen stelle steht.
Für den Einstieg kann man sich durchaus mal http://www.minix3.org/ bzw http://minix1.woodhull.com/ ansehen, welches auch in oben genanntem Buch angesprochen wird.
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.