projets-se.plil.fr - Contributions [fr]

SE3Groupe2025-4

2026-06-19T14:35:36Z

Rex : Révocation des modifications de Rex (discussion) vers la dernière version créée par Aboualle

= Programmation des systèmes embarqués =

== Carte électronique ==

Carte réalisée en utilisant le logiciel <code>KiCAD</code> : [[File:2025-PSE-04-systeme.zip|ma carte électronique]].

Schéma électronique de la carte :

[[File:2025_PSE-04-PROG-schema.pdf|thumb|center|400px|Mon schéma électronique]]

Résultat du routage :

[[File:2025_PSE-04-PROG-PCB.png|thumb|center|400px|Mon routage]]

[[File:2025_PSE-04-PROG-carte.png|thumb|center|400px|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).

<syntaxhighlight lang="c" line="1">
#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);
}
}
</syntaxhighlight>

==== 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 :

<syntaxhighlight lang="bash">
make clean
make
sudo dfu-programmer atmega8u2 erase --force
sudo dfu-programmer atmega8u2 flash blink.hex
sudo dfu-programmer atmega8u2 reset
</syntaxhighlight>

Après le reset, les deux LEDs doivent clignoter 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 :

<syntaxhighlight lang="c">
#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
</syntaxhighlight>

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

<syntaxhighlight lang="c">
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 = { ... },
};
</syntaxhighlight>

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.

<syntaxhighlight lang="c">
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();
}
}
</syntaxhighlight>

**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.

<syntaxhighlight lang="c">
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();
}
}
</syntaxhighlight>

**É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.

[[File:Wiki-capture-lsusb.png|thumb|center|400px|lsusb]]

[[File:Wiki-photo-prog.jpeg|thumb|center|400px|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 : [https://gitea.plil.fr/aboualle/2025_PSE_04_aboualle_tregaud].

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

Ajouter un <code>.gitignore</code> 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[https://projets-se.plil.fr/mediawiki/index.php/SE3Groupe2025-16].
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).

[[Fichier:clavier_ergo_top.jpg|center|vignette|500px|Vue de la carte clavier finalisée]]

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

== 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.

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

== 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.

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

=== 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).

<h4>Chargeur Li-ion MAX1811</h4>

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.

<h4>Convertisseur Boost MCP1640</h4>

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 :

<math>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</math>

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 :

<math>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</math>

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

<math>\Delta I_L = \frac{V_{IN} \times D}{L \times f_{SW}}</math>

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

<math>\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</math>

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

<math>I_{Lpeak} = I_{BAT} + \frac{\Delta I_L}{2} \approx 0,477 + 0,2045 \approx 0,682\,A</math>

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.

[[Fichier:wiki_schema_alimentation.png|center|vignette|400px|La section alimentation du circuit]]

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

=== 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.

<h4>Horloge et découplage</h4>

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 :

<math>C_L = \frac{C_1 \cdot C_2}{C_1 + C_2} + C_{parasite}</math>

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...).

<h4>Gestion de l’USB</h4>

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.

<h4>Connecteur ISP</h4>

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.

<h4>Boutons RST et HWB</h4>

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).

[[Fichier:wiki_schema_mcu.png|center|vignette|400px|Schéma microcontrôleur du circuit]]

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

=== 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).

<h4>Routage des colonnes et lignes</h4>

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.

<h4>Diodes anti-ghosting</h4>

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.

[[Fichier:wiki_matrice_diode.png|center|vignette|400px|Principe d’une cellule de la matrice : le switch MX_SW_HS en série avec une diode]]

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

=== 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.

<h4>Caractéristiques des LEDs APFA3010</h4>

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).

<h4>Drivers PWM TLC5947</h4>

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

<h4>Répartition des LEDs entre les deux drivers</h4>

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).

[[Fichier:wiki_tlc5947_cascade.png|center|vignette|600px|Cascade de deux TLC5947 pour 16 LEDs RGB]]

<h4>Résistance de référence IREF</h4>

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

<math>I_{out} (mA) = \frac{39,06}{R_{IREF} (k\Omega)}</math>

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

<math>R_{IREF} = \frac{39,06}{5} \approx 7,81\,k\Omega</math>

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>

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.

<h4>Gestion matérielle de la PWM</h4>

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.

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

== 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.

<h4>Initialisation</h4>

La fonction <code>matrix_init()</code> 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.

<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 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 :

<syntaxhighlight lang="c">
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);
}
</syntaxhighlight>

Le tableau <code>matrix_state</code> est accessible depuis les autres modules.

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

=== 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).

<h4>Brochage et connexions</h4>

