Hallo

Es ist der aktuellste Thread, weil es der einzige ist.

Vielleicht die Antwort auf die zweite Frage zuerst: Wenn man die Interrupts ausschaltet, wird die ISR für sleep() nicht mehr aufgerufen.

In der Lib für die Base findet man folgende ISR: Externer INT0 und INT1 für die Encoder, INT2 fürs ACS, Timer1_comp als Zeitgeber für sleep() und die Stopwatches, Power-on-Warnung und die Motorregelung. Letztlich noch die Timer2_comp für die ACS-Impulse. Da die IR-Kommunikation blockierend ist, können wir das ACS als Störquelle ausschließen. Wenn dann noch die Antrieb stören sollten, könnte man die auch kurz anhalten. Eine kleine Verzögerung bei den sleep()s stört aber nicht wirklich:

Zu 1: Die Bitdauer bei 2400 Baud ist 417µs, sleep(1) dauert 100ms. Ähnlich wie bei Himmel und Hölle haben wir zehn Felder hintereinander (Start-, 8 Daten und Stopbit) mit je 417 Länge und wir müssen so durchspringen, dass wir jedes Feld genau einmal treffen. Einzige Einschränkung: Wir haben nur 100er als Sprungweite. Beim ersten Sprung mit 300 trifft man das dritte Viertel (im Abstand von 300 von der Vorderkante) des Startbits und alle weiteren mit 400 treffen dann die einzelnen Datenbits. Da die Feldlänge aber nicht unseren Sprungweiten entspricht, landen wir mit jedem Sprung um den Unterschied (hier 17) kürzer. Das summiert sich dann auf 11*17 und ist weniger als die 300 die wir zu Beginn noch Abstand zum Feldanfang hatten. Verwirrt? Ich auch.

Bei 1200 Baud beträgt die Bitdauer 834µs. Durch einfaches Verdoppeln der Werte würde sich dann sleep(6) als Startverzögerung anbieten und sleep(8) zum Weiterspringen. Da man mit sleep(8) aber auch noch mit 34µs reserve auf das Startbit treffen würde, wäre sleep(7) als Startverzögerung wohl optimal.

Um nun nochmals auf die Interrupts zurückzukommen: Da die sleep()s eh nicht genau in die Feldlänge passen, stört eine kurze Verlängerung der Verzögerung durch die Ausführung einer ISR nicht.

Gruß

mic

Der Trick mit Sleep() ist schon alt:
https://www.roboternetz.de/community...597#post444597