TODOPIC
Microcontroladores PIC => Todo en microcontroladores PIC => Mensaje iniciado por: cabflip en 07 de Mayo de 2013, 13:50:30
-
Hola gente, soy nuevo en el foro y estoy acá porque ya no se a quien mas recurrir! :5]
Una empresa me encargo un proyecto USB, yo les dije que no tenia ni idea sobre el tema a lo que me contestaron que no importaba, que querían que lo haga yo, que averigüe... ja!
No quiero molestarlos con todo el resto del programa porque es largo y solo tengo problemas en la transmisión. El tema es el siguiente, con un PIC18F4550 y un xtal de 20Mhz, necesito transmitir 250KB en un segundo, que son repetidas mediciones de una plancha de 48x48 sensores, que ya están guardadas en la memoria del micro. Para probar la TX con la PC me base en el proyecto de http://picmania.garcia-cuervo.net/usb_3_cdctransfers.php, el cual me anduvo sin problemas... excepto que solo lograba transmitir al rededor de 50kb en un segundo... demasiado lento para lo que necesito.
El programa lo hice en CCS y utilice el hyperterminal para recibir el los datos en la pc. Como podrán ver en el cogido a continuación, mi idea fue mostrar los datos en forma de tabla, 48 columnas, 48 filas y transmitir 50 veces la plancha, que es mas o menos lo que necesito. Una vez que envio las 50 planchas hace titilar un led que se encuentra en el PIN C0.
El circuito es TAN SIMPLE COMO ESO, transmite por USB y en el pin C0 hay un led, nada mas.
Este fue el codigo que utilice, basado en el proyecto de picmania:
#include <18F4550.h>
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use delay(clock=48000000)
#include ".\include\usb_cdc.h"
void main() {
BYTE columna,fila,plancha;
output_high(PIN_C0);
delay_ms(300);
usb_cdc_init();
usb_init();
while(!usb_cdc_connected()) {}
output_low(PIN_C0);
while (TRUE) {
for(plancha=1;plancha<=50;++plancha){
for(columna=1; columna<=48;++columna){
printf(usb_cdc_putc, "\r\n");
for(fila=1; fila<=48; ++fila) {
printf(usb_cdc_putc, "%2x" fila);
printf(usb_cdc_putc, " ");
}
}printf(usb_cdc_putc, "\r\n\n Plancha: ");
printf(usb_cdc_putc, "%2x" plancha );
printf(usb_cdc_putc, "\r\n");
}
while (TRUE)
{output_toggle(PIN_C0);
delay_ms(500);}
}
}
Estaria muy agradecido si me pudieran ayudar con este problema!
Saludos!
Facundo
-
Tu led nunca va a tildar porque el 1er while nunca termina.
-
Hola.
Lamento decirte que en el modo en el que te estás comunicando, el máximo es de 64KBps por endpoint. Podrías intentar enviar mediante 4 endpoints la información, e intentar de esa manera llegar a los 256KB, o vas a tener que usar el oscuro y tabú modo Isócrono. Yo he implementado comunicación isócrona, pero con microcontroladores ARM, y he logrado velocidades de hasta 1023KBps con un sólo endpoint.
Saludos.
-
Buno, el modo bulk no es mas rápido que el cdc?
-
El máximo de la especificación full speed(12mbps que es el que tienen esos uC) si no recuerdo mal, es de 64 bytes por milisegundo por endpoint, máximo( <= 64KBps). El bulk es el peor de todos, porque es el que tiene menor prioridad. Cualquier otro dispositivo conectado al bus va a tener más o al menos igual prioridad para intercambiar datos.
Saludos.
-
Mmm pense que el hid era el peor de todos, pues el bulk requiere de driver.
-
El HID tiene tiempo de entrega garantizado, el bulk no. Igualmente el HID puede requerir de driver también, todo depende del descriptor.
Saludos!
-
Si bueno, todo seria cuestion de pruebas. Yo realice algunas pero sin finalizarlas, andaba habilitando mas endpoints en modo bulk. Y bueno, como bien dices, el modo isocrono es un tabu en los pic, aunqe se que podria llegar algun bit defectuoso en este modo.
-
Si, en modo isócrono no hay verificación de integridad de paquete y por lo tanto tampoco reintento de envío automático. Pero siempre podés vos implementar un CRC o simil para verificar la integridad del paquete, si es que te hace falta. En mi caso como es un stream de video, si un valor falla, pues no es tan grave.
Saludos.
-
Tu led nunca va a tildar porque el 1er while nunca termina.
Este programa ya anduvo, el led titila porque esta adentro del while, solo que el programa lo dejo estancado ahi porque no necesito que haga nada mas una vez que envio la plancha.
Saludos
-
Hola.
Lamento decirte que en el modo en el que te estás comunicando, el máximo es de 64KBps por endpoint. Podrías intentar enviar mediante 4 endpoints la información, e intentar de esa manera llegar a los 256KB, o vas a tener que usar el oscuro y tabú modo Isócrono. Yo he implementado comunicación isócrona, pero con microcontroladores ARM, y he logrado velocidades de hasta 1023KBps con un sólo endpoint.
Saludos.
Okey, la verdad es que empece a mirar el tema este del usb hace unas semanas y todavia me cuesta manejar algunas cosas, sobre todo porque no logro encontrar alguna pagina o algun ejemplo que me explique bien como utilizar el metodo bulk, diferentes endpoints y todo lo que necesitaria para al menos conseguir unos 250kbps. No tenes algun link o algun programa donde pueda mas o menos entender como establecer una buena comunicacion con la menor perdida de datos posible?
Gracias! Saludos
-
Tienes razon, tus llaves me confundieron xD
-
Hola.
Lamento decirte que en el modo en el que te estás comunicando, el máximo es de 64KBps por endpoint. Podrías intentar enviar mediante 4 endpoints la información, e intentar de esa manera llegar a los 256KB, o vas a tener que usar el oscuro y tabú modo Isócrono. Yo he implementado comunicación isócrona, pero con microcontroladores ARM, y he logrado velocidades de hasta 1023KBps con un sólo endpoint.
Saludos.
Okey, la verdad es que empece a mirar el tema este del usb hace unas semanas y todavia me cuesta manejar algunas cosas, sobre todo porque no logro encontrar alguna pagina o algun ejemplo que me explique bien como utilizar el metodo bulk, diferentes endpoints y todo lo que necesitaria para al menos conseguir unos 250kbps. No tenes algun link o algun programa donde pueda mas o menos entender como establecer una buena comunicacion con la menor perdida de datos posible?
Gracias! Saludos
Si eliges el bulk, ten cuidado porque como he dicho previamente, el bulk no tiene tiempo de entrega asegurado. Es decir que no se hará el mayor esfuerzo posible en intentar enviar la información rápidamente, sino que se le dará prioridad antes a cualquier otro dispositivo HID, Isocrono, etc.
RedPic ha generado un contenido muy completo de algunas clases del USB, entre ellas el Bulk:
http://picmania.garcia-cuervo.net/usb_0_desencadenado.php
El problema no es la pérdida de datos. El problema es que el USB Full Speed(12Mbps), que es el de mayor velocidad que soportan estos micros, tiene un límite de 64kBps en cualquiera de sus modos: Bulk, HID, CDC, etc. El único que se sale de eso es el Isócrono, que permite hasta 1023kBps.
En el foro de Microchip he visto gente que ha implementado Isócrono en PIC, claro que usando el compilador de Microchip, no el CCS.
-
Si eliges el bulk, ten cuidado porque como he dicho previamente, el bulk no tiene tiempo de entrega asegurado. Es decir que no se hará el mayor esfuerzo posible en intentar enviar la información rápidamente, sino que se le dará prioridad antes a cualquier otro dispositivo HID, Isocrono, etc.
RedPic ha generado un contenido muy completo de algunas clases del USB, entre ellas el Bulk:
http://picmania.garcia-cuervo.net/usb_0_desencadenado.php
El problema no es la pérdida de datos. El problema es que el USB Full Speed(12Mbps), que es el de mayor velocidad que soportan estos micros, tiene un límite de 64kBps en cualquiera de sus modos: Bulk, HID, CDC, etc. El único que se sale de eso es el Isócrono, que permite hasta 1023kBps.
En el foro de Microchip he visto gente que ha implementado Isócrono en PIC, claro que usando el compilador de Microchip, no el CCS.
Es que estuve revisando mucho el material subido por RedPic, el problema con el método bulk es que no conseguí hacer andar el driver, al menos no en mi PC (tengo Windows 7 de 64bits, capaz sea por eso) por lo que no pude ni enumerar el pic. Busque drivers para el metodo bulk, para win 7 de 64bits pero no me anduvieron.
No hay alguna forma de habilitar mas endpoints para el metodo CDC? Para hacer como vos decís de lograr 256KB/s.
-
Raro lo del driver. Podrías bajarte el "Microchip Solutions" de la página oficial de Microchip. Allí dentro viene, entre otras tantas cosas, el último driver que debería ser compatible con x86 y x64. Si usas HID con descriptores que no se salgan de lo estándar, no requieres drivers para nada.
Por otro lado, deberías poder agregar endpoints y/o interfaces a gusto. Lamentablemente CDC es uno de los que menos he usado, y sólo para lograr un conversor USB a RS232. Lo que puede complicarse luego es la recepción de los paquetes por varios endpoints, pero si eres organizado y puedes identificar correctamente cada parte, seguramente lograrás reconstruir los datos en la PC.
-
Mmm bueno, gracias bruno, voy a probar con el metodo HID que lo utilice solo una vez, adaptando un ejemplo de un teclado, que no me anduvo para nada porque obviamente usaba delays para no enviar un millon de veces la letra cada vez que presionas la tecla jaja y como no supe sacarlos, perdia mucha info en el envio y lo deje ahi.
Ayer justo descargue algo llamado Application library de microchip. La instale y todo pero no me resolvió ningún problema con el driver, al contrario. Voy a probar con el Microchip solutions que me dijiste a ver si puedo terminar con este proyecto de una buena vez!
En cuanto pruebe seguramente voy a volver con mas dudas jaja
Saludos y gracias!
-
Buenas, pregunta para Bruno, ya que no sabia lo de las prioridades del bulk, implemente un joystick en HID leyendo encoders, y no lograba que la pc detecte cada movimiento del encoder, y no eran muchos, a lo sumo 10 por segundo, despues tome el mismo programa y lo hice en bulk y logro detectar mucho mas que 10 o 20 pulsos por segundo, siempre me pregunte si era problema del HID, o del soft de la pc que no lograba detectar tantos datos por segundo, es posible esto, o esta mal implementado algo en el HID y no caigo en la cuenta?
Saludos.
Alejandro.
-
Mmm bueno, gracias bruno, voy a probar con el metodo HID que lo utilice solo una vez, adaptando un ejemplo de un teclado, que no me anduvo para nada porque obviamente usaba delays para no enviar un millon de veces la letra cada vez que presionas la tecla jaja y como no supe sacarlos, perdia mucha info en el envio y lo deje ahi.
Ayer justo descargue algo llamado Application library de microchip. La instale y todo pero no me resolvió ningún problema con el driver, al contrario. Voy a probar con el Microchip solutions que me dijiste a ver si puedo terminar con este proyecto de una buena vez!
En cuanto pruebe seguramente voy a volver con mas dudas jaja
Saludos y gracias!
Ese Application Library es precisamente el famoso "Microchip Solutions". Fijate en "...\Microchip Solutions v2012-04-03\USB\Tools\MCHPUSB Custom Driver\MCHPUSB Driver\Release\"
si te instala el driver en x64.
Buenas, pregunta para Bruno, ya que no sabia lo de las prioridades del bulk, implemente un joystick en HID leyendo encoders, y no lograba que la pc detecte cada movimiento del encoder, y no eran muchos, a lo sumo 10 por segundo, despues tome el mismo programa y lo hice en bulk y logro detectar mucho mas que 10 o 20 pulsos por segundo, siempre me pregunte si era problema del HID, o del soft de la pc que no lograba detectar tantos datos por segundo, es posible esto, o esta mal implementado algo en el HID y no caigo en la cuenta?
Saludos.
Alejandro.
Hola, cómo implementaste el encoder? Es decir, cómo representaste el encoder en el descriptor del HID? El problema muchas veces pasa por el lado de la PC. Uno siempre se envicia y quiere enviar la mayor cantidad de información posible, lo más rápido posible. Por ejemplo, si te dan a elegir el intervalo de envío, le ponemos 1ms (el mínimo para USB Full Speed). Todo tiene un costo. Seguramente lo que te estaba pasando en HID es que tu aplicación estaba perdiendo algunos paquetes, seguramente debido a la alta velocidad a la que los enviabas y/o a un mal driver de comunicación HID de la PC o bien a un algoritmo de captura de datos recibidos lento o deficiente. Por ahí es mejor hacer menos envíos y concentrar más la informacion, si es posible, para minimizar la posibilidad de perder un paquete y tener más tiempo de procesado y entre pooling.
Pensemos por ejemplo en un mouse, sea tanto por puerto PS2/mini-PS2 o USB. El mouse va a intentar enviar cada cierto intervalo de tiempo, entre otras cosas, la cantidad de movimiento acumulado. Si no puede confirmar el envío satisfactorio (tanto el PS2 como el USB permiten saber si el paquete ha sido enviado correctamente) seguirá acumulando los nuevos movimientos al previo, e intentará reenviar el paquete luego. Pero fijemonos en que la cantidad de movimiento total, cuando se reciba, se mantendrá fiel a la realidad (aunque habremos sido penalizados sin saber por dónde se ha movido el mouse durante todo ese tiempo en que no logró enviarnos su movimiento acumulado). Más de una vez seguramente habrán sufrido este tipo de "congelamientos" en el puntero del mouse de su PC, en el cual el mouse cambia de posición sólo una vez por segundo o a veces más. Pero sin embargo, una vez que la posición del puntero se refresca, el movimiento se mantiene fiel al hecho en el mouse. De eso se trata en caso de encoders, de no perder los valores ya que los datos relacionados al movimiento son relativos, no absolutos.
Saludos.
-
Gracias Bruno por la respuesta, lo que implemente fue un joystick común, en el pic hacia la lógica para saber en que dirección giraba el encoder, cuando tenia ese dato lo enviaba como pulsación de un botón, por ejemplo el 1, cuando giraba en sentido contrario enviaba el 2, así cada vez que el pic detectaba que el encoder avanzaba o retrocedía enviaba el dato, luego lo dejaba un cierto tiempo pulsado, el suficiente para que el próximo movimiento del encoder no se solape con el anterior, y eso era todo, funcionaba muy bien, solo que lerdo, no se podía enviar muchos datos seguidos como te comentaba, luego con el bulk, lo que hago es directamente convertir la rotación del encoder en un numero, 1 para avanzar 255 para retroceder, y asi envio de una los datos de 8 encoders, mas 8 ejes, y alli desde un soft en visual basic interpretaba los datos, ahi se terminaron los problemas, puedo enviar datos suficientes para mi aplicación.
Otra cosa que me comentaron es la opción de hacer la repetición de un pulsador, osea que el driver de la pc al recibir una cierta cantidad de pulsos, pasaba a modo repetición, osea por cada pulso recibido el driver lo convertía en 10 por ejemplo, esto no lo probé (porque no me quedan claro algunas cosas), y no lei, fue el comentario de otro forista en otro foro.
Ahora viendo como funciona el sistema en modo bulk, no quiero cambiarlo, pero me gustaría saber por que no funcionaba antes.
Espero haberme hecho entender.
Saludos
Alejandro.
Edito, bah agrego algo, siempre trate el encoder como relativo, ya que paso solo los incrementos, como estaba tratado como pulsaciones de botones los incrementos, no puedo hacer lo mismo que el mouse
porque en realidad me serviria hacer lo que hace la rueda del mouse.
En definitiva lo que busco hacer es modificar algo en la pantalla (las radios del flight simulator), con un encoder, si giro rapido el encoder en lugar de saltar de uno en uno salta de 5 en 5, ese es el resultado
que buscaba con le HID, al final hago todo en un soft de visual basic y listo.
-
En definitiva lo que busco hacer es modificar algo en la pantalla (las radios del flight simulator), con un encoder, si giro rapido el encoder en lugar de saltar de uno en uno salta de 5 en 5, ese es el resultado
que buscaba con le HID, al final hago todo en un soft de visual basic y listo.
Jeje, justo estoy con esto, pero en lugar de las radios estoy haciendo un control para el MCP. Tengo montato el circuito en placa board pendiente de acabar la pcb y haciendo pruebas. Estoy controlando unos 10 pulsadores, un par de interruptores, unos 10 leds, 1 encoder y 1 lcd.
La conexión es usb en modo HID y no tengo ningún problema, ni noto nada de demora. La unica diferencia es que no lo controlo como joy sino que realicé una interface en C# que intreactua entre fsx y pic.
Lo que me gusta del HID es que no tengo que preocuparme de drivers :P
Un saludo
-
Ese Application Library es precisamente el famoso "Microchip Solutions". Fijate en "...\Microchip Solutions v2012-04-03\USB\Tools\MCHPUSB Custom Driver\MCHPUSB Driver\Release\"
si te instala el driver en x64.
Uh recién lo acabo de instalar y me lo tomo genial, pero el problema es que sigue sin enumerar el USB no se porque. Se estanca en el "usb_wait_for_enumeration();". Puede ser porque ningun programa en la pc recibe los datos que envio? Yo estoy usando el USB Monitor Pro, pero no se sirve para lo que yo quiero. Yo querria un Hyperterminal, pero para USB, ¿tenes idea de cual podria usar?
Gracias!
-
Dónde estás viendo que se queda en usb_wait_for_enumeration()? En el PIC?
Te recomiendo que te bajes el USBLyzer y el USBDeview para poder saber bien qué está pasando y si se está intercambiando información con el dispositivo. Para convertir un USB en RS232 se usa CDC.
Saludos
-
En definitiva lo que busco hacer es modificar algo en la pantalla (las radios del flight simulator), con un encoder, si giro rapido el encoder en lugar de saltar de uno en uno salta de 5 en 5, ese es el resultado
que buscaba con le HID, al final hago todo en un soft de visual basic y listo.
Jeje, justo estoy con esto, pero en lugar de las radios estoy haciendo un control para el MCP. Tengo montato el circuito en placa board pendiente de acabar la pcb y haciendo pruebas. Estoy controlando unos 10 pulsadores, un par de interruptores, unos 10 leds, 1 encoder y 1 lcd.
La conexión es usb en modo HID y no tengo ningún problema, ni noto nada de demora. La unica diferencia es que no lo controlo como joy sino que realicé una interface en C# que intreactua entre fsx y pic.
Lo que me gusta del HID es que no tengo que preocuparme de drivers :P
Un saludo
Hola, yo tengo por ahora andado 5 encoders del panel de un C172, y el problema lo note cuando quieres por ej mover el OBS del VOR, y quieres darle una vuelta completa al VOR, entonces ahi empece a notar que debia dar como 20 vueltas del encoder, estudiando vi que se saltaban pulsos (como que la PC no los veia), entonces intente hacer la aceleracion como la de la rueda del mouse que cuando la giras rapido empieza a aumentar mas por cada pulso que llega a la pc, ahi vi que me era imposible lograr eso, por ello pase a bulk, con un soft en visal basic, y de ahi por ethernet lo escribo en el FSX, como alli puedo regular las aceleraciones, y la cantidad de pulsos por cada tic del encoder, opte por dejar asi como esta, la ves que quise utilizar esa forma en HID, se me colgaba todo.
Saludos.
-
Dónde estás viendo que se queda en usb_wait_for_enumeration()? En el PIC?
Te recomiendo que te bajes el USBLyzer y el USBDeview para poder saber bien qué está pasando y si se está intercambiando información con el dispositivo. Para convertir un USB en RS232 se usa CDC.
Saludos
Hice que titile un led una vez después de el usb_init(); una vez despues del usb_task(); y cuando tendria que titilar de nuevo, pero dos veces, despues de Usb_wait_for_enumeration(); no lo hace, y se queda encendido. La idea era que desp de configurar todo se apague, pero nunca llega a enumerar el dispositivo. Dale, los voy a probar a ver que tal.
-
Hola gente del foro! Pude resolver el problema de la velocidad con el CDC, pero tengo un nuevo problema... Cuando hago:
rx_pc= usb_cdc_getc();
usb_cdc_putc(rx_pc);
La pc SIEMPRE recibe 37 en decimal, sin importar que caracter le envie. El programa en pc es un transceptor via RS232. Enumera el dispositivo correctamente, funciona todo, excepto que el pic recibe siempre lo mismo. Lo use puenteando la RX con TX de una placa que convierte USB en RS232 y lo que yo envio, lo devuelve tal cual. Pero al momento de recibirlo en el pic, o de enviarle al pic siempre recibe 37 en decimal.
Espero que puedan ayudarme!
Gracias y saludos
-
Hola, no recuerdo bien las librerías, pero no deberías primero asegurarte que hay algo que leer haciendo un usb_kbhit()?
Saludos.
-
Hola, no recuerdo bien las librerías, pero no deberías primero asegurarte que hay algo que leer haciendo un usb_kbhit()?
Saludos.
#include <18F4550.h>
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use delay(clock=48000000)
#include ".\include\usb_cdc.h"
////////////////////// Definicion de las Funciones /////////////////////////////
void config_puertos (void){
SET_TRIS_B (0b11111111); //Todo entrada, DATOS
SET_TRIS_D (0b11110000); //4 bits + sign. ENTRADAS, 4 bits - sign. SALIDAS
}
/////////////////////////////// Defines ////////////////////////////////////////
#BYTE PORTA=0xf80
#BYTE PORTB=0xf81
#BYTE PORTD=0xf83
#define LED pin_C0
////////////////////////// Variables Globales //////////////////////////////////
BYTE i,RX_PC=0,prueba=0xff;
//////////////////////////// Funcion Main //////////////////////////////////////
void main() {
ON(Led);
delay_ms(300);
usb_cdc_init();
usb_init();
while(!usb_cdc_connected()) {}
OFF(Led);
delay_ms(500);
ON(Led);
while (TRUE) {
if(usb_cdc_kbhit()) //Si el ENDPOINT contiene datos del host..
{RX_PC= usb_cdc_getc();
usb_cdc_putc(RX_PC);
usb_cdc_putc(prueba);
} //Bucle de transmision (If KBhit contiene datos)
// ON(Led); //Antes de salir enciende el led READY para proxima operacion
} //Bucle infinito
} //Bucle Main
Sisi obvio, ahi esta todo el codigo. Envio a la PC sin problemas la variable PRUEBA, pero recibe SIEMPRE lo mismo, sin importar que dato le envie. ¿Alguno tiene idea de porque podria ser?