Je dois choisir un sujet de thèse bientôt et j'avais envisagé de mettre en œuvre un système d'exploitation pour une architecture qui n'est pas x86 (je me penche vers le bras ou l'AVR). La raison pour laquelle j'évite x86 est parce que j'aimerais acquérir une expérience avec des plates-formes intégrées et que je (éventuellement mal) estimait que la tâche peut être plus facile lorsqu'elle est effectuée à une plus petite échelle. Quelqu'un a-t-il des indications sur des sites Web ou des ressources où il y en a quelques exemples. J'ai tout lu sur la plupart des questions OSDEV sur le débordement de la pile et je suis également au courant d'Avrfreaks et d'OSDEV. De plus, si quelqu'un a eu de l'expérience dans ce domaine et souhaitait offrir des conseils en ce qui concerne l'approche ou la plate-forme, il serait très apprécié.
merci
10 Réponses :
Contiki pourrait être une bonne chose à rechercher. C'est très petit, fonctionne sur des microcontrôles et est open source. Il a un biais lourd vers la mise en réseau et les communications, mais vous pouvez peut-être sauter ces pièces et se concentrer sur le noyau.
Stuff assez solide.
Merci pour la référence, il est actuellement assis sur ma bibliothèque, c'était le texte de référence pour mon sujet d'architecture de systèmes d'exploitation l'an dernier =]
Développer un système d'exploitation (RT) n'est pas une tâche triviale. C'est très éducatif cependant. Mon conseil à vous est de démarrer le matériel indépendant. PC est un bon point de départ car il vient avec de nombreuses possibilités d'E / S et de bons débogage. Si vous créez une application de machine type d'une version virtuelle, vous pouvez créer quelque chose avec des capacités de plate-forme simples (sortie de la console, certains boutons / indicateurs sont un bon départ). De plus, vous pouvez utiliser des fichiers par exemple, pour produire le chronométrage (planifications) si vous commencez sur 'Bare Metal', vous devrez commencer à partir de zéro. Le débogage sur une LED (marche / arrêt / clignotement) est très difficile et prend beaucoup de temps. Mon deuxième conseil est de définir votre portée tôt: est-ce le planificateur, les mécanismes de communication ou les systèmes de fichiers qui vous intéressent ...? Faire tout peut facilement se retrouver dans un projet de vie longue.
Samek, Miro, UML Praticial STechertarts en C / C ++ contient des intéressants sections sur un microkernel. C'est l'un de mes livres préférés. Projets avancés de microcontrôleur PIC en C: de USB à RTOS avec la série PIC 18F semble couvrir certains de vos intérêts; Je ne l'ai pas encore lu cependant. Systèmes d'exploitation: Les principes de communes et de conception peuvent également apporter de bonnes perspectives. Il couvre tous les aspects du planificateur à la pile de réseau. Bonne chance!
Si vous choisissez Bras, récupérez une copie du Guide du développeur System (Sloss, Symes, Wright). Lien vers Amazon
Le chapitre 11 traite de la mise en œuvre d'un système d'exploitation incorporé simple, avec de grandes explications et un code d'échantillon.
On dirait que vous devriez avoir une copie du livre de Jean Labrosse's MicroC / OS .
On dirait qu'il peut juste l'avoir juste mis à jour aussi.
http://micrime.com/page/press_room/news/idh40
Il s'agit d'un livre bien documenté décrivant les travaux internes d'un RTOS écrit en C et porté à de nombreux processeurs embarqués. Vous pouvez également l'exécuter sur un X86, puis croisez-vous à un autre processeur.
bras et avr sont la craie et le fromage - vous avez scopé cela très large!
Vous pouvez produire un système d'exploitation très différent et plus sophistiqué pour le bras qu'AVR (sauf si vous parlez d'AVR32 peut-être - qui est une architecture complètement différente?).
AVR serait beaucoup plus contraignant au point de savoir que la tâche peut être juste à triviale pour la portée de votre thèse. Même la spécification du bras ne diminue pas beaucoup; Les pièces de bras bas de gamme ont de petites mémoires sur puce, pas de mmu et de périphériques simples; Les pièces d'extrémité supérieures ont une MMU, des caches de données / instructions, souvent un GPU, parfois une FPU, une exécution matérielle Java ByTecode et de nombreux autres périphériques complexes. Le terme «bras» couvre ARM7, Arm9, Arm11, Cortex M3, Cortex M8, ainsi qu'un certain nombre d'architectures destinées à être utilisées sur les ASIC et les FPGA - vous devez donc la réduire un peu peut-être?
Si vous choisissez Bras, jetez un coup d'œil à ces ressources . Surtout les guides d'initiés de Hitex et le "Bâtiment en métal nu avec GNU", ils vous aideront à obtenir votre planche "up" et à former le point de départ de votre système d'exploitation.
La première chose à laquelle je recommande est de réduire considérablement votre sujet de thèse. OSS sont omniprésents, bien recherchés et développés. Quelle idée de nouvelle idée espérez-vous poursuivre?
Cela dit, le Avrx est un très petit microkernel J'ai utilisé professionnellement sur les microcontrôleurs AVR. Il est écrit en montage. Une personne a commencé à le porter à C, mais n'a pas terminé le port. Soit finaliser le port à C et / ou faire un port C à l'architecture AVR32 serait précieux.
Un système d'exploitation ne doit pas être étroitement couplé à aucun processeur SO Bras ou X86 n'a pas d'importance.
Ce sera un sujet plus important, si nous commençons à discuter si le bras est intégré et X86 n'est pas. Quoi qu'il en soit, de nombreux endroits dans lesquels des processeurs X86 sont utilisés pour le développement logiciel intégré.
Je suppose que la majeure partie du code du noyau sera juste un lanugage clair. Il existe de nombreux systèmes d'exploitation gratuits déjà disponibles, comme par exemple, Linux intégré, la version gratuite d'Itron, Minix, etc. ... Ce sera une tâche ardue.
Mais d'autre part, ce que vous pouvez essayer, c'est que le port est intégré à Linux aux plates-formes dans lesquelles il ne fonctionne pas encore. Ce sera vraiment utile au monde.
idiot alors qu'il peut sembler, je suis récemment intéressé par le plate-forme Arduino pour apprendre quelques astuces de piratage avec l'aide d'amis plus expérimentés. Il y avait aussi Ce fil pour un gars intéressé à écrire un système d'exploitation pour celui-ci ( Bien que pas son intention principale).
Je pense que l'Arduino est très basique et simple comme un outil éducatif pour ces efforts. Cela vaut la peine d'essayer de le vérifier s'il correspond à la facture.
Un RTOS n'est presque jamais spécifique à l'architecture. Reportez-vous à une architecture RTOS disponible sur le net et vous remarquerez qu'une couche d'abstraction CPU / matériel résentifique la CPU. Les portions spécifiques du conseil (qui traitent des périphériques tels que les ports COM, la minuterie, etc.) sont extraites par un package de support de carte.
Pour commencer, comprendre comment les œuvres multi-threading dans une RTO essaient de mettre en œuvre un code de commutateur de contexte simple pour la CPU de votre choix; Cela impliquera un code permettant de créer un contexte de fil, de sauver un contexte et de restaurer un contexte enregistré. Ce code constituera la base de votre couche d'abstraction matérielle. Le développement initial peut facilement être accompli à l'aide d'un simulateur de logiciel pour la CPU sélectionnée.
Je suis d'accord avec l'affiche qui a suggéré de lire le livre, UCOS-II de Jean Labrosse. Des échantillons de code de commutateur de contexte, en particulier pour le X86, ne doivent être qu'une fouille Google!
Ou vous pouvez me rejoindre dans ma quête d'un clone d'EXEC (Amigaos) pour l'amiga d'origine. ;-)