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
Enlaces y noticias
avr, programación, Proyectos, tiempo real, usb
Recent Comments