SE3Groupe2025-11
Programmation des systèmes embarqués
Carte électronique
Carte réalisée en utilisant le logiciel KiCAD : Fichier:2025-PSE-G11-PROG.zip.
Schéma électronique de la carte :
Résultat du routage :
Résultat 3D :
Photo de la carte soudée :
Vidéo très courte et en basse résolution de la carte en fonctionnement :
Média:2025-PSE-BB-PROG-video.mp4
Programmation
Bilan
J'indique où j'en suis arrivé à la fin des séances.
Eventuellement la vidéo brève du fonctionnement complet du programmateur : Média:2025-PSE-BB-PROG-final.mp4.
Premier système embarqué
Archive GIT
Mon archive GIT pour le projet KiCAD et pour les programmes : [1].
Description du système embarqué
Objectif
L'objectif de ce projet est de concevoir une télécommande de présentation intelligente et sans fil. Elle devra être capable de contrôler un ordinateur à distance (diaporama, pointeur laser ), tout en assistant l'orateur dans la gestion de son temps de parole via un écran OLED, une jauge LED et des alertes haptiques. Nous l'avons donner un nom SMART PRESENTER
Fonctionnalités de la télécommande :
Notre télécommande posséderas plusieurs fonctionnalités parmi lesquels nous avons :
-> Contrôle et Navigation (Interaction avec le PC) :
- Navigation des diapositives : Passage à la diapositive suivante ou précédente via des boutons physiques dédiés.
- Pointeur Laser intégré : Activation d'un laser physique pour désigner directement des éléments sur un écran de projection ou un tableau.
- Mode "Stay focus" : Un bouton qui envoie une commande au PC. Cela coupe l'affichage de la présentation (écran noir) pour que l'auditoire se concentre uniquement sur l'orateur. Ou encore un mode qui afficherais selement une partie de la diapos afin que l'auditoir se concentre sur un point précis délimité par un cercle ou l'extérieur est mis en mode sombre.
-> Assistance et Gestion du Temps (Feedback Utilisateur) :
- Moniteur OLED : Affichage en temps réel du chronomètre, du temps restant et du nom de la partie en cours de la présentation.
- Jauge de progression visuelle : Indication de l'avancement du temps via une barre de LEDs RGB intégrée (changement progressif de couleur, du vert vers le rouge).
- Alertes Haptiques (Vibreur) : Vibrations discrètes ressenties dans la main pour avertir l'orateur des paliers cruciaux (mi-parcours, dernière minute, temps écoulé).
-> Fonctionnalité intelligente:
- Mise en veille automatique : Utiliser un accéléromètre pour détecter si la télécommande est posée sur la table. Si elle ne bouge plus pendant 2 minutes, l'écran OLED s'éteint pour économiser la batterie.
Conception des circuits
Pour la conception de notre télécommande de présentation nommée SMART PRESENTER, l'analyse de conception de ce dernier est plutôt subdivisée en deux grandes phases.
Nous aurons entre autres la conception de la télécommande principale elle-même et également du socle récepteur qui sera relié à l'ordinateur.
Le système s'appuiera sur le principe de communication radio pour l'échange de données entre la télécommande et le socle de réception connecté au PC de l'orateur.
Nous allons maintenant analyser en profondeur chacun des grands circuits de notre projet afin de choisir les composants, de valider ces derniers, de concevoir leurs schémas et de réaliser le routage du circuit final.
Composants du projets
L'architecture de notre système s'articule autour des éléments suivants :
Le microcontrôleur MCU : ATMEGA32U4
Le microcontrôleur ATmega32U4, basé sur l'architecture AVR RISC 8 bits, constitue le cerveau et le centre d'orchestration de l'ensemble du socle récepteur.
Ce composant a été spécifiquement sélectionné pour ses caractéristiques matérielles qui répondent parfaitement aux exigences d'une passerelle de communication radio-vers-PC.
Le choix de ce composant s'articule autour des atouts techniques suivants :
- Contrôleur USB 2.0 natif (Hardware USB) : C'est l'argument principal de cette architecture. Contrairement à d'autres microcontrôleurs nécessitant une puce convertisseuse externe (type FTDI ou CH340) générant des ports séries virtuels souvent instables, l'ATmega32U4 intègre un module USB directement dans son silicium. Cela permet une émulation matérielle pure des périphériques d'interface humaine (HID), indispensable pour un fonctionnement "Plug & Play".
- Bus de Communication (SPI Matériel) : La puce dispose d'un contrôleur matériel SPI dédié, essentiel pour dialoguer à haute vitesse avec le module radio nRF24L01+.
- Ressources Mémoire : Doté de 32 Ko de mémoire Flash et de 2.5 Ko de SRAM, l'ATmega32U4 dispose d'un espace de stockage amplement suffisant pour héberger la pile logicielle USB (framework LUFA), les descripteurs complexes du périphérique, et la logique de décodage des trames radio.
Tout cela est résumé dans le tableau ci-dessous :
| Caractéristiques | ATmega32U4 |
|---|---|
| Architecture | AVR 8 bits |
| Mémoire Flash | 32 KB |
| RAM (SRAM) | 2.5 KB |
| EEPROM | 1 KB |
| Fréquence d'horloge max. | 16 MHz |
| Nombre de broches GPIO | 26 |
| Interfaces de communication | UART, SPI, I²C, USB 2.0 |
| Contrôleur USB intégré | Oui (USB 2.0) |
| Taille des registres | 8 bits |
| Nombre de broches | 32 |
| Différences principales | Conçu pour des applications nécessitant un contrôleur USB intégré, avec une mémoire et un nombre de broches intermédiaires |
Datasheet ATmega32u4 :
La communication radio
Il s'agit d'un transceiver (émetteur-récepteur) très basse consommation fonctionnant dans la bande de fréquences libre ISM (Industrial, Scientific and Medical) des 2.4 GHz. il seras utiliser dans notre cas pour la réception des data provenant de la télécommande principale et le mettre a la disposition du MCU pour la transmission au PC . Ensemble des spécificité technique du composants est décrite dans la datasheet :
Datasheet NRF24L01 :
Le Régulateur de Tension LDO (Adaptation d'Énergie)
Bien que le socle récepteur bénéficie d'une source d'énergie théoriquement infinie grâce au port USB de l'ordinateur hôte (délivrant une tension nominale de 5V), une adaptation stricte de cette tension est impérative. En effet, si le microcontrôleur ATmega32U4 exploite nativement ce 5V pour fonctionner à sa fréquence maximale de 16 MHz, le module radiofréquence nRF24L01+ possède une tolérance absolue fixée à 3.6V. Une exposition directe au VBUS de l'USB entraînerait la destruction immédiate de la puce RF.
Pour pallier ce problème et garantir l'intégrité du système, l'architecture intègre un régulateur de tension linéaire à faible chute (LDO - Low Drop-Out), tel que le LM1117-3.3.
Datasheet LDO :
Le Moteur Haptique (ERM)
Pour offrir une expérience ergonomique optimale à l'orateur, la télécommande intègre un micro-moteur vibrant de type ERM (Eccentric Rotating Mass).
Son rôle principal est de fournir un retour haptique discret. Cela permet de transmettre des alertes temporelles à l'utilisateur (par exemple, de signaler par une légère vibration qu'il ne reste que 5 minutes de présentation) sans l'obliger à regarder l'écran, lui permettant ainsi de maintenir un contact visuel constant avec son public.
D'un point de vue matériel, le pilotage de ce moteur (qui constitue une charge fortement inductive) ne peut pas se faire directement via les broches du microcontrôleur. Il nécessite un sous-circuit de puissance et de protection robuste :
- Pilotage (Low-Side Switching) : Utilisation d'un transistor MOSFET Canal-N (ex: 2N7002) pour agir comme un interrupteur commandé par la masse. Il est piloté par un signal PWM de l'ATmega32U4, ce qui permet de faire varier l'intensité de la vibration.
- Protection (Diode de roue libre) : Ajout d'une diode Schottky rapide en anti-parallèle du moteur. Elle est vitale pour dissiper l'énergie de la bobine et bloquer les pics de tension destructeurs (force contre-électromotrice) lors de l'arrêt du moteur.
- Filtrage antiparasite : Un condensateur de découplage de 100 nF est placé en parallèle pour absorber le bruit électrique généré par les balais du moteur, évitant ainsi de perturber la communication du module radio nRF24L01+.
- Alimentation isolée : Le moteur tire son énergie directement de la batterie (VBAT_SW) et non du régulateur LDO 3.3V, pour préserver la stabilité de la tension de la logique numérique.
La baterie lithium :
Élément incontournable pour une autonomie de la télécommande nous avons opter pour la LP-402933-1S-3.
Ce choix est dicté tout dabbord par l'exigence de finesse de la télécommande . Ses 4 mm d'épaisseur permettent une intégration sans surépaisseur du boîtier, tout en garantissant une autonomie suffisante pour environ 15 à 20 présentations d'une heure.
- Emplacement : Pour une meilleur sécurité une tolérance de +0.2 mm dans le boîtier serais plus optimal pour prévenir un éventuel gonflement naturel de la cellule LiPo en fin de vie.
- Tension & Courant de charge : La batterie est alimenté à 4.2V. Pour maximiser sa durée de vie, le circuit de charge sera configuré avec une résistance de programmation limitant le courant à 180 mA.
Le Pointeur Laser
Élément incontournable d'une télécommande de présentation, le module laser rouge (5mW / 650nm) permet à l'orateur de mettre en évidence des éléments clés sur son support visuel.
D'un point de vue de la conception électronique, nous avons délibérément choisi d'appliquer le principe KISS (Keep It Simple, Stupid) pour ce circuit. Plutôt que de piloter le laser via une broche du microcontrôleur et un transistor, l'architecture repose sur une connexion matérielle directe :
- Circuit en série direct : Le laser est alimenté directement par la tension de la batterie (VBAT_SW), en passant simplement par un bouton poussoir dédié.
- Avantages de cette architecture : Ce choix permet de libérer des broches d'entrées/sorties sur l'ATmega32U4 et d'alléger le code C (aucune ligne de code n'est requise pour le laser). De plus, le système offre une latence nulle et une fiabilité totale : même si le microcontrôleur est occupé par une tâche complexe ou subit un plantage, le laser fonctionnera toujours.
L'Écran OLED (Interface Visuelle)
L'écran OLED (généralement un module de 1.3 pouces) constitue le tableau de bord de la télécommande. Très économe en énergie (les pixels noirs ne consommant rien), il permet de fournir à l'orateur des informations critiques sans le distraire : temps écoulé (chronomètre), niveau de batterie restant, et confirmation de la connexion radio avec le socle récepteur.
L'intégration de ce module s'articule autour des choix techniques suivants :
- Communication I²C : L'écran dialogue avec le microcontrôleur ATmega32U4 via le bus I²C (broches SDA pour les données et SCL pour l'horloge). Ce choix permet de minimiser le nombre de pistes sur le circuit imprimé (seulement 2 fils de données nécessaires).
- Cohérence des niveaux logiques : Contrairement au moteur ou au laser, l'écran OLED est alimenté par le réseau régulé +3V3. Il est crucial que l'écran et le microcontrôleur partagent exactement la même tension d'alimentation (3.3V) pour que leurs signaux logiques (les 0 et les 1) soient parfaitement compatibles sans nécessiter de convertisseur de niveau logique (Level Shifter).
Contrôleur de charge MAX1873REEE+
Le MAX1873REEE est le cerveau de la gestion énergétique de notre télécommande. Son rôle est de transformer la tension d'entrée (USB) pour charger la batterie LiPo en toute sécurité.
Rôle :
- Protection de la batterie : le côntroleur de charge assure que la batterie LP-402933 ne dépasse jamais 4.2V, évitant ainsi tout risque de gonflement ou d'incendie dans le boîtier fermé et compact. Il gère le cycle de charge intelligent (Courant Constant / Tension Constante). Il protège donc la batterie contre les pics d'intensité qui pourraient réduire sa durée de vie.
- Gestion thermique : Contrairement à des chargeurs basiques, le MAX1873REEE+ est un contrôleur à découpage qui chauffe très peu. C'est un point clé car la télécommande sera tenue en main et donc une chauffe excessive serait inconfortable pour l'utilisateur pendant une présentation
- Indicateur d'état : Il permet au système de savoir quand la charge est terminée, ce qui nous permet d'éteindre la LED de charge.
Carte électronique du Récepteur (Receiver Board)
La conception et la validation du socle récepteur (dongle USB) ont été menées de manière rigoureuse. L'ensemble de l'archive de conception est disponible ici : Fichier:2025-PSE-BB-systeme.zip.
1. Conception et Réalisation Matérielle (CAO)
La carte a été entièrement routée sous KiCad pour répondre à des contraintes de compacité inhérentes à un dongle USB.
Schématique et Routage
La conception assistée par ordinateur (CAO) de la carte s'est déroulée en deux phases distinctes sous KiCad : la saisie du schéma de principe et le placement-routage.
- Schéma électronique : Il intègre le cœur du système (le microcontrôleur ATmega32U4), le circuit d'horloge (quartz externe), les lignes de filtrage pour sécuriser l'alimentation USB, ainsi que l'interfaçage avec le module de communication radio.
- Routage : Un soin particulier a été apporté au placement des composants CMS pour minimiser l'encombrement. Un plan de masse continu a été configuré pour limiter les interférences électromagnétiques (bruits) et garantir une transmission de données fiable.
|
|
| Figure 1 : Schéma de principe Saisie de l'architecture matérielle globale, de l'alimentation USB à la gestion des signaux logiques. |
Figure 2 : Routage (PCB) Aperçu du tracé des pistes et de l'optimisation de l'espace, avec application d'un plan de masse global. |
Assemblage Physique
Le passage du virtuel au réel s'est fait par une phase de brasage minutieuse des composants montés en surface (CMS) au sein des laboratoires de l'école.
 Figure 1 : Circuit imprimé (PCB) nu reçu après fabrication. |
 Figure 2 : Carte réceptrice après brasage complet des composants CMS. |
 Figure 3 : Modélisation 3D de contrôle de la carte réceptrice. | |
