USB y PIC 18F2550 Desarrollo de proyectos en ASM

inmagen22.jpg

BIT 7 : No implementado , se lee como '0'.

BIT 6 SOFIE: Bit de permiso de la interrupción del START-OF-FRAME.
1 = interrupción permitida
0 = interrupción inhabilitada
BIT 5 STALLIE: Bit de permiso de la interrupción del protocolo STALL.
1 = interrupción permitida
0 = interrupción inhabilitada
BIT 4 IDLEIE: Bit de permiso de la interrupción de reposo.
1 = interrupción permitida
0 = interrupción inhabilitada
BIT 3 TRNIE: Bit de permiso de la interrupción de transacción completa.
1 = interrupción permitida
0 = interrupción inhabilitada
BIT 2 ACTVIE: Bit de permiso de la interrupción de detección de la actividad del bus.
1 = interrupción permitida
0 = interrupción inhabilitada
BIT 1 UERRIE: Bit de permiso de la interrupción de error del USB.
1 = interrupción permitida
0 = interrupción inhabilitada
BIT 0 URSTIE: Bit de permiso de la interrupción del reset del USB.
1 = interrupción permitida
0 = interrupción inhabilitada

REGISTRO DE ESTADO DE LAS INTERRUPCIONES POR ERROR DEL USB (UEIR):
El registro de estado de las interrupciones de error del USB contiene los flags para cada fuente de error del periférico USB. Cada una de estas fuentes se controla con el bit de permiso de interrupción correspondiente del registro UEIE. Todas los flags de error de USB se suman para generar el flag de interrupción de error del USB (UERRIF) en el nivel superior de la lógica de interrupción.
Cada bit de error se activa cuando se detecta la condición de interrupción. Así, la interrupción normalmente no corresponde con el final de un símbolo que se acaba de procesar.
Una vez que un bit de interrupción haya activado el SIE, tiene que borrarse por software escribiendo un ‘0’.

inmagen23.jpg


BIT 7 BTSEF: Flag de error del bit mercancía.
1= Error detectado.
0= No se ha detectado error.
BIT 4 BTOEF: Flag de error de espera en el procesamiento del bus.
1= error detectado (han llegado más de 16bits de reposo antes de un EOP).
0= error no detectado.
BIT 3 DFN8EF: Flag de error del tamaño de los datos.
1= error detectado (no era un número entero de bytes).
0= error no detectado.
BIT 2 CRC16EF: Flag de fallo CRC16
1= error detectado.
0= error no detectado.
BIT 1 CRC5EF: Flag de error del anfitrión CRC5.
1= error detectado (paquete simbólico rechazado).
0= error no detectado.
BIT 0 PIDEF: Flag de prueba de fallo de PID.
1= error detectado.
0= error no detectado.

REGISTRO DE PERMISO DE LAS INTERRUPCIONES DE ERROR (UEIE):

El registro de permiso de las interrupciones de error (UEIE) contiene los bits de activación para cada fuente de interrupción de error del USB. Activando cualquiera de estos bits se activa la fuente de la interrupción respectiva. Como el registro UIE, los bits activos sólo afectan la propagación de la
condición de la interrupción. Los flags se activan cuando se cumplen sus condiciones.
inmagen24.jpg


BIT 7 BTSEF: Bit de permiso de interrupción del error del bit mercancía.
1= Interrupción permitida.
0= Interrupción no permitida.
BIT 4 BTOEF: Bit de permiso de interrupción del error de espera en el procesamiento del bus.
1= Interrupción permitida.
0= Interrupción no permitida.
BIT 3 DFN8EF: Bit de permiso de interrupción del error del tamaño de los datos.
1= Interrupción permitida.
0= Interrupción no permitida.
BIT 2 CRC16EF: Bit de permiso de interrupción del fallo CRC16.
1= Interrupción permitida.
0= Interrupción no permitida.
BIT 1 CRC5EF: Bit de permiso de interrupción del error del anfitrión CRC5.
1= Interrupción permitida.
0= Interrupción no permitida.
BIT 0 PIDEF: Bit de permiso de interrupción del prueba de fallo de PID.
1= Interrupción permitida.
0= Interrupción no permitida.
 
MODOS DE ENERGÍA DEL USB:
Las aplicaciones USB tendrán diferentes requisitos y configuración de energía.
Los casos más comunes son los presentados aquí.
SÓLO ENERGÍA EN EL BUS:
inmagen25.jpg

En modo de sólo energía en el bus. Es el método más simple de energía para el dispositivo.
SÓLO SELF-POWER:
inmagen26.jpg

En modo sólo SELF-POWER, el uso del USB proporciona su propia energía, con la energía muy pequeña cedida por el USB. Observar que indica cuando el USB ha estado conectado.
ENERGÍA DUAL CON DOMINANCIA SELF-POWER:
inmagen27.jpg

Algunas aplicaciones necesitan una opción con dos energías. La aplicación utiliza la fuente de energía
interna como primaria, pero cambia a la energía del USB cuando no se dispone de una fuente lineal.

