MAX232 an ATmega32 - seltsames Verhalten

Aug 21, 2005 9 Replies

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


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

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

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

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

2?

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

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.

Hallo Wolf

Problem schon gefunden?

Was sagen Deine Fuses?

Jürgen

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

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required