TODOPIC
Microcontroladores PIC => Almacén del Assembler => Mensaje iniciado por: jonathanPIC888 en 16 de Febrero de 2010, 16:04:57
-
Hola a todos :-/
En esta ocación vengo para empezar a desarrollar entre todos una librería de USB usando el lenguaje ensamblador para la familia de microcontroladores PIC18FXX5X.
La razón de esto , es porque hay muchos usuarios que son expertos manejando ASM pero no saben utilizar bien el lenguaje C o lenguajes de alto nivel. También otra razón es que quiero que todos entendamos de una manera más profunda el funcionamiento del módulo USB de la familia microchip...y luego de esto poder "tratar" de implementar la comunicación USB ( por software) en cualquier microcontrolador que no disponga de este módulo de forma física. ;-)
Para empezar a trabajar con el puerto USB del microcontrolador veremos todos los registros del micro asociados con este periférico , su funcionamiento y luego poco a poco comenzaremos a confeccionar los primeros programas. :-)
Bueno para empezar veremos donde están hubicados los pines D- y D+ ( correspondientes a las señales de datos del puerto USB en el PIC18F2550 y en el PIC18F4550) , asi como también los otros pines que intervienen en su funcionamiento.
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen1.jpg)
Breve descripción del funcionamiento del módulo USB:
La familia de dispositivos PIC18FX455/X550 contiene una interfaz serie compatible con el SIE (serial interface engine o máquina con comunicación serie en español) USB “full-speed” (2.0) y “de poca velocidad” (1.0) que permite la comunicación rápida entre cualquier dispositivo USB y el microcontrolador PIC®.
El SIE puede interconectarse directamente al USB, utilizando el transmisor - receptor interno, o puede conectarse a través un transmisor-receptor externo. El PIC tiene un regulador interno de 3,3V para alimentar el transmisor-receptor interno en aplicaciones de 5V.
Se han incluido algunas características especiales en el hardware para mejorar el funcionamiento. Se proporciona memoria de puerto dual en la memoria de datos del dispositivo (RAM del USB) para tener acceso directo a la memoria desde el núcleo del microcontrolador y desde el SIE. También se proporcionan unos buffer para que el programador elija libremente el uso de la memoria dentro del espacio de la RAM del USB. Existe un puerto paralelo para transmitir grandes cantidades de datos (SSP), para esto se ha proporcionado la ayuda de transferencia ininterrumpida de volúmenes de datos grandes, por ejemplo datos síncronos, a los buffer de memoria externos.
Bueno ahora veremos en detalle como se comunica la SIE con el exterior y las diferentes opciones a nivel conexionado del USB con el exterior:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen2.jpg)
Antes que nada veremos las notas a las referencias 2 y 3 que están dentro de la inmágen. Aclarar que estas notas son importantes para no cometer equivocaciones a la hora de programar el código que lo configura.
entonces:
Nota* 2:Las pull - ups externas son opcionales , pero si queremos usarlas hay que desactivar las propias resistencias de pull - up internas que tiene el microcontrolador. La activación o desactivación de estas resistencias se hace mediante el bit UPUEN...que se verá más adelante.
Nota* 3:El regulador de voltaje de 3.3v, nos provee de tensión al módulo USB en aplicaciones de 3.3v. En caso de tener una fuente externa de 3.3v conectada a Vusb, tenemos que desactivar el módulo interno del regulador.
Vemos en la inmágen los diferentes pines que según configuración de la SIE , podemos usar un transceptor externo, el fin de este tutorial no es el estudio de los módulos externos , por lo que se verá muy superficialmente.
Algo ¡ Muy importante ! que tenemos que ver es el puente bidireccional entre la SIE y el SSP...este puente nos va a permitir el transporte a alta velocidad de grandes flujos de datos en modo sincrono, por lo que se estudiará también en su momento.
Ver la siguiente inmágen en donde se muestra dicho puente:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen3.jpg)
Estado y control del módulo USB:
En total hay 22 registros para manejar las transacciones del USB. Los registros son:
• Registro de control del USB (UCON)
• Registro de configuración del USB (UCFG)
• Registro de estado de la transferencia del USB (USTAT)
• Registro de dirección de dispositivo USB (UADDR)
• Registros del número del frame (UFRMH: UFRML)
• Registros activadores de los Endpoints de 0 a 15 (UEPN)
El primer registro que estudiaremos será el UCON (registro de control del USB):
En la siguiente inmágen veremos como está constituido:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen4.jpg)
Este registro de control contiene los bits necesarios para determinar el comportamiento del bus durante las transferencias. El registro contiene los bits que gobiernan lo siguiente:
• Permiso del periférico principal del USB
• Reset de los punteros tipo ping-pong
• Control del modo al suspender
• Desactivar la transferencia de paquetes
El significado de los diferentes bits se muestra a continuación:
BIT7: Bit no implementado se lee como "0"
BIT6: El bit PPBRST, se encarga de controlar el estado del reset, cuando se utiliza el modo Doble - Buffering o modo Ping - Pong.Cuando se activa el bit PPBRST, todos los buffers Ping - Pong se fijan a los buffers intermedios. El bit PPBRST, tiene que borrarse por firmware.Este bit se ignora en los modos de buffer que no usen el buffer ping-pong.
BIT5: El bit SE0,se utiliza para indicar el estado del bus, si sólo se manda un cero.
Cuando se permite el módulo USB, este bit debe supervisarse para determinar si las líneas de datos han salido de una condición de single-ended cero (sólo se manda cero). Esto ayuda a distinguir el estado de ciclo inicial de la señal de reset del USB.
BIT4: El bit PKTDIS,es un flag que indica si el SIE ha inhabilitado la transmisión y la recepción de paquetes. Este lo bit activa el SIE cuando recibe un SETUP para permitir su procesamiento. Este bit no lo puede activar el microcontrolador, sólo borrar; al despejarlo el SIE continua la transmisión y/o recepción. Cualquier acontecimiento pendiente dentro del buffer intermedio todavía estará disponible, indicado dentro del registro USTAT en el buffer FIFO.
BIT3: El bit USBEN,la operación total del módulo USB se controla con este bit. Activar este bit setea el módulo y resetea todos los bits PPBI en el Buffer a ‘0’. Este bit también activa el regulador de tensión del chip y conecta las resistencias pull-up, si se permiten. Así, este bit puede utilizarse como una unión/separación al USB. Aunque se ignoran todos los estados y bits de control si este bit está borrado, el módulo necesita preconfigurarse antes de activar este bit.
BIT2: El bit RESUME,permite al periférico realizar un reinicio ejecutando la señal resume. Para generar un reinicio válido, por firmware se debe activar el RESUME durante 10ms y entonces borrar el bit.
BIT1: El bit SUSPND,coloca el módulo y soporte del circuito (es decir,regulador de tensión) en un modo de baja potencia. El reloj de entrada al SIE se desactiva. Este bit debe activarse por software dentro de la respuesta a una interrupción IDLEIF. Debe borrarse por firmware después de observar una interrupción ACTVIF. Cuando este bit está activo, sigue estando el dispositivo unido al bus pero las salidas del transmisor-receptor permanecen en reposo. La tensión en el pin VUSB puede variar dependiendo del valor de este bit. Activar este bit antes de un IDLEIF dará lugar a
comportamiento imprevisible del bus.
Nota:Cuando esté en el modo de suspensión, el bus del dispositivo USB se limita al 500μA de corriente. Ésta es la corriente completa cedida por el dispositivo PIC y su circuito de soporte. Hay que tener cuidado de ceder la corriente mínima cuando el dispositivo entre en el modo de suspensión.
BIT0: Bit no implementado se lee como "0"
Registro de configuración del USB:
Antes de comunicarse con el USB, se tiene que configurar el módulo del hardware interno y/o externo. La mayor parte de la configuración se realiza con el registro UCFG. El regulador de tensión del USB se maneja con la configuración de los registros.
El registro UFCG contiene la mayor parte de los bits que dirigen el comportamiento del módulo USB. Éstos incluyen:
• Velocidad del bus (“Alta velocidad” vs “Baja velocidad”)
• Permiso de las resistencias pull-up del chip
• Permiso del transmisor del chip
• Uso del buffer ping-pong
El registro UCFG también contiene dos bits que ayudan a probar el módulo, eliminando errores y certificaciones del USB. La salida de control de estos bits permite el monitor de estado y generación de patrones “de ojo”.
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen5.jpg)
BIT 7: UTEYE: Bit de permiso del test patrón “de ojo” del USB.
1 = prueba del patrón “de ojo” permitido.
0 = prueba del patrón “de ojo” inhabilitado.
BIT 6: UOEMON: Bit de permiso del monitor OE del USB.
1 = señal del UOE* activa; indica los intervalos durante los cuales las líneas D+/D- están conduciendo.
0 = señales del UOE* inactivas.
BIT 4: UPUEN: Bit de permiso del pull-up del chip.
1 = Pull-up del chip permitido (pull-up en D+ con FSEN=1 o en D- con FSEN=0).
0 = Pull-up del chip desactivado.
BIT 3: UTRDIS: Bit inhabilitador del transmisor del chip
1 = Transmisor del chip inhabilitado; la interfaz digital del transmisor permitida.
0 = transmisor del chip activo.
BIT 2: FSEN: Bit de permiso del Full-Speed.
1 = dispositivo Full-speed: controla los flancos del transmisor; requiere un reloj de 48MHz.
0 = dispositivo de poca velocidad: controla los flancos del transmisor; requiere un reloj de 6MHz.
BIT 1-0 PPB1:PPB0: Bits de configuración de los buffer ping-pong.
11 = buffers ping-pong permitidos en los End-Points 1 a 15.
10 = buffers ping-pong permitidos en todos los End-Points.
01 = buffer ping-pong permitido en los End-Points de salida 0.
00 = buffers ping-pong inhabilitados.
Nota 1:
1: Si se activa UTRDIS, la señal UOE* estará activa independiente del ajuste del bit UOEMON.
2: Los bits UPUEN, UTRDIS y FSEN no deben cambiarse mientras el módulo USB esté permitido. Estos valores se deben preconfigurar antes de permitir el módulo.
3: Este bit solamente es válido cuando el transmisor del chip está activo (UTRDIS = 0); si no, se ignora.
Nota 2: La velocidad del USB, la transmisión y las pull-up deben configurase solamente durante la fase de activación del módulo. No se recomienda cambiar estos ajustes mientras que el módulo esté funcionando.
Bueno espero que les interese el tema ....después sigo :-/
-
Que tipo de modulo USB externo puede conectarse alli ??
-
y por ejemplo el USBN960X , lo podés utilizar como módulo de comunicaciones externo y conectarlo de la siguiente forma:
USBN_INT PIN_B0
USBN_RS PIN_C1
USBN_CS PIN_C2
USBN_RD PIN_C3
USBN_WR PIN_C4
USBN_A0 PIN_C5
-
PD: Mi idea después de finalizar con todo el tutorial que se va a desarrollar es que tengamos la capacidad de desarrollar el USB por software usando PIC's de menos recursos.....como lo hizo una vez un usuario utilizando un PIC16F84A 8)
-
En la pagina de National no lo recomiendan en nuevos diseños, incluso en la hoja de datos dice que es Obsoleto !! :shock: :shock:
-
PD: Mi idea después de finalizar con todo el tutorial que se va a desarrollar es que tengamos la capacidad de desarrollar el USB por software usando PIC's de menos recursos.....como lo hizo una vez un usuario utilizando un PIC16F84A 8)
pa mi que el individuo que se curró un usb con un 16f84, en asm :shock: no era de este planeta :D pero, por qué no?? yo me apunto al hilo pa ver si aprendo algo :mrgreen:
un saludo
-
PD: Mi idea después de finalizar con todo el tutorial que se va a desarrollar es que tengamos la capacidad de desarrollar el USB por software usando PIC's de menos recursos.....como lo hizo una vez un usuario utilizando un PIC16F84A 8)
El desarrollo de implementar la comunicación usb directo desde un 16f84a y un 16f628 es de Ángel Baños Jiménez:
http://www.telefonica.net/web2/hidlcd/ (http://www.telefonica.net/web2/hidlcd/)
(http://www.telefonica.net/web2/hidlcd/DSCN1038.JPG)
Quien además luego puso a comercializar un grabador por usb usando ese chip (el 628).
(http://www.silancode.com.es/UPP628new/Images/UPP628V3Hard.png)
Según comenta le llevó 3 años de desarrollo en sus tiempos libres.
-
Si bien la implementación por software del protocolo USB resulta interesante y retadora considero que los resultados son poco fructíferos.
El ejemplo de Angel Baños es excelente, un gran logro, pero utiliza la clase de dispositivos de interfaz humana en USB 1.1. Esto tiene 2 cuestiones:
1. La clase HID define que en low speed (1.5Mbps) los reportes se envían a razón de 100 por segundo (10ms por reporte mínimo).
2. El tamaño de cada reporte es de 8 bytes.
Haciendo cuentas se tiene una velocidad de 800 bytes por segundo, evidentemente rebasable por una conexión RS232 típica.
Contar con 800 bytes por segundo es útil para aplicaciones de bajas prestaciones como teclados o mouses, pero para otras transferencias se vuelve un cuello de botella.
Estoy seguro que hacer USB por software es un buen reto y que vale la pena hacerlo para aprender más sobre el protocolo USB, pero como uso práctico queda rebasado por el USB por hardware que los PIC ya traen, con velocidades prácticas de hasta 8Mbps en Full-Speed.
Johnattan, te deseo éxito en tu proeza. :mrgreen:
-
MGLSOFT:Disculpá fué el único que se me ocurrió en este momento de un ejemplo de C de CCS, si encuentro otro te lo hago saber a la brevedad.
alogic.on:Hola como estás , el señor que desarrollo la comunicación USB en un PIC16F84A no era de otro planeta sino alguien que le puso mucho empeño al tema...yo espero llegar a un resultado similar...es una cuestión de superación personal nomás ;-)
Felixls:Hola como estás felixls...ese señor debe saber todo sobre USB :-/ yo no espero saberlo todo pero tengo todo para aprender y voy a hacer lo mejor que pueda ;-)
migsantiago:Como estás...el desarrollo de esta idea es por un fin puramente educativo.....ahora los PIC de la serie PIC18FXX50 tienen mucha más capacidad pero como dije es por el solo hecho de aprender...
Mi curiosidad se generó principalmente a razón de que vi una página donde implementan el protocolo USB 100% por software en micros AVR de pocos recursos.
-
migsantiago:Como estás...el desarrollo de esta idea es por un fin puramente educativo.....ahora los PIC de la serie PIC18FXX50 tienen mucha más capacidad pero como dije es por el solo hecho de aprender...
Mi curiosidad se generó principalmente a razón de que vi una página donde implementan el protocolo USB 100% por software en micros AVR de pocos recursos.
Sí, estoy seguro de que aprenderás mucho.
El problema es que los AVRs que implementan USB por software son de al menos 12MIPS y se programan en C mientras que los PIC propuestos corren hasta 5MIPS y deben programarse en ASM para sacar el máximo provecho en cuanto a tiempos.
El hacer overclocking del pic16 a 6MIPS es peligroso.
Hay PIC18 que corren a 12MIPS pero curiosamente esos son los que traen USB integrado por hardware.
-
Viendo un poco el registro UCFG, en donde se encuentra el bit UTEYE, que es un bit de control de estado del USB que vigila los errores y es un generador de patrones.
Luego tenemos al bit UOEMON. Este bit nos muestra cuando las lineas D+ y D- están conduciendo y lo que estos valores representan según el siguiente cuadro:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen6.jpg)
Ahora tenemos 2 bit que trabajan de forma conjunta FSEN y UPUEN, según sea su configuración activarán o desactivarán las Resistencias Pull - Up internas del módulo USB o configuraran el módulo USB para trabajar a full - speed o slow - speed.
Veamos el circuito lógico que realiza estas acciones y una pequeña tabla donde se muestran las posibles configuraciones.
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen7.jpg)
Luego tenemos UTRDIS, que habilita o deshabilita el transmisor del chip, en caso de que el bit sea 0 , activamos el transceptor y los pines C4 y C5 son usados para conectar el dispostivo USB.
En caso de que el bit sea seteado a 1 , el transceptor es desactivado y las lineas C4 y C5 quedan para poder ser usadas como entradas digitales unicamente.
Por último tenemos los bits de configuración BIT 1-0 PPB1:PPB0: que establecen la configuración del modo Ping - Pong.
-
Permiso de la salida del monitor del USB:
El monitor del USB OE* proporciona información de la operación del SIE si está escuchando el bus o está conduciendo por el bus. Esto se permite por defecto al usar un transmisor externo o cuando UCFG<6>=1. La supervisión del USB OE* es útil para el eliminar errores del sistema inicial.
Permiso del test patrón “de ojo”:
Se genera una prueba automática al activar el bit UCFG<7> del patrón “de ojo”. La salida del patrón “de ojo” dependerá de los ajustes del módulo, significando que el usuario es el primer responsable de configurar los ajustes del reloj SIE, las resistencias pull-up y el modo transmisor. Además, el módulo tiene que estar permitido.
Una vez que se active UTEYE, el módulo emula un cambio a una recepción para transmitir el estado y comenzará a transmitir una secuencia de bits J-K-J-K (K-J-K-J en “velocidad completa”). La secuencia se repetirá indefinidamente mientras que el test patrón “de ojo” esté permitido.
Observar que este bit no se debe activar mientras que el módulo está conectado con un sistema real USB. Este modo de prueba se utiliza para ayudar con las verificaciones internas de las pruebas de certificación USB. Se utiliza para depurar los fallos obtenidos por el ruido de las señales que pueden afectar los flancos del sistema, uniones de impedancias mal hechas y proximidad a otros componentes. No comprueba correctamente la transición de un estado de recepción a uno de transmisión. Aunque el patrón de ojo no significa que se sustituya la prueba más compleja de certificación del USB, pero ayuda durante el primer test para eliminar errores del sistema.
Regulador de voltaje interno:
Los dispositivos PIC18FX455/X550 tienen un regulador incorporado 3,3V para proporcionar energía al transmisor interno y proporcionar una fuente para el pull-up interno y externo. Para que el regulador sea estable se necesita un condensador externo de 220nF (±20%). Cabe aclarar que se pueden colocar capacitores de mayor capacidad pero no es necesario ya que con 220nF (±20%) funciona correctamente.
Nota: La corriente de VUSB es suficiente para controlar un pull-up externo y el transmisor interno. El regulador se activa por defecto y puede inhabilitarse a través del bit de configuración VREGEN. Cuando está activo, la tensión es visible en el pin VUSB. Cuando el regulador está desactivado, se tiene que conectar una fuente de 3,3V al pin VUSB para alimentar el transmisor interno. Si el transmisor interno no se utiliza, VUSB tampoco se activa. VDD debe ser mayor que VUSB en cualquier momento, o igual con el regulador inhabilitado.
-
Hola!
Este PDF de la Universidad de Salamanca te vendrá como anillo al dedo para lo que estas explicando:
http://slalen.iespana.es/pics/datos/datasheet.pdf
;-)
-
Hola ariel como estás
Justamente desde ahí me estaba guiando para la parte de explicación de los registros....después cuando tenga bien en claro o por lo menos entienda como funcionan los registros relacionados con el USB, entonces voy a empezar a estudiar la forma de escribir una librería de control en ASM para desarrollar programas de control.
-
Ups...llegue tarde :)
-
de tarde nada, pa la saca :mrgreen:
-
Registro de estado del USB (USTAT):
El registro de estado del USB divulga el estado de las transacciones dentro del SIE. Cuando el SIE publica una interrupción de transferencia completa por el USB, hay que leer USTAT para determinar el estado de la transferencia. USTAT contiene el número del Endpoint de la transferencia, dirección y valor del puntero del buffer pingpong (si está utilizado).
Nota: Los datos en el registro de estado del USB son válidos solamente cuando el flag de interrupción TRNIF está activo.
El registro USTAT es realmente una ventana legible de los cuatro bytes de estado FIFO mantenida por el SIE. Permite al microcontrolador procesar una transferencia mientras que SIE procesa los Endpoints adicionales. Cuando el SIE termina con un buffer de lectura o escritura de datos, actualiza el registro USTAT. Si se realiza otra transferencia USB antes de realizar una interrupción de transacción completa, el SIEalmacenará el estado de la transferencia siguiente en el estado FIFO. Despejando el flag de la transferencia completa, TRNIF, provoca al SIE que avance el FIFO. Si los datos siguientes en el registro FIFO son válidos, el SIE inmediatamente reafirma la interrupción. Si no hay datos adicionales presentes, TRNIF seguirá borrado; los datos de USTATpuede que no sean correctos.
Nota: Si se recibe una petición de Endpoint mientras que el USTAT FIFO este lleno, el SIE publica automáticamente un NAK de nuevo al anfitrión.
En la siguiente figura mostramos la FIFO:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen8.jpg)
Ahora veremos que significan cada uno de los bits dentro del registro.
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen9.jpg)
BIT 7: No implementado , legible como "0"
BIT 6 al 3: ENDP3:ENDP0: Bits de actividad del número codificado del último Endpoint (representa el número del BDT actualizado por la última transferencia del USB).
1111 = Endpoint 15
1110 = Endpoint 14
….
0001 = Endpoint 1
0000 = Endpoint 0
BIT2: DIR: Bit puntero de la última dirección BD.
1 = la última transacción era de entrada.
0 = la última transacción era de salida o de SETUP.
BIT1 PPBI: Bit puntero del puntero ping-pong BD*
1 = la transacción pasada estaba al banco Odd de BD.
0 = la transacción pasada estaba al banco Even de BD.
NOTA: Este bit es solamente válido para los Endpoints con registros Even y Odd BD disponibles.
-
CONTROL DE LOS ENDPOINTS DEL USB:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen10.jpg)
Las funciones de cada bit se dan a continuación:
BIT 7 - 5: No implementados, se leen como "0".
BIT 4 EPHSHK: Bit de permiso del protocolo de intercambio
1= Se permite el protocolo de intercambio del Endpoint.
0= Se inhabilita (utilizado con los Endpoints síncronos).
BIT 3 EPCONDIS: Bit bidireccional de control del Endpoint
Si EPOUTEN=1 y EPINEN=1:
1= Inhabilita las transferencias de control del Endpoint n; sólo permite las de entrada y las de salida.
0= Permite las transferencias de control (SETUP) y las de entrada y salida del Endpoint n.
BIT2 EPOUTEN: Bit de permiso de la salida del Endpoint.
1= La salida del Endpoint n permitida.
0= La salida del Endpoint n inhabilitada.
BIT 1 EPINEN: Bit de permiso de la entrada del Endpoint.
1= La entrada del Endpoint n permitida.
0= La entrada del Endpoint n inhabilitada.
BIT 0 EPSTALL: Bit de permiso de la parada del Endpoint*
1= Se puede parar el Endpoint n.
0= El Endpoint n no se puede parar.
Nota 1: Válido solamente si se permite el Endpoint n; si no, se ignora el bit.
Cada uno de los 16 Endpoints bidireccionales posibles tiene un registro de control independiente, UEPn (donde ‘n’ representa el número del Endpoint). Cada registro tiene los mismos bits de control.
El bit EPHSHK (UEPn<4>) controla el protocolo de intercambio de los Endpoints; activar este bit permite el protocolo de intercambio del USB. Típicamente, este bit se setea siempre excepto al usar Endpoints síncronos.
El bit EPCONDIS (UEPn<3>) se utiliza para permitir o inhabilitar las operaciones de control del USB (SETUP) con Endpoint. Borrar este bit permite las transacciones SETUP. Observar que los bits EPINEN y EPOUTEN se deben activar para permitir las transacciones de entrada y de salida. Para el Endpoint 0, este bit debe estar siempre borrado por que las especificaciones del USB identifican el Endpoint 0 como el Endpoint de control por defecto.
El bit EPOUTEN (UEPn<2>) se utiliza para permitir o para inhabilitar las transacciones de salida del anfitrión. Activar este bit permite transacciones de salida. Semejantemente, el bit EPINEN (UEPn<1>) permite o inhabilita las transacciones de
entrada al anfitrión.
El bit EPSTALL (UEPn<0>) se utiliza para indicar la condición STALL para el Endpoint. Si se ejecuta una STALL en un Endpoint particular, el bit EPSTALL para ese Endpoint lo activará el SIE. Este bit permanece hasta que se borre por software o hasta que ocurra un reset del SIE.
REGISTRO DE DIRECCIÓN DEL USB (UADDR):
El registro de dirección del USB contiene la única dirección del USB que el periférico descifra cuando está activo. UADDR se pone a 00h cuando recibe un reset del USB, indicado por URSTIF, o con un reset al microcontrolador. La dirección del USB la tiene que escribir el microcontrolador durante la fase de setup del USB como parte del firmware del USB de la ayuda de microchip.
REGISTROS DEL NÚMERO DEL FRAME DEL USB (UFRMH:UFRML):
Los registros del número del frame contienen los 11bits del número del frame.
El byte de orden inferior está en UFRML, mientras que los tres bits de orden superior permanecen en UFRMH. El par de registros se actualizan con el número de frame actual cuando recibe un SOF. Para el microcontrolador, estos registros son sólo de lectura. El registro del número del frame se utiliza sobre todo para transferencias síncronas.
-
RAM DEL USB:
Los datos del USB se mueven entre el núcleo del microcontrolador y el SIE a través de una memoria
conocida como USB RAM. Ésta es una memoria de puerto dual especial que está mapeada en la memoria normal de datos en los bancos de 4 a 7 (400h a 7FFh) para un total de 1kbyte.
El banco 4 (400h con 4FFh) se utiliza específicamente en el control del buffer del Endpoint, mientras que los bancos de 5 a 7 están disponibles para los datos del USB. Dependiendo del tipo de buffer que se utilice, los 8 bytes del banco 4 pueden estar disponibles para utilizarlos como buffer del USB.
Aunque la RAM del USB está disponible en el microcontrolador como memoria de datos, las secciones que está modificando el SIE no las puede usar el microcontrolador. Se utiliza un mecanismo de semáforos para determinar el acceso a un buffer en un momento dado.
IMPLEMENTACIÓN DE LA RAM DEL USB EN LA ESPACIO DE MEMORIA DE DATOS:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen11.jpg)
BUFFER DESCRIPTOR Y TABLA DEL BUFFER DESCRIPTOR:
Los registros del banco 4 se utilizan específicamente para el control del buffer del Endpoint en una estructura conocida como Tabla del Buffer descriptor (BDT). Esto proporciona un método flexible a los usuarios para construir y para controlar los Buffers
del Endpoint de varias longitudes y configuraciones. Los BDT se componen de los Buffers descriptores (BD) que se utilizan para definir y controlar los Buffers reales del Espacio de la RAM del USB. Cada BD, alternadamente, consiste en cuatro registros, donde n representa uno de los 64 BDs
posibles (gama de 0 a 63):
• BDnSTAT: Registro de estado de BD
• BDnCNT: Registro del byte de cuenta de BD
• BDnADRL: Registro bajo de la dirección de BD
• BDnADRH: Registro alto de la dirección de BD
BDs ocurre siempre como bloque de cuatro bytes en la secuencia,
BDnSTAT:BDnCNT:BDnADRL:BDnADRH. La dirección de BDnSTAT es siempre una compensación de (4n-1) (en hexadecimal) de 400h, con n como el número del Buffer descriptor.
Dependiendo de la configuración del buffering utilizada, hay 32, 33 ó 64 sistemas de Buffer descriptores. El BDT debe ser por lo menos 8 bytes de largo. Esto se debe a que la especificación del USB asigna que por mandato debe tener cada dispositivo el Endpoint0 configurado como entrada y salida en la disposición inicial. Dependiendo del Endpoint y de la configuración buffering, el BDT puede ser de 256 bytes de largo.
Aunque se puede creer que los buffers descriptores y los registros de dirección son registros de funciones especiales que no están mapeados en hardware, como lo están los SFRs convencionales en el banco 15 del microcontrolador. Si el Endpoint correspondiente a un BD particular no está permitido, sus registros no se utilizan. En vez de aparecer como direcciones no implementadas, aparecen como RAM disponible. Solamente cuando un Endpoint está permitido, activando el bit UEPn<1>, se consigue que la memoria de esas direcciones funcione como BD. Como los registros BD tienen cualquier dirección en la memoria de datos en un reset, también tienen un valor
indeterminado.
Un sistema particular de los registros BD son solamente válidos si el Endpoint correspondiente está permitido usando el registro UEPn. Todos los registros BD están disponibles en la RAM del USB. El BD para cada Endpoint debe configurarse antes de permitirlo.
-
EJEMPLO DE UN BUFFER DESCRIPTOR:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen12.jpg)
ESTADO Y CONFIGURACIÓN DE LOS BD:
Los Buffer descriptores no sólo definen el tamaño de un Buffer Endpoint, sino también determina su configuración y control. La mayor parte de la configuración se hace con el registro de estado del BD, BDnSTAT. Cada BD tiene su propio registro correspondientemente numerado BDnSTAT.
No como otros registros de control, la configuración de los bits del registro BDnSTAT depende del contexto. Hay dos configuraciones distintas, dependiendo de si el microcontrolador o el módulo del USB está modificando el BD y Buffer en un momento dado. Solamente se comparten tres definiciones de bit entre los dos.
-
Propiedades del Buffer:
Los Buffers y su BDs los comparten la CPU y el módulo del USB, se utiliza un semáforo para distinguir el BD y los Buffers asociados en memoria que se permiten actualizar.
Esto se logra con el bit UOWN (BDnSTAT<7>). UOWN es el único bit compartido entre las dos configuraciones BDnSTAT.
Cuando UOWN está borrado, la entrada de BD la dirige por el núcleo del microcontrolador. Cuando se activa el bit UOWN, la entrada del BD y la memoria del Buffer los controla por el periférico USB. El núcleo no debe modificar el BD o su Buffer correspondiente en este momento. Observar que el núcleo del microcontrolador puede leer BDnSTAT mientras que el SIE controla el Buffer y viceversa.
Los Buffer descriptores tienen varios significados dependiendo de la fuente de actualización del registro. Antes de poner en sus manos el periférico del USB, el usuario puede configurar las operaciones básicas del periférico con los bits BDnSTAT. Durante este tiempo, el byte de control de la cuenta y los registros de direccionamiento del Buffer también pueden fijarse.
Cuando se activa UOWN, el usuario puede depender de los valores escritos en los BDs. El SIE actualiza el BDs cuanto es necesario, sobrescribiendo los valores originales del BD. El registro BDnSTAT lo actualiza el SIE con el PID; la cuenta de la transferencia, BDnCNT, se actualiza también.
El byte BDnSTAT del BDT debe ser el último byte que se actualice al prepararse para armar un Endpoint. El SIE borrará el bit UOWN cuando se termine una transacción. La única excepción es cuando KEN y/o BSTALL están permitidos.
No existe ningún mecanismo por hardware para bloquear el acceso cuando se setea el bit UOWN. Así, puede ocurrir un comportamiento inesperado si el microcontrolador intenta modificar la memoria cuando el SIE lo posee.
Semejantemente, leyendo tal memoria se pueden obtener datos inexactos hasta que el periférico USB devuelve la propiedad al microcontrolador.
Registro BDnSTAT (modo CPU):
Cuando UOWN=0, el núcleo del microcontrolador posee BD. En este punto, los otros siete bits del registro toman las funciones de control.
El bit, KEN (BDnSTAT<5>), determina si un BD permanece activo. Si se setea el bit, una vez que el bit UOWN esté activo, seguirá controlado el SIE independiente de la actividad del Endpoint. Esto previene a la FIFO USTAT de actualizarse, así como activar la interrupción de transacción completa para el Endpoint. Esta característica se debe permitir solamente cuando el puerto paralelo se selecciona como canal de entradasalida de datos en lugar de la RAM del USB.
El bit inhabilita el incremento de la dirección, INCDIS (BDnSTAT<4>), que controla el direccionamiento automático por incremento del SIE. Activar INCDIS inhabilita el auto incremento de la dirección del Buffer por el SIE para cada byte transmitido o recibido. Esta característica sólo se tiene que utilizar con el puerto paralelo, donde cada byte de datos se procesa a/desde la misma posición de memoria.
El bit de permiso de la sincronización de palabras, DTSEN (BDnSTAT<3>), se encarga de comprobar la paridad de los datos. Activar DTSEN permite la sincronización con el SIE. Cuando está permitido, comprueba la paridad del paquete de los datos contra el valor de DTS (BDnSTAT<6>). Si un paquete llega con una sincronización incorrecta, los datos se ignoran. No se escriben en la RAM del USB y el flag de interrupción de transferencia completa del USB no se activará. Sin embargo, el SIE enviará un ACK al anfitrión para reconocer el recibo.
El bit del buffer de parada, BSTALL (BDnSTAT<2>), proporciona ayuda en el control de las transferencias, generalmente una parada en el Endpoint 0. También proporciona ayuda con los comandos SET_FEATURE/CLEAR_FEATURE; típicamente, paradas continuas en cualquier Endpoint con excepción del Endpoint de control por defecto.
El bit BSTALL también permite las paradas del Buffer. Activar BSTALL hace que el SIE devuelva un STALL al anfitrión si el símbolo recibido utilizaría el BD en esa localización. Cuando se activa el bit EPSTALL en el registro de control correspondiente UEPn se genera una interrupción STALL cuando se manda la STALL al anfitrión. El bit UOWN activado y el BDs no se cambia a menos que se reciba un SETUP. En este caso, la condición de la STALL se borra y la propiedad del BD se devuelve al núcleo
del microcontrolador.
Los bits BD9:BD8 (BDnSTAT<1:0>) guardan los dos dígitos más significativos del byte de la cuenta del SIE; los 8 dígitos más bajos se almacenan en el registro correspondiente BDnCNT.
-
EFECTO DEL BIT DTSEN EN LA RECEPCIÓN DE PAQUETES PARES/IMPARES (DATA0/DATA1):
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen13.jpg)
BDnSTAT: REGISTRO DEL ESTADO DEL BUFFER DESCRIPTOR n (BD0STAT HASTA BD63STAT), MODO CPU (LOS DATOS SE ESCRIBEN AL LADO):
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen14.jpg)
BIT 7 UOWN: Bit de posesión del USB(1)
0 = El núcleo del microcontrolador posee el BD y su Buffer correspondiente.
BIT 6 DTS: Bit de sincronización de los datos(2)
1 = Paquete de datos 1.
0 = Paquete de datos 0.
BIT 5 KEN: Bit de permiso de la subsistencia de BD.
1 = USB guardará el BD indefinidamente una vez que UOWN se active
(requerido en la configuración de los Endpoint del SPP).
0 = USB guardará el último símbolo procesado.
BIT 4 INCDIS: Bit de inhabilitación del incremento de la dirección
1 = El incremento de la dirección inhabilitado (requerido en la configuración de los
Endpoint del SPP).
0 = Incremento de la dirección permitido.
BIT 3 DTSEN: Bit de permiso de la sincronización.
1 = Sincronización de los datos permitida; los paquetes de los datos con valor
incorrecto de la sinc. se ignoran excepto un SETUP, que se acepta.
0 = ninguna sincronización de los datos.
BIT 2 BSTALL: Bit de permiso de paradas en el Buffer.
1 = Parada del Buffer permitida; el protocolo de la STALL publica si se recibe un
símbolo que utilizaría el BD en la localización dada (UOWN se activa, el resto sin
cambios).
0 = parada del Buffer inhabilitado.
BIT 1-0 BC9:BC8: Bits del byte de cuenta 9 y 8.
Los bits de cuenta del byte representan el número de bytes que se transmitirán
con un símbolo IN o recibidos durante un símbolo OUT. Junto con BC<7:0>, las
cuentas de byte válidas son 0-1023.
Nota 1:Este bit debe inicializarlo el usuario con el valor deseado antes de permitir el módulo USB.
Nota 2:Se ignora este bit a menos que DTSEN = 1.
Registros BDnSTAT (modo SIE):
Cuando los BDs y su Buffer los gobierna el SIE, la mayoría de los bits de BDnSTAT toman distintos significados. Al activarse UOWN, cualquier dato o ajuste de control escritos por el usuario se sobrescriben con datos del SIE.
El registro BDnSTAT lo actualiza el SIE con el identificador del paquete (PID) se almacena en BDnSTAT<5:3>. Se actualiza la cuenta de la transferencia en el registro BDnCNT correspondiente. Los valores que desbordan el registro de 8 bits se transportan a los dos dígitos más significativos de la cuenta, almacenados en BDnSTAT<1:0>.
BDnSTAT: REGISTRO DE ESTADO DEL BUFFER DESCRIPTOR n (BD0STAT A BD63STAT), MODO SIE (DATOS DEVUELTOS POR EL LADO DEL MICROCONTROLADOR):
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen15.jpg)
BIT 7 UOWN: Bit de posesión del USB.
1= El SIE gobierna el BD y el buffer correspondiente.
BIT 5-2 PID3:PID0: Bits identificadores del paquete. El valor recibido del símbolo PID de la
última transferencia (sólo IN, OUT o SETUP).
BIT 1-0 BC9:BC8: Bits del byte de cuenta 9 y 8.
Esto bits los actualiza el SIE para reflejar al número de bytes recibidos en una
transferencia OUT y el número de bytes transmitidos en una IN.
BYTE DE CUENTA DE BD:
El byte de cuenta representa el número total de bytes que se transmitirán durante una IN. Después de la transferencia IN, el SIE devolverá el número de bytes enviados al anfitrión.
Para una transferencia OUT, el byte de cuenta representa número máximo de los bytes que se pueden recibir y almacenar en la RAM del USB. Después de una transferencia OUT, el SIE devolverá el número real de bytes recibidos. Si este número excede el byte de cuenta correspondiente, el paquete de datos se rechazará y se generará un protocolo de intercambio NAK. Cuando sucede esto, el byte de cuenta no se actualiza.
El byte de cuenta de 10 bits se distribuye sobre dos registros. Los 8 bits más bajos de la cuenta residen en el registro BDnCNT. Los dos altos en BDnSTAT<1:0>. Esto representa una gama válida para el byte de 0 a 1023.
VALIDACIÓN DE LA DIRECCIÓN DE BD:
El par de registros de dirección de BD contiene la dirección de comienzo de la RAM para el Buffer del Endpoint correspondiente. Para que una localización que comienza en el Endpoint sea válida, debe estar en la gama de la RAM del USB, 400h a 7FFh. No hay ningún mecanismo por hardware para comprobar la dirección del BD.
Si el valor de la dirección de BD no señala a una dirección de la RAM del USB, o si señala a una dirección dentro del Buffer de otro Endpoint, es probable que se pierdan los datos o que se sobrescriban. Semejantemente, solapando un Buffer de recepción (Endpoint de salida) con una localización de BD en uso se obtienen resultados inesperados. Cuando se desarrollan aplicaciones USB, el usuario puede incluir software para validar las direcciones en el código.
BUFFERING PING-PONG:
Un Endpoint se define para tener un Buffer ping-pong cuando tiene dos sistemas de entradas de BD: un sistema para una transferencia par y otro para una transferencia impar. Esto permite a la CPU procesar un BD mientras que el SIE procesa el otro BD.
El doble buffering BD, permite un rendimiento de procesamiento máximo del/al USB.
El módulo USB apoya cuatro modos de operación:
• Ninguna ayuda del ping-pong
• Ayuda del Buffer del ping-pong del OUT Endpoint 0 solamente
• Ayuda del Buffer del ping-pong para todas los Endpoints
• Ayuda del Buffer del ping-pong para el resto de los Endpoints excepto el 0
Los ajustes del Buffer ping-pong se configuran con los bits PPB1:PPB0 en el registro UCFG.
El módulo USB no pierde de vista el puntero ping-pong de cada Endpoint.
Todos los punteros están reseteados inicialmente al BD par cuando se activa el módulo.
Al terminar una transacción (SIE borra UOWN), el puntero se une al BD impar. Al terminar la transacción siguiente, el puntero se une de nuevo al BD par y así sucesivamente.
El estado par/impar de la transacción realizada se almacena en el bit PBI del registro USTAT. El usuario puede resetear todos los punteros ping-pong al par con el bit PPBRST.
Cada BD tiene una relación fija con un Endpoint particular, dependiendo de la configuración del buffering. Esta relación significa también que pueden aparecer vacíos en las BDT si los Endpoints no se activan contiguamente. Esto significa en teoría, que los BDs de los Endpoints desactivados podían utilizarse como espacio de Buffer. En la práctica, los usuarios deben evitar usar tales espacios en el BDT a menos que el método de validar direcciones de BD esté en ejecución.
TABLAS DEL BUFFER DESCIPTOR MAPEADAS PARA LOS MODOS DE LOS BUFFER:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen16.jpg)
ASIGNACIÓN DE LOS BUFFERS DESCRIPTORES A LOS DIFERENTES MODOS DE BUFFERING:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen17.jpg)
-
jonathanPIC888,
Te súper felicito por lo que estas haciendo, es un trabajo muy arduo y seguro tendrá sus frutos cuando lo termines.
Tenes muy claro lo que estas buscando y seguramente lo vas a lograr (por ahi yo también soy de esos que re-inventan la rueda, pero bueno que se le va hacer, desafíos son desafíos).
Como ayuda te puedo dar este dato. Lo que estas haciendo esta echo en la Franklin W. Olin College of Engineering. Yo lo encontré buscando justo eso que estas haciendo, una librería en ASM del USB. Te lo paso, tal ves puedas sacar datos interesantes de como implementar la librería, como por ejemplo, están implementadas en ASM las instrucciones de alto nivel como el FOR, IF, WHILE, etc..
Un dato, que no es menor, la libreria funciona.
Este es el link (http://pe.ece.olin.edu/ece/projects.html) del proyecto.
Saludos,
Gustavo
-
SUMARIO DE LOS REGISTROS DE LOS BDT DEL USB:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen18.jpg)
Nota 1: En los registros de los BD, la n es un valor de 0 a 63. Los 64 registros son semejantes. Todos tienen valores indeterminados en los reset.
Nota 2: Del bit 5 al 2 del BDnSTAT lo utiliza el SIE para devolver los valores PID3:PID0 una vez el registro haya cambiado al SIE (Activar el bit UOWN). Cuando los registros estén bajo el control del SIE, los valores de KEN, DTSEN, INCDIS y BSTALL no tienen validez.
Nota 3: Antes de activar el bit UOWN, los bits 5 al 2 del BDnSTAT configuran KEN, DTSEN, INCDIS y BSTALL.
Nota 4: Se ignora este bit a menos que DTSEN=1.
INTERRUPCIONES DEL USB:
El módulo USB puede generar condiciones de interrupción múltiples. Para acomodar todas estas fuentes de interrupción, el módulo proporciona su propia lógica de estructura de interrupción, similar a la del microcontrolador. Las interrupciones del USB se activan con un sistema de registros de control y registradas con un sistema separado de flags. Todas las fuentes se concentran en una sola petición de interrupción del USB, USBIF (PIR2<5>).
Hay dos capas de registros de interrupción en el módulo USB. El nivel superior consiste en todas las interrupciones de estado del USB; éstos se permiten y se señalan por medio de un flag en los registros UIE y UIR, respectivamente. El segundo nivel consiste en las condiciones de error del USB, se permiten y señalan por medio de un flag en los registros UEIR y UEIE. Ninguna condición de interrupción en estos provoca la activación del flag de interrupción por error del USB (UERRIF) en el nivel superior.
Las interrupciones se pueden utilizar para detectar acontecimientos rutinarios en una transacción USB.
LÓGICA DE LA INTERRUPCIÓN DEL USB:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen19.jpg)
EJEMPLO DE LOS EVENTOS TRANSACCIÓN E INTERRUPCIÓN:
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen20.jpg)
Nota 1: La transferencia de control mostrada es sólo un ejemplo que muestra los eventos que ocurren en cada transacción. El control típico de la transferencia se puede extender a varios frames.
REGISTRO DE ESTADO DE LAS INTERRUPCIONES DEL USB (UIR):
El registro de estado de las interrupciones del USB contiene los flags para el estado de cada fuente de interrupción. Cada una de estas interrupciones tiene un bit de permiso en el registro UIE correspondiente. Todos los flags de estado del USB se suman para generar el flag de interrupción USBIF para el túnel de interrupción del micro.
Una vez que el SIE active un bit de interrupción, se tiene que borrar por software escribiendo un ‘0’. Los flags se pueden activar por software para ayudar en la búsqueda de errores del firmware.
(http://i822.photobucket.com/albums/zz150/MoyanoJonathan/inmagen21.jpg)
BIT 7: No implementado, se lee como "0"
BIT 6 SOFIF: Bit de interrupción del símbolo START-OF-FRAME.
1= START-OF-FRAME recibido por el SIE.
0= Ningún START-OF-FRAME recibido por el SIE.
BIT 5 STALLIF: Bit de interrupción del protocolo de STALL.
1= Protocolo de STALL enviado por el SIE.
0= Protocolo de intercambio STALL no se ha enviado.
BIT 4 IDLEIF: Bit de interrupción detector de reposo(1).
1= Reposo detectado (estado de reposo de 3ms o más).
0= Ninguna condición de reposo detectada.
BIT 3 TRNIF: Bit de interrupción de transacción completa(2).
1= Transacción pendiente completa; leer el registro USTAT para información del Endpoint.
0= Transacción pendiente no completada o no hay.
BIT 2 ACTVIF: Bit de interrupción de detección de la actividad del bus(3).
1= Actividad detectada en las líneas D+/D-.
0= Ninguna actividad detectada en las líneas D+/DBIT.
BIT 1 UERRIF: Bit de interrupción de la condición de error del USB(4).
1= Ha ocurrido una condición de error desenmascarada.
0= No ha ocurrido ninguna condición de error.
BIT 0 URSTIF: Bit de interrupción de reset del USB.
1= Ha ocurrido un reset en el USB, 00h se carga en el registro UADDR.
0= No ha ocurrido ningún reset del USB.
Nota 1: Una vez que se detecte un estado de reposo, el usuario puede colocar al módulo USB en este modo.
Nota 2: Borrar este bit hará avanzar la USTAT FIFO (válido solamente con los símbolos IN, OUT y SETUP).
Nota 3: Este bit es desenmascarado al detectar un acontecimiento de interrupción UIDLE.
Nota 4: Solamente las condiciones de error permitidas a través del registro UEIE activarán este bit. Este bit es bit de estado y no lo puede modificar el usuario.
Bit de interrupción de detección de la actividad del bus (ACTVIF):
El bit ACTVIF no se puede ser borrar inmediatamente después de despertar al módulo USB del modo reposo o cuando se suspende. Se necesita un retraso para sincronizar el estado interno del hardware antes de que el bit ACTVIF pueda borrarse por firmware. Borrar el bit ACTVIF antes de sincronizar el hardware puede que no cause efecto. Además, si el módulo USB utiliza una fuente de reloj de 96MHz PLL,después se borra el bit SUSPND, el módulo del USB puede ser operacional inmediatamente mientras que espera los 96MHz PLL.
BORRADO DEL BIT ACTVIF (UIR<2>):
Ensamblador:
BCF UCON, SUSPND
LOOP:
BTFSS UIR, ACTVIF
BRA DONE
BCF UIR, ACTVIF
BRA LOOP
DONE:
REGISTRO DE PERMISO DE LAS INTERRUPCIONES (UIE):
El registro de permiso de la interrupción del USB contiene los bits de permiso del estado de las fuentes de interrupción USB. No fijar ninguno de estos bits permitirá la interrupción elegida en el registro UIR.
Los valores en este registro afectan solamente la propagación de una condición de interrupción a la lógica de interrupción del microcontrolador. Los flags todavía están activados por su condición de interrupción, permite que sean interrogados y se mantienen sin realmente la interrupción.
Gracias GDM, lo que estoy haciendo es como un método de autoenseñanza para aprender como funciona el USB a nivel de bits ...es decir comprenderlo realmente. Esto cuesta bastante pero una vez que se aprende podes hacer lo que querés. :-/
-
Hola Jhonatan , gracias por la info y gracias por hacerla en español...
Yo estoy haciendo un programa en assembler de comunicacion USB y estoy empezando ha hacer un post para conversar de como va el programa, pretendo hablar solo de código assembler asi que tu post ha sido de gran ayuda... asi que queria decirte que:
estoy basando mucho mi introduccion del MOdulo USB en tu post(basicamente estoy diciendoles que vengan a ver aca si quieren saber como funciona un modulo USB :mrgreen:) , asi que gracias , y..
talvez quieras darte una vuelta por alla que hemos de nesecitar tus conocimientos , pareces que conoces mucho de USB y nos puedes ayudar de mucho:
http://www.todopic.com.ar/foros/index.php?topic=36612.msg305178#msg305178
saludos.
-
Jajaja eres un sádico xP.... yo también quería en principio hacer mi tesis con una comunicación en USB, pero al tener problemas con la comunicación entre master y esclavo en i2c en lenguaje C, me cambié a assembler y con eso también mis ganas de controlar el master via USB xP. Aunque me ha pasado mucho por la cabeza intentarlo en Assembler pero ya no me queda tiempo para entregar mi proyecto u.u
-
Jajajajajaja.., pues tal ves quieras considerar hacerlo con USB, mi pana dan!, porque lo he hecho!, todo en assembler y sin siquiera linker ni C ni nada...puro, primitivo y jugoso assembler básico!,
Y, mejor aún, ni bien sepa como postear código aquí lo pongo! ! !.....
PD: Saludos Venezuela ! ! !
-
listo, pueden ver el código, aqui: aqui (http://www.todopic.com.ar/foros/index.php?topic=36612.msg318340#msg318340)
PD:el código fué hecho x César González y Gerónimo Molina bajo derechos copyleft. cualquier duda, aqui estamos.
-
EN SI QUE HACER EL CODIGO O Q FUNCIONALIDAD TIENE
-
¡¡¡¡¡¡Saludos a todos los hermanos del foro!!!!!! :-/ :-/ :-/
Y en especial a Gero (Tronix) y jonathanPIC888 les doy mis respetos de manera sincera, buen trabajo ((:-)) ((:-))
Aunque a jonathanPIC888 le digo que a partir del esfuerzo de retadores como él se desarrollan las cosas más complejas y avanzadas que hay en este mundo, son tantas esas cosas y cito: todo el que trabaja la electronica digital conoce el Algebra de Boole y sabe que junto al transistor hicieron germinar a las computadoras de hoy, resulta que George Boole murió en 1.864 y el hombre no tuvo idea del alcance de su pequeño aporte.
-
Y en especial a Gero (Tronix) y jonathanPIC888 les doy mis respetos de manera sincera, buen trabajo
Aunque a jonathanPIC888 le digo que a partir del esfuerzo de retadores como él se desarrollan las cosas más complejas y avanzadas que hay en este mundo, son tantas esas cosas y cito: todo el que trabaja la electronica digital conoce el Algebra de Boole y sabe que junto al transistor hicieron germinar a las computadoras de hoy, resulta que George Boole murió en 1.864 y el hombre no tuvo idea del alcance de su pequeño aporte.
Muchas gracias por las palabras, pero sinceramente no creo que siga el desarrollo en ASM, principalmente por su gran complejidad y falta de aplicación práctica (por lo menos para mi). Igual si sigo estudiando el tema en lenguaje C, que me parece mucho mas aplicable a proyectos más grandes que no solo manejen comunicación USB.
Saludos y que estés bien !