Dudas USB y 12Mbps

[giff]

Hola nuevamente. ¿Han intentado (del lado del PC) mantener siempre los pipes out enviando datos? Pregunto porque, al momento de que el PIC este listo de enviar la información al host este ya tenga asegurado el dato que el buffer.

pongo un ejemplo en el lado del PIC, con el EP2:

Código: C

1. usb_task();
2.       if(usb_enumerated())        
3.          {  
4.              while(usb_kbhit(2)) /*mientras tenga algo, no importa que dato sea, envie.*/
5.              {    
6.             usb_put_packet(2, envia_int32, 24,USB_DTS_TOGGLE); /*enviamos el paquete de tamaño 1byte del EP2 al host  */  
7.             }
8.          }

En el lado del PC se activa un evento activado por un timer solo datos para el EP2 OUT enviando mas rápido que nuestra rutina en el pic solo para asegurar la transferencia que hay dato. En mi caso, envio datos cada un segundo al host pero se me desincroniza este porque no se como cuadrar los tiempos del PIC con los del PC. Así que uso un EP2 IN exclusivo para enviar las lecturas al host, mientras que el OUT lo voi sobreescribiendo a una velocidad mayor al envió propiamente tal.

Lo probare para mas EP, pero no tengo como tasar la velocidad de transferencia.

PD: wii aprendi a usar geshi

[migsantiago]

Para el modo bulk no hace falta enviarle un dato al pic para que el endpoint responda.

Sólo basta con enviar el dato y que la PC siempre los esté recibiendo. La PC no debe enviar nada a nivel datos, sólo a nivel protocolo pero esta parte es invisible a nivel usuario.

La siguiente rutina en el pic sería más que suficiente...

Código: [Seleccionar]

while(condicion[0])
{
while(usb_put_packet(2, condicion, 24,USB_DTS_TOGGLE)==0);
}

Mientras haya algo que enviar, que lo envíe, pero que espere a que se haya enviado.

[giff]

Ouch, gracias por dar correcciones de concepto migsantiago, aun me falta pero iré a las montañas y seguir practicando. Claro, tal como dices, dicho y hecho ya que no es necesaria una condicion para que el pic envíe al host, eso lo torna mucho más facil para mi.

Del lado del pc dejo un timer corriendo cada 1 ms haciendo esto:

Código: C#

