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
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.
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
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
Tal como lo esperaba el port de AVR-LUA funciona, con un pequeño defecto, me quede sin RAM simplemente la RAM interna no es suficiente. Es de esperarse que se presente este inconveniente por lo que ya mande cotizar las tarjetas de desarrollo con la RAM extendida para poder avanzar con todos los proyectos que dependen de esto.
EOT
Enlace muy interesante:
Esta página documenta un SBC(Single Board Computer) diseñado para adquisición de imágenes y procesamiento. Es una implementación abierta, lo que significa que los esquemáticos
y el layout están disponibles. Esta plataforma corre Linux/ARM, y es muy fácil de desarrollar. Todas las herramientas de desarrollo son gratuitas. Con excepción de Altera’s Quartus II Web Edition,
la herramientas también son open-source.
Características:
A ver cuantos se animan a armar una por el estilo. Requiere 4 capas pero de todas formas se puede mandar a hacer, me avisan los interesados.
| 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 | ||||||