Hallo,
ich benutze das STK525 Starter-Kit und habe mir das CDC-Beispiel von
Atmel auf meine Anwendung angepasst. Dabei wird ein virt. COMPort
erstellt von dem ich Daten empfangen kann. Die Daten kommen vom
AD-Wandler, das Problem ist, dass der Controller nach einer gewissen
Zeit in einen Sleep-Modus(wenn es das ist) geht, das passiert aber nur
wenn ich keine Daten am PC empfange, also dass Prog zum Daten holen
nicht gestartet hab.
Der Controller sendet eine Zeit lang und steht dann still, er läuft erst
wieder, wenn ich einen Reset mache, oder das Programm auf dem PC starte.
Ich habe nichts dazu in der .pdf zur AppNote gefunden. Aber im DB zum
AT90USB steht, dass man ihn in den einen sleep-Modus setzen kann, so
dass der AD-Wandler nicht gestört wird.
Ich habe neben dem AD-Wandler nämlich noch andere Funktionen
implementiert, aber die laufen dann nat. auch nicht.
Kann mir jemand helfen? Den ganzen Quelltext zu posten wäre recht viel,
aber viell. weiß jemand an welcher Stelle ich suchen muss!
Gruß
Thorben
Keine eine Ahnung?
Die vorinitialisierten Funktionen hab ich jetzt gefunden, sie werden
aber nicht aufgerufen, d.h. dass es wohl kein Sleep-Modus ist. Was gibt
es denn sonst noch für Möglichkeiten den Prozessor lahm zu legen? Gibt
es sowas wie einen StandBy?
Thorben
Hört sich danach an das möglicherweise dein TX Buffer nach einiger
Zeitvoll ist weil die Daten nicht abgeholt werden.
Ich kenne die Appnote nicht, aber kann es eine Art acknownledge oder
request benötigt wird um den Bufferinhalt zu holen bzw. zu bestätigen?
Hi Thorben,
meine Vermutung geht auch in Richtung von Michael.
Bei USB ist es so, dass ein Gerät (in dem Fall das STK) nicht einfach
Daten senden kann. Es muss warten, bis es vom Host (also dem PC) dazu
aufgefordert wird.
Wenn jetzt Deine Applikation nicht läuft wird der PC wohl auch keine
Daten vom STK anfordern. Deswegen füllt das seine Buffer bis sie voll
sind und wartet dann darauf, dass der PC endlich mal Daten anfordert.
Dies tut er in dem Moment, wo Du die Applikation startest, deswegen
'läuft' der µC dann auch weiter.
So könnte ich mir das Verhalten zumindest erklären.
Viele Grüße
..oder ist dann der Puffer im Host voll, und dieser sendet keinen
request? an den Controller. Geschieht das dann beim Enumerationsprozess,
oder an anderer Stelle?
Thorben
>Dann müsst ich im Quelltext doch was finden, wo der Buffer geprüft wird,>und den könnt ich ja dann löschen wenn er voll ist!?
Hab gestern nur mal schnell in die Sourcen geschaut.
Es gibt eine Funktion usb_uart_flush, diese dient wohl dazu den Inhalt
des TX Buffers zu senden.
Wird diese nicht explicite aufgerufen wird der Buffer solange gefüllt
bis er voll ist un erst dann gesendet.
Kontrollier nochmal deinen Code, ob die Senderoutine auch richtig ist.
if(cpt_sof>=NB_MS_BEFORE_FLUSH && tx_counter!=0 ) {
cpt_sof=0;
uart_usb_flush();
}
das ist das einzige mal, dass uart_usb_flush() aufgerufen wird
cpt_sof wird jede ms um 1 inkrementiert und NB_MS.. ist als 50
definiert,
aber tx_counter verwirrt:
-wird mit 0 initialisiert, aber nicht erhöht (bzw. nur in einer
Fkt., die nicht aufgerufen wird), also ist die Bed. nie erfüllt
-zur Ausgabe wird printf() verwendet
(fdevopen(uart_usb_putchar,uart_usb_getchar));
das wird doch dann in den Puffer geschrieben(der nie gesendet wird?),
oder?
Thorben
Hmm weis ja nicht wo du guckst, aber tx_counter wird in der Funktion
uart_usb_putchar erhöht, und in uart_usb_flush zurückgesetzt.
Das ganze findest du in der Datei uart_usb_lib.c
>tx_counter wird in der Funktion uart_usb_putchar erhöht
die Funktion wird bei mir nicht direkt aufgerufen, sondern mit fdevopen
für printf. sry hab nicht genau hingeschaut
int uart_usb_putchar(int data_to_send)
{
Usb_select_endpoint(TX_EP);
while(!uart_usb_tx_ready()); // Wait Endpoint ready
Usb_write_byte(data_to_send);
tx_counter++;
if(!Is_usb_write_enabled()) //If Endpoint full -> flush
{
uart_usb_flush();
}
return data_to_send;
}
Kann es sein, dass der uC dann in der Schleife festhängt? Könnte ich die
einfach rausnehmen?
Thorben
Hi,
habe die Schleife jetzt rausgenommen, und es scheint zu funktionieren,
nur glaube ich, dass es bei Ausbau der USB-Kommunikation Probleme geben
könnte, da dass RWAL - Read/Write Allowed Flag aus UEINTX abgefragt
wird, welches einen overflow verhindern soll, oder gilt das nur wenn ich
Daten von der CPU zum Controller schicke?
Einen USB-Monitor habe ich mir auch runtergeladen und mir die raw
packets angeschaut, nur wüsste ich nicht wo ich genau nach suchen sollte
bzw. wo ich den request finde..
Gruß
Thorben
