Max232 Schaltung für AVR funzt nicht - wie testen?

Hallo,

W. Bayer schrieb:

Oszi an R1Out, ser. Daten schicken: Zappelt da was zwischen 0V und 5V? Umgekehrt: Rechtecksignal an T1In anlegen, kommt dann ein solches mit knapp +/- 10V an T1Out heraus? Sind die Elkos ok? Über die Funktion steht doch alles im Datenblatt, ruhig mal reinschauen...

Gruß, Bernhard

Hmm, stimmt ggf. noch die von der Software angenommene Taktrate nicht mit der wirklichen überein? Da bin ich als erstes drauf reingefallen :-)

Viele Grüße, Gilles.

@Bernhard: Ich hab leider keinen Oszi, ich lieb=E4ugle zwar mit einem, hab aber noch nichts g=FCnstiges gefunden... Die Elkos habe ich extra noch mal ausgel=F6tet und neue geholt, daran lag's aber nicht :-(

@Gilles: Meinst Du die Baudrate vom AVR bzw. meiner seriellen Schnittstelle? Die sollte =FCbereinstimmen, beides bei 9600 Baud.

M=FCsste ich durch =DCberbr=FCcken der beiden Tx/Rx Ausg=E4nge am Max232 ke= in lokales Echo bekommen? Also quasi so als ob ich direkt am seriellen Ausgang Tx/Rx =FCberbr=FCcke? Mich hat n=E4mlich gewundert, dass das garnix bewirkt.

Ich habe das an zwei PCs getestet, der eine hat eine echte serielle S. mit +/- 12V, der andere einen USB->RS232 Adapter, da kommt n=E4mlich nur

danke & Gru=DF Werner

W. Bayer schrieb:

Protokoll richtig eingestellt? Bekommst du denn ein Echo wenn du Rx und Tx auf der +/-12V Ebene brückst?

Gruß Dieter

W. Bayer meinte:

Hmm, laut Datenblatt sind es aber beim MAX232 1µF und beim MAX232A

Echo mußt Du beim Überbrücken bekommen, egal auf welcher Seite.

Mal abgesehen davon, daß es sich dabei nicht um ein "lokales Echo" handelt (nicht deine Formulierung, sondern die des OP), ist es natürlich nicht zwingend, daß man bei einfachem Kurzschluß der korrespondierenden Ein- und Ausgänge in einer Applikation ein Echo erhält. Ob das klappt, hängt auf der RS232-Seite von der "Ergiebigkeit" des Ausgangs der angeschlossenen PC-Schnittstelle im Verhältnis zur Ergiebigkeit des MAX232 ab und auf der MAX232-Vcc-Seite natürlich von der "Ergiebigkeit" der dort angeschlossenen weiteren Hardware, wieder im Verhältnis zur der "Ergiebigkeit" des MAX232, bloß diesmal eben auf dessen Vcc-Seite.

Während auf der RS232-Seite i.d.R. die PC-Schnittstelle (mit Ausnahme von halbseidenen USB-Adaptern) die deutlich stärkeren Stromargumente hat, um gegen den MAX zu gewinnen, sieht das auf der Vcc-Seite oft schon ganz anders aus. Der aktive Ausgang eines ATMega gewinnt hier z.B. ganz locker gegen den Ausgang des MAX, wenn beide "gegeneinander" auf denselben Eingang des MAX arbeiten.

Und, last but not least: Ein Brücke aus Lötzinn gewinnt sowieso praktisch immer. Egal auf welcher Seite des MAX man sie produziert hat. Vor dem allgewaltigen Massepotential in seiner niederohmigsten Inkarnation vergehen alle Stromquellen in Ewigkeit. Amen.

Heiko Nocon schrieb:

Ich hatte den OP so verstanden, dass er wirklich nur die beiden Pins am MAX 232 gebrückt hat, also ohne AVR (bzw. AVR mit gelöschtem ROM, damit alle Pins Eingang sind). Dann muss es wirklich immer funktionieren mit dem Echo, sonst ist was anderes foul (z. B. ein Terminalprogramm, das auf ein dümmliches Modemsteuersignal wartet wie DCD oder DSR).

Heiko Nocon meinte:

Natürlich, ich würde das auch nur mit offenen Ein/Ausgängen machen. D.h. für den Test den Controller abklemmen oder um nur die PC Schnittstelle zu prüfen den MAX abklemmen. Dann halt Stück für Stück bis zu dem Punkt wo es hängt.

Ich würde aber erstmal zu anderen Kondensatoren raten, denn die auf der erwähnten Web-Seite angegebenen 22µF empfinde ich als etwas krass gegenüber den Angaben im Datenblatt.

Nein, ich meine die AVR-Seite alleine. Die gewünschte Baudrate wird dem Chip ja nur indirekt durch einen Vorteiler (UBRR1H/L) mitgeteilt, der sich (in C) aus

