USB y PIC 18F2550 Desarrollo de proyectos en ASM

Excelente aporte Moyano Jonathan.

Por alla del 2003 queria hacer una aplicacion con usb y pics, por desgracia muchas cosas se conjuntaron y jamas pude conseguir mi objetivo. Pero nunca es tarde y se agradece el aporte.
Ahora entendere las bases del USB.
Una pregunta que espero no sea adelantada por lo que se a descrito hasta el momento: por esas fechas que hice mi primer intento se requeria de hacer el driver para el S.O. por lo que tuve que conseguir el DDK de Microsoft, ¿es necesario o se puede omitir este paso? ya que la verdad nunca logre entender o conseguir un manual que me ayudara a usar este paquete.
Si alguien considera necesario, puedo hacer una ISO del mismo y subirlo, solo que me ayude ya que desconozco la forma de hacerlo.

Saludos
 
No ahora todos los drivers están desarrollados para poder usar el USB del PIC. Además en este tutorial al principio por lo menos se usará protocolo HID por lo que no vas a necesitar drivers especiales.
 
EJEMPLO DE UN BUFFER DESCRIPTOR:
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.
 
oye amigo moyano estoy tratando de simular en proteus los distintos codigos que estoy generando pero sin tener exito mi pregunta es ¿se puede simular o no el puerto usb del micro 18f4550? y la otra es cuando configuras los BD`s es nesesario todos o solo uno de ellos. Espero no incomodar pero sera de gran ayuda por que el codigo si se simula en MPlab que es el que ocupo para este tipo de programacion, pero quiero ver si es factible hacerlo en el proteus dado que eso de estar grabando y borrando el micro muy seguido se me hace muy trbajoso y ademas para cuidar la integridad del micro por no dañarlo por tantas veces que lo e grabado.

SALUDOS
 
Hola Moyano.
Esta parte del usb en asm, tambien esta interesante
y en el lenguaje que siempre manejo...claro que ahy vamos tambien con ccs
Gracias por este nuevo y gran aporte.:apreton::aplauso:
 
EFECTO DEL BIT DTSEN EN LA RECEPCIÓN DE PAQUETES PARES/IMPARES (DATA0/DATA1):
inmagen13.jpg

BDnSTAT: REGISTRO DEL ESTADO DEL BUFFER DESCRIPTOR n (BD0STAT HASTA BD63STAT), MODO CPU (LOS DATOS SE ESCRIBEN AL LADO):
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):

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:

inmagen16.jpg


ASIGNACIÓN DE LOS BUFFERS DESCRIPTORES A LOS DIFERENTES MODOS DE BUFFERING:

inmagen17.jpg

 
SUMARIO DE LOS REGISTROS DE LOS BDT DEL USB:
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:
inmagen19.jpg

EJEMPLO DE LOS EVENTOS TRANSACCIÓN E INTERRUPCIÓN:
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.
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.
 
muy bien yona , te cuento que encontre unos programas para usb pero tienen mescla con c y deje de entenderlos , con este post pienso que voy a aclarar mis dudas que son un monton , metele plomo nomas :LOL:
 
lo que voy a hacer acá es puro ASM...para que todos veamos el funcionamiento desde 0 de lo que es el USB en esta línea de PIC. Pero aún falta para terminar la teoría y después de a poco hay que ir entendiendo las diferentes funciones de control para finalizar con la escritura de una librería macro que podamos usar todos en nuestros proyectos.
 
Ya que vamos a lo básico en programación del firmware (assembler) también estaría bueno poner el algoritmo del host en forma general en vez de usar lenguaje de Visual Basic. Si bien es un lenguaje fácil hay gente que le gustaría utilizar otro. Como C o C# , etc.
 
Apoyo la sugerencia del compañero foso. Y me pongo como voluntario para ir construyendo una interface con C. Mas sin embargo surge el problema del driver, si alguien tiene algo de info ojala y nos pueda apoyar.

Saludos.
 
Hola Gente.
Moyano sos un capo, les comento que logre sacarle todas las macros a un ej quedo 100% asm, aunque a algunas rutinas todavía no las entiendo bien.
Si les interesa se los paso, tambien tengo codigo en VB6 para el host
 
yo estoy en lo mismo ...toda la semana pasada y la anterior a esa me quedé sin PC por que se me rompio. Ahora desde la semana que viene sigo con el tema que se me quedó medio dormido. Estaría bueno diego que pusieras lo que has podido sacar en limpio.
 
Bueno les comento a este proyecto no solo le saque las macros, también le desactive las entradas analógicas que usaba en el original, quedo como un eco le envías un dato, setea la salida PWM (portc 2 poner un led) y te lo devuelve
También les dejo el soft original que tiene el circuito y el código fuente para el host
 

Adjuntos

  • HID_Basic.zip
    534.4 KB · Visitas: 520
  • Proyecto Original.zip
    1.3 MB · Visitas: 458
Atrás
Arriba