RN-Control allgemein sowie Kommunikation via RS232

Hallo werte Robotiker,

ich bin vor 2 Wochen auf dieses Forum gestossen und habe mir letzte Woche (und nach intensivem Studium diverser Artikel ;) ) das RN-Control32 sowie ein Kabel auf RS232 bei Robotikhardware bestellt.
Letzte Woche ist dann auch beides angekommen. Ich habe das RN-Control an ein 5V-Netzteil angeschlossen, prompt hat es wunderbar zu blinken und zu "schnarren" (eine treffendere Bezeichnung für die Geräusche ist mir bislang noch nicht eingefallen) angefangen.
Ich habe die Bascom Entwicklungsumgebung (sowie später den RN-Bootloader) installiert und wollte den "RNControlTestMega32" auf die Hardware schieben.
Beim ersten Test mit dem MCS Bootloader hatte ich verschiedene Returncodes (0 bzw 123 sowie 255 waren die häufigsten), leider kam nicht einmal eine Datenübertragung zustande. Daraufhin habe ich die Baudrate von 38400 immer weiter abgesenkt, die letzten Tests ließ ich mit 300 Baud laufen. Am Resultat änderte sich nichts :(
Also habe ich - wie auch schon die Tage zuvor - hier im Forum gelesen und habe es daraufhin mit dem RN-Bootloader versucht. Der scheint zwar irgendwie mit dem RN-Control kommunizieren zu können, trotzdem war keine Datenübertragung möglich. Es wurde angezeigt, dass der Programmer Daten sendet sowie empfängt (die empfangenen Daten waren jedoch recht kryptisch), nur schienen die zwei an der Kommunikation beteiligten Devices unterschiedliche Sprachen zu sprechen.
Hier im Forum finden sich ja eine Menge Themen zu Schwierigkeiten mit der seriellen Kommunikation über RS232, allerdings bin dort auch nicht schlauer geworden.
Ich habe auch PonyPro installiert, jedoch war keine "Probe" auf die RS232 (egal mit welcher Konfiguration) möglich :(

Hier nun ein paar Fragen :
Das RN-Control "schnattert" und blinkt ja echt nett .... nur was soll ich mit diesen "Äusserungen" anfangen ?
Sind das Beepcodes oder Keycodes, die das Control mir mitzuteilen versucht ?
Wenn ja, gibt es dann eine Übersicht mit den Bedeutungen ?
Gibt es Tools um die serielle Schnittstelle am PC auszulesen (ähnlich WireShark für Netzwerkverbindungen) ?
Was würdet ihr mir raten, wie ich den Fehler (wenns den denn gibt) logisch am schnellsten eingrenzen kann ?
Bitte an dieser Stelle keine Hinweise auf den ISP-Dongle, diesen möchte ich mir als letzte (!) Alternative zur Kommunikation aufheben.
Schliesslich muss es ja irgendwie mit RS232 gehen ;)

Danke schonmal für die sicherlich konstruktiven Tips, die folgen mögen !


Grüsse, DaSumpf

Hi,

Zitat:

---

...und habe es daraufhin mit dem RN-Bootloader versucht.

---

meinst du damit den Bootloader des ATMegas?


Ich kann dir an dieser Stelle nur einen schon oft gegebenen Tipp geben: RS232-Stecker einmal umdrehen und alles so einstellen, wie in der Dokumentation zum Board angegeben.


Das RNControlTestMega32 ist aber schon am Chip vorinstalliert, probier mal, ob die Terminalausgabe klappt. Dazu einfach die Tasten drücken und im Bascom-Terminal schauen, ob was ankommt. Kommen nur kryptische Zeichen, ist der Stecker verpolt.


Viele Grüße
ikarus_177

Zitat:

---

Ich habe das RN-Control an ein 5V-Netzteil angeschlossen

---

5V sind zu wenig für sicheren Betrieb des RN-Control!
Der Spannungsregler auf dem Board braucht rund 2V mehr als seine Ausgangsspannung - also mindestens 7 Volt sollten es schon sein.

Auch wenn das vielleicht nicht der Hauptgrund für dein Problem ist, kann es doch dazu beitragen.

Gruß, Cairol

Ich denke mich dunkel dran erinnern zu können das das auch bei mir
am Anfang ein Problem war.

Auch ich hatte 5V dran und das war zu wenig :-(
Ich Arbeite immer mit 9V :-)

/Glacier

Hallo,

leider war die letzte Zeit recht stressig, so dass ich erst jetzt dazu komme mich wieder zu melden ;)
Besten Dank für die Tips, ich betreibe mein RN-Control nun mit 9V ... und siehe da - die Kommunikation scheint zu klappen.
Der MCS Bootloader scheint das Compilat aufs Control übertragen zu können wie ich dem Fortschrittsbalken, der nun erscheint, entnehmen kann.
Leider scheint trotzdem nicht alles zu funktionieren .... wenn ich das RN-Control einschalte (also Strom draufgebe), dann gibt es immer einen "Dauerton" (eher sehr schnell wiederholte Einzeltöne) von sich, der nach gut 10 Sekunden aufhört. Unmittelbar nach erfolgreicher Datenübertragung bekomme ich auch einen Dauerton (der allerdings höher ist) von etwa 10 Sekunden, dann 2 oder 3 Sekunden Pause, dann wieder den als erstes beschriebenen Dauerton.
Ich weiss nun leider nicht ob es sich hierbei um eine Fehler- oder Erfolgsmeldung handelt, auf jeden Fall scheint das aufgespielte Programm nicht zu funktionieren.
Ich habe das Testprogramm "RNControlTestMega32" soweit beschnitten, dass nun (ohne vorherige Tasteneingabe) das Lauflicht 10 mal über die LEDs wandern sollte .... was leider nicht passiert :(
Auf dem Terminal (von der Bascom-Entwicklungsumgebung) bekomme ich leider überhaupt keine Ausgaben, somit vermag ich nicht zu sagen ob mein Programm wirklich am RN-Control angekommen ist.

Welches weitere Vorgehen würdet ihr mir nahelegen um doch noch mein begehrtes Lauflicht zu bekommen ?
Gibt es Diagnosemöglichkeiten für die Kommunikation per RS232 ?

Besten Dank schonmal !

Grüsse, DaSumpf

Hallo DaSumpf,

Hast Du nicht das FERTIGE Board gekauft?

Zitat:

---

... Netzteil angeschlossen, prompt hat es wunderbar zu blinken und zu "schnarren" ...

---

... denn da tat sich ja schon was. Das "Schnarren" lag eben an der zu geringen Eingangsspannung. Im fertigen Board steht ja im Chip ein Test-/Beispielprogramm schon drinnen und die Fuses sind gesetzt. Daher auch dieses loslaufen. Also bei mir hatte das alles gut funktioniert.

Hast Du die "Betriebsanleitung" für das Board gelesen? Die kommt ja auf der CD mit. Darin sind die einzelnen Funktionen des Testprogramms erklärt. Mir ist auch nicht verständlich, warum Du Dir den Bootloader erst aufspielst. Denn der wurde ja bereits mitgeliefert. Und den aufzuspielen ist vielleicht für einen Anfänger nicht soooo pfiffig, da muss man spezielle Fusebits für die Bootloader-Adressen setzen und so. Und die dann wieder zurücksetzen.

Zitat:

---

Zitat von DaSumpf

... Gibt es Diagnosemöglichkeiten für die Kommunikation per RS232 ? ...

---

Klar - das Testprogramm auf dem fertig programmierten M32 sendet an das Terminal einen Begrüßungstext (siehe dazu Doku).

Andererseits klingt Deine Fehlerbeschreibung danach, als hättest Du auf Deinem Controller noch den internen Takt gesetzt.

Vorschlag: lies doch mal den Inhalt Deines Controllers aus. WENN noch das Testprogramm drin steht, dann sollte der Code in den ersten acht Zeilen wie folgt lauten:

Code:

---

:100000000C942A001895000018950000189500001F
:10001000189500001895000018950000189500002C
:10002000189500001895000018950000189500001C
:10003000189500001895000018950000189500000C
:1000400018950000189500001895000018950000FC
:10005000189500008FE58DBFC0E4E8E14E2E88E0E2
:100060008EBFD8E0F8E05F2EEEEFF7E0A0E6B0E05C
:1000700088278D933197E9F787E689B980E080BDBD

---

... zumindest stand das bei mir so drin....

Und wenn Du nichts lesen kannst - dann funktioniert der Prommer (noch) nicht richtig.

Viel Erfolg

Ich hab mir grad mal meinen originalen Mega32 in die RNControl montiert - da kommt folgender Text raus:

Code:

---

**** RN-CONTROL 1.4 mit Bootloader 38400 Baud *****
Demoprogramm vom 7.2.2007
Das beliebte Experimentier- und Roboterboard
Weitere passende Zusatzboards bei www.robotikhardware.de
Alle RN-Boards bei auf der Seite www.robotikhardware.de
lassen sich sehr bequem mit Bascom-Basic programmieren.
Viele Tipps und Foren zu den RN-Boards gibt es unter
www.roboternetz.de und www.rn-wissen.de

---

Zitat:

---

Zitat von oberallgeier

Hast Du nicht das FERTIGE Board gekauft?

---

Doch, das habe ich gekauft.

Zitat:

---

Zitat von oberallgeier

Hast Du die "Betriebsanleitung" für das Board gelesen?

---

Jupp, immer mal wieder um mir sicher sein zu können dass mir nichts entgangen ist ;)

