Soy estudiante y estoy empezando un proyecto en el que estoy trabajando con el kit de inicio USB dsPIC33E de Microchip. Usé algunas muestras tomadas de este sitio para iniciar, enviar y recibir paquetes. No hay pantalla en esta placa, así que estoy imprimiendo lo que necesito en la pantalla de la computadora con un software de terminal IVT VT220.
Mi primer problema es imprimir más de una línea en la pantalla: si tiene 2 comandos de impresión en el mismo código, imprimirá solo el primero, luego hará el resto del código, solo sin el segundo comando de impresión. Por ejemplo este código:
// some code
putrsUSBUSART("first print");
putrsUSBUSART("second print");
//the rest of the code
imprimirá "primera impresión" y luego hará el resto del código.
El segundo problema que tengo es enviar y recibir mensajes en diferentes modos. Cuando estoy usando el modo de bucle invertido, puedo transmitir un mensaje y luego recibirlo. Al verificar el registro rx, parece que el mensaje se transfirió correctamente. Sin embargo, al cambiar el modo al modo normal y hacer exactamente el mismo proceso, todavía parece que el mensaje que he recibido es válido (¡aunque funciona solo con un dispositivo! Así que se supone que funciona bien solo en loopback, no en modo normal . o tal vez no funciona en absoluto en ambos modos?).
¿Alguna sugerencia de por qué suceden estas cosas?
Creo que la putrsUSBUSART();función probablemente no bloquee y tenga un control de que el periférico esté ocupado. Cuando intenta enviar la segunda cadena, verifica y encuentra que el periférico está ocupado, por lo que simplemente se salta.
Recuerdo otra función de tipo "sendUSB" que funciona de esta manera en las bibliotecas USB.
Para una prueba rápida de lo anterior, intente agregar un retraso entre las dos llamadas de función para ver si resuelve el problema (esta no es una solución permanente; probablemente haya una función para verificar esto, pero esto debería funcionar solo para verificar)
Por lo que puedo ver, el kit de inicio dsPIC33F se basa en otro PIC con un periférico USB para hacer las comunicaciones USB (AFAIK ninguno de los dsPIC tiene un periférico USB) También parece que
el firmware de demostración está configurado para emular un puerto COM para comunicaciones en serie. No pude encontrar ninguna documentación para el código, pero encontré esto:
Las instrucciones para esta demostración se pueden encontrar en C:\dsPIC33E PIC24E USB Starter Kit Demo\Documentation\Getting Started\Getting Started - Running the Device - CDC - Basic Demo. Consulte la sección Ejecución de la demostración.
Supongo que toda la documentación necesaria estará en la carpeta "Documentación". Debe tener detalles de las funciones utilizadas en la aplicación de demostración, para que pueda comprobar cómo funcionan. También puede simplemente verificar el código de función en sí.
Sé que esta es una pregunta antigua, pero en caso de que alguien más venga...
El problema es que las put*USBUSART()funciones no bloquean y, por lo tanto, la pila USB aún no está lista para transmitir la segunda cadena cuando sale la primera función.
Puede verificar si está listo o no a través de la USBUSARTIsTxTrfReady()función. Esta es la forma de crear un conjunto de put[r]sfunciones de bloqueo:
// USB magic stuff
void usbPerformTasks(void)
{
USBDeviceTasks();
if(USBGetDeviceState() < CONFIGURED_STATE /*|| USBIsDeviceSuspended()*/)
return;
CDCTxService();
}
// blocking until we're ready to transmit
void usbBlockTx(void)
{
while(!USBUSARTIsTxTrfReady())
usbPerformTasks();
}
// ROM function
void usbBlockPutRS(const far rom char* str)
{
usbBlockTx();
putrsUSBUSART(str);
/*
* Also put this in if you want to wait for the Tx to finish,
* but if you only use these two functions, you don't need it.
*/
//usbBlockTx();
}
// RAM function
void usbBlockPutS(char* str)
{
usbBlockTx();
putsUSBUSART(str);
/*
* DO NOT COMMENT THIS OUT -- it is needed because putsUSBUSART()
* does not copy the data, which means that `str` could possibly
* get changed in mid-transmission. This is not required for the
* ROM version of the function, since ROM data cannot change -- well,
* unless you happen to be programming the uC, but then we wouldn't
* be running this code here.
*/
usbBlockTx();
}
Chetan Bhargava