3.4.1d precision et suggestion de manipulation sur l’organisation des repertoires/fichiers

Bonjour,
Dans 3.4.1.c et 3.4.1.d sont présentées les possibilités des cartes avec une arborescence par architecture/famille/cpu/modele
arborescence que je ne trouve pas dans les repertoires riot/RIOT/boards
de meme dans le 3.4.1.d vous indiquez que la capacité (features) timer est indispensable or je suis allé voir le Makefile.features de la carte iotlab-m3 et il n’y a que dma
"jovyan@c642f1ef2182:~/work/iot-lab-training/riot/RIOT/boards/iotlab-m3$ cat Makefile.features
include $(RIOTBOARD)/common/iotlab/Makefile.features

FEATURES_PROVIDED += periph_dma"

pour une autre carte que je connais (teensy31) j’ai bien trouvé le timer
en revanche je n’ai pas trouvé le type de CPU qui avait été trouvée dans TP4 : stm32f1

manifestement dans la carte il y a l’include qui permet d’aller chercher les fonctions génériques qui sont dans common , donc l’architecture arborescente présentée précédemment ne correspond pas a une arborescence dans RIOT mais des include inclus dans le dossier common.

Naviguer dans les dossiers (soit par jupyter, soit en chargeant RIOT sur Github) fournirait une activité éclairante
Merci de me lire

Vous confondez les concepts de cartes et de cpu présentés dans le cours (voir les paragraphes 3.4.1b et 3.4.1c). Le concept “architecture/famille/cpu/modele” ne se traduit pas, dans l’état actuel de RIOT, en une arborescence de dossiers mais est un concept hiérarchique, visant à réduire la duplication de code à plusieurs niveaux.

Le type et le modèle de CPU présent sur la carte iotlab-m3 sont définis dans boards/common/iotlab/Makefile.features. Cette information est mise en commun car il existe 2 types de cartes IoT-LAB très légèrement différentes (iotlab-m3 et iotlab-a8-m3). Plutôt que de dupliquer le code à 2 endroits différents, ce qui le rendrait difficile à maintenir, le projet RIOT utilise des emplacements communs de ce type quand c’est possible.
Ceci est mentionné au début du paragraphe 3.4.1b.

La features timer (avec plusieurs autres) se trouve également dans ce fichier commun. Par contre seule la fonctionnalité DMA est paramétrée pour le iotlab-m3 et donc est définie dans le fichier spécifique de la carte.

La variable CPU est bien définie pour la teensy dans le fichier boards/teensy/Makefile.features. Et ce n’est pas un stm32f1 (peut-être une autre version de la carte ?) mais un microcontroleur kinetis.

De manière générale, le cours ne rentre pas dans tous les détails pour ne pas perdre le lecteur. L’essentiel est surtout de comprendre où sont les informations importantes et comment les choses s’articulent entre elles. Seuls les éléments qui doivent être connus et qui seront utilisés dans les TP sont abordés.

Il semble cependant qu’il y ait matière à améliorer le texte pour le rendre encore plus clair.

Je note également la suggestion de navigation dans les dossiers pour découvrir la base de code de RIOT. On pourrait également imaginer quelque chose de similaire pour expliquer l’organisation des TPs de ce Mooc (par example dans le notebook start-mooc.ipynb).

J’avais bien compris la différence, je pointais justement la différence entre la présentation conceptuelle purement hiérarchique, et la mise en oeuvre qui ne correspond pas (ou tres partiellement) à ce modele hierarchique. mais comme j’ai repris mon texte à plusieurs reprises il n’etait peut etre pas clair…
(j’ai pris le teensy parceque je le connaissais, mais il semble etrange a son propos qu’il n’y ait pas une “arborescence”, mutualisation avec Kinetis)

Le support de la carte en elle-même n’est pas mutualisé car c’est (pour l’instant) la seule carte de cette famille de cartes (les teensy).
Par contre, le support du cpu utilise le code générique des cpus kinetis (un seul dossier cpu/kinetis) qui pour le coup est parfaitement mutualisé dans RIOT.