Zitat:

---

Zitat von oberallgeier

Mir ist auch nicht verständlich, warum Du Dir den Bootloader erst aufspielst.

---

An dieser Stelle habe ich mich - bedingt durch meine Unwissenheit - falsch ausgedrückt. Mit "Bootloader aufspielen" meine ich die Installation des von Robotikhardware.de zur Verfügung gestellten "RN-Bootloader" auf meinen PC. Aufs RN-Control konnte ich ja noch gar nichts aufspielen, da die Kommunikation noch nicht funktionierte.

Zitat:

---

Zitat von oberallgeier

Andererseits klingt Deine Fehlerbeschreibung danach, als hättest Du auf Deinem Controller noch den internen Takt gesetzt.

---

Erklärung hierzu bitte ;)
Ich habe im Code "$crystal = 1000000" stehen.

Zitat:

---

Zitat von oberallgeier

Und wenn Du nichts lesen kannst - dann funktioniert der Prommer (noch) nicht richtig.

---

Das scheint mir aktuell am wahrscheinlichsten zu sein, ich werde in diese Richtung weiterforschen.

Zitat:

---

Zitat von oberallgeier

Viel Erfolg

---

Danke & Danke für die Antworten ! :)

Zitat:

---

Zitat von DaSumpf

Erklärung hierzu bitte ;)
Ich habe im Code "$crystal = 1000000" stehen...

