« SE3Groupe2025-4 » : différence entre les versions

De projets-se.plil.fr
Aller à la navigation Aller à la recherche
(Mise a jour finale du code)
Ligne 322 : Ligne 322 :


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.
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.
<h4>Problème de surintensité et correction</h4>
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 <math>39,06 / 3,3 \approx 11,8\,mA</math>, ce qui est plus sûr tout en restant lumineux. Le code compense ensuite les différences de sensibilité des couleurs (voir section logicielle).


<h4>Alimentation des LEDs</h4>
<h4>Alimentation des LEDs</h4>
Ligne 352 : Ligne 356 :
<h4>Balayage et anti‑rebond</h4>
<h4>Balayage et anti‑rebond</h4>


Le balayage est effectué par la fonction <code>matrix_scan()</code>. Pour chaque ligne, on abaisse la broche correspondante (select_row), on attend quelques microsecondes, puis on lit l’état des six colonnes (read_col). Un registre à décalage de 8 bits par touche (<code>debounce_state</code>) 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 <code>matrix_state[5][6]</code> (booléen).
Le balayage est effectué par la fonction <code>matrix_scan()</code>. 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 (<code>debounce_state</code>) 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 <code>matrix_state[5][6]</code> (booléen).


L’extrait suivant montre la boucle de balayage :
L’extrait suivant montre la boucle de balayage :
Ligne 372 : Ligne 376 :
</syntaxhighlight>
</syntaxhighlight>


Le tableau <code>matrix_state</code> est accessible depuis les autres modules pour connaître l’état des touches.
Le tableau <code>matrix_state</code> est accessible depuis les autres modules.


<br style="clear:both;" />
<br style="clear:both;" />
Ligne 378 : Ligne 382 :
=== Pilotage des LEDs RGB (TLC5947) ===
=== 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 (SPI logiciel). La communication n’utilise pas le module SPI matériel de l’ATmega32U4 ; les broches sont commandées directement par le code (bit‑banging).
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).


