SE3Groupe2025-4

Programmation des systèmes embarqués

Carte électronique

Carte réalisée en utilisant le logiciel KiCAD : Fichier:2025-PSE-04-systeme.zip.

Schéma électronique de la carte :

Mon schéma électronique

Résultat du routage :

Mon routage

Ma carte

Photo de la carte soudée :

Vidéo très courte et en basse résolution de la carte en fonctionnement :

Programmation

Test de la carte

Avant d’aborder la programmation USB avec LUFA, nous avons validé le bon fonctionnement de notre carte électronique avec un programme simple de clignotement des deux LEDs (connectées à PD0 et PD1).

Clignotement des LEDs (blink)

Ce code alterne l’état des deux LEDs toutes les 500 ms. Il configure également l’horloge externe à 16 MHz (si les fusibles ne sont pas encore programmés).

#include <avr/io.h>
#include <util/delay.h>

// Passage à l'horloge externe 16 MHz sans diviseur
static inline void clock_init(void) {
    CLKSEL0 = 0b00010101;   // sélection horloge externe
    CLKSEL1 = 0b00001111;   // fréquence mini 8 MHz
    CLKPR   = (1 << CLKPCE); // autorise la modification du diviseur
    CLKPR   = 0;             // diviseur = 1
}

int main(void) {
    clock_init();

    // PD0 et PD1 en sortie (LED1 sur PD0, LED2 sur PD1)
    DDRD |= (1 << PD0) | (1 << PD1);

    while (1) {
        PORTD |=  (1 << PD0); // LED1 allumée
        PORTD &= ~(1 << PD1); // LED2 éteinte
        _delay_ms(500);

        PORTD &= ~(1 << PD0); // LED1 éteinte
        PORTD |=  (1 << PD1); // LED2 allumée
        _delay_ms(500);
    }
}

Compilation et téléversement

Pour compiler, utilisez un Makefile adapté à l’ATmega8U2 (F_CPU=16000000). Le fichier hex généré est flashé via dfu-programmer :

make clean
make
sudo dfu-programmer atmega8u2 erase --force
sudo dfu-programmer atmega8u2 flash blink.hex
sudo dfu-programmer atmega8u2 reset

Après le reset, les deux LEDs clignotent en alternance. Ce test confirme que :

• Le microcontrôleur est correctement alimenté ;
• L’horloge externe 16 MHz fonctionne ;
• Les broches PD0 et PD1 sont accessibles et commandables ;
• Le chargeur DFU est opérationnel.

Gestion personnalisée des endpoints (IN/OUT)

L’objectif est de piloter directement les LEDs depuis le PC et de lire l’état des boutons, sans passer par la classe CDC. Pour cela, nous avons défini une interface USB générique (classe 0xFF) avec deux points d’accès de type INTERRUPT.

Descripteurs USB

Le fichier Descriptors.h déclare les adresses et la taille des endpoints :

#define LED_OUT_EPADDR  (ENDPOINT_DIR_OUT | 1)   // Endpoint 1 OUT
#define BTN_IN_EPADDR   (ENDPOINT_DIR_IN  | 2)   // Endpoint 2 IN
#define EP_SIZE         8

Dans Descriptors.c, la configuration est décrite avec une interface unique (bInterfaceClass = 0xFF) et deux endpoints :

const USB_Descriptor_Configuration_t PROGMEM ConfigurationDescriptor =
{
    .Config = { ... },
    .Interface =
    {
        .Header          = { .Size = sizeof(USB_Descriptor_Interface_t), .Type = DTYPE_Interface },
        .InterfaceNumber = 0,
        .TotalEndpoints  = 2,
        .Class           = 0xFF,   // Vendor-specific
        .SubClass        = 0x00,
        .Protocol        = 0x00,
    },
    .Endpoint_OUT = { ... },
    .Endpoint_IN  = { ... },
};

Les chaînes de caractères (fabricant, produit, numéro de série) sont également définies. Le callback CALLBACK_USB_GetDescriptor fournit ces descripteurs à l’hôte lors de l’énumération.

Code de la carte (CustomHID.c)

Le programme principal est simplifié : il initialise le matériel, démarre la pile USB, puis boucle sur les tâches USB et le traitement des endpoints.

Initialisation matérielle : - Les LEDs (PD0 et PD1) sont configurées en sortie. - Les boutons (PC4 et PC5) sont en entrée avec pull‑up internes. - Le watchdog est désactivé et l’horloge est mise à 16 MHz (si les fusibles ne sont pas encore programmés).

