Archive

Posts Tagged ‘usb’

DS1M12 usb osciloscope in linux and python

October 1st, 2008
Well, today in the afternoon I was given a task, make the Usb Instruments DS1M12 usb osciloscope in linux, it was quite a surprise
to find out it had some kind of support for Linux and I started my work with their sources.

I found it requires two downloads one from USB Instruments itself and another from a thirdparty driver

Well, those two comes with some .so files you need to link your programs so you need to make sure
they have proper names like libDS1M12.so, libftd2xx.so and they can be found in the LD_LIBRARY_PATH or something like that, this is important.

After you get this solved it’s pretty straightforward with the USB Instruments package comes a good example you can use to understand their library, this took a bit of time since we(called some one to help me pinpoint some problems) could get it working and seeing the data flow quite fast, yet, it took us some time to discover that the sample code enabled the testmode and instead of real sampling, after that we could see the two channels sampling also the signal generator send out the example signals.

After this we agreed that it would be good to have a python interface to this osciloscope and I started working with swig to generare a proper wrapper around the USB Instruments library, around an hour ago I finished what we could call the first release of the interface and I’m being able to plot some data using matlplot lib. It took me a bit to figure how to manage to wrap some of the functions yet in the end swig and numpy solved all my issues.

I’m not really sure If I can release everything at the moment, I think I’ll have to ask USB Instruments since I use one of their headers to build the swig wrapper and it requires some minor modifications to make it work nicely so I would have to publish the modified header. If i get permission or any idea how I should publish the repository, it will be here at valkertown Mercurial Repositories

For now you have to beleive me that now the use of this osciloscope it’s reduced to something like this

  1.  
  2. """
  3.   Author: Carlos Andres Perilla
  4.   Centro Internacional de Física, Bogotá-Colombia.
  5.  
  6.   This program is free software: you can redistribute it and/or
  7.   modify it under the terms of the GNU Affero General Public License
  8.   as published by the Free Software Foundation, either version 3 of
  9.   the License, or (at your option) any later version.
  10.  
  11.   This program is distributed in the hope that it will be useful, but
  12.   WITHOUT ANY WARRANTY; without even the implied warranty of
  13.   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  14.   Affero General Public License for more details.
  15.  
  16.   You should have received a copy of the GNU Affero General Public
  17.   License along with this program.  If not, see
  18.   <http://www.gnu.org/licenses/>.
  19.  
  20. """
  21.  
  22. from Osciloscope import UsbOsciloscope
  23. from pylab import *
  24. import time
  25.  
  26. o = UsbOsciloscope()
  27. # Load the firmare into the osciloscope FPGA, this the RFB that comes in the USBI pack.
  28. o.program()
  29. # Enables both channels for sampling
  30. o.set_channels()
  31.  
  32. while True:
  33.     # Start signal, it gets some other params like
  34.     # triggering configuration, port conf and a lot of other things
  35.     o.start_scan()
  36.     status = -1
  37.     while status != 0:
  38.         # Do the actual reading of a single frame
  39.         retval = o.get_data()
  40.         status = retval[0]
  41.         if status != 0:
  42.             # Since the buffers can be large and the according
  43.             # to the sampling rate we may need to wait a bit
  44.             time.sleep(0.01)
  45.         else:
  46.             # If we got the data successfully we can now plot what we got using
  47.             # matplot lib.
  48.             values = retval[5].dwNumValuesReturned
  49.             x_axis = arange(0,values,1)
  50.             plot(x_axis ,retval[2][0:values],‘r–’,x_axis,retval[3][0:values],‘bs’)
  51.             show()
  52.  

Enlaces y noticias , , , , , , ,

USB y Tiempo Real

May 17th, 2007

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 , , , ,

AT90USB128, Update

April 19th, 2007

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…

Enlaces y noticias , , ,

Notas sobre el USB: Velocidad de Transferencia

February 8th, 2007

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

Enlaces y noticias , , , ,

Dos excelentes fuentes de documentación para Drivers Linux y USB

February 6th, 2007

Voy a realizar una pequeña reseña de dos documentos sumamente utiles para el desarrollo de drivers USB para Linux.

Linux Device Drivers, Third Edition

Este libro es uno de aquellos que no se pueden omitir como referencia en cada desarrollo, contiene casi todo lo que se necesita saber para crear drivers de toda clase, con un estilo muy particular.

El libro presenta la documentación necesaria para crear las tres clases principales de dispositivos en linux, character, block y net. Así como los mecanismos necesarios para registrar memoria, manejar dispositivos USB y PCI, enumeración mayor/minor automatica(nuevo para Kernel 2.6).

En general el libro destaca por presentar una fuente de información de las particularidades de los últimos cambios en la linea 2.6 del kernel de linux, y un gran número de valiosos consejos muy útiles para escribir drivers mucho más limpios y eficientes.

Programming Guide for Linux USB Device Drivers

Este segundo libro se trata más de una referencia particular a los drivers USB; contiene la información concreta de la implementación de dispositivos de carácteres y presenta una información más detallada sobre las diferentes formas de realizar transferencias en el USB.

EOP

Enlaces y noticias , , , ,

Notas sobre implementación del DAQ-USB

February 5th, 2007

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

  • Tamaño del paquete
  • Numero de paquetes por segundo
  • Ancho de bandaasignado por el HOST
  • Fuente de información
  • Scheduler del uC

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

Enlaces y noticias , , , ,

Actualización AT90USB128, y lecturas adicionales.

February 1st, 2007

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:

  1.  
  2. struct usb_XXX_descriptor {
  3.     U8 length,
  4.     U8 type,
  5.     …
  6. };
  7. code struct usb_XXX_descriptor USB_xxx_descriptor_flash = {
  8.   … //Inicialización
  9. };
  10.  

Luego para retomar los valores de la flash:

  1.  
  2. code * pbuff;
  3. pbuff=&(USB_xxx_descriptor_flash.size);
  4. byte=pgm_read_byte_near(*pbuff++);
  5.  

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:

  1.  
  2. struct S_usb_XXX_descriptor {
  3.   U8 length,
  4.   U8 type,
  5.   …
  6. };
  7.  
  8. union PS_usb_XXX_descriptor{
  9.    struct S_usb_XXX_descriptor desc;
  10.    char ptr[sizeof(PS_usb_XXX_descriptor)];
  11. }
  12.  
  13.  
  14. code union  PS_usb_XXX_descriptor USB_xxx_descriptor_flash = {{ // <<— Importante!!
  15.   … //Inicialización
  16. }};
  17.  
  18.  
  19. pbuff=USB_xxx_descriptor_flash.ptr;
  20.  
  21.  

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

Enlaces y noticias , , ,

AT90USB128 Actualización

December 26th, 2006

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

Enlaces y noticias , , , ,

AT90USB128

December 21st, 2006

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

Enlaces y noticias , ,