Lab de systèmes embarqués : registres, broches, PWM et interruptions sur une puce simulée

Ce lab donne à chaque élève un JupyterLab à lui, avec une petite puce 8 bits inventée, écrite en Python simple pour que chaque ligne se lise. La puce a sept registres, une horloge qui avance par tops, un minuteur qui pilote une broche PWM et un bouton qui déclenche une interruption. Le dossier de travail contient la puce, mcu.py, un notebook de départ et de courts scripts, une idée chacun.

C’est un simulateur d’une puce qui n’existe pas, pas une vraie carte, et les vraies puces diffèrent : elles ont plus de registres, d’autres noms et bien plus de règles, donc c’est la fiche technique qu’il faut lire pour une vraie. Ce n’est pas non plus un lab d’attaque. Chaque copie n’a aucun accès à internet ni à aucun autre élève.

Ce que les élèves apprennent

Qu’un registre est un octet dont chaque bit a un sens, affiché en binaire, en hexadécimal et en nombres ordinaires. Puis mettre à 1, à 0 et inverser des bits avec un masque, faire d’une broche une sortie avec le registre de direction des données, la piloter et la relire, et un motif de clignotement sur huit tops. Puis un minuteur et une valeur de comparaison qui produisent un signal PWM : des valeurs de 4, 8 et 12 sur une période de 16 tops donnent 25, 50 et 75 pour cent. Enfin un bouton qui rebondit : une boucle d’interrogation compte un appui comme deux, et une interruption appelle son gestionnaire pour les deux mêmes fronts, jusqu’à ce que le gestionnaire attende la fin du rebond. Il convient aux introductions aux systèmes embarqués, à l’architecture des ordinateurs et à l’électronique.

Le lancer dans votre navigateur

Le lab démarre un seul service, jupyter, qui écrit la puce, le notebook et les petits scripts dans son dossier de travail, et il est prêt en quelques secondes, sur les 512 Mo qu’un service peut avoir. JupyterLab ne demande aucun jeton, car la porte de la plateforme sait déjà qui l’ouvre. Le terminal à côté du lab n’a pas de Python à lui : il atteint celui du lab avec docker exec jupyter, suivi de la commande à lancer à l’intérieur. Chaque script affiche la même chose à chaque fois.

  1. Ouvrir la page Conteneur. Ouvrez « Créer » dans la barre et choisissez « Lancer un conteneur ». Tout le monde peut ouvrir la page, et le lab Git et le lab SQL se lancent sans compte. Tous les autres labs demandent un compte gratuit : créez-en un, connectez-vous, puis appuyez sur « Démarrer ».
  2. Trouver le lab. La carte « Laboratoires d’exemple » liste tous les exemples. Trouvez JupyterLab : systèmes embarqués avec une puce simulée.
  3. Appuyer sur Démarrer. « Démarrer » le lance tel quel, en un clic. « Modifier le fichier d’abord » ouvre le fichier compose pour que vous puissiez le changer avant de démarrer.
  4. L’ouvrir. Sur la page du lab, la barre du lab a un lien nommé JupyterLab : appuyez dessus pour ouvrir JupyterLab dans votre navigateur et double-cliquez sur start.ipynb. Appuyez ensuite sur « Ouvrir le terminal » et tapez docker exec jupyter python3 steps/registers.py pour voir les sept registres, tous à 0b00000000 après une réinitialisation.

Que demander aux élèves de rendre

Un court script ou notebook à eux qui importe mcu.py, par exemple un motif de clignotement de leur choix sur huit tops ou un signal PWM avec un rapport cyclique qu’ils ont choisi et calculé, téléchargé depuis JupyterLab avec File, Download. Puis une ou deux phrases, de leurs propres mots, sur ce que les registres ont montré. Rien n’est noté automatiquement : la phrase montre si c’était compris. Pour un travail plus poussé, demandez un gestionnaire de bouton qui compte un appui une seule fois, et que l’élève dise en quoi le simulateur diffère d’une vraie puce.

Une leçon de base sur ce lab

