MAX232 an ATmega32 - seltsames Verhalten

Hallo,

um einem Atmel ATmega32 (AVR) das Sprechen mit dem Computer zu vereinfachen habe ich einen MAX232 an die Pins RXD und TXD meines AVR geh=E4ngt.

Der Versand von Nachrichten zum PC klappt hervorragend, es sind nichtmal Einbr=FCche in der Spannungsversorgung sichtbar, aber beim Empfang passiert auf den Leitungen etwas eigenartiges:

Der Pegel bricht auf TTL-Seite mit jedem Zeichen von +5V Ruhepegel nur kurz auf ca. +4.9V ein. Schalte ich einen zweiten Transceiver dazu, bekomme ich +4.8V - das ist zwar richtiger, aber noch nicht ganz in Ordnung :-)

Erst wenn ich den Microcontroller abklemme (oder mittels Jumper im Reset halte) bekomme ich saubere Pegel von +5V und 0V - hat der AVR also einen gigantischen Pull-Up auf 5V aktiv, zu gro=DF f=FCr den MAX232?

Die Beschaltung des MAX232 ist (f=FCr ein Null-Modem-Kabel) wie folgt:

AVR MAX232 RS232 RXD -- 9 8 -- TX TXD -- 10 7 -- RX GND -- 15 15 -- GND

zus=E4tzlich gibt's noch die obligatorischen +5V an Bein 16 des MAX232 und jeweils einen 1uF-Kondensator an den Beinchen 1->3, 2->GND, 4->5 und GND->6.

Die Initialisierung des USARTS passiert mit folgendem Code-Schnipsel:

UCSRB |=3D (1

Reply to
Wolfgang Meier
Loading thread data ...

Wolfgang Meier schrieb:

Hallo ,

gibts evt. einen Kurzen zum Nachbarpin? (welches Gehäuse?)

Bei Nennung der Quarzfrequenz gibts ein kompiliertes Zweizeilerlein, um Hardwarefehler auszuschließen per Mail.

Jan Conrads

Reply to
Jan Conrads

Jan Conrads schrieb:

DIL. An einen Kurzschluss glaube ich aber eher nicht - zwinge ich die Pins per gehaltenem Reset in den Tristate, dann sind die Pegel ja genau wie erwartet.

Quarz l=E4uft mit 8.00 MHz.

Wenn's wirklich nur ein Zweizeiler ist, poste doch bitte zus=E4tzlich den Assemblercode hier hinein, dann m=FCssen sich zuk=FCnftige Antwortsuchende nicht erst per Mail an dich wenden ;-)

Danke schonmal,

Wolf

Reply to
Wolfgang Meier

Da arbeitet wohl Augang gegen Ausgang...

Geht Pin 9 auch wirklich zum richtigen Pin des AVR?

Sollte eigentlich gehen, ich verwende bei einem ATMega8:

void v_RS232_Init(uint8 w_Baudrate) { UBRRH = w_Baudrate >> 8; UBRRL = w_Baudrate & 0xFF; UCSRA = 0; /* U2X = 0, Normal Mode */ UCSRB = (1 bei aktiviertem RXEN das Beinchen sowieso nicht mehr auf DDRD hört.

Und was passiert bei nicht aktiviertem RXEN?

cu,

Steffen

Reply to
Steffen Koepf

Wolfgang Meier schrieb:

Leider bin ich des Assemblers unkundig, deshalb auch kompiliert.

@Wolf you've got Mail (wenn die Mailaddresse zustellfähig ist)

Jan Conrads

Reply to
Jan Conrads

2?

Dachte ich auch - aber jedes Mal, wenn ich Reset gedr=FCckt hielt, war der Pegel prima.

Reply to
Wolfgang Meier

Steffen Koepf schrieb:

Wolfgang Meier wrote:

Klar, weil dann die Ausgänge des Controllers hochomig wurden. Sicheres Zeichen dafür, dass zwei Ausgänge gegeneinander kämpften.

Reply to
Michael Roth

Hallo Wolf

Problem schon gefunden?

Was sagen Deine Fuses?

Jürgen

Reply to
Jürgen Schulz

Michael Roth schrieb:

Kann mich dieser Meinung nur anschlie=DFen. So klein kann ein Eingangs-Pull-Up kaum sein, da=DF er vom MAX232 nicht runtergezogen werden kann. Es sei denn, der jeweilige Pin ist ein Ausgang und damit per Ausgangstreiber mit einem 'virtuellen' Pull-up in Form des oberen Ausgangstransistors versehen.

Funzen k=F6nnte sowas allenfalls, wenn der Ausgang open-collector ist, mit einem gro=DFen Pull-up. Etwas =E4hnliches wurde bei den 8051er-uC's gemacht, mit den 'quasi-bidirektionalen' Pins, das funzte nur, wenn vorher eine 1 in das Register geschrieben wurde (Ausgang =3D high), da der Pull-up nur schwach war, lie=DF er sich dann per TTL-Ansteuerung auch runterziehen.

Auf die Dauer kann das Beschalten Ausgang gegen Ausgang auch zu Hardwaresch=E4den f=FChren.

Winfried B=FCchsensch=FCtz

Reply to
w-buechsenschuetz

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.