Parece que compilar el gcc 4.1.1 es algo molesto, sin embargo existe el AVR-Wiki con instrucciones bastante agradables de como compilar e incluso un script para compilar todo el tool chain.
Por mi parte prefiero hacer todo a mano, pero pues es una bonita alternativa.
Dos set de parches importantes para utilizar el AT90USB128:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-gcc/files/
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-binutils/files/
EOT
Bien, por fin voy a trabajar un poco con USB y AVR.
El AT90USB128 Hasta ahora es una versi’on muy similar al ATMega128 pero se sacrifican algunos modulos funcionales por el controlador USB. El que estoy usando viene en empaquetado QFN64 algo molesto para soldar en el prototipo pero se gana algo de espacio en el PCB a la hora de hacer el final. Es pin a pin compatible con otras versiones de AVR de 64 pines, pero no con el ATMega128 para la programaci’on ISP pues el ATMega128 me consta que hace algunos cambio para esta programaci’on y en este chip estos pines los de la USART0 se utilizan para el driver USB.
Mi versi’on antigua del UISP reconocio el chip como un ATMEGA103 alike, la versi’on CVS lo reconoce como tal, revise el c’odigo fuente del programador e hice unas actualizaciones para que le pusiera bien el nombre y lo tratara como un ATMEGA128 internamente, y con las correcciones en los tamagnos. Las pruebas posteriores han indicado que no hace falta hacer mayores cambios al programador para que funcione. Escribir/leer fusibles, flash y eeprom ha sido exitoso hasta ahora.
Una vez superada esta etapa que me preocupaba sobre las otras, voy a probar GCC 4.1.1 para AVR y Binutils 2.17 y AVR-LIBC CVS por que revisando los changelogs y los fuentes, parece que tiene ya soporte con nombre para el at90usb128.
En unas horas que termine la experimentaci’on har’e un informe de que cambios hay con respecto a el tutorial anterior sobre el tool chain AVR.
EOT
Simulador de Robot con chip ADN simulado
Bueno de mi curso de robotica evolutiva salio esto:
Es una bobada, esta hecho en pygame y vhdl el chip ADN, para simular el VHDL y embederlo en python utilice GHDL, que genera binarios nativos para SO.
Me gusto como quedo el sapito.
EOT
Esto es una nota que va para recordar en el trabajo. Estas bases de datos se ven atractivas para los proyectos que se estan haciendo viejos y tenemos muchos datos que ya solo nos interesan para las estadisticas.
Estando aqu’i en Trieste, un expositor( Paul Bartholdi) presento una idea muy interesante, la creaci’on del programa para el manejo de FAQs desde la linea de comandos. En s’i es m’as bien una base de conocimiento que un grupo de personas mantienen como una coleccion de archivos en sus $HOME.
La idea es crear un archivo .faq_XX donde XX es arbitrario pero se espera que indique el temario de la base
de conocimientos que encierra.
En cada uno de estos archivos, se encuentra el contenido de la siguiente manera:
FAQRC
The file .faqrc , in your $HOME directory, should contain the list of all
the faq files you want to query, in your directories or anywhere else.
KEYWORDS
The line containing keywords must start in column 1 with one or more
keywords characterizing the following text.
A keyword line effectively ends the previous entry.
As’i la primera linea contiene el autor y alguna informaci’on extra. y seguido en mayusculas se colocan las palabras claves para una busqueda, en las lineas siguientes se coloca el contenido relacionado con las palabras clave.
Luego al usar el programa faq:
$faq faqrc
The file .faqrc , in your $HOME directory, should contain the list of all
the faq files you want to query, in your directories or anywhere else.
La idea en si me parece muy buena, para pequegnos grupos, donde es f’acil compartir pequegnos archivos, y no se requiere de un medio de publicaci’on muy formal de la informaci’on adem’as de es la idea de un FAQ respuestas pequegnas a preguntas muy comunes, de esta forma se ahorra uno el tiempo de realizar la investigaci’on.
Por ahora el programa esta escrito en TCSH, ya hice una modificaci’on de este para bash, y tiene un funcionamiento muy basico, lo he mejorado un poco pero pienso que la idea es poderosa y se puede extender un POCO m’as, no es que quiera hacer un gran proyecto a partir de esta idea.
Eso es todo. El c’odigo fuente ya hablare con sus autores originales para ver si lo puedo publicar.
EOT
Hace poco compo parte de un proyecto escribi un m’odulo para el kernel de linux, en especial para el target de ARM9 AT91RM9200.
La idea es sencilla, es un driver para el PIO, que debe generar los siguientes dispositivos:
/dev/port[a-g]
/dev/pin[a-g][0-31]
As’i se puede realizar un acceso directo al PIN individual o a cada puerto en conjunto.
Inicialmente estoy trabajando con el puerto A, y es funcional de la siguietne forma.
echo O > /dev/pina14
echo 0 > /dev/pina14
echo 1 > /dev/pina14
echo I > /dev/pina14
Esto saliio como una necesidad y mi poca experiencia con los device drivers de Linux produjo ese driver.
Sin embargo leyendo el libro Linux Device Drivers con bastante juicio, he encontrado que cometi algunas barbaridades en ese c’odigo, ya que mezcle arbitrariamente mecanismo y politica. Adem’as de no utilizar los mecanismo estandar para el ctlio. Por esto me he comprometido a crear el driver completamente y con un disegno que debe estar terminado para cuando termine el libro, completamente de acuerdo con las especificaciones de disegno de un buen modulo/driver de Linux.
El motivo para crear tal driver, es simple, con el port de linux para ARM9, queremos tener un ambiente de desarrollo muy sencillo para tareas tipo PLC, donde lo que importa es la gestion y no los tiempos de respuesta.
Este mecanismo en el que un simple echo 0 > /dev/pinxx, echo > /dev/pinxxx controla una salida l’ogica permite disegnos de programas muy simples para el control desde un muy alto nivel.
EOT
En estos d’ias durante el curso de Instrumentaci’on Distribuida para Laboratorio, he consumido grandes cantidades de informaci’on sobre sistemas digitales una vez m’as, sin embargo esta vez he caido en cuenta en una de las necesidades b’asicas para poder comunicar el conocimiento que se adquiere en este odioso mundo digital.
Los diagramas de tiempo es la herramienta b’asica para la especificaci’on, transmisi’on y verificaci’on del funcionamiento de dos sistemas digitales que se comunican. Sin embargo hasta la fecha no me he encontrado con una buena herramienta para el disegno y presentaci’on de estos diagramas.
Siempre se puede recurrir a un HDL para generar estos diagramas, pero lo encuentro tedioso y poco disegnado para la creaci’on de un documento o una presentaci’on.
En estos d’ias del curso, he visto toda clase de diagramas, y han sido sumamente deficientes. Esto a’un para los instructores que provienen del CERN o incluso de los mejores adeptos de LaTEX se ven copiando las imagenes que se encuentran den datasheets y cuando este no se encuentra, en general carecemos de capacidades de dibujo suficientes para hacer un diagrama esteticamente correcto.
Si bien es cierto que se logra transmitir la informaci’on, en ocasiones la descripci’on es ambigua y no permite en un aspecto m’as interno del desarrollo, verificaci’on por parte de un programa si se esta cumpliendo o no la especificaci’on del diagrama de tiempo.
Ahora esto me trae una pequegna idea que ya tengo en papel gran parte del disegno y me ha traido buenos ratos de lectura.
La idea por ahora es sencilla, es crear un preprocesador para LaTEX(inicialmente) del estilo circuit macros para disegnar y establecer los diagramas de tiempo de una forma coherente y bien estructurada.
Creo que la idea es muy interesante y para quienes al igual que para mi, programas como graphviz nos hacen la vida m’as f’acil, van a agredecer la escritura de este programa.
Espero poder terminar generar la documentaci’on y la especificaci’on en papel pronto, para poder empezar a crear un pequegno programa de demostraci’on.
Como tengo en las notas, las GUIs significan perdida de tiempo, por lo que algo as’i no esta contemplado para nada en el proyecto.
EOT
Distcc, TOL Awards ?, y me *** la board
Como me urge tener la m\’aquina a sacrificar m\’as plata del viaje a Italia -_-
\end{rant}
\begin{new}
Hoy descubri que estoy nominado como el blog m\’as \~no\~no de la TOL.
Voten por mi XD
\end{new}
\begin{log}
Bueno ahora tengo como pasatiempo compilar gcc,glibc,binutils, kernel y hacer linux from sratch para las nuevas plataformas de desarrollo que los nuevos proyectos exigen.
Como este pasatiempo es sumamente divertido y variado, decid\’i hacerme un favor y configurar en mis maquinitas el distcc para hacerlo un poco menos divertido.
Esto no es nuevo de hecho ya lo hab\’ia hecho antes pero me di cuenta que no tenia en log y me toco buscar en la documentaci\’on nuevamente, para evitar futuros inconvenientes:
Distcc es un programa que permite distribuir la carga de la compilaci\’on en diferentes computadores a traves de la red.
Slack ya tiene instalado el distcc por lo que me importa poco esta parte y sin embargo, es poco relevante.
La configuraci\’on se realiza por m\’aquina que va a recibir pedazos de la compilaci\’on.
\begin{code}
/usr/bin/distccd –daemon –user nobody -a 192.168.1.0/24 –log-file /var/log/distccd.log
\end{code}
Se pueden recibir compilaciones de toda una subred o de un cliente en especial, me interesa una subred para poder compilar desde diferentes terminales.
Esa es toda la “configuraci\’on” necesaria para cada m\’aquina que va a recibir tareas.
Por otra parte si se trata de cross-compilers, como en mi caso, debe estar disponible el kit completo en cada m\’aquina que va a realizar compilaci\’on.
En la m\’aquina principal de compilaci\’on la tarea es:
\begin{code}
export CC=distcc
export DISTCC_HOSTS=”host1 host2 … hostn”
alias make=’make -jn*3+1 # donde n es el n\’umero de m\’aquinas disponibles
\end{code}
Luego de esto, la mayoria de compilaciones con y sin autotools funcionan en el “farm”, sin embargo a veces toca editar los Makefiles y/o otros scripts de compilaci\’on para asegurarse que hace uso del “farm”.
Algo que me toco hacer para asegurarme que make siempre usara todo el farm:
\begin{code}
mv make make_orig
make:
#!/bin/sh
/usr/bin/make_orig -j(n*3+1) $*
EOF
chmod 755 make
\end{code}
Es sucio, se ve feo, pero funciona.
Si se trata de cross-compile, o si no se trata de gcc, se llama distcc seguido del nombre del compilador que se va a usar.
Por si no se noto al principio: Odio tener que compilar la herramientas b\’asicas del sistema y odio a\’un m\’as cuando tengo que hacer linux from scratch, pero me persigue…
\end{log}
\end{post}
La compañia enfora ofrece unos bonitos modems gprs con un GPS integrado, los modems gprs son bastante uniformes en cuanto a su uso.
La parte GPS estos modems soporta dos protcolos para presentar la información NMEA y TAIP, en lo personal prefiero TAIP por no utilizar separadores, solo delimitadores; e incluso utiliza checksum.
Ahora la hora GPS llega a milesimas de segundo sin embargo dada la comunicación serial y los tiempos de respuesta del propio aparato la incetidumbre sobre el tiempo se acerca a 500ms, una pequeña corrección estadistica aproxima este tiempo a unos 10ms.
Aún así queda un error sistematico originado por que se desconoce la latencia entre la toma del tiempo y la transmisión sobre el canal y en este caso se esta aproximando al tiempo total de respuesta, medido desde el fin de la transmisión de la petición.
En algunos GPS existe el concepto de marca de tiempo que sugiere una incertidumbre de 1us, sin embargo la adquisición y correción del tiempo con esta marca de tiempo no es necesaria en esta aplicación. Sin embargo queda nota de su existencia.
EOT
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Jan | ||||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | ||||||