2. Diagnostic Matériel (Test Up)
Pour valider le comportement dynamique de la carte et vérifier l'intégrité de nos soudures avant toute communication complexe, nous avons implémenté un programme de test visuel ("Test Up").
- Comportement observé : Lors du branchement, la LED rouge s'allume fixement (validation de la présence de la tension d'alimentation de 5V). Immédiatement après, la LED verte se met à clignoter à fréquence régulière.
- Signification technique : Ce signal confirme que le microcontrôleur n'est pas bloqué, que l'horloge système externe (quartz) oscille correctement et que les broches GPIO sont fonctionnelles.
Code de test associé (Clignotement LED verte) :
#include <avr/io.h>
#include <util/delay.h>
#include <avr/power.h>
#include <avr/wdt.h>
int main(void) {
// 1. Désactivation du Watchdog pour éviter les reboots intempestifs
cli();
MCUSR &= ~(1 << WDRF);
wdt_disable();
// 2. Configuration de l'horloge système
clock_prescale_set(clock_div_1); // Fonctionnement à pleine vitesse
// 3. Configuration de la broche de la LED verte en sortie
DDRF |= (1 << PF1); // (Broche PF1 à adapter selon routage exact)
// 4. Boucle infinie de clignotement
while (1) {
PORTF ^= (1 << PF1); // Inverse l'état de la LED
_delay_ms(500); // Pause de 500 millisecondes
}
return 0;
}
3. Validation de l'Énumération USB (Bootloader vs Firmware)
- Emplacement du code source :
2025_PSE_G11_jngalamo_esamake/Logiciel/receiver_board_code/LUFA/PolytechLille/receiver_board
Arborescence de la configuration USB (Récepteur)
Le code responsable de l'identité USB de la carte réceptrice se trouve dans le répertoire mentionné ci-dessus. Il est structuré de la manière suivante :
Descriptors.c / .h: Fichiers contenant la déclaration formelle du périphérique en mode HID (Clavier) et définissant la chaîne de caractères personnalisée "Jospen && samake SMART PRESENTER Receiver".receiver_board.c: Fichier principal gérant la boucle d'exécution, l'initialisation matérielle et la gestion de la pile USB LUFA.Makefile: Fichier de compilation configuré pour cibler l'architecture matérielle de l'ATmega32U4.
La validation de l'interface USB s'est effectuée par étapes sous Linux. Nous avons analysé le comportement de la carte à sa sortie d'usine, puis après l'injection de notre propre pile logicielle (firmware HID).
Étape A : Détection de la puce vierge (Mode DFU)
Avant toute programmation, la carte contient le programme de démarrage d'usine d'Atmel.
 Détection globale : Le système détecte un périphérique Atmel Corp. |
 Zoom sur l'identité : L'identifiant 03eb:2ff4 Atmel Corp. atmega32u4 DFU bootloader confirme que la puce est prête à être flashée.