<h4>Brochage et connexions</h4>
<h4>Brochage et connexions</h4>
Ligne 385 : Ligne 389 :
* '''SCLK''' (horloge) : PD0 – chaque front montant valide un bit
* '''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
* '''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), à 1 pour éteindre
* '''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)
* '''SOUT''' (sortie série de U4) → reliée à SIN de U5 (cascade)


<h4>Trame de données</h4>
<h4>Trame de données</h4>


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


<pre>
<pre>
Ligne 396 : Ligne 400 :
</pre>
</pre>


Pour chaque canal, on envoie 12 bits, le '''bit de poids fort (MSB) en premier'''. La fonction <code>tlc_update()</code> réalise cette transmission :
Pour chaque canal, on envoie 12 bits, le '''bit de poids fort (MSB) en premier'''. La fonction <code>tlc_update()</code> réalise cette transmission.
 
<syntaxhighlight lang="c">
for (int8_t c = NUM_CHANNELS - 1; c >= 0; c--) {
    uint16_t value = pwm_buffer[c];
    for (int8_t b = 11; b >= 0; b--) {
        if (value & (1 << b)) PORTB |= (1 << PB5);
        else PORTB &= ~(1 << PB5);
        PORTD |= (1 << PD0);  // SCLK haut
        PORTD &= ~(1 << PD0);  // SCLK bas
    }
}
PORTD |= (1 << PD6);          // XLAT haut
PORTD &= ~(1 << PD6);          // XLAT bas
</syntaxhighlight>


Le buffer <code>pwm_buffer</code> contient les valeurs 12‑bits (0 à 4095) pour chacun des 48 canaux. L’ordre des canaux par LED est défini dans <code>tlc_set_led()</code> : pour chaque LED, les trois canaux consécutifs sont assignés respectivement au rouge, bleu, vert (selon le brochage de la LED APFA3010).
Le buffer <code>pwm_buffer</code> contient les valeurs 12‑bits (0 à 4095) pour chacun des 48 canaux. L’ordre des canaux par LED est défini dans <code>tlc_set_led()</code> : pour chaque LED, les trois canaux consécutifs sont assignés respectivement au rouge, bleu, vert (selon le brochage de la LED APFA3010).
<h4>Courant de sortie (IREF)</h4>
Chaque canal du TLC5947 délivre un courant constant défini par une résistance externe (R9 pour U4, R10 pour U5). La formule est :
<math>I_{out} (mA) = \frac{39,06}{R_{IREF} (k\Omega)}</math>
Avec <math>R9 = R10 = 1\,968\,\Omega \approx 1,97\,k\Omega</math>, on obtient :
<math>I_{out} \approx \frac{39,06}{1,97} \approx 19,8\,mA</math>
Ce courant est élevé (LED très lumineuses). Dans le code, on réduit l’intensité en divisant les valeurs PWM par 8 (exemple : <code>tlc_set_led(i, r >> 3, g >> 3, b >> 3)</code>), ce qui correspond à un courant moyen plus faible.


<h4>Animation : dégradé de couleurs mouvant (rainbow)</h4>
<h4>Animation : dégradé de couleurs mouvant (rainbow)</h4>


Pour obtenir un effet « arc‑en‑ciel » se déplaçant sur le clavier, on utilise le modèle de couleur '''HSV''' (teinte, saturation, valeur). La teinte (<math>H</math>) est un angle de 0 à 360°, la saturation et la valeur sont fixées à 1.
L’animation utilise le modèle de couleur '''HSV''' (teinte, saturation, valeur). La teinte (<math>H</math>) varie de 0 à 360°, la saturation et la valeur sont fixées à 1. La conversion <math>HSV \to RGB</math> est réalisée par la fonction <code>hsv_to_rgb()</code>. La formule classique est utilisée, avec <math>C = 4095</math> (pleine échelle 12 bits).


La conversion <math>HSV \to RGB</math> se fait par la fonction <code>hsv_to_rgb()</code>. Soit <math>H \in [0,360]</math>, <math>C = V \cdot S \cdot 4095</math> (ici <math>V=1, S=1</math> donc <math>C = 4095</math>). On définit <math>X = C \cdot (1 - |(H/60) \mod 2 - 1|)</math> et <math>m = 0</math>. Les composantes <math>(R', G', B')</math> sont données par :
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 <math>i</math> à l’instant <math>t</math> est :


<math>
<math>H_i(t) = H_{global}(t) + \alpha \cdot (x_i - x_{ref}) + \beta \cdot (y_i - y_{ref})</math>
(R', G', B') =  
\begin{cases}
(C, X, 0) & \text{si } 0 \le H < 60 \\
(X, C, 0) & \text{si } 60 \le H < 120 \\
(0, C, X) & \text{si } 120 \le H < 180 \\
(0, X, C) & \text{si } 180 \le H < 240 \\
(X, 0, C) & \text{si } 240 \le H < 300 \\
(C, 0, X) & \text{si } 300 \le H < 360
\end{cases}
</math>


Les valeurs finales <math>(R,G,B)</math> sont <math>(R', G', B')</math> arrondies à l’entier.
avec <math>\alpha = 0,5</math>, <math>\beta = 0,3</math>, et <math>(x_{ref}, y_{ref}) = (139,0\,; -136,0)</math> mm (centre approximatif du clavier).


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. Les coordonnées <math>(x_i, y_i)</math> de chaque LED (en mm) sont stockées dans un tableau. La teinte de la LED <math>i</math> à l’instant <math>t</math> est :
<h4>Compensation des couleurs</h4>


<math>H_i(t) = H_{global}(t) + \alpha \cdot (x_i - x_{ref}) + \beta \cdot (y_i - y_{ref})</math>
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 :


où <math>H_{global}(t)</math> varie cycliquement (de 0 à 360°), et <math>\alpha, \beta</math> sont des coefficients empiriques (dans le code : <math>\alpha = 0,5</math>, <math>\beta = 0,3</math>). Les références <math>x_{ref}=139,0</math> mm et <math>y_{ref}=-136,0</math> mm correspondent environ au centre du clavier.
* Rouge → <code>r >> 1</code> (division par 2)
* Vert → <code>g >> 4</code> (division par 16)
* Bleu → <code>b >> 4</code> (division par 16)


Le résultat est un '''arc‑en‑ciel continu''' se déplaçant progressivement sur l’ensemble des touches. Le code principal incrémente <math>H_{global}</math> toutes les 30 ms environ, puis appelle <code>update_leds_rainbow()</code> qui calcule et envoie les nouvelles valeurs PWM aux TLC5947.
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.


<br style="clear:both;" />
<br style="clear:both;" />
Ligne 458 : Ligne 428 :
=== Communication USB (LUFA) ===
=== Communication USB (LUFA) ===


Le fichier <code>LUFAConfig.h</code> définit les options de compilation :
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 <code>dfu-programmer</code>.
* <code>USE_FLASH_DESCRIPTORS</code> : les descripteurs sont stockés en mémoire Flash (PROGMEM).
 
* <code>FIXED_CONTROL_ENDPOINT_SIZE = 8</code> : taille de l’endpoint de contrôle.
<h4>Configuration LUFA</h4>
* <code>FIXED_NUM_CONFIGURATIONS = 1</code> : une seule configuration.
* <code>USB_DEVICE_ONLY</code> : le mode hôte n’est pas utilisé.


Le bootloader '''DFU''' (Device Firmware Upgrade) présent en usine sur l’ATmega32U4 permet de programmer le clavier directement par USB, sans programmateur externe. Il suffit d’appuyer sur le bouton HWB (SW1) au moment de la mise sous tension pour forcer le mode DFU, puis d’utiliser l’outil <code>dfu-programmer</code>.
Le fichier <code>LUFAConfig.h</code> définit :
* <code>USE_FLASH_DESCRIPTORS</code> (descripteurs en mémoire Flash)
* <code>FIXED_CONTROL_ENDPOINT_SIZE = 8</code>
* <code>FIXED_NUM_CONFIGURATIONS = 1</code>
* <code>USB_DEVICE_ONLY</code> (pas de mode hôte)


<h4>Descripteurs USB</h4>
<h4>Descripteurs USB</h4>


Le fichier <code>Descriptors.c</code> contient les descripteurs envoyés à l’hôte lors de l’énumération :
Le fichier <code>Descriptors.c</code> 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.


* '''Device Descriptor''' : identifie le fabricant (Vendor ID = 0x03EB, Atmel), le produit (Product ID = 0x2042, “LUFA Keyboard Demo”), et la version USB.
<h4>Implémentation de la classe HID</h4>
* '''Configuration Descriptor''' : déclare une interface (HID) avec deux endpoints (IN et OUT).
* '''HID Report Descriptor''' : décrit le format des rapports (modificateurs, codes de touches, LEDs).


Le rapport HID (périphérique clavier) est standard : 8 bits de modificateurs (Ctrl, Shift, Alt, GUI), 1 octet réservé, puis 6 octets pour les codes de touches (jusqu’à 6 touches simultanées). Le descripteur inclut également un rapport OUT pour recevoir l’état des LEDs (Caps Lock, Num Lock, etc.).
Le fichier <code>usb_keyboard.c</code> contient les callbacks. Le tableau <code>test_keymap</code> 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.


<h4>Implémentation de la classe HID</h4>
Exemple de keymap (extrait) :
 
Le fichier <code>usb_keyboard.c</code> gère l’initialisation USB et les callbacks. Voici un extrait des fonctions principales :


<syntaxhighlight lang="c">
<syntaxhighlight lang="c">
// Structure d'interface HID (un seul endpoint IN)
const uint8_t test_keymap[MATRIX_ROWS][MATRIX_COLS] = {
USB_ClassInfo_HID_Device_t Keyboard_HID_Interface = {
     {HID_KEYBOARD_SC_5_AND_PERCENTAGE, HID_KEYBOARD_SC_4_AND_DOLLAR, ..., HID_KEYBOARD_SC_ESCAPE},
     .Config = {
    {HID_KEYBOARD_SC_T, HID_KEYBOARD_SC_R, ..., HID_KEYBOARD_SC_TAB},
        .InterfaceNumber              = INTERFACE_ID_Keyboard,
    // ...
        .ReportINEndpoint            = {
            .Address              = KEYBOARD_IN_EPADDR,
            .Size                = KEYBOARD_EPSIZE,
            .Banks                = 1,
        },
        .PrevReportINBuffer          = PrevKeyboardHIDReportBuffer,
        .PrevReportINBufferSize      = sizeof(PrevKeyboardHIDReportBuffer),
    },
};
};
void usb_keyboard_init(void) {
    // Désactivation du watchdog et réglage de l'horloge
    MCUSR &= ~(1 << WDRF);
    wdt_disable();
    clock_prescale_set(clock_div_1);
    // Désactivation du JTAG (libère les broches PF4-PF7)
    MCUCR |= (1 << JTD);
    MCUCR |= (1 << JTD);
    USB_Init();
}
// Callback appelée pour construire le rapport HID à envoyer
bool CALLBACK_HID_Device_CreateHIDReport(
    USB_ClassInfo_HID_Device_t* const HIDInterfaceInfo,
    uint8_t* const ReportID,
    const uint8_t ReportType,
    void* ReportData,
    uint16_t* const ReportSize) {
    USB_KeyboardReport_Data_t* KeyboardReport = (USB_KeyboardReport_Data_t*)ReportData;
    memset(KeyboardReport, 0, sizeof(USB_KeyboardReport_Data_t));
    uint8_t used = 0;
    // Parcours de matrix_state (défini dans matrix.c)
    for (uint8_t r = 0; r < MATRIX_ROWS; r++) {
        for (uint8_t c = 0; c < MATRIX_COLS; c++) {
            if (matrix_state[r][c]) {
                uint8_t key = test_keymap[r][c];
                if (key >= HID_KEYBOARD_MODIFIER_LEFTCTRL &&
                    key <= HID_KEYBOARD_MODIFIER_RIGHTGUI) {
                    // C'est un modificateur
                    KeyboardReport->Modifier |= key;
                } else if (used < 6) {
                    KeyboardReport->KeyCode[used++] = key;
                }
            }
        }
    }
    *ReportSize = sizeof(USB_KeyboardReport_Data_t);
    return false;
}
</syntaxhighlight>
</syntaxhighlight>


Le tableau <code>test_keymap</code> (défini dans <code>usb_keyboard.c</code>) fait correspondre chaque position de la matrice (5 lignes × 6 colonnes) à un code de touche HID (ou à un modificateur). Les codes sont ceux définis par la norme USB HID (ex. <code>HID_KEYBOARD_SC_A</code>). Le callback est appelé périodiquement par LUFA ; il construit le rapport et l’envoie sur l’endpoint IN.
La fonction <code>CALLBACK_HID_Device_CreateHIDReport()</code> parcourt <code>matrix_state</code> et construit le rapport USB. Un code spécial (<code>MY_CUSTOM_CTRL</code>) permet d’injecter le modificateur Ctrl gauche (pour les raccourcis copier/coller, par exemple).
 
<h4>Réception de l’état des LEDs (Caps Lock)</h4>
 
Bien que le clavier n’utilise pas de LED Caps Lock dédiée sur la carte (la LED D31 n’est pas montée), le callback <code>CALLBACK_HID_Device_ProcessHIDReport</code> pourrait être implémenté pour recevoir les commandes de l’hôte (par exemple pour allumer une LED virtuelle ou modifier le rétroéclairage). Dans notre code, ce callback est laissé vide.


<br style="clear:both;" />
<br style="clear:both;" />
Ligne 550 : Ligne 462 :
=== Programme principal et animation RGB ===
=== Programme principal et animation RGB ===


Le fichier '''main.c''' orchestre l’ensemble des modules : initialisation du matériel, balayage de la matrice, traitement USB, et animation des LEDs RGB. La boucle principale est simple :
Le fichier '''main.c''' orchestre l’ensemble. La boucle principale :
 
* <code>matrix_scan()</code> met à jour l’état des touches (avec anti‑rebond).
* <code>usb_keyboard_task()</code> maintient la communication USB active (envoi des rapports HID).
* Une animation RGB change la couleur des LEDs à intervalles réguliers.
 
<h4>Implémentation de l’effet « rainbow »</h4>
 
L’animation utilise le modèle de couleur '''HSV''' pour créer un dégradé continu se déplaçant dans le temps et dans l’espace. La teinte globale (<math>H_{global}</math>) s’incrémente cycliquement (une rotation complète toutes les quelques secondes). À chaque LED est associée une teinte individuelle :
 
<math>H_i = H_{global} + \alpha \cdot (x_i - x_{ref}) + \beta \cdot (y_i - y_{ref})</math>
 
où <math>(x_i, y_i)</math> sont les coordonnées physiques de la LED (relevées dans le fichier de placement PCB), <math>\alpha = 0,5</math>, <math>\beta = 0,3</math>, et <math>(x_{ref}, y_{ref})</math> est le centre approximatif du clavier.
 
La conversion HSV → RGB (12 bits) est réalisée par la fonction <code>hsv_to_rgb()</code>. L’intensité est volontairement réduite (division par 8) pour ne pas éblouir.
 
Voici la boucle principale complète :
 
<syntaxhighlight lang="c">
int main(void) {
    matrix_init();
    usb_keyboard_init();
    tlc_init();
    sei();
 
    float hue = 0.0f;
    uint16_t loop_counter = 0;
 
    while (1) {
        matrix_scan();
        usb_keyboard_task();


        loop_counter++;
* <code>matrix_scan()</code> met à jour l’état des touches.
        if (loop_counter >= 30) {  // ~30 ms
* <code>usb_keyboard_task()</code> maintient la communication USB.
            loop_counter = 0;
* <code>keyboard_link_task()</code> gère la réception des données de l’autre moitié du clavier (UART).
            hue += 4.0f;
* Toutes les 50 boucles, il envoie sa propre matrice via <code>keyboard_send_matrix()</code>.
            if (hue >= 360.0f) hue -= 360.0f;
* Toutes les 30 boucles (≈ 30 ms), la teinte globale <math>H_{global}</math> est incrémentée de 4° et les LEDs sont mises à jour avec <code>update_leds_rainbow()</code>.
            update_leds_rainbow(hue);
        }
        _delay_ms(1);
    }
}
</syntaxhighlight>


La fonction <code>update_leds_rainbow(hue)</code> calcule pour chaque LED sa couleur, appelle <code>tlc_set_led()</code> pour remplir le buffer PWM, puis <code>tlc_update()</code> pour transférer les données vers les drivers. Le résultat est un dégradé fluide et continu sur l’ensemble du clavier.
La fonction <code>update_leds_rainbow()</code> applique le calcul de teinte spatiale et la compensation des couleurs décrites plus haut.


<br style="clear:both;" />
<br style="clear:both;" />


=== Communication UART avec la seconde moitié du clavier ===
=== Communication UART entre les deux moitiés du clavier ===


Le clavier étant ergonomique (séparé en deux parties), les deux moitiés communiquent via une liaison '''UART''' (Universal Asynchronous Receiver‑Transmitter) sur une prise jack 3,5 mm (J2). L’ATmega32U4 dispose d’un module USART1 (broches PD2 pour RX, PD3 pour TX). La communication permet d’échanger l’état des touches de chaque côté et éventuellement de synchroniser les effets RGB.
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 :


<h4>Initialisation de l’UART</h4>
* '''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