---

Das erklären wir später - ja? Das Umstellen des Controllers von internen auf externen Takt geschieht mit Fusebits (so ne Art "Hauptschalter" oder eben "Sicherungen") - die IM Controller sind. Also das eben später.

Ok, Du hast also noch nix verstellt - dann sollte Dein Bord noch laufen. Dann müsste aber anfangs so ne Art "klingeln" kommen, danach leuchten ein, zwei, drei Leuchtdioden auf - und an der seriellen Schnittstelle kannst Du mit dem Terminalprogramm den eben genannten Text auslesen. Dazu die RS232 (die drei Pinne am RNControl) am PC anschliessen, Terminalprogramm einschalten, auf 9600 Baud - und lesen. Wenn nix kommt, könntest Du versuchen, den Stecker zur RNControl "umzudrehen" - also RX und TX tauschen.

Zitat:

---

Zitat von oberallgeier

Dann müsste aber anfangs so ne Art "klingeln" kommen, danach leuchten ein, zwei, drei Leuchtdioden auf ...

---

So wars am Anfang auch immer, nun habe ich seit einigen Tagen leider den weiter oben im Thread beschriebenen Effekt :

Zitat:

---

Zitat von DaSumpf

wenn ich das RN-Control einschalte (also Strom draufgebe), dann gibt es immer einen "Dauerton" (eher sehr schnell wiederholte Einzeltöne) von sich, der nach gut 10 Sekunden aufhört.

