Bonjour,
je cherche un livre pour apprendre à programmer un OS complet pour une carte embarquée avec processeur ARM, en connaissez-vous ?
-----
Bonjour,
je cherche un livre pour apprendre à programmer un OS complet pour une carte embarquée avec processeur ARM, en connaissez-vous ?
Savoir programmer en assembleur ARM, lire une datasheet, comment fonctionne l'électronique, ai-je besoin d'autre chose pour programmer cet OS ?
Le sens des réalités.
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Mis à part ça ?
Mis à part ça également ?
Pour une personne "normale", le cursus de formation standard prend plusieurs années à temps plein ...
Ca ne répond toujours pas à ta question, mais c'est juste pour t'éviter une perte de temps certaine.
Commence par faire clignoter une led en assembleur ARM et tu reviens. Je pense que ça va te prendre plusieurs semaines rien que pour le temps de maîtriser un minimum ta carte, ta chaîne de développement et l'assembleur de la bête.
Je doute que ça serve à quelque chose de répondre à Factorisable ...
Le style avait un air connu mais je n'avais pas fait le lien. Merci.Je doute que ça serve à quelque chose de répondre à Factorisable ...
Pour la théorie, voir peut-être les travaux d'Andrew S. Tanenbaum.
https://en.wikipedia.org/wiki/Andrew_S._Tanenbaum
Salut,
Comme il faut un début à tout,
Commence par te préoccuper de savoir comment fonctionne le processeur
Jeu d'instructions, Modes d'adressages, le mode Interrupt, les I/O etc..
Ensuite, commence par faire quelques exercices simples, mais pour tout ça il te faut au Minimum
un cross assembleur
une carte en état de marche, un boot qui contient une série de fonctions de base,
-gérer un terminal ( PC en mode dialogue avec ta carte par exemple )
-télécharger du code exécutable,
-lancer ce code
etc...
si t'as pas ce minimum t'as aucune chance d'arriver au bout de ton affaire.
Regarde voir dans le forum électronique, tu trouveras certainement des gens qui
connaissent tous ça.
Si non tu trouveras des infos ici
https://www.forth.com/embedded/
Cordialement
Ludwig
Je me souviens du sketch des inconnus caricaturant une série américaine où les flics n'utilisaient qu'un seul mot : fuck.
Ludwig1, c'est pareil : 1 seul mot, forth. La proximité des 2 mots sans doute...
Re
Si jamais tu peux encore changer de carte, alors regarde le processeur RTX2010RH ici
http://www.intersil.com/en/products/...RH.html#0.html
Remplace le RTX 2000 mis au point par Harris
https://www.harris.com/
Cordialement
Ludwig
Merci pour vos réponses. En cherchant Andrew S. Tanenbaum j'ai trouvé un certain nombre de livre qui pourrait être intéressant. Non la carte est une Beaglebone Black pas moyen de changer, je vais jeter un oeil à ce site https://www.forth.com/embedded/. Sinon, on n'a répondu à ma deuxième question.
Si ton objectif est toujours de fabriquer un robot humanoïde a auto-apprentissage, tu prends le problème complètement à l'envers.
Tu pars du bas alors qu'il faudrait partir du haut.
En informatique, on fait des prototypes et des preuves de concept.
Travaille ton algorithme d'auto-apprentissage avec des langages de haut de niveau sans perdre de temps avec des OS et de l'assembleur. (qui est le langage le plus consommateur en temps, on ne l'utilise d'ailleurs que pour des petites fonctions mais plus personne ne fait de logiciel complet en assembleur sauf cas très spécifique) Montre qu'il peut fonctionner et alors tu pourras avoir les financements nécessaires à la réalisation de ton projet et tu pourras engager des équipes qui ont les compétences pour réaliser les "détails" (mécanique, hardware, OS, optimisation, etc...). C'est comme ça qu'on mène un projet.
De la manière dont tu t'y prends, une vie humaine ne sera pas suffisante en temps pour y arriver. Ça fait déjà des mois que tu patines dans la semoule.
Dernière modification par Garion ; 16/10/2016 à 19h27.
La base d'un OS c'est la gestion des fichiers.
Donc savoir gérer un système de fichier en FAT32 est un minimum. https://fr.wikipedia.org/wiki/FAT32
Tu n'es pas obligé de gérer l'arborescence des répertoires, juste seul le répertoire racine.
Tu pourrais aussi utiliser ton propre système de fichier, mais dans ce cas il ne te serait pas
possible de transférer simplement tes fichiers, et tu devrais recréer éditeur, compilateur...etc...
Je comprends bien que tu souhaites créer ton OS pour être sûr d'avoir un contrôle total sur
le temps d'exécution de ton programme final.
Mais tu as des OS "temps Réel" comme Windows CE, QNX ou LINUX-rt (wikipedia donne pas mal d'infos)
Ce qui te permettra de pouvoir utiliser des drivers existants et fonctionnels, et de te focaliser sur ton soft
Il a peur que des espions viennent lui piquer ses idées . . .
Voir http://forums.futura-sciences.com/lo...eme-isole.html
Mais non, tu sais bien que ce n'est pas lui
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Non!
Le but d'un noyau est de gérer les ressources qui sont matériels au travers des pilotes de périph, mais également le temps CPU à partager entre les différents processus, et principalement la gestion des ressources mémoires, pas (seulement) la quantité, mais surtout la visibilité, pour éviter qu'un pointeur fou d'un processus vienne écrire dans la zone de mémoire d'un autre processus, c'est détecter par le noyau qui envoie un segfault au processus incriminé. Cette distinction espace noyau / espace utilisateur est indispensable pour parler d'OS.
Et contrairement à ce que son nom semble indiquer, un bidule comme FreeRTOS n'est pas un OS, ce n'est qu'un "scheduler".
Gérer un (ou plusieurs) systèmes de fichiers ca arrive après, au moins par ce qu'il faut les pilotes pour accéder au support de la mémoire de masse.
Si c'est une référence au "DOS" (disk operating system), contrairement à ce que son nom indique, c'est encore moins un OS que FreeRTOS: si je me rappel bien il n'y a même pas de scheduler, et l'accès aux ressources matériels se fait directement...
En effet. Ce qu'on appelait les OS à l'époque des disquettes géraient principalement le système de fichier et quelques petites autres choses. Ensuite, suivant les environnements, on accédait plus au moins directement au hardware (direct ou via la ROM sur l'Apple II, moins sur CP/M, via le BIOS sous MS-DOS mais aussi avec des appel système...).
Mais déjà à cette époque là, les OS sur des machines plus puissantes (stations Unix, Vax, mainframe) faisaient bien tout ce que tu décrit.
oui, mais là vous parlez d'OS multi-tâches et multi-utilisateurs...
Je ne suis pas sûr qu'il ait besoin de gérer ça
Vu qu'on ne sait pas ce qu'il veut faire, il n'a pas besoin non plus forcément de gérer un système de fichier.
Sinon, pour reprendre ton message qui ne parlait ni de mono-tâche ni de mono-utilisateur :
Pourquoi FAT32 ? Il y a pas mal d'autres dont le code source est accessible et qui sont prévu pour de l'embarqué. Voir par ex http://www.yaffs.net/Donc savoir gérer un système de fichier en FAT32 est un minimum. https://fr.wikipedia.org/wiki/FAT32
Tu n'es pas obligé de gérer l'arborescence des répertoires, juste seul le répertoire racine.
Pas du tout. Il peut très bien transférer de nombreuses façons via une liaison physique ou réseau. C'est en général ce qu'on fait sur de l'embarqué.
Et on édite/compile sur une machine extérieure donc aucun rapport.
Mais si on sait ce qu'il veut faire
Parce que c'est un système de fichier simple, et qui est géré par la plupart des OSil n'a pas besoin non plus forcément de gérer un système de fichier.
Pourquoi FAT32 ? Il y a pas mal d'autres dont le code source est accessible et qui sont prévu pour de l'embarqué.
Salut,
j'ai un peu regardé ton affaire avec ta carte Eagle....etc. C'est un produit de chez Texas semble t'il. T'as pas besoin d'un OS
pour ça, installe une machine Virtuelle, Java ou autre et l'affaire est réglée.
Personnellement, je te conseillerais la machine que je t'ai indiquée, tu peux directement écrire dans les registres de configuration des I/O et autre à partir du clavier et ainsi tester des bouts de code en mode interactif. Cette façon de développer est au moins 10 fois plus rapide que les méthodes classiques ou il faut écrire 20 lignes de code pour mettre un bit
à 1 ( J'exagère mais il y a de ça ).
En outre la machine virtuelle gère les Interrupts ainsi que le multitache.
Si j'ai bien compris tu veux faire un robot donc tu ne couperas pas ni au multitâche ni aux Interrupts. En outre il te faudra
développer des régulateurs, je ne connais pas tes connaissances en automatique, par contre je peux te dire que la mise au point d'un régulateur numérique dans l'espace d'état n'est pas forcément simple.
Pour te donner un avant gout sur ce qui t'attend:
http://r.search.yahoo.com/_ylt=A9mSs...CzG95M7TVSgAM-
Et le P.I.D numérique c'est ce qu'il de moins difficile, mais avant d'en arriver là il te faudra avoir construit le Hardware complet.
Cordialement
Ludwig
Quand on veut un OS, c'est bien souvent pour la séparation de la visibilité mémoire, ce n'est pas forcément une question de multi-utilisateurs, en gros gérer la MMU, ou l'émuler s'il n'y en a pas. Pour faire du multi-tâche, il suffit d'un scheduler, comme FreeRTOS par exemple.
Merci pour vos réponses, et pour ma deuxième question ?
Je pensais que :
1ere question : un livre qui explique tout
2eme question : j'ai besoin de quoi pour faire mon OS
pour la 1ere c'était facile : il n'y en a pas
pour la 2eme : c'était de quoi on parlait non ?
tu auras besoin du schéma de la carte mère, ce qui te permettra de savoir comment sont connectés les CI entre eux,
et avec leurs datasheet respectives, de savoir comment les faire communiquer.
Merci, je vais donc m'y mettre.