pxaRC - Logiciels pour le modélisme et la robotique sur Linux/PXA255/PXA270

$ tar zxvf pxarc-$VERSION.tar.gz
$ cp -r pxarc-$VERSION/package/buildroot $SOMEWHERE/gumstix-buildroot/package/pxarc
$ cd $SOMEWHERE/gumstix-buildroot/
$ echo 'source "package/pxarc/Config.in"' >> package/Config.in    # Optionnel (pour voir pxaRC dans menuconfig).
$ make                                                            # Compile les outils si nécessaire.
$ make TARGETS="linux pxarc"                                      # Compile pxaRC.
$ ls build_arm_nofpu/root/lib/modules/*/misc/                     # Vérifier la présence des nouveaux modules. 

$ tar zxvf pxarc-$VERSION.tar.gz
$ cd pxarc-$VERSION/src
$ vi Makefile    # Modifier $(BR) et $(LINUX_VERSION)
$ make
$ scp *.ko root@$IPADDRESS:
$ scp iprc_rx.target root@$IPADDRESS:iprc_rx
$ scp ppmrelay.target root@$IPADDRESS:ppmrelay
$ scp short2ascii.target root@$IPADDRESS:short2ascii
$ scp ascii2short.target root@$IPADDRESS:ascii2short
$ scp long2ascii.target root@$IPADDRESS:long2ascii
$ scp ascii2long.target root@$IPADDRESS:ascii2long

pxa_rtsched.ko gère des tâches temps réel à l'aide des fast interrupts (FIQ) du PXA. Ses fonctionnalités principales sont :

pxa_rtsched est conçu pour être utilisé par d'autres modules du noyau tels que pxa_opwm et pxa_ipwm via l'API pxa_rtsched.h. Il n'a aucune interface accessible par l'utilisateur, hormis l'affichage de statistiques dans dmesg lors du déchargement.

Le timer a une période de 271 ns pour le PXA255 et 308 ns pour le PXA370, ce qui correspond à une résolution d'environ 12 bits dans le contexte de signaux R/C. En pratique, pour une raison encore non identifiée, la gigue et la latence peuvent atteindre ±3 µs sur un processeur 200 MHz très chargé. Ceci reste acceptable pour de nombreuses applications (la plupart des servos R/C ont un hystérésis de plusieurs microsecondes).

Figure 5.  Impulsions de 20 µs générées par pxa_rtsched, avec une gigue de ±2 µs

pxa_rtsched utilise le registre OSMR1 du timer 1, qui est en principe disponible sur Linux ARM. OSMR0 est utilisé par le timer système, et OSMR3 par le watchdog.

Les astuces suivantes permettent de réduire la latence :

pxa_opwm.ko est un générateur de signaux PWM/PPM pour processeurs PXA255 et PXA270. Il se présente comme un module noyau Linux chargeable dynamiquement. Il peut être configuré pour générer un signal PPM multi-canal unique et/ou les signaux PWM correspondants. Les signaux peuvent être émis sur n'importe quelque broche GPIO.

pxa_opwm n'utilise pas les générateurs PWM hardware du PXA.

pxa_opwm remplace pxa_mpwm, version antérieure avec une résolution de 8 bits.

Figure 6.  Signaux générés en mode PPM ; explication des réglages de timing

Les broches GPIO, canaux et temporisations sont configurés à l'aide des paramètres du module, comme illustré ci-dessous (Tableau 2, «  Exemples de configurations pour le module pxa_opwm  »).

Un processus utilisateur contrôle pxa_opwm en écrivant des entiers non signés sur 16 bits en orientation native (host endianness) dans un device (voir Tableau 3, «  Devices pxa_opwm  »). Les signaux sont générés dès que le programme a ouvert le device et initialisé les valeurs de tous les canaux.

Lorsque le programme libère le device, les sorties repassent au niveau logique 0. Ceci provoque généralement l'arrêt des variateurs de vitesse et la mise en veille des servos. Cette fonction de sécurité peut être désactivée en ajoutant persistent=1 dans le paramétrage du module.

pxa_opwm est une application directe de pxa_rtsched. Pour générer une trame PPM de N impulsions, pxa_opwm enregistre une séquence temporisée de 2*N tâches dans l'ordonnanceur (N pour les transitions montantes, N pour les transitions descendantes). Les signaux PWM optionnels correspondants sont générés par les même tâches.

pxa_ipwm.ko est un décodeur de signaux PWM/PPM/DCM et compteur d'impulsions à base d'interruptions GPIO. Il se présente comme un module noyau Linux chargeable dynamiquement.

Les broches GPIO, formats des signaux et temporisations sont configurés à l'aide des paramètres du module comme illustré ci-dessous (Tableau 4, «  Exemples de configurations pour le module pxa_ipwm  »).

Figure 7.  Décodage PWM ; explication des paramètres

Figure 8.  Décodage PPM ; explication des paramètres

Figure 9.  Décodage DCM ; explication des paramètres

Un processus utilisateur interroge pxa_ipwm par l'intermédiaire de devices (voir Tableau 5, «  Devices pxa_ipwm  »).

En mode PWM/PPM/DCM, read() renvoie l'erreur -ETIMEDOUT si aucune mesure datant de moins de timeout n'est disponible. Si le signal ne respecte pas les temporisations configurées, read() renvoie -EIO (cf. figures). Sinon il renvoie la mesure la plus récente (sans attendre l'impulsion suivante). Le format des valeurs de canaux est le même que pour pxa_opwm.

En mode compteur, read() renvoie un entier non signé de 32 bits en orientation native (host endianness). Le premier appel à read() renvoie immédiatement la valeur courante du compteur. Chaque appel suivant attend que le compteur s'incrémente. Il peut y avoir une latence (configurable par timeout=...) ; ceci est dû au fait qu'il est difficile de faire réveiller un process utilisateur par une tâche FIQ.

Un compteur d'impulsions peut être réinitialisé à une valeur arbitraire en écrivant dans le device. Cependant, il n'est pas prévu de pouvoir lire et effacer un compteur de façon atomique.

pxa_ipwm s'enregistre auprès de pxa_rtsched pour recevoir les interruptions sur transitions GPIO. Le handler FIQ enregistre un horodatage de chaque transition dans une file FIFO (implémentée par un buffer cyclique), et ces données sont converties en valeurs PWM/PPM/DCM lorsque read() est appelé. Le handler FIQ incrémente aussi les compteurs d'impulsions.

Il existe des alternatives à pxa_ipwm pour la plate-forme Gumstix ; voir par exemple [ROBOSTIX_RC_INPUT].

pxa_cfcam.ko capture des images en provenance d'un capteur CMOS connecté directement sur le port PCMCIA/CF du PXA255. L'interfaçage est décrit dans [CFCAM].

Fonctionnalités :

pxa_cfcam_pnm.ko est un plugin pour pxa_cfcam qui transforme les données du capteur CMOS au format Bayer en images non compressées au format PNM (couleur 24 bits ou niveaux de gris 8 bits). Le header PNM peut être supprimé avec l'option pnm_header=0.

# modprobe pxa_cfcam
# modprobe pxa_cfcam_pnm
# dd if=/dev/cfcam0 of=/tmp/image.ppm bs=2M count=1

# modprobe pxa_cfcam
# modprobe pxa_cfcam_pnm bpp=1
# dd if=/dev/cfcam0 of=/tmp/image.pgm bs=2M count=1

# modprobe pxa_cfcam
# modprobe pxa_cfcam_pnm pnm_header=0

/* Exemple simplifié sans traitement des erreurs. */
int fd = open("/dev/cfcam0", O_RDWR, 0);
unsigned char *mem = mmap(NULL, 320*240*3*2, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
while ( 1 ) {
  u32 offset;
  read(fd, &offset, sizeof(offset));
  unsigned char *rgb = mem + offset;
  /* 'rgb' pointe vers une image RVB de 320*240*3 octets */
}

L'implémentation est encore très rudimentaire. La liste des configurations supportées est figée dans pxa_cfcam.c. La configuration à utiliser est sélectionnée à l'aide du paramètre de module sensor=N. Pour gérer un nouveau capteur ou un nouveau format d'image, il faut modifier le code source.

Pour déterminer les caractéristiques d'un nouveau capteur, on peut commencer par enregistrer une image brute de la façon suivante :

# modprobe pxa_cfcam sensor=0
# modprobe pxa_cfcam_pnm raw=1 bpp=1
# dd if=/dev/cfcam0 of=/tmp/image.pgm bs=2M count=1

pxa_cfcam commence par actionner l'entrée reset du capteur, et envoie optionnellement des commandes I2C pour le configurer. Il émet également le nombre d'impulsions d'horloge requis pour que le capteur achève son initialisation et commence à produire des images.

Ensuite, une liste circulaire de descripteurs DMA lit en permanence les données brutes du capteur CMOS, et le cadence par la même occasion. Les données reçues pendant les intervalles de synchronisation horizontale et verticale sont ignorées.

Des interruptions DMA sont générées à la fin de chaque ligne. En mode synchrone (sans utiliser mmap()), pxa_cfcam transfère et convertit les données depuis le buffer DMA vers le buffer référencé dans l'appel système read(). En mode asynchrone (avec mmap()), pxa_cfcam transfère et convertit les données depuis le buffer DMA vers la moitié d'un buffer mmapé au préalable, pendant que le process utilisateur travaille sur l'autre moitié. Les deux moitiés sont échangées lors de chaque appel système read().

pxa_cfcam n'utilise pas les sorties HSYNC and VSYNC du capteur. Ceci nécessite que les nombres de cycles d'horloge de chaque image et de chaque intervalle de synchronisation soient connus à l'avance.