Bueno aunque no voy a agregar contenido voy a dejar un link
a una sección de mi página oficial que contendra los links a
los articulos que he escrito previamente, como referencia
ya que no he respetado ningún formato intuitivo para que sean
faciles de encontrar.
Aquí va: Valkertown AVR Guide
EOP
Bueno, aunque no he terminado con el desarrolo sobre USB, dejo escritas ya las
conclusiones.
Antes de empezar con las conclusiones hago una pequeña introduccion al problema.
Para las aplicaciones de tiempo real se requiere, primero , que todas las operaciones se
realizen en intervalos determinados con minimas varaciones; segundo, una fiabilidad de la
informacion tan cercano al 100% como sea posible, pero la aplicacion puede ser un poco más
tolerante a errores. Para el caso del USB lo que se desea es transmitir ya sea bloques
asincronicos o rafagas constantes. Por ejemplo, adquisición de señales analogicas y
decisiones de control sensibles al retardo.
Hoy en dia los puertos serie y paralelo de los computadores personales se han ido
reemplazando con puertos USB que son mucho más flexibles y veloces. Las velocidades de
transferencia logradas con dispositivos USB y los bajos costos llevan a pensar en su viab
lidad en los sistemas de tiempo real.
Creo que una de las primeras conclusiones que puedo sacar es que si pretende hacer
desarrollo de aplicaciones de adquisición en windows se enfrenta a el peor de los casos en
cuanto a latencia y versatilidad; El motivo es simple, USB no esta diseñado para
aplicaciones de tiempo real, todos los modos de transmisión presentan alguna
caracteristica que va en contra de los requerimientos del tiempo real.
Si el desarrollo se realiza en Linux, existe la posiblidad de modificar los controladores
del “HOST USB” y establecer un mecanismo para transferencias de tiempo real.
Esto no quiere decir que no se puedan realizar aplicaciones de tiempo real sobre el USB,
sin embargo estas probablemente quedan restringidas a 1 “endpoint” de tipo
interrupción. Para USB “full-speed” el ancho de banda maximo se impone en 64kB/s. Se
supone que tiene un intervalo de 1ms entre paquetes de 64B, sin embargo esto no es cierto,
la realidad es mucho peor (debo incluir estas mediciones).
Existe la posibilidad de utilizar varios enpoints de tipo interrupción para incrementar el
AB. Sin embargo no existe mecanismo alguno para asegurar la secuencia en la que se envian
los paquetes.
El modo “isochronous” para transmitir los datos a pesar de asegurar AB y transferencias
estables, detecta errores pero no los corrige. En USB un paquete marcado como erroneo
significa de 8 a 1024 Bytes perdidos, además de tener tendencia a los errores tipo burst.
Un código de corrección de errores e interleaving son supremamente utiles en este
caso(Incremento exagerado de la distancia en el “data-path” y consumo de ciclos de
proceso).
La única solucion viable para obtener el maximo AB del USB y tener caracteristicas
deseables para un sistema de tiempo real sobre USB requiere de una modificacion del
“HOST-USB” y seguramente romper el estandart. Realizar una implementación seria de esto
esta fuera de mi alcance en este momento, no tengo el tiempo ni motivación suficiente para
solucionar este problema.
Considerando alternativas como Firewire, este tiene caracteristicas muy superiores de AB,
pero el diseño es muy similar al USB.
Bueno estas son las caracteristicas con las que se encuentra la primera vez que se trab ja
con el USB, y la conclusión más grande: Es posible hacer tiempo real con el USB, se tiene
un diseño que va en contra de las necesidades y esto genera complejidad extra y asi mismo
requerimientos y consideraciones adicionales, pero es lo suficientemente flexible y un
gran AB. Es muy importante tener en cuenta que la latencia minima posible es 1ms, las
transferencias se realizan en paquetes grandes de bytes y si se quiere utilizar en
aplicaciones de tiempo real el AB efectivo será muy inferior al disponible.
Eso es todo, como va para el blog, si alguien le resulta interesante y tiene algún
comentario o pregunta estaré encantado de responderlo.
EOP
Que demonios hace el NYET_ENABLED, NYET_DISABLED, en el código de ejemplo de ATMEL parece hacer algo, pero no aparece en ningun datasheet, es más aparece como reservado y sugiere no meterse con estos bits. No es algo muy agradable…
Bien despues de implementar exitosamente las transferneias Isochronous en el uC y un controlador propio para el núcleo de Linux. sin duda es más complicado que los otros métodos pero es el que garantiza el mayor ancho de banda disponible para el dispositivo a costa de fiabilidad.
Unos números rapidos que sirven como guia para calcular el AB disponible en una aplicación que utilice USB.
Una caracteristica especial que se puede ver en las transferencias Isocronous e interrupt es la de tener la minima latencia si a esto se une la idea que todas las transferencias del protocolo USB son iniciadas por el HOST esto implica naturalmente que la velocidad de transferencia y el AB disponible es determinado por el host.
Ahora, el USB esta orientado a la transmisión de paquetes y lleva consigo un diseño round-robin sobre los dispositivos enumerados para la solicitud de un paquete. Según la especificación del USB para dispositivos de velocidad baja y velocidad “completa”(full speed) el intervalo de transmisión de paquetes se define en el enpoint descriptor, esto implica la primera limitación del ancho de banda.
Si de mira el campo INTERVAL del ENDPOINT DESCRIPTOR se ve que este es un BYTE, este indica el número de milisengundos(ms) entre petición y petición, esto es igualmente cierto para transferencias Isoc e Int. Para dispositivos de alta velocidad este número es de 1/8ms.
El sigueinte parámetro que determina el AB disponible es el tamaño del paquete; para transferencias tipo Int el maximo es de 64bytes y para transferencias tipo Isoc es de 1023 para velocidad completa y 1024 para alta velocidad.
Si se quiere ver la tabla completa de tamaños de paquetes disponibles y de intervalos disponibles para el USB toda esta información esta en la especificación del USB.
Ahora lo que me interesa, con estas dos consideraciones el calculo resulta muy simple:
AB = PACKETSIZE / INTERVAL [KBps]
Si bien este es el AB Maximo disponible sin considerar la probabilidad de error y sin tener en cuenta las limitaciones propias de cada implementación.
Para el AT90USB128 el máximo AB posible es de 512KBps, por las propias limitaciones del hardware.
Una caracteristica muy importante de este sistema es que el HOST puede tomar decisiones sobre el AB desde la enumeración de los dispositivos, y los dispositivos deben tener tener en cuenta que es posible que al solicitar un AB con estos dos parametros el HOST puede rechazar la configuración. Por esto se recomienda incluir diferentes interfaces si es posible con diferentes AB para asegurar el funcionamiento del dispositivos en tantos casos como sea posible.
Referencia: USB 2.0 Specification
Eso es todo, EOP
Bueno luego de solucionar todos los problemas que aparecieron en mi implementación del USB en una tarjeta de desarrollo propia, puedo empezar a hablar sobre las consideraciones y cosas que he encontrado hasta el momento del USB.
El problema que se debe enfrentar la implementación que realice del USB es el de transmitir la información a la mayor velocidad posible, esto implica optimizar los siguientes parametros
En el protocolo USB existen tres formas de transmitir la información y de estas solo dos parecen interesantes para la el problema, Bulk e Isochronous.
El principal problema de utilizar Isochronous en esta aplicacion es la integridad de la información, ya que este no la aseura.
En bulk el problema es que el ancho de banda no es garantizado por el host, y se debe intentar concentrar la transmisión de la información.
El mayor de todos los inconvenientes del USB es la integración con un esquema de tiempo real, pues al ser estar todo el control al lado del HOST, depende de este asegurar el tiempo real en la transmisión de los datos o un esquema de marcas de tiempo para los datos, lo que implica un aumento en el AB necesario para la transmisión.
Asegurar el tiempo real en la implementación del HOST-USB de Linux aun me elude, pero es trabajo en progreso.
En cuanto a las transmisiones BULK el tamaño del paquete influye en la velocidad de transmisión, naturalmente es de esperarse, por lo que se debe escoger el tamaño del paquete lo más grande que permita la implementación y la configuración.
Por ahora esto, más consideraciones a medida que progrese.
Hasta ahora he logrado velocidades de 7KBps, 14KBps y 36KBps. Es aun muy bajo para lo que se espera del USB que es cerca de 900KBps, pero es muy dependiente de todas las implementaciones por lo que aun falta investigar más.
EOP
Bien, una buena noticia ya tengo completamente funcional el sistema USB, luego de resolver una serie de problemas.
EL código de ejemplo de ATMEL para GCC tiene problemas de impementación, el motivo es el siguiente,
en el código de ATMEL se definen los “descriptors” de la siguiente forma:
Luego para retomar los valores de la flash:
Aparentemente GCC tiene problemas para calcular la posición de memoria en flash si se trata de esta forma la estructura, luego de hacer unos experimentos llegue a que la mejor forma para tratar este problema:
De esta forma GCC si calcula bien las direcciones en flash para los “descriptors”, en el código de ATMEL existen dos referencias explícitas a este problema, marcadas con #warning, sin embargo existen otros más que es imperativo corregir.
De aqui en adelante he de modificar completamente el funcionamiento, pues HID no es adecuado para mi aplicación.
Algunas lecturas muy interesantes escritas por Eric S. Raymond’s, uno de mis autores favoritos.
Eso es todo por ahora.
EOP
OK, hoy volvi a trabajar un rato con este chip:
Logre compilar el código de ejemplo de Atmel con algunos inconvenientes por que este código viene para windoze y toco cambiar unos \ por /, me tomo demasiado tiempo darme cuenta de eso -_-, para futura referencia.
Luego cargue el .hex que genero de este ejemplo con mi uisp modificado y en el dmesg de mi kernel, sale lo siguiente:
usb 2-1: new low speed USB device using ohci_hcd and address 2
usb 2-1: device descriptor read/64, error -110
usb 2-1: device descriptor read/64, error -110
usb 2-1: new low speed USB device using ohci_hcd and address 3
usb 2-1: device descriptor read/64, error -110
usb 2-1: device descriptor read/64, error -110
usb 2-1: new low speed USB device using ohci_hcd and address 4
usb 2-1: device not accepting address 4, error -110
usb 2-1: new low speed USB device using ohci_hcd and address 5
Este ejemplo según parece maneja una interface USB-USART, utiliza un scheduler sin continuación, esta demasiado bien estructurado parece, pero tiene un reguero de directorios y referencias que hacen molesto seguir el funcionamiento. Me queda una tarea larga para terminar de comprender como se usa el USB en este dispositivo, quiza empieze la siguiente prueba con los HID.
EOT
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
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
Deepspawn@identica
Recent Comments