Le fichier '''serial.c''' fournit les fonctions de base. L’initialisation se fait avec <code>init_serial(speed)</code> (par exemple 115200 bauds). La formule de calcul du registre <code>UBRR1</code> est adaptée à l’ATmega32U4 (horloge 16 MHz, mode asynchrone) :
<h4>Envoi</h4>


<math>UBRR = \frac{F_{CPU}}{16 \times Baud} - 1</math>
<code>keyboard_send_matrix()</code> compresse la matrice locale dans 4 octets et appelle <code>send_packet()</code> qui envoie les 7 octets du paquet.


Avec <math>F_{CPU} = 16\,000\,000</math> et <math>Baud = 115\,200</math>, on obtient <math>UBRR \approx 8</math>. La configuration suivante est utilisée : 8 bits de données, 1 stop bit, pas de parité.
<h4>Réception</h4>


<h4>Envoi et réception de données</h4>
<code>keyboard_link_task()</code> 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 <code>remote_matrix_valid</code> est positionné. La fonction <code>keyboard_get_remote_matrix()</code> permet ensuite de récupérer la matrice distante.
 
La fonction <code>send_serial(char c)</code> transmet un octet (attente du flag <code>UDRE1</code>). La fonction <code>get_serial(void)</code> lit un octet (attente du flag <code>RXC1</code>). Pour simplifier l’envoi de chaînes formatées, <code>init_printf()</code> redirige <code>printf()</code> vers l’UART.
 
