-         
Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 28

Thema: USART Komplikationen

  1. #1

    USART Komplikationen

    Anzeige

    Hi zusammen,

    nachdem ich nun nen funktionierenden LCD-Schirm habe *freu*
    Hab ich mich direkt ans nächste Thema gewagt - dem USART... Ich hab vorhin alles fertig zusammengelötet und angeschlossen, basierend auf der Schaltung von http://www.mikrocontroller.net/tutorial/uart.htm

    Als Terminal benutze ich dieses hier: http://bray.velenje.cx/avr/terminal/

    Wenn ich das Programm starte erkennt es automatisch die Baudrate, daher gehe ich mal davon aus, das ich alles richtig zusammengelötet habe, da auch kein Teil heiß wurde und die Elkos noch heile sind
    Natürlich kann das auch nur Zufall sein mit der Baudrate, wenn das Programm zB 9600 als Defaultwert hat...

    Naja, jedenfalls passiert gar nix, weder receive noch transmit funktioniert... Nachdem ich erstmal selber versucht habe, dass zu coden und es nicht ging, hab ich die Lib von www.mc-project.de genommen, aber auch diese scheint nicht zu arbeiten:

    Code:
    #define F_CPU 8000000
    #define USART_BAUD_RATE 9600
    #define USART_BAUD_SELECT (F_CPU/(USART_BAUD_RATE*16l)-1)
    
    void USART_Init(void) {
        //UCSRB = (1<<RXCIE) | (1<<TXCIE) | (1<<RXEN) | (1<<TXEN);
    	UCSRB =  (1<<RXEN) | (1<<TXEN);
        UBRRL = (unsigned char) USART_BAUD_SELECT;
    }
    
    void USART_transmit (unsigned char c) {
    	while (!(UCSRA & (1<<UDRE))) {}
    	UDR = c;
    }
    
    unsigned char USART_receive (void) {
        while(!(UCSRA & (1<<RXC))) {}
        return UDR;
    }
    
    void USART_transmit_string (unsigned char *string) {
        while (!(UCSRA & (1<<UDRE))) {}
    	while ( *string)
    		USART_transmit (*string++);
    }
    
    int main (void)
     {
     USART_Init();
    
     while (1)
      {
       USART_transmit_string("Hello World");
      }
     }
    Ich weiß jetzt nicht, ob ich anstatt F_CPU 8 * 10^6 nicht 1 * 10^6 nehmen müsste, weil ich nen ATmega16 habe und gelesen hab, dass man dort die Oszilatorfrequenz nehmen muss...

    Außerdem kann ich mich noch dunkel an die Zeiten erinnern, als man noch mit seriellen Mäusen gearbeitet hat... Diese mussten doch immer vor dem Hochfahren des Systems angeschloßen sein - Kann das daran liegen?

    Irgendwelche Vorschläge?

    ThxInAdv
    Alex

  2. #2
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Hi, nur ein Tip nebenbei: wenn das terminal ÜBERHAUPT nix zeigt, auch nicht wtlbrnft oder smileys, was bei Baudratenfehler vorkommt, versuch mal, auf der PC <> Boardverbindung RX u. TX (2 u.3) auszukreuzen.
    Je nach Kabel u. Anschluß kann das schon mal verkehrt sein.
    Is nur ein Versuch, denn solche Download-Beispiele funzen meist schon
    mfg robert

  3. #3
    d'oh
    Tatsächlich, ich hab mich gestern verzählt....

    Naja jetzt empfang schon mal was, aber es kommt im Moment nur Müll an...

    Wenn ich für F_CPU 8000000 wähle kommt bei dem oben geposteten Code sowas hier an:
    ð<0><0>€€€<0>€<0>€€<0>€€€€€<0><0>€€€€€€€<0>
    <0>€<0>€€<0><0>€<0><0>€€€<0>€<0>€€<0>€€€€€<0>
    <0>€€€€€€€<0><0>€<0>€€<0><0>
    Mit F_CPU 1000000 sowas:
    ‹K‘µ¶Û Zݲ¶i†Ëݐå+Ñ´¤)Ëݐå+Ñ´¤)Ëݐå+Ñ´¤)Ãݐå+Ñ´¤)Ãݐå+Ñ´
    ¤)Ëݐå+Ñ´¤)Ëݐå+Ñ´¤)Ëݐå+
    (Zeilenumbrüche hab ich der "Übersicht" wegen reingehauen)

    Nun würd ich mal vermuten, das irgendwas mit der Baut-Rate noch nicht so ganz stimmt
    Aber warum?
    Ich hab nen ATmega16 mit 8Mhz... Der interne Oszi ist afaik 1Mhz, aber beide Zahlen arbeiten ja nicht so richtig gut :-/

  4. #4
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Na ja, F_CPU sollt' schon in die Nähe der Realität kommen.
    Wie taktest du deinen Fuzzy nun wirklich ? mit 8 oder intern mit 1 MHz ?
    mfg

  5. #5
    öhm...
    Also ich hab nen Quarz mit 8.000 MHz an die xtals geschloßen.
    Aber ich weiß net, ob ich irgend nen Fusebit ändern muss - bisher war mir das ja an sich auch egal, mit welchem Takt der gearbeitet hat, dass er gearbeitet hat, hat mir gereicht

    edit:
    Hab bissel rumgestöbert und diesen Beitrag gefunden:
    https://www.roboternetz.de/phpBB2/ze...rag.php?t=2576

    Ich hab dann entsprechend die Fusebits umgelegt und jetzt reagiert der Mikrocontroller nicht mehr...

    edit2:
    *stöhn* War ne kalte Lötstelle ^^

    edit3:
    Yeah Baby
    Hello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello

  6. #6
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    05.11.2004
    Ort
    Karlsruhe
    Beiträge
    223
    Natürlich kann das auch nur Zufall sein mit der Baudrate, wenn das Programm zB 9600 als Defaultwert hat...
    9600 ist ein Quasi-Standard und das von dir verwendete Terminal merkt sich die letzte Einstellung. Also nix mit automatisch erkennen Erkennen tut es nur welche seriellen Ports überhaupt verwendbar sind.

  7. #7
    Nun hab ich ein neues Problem - ein sehr seltsames, dass ich mir echt nicht erklären kann...

    Das Ganze fing damit an, dass mein Pony angefangen hat zu streiken und nur etwa 5-6% aller Schreibversuche erfolgreich beendet wurden.
    Daraufhin hab ich geradzu verzweifelt irgendwelche eher schlecht gelöteten Stellen neu gelötet und tausende von Stellen durchgegangen, ob sie gut gelötet sind etc.

    Nun geht das Programmieren meist, jedoch muss ich ab und zu meinen LCD abklemmen - sehr seltsam :-?

    Nun habe ich den oberen Code auf folgenden Code erweitert:
    Code:
    #include "../main.h"
    
    volatile unsigned char data;
    
    void USART_Init(void) {
        UCSRB = (1<<RXCIE) | (1<<RXEN) | (1<<TXEN);
    	//UCSRB =  (1<<RXEN) | (1<<TXEN);
        UBRRL = (unsigned char) USART_BAUD_SELECT;
    }
    
    void USART_transmit (unsigned char c) {
    	while (!(UCSRA & (1<<UDRE))) {}
    	UDR = c;
    }
    
    unsigned char USART_receive (void) {
        while(!(UCSRA & (1<<RXC))) {}
        return UDR;
    }
    
    void USART_transmit_string (unsigned char *string) {
        while (!(UCSRA & (1<<UDRE))) {}
    	while ( *string)
    		USART_transmit (*string++);
    }
    
    SIGNAL (SIG_UART_RECV) {		
    	data = UDR;
    	lcd_write("muh");
    }
    
    int main (void)
     {
     USART_Init();
     lcd_init();
     data = ' ';
     lcd_on(CURSOR + BLINK);
     
     lcd_write("Ready 2 GO");
     lcd_setPos(1,2); lcd_write("3"); lcd_delay(80);
     lcd_setPos(1,2); lcd_write("2"); lcd_delay(80);
     lcd_setPos(1,2); lcd_write("1"); lcd_delay(80);
     
     USART_transmit_string("lets go :)");
     
     lcd_cls();
     
     sei();
    
     while (1)
      {
       if (data == 'c') lcd_cls();
       else if (data != ' ')
        {
         lcd_write(data);
    	 USART_transmit(data);
         data = ' ';
        }
      }
     }
    Alle Vordefinierten Eigenschaften sowie die Funktionen für die LCD werden über die main.h eingebunden.

    Nunja, bewirken sollte der Code folgendes:
    Wenn ich über mein Terminal etwas sende, sollte auf meinem LCD Bildschirm das zeichen angezeigt werden und als zweite Bestätigung nochmal zurück ans Terminal geschickt werden.

    In der Praxis passierte folgendes:
    Das LCD wurde initialisiert, der Countdown läuft ab, dann wurde der Bildschirm schwarz und wurde erneut initalisiert und der Countdown erschien wieder.
    Daher hab ich in die SIGNAL die Ausgabe "muh" reingepackt. Nun wurde kurz bevor das LCD schwarz wird noch muh ausgegeben.
    Danach fing der µC die main-Routine wieder von neu an. Als ob das Ganze nicht seltsam genug wäre, hier noch ne Kuriosität:
    Wenn ich das RS-232 Kabel entferne, ändert sich nix, der µC empfängt trotzdem noch irgendetwas, gibt kurz "muh" aus und resetet.

    Ich hab mir gedacht, das ich vllt irgendwie den Watchdog eingeschaltet haben könnte, jedoch weiß ich gar net, wie man den an kriegt und bezweifel auch, dass das sein kann.

    Naja, zum testen habe ich wieder die alte File mit dem Hello World auf den µC gepackt, aber das Terminal empängt wieder nur Müll, ähnlich wie vorhin, als der Quarz net stimmte...

    *Idee*
    ---------------------------Kurze Schreibpause-----------------

    Nun, ich hab kurz geschaut, und die Fusebits haben sich irgendwie wieder so gesetzt, dass der interne Quarz verwendet wird.
    Irgendwelche logischen Erklärungen dafür?

    Nachdem ich die Fusebits nun umgestellt habe, arbeitet das Dongle wieder net sauber, ich kann nur coden, wenn ich die Platte mit LCD und USART abklemme...

    Naja, nun hab ich das neue Programm wieder getestet, und beim ersten Mal gab der im Terminal "Lets go )))))))))))))))))))))))))))[...]" und auf dem LCD "muh)muh)muh)[...]" aus.

    Danach hab ich mal dies mal das wegkommentiert oder hinzugefügt und jetzt kommt schonwieder nur Müll im Terminal raus: "88ÿ8ð8ðxð8ðxpü
    " Und dementsprechend auch auf dem LCD


    Ich verstehs net...

  8. #8
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Hallo, Kollege, keep cool, don't panic !
    Step by Step, back to the roots = "hello world"
    Wenn das immer noch klappt, kann's ja nicht gleichzeitig falsch sein.
    Also halte dir dieses Programm warm und unverändert und wenn irgendwas spinnt, lade es wieder und schau, ob's noch geht.
    Wenn ja, hat's halt was mit dem aktuellen neuen Programm.
    Wenn nicht, --> alles retour, bis das wieder klappt.
    Wenn du OHNE Lcd und UART einwandfrei mit dem Pony coden kannst, ist da irgendwo dort der Wurm drin. ABER PONY MUSS GEHEN !
    Stell die Geräte mal softwaremäßig einzeln in die Ecke, d.h. entweder NUR UART-Echo testen oder NUR LCD.

    Dein Programm:
    schau mal die Funktiondefinition "lcd-write" nach.
    ist das ? void lcd_write(char* string) oder so ähnlich ?
    wenn ja, und wenn du dann schreibst lcd_write(data) dann isser im Nirwana.

    fürd erste mfg robert

  9. #9
    Zum Programm: Warum killt das den Controller?

    Es is echt verückt, wenn ich LCD und USART am µC angeschloßen habe, dann kann ich ihn einfach nicht coden, das kann doch nicht sein...
    Und das Hello World Programm gibt wieder Unsinn aus

  10. #10
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Ist von deinem PIC/LCD eigentlich ein Schaltplan da ?
    KILLEN: wenn die Funktion lcd_write die Adresse eines strings erwartet, der mit einem \0 endet, und kriegt die Adresse von einem Einzelbyte, fängt er deine Memory zum displayen an, bis er eine Null findet. Das kann dauern und ein sehr langer String sein.
    Noch schlimmer, wenn er "data" by Value kriegt, dann liest er überhaupt irgendwo.
    Wenn's geht, schau dir den generierten Assembler an, vielleicht isser ja auch gescheiter als gedacht.
    PS Wenn einer murkst, ist es eher der LCD. die MAXen sind normalerweise Büffeln, die keine Schwierigkeiten machen. Vielleicht laßt sich der LCD einzeln mal abhängen ?
    mfg robert

Seite 1 von 3 123 LetzteLetzte

Berechtigungen

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