Embedded Systems Basics est une petite leçon qui se fait dans ce lab. L’élève y liste le dossier de travail, affiche les registres, met à 1, à 0 et inverse des bits, pilote une broche et la fait clignoter, produit un signal PWM à trois rapports cycliques, et compare l’interrogation et l’interruption sur un bouton qui rebondit, puis retrouve le même travail dans le notebook de départ.

Elle est volontairement petite : elle montre à un enseignant ce qu’est une leçon qui se fait dans un lab, et le lab fait le reste. Copiez-la dans un module à vous pour la modifier.

Le code sur GitHub

Le fichier compose n’a pas de Dockerfile : il lance une seule image publique, scipy-notebook des Jupyter Docker Stacks, figée sur une étiquette datée, avec son propre compte sans privilèges et 512 Mo de mémoire. L’image est sous licence BSD-3-Clause et n’est pas distribuée par nous. Le fichier écrit la puce et les scripts au démarrage : chaque copie affiche la même chose et rien n’est téléchargé. Les limites sont honnêtes : c’est une seule puce inventée, il n’y a ni vrai minutage ni électronique, rien ne peut être installé depuis internet, et une vraie carte a bien plus à apprendre. Rien n’est conservé quand le lab s’arrête : l’élève télécharge son travail avant.

En faire un travail

Indiquez dans la tâche ce qu’il faut rendre.

  1. Créer le lab. Dans votre module, ajoutez une tâche et choisissez la carte « Lab de conteneurs », puis « Dans un dépôt GitHub ». Indiquez https://github.com/mitsurutech/lab-embedded-sim avec la branche main. Le fichier compose par défaut est compose.yaml. Faites d’abord un fork du dépôt si vous voulez le modifier, par exemple pour donner un autre registre à la puce.
  2. Publier et l’essayer. « Publier » fige le commit qui vous a été montré : un changement ultérieur dans le dépôt ne modifie donc pas un lab que vous avez déjà proposé. Démarrez d’abord votre propre copie.
  3. Le distribuer. Attribuez-le comme n’importe quelle tâche, avec une échéance si vous le souhaitez, et indiquez dans la tâche ce qu’il faut faire et ce qu’il faut rendre.
  4. Noter ce qui est rendu. Ouvrez la copie d’un élève et le travail rendu, notez-le et renvoyez-le avec un motif s’il demande un complément.

Essayer ce lab, et ce qu’il coûte

Un compte personnel gratuit permet de suivre les leçons de base de ce lab, avec chaque mois assez de crédit gratuit pour suivre la plupart des leçons, sans carte. Pour une classe, un établissement a ses 365 premiers jours gratuits pour 50 élèves au plus, puis paie par élève et par an, tous les labs compris et les enseignants gratuits.

Questions fréquentes

Pourquoi n’y a-t-il ni jeton ni mot de passe à taper ?
La page web d’un lab ne s’atteint que par la porte de la plateforme, qui sait déjà qui vous êtes et ne laisse entrer que vous et les enseignants de votre module. JupyterLab démarre donc sans jeton. Ne le lancez pas ainsi sur une machine que d’autres peuvent atteindre.
Pourquoi le terminal utilise-t-il docker exec jupyter ?
Le terminal du lab contient curl, psql et quelques autres clients, mais pas Python. docker exec jupyter lance une commande dans le conteneur du lab, qui a Python. JupyterLab a aussi son propre terminal, sous File, New, Terminal.
Est-ce une vraie puce ?
Non. C’est une petite puce inventée, écrite en Python pour que les idées que partagent les vraies puces, registres, bits, broches, minuteurs et interruptions, puissent se lire et se lancer. Une vraie puce a d’autres noms de registres et d’autres positions de bits, un vrai comportement électrique et un vrai minutage, et rien de cela n’est simulé ici.
Les élèves peuvent-ils modifier la puce ?
Oui. mcu.py est dans le dossier de travail, court et commenté : un élève peut ajouter un registre ou changer la période du minuteur et relancer les scripts. Les changements ne durent que jusqu’à l’arrêt du lab. Pour une autre puce pour toute la classe, faites un fork du dépôt, changez le fichier qu’écrit le fichier compose, et proposez le fork comme lab.