* '''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)

<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 :

<pre>
Canal 23 (U5) → Canal 22 (U5) → … → Canal 0 (U5) → Canal 23 (U4) → … → Canal 0 (U4)
</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.

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>Animation : dégradé de couleurs mouvant (rainbow)</h4>

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).

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

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).

<h4>Compensation des couleurs</h4>

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 → <code>r >> 1</code> (division par 2)
* Vert → <code>g >> 4</code> (division par 16)
* Bleu → <code>b >> 4</code> (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.

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

=== 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 <code>dfu-programmer</code>.

<h4>Configuration LUFA</h4>

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>

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.

<h4>Implémentation de la classe HID</h4>

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.

Exemple de keymap (extrait) :

<syntaxhighlight lang="c">
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},
// ...
};
</syntaxhighlight>

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).

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

=== Programme principal et animation RGB ===

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

* <code>matrix_scan()</code> met à jour l’état des touches.
* <code>usb_keyboard_task()</code> maintient la communication USB.
* <code>keyboard_link_task()</code> 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 <code>keyboard_send_matrix()</code>.
* 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>.

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;" />

=== 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

<h4>Envoi</h4>

<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.

<h4>Réception</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.

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;" />

== Composants à acheter ==

[https://fr.farnell.com/analog-devices/max1811esa-t/chargeur-batterie-li-ion-500ma/dp/3916608 | lien farnell Chargeur_Batterie]

[https://fr.farnell.com/same-sky/sj-3523-smt-tr/conn-audio-t-l-fem-90-stereo-4p/dp/4814364 | lien (farnell) Connecteur jack femelle 3.5mm]

[https://fr.farnell.com/microchip/mcp1640bt-i-chy/conv-dc-dc-sync-boost-500khz-85/dp/1800207RL | lien farnell DC-DC_step-up mcp1640bt]

[https://fr.farnell.com/wurth-elektronik/150141m173100/led-1411-rgb-270mcd-950mcd-230mcd/dp/2322115 | LED_RGB led 150141]

[https://fr.farnell.com/texas-instruments/tlc5947dap/ic-led-driver-linear-32-tssop/dp/3119196 | lien led driver tlc5947]

'''Voir avec M.Redon ?'''

[https://www.aliexpress.us/item/3256805961019213.html?spm=a2g0o.productlist.main.1.66eclXL5lXL5cf&algo_pvid=ca5aafba-3d33-48dd-8cc9-1bb366397f0b&algo_exp_id=ca5aafba-3d33-48dd-8cc9-1bb366397f0b-0&pdp_ext_f=%7B%22order%22%3A%2218%22%2C%22eval%22%3A%221%22%2C%22fromPage%22%3A%22search%22%7D&pdp_npi=6%40dis%21USD%2114.95%2110.45%21%21%2114.95%2110.45%21%40210384cc17730991634577851e3de4%2112000035974925908%21sea%21US%210%21ABX%211%210%21n_tag%3A-29910%3Bd%3Aaf0128d0%3Bm03_new_user%3A-29895%3BpisId%3A5000000197827636&curPageLogUid=b1itGq4vumse&utparam-url=scene%3Asearch%7Cquery_from%3A%7Cx_object_id%3A1005006147333965%7C_p_origin_prod%3A|Switch Aliexpress ( 14.95 euro pour 50 pièces)]

2x [https://www.amazon.fr/dp/B0GRWRB35R?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=1A6WWK5JXXYDI&dib=eyJ2IjoiMSJ9.knTjQV522IT_x46yYmNW2g.yIdEmWsx71pRbn6RsO1Dsoph1vyoIyzvcLufmAX48M0&dib_tag=se&keywords=Kailh+Hotswap+Socket+CPG135001S30&qid=1773098978&s=computers&sprefix=kailh+hotswap+socket+cpg135001s30%2Ccomputers%2C439&sr=1-1|Hot-Swap_Kailh Amazon (6.38euro pour 20 pièces)]

== Carte électronique ==

Carte réalisée en utilisant le logiciel <code>KiCAD</code> : [[File:2025-PSE-04-systeme.zip|ma carte électronique]].

Schéma électronique de la carte :

[[File:2025_PSE-04-systeme-schema.pdf|thumb|center|400px|Mon schéma électronique]]

Résultat du routage :

[[File:2025_PSE-04-systeme-PCB.pdf|thumb|center|400px|Mon routage]]

Photo de la carte soudée :

[[File:2025_PSE-04-systeme-carte.jpg|thumb|center|400px|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]]

SE3Groupe2025-4

2026-06-19T14:33:56Z

Rex : /* Code de la carte (CustomHID.c) */

= Programmation des systèmes embarqués =

== Carte électronique ==

Carte réalisée en utilisant le logiciel <code>KiCAD</code> : [[File:2025-PSE-04-systeme.zip|ma carte électronique]].

Schéma électronique de la carte :

[[File:2025_PSE-04-PROG-schema.pdf|thumb|center|400px|Mon schéma électronique]]

Résultat du routage :

[[File:2025_PSE-04-PROG-PCB.png|thumb|center|400px|Mon routage]]

[[File:2025_PSE-04-PROG-carte.png|thumb|center|400px|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).

<syntaxhighlight lang="c" line="1">
#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);
}
}
</syntaxhighlight>

==== 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 :

<syntaxhighlight lang="bash">
make clean
make
sudo dfu-programmer atmega8u2 erase --force
sudo dfu-programmer atmega8u2 flash blink.hex
sudo dfu-programmer atmega8u2 reset
</syntaxhighlight>

Après le reset, les deux LEDs doivent clignoter 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 :

<syntaxhighlight lang="c">
#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
</syntaxhighlight>

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

<syntaxhighlight lang="c">
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 = { ... },
};
</syntaxhighlight>

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.

<syntaxhighlight lang="c">
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();
}
}
</syntaxhighlight>

**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.

<syntaxhighlight lang="c">
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();
}
}
</syntaxhighlight>

**É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.

[[File:Wiki-capture-lsusb.png|thumb|center|400px|lsusb]]

[[File:Wiki-photo-prog.jpeg|thumb|center|400px|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 : [https://gitea.plil.fr/aboualle/2025_PSE_04_aboualle_tregaud].

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

Ajouter un <code>.gitignore</code> 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[https://projets-se.plil.fr/mediawiki/index.php/SE3Groupe2025-16].
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).

[[Fichier:clavier_ergo_top.jpg|center|vignette|500px|Vue de la carte clavier finalisée]]

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

== 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.

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

== 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.

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

=== 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).

<h4>Chargeur Li-ion MAX1811</h4>

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.

<h4>Convertisseur Boost MCP1640</h4>

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 :

<math>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</math>

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 :

<math>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</math>

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

<math>\Delta I_L = \frac{V_{IN} \times D}{L \times f_{SW}}</math>

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

<math>\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</math>

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

<math>I_{Lpeak} = I_{BAT} + \frac{\Delta I_L}{2} \approx 0,477 + 0,2045 \approx 0,682\,A</math>

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.

[[Fichier:wiki_schema_alimentation.png|center|vignette|400px|La section alimentation du circuit]]

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

=== 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.

<h4>Horloge et découplage</h4>

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 :

<math>C_L = \frac{C_1 \cdot C_2}{C_1 + C_2} + C_{parasite}</math>

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...).

<h4>Gestion de l’USB</h4>

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.

<h4>Connecteur ISP</h4>

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.

<h4>Boutons RST et HWB</h4>

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).

[[Fichier:wiki_schema_mcu.png|center|vignette|400px|Schéma microcontrôleur du circuit]]

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

=== 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).

<h4>Routage des colonnes et lignes</h4>

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.

<h4>Diodes anti-ghosting</h4>

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.

[[Fichier:wiki_matrice_diode.png|center|vignette|400px|Principe d’une cellule de la matrice : le switch MX_SW_HS en série avec une diode]]

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

=== 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.

<h4>Caractéristiques des LEDs APFA3010</h4>

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).

<h4>Drivers PWM TLC5947</h4>

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

<h4>Répartition des LEDs entre les deux drivers</h4>

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).

[[Fichier:wiki_tlc5947_cascade.png|center|vignette|600px|Cascade de deux TLC5947 pour 16 LEDs RGB]]

<h4>Résistance de référence IREF</h4>

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

<math>I_{out} (mA) = \frac{39,06}{R_{IREF} (k\Omega)}</math>

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

<math>R_{IREF} = \frac{39,06}{5} \approx 7,81\,k\Omega</math>

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>

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.

<h4>Gestion matérielle de la PWM</h4>

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.

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

== 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.

<h4>Initialisation</h4>

La fonction <code>matrix_init()</code> 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.

<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 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 :

<syntaxhighlight lang="c">
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);
}
</syntaxhighlight>

Le tableau <code>matrix_state</code> est accessible depuis les autres modules.

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

=== 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).

<h4>Brochage et connexions</h4>

* '''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)

