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?
hier der Link, wo es eine pdf dazu gibt. Ab S.16 wird das Prog
beschrieben, ich werd da aber nicht schlau draus.
("AVR272: USB CDC Demonstration UART to USB Bridge")
http://www.atmel.com/dyn/products/tools_card.asp?family_id=607&family_name=AVR+8%2DBit+RISC+&tool_id=3878
Ich hab mal einen Zähler mitlaufen lassen, wenn etwas gesendet wird. Der
landet immer bei 199.
Gruß
Thorben
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
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!? Thorben
..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.
Ah, uart_usb_flush heist die Funktion. Siehe Appnote Seite 19, Kapitel 8.2.
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
Kannst du probieren, glaube aber nicht das es das ist. Hast du mal einen USB Monitor benutzt um zusehen was auf dem Bus los ist?
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.