Re: Sujet de TX NxOS
David Anderson
> > > Cependant, au bout de quelques temps j'obtiens une assertion dans
> > > sensors.c mais je n'ai aucun capteur connecté. Je pense que le problème
> > > doit venir de la.
>
> J'ai shunté le problème : j'ai modifié le main.c en faisant :
> tests_display()
> test_usb()
Bien vu, mais l'assertion est anormale. L'absence de capteur connecté
devrait simplement résulter en des mesures inintéressantes. En
général, toute assertion, quelle qu'elle soit, est signe qu'il y a un
bug, puisque c'est un filet de sécurité. Je vais ouvrir un bug dans
Trac pour ca.
> ce qui m'a permis de tester la connection usb depuis le PC vers le NXT
> et d'exécuter quelques commandes. J'en ai d'ailleures profiter pour
> rajouter une commande "help" qui me liste les différentes commandes
> possibles :-)
Ah, nous avons un nouveau contributeur :-). Maintenant que Mercurial
devrait fonctionner depuis l'UTBM (cf. plus bas), je peux vous créer
un dépot, histoire de pouvoir gérer vos modifs dans Mercurial
directement.
> Merci en tout cas, pour votre aide pour démarrer NxOS.
Et merci de supporter la procédure, encore assez (et trop) vaudou :-)
> J'en profite pour vous demander si vous avez des sujets de TX à proposer
> pour continuer les développements de NxOS pour le semestre prochain.
J'ai plusieurs idées de pistes à explorer. Il faudrait sans doute les
polir et les affiner un peu pour en faire des bons sujets de TX, ainsi
que calibrer la difficulté, mais quelques idées comme ça à chaud:
* Portage et intégration du "remote GDB stub" au Baseplate, et
interfaçage avec gdbserver pour permettre du débuggage distant.
Selon les specs exactes du stub gdb et le succès de la TX, ca pourrait
aller du simple breakpoint + affichage du contenu des registres et du
désassemblage du code en cours d'exécution, jusqu'a de l'exécution pas
à pas dans le code source d'origine, voire même la possibilité
d'installer des points de trace, pour pouvoir débugger du code d'IRQ
sans planter la bestiole. Travail ardu en perspective je crains, parce
que nous n'utilisons pas un format binaire connu, et notre format
binaire n'inclut pas les infos de debug générées par gcc.
Touche à: formats binaires, programmation C et assembleur arm7 très
bas niveau (injection d'instructions breakpoints, gestion
d'exceptions), portage vers une architecture embarquée, les "joies" du
débuggage embarqué sans JTAG.
* Support de transmission haute vitesse par RS-485
Le 4e port capteur dispose, en plus des modes analogiques et I2C, d'un
controlleur RS485. S'il est correctement configuré, il pourrait
permettre de raccorder le NXT à beaucoup de capteurs conçus pour bus
de terrain, voire même de brancher deux NXT entre eux pour transmettre
des données sans encombrer la bande passante Bluetooth. Un peu de
reverse engineering en perspective, puisqu'on a aucune spécification
pour le controlleur RS485. Lego nous informe juste qu'il existe, et il
figure sur les plans de cablage. Reste à trouver le modèle, les specs,
et implémenter un pilote de baseplate pour s'en servir.
Touche à: développement de pilotes pour système embarqué, savoir
trouver/lire/comprendre une spec de périphérique, éventuellement un
peu d'imagination et de contacts au GESC pour trouver des applications
amusantes du bus RS485 (de toute manière il faudra trouver quelque
chose pour tester que le pilote fonctionne!). En poussant un peu le
vice, en trouvant une caméra RS485, on pourrait même envisager une
collaboration REM/I2RV pour faire du traitement d'image avec le NXT
(probablement avec soutien d'un PC via Bluetooth)
* Implémenter un pilote Flash et un système de fichiers
Actuellement NxOS peut booter de la flash, mais n'utilise que quelques
ko des 256, et ne sait pour l'instant ni lire ni écrire le reste. Il
faudrait développer tout d'abord un pilote bas niveau pour lire et
modifier les blocs de la flash (structurée en bloc, elle ne peut être
reprogrammée qu'un bloc entier a la fois, la structure exacte est
documentée). Puis, par dessus, développer un système de fichiers. Il
n'a pas besoin d'être extrêmement évolué (pas besoin d'arborescences
infiniment profondes, ni de permissions autres que
exécutable/non-exécutable), mais devrait permettre de "simuler" un
système de fichiers à la firmware Lego au niveau des fonctionalités
disponibles. Point d'intéret particulier, le système de fichiers
devrait essayer d'implémenter un algorithme de wear-levelling, pour
étaler les écritures le plus possible sur l'ensemble de la mémoire.
Le développement du pilote de blocs pourra s'inspirer du travail
accompli par Lejos. Le développement du système de fichier de haut
niveau devrait au moins consulter les specs/le code de jffs2 et romfs
pour l'état de l'art et leur piquer des idées. En outre, il faudrait
coordonner la conception du système de fichiers avec Lejos, ils
souhaiteraient passer leur VM a NxOS, et ont donc leur mot à dire sur
le système de fichiers.
Touche à: développement de pilotes embarqués, conception/développement
ou portage d'un système de fichiers destiné à l'embarqué (aspects
algorithmiques intéressants pour la structuration d'un FS pour très
petite zone de stockage et pour le wear-levelling), interaction avec
un projet logiciel libre (Lejos).
* Développement d'un noyau applicatif Lego
Toujours dans notre optique de vouloir unifier les plateformes NXT,
une étape importante est le développement d'un noyau applicatif qui
implémente la machine virtuelle et les protocoles du firmware officiel
de Lego. Il faudra réimplémenter (plus proprement que Lego!) la
machine virtuelle spécifiée dans la doc NXTreme, se débrouillant au
passage pour adapter au besoin le modèle très synchrone de la VM Lego
au modèle de pilotes asynchrones du Baseplate. Il faudra également
implémenter le protocole Phantom, l'API de communication haut niveau
par USB/Bluetooth qui permet de télécommander un robot et d'interagir
avec son OS. Le but final ici est que même l'IDE de Lego ne puisse se
rendre compte qu'il ne communique pas vraiment avec son OS à lui!
A noter que ce sujet dépendrait en partie du développement du système
de fichiers, puisqu'une partie des opcodes de la VM et une partie du
protocole Phantom suppose l'existence d'un système de fichiers. Je
pense qu'il est possible de laisser ces morceaux de coté et/ou
d'implémenter des solutions temporaires en attendant que le FS
devienne une réalité. Mais bien préciser qu'il y a déjà de quoi faire,
et des solutions palliatives, et qu'il ne faut pas attendre le FS pour
s'y mettre!
Touche a: implémentation d'une machine virtuelle, utilisation d'un OS
embarqué (NxOS Baseplate ici), implémentation de protocoles de
communication, émulation d'architecture tierce.
* Portage d'autres architectures sur NxOS
Je suis un peu moins chaud pour ça, vu que ca implique un Baseplate
ayant une API stable, et pas mal de diplomatie avec les projets qui
n'ont pas encore entendu parler de NxOS. Mais s'il y a quelqu'un de
vraiment motivé par un truc particulier de ce coté là, pourquoi pas.
Les projets qui pourraient faire l'objet d'un portage: Lejos-OSEK (le
noyau temps-réel OSEK, porté sur un "baseplate" à base de bouts d'un
ancien noyau de Lejos retaillé à la hache), pbLua (machine virtuelle
Lua), pbForth (machine virtuelle Forth).
Le seul qui aie déjà été contacté est Lejos. Ils ont l'air très
intéressés, mais je ne pense pas que le Baseplate soit prêt au niveau
maturité à les accueillir. Dans tous les cas, porter des architectures
à ce stade nécessiterait pas mal de travail de maintenance, pour
adapter au fil des évolutions des API du Baseplate.
* Développement des outils de développement
Au lieu de ce titre un peu récursif, on pourrait dire plus simplement
"pouvoir développer des noyaux applicatifs sous Eclipse". Ca serait
sympa de créer des workflows de développement dans des IDE de plus
haut niveau, pour que des développeurs potentiels ne soient pas
rebutés par le fait de devoir utiliser gcc et un terminal tout le
temps. Je cite Eclipse comme ça, mais d'autres candidats potentiels
seraient Netbeans et Jedit.
Attention: quoi qu'il arrive, il ne s'agit pas de rendre l'utilisation
de l'IDE obligatoire, plutot de réaliser une intégration un peu comme
celle qu'a fait WindRiver pour VxWorks, dans leur Eclipse modifié:
sélectionner "Build project" va lancer en arrière plan Scons, en lui
passant les bons paramètres, réinjecter les erreurs dans l'IDE,
fournir un accès rapide à la doc d'API...
D'autres choses à explorer de ce coté là: développer un "package"
installable sous Windows, contenant la chaine de compilation croisée,
pynxt, tous les outils qu'on a développé, les sources de NxOS, bref
tout ce qu'il faut pour pouvoir lancer une console cygwin (ou eclipse)
et se mettre à développer. Je n'ai aucune idée de ce que ca implique,
mais cela pourrait permettre d'ouvrir NxOS à un public plus large.
Ce sujet m'a l'air moins REM que les autres. Je dirait presque que
c'est plutot un sujet d'ILC, mais il y a tout de même un lien marginal
avec l'embarqué, vu que ca serait pour NxOS :-).
Et euh... Voila. C'est déjà pas mal comme pistes :-)
> De mon côté je réfléchis à la possibilité d'utiliser NxOS dans le cadre
> de l'UV LO52 (sys embarqué), car je trouve l'outil extrêmement
> intéressant d'un point de vue pédagogique pour le côté système embarqué
> de la filière REM. NxOS pourrait ainsi être utilisé en TP, mais
> également pour le projet LO52.
En ce qui me concerne, je suis tout à fait partant! Enfin, je ne serai
plus dans le coin, mais Maxime le sera, et je peux fournir de l'aide
par mail/téléphone au besoin. Je noterais tout de même que NxOS est
encore beaucoup plus brut de décoffrage que le firmware officiel ou
d'autres solutions existantes. Personellement ça m'intéresserait,
parce que NxOS est plus proche du vrai matériel que les abstractions
de Lego, et n'essaye pas de cacher la complexité de la plateforme,
donc ca me parait pertinent pour des ingénieurs en systèmes embarqués.
Mais je me demande si des étudiants ne risquent pas d'être un peu
traumatisés par ca comme première approche d'OS embarqués...
Sinon, en ce qui concerne le problème de Mercurial et le proxy, c'est
un bug connu qui empêche de se connecter en SSL via un proxy. Pour y
remédier, j'ai déployé une copie de l'hébergement sur
http://nxt.natulte.net/nxos/hg . Vous devriez pouvoir interagir avec
les dépots en utilisant Mercurial, il faut juste configurer le proxy.
Mettez ceci dans le fichier /home/ogrunder/.hgrc :
[ui]
username = Olivier Grunder <olivier...@utbm.fr>
[http_proxy]
host = proxy.utbm.fr:3128
La première directive est juste cosmétique, pour que les commits
portent votre nom, plutot qu'un machin générique qu'il tente de
deviner à partir des infos utilisateur. La deuxième devrait faire
tomber en marche mercurial pour du http://, à partir de machines
cablées au réseau UTBM (pas les machines depuis la zone portable, il
faut une authentification en plus).
Enfin, j'ai mis à jour le dépot devel (hg clone
http://nxt.natulte.net/nxos/hg/devel), il contient maintenant une
copie des sources avec un Marvin qui devrait compiler (ca marche ici).
Le noyau est encore instable, il exhibe le bug de plantage que j'avais
évoqué à la soutenance. Les tentatives de corriger ce problème sont
encore en foutoir dans une copie locale, en attendant que j'identifie
le problème exact.
Si vous êtes dispo cet après-midi (mercredi), je peux venir pour aider
à résoudre les problèmes restants, voir ce qu'on peut faire pour
rendre la plateforme plus facile à utiliser, et discuter des TX/LO52.
Et sur ce, il est l'heure d'aller dormir :-).
- David