Différences

Ci-dessous, les différences entre deux révisions de la page.

--- pg208:accueil [2025/03/26 10:52] – Yannick Bornat
+++ pg208:accueil [2026/03/12 01:49] (Version actuelle) – Yannick Bornat
@@ Ligne 48: / Ligne 48: @@
 == Accès aux cartes depuis WSL (Linux sous windows) ==
- Par défaut, les cartes MX3 sont réservées par windows qui ne partage pas son accès avec le linux qu'il héberge. Il y a donc une manipulation à faire pour indiquer que windows ne doit pas l'utiliser et la laisser accessible au sous-système linux. M. Maraninchi (Majeure num 1), dans sa grande bonté, m'a transmis ce lien qui explique comment faire : [[https://learn.microsoft.com/fr-fr/windows/wsl/connect-usb#attach-a-usb-device]].
+ Par défaut, les cartes MX3 sont réservées par windows qui ne partage pas son accès avec le linux qu'il héberge. Il y a donc une manipulation à faire pour indiquer que windows ne doit pas l'utiliser et la laisser accessible au sous-système linux. M. Maraninchi (Majeure num 1 2025), dans sa grande bonté, m'a transmis ce lien qui explique comment faire : [[https://learn.microsoft.com/fr-fr/windows/wsl/connect-usb#attach-a-usb-device]].
 == Accès à distance par les machines de l'ENSEIRB ==
 Des cartes sont accessibles dans une salle sous clé, mais vous pouvez tester du code à distance.
-Pour cela, depuis le réseau de l'ENSEIRB, il vous suffit d'exécuter la commande ''ssh <nom_de_machine''
+Pour cela, depuis le réseau de l'ENSEIRB, il vous suffit d'exécuter la commande ''ssh <nom_de_machine>''
 pour obtenir un terminal sur la machine concernée. Depuis ce terminal, vous pouvez accéder à vos fichiers, compiler et éxécuter votre programme.
 Précautions à prendre :
-  - utilisez la commande ''users'' pour
+  * Utilisez la commande ''users'' pour savoir si vous êtes seul(e)(s) sur la machine. Il n'y a pas de gestion des accès concurrents, vos programmes pourraient interférer sans vous dire ce qui ne va pas.
+  * Essayez d'être brefs dans vos tests, surtout si vous n'êtes pas seul.
+  * Rien ne garantit que l'utilisateur ait laissé la carte dans un état propre. Pour vos assurer qu'elle est de bonne disposition, envoyez 256 fois la commande NOP (0x00). Au pire, ça ne fait rien, au mieux, la carte était en attente de données, et vous lui en avez fourni suffisament pour qu'elle aie terminé la commande en cours.
+  * La règle est l'auto-discipline. Nous n'avons pas les ressources pour gérer les conflits. Ça se passe bien ou on met fin à la manip.
+  * pour l'instant, il n'y a aucune garantie que les machines restent accessibles. Elles sont susceptibles de se mettre en sommeil. C'est sous surveillance.
+Vous ne pouvez pas lire l'écran et les LEDs, mais vous pouvez relire les registres. Le fonctionnement interne de la carte vous garantit que la lecture des caractères de l'écran (@ 64 à 95) correspond à ce qui est affiché, pareil pour les LEDs. Pour assurer les tests sur les Switchs, chaque carte a une position différente sur les switches, il suffit donc de changer de machine et vérifier si la valeur lue est cohérente.
+Les machines disponibles (susceptible d'évolution):
+  * <del>shu</del> (sw:0x29)
+  * <del>vika</del> (sw:0x61)
+  * <del>teden</del> (sw:0x23)
+  * <del>hafta</del> (sw:0x54)
+  * <del>seachtain</del> (débranché)
+  * <del>hebdomadis</del> (débranché)
+Exemple de code de démo :
+    > ssh hebdomadis
+    > users
+  bornat
+    > ls /dev/ttyUSB0
+  crwxrwxrwx 1 root dialout 188, 0 26 mars  11:23 /dev/ttyUSB0
+    > make
+    > ./votre_programme /dev/ttyUSB0
+  ...
+  ...
+    > exit