MAX232 an ATmega32 - seltsames Verhalten

W

Wolfgang Meier

Guest
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ängt.


Der Versand von Nachrichten zum PC klappt hervorragend, es sind
nichtmal Einbrüche 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ß für den MAX232?



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

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

zusätzlich 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 |= (1<<RXEN) | (1<<TXEN); // activate RX, TX
UCSRC |= (1<<URSEL) | (3<<UCSZ0); // Asyc. 8N1
uint16_t ubrr = F_CPU / (USART_BAUD * 16L) - 1;
UBRRH = (uint8_t)(ubrr >> 8);
UBRRL = (uint8_t)(ubrr >> 0);

....soweit also auch keine schwarze Magie. Selbst ein vorgeschaltetes...

bit_clear(DDRD, PD0);
bit_clear(PORTD, PD0);

....bringt keine Linderung. Kein Wunder - sagt das Datenblatt ja, dass
bei aktiviertem RXEN das Beinchen sowieso nicht mehr auf DDRD hört.


Aber was könnte dann los sein?

Vielleicht hat ja jemand von euch schon einmal etwas ähnliches erlebt
und kann mir einen Tip geben.


Help me, d.s.e! You are my only hope...

Wolf
 
Wolfgang Meier schrieb:
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ängt.


Der Versand von Nachrichten zum PC klappt hervorragend, es sind
nichtmal Einbrüche 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ß für den MAX232?



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

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

zusätzlich 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 |= (1<<RXEN) | (1<<TXEN); // activate RX, TX
UCSRC |= (1<<URSEL) | (3<<UCSZ0); // Asyc. 8N1
uint16_t ubrr = F_CPU / (USART_BAUD * 16L) - 1;
UBRRH = (uint8_t)(ubrr >> 8);
UBRRL = (uint8_t)(ubrr >> 0);

....soweit also auch keine schwarze Magie. Selbst ein vorgeschaltetes...

bit_clear(DDRD, PD0);
bit_clear(PORTD, PD0);

....bringt keine Linderung. Kein Wunder - sagt das Datenblatt ja, dass
bei aktiviertem RXEN das Beinchen sowieso nicht mehr auf DDRD hört.


Aber was könnte dann los sein?

Vielleicht hat ja jemand von euch schon einmal etwas ähnliches erlebt
und kann mir einen Tip geben.


Help me, d.s.e! You are my only hope...

Wolf
Click to expand...

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:
Wolfgang Meier schrieb:
Der Pegel bricht auf TTL-Seite mit jedem Zeichen von +5V Ruhepegel nur
kurz auf ca. +4.9V ein.

Erst wenn ich den Microcontroller abklemme (oder mittels Jumper im
Reset halte) bekomme ich saubere Pegel von +5V und 0V

gibts evt. einen Kurzen zum Nachbarpin? (welches Gehäuse?)
Click to expand...
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.

Bei Nennung der Quarzfrequenz gibts ein kompiliertes Zweizeilerlein, um
Hardwarefehler auszuschließen per Mail.
Click to expand...
Quarz läuft mit 8.00 MHz.

Wenn's wirklich nur ein Zweizeiler ist, poste doch bitte zusätzlich
den Assemblercode hier hinein, dann müssen sich zukünftige
Antwortsuchende nicht erst per Mail an dich wenden ;-)

Danke schonmal,

Wolf
 
Wolfgang Meier <womei@sofort-mail.de> wrote:

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ß für den MAX232?
Click to expand...
Da arbeitet wohl Augang gegen Ausgang...

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

AVR MAX232 RS232
RXD -- 9 8 -- TX
TXD -- 10 7 -- RX
GND -- 15 15 -- GND
Click to expand...
Geht Pin 9 auch wirklich zum richtigen Pin des AVR?

Die Initialisierung des USARTS passiert mit folgendem Code-Schnipsel:

UCSRB |= (1<<RXEN) | (1<<TXEN); // activate RX, TX
UCSRC |= (1<<URSEL) | (3<<UCSZ0); // Asyc. 8N1
uint16_t ubrr = F_CPU / (USART_BAUD * 16L) - 1;
UBRRH = (uint8_t)(ubrr >> 8);
UBRRL = (uint8_t)(ubrr >> 0);
Click to expand...
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 << RXEN) | (1 << TXEN); /* Enable Receiver and Transmitter */
UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0); /* Async, 8N1 Mode */

}

