mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATMEGA32A UART Problem


Autor: Hue \a (hue)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wieder muss ich das Forum bemühen, um eine Klärung meines Problems zu 
bekommen. Ich betreibe mein ATMEGA32A mit 1MHz internen Oszillator. 
Leider bekomme ich in Minicom kein Zeichen. Obwohl im regelmässigen 
Abstand auf der TXD Leitung ein kurzzeitiges Signal erscheint. Ich habe 
leider keinen Oszi, um nähere Hardwareuntersuchungen anzustellen. Sieht 
jemand in meinem Quellcode einen Fehler?

MfG

hue \a

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Ich betreibe mein ATMEGA32A mit 1MHz internen Oszillator.

Schlecht. Der interne Oszillator ist für serielle Kommunikation nicht 
sonderlich geeignet. Nimm einen (Baudraten-) Quarz.

>usart_transmit:
...
>reti

Unterprogramme werden mit 'ret' abgeschlossen.

MfG Spess

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Unterprogramme werden mit 'ret' abgeschlossen.

Und mit RETI abgeschossen;)
SCNR

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

am Abschluss einer ISR sollte es nicht liegen, da ich an einer LED PORTA 
Bit0 sehe, dass die ISR funktioniert. Leider bekomme ich das Zeichen 'U' 
nicht in den Rechner. Ich benutze einen USB-Seriell Adapter um die Daten 
zu empfangen.

Hat noch jemand eine Idee?

MfG

hue \a

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Und mit RETI abgeschossen;)

Nicht wirklich. Aber das setzen des I-Flags kann u.U. für Verwirrung 
sorgen.

MfG Spess

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Hat noch jemand eine Idee?

Nochmal: Dein Takt passt nicht.

MfG Spess

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

den Takt habe ich schon einmal auf 16MHz hochgesetzt, und den Code laut 
Atmel- Datenblatt angepasst. Auch die Reduzierung auf 2400 Baud mit 
einem relativen Fehler von 0.2% bringt mir die Lösung nicht.

hue \a

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Auch die Reduzierung auf 2400 Baud mit
>einem relativen Fehler von 0.2% bringt mir die Lösung nicht.

0.2% Fehler hat die Baudrate wenn der Takt 0% Fehler hat.
Wenn der Takt 3% Fehler hat kannst du die 0.2% Fehler
vernachlässigen.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hue schrub:
> den Takt habe ich schon einmal auf 16MHz hochgesetzt

Wie genau hast Du den 'hochgesetzt'? Hoffentlich mit einem externen 
Quarz oder Quarzoszillator nebst passender Fuses. Abgesehen davon steht 
der Rest in [1] und [2].

HTH

[1] http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART
[2] http://www.mikrocontroller.net/articles/AVR_Checkl...

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich komme noch immer nicht weiter, und habe noch folgendes Problem, dass 
die LED am PORTA,0 mit einer Blinkdauer von 4.16sec doppelt so schnell 
blinkt, als im Timer1 eingestellt. Also bei einem Interrupt bei 16MHz 
und Overflow bei 0xFFFF müsste laut Formel die Blinkdauer 8.38sec 
betragen. Das Blinken wird doch nur angesprungen, wenn 8.38sec rum sind?

Wenn meine Betrachtung so richtig sind, dann kann auch mit der Taktung 
des UART nichts stimmen.

Kann mir jemand helfen?

MfG

HUE \a

