Atmega16 UART empfängt nicht - senden klappt

> Schicke ich über minicom jedoch etwas, tut sich am Ausgang des uC nichts.

Zunächst sollte sich was am Eingang tun. Wenn sich dort nix tut, hat 
der Kleine doch keine Chance! Dann müsstest du minicom überreden, 
jedes eingetipperte Zeichen direkt zu senden und nicht erst beim 
Zeilenende (Return).

Krapao schrieb:
> Zunächst sollte sich was am Eingang tun.

Wie kann ich denn am besten testen, ob sich was am Eingang tut? Ich habe 
leider kein Oszilloskop. Geht das mit einem Digitalmultimeter?

Marco

Multimeter reicht. Baudrate auf PC-Seite so langsam wie möglich (bei 
1200 Baud sollte noch was zu sehen sein, bei 3ßß Baud sieht man sicher 
was) und dann die DC Spannung am Eingang gegen GND messen. Der 
Spannungspegel (Absolutwert mal außen vor) muss bei jedem Zeichen 
schwanken nicht erst nach Drücken des Return.

Dem Loopback (AVR aus der Fassung raus und Drahtbrücke zwischen RXD/TXD) 
sind 1:1 RS232 Kabel (korrekt) und Nullmodemkabel (problematisch) 
gleich.

Der Loopback testet nicht die korrekte Zuordnung der TXD/RXD Leitungen 
an die entsprechenden Pins des AVR. Die richtige Zuordnung findest du 
aber mit dem Multimeter raus.

Beim fertigen Pollingboard kann eine falsche Zurodnung praktisch fast 
nur durch Verwendung eines Nullmodemkabels entstehen. Bei 
Eigenbauschaltungen ist es schon einfacher möglich falsch zu verdrahten.

Die zu erwartenden TTL Pegel an RXD Pin des AVR kannst du im Artikel 
RS232 nachlesen.

Bei jedem Tastendruck schwankt die Spannung zwischen RXD (Pin14) und GND 
um ca. 1-2 mV. Ist das zu wenig?

Marco

Ja, zu wenig. 1-2 mV (bei korrekter Bedienung des Multimeters: DC 
Messung Messbereich 10V oder 20V je nach Typ) sind Grundrauschen.

Da müsste bei korrekter Beschaltung ein Schwanken von HIGH (Ruhepegel um 
5V) auf LOW (um 0 V) zu sehen sein.

Zupf den AVR raus und mach Spannungsmessungen an der IC Fassung bei 
spannungsversorgtem Pollinboard. Am RXD IC-Pin muss ein HIGH Pegel zu 
messen sein und am TXD IC-Pin ein LOW Pegel.

Wenn es umgekehrt ist, kontrolliere mit dem Durchgangstester deines 
Multimeters dein RS232-Kabel, ob es 1:1 verschaltet ist (korrekt) oder 
TX/RX gekreuzt sind (falsches Kabel, Nullmodem).

Ich habe gerade das Kabel durchgepiepst. Es hat keine gekreuzten 
Leitungen, ist also ein Modemkabel, also kein Fehler.

Leider habe ich auch keinen anderen Atmega16, um ihn als Fehlerquelle 
auszuschließen. Ich probiere es morgen mal mit einem Atmega8.

Danke für die Hilfe

Ok, ich habe das ganze nochmal ohne uC nur an den Pins gemessen - Ohne 
Tastendruck liegen 5V an, bei Tastendruck bricht die Spannung auf 2,5V 
bis 3V ein. Denke, das ist OK.

Ich kenne das Problem mit dem Pollin-Board. Die onboard serielle 
Schnittelle nutze ich allerdings nie. Hast Du JP1 und JP2 gesetzt (siehe 
Datenblatt)? Falls Das nicht funktioniert: Hast Du einen FTDI-Adapter? 
Falls ja, dann kannst Du direkt PD0, PD1 (Atmega16) und GND mit einem 
dünnen Draht verbinden. Das funktioniert in jedem Fall.

Ja, JP1 und JP2 habe ich gesetzt. Ich habe alles durchgepiept und die 
Pinbelegungen gecheckt. Gerade nochmal einen Backloop-Check gemacht. 
Funktioniert alles. Einen USB-Adapter für serielle Schnittstelle habe 
ich auch. Werde ich morgen auch testen, nachdem ich den Atmega8 getestet 
habe.

Danke!

> Ok, ich habe das ganze nochmal ohne uC nur an den Pins gemessen - Ohne
> Tastendruck liegen 5V an, bei Tastendruck bricht die Spannung auf 2,5V
> bis 3V ein. Denke, das ist OK.

Vermutlich OK.

Das Bitgeklapper eines Zeichens wird über die Zeit der Übertragung einen 
Mix aus HIGH und LOW erzeugen und du wirst im Mittel "2,5V bis 3V" 
messen.

Wie war die Spannung bei eingestecktem AVR und den 1-2 mV?
MOMENT da kommt mir ein Verdacht...

> int main(void)
> {
>   uart_init();
>
>   DDRD = 0xFF; // PORTC Ausgang
>   USART_Transmit('h');

Hör' mal auf, bei der DDRD Zuweisung nach der UART-Initialisierung und 
bei der Ausgabe von c an dem RXD (PD0 = Pin14 beim Atmega16) zu 
fummeln :-)

Es wäre wesentlich geschickter, wenn du c nicht auf PORTD schickst, 
sondern z.B. auf PORTC wie im Kommentar angedeutet (dann aber die JTAGEN 
Fuse disablen).

Alternativ maskiere bei den DDRD und PORTD Zugriffen die PD0 und PD1 
Pins aus (Bitmanipulation).

Hallo :) ich habe den gleichen Code auf einen Atmega8 auf demselben 
Board geladen und dort läuft er. Vermutlich funktioniert der UART vom 
Atmega16 tatsächlich nicht mehr vollständig.

Vielen Dank für Eure Hilfe :)

Hey Krapao... Du hattest recht :D Ich habe damit ja den gesamten Port 
als Ausgang definiert... dann funktioniert natürlich der UART nicht mehr 
:(

Jetzt klappts auch mit dem Atmega16 :D

Danke danke danke

Hi

>Hey Krapao... Du hattest recht :D Ich habe damit ja den gesamten Port
>als Ausgang definiert... dann funktioniert natürlich der UART nicht mehr
>:(

Stimmt nicht. Datenblatt (Alternate Port Functions):

RXD, Receive Data (Data input pin for the USART). When the USART 
Receiver is enabled this pin is configured as an input regardless of the 
value of DDD0.

Und TXD wird auch automatisch zum Ausgang wenn TXE gesetzt wird. Du 
brauchst dich also nicht um die Datenrichtung von TXD/RXD kümmern.

MfG Spess

Spess53 hat recht. Die Definition am Ausgang hat nichts mit der Sache zu 
tun. Es war vielmehr das Flachbandkabel, welches ich in das Pollinboard 
gesteckt hatte, um es mit dem Addon-Board zu verbinden. Selbst wenn nur 
das Flachbandkabel mit offenem Ende eingesteckt ist, funktioniert die 
Übertragung mit UART nicht mehr. ich werde nun das Flachbandkabel 
testen.

Habe den Fehler gefunden. Genau wie hier:

Beitrag "Re: Pollin Evaluationsboard mit Add-On Board RS232 Fehler"

ziemlich ärgerlich, aber jetzt gehts ja :)