---

Während diesem "Dauerton" blinken zwei LEDs sporadisch.
Auch nach drücken des Reset-Knopfes ändert sich das Verhalten nicht .... ich hoffe nur nichts kaputt gemacht zu haben.

Danke für die Hilfe, DaSumpf

Hmm, grübel, sitzt der Quarz fest? Sind irgendwelche Kondensatoren verbogen? Schau doch mal: so sah meine RNControl im Lieferzustand aus (Link zum Bild nach einem Tag entfernt).

Es spricht einiges dafür, dass der Takt nicht stimmt: sowohl Deinen "Dauerton" als auch die blinkenden LED´s habe ich nicht. Aber ich hab keine Ahnung wie sich das selbst verstellen kann. Kannst Du den Begrüssungstext empfangen? Mit welcher Baudrate (evtl. ein bisschen spielen mit den Werten beim Terminal).

Sorry für die späte Antwort, war Rechnungen verteilen und einkaufen.

Guden!

Hab auch en Problem mit RS232 beim RN-Control v1.4.

Ich benutze den USBProg sowohl als Programmer als auch als Serielleschnittstelle (/dev/ttyACM0) indem ich gelegentlich die Firmwire wechsel.

Das bereits aufgespielte Demoprogramm hab ich mit der C-Variante überspielt.

Das Lauflicht läuft. Und das 12s lang, so wie es sein soll, denn (6*150ms+300ms)*10 = 12s.
Also stimmt die Taktfrequenz (16MHZ). 8-[

Wenn ich jetzt aba mit minicom versuch den Text zu lesen, den das RN-Control ausgibt, wenn man en paar Tasten drückt, dann bekomm ich nur irgedend en Zeichensalat.
Das 3 adrige Flachband Kabel vom USBProg zum Board ist auch nur so 20cm lang, sollte also Störungsfrei sein.

Baudrate vom USBProg ist fix 9600. Minicom hab ich mit 9600 8N1 ohne Hard- und Software Flow-Control konfiguriert. Mit KontrollerLab anstatt minicom das gleiche..

Habsch irgendwas vergessen? Oder falsch gemacht? Oder is vllt das Demoprogramm fehlerhaft?

Danke im Voraus :D

DaSumpf, versuch doch auch mal mit ner Uhr und dem Lauflicht die Taktfrequenz zu überprüfen. Ansonsten vllt mal die Fusebits überprüfen mit:
avrdude -c avrispv2 -P *PORT* -p m32 -n -v
Ich bekomm da lfuse = FF und hfuse = CA.

Mir is nochwas aufgefallen..

Wenn ich mit "make all" das Demoprogramm kompilier, bekomm ich diese Warnung:
#warning "F_CPU not defined for <util/delay.h>"

Aber das kann nicht sein, denn im Makefile steht:
F_CPU = 16000000

Wie auch immer.. ich hab dann einfach mal:
#define F_CPU 16000000UL über die Include-Anweisung von <util/delay.h> geschrieben.
Die Warnung ist nun weg, aber jetzt klingt die Begrüßungsmelodie total komisch.

Was is da los? :D

Hab mir mal die delay.h angeschaut un da steht:
#ifndef F_CPU
/* prevent compiler error by supplying a default */
# warning "F_CPU not defined for <util/delay.h>"
# define F_CPU 1000000UL
#endif

Somit wird also ein Default-Wert von F_CPU = 1000000UL definiert und ich denke mal, dass das Demoprogramm bezüglich des Sounds und vllt auch der RS232 Funktionen darauf hin abgestimmt wurde. Soll heißen, das Demoprogramm funktioniert nur korrekt wenn es mit 16000000Hz läuft aber ihm 1000000Hz angegeben werden. Vllt bekomm ich desswegen auch nur Datenmüll über RS232.