Re: [nxos-discuss-fr] Présentations !
David Anderson
On 2/29/08, Alexandre Haffner <haffne...@gmail.com> wrote:
> Je m'appel Alexandre Haffner, je vais travailler sur cette TX avec un
> autre étudiant qui devrait se présenter sous peu je suppose.
Bienvenue :-). Je me présente aussi pour l'occase, David Anderson, je
suis le papounet de NxOS, qui a commencé sa vie dans une TX au
printemps dernier. Maintenant je suis en ST50, mais j'ai bien
l'intention de continuer le développement de cet OS, parce que d'une
part c'est très fun, et d'autre part ca peut servir au monde :-).
Sinon, pour le projet, on utilise Trac pour gérer le développement:
http://nxt.natulte.net/nxos/trac . Je ne sais pas si tu as déjà
utilisé Trac, mais il inclut un explorateur de code source, un bug
tracker, et un wiki. Tu remarqueras que tout est en anglais, c'est la
langue qu'on utilise sur le wiki, ainsi que dans le code (commentaires
et messages de commit).
Au niveau controle de code source, on utilise Mercurial, accessible
sur https://ssl.natulte.net/nxos/ . Si tu ne connais pas ce système,
je t'invite à te documenter sur http://selenic.com/mercurial , parce
que pour coder sur NxOS, il va falloir s'en servir :-). Je te crée une
branche du dépot principal demain, pour que tu puisses commencer à
développer. En gros, tu travailles sur ta branche, et de temps en
temps on fait une revue du code, et si c'est bon, on l'intègre au
tronc de développement.
> J'ai lu le premier rapport concernant l'implémentation du premiernoyau
> et tenté de faire tourner la bête. Le tout marche plutot bien et assez
> facilement mais j'ai eu un premier problème en voulant envoyer des
> commandes par l'USB en utilisant le système de tests via le script
> usb_console. J'ai réussi une première
> fois à l'éxécuter et j'ai malencontreusement :) entré une commande non
> reconnue et depuis impossible d'acceder à nouveau à cette interface.
> Voici l'erreur que j'obtient :
>
> Traceback (most recent call last):
> File "./usb_console.py", line 10, in <module>
> from nxt.lowlevel import get_device
> ImportError: No module named nxt.lowlevel
Hmm. Tu dis que tu as réussi à exécuter une première fois la console
USB avant que ca ne plante? L'erreur que tu as ressemble à un problème
de PYTHONPATH, il faut lancer la console USB dans le répertoire
usb_console, en exportant avant un chemin en plus pour que Python
trouve le module pynxt. Depuis le répertoire usb_console:
export PYTHONPATH=`pwd`/../pynxt
./usb_console.py
La console (et surtout le firmware de test sur la brique) sont encore
un peu capricieux, il vaut mieux ne pas quitter/relancer la console
sans également rebooter la brique (en gros, ne pas désassocier la
console de la brique une fois associé).
> Question quand même, apres avoir entré une commande non reconnue ma
> console unix m'a signalée une exception (dont je n'ai pu le souvenir
> malheureusement...). Est-ce le résultat de la ligne de code suivante ?
> (j'en doute)
>
> nx_usb_write((U8 *)USB_UNKNOWN, sizeof(USB_UNKNOWN)-1);
Non. Cette instruction envoit via USB la réponse "unknown" (cherche la
constante USB_UNKNOWN, c'est une chaine), qui s'afficherait alors dans
la console USB pour dire que "ben non, je comprends pas". Si la
console plante avec l'erreur au dessus, elle n'est pas encore associée
a la brique, donc aucune communication avec le firmware.
> Et dernière question concernant les conventions de nommage des
> fichiers. Que signifie
> le underscore devant les noms de fichiers ?
Dans le Baseplate (cf. le deuxième rapport, celui du semestre passé,
pour les détails sur la terminologie), il y a deux interfaces:
l'interface publique, qui est celle qui se trouve dans les fichiers .h
sans underscore. Cette interface est celle que les noyaux applicatifs
peuvent utiliser pour toucher au système. En interne, il faut des fois
que des modules du Baseplate communiquent entre eux, sans pour autant
que ces API soient disponibles pour les noyaux applicatifs. Ces API
internes sont définies dans des headers préfixés d'un underscore.
Le meilleur exemple de ca, c'est nxos/base/drivers/_avr.h, qui
contient l'interface privée du pilote du coprocesseur l'AVR. L'AVR
pilote des fonctions assez diverses, dont le controle moteur, la
gestion des capteurs analogiques, et le controle d'alimentation de la
brique.
Pour les noyaux applicatifs, ces différentes fonctionalités de l'AVR
sont disponibles via des API de plus haut niveau. Par exemple,
nxos/base/core.h définit la fonction nx_core_halt(), qui éteint la
brique en passant par la fonction privée nx__avr_power_down() du
pilote AVR. Mais avant d'apeller cette fonction, elle en invoque
d'autres: un handler de shutdown optionel pour le noyau applicatif, la
fonction de shutdown du pilote LCD (qui doit drainer le convertisseur
à pompe de charge de l'écran pour ne pas l'endommager a l'arrêt), la
fonction de shutdown USB (pour se déconnecter proprement du bus
USB)... Bref, la fonction nx__avr_power_down() n'est que l'étape
finale de l'arrêt du système, et est donc privée, parce qu'il ne faut
pas que le noyau applicatif court-circuite la logique de shutdown
complète.
Si tu envisages NxOS comme une pile de couches, les headers
underscorés sont destinés uniquement à la communication horizontale au
sein d'une même couche (ici, le baseplate), alors que les autres
headers sont destinés à une utilisation verticale, par la couche au
dessus.
Quelques unes des conventions de code sont répertoriées sur le wiki,
sur http://nxt.natulte.net/nxos/trac/wiki/NxOS/CodingStyle
> J'espère qu'on va bien s'amuser et produire quelque chose qui vous
> servira :)
J'espère bien, mais ca ne devrait pas poser de problème. :-)
- Dave
Alexandre Haffner
Concernant Trac et mercurial je vais me documenter, j'avais l'habitude
de SVN ca ne devrait pas trop me changer j'espere.
Concernant le problème avec usb_console c'était bel et bien cette
histoire de pythonpath, je l'avais bien réglé la première fois et
après le bug de la console j'ai oublié de le remettre... :) D'ailleur
j'ai eu cette erreur à nouveau mais il semblerait que ce soit une
exception du script python justement :
Exception in thread Thread-1:
File
self.run()
File "threading.py",
line 440, in run
self.__target(*self.__args, **self.__kwargs)
File "./
usb_console.py", line 51, in output_thread
log.addstr(logpos, 1, repr(data[1])[1:-1],
curses.color_pair(data[0]+1))
error: addstr() returned ERR
Pour les conventions de nommage et style de code, merci pour les
références, je n'avais pas eu le temps de tout lire... j'ai récuperé
les documents et la bête hier après midi :) En tout cas tout est bien
clair maintenant, parfait. A priori je n'aurais donc pas à utiliser de
fonctions issues des fichiers _xxx s'il y a leur pendant public dans
les fichiers sans underscore.
Sinon j'ai refais tout un tas de petits essais tout à fait
concluants !
J'ai cependant fait je crois face à une petite erreur au niveau du
fimware de tests, fichier test.c :
http://nxt.natulte.net/nxos/trac/browser/nxos/systems/tests/tests.c#L647
Lors du test usb et de l'appel des fonctions "display" puis "sound"
j'obtient sur le lcd l'affichage de "sounda" avec le "a" résiduel du
"display" je suppose. L'appel à "i = tests_command(buffer, lng);"
n'est pas affecté etant donné que la longueur est transmise. Si je ne
me trompe pas, lng contient le nombre d'octet passés par l'usb (sans
le \0). On veut donc savoir si cette commande + \0 rentre dans le
buffer et si oui placer \0 juste après la commande, c'est à dire à
l'index lng et non pas lng+1.
lng = 5
s o u n d \0
0 1 2 3 4 5
A la place de :
649 if ((lng+1) < NX_USB_PACKET_SIZE)
650 buffer[lng+1] = '\0';
651 else
652 buffer[NX_USB_PACKET_SIZE-1] = '\0';
J'aurais bien vu :
649 if ((lng+1) < NX_USB_PACKET_SIZE)
650 buffer[lng] = '\0'; <<<
651 else
652 buffer[NX_USB_PACKET_SIZE-1] = '\0';
Merci de me confirmer ça, j'ai peu êter raté quelque chose :)
A bientôt !
Alex
>
> > Je m'appel Alexandre Haffner, je vais travailler sur cette TX avec un
> > autre étudiant qui devrait se présenter sous peu je suppose.
>
> Bienvenue :-). Je me présente aussi pour l'occase, David Anderson, je
> suis le papounet de NxOS, qui a commencé sa vie dans une TX au
> printemps dernier. Maintenant je suis en ST50, mais j'ai bien
> l'intention de continuer le développement de cet OS, parce que d'une
> part c'est très fun, et d'autre part ca peut servir au monde :-).
>
> tracker, et un wiki. Tu remarqueras que tout est en anglais, c'est la
> langue qu'on utilise sur le wiki, ainsi que dans le code (commentaires
> et messages de commit).
>
> Au niveau controle de code source, on utilise Mercurial, accessible
> je t'invite à te documenter surhttp://selenic.com/mercurial, parce
David Anderson
complètement oublié de répondre.
2008/2/29 Alexandre Haffner <haffne...@gmail.com>:
> Concernant Trac et mercurial je vais me documenter, j'avais l'habitude
> de SVN ca ne devrait pas trop me changer j'espere.
Ca change un peu, mais pas trop. Je pense que tu as du découvrir entretemps :-).
> Exception in thread Thread-1:
>
> Traceback (most recent call last):
> File
> "threading.py", line 460, in __bootstrap
> self.run()
> File "threading.py",
> line 440, in run
> self.__target(*self.__args, **self.__kwargs)
> File "./
> usb_console.py", line 51, in output_thread
> log.addstr(logpos, 1, repr(data[1])[1:-1],
> curses.color_pair(data[0]+1))
> error: addstr() returned ERR
Oula, ca comme ca je ne vois pas ce que ca pourrait être, ca ne m'est
jamais arrivé. Ca t'arrive encore?
> Pour les conventions de nommage et style de code, merci pour les
> références, je n'avais pas eu le temps de tout lire... j'ai récuperé
> les documents et la bête hier après midi :) En tout cas tout est bien
> clair maintenant, parfait. A priori je n'aurais donc pas à utiliser de
> fonctions issues des fichiers _xxx s'il y a leur pendant public dans
> les fichiers sans underscore.
Voila. Et si tu dois te servir des fonctions dans _xxx.h depuis un
noyau applicatif, reflechis un gros coup pour savoir si c'est vraiment
une bonne idée, et si tu penses que oui, lance une discussion ici.
C'est peut-être une fonction qu'il est utile de rendre publique :-).
> Sinon j'ai refais tout un tas de petits essais tout à fait
> concluants !
> J'ai cependant fait je crois face à une petite erreur au niveau du
> fimware de tests, fichier test.c :
>
> http://nxt.natulte.net/nxos/trac/browser/nxos/systems/tests/tests.c#L647
>
> Lors du test usb et de l'appel des fonctions "display" puis "sound"
> j'obtient sur le lcd l'affichage de "sounda" avec le "a" résiduel du
> "display" je suppose. L'appel à "i = tests_command(buffer, lng);"
> n'est pas affecté etant donné que la longueur est transmise. Si je ne
> me trompe pas, lng contient le nombre d'octet passés par l'usb (sans
> le \0). On veut donc savoir si cette commande + \0 rentre dans le
> buffer et si oui placer \0 juste après la commande, c'est à dire à
> l'index lng et non pas lng+1.
>
> lng = 5
> s o u n d \0
> 0 1 2 3 4 5
>
> A la place de :
>
> 649 if ((lng+1) < NX_USB_PACKET_SIZE)
> 650 buffer[lng+1] = '\0';
> 651 else
> 652 buffer[NX_USB_PACKET_SIZE-1] = '\0';
>
>
> J'aurais bien vu :
>
> 649 if ((lng+1) < NX_USB_PACKET_SIZE)
> 650 buffer[lng] = '\0'; <<<
Ca me semble effectivement être une OBOE (Off By One Error) classique.
Je t'invite à la corriger :-).