I/O der Base mit M32 auslesen

Hallo,

ich habe einen RP6 mit M32.

Am RP6 habe ich zwei zusätzliche hintere Bumper angebaut, die ich an IO1 und IO2 der Basis angeschlossen habe.

Auf dem RP6 läuft die RP6Base_I2CSlave. Auf dem M32 habe ich als Grundgerüst die RP6Control_10_Move2 laufen, die ich schon etwas ausgebaut habe und gern weiter verwenden möchte.

Die RP6Base_I2CSlave stellt ja viele Werte zur Verfügung, von denen ich in der M32 dann auch z.B. adc0 und adc1 zum Auslesen der Sharp-Distanz-Sensoren schon verwendet habe. Wie bekomme ich aber Zugriff auf IO1 und IO2 der Basis?

Viele Dank und viele Grüße!

Ernst

Moin,
ich habe es für die M256 gemacht, und habe daran Höhenbumper angeschlossen, vielleicht hilft es dir ja.
Wenn du noch Erklärungen brauchst melde dich.
Hier: Anhang 27787

Thorben W

Hallo Thorben,

vielen Dank für das Programm!

Wenn ich es richtig sehe, müsste ich bei mir also die RP6Control_I2CMasterLib und die RP6RobotBaseLib (.c und .h Dateien) anpassen und kann dann deinen zusätzlichen Hight Bumpers Event Handler im Hauptprogramm benutzen.

Könnte es eigentlich noch eine einfachere Möglichkeit geben, um die I/O der Basis über M32 auszulesen oder ist es generell notwendig, die Lib´s zu verändern?

Ernst

Du bindest nur die Libs ein und schreibst eine Komponente die auf Basis der Libs die entsprechende Funktionalität erfüllt. Die libs zu verändern halte ich für die denkbar schlechteste Option,

@shedepe: Ah, natürlich!

Danke, da wollte ich es mir komplizierter machen als notwendig :-)

- - - Aktualisiert - - -

@Thorben

in Deinem Beispiel sind in der RP6M256_I2CMasterLib.h die Variablen RC5Reception und RC5transmitReady auskommentiert. Hat das mit der hinzugefügten Funktion High_Bumper zu tun, d.h. gibt es nur die Möglichkeit RC5 Funktionalität oder zusätzliche Bumper? (Die RC5 Routinen benutze ich bereits in meinem Programm, auf die wollte ich nicht verzichten).

Viele Grüße

Ernst

Nein das nicht aber wenn du sie Brauchst dann musst du das Dateivormat ändern

Code:

---

// This bitfield contains the main interrupt event status bits. This can be
// read out and any Master devices can react on the specific events.
union {
    uint16_t byte;
    struct {
        uint8_t batLow:1;
        uint8_t bumperLeft:1;
        uint8_t bumperRight:1;
        uint8_t RC5reception:1;
        uint8_t RC5transmitReady:1;
        uint8_t obstacleLeft:1;
        uint8_t obstacleRight:1;
        uint8_t driveSystemChange:1;
        uint8_t hightbumperLeft:1;
        uint8_t hightbumperRight:1;
    };
} interrupt_status;

---

in uint16_t byte;
Du musst dann auch noch diese Stelle Anpassen: RP6M256_I2CMasterLib.c

Code:

---

/*****************************************************************************/

// Bitmasks for comparision:
#define MASK_ACS            0b01100000 // the ACS Status bits... 01100000
#define MASK_BUMPER        0b00000110 // Bumper bits
#define MASK_HIGHT_BUMPER    0b00011000 // Hight Bumper bits
//#define MASK_RC5              0b00001000 // RC5 Reception bit
#define MASK_BATLOW            0b00000001 // Low Voltage bit

---

Das es halt mit den Masken keine überschneidungen gibt.

Ich hoffe das hilft weiter.
Thorben W

Hallo Thorben,

danke für Deine Erklärung. Langsam verstehe ich auch die Kommunikation zwischen Slave und M32...

Was ich jetzt nicht verstehe:
Im Slave Programm wird interrupt_status verwendet und später als erstes Byte (I2C_REG_STATUS1) übergeben, in das Register-Byte passen aber doch nur 8 bits rein, im oberen Beispiel sind es aber dann 10 bits?

Viele Grüße

Ernst

Hallo Ernst,
dann musst du diese Zeile auch anpassen, du meist sicherlich diese:

Code:

---

I2CTWI_readRegisters[I2C_REG_STATUS1] =          (uint16_t)(interrupt_status.byte);

---

Ich hoffe deine Frage damit beantwortet zu haben.
Thorben W

Hallo Thorben,

es läuft :-)

Ich habe es jetzt aber doch so gemacht, das ich die Libs editiert habe, damit ich nicht ganz durcheinander komme.
Bei den zu übergebenden Registern habe ich es dann doch etwas anders gemacht (weil ich das gedanklich einfacher nachvollziehen konnte):
Bei status.byte und drive_status.byte waren noch bits frei, die ich benutzt habe. Die interrupt_status.byte habe ich so gelassen.

Von der Basis aus kümmert er sich jetzt also auch um zwei zusätzliche Bumper hinten an I0 1 und 2 sowie um zwei Reed-Kontakte an IO 3 und 4. Analog zu der originalen Lösung mit den vorderen Bumpern überträgt er das Ereignis an die M32.

Vielen Dank für Deine Hilfe!

Ernst