Problem mit der Integration des RP6 Sensor Board

[Jumptime]

Hallo,
ich habe offensichtlich ein Zuordnungsproblem:
Nachdem ich mich ein wenig :mad: über die SW von Arexx für das RP6 Sensor Board geärgert habe, fand ich zum Glück den Artikel im http://rn-wissen.de/wiki/index.php/RP6_Sensor_Board_und_Xtra_Module. Mit diesem konnte ich dann das Sensorboard testen. Das Beispielprogramm funktionierte ohne größere Probleme. :p Vielen Dank an den Autor Dirk.
Nun wollte ich das Sensorboard in eine eigene Anwendung integrieren:

// Includes:
#include "RP6I2CmasterTWI.h" // I2C Master Library
#include "RP6M256_Erweiterung.c" // für den Roboterarm alt
#include "RP6M256_Sensor_BoardLib.c"

Plötzlich bekomme ich eine Fehlermeldung in der: RP6M256_I2CMasterLib.h und zwar:

In file included from Roboter.c:46:
./../RP6Lib/RP6M256_I2CMasterLib.h:238: error: expected identifier or '(' before numeric constant
./../RP6Lib/RP6M256_I2CMasterLib.h:239: error: expected ';' before 'uint8_t'
Roboter.c: In function 'acsStateChanged':

Der Fehler wird in folgendem Code gefunden, der nicht falsch sein kann, da er ja sonst auch funktioniert und nicht von mir ist?

