|
 |
 |
 |
|
|
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: So, 16.12.2007 16:44:51
In-reply-to:
<20071215202121.311120@xxxxxxx>
References:
<000001c83e8a$1d59ea20$0200a8c0@mexpnew> <CD26B958-21F4-40E7-94A2-319F8E58F3A4@xxxxxxxxxxxxxxx> <20071215202121.311120@xxxxxxx>
Hallo Frank,
Am 15.12.2007 um 21:21 schrieb Frank Menzel:
Hallo,
das Speichern auf den Stack innerhalbs des Fahrverhaltens ist auch
ein kleines Verhalten, weil nur ein solches via remotecall aufrufbar
ist. Sonst reicht natürlich eine Routine.
ne, du kannst mit den RemoteCalls jede x-beliebige Funktion starten.
Ob die dann mit switch_to() ein Verhalten aktiv schaltet, ist den
RemoteCalls egal. Einzige Einschränkung ist, dass die Funktion als
ersten Parameter einen Zeiger erwartet, der dann halt auf den
Datensatz des RemoteCall-Verhaltens zeigt. Das stört aber ja nicht
weiter.
Ich habe kein Array gemacht, weil ich nicht begrenzt sein wollte.
Na ja, begrenzt ist es in erster Linie durch das kleine RAM vom Bot.
Und als Liste gehen schon 33 % des Stack-Speichers nur für die next-
Zeiger drauf, die du beim Array nicht brauchst. Hinzu kommt noch der
Speicherbedarf, den malloc() für sich braucht um den Heap zu
verwalten, pro malloc() noch mal 2 Byte, also sind 50 % des
verbrauchten Speicherplatzes Overhead.
Außerdem hatte ich auf AVR auch schon den Effekt, dass malloc()
irgendwann angefangen hat den Stack mit Daten zu überschreiben, dann
stürzt der Bot-Code natürlich entweder gleich ab, oder fängt an
sinnlose Dinge zu tun. Daher wäre ich mit malloc() sehr vorsichtig.
Zum Testen kann es sehr praktisch sein, aber endgültige Sachen lieber
statisch machen.
Besser wäre eine feste Stack-Größe und bei mehr Einträgen wird einfach
der Älteste überschrieben.
Gruß Timo
|
|
|