Autor: Hubert G. (hubertg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir ergibt 16Mhz  1024  65535 = 4,19sec

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hue \a schrieb:

> die LED am PORTA,0 mit einer Blinkdauer von 4.16sec doppelt so schnell
> blinkt, als im Timer1 eingestellt. Also bei einem Interrupt bei 16MHz
> und Overflow bei 0xFFFF müsste laut Formel die Blinkdauer 8.38sec
> betragen.

Du sollst keine Formeln anwenden, die du nicht verstehst. Statt dessen 
sollst du dir klarmachen, wie ein Timer funktioniert, dann brauchst du 
die Formel nicht.

Wenn deiné LED 4.19 Sekunden an ist und dann 4.19 Sekunden aus, dann 
läuft dein Prozessor nicht mit 16 Mhz sondern mit 1Mhz, denn

1000000/64/65536 = 0.238

Kehrwert davon sind 4.19 Sekunden.

Alle 4.19 Sekunden wird daher die ISR angesprungen, in der du die LED 
umschaltest.

Würde dein Prozessor mit 16 Mhz arbeiten, dann würde die ISR alle 0.26 
Sekunden angesprungen und damit die LED umgeschaltet werden.

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"USB-Seriell Adapter"

Ja. Lass des ma bleiben. Die Dinger buggen manchmal. Hatte letztens das 
gleiche Problem. Pc mit serieller Schnittstelle: fehlerfrei. Laptop mit 
Adapter: keine Funktion. Anderer Laptop mit gleichem Adapter und 
gleichen Einstellungen: fehlerfrei.

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe bei meinen Betrachtungen einen Fehler festgestellt, die hier 
wieder zur Verwirrung beigetragen haben. Ich takte richtig mit 16MHz 
nebst passenden Fusebits. Meine Berechnungen sind insofern richtig, da 
sie die Umschaltfrequenz von TOV berechnen, also einmal an und einmal 
aus. Dies ergibt eine Laufzeit von 8.38sec. Also 16MHz/(2*1024*65536) 
und dann invertiert.

Daraus schlussfolgere ich, das mein System korrekt arbeitet.

Nun habe ich aber immer noch das Problem des Datenaustausches per UART.
Ich benutzte einen USB-Seriell-Adapter und bekomme mit den eingestellten 
Datenübertragungsraten und minicom keinen Verkehr zustande.

Hat jemand noch einen Tipp?

MfG

HUE \a

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bla schrieb:
> USB-Seriell Adapter"
>
> Ja. Lass des ma bleiben. Die Dinger buggen manchmal. Hatte letztens das
> gleiche Problem. Pc mit serieller Schnittstelle: fehlerfrei. Laptop mit
> Adapter: keine Funktion. Anderer Laptop mit gleichem Adapter und
> gleichen Einstellungen: fehlerfrei.

sorry wegem Doppelposten

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hue \a schrieb:

> Also 16MHz/(2*1024*65536)

                ****

Sicher?
In deinem zuerst geposteten Programm hast du nämlich einen Vorteiler von 
64 und nicht 1024.
      ldi    r16,(1<<CS10|1<<CS11)
      out    TCCR1B,r16

1024 / 64  ergibt aber wieder einen Faktor 16
Arbeitet dein System mit 1 Mhz, hast du einen Vorteiler von 64 
programmiert und mit 1024 gerechnet, kommen falsche Zeiten raus, die dir 
duch den Fehlerfaktor 16 vorgaukeln, dass dein System mit 16 Mhz 
arbeiten würde.

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe den Vorteiler auf 1024 geändert, da ich sicherstellen wollte, 
dass alle Datenpakete in der Zeit von 4.19sec bei beliebiger Baudrate 
ankommen.

Ich hatte dies vergessen zu dokumentieren.
Ich habe weiterhin das Kommunikationsproblem, habe auch nun einen 
Rechner besorgt, mit richtiger RS232 Schnittstelle, also ohne USB 
Adapter: kein Signal vom AVR.

Wenn mich jemand sucht, ich bin im Badezimmer... auf dem Fussboden ... 
und heule.

MfG

HUE \a

Autor: Michael 93 (michael93) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

also laut Datenblatt ist PD1 der TxD Pin. Müsstest du dann nicht auch 
irgendwann mal in DDRD reinschreiben, dass PD1 ein Ausgang sein soll?

Grüße,
Michael

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>kein Signal vom AVR.

Ist denn da auch ein kleines Mäxchen (MAX232) im Spiel?
Oder AVR direkt an RS232 angeschlossen?

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ja ich habe einen Schnittstellenwandler eingebaut. Es liegen am TxD 
Ausgang auch Pegel an, welche nach 4.19sec (die LED wechselt den 
Zustand) sich ändern und wieder in Ausgangspegel gehen. Der Pegel liegt 
bei -8.8V und wird nach 4.19sec positiv für kurze Zeit, ich habe leider 
keinen Oszi.

Das Setzen des Richtungsregisters auf Ausgang am TxD ist nun 
folgendermaßen:

ldi r16,0x02
out DDRD,r16

Leider ohne Erfolg... bin wieder im Bad...


MfG

HUE \a

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hue \a schrieb:
> Hallo,
>
> ja ich habe einen Schnittstellenwandler eingebaut. Es liegen am TxD
> Ausgang auch Pegel an, welche nach 4.19sec (die LED wechselt den
> Zustand) sich ändern und wieder in Ausgangspegel gehen. Der Pegel liegt
> bei -8.8V und wird nach 4.19sec positiv für kurze Zeit, ich habe leider
> keinen Oszi.

Das sieht eigentlich gut aus.

Was ist mit dem Seriell-Kabel?
Hast du das schon durchgemessen bzw. den Loopback-Test gemacht?

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeigt doch mal den aktuellen Quellcode (vollständig) nebst Fuses(!). 
Falls es an dem nicht liegt kanns immernoch ein Hardwareproblem sein. Da 
man letzteres übers Netz schwer beurteilen kann stollten wir mit 
ersterem beginnen.

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das Kabel ist ein Nullmodem- Kabel und die Ader RxD und TxD sind 
messtechnisch geprüft. Ich kann am Ende ja auch den Wechsel des Pegels 
am Pin 2 messen.

MfG

HUE \a

Autor: Hue \a (hue)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Siehe Quelltext.

MfG

HUE \a

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hue \a schrieb:
> Hallo,
>
> das Kabel ist ein Nullmodem- Kabel und die Ader RxD und TxD sind
> messtechnisch geprüft. Ich kann am Ende ja auch den Wechsel des Pegels
> am Pin 2 messen.

OK.
Dann Loppback Test:
µC aus dem Sockel rausnehmen, TxD mit RxD im Sockel mit einer 
Kabelbrücke verbinden. Am Terminalprogramm auf der Tastatur klimpern. 
Was du klimperst muss angezeigt werden.
Gegentest: Brücke rausnehmen, das Echo muss aufhören.

Wenn das funktioniert, dann ist die Hardware in Ordnung.

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

der Tipp mit dem Loopback Test ist prima, und es hat auch ein lokales 
Echo gegeben, also erfolgreich gelötet und gesteckt.

Aber wie solls nun weitergehen?

MfG

HUE \a

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin es nochmal,

da ich mit Minicom die Verbinung über einen USB Adapter hergestellt 
habe, muss doch dann die Fehler in meinem Programm liegen. Kann jemand 
das unabhängig noch einmal ansehen. Es müsste mit 9600 Baud 8,n,1 
eingestellt sein, sonst hätte Minicom ja gemeckert.

Für Eure zahlreichen Hinweise bin ich schon jetzt recht froh, ich habe 
wieder viel gelernt. Man lernt ja nie aus....


MfG

HUE \a

PS: Hier noch das Makefile mit den Fuses.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hue \a schrieb:
> Hallo,
>
> der Tipp mit dem Loopback Test ist prima, und es hat auch ein lokales
> Echo gegeben, also erfolgreich gelötet und gesteckt.
>
> Aber wie solls nun weitergehen?

Damit kann man dann die Hardware abhaken. An der liegts nicht.
Auch dein USB Adapter ist damit erst mal aus dem Schneider.

Autor: Hue \a (hue)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier das Makefile.

HUE \a

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein kleiner Hardware-Einwurf: RX/TX am µC vertauscht?

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

die Anschlüsse habe ich geprüft, sind korrekt verdrahtet.

MfG

HUE \a

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmals,

es scheinen mehrere Bytes anzukommen, ich habe mit einem 
selbstgeschriebenen Programm auf dem PC immer mehrere Bytes auslesen 
können, obwohl ich im Assembler nur ein 'U' sende. Das 'U' kommt aber 
nicht an. Es kommen nur 0x00 an.

Hat jemand noch einen Tipp?

MfG

HUE \a

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hue \a schrieb:

> Hat jemand noch einen Tipp?

Immer derselbe.
Bei diesen Symptomen ist es zu 99% so, dass der µC mit einer anderen 
Taktrate arbeitet als du denkst.

Ich bin jetzt aber ehrlich gesagt zu faul ein Assembler-Testprogramm zu 
schreiben. In C würdest du eines auf der weiter oben schon verlinkten 
Troubleshooting Seite finden.

> es scheinen mehrere Bytes anzukommen, ich habe mit einem
> selbstgeschriebenen Programm auf dem PC immer mehrere Bytes auslesen
> können

Für die ersten Tests würde ich kein selbstgeschriebenes Programm 
verwenden. Stichwort: Mehrfrontenkrieg. Du weißt dann nie ob das Problem 
beim Sender oder beim Empfänger liegt. Auf PC-Seite würde ich zuerst auf 
eine bewährte, nachweislich funktionierende Lösung wie zb HTerm setzen.

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe in den Troubleshooting einen Hinweis auf das CLKDIV Bit 
gefunden und kann es in den Fuses nicht finden. In welchem Register 
steht das denn?

MfG

HUE \a

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In gar keinem. Ist eine Fuse.
Die gibts aber beim Mega32 nicht.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..mehrere Bytes statt nur einem? Das könnte an einer falschen Baudrate 
liegen. Oder an was anderem :-)

