Va de nuevo. Llevo muchos intentos de mantener un blog con ideas probadas y por probar. En una de esas este sí pega. A ver que pasa....
Para arrancar, decido compartirte una lista de acciones a tomar para que el fabuloso MSP430 Launchpad de Texas Instruments sea accessible para un usuario GNU/Linux que no sea root.
¿Cuál es el diagnóstico? Con tu Launchpad conectado a un puerto USB y con el programa mspdebug instalado (yo lo tengo disponible en los repositorios de mi distribución Fedora), ejecuta:
[oscar@oys ~]$ mspdebug rf2500
Trying to open interface 1 on 033
rf2500: warning: can't detach kernel driver: Operation not permitted
rf2500: can't claim interface: Operation not permitted
rf2500: failed to open RF2500 device
y lo más probable es que recibas una respuesta como la anterior, que indica que como usuario estándar, limitado únicamente a poderes terrenales sobre tu sistema, no tienes acceso al fichero dinámico que da el acceso a la Launchpad. Pero no todo está perdido.
El sistema udev de GNU/Linux facilita la configuración automática de dispositivos USB, mediante la elaboración de "reglas" de conexión. Estas reglas residen (para Fedora) en el directorio /etc/udev/rules.d, y bastará con agregar una para el Launchpad a modo de que al conectarse, el sistema udev genere un fichero dinámico en /dev (típicamente /dev/ttyACM0) con los permisos adecuados. Vamos por partes.
Primero, verifica las claves de identificación de tu Launchpad. Conecta el dispositivo a un puerto USB y ejecuta:
[oscar@oys ~]$ lsusb | grep -i Texas
Bus 001 Device 007: ID 0451:f432 Texas Instruments, Inc. eZ430 Development Tool
donde se ve que el dispositivo ttyACM0 (tu acceso serial al Launchpad) tiene los permisos correctos. Ahora, al ejecutar:
[oscar@oys ~]$ mspdebug rf2500
MSPDebug version 0.21 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2012 Daniel Beer <dlbeer@gmail.com>
....
aparece la respuesta esperada y puedes acceder a tu juguete preferido.
Para arrancar, decido compartirte una lista de acciones a tomar para que el fabuloso MSP430 Launchpad de Texas Instruments sea accessible para un usuario GNU/Linux que no sea root.
¿Cuál es el diagnóstico? Con tu Launchpad conectado a un puerto USB y con el programa mspdebug instalado (yo lo tengo disponible en los repositorios de mi distribución Fedora), ejecuta:
[oscar@oys ~]$ mspdebug rf2500
Trying to open interface 1 on 033
rf2500: warning: can't detach kernel driver: Operation not permitted
rf2500: can't claim interface: Operation not permitted
rf2500: failed to open RF2500 device
y lo más probable es que recibas una respuesta como la anterior, que indica que como usuario estándar, limitado únicamente a poderes terrenales sobre tu sistema, no tienes acceso al fichero dinámico que da el acceso a la Launchpad. Pero no todo está perdido.
El sistema udev de GNU/Linux facilita la configuración automática de dispositivos USB, mediante la elaboración de "reglas" de conexión. Estas reglas residen (para Fedora) en el directorio /etc/udev/rules.d, y bastará con agregar una para el Launchpad a modo de que al conectarse, el sistema udev genere un fichero dinámico en /dev (típicamente /dev/ttyACM0) con los permisos adecuados. Vamos por partes.
Primero, verifica las claves de identificación de tu Launchpad. Conecta el dispositivo a un puerto USB y ejecuta:
[oscar@oys ~]$ lsusb | grep -i Texas
Bus 001 Device 007: ID 0451:f432 Texas Instruments, Inc. eZ430 Development Tool
Las claves de identificación tienen la forma IDVendor:IDProduct, de acuerdo a las especificaciones de USB. En mi caso (y muy seguramente en el de todos los que tengan una tarjeta Rev 1.5), las claves son 0451:f432. Estas serán usadas en la escritura de las reglas de conexión udev.
Ahora, a escribir el archivo de reglas. Se requiere acceso de administrador para crear un archivo en /etc/udev/rules.d, así que por el medio que acostumbres gana acceso de administrador y crea el archivo 10-launchpad.rules. Mi versión particular para hacer esto es (yo tengo configurado el archivo /etc/sudoers):
[oscar@oys ~]$ sudo vi /etc/udev/rules.d/10-launchpad.rules
ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f432", MODE:="0660", GROUP:="plugdev"
~
La linea que comienza con ATTRS es la que hay que escribir en el archivo de reglas. Nota que usé el IDVendor y el IDProduct que reportó lsusb. Esta regla dará acceso de lectura/escritura al administrador y al grupo 'plugdev'. Para que la regla sea útil para tí, agrega plugdev a tu lista de grupos:
[oscar@oys ~]$ sudo usermod -a -G plugdev oscar
Como las asociaciones de grupo se realizan en el login, debes cerrar tu sesión y volver a ingresar para que quedes como miembro de plugdev, lo cual puedes verificar luego de tu reingreso con:
[oscar@oys ~]$ groups
oscar wheel tty dialout lock plugdev bumblebee vboxusers
Falta únicamente decirle al sistema que considere las nuevas reglas de udev. Para ello ejecuta:
Ahora, a escribir el archivo de reglas. Se requiere acceso de administrador para crear un archivo en /etc/udev/rules.d, así que por el medio que acostumbres gana acceso de administrador y crea el archivo 10-launchpad.rules. Mi versión particular para hacer esto es (yo tengo configurado el archivo /etc/sudoers):
[oscar@oys ~]$ sudo vi /etc/udev/rules.d/10-launchpad.rules
ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f432", MODE:="0660", GROUP:="plugdev"
~
La linea que comienza con ATTRS es la que hay que escribir en el archivo de reglas. Nota que usé el IDVendor y el IDProduct que reportó lsusb. Esta regla dará acceso de lectura/escritura al administrador y al grupo 'plugdev'. Para que la regla sea útil para tí, agrega plugdev a tu lista de grupos:
[oscar@oys ~]$ sudo usermod -a -G plugdev oscar
Como las asociaciones de grupo se realizan en el login, debes cerrar tu sesión y volver a ingresar para que quedes como miembro de plugdev, lo cual puedes verificar luego de tu reingreso con:
[oscar@oys ~]$ groups
oscar wheel tty dialout lock plugdev bumblebee vboxusers
Falta únicamente decirle al sistema que considere las nuevas reglas de udev. Para ello ejecuta:
[oscar@oys ~]$ sudo udevadm trigger
con lo que forzarás la reconexión de los dispositivos y la creación de los ficheros /dev adecuados (En el siguiente reinicio de tu sistema este paso ya no será necesario). Puedes verificar que todo ha quedado listo con:
[oscar@oys ~]$ ls -la /dev/tty* | grep -i plugdev
crw-rw----. 1 root plugdev 166, 0 Oct 13 16:02 /dev/ttyACM0
con lo que forzarás la reconexión de los dispositivos y la creación de los ficheros /dev adecuados (En el siguiente reinicio de tu sistema este paso ya no será necesario). Puedes verificar que todo ha quedado listo con:
[oscar@oys ~]$ ls -la /dev/tty* | grep -i plugdev
crw-rw----. 1 root plugdev 166, 0 Oct 13 16:02 /dev/ttyACM0
donde se ve que el dispositivo ttyACM0 (tu acceso serial al Launchpad) tiene los permisos correctos. Ahora, al ejecutar:
[oscar@oys ~]$ mspdebug rf2500
MSPDebug version 0.21 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2012 Daniel Beer <dlbeer@gmail.com>
....
aparece la respuesta esperada y puedes acceder a tu juguete preferido.
Comments
Post a Comment