Zeichen fehlerhaft über RS232 an/von ATmega16

Tom wrote:
> Hallo Spezialisten,

> Nun habe ich das Problem, dass bei vielen Tasten nicht das aufgedruckte
> Zeichen gesendet/empfangen wird, sondern willkürliche. Jedoch
> reproduzierbar immer das gleiche. Weiter tritt der Fehler auf, dass ca.
> jeder zehnter Tastendruck nicht das gewünschte Zeichen liefert. Z. B.:
> aaaaaaaaajaaaaaaa.
>
> Habe ich einen grundsätzlichen Denkfehler im System bzgl. ASCII-Code o.

Welcher Takt?
Welche Baudrate?
Welche einstellungen in Hyperterm?
Welcher Code?

so viele Fragen...

Grüße
Björn

Tom wrote:
>>>Welcher Code?
> Hier war nur meine Frage, ob ich evtl. den ASCII-Code o. ä. falsch
> interpretiert habe.
Woher sollen wir das bitteschön wissen, ohne Deinen *PROGRAMM*-Code?

Tom wrote:
>>>Welcher Code?
> Hier war nur meine Frage, ob ich evtl. den ASCII-Code o. ä. falsch
> interpretiert habe.

Kann keiner wissen, du zeigst ja keinen Code.

Aber: Wie ist das zu interpretieren:
dass bei vielen Tasten nicht das aufgedruckte
Zeichen gesendet/empfangen wird

Heist das du legst den Finger auf die Taste und lässt ihn dort.
D.h. die Zeichen werden in schneller Folge gesendet.
Oder drückst du jedesmal die Taste erneut?

Erhöhe mal die Anzahl der Stoppbits auf 2. Dadurch verschaffst
du der jeweiligen Gegenstelle etwas mehr Zeit ein Zeichen zu
verarbeiten.

Tom wrote:
> Sorry hatte ich vergessen anzufügen:
>
> Initialisierung von USART stimmt. Das hab ich natürlich
> (achthunderdsiebzigmal) überprüft.
>
>>>Welcher Code?
> Hier war nur meine Frage, ob ich evtl. den ASCII-Code o. ä. falsch
> interpretiert habe.

Wenn Du genau das wieder zurückschickst was reinkommt dann gibt es da 
nichts zu interpretieren.

Ich tippe mal auf ungünstigen Takt in verbindung mit der Baudrate..

Grüße
Björn

Michael Wilhelm wrote:
> Der interne Oszillator ist sehr Temperatur- und
> Betriebsspannungsabhängig. Externer Baudratenquarz wird dein Problem
> lösen.
>
> MW

Mein reden...

mit Baudrate 4800 könnte es eventuell gerade so gehen...

Wenn der RxC-Interrupt auftritt, dann wurde bereits ein Zeichen 
empfangen! Der Aufruf der Funktion getche in der ISR ist völliger Murks. 
Bitte schau Dir im AVR-GCC-Tutorial die entsprechenden Abschnitte 
an. Da steht wie's geht.

> typedef unsigned int uint16;
> typedef signed int sint16;
> typedef unsigned short uint8;
> typedef signed short sint8;
In der Headerdatei stdint.h sind bereits Typen mit Längenangabe 
definiert. Warum muss da jeder seinen eigenen Mist definieren?

Björn Wieck wrote:
> Mein reden...
>
> mit Baudrate 4800 könnte es eventuell gerade so gehen...
Der Fehler ist relativ und tritt, wenn vorhanden, dann bei jeder 
Baudrate auf, die sich mit gleichem Grundfehler einstellen lässt. Und 
bei 4 MHz CPU-Takt ist es wurscht, ob man 9600 oder 4800 Baud nimmt, 
haben beide 0,2%...

Tom wrote:
> Das sollt natürlich keine Provokation darstellen. Dies wurde mir
> empfohlen, um das Programm für andere Compiler lesbar zu machen....
Hab ja auch nicht von einer Provokation geredet. Und die stdint.h ist 
Bestandteil von C und kann deshalb auch von jedem C-Compiler verarbeitet 
werden.

Der springende Punkt ist:
Das sind deine Erfahrungen.
Andere haben andere Erfahrungen.
Hängt auch davon ab, welchen AVR du konkret benutzt. Unterschiedlich
AVR haben unterschiedliche RC-Oszillatoren implementiert, die
unterschiedliche Temperaturabhängigkeiten haben.

interner Oszi + UART kann funktionieren, muss aber nicht.

Vorausetzung für den internen Oszillator ist zunächst, dass man den 
Kalibrierungswert verwendet. Die AVRs haben dafür eine etwas 
eigenwillige Methode, denn der Oszillator ist von Haus aus unkalibriert 
und es muss ein auf dem Umweg über den Programmer aus einem speziellen 
dem Controller selbst nicht zugänglichen Bereich entnommener 
Kalibrierwert in OSCAL reingeschrieben werden. Ein Zirkus, der bei 
anderen µC-Familien mit leidlich genauem internem Oszillator nicht 
erforderlich ist.

Die Chancen auf leidlich verwendbare UART stehen dann bedeutend besser.

Aber trotzdem sollte man das dann allenfalls für Testzwecke so machen, 
beispielsweise bei einem Debug-Ausgang. Nicht für produktiv verwendet 
Schnittstellen.

Karl heinz Buchegger wrote:
>
> interner Oszi + UART kann funktionieren, muss aber nicht.

So wie bei mir. 2 MHz interner OSC:
9600 und drüber geht nicht, kommt nur Müll.
4800 und drunter geht.

Für ein paar Debuginformationen ist das noch zu verkraften aber eine
ernsthafte Kommunikation würde ich mit dem internen RC nicht machen 
wollen.

Grüße
Björn

Björn Wieck wrote:
> So wie bei mir. 2 MHz interner OSC:
> 9600 und drüber geht nicht, kommt nur Müll.
> 4800 und drunter geht.
Wundert mich, dass die 9600 auch schon nicht laufen, wenn 2400 und 4800 
gehen (sind schließlich alle mit 0,2% Grundabweichung machbar)... Dass 
die Raten über 9600 Bd allesamt mit 2 MHz nicht gehen, kann man 
allerdings dem Datenblatt entnehmen.

Johannes M. wrote:
> Wundert mich, dass die 9600 auch schon nicht laufen, wenn 2400 und 4800
> gehen (sind schließlich alle mit 0,2% Grundabweichung machbar)... Dass
> die Raten über 9600 Bd allesamt mit 2 MHz nicht gehen, kann man
> allerdings dem Datenblatt entnehmen.

Ist auch nur eine Erfahrung die ich mal gemacht habe.
Vielleicht ist ja auch der PC der daranhängt besonders gutmütig oder so.

Die Übertragung mit 4800 ist ja auch nicht immer fehlerfrei gewesen aber 
für Debug hats gelangt.

Die meisten meiner µC Anwendungen sind eh zeitunkritisch so das ich oft 
den internen RC nehme.

Aber wie ich schon sagte: RC Oszillator und UART ist Pfui wenns 
zuverlässig sein soll.

Grüße
Björn