|
c't Projekte - c't-Bot und c't-Sim -
Mailinglisten
[Voriger (Datum)]
[Nächster (Datum)]
[Voriger (Thread)]
[Nächster (Thread)]
[Nach Datum][Nach Thread]
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
|
|