Cette page est dédiée à l'enseignement C++/programmation objet en MINEURE numérique. Pour la version majeure, ça se passe ici

• TP1 : Introduction, conteneurs, itérateurs
• TP2 : Plus de conteneurs / fichiers
• TP3 : Surcharges / Templates
• TP4 : La programmation objet
• TP5 : Diagramme UML / fonctions amies / héritage
• TP6 : Classes Abstraites / Exceptions
• mini-projet : Couche d'abstraction matérielle

• mx3board_regs.h : Fichier de définition des constantes pour le projet MX3
• main_mx3.c : Fichier d'exemple de communication MX3 (en C) à reprendre en C++

• jourdain.txt : juste un peu de texte
• De la terre à la Lune (Jules Vernes) : encore un peu plus de texte
• The hound of the Baskervilles (Sir Arthur Conan Doyle : a bit more text (without accents)
• The Picture of Dorian Gray (Oscar Wilde : still without accents
• The Call of The Wild (Jack London) : one last more
• Makefile pour le TP4

Les morceaux suivants sont à votre disposition. Les noms sont volontairement flou pour titiller votre curiosité . Merci de ne pas discuter les choix artistiques .

• caniche.txt
• children.txt
• chiwawa.txt
• eyes.txt
• froumi.txt
• lights.txt
• santa.txt
• smoke.txt
• soupe.txt

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.

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 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 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 ait 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 je 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 (@ 32 à 63) 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):

• shu (sw:0x29)
• vika (sw:0x61)
• teden (sw:0x23)
• hafta (sw:0x54)
• seachtain (débranché)
• hebdomadis (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