Hack doch mal ein kleines Bruteforcetestprogramm zusammen, etwa so wie 
folgt (in Pseudocode):
main()
{
    char pTemp[11];

    // enable tx
    UCSRB = (1 << TXEN);

    for (uint16_t ubrr = 0; ubrr < 1024; ubrr++)
    {
        UBRRH = ubrr >> 8;
        UBRRL = ubrr & 0xFF;

        sprintf(pTemp, "..%d..\n", ubrr);

        uart_send_string(pTemp);
        _delay_ms(200);
    }

    while (1)
        STATUS_LED_TOGGLE();
}

Dessen Ausführung sollte man abwarten können (gut 200 Sekunden 
Verwartezeit sofern F_CPU halbwegs passt, zzgl. Übertragungszeiten, das 
ist abwartbar), und irgendwann(tm) sollte dann auch was sinnvolles(tm) 
im Terminal ankommen.

Wenn gar nie nicht nix sinnvolles kommt-> Nochwoanderseinbug. Wenn was 
sinnvolles kommt (hier: ein funktionierender Wert für UBRR), dann kann 
man auf F_CPU und co zurückschließen.

Hierzuworkstation sieht der Anfang der Ausgabe übrigens so aus:
�����!�h�I�I�I�I�)��ד���u�ץj���Jխ��J�Zū����W�jVT�%–I��IʖI�..22..�..23..
..24..
..25..
..26..
..27..
..28..
.N29..
^^3`^^
^^sa^^
��cļ����t����DŽ�����T������G�����G�<�#��##|�BŒcc|�B�

..wobei rein rechnerisch die 25 korrekt ist (16MHz, 38400).

Also, viel Spaß!

Autor: Hue \a (hue)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Forumsleser,

dies wird meine letzte Anfrage bezüglich meines Problems sein, ich habe 
das Thema zu lange strapaziert, ich hätte nur noch eine Bitte, mein 
gepostetes Datenfile einmal zu untersuchen.

Ich habe die Daten vom ATmega32 empfangen, welchen ich wie im Quellcode 
beschrieben auf 9600Baud, 8 Bit, keine Parität, ein Stopbit eingestellt 
habe.

Dann habe ich auf meinem Rechner ein Programm geschieben, welches die 
Datenrate von 1 bis fast unendlich laufen lies, und die Ergebnisse des 
Empfangs in die Datei data.dat geschieben habe.

Der Aufbau der Datei ist pro Zeile folgendermaßen:

Baudrate Data: 'empfangene Daten' End

Ich werde aus den empfangenden Daten nicht schlau, es sind verschiedene 
Zeichen, meistens mehrere Bytes.

Bitte helft mir ein letztes Mal, ich weiss mir keinen Rat mehr.

MfG

HUE \a

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hue \a schrieb:
> Ich werde aus den empfangenden Daten nicht schlau,

Im Großen und Ganzen weist Du nach, dass Deine Methode, die Baudrate des 
PC kontinuierlich zu ändern, Essig ist.  Das Ergebnis springt, und zwar 
immer ziemlich genau dann, wenn eine neue Standard-Baudrate erreicht 
ist, z.B. bei 2400 und 4803 Baud,  Warum der Sprung nicht immer bei dem 
exakten Erreichen der Standard-Baudrate ist, bleibt wohl ein Geheimnis 
Deines Programms.

Ein weiteres Geheimnis bleibt, warum Du nicht endlich die Methode 
änderst und einen der gemachten Vorschläge durchführst, sondern 
stattdessen das weiter betreibst, was weiter oben so schön als 
Zweifrontenkrieg bezeichnet wurde.

Ein C-Programm, das in Verbindung mit einem Terminalprogramm die 
Baudrate (und diesmal wirklich kontinuierlich) ändert, wurde bereits 
vorgeführt.  Mach das mal.

(P.S. Wenn Dein Problem im Handling eines C-Programms liegt („wie kriege 
ich das ans Laufen?“: das hättest Du in dieser Zeit längst gelöst.  Oder 
in Assembler geschrieben.)

Autor: Hue \a (hue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hurra,

ein Fehler im Quelltext:
            ldi  r17,LOW(103)
            ldi  r16,HIGH(103)
            out  UBRRH,r16
            out  UBRRL,r17

habe ich ersetzt durch:


            ldi     r17,103
            ldi     r16,0
            out     UBRRH,r16
            out     UBRRL,r17

Jetzt geht es, also kein Fehler in der Taktung vom Chip! Ich bin 
erleichtert,
VIELEN DANK für Eure Hilfen. Wirklich!

MfG

HUE \a

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Also im AVR Studio eigenen AVR Assembler/AVR Assembler2 funktioniert die 
erste Variante definitiv.

MfG Spess

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die zweite Version ergibt:
000018 e617                  ldi                r17,103
000019 e000                  ldi                r16,0
und die erste genau dasselbe:
000018 e617                  ldi                r17,LOW(103)
000019 e000                  ldi                r16,HIGH(103)

Nicht dass ich irgendetwas Anderes erwartet hätte; nur der 
Vollständigkeit halber.

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.