Dans le projet, les deux moitiés de clavier échangent périodiquement leur matrice de touches (30 bits chacune). Un protocole simple (start byte, commande, données, checksum) pourrait être implémenté. Par exemple, l’envoi de l’état des touches sous forme d’un paquet de 4 octets (30 bits = 4 octets avec 2 bits inutilisés). La réception met à jour une matrice virtuelle représentant les touches de l’autre côté.
 
<h4>Exemple d’échange</h4>
 
Voici une ébauche de fonction d’envoi de l’état local :
 
<syntaxhighlight lang="c">
void send_matrix_state(void) {
    uint8_t buffer[4] = {0};
    // Compression de matrix_state[5][6] dans 30 bits
    for (uint8_t r = 0; r < MATRIX_ROWS; r++) {
        for (uint8_t c = 0; c < MATRIX_COLS; c++) {
            if (matrix_state[r][c]) {
                uint8_t bit = r * MATRIX_COLS + c;
                buffer[bit / 8] |= (1 << (bit % 8));
            }
        }
    }
    send_serial(0xAA); // start
    send_serial(0x01); // commande "état matrice"
    for (uint8_t i = 0; i < 4; i++) send_serial(buffer[i]);
    send_serial(checksum(buffer, 4));
}
</syntaxhighlight>


