Estoy tratando de comunicarme entre una computadora y un PIC32 usando el controlador de dispositivo CDC de las bibliotecas de aplicaciones de Microchip. Tengo un problema, en el que si emito algunas oraciones usando, putrsUSBUSART()no recibo nada. Sin embargo, si agrego eso con un bucle que envía spam, por ejemplo, "prueba\r\n", eventualmente los recibo (y al menos algunas de las oraciones que quería ver).
Estoy usando minicom en una caja de Linux como mi programa de terminal. Si el controlador CDC no debe hacer eso, tendré que mirar el programa del controlador/terminal del host a continuación.
Parece que está utilizando una llamada de salida que desciende o está diseñada para imitar las opciones de venta. puts()es tradicionalmente una función de flujo y, por lo tanto, no se debe esperar que comprometa necesariamente la salida hasta que ocurra algo como:
(y tal vez algunos otros factores desencadenantes relacionados que no vienen a la mente de inmediato)
Como USB es una interfaz empaquetada, también podría tener un algoritmo inadecuado en el firmware para decidir cuándo vale la pena enviar un paquete.
Finalmente, mientras que el controlador CDC-ACM debe ser independiente del proveedor, la API serie posix mediante la cual los programas de aplicación acceden a él se puede configurar para una amplia variedad de comportamientos. Los programas de terminal normalmente lo colocan en un modo bastante crudo y receptivo, pero si termina escribiendo su propio cliente, es probable que necesite algunos ajustes de termios. Puedes jugar con muchas de estas configuraciones desde la línea de comandos usando el sttyprograma.
Siempre diseño cosas con al menos un puerto serial RS232. Intento encarecidamente conectar esto al UART que usa el cargador de arranque, si está presente.
Razones:
1.) Porque se puede usar para depurar otros subsistemas (USB incluido)
2.) Porque es un puerto confiable donde puedo descargar el firmware cuando nada más funciona
scott seidman
chris stratton
chris stratton