keine Verbindung vom RNBFRA-Board zum PC über RS232

[jguethe]

Re: die Verbindung vom RN-Board zum PC über RS232 funktioniert nicht.


Hi,

Ich mache meine ersten Gehversuche mit dem Board RNBFRA Version 1.22. Die Standard- Testprogramme laufen.

Seit Stunden versuche ich jedoch, das Mini-Programm „helloworld“ auf den PC auszugeben. Mit dem BASCOM-Simulator funktioniert es. Damit ist ja wohl sicher, dass das Programm prinzipiell funktioniert.

Die Verdrahtung (vorhandenes serielles Kabel, SuB-D-Stecker entfernt, 3-Pin Stecker für Board angelötet (TX, RX, GND). Diese Verdrahtung habe ich mehrfach geprüft; es gibt keinen Kurzschluss usw., das muss i.O. sein.

Baudrate 9600 im Programm und Terminal-Settings gleichlautend eingestellt.

Sowohl über COM1 oder COM2 (Setting in Terminal-Emulation natürlich angepasst) tut sich absolut nichts.
Auch Eingaben über die PC-Tastatur (Menüpunkte „Send ASCII-Charakter“ und Send magic number“ sind ebenfalls ohne jedes sichtbare Egebnis im Terminalfenster.
Wenn ich über Upload File die helloworld.hex lade, wird der Ladevorgang unten im Terminalfenster angezeigt (Fortschrittsbalken). Das ist aber auch alles.

Ich habe schließlich sogar mit einem Oscilloskop versucht, am Tx-Pin der RS232-Schnittstelle ein Signal nachzuweisen. Das Programm gibt ja in einer Endlosschleife permanent Daten aus. Ich habe aber bisher auch mit dem Oscillosop nichts feststellen können. Vielleicht habe ich aber nur das O. falsch eingestellt oder habe immer nur in der Wait-Phase (Wait-Befehl im Code) gemessen. Das muss ich wohl noch einmal mit Sorgfalt wiederholen.


Darüber hinaus fällt mir nichts mehr ein, was ich noch machen könnte. Denkbar wäre natürlich, dass die Com-Schnittstellen am PC eine Macke haben, aber gleich beide ?
Bin ich irgendwo auf dem völlig „falschen Dampfer“

Hat jemand eine Idee?

Besten dank schon mal im Voraus.

[robo_wolf]

also wenn sich am PC eine serielle verabschiedet, ist die andere gleich mit hin.
Ging mir auch so... :-(
Aber zu deinem Problem.
Ist deine Frequenz auf 8000000 oder 1000000?
8000000 ist die externe 1000000 ist die interne.
Wenn du dein ATmega noch nicht umgestellt hast, sollte da 1000000 stehen.
Gruß Silvio

[jguethe]

danke für die prompte Antwort.
Ich verwende Atmeg16 und habe versuchsweise eingegeben:
$crystal = 1000000 ' 1 Mhz
und
$crystal = 10000000 '10 Mhz
Es ändert sich gar nichts.
Ich kann das mit den abweichenden Frequenzen auch

[robo_wolf]

ne ne
du kannst nicht einfach die Frequenz einstellen wie du willst.
Entweder du hast auf intern 1MHz oder extern auf 8Mhz, je nachdem ob du schon den externen Quarz(8MHz) nutzt oder nicht.

[robo_wolf]

In der Bedienungsanleitung ist die Umstellung beschrieben.
???Fusebits??? sagt dir das schon was?


Gruß Silvio

PS.
Hat das LED-Lauflichtprogramm funktioniert?

[jguethe]

ich verwende atmega16 mit 8-MHz Quarz.
im Quellcode steht original
$crystal = 8000000
Versuchsweise habe ich 1000000 und 10000000 (eine Null mehr für 10Mhz) genommen.
Es ändert sich nichts.

Meine vorherige Antwort war unvollständig und verstümmelt. Der Editor in meinem notobook spinnt. Das ist aber eine andere Baustelle.
Gruß
jguethe

[robo_wolf]

LED-Lauflicht: funktionierte es oder nicht?
Falls du es noch nicht probiert hast, tu es bitte.
Frank hat sich bei der Reihenfolge der Programme schon ein wenig Gedanken gemacht.
Es geht dabei um das systematische Testen der Komponenten.
Gruß Silvio

Ps. Bis du sicher, daß du das Programm auch wirklich übertragen hast?

[jguethe]

Die Fusebits für atmage16 habe ich nach Vorlage eingestellt (nachdem ich einen atmega32 lahmgelegt habe). Die Einstellungen habe ich noch noch einmal geprüft. Alles exakt so wie beschrieben.
Das Lauflicht läuft hervorragend. Alle Testprogramme, die mit der aktuellen Hardware (am Board sind 2 Getriebemotore angeschlossen) Sinn machen, habe ich ohne Probleme zum Laufen gebracht. Auch „helloworld“ läuft (Simulator); nur die Ausgabe auf RS232 geht nicht.

Das Lauflicht und Getriebeprogramm - Programm habe ich just for fun kombiniert und variiert, um etwas „feeling“ für die Programmierung zu bekommen ( Bascom und die AVR-spezifische Befehlssyntax sind für mich als AVR-Neuling etwas gewöhnungsbedürftig (bin mehr in Turbo Pascal zu Hause).

Ich bin auch sicher, dass die Programme in den Chip gelangt sind.

Gruß
jguethe

[robo_wolf]

also wenn alle anderen Programme laufen, passen deine Einstellungen.
Hast du das Kabel auch von robotikharware(http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath=73&products_id=42) gekauft?
Ich erinnere mich, daß es vor ein paar Monaten Probleme mit der Verdrahtung des Steckers gab. Eventuell mal die Verdrahtung überprüfen.
Eine weitere Fehlerquelle könnte der MAX232 oder einer seiner Elkos(4,7µF) sein..? Schau noch mal die Polungen an. Und um die serielle Schnittstelle auszuschließen.. Hast du vielleicht an anderes Peripheriegerät, was du an der Schnittstelle testen könntest? Modem vielleicht?
Gruß Silvio

[jguethe]

Vielen Dank,
ich werde jetzt nach dem Fehlerausschlussverfahren vorgehen.
In meinem Dunstkreis gibt es mehrere Rechner und auch ein serielles Peripheriegerät (Telefonanlage mit Schreib- und Lesefunktion), so dass ich die serielle Schnittstelle meines Home-PC und die des Boards auch damit testen kann. Dauert nur etwas.

Das Kabel ist nicht von robotikharware.de (hatte damals übersehen, dass es dort so was gibt). Habe mir das Kabel daher gestern mit Hilfe der sehr guten Schnittstellenbeschreibung in roboternetz.de selbst zusammengebastelt. Die Pinbelegung etc. ist mit Ohm-Meter durchgemessen. Ich halte es nahezu für ausgeschlossen, dass es daran liegt.

Da ich mit dem Oscilloscop bisher kein signifikantes Signal am TX-Pin des Boards nachweisen konnte, nehme ich stark an, dass der Hund irgendwo auf dem Signalweg vom atmega über den Max232 zum Ausgang begraben liegt. Die Hardware-Seite werde ich – wie von dir angeregt - noch einmal genauestens prüfen.

Mein helloworld-Programm werde ich veranlassen, dass es in einer Schleife und ohne Verzögerung ununterbrochen eine Ausgabe produziert. Da die Daten bitweise übertragen werden, muss ich doch die Taktfreqzenz vom Chip bis zum Tx-pin verfolgen können. Dazu muss ich mich natürlich etwas intensiver mit der Hardware, der Verdrahtung auf dem Board und der Methode der Signalaufbereitung etc. beschäftigen, um herauszufinden welche Signale ich wo und in welcher Form (Pegel, Frequenz) erwarten darf. Kurz gesagt: ich möchte den Sollzustand mit dem Istzustand vergleichen. Mein Problem ist aber zunächst einmal der Sollzustand. Mangels hinreichender konkreter Erfahrung bin ich dabei auf meine Überlegungen angewiesen; die müssen aber nicht immer richtig sein. Für Hinweise, welche in diese Richtung gehen, wäre ich sehr dankbar.

Gruß
jguethe

[PicNick]

Vergiß mal Oszi & Co:

Das PC-Terminalprogramm + COM Port kannst du einfach und zweifelsfrei testen:
Steck das Kabel vom RNBFRA-Board ab und überbrücke die beiden äusseren Pins (Rx u. TX)
was du jetzt am PC schreibst, muß dadurch als echo am Terminalfenster erscheinen.
Gern wird auf "handshake" (Flußkontrolle) vergessen. DAS MUSS auf NONE stehen !)


Bevor das nicht geht, brauchst du nix anderes zu suchen.

lass hören !

[robo_wolf]

bin der gleichen Meinung und würde die geiche Schlüsse ziehen.

Wenn du direkt am TX der Platine keinerlei Aktivität findest, liegt es an der Platine selbst.
Als Erstes die Lötstellen überprüfen.(mit Multimeter messen)
Der MAX232 wird von PD0 und PD1 des ATmegea bedient.
Den ATmega würde ich ausschließen. Die restlichen Schaltungen arbeiten ja.
Da bleibt der MAX232 selbst(ist er richtig herum im Sockel) und die 4 Elkos mit 4,7µF(Polung).
Viel mehr kann es doch nicht sein.

Also viel Spass beim Suchen...
Gruß Silvio

[Olle_Filzlaus]

Hallo,

wenn du ein Oszi hast, würde ich an deiner Stelle mal am TXD Pin des Atmegas direkt messen (Spannung zwischen 0 un d5V, also TTL).
Dann messe mal am MAx232, also deinem Serial - TTL wandler. Eventuell hast du ein Problem mit einer Lötstelle / Leiterbahn und es kommt kein Signal zum MAX.

Zur not schreibe dir einfach ein kleines Programm was den TXD Port des Atmegas blinken lässt. Bei fragen dazu helfen wir dir hier gerne.

Weil wenn ich mich nicht ganz irre sind nach dem MAX232 die 0V des Atmegas -12V und die 5V des Atmegas sind +12V.

Oder der MAx ist defekt. Dann passiert och nichts.

Das müsstest du also alles mit dem Oszi messen können.

cu arno

PS: was bei mir damals auch ein Problem war, ich hatte nur ein 3 Adriges Kabel genommen und hatte die MAssen vom PC nicht mit dem vom Board verbunden. Damit hing die scheinbar etwas Quer und ging nicht. nach verbinden der beiden geräte ging es wunderbar.

PPS: Ups, da war ich zu langsam.

[jguethe]

Dank Euch allen,

muss das erst mal alles abarbeiten. Dauert ein Weilchen.
Wenn's so weit ist, berichte ich über den Fortgang.

Gruss
jguethe

[jguethe]

Hallo,
zum aktuellen Stand meines RS232-Problems:
es hat mir keine Ruhe gelassen, obwohl ich eigentlich was anderes zu tun hatte.
PC-Schnittstelle wie von Robert beschrieben getestet – besten Dank für den Tipp - ; danach sollte die RS232 am PC incl. mein selbst gestricktes Kabel ok sein. Die Tastatureingaben erscheinen im Terminalfenster. Ich denke, damit ist auch sicher, dass der Treiber für die Schnittstelle geladen ist. Ich erwähne das deshalb, weil bei einem meiner PC’s die serielle Schnittstelle nach jedem Neustart nicht funktioniert. Wenn ich dann den Treiber aktualisiere, also neu lade, ist alles wieder ok.

Inzwischen sind alle Lötstellen etc geprüft. Kein Elko wurde falsch gepolt; die IC’s sind alle richtig eingesetzt. Alle Verbindungen sind mit Ohm-Meter durchgemessen. Ich kann in dieser Richtung absolut keinen Fehler feststellen; ich muss schon sagen: leider. Denn ein gefundener kapitaler Fehler, wäre vermutlich die Lösung.

Inzwischen ist es mir aber nun doch gelungen, mit dem Osci Datenpakete nachzuweisen. Sie sind eindeutig vom Programm erzeugt. Ich habe das mit mehreren Programmversionen getestet, die signifikante Datenpakete erzeugen; sie sind nicht mehr da, wenn das Programm gelöscht wird usw.; hier gibt es keinerlei Zweifel. Sie lassen sich vom Pin15 (PD1 des Atmega16) über den Eingang des Max232 (Pin11) bis zum Ausgang Tx nachweisen. Dort messe ich mit Ohm-Meter ohne Signal etwa -10,5 VDC, mit Signal (signalabhängig) etwa -6, 5 bis -8,5VDC. Das ist von der Funktionsweise des MAX her ja auch logisch. Die Messergebnisse bleiben stabil, ob das RS232-Kabel nun angeschlossen ist oder nicht. Auch am Ende des Kabels (also die Buchse, die in den PC geht, kommt das Signal unverändert an. Meine Messungen interpretiere ich so, dass die Pegelumwandlung des MAX232 grundsätzlich funktioniert.

Da im Terminalfenster trotzdem nichts sichtbar ist, bin ich ziemlich ratlos.

Zwei Messergebisse machen mich stutzig:
1. Am Pin 6 des MAX232 messe ich mit nur etwa -8,5 VDC (Soll -10VDC). Ist diese Abweichung normal ?
2. Am Coprozessor AT90S2313 zeigt mir mein Osci eine wunderschöne Sinuskurve der 4Mhz-Frequenz mit sehr hoher Amplitude an, die sich auch sehr schön „einfangen“ lässt.
3. Am Mega16 dagegen muss ich die Empfindlichkeit des Eingangs etwa um den Faktor 10 erhöhen, um die 8Mhz zu sehen, das Triggern ist deutlich problematischer. Das Signal ist auch etwas „verrauscht“. Kann natürlich auch sein, dass mein Osci bei 8 MHz schon leicht überfordert ist. Das ist schließlich kein High-Tec-Laborgerät. Da der ATMEGA aber mit diversen Programmen läuft, kann diesbezüglich eigentlich kein Fehler vorliegen.

Einstweilen habe ich den MAX232 im Verdacht und auch die PC-Schnittstelle. Ich werde ersteren zunächst auswechseln. Ersatzbestellung ist schon veranlasst. Und dann es noch einmal mit einem anderen PC versuchen und Masse-PC und Masse-Board miteinander verbinden; letzteres kann ja auch Probleme bereiten.

mfg
jguethe

[PicNick]

Gemach, gemach.
Jetzt könntest du den ATmeg32 sicherheitshalber rausnehmen.
Das µC<>PC Kabel wieder anstecken.
Und jetzt die RX TX Leitungen auf der RNBFRA überbrücken und das gleiche mit ECHO probieren.
(Das kannst du auf dem Jumper, wo auch die RxTx Verbindungen zum CoProz gejumpert werden

Also erst war's ein Echo VOR dem MAX.
Jetzt wär's ein Echo NACH dem Max.

Geht das--> Max ist in Ordnung --> Next : Atmega checken.
Geht das nicht (sicherheitshalber das Rx232-Kabel auch mal andersrum stecken. ) hat es definitiv was mit dem MAX.

nun ?

[jguethe]

ich mag es gar nicht sagen, aber die Lösung ist so einfach.
Die Rx/TX_Leitungen müssen natürlich gekreuzt werden.
Hatte immer - im Glauben an meine eigene Unfehlbarkeit - angenommen, dass ich das schon längst probiert hatte.
Der letzte Hinweis von Picknick hat mich dann veranlasst, meinen Altersstarrsinn mal einen Moment zu vergessen und den Stecker auf der Platine um 180 Grad zu drehen, bevor ich alles andere probiere. Ich wollte erst gar nicht glauben, was ich dann sah.

Sorry, wenn ich Euch genervt habe.

Für mich war es zwar auch nervig, aber nicht umsonst. Ich habe mich notgedrungen etwas mehr um die Hardware u. Funktionen des RNBFRA kümmern müssen und dabei manches gelernt.

Danke für die Hilfe
mfg
jguethe

[PicNick]

*schwitz*
Naja, laut Murphy:
Wenn man ein Kabel irgendwie verkehrt reinstecken kann, wird man es auch tun.
Mach Dir nix draus. *g*

[jguethe]

gut zu wissen, dass man nicht vollends verdammt wird.

Der kleingedruckte Spruch ist ja sehr beziehungsvoll. Ich denke, ich habe verstanden. Hast' ja Recht.
mfg

[robo_wolf]

jaja dummerweise denkt man immer gleich ans Schlimmste... :-) O:) Dabei sind es oft die einfachste Dinge, die zur Verzweiflung bringen.
Wenn man es im Nachhinein nüchtern betrachte, ist es sowas von einleuchtend, das nur der RX was vom TX wissen möchte und RX mit RX nichts anzufangen weiß.

Aber du kannst sicher sein, diese Stolpersteine werde dir immer wieder mal begegnen.
Silvio