union
{
uint8_t byte; //unit8_t byte;
struct
{
uint8_t LEDsR:3;
uint8_t LEDsL:3;
uint8_t reserved:2;
};
struct
{
uint8_t LED1:1; // und zwar in dieser Zeile
uint8_t LED2:1;
uint8_t LED3:1;
uint8_t LED4:1;
uint8_t LED5:1;
uint8_t LED6:1;
uint8_t reserved1:1;
uint8_t reserved2:1;
};

Natürlich kommen daraufhin weitere Fehlermeldungen.
Kommentiere ich #include "RP6M256_Sensor_BoardLib.c" aus, ist alles gut?

Hat jemand einen Tipp?
Vielen Dank im Voraus.

[Dirk]

Hi,

wenn du die Lib für das Sensor Board in anderen Projekten benutzen willst, must du nicht die Lib Source (.c), sondern den Header (.h) inkludieren:
#include "RP6M256_Sensor_BoardLib.h"

[Jumptime]

Danke Dirk, aber

dann kommt dass:

Compiling: Roboter.c
avr-gcc -c -mmcu=atmega2560 -I. -gdwarf-2 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=Roboter.lst -I./../RP6Lib -I./../RP6Lib/RP6control_M256_WIFI -I./../RP6Lib/RP6common -I./../RP6Lib/RP6control_M256_WIFI/sdc -std=gnu99 -MD -MP -MF .dep/Roboter.o.d Roboter.c -o Roboter.o
In file included from Roboter.c:46:
./../RP6Lib/RP6M256_I2CMasterLib.h:238: error: expected identifier or '(' before numeric constant
./../RP6Lib/RP6M256_I2CMasterLib.h:239: error: expected ';' before 'uint8_t'
Roboter.c: In function 'acsStateChanged':
Roboter.c:413: error: expected identifier before numeric constant
Roboter.c:414: error: expected identifier before numeric constant
Roboter.c:415: error: expected identifier before numeric constant
Roboter.c:416: error: expected identifier before numeric constant
make: *** [Roboter.o] Error 1

Daher bin ich ja ein wenig verzweifelt, denn die Fehlerausgabe ist die gleiche, halt nur aus der *.h?

Gruß
Kai

[Dirk]

Hi Kai,

das Problem könnte ein Syntax-Fehler irgendwo in deinem Hauptprogramm sein.
Manchmal reicht eine fehlende Klammer oder ein fehlendes ;

[Jumptime]

Danke, dann muss ich mich wohl auf die Suche mache.

Gruß Kai

[Jumptime]

Hi,

ich muss doch nochmal fragen:
Ich habe nach einigen Tests und langem suchen wieder das Original RP6M256_12_WIFI_REMOTE_2.c Programm in den Bot geladen, ohne Sensorboard. Alles ok, so wie es sein soll.
Dann die #include "RP6M256_Sensor_BoardLib.h" ins Programm eingefügt, die o.g. Fehler einfach auskommentiert, sind ja nur die StatusLED (die offenbar mit der Deklaration in der SensoboardLib nicht klar kommen) Programm läuft.
Jetzt das Sensorboard, eigentlich nur den XBUS angeschlossen, keine Reaktion auf die Bumper und den ACS ???????????????????

Hat jemand diesen Fehler ebenfalls und ggf. gelöst?
Ihr würdet mir wirklich weiterhelfen.

Gruß Kai

[Dirk]

Das Problem ist, dass LED1..LED6 in der RP6M256_Sensor_BoardLib anders definiert sind als in der RP6M256_I2CMasterLib.

Ich habe deshalb in den RN-Wissen-Artikel zum RP6 Sensor Board eine neue Version 1.1 (http://rn-wissen.de/wiki/index.php/RP6_Sensor_Board_und_Xtra_Module#RP6_M256_WiFi:_Se nsor_Board_Library) eingestellt, die jetzt kompatibel zur I2CMasterLib ist.

[Jumptime]

Na vielen Dank!
die StatusLED funktionieren. Welche Änderungen du in der neuen Version vorgenommen hast schaue ich mir später an.
Auch mit den Adressen im I2C-Bus muss ich mich nochmal beschäftigen, denn ich hoffe das daran der Fehler der nicht erkannten Sensoren der Basis (Bumper, ACS) liegt.

Gruß Kai

[Dirk]

Hi,

Auch mit den Adressen im I2C-Bus muss ich mich nochmal beschäftigen, denn ich hoffe das daran der Fehler der nicht erkannten Sensoren der Basis (Bumper, ACS) liegt.
Dass das Programm nicht auf Bumper u. ACS reagiert, kann daran liegen, dass der I2C-Slave auf der RP6v2 Base nicht läuft.
Das passiert z.B., wenn du das ganze System (RP6v2, M256 WiFi, Sensor Board) über WiFi startest.
Dann wird u.U. das I2C-Slave-Programm auf der Base nicht mit gestartet.
Probier mal, das System über den Start-Button auf dem RP6v2 Mainboard zu starten.

[Jumptime]

Hi,
die Idee hatte ich auch schon. Aber die StatusLEDs auf der Base blinken aber beim Start bzw. der Initialisierung, so dass ich glaube, dass das I2C-Slave-Programm schon gestartet wird. Wenn ich das Sonsorboard am XBUS nicht anstecke funktionieren die Sensoren. Erst wenn das Sensorboard am XBUS ist, werden diese ausgebremst. Einen Adresskonflikt war mein erster Gedanke, aber der scheint nicht vorzuliegen, das Verbindungskabel habe ich auch schon gewechselt. Ich werde mal noch ein wenig rumexperimentieren. und sollte ich nicht weiter kommen melde ich mich wieder. Finde ich die Lösung melde ich mich auch! Ach ja, dein Testprogramm funktionierte ohne Probleme.

Gruß Kai

[Jumptime]

Hi,

ich muss nochmal nachbohren. Ich komme einfach nicht weiter.
Das Problem: wenn ich das Sensor Boards am XBUS anstecke funktionieren das ACS und die Bumper der Base nicht mehr. Alle Platten auf evtl. Lötbrücken gecheckt. Verschiedene Beispielprogramme geladen und des Sensor Board angeschlossen. Das Testprogramm für das Sensorboard funktioniert. Ach kommen Daten vom Sensorboard zur M256 durch.
Beim Beispielprogramm:
Example_06_I2CMaster - keine Fehler erkennbar
Example_07_I2CMaster - „I2C ERROR – TWI STATE: 0x20“ – kein ACK auf write?
Example_08_I2CMaster - ACS Status wird nicht mehr ausgegeben
Example_09_Move - kommt dann die Fehlermeldung „I2C ERROR – TWI STATE: 0x“ ohne Nummer
So zeiht sich das durch. Leider weis ich nicht wie ich auf das fehlende "acknowledge" reagieren soll. Soweit gehen meine Kentnisse leider nicht.
Es macht auch keinen Unterschied, ob ich versuche zu initialisieren:
I2CTWI_initMaster(100);
I2CTWI_setRequestedDataReadyHandler(I2C_requestedD ataReady);
I2CTWI_setTransmissionErrorHandler(I2C_transmissio nError);
sensor_board_init();
oder nicht.
Bin Ratlos - benötige Tip.

Gruß Kai

[Dirk]

Hallo Kai,

ich habe leider keine Zeit, das alles zu probieren. Du bekommst offenbar Lesefehler auf dem I2C-Bus.

Bindest du die Lib nur ein und initialisierst sie (mit sensor_board_init) oder nutzt du auch noch weitere Funktionen der Lib oder Ausgaben des Demoprogramms für deine Tests?

[Jumptime]

Hallo Dirk,


ich habe leider keine Zeit, das alles zu probieren, kann ich verstehen.
Bisher habe ich nicht direkt die Sensoren versucht auszulesen. Beim Demoprog. Example_08_I2CMaster glaub ich brachte der Front Sharp an ADC 0 der Base brauchbare Werte, auch als das ACS und die Bumper nicht gingen.
Ich habe jetzt dein Demoprogramm mit dem Example_12_WIFI_REMOTE_2 kompiniert:
29099

29100
Die Temperaturwerte sind ok (nicht geeicht) die RTC zählt, der Gyro schwankt, der Compass ändert sich jedoch nicht. :confused:

Ich werde meinen Verdacht jetzt mal auf den Slave richten.

Gruß Kai

[Jumptime]

Hallo Dirk,

ich muss dich nochmals bemühen. Ich bin nur ein kleines Stück weiter gekommen.
Die Fehler auf dem I2C Bus entstehen wahrscheinlich, weil die Interruptleitung INT1 nicht mehr getaktet werden kann, warum auch immer.
Aber von vorn: Base als Slave, in der M256 Wifi (z.B.) das Beispielprogramm RP6M256_07_I2CMaster.hex.
Per WLA startet die Base nur jedes dritte oder vierte mal richtig. (wie du bereits sagtest)
Per Start/Stop-Taster klappt wiederum nur ab und an eine WLAN-Übertragung.
Aber es ist immer ein Tackt auf dem INT1 mit einem Logiktester zu messen, der sich ändert, wenn das ACS oder die Bumper ansprechen, ok.
Ist das Sensor-Board angeschlossen tut sich nichts - egal ob es nur angesteckt ist oder per SW initialisierst ist (sensor_board_init)?
Die INT1 wird nicht nach H oder L gezogen.
Habe ein zweites Board bereits getestet - also es ist bestimmt nicht defekt. Hast du eine Idee?

Habs nämlich langsam satt. :mad:

Aber mal was anderes, wie lassen sich eigentlich die Jumper (J1 - J5) öffnen, nur durch löten?


mfg
Kai

[Dirk]

Hi Kai,

Die Fehler auf dem I2C Bus entstehen wahrscheinlich, weil die Interruptleitung INT1 nicht mehr getaktet werden kann, warum auch immer.
Zumindest kann nicht sicher auf die Ereignisse reagiert werden.
Leider verwendet das Sensor Board gnadenlos alle INTs des XBUS.
XBUS INT1 -> LSM303DLHC: INT1
XBUS INT2 -> MAX7311: INT_N
XBUS INT3 -> DS1339: SQW/INT_N und LSM303DLHC: INT2

Der Base I2C-Slave und alle I2C-Master (M32, M128, M256 WiFi) nutzen XBUS INT1 für das Signalisieren von akuten Ereignissen.


Was man machen könnte:

a) Den 0-Ohm-Widerstand J3 auf dem Sensor Board auslöten (J3 öffnen). Damit ist INT1 wieder frei für die anderen Boards und die I2C-Master-Slave-Demos müßten wieder funktionieren. Du kannst den 0-Ohm-Widerstand ja aufbewahren, so dass das Ganze umkehrbar ist.

b) Wenn du nicht gern am Sensor Board löten willst, könnte man am Flachkabel, das den XBUS des RP6 mit dem Sensor Board verbindet, die Ader 8 unterbrechen,- das hätte denselben Effekt.

c) Soweit ich mich erinnere, kann man die INTs des LSM303DLHC frei programmieren. Lies mal das Datenblatt. Möglicherweise gibt es eine Konfiguration, die den INT1-Pin des LSM303DLHC hochohmig läßt und keine INT-Signale produziert. Dann bräuchte man a) oder b) nicht.

Berichte doch mal, was bei dir funktioniert hat.

[Jumptime]

Danke Dirk.

Kabel zerlegen ohne ein neues zur Hand - nicht mein Ding.
Ich habe mich für das Auslöten von J3 entschieden. Das man so etwas Jumper nennt war mir neu. Ich hatte gestern schon den Gedanke, hab mich nur nicht getraut. Damit funktionieren die I2C Master-Slave-Demos. :p
Die Sensoren können ausgelesen werden während der Bot im "behaviourController" sich bewegt. Mehr wollte ich gar nicht.
Ob der Interrupt vom LSM303DLHC benötiget wird, werde ich sehen. Denn das mit dem Hochohmig schalten und das mit dem Daten(blatt)buch :confused:


Also nochmal Danke
damit sollte sich dieser Thread erledigt haben.
Kai