ATmega16 UART sendet keine Daten

[Bibub (Gast)]

Hallo liebes Forum,
ich versuche gerade eine Verbindung zwischen meinem ATmega16 und meinem 
PC aufzubauen. Das Problem ist, dass mein µC keine Daten an meinen PC 
sendet. HTERM zeigt nichts an. Der µC läuft mit einem 14.7456 MHz 
Quartz. In AVR Studio hab ich EXTHIFXTALRES_16KCK_64MS eingestellt. Die 
Werte für UBRR habe ich dem Datenblatt entnommen. Hat jemand eine Ahnung 
warum der Code nicht funktioniert?

int main(void)
{
  UBRRH = 0;
  UBRRL = 95;
  UCSRB = (1<<RXEN) | (1<<TXEN); //Schreiben und lesen aktivieren
  UCSRC = (1<<URSEL) | (1<<UCSZ1) | (1<<UCSZ0); //8 bit Übertragung
  
    while (1) 
    {
    while (!(UCSRA & (1<<UDRE)));
    UDR = 'd';
    }
  return 0;
}

Grüße
Bibub

[spess53 (Gast)]

Hi

DD-Register gesetzt?

MfG Spess

[Bibub (Gast)]

Muss ich PD1 als Output setzen?

[spess53 (Gast)]

Hi

>Muss ich PD1 als Output setzen?

Stop zurück. Beim Setzen von TXEN und RXEN übernimmt die UART die 
Kontrolle über die Pins.

MfG Spess

[Bibub (Gast)]

Okay sonst noch irgend eine Idee woran es liegen kann. Ich mein 
eigentlich sollte das doch nicht so schwer sein

[Walter S. (avatar)]

die richtigen Pins verbunden?
Ansonsten das Signal mal mit dem Oszi anschauen, die übliche Fehlersuche 
halt
Ach ja: dazwischen ist doch noch ein Wandler??

[Bibub (Gast)]

Zwischen dem ATmega und dem PC hängt ein FDI232 Board. Die Kabel sind 
auch richtig gekreuzt

[Rainer B. (katastrophenheinz)]

Was passiert, wenn du ein 'd' direkt wieder zurück an den Rx-Pin vom 
mega sendest?

bzw. am FDTI Rx und Tx brückst? Wird das zeichen in hterm anezeigt?

[Bibub (Gast)]

Wenn ich RXD und TXD beim FTDI brücke empfängt er immer direkt das 
zeichen, das ich gesendet habe. Beim AVR habe ich auch mal RXD und TXD 
gebrückt und das Ergebnis aus dem Empfangsschritt auf einen PORT legen 
lassen. Das Programm kommt anscheinend gar nicht zu Empfangen bzw. er 
erkennt nicht, dass etwas gesendet wurde

[Bibub (Gast)]

Ich habe das Signal mal mit dem Oszi angeschaut. Man sieht nichts sprich 
der ATmega sendet einfach gar nichts. TXD bleibt auf 0V

[Rainer B. (katastrophenheinz)]

Hmm,

hilft dir jetzt nicht weiter, aber:
Dein Programm mit Copy/Paste kopiert, lediglich UBRRL angepasst, rennt 
bei mir auf einem mega32 so wie gewollt.

Hast du mal getestet, ob dein Prozessor überhaupt losrennt? Dh. mal eine 
LED blinken lassen oder irgendein Portbit klappern lassen und mit Oszi 
angeguckt?

[horst (Gast)]

Genau lass mal ne LED mit 1 HZ blinken. Dann siehste ob der überhaupt 
läuft und ob der Takt einigermaßen stimmt.

[M. K. (sylaina)]

Der Code oben ist auf jeden Fall in Ordnung, es muss an was anderem 
liegen. Wie ja schon gesagt wurde: Wenn der TX Pin nix macht dann ist 
der Atmega wahrscheinlich erst gar nicht angelaufen. Fuses für den 
Oszilator sind richtig gesetzt? Vor allem auch geschrieben und nicht nur 
im Studio eingestellt? So ein ähnliches Problem hatte letzt ein Freund, 
der hat sich quasi tot gesucht. Er hatte schlicht "vergessen" die Fuses 
auch zu schreiben.

[Konrad S. (maybee)]

Bibub schrieb:
> TXD bleibt auf 0V

Das ist als Ruhepotenzial falsch! Such mal nach Kurzschluss.

[M. K. (sylaina)]

Konrad S. schrieb:
> Bibub schrieb:
>> TXD bleibt auf 0V
>
> Das ist als Ruhepotenzial falsch! Such mal nach Kurzschluss.

Richtig aber das könnte auch darauf hindeuten, dass der Atmega nicht 
anläuft. 0V ist nämlich als Initialisierungspotential korrekt ;)

[Felix A. (madifaxle)]

Ich habe dein Beispiel auf einen ATmega32L gepackt. Der hat einen 
externen 7,3728 MHz Quarz, womit sich dann genau UBRRL = 95 für 4800 
Baud ergibt.