((F_CPU/((baudrate)*16UL)) - 1)

errechnet. F_CPU ist hier meist ein #define (-D) aus dem Makefile oder einem Headerfile. Wenn F_CPU so wie es die Software (z.B. gcc-avr) sieht jetzt nicht mit der Realität (echte Taktfrequenz am ATMega8) übereinstimmt dann ist das Ergebnis eine falsche resultierende Baudrate.

Eine Idee wäre noch die ganze USART Komplexität erstmal (zu Diagnosezwecken) zu umgehen indem Du PD0 (aka RXD) als Eingang und PD1 (TXD) als Ausgang schaltest, und in einer Schleife PD1 gemütlich im Sekundentakt toggeln lässt und das auf PD0 gelesene auf einem anderen Port/Pin ausgibst. Macht ggf. das Messen einfacher :-)

Viele Grüße, Gilles.

Seh ich genauso. 22uF ist wirklich viel.

Mit 10 uF geht es meistens, kann aber bei einigen Varianten schon mal Probleme machen. Ich verwende deshalb normalerweise 1uF Kondensatoren.

Wenn es nicht funktioniert, kann man zunächst mal ohne PC und Mikrocontroller testen, d.h. einfach die Eingänge auf 0V bzw. 5V legen und schauen, ob am Ausgang das invertierte Signal mit dem richtigen Pegel herauskommt.

Dabei ist es auf der +-12V Seite zunächst egal, ob man den RX-Pin mit

Der TX-Pin auf der 12V Seite sollte dann ca. +- 8 bis +-10V liefern.

Dann könnte man noch die Spannungen an den Kondensatoren der Ladungspumpen nachmessen. Was da anliegen muss, sollte sich aus dem Datenblatt ergeben.

Aber eigentlich ist so ein MAX232 ziemlich pflegeleicht und unproblematisch.

Gruß

Stefan

Falsch. Das ist nur die Hälfte der Wahrheit. Nichtmal das.

Zwei Aspekte läßt du hier nämlich geflissentlich unter den Tisch fallen:

Du hast sicherlich Recht, man kann natürlich auch noch einiges mehr beim Initialisieren der Schnittstelle falsch machen. Mein Punkt war weniger die exakte Formel zur Einstellung der Baudrate zu liefern sondern auf eine potentiell hintertückische Fehlerquelle hinzuweisen, aus leidvoller Erfahrung heraus :-)

Ich bin beileibe kein AVR-Experte, sind Rundungsprobleme (derart dass nicht mal Müll ankommt) bei den angegebenen 9600 Baud (die vom OP angegebene Schaltung benutzt wohl mindestens 4, 7.3728 MHz) zu erwarten? Wäre double speed nötig?

Wie dem auch sei, ich hoffe Werner lässt uns wissen was letztlich das Problem war.

Viele Grüße, Gilles.

Gilles Kohl schrieb:

Hängt vom CPU-Takt ab. Mit den voreingestellten 1 MHz aus dem RC-Oszillator ergeben sich beim 16-fach oversampling zu große Fehler für 9600 Bd, sodass man U2X dort braucht.

Hallo an alle,

vielen Dank f=FCr die rege Beteiligung!

Ich bin noch dran, folgende Erkenntnisse habe ich gewinnen k=F6nnen:

- Die Schaltung funktioniert so wie angegeben

- Mit 2400 Baud kann ich Daten vom AVR an den PC schicken (andersherum habe ich noch nicht versucht) - ich habe ebenfalls die Wunderformel aus dem Datenblatt benutzt: ((F_CPU/((baudrate)*16UL)) - 1)

- Mit 9600 Baud hab ich es noch nicht hinbekommen, dabei habe ich eine Schleife gebastelt in der ich den Takt langsam hochz=E4hle und immer die gleichen Buchstaben raussende (ich war mir urspr=FCnglich auch mit dem 1 MHz nicht sicher), dann wird es wohl so sein, dass der Takt dabei nicht reicht.

Ich programmiere ja ansonsten Java und so Webgeschichten, hatte also bislang mit Asm und C eher weniger zu tun. Ich habe jetzt AvrStudio und WinAvr in Verwendung, damit klappt es ganz gut.

Ich h=E4tte noch zwei kleinere Fragen:

- Ich habe ja einen 16MHz Quarz in der Schaltung. Wie kann ich den aktivieren (ich habe PonyProg zum kopieren), also welche FUSE-Bits muss ich setzen?

- Die main Funktion scheint sich ewig zu wiederholen, ist das normal? =DCblicherweise sollte die doch nur einmal durchlaufen? Ich bekommen also "Hallo AVRHallo AVRHallo AVRHallo AVR" [...] statt nur einmal.

danke & Gru=DF an alle Werner

Mein Testprogramm um einen String von AVR an PC zu senden sieht so aus:

#include #include #include

