Grundschaltung ATMega8 & Max232

[JKLCK]

Hi,

ich bin grad an einer Platine mit Mega8 und Max232 auf ein Problem gestoßen.
Zur Platine:

Der Mega8 wird mit dem MCS Bootloader per ISP vorprogrammiert und soll dann in diese Platine eingesetzt werden. Neue Programmierung soll dann eben per Bootloader und RS232 auf den Mega8 gelangen.

Spannungsversorgung ist ein 7,4V LiPo, Spannungsregler ein 7805 IC;
der Max232 wurde wie im Datenblatt empfohlen mit 1,0u Elkos beschaltet

Reset wird wie bei der RN-Control 1.4 beschaltet.

Zwischen Vcc und GND sitzt ein 100nF Keramikkondensator
Pin 8 & Pin 22 sind beide auf GND
Aref und Avcc Sitzen an 5V (Vcc)

Zum Problem:

Programmierung verläuft ohne Probleme per ISP
Als Testprogramm (auch per ISP programmiert) wurde ein einfacher "print" befehlt und im Loop programmiert.
Wenn der Microcontroller jedoch nun eingesetzt wird erhalte ich kein Signal per RS232.


Wie kann ich am besten feststellen, wo das problem lieg?
Evt an der Beschaltung? An den ICs?

Anbei der Schaltplan als PDF

Vielen Dank schonmal für eure Hilfe :)

[Besserwessi]

Die Diode am Eingang ist überdimensioniert. Besser wäre ein kleine Shottkydiodem, denn die Spannung ist schon knapp. Unter etwa 3.6 V je zelle wird man so kaum die vollen 5 V kriegen. Vermutlich wäre ein Low Drop Regler hier besser, denn gegen Ende ist die Spannung mehr bei etwa 6 V.

Das eigentliche Problem könnte sein, das die Frequenz des µC nicht stimmt. Der internen Oszillator reicht nicht für einen zuverlässige RS232 Verbindung.

Sonst nur die üblichen, aber nicht scherwiegenden Fehler:
1) zweiter Abblockkondensator bei AVCC-AGND fehlt.
2) AREF an Vcc ist nicht sinnvoll, das macht man meistens besser intern.
3) der Elko hinter den Regeler ist reichlich groß, 10 µF würden auch schon reichen, wenn überhaupt nötig (bei den lowdrop Reglern in der Regel, bein 7805 aber nicht)


Zum nachmessen:
1) Spannungen an C9 und C10 : sollte jeweils etwa 9 V sein.
2) Spannung hinter dem Regler (5V ?)
3) Loopback test: µC aus dem Sockel und dafür Brücke zwischen Pins 2/3
4) kommte denn vom Pront irgendwas an ? (Zahl der Zeichen ?)

[JKLCK]

Danke für die schnelle Antwort!

also, ich bin grad leider nicht zuhause aber ich probiers mal trotzdem:
Also, externer Quarz anschaffen (ca. 20MHz?)
werde zweiten 100uF an AVcc und AGnd setzen und Aref trennen.
muss auch nochmal die 100uF nachmessen, hatte schonmal probleme damit.
bin mir sicher, dass der Regler 5V ausgibt, das ist schon geprüft.
Loopbacktest und C9 und C10 gemessen wird gemacht, sobald ich zuhause bin.
hab gesehen bei der RN Control und RNMega8 sind die Elkos am Max232 4,7u.
Ne Ahnung wie das zustandekommt?
Was meinst du mit Pront?
Wenn du Print meinst nein, jedoch wenn nach einem reset kommen gelegentlich 1-11 zeichen per rs232 an(meistens C mit nem Strich unten).

Mal sehen was die änderungen bringen :)

Anbei der neue Schaltplan

[Hubert.G]

Ein Baudraten Quarz ist für hohe Übertragungsraten besser, 18,432 MHz wäre z.B. so einer.

[JKLCK]

Werde wohl einen 16MHz Quarz benutzen, da das Board mit dem diese Platine kommunizieren soll auch auf 16 MHz läuft