Ergebnis: läuft ohne Abänderung. Überlastet aber wie immer Windows und 
den Eigangspuffer. Das Terminal hängt sich auf (bei 4800 Baud!).

Also sind zwei Zeilen zum Drosseln hinzu gekommen.

[c]
#include <avr/io.h>

int main(void)
{
  uint16_t  i;

  UBRRH = 0;
  UBRRL = 95;
  UCSRB = (1<<RXEN) | (1<<TXEN); //Schreiben und lesen aktivieren
  UCSRC = (1<<URSEL) | (1<<UCSZ1) | (1<<UCSZ0); //8 bit Übertragung

    while (1)
    {
    while (!(UCSRA & (1<<UDRE)));
    UDR = 'd';

    i = 0;
    while (i < 50000) { i++; }

    }
  return 0;
}

[c-hater (Gast)]

Felix A. schrieb:

> Ergebnis: läuft ohne Abänderung. Überlastet aber wie immer Windows und
> den Eigangspuffer. Das Terminal hängt sich auf (bei 4800 Baud!).

Also an Windows liegt das garantiert nicht.

Mit 115200 ist jedenfalls völlig problemlos Vollduplex-Kommunikation mit 
(nahezu) konstanter theoretischer Maximal-Nettorate möglich. Man muß 
halt bloß die Sende- und Empfangspuffer groß genug machen, daß auch eine 
20ms-Auszeit des Sende- und/oder Empfangsthreads nicht gleich die 
Datenströme abreißen läßt.

Und früher(tm), als ich noch eine entsprechende UART in meinem Rechner 
hatte, ging das auch mit 921600. Auch unter Windows. Und damals waren 
die CPUs weitaus langsamer...

Fazit: Man muß einfach bloß richtig programmieren können und sein OS 
beherrschen, dann klappt das schon.

[Bibub (Gast)]

Ich hab jetzt mal ein Blinklicht gebaut und die Fuses neu geschrieben.
Die LED flakert ohne Probleme. Das Programm wird also auch richtig 
übertragen und ausgeführt

[M. K. (sylaina)]

Dann doch Hardware-Fehler? Hast du auch keinen Kurzschluss wo er nicht 
hin gehört?

[hihihi (Gast)]

Michael K. schrieb:
> Hast du auch keinen Kurzschluss wo er nicht
> hin gehört?

Oder anders: Hast du alle Kurzschlüsse da wo sie hingehören?

[Bibub (Gast)]

Okay ich habs endlich hin gebracht etwas zu senden. Der Grund war, dass 
der Anschluss des ISPs nicht nach Standard sonder willkürlich belegt 
war. Alles war gleich, außer das PD1 auch noch außen auf GND geführt 
wurde. Ich kann jetzt Daten senden aber es kommt nur unfung an. Anstallt 
0x04 bekomme ich z.B. 0xDF

[Frank (Gast)]

Bibub schrieb:
> aber es kommt nur unfung an. Anstallt 0x04 bekomme ich z.B. 0xDF

Typische Fehler an dieser Stelle:
Falscher Takt eingestellt (falscher wert oder falsche Quelle)
Div8 Fuse gesetzt.
Baudrate falsch gesetzt...

[M. K. (sylaina)]

Bibub schrieb:
> Ich kann jetzt Daten senden aber es kommt nur unfung an. Anstallt
> 0x04 bekomme ich z.B. 0xDF

Baudrate und/oder Übertragungsart (6, 7, 8, 9 bit Mode, 1/2 Stoppbits 
usw.) falsch eingestellt.

[Konrad S. (maybee)]

Michael K. schrieb:
> Baudrate und/oder Übertragungsart (6, 7, 8, 9 bit Mode, 1/2 Stoppbits
> usw.) falsch eingestellt.

Die Stoppbits sind unschuldig, beim Empfangen reicht unabhängig von der 
Einstellung ein Stoppbit.

[Bibub (Gast)]

Also ein DIV8 Fuse gibts bei mir gar nicht. Die Werte für UBRR hab ich 
ja aus dem Datasheet entnommen. Der UART ist auch auf 8 Bit eingestellt

[Bibub (Gast)]

Ich hab das Problem gefunden. Testweise hab ich einfach mal alles mit 
nem MAX232 und einer echten RS232 Schnittstelle an einem alten PC 
getestet. Alles hat perfekt geklappt. Ich vermute, dass der FTDI 
irgendwie schrott ist

[M. K. (sylaina)]

Bibub schrieb:
> Ich hab das Problem gefunden. Testweise hab ich einfach mal alles mit
> nem MAX232 und einer echten RS232 Schnittstelle an einem alten PC
> getestet. Alles hat perfekt geklappt. Ich vermute, dass der FTDI
> irgendwie schrott ist

Hm, da hätten wir lange raten können.

[Frank (Gast)]

Bibub schrieb:
> Also ein DIV8 Fuse gibts bei mir gar nicht.

CLKDIV meinte ich, habe schon lange nichts mehr mit AVRs gemacht ;-)

[Bibub (Gast)]

Ja war echt ein blöder Fehler. Vielen Dank für die Klasse Unterstützung