Ich bin Student und starte ein Projekt, in dem ich mit dem dsPIC33E USB Starter Kit von Microchip arbeite. Ich habe einige Samples von dieser Seite zum Initiieren, Senden und Empfangen von Paketen verwendet. In diesem Board gibt es keinen Bildschirm, also drucke ich das, was ich brauche, auf dem Computerbildschirm mit einer Terminalsoftware IVT VT220.
Mein erstes Problem ist das Drucken von mehr als einer Zeile auf dem Bildschirm - wenn 2 Druckbefehle im selben Code vorhanden sind, wird nur der erste gedruckt und dann der Rest des Codes, nur ohne den zweiten Druckbefehl. Zum Beispiel dieser Code:
// some code
putrsUSBUSART("first print");
putrsUSBUSART("second print");
//the rest of the code
wird "first print" drucken und dann den Rest des Codes ausführen.
Das zweite Problem, das ich habe, ist das Senden und Empfangen von Nachrichten in verschiedenen Modi. Wenn ich den Loopback-Modus verwende, kann ich eine Nachricht senden und dann empfangen. Durch Überprüfung des rx-Registers sieht es so aus, als ob die Nachricht korrekt übertragen wurde. Wenn Sie jedoch den Modus in den normalen Modus ändern und genau denselben Vorgang ausführen, sieht es immer noch so aus, als ob die Nachricht, die ich erhalten habe, gültig ist (obwohl nur mit einem Gerät gearbeitet wird! Es wird also angenommen, dass sie nur im Loopback einwandfrei funktioniert, nicht im normalen Modus . oder vielleicht funktioniert es in beiden Modi überhaupt nicht?).
Irgendwelche Vorschläge, warum diese Dinge passieren???
Ich denke, die putrsUSBUSART();Funktion ist wahrscheinlich nicht blockierend und überprüft, ob das Peripheriegerät beschäftigt ist. Wenn Sie versuchen, die zweite Zeichenfolge zu senden, prüft es und stellt fest, dass das Peripheriegerät beschäftigt ist, also überspringt es einfach.
Ich erinnere mich an eine andere Funktion vom Typ "sendUSB", die auf diese Weise in den USB-Bibliotheken arbeitet.
Versuchen Sie für einen schnellen Test des oben Gesagten, eine Verzögerung zwischen den beiden Funktionsaufrufen hinzuzufügen, um zu sehen, ob das Problem dadurch behoben wird (dies ist keine dauerhafte Lösung - es gibt wahrscheinlich eine Funktion, die darauf überprüft werden kann, aber dies sollte nur zur Überprüfung ausreichen).
Soweit ich sehen kann, ist das dsPIC33F-Starterkit auf einen anderen PIC mit einem USB-Peripheriegerät angewiesen, um die USB-Kommunikation durchzuführen (AFAIK, keines der dsPICs hat ein USB-Peripheriegerät)
. Serielle Kommunikation. Ich konnte keine Dokumentation für den Code finden, aber ich habe Folgendes gefunden:
Die Anweisungen für diese Demo finden Sie unter C:\dsPIC33E PIC24E USB Starter Kit Demo\Documentation\Erste Schritte\Getting Started - Running the Device - CDC - Basic Demo. Siehe den Abschnitt Demo ausführen.
Ich gehe davon aus, dass sich die gesamte erforderliche Dokumentation im Ordner "Dokumentation" befindet. Es sollte Details zu den in der Demoanwendung verwendeten Funktionen enthalten, damit Sie überprüfen können, wie sie funktionieren. Sie können auch einfach den Funktionscode selbst überprüfen.
Ich weiß, dass dies eine uralte Frage ist, aber falls noch jemand vorbeikommt...
Das Problem besteht darin, dass die put*USBUSART()Funktionen nicht blockieren und der USB-Stack daher noch nicht bereit ist, die zweite Zeichenfolge zu übertragen, wenn die erste Funktion beendet wird.
Sie können über die Funktion prüfen, ob es bereit ist oder nicht USBUSARTIsTxTrfReady(). So erstellen Sie einen blockierenden Satz von put[r]sFunktionen:
// 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