Traitement de l’endpoint OUT (process_out) : - Sélectionne l’endpoint OUT. - Si un paquet est reçu, lit un octet et applique ses bits 0 et 1 aux LEDs.

static void process_out(void)
{
    Endpoint_SelectEndpoint(EP_OUT);
    if (Endpoint_IsOUTReceived() && Endpoint_IsReadWriteAllowed())
    {
        uint8_t cmd = Endpoint_Read_8();
        LED_PORT = (LED_PORT & ~((1<<LED1_PIN)|(1<<LED2_PIN))) | (cmd & 0x03);
        Endpoint_ClearOUT();
    }
}

Traitement de l’endpoint IN (process_in) : - Sélectionne l’endpoint IN. - Si l’endpoint est prêt à écrire, lit l’état des deux boutons (bits PC4 et PC5) et les envoie dans un octet.

static void process_in(void)
{
    Endpoint_SelectEndpoint(EP_IN);
    if (Endpoint_IsReadWriteAllowed())
    {
        uint8_t buttons = PINC & ((1<<BTN1_PIN)|(1<<BTN2_PIN));
        Endpoint_Write_8(buttons);
        Endpoint_ClearIN();
    }
}

Événements USB : - EVENT_USB_Device_ConfigurationChanged configure les deux endpoints (taille 8, type INTERRUPT). - EVENT_USB_Device_ControlRequest gère les requêtes standard (délégation à LUFA).

La boucle principale appelle USB_USBTask() et les deux fonctions de traitement uniquement lorsque l’adresse USB est attribuée.

Programme PC (main_pc.c)

Le programme côté PC utilise la bibliothèque libusb-1.0 pour dialoguer avec la carte.

Initialisation : - Ouvre le périphérique par VID/PID (0x03EB / 0x2044). - Détache le pilote noyau si nécessaire. - Réclame l’interface (claim).

Contrôle des LEDs (OUT) : - Les touches 1, 2, 3 basculent respectivement les bits 5, 6, 7 (mais ici seuls les bits 0 et 1 sont utilisés). - La touche 0 éteint tout. - L’envoi se fait via libusb_interrupt_transfer sur l’endpoint OUT (adresse 0x01).

Lecture des boutons (IN) : - Une requête libusb_interrupt_transfer est effectuée périodiquement sur l’endpoint IN (0x82). - L’octet reçu est affiché, et un message indique quel bouton est pressé (SW3 sur PC4, SW4 sur PC5).

Le programme utilise select sur stdin pour ne pas bloquer, ce qui permet une interaction fluide.

Résultat attendu : - Le programme affiche l’état des boutons en temps réel. - En appuyant sur 1, 2, 3 ou 0, les LEDs (PD0 et PD1) s’allument/s’éteignent selon les commandes envoyées.

Cette validation est indispensable avant d’implémenter le protocole ISP, car nous allons réutiliser exactement ce même canal pour échanger des commandes SPI avec la cible.

Malheureusement après avoir flashé ce code, la carte arretait d'accepter la commande dfu-programmer atmega16u2 erase. Donc on ne peut pas avancer.

Voici une capture de la reconnaissance de la carte en LUFA.

lsusb

photo du programmeur 2 minutes après que je l'ai cramé

Bilan

10/03/2026:

Recherche de composants. Les composants trouvés sont :

- 74HC4067 : Démultiplexeur

- WL-SFTW SMT Full-color TOP LED : Led RGB

- Gestion des leds : TLC5947

Réflexion routage :

Vérification de possibilité du routage sur 2 couches uniquement. Une couche pour les leds, une couche pour les boutons.

17/03/2026:

Lecture des différentes datasheets pour savoir pour valider les choix trouvés.

Choix final de se limiter à deux drivers TLC et d'abandonner la piste du demultiplexeur

23/03/2026

Rectification du problème KiCad 10, remise du projet KiCad à la 9ᵉ version. Création de la liste finale des pièces à commander (cf. Composants à acheter).

24/03/2026:

Discussion sur les contraintes d'alimentation et le nombre des RGB à utiliser sur la carte.

Fin schema, choix des derniers composants pour communication entre les deux cartes.

31/03/2026:

Routage.

12/05/2026:

Récuperation de la carte.

18/05/2026:

Récupération des composants et début de la soudure

20/05/2026:

Soudure des composants. Nous avons cramé le uP en augmentant l'intensité des LEDs. donc on va chercher a le remplacer.

26/05/2026:

fin présumée de la soudure de la soudure et début du code. ce qui nous menait a détruire notre microprocesseur à cause d'une demande trop élevée de courant par les LEDs. Eventuellement la solution était de désouder la résistance de courant de la TLC et la remplacer par une résistance d'une valeur plus élevée (3,3k)

02/06/2026:

Séance bonus offerte par Mr. Boé, qui nous avait dit de faire un dernier flash en ISP. Ce dernier ne marchait pas donc nous avons désoudé le microprocesseur. Le nouveau microprocesseur étant finalement soudé, on a confirmé nos suspicions: L'ancien microprocesseur ne marchait vraiment pas. On peut désormais flasher le fichier hex dans la carte. il n'y a plus de composants qui se chauffent, on peut finalement attaquer la partie code.

Premier système embarqué

Archive GIT;

Mon archive GIT pour le projet KiCAD et pour les programmes : [1].

Archive privée. Binôme comme administrateur. Boé et Redon comme administrateur. - FAIT

Ajouter un .gitignore pour KiCAD et langage C. - FAIT

Structure avec matériel (y compris production - gerber, bill of materials) / logiciel / documentation (e.g. documentation technique).

Description du système embarqué

Nous prévoyons de faire un clavier, séparé en deux parties. Nous sommes en collaboration avec le groupe 16[2]. Le clavier sera capable de :

• récupérer les touches pressées par l'autre partie du clavier.
• Communiquer avec l'ordinateur pour envoyer les informations

Les communications seront réalisées en UART

Il s'agit d'un clavier ergonomique RGB au format matrice 5 × 6 (30 touches). La carte embarque un ATMega32U4 (quartz 16 MHz), une gestion complète de l’alimentation sur batterie Li‑ion (chargeur MAX1811 + boost MCP1640 vers 5 V), un rétroéclairage RGB individuel pour 16 touches (deux drivers PWM TLC5947 en cascade), et une prise jack 3,5 mm permettant la communication UART avec une seconde moitié de clavier (clavier ergonomique séparé).

La saisie est assurée par liaison USB en mode clavier HID (LUFA). La programmation se faisait à priori en ISP, mais eventuellement par USB (bootloader DFU).

Vue de la carte clavier finalisée

Matériel (Hardware)

Switches et sockets

Les switches mécaniques utilisés sont des modèles de la marque **KAILH**, disponibles au laboratoire. Nous avons également récupéré des **sockets hot‑swap** adaptées à ces switches. L’intérêt de ces modules est de pouvoir insérer ou retirer les boutons à volonté, sans qu’ils soient soudés directement au PCB (seules les sockets sont soudées). Cela facilite la réutilisation des boutons d’un projet à l’autre et améliore la réparabilité du clavier.

Matériel (Hardware)

Switches et sockets

Les switches mécaniques utilisés sont des modèles de la marque KAILH, disponibles au laboratoire. Nous avons également récupéré des sockets hot‑swap adaptées. Seules les sockets sont soudées sur le PCB, ce qui permet de changer les switches sans dessouder.

Alimentation

La carte peut être alimentée soit par le port USB (5 V), soit par une batterie Li‑ion (3,7 V nominal) connectée sur le connecteur J3. Un circuit de gestion de batterie et un convertisseur élévateur (boost) génèrent une tension stable de 5 V pour toute la logique (MCU, LEDs, drivers).

Chargeur Li-ion MAX1811

Le composant U1 (MAX1811) est un chargeur linéaire dédié aux batteries Li‑ion, alimenté directement par le 5 V USB. Ses broches de configuration permettent de choisir la tension de fin de charge et le courant de charge :

- SELV (pin 1) : sélectionne la tension de charge (4,1 V ou 4,2 V). Une résistance de tirage (R11 = 10 kΩ) fixe le niveau haut → tension de charge = 4,2 V. - SELI (pin 2) : choisit le courant de charge (100 mA ou 500 mA). La broche est pilotée par le MCU (PB0) pour moduler le courant en fonction de la source USB. - EN (pin 7) : maintenue à VUSB (5 V) via la résistance R4 (150 Ω) pour activer le chargeur en permanence. - /CHG (pin 8) : sortie à drain ouvert qui passe à l’état bas lorsque la batterie est en cours de charge. Une LED rouge D31 (anode sur VUSB, cathode sur /CHG) permet un affichage visuel de la charge.

Le condensateur C4 (4,7 µF) filtre l’entrée VUSB ; C5 (2,2 µF) et C6 (4,7 µF) sont placés sur la sortie BATT pour stabiliser la tension batterie.

Convertisseur Boost MCP1640

Le régulateur élévateur U3 (MCP1640) élève la tension de la batterie (typiquement 3,7 V, mais pouvant descendre jusqu’à 0,8 V en décharge profonde) à une sortie régulée de 5 V. La broche **EN** est connectée directement à la batterie (via J3) afin de démarrer le convertisseur dès qu’une batterie est présente.

La tension de sortie est fixée par un pont diviseur externe connecté sur la broche V_FB (pin 4) :

- R5 = 976 kΩ, R6 = 309 kΩ

La tension de référence interne est V_FB = 1,21 V. La tension de sortie se calcule par :

$V_{OUT}=V_{FB}\times \left(1+{\frac {R5}{R6}}\right)=1,21\times \left(1+{\frac {976}{309}}\right)\approx 1,21\times 4,158\approx 5,03\,V$

La valeur est bien proche de 5 V.

Choix de l’inductance L1 (4,7 µH)

La consommation estimée du système (MCU + 16 LEDs RGB à faible courant + drivers) est d’environ 300 mA sous 5 V. En tenant compte d’un rendement η ≈ 85 % (valeur typique pour ce convertisseur à charge moyenne), le courant moyen tiré de la batterie (3,7 V) est :

$I_{BAT}={\frac {V_{OUT}\times I_{OUT}}{V_{IN}\times \eta }}={\frac {5\times 0,3}{3,7\times 0,85}}\approx 0,477\,A$

L’ondulation du courant dans l’inductance est donnée par :

$\Delta I_{L}={\frac {V_{IN}\times D}{L\times f_{SW}}}$

avec un rapport cyclique typique $D=1-{\frac {V_{IN}}{V_{OUT}}}=1-{\frac {3,7}{5}}=0,26$, une fréquence de découpage $f_{SW}=500\,kHz$ (d’après la datasheet du MCP1640), et L = 4,7 µH.

$\Delta I_{L}={\frac {3,7\times 0,26}{4,7\times 10^{-6}\times 500\times 10^{3}}}\approx {\frac {0,962}{2,35}}\approx 0,409\,A$

Le courant de crête dans l’inductance vaut donc :

$I_{Lpeak}=I_{BAT}+{\frac {\Delta I_{L}}{2}}\approx 0,477+0,2045\approx 0,682\,A$

L’inductance choisie (référence XGL4020-471MEC ou équivalent) présente un courant de saturation supérieur à 1,5 A, ce qui garantit une marge confortable.

Filtrage d’entrée et de sortie

- Condensateur d’entrée C7 = 10 µF (faible ESR) pour minimiser l’impédance côté batterie. - Condensateurs de sortie C8 = 4,7 µF et C9 = 4,7 µF (en parallèle) pour réduire l’ondulation résiduelle et répondre aux appels de courant du MCU et des LEDs.

La sortie VCC (5 V) alimente l’ensemble du système : MCU (via ses broches VCC, AVCC, UVCC), les drivers TLC5947, et l’anode commune des LEDs RGB.

La section alimentation du circuit

Microcontrôleur ATMega32U4

Le cœur du système est un **ATMega32U4** (référence U2) cadencé à 16 MHz par un quartz externe (Y1). Ce microcontrôleur intègre un contrôleur USB matériel, ce qui permet de l’utiliser en périphérique HID sans composant additionnel.

Horloge et découplage

Un quartz Y1 (référence Crystal_GND24) au boîtier 3225 (3,2 × 2,5 mm) génère la fréquence de base de 16 MHz. Les capacités de charge C1 et C2 (22 pF chacune) sont connectées respectivement aux broches XTAL1 et XTAL2, l’autre borne étant reliée à la masse. Ces valeurs sont conformes à la préconisation de la datasheet pour un quartz à 16 MHz.

La formule approchée de la capacité de charge vue par le quartz est :

$C_{L}={\frac {C_{1}\cdot C_{2}}{C_{1}+C_{2}}}+C_{parasite}$

Avec C1 = C2 = 22 pF et une capacité parasite de l’ordre de 5 pF, on obtient C_L ≈ 16 pF, ce qui correspond aux spécifications des quartz courants.

L’alimentation du MCU est filtrée par plusieurs condensateurs de découplage placés au plus près des broches d’alimentation :

- C3 = 1 µF entre UCAP (pin 6) et GND – nécessaire à la stabilité du régulateur interne USB. - C10, C11, C12 = 0,1 µF chacun – découplage classique pour les broches VCC (pin 14), AVCC (pin 24) et UVCC (pin 2). - Les plans de masse sont interconnectés via les broches GND (pins 5, 15, 23, 35, 43, voir datasheet...).

Gestion de l’USB

Le port USB de type A (J1) est directement relié au MCU : - VBUS (pin 1 du connecteur) est envoyé sur la broche VBUS (pin 7) de l’ATmega32U4 pour détecter la présence du câble. - D+ (pin 3 du connecteur) et D- (pin 2) sont connectés respectivement aux broches D+ (pin 4) et D- (pin 3), eventuellement on découvre que c'est une erreur et que nous devrons mettre des résistances 22 Ω. - Le shield du connecteur (pin 5) est relié à la masse.

La programmation du bootloader DFU se fait par USB ; une fois le code chargé, le clavier est reconnu comme périphérique HID.

Connecteur ISP

Un connecteur AVR-ISP-6 (J4) au pas 2,54 mm permet la programmation par un programmateur externe (par exemple AVR ISP mkII). Le brochage est standard : - Pin 1 : MISO (PB3) - Pin 2 : VCC (5 V) - Pin 3 : SCK (PB1) - Pin 4 : MOSI (PB2) - Pin 5 : RESET (actif à l’état bas) - Pin 6 : GND

Des résistances de pull‑up de 10 kΩ (R7 et R8) sont placées respectivement sur les lignes HWB et RESET pour éviter les flottements.

Boutons RST et HWB

Deux boutons poussoirs (SW1 et SW2) sont disponibles : - SW2 connecté sur la broche RESET (pin 13) : un appui provoque une réinitialisation matérielle du microcontrôleur. - SW1 connecté sur la broche HWB (pin 33) : pendant le démarrage, maintenir ce bouton force le bootloader à attendre une programmation USB (mode DFU). En fonctionnement normal, cette broche peut être réutilisée comme entrée/sortie (PE2).

Schéma microcontrôleur du circuit

Matrice de touches 5×6

Le clavier comporte 30 touches organisées en une matrice de 5 lignes et 6 colonnes. Cette architecture minimise le nombre de broches nécessaires sur le microcontrôleur (5 + 6 = 11 broches au lieu de 30).

Routage des colonnes et lignes

Les broches du microcontrôleur sont réparties sur plusieurs ports pour faciliter le routage du PCB :

Colonnes (6 broches) :

• COL0 → PF7 (pin 36)
• COL1 → PF6 (pin 37)
• COL2 → PF5 (pin 38)
• COL3 → PF4 (pin 39)
• COL4 → PF1 (pin 40)
• COL5 → PF0 (pin 41)

Lignes (5 broches) :

• ROW0 → PC7 (pin 32)
• ROW1 → PC6 (pin 31)
• ROW2 → PB6 (pin 30)
• ROW3 → PB4 (pin 28)
• ROW4 → PD7 (pin 27)

Les colonnes sont configurées en entrées avec pull-up interne (activées par logiciel). Les lignes sont configurées en sorties, et sont normalement à l’état haut (désactivées). Pour détecter une pression sur une touche située à l’intersection d’une ligne L et d’une colonne C, la ligne est passée à l’état bas (LOW), puis on lit l’état de la colonne. Si la colonne est à 0 (LOW), la touche est enfoncée.

Diodes anti-ghosting

Afin d’éviter les phénomènes de ghosting (détection de fausses touches lorsque plusieurs boutons sont pressés simultanément), une diode est placée en série avec chaque commutateur. Les références D1 à D30 (30 diodes au total, boîtier 0603) sont connectées avec leur anode sur la colonne et leur cathode sur la ligne (ou l’inverse selon le sens de balayage). Le schéma ci-dessous illustre une cellule typique.

Principe d’une cellule de la matrice : le switch MX_SW_HS en série avec une diode

Rétroéclairage RGB

Le clavier est équipé de 16 LEDs RGB (référence APFA3010), chacune étant une LED à anode commune (trois cathodes : rouge, verte, bleue). Elles sont disposées sous les touches principales pour offrir un éclairage personnalisable.

Caractéristiques des LEDs APFA3010

Chaque LED APFA3010 se présente dans un boîtier SMD 3,0 × 1,5 mm au format horizontal. Ses quatre broches sont :

• Broche 1 : R (cathode rouge)
• Broche 2 : A (anode commune → reliée au VCC 5 V)
• Broche 3 : G (cathode verte)
• Broche 4 : B (cathode bleue)

La luminosité de chaque couleur est contrôlée individuellement par modulation de largeur d’impulsion (PWM).

Drivers PWM TLC5947

Le pilotage des 16 × 3 = 48 canaux PWM est assuré par deux circuits TLC5947 (U4 et U5). Ce sont des drivers à 24 canaux chacun, 12 bits de résolution, communiquant via une interface SPI. Le montage en cascade permet d’envoyer les données à U4, qui les transmet à U5 par sa sortie SOUT.

Caractéristiques principales du TLC5947 :

• 24 sorties à courant constant (réglable par une résistance externe)
• Résolution PWM : 4096 niveaux (12 bits)
• Fréquence interne de PWM fixe (≈ 30 kHz)
• Broches de commande : SCLK (horloge), SIN (entrée série), SOUT (sortie série), XLAT (verrouillage), BLANK (sorties actives / désactivées)
• Alimentation : 3,0 V à 5,5 V – ici reliée au VCC 5 V

Répartition des LEDs entre les deux drivers

Les 16 LEDs sont réparties de manière équilibrée :

• U4 pilote les 8 premières LEDs (canaux OUT0 à OUT23). Chaque LED utilise trois canaux consécutifs (R, G, B).
• U5 pilote les 8 LEDs suivantes (même principe).

La connexion en cascade est réalisée ainsi :

• SIN de U4 relié à la broche PB5 (MOSI) du MCU.
• SOUT de U4 relié à SIN de U5.
• SCLK, XLAT et BLANK sont communs aux deux drivers (broches PD0, PD6 et PD4 respectivement).

Cascade de deux TLC5947 pour 16 LEDs RGB

Résistance de référence IREF

Chaque driver TLC5947 nécessite une résistance R(IREF) pour fixer le courant de sortie sur chaque canal. La formule est :

$I_{out}(mA)={\frac {39,06}{R_{IREF}(k\Omega )}}$

Pour un courant typique de 5 mA par couleur (luminosité suffisante pour une utilisation en intérieur), on calcule :

$R_{IREF}={\frac {39,06}{5}}\approx 7,81\,k\Omega$

Les valeurs standard les plus proches sont 7,5 kΩ ou 8,2 kΩ. Dans le schéma, on trouve R9 = 1 968 Ω et R10 = 1 968 Ω (soit environ 1,97 kΩ), ce qui donnerait un courant de presque 20 mA – probablement adapté à des LEDs plus puissantes ou à un usage extérieur. En pratique, cette valeur peut être ajustée par remplacement de la résistance.

Problème de surintensité et correction

Lors des premiers tests, le microcontrôleur a été endommagé à cause d’une demande de courant trop élevée par les LEDs. La solution a été de remplacer les résistances de référence IREF (R9 et R10) initiales de 1,97 kΩ par des résistances de 3,3 kΩ. Avec cette nouvelle valeur, le courant par canal tombe à environ $39,06/3,3\approx 11,8\,mA$, ce qui est plus sûr tout en restant lumineux. Le code compense ensuite les différences de sensibilité des couleurs (voir section logicielle).

Alimentation des LEDs

L’anode commune (broche 2) de chaque APFA3010 est reliée directement au VCC 5 V du boost. La consommation totale dépend du nombre de LEDs allumées et du courant par canal. Avec 16 LEDs × 3 couleurs × 5 mA = 240 mA maximal, ce qui reste dans les capacités du MCP1640.

Gestion matérielle de la PWM

La génération des niveaux PWM est entièrement assurée par les TLC5947. Le microcontrôleur envoie simplement, via SPI, une trame de 48 × 12 bits = 576 bits (soit 72 octets) pour définir les rapports cycliques de chaque canal. Une fois les données transmises, une impulsion sur XLAT verrouille les nouvelles valeurs, et BLANK (normalement à l’état bas) peut être utilisée pour éteindre temporairement toutes les sorties.

Cette architecture décharge complètement le MCU de la gestion du PWM, ce qui laisse toute sa puissance pour le balayage de la matrice et la communication USB.

Logiciel (Software)

La partie logicielle du clavier est décomposée en plusieurs modules : lecture de la matrice de touches, pilotage des LEDs RGB, communication USB (périphérique clavier HID), et communication UART avec la seconde moitié du clavier ergonomique.

Gestion de la matrice de touches

Le fichier matrix.c implémente le balayage d’une matrice 5 lignes × 6 colonnes. Les broches sont configurées comme suit :

• Lignes (sorties) : PC7, PC6, PB6, PB4, PD7 – mises à 1 (HIGH) au repos.
• Colonnes (entrées avec pull‑up) : PF7, PF6, PF5, PF4, PF1, PF0.

Initialisation

La fonction matrix_init() configure les directions des broches et active les résistances de pull‑up sur les colonnes. Elle désactive également le débogueur JTAG (broches PF4‑PF7) pour libérer ces ports.

Balayage et anti‑rebond

Le balayage est effectué par la fonction matrix_scan(). Pour chaque ligne, on abaisse la broche correspondante (select_row), on attend 2 µs (nécessaire à cause de la capacité parasite des lignes), puis on lit l’état des six colonnes (read_col). Un registre à décalage de 8 bits par touche (debounce_state) stocke l’historique des lectures. Une touche est considérée comme enfoncée après 8 échantillons consécutifs à 1, et comme relâchée après 8 échantillons à 0. Le résultat final est stocké dans le tableau matrix_state[5][6] (booléen).

L’extrait suivant montre la boucle de balayage :

for (uint8_t r = 0; r < MATRIX_ROWS; r++) {
    select_row(r);
    _delay_us(2);
    for (uint8_t c = 0; c < MATRIX_COLS; c++) {
        bool raw = read_col(c);
        debounce_state[r][c] = (debounce_state[r][c] << 1) | raw;
        if (debounce_state[r][c] == 0xFF && !matrix_state[r][c])
            matrix_state[r][c] = true;
        else if (debounce_state[r][c] == 0x00 && matrix_state[r][c])
            matrix_state[r][c] = false;
    }
    unselect_row(r);
}

Le tableau matrix_state est accessible depuis les autres modules.

Pilotage des LEDs RGB (TLC5947)

Les 16 LEDs RGB sont contrôlées par deux circuits TLC5947 (U4 et U5) montés en cascade. Chaque TLC5947 est un driver à 24 canaux PWM (12 bits de résolution) piloté par une liaison série en bit‑banging (SPI logiciel).

Brochage et connexions

• SIN (entrée série) : PB5 – données des PWM (48 canaux × 12 bits = 576 bits)
• SCLK (horloge) : PD0 – chaque front montant valide un bit
• XLAT (verrouillage) : PD6 – après transmission, un front basculant transfère les données vers les registres PWM
• BLANK (sorties actives) : PD5 – à 0 pour activer les sorties (les LEDs s’allument)
• SOUT (sortie série de U4) → reliée à SIN de U5 (cascade)

Trame de données

Le TLC5947 attend les données canal par canal, en commençant par le dernier canal du dernier circuit intégré. L’ordre est :

Canal 23 (U5) → Canal 22 (U5) → … → Canal 0 (U5) → Canal 23 (U4) → … → Canal 0 (U4)

Pour chaque canal, on envoie 12 bits, le bit de poids fort (MSB) en premier. La fonction tlc_update() réalise cette transmission.

Le buffer pwm_buffer contient les valeurs 12‑bits (0 à 4095) pour chacun des 48 canaux. L’ordre des canaux par LED est défini dans tlc_set_led() : pour chaque LED, les trois canaux consécutifs sont assignés respectivement au rouge, bleu, vert (selon le brochage de la LED APFA3010).

Animation : dégradé de couleurs mouvant (rainbow)

L’animation utilise le modèle de couleur HSV (teinte, saturation, valeur). La teinte ($H$) varie de 0 à 360°, la saturation et la valeur sont fixées à 1. La conversion $HSV\to RGB$ est réalisée par la fonction hsv_to_rgb(). La formule classique est utilisée, avec $C=4095$ (pleine échelle 12 bits).

Pour créer un dégradé spatial, on associe à chaque LED une teinte de base qui dépend de sa position physique sur le PCB (coordonnées extraites du fichier de placement KiCad). La teinte de la LED $i$ à l’instant $t$ est :

$H_{i}(t)=H_{global}(t)+\alpha \cdot (x_{i}-x_{ref})+\beta \cdot (y_{i}-y_{ref})$

avec $\alpha =0,5$, $\beta =0,3$, et $(x_{ref},y_{ref})=(139,0\,;-136,0)$ mm (centre approximatif du clavier).

Compensation des couleurs

Les LEDs APFA3010 ont des efficacités lumineuses différentes : le rouge est beaucoup moins intense que le vert et le bleu à courant égal. Pour équilibrer visuellement les couleurs, le code applique un facteur d’atténuation différent par canal :

• Rouge → r >> 1 (division par 2)
• Vert → g >> 4 (division par 16)
• Bleu → b >> 4 (division par 16)

Ces coefficients ont été ajustés empiriquement pour obtenir un blanc équilibré et des dégradés harmonieux. La luminosité globale est ainsi réduite, ce qui évite également l’éblouissement.

Communication USB (LUFA)

La bibliothèque LUFA gère le périphérique USB en mode HID (clavier). Le bootloader DFU (présent en usine sur l’ATmega32U4) permet de programmer la carte directement par USB, sans programmateur externe. Il suffit d’appuyer sur le bouton HWB (SW1) au moment de la mise sous tension, puis d’utiliser l’outil dfu-programmer.

Configuration LUFA

Le fichier LUFAConfig.h définit :

• USE_FLASH_DESCRIPTORS (descripteurs en mémoire Flash)
• FIXED_CONTROL_ENDPOINT_SIZE = 8
• FIXED_NUM_CONFIGURATIONS = 1
• USB_DEVICE_ONLY (pas de mode hôte)

Descripteurs USB

Le fichier Descriptors.c suit le format standard d’un clavier HID bootable (rapport de 8 modificateurs + 6 codes de touches). Le Vendor ID est 0x03EB (Atmel) et le Product ID 0x2042.

Implémentation de la classe HID

Le fichier usb_keyboard.c contient les callbacks. Le tableau test_keymap associe chaque position de la matrice à un code HID. Important : ce tableau est inversé (miroir) car les switches ont été soudés sur la face opposée à celle prévue initialement. L’ordre des lignes et colonnes a donc dû être retourné en logiciel pour que les touches correspondent aux caractères attendus.

Exemple de keymap (extrait) :

const uint8_t test_keymap[MATRIX_ROWS][MATRIX_COLS] = {
    {HID_KEYBOARD_SC_5_AND_PERCENTAGE, HID_KEYBOARD_SC_4_AND_DOLLAR, ..., HID_KEYBOARD_SC_ESCAPE},
    {HID_KEYBOARD_SC_T, HID_KEYBOARD_SC_R, ..., HID_KEYBOARD_SC_TAB},
    // ...
};

La fonction CALLBACK_HID_Device_CreateHIDReport() parcourt matrix_state et construit le rapport USB. Un code spécial (MY_CUSTOM_CTRL) permet d’injecter le modificateur Ctrl gauche (pour les raccourcis copier/coller, par exemple).

Programme principal et animation RGB

Le fichier main.c orchestre l’ensemble. La boucle principale :

• matrix_scan() met à jour l’état des touches.
• usb_keyboard_task() maintient la communication USB.
• keyboard_link_task() gère la réception des données de l’autre moitié du clavier (UART).
• Toutes les 50 boucles, il envoie sa propre matrice via keyboard_send_matrix().
• Toutes les 30 boucles (≈ 30 ms), la teinte globale $H_{global}$ est incrémentée de 4° et les LEDs sont mises à jour avec update_leds_rainbow().

La fonction update_leds_rainbow() applique le calcul de teinte spatiale et la compensation des couleurs décrites plus haut.

Communication UART entre les deux moitiés du clavier

Les deux parties du clavier ergonomique communiquent via la prise jack 3,5 mm (USART1 de l’ATmega32U4, broches PD2 (RX) et PD3 (TX)). Le protocole est le suivant :

• Start byte : 0xAA
• Commande : 0x01 pour l’état de la matrice
• Longueur : 4 octets (30 bits → 4 octets, 2 bits inutilisés)
• Données : 4 octets contenant les 30 bits compressés (bit n = ligne*6 + colonne)
• Checksum : somme modulo 256 des 4 octets de données

Envoi

keyboard_send_matrix() compresse la matrice locale dans 4 octets et appelle send_packet() qui envoie les 7 octets du paquet.

Réception

keyboard_link_task() est appelée dans la boucle principale. Elle lit les octets reçus, vérifie le start byte, la commande, la longueur et le checksum. En cas de paquet valide, les données sont stockées dans un buffer et un flag remote_matrix_valid est positionné. La fonction keyboard_get_remote_matrix() permet ensuite de récupérer la matrice distante.

Les deux claviers s’envoient ainsi mutuellement leur état de manière périodique. Les touches de l’autre moitié sont fusionnées avec les touches locales (à faire dans main.c via la variable remote_matrix) avant de générer le rapport USB.

Composants à acheter

| lien farnell Chargeur_Batterie

| lien (farnell) Connecteur jack femelle 3.5mm

| lien farnell DC-DC_step-up mcp1640bt

| LED_RGB led 150141

| lien led driver tlc5947

Voir avec M.Redon ?

Aliexpress ( 14.95 euro pour 50 pièces)

2x Amazon (6.38euro pour 20 pièces)

Carte électronique

Carte réalisée en utilisant le logiciel KiCAD : Fichier:2025-PSE-04-systeme.zip.

Schéma électronique de la carte :

Mon schéma électronique

Résultat du routage :

Mon routage

Photo de la carte soudée :

Ma carte

Vidéo très courte et en basse résolution de la carte en fonctionnement :

Média:2025-PSE-04-systeme-video.mp4

Vidéo des LEDs RGB :

Média:Wiki-video-rgb.mp4