<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 :

<pre>
Canal 23 (U5) → Canal 22 (U5) → … → Canal 0 (U5) → Canal 23 (U4) → … → Canal 0 (U4)
</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.

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>Animation : dégradé de couleurs mouvant (rainbow)</h4>

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).

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

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).

<h4>Compensation des couleurs</h4>

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 → <code>r >> 1</code> (division par 2)
* Vert → <code>g >> 4</code> (division par 16)
* Bleu → <code>b >> 4</code> (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.

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

=== 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 <code>dfu-programmer</code>.

<h4>Configuration LUFA</h4>

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>

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.

<h4>Implémentation de la classe HID</h4>

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.

Exemple de keymap (extrait) :

<syntaxhighlight lang="c">
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},
// ...
};
</syntaxhighlight>

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).

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

=== Programme principal et animation RGB ===

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

* <code>matrix_scan()</code> met à jour l’état des touches.
* <code>usb_keyboard_task()</code> maintient la communication USB.
* <code>keyboard_link_task()</code> 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 <code>keyboard_send_matrix()</code>.
* 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>.

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;" />

=== 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

<h4>Envoi</h4>

<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.

<h4>Réception</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.

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;" />

== Composants à acheter ==

[https://fr.farnell.com/analog-devices/max1811esa-t/chargeur-batterie-li-ion-500ma/dp/3916608 | lien farnell Chargeur_Batterie]

[https://fr.farnell.com/same-sky/sj-3523-smt-tr/conn-audio-t-l-fem-90-stereo-4p/dp/4814364 | lien (farnell) Connecteur jack femelle 3.5mm]

[https://fr.farnell.com/microchip/mcp1640bt-i-chy/conv-dc-dc-sync-boost-500khz-85/dp/1800207RL | lien farnell DC-DC_step-up mcp1640bt]

[https://fr.farnell.com/wurth-elektronik/150141m173100/led-1411-rgb-270mcd-950mcd-230mcd/dp/2322115 | LED_RGB led 150141]

[https://fr.farnell.com/texas-instruments/tlc5947dap/ic-led-driver-linear-32-tssop/dp/3119196 | lien led driver tlc5947]

'''Voir avec M.Redon ?'''

[https://www.aliexpress.us/item/3256805961019213.html?spm=a2g0o.productlist.main.1.66eclXL5lXL5cf&algo_pvid=ca5aafba-3d33-48dd-8cc9-1bb366397f0b&algo_exp_id=ca5aafba-3d33-48dd-8cc9-1bb366397f0b-0&pdp_ext_f=%7B%22order%22%3A%2218%22%2C%22eval%22%3A%221%22%2C%22fromPage%22%3A%22search%22%7D&pdp_npi=6%40dis%21USD%2114.95%2110.45%21%21%2114.95%2110.45%21%40210384cc17730991634577851e3de4%2112000035974925908%21sea%21US%210%21ABX%211%210%21n_tag%3A-29910%3Bd%3Aaf0128d0%3Bm03_new_user%3A-29895%3BpisId%3A5000000197827636&curPageLogUid=b1itGq4vumse&utparam-url=scene%3Asearch%7Cquery_from%3A%7Cx_object_id%3A1005006147333965%7C_p_origin_prod%3A|Switch Aliexpress ( 14.95 euro pour 50 pièces)]

2x [https://www.amazon.fr/dp/B0GRWRB35R?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=1A6WWK5JXXYDI&dib=eyJ2IjoiMSJ9.knTjQV522IT_x46yYmNW2g.yIdEmWsx71pRbn6RsO1Dsoph1vyoIyzvcLufmAX48M0&dib_tag=se&keywords=Kailh+Hotswap+Socket+CPG135001S30&qid=1773098978&s=computers&sprefix=kailh+hotswap+socket+cpg135001s30%2Ccomputers%2C439&sr=1-1|Hot-Swap_Kailh Amazon (6.38euro pour 20 pièces)]

== Carte électronique ==

Carte réalisée en utilisant le logiciel <code>KiCAD</code> : [[File:2025-PSE-04-systeme.zip|ma carte électronique]].

Schéma électronique de la carte :

[[File:2025_PSE-04-systeme-schema.pdf|thumb|center|400px|Mon schéma électronique]]

Résultat du routage :

[[File:2025_PSE-04-systeme-PCB.pdf|thumb|center|400px|Mon routage]]

Photo de la carte soudée :

[[File:2025_PSE-04-systeme-carte.jpg|thumb|center|400px|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]]

Discussion:SE3Groupe2025-21

2026-06-18T10:55:44Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 21/02/2026 : ok pour l'idée
* 24/03/2026 : schématique toujours pas terminée, un routage deconnecté du schéma ?

* Note :
** schématique : 1OO %
** routage : 75 %
** assemblage : 75 %
** code C : 100 %
** tests / mise au point : 75 %
** wiki : 25 %
** gestion projet (avancée régulière) : 75 %

* Note PGM AVR : 11/20
** PGM AVR : C : 66% , R : 90% , P : 25%, W : 50%
** Commentaire : programme de test LED compilé pour un ATmega328p ...

Discussion:SE3Groupe2025-20

2026-06-18T10:54:27Z

Rex :

* 17/02/2026 : pas d'idée clairement détaillée
* 24/03/2026 : corrections demandées non exécutées

* Note :
** schématique : 100 %
** routage : 75 %
** assemblage : 75 %
** code C : 50 %
** tests / mise au point : 50 %
** wiki : 25 %
** gestion projet (avancée régulière) : 75 %

* Note PGM AVR : 8/20
** PGM AVR : C : 85%, R : 66%, P : 0%, W : 33%.

Discussion:SE3Groupe2025-19

2026-06-18T10:53:51Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 24/03/2026 : corrections schématiques non faites ? Un début de routage qui semble mal organisé

* Note :
** schématique : 100 %
** routage : 75 %
** assemblage : 90 %
** code C : 50 %
** tests / mise au point : 100 %
** wiki : 75 %
** gestion projet (avancée régulière) : 75 %

* Note PGM AVR : 13/20
** PGM AVR : C : 85% , R : 85% , P : 40% , W : 75%
** Commentaire : programmes OK pour LED et boutons, vidéos attenantes, rien sur la programmation AVR

Discussion:SE3Groupe2025-19

2026-06-18T10:53:17Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 24/03/2026 : corrections schématiques non faites ? Un début de routage qui semble mal organisé

* Note :
** schématique : 100 %
** routage : 75 %
** assemblage : 90 %
** code C : 50 %
** tests / mise au point : 100 %
** wiki : 75 %
** gestion projet (avancée régulière) : 75 %

* Note PGM AVR :
** PGM AVR : C : 85% , R : 85% , P : 40% , W : 75%
** Commentaire : programmes OK pour LED et boutons, vidéos attenantes, rien sur la programmation AVR

Discussion:SE3Groupe2025-18

2026-06-18T10:52:45Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 24/03/2026 : encore des corrections à effectuer

* Note :
** schématique : 90 %
** routage : 75 %
** assemblage : 100 %
** code C : 100 %
** tests / mise au point : 75 %
** wiki : 25 %
** gestion projet (avancée régulière) : 75 %

* Note PGM AVR : 6/20
** PGM AVR : C : 60%, R : 33% , P : 10% , W : 25%
** Commentaire : peine à la conception, carte non fonctionnelle, pas de schéma, un programme de test LED/boutons avec des broches pour les LED qui ne correspondent pas à la carte.

Discussion:SE3Groupe2025-17

2026-06-18T10:51:50Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 21/02/2026 : ok idée, pas du tout dans la bonne partie du wiki
* 24/03/2026 : git vide

* Note :
** schématique : 100 %
** routage : 90 %
** assemblage : 100 %
** code C : 100 %
** tests / mise au point : 75 %
** wiki : 25 %
** gestion projet (avancée régulière) : 25 %

* Note PGM AVR : 6/20
** PGM AVR : C : 66%, R : 33%, P : 0%, W : 33%
** Commentaire : conception tardive, pas de photo de la carte réalisée, a priori non fonctionnelle, aucun programme trouvé sur le Wiki ou le GIT

Discussion:SE3Groupe2025-16

2026-06-18T10:50:50Z

Rex :

* 17/02/2026 : ok pour idée, à étoffer un peu
* 24/03/2026 : encore des modifications schématique à faire

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 0 %
** code C : 100 %
** tests / mise au point : 0 %
** wiki : 25 %
** gestion projet (avancée régulière) : 50 %

* Note PGM AVR : 4/20
** PGM AVR : C : 90%, R : 0%, P : 0%, W : 10%
** Commentaire : aucune photo de la carte soudée, pas de vidéos, plus généralement le Wiki ne contient rien sur le programmeur

Discussion:SE3Groupe2025-15

2026-06-18T10:49:41Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 24/03/2026 : les corrections demandées ne sont pas faite, un PCB sans rapport ?

* Note :
** schématique : 100 %
** routage : 50 %
** assemblage : 50 %
** code C : 25 %
** tests / mise au point : 50 %
** wiki : 50 %
** gestion projet (avancée régulière) : 50 %

* Note PGM AVR : 11/20
** PGM AVR : C : 85%, R : 66%, P : 33%, W : 50%
** Commentaire : aucune vidéo de démonstration des programmes de test, pour le projet LUFA, utiliser PC1 comme reset de la cible va marcher moyen, le programme libusb n'affiche rien
** Commentaire : courriel envoyé pour demander au binôme de s'expliquer sur l'absence de preuve de fonctionnement.

Discussion:SE3Groupe2025-14

2026-06-18T10:48:14Z

Rex :

[[file:2025-PSE-GXX-PCB.png]]

* 17/02/2026 : ok, si utilisation de ressources externes, ne pas hésiter à sourcer
* 34/03/2026 : schématique OK

* Note :
** schématique : 100 %
** routage : 25 %
** assemblage : 50 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 25 %
** gestion projet (avancée régulière) : 100 %

* Note PGM AVR : 5/20
** PGM AVR : C : 60%, R : 50%, P : 0%, W : 10%
** Commentaire : conception bien tardive, aide massive pour la réalisation, a priori aucun programme

Discussion:SE3Groupe2025-13

2026-06-18T10:46:58Z

Rex :

* 17/02/2026 : Pas de description du système embarqué
* 17/02/2026 : une description trop sommaire pour juger
* 23/03/2026 : des correction schématique, PCB routé mais de nombreuses corrections à effectuer

* Note :
** schématique : 50 %
** routage : 100 %
** assemblage : 75 %
** code C : 0 %
** tests / mise au point : 0 %
** wiki : 10 %
** gestion projet (avancée régulière) : 100 %

* Note PGM AVR : 6/20
** PGM AVR : C : 100%, R : 33%, P : 0%, W : 10%
** Commentaire : photo d'une carte incomplétement soudée, aucune vidéo de démonstration

Discussion:SE3Groupe2025-12

2026-06-18T10:45:46Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 24/03/2026 : le git est dans un état déplorable, de nombreuses corrections sur le shématique dans /hardware

* Note :
** schématique : 10 %
** routage : 10 %
** assemblage : 0 %
** code C : 0 %
** tests / mise au point : 0 %
** wiki : 0 %
** gestion projet (avancée régulière) : 0 %

* Note PGM AVR : 2/20
** PGM AVR : C : 33%, R : 0%, P : 0%, W : 10%.

Discussion:SE3Groupe2025-11

2026-06-18T10:45:01Z

Rex :

[[FIle:2025-PSE-11-PROG.zip]]

* 17/02/2026 : Pas de description du système embarqué
* 21/02/2026 : ok idée, il va falloir limiter le nombre de chose à réaliser, là c'est trop vous courrez à l'échec
* 24/03/2026 : schématique carte principale OK, une correction à faire sur récepteur

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 100 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 100 %
** gestion projet (avancée régulière) : 75 %

* Note PGM AVR : 6/20
** PGM AVR : C : 66%, R : 50%, P : 0%, W : 25%.

Discussion:SE3Groupe2025-10

2026-06-18T10:44:07Z

Rex :

* 17/02/2026 : Pas de descritpion du système embarqué - en fait si, mais à un autre endroit
* 25/02/2026 : première version schématique, quelques erreur à corriger
* 24/03/2026 : correction schématique à effectuer, deux projets qui semblent identiques ?

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 90 %
** code C : 50 %
** tests / mise au point : 90 %
** wiki : 75 %
** gestion projet (avancée régulière) : 75 %

* Note PGM AVR : 15/20
** PGM AVR : C : 90%, R : 90%, P : 66%, W : 66%
** Commentaire : pas de vidéo de démonstration sur la partie programmation AVR mais un brave projet LUFA plutôt bien parti, le programme libusb est dans les limbes

Discussion:SE3Groupe2025-9

2026-06-18T10:43:08Z

Rex :

* 17/02/2026 : idée ok
* 24/03/2026 : git semble vide ?

* Note :
** schématique : 100 %
** routage : 50 %
** assemblage : 75 %
** code C : 25 %
** tests / mise au point : 50 %
** wiki : 50 %
** gestion projet (avancée régulière) : 50 %

* Note PGM AVR : 7/20
** PGM AVR : C : 75%, R : 85%, P : 0%, W : 15%.
** Commentaire : amusant pour le programmateur AVR les vidéos ne correspondent pas à la carte du binôme mais les noms apparents sont bien forcés à B9.

Discussion:SE3Groupe2025-8

2026-06-18T10:41:46Z

Rex :

* 17/02/2026 : pas de description du projet
* 24/03/2026 : problème de git ?

* Note :
** schématique : 25 %
** routage : 25 %
** assemblage : 25 %
** code C : 25 %
** tests / mise au point : 50 %
** wiki : 50 %
** gestion projet (avancée régulière) : 25 %

* Note PGM AVR : 7/20
** PGM AVR : C : 85%, R : 66%, P : 0%, W : 25%
** Commentaire : Le Wiki n'a pas été utilisé comme demandé. Toutes les modifications datent du 14 juin. Concernant le programmateur AVR, des programmes apparaissent le 14 juin :
*** les programmes ne correspondent pas au schéma (LED sur d'autres broches, idem pour la commande du reset) ;
*** aucune vidéo de démonstration.
** Commentaire : Dans ces conditions ces programmes ne peuvent pas être pris en compte.

Discussion:SE3Groupe2025-7

2026-06-18T10:40:03Z

Rex :

* 17/02/2026 : idée ok
* 24/03/2026 : schématiques miniclavier et récepteur ok

* Note :
** schématique : 100 %
** routage : 75 %
** assemblage : 75 %
** code C : 50 %
** tests / mise au point : 25 %
** wiki : 50 %
** gestion projet (avancée régulière) : 25 %

* Note PGM AVR : 5/20
** PGM AVR : C : 75%, R : 25%, P : 0%, W : 25%

Discussion:SE3Groupe2025-2

2026-06-18T10:39:36Z

Rex :

* 17/02/2026 : vue l'application pourquoi un écran ? Deux / trois servos qui bougent des yeux et une bouche ?
* 24/03/2026 : schématique non corrigée ? PCB en cours ?

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 90 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 100 %
** gestion projet (avancée régulière) : 75%

* Note PGM AVR : 19/20
** PGM AVR : C : 85%, R : 75%, P : 100%, W : 100%
** Commentaire : exceptionnel !!

Discussion:SE3Groupe2025-6

2026-06-18T10:39:24Z

Rex :

* 17/02/2026 : prévoir possibilité de sauvegarder les données par USB
* 25/02/2026 : première version schématique, quelques erreur à corriger
* 24/03/2026 : PCB routé, quelques corrections à effectuer

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 100 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 90 %
** gestion projet (avancée régulière) : 100 %

* Note PGM AVR : 18/20
** PGM AVR : C : 90% , R : 100% , P : 90% , W : 66%
** Commentaire : excellent mais manque la démonstration de la signature et le Wiki est trop léger par rapport au travail

Discussion:SE3Groupe2025-4

2026-06-18T10:39:00Z

Rex :

* 17/02/2026 : ok idée
* 24/03/2026 : Kicad trop récent, pas possible de regarder

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 75 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 100 %
** gestion projet (avancée régulière) : 50 %

* Note PGM AVR : 6/20 (note temporaire)
** PGM AVR : C : 85% , R : ? , P : 0%, W : 10%
** Commentaire : courriel pour demander au binôme l'état de la réalisation

Discussion:SE3Groupe2025-2

2026-06-18T10:38:40Z

Rex :

Discussion:SE3Groupe2025-6

2026-06-18T10:37:52Z

Rex :

* 17/02/2026 : prévoir possibilité de sauvegarder les données par USB
* 25/02/2026 : première version schématique, quelques erreur à corriger
* 24/03/2026 : PCB routé, quelques corrections à effectuer

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 100 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 90 %
** gestion projet (avancée régulière) : 100 %

* Note PGM AVR : 18/20
** PGM AVR : C : 90% , R : 100% , P : 90% , W : 66% / Excellent mais manque la démonstration de la signature et le Wiki est trop léger par rapport au travail

Discussion:SE3Groupe2025-4

2026-06-18T10:36:46Z

Rex :

* 17/02/2026 : ok idée
* 24/03/2026 : Kicad trop récent, pas possible de regarder

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 75 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 100 %
** gestion projet (avancée régulière) : 50 %

* Note PGM AVR : 6/20 (note temporaire)
** PGM AVR : C : 85% , R : ? , P : 0%, W : 10% / courriel pour demander au binôme l'état de la réalisation

Discussion:SE3Groupe2025-3

2026-06-18T10:35:26Z

Rex :

* 17/02/2026 : ok idée
* 24/03/2026 : corrections schématiques demandées non effectuées

* Note :
** schématique : 25 %
** routage : 25 %
** assemblage : 25 %
** code C : 10%
** tests / mise au point : 10 %
** wiki : 25 %
** gestion projet (avancée régulière) : 25 %

* Note PGM AVR : 1/20
** PGM AVR : C : 10%, R : 0%, P : 0%, W : 0%

Discussion:SE3Groupe2025-2

2026-06-18T10:34:31Z

Rex :

Discussion:SE3Groupe2025-1

2026-06-18T10:33:25Z

Rex :

* 17/02/2026 : ajouter des Leds façon vu-mètre pour donnerune indication ?
* 03/03/2026 : wiki non rempli, schématique pas commencée
* 24/03/2026 : beaucoup de corrections sur schématique

* Note :
** schématique : 75 %
** routage : 75 %
** assemblage : 50 %
** code C : 0 %
** tests / mise au point : 10 %
** wiki : 25 %
** gestion projet (avancée régulière) : 75 %

* Note PGM AVR : 7/20
** PGM AVR -> C : 75% , R : 66%, P : 0%, W : 25%

Discussion:SE3Groupe2025-15

2026-06-18T10:22:53Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 24/03/2026 : les corrections demandées ne sont pas faite, un PCB sans rapport ?

* Note :
** schématique : 100 %
** routage : 50 %
** assemblage : 50 %
** code C : 25 %
** tests / mise au point : 50 %
** wiki : 50 %
** gestion projet (avancée régulière) : 50 %

PGM AVR : C : 85%, R : 66%, P : 33%, W : 50% / Aucune vidéo de démonstration des programmes de test, pour le projet LUFA, utiliser PC1 comme reset de la cible va marcher moyen, le programme libusb n'affiche rien

Courriel envoyé pour demander au binôme de s'expliquer sur l'absence de preuve de fonctionnement.

Discussion:SE3Groupe2025-14

2026-06-18T09:58:40Z

Rex :

[[file:2025-PSE-GXX-PCB.png]]

* 17/02/2026 : ok, si utilisation de ressources externes, ne pas hésiter à sourcer
* 34/03/2026 : schématique OK

* Note :
** schématique : 100 %
** routage : 25 %
** assemblage : 50 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 25 %
** gestion projet (avancée régulière) : 100 %

PGM AVR : C : 60%, R : 50%, P : 0%, W : 10% / Conception bien tardive, aide massive pour la réalisation, a priori aucun programme

Discussion:SE3Groupe2025-13

2026-06-18T09:55:18Z

Rex :

* 17/02/2026 : Pas de description du système embarqué
* 17/02/2026 : une description trop sommaire pour juger
* 23/03/2026 : des correction schméatique, PCB routé mais de nombreuses corrections à effectuer

* Note :
** schématique : 50 %
** routage : 100 %
** assemblage : 75 %
** code C : 0 %
** tests / mise au point : 0 %
** wiki : 10 %
** gestion projet (avancée régulière) : 100 %

PGM AVR : C : 100%, R : 33%, P : 0%, W : 10% / Photo d'une carte incomplétement soudée, aucune vidéo de démonstration

Discussion:SE3Groupe2025-16

2026-06-18T09:51:24Z

Rex :

* 17/02/2026 : ok pour idée, à étoffer un peu
* 24/03/2026 : encore des modifications schématique à faire

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 0 %
** code C : 100 %
** tests / mise au point : 0 %
** wiki : 25 %
** gestion projet (avancée régulière) : 50 %

PGM AVR : C : 90%, R : 0%, P : 0%, W : 10% / Aucune photo de la carte soudée, pas de vidéos, plus généralement le Wiki ne contient rien sur le programmeur

Discussion:SE3Groupe2025-17

2026-06-18T09:46:27Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 21/02/2026 : ok idée, pas du tout dans la bonne partie du wiki
* 24/03/2026 : git vide

* Note :
** schématique : 100 %
** routage : 90 %
** assemblage : 100 %
** code C : 100 %
** tests / mise au point : 75 %
** wiki : 25 %
** gestion projet (avancée régulière) : 25 %

PGM AVR : C : 66%, R : 33%, P : 0%, W : 33% / Conception tardive, pas de photo de la carte réalisée, a priori non fonctionnelle, aucun programme trouvé sur le Wiki ou le GIT

Discussion:SE3Groupe2025-18

2026-06-18T09:40:19Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 24/03/2026 : encore des corrections à effectuer

* Note :
** schématique : 90 %
** routage : 75 %
** assemblage : 100 %
** code C : 100 %
** tests / mise au point : 75 %
** wiki : 25 %
** gestion projet (avancée régulière) : 75 %

PGM AVR : C : 60%, R : 33% , P : 10% , W : 25% / Peine à la conception, carte non fonctionnelle, pas de schéma, un programme de test LED/boutons avec des broches pour les LED qui ne correspondent pas à la carte.

Discussion:SE3Groupe2025-19

2026-06-18T09:31:37Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 24/03/2026 : corrections schématiques non faites ? Un début de routage qui semble mal organisé

* Note :
** schématique : %
** routage : %
** assemblage : %
** code C : %
** tests / mise au point : %
** wiki : %
** gestion projet (avancée régulière) : %

PGM AVR : C : 85% , R : 85% , P : 40% , W : 75% / Programmes OK pour LED et boutons, vidéos attenantes, rien sur la programmation AVR

Discussion:SE3Groupe2025-12

2026-06-18T08:37:19Z

Rex :

Discussion:SE3Groupe2025-20

2026-06-18T08:35:27Z

Rex :

* 17/02/2026 : pas d'idée clairement détaillée
* 24/03/2026 : corrections demandées non exécutées

* Note :
** schématique : %
** routage : %
** assemblage : %
** code C : %
** tests / mise au point : %
** wiki : %
** gestion projet (avancée régulière) : %

PGM AVR : C : 85%, R : 66%, P : 0%, W : 33%.

Discussion:SE3Groupe2025-21

2026-06-18T08:33:33Z

Rex :

* 17/02/2026 : pas de description du système embarqué
* 21/02/2026 : ok pour l'idée
* 24/03/2026 : schématique toujours pas terminée, un routage deconnecté du schéma ?

* Note :
** schématique : %
** routage : %
** assemblage : %
** code C : %
** tests / mise au point : %
** wiki : %
** gestion projet (avancée régulière) : %

PGM AVR : C : 66% , R : 90% , P : 25%, W : 50% / Programme de test LED compilé pour un ATmega328p ...

Discussion:SE3Groupe2025-10

2026-06-18T08:19:53Z

Rex :

* 17/02/2026 : Pas de descritpion du système embarqué - en fait si, mais à un autre endroit
* 25/02/2026 : première version schématique, quelques erreur à corriger
* 24/03/2026 : correction schématique à effectuer, deux projets qui semblent identiques ?

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 90 %
** code C : 50 %
** tests / mise au point : 90 %
** wiki : 75 %
** gestion projet (avancée régulière) : 75 %

PGM AVR : C : 90%, R : 90%, P : 66%, W : 66% / Pas de vidéo de démonstration sur la partie programmation AVR mais un brave projet LUFA plutôt bien parti, le programme libusb est dans les limbes

Discussion:SE3Groupe2025-9

2026-06-18T08:19:33Z

Rex :

* 17/02/2026 : idée ok
* 24/03/2026 : git semble vide ?

* Note :
** schématique : 100 %
** routage : 50 %
** assemblage : 75 %
** code C : 25 %
** tests / mise au point : 50 %
** wiki : 50 %
** gestion projet (avancée régulière) : 50 %

PGM AVR : C : 75%, R : 85%, P : 0%, W : 15%.

Amusant pour le programmateur AVR les vidéos ne correspondent pas à la carte du binômes mais les noms apparents sont bien forcés à B9.

Discussion:SE3Groupe2025-7

2026-06-18T08:19:08Z

Rex :

Discussion:SE3Groupe2025-4

2026-06-18T08:18:52Z

Rex :

* 17/02/2026 : ok idée
* 24/03/2026 : Kicad trop récent, pas possible de regarder

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 75 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 100 %
** gestion projet (avancée régulière) : 50 %

PGM AVR : C : 85% , R : , P : 0%, W : 10% / courriel pour demander au binôme l'état de la réalisation

Discussion:SE3Groupe2025-1

2026-06-18T08:18:36Z

Rex :

Discussion:SE3Groupe2025-11

2026-06-18T08:17:17Z

Rex :

[[FIle:2025-PSE-11-PROG.zip]]

* 17/02/2026 : Pas de description du système embarqué
* 21/02/2026 : ok idée, il va falloir limiter le nombre de chose à réaliser, là c'est trop vous courrez à l'échec
* 24/03/2026 : schématique carte principale OK, une correction à faire sur récepteur

* Note :
** schématique : %
** routage : %
** assemblage : %
** code C : %
** tests / mise au point : %
** wiki : %
** gestion projet (avancée régulière) : 75 %

PGM AVR : C : 66%, R : 50%, P : 0%, W : 25%.

Discussion:SE3Groupe2025-10

2026-06-18T08:11:56Z

Rex :

* 17/02/2026 : Pas de descritpion du système embarqué - en fait si, mais à un autre endroit
* 25/02/2026 : première version schématique, quelques erreur à corriger
* 24/03/2026 : correction schématique à effectuer, deux projets qui semblent identiques ?

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 90 %
** code C : 50 %
** tests / mise au point : 90 %
** wiki : 75 %
** gestion projet (avancée régulière) : 75 %

PGM AVR : C : 90%, R : 90%, P : 66%, W : 75% / Pas de vidéo de démonstration sur la partie programmation AVR mais un brave projet LUFA plutôt bien parti, le programme libusb est dans les limbes

Discussion:SE3Groupe2025-10

2026-06-18T08:11:22Z

Rex :

* 17/02/2026 : Pas de descritpion du système embarqué - en fait si, mais à un autre endroit
* 25/02/2026 : première version schématique, quelques erreur à corriger
* 24/03/2026 : correction schématique à effectuer, deux projets qui semblent identiques ?

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 90 %
** code C : 50 %
** tests / mise au point : 90 %
** wiki : 75 %
** gestion projet (avancée régulière) : 75 %

PGM AVR : C : 90%, R : 90%, P : 66%, W : 75% / Pas de vidéo de démonstration sur la partie programmation AVR mais un projet LUFA plutôt bien parti, le programme libusb est dans les limbes

Discussion:SE3Groupe2025-9

2026-06-18T08:05:29Z

Rex :

* 17/02/2026 : idée ok
* 24/03/2026 : git semble vide ?

* Note :
** schématique : 100 %
** routage : 50 %
** assemblage : 75 %
** code C : 25 %
** tests / mise au point : 50 %
** wiki : 50 %
** gestion projet (avancée régulière) : 50 %

PGM AVR : C : 75%, R : 85%, P : 0%, W : 25%.

Amusant pour le programmateur AVR les vidéos ne correspondent pas à la carte du binômes mais les noms apparents sont bien forcés à B9.

Discussion:SE3Groupe2025-8

2026-06-18T08:00:52Z

Rex :

* 17/02/2026 : pas de description du projet
* 24/03/2026 : problème de git ?

* Note :
** schématique : 25 %
** routage : 25 %
** assemblage : 25 %
** code C : 25 %
** tests / mise au point : 50 %
** wiki : 50 %
** gestion projet (avancée régulière) : 25 %

PGM AVR : C : 85%, R : 66%, P : 0%, W : 25%

Le Wiki n'a pas été utilisé comme demandé. Toutes les modifications datent du 14 juin.
Concernant le programmateur AVR, des programmes apparaissent le 14 juin :
* les programmes ne correspondent pas au schéma (LED sur d'autres broches, idem pour la commande du reset) ;
* aucune vidéo de démonstration.
Dans ces conditions ces programmes ne peuvent pas être pris en compte.

Discussion:SE3Groupe2025-7

2026-06-18T06:59:19Z

Rex :

Discussion:SE3Groupe2025-6

2026-06-18T06:56:22Z

Rex :

* 17/02/2026 : prévoir possibilité de sauvegarder les données par USB
* 25/02/2026 : première version schématique, quelques erreur à corriger
* 24/03/2026 : PCB routé, quelques corrections à effectuer

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 100 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 90 %
** gestion projet (avancée régulière) : 100 %

PGM AVR : C : 90% , R : 100% , P: 90% : , W : 66% / Excellent mais manque la démonstration de la signature et le Wiki est trop léger par rapport au travail

Discussion:SE3Groupe2025-4

2026-06-18T06:50:40Z

Rex :

* 17/02/2026 : ok idée
* 24/03/2026 : Kicad trop récent, pas possible de regarder

* Note :
** schématique : 100 %
** routage : 100 %
** assemblage : 75 %
** code C : 100 %
** tests / mise au point : 100 %
** wiki : 100 %
** gestion projet (avancée régulière) : 50 %

PGM AVR : C : 85% , R : , P : 0%, W : 25% / courriel pour demander au binôme l'état de la réalisation