Important: notez que je vais décrire ici, non pas le design de la version 0.3.323 mais celui que je suis en train de refaire.

Voici, le schéma d'ensemble (à droite, cliquer pour plus grand) de la pile Helios.

Elle se compose de 3 couches purement logicielles:

1. En haut, la couche des standards et interfaces:
   • classes d'accès aux standards comme l'AVC, IEC61883, etc.
   • classes d'interface comme raw1394 (accès DOS aux noeuds) ou device.class permettant d'abstraire la connection physique d'un device donnés.
2. Au centre la couche qui gère tous les bus répondant à la norme IEEE1394, le coeur d'Helios. Elle donne aussi accès à une boite à outils pour créer de nouvelles classes ou pilotes HW.
3. En bas, la couche d'abstraction matérielle, les pilotes: des bibliothèques système de type device donnant à Helios l'accès au matériel¹⁾.

C'est un découpage plus poussé que ce que l'on trouve dans le commerce, permettant une grande souplesse dans le support autant applicatif que matériel. De plus l'API fournie sera limitée à nombre réduit de fonctions, essentiellement basé sur les tags, permettant une évolution d'Helios sans provoquer une charge d'adaptation aux applications.

C'est un modèle qui permet d'abstraire le matériel qui va implémenter l'IEEE1394. Dans le schéma d'exemple précédent, on montre l'utilisation d'un pilote OHCI: l'OHCI normalise un bus IEEE1394 sous forme de chipsets accèssibles sur un bus PCI et utilisant des DMA pour le transfert de données entre le chipset et la mémoire. Le pilote oci1394.device va donc ici scanner le bus PCI, trouver les chipsets implémentant l'OHCI1394 et permettre à la couche de gestion des bus série 1394 (SB) les transferts de données. Cette dernière ne sais pas que c'est les infos viennent par un bus PCI, elle ne sais pas non plus que des accès DMA sont fait. Elle ne sait que gérer des paquets au format IEEE1394 (et pas OHCI donc), ainsi gérer le protocol IEEE1394 serial bus (qui est le noeud root, gestion des flux isochrones, …), en faite il ne fait que de voir la partie logique décrite dans la norme IEEE1394.
L'ohci1394.device lui sait où et sous quelle forme finale il faut mettre toutes ces informations. Ainsi on peut imaginer un pilote serial1394.device qui fait passer les flux IEEE1394 sur une ligne RS-232²⁾.

Vient ensuite dans ce modèle la séparation avec la couche protocoles haut-niveau. Sur mon exemple j'ai représenté une classe AVC et une classe IEC61883. Une multitude d'autres classes peuvent venir ici, comme la classe-interfaces device.class qui permet de tracer, génération après génération, un device 1394 (un scanner par exemple) ayant un GUID définis, permettant du coup de savoir où se trouve ce device sur l'arbre du bus après plusieurs reset du bus, voir sa compléte modification.

On remarquera sur le schèma que les applications non pas accès directement à l'helios.library: elles doivent passer par les classes. Cela permettant d'avoir une API claire et unique pour les applications. Si une application doit effectuer des opérations simples sans protocole particulier, comme l'envois d'un paquet IEEE1394, elle passera par la classe raw1394. L'accès à la bibliothèque Helios est réservé aux programmeurs des classes.³⁾

Helios possède uniquement une API s'utilisant en langage C. Celle-ci se base sur l'API de MorphOS 1.4.x.
Se reporter aux documentations de développement sous MorphOS pour savoir comment installer et utiliser un environement de développement.

Quelques notes sur l'API d'Helios:

• Includes, libs, …: l'archive d'Helios vient avec un répertoire SDK contenant le matériel nécessaire au developpement en C ;
• Tags: Helios se réserve les valeurs suivantes pour le champ ti_Tag dans l'utilisation de la structure TagItem: [8E71000016 .. 8E71ffff16].