Absender: Timo Sandmann
Datum: Di, 02.09.2008 17:44:24
In-reply-to:
<48BD5849.4060801@xxxxxxxx>
References:
<F8BEDEFE-0A85-4D2E-A348-3DDAA4D80615@xxxxxxxxxxxxxxx> <48BD5849.4060801@xxxxxxxx>
Hi, Am 02.09.2008 um 17:14 schrieb Benjamin Benz:
Hi,Der Zweck klingt logisch und es wäre sicher auch intuitiv, wenn man sich nicht Gedanken darüber machen muss, wer gerade sonst noch was benutzt.MAn müsste eigentlich auch nur dem Verhalten nen Pointer auf Platz für seinen eigenen Stack mitgeben ...
ne also ich meinte jetzt nicht, dass die Verhalten parallel ablaufen, sondern dass es einfach nur mehrere Einträge für ein Verhalten in der Verhaltens-Liste gibt. Den Stack organisiert dann einfach weiterhin der Compiler, ein Problem sind nur die globalen Daten des Verhaltens. Die würde ich in ein struct packen und switch_to_behaviour() könnte einen Zeiger auf den Eintrag in der Liste zurückgeben. Jetzt bekommt Behaviour_t noch einen void-Zeiger spendiert und dann kann die Botenfunktion nach dem switch_to für ihr struct Speicher anfordern und die Adresse in den Zeiger in Behaviour_t speichern. Die Verhalten greifen dann einfach auf data->zeiger_auf_eigene_daten->... zu anstatt auf die globalen Variablennamen (das dürfte kaum Overhead haben).
Problem: Verhalten höherer Priorität müssten ihre Priorität irgendwie vererben. Angenommen bot_turn() läuft, jetzt kommt ein Notfallverhalten dran, das ein neues bot_turn() startet, dann muss das bot_turn() aufgerufen werden, dessen Aufrufer die höhere Priorität hat.
Dann stellt sich allerdings irgendwann die Frage, ob wir nicht mehr oder weniger Stück für Stück ein komplettes OS nachbauen und nur in Verhalten umtaufen ... vielleicht müsste man dann mal irgendwann überlegen, ob nicht ein tieferer Einschnitt lohnt und man tatsächlich auf ein Embedded OS umsteigt ...
Ja das hab ich auch schon mal überlegt, vor allem weil wir es für die Map eh schon haben und das auch ganz gut funktioniert, wie man am neuen Verhalten jetzt sieht. Ich glaube dafür hat der ATmega32 allerdings zu wenig RAM, das ginge dann nur mit ATmega644 und wäre nicht mehr zum alten Verhaltenscode kompatibel.
--> irgendwann ct-Bot-Framework V2? Timo