3.3.4 manque d’explication

Bonjour,
Dans l’explication sur les modes d’economie d’énergie, j’ai du mal a trouver le lien entre la commande a ajouter au makefile :
CFLAGS += ‘-DPM_BLOCKER_INITIAL={ .val_u32 = 0x01010100 }’
et les commentaires : “On remarquera que, dans cet exemple, le mode 1 étant toujours bloqué, aucun mode de basse consommation ne sera activé pour un STM32. Par contre, la basse consommation fonctionnera sur un Kinetis.”
Comment peut on faire le lien entre le cflag et le mode 1 (est-ce lié aux bits 0 1 … sachant qu’il n’y a que 4 niveaux possibles), d’apres la cascade expliquée on devrait essayer les modes 4, 3, 2 avant le 1.
Merci d’avance pour les eclaircissements dans le cours.

Bonjour,

Chaque niveau correspond à un octet du champ val_u32. Si on le découpe en 4 octets (en représentation héxadécimale), on a donc:

• niveau 3: 01 (bloqué)
• niveau 2: 01 (bloqué)
• niveau 1: 01 (bloqué)
• niveau 0: 00 (débloqué)

STM32 propose 2 modes basse consommation, donc les niveaux 2 et 3 ne sont pas pris en compte. Il reste les niveaux 0 et 1. Pour STM32, le niveau 1 correspond généralement au mode STOP (avec rétention de RAM) et le niveau 0 au mode STANDBY (sans rétention de RAM, le microcontrôleur redémarre complètement au réveil, seule certaines clocks conservent leurs état, comme le RTC + certains registres de backup, mais ça dépend des modèles).
Donc si le niveau 0 est débloqué mais pas le niveau 1, le système ne bascule pas en deep sleep.

Pour les kinetis, il n’y a qu’un seul niveau deep sleep. Dond débloquer le niveau 0 suffit à passer en deep sleep, puisque les autres niveaux ne sont pas pris en compte.

Je suis conscient que ce mécanisme n’est pas le plus simple à comprendre et que le texte peut être amélioré.

Merci, sans cette explication le texte est incompréhensible.
Dans votre explication on ne decoupe pas en 4 octets, mais on découpe l’octet en 4 paquets de 2 bits.
De plus au vu de cette explication il y a une contradiction avec le fonctionnement du mode cascade dans le cours qui indique que : si le mode le plus élevé (je suppose qu’il s’agit du mode 3) est bloqué, on ne cherche pas plus loin et on reste en idle, ce n’est que dans le cas ou le mode le plus élevé est débloqué que l’on examine le mode en dessous, en suivant cette logique on n’arrivera jamais au niveau 0 puisque le 3 est bloqué, on restera en idle.
Donc le parametrage donnée se comporterait exactement comme %01010101
Dans votre expllication vous semblez indiquer que l’on ne prend pas en compte les niveaux 2 et 3 car le STM32 n’a que 2 niveaux de sleep, à quel endroit dans la logique décrite de la cascad ce parametre intervient-il ?
L’explication est vraiment TRES peu claire avec les notions de bloqué et de cascade, soit ce n’est pas important et il faudrait etre plus sommaire, soit c’est utile et il faudrait etre plus clair.
PS : dans les notations généralement admises 0x représente de l’hexadécimal (comme $ quand il est devant), le binaire est souvent préfixé par %. (Cf notation https://fr.wikipedia.org/wiki/Système_hexadécimal ).

C’est pourtant ce qui est écrit dans le cours:

Le basculement vers le mode de plus faible consommation possible se fait en utilisant un algorithme de type cascade :

- En partant du nombre de modes définis pour une architecture donnée (par exemple 2 pour STM32), RIOT regarde si le mode le plus élevé est débloqué.
- Si ce mode est bloqué, il reste dans le mode courant (idle).
- Si le mode est débloqué, il regarde si un mode inférieur est débloqué et ainsi de suite.

Je vais rajouter mon explication précédente sur le cas des STM32 pour rendre l’exemple du texte encore plus limpide.

PS : dans les notations généralement admises 0x représente de l’hexadécimal (comme $ quand il est devant), le binaire est souvent préfixé par %

C’est bien la notation qui est utilisée dans le cours:

CFLAGS += '-DPM_BLOCKER_INITIAL={ .val_u32 = 0x01010100 }'

En C, la notation binaire utilise plutôt le préfixe 0b (par exemple: 0b10101010 = 0xAA).