Hallo rossir,

da hast Du dir ja echt viel Mühe gemacht mein Testprogramm umzugestalten. Ich gebe Dir Recht, die main()-Funktion ist nun hübsch lesbar geworden.
Gut, dass Du als Stichwort Subsumption angeführt hast. Ich hatte vor Jahren (Jahrzehnte wohl eher) mal davon gehört. Aber wie es nun so ist, gerät einiges in Vergessenheit.
Deshalb habe ich auch leichte Probleme damit, wie die von Dir geschriebene wait()-Funktion sicherstellen kann, dass auch die 'Prozesse' mit der niedrigen Prio dran kommen.
Wenn ich als 'böser' Nutzer die Funktion immer nur mit wait(0); aufrufe, dann kann es doch passieren, dass die for()-Schleife nicht bis zur letzten eingetragenen Funktion kommt.
Warum lässt Du die Schleife nicht von 0 bis zur Anzahl der eingetragenen Funktionen/Prozesse laufen?
Oder sogar den Start der For-Variablen mit der letzten Prozessnummer + 1 beginnen? (Klar, am Ende wieder zur ersten Funktion.) Dann kommen auf alle Fälle alle Funktionen mindestens einmal dran.
Was habe ich noch alles vergessen zum Thema Subsumption?

Ansonsten ist die Integration in dieser Form sehr gut gelungen.


Zu Deinem Patch-3 habe ich vor allem zur Funktion adc_low.c/ReadADC() eine Frage.
Warum gibst Du dort mit "return adc >> 6;" den Wert aus adcValue[mux] geshiftet zurück?
In asuro.c/IsrStandard() holt Du die maximale ADC-Auflösung mit "sensor = ADCL | (ADCH << 8 );" und schreibst diesen Wert nach adcValue[adc_cnt]. Somit sind ja erst einmal alle Bits vom Wandler vorhanden. Und auch wenn die Genauigkeit in den unteren Bits eventuell nicht so gut ist, sehe ich keinen Grund die 6 untersten Bits dann zu eliminieren.

In asuro.c/Init() schaltest Du die Odometrie-LEDs ein. Macht ja auch Sinn, wenn der ADC gleich gestartet wird. In adc.c/OdometryData() knipst Du die Lampen auch wieder an und holst die interruptermittelten Daten. Was aber, wenn der 'böse' Nutzer dir die Lampen vorher mal ausgeschaltet hat?
Das gleiche ist auch bei der Front-LED.

Also gilt auch in Deiner Interrupt-Lösung, dass die LEDs, auch die Brems-LEDs, für die Nutzung im eigentlichen Programm tabu sind.
Ich habe für die Brems-LEDs den Ansatz, dass man sie in den Zeiten, in denen die Odo-ADCs nicht in Betrieb sind, den 'Wunsch', die Dinger zu nutzen, dazwischen schiebt. Ist aber noch nicht fehlerfrei, deshalb ist der Code im Timer noch auskommentiert.
Aber zumindest könnten sie dann in Deiner Variante für 4 von 6 ADC-Läufen einschaltbar sein.

Die Einführung vom MY_SWITCH_THRESHHOLD-define ist mir suspekt.
In switches.c/PollSwitch() interpretierst Du einen ADC-Wert größer als dieses Threshhold ja als rauschen. So weit ok.
Aber in asuro.c/IsrStandard() kann ich nicht folgen an der Stelle "switched=switched || sensor<(MY_SWITCH_THRESHHOLD<<6);".
Warum schiebst Du den 'großen' Wert von Threshhold noch mal um 6 Bit. Danach ist es so groß, dass sensor doch immer darunter liegt. Oder etwa doch nicht?


So, genug Fragen für heute.
Dieses Subsumption werde ich jedenfalls auf alle Fälle bei Dir für meine nächsten Test-Programme räubern . Sieht einfach wirklich besser aus.

Gruß Sternthaler

P.S.: Einen Regler habe ich für diesen Test bewusst nicht genutzt, da ich hier die Positionsbestimmung anhand von 'krummen' Geraden sehen will.