#define F_OSC 1000000 /* oscillator-frequency in Hz */ #define UART_BAUD_RATE 2400 #define UART_BAUD_CALC(UART_BAUD_RATE,F_OSC) ((F_OSC)/ ((UART_BAUD_RATE)*16l)-1)

void init(long osc) { // set baud rate UBRRH =3D (uint8_t)(UART_BAUD_CALC(UART_BAUD_RATE,osc)>>8); UBRRL =3D (uint8_t)UART_BAUD_CALC(UART_BAUD_RATE,osc);

// Enable receiver and transmitter; enable RX interrupt UCSRB =3D (1

Mein Macro rechnet mit deinen Angaben zu Takt und Bitrate als bestmögliche Initialisierung aus:

UBRRL=12 UBRRL=0 U2X-Bit setzen

Das heißt zwar noch nicht, daß es auch tatsächlich funktioniert, aber die Wahrscheinlichkeit dafür ist deutlich höher als bei der von dir gewählten Variante.

Nur CKSEL0 angehakt.

Wenn du main mit return verläßt: Klar. Du mußt da eine Endlosschleife nach der Ausgabe einbauen.

Hier gibt es kein Betriebssystem, was nach Ende der Anwendung die Kontrolle übernimmt. Die Anwendung selbst ist das OS und das verläßt man nur durch Ausschalten.

Am Tue, 20 Mar 2007 20:03:20 +0100 schrieb Heiko Nocon:

Ich nehme für so etwas immer den Application Builder aus dem ICC-AVR (geht IMHO auch in der Trialversion). Der wirft dann schon das Grundgerüst mit den gewünschten Initialisierungen aus und zeigt beim UART die Abweichung vom Soll in% an.

Lutz

W. Bayer schrieb:

Schau doch mal ins ATMEGA8-Datenblatt, Seite 136:

UBRR ist auf fosc/(16*baud)-1 zu setzen. Da nur ganzzahlige Werte für UBRR in Frage kommen, wird die tatsächliche Baud-Rate am Ende fosc/(16 UBRR +1) betragen, also leicht anders sein.

Diese Rate sollte keine großen Abweichungen von der des Computers zeigen, ansonsten tastet der Computer während des Abtastens des gesendeten Bytes nicht mehr die zeitliche Mitte der Bits ab und kann während der 8N1 Bits ins falsche Bit rutschen. Damit das nicht passiert empfiehlt Amtel auf Seite 158 für den 8N1-Modus einen maximalen Fehler von 2%.

Für deine µC-Frequenz und 9600 Baud erhält man also (auch gemäss Tabelle 60) einen Fehler von -7%, was zuviel ist.

Mit dem U2X-Modus (und den geänderten Formeln mit 8 statt 16) klappt es mit deiner Taktrate besser: UBRR=12 liefert -0.2% Fehler für 9600 Baud.

Wenn Du die interne Taktrate auf 8 MHz setzt, bekommst Du mit gleichem Fehler auch 38400 Baud hin. Ansonsten gibt es noch die Möglichkeit Baudraten-Quarze zu nehmen, so daß der Fehler wirklich 0% wird.

Optimiert der Compiler da das strlen aus der Schleife raus oder berechnet er die Länge bei jedem Durchlauf neu?

Ich hätte das ja eher als while (*seq) { while(!(UCSRA & (1

Versuch mal 2MHz sowohl via PonyProg (s.u) in der Hardware (interner Oszillator) als auch als F_OSC einzustellen (dabei nicht vergessen in Deinem main() das F_OSC auch wirklich zu benutzen ;-) damit sollten

PonyProg scheint die Besonderheit zu haben, die Bits invertiert darzustellen - angehakte Checkbox --> Bit ist 0 (fuse programmiert). Hier steht was dazu:

Ersetze das return 0 durch ein while(1); o.ä. (Der GCC ist übrigens schlau genug, nicht anzumeckern dass die Funktion nichts zurückgibt, da sie das ja dann auch nie vorhat :-)

Dieselben Restarts werden auch auftauchen wenn Du Interrupts per sei(); generell freischaltest (den RX interrupt hast Du ja schon aktiviert), der PC Zeichen schickt und Du noch keinen interrupt handler spendiert hast. (Been there, done that ...)

Ich hab' mir nicht angeschaut ob/wie das wegoptimiert wird, aber die for-Schleife in uart_out_string berechnet im Prinzip für jedes Zeichen das sie ausgibt, die Stringlänge erneut, ahem.

Viele Grüße, Gilles.

Moin!

Wenn der AVR momentan noch auf dem internen RC-Oszillator läuft, ist das wirklich kein Wunder, wenns nicht klappt. Zusätzlich zu den Rundungsfehlern bei der Baudrate läuft der interne Oszillator nämlich mit +/- 3% (@5V, 25°C) -0,07%/K +3%/V. Für die RS232 sind schon die

Gruß, Michael.