doppelter widersprüchlicher Zugriff auf MotorPins durch 2 konkurr. pthread Tasks?

[HaWe]

hallo,
ich bin noch dran an meinem Raspi-Robot, der per BT Fernbedienung gesteuert wird.
Um eine BT-Unterbrechung zu registrieren, läuft ein Heartbeat-Signal von der Fernsteuerung zum Robot, das vom Raspi detektiert wird.
Nur bei intakter Verbindung ( _REMOTE_OK_ == TRUE ) dürfen dann Motor-Aktionen erfolgen.
Die Motorsteuerung läuft über L293-kompatible H-Brücken.
Die Motor-API ist diese:

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

#define motorCoast(nr) motorOn(nr, 0) // alias for motor coast

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

void motorBrake(int nr, int dirpwm) { // brake by pwm power
int pwm;

pwm = abs(dirpwm);

digitalWrite(motor[nr].pind1, HIGH);
digitalWrite(motor[nr].pind2, HIGH);

motor[nr].dirpwm = pwm;
softPwmWrite(motor[nr].pinpwm, pwm); // brake power always > 0

}

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

void motorOn(int nr, int dirpwm) { // motor On (nr, dir_pwm)
int dir, pwm; // signed pwm:

if(dirpwm > 0) dir = +1; // pwm > 0: forward
else if(dirpwm < 0) dir = -1; // pwm < 0: reverse
else dir = 0; // pwm = 0: coast

if (!_REMOTE_OK_) dirpwm=0; // <<<<<<<<<<<<<<
pwm = abs(dirpwm);


if(dir> 0) {
digitalWrite( motor[nr].pind1, HIGH);
digitalWrite( motor[nr].pind2, LOW);
}
else
if(dir==0) {
digitalWrite( motor[nr].pind1, LOW);
digitalWrite( motor[nr].pind2, LOW);
}
else {
digitalWrite( motor[nr].pind1, LOW);
digitalWrite( motor[nr].pind2, HIGH);
}
motor[nr].dirpwm = dirpwm;
softPwmWrite( motor[nr].pinpwm, pwm);


}
Man sieht: motorOn ist nur möglich, wenn die Heartbeat-kontrollierte Variable _REMOTE_OK_ auf TRUE gesetzt ist.

Das Problem ergibt sich jetzt aus der nächsten geplanten Erweiterung, einem MT-"Behaviour" Setup per Subsumption-Architektur.

Hier kann man es nicht restlos ausschließen, dass ein Task einen Motor anschaltet aufgrund falscher Environment-Daten oder weil er sich in einer Endlosschleife aufgehängt hat, und so die Motorpins auf HIGH zieht.
Auch in diesen Fällen muss ein Abschalten per Heartbeat-Semaphore oder einer anderen "EMERGENCY_STOP" Bedingung möglich sein, um unkontrolliertes Verhalten zu verhindern.

Was passiert nun, wenn ich per Heartbeat-gesteuertem Zusatz-Thread alle Motor-Pins auf LOW schalte, währenddessen der fehlerhafte Thread sie auf HIGH zieht?


void* thread99Go (void* ) { // EMERGENCYSTOP WATCHER
while(1) {
if(!_REMOTE_OK_) {
motorCoast[0];
motorCoast[1];
//...
}
}
return NULL;
}

Ist dann ein Kurzschluss zu befürchten?

ich will es nicht einfach ausprobieren, um den Raspi nicht zu beschädigen.

[Searcher]

Die Motorsteuerung läuft über L293-kompatible H-Brücken.

Was passiert nun, wenn ich per Heartbeat-gesteuertem Zusatz-Thread alle Motor-Pins auf LOW schalte, währenddessen der fehlerhafte Thread sie auf HIGH zieht?
Ist dann ein Kurzschluss zu befürchten?

ich will es nicht einfach ausprobieren, um den Raspi nicht zu beschädigen.

Nach Datenblatt kann jede logische Kombination an den Eingängen eines L293 angelegt werden, ohne das es zu einem Kurzschluß innerhalb des L293 kommt.

Ob es da zu anderweitig zu einem Kurzschluß kommen kann, könnte man anhand eines Schaltplans besser beurteilen.

Innerhalb des Raspis auf einem Ausgangsportpin kommt es sicherlich auch nicht zu einem Kurzschluß durch ein Programm.

[HaWe]

hallo,
nein, das Problem ist nicht der L293, da habe ich keine Angst, sondern der Raspi selber!
Hier schaltet möglicherweise der Task A den pin BCM12 auf HIGH und (gleichzeitig) ein anderer Task B denselben pin BCM12 auf LOW.

Da der Raspi 2 ein quadcore ist, ist es u.U sogar "echt gleichzeitig" möglich, nicht nur pseudo-gleichzeitig per unterschiedliche scheduler time-slices.

Da liegt der Hund begraben... :-/

wenn diese Aussage allerdings 100% sicher ist

Innerhalb des Raspis auf einem Ausgangsportpin kommt es sicherlich auch nicht zu einem Kurzschluß durch ein Programm.

dann wäre alles gut! :)

[Mxt]

Da der Raspi 2 ein quadcore ist, ist es u.U sogar "echt gleichzeitig" möglich, nicht nur pseudo-gleichzeitig per unterschiedleiche scheduler time-slices.

Auch auf Mehrkernprozessoren gibt es Dinge, die nicht gleichzeitig passieren dürfen. Da sorgt aber schon die Hardware dafür, dass das nicht passiert.

[HaWe]

alles klar dann -
2 Stühle, 1 Meinung...: :D
da bin ich jetzt beruhigt 8-)
Ich machs dann mit meinem extra-Emerency thread, der im Ernstfall alle pins auf LOW zieht!

Danke an euch! 8-)