Ich muss mich bald für ein Thema entscheiden und überlege mir, ein Betriebssystem für eine Architektur zu implementieren, die nicht x86 ist (ich bin auf ARM oder AVR ausgerichtet). Der Grund, warum ich x86 meide, ist, dass ich einige Erfahrungen mit eingebetteten Plattformen sammeln möchte und ich (möglicherweise fälschlicherweise) glaube, dass die Aufgabe einfacher ist, wenn sie in einem kleineren Umfang ausgeführt wird. Hat jemand irgendwelche Hinweise auf Websites oder Ressourcen, wo es einige Beispiele dafür gibt. Ich habe die meisten, wenn nicht alle OSEvev-Fragen über den Stack-Überlauf gelesen, und mir sind auch AvrFreaks und OSDev bekannt. Zusätzlich, wenn jemand Erfahrung in diesem Bereich hatte und einen Ratschlag in Bezug auf Annäherung oder Plattform geben wollte, würde es sehr geschätzt werden.
Danke
Die Entwicklung eines (RT) Betriebssystems ist keine triviale Aufgabe. Es ist jedoch sehr lehrreich. Mein Rat an Sie ist, hardwareunabhängig zu beginnen. PC ist ein guter Ausgangspunkt, da es mit vielen I / O-Möglichkeiten und gutem Debugging ausgestattet ist. Wenn Sie eine Art virtuelle Maschinenanwendung erstellen, können Sie etwas mit einfachen Plattformfunktionen erstellen (Konsolenausgabe, einige Schaltflächen / Indikatoren sind ein guter Anfang). Außerdem können Sie beispielsweise Dateien verwenden, um das Timing (Zeitpläne) auszugeben. Wenn Sie mit 'Bare Metal' beginnen, müssen Sie von vorne anfangen. Debugging auf einer LED (an / aus / blinkend) ist sehr hart und zeitaufwendig. Mein zweiter Rat ist, den Umfang früh zu definieren: Ist es der Scheduler, die Kommunikationsmechanismen oder die Dateisysteme, an denen Sie interessiert sind? Alles zu tun kann leicht zu einem lebenslangen Projekt führen.
Samek, Miro, Praktische UML-Statecharts in C / C ++ enthält einige interessante Abschnitte zu einem Microkernel. Es ist eines meiner Lieblingsbücher. Fortgeschrittene PIC-Mikrocontroller-Projekte in C: Von USB zu RTOS mit der PIC 18F-Serie scheint einige Ihrer Interessen zu decken; Ich habe es aber noch nicht gelesen. Betriebssysteme: Internals und Design Principles können auch gute Einsichten bringen. Es deckt alle Aspekte vom Scheduler bis zum Netzwerkstack ab. Viel Glück!
Es scheint, als ob Sie eine Kopie von Jean Labrosses Buch MicroC / OS erhalten sollten.
Es sieht so aus, als hätte er es gerade eben aktualisiert.
Dies ist ein gut dokumentiertes Buch, das die inneren Abläufe eines RTOS beschreibt, das in C geschrieben und auf viele eingebettete Prozessoren portiert wurde. Sie könnten es auch auf einem x86 ausführen und dann die Kompilierung zu einem anderen Prozessor durchführen.
Contiki könnte eine gute Sache zu erforschen sein. Es ist sehr klein, läuft auf Mikrocontrollern und ist Open Source. Es hat eine starke Vorliebe für Netzwerke und Kommunikation, aber vielleicht können Sie diese Teile überspringen und sich auf den Kernel konzentrieren.
Wenn Sie ARM wählen, holen Sie sich eine Kopie des ARM System Developer's Guide (Sloss, Symes, Wright). Link zu Amazon
In Kapitel 11 wird die Implementierung eines einfachen eingebetteten Betriebssystems mit ausführlichen Erläuterungen und Beispielcode erläutert.
ARM und AVR sind Kreide und Käse - Sie haben das sehr weit gefasst!
Sie könnten ein sehr anderes und ausgeklügelteres Betriebssystem für ARM als AVR erzeugen (es sei denn, Sie sprechen über AVR32 vielleicht - was ist eine völlig andere Architektur?).
AVR wäre viel mehr zu dem Punkt eingeschränkt, dass die Aufgabe für den Umfang Ihrer These einfach zu trivial sein könnte. Selbst wenn man ARM spezifiziert, wird es nicht viel eingegrenzt; Low-End-ARM-Teile haben kleine On-Chip-Speicher, keine MMU und einfache Peripheriegeräte; höhere Endteile haben eine MMU, Daten- / Befehls-Caches, oft eine GPU, manchmal eine FPU, Hardware-Java-Bytecode-Ausführung und viele andere komplexe Peripheriegeräte. Der Begriff "ARM" umfasst ARM7, ARM9, ARM11, Cortex M3, Cortex M8 und eine Reihe von Architekturen, die für ASICs und FPGAs gedacht sind - also müssen Sie sie vielleicht etwas eingrenzen?
Wenn Sie ARM auswählen, sehen Sie sich diese Ressourcen an. Vor allem die Insider's Guides von Hitex und der "Bare-Metal-ARM mit GNU bauen" helfen Ihnen dabei, Ihr Board "aufzurichten" und den Ausgangspunkt für Ihr Betriebssystem zu bilden.
So dumm es klingen mag, ich war kürzlich an der Arduino -Plattform interessiert, um einige Hacking-Tricks mit Hilfe von erfahreneren Freunden zu lernen . Es gab auch diesen Thread für einen Typ, der daran interessiert war, ein Betriebssystem dafür zu schreiben (obwohl nicht sein primäres) Absicht).
Ich denke, das Arduino ist sehr einfach und unkompliziert als ein pädagogisches Werkzeug für solche Bemühungen. Es kann sich lohnen, es auszuprobieren, wenn es der Rechnung entspricht.
alt text http://ecx.images-amazon.com/images/I/3125C47MR4L ._SL500_AA180_.jpg Ссылка
Ziemlich solides Zeug.
Das erste, was ich empfehle, ist, das Thema der Dissertation erheblich einzuschränken. Betriebssysteme sind allgegenwärtig, gut erforscht und entwickelt. Welche neue Idee hoffst du zu verfolgen?
Das heißt, AvrX ist ein sehr kleiner Mikrokernel, den ich professionell benutzt habe AVR-Mikrocontroller. Es ist in Assembly geschrieben. Eine Person hat damit begonnen, sie nach C zu portieren, hat aber den Port noch nicht fertiggestellt. Entweder ist der Abschluss des Ports zu C und / oder die Erstellung eines C-Ports für die AVR32-Architektur wertvoll.
Ein OS sollte nicht eng mit einem Prozessor verbunden sein , so dass ARM oder x86 keine Rolle spielt. Es wird ein größeres Thema sein, wenn wir anfangen zu diskutieren, ob ARM eingebettet ist und x86 nicht. Wie auch immer, es gibt viele Orte, an denen x86-Prozessoren für die Embedded-Software-Entwicklung verwendet werden.
Ich schätze, der größte Teil des Kernel-Codes wird einfach nur C-Sprache sein. Es gibt viele freie OS, die bereits verfügbar sind, wie zum Beispiel Embedded Linux, Free Version von Itron, Minix, etc ... Es wird eine entmutigende Aufgabe sein.
Auf der anderen Seite können Sie Port Embedded Linux auf Plattformen ausprobieren, auf denen es noch nicht funktioniert. Das wird der Welt wirklich nützlich sein.
Ein RTOS ist fast nie architekturspezifisch. Beziehen Sie sich auf eine beliebige RTOS-Architektur, die im Netz verfügbar ist, und Sie werden feststellen, dass eine CPU / Hardware-Abstraktionsschicht die CPU abstrahiert. Die boardspezifischen Teile (die Peripheriegeräte wie Com-Ports, Timer usw. behandeln) werden von einem Board-Support-Paket abstrahiert.
Um zu verstehen, wie Multithreading in einem RTOS funktioniert, versuchen Sie zunächst, einen einfachen Kontextwechselcode für die CPU Ihrer Wahl zu implementieren. Dies beinhaltet Code zum Erstellen eines Threadkontextes, Speichern eines Kontexts und Wiederherstellen eines gespeicherten Kontexts. Dieser Code bildet die Grundlage für Ihre Hardware-Abstraktionsschicht. Die anfängliche Entwicklung kann leicht unter Verwendung eines Software-Simulators für die ausgewählte CPU erreicht werden.
Ich stimme dem Poster zu, das vorgeschlagen hat, das Buch uCOS-II von Jean Labrosse zu lesen. Beispiele für Kontextwechselcode, insbesondere für x86, sollten nur eine Google-Suche sein!
Tags und Links c assembly embedded operating-system
