Behavior Tree et Arduino, la suite

Comme j'ai peu de temps à mettre sur le projet, le code n'est pas encore terminé mais la structure principale est là. Cependant, avec le peu de RAM d'un Arduino UNO, il est impératif de pouvoir utilisé un mécanisme de proxy et de désérialisation au besoin. Il y a donc un type de noeud "proxy" qui désérialise lorsque demandé d'être exécutée et détruit les sous-éléments lorsque le résultat de l'enfant est disponible ( fail ou success ). 

Une étape plus loin serait de permettre une gestion de priorité et retirer une sous-structure si elle est jugée moins importante qu'une nouvelle devant être instanciée. La structure courante d'un nœud de l'arbre est la suivante:

class BehaviorTreeNode
{
public:
  int data;
  byte type;
  byte state;
  byte child;
  byte next;
};

Il y a donc 255 sortes de nœuds possibles, le state identifie si le nœud est running, fail, success ou encore non touché ou peut être remis dans le pool de non utilisé.Il serait possible d'utilisé 4 bits pour l'état et les 4 autre pour 16 niveaux de priorités.

Je veux permettre d’interrompre le parcours de l'arbre après un certains délais, et reprendre au prochain "tick", ce qui en ferai un type de système multitâche préemptif. Cependant, si des sections complète de l'arbre peuvent disparaitre en plein milieu de l'exécution, il faudra y faire bien attention.

Autres contraintes, un arbres est limité à 255 nœuds, quoi que trop pour la RAM d'un UNO, pourrait être utile pour un MEGA ou Zero. Aussi, il n'y a que 16 bits pour l'encodage des données. Soit deux 8 bits ou un entier. Les 8 bits utilisés pour l'indice de l'enfant pourrait être utilisés comme valeur temporaire pour une tâche n'ayant pas d'enfant mais devrait être refléter dans le state.

En passant, comme pour utiliser les données en Flash sur un UNO il est nécessaire d'utilisé la directive progmem et le méthodes de la famille des pgm_read_word_near, il y aura deux méthode pour la désérialisation, peut-être même trois si je décide de supporter les cartes SD. La version Flash pour microcontrôleur ARM ( SAMD ), ne fera que pointer version la version en RAM puisque les ARM peuvent adressé directement la Flash et n'a besoin que de lecture seule.

Ceci dit, avant d'implémenter de nouveau concept, je vais terminer la version de base. Il me reste quelques méthodes de parcours puis je pourrait commiter.