...soweit also auch keine schwarze Magie. Selbst ein vorgeschaltetes...

bit_clear(DDRD, PD0);
bit_clear(PORTD, PD0);

...bringt keine Linderung. Kein Wunder - sagt das Datenblatt ja, dass
bei aktiviertem RXEN das Beinchen sowieso nicht mehr auf DDRD hört.
Click to expand...
Und was passiert bei nicht aktiviertem RXEN?


cu,

Steffen
 
Wolfgang Meier schrieb:
Jan Conrads schrieb:

Wolfgang Meier schrieb:

Der Pegel bricht auf TTL-Seite mit jedem Zeichen von +5V Ruhepegel nur
kurz auf ca. +4.9V ein.


Erst wenn ich den Microcontroller abklemme (oder mittels Jumper im
Reset halte) bekomme ich saubere Pegel von +5V und 0V


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


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.


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


Quarz läuft mit 8.00 MHz.

Wenn's wirklich nur ein Zweizeiler ist, poste doch bitte zusätzlich
den Assemblercode hier hinein, dann müssen sich zukünftige
Antwortsuchende nicht erst per Mail an dich wenden ;-)

Danke schonmal,

Wolf
Click to expand...

Leider bin ich des Assemblers unkundig, deshalb auch kompiliert.

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


Jan Conrads
 
Steffen Koepf schrieb:
Wolfgang Meier <womei@sofort-mail.de> wrote:

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ß für den MAX232?

Da arbeitet wohl Augang gegen Ausgang...
Click to expand...
Dachte ich auch - aber jedes Mal, wenn ich Reset gedrückt hielt, war
der Pegel prima.


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 << RXEN) | (1 << TXEN); /* Enable Receiver and Transmitter */
UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0); /* Async, 8N1 Mode */

}
Click to expand...
Danke, hat mir sehr geholfen. Nachdem ich einen Fehler in der Software
ausschließen konnte, musste er also in der Hardware stecken...


Und was passiert bei nicht aktiviertem RXEN?
Click to expand...
Klappt die Übertragung prima. Bei nicht gesetztem TXEN nur das
Empfangen, dafür mit remote-Echo. Tatsächlich war ein
Haar-Kurzschluss zwischen den Leiterbahnen dafür verantwortlich:

Gemessen - Durchgang
Reset gedrückt - Kein Durchgang
Gemessen - Wieder Durchgang
Grübel - Grübel
Knapp neben Reset auf die Platine gedrückt - Wieder kein Durchgang
Aha! - Hinschau - Lupe hol - Dreh - Wend - Kratz
Gemessen - Durchgang
Ausgelötet - Eingelötet
Gemessen - Kein Durchgang
Mit-flacher-Hand-an-die-Stirn-schlag


Danke euch für's Helfen!

Wolf
 
Steffen Koepf schrieb:
Da arbeitet wohl Augang gegen Ausgang...
Click to expand...
Wolfgang Meier wrote:
Dachte ich auch - aber jedes Mal, wenn ich Reset gedrückt hielt, war
der Pegel prima.
Click to expand...
Klar, weil dann die Ausgänge des Controllers hochomig wurden. Sicheres
Zeichen dafür, dass zwei Ausgänge gegeneinander kämpften.
 
Michael Roth schrieb:

Steffen Koepf schrieb:

Da arbeitet wohl Augang gegen Ausgang...

Wolfgang Meier wrote:

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

Klar, weil dann die Ausgänge des Controllers hochomig wurden. Sicheres
Zeichen dafür, dass zwei Ausgänge gegeneinander kämpften.
Click to expand...
Kann mich dieser Meinung nur anschließen. So klein kann ein
Eingangs-Pull-Up kaum sein, daß 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önnte sowas allenfalls, wenn der Ausgang open-collector ist,
mit einem großen Pull-up. Etwas ähnliches 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 = high), da
der Pull-up nur schwach war, ließ er sich dann per TTL-Ansteuerung
auch runterziehen.

Auf die Dauer kann das Beschalten Ausgang gegen Ausgang auch zu
Hardwareschäden führen.

Winfried Büchsenschütz
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top