La réception se fait dans la boucle principale (ou par interruption). Les touches reçues sont fusionnées avec les touches locales avant de générer le rapport USB. Ainsi, l’ordinateur voit un seul clavier combinant les deux moitiés.
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 <code>main.c</code> via la variable <code>remote_matrix</code>) avant de générer le rapport USB.


<br style="clear:both;" />
<br style="clear:both;" />

Version du 13 juin 2026 à 18:37

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 :

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

Programmation

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

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 :

Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle 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 :

Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle 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 :

Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle \Delta I_L = \frac{V_{IN} \times D}{L \times f_{SW}}}

avec un rapport cyclique typique Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle D = 1 - \frac{V_{IN}}{V_{OUT}} = 1 - \frac{3,7}{5} = 0,26} , une fréquence de découpage Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle f_{SW} = 500\,kHz} (d’après la datasheet du MCP1640), et L = 4,7 µH.

Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle \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 :

Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle 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 :

Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle 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 :

Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle 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 :

Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle 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 Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle 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 () varie de 0 à 360°, la saturation et la valeur sont fixées à 1. La conversion est réalisée par la fonction hsv_to_rgb(). La formule classique est utilisée, avec (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 à l’instant est :

avec , Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle \beta = 0,3} , et Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle (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 Échec de l’analyse (SVG avec PNG en repli (MathML peut être activé via une extension du navigateur) : réponse non valide(« Math extension cannot connect to Restbase. ») du serveur « https://wikimedia.org/api/rest_v1/ » :): {\displaystyle 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-BB-systeme-video.mp4

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-systeme-final.mp4.

Récupérée de « http:///mediawiki/index.php?title=SE3Groupe2025-4&oldid=10706 »