Nota: Los usuarios deben tener presente los límites de energía del USB. Según
la especificación del USB 2.0, no puede exceder 100mA en un dispositivo de baja
potencia ó 500mA en uno de alta.

STREAMING PARALLEL PORT (SPP):
El puerto paralelo (SPP) es una ruta alternativa de los datos además de la RAM del USB. Usando el SPP, un Endpoint se puede configurar para enviar o para recibir datos directamente del hardware externo.
Este método presenta posibilidades de diseño donde el microcontrolador actúa como encargado de los datos, permitiendo al SPP pasar bloques grandes de datos sin que el micro regule lo que procesa realmente. Un ejemplo de aplicación puede incluir un sistema de adquisición de datos, donde los datos fluyen de una FIFO externa a través del USB al ordenador. En este caso, el control del Endpoint lo realiza el microcontrolador y los movimientos de datos en bruto se procesan externamente.
El SPP se permite como puerto de un Endpoint del USB a través del BD asociado al Endpoint. El Endpoint tiene que activarse de la siguiente manera:
1. Activar BDnADRL:BDnADRH direccionado a FFFFh.
2. Activar KEN (BDnSTAT<5>) par que el SIE controle el Buffer.
3. Activar INCDIS (BDnSTAT<4>) para inhabilitar el incremento de dirección automático.

Nota 1: Si un Endpoint se configura para utilizar el SPP, el módulo SPP debe configurarse para utilizar el módulo USB. Si no, puede ocurrir una operación inesperada.
Nota 2: Además, si un Endpoint se configura para utilizar el SPP, el tipo de transferencia de datos de ese Endpoint debe ser síncrona.

OSCILADOR:
El módulo USB necesita una señal específica de reloj. En operaciones fullspeed, el reloj tiene que ser de 48MHz. El microcontrolador y los periféricos no tienen porque tener la misma frecuencia de reloj o la misma fuente.
REGISTROS ASOCIADOS A LAS OPERACIONES DEL MÓDULO USB:
inmagen28.jpg

Leyenda: = las localizaciones no están implementadas. Las celdas sombreadas
no se utilizan con el módulo USB.
Nota 1: Esta tabla incluye solamente las localizaciones SFRs mapeadas en el banco 15 de la memoria de datos. Los registros de los BD, que están mapeados en el banco 4 y no son SFRs verdaderos, están en la tabla 17-5.

DESCRIPCIÓN DEL USB:
Esta sección presenta algunos conceptos básicos del USB e información útil necesaria para diseñar un dispositivo USB. Así, se anima al lector que refiera a las especificaciones del USB para más información (www.usb.org). Si estás muy al corriente de los detalles de USB, entonces ésta sección sirve como recuerdo básico, de alto nivel del USB.

ESQUEMA DE CAPAS:
La funcionalidad del dispositivo del USB se estructura en un esquema de capas.
Cada nivel se asocia a un nivel funcional dentro del dispositivo. La capa más alta, con excepción del dispositivo, es la de configuración. Un dispositivo puede tener configuraciones múltiples. Por ejemplo, un dispositivo particular puede tener requisitos de energía múltiples basados en Self-Power o modos de energía sólo del bus.
Para cada configuración, puede haber múltiple interfaces. Cada interfaz podía apoyar un modo particular de esa configuración.
Debajo del interfaz están los Endpoints. Los datos se mueven directamente a este nivel. Puede haber 16 Endpoints bidireccionales. El Endpoint 0 es siempre el Endpoint de control por defecto; cuando el dispositivo está en el bus, el Endpoint 0 debe estar disponible para configurarlo.
inmagen29.jpg
 
Moyano Jonathan la data que estas dando es muy pero muy valiosa para muchas de las personas que se interesan por manejar cosas por USB.
Actualmente estoy con la idea de desarrollar un circuito capas de extrer fotos de una webcam con PIC para utilizarla como camara de video sin tener que depender de una PC, y enviar la imagen a un TV o monitor.
Gracias a tu informacion voy a poder entender y comprender el funcionamiento del modulo USB que utiliza el PIC, y con el poder manejar la camara.
Si te intreza el proyecto podriamos desarrollarlo juntos y aprender del mismo.
Desde ya muchas gracias por tu aporte tan valioso para la comunidad.
 
Disculpa la pregunta pero me podrias explicar de manera sencilla como esta eso del pic 18fxxx y el puerto USB yo he trabajado solo con el pic 16f84 y 16f628 y 12f508 pero me gustaria saber que es eso del USB y que podria hacer con el , se que es una pregunta chafa pero me interesaria saber que es eso, gracias , buen dia
 
Hola soulmen ! Si el ejemplo está en ASM para PIC24f ponelo pero si está en C30 por favor ponelo en un hilo aparte ...por que este tema es solo para USB en ASM.
Un saludo !