[JonnyP]

Wenn du über RS-232 kommunizieren willst, dann ist die Baudratenfrequenz wichtig und nicht so sehr der Prozessortakt. Wie hier schon erwähnt, benutze einen "Baudratenquarz" mit 14.xxx oder 18.xxx MHz wenn du nicht auf die Nase fallen willst.

[Willa]

Also ich benutze einen 16MHz Quarz am ATmega32 bei 115200 baud. Noch nie einen Fehler bemerkt.... Soo wichtig kann ein Baudratenquarz dann nicht sein? Oder macht sich das erst bei langen Leitungen bemerkbar?

[oberallgeier]

... externer Quarz anschaffen (ca. 20MHz?) ...
Werde wohl einen 16MHz Quarz benutzen ...Atmel spezifiziert in den Datenblättern den Mega8 und den Mega8A (http://www.atmel.com/dyn/resources/prod_documents/doc8159.pdf) mit maximal 16 MHz. Wäre also wohl sinnvoll, innerhalb dieser Spezifikation zu bleiben. Es ist nicht zwingend notwendig, für Sendecontroller und Empfänger den gleichen Quarz zu nehmen, könnte aber zur Minimierung der Fehler hilfreich sein. (Ich vermute, dass bei gleicher Fehlerabweichung die Verbindung recht stabil läuft . . . *gggg* . . . ist aber eine unbewiesene bzw. ungetestete Vermutung).

Für 20 MHz-Quarze (mit denen ich meine M168er betreibe) habe ich mal eine Fehlerrechnung für verschiedene UBRR gemacht. (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=438494#438494) So etwas gibt es aber auch in verschiedenen Baudratenrechnern, die im www herumschwirren.

[JKLCK]

an C10 liegen nur 4,7V an
an C9 die erwarteten 9,5V

Loopbacktest im bascom:
wenn ich ASCII Code 100 sende kommt ein d zurück, sollte also auch IO sein

liegt also wohl am Quarz?

mal sehn wie das dann mit dem 16MHz ding läuft

[JKLCK]

funktioniert immernoch nicht, nachdem ich den Quarz eingebaut hab und die Fusebits per ISP auf den ext. Quarz eingestellt hab.

Noch vorschläge jemand?

Einfach mal ISP an die Platine knallen und gucken ob ich dann kommunizieren kann? würde das gehen?

[Hubert.G]

Hast du schon mal probiert den Kontroller herausnehmen und im Sockel RX und TX zu brücken und eine Eingabe über das Terminal zu machen, dann sollte ein Echo auf den Bildschirm zurück kommen. Wenn das funktioniert dann ist der Wurm in Kontroller.

[JKLCK]

Hab das gemacht und dann im Bascom Terminal einen ASCII Code gesendet und etwas zurückerhalten, dass sinnvoll aussah. Glaube es war 123 und ein d zurück.

Muss man evt. die 22pF Kerkos am Quarz über einen 100nF Kerko an 5V anklemmen?

Ich bin kurz davor, alles nochmal zu probieren :)

[Besserwessi]

Die 22 pF am Quarz kommen nach GND. Es würde wahrscheinlich auch nach Vcc oder über einen extra 100 nF Kondensator in Reihe gehen, aber das ist nur störempfindlicher.

Die 100 nF kommen von GND nach VCC bzw. von AGND (manchmal auch als GND bezeichnet) nach AVCC.

Die nur 5 V an einem der Elkos für den am max232 sind sicht unbedingt das was sein soll, aber die meisten PCs kommen auch mit der kleineren Spannung zurecht. Irgendein kleiner Fehler (kalte Lötstelle oder Haarriss ?) müßte da aber auch noch sein. Könnte auch eine Messung am falschen Elko sein.

So wie es Aussieht geht irgendwas beim Controller nicht. Ein erste Test wäre es eine LED blinken zu lassen. Damit sieht man erst mal ober der µC überhaupt läuft und man kann die Taktfrequenz bestimmen.