Irgendwie liegt hier ein Mißverständnis vor. Ob 800 oder 8000, das hat gar nichts mit der Taskpriorität zu tun, sondern ist allein ein motor_Control(..) interner Scaling Faktor für die Encoderticks pro Zeiteinheit.

Ich hätte deshalb erwartet, als ich Deinen Code testete, dass ASURO durch die Verwendung von 8000 (statt 800) ca. 10 mal langsamer fährt. Dem war aber nicht so! Nach einigem Debuggen habe ich den Fehler in motor_Control(..) gefunden. Ta wurde falsch berechnet und deshalb war die Reglung eher chaotisch und leider auch abhängig von den Nachbartasks. Hier der korrigierte Code:
Code:
int delta=100, Kp=20;  // entspricht Kp=0.2

int regel(int pwm, int e) {
	int y= (Kp * e)/100;
	pwm+=y;
	return (pwm>127)? 127 : ((pwm<-127) ? -127 : pwm);
}

int motor_Awake(int idx) {
	return Gettime()>motorTime;
}

int motor_Control(int sensor) {
	static int lpwm=0;
	static int rpwm=0;
	int l_ticks, r_ticks;
	int Ta=Gettime()-motorTime+delta;

	l_ticks=encoder[LEFT];
	r_ticks=encoder[RIGHT];
	EncoderSet(0,0); //Encoder Reset ();
	motorTime=Gettime()+delta;
	
	lpwm=regel(lpwm, leftSpeed -1240*L_DIR*l_ticks/Ta);
	rpwm=regel(rpwm, rightSpeed-1240*R_DIR*r_ticks/Ta);
		
	SetMotorPower(lpwm, rpwm);
	return 0x1;
}
Die Änderungen im Einzelnen:
1) Der Hauptfehler ist in motor_Control(..) durch folgende Zeile korrigiert:
--> int Ta=Gettime()-motorTime+delta;

2) Dadurch ist folgende Zeile in regeln(..) nicht mehr nötig:
--> y= (y>10)? 10 : ((y<-10) ? -10 : y);

3) Ausserdem kommen in 10ms nur 0 oder 1 Encoderticks zustande. Deshalb habe ich delta jetzt auf 100ms gesetzt.

4) Schlußendlich habe ich das Scaling auf 1240 ausgepingelt. (Für die 4-fach Encoderscheibe.)


Eine Gegenfrage: Für welchen unserer Task würde es Sinn machen die Priorität "nachvollziehbar" zu steuern?

Der c't-Bot fährt multi threaded, da macht es Sinn ein wenig - aber nicht zu viel - über thread Prioritäten nachzudenken.

Bei meinem Programmgerüst wird die Priorität allein durch die Reihenfolge der Einträge in actionList[] festgelegt. Vielleicht sollte man in diesem Fall besser von Tasklayern sprechen statt von Taskprioritäten. (Stichwort: Türme von Hanoi)

"weiter zu optimieren?" Klar, das geht bestimmt immer.