Riot: 6TiSCH non pris en charge dans RIOT

Créé le 2 févr. 2020  ·  5Commentaires  ·  Source: RIOT-OS/RIOT

Actuellement, RIOT ne prend pas en charge le 6TiSCH, qui est l'adaptation de 6LoWPAN sur 802.15.4 TSCH (saut de canal à créneaux temporels), qui est annoncé comme une grande amélioration par rapport au 6LoWPAN à canal fixe. Ce problème suit les étapes globales nécessaires dans RIOT pour exécuter 6TiSCH.

  • [ ] #4858 : Prise en charge de la version 2 de la trame IEEE 802.15.4
  • [ ] Prend en charge la procédure d'assemblage 6TiSCH
  • [ ] Prise en charge de la transmission de trames à créneaux horaires
  • [ ] ...

Meta : Étant donné que 6TiSCH est un sujet très recherché qui revient régulièrement dans les discussions 6LoWPAN, quelque chose de consultable sur le Web devrait refléter l'état des choses ici. (Au moment de la rédaction, les recherches de riot et 6TiSCH donnent des liens vers des présentations obsolètes, des bibliothèques externes mentionnant l'intégration d'OpenWSN et similaires).

network tracking

Commentaire le plus utile

Je travaille actuellement sur le portage d'OpenWSN dans RIOT en tant que pkg. L'approche initiale que je prends sera de prendre toute la pile. Dans # 8570, il n'a été pris que jusqu'à udp , mais depuis que la procédure de jointure a été ajoutée, il existe une dépendance matérielle à OpenWSN coap, cela devra d'abord être ajouté.

J'espère pouvoir ouvrir un premier PR à ce sujet dans la semaine ou les deux prochaines.

Tous les 5 commentaires

Je travaille actuellement sur le portage d'OpenWSN dans RIOT en tant que pkg. L'approche initiale que je prends sera de prendre toute la pile. Dans # 8570, il n'a été pris que jusqu'à udp , mais depuis que la procédure de jointure a été ajoutée, il existe une dépendance matérielle à OpenWSN coap, cela devra d'abord être ajouté.

J'espère pouvoir ouvrir un premier PR à ce sujet dans la semaine ou les deux prochaines.

L'approche initiale que je prends sera de prendre toute la pile.

Autant que je sache, un nœud racine RPL est requis dans OpenWSN pour lancer la planification du réseau. Cependant, son implémentation dans OpenWSN est divisée en deux composants logiciels. L'un d'eux s'exécute sur le nœud intégré, envoie des balises et annonce les préfixes IPv6. Avec #8570 et ses successeurs, cela a bien fonctionné. Le deuxième composant traite du routage mais il s'exécute dans un outil python sur votre machine qui se connecte au nœud intégré via openserial (un UART personnalisé). Comment comptez-vous gérer cela ?

Le deuxième composant traite du routage mais il s'exécute dans un outil python sur votre machine qui se connecte au nœud intégré via openserial (un UART personnalisé). Comment comptez-vous gérer cela ?

J'utilise actuellement openvisualizer , et je n'ai pas de support pour les nœuds racine RIOT, je n'ai pas non plus réussi à ce que openserial fonctionne correctement sur les nœuds RIOT.

Le PR initial nécessiterait un nœud racine OpenWSN...

13824 est fusionné donc peut-on considérer celui-ci comme résolu ?

@aabadie Je pense que la prémisse de ce problème est abordée.
Pour mettre mes deux sous, il pourrait toujours être souhaitable d'écrire des couches inférieures fournissant 6tisch pour gnrc ou d'éviscérer openwsn pour activer gnrc par-dessus. Enfin pour fournir une option RIOT uniquement, sans nœud racine rpl spécifique à openwsn.
Quoi qu'il en soit, je suis d'accord que ce PR devrait pour l'instant résoudre ce problème.

Cette page vous a été utile?
0 / 5 - 0 notes