Hola Moyano....a pesar de que este hilo tiene mas de 6 meses de inactividad,he leido largamente
los tòpicos buscando mi pregunta al asunto que es la siguiente y pido disculpa si se me paso por alto.
Para mi todo el tema PIC es claro ,incluso en USB,por tanto esperaba de tu parte que hablaras de lo que para mi es de lo mas importante y que me impedia hacer algun desarrollo en USB y es el siguiente :
Todo muy lindo respecto de la PIC y su puerto USB....el tema es cuando lo quieres conectar a ALGO...del otro lado.
Uno supone que la aplicacion mas directa y lògica es ...una PC.
Ahi aparece el TEMA...DRIVERs , junto con Libreria para sist. Operativos ,derechos intelectuales y -know how-, acceder a -info- de estructuras y compatibilidad en protocolos ,mas las herramientas de implementaciòn ,casi todas con derecho de copia....
Me perdì de algo ? Esa parte ya la tienes solucionada ?
Quiero decir ,para hacerlo fàcil...enchufas tu -aparatito- en una con XP y....?
Donde està la -info- pùblica , del protocolo de atenciòn ?
La estructura del bloque de datos ?
Que libreria del sist operativo -atiende- los puertos ?
Como indusco al sist.operativo a que dispare -mi programa residente- que -atiende- la aplicaciòn de mi interfaz USB,cualquiera que esta fuese ? (supongamos,enviar datos de un voltimetro )
El sistema operatico XP ademas, ante una conexiòn de este tipo ,pide el codigo VENDOR,referente al fabricante de la electronica y software asociado para darle curso.
Esa parte , hay que PIRATEARLA para que sea posible , segun entiendo.
si respondes continuo....


....un saludo.
 
Última edición:
Este tema lo he dejado de lado para cuando tenga mas tiempo para encararlo por que el estudio que hay que hacer es intensivo....ya tengo la info pero está todo en inglés y tengo que pedir algunos permisos de sus autores..por que parte la he extraido de trabajos ajenos...lo que he podido realizar yo es el control de dispositivos USB pero trabajando en C
 
Moyano Jonathan la data que estas dando es muy pero muy valiosa para muchas de las personas que se interesan por manejar cosas por USB.
Actualmente estoy con la idea de desarrollar un circuito capas de extrer fotos de una webcam con PIC para utilizarla como camara de video sin tener que depender de una PC, y enviar la imagen a un TV o monitor.
Gracias a tu informacion voy a poder entender y comprender el funcionamiento del modulo USB que utiliza el PIC, y con el poder manejar la camara.
Si te intreza el proyecto podriamos desarrollarlo juntos y aprender del mismo.
Desde ya muchas gracias por tu aporte tan valioso para la comunidad.

Tratamiento de sonudo están los dsPIC. Para tratamiento e Audio/Vídeo se usa los PIC32.
 
Los PIC18 con USB no pueden trabajar como host, por lo tanto no se le pueden conectar otros dispositivos como memorias usb, cámaras usb, etc. Para eso se necesita de los PIC32 o superiores.
Solo eso...

chauuu y éxitos...
 
Los PIC18 con USB no pueden trabajar como host, por lo tanto no se le pueden conectar otros dispositivos como memorias usb, cámaras usb, etc. Para eso se necesita de los PIC32 o superiores.
Solo eso...

chauuu y éxitos...

No se a quien respondias , pero si era a mi, te digo que es claro que estas PICs, no funcionan como HOST , sino como clientes de una hipotètica red.
Puedo conectar a esta RED de un MICRO de 32 bits., pero a menudo la comunicacion se justifica como comunicante a distancia de los elementos y en USB, el cable no supera los 3 metros.
Asi que nos queda solo la posibilidad de transferencia a -otro - entorno de dichos -datos-.
Es dificil pensar que la info dentro del micro 32 bit, pueda ser muy ùtil, ya que lo que la potencia, es la posibilidad de transferir a la -NUBE- mundial de datos a traves de protocolos unversales con derecho a copia casi todos ellos.
Tal vez la soluciòn sea....LINUX,que es un remedo invertido del sistema UNIX de los unversitarios Yankees!!!
..y ahi ...me prendo !!!! Saludos.
 
Última edición:
Gente,estoy siguiendo el hilo de este tutorial,ya que necesito comunicar un pic por usb con un pc.
El proyecto es enviar un valor de voltaje que se ha capturado en el conversor ad y un nombre asociado,por ejemplo "voltaje1" "6".
La limitacion mas grande que tengo es que no entiendo ni j de lenguaje C y solo se hacer el firmware en ASM.
Alguien podria aportarme algo mas en el hilo del tutorial como para poder empezar con algo en la practica?.
He estado googleando y no hay practicamente nada para asm.
 
Es que el problema está en que hay que desarrollar prácticamente desde o, hay algunos ejemplos en la red en asm para comunicar el PIC mediante HID...pero entenderlos es un muy complejo si no sabes como funciona estructuralmente el USB.
 
Ya tengo algo de documentación como para empezar, espero poder seguir pronto. En este momento me estoy yendo de vacaciones y no voy a tener mi pc a mano...espero poder seguir aportando al hilo que se va a poner interesante...pero tengan paciencia todo lo que respecta al USB en si...es muy complicado y largo de entender ..por eso no he tenido tiempo de ponerme al 100%
 
Atrás
Arriba