-         

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 29

Thema: UART stoppt nach einiger Zeit

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    06.07.2004
    Beiträge
    122

    UART stoppt nach einiger Zeit

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    Ich hoffe ihr könnt mir bei meinem Problem helfen...
    Ich habe ein UART Beispiel nach der Anleitung vom Mikrokontroller.net-Tutorial geschrieben. Senden vom uC zum PC funktioniert ohne Probleme.... aber komischerweise bricht mir die Verbindung beim senden vom PC zum uC nach ca. 5s ab. Ich habe es so geschrieben, dass ich über das Terminal die LED's mit der Taste "a" einschalten kann und mit der Taste "s" wieder ausschalten kann. Funktioniert in den ersten 5 sekunden, danach tut sich jedoch nichts mehr.

    Ich hoffe ihr könnt mir helfen. Anbei das Beispielprogramm mit Interrupts...

    Code:
    #include <io.h>#include <avr/io.h>
    #include <avr/interrupt.h>
    #include <avr/signal.h>
    
    #define F_CPU 4000000       // 4Mhz-Quarz
    #define UART_BAUD_RATE 9600  // 9600 Baud
    
    
    volatile char Daten;
    
    SIGNAL(SIG_UART_RECV)
    {
        Daten = UDR;
    }
    
    
    int main(void)
    {
        UCR  = (1<<TXEN) |(1<<RXEN)|( 1<<RXCIE) ;
    	UBRR= F_CPU/(UART_BAUD_RATE * 16L)-1;
    	outp(0xff,DDRC);
    	sei();
    	while(1)
    	{
            if(Daten=='a')
            {
                Daten = 0;
    			outp(0xFF,PORTC);
            }
            if(Daten == 's')
            {
                Daten = 0;
    			outp(0x00,PORTC);
            }
        }
    
    } [/quote]

  2. #2
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    23.05.2004
    Ort
    Untersöchering(Bayern,Alpenvorland)
    Alter
    30
    Beiträge
    215
    Erstmal wieso deklariest du Daten als volatile, braucht man doch da garnicht.
    Und mach sie zu ner unsigned das sie sonst von -127 - +127 geht und nicht den vollen ASCII Code darstellen kann.
    Und noch was schau mal wieder zu www.mikrocontroller.net
    es hat sich bei C einiges geändert, eigentlich gibt es outp() nicht mehr
    statt dessen DDRC = 0xff;
    Ich glaub nicht das es was aus macht aber erst machst du =='a' also ' ' bedeutet das Zeichen s und dann nur ==0 wobei jetzt hier die Zahl 0 gemeint was glaub ich was anderes ist wie '0', hier ist nämlich glaub ich das Zeichen 0 gemeint.
    Gruß Muraad

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    06.07.2004
    Beiträge
    122

    ...

    Soviel ich weiss, muss man das volatile voransetzen, damit die Variabel auch für die Interrupts gültig ist, oder...?
    Und das mit dem outp() ist eigentlich auch nicht so meine Weise... hab diesen Code nur mal zum testen geladen. Habs auch schon selber geschrieben -- ohne Erfolg.
    Ich glaube kaum, dass es etwas mit dem == zu tun haben kann, da es ja für eine Zeit TipTop funktioniert. Könnte womöglich auch der Quarz oder Port defekt sein? Hatte nämlich auch schon mal das Problem beim LCD, dass es erst nach ca. 5s initialisiert wurde....

    Hätte jemand noch eine Idee?

    Danke

  4. #4
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    17.11.2003
    Ort
    Alfeld (50km südl. Hannover)
    Alter
    34
    Beiträge
    237
    @muraad
    Ich würd sie auch als volatile deklarieren, schließlich wird Daten im Interrupt
    verwendet. Ohne volatile kann es doch sein, dass er sich in der main
    Routine den Inhalt aus dem (veralteten) Register hohlt und nicht neu aus
    dem Speicher ließt?
    Oder steh ich aufm Schlauch?


    if(foo) == 0 vergleicht mit dem Wert 0 also 0x00,
    ff(bar) == '0' vergleicht mit dem ASCII Wert von 0 also 0x48.

    Aber wieso er abstürzt weiß ich auch nicht, am üblichen Verdächtigen,
    dem Watchdog kann es ja eigentlich nicht liegen.
    Open Minds. Open Sources. Open Future

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    06.07.2004
    Beiträge
    122
    Ich werd mir mal einen neuen Controller und Quarz kaufen.... könnte gut sein, dass irgendwo mal was kaputtgegangen ist. Hatte schon andere Probleme.... kostet ja zum Glück nicht die Welt

  6. #6
    Benutzer Stammmitglied
    Registriert seit
    21.12.2004
    Beiträge
    32
    Also die volatile deklaration ist notwendig, wenn man die variable auch ausserhalb des interrupt event handles verwendet. Dann ansonsten wird sie vom complier weg optimiert

  7. #7
    Benutzer Stammmitglied
    Registriert seit
    21.12.2004
    Beiträge
    32
    nimm mal anstelle
    UCR = (1<<TXEN) |(1<<RXEN)|( 1<<RXCIE) ;

    das hier
    UCR = (1<<RXEN)|( 1<<RXCIE) ;

  8. #8
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    06.07.2004
    Beiträge
    122
    Da hat leider auch nichts gebracht.... Habe auch schon den Controller gewechselt -- ohne Erfolg...
    Könnte es was mit dem Overflow vom UART zu tun haben?

    Ach und nur so nebenbei:
    MAX232 sollte auch in Ordnung sein, da ich, wenn ich das Signal auf den PC Rückführe saubere Daten bekomme, keine Fehler, nichts. Also muss es etwas mit dem ATMEL zu tun haben....

  9. #9
    Neuer Benutzer Öfters hier
    Registriert seit
    14.10.2004
    Beiträge
    8
    Du koenntest auch ein Problem mit dem Baudratenfehler haben.
    Bei 9600 Baud und einem 4MHz Takt hast du einen Fehler von 0.2%.
    Stell mal 3.6864MHz ein, oder nimm den entsprechenden Quarz und probier es damit noch mal.

  10. #10
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    06.07.2004
    Beiträge
    122
    Das mit den 9600 Baud und 4MHz passt schon.
    Wie gesagt. Senden an den PC funktioniert einwandfrei und mit einer Toleranz, die ich noch niee bemerkt habe
    Auch sollte das Empfange theoretisch funktionieren, da es in den ersten 5s ohne Probleme läuft....
    Was könnte da noch falsch sein????????

Seite 1 von 3 123 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •