Atmega8A UART sendet nur Müll

Hallo,

was ist hier wohl falsch ?

1

while (!( UCSRA & (1<<UDRE))); //<===  //warten bis Senden möglich

2

  {

3

4

  }

Sonst braucht so ein AVR auch einen Takt, den mal als Define F_CPU 
wieder findet.
Wie sieht das in deinem Code aus?

Evtl. passen die Fustbit-Einstellung: Prescaler 1/8 zu deiner Annahme 
nicht.

...und das kommt in Putty an:

"«::"

Lars schrieb:
> ...und das kommt in Putty an:
>
> "«::"

Frage: Wenn man was tut?

5x Ausgabe mit delay von 2 Sekunden:

▒::
                                                                                                                                                                                            ▒::
                                                                                                                                                                                               ▒::
                                                                                                                                                                                                  ▒::
                                                                                                                                                                                                     ▒::



...


Bei Puttybaudrate von 2400 kommt nichts an.
Unter Translation habe ich UTF-8 belassen.

Nun, auf Fragen gehst Du anscheinend nicht ein...

Schade.

Wie sieht die Ausgabe als HEX aus, was ist zu sehen?
Korreliert das dann doch zum Programm, wenn die Baudrate nicht stimmt?

Hier die Ausgabe statt Putty mit hterm in Ascii, Hex, Dec und Bin.
Gesendet wird weiterhin "Hallo".

Und das wäre bei BAUD = 2400.

Ein 10 Sekunden Delay ist schon drinnen.

1

 while (1) 

2

    {

3

    _delay_ms(10000);

4

    uart_puts("Hallo");

5

    }

Auch habe ich hier das Semikolon entfernt:

1

int uart_putc(unsigned char c)

2

{

3

  while (!( UCSRA & (1<<UDRE)))  //warten bis Senden möglich

4

  {

5

6

  }

7

8

  UDR = c;      //sende Zeichen

9

  return 0;

10

}

Lars schrieb:
> //uart.c:
>
> #include <avr/io.h>
> #include "uart.h"
>
> void uart_init(void)
> {
>   UBRRH = UBRR_VAL >> 8;
>   UBRRL = UBRR_VAL & 0xFF;
>
>   // UART TX einschalten
>   UCSRB |= (1 << TXEN);
>   //Frame Format: Asynchron 8N1
>   UCSRC |= (1<<URSEL) | (1<<UCSZ0)|(1<<UCSZ1);
> }
>

Es könnte sein, dass du die Zuweisung an UBRRH und UBRRL noch casten 
müsstest auf uint8.

Z. B. so: UBRRH = (uint8_t)(UBRRVAL >> 8);

Zu den Fusebits:

Dort habe ich High = 0xD9 und Low = 0xED, F_CPU ist mit 8000000UL 
definiert.

Habe statt "Hallo" jetzt "xxxxx" geschrieben. Anbei das Ergebnis. Die 
ersten 4 Zeichen sind gleich, das 5. allerdings nicht mehr.

Ich habe dein Programm mal genommen und auf meinen ATmega8 geschmissen.

Nach Konfiguration der Konstante F_CPU über die Gnu Compiler Symbols 
(mit der Quarzfrequenz 7,3728MHz, die ich habe) kommt ein Hallo sehr 
zuverlässig raus.

Du hast womöglich F_CPU nicht (an der richtigen Stelle?) definiert oder 
die CKDIV-Fuse gesetzt. Der Takt an deiner CPU scheint nicht so zu sein, 
wie du denkst.

Probe: toggle ne LED einmal die Sekunde per delay_ms(1000). Stimmt die 
Taktfrequenz? Dann ist es was anderes bei dir.

Danke Karl,

dann liegt es scheinbar nicht am Code.
Ich habe jetzt mal den internen 1 MHz Takt des AVR verwenwendet. Dieser 
ist unter Symbols mit "F_CPU=1000000UL" definiert. Ferner habe ich die 
Baudrate auf 2400 reduziert.

Im Terminal kommt damit leider auch nur der selbe "Mist" an.

Der Takt an sich scheint zu stimmen, durch das delay kommt alle 10 
Sekunden der Datensatz.

Junge, nimm ein Oszilloskop und schaue ob auf der Uart TX die richtigen 
Zeichen rauskommen und ob der Takt überhaupt korrekt ist. Das ist doch 
ein Rumstochern hier. Wenn du dort 18243 statt 19200 hast, weißt du was 
los ist.

Es gibt heutzutage auch Oszilloskope, die eine UART dekodieren und dir 
in Echtzeit anzeigen, was du überträgst.

Ein Oszilloskop (gibt's unter dem Namen DSO138 ab ca. 30€) oder ein 8 
Channel Logic Analyzer (ab 10€) wäre jetzt nützlich.

Stefanus F. schrieb:
> ... oder ein 8 Channel Logic Analyzer (ab 10€) wäre jetzt nützlich.

Sind die jetzt sooh teuer geworden? :-0
Vor ein paar Tagen waren die noch deutlich unter 6€.

Lars schrieb:
> Anbei das Ergebnis.
das sieht sehr stark nach einem invertieren Signal aus (wirklich schwer 
vorstellbar, da das erste Datenbit dann zum Startbit wird usw.). Evtl. 
ist im FTDI-Treiber Rx auf invertiert eingestellt.
Ansonsten neben dem von Volker vorgeschlagenem 'U' auch 0xF0 und 0x0F 
ausprobieren.

Läuft der mega8 denn wirklich mit dem externen 8 MHz-Quarz?

Der Baudraten-Mist lässt sich leicht erklären, wenn zwar ein
Quarz dranhängt, aber der interne RC-Oszillator benutzt
wird und mit CKSEL3:0 zu F-CPU = 1, 2, 4, (oder 8) MHz
geschaltet ist.

Ohne Oszi hilft es dann nur, einen Hardware-Timer so zu
programmieren, dass er auf einem Port-Pin im Sekundentakt
eine LED aufblitzen lässt.

Der 16-Bit Timer1 mit Vorteiler 1/256 als CTC mit
MAX-Count = 31249 könnte das bewerkstelligen. Das kann man
über ein paar Minuten mit dem Sekundentakt einer Uhr
vergleichen.
Bei echten 8 MHz läuft das synchron!
Taktfehler im Prozentbereich (die RS232 außer Takt bringen)
fallen damit schnell auf.

Jakob schrieb:
> Ohne Oszi hilft es dann nur, einen Hardware-Timer so zu
> programmieren, dass er auf einem Port-Pin im Sekundentakt
> eine LED aufblitzen lässt.

In Zeiten von C auf dem µC, wird man wohl einfacher ein delay() zusammen 
mit dem Blinken einer LED verwenden. Das reicht um einen grob falschen 
Quarz oder Teiler zu identifizieren.
Bei Preisen von unter 6€ für einen elementaren Logikanalysator gibt es 
heutzutage eigentlich keinen vernünftigen Grund, auch nur 1/2h damit zu 
verbringen, über Timing und Polarität von einem UART-Signal rum zu 
rätseln.

Volker S. schrieb:
> Schwer vorstellbar, wie aus einem 'x' 0x78 ein 0xE8 wird.
Da das Messergebnis trotz Hinweis und Dokumentation als "erster Gedanke" 
weiterhin so viele Fragezeichen verursacht ein Versuch mit Zeichen zu 
beschreiben was passiert wenn 'x' bzw. 'xx' 100% taktgenau/100% 
invertiert gesendet (ex)oder empfangen wird:

1

$78:0111.1000           ; 'x'

2

r:  0001.1110            ; lsb first (praktisch rückwärts)

3

f: sooo1 111oE sooo1 111oE ^^^^; 'xx'framed:+(s)tart/(E)ndbit + idle(^)

4

i: ^^^^s ooo1o 111Es ooo1o oooe; invertiert(s=startbit Erkennung)

5

rec:   | 00010 111+| 00010 000-; 'netto' Empfang; Frame:[+|-];0...=brk

6

msb-f    111 01000($E8)-($08[FE])-($00[brk])

(auch 'Hallo' wurde 100% taktrichtig/signalfalsch gemessen)
Mögliche Ursachen:
a) Treiber/Empfänger 'verkehrt' eingestellt
b) Sender u.U. eine Platine auf der Max 2. einen Käfer verzinnt hat 
(quasi ein Rs232-Bug in dem Kontext) oder
c) etwas komplizierte Steckerverpolung (Tx an Vcc/ Gnd an Rx) was aber 
eigentlich nur mit viel Übung passieren dürfte.

Eigentlich gibt es bei solchen eindeutigen Messergebnissen keinen 
vernünftigen Grund wild von zusätzlicher Hardware zu schreiben wenn 
schon das Messergebnis des verwendeten elementaren Logikanalysators 
nicht verstanden wird.

NB.: wenn eh eine serielle Schnittstelle verwendet werden soll,dann 
lässt die sich auch sehr einfach ohne zusätzliche Verkabelungen/LED o.ä. 
durch Senden eines(!) 0x7f zur Taktmessung verwenden: kommen 2 Zeichen 
an, dann einfach auf 8MHz hochskillen ;-)

Danke Dirk und Peter!

Eure Vermutung war richtig. Ich habe mir mal das FTDI_Tool 
runtergeladen. Im Eeprom des Chips sind tatsächlich RX und TX als 
invertiert gesetzt.
Wäre ich nie drauf gekommen, da ich das Kabel kürzlich für eine andere 
Andwendung neu gekauft hatte und dort die Kommunikation (Senden und 
Empfangen) problemlos funktionierte.

Laut Datenblatt
Seite 22 sind TX und RX werksseitig nicht invertiert, bei mir aber 
schon.

Seite 22

https://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232R_CABLES.pdf