[Botix-devel] Re: FW: Botix, weer een stapje verder..:)

[Ger A. <in...@ge...>]

Just4 Fun schreef:

> Hoi Ger,
>
>> =>De registry.h (of main.c) moet niet per persoon, of zelfs maar per 
>> per bot instelbaar zijn, maar per controller. Een bot kan niet en 
>> hoort niet te weten over welke conrollers de functies verdeeld zijn 
>> (subsumption additivity). En of dit nou in main.c of in de registry.h 
>> gebeurt is mij om het even. Enkel zou dit betekenen dat er per 
>> controller een registry.h aangemaakt moet worden. En dat lijkt me een 
>> nog slechtere oplossing dan het 1 en ander vanuit main.c te regelen. 
>> Want als je dan een nieuwe sensor zou toevoegen dan zouden alle 
>> registry.h bestanden moeten worden aangepast.
>
>
>
> QUOTE
> in feite denk ik dat als je alle controllers binnen een bot 1 
> registry.h file geeft dat dat geen kwaad kan.
> In feite is er 2 soorten hardware:
> -Hardware aan pins van de processor
> -Hardware bereikbaar via i2c
>
> Voor de eerste soort kan 't geen kwaad om 't te registreren, als je m 
> maar niet wilt gebruiken en voor de tweede soort kan t zowiso geen 
> kwaad, want dat werkt gewoon.
> UNQUOTE
> Dit snap ik ff niet? Hoe weet iedere controller binnen een bot dan 
> welk programmas hij moet gebruiken, respectievelijk welke pins hij 
> waarvoor kan gebruiken?
>
iedere controller heeft zn eigen stukje code. Zet voor 't compileren 
even een parameter waardoor een ander stukkie code geselecteerd wordt en 
je kunt compilen en flashen. Zo houd je toch 1 codebase!

>
>
>> Als je aparte processoren aparte levels wilt laten doen kun je in de 
>> main de andere levels uitcommentarieren. Eventueel kunnen we een 
>> extra variabele toevoegen waarin wordt geregistreerd welke levels de 
>> processor moet doen. Dan hoeft voor 't compilen alleen die variabele 
>> aangepast te worden voor jou.
>> =>Het is ingewikkelder: Ik wil niet aparte layers door aparte 
>> controllers uit laten voeren, maar bepaalde AFSMs hebben een eigen 
>> controller nodig, zoals bijvoorbeeld de ontvanger van een 
>> IR-afstandsbediening. Deze moet continu op ontvangen staan en houdt 
>> dus geen tijd over voor andere processen. Een ander voorbeeld is een 
>> I2C slave. Deze moet klaar staan als een master zijn boodschap wil 
>> overzetten. Het is een wezenlijk onderdeel van subsumption dat AFSMs 
>> parallel en asynchroon lopen!
>
>
> In feite kun je grofweg 2 types controller onderscheiden:
> - per subsumption level een processor (op meerdere levels op een 
> processor)
> - een processor met een specifieke taak.
> => dit is geen OF OF verdeling. AFSMs zijn niet afhankelijk van een 
> controller, laat staan dat een layer dat is.
>
ok

>
> De laatste kun je zien als een 'black box', heeft weinig met 
> subsumption te maken. De "hardwarelibrary" is wel bruikbaar denk ik. 
> => Klopt, het is hooguit een controlstructure boven de subsumption. 
> Maar het komt wel degelijk via een AFSM het systeem in. Boevendien 
> moet ik hem wel programmeren en ik heb weinig zin om voor iedere 
> wijziging in een controller mn hele Eclips of Botix om te gaan bouwen 
> en vervolgens weer terug te moeten bouwen.

zie boven.

>
> Het komt idd dichter bij de subsumption theorie als je parallel de 
> afsms laat lopen. Maar dan moet je ook voor iedere afsm een controller 
> inzetten. Wouter, die vriend van mij, heeft plannen om multitasking te 
> implementeren op een AVR. Wellicht ook wel iets aardigs.
> => Een AVR kent uit de aard van de hardware geen multitasking. Er is 
> slechts 1 ALU en alle processen lopen via deze ALU. Het wordt dus 
> altijd iets van semi-multi-tasking (Windows 3.1 achtig). Dus, alhoewel 
> ik me graag laat verrassen, heb ik er weinig vertrouwen in dat dit ook 
> daadwerkelijk gaat lukken. Het is inderdaad zo dat je theoretisch voor 
> iedere AFSM een aparte controller nodig hebt als het model perfect zou 
> willen imlementeren. Dit was ook het hele basisidee achter 
> subsumption. De meeste subsumption apparaten werken dan ook met 
> heftige externe computers. Maar het is ook een gegeven dat des te 
> hoger de layer waarin de AFSM komt, des te minder kritisch de timing 
> is. Dit is dus waar we compromissen kunnen sluiten met de theorie. Je 
> kunt natuurlijk alles op 1 controller douwen, maar dan zal subsumption 
> nooit echt goed werken. Real/time timing is het grote probleem.

Klopt, een soort 3.1 multitasking idd. Echter, als je slechts de taken 
die echt 100% van de processortijd vergen apart zet, kun je best met een 
dergelijke multitasking uitkomen. Ik denk dat je je teveel fixeert op 
realtime, dat is vlg. mij niet noodzakelijk. Overigens, de implementatie 
van de afsms zoals ie nu in main.c staat, emuleert dat al enigszinds.

>
> Groetjes,
>
> Richard
>
>

Kun je je even aanmelden op de mailinglist en zullen we afspreken dat 
onze communicatie via deze (nog erg korte) 
bot...@li... lijst gaat? Dan worden onze mails 
gearchiveerd.

https://lists.sourceforge.net/lists/listinfo/botix-devel

Groetn,
Ger.