« SE4 2024/2025 EC2 » : différence entre les versions
(Page créée avec « = Objectifs = Vous allez concevoir, réaliser et programmer un système embarqué de test de terminaux série assez souvent utilisés pour l'administration système et réseau. Les terminaux visés sont des terminaux logiciels comme <code>minicom</code> tournant sur un système d'exploitation moderne mais aussi d'ancien terminaux comme un Ampex 210 ou un Televideo TVI-920C. Vous commencerez par concevoir votre carte dont le coeur doit être un microcontrôleur... ») |
|||
(15 versions intermédiaires par 2 utilisateurs non affichées) | |||
Ligne 5 : | Ligne 5 : | ||
Les terminaux visés sont des terminaux logiciels comme <code>minicom</code> tournant sur un système d'exploitation moderne mais aussi d'ancien terminaux comme un Ampex 210 ou un Televideo TVI-920C. | Les terminaux visés sont des terminaux logiciels comme <code>minicom</code> tournant sur un système d'exploitation moderne mais aussi d'ancien terminaux comme un Ampex 210 ou un Televideo TVI-920C. | ||
Vous commencerez par concevoir votre carte dont le coeur doit être un microcontrôleur AVR et qui doit pouvoir se connecter en USB/série à un PC moderne mais aussi à d'anciens terminaux via des connecteurs DB9 et DB25 (voir les manuels des terminaux pour le brochage). L'utilisateur doit aussi pouvoir sélectionner le mode de test et le type de terminal. Vous avez le droit à un budget de 50 euros pour la carte, les composants et le port. | Vous commencerez par concevoir votre carte dont le coeur doit être un microcontrôleur AVR et qui doit pouvoir se connecter en USB/série à un PC moderne mais aussi à d'anciens terminaux via des connecteurs DB9 et DB25 (voir les manuels des terminaux pour le brochage). L'utilisateur doit aussi pouvoir sélectionner le mode de test et le type de terminal. Une réflexion doit être menée sur l'alimentation de la carte. Vous avez le droit à un budget de 50 euros pour la carte, les composants et le port. | ||
Une fois la carte conçue et validée par l'encadrant vous pourrez vous pencher sur la programmation de la carte. Cette programmation se fera uniquement en utilisant la version AVR de <code>gcc</code> et l'utilitaire <code>dfu-programmer</code>. Vous pouvez utiliser l'Arduino Uno fourni pour les premières versions de votre programme de test de terminaux. Comme terminal vous pouvez utiliser <code>minicom</code> dans un premier temps. | Une fois la carte conçue et validée par l'encadrant vous pourrez vous pencher sur la programmation de la carte. Cette programmation se fera uniquement en utilisant la version AVR de <code>gcc</code> et l'utilitaire <code>dfu-programmer</code>. Vous pouvez utiliser l'Arduino Uno fourni pour les premières versions de votre programme de test de terminaux. Comme terminal vous pouvez utiliser <code>minicom</code> dans un premier temps. | ||
Le logiciel de test doit proposer plusieurs tests, un test fonctionnant en ASCII pur, par exemple un jeu de pendu et un jeu plus complexe utilisant des séquences de déplacement du curseur sur l'écran, par exemple un jeu tétris. Pour les séquences permettant l'adressage du curseur, vous pouvez utilisez le protocole VT100 pour <code>minicom</code>. Pour les terminaux plus anciens, vérifiez quels protocoles avancés de gestion d'affichage sont disponibles. Le cas échéant, faites en sorte que votre test avancé puisse utiliser des protocoles différents sélectionnés par l'utilisateur via les contrôles sur votre carte. | Le logiciel de test doit proposer plusieurs tests, un test fonctionnant en ASCII pur, par exemple un jeu de pendu et un jeu plus complexe utilisant des séquences de déplacement du curseur sur l'écran, par exemple un jeu tétris. Pour les séquences permettant l'adressage du curseur, vous pouvez utilisez le protocole VT100 pour <code>minicom</code>. Pour les terminaux plus anciens, vérifiez quels protocoles avancés de gestion d'affichage sont disponibles. Le cas échéant, faites en sorte que votre test avancé puisse utiliser des protocoles différents sélectionnés par l'utilisateur via les contrôles sur votre carte. | ||
L'épreuve sera considérée comme un succès s'il est possible de jouer à tétris sur un des deux anciens terminaux. | |||
Il s'agit là d'un cahier des charges initial qui peut être revu en cas d'ambigüité. Vous avez jusqu'au 1 septembre pour réaliser le travail demandé. Il vous est explicitement demandé de produire un travail régulier le plus tôt possible *et* de faire des rapports réguliers (obligatoirement au travers de ce Wiki) à votre encadrant. S'y prendre à la dernière minute avec un seul retour à quelques jours de la date limite est une garantie d'échec. | |||
= Matériel nécessaire = | = Matériel nécessaire = | ||
Ligne 17 : | Ligne 21 : | ||
* d'un Arduino UNO pour le test de la version initiale de votre programme embarqué (fourni par l'encadrant) ; | * d'un Arduino UNO pour le test de la version initiale de votre programme embarqué (fourni par l'encadrant) ; | ||
* de terminaux Ampex 210 et Televideo TVI-920C (à utiliser à l'école fin août). | * de terminaux Ampex 210 et Televideo TVI-920C (à utiliser à l'école fin août). | ||
= Foire aux questions = | |||
* L'épreuve complémentaire est-elle réalisable au domicile de l'élève ? | |||
La conception de la carte est réalisable à domicile, la fabrication de la carte est prévue à l'extérieur (50 euros maximum, composants et port compris), il faut donc une adresse postale valide pour recevoir le PCB, la réalisation de la carte peut être externalisée (dans la limite des 50 euros) ou à domicile en utilisant un fer à souder personnel, le développement initial est réalisable sur l'Arduino fourni (et un PC personnel), les tests basiques et avancés sont réalisables à domicile (Arduino et PC personnel), le test sur les anciens terminaux est à prévoir fin août à l'école. Il n'est pas prévu d'accès aux ressources de l'école avant fin août. | |||
* Où est disponible l'Arduino UNO ? | |||
Comme indiqué dans le courriel du 15 juillet, le matériel est disponible à l'accueil de l'école. A rendre au premier septembre 2025. | |||
* Comment programmer la carte ? | |||
Comme indiqué dans le sujet, la carte doit pouvoir se programmer par DFU/USB. Il est conseillé d'utiliser un système d'exploitation Linux pour le développement du programme embarqué mais vous pouvez utiliser tout autre système du moment que vous assumez ce choix. | |||
* Comment sera testée la carte réalisée ? | |||
La carte sera testée par l'encadrant d'abord en utilisant l'utilitaire <code>minicom</code> avec son émulation VT100 sous un Linux mais l'élève peut tester son code avec tout autre outil. Un second test sera conduit sur les anciens terminaux série de l'école. | |||
* Précisions sur les jeux "pendu" et "tétris" | |||
Les jeux évoqués doivent pouvoir être joué à partir de l'écran et des touches des terminaux. Les éventuelles touches sur la cartes ne servent qu'à sélectionner le test et le protocole de commandes du terminal (VT100 ou autre). | |||
= Travail réalisé = | = Travail réalisé = | ||
... | === COMPTE-RENDU DU 28/07/2025 === | ||
==== <u>Préliminaires – Connexion d’un Arduino via USB à Minicom dans WSL2</u> ==== | |||
Dans ce projet, il est nécessaire de communiquer avec un microcontrôleur (ici, un '''Arduino Uno''') connecté en '''USB''' à un PC sous '''Windows 11''', en utilisant un outil typiquement '''Linux''' : '''Minicom''', un terminal série. | |||
Or, Minicom ne fonctionne pas directement sur Windows, et nécessite un environnement Linux. Pour cette raison, nous avons mis en place un environnement '''WSL2''' (Windows Subsystem for Linux) avec '''Ubuntu''', capable d'accéder au port USB de l'Arduino. | |||
Cette section détaille toutes les étapes techniques pour configurer correctement cette chaîne de communication entre : | |||
* l’'''IDE Arduino''' sous Windows pour téléverser les programmes, | |||
* l’environnement '''Ubuntu WSL2''' pour dialoguer via le terminal Minicom. | |||
===== <u>Environnement logiciel utilisé</u> ===== | |||
* '''Système d’exploitation''' : Windows 11 | |||
* '''Distribution Linux via WSL2''' : Ubuntu 20.04 | |||
* '''Périphérique série utilisé''' : Arduino Uno | |||
* '''Outils utilisés''' : | |||
** WSL2 | |||
** usbipd-win (redirection USB vers WSL) | |||
** <code>Minicom</code> (communication série Linux) | |||
==== Redirection USB du port Arduino vers WSL ==== | |||
Par défaut, un port USB comme '''COM9''' sur Windows '''n'est pas visible directement''' sous WSL. Pour le rendre accessible à Ubuntu, il faut utiliser '''usbipd-win'''. | |||
==== Installer usbipd ==== | |||
Dans PowerShell : | |||
<syntaxhighlight lang="bash">winget install usbipd</syntaxhighlight> | |||
Redémarrer le système W11 une fois l'installation terminée. | |||
=== Identifier le port USB de l’Arduino === | |||
Branche l’Arduino via USB. | |||
Dans PowerShell : | |||
<syntaxhighlight lang="bash">usbipd list</syntaxhighlight> | |||
Cela affiche tous les périphériques USB connectés. | |||
<syntaxhighlight lang="bash">BUSID VID:PID DEVICE | |||
1-1 2341:0043 Périphérique série USB (COM9)</syntaxhighlight> | |||
Ici, le '''BUSID''' est <code>1-1</code> et l’Arduino est détecté sur le '''port COM9'''. | |||
=== Partager puis attacher le port à WSL === | |||
Toujours dans PowerShell : | |||
<syntaxhighlight lang="bash">usbipd bind --busid 1-1 | |||
usbipd attach --busid 1-1 --wsl</syntaxhighlight> | |||
Vérifier dans Ubuntu que le port est bien présent | |||
Dans Ubuntu (WSL) : | |||
<syntaxhighlight lang="bash">ls /dev/tty* | |||
/dev/tty /dev/tty21 /dev/tty35 /dev/tty49 /dev/tty62 | |||
/dev/tty0 /dev/tty22 /dev/tty36 /dev/tty5 /dev/tty63 | |||
/dev/tty1 /dev/tty23 /dev/tty37 /dev/tty50 /dev/tty7 | |||
/dev/tty10 /dev/tty24 /dev/tty38 /dev/tty51 /dev/tty8 | |||
/dev/tty11 /dev/tty25 /dev/tty39 /dev/tty52 /dev/tty9 | |||
/dev/tty12 /dev/tty26 /dev/tty4 /dev/tty53 /dev/ttyACM0 | |||
/dev/tty13 /dev/tty27 /dev/tty40 /dev/tty54 /dev/ttyS0 | |||
/dev/tty14 /dev/tty28 /dev/tty41 /dev/tty55 /dev/ttyS1 | |||
/dev/tty15 /dev/tty29 /dev/tty42 /dev/tty56 /dev/ttyS2 | |||
/dev/tty16 /dev/tty3 /dev/tty43 /dev/tty57 /dev/ttyS3 | |||
/dev/tty17 /dev/tty30 /dev/tty44 /dev/tty58 /dev/ttyS4 | |||
/dev/tty18 /dev/tty31 /dev/tty45 /dev/tty59 /dev/ttyS5 | |||
/dev/tty19 /dev/tty32 /dev/tty46 /dev/tty6 /dev/ttyS6 | |||
/dev/tty2 /dev/tty33 /dev/tty47 /dev/tty60 /dev/ttyS7 | |||
/dev/tty20 /dev/tty34 /dev/tty48 /dev/tty61 | |||
</syntaxhighlight> | |||
Ce périphérique correspond à l’Arduino connecté en USB. | |||
C’est ce port que Minicom utilisera pour la communication série. | |||
Exemple de sketch Arduino pour test de communication | |||
Ce sketch permet de tester si la communication fonctionne bien. | |||
Téléverser via l’IDE Arduino sous Windows avant d’attacher le périphérique à WSL : | |||
<syntaxhighlight lang="cpp"> | |||
void setup() { | |||
Serial.begin(9600); | |||
} | |||
void loop() { | |||
if (Serial.available()) { | |||
char c = Serial.read(); | |||
Serial.print("Vous avez tapé : "); | |||
Serial.println(c); | |||
} | |||
}</syntaxhighlight> | |||
Alternance Windows ↔ WSL | |||
Pour téléverser un sketch depuis Windows : | |||
<syntaxhighlight lang="powershell">usbipd detach --busid 1-1</syntaxhighlight> | |||
(Le périphérique redevient accessible dans l’IDE Arduino sous Windows) | |||
Pour basculer la communication vers Ubuntu (Minicom) : | |||
<syntaxhighlight lang="powershell">usbipd bind --busid 1-1 | |||
usbipd attach --busid 1-1 --wsl</syntaxhighlight> | |||
Cette alternance peut être répétée autant que nécessaire. | |||
= Documents Rendus = | = Documents Rendus = | ||
== Projet KiCAD de la carte == | == Projet KiCAD de la carte == | ||
Lien Gitea avec Code Arduino, Code C, Makefile, fichiers KiCAD : https://gitea.plil.fr/pcasimir/Test-Terminaux_Rattrapages-SE4-2025.git | |||
{| class="wikitable" | |||
|+ | |||
![[Fichier:Terminal-Testing SCH KiCAD.pdf|alt=Terminal-Testing SCH KiCAD|vignette|Terminal-Testing SCH KiCAD]] | |||
|} | |||
== Programme de test ASCII == | == Programme de test ASCII == | ||
Archive attachée avec <code>Makefile</code> intégré. | Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile"> | ||
# ========= Projet ========= | |||
TARGET = program | |||
MCU = atmega328p | |||
F_CPU = 16000000UL | |||
# Tes sources C | |||
SRC = main.c serial.c timer.c hangman.c tetris.c | |||
OBJ = $(SRC:.c=.o) | |||
# ========= Outils ========= | |||
CC = avr-gcc | |||
OBJCOPY = avr-objcopy | |||
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99 | |||
# ========= Port série (à adapter si besoin) ========= | |||
# Linux / WSL | |||
PORT = /dev/ttyACM0 | |||
# Windows (exemple) | |||
# PORT = COM4 | |||
# macOS (exemple) | |||
# PORT = /dev/tty.usbmodem14101 | |||
# ========= avrdude (bootloader Optiboot UNO) ========= | |||
AVRDUDE = avrdude | |||
PROGRAMMER = arduino | |||
BAUD = 115200 | |||
# ========= dfu-programmer (ATmega16U2 en DFU) ========= | |||
DFU_CHIP = atmega16u2 | |||
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA) | |||
# Exemples : | |||
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex | |||
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex | |||
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex | |||
# ========= Règles par défaut ========= | |||
.PHONY: all clean upload flash16u2 help | |||
all: $(TARGET).hex | |||
$(TARGET).elf: $(OBJ) | |||
$(CC) $(CFLAGS) -o $@ $^ | |||
%.o: %.c | |||
$(CC) $(CFLAGS) -c $< -o $@ | |||
%.hex: %.elf | |||
$(OBJCOPY) -O ihex -R .eeprom $< $@ | |||
# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) ========= | |||
upload: $(TARGET).hex | |||
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i | |||
# ========= Flash du 16U2 en DFU (optionnel) ========= | |||
flash16u2: | |||
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi | |||
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)." | |||
dfu-programmer $(DFU_CHIP) erase | |||
dfu-programmer $(DFU_CHIP) flash $(FW16U2) | |||
dfu-programmer $(DFU_CHIP) reset | |||
@echo ">> 16U2 reflashé. Le port série doit réapparaître." | |||
clean: | |||
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex | |||
help: | |||
@echo "Cibles utiles :" | |||
@echo " make -> compile et génère $(TARGET).hex" | |||
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)" | |||
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)" | |||
@echo " make clean -> nettoyage" | |||
</syntaxhighlight>Deuxième Makefile<syntaxhighlight lang="makefile"> | |||
# ========= Projet ========= | |||
TARGET = program | |||
MCU = at90usb1287 | |||
F_CPU = 16000000UL | |||
# ========= LUFA ========= | |||
LUFA_PATH = ./LUFA | |||
# Core USB (prend tous les .c du core + AVR8 pour éviter les soucis de noms) | |||
LUFA_CORE_SRC = \ | |||
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/*.c) \ | |||
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/AVR8/*.c) | |||
# Classe CDC côté Device (et commun) — uniquement CDC | |||
LUFA_CLASS_SRC = \ | |||
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Common/*CDC*.c) \ | |||
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Device/*CDC*.c) | |||
# ========= Sources de ton projet ========= | |||
SRC = main.c hangman.c tetris.c timer.c serial.c Descriptors.c \ | |||
$(LUFA_CORE_SRC) $(LUFA_CLASS_SRC) | |||
OBJ = $(SRC:.c=.o) | |||
Vidéos de démonstration avec <code>minicom</code>. | # ========= Outils ========= | ||
CC = avr-gcc | |||
OBJCOPY = avr-objcopy | |||
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -ffunction-sections -fdata-sections \ | |||
-I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I. \ | |||
-DUSE_LUFA_CONFIG_HEADER -I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I. | |||
LDFLAGS = -Wl,--gc-sections | |||
# ========= Règles ========= | |||
.PHONY: all clean erase flash reset info | |||
all: $(TARGET).hex | |||
%.o: %.c | |||
$(CC) $(CFLAGS) -c $< -o $@ | |||
$(TARGET).elf: $(OBJ) | |||
$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ | |||
$(TARGET).hex: $(TARGET).elf | |||
$(OBJCOPY) -O ihex -R .eeprom $< $@ | |||
clean: | |||
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex | |||
# -------- DFU workflow -------- | |||
info: | |||
@echo "DFU: maintenir HWB, pulse RESET, relâcher RESET, relâcher HWB." | |||
@echo "Ensuite: make erase && make flash && make reset" | |||
erase: | |||
dfu-programmer at90usb1287 erase | |||
flash: $(TARGET).hex | |||
dfu-programmer at90usb1287 flash $(TARGET).hex | |||
reset: | |||
dfu-programmer at90usb1287 reset | |||
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>. | |||
{| class="wikitable" | |||
|+ | |||
![[Fichier:Arduino UNO Minicom Pendu + Tetriss.mp4|vignette|Arduino UNO Minicom Pendu + Tetriss]] | |||
|} | |||
== Programme de test avancé == | == Programme de test avancé == | ||
Archive attachée avec <code>Makefile</code> intégré. | Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile"> | ||
# ========= Projet ========= | |||
TARGET = program | |||
MCU = atmega328p | |||
F_CPU = 16000000UL | |||
# Tes sources C (modifie si besoin) | |||
SRC = main.c serial.c timer.c hangman.c tetris.c | |||
OBJ = $(SRC:.c=.o) | |||
# ========= Outils ========= | |||
CC = avr-gcc | |||
OBJCOPY = avr-objcopy | |||
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99 | |||
# ========= Port série (à adapter) ========= | |||
# Linux / WSL | |||
PORT = /dev/ttyACM0 | |||
# Windows (exemple) | |||
# PORT = COM4 | |||
# macOS (exemple) | |||
# PORT = /dev/tty.usbmodem14101 | |||
# ========= avrdude (bootloader Optiboot UNO) ========= | |||
AVRDUDE = avrdude | |||
PROGRAMMER = arduino | |||
BAUD = 115200 | |||
# ========= dfu-programmer (ATmega16U2 en DFU) ========= | |||
DFU_CHIP = atmega16u2 | |||
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA) | |||
# Exemples : | |||
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex | |||
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex | |||
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex | |||
# ========= Règles par défaut ========= | |||
.PHONY: all clean upload flash16u2 help | |||
all: $(TARGET).hex | |||
$(TARGET).elf: $(OBJ) | |||
$(CC) $(CFLAGS) -o $@ $^ | |||
%.o: %.c | |||
$(CC) $(CFLAGS) -c $< -o $@ | |||
%.hex: %.elf | |||
$(OBJCOPY) -O ihex -R .eeprom $< $@ | |||
# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) ========= | |||
upload: $(TARGET).hex | |||
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i | |||
# ========= Flash du 16U2 en DFU (optionnel) ========= | |||
flash16u2: | |||
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi | |||
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)." | |||
dfu-programmer $(DFU_CHIP) erase | |||
dfu-programmer $(DFU_CHIP) flash $(FW16U2) | |||
dfu-programmer $(DFU_CHIP) reset | |||
@echo ">> 16U2 reflashé. Le port série doit réapparaître." | |||
clean: | |||
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex | |||
help: | |||
@echo "Cibles utiles :" | |||
@echo " make -> compile et génère $(TARGET).hex" | |||
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)" | |||
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)" | |||
@echo " make clean -> nettoyage" | |||
</syntaxhighlight>Deuxième Makefile <syntaxhighlight lang="makefile"> | |||
# ========= Projet ========= | |||
TARGET = program | |||
MCU = at90usb1287 | |||
F_CPU = 16000000UL | |||
# ========= LUFA ========= | |||
LUFA_PATH = ./LUFA | |||
# Core USB (prend tous les .c du core + AVR8 pour éviter les soucis de noms) | |||
LUFA_CORE_SRC = \ | |||
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/*.c) \ | |||
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/AVR8/*.c) | |||
# Classe CDC côté Device (et commun) — uniquement CDC | |||
LUFA_CLASS_SRC = \ | |||
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Common/*CDC*.c) \ | |||
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Device/*CDC*.c) | |||
# ========= Sources de ton projet ========= | |||
SRC = main.c hangman.c tetris.c timer.c serial.c Descriptors.c \ | |||
$(LUFA_CORE_SRC) $(LUFA_CLASS_SRC) | |||
OBJ = $(SRC:.c=.o) | |||
# ========= Outils ========= | |||
CC = avr-gcc | |||
OBJCOPY = avr-objcopy | |||
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -ffunction-sections -fdata-sections \ | |||
-I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I. \ | |||
-DUSE_LUFA_CONFIG_HEADER -I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I. | |||
LDFLAGS = -Wl,--gc-sections | |||
# ========= Règles ========= | |||
.PHONY: all clean erase flash reset info | |||
all: $(TARGET).hex | |||
%.o: %.c | |||
$(CC) $(CFLAGS) -c $< -o $@ | |||
$(TARGET).elf: $(OBJ) | |||
$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ | |||
$(TARGET).hex: $(TARGET).elf | |||
$(OBJCOPY) -O ihex -R .eeprom $< $@ | |||
clean: | |||
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex | |||
# -------- DFU workflow -------- | |||
info: | |||
@echo "DFU: maintenir HWB, pulse RESET, relâcher RESET, relâcher HWB." | |||
@echo "Ensuite: make erase && make flash && make reset" | |||
erase: | |||
dfu-programmer at90usb1287 erase | |||
flash: $(TARGET).hex | |||
dfu-programmer at90usb1287 flash $(TARGET).hex | |||
Vidéos de démonstration avec <code>minicom</code>. | reset: | ||
dfu-programmer at90usb1287 reset | |||
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>. | |||
{| class="wikitable" | |||
|+ | |||
![[Fichier:Arduino UNO Minicom Pendu + Tetris.mp4|vignette]] | |||
|- | |||
![[Fichier:Vidéo démonstrative surMinicom avec Carte de M-Zongo.mp4|vignette|Vidéo démonstrative surMinicom avec Carte de M-Zongo]] | |||
|} | |||
== Démonstration de fonctionnement sur terminaux anciens == | == Démonstration de fonctionnement sur terminaux anciens == | ||
Vidéos de démonstration. | Vidéos de démonstration. |
Version actuelle datée du 3 septembre 2025 à 18:32
Objectifs
Vous allez concevoir, réaliser et programmer un système embarqué de test de terminaux série assez souvent utilisés pour l'administration système et réseau.
Les terminaux visés sont des terminaux logiciels comme minicom
tournant sur un système d'exploitation moderne mais aussi d'ancien terminaux comme un Ampex 210 ou un Televideo TVI-920C.
Vous commencerez par concevoir votre carte dont le coeur doit être un microcontrôleur AVR et qui doit pouvoir se connecter en USB/série à un PC moderne mais aussi à d'anciens terminaux via des connecteurs DB9 et DB25 (voir les manuels des terminaux pour le brochage). L'utilisateur doit aussi pouvoir sélectionner le mode de test et le type de terminal. Une réflexion doit être menée sur l'alimentation de la carte. Vous avez le droit à un budget de 50 euros pour la carte, les composants et le port.
Une fois la carte conçue et validée par l'encadrant vous pourrez vous pencher sur la programmation de la carte. Cette programmation se fera uniquement en utilisant la version AVR de gcc
et l'utilitaire dfu-programmer
. Vous pouvez utiliser l'Arduino Uno fourni pour les premières versions de votre programme de test de terminaux. Comme terminal vous pouvez utiliser minicom
dans un premier temps.
Le logiciel de test doit proposer plusieurs tests, un test fonctionnant en ASCII pur, par exemple un jeu de pendu et un jeu plus complexe utilisant des séquences de déplacement du curseur sur l'écran, par exemple un jeu tétris. Pour les séquences permettant l'adressage du curseur, vous pouvez utilisez le protocole VT100 pour minicom
. Pour les terminaux plus anciens, vérifiez quels protocoles avancés de gestion d'affichage sont disponibles. Le cas échéant, faites en sorte que votre test avancé puisse utiliser des protocoles différents sélectionnés par l'utilisateur via les contrôles sur votre carte.
L'épreuve sera considérée comme un succès s'il est possible de jouer à tétris sur un des deux anciens terminaux.
Il s'agit là d'un cahier des charges initial qui peut être revu en cas d'ambigüité. Vous avez jusqu'au 1 septembre pour réaliser le travail demandé. Il vous est explicitement demandé de produire un travail régulier le plus tôt possible *et* de faire des rapports réguliers (obligatoirement au travers de ce Wiki) à votre encadrant. S'y prendre à la dernière minute avec un seul retour à quelques jours de la date limite est une garantie d'échec.
Matériel nécessaire
Le matériel nécessaire est constitué :
- d'un PC pour la conception de la carte et la mise au point du programme embarqué (à votre charge) ;
- d'un Arduino UNO pour le test de la version initiale de votre programme embarqué (fourni par l'encadrant) ;
- de terminaux Ampex 210 et Televideo TVI-920C (à utiliser à l'école fin août).
Foire aux questions
- L'épreuve complémentaire est-elle réalisable au domicile de l'élève ?
La conception de la carte est réalisable à domicile, la fabrication de la carte est prévue à l'extérieur (50 euros maximum, composants et port compris), il faut donc une adresse postale valide pour recevoir le PCB, la réalisation de la carte peut être externalisée (dans la limite des 50 euros) ou à domicile en utilisant un fer à souder personnel, le développement initial est réalisable sur l'Arduino fourni (et un PC personnel), les tests basiques et avancés sont réalisables à domicile (Arduino et PC personnel), le test sur les anciens terminaux est à prévoir fin août à l'école. Il n'est pas prévu d'accès aux ressources de l'école avant fin août.
- Où est disponible l'Arduino UNO ?
Comme indiqué dans le courriel du 15 juillet, le matériel est disponible à l'accueil de l'école. A rendre au premier septembre 2025.
- Comment programmer la carte ?
Comme indiqué dans le sujet, la carte doit pouvoir se programmer par DFU/USB. Il est conseillé d'utiliser un système d'exploitation Linux pour le développement du programme embarqué mais vous pouvez utiliser tout autre système du moment que vous assumez ce choix.
- Comment sera testée la carte réalisée ?
La carte sera testée par l'encadrant d'abord en utilisant l'utilitaire minicom
avec son émulation VT100 sous un Linux mais l'élève peut tester son code avec tout autre outil. Un second test sera conduit sur les anciens terminaux série de l'école.
- Précisions sur les jeux "pendu" et "tétris"
Les jeux évoqués doivent pouvoir être joué à partir de l'écran et des touches des terminaux. Les éventuelles touches sur la cartes ne servent qu'à sélectionner le test et le protocole de commandes du terminal (VT100 ou autre).
Travail réalisé
COMPTE-RENDU DU 28/07/2025
Préliminaires – Connexion d’un Arduino via USB à Minicom dans WSL2
Dans ce projet, il est nécessaire de communiquer avec un microcontrôleur (ici, un Arduino Uno) connecté en USB à un PC sous Windows 11, en utilisant un outil typiquement Linux : Minicom, un terminal série.
Or, Minicom ne fonctionne pas directement sur Windows, et nécessite un environnement Linux. Pour cette raison, nous avons mis en place un environnement WSL2 (Windows Subsystem for Linux) avec Ubuntu, capable d'accéder au port USB de l'Arduino.
Cette section détaille toutes les étapes techniques pour configurer correctement cette chaîne de communication entre :
- l’IDE Arduino sous Windows pour téléverser les programmes,
- l’environnement Ubuntu WSL2 pour dialoguer via le terminal Minicom.
Environnement logiciel utilisé
- Système d’exploitation : Windows 11
- Distribution Linux via WSL2 : Ubuntu 20.04
- Périphérique série utilisé : Arduino Uno
- Outils utilisés :
- WSL2
- usbipd-win (redirection USB vers WSL)
Minicom
(communication série Linux)
Redirection USB du port Arduino vers WSL
Par défaut, un port USB comme COM9 sur Windows n'est pas visible directement sous WSL. Pour le rendre accessible à Ubuntu, il faut utiliser usbipd-win.
Installer usbipd
Dans PowerShell :
winget install usbipd
Redémarrer le système W11 une fois l'installation terminée.
Identifier le port USB de l’Arduino
Branche l’Arduino via USB.
Dans PowerShell :
usbipd list
Cela affiche tous les périphériques USB connectés.
BUSID VID:PID DEVICE
1-1 2341:0043 Périphérique série USB (COM9)
Ici, le BUSID est 1-1
et l’Arduino est détecté sur le port COM9.
Partager puis attacher le port à WSL
Toujours dans PowerShell :
usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl
Vérifier dans Ubuntu que le port est bien présent Dans Ubuntu (WSL) :
ls /dev/tty*
/dev/tty /dev/tty21 /dev/tty35 /dev/tty49 /dev/tty62
/dev/tty0 /dev/tty22 /dev/tty36 /dev/tty5 /dev/tty63
/dev/tty1 /dev/tty23 /dev/tty37 /dev/tty50 /dev/tty7
/dev/tty10 /dev/tty24 /dev/tty38 /dev/tty51 /dev/tty8
/dev/tty11 /dev/tty25 /dev/tty39 /dev/tty52 /dev/tty9
/dev/tty12 /dev/tty26 /dev/tty4 /dev/tty53 /dev/ttyACM0
/dev/tty13 /dev/tty27 /dev/tty40 /dev/tty54 /dev/ttyS0
/dev/tty14 /dev/tty28 /dev/tty41 /dev/tty55 /dev/ttyS1
/dev/tty15 /dev/tty29 /dev/tty42 /dev/tty56 /dev/ttyS2
/dev/tty16 /dev/tty3 /dev/tty43 /dev/tty57 /dev/ttyS3
/dev/tty17 /dev/tty30 /dev/tty44 /dev/tty58 /dev/ttyS4
/dev/tty18 /dev/tty31 /dev/tty45 /dev/tty59 /dev/ttyS5
/dev/tty19 /dev/tty32 /dev/tty46 /dev/tty6 /dev/ttyS6
/dev/tty2 /dev/tty33 /dev/tty47 /dev/tty60 /dev/ttyS7
/dev/tty20 /dev/tty34 /dev/tty48 /dev/tty61
Ce périphérique correspond à l’Arduino connecté en USB. C’est ce port que Minicom utilisera pour la communication série.
Exemple de sketch Arduino pour test de communication Ce sketch permet de tester si la communication fonctionne bien. Téléverser via l’IDE Arduino sous Windows avant d’attacher le périphérique à WSL :
void setup() {
Serial.begin(9600);
}
void loop() {
if (Serial.available()) {
char c = Serial.read();
Serial.print("Vous avez tapé : ");
Serial.println(c);
}
}
Alternance Windows ↔ WSL
Pour téléverser un sketch depuis Windows :
usbipd detach --busid 1-1
(Le périphérique redevient accessible dans l’IDE Arduino sous Windows)
Pour basculer la communication vers Ubuntu (Minicom) :
usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl
Cette alternance peut être répétée autant que nécessaire.
Documents Rendus
Projet KiCAD de la carte
Lien Gitea avec Code Arduino, Code C, Makefile, fichiers KiCAD : https://gitea.plil.fr/pcasimir/Test-Terminaux_Rattrapages-SE4-2025.git
Programme de test ASCII
Archive attachée avec Makefile
intégré.
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL
# Tes sources C
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)
# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99
# ========= Port série (à adapter si besoin) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101
# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200
# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help
all: $(TARGET).hex
$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@
%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@
# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i
# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."
clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex
help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
Deuxième Makefile
# ========= Projet =========
TARGET = program
MCU = at90usb1287
F_CPU = 16000000UL
# ========= LUFA =========
LUFA_PATH = ./LUFA
# Core USB (prend tous les .c du core + AVR8 pour éviter les soucis de noms)
LUFA_CORE_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/AVR8/*.c)
# Classe CDC côté Device (et commun) — uniquement CDC
LUFA_CLASS_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Common/*CDC*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Device/*CDC*.c)
# ========= Sources de ton projet =========
SRC = main.c hangman.c tetris.c timer.c serial.c Descriptors.c \
$(LUFA_CORE_SRC) $(LUFA_CLASS_SRC)
OBJ = $(SRC:.c=.o)
# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -ffunction-sections -fdata-sections \
-I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I. \
-DUSE_LUFA_CONFIG_HEADER -I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I.
LDFLAGS = -Wl,--gc-sections
# ========= Règles =========
.PHONY: all clean erase flash reset info
all: $(TARGET).hex
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@
$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@
$(TARGET).hex: $(TARGET).elf
$(OBJCOPY) -O ihex -R .eeprom $< $@
clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex
# -------- DFU workflow --------
info:
@echo "DFU: maintenir HWB, pulse RESET, relâcher RESET, relâcher HWB."
@echo "Ensuite: make erase && make flash && make reset"
erase:
dfu-programmer at90usb1287 erase
flash: $(TARGET).hex
dfu-programmer at90usb1287 flash $(TARGET).hex
reset:
dfu-programmer at90usb1287 reset
Vidéos de démonstration avec minicom
.
Programme de test avancé
Archive attachée avec Makefile
intégré.
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL
# Tes sources C (modifie si besoin)
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)
# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99
# ========= Port série (à adapter) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101
# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200
# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help
all: $(TARGET).hex
$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@
%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@
# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i
# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."
clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex
help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
Deuxième Makefile
# ========= Projet =========
TARGET = program
MCU = at90usb1287
F_CPU = 16000000UL
# ========= LUFA =========
LUFA_PATH = ./LUFA
# Core USB (prend tous les .c du core + AVR8 pour éviter les soucis de noms)
LUFA_CORE_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/AVR8/*.c)
# Classe CDC côté Device (et commun) — uniquement CDC
LUFA_CLASS_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Common/*CDC*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Device/*CDC*.c)
# ========= Sources de ton projet =========
SRC = main.c hangman.c tetris.c timer.c serial.c Descriptors.c \
$(LUFA_CORE_SRC) $(LUFA_CLASS_SRC)
OBJ = $(SRC:.c=.o)
# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -ffunction-sections -fdata-sections \
-I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I. \
-DUSE_LUFA_CONFIG_HEADER -I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I.
LDFLAGS = -Wl,--gc-sections
# ========= Règles =========
.PHONY: all clean erase flash reset info
all: $(TARGET).hex
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@
$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@
$(TARGET).hex: $(TARGET).elf
$(OBJCOPY) -O ihex -R .eeprom $< $@
clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex
# -------- DFU workflow --------
info:
@echo "DFU: maintenir HWB, pulse RESET, relâcher RESET, relâcher HWB."
@echo "Ensuite: make erase && make flash && make reset"
erase:
dfu-programmer at90usb1287 erase
flash: $(TARGET).hex
dfu-programmer at90usb1287 flash $(TARGET).hex
reset:
dfu-programmer at90usb1287 reset
Vidéos de démonstration avec minicom
.
Démonstration de fonctionnement sur terminaux anciens
Vidéos de démonstration.