|
Étape B : Détection de notre Firmware personnalisé (Mode HID)
Après avoir compilé et téléversé notre code basé sur la bibliothèque LUFA, la carte doit changer d'identité pour devenir notre propre périphérique "SMART PRESENTER".
 Détection globale : La carte n'est plus un composant générique Atmel, elle répond sous un nouveau nom sur le bus USB. |
 Zoom sur l'identité propre : La carte s'énumère avec succès sous notre identité unique : Jospen && samake SMART PRESENTER Receiver.
|
4. Analyse Approfondie du Descripteur HID
Pour prouver que notre carte ne se contente pas d'afficher un nom, mais qu'elle est bien structurée pour agir comme un clavier physique, nous avons interrogé la description profonde du périphérique avec la commande lsusb -vvvv.
L'analyse de cette longue liste confirme trois points techniques essentiels à la réussite de notre projet :
bMaxPower 100mA: Indique que notre carte est éco-conçue et informe l'hôte qu'elle ne dépassera pas un appel de courant de 100 mA, se conformant parfaitement aux exigences d'alimentation de la norme USB.bInterfaceClass 3 Human Interface Device: Prouve que le système d'exploitation charge automatiquement le pilote universel des périphériques d'interface humaine (HID). La carte est ainsi "Plug & Play" (aucun pilote à installer).bInterfaceProtocol 1 Keyboard: Valide la configuration fonctionnelle finale de notre firmware LUFA. La carte est reconnue nativement comme un clavier matériel, ce qui lui donne l'autorisation d'envoyer les frappes (flèches droite/gauche) nécessaires au changement de diapositive.
5. Bilan Fonctionnel du Récepteur
- Points validés :
- L'alimentation électrique et l'intégrité de la couche matérielle (PCB et brasures) sont parfaites.
- L'interface USB, la déclaration des descripteurs de périphériques, l'attribution du nom personnalisé et l'émulation clavier (HID) fonctionnent de manière optimale.
- Limitations actuelles :
- À l'instar de la carte principale, le module de transmission radio présente des dysfonctionnements physiques ou de configuration. La communication sans-fil entre l'émetteur et ce récepteur est actuellement bloquée, nécessitant une phase de débogage approfondie sur l'étage RF.
Carte électronique du MAIN BOARD
Carte réalisée en utilisant le logiciel KiCAD : Fichier:2025-PSE-BB-systeme.zip.
Conception de la carte
Schématique sous KiCad
La première étape de notre conception matérielle a consisté à réaliser le schéma électrique global de la télécommande sous KiCad. Nous avons veillé à y intégrer et structurer logiquement tous les blocs fonctionnels : le microcontrôleur central (ATmega32U4), le circuit de gestion de l'alimentation et de recharge de la batterie, le module radio, ainsi que les interfaces utilisateur (écran OLED, boutons, moteur haptique).
Routage de la carte
Une fois l'architecture validée, nous sommes passés à la conception du circuit imprimé (PCB). Le défi majeur de cette étape a été la contrainte de taille : il a fallu agencer l'ensemble des composants CMS de manière très compacte pour garantir une bonne ergonomie en main, tout en optimisant le placement et en respectant les règles de conception (DRC) pour le tracé des pistes.
Résultat du routage :
Résultats 3D
Avant de lancer l'usinage des cartes, la prévisualisation 3D de KiCad nous a été très utile. Elle nous a permis de valider visuellement l'encombrement des composants (notamment la hauteur de l'écran et des boutons) et de confirmer que l'assemblage mécanique global serait cohérent.
Cartes physiques : Réception et Assemblage
Le passage du modèle virtuel (CAO) à l'élément physique s'est articulé autour de deux étapes clés : le contrôle de l'intégrité du circuit imprimé reçu et le brasage minutieux de l'ensemble des composants montés en surface (CMS).
Voici l'évolution visuelle de notre carte principale :
|
|
| Figure 1 : Circuit imprimé nu Aperçu du PCB à sa réception de l'usine. Étape de vérification des pistes, du plan de masse et de l'alignement des empreintes avant le dépôt du flux de soudure. |
Figure 2 : Carte finale assemblée Rendu après le brasage des composants CMS en laboratoire. Les joints de soudure ont été inspectés pour écarter tout risque de court-circuit ou de perle de soudure isolée. |
Un nettoyage final à l'isopropanol a été effectué après l'assemblage pour éliminer les résidus de flux et garantir une conductivité optimale avant la première mise sous tension (Test Up).
Validation des Sous-Systèmes
Voici les différentes étapes de validation pour chaque composant et périphérique de la carte.
Test des Boutons Poussoirs
- État de validation : ✅ Fonctionnel
- Commentaire : Les appuis sur les boutons sont correctement détectés. Le filtrage anti-rebond (matériel/logiciel) est efficace et les interruptions se déclenchent sans faux positifs.
Code de test associé :
#include <avr/io.h>
#include <avr/wdt.h>
#include <avr/power.h>
#include <avr/interrupt.h>
#define LED_DATA PF1
#define BTN_NEXT PF4
#define BTN_START PF5
#define BTN_PREV PF6
int main(void) {
// SÉQUENCE DE NETTOYAGE ET SÉCURITÉ
cli();
MCUSR &= ~(1 << WDRF);
wdt_disable();
clock_prescale_set(clock_div_1);
// DÉSACTIVATION DU JTAG (La clé du problème)
// Pour libérer les broches PF4, PF5, PF6 et PF7, il faut mettre
// le bit JTD (JTAG Disable) à 1 dans le registre MCUCR.
// SÉCURITÉ ATMEL : L'instruction doit être répétée 2 fois consécutivement !
MCUCR |= (1 << JTD);
MCUCR |= (1 << JTD);
// CONFIGURATION DES BROCHES
DDRF |= (1 << LED_DATA);
DDRF &= ~((1 << BTN_NEXT) | (1 << BTN_START) | (1 << BTN_PREV));
PORTF |= ((1 << BTN_NEXT) | (1 << BTN_START) | (1 << BTN_PREV));
PORTF &= ~(1 << LED_DATA);
sei();
// BOUCLE INFINIE
while (1) {
if (!(PINF & (1 << BTN_NEXT)) ||
!(PINF & (1 << BTN_START)) ||
!(PINF & (1 << BTN_PREV))) {
PORTF |= (1 << LED_DATA); // Allume la LED
} else {
PORTF &= ~(1 << LED_DATA); // Eteint la LED
}
}
return 0;
}
Test des Microcontrôleurs
- État de validation : ✅ Fonctionnel
- Commentaire : Le microcontrôleur est bien alimenté, l'oscillateur fonctionne à la fréquence attendue, et la communication avec l'interface de programmation/débogage s'établit sans erreur (clignotement de la LED de statut validé).
Code de test associé :
#include <avr/io.h>
#include <util/delay.h>
#include <avr/power.h>
#include <avr/wdt.h> // Bibliothèque du Watchdog
#include <avr/interrupt.h> // Bibliothèque des interruptions
int main(void) {
// SÉQUENCE DE NETTOYAGE ABSOLU
cli(); // 1. Couper toutes les interruptions (crucial pour l'horloge)
MCUSR &= ~(1 << WDRF); // 2. Effacer le drapeau de redémarrage du Watchdog
wdt_disable(); // 3. Désactiver totalement le Watchdog
// CONFIGURATION DE L'HORLOGE
clock_prescale_set(clock_div_1); // 4. Forcer la vitesse à 8 MHz
// CONFIGURATION DES BROCHES
DDRF |= (1 << PF1);
while (1) {
PORTF ^= (1 << PF1);
_delay_ms(150);
}
return 0;
}
Test du Module Laser
- État de validation : ✅ Fonctionnel
- Commentaire : L'activation de la broche de commande déclenche correctement l'émission du laser. La puissance délivrée est stable et la coupure est instantanée à la désactivation.
Code de test associé :
/* * Remplace ce bloc par ton code de test.
* Exemple : Activation/Désactivation d'une broche GPIO pour piloter le transistor du laser.
*/
Test de l'Écran OLED
- État de validation : ✅ Fonctionnel
- Commentaire : La communication I2C/SPI avec l'écran est établie. L'initialisation de l'affichage réussit et les pixels s'allument correctement sans artefacts visuels.
Code de test associé :
#include <avr/io.h>
#include <util/delay.h>
#include <avr/wdt.h>
#include <avr/power.h> // Ajouté pour sécuriser l'horloge
#define OLED_ADDR 0x78
// =========================================================================
// 1. PILOTE I2C MATÉRIEL (TWI)
// =========================================================================
void i2c_init(void) {
TWSR = 0x00;
TWBR = ((F_CPU / 100000UL) - 16) / 2;
TWCR = (1 << TWEN);
}
void i2c_start(void) {
TWCR = (1 << TWINT) | (1 << TWSTA) | (1 << TWEN);
while (!(TWCR & (1 << TWINT)));
}
void i2c_stop(void) {
TWCR = (1 << TWINT) | (1 << TWSTO) | (1 << TWEN);
}
void i2c_write(uint8_t data) {
TWDR = data;
TWCR = (1 << TWINT) | (1 << TWEN);
while (!(TWCR & (1 << TWINT)));
}
// =========================================================================
// 2. PILOTE ÉCRAN OLED (SH1106)
// =========================================================================
void oled_command(uint8_t cmd) {
i2c_start(); i2c_write(OLED_ADDR); i2c_write(0x00); i2c_write(cmd); i2c_stop();
}
void oled_data(uint8_t data) {
i2c_start(); i2c_write(OLED_ADDR); i2c_write(0x40); i2c_write(data); i2c_stop();
}
void oled_init(void) {
_delay_ms(100);
oled_command(0xAE); oled_command(0xC8); oled_command(0xA1);
oled_command(0x81); oled_command(0x7F); oled_command(0xA6);
oled_command(0xAF);
}
void oled_clear(void) {
for (uint8_t page = 0; page < 8; page++) {
oled_command(0xB0 + page);
oled_command(0x02); // Offset pour écran 1.3" (SH1106)
oled_command(0x10);
for (uint8_t col = 0; col < 128; col++) {
oled_data(0x00); // 0x00 = pixel éteint (noir)
}
}
}
// Fonction pour positionner le curseur
// page : 0 à 7 (lignes horizontales)
// col : 0 à 127 (pixels verticaux)
void oled_set_cursor(uint8_t page, uint8_t col) {
col += 2; // Décalage indispensable pour le contrôleur SH1106
oled_command(0xB0 + page);
oled_command(0x00 | (col & 0x0F));
oled_command(0x10 | ((col >> 4) & 0x0F));
}
// =========================================================================
// 3. GESTION DU TEXTE ET POLICE D'ÉCRITURE
// =========================================================================
// Mini-police pour les lettres de A à Z (5 colonnes de large par caractère)
const uint8_t font_mini[][5] = {
{0x00, 0x00, 0x00, 0x00, 0x00}, // Espace (Index 0)
{0x7E, 0x11, 0x11, 0x11, 0x7E}, // A (Index 1)
{0x7F, 0x49, 0x49, 0x49, 0x36}, // B
{0x3E, 0x41, 0x41, 0x41, 0x22}, // C
{0x7F, 0x41, 0x41, 0x22, 0x1C}, // D
{0x7F, 0x49, 0x49, 0x49, 0x41}, // E
{0x7F, 0x09, 0x09, 0x09, 0x01}, // F
{0x3E, 0x41, 0x49, 0x49, 0x7A}, // G
{0x7F, 0x08, 0x08, 0x08, 0x7F}, // H
{0x00, 0x41, 0x7F, 0x41, 0x00}, // I
{0x20, 0x40, 0x41, 0x3F, 0x01}, // J
{0x7F, 0x08, 0x14, 0x22, 0x41}, // K
{0x7F, 0x40, 0x40, 0x40, 0x40}, // L
{0x7F, 0x02, 0x0C, 0x02, 0x7F}, // M
{0x7F, 0x04, 0x08, 0x10, 0x7F}, // N
{0x3E, 0x41, 0x41, 0x41, 0x3E}, // O
{0x7F, 0x09, 0x09, 0x09, 0x06}, // P
{0x3E, 0x41, 0x51, 0x21, 0x5E}, // Q
{0x7F, 0x09, 0x19, 0x29, 0x46}, // R
{0x46, 0x49, 0x49, 0x49, 0x31}, // S
{0x01, 0x01, 0x7F, 0x01, 0x01}, // T
{0x3F, 0x40, 0x40, 0x40, 0x3F}, // U
{0x1F, 0x20, 0x40, 0x20, 0x1F}, // V
{0x3F, 0x40, 0x38, 0x40, 0x3F}, // W
{0x63, 0x14, 0x08, 0x14, 0x63}, // X
{0x07, 0x08, 0x70, 0x08, 0x07}, // Y
{0x61, 0x51, 0x49, 0x45, 0x43} // Z (Index 26)
};
// Dessine un caractère à l'emplacement actuel du curseur
void oled_print_char(char c) {
// Conversion automatique des minuscules en majuscules
if (c >= 'a' && c <= 'z') c -= 32;
// Si le caractère n'est ni une lettre ni un espace, on met un espace
if ((c < 'A' || c > 'Z') && c != ' ') c = ' ';
uint8_t index = (c == ' ') ? 0 : (c - 'A' + 1);
for (uint8_t i = 0; i < 5; i++) {
oled_data(font_mini[index][i]);
}
oled_data(0x00); // 1 pixel d'espace vide entre chaque lettre pour la lisibilité
}
// Dessine une phrase complète à une page (ligne) et colonne données
void oled_print_string(uint8_t page, uint8_t col, const char* str) {
oled_set_cursor(page, col);
while (*str) {
oled_print_char(*str++);
}
}
// =========================================================================
// PROGRAMME PRINCIPAL
// =========================================================================
int main(void) {
// Nettoyage et sécurisation de l'horloge
MCUSR = 0;
wdt_disable();
clock_prescale_set(clock_div_1); // Force l'horloge à tourner à sa vitesse normale
// Initialisation
i2c_init();
oled_init();
// Vider l'écran des parasites de démarrage
oled_clear();
// Affichage centré (Page 3 = Milieu vertical, Col 20 = Marge à gauche)
oled_print_string(3, 20, "bonjour jospen");
// afficher samake juste en bas
oled_print_string(5, 20, "Samake");
while (1) {
// L'écran garde les pixels en mémoire tout seul.
// Le microcontrôleur n'a plus rien à faire ici !
}
return 0;
}
Test du Circuit de Charge de la Batterie
- État de validation : ✅ Fonctionnel
- Commentaire : Le circuit de gestion de l'alimentation régule bien la tension. La détection de branchement USB bascule l'alimentation, et le courant de charge mesuré vers la batterie correspond aux spécifications du composant. La lecture de la tension via l'ADC (`VBAT_MEASURE`) est précise.
Code de test associé :
/* * Remplace ce bloc par ton code de test.
* Exemple : Lecture de la valeur ADC de VBAT et conversion en tension.
*/
Test du Moteur ERM (Vibreur)
- État de validation : ✅ Fonctionnel
- Commentaire : Le moteur ERM est entièrement opérationnel. Le contrôle de l'intensité de la vibration s'effectue avec succès par modulation de largeur d'impulsion (PWM), permettant de faire varier la puissance du retour haptique de manière fluide et précise.
Code de test associé :
#include <avr/io.h>
#include <util/delay.h>
#include <avr/power.h>
#include <avr/wdt.h>
// Inclusion de notre pilote moteur
#include "motor.h"
int main(void) {
// 1. Sécurités de démarrage
MCUSR = 0;
wdt_disable();
clock_prescale_set(clock_div_1); // Horloge à 8 MHz
// 2. Initialisation du moteur (Configure PB5 en sortie)
motor_init();
// 3. Configuration de la LED principale (PF1) pour le retour visuel
DDRF |= (1 << PF1);
PORTF &= ~(1 << PF1); // LED éteinte au démarrage
// Boucle infinie : Le "battement de cœur" haptique
while (1) {
// DÉBUT DE LA VIBRATION
// Allumer la LED
PORTF |= (1 << PF1);
// Générer une vibration assez longue (200 millisecondes) pour bien la sentir
motor_pulse(200);
// FIN DE LA VIBRATION
// Éteindre la LED
PORTF &= ~(1 << PF1);
// Attendre 2 secondes en silence complet avant la prochaine vibration
_delay_ms(2000);
}
return 0;
}
Configuration de la Communication USB (Plan initial vs Adaptation)
- État de validation : ✅ Fonctionnel (Solution de contournement filaire)
- Emplacement du projet :
2025_PSE_G11_jngalamo_esamake/Logiciel/Main_Board/firmware/LUFA/PolytechLille/keyboard_COM
Arborescence de configuration USB
Le firmware est structuré pour permettre la compilation dynamique de nos descripteurs. La configuration USB se situe précisément dans le répertoire cité ci-dessus :
Descriptors.c / .h: Contient la définition des descripteurs USB (Vendor ID, Product ID, Interfaces HID/CDC). C'est ici que le nom "HaptiPointer" est déclaré.keyboard_COM.c(Fichier principal) : Gère la logique des interfaces hybrides, l'initialisation de la pile LUFA et le traitement des interruptions.Makefile: Définit les paramètres de compilation pour l'ATmega32U4.
- Explication technique des choix d'architecture :
1. Plan Initial : Architecture Distribuée (Radio requise)
À l'origine, la carte principale (télécommande) devait être configurée uniquement en périphérique CDC (Port Série Virtuel). Ce mode exclusif permettait à notre application PC « HaptiPointer Studio V1.1 » de téléverser et de stocker les données de la présentation directement dans l'EEPROM de la télécommande.
En situation de présentation, la télécommande devait être totalement autonome physiquement. Elle devait envoyer ses commandes de navigation (diapositive suivante/précédente) par liaison radio au socle récepteur (dongle USB). Ce dernier, configuré en périphérique HID (clavier standard), se chargeait alors de "taper" les touches de clavier correspondantes pour piloter l'ordinateur.
Pour valider cette première étape, nous avions configuré avec succès la carte principale en mode CDC pur, comme le prouvent les captures de l'énumération USB ci-dessous :
 1. Détection globale : Exécution de la commande "lsusb" montrant la détection du périphérique CDC. |
 2. Zoom sur l'ID : La carte s'identifie bien avec le nom de notre projet "HaptiPointer" (ID 0333:2004). |
 3. Descripteur global : Affichage détaillé des classes et interfaces via "lsusb -vvvv". |
 4. Validation CDC : Confirmation de la présence de la classe "Communications" (Abstract modem) indispensable pour le transfert série. |
2. Adaptation : Architecture Intégrée (Mode Hybride Filaire)
Face à la défaillance inattendue du module sans-fil matériel, nous avons dû adapter notre firmware pour maintenir la fonctionnalité du système. Pour que la télécommande reste utilisable, nous avons opté pour une liaison filaire USB directe entre la carte principale et le PC, en contournant totalement le récepteur.
La carte principale a donc été reconfigurée en périphérique USB Composite (Hybride). Elle gère désormais simultanément, sur un unique port USB, deux interfaces logiques distinctes qui ne rentrent pas en conflit :
- Une interface HID (Human Interface Device) : Elle agit nativement comme un clavier standard pour envoyer les commandes de navigation (flèches droite/gauche) directement à l'ordinateur lors du passage des diapositives.
- Une interface CDC (Communication Device Class) : Elle conserve le lien série virtuel (port COM série), permettant à l'application HaptiPointer Studio V1.1 de continuer à transmettre les données de configuration de la présentation vers la télécommande.
Pour vérifier la bonne énumération de cette implémentation hybride sous notre environnement de développement Linux, nous avons utilisé l'utilitaire système d'analyse des bus USB. Voici les résultats détaillés de la détection de notre carte (avec son Vendor ID / Product ID spécifique 0333:2004) :
 1. Détection globale : Exécution de la commande "lsusb" montrant les périphériques connectés. |
 2. Zoom sur l'ID : Ligne de détection de notre télécommande (ID 0333:2004). |
 3. Descripteur global : Exécution de "lsusb -vvvv -d 0333:2004". |
 4. Suite du descripteur : Confirmation de l'assignation des Endpoints pour le combo HID et CDC. |
3. Analyse du descripteur USB
L'analyse détaillée du périphérique (visibles sur les captures 3 et 4) confirme que notre firmware composite est correctement énuméré par le système d'exploitation hôte. Le système détecte bien une architecture à interfaces multiples :
- L'interface CDC (Port COM virtuel) : Le descripteur indique clairement la présence d'une classe de communication (
Communications / Abstract (modem)). On y retrouve les points d'accès (Endpoints) nécessaires pour une liaison série bidirectionnelle, notamment les Endpoints de typeBulk(IN et OUT) pour le transfert asynchrone des données de présentation depuis l'application HaptiPointer Studio. - L'interface HID (Clavier) : Le descripteur expose également une classe Human Interface Device (
Human Interface Device / Boot Interface Subclass / Keyboard). On y observe un Endpoint de typeInterrupt IN, qui est spécifiquement dédié à l'envoi immédiat et prioritaire des frappes de touches (flèches de navigation) vers le PC.
Cette énumération prouve que l'ordinateur alloue correctement la bande passante et charge les pilotes natifs requis pour faire cohabiter le transfert de données série et l'émulation de clavier sur un seul et même câble USB.
Application PC : "HaptiPointer Studio V1.1"
L'application "HaptiPointer Studio" est le pivot logiciel qui transforme notre télécommande d'un simple accessoire statique en un outil de présentation intelligent et personnalisable. Elle fait le pont entre la configuration sur PC et le matériel embarqué.
- Emplacement du projet :
2025_PSE_G11_jngalamo_esamake/Logiciel/Main_Board/Software
1. Rôle conceptuel dans le projet
Au-delà d'une simple interface, HaptiPointer Studio constitue l'élément différenciateur qui donne à notre projet son caractère "Smart".
Dans le cadre du SMART PRESENTER, cette application résout une problématique majeure des télécommandes classiques : la rigidité matérielle. Elle permet de dissocier le micrologiciel (firmware) gravé dans l'ATmega32U4 des données spécifiques à chaque conférence. Ainsi, la télécommande devient un outil générique, adaptable en quelques secondes à n'importe quel timing ou structure de présentation. En automatisant la gestion des données, l'application garantit que l'orateur se concentre sur son public plutôt que sur la complexité technique de son matériel.
2. Rôle opérationnel : Le chef d'orchestre de la télécommande
Le rôle fondamental de cette application (développée en Python) est de rendre la télécommande matériellement autonome lors du discours. Au lieu de devoir recompiler le code C de la carte à chaque nouvelle présentation, l'application permet de :
- Centraliser la structure temporelle : Créer une liste ordonnée de diapositives, en assignant à chacune un titre et un temps de parole via une interface graphique ergonomique.
- Transférer les données (USB CDC) : Compiler ces informations dans une trame de données structurée et l'envoyer via le Port Série Virtuel (COM) directement dans la mémoire non-volatile (EEPROM) du microcontrôleur. La carte "apprend" ainsi le déroulement exact de l'intervention.
- Valider la communication (Handshake) : Assurer un dialogue bidirectionnel sécurisé. L'application attend une réponse de confirmation (trame "BINGO") de la part de la carte pour valider à l'utilisateur que les données ont été gravées avec succès sans corruption.
3. Interface et Démonstration
Le développement de l'interface graphique a été pensé pour être intuitif et léger, nécessitant très peu de ressources système.
Démonstration vidéo du transfert de données vers la carte :
Travail effectué
Voici l'état d'avancement des travaux de conception de notre télécommande :
📅 16 février 2026
- Choix du projet : Après l'émergence de plusieurs idées (écran de monitoring et régulation de température, conception d'une manette de jeu, etc.), nous avons finalement décidé de réaliser une télécommande intelligente pour la gestion des présentations. Elle inclura plusieurs fonctionnalités pour aider au mieux l'orateur, comme le contrôle des diapositives et des alertes temporelles bien définies. Nous avons nommé notre projet : SMART PRESENTER.
- Mise en place des outils : Création, configuration et structuration du dépôt Git pour faciliter le partage des fichiers au sein du binôme et permettre le suivi par les examinateurs.
- Documentation : Configuration du Wiki pour tracer nos choix techniques et afficher nos résultats (faisant office de rapport écrit continu de notre travail).
📅 2 mars 2026
Après avoir validé le choix du projet et les configurations initiales, nous sommes passés à la phase de spécification et de conception :
- Définition détaillée des différentes fonctionnalités de la carte.
- Organisation du travail et finalisation de l'architecture globale du système. Il en ressort la nécessité de fabriquer deux cartes distinctes : un socle récepteur (dongle USB) et une télécommande principale sur batterie.
- Début de la conception du schéma électrique pour le socle récepteur (choix des composants et validation de l'architecture).
- Mise à jour du dépôt Git et du Wiki.
📅 9 mars 2026
- Revue de conception : Contrôle et validation du schéma du socle récepteur par l'examinateur. Quelques corrections ont été apportées suite à ses retours pour fiabiliser la carte.
- Nomenclature : Établissement de la liste des composants (BOM) du socle récepteur avec l'identification des références Mouser exactes en vue de l'achat.
- Carte principale : Début de la conception schématique de la télécommande principale (SMART PRESENTER).
📅 17 mars 2026
- Fin des corrections des deux cartes (main_board et receiver_board) de notre télécommande.
- Assignations des empreintes des composants des deux cartes.
- Début du routage de la receiver_board.
📅 24 mars 2026
- Corrections des dernières erreurs sur les deux cartes (main_board et receiver_board) après remarques du prof.
- Fin du routage de la receiver_board.
📅 31 mars 2026
- Routage et Fabrication : Réalisation et finalisation du routage de la carte principale (main_board). Lancement des vérifications des règles de conception (DRC).
- Génération des fichiers : Création des fichiers de fabrication (fichiers Gerber et de perçage) pour l'ensemble du système et préparation de la commande des circuits imprimés.
📅 7 avril 2026
- Développement Firmware : Mise en place de l'environnement de travail pour la programmation bas niveau des microcontrôleurs (ATmega32U4).
- Pile USB : Début de l'implémentation de la communication via la bibliothèque LUFA pour configurer le socle récepteur afin qu'il soit reconnu correctement par l'ordinateur en USB CDC.
📅 5 mai 2026
- Assemblage et Tests Matériels : Réception des circuits imprimés. Soudure des composants CMS et assemblage du socle récepteur ainsi que de la télécommande.
- Vérifications : Réalisation des premiers tests électriques (contrôle des courts-circuits, validation des tensions) et premiers essais de flashage des puces.
📅 12 mai 2026
- Programmation embarquée : Écriture des routines pour l'écriture et la lecture des données de présentation dans l'EEPROM de la télécommande.
- Protocole : Mise en place de la logique de la trame de transmission sécurisée pour faire communiquer efficacement la télécommande et le récepteur.
📅 18 mai 2026
- Développement Logiciel PC : Création de l'application de bureau "HaptiPointer Studio v1.1" développée en Python avec l'interface graphique Tkinter. Cette application a pour but de configurer et de transférer les données de présentation vers la télécommande.
📅 19 mai 2026
- Intégration Logiciel/Matériel : Tests de communication USB CDC entre HaptiPointer Studio et le matériel.
- Optimisation : Ajustement de la gestion des processus (thread handling) côté Python pour assurer un transfert de données fluide et sécurisé sans provoquer de blocage (freeze) de l'interface graphique.
📅 26 mai 2026
- Validation globale : Tests complets et intensifs du système global (SMART PRESENTER couplé à HaptiPointer Studio) en conditions réelles de présentation.
- Documentation finale : Rédaction de la documentation formelle sur le Wiki du projet (explication détaillée de la logique des trames et de l'architecture logicielle) et préparation pour la présentation finale.
Bilan et État d'Avancement
À l'issue de l'ensemble de nos séances de travail, voici le statut final de notre projet SMART PRESENTER. Nous avons dressé un bilan détaillé des fonctionnalités pour chacune des deux cartes constituant notre système.
📡 Carte Réceptrice (Receiver Board)
Le socle récepteur (dongle) a été assemblé, mais rencontre une limitation technique majeure :
- ❌ Module de communication sans-fil : Non fonctionnel. Le module radio ne parvient pas à établir une liaison stable/fonctionnelle avec la télécommande.
- ✅ Alimentation USB : Fonctionnelle (la carte est sous tension lorsqu'elle est branchée au PC).
- ✅ Communication USB : Fonctionnelle. La télécommande est bien reconnue par l'ordinateur comme un périphérique HID
🎛️ Carte Principale (Main Board - Télécommande)
La télécommande principale a été assemblée et testée avec succès sur la quasi-totalité de ses périphériques internes, à l'exception de la communication radio :
- ✅ Boutons de contrôle : Fonctionnels. La détection des appuis utilisateur est opérationnelle.
- ✅ Retour haptique (Moteur vibreur) : Fonctionnel. Les alertes vibratoires s'activent correctement.
- ✅ Écran OLED : Fonctionnel. L'affichage de l'interface et des données est net et réactif.
- ✅ Circuit de charge : Fonctionnel. La gestion de la batterie et sa recharge via le port USB s'effectuent sans problème.
- ✅ Communication USB : Fonctionnelle. La télécommande est bien reconnue par l'ordinateur et communique parfaitement en filaire (notamment avec notre application Python).
- ❌ Module de communication sans-fil : Non fonctionnel. Tout comme pour la base, la transmission radio des commandes n'a pas pu être finalisée.
🎥 Démonstration
Malgré l'absence de liaison sans-fil, la télécommande est capable de démontrer la majorité de ses capacités en local ou via USB. Voici une brève vidéo illustrant le fonctionnement global des périphériques opérationnels de notre programmateur :