mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmel CDC AppNote - SleepMode? STK525


Autor: Thorben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thorben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thorben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?f...

Ich hab mal einen Zähler mitlaufen lassen, wenn etwas gesendet wird. Der 
landet immer bei 199.

Gruß
Thorben

Autor: Ampfing (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thorben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thorben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..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

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, uart_usb_flush heist die Funktion.
Siehe Appnote Seite 19, Kapitel 8.2.

Autor: Thorben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thorben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thorben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.