Hola, mi duda es la que sigue: segun Moyano Jonathan la velocidad maxima del PIC es 64 Kbps o algo asi.
esto es una payasada, porque con PICS bien equipados, tienen UART que alcanzan mas velocidades que esa cosa.
hay otra forma de controlar al PIC y que realmente alcanze o se aproxime a los 12 Mbps que dice el fabricante que tiene?.
Diganme si se alcanzan esas velocidades para no perder el tiempo y estudiar mas del PIC, o si no lo alcanzan para bnuscar otro micro que si lo haga. gracias
Hola, quería aclarar algunas confusiones. La limitación no es de 64kbps sino de 64 bytes/ms, es decir, 64x8 = 512kbps.
Esto vale para la clase de dispositivo USB estandar llamada CDC (communication device class). En USB hay otras clases estandar como el MSD (mass storage device), HID (human interface device), etc. También se puede definir una interfaz USB no estandar usando la cantidad/tipo de endpoints que uno especifico, son las "Vendor class" o clases propietarias.
La clase CDC en particular utiliza endpoints del tipo INT, que para USB2.0 tiene un tiempo de polling mínimo de 1 milisegundo. En USB el maestro pregunta a intervalos de tiempo regulares o no si el esclavo - nuestro PIC por ejemplo - tiene algo para transmitir. Si los intervalos de tiempo son o no regulares depende del tipo de endpoint: INT/BULK/ISO (no sé si hay alguno más). Se supone que la ventaja de usar INT es que uno tiene asegurado (en teoría) que el dispositivo esclavo es interrogado siempre cumpliendo con el tiempo especificado.
Por eso si uno usa endpoints bulk - donde no se asegura que el esclavo sea interrogado cada cierto tiempo, sino que se interrogará cuando el maestro pueda - esa limitación de tiempo no está. El esclavo se interrogará en intervalos de tiempo que dependerán de cuantos otros dispositivos hayan conectados al mismo bus. De todas formas no creo que interrogue a intervalos menores de 1ms, lo que sí puede pasar es que con bulk el esclavo le puede responder "tengo 256 bytes para enviarte" y esa transacción se puede llevar a cabo si el maestro no está cargado en el milisegundo que dura la transacción. Entonces en vez de transmitir 64 bytes que son el máximo para un endpoint INT (que se utilicen en clases CDC), puede transmitir una cantidad de información mayor; pero no hay garantía de que esa información llegue en el próximo milisegundo, o en los próximos 100 milisegundos. Todo dependerá de que otros dispositivos haya conectados al bus USB.
Bueno, seguramente hay imprecisiones en lo que dije antes, pero quería dar una idea general del por qué de las velocidades y limitaciones.
Siempre podés intentar definir una clase propietaria, pero se te va a complicar el diseño. Usando las clases estandar te asegurás que el día de mañana tu dispositivo no debería tener problemas en ser reconocido por Windows, Linux, MacOS, etc - porque los drivers ya los incorpora el sistema operativo debido a que son estandares ampliamente reconocidos. En cambio si haces un clase propietaria vas a tener que buscar drivers que funcionen para cada SO. En tal caso probá con libusb / libusb-win32 que al menos podría funcionar con Windows/Linux.
Saludos.
