Problem mit der Integration des RP6 Sensor Board

[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:



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

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.

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.
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


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