1. public devolver_calculo Lect_calculo(){
2.            
3.             devolver_calculo dvc;
4. envia_denueo:          
5.             byte* receive_buf = stackalloc byte[24];
6.  
7.             DWORD RecvLength = 24;
8.        
9.             ReceivePacket2(receive_buf, &RecvLength);
10.  
11.            
12.                 byte[] buffsal = new byte[24];
13.        
14.                 int suma = 0;
15.                 for (int i = 0; i < 23; i++)
16.                 {
17.                     buffsal[i] = receive_buf[i];
18.                     suma +=  buffsal[i];
19.                 }
20.             if(suma == 0)
21.             {
22.                 goto envia_denueo;
23.  
24.             dvc.p_total = (float)0.001234 * (BitConverter.ToInt32(buffsal, 0)) - (float) 0.0012;
25.             dvc.p_off =(float) 0.001234 * BitConverter.ToInt32(buffsal, 4) - (float) 0.0012;
26.             dvc.p_on = BitConverter.ToInt32(buffsal, 8);
27.             dvc.dato_p_off_pctaje = BitConverter.ToInt32(buffsal, 12);
28.             dvc.dato_p_on_pctaje = BitConverter.ToInt32(buffsal, 16);
29.             dvc.dato_p_ahorro_pctaje = BitConverter.ToInt32(buffsal, 20);
30.            
31.             return dvc;
32.             }

Ahí aseguro que lleguen mis datos al buffer, que llegue lo que llegue y si es cero realizo un goto para volver a recibir packetes desde ese EP2 bajo un timer que hace polling "cada 1ms" (ni idea de cuan exacto será). El programa se me pega cuando desconecto el usb y es porque este se va a un loop indefinido. Debo ingresar otra condicion que me detecte que está conectado o no el PIC al bus. Hay una funcion importada del archivo creo y en un blog (unpocodeelectronica) creo que vi como proceder. Seguire investigando

[migsantiago]

Los timers que Visual Studio tiene no son precisos. Es muy difícil obtener tiempos precisos menores a 5ms a nivel usuario.

Si el CPU está atendiendo más procesos al mismo tiempo, esos tiempos de 1ms crecen.

Para garantizarlos hay que ejecutarlos a nivel kernel según lo que he leído.

[WOOD_girl]

hola migsantiago, te felicito por este post, esta realmente bueno, pues te comento que yo tambien soy una de las tantas personas que necesitan enviar datos hacia el PC de manera rapida y eficiente. yo he utlizado el modo BULK para tratar de transmitir 1000 bytes obtenidos previamente por el conversor ADC del pic (lo mismo que tu intentabas hacer al inicio del post) pero intente enviar primero un array tipo char y lo simule en proteus y funciono muy  bien, pero al probarlo en fisico, no llegaban ni 200 bytes (estoy usando el  usb_puts), note que tu mencionaste un retraso de 250mS, no hay posibilidad de bajarle a este restraso??.   se que tu solucionaste el problema usando el HID, pero he intentado descargar la informacion que has posteado pero los enlaces dicen que no hay archivos, podrias actualizar los links porfavor???

yo estoy trabajando en labview 8.2 y la verdad que tampoco colabora mucho (es muy lento). sera facil manejar el HID en labview??


agradezco mucho tu colaboración

[migsantiago]

Hola Woodgirl

El retraso de 250ms es usando la clase CDC (RS232 virtual), no con bulk (según recuerdo porque esas pruebas las hice hace como un año).

Yo dejé de usar el modo bulk porque tiene un enorme inconveniente... el host (el controlador USB en la PC) no pide los datos constantemente. Los endpoint BULK sólo transmiten información cuando el bus USB está desocupado.

Sobre los archivos HID, la mejor librería que he visto está en www.lvr.com. No sé a qué archivos te refieras.

Rara vez uso Proteus porque tiene muchos inconvenientes y bugs. Uno se alegra cuando el firmware opera virtualmente; pero cuando se prueba en la realidad y falla, es un caos.

Hace unos meses quise probar Labview y HID mediante una enumeración especial (se hace un driver único para el dispositivo USB). El HID se desenumeraba (desconectaba) constantemente por lo que mejor desistí.

[WOOD_girl]

hola migssantiago, gracias por tu respuesta, mira yo estoy adquiriendo datos por el ADC  almaceno 1000 datos en un array y luego los envio, entonces me recomiendas que me pase a HID?? (si pasa lo que tu dices, entonces va a ser un lio!). y  pues estuve mirando lo que te comente en mi anterior post y ya pude visualizar 766 bytes  en el labview desde el pic18f2550,  la solución?,  cambiar el receivedelay de 1mS a 50mS.


los archivos a los que hago referencia es a la libreria que tu modificaste y que nombraste USB_fast.

[migsantiago]

Si te es sencillo entender el código de www.lvr.com entonces pasa a HID. Pero si te es complicado mejor sigue con bulk.

Todos usamos CCS para echar a andar USB pero C18 tiene muy buenos ejemplos de USB. Hay unos endpoints isócronos que son como los hermanos menores de los interruptivos (los usados en HID). Los isócronos envían datos de forma constante (velocidad y tiempo) pero tienen la desventaja de que no corrigen errores. Los interruptivos son iguales pero sí corrigen errores.

Dale una revisada a la Microchip Applications Library y a los muchos ejemplos USB que trae. Talvez encuentres algo que satisfaga tu problema.

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784

La clase de Audio implementa endpoints isócronos.

Sobre la librería usb_fast, el código está en este tema:

http://www.todopic.com.ar/foros/index.php?topic=25188.msg224608#msg224608

[WOOD_girl]

muchas gracias santiago me pondre de inmediato a leer ( y tratar de digerir) la info, y muchas gracias por la libreria, estare comentando los avances o tropiezos, 

[Suky]

Hoy se me ha venido a la cabeza los comentarios de algunos foreros que indicando que al trabajar con USB y otras interrupciones ocurren problemas con la comunicación.  Me llama la atención el problema, porque seguramente con una buena administración del uso de las interrupciones esto seguramente no ocurre. Pero encontré otro detalle a mi parecer importante, el cual es que en CCS se acostumbra a no trabajar con las prioridades de las interrupciones que nos provee el hardware de los PIC18F. La solución es sencilla, solo hay que definir:

Código: C

1. #device high_ints=TRUE

Y cambiar en el archivo pic18_usb.c

Código: C

1. #int_usb
2. void usb_isr()
3. {
4.    int8 TRNAttempts;

por

Código: C

1. #int_usb fast
2. void usb_isr()
3. {
4.    int8 TRNAttempts;

Y listo, se trabaja con los 2 vectores de interrupciones, y a la interrupción de USB se le asigna el vector de alta prioridad, por lo cual aunque haya una mala administración de las interrupciones no debería ocurrir problema alguno con la comunicación.

Espero no haber repetido el comentario de algún compañero, pero sinceramente no lo he leído en ningún sitio 


Saludos!   

[migsantiago]

Alguien sabe como hacer una aplicacion CDC que maneje las lineas de control del port serial, ademas de RX y TX ??
Perdon si no es el lugar de consulta, por favor moverlo a donde crean conveniente...

Un poco tarde la respuesta, pero bueno 

Conociendo a los PIC24 me entero que su USART ya incluye los pines que pides RTS y CTS o algo así. Seguro que la librería CDC USB los implementa completamente en hardware, nadamás hay que revisar el código.