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

SE4Binome2024-2

2025-01-26T19:01:58Z

Mbarret : /* Résultat des tests */

= Pico Ordinateur =
Ce projet vise à concevoir un pico ordinateur divisé en plusieurs parties, réalisées par différents binômes. Le rôle de notre binôme est de développer une carte fille équipée d'un microcontrôleur ATMega328p et d'un écran LCD contrôlé par un HD44780, en plus de la conception d'un Shield et d'un ordonnanceur. Cette carte sera connectée à une carte mère via un connecteur HE10 et devra gérer l'affichage de caractères ASCII, ainsi que quelques commandes spécifiques VT100. De plus, nous ajouterons une RAM SPI pour améliorer les performances de gestion de l'affichage.

Lien du git : https://gitea.plil.fr/mbarret/pico_kaoutar_maxime

== Carte Fille (Écran LCD) ==

=== Description ===
La carte fille que nous avons développée contient les éléments suivants :

* Un microcontrôleur '''ATMega328p''' pour la gestion de l'affichage.
* Un écran '''LCD avec contrôleur HD44780''' pour l'affichage de caractères ASCII.
* Un '''potentiomètre 3310P''' pour ajuster la luminosité des cristaux liquides de l'écran.
* Un '''connecteur HE10''' pour relier la carte fille à la carte mère.
* Un '''connecteur AVR ISP''' pour la programmation du microcontrôleur.
* Une '''RAM SP'''I (e.g. FM24C04B-GTR) pour stocker temporairement les données d'affichage.

=== Fonctionnalités Demandées ===

* Gestion de l'écran LCD : Le microcontrôleur doit gérer les écrans HD44780 avec 1, 2, 3 ou 4 lignes et afficher des caractères ASCII.
* Saut de ligne et retour chariot : Les caractères spéciaux `\n` et `\r` doivent être pris en compte.
* Commandes VT100 : Quelques codes VT100, notamment ceux pour le déplacement du curseur, doivent être supportés.
* Défilement automatique : Le contrôleur HD44780 doit être configuré pour activer le mode de défilement automatique.
* Connexion SPI : La carte mère doit envoyer les commandes via SPI. Le premier octet envoyé doit être le code commande `0x01`, suivi des caractères à afficher.
* Vérification de la disponibilité de l'écran : La carte fille met la ligne SPI en état haut lorsque l'affichage est en cours. La carte mère doit attendre que l'état soit bas avant de transmettre de nouvelles données, ou envoyer des commandes `0xFF` pour vérifier si l'écran est prêt.

=== Ajout d'une RAM SPI ===
Pour complexifier la carte fille, nous ajouterons une RAM SPI (e.g. FM24C04B-GTR). Cette mémoire permet de stocker temporairement les caractères reçus par SPI avant leur affichage. Le microcontrôleur de la carte fille rafraîchit régulièrement l'écran en lisant les données de la RAM, ce qui améliore la fluidité de l'affichage et permet de libérer la carte mère plus rapidement.

Nous avons choisi la RAM FM25W256-G disponible chez RS Component.
https://fr.rs-online.com/web/p/memoires-fram/1254228?gb=s

Voici un schéma simplifié de la communication entre les composants :
* La carte mère écrit dans la RAM SPI via le bus SPI.
* Le microcontrôleur de la carte fille lit les données de la RAM SPI et les envoie à l'écran LCD pour mise à jour régulière.

=== Schéma de Connexion ===
[[Fichier:carteEcran.pdf|922x922px]]

=== Ajout de sélecteurs ===
Ajouter des sélecteurs permet de choisir entre le microprocesseur et la connexion SPI venant de la carte mère. Pour cela, nous avons fait une simulation sur LTSpice. Voici le schéma et sa simulation :
[[Fichier:Circuit de simulation.png|gauche|vignette|577x577px]]
[[Fichier:Simulation.png|néant|vignette|501x501px]]

<br><br>
La fonction PULSE nous permet de simuler le SELECT. Nous avons pris des modèles de transistors déjà sur le logiciel pour pouvoir simuler.

On remarque que, sur la simulation, un des transistors PMOS est inversee. Quand un des PMOS est passant, l'autre est bloquant. Cette simulation nous permet de valider notre sélecteur pour notre carte écran. Nous avons reproduit ce schéma dans Kicad.

=== Carte écran soudée ===
Nous avons terminé de souder complétement notre carte et il est temps de la tester. Pour vérifier le bon fonctionnement de notre travail, nous utiliserons un code test dédié à notre écran HD44780 fournis par la librairie du même nom sur l'IDE Arduino. Cette méthode de test nous convient parfaitement puisque nous voulons uniquement vérifier son fonctionnement.

Malheureusement, le code ne fonctionne pas directement à cause de mauvais branchement sur notre connecteur. On avait relié directement les pins Enable, et RS du connecteur écran à notre 5V. Nous avons du alors faire du bricolage pour la réparer. Pour ce faire, nous avons donc coupé les piste du RS et Enable pour les relier à des pins non utilisés du microcontrôleur.
[[Fichier:Resolution carte ecran.png|centré|vignette]]

Après ces réparations, on arrive à afficher le texte voulu grâce au code d'exemple Arduino :
[[Fichier:Ecran.jpg|centré|vignette]]

Il nous faut désormais tester notre carte écran en code C. Pour ce faire, nous avons récupéré le code des Masters I2L et mis à jour les fuses de l'atmega328p. Cependant lors de l'upload du code, notre Atmega n'est plus détecté. Nous devons alors vérifier la clock par le biais d'un oscilloscope.

Cette carte a du être recommencée car après l'ajout de commande changeant les fuses du microprocesseur, ce dernier n'était plus reconnu. Ainsi nous avons pris le temps de resouder une carte écran.

Apres cela un autre problème (cette fois ci de circuit) est que nous perdons 1,5V entre le Shield et la carte écran. Apres quelque test au multimètre sans réponse nous avons vérifié la clock au niveau du Shield et au niveau de la carte écran.
[[Fichier:Clock shield.jpg|gauche|vignette|594x594px|Clock SPI sur le Shield]]
[[Fichier:Clock carte ecran.jpg|néant|vignette|484x484px|Clock SPI sur la carte écran]]
<br>
<br>
<br>
<br>
Cela est selon nous la cause de non fonctionnement du transfert de donnée entre les deux cartes.

== Ordonnanceur et Gestion du Contexte des Tâches ==

=== Introduction ===
L'ordonnanceur est un composant clé de notre pico-ordinateur, assurant la gestion et l'exécution ordonnée des différentes tâches. Il permet un partage équitable du temps processeur grâce à un algorithme de round-robin. De plus, il vérifie la disponibilité des ressources matérielles, comme les lignes SPI et les périphériques LED.

La gestion du contexte des tâches est assurée par des macros de sauvegarde (`SAVE_REGISTERS`) et de restauration (`RESTORE_REGISTERS`) des registres, permettant ainsi d'interrompre et de reprendre l'exécution de chaque tâche.

=== Structure des Tâches ===

Chaque tâche est représentée par la structure `process` :

<syntaxhighlight lang="cpp">
typedef struct process {
uint16_t stackPointer; // Adresse du pointeur de pile, définissant le contexte de la tâche
void (*addressFunction)(void); // Adresse de la fonction à exécuter
int state; // État de la tâche (0 = prête, 1 = en cours, 2 = terminée)
} process;
</syntaxhighlight>

Dans ce programme, `stackPointer` stocke la position de la pile de chaque tâche, `addressFunction` est un pointeur vers la fonction de la tâche, et `state` représente l’état actuel de la tâche.

=== Initialisation des Tâches ===

Les tâches sont initialisées dans le tableau `task`, contenant des fonctions telles que `Serial_Led`, `LED1_blink`, et `Serial_Message`, chacune avec son pointeur de pile initial :

<syntaxhighlight lang="cpp">
process task[NB_TASKS] = {
{0x700, Serial_Led, 0},
{0x600, LED1_blink, 0},
{0x500, Serial_Message, 0}
};
</syntaxhighlight>

=== Macros de Sauvegarde et Restauration des Registres ===

Les macros `SAVE_REGISTERS()` et `RESTORE_REGISTERS()` permettent de sauvegarder et de restaurer les registres lors du changement de tâche :

<syntaxhighlight lang="cpp">
#define RESTORE_REGISTERS() \
asm volatile ( \
/* Code pour restaurer les registres ici */ \
);

#define SAVE_REGISTERS() \
asm volatile ( \
/* Code pour sauvegarder les registres ici */ \
);
</syntaxhighlight>

Ces macros utilisent des instructions d’assembleur pour pousser et dépiler les registres, préservant ainsi l’état complet de la tâche au moment de l'interruption.

=== Ordonnancement des Tâches ===

L'ordonnanceur suit l'algorithme round-robin. La fonction `scheduler()` passe d'une tâche à la suivante dans le tableau `task` :

<syntaxhighlight lang="cpp">
void scheduler() {
currentTask++;
if (currentTask == NB_TASKS) currentTask = 0; // Retour à la première tâche après la dernière
}
</syntaxhighlight>

=== Gestion des Interruptions ===

L'interruption liée au minuteur (`TIMER1_COMPA_vect`) déclenche l'ordonnanceur et le changement de tâche, en sauvegardant et restaurant le contexte :

<syntaxhighlight lang="cpp">
ISR(TIMER1_COMPA_vect, ISR_NAKED) {
SAVE_REGISTERS();
task[currentTask].stackPointer = SP;
scheduler();
SP = task[currentTask].stackPointer;
RESTORE_REGISTERS();
asm volatile("reti");
}
</syntaxhighlight>

* `SAVE_REGISTERS()` : sauvegarde le contexte de la tâche courante.
* `scheduler()` : passe à la tâche suivante.
* `RESTORE_REGISTERS()` : restaure le contexte de la nouvelle tâche.
* `asm volatile("reti");` : retourne de l'interruption en restaurant l'état.

=== Initialisation du Système ===

Les fonctions d'initialisation préparent les ressources, telles que les LED et l'UART, pour la communication série.

<syntaxhighlight lang="cpp">
void LED_init() {
DDRC |= (1<<LED1) | (1<<LED2);
DDRD |= (1<<LED3) | (1<<LED4) | (1<<LED5);
PORTC |= (1<<LED1) | (1<<LED2);
PORTD |= (1<<LED3) | (1<<LED4) | (1<<LED5);
}
</syntaxhighlight>

=== Fonctions des Tâches ===

Chaque tâche a une fonction dédiée. Par exemple, `LED1_blink` fait clignoter une LED, et `Serial_Message` envoie des messages en série.

<syntaxhighlight lang="cpp">
void LED1_blink() {
while(1) {
PORTC ^= (1<<LED1);
_delay_ms(150);
}
}
</syntaxhighlight>

Ces fonctions sont répétitives pour les autres LED, avec des délais différents pour créer des clignotements variés.

=== Communication Série ===

L'initialisation de l'UART et les fonctions de réception et de transmission sont définies pour permettre la communication série :

<syntaxhighlight lang="cpp">
void USART_Init(unsigned int ubrr) {
UBRR0H = (unsigned char)(ubrr>>8);
UBRR0L = (unsigned char)ubrr;
UCSR0B = (1<<RXEN0) | (1<<TXEN0);
UCSR0C = (1<<USBS0) | (3<<UCSZ00);
}

unsigned char USART_Receive(void) {
while (!(UCSR0A & (1<<RXC0)));
return UDR0;
}
</syntaxhighlight>

=== Fonction `main` ===

La fonction `main` configure les LED, l'UART, et initialise l'ordonnanceur avant de lancer la première tâche :

<syntaxhighlight lang="cpp">
int main(void) {
cli();
LED_init();
USART_Init(MYUBRR);
init_minuteur(256, PERIODE);
for(int i = 1; i < NB_TASKS; i++) init_pile(i);
SP = task[0].stackPointer;
sei();
task[0].addressFunction();
}
</syntaxhighlight>

1. `cli()` : désactive les interruptions.
2. `LED_init()` et `USART_Init()` : initialisent les LED et la communication série.
3. `init_minuteur()` : initialise le minuteur avec une période.
4. `init_pile(i)` : initialise la pile pour chaque tâche.
5. `sei()` : réactive les interruptions.

L'ordonnanceur gère ainsi le contexte des tâches en suivant une séquence de round-robin, tout en assurant que chaque tâche exécute son cycle de manière autonome et en garantissant la disponibilité des ressources matérielles.

=== Fonction `wait()` ===
Comme première amélioration de votre ordonnanceur, il nous a été demandé de mettre en place un état endormi pour nos processus. Pour cela nous avons créer la procédure wait() suivante :

<syntaxhighlight lang="cpp">
void wait(int time_ms){
task[currentTask].state = SLEEP;
task[currentTask].sleeping_time = time_ms;
TCNT1 = 0;
TIMER1_COMPA_vect();
}
</syntaxhighlight>On modifie aussi les procedures des LED :<syntaxhighlight lang="cpp">
void LED1_blink(){
while(1){
PORTC ^= (1<<LED1);
_delay_ms(200);
wait(5000);

}
}
</syntaxhighlight>Et la structure :<syntaxhighlight lang="cpp">
typedef struct{
uint16_t stackPointer; // stack pointer, défini le début du process
void (*addressFunction)(void); // adresse de l'instruction en cours
int state; // état de la fonction (Awake ou Idle)
int sleeping_time;
}process;
</syntaxhighlight>En faisant cela dès qu'une tâche est appelée en présence d'un wait on met à jour son état ainsi que son temps d'attente. Par la suite, on modifie le scheduler() pour réveiller les tâches endormies si nécessaire : <syntaxhighlight lang="cpp">
void scheduler (){
for(int i=0;i<NB_TASKS;i++){
if(task[i].state==SLEEP){
task[i].sleeping_time -= REDUCE_TIME;
if(task[i].sleeping_time <= 0){
task[i].sleeping_time = 0;
task[i].state = AWAKE;
}
}
}
do{
currentTask ++;
if(currentTask >= NB_TASKS) currentTask = 0; // ordonnanceur en mode Round Robin
}while(task[currentTask].state == SLEEP);
}
</syntaxhighlight>Avec ces modifications nous avons réussi à obtenir le résultat suivant :
[[Fichier:Wait.mp4|néant|vignette]]

Nous avons eu un problème avec la LED rouge. En effet, apres de tres nombreuses tentatives, nous n'avions pas reussi a la faire clignoter. Nous avons abordé plusieurs methode pour débugger notre code comme manipuler la LED rouge seule. C'est plus tard que nous avons compris que le problème venait de l'utilisation du pin PD1 de notre carte. Le pin PD1 peut aussi être utilisé pour gérer la connexion RX. Ainsi, quand nous voulions utiliser l'instruction <code>USART_Init(MYUBRR);</code> cela ne permettait pas de faire clignoter la LED. Cette LED sera donc inutilisée dans la suite du projet si nous utilisons l'UART.

[[Fichier:Wait2.mp4|néant|vignette|300x300px]]

== Carte Shield ==

=== Description ===
La carte Shield est une carte mère qui sert à connecter et contrôler divers périphériques, notamment la carte fille (écran), un clavier, et d'autres composants. Nous avons conçu cette carte pour faciliter la gestion des communications SPI entre la carte mère et les différentes cartes filles.

=== Connectivité SPI ===
La carte Shield utilise plusieurs lignes SPI pour communiquer avec les cartes filles. Chaque périphérique, comme l'écran, est assigné à une ligne SPI spécifique. La carte Shield vérifie également la disponibilité des périphériques avant d'envoyer des commandes via SPI. Nous avons effectué plusieurs test afin de vérifier le bon fonctionnement de notre carte Shield. Nous avons tester le fonctionnement des LED, la connectivité de la carte SD, et nous avons utiliser le Shield pour faire un timer sur un afficheur 7 segments.
<br><br>
[[Fichier:Diode.jpg|gauche|vignette|412x412px|Test des LEDs]]
[[Fichier:TestSD.jpg|vignette|Test de la carte SD]]
[[Fichier:Video7seg.mp4|vignette|400x400px|Timer sur un afficheur 7 segments|néant]]

=== Schéma de Connexion ===
Voici notre Schematic Kicad pour le Shield:

[[Fichier:picoshield.pdf|922x922px]]

== Bilan de puissance ==
Afin de déterminer la puissance consommée par notre carte, et se coordonner avec le binôme s'occupant de la carte mère, nous effectuons un bilan de puissance. Pour chaque composant nous nous sommes référés à leur datasheets :

* HD44780 : '''150 µA''' ([https://www.sparkfun.com/datasheets/LCD/HD44780.pdf datasheet])
* Ecran LCD 2x16 : '''1,2 mA''' ([https://docs.rs-online.com/d50a/0900766b8127cd1d.pdf datasheet])
* LED de Test : 1,7/510 = 3 mA donc comme nous en avons 2 on a besoin de '''6 mA'''
* Atmega : '''14 mA''' ([https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf datasheet])
* FRAM25 : '''2 mA ('''[https://docs.rs-online.com/e062/A700000007893278.pdf datasheet])
* MUX CD405 : '''10 mA''' ([https://www.ti.com/lit/ds/symlink/cd4051b.pdf datasheet])

Au total, notre carte consommera '''0,17 W'''.
== Tests Réalisés ==

=== Tests de l'Ordonnanceur ===
* Gestion des tâches : Nous avons simulé plusieurs tâches, dont l'affichage et la gestion du clavier, et vérifié que l'ordonnanceur passe correctement d'une tâche à l'autre.
* En utilisant le logiciel minicom nous avons pus lancer une 2eme tâche en parallèle d'une première tâche. En tapant "a" une deuxième LED se met à clignoter.
[[Fichier:Videoprocess.mp4|centré|vignette|400x300px|Test de l'ordonnanceur : lancer une tâche. ]]

*Pour tester la connexion série du Shield avec le 7 segment on utilise l'outil Minicom de nouveau afin de faire apparaitre un caractère sur le 7 segment. Pour cela on utilise la fonction Serial Message tout en modifiant le reste du code en conséquence :

<syntaxhighlight lang="cpp">
void Serial_Message(){ //lecture, ecriture port serie et ecriture sur 7 Seg
unsigned char data;
spi_display_cmd1(0x76);
_delay_ms(100);
while(1){
data = USART_Receive();
if (data >= '0' && data <= '9') {
spi_display_data(data, '0', '0', '0');
}
USART_Transmit(data);
}
}
</syntaxhighlight>En utilisant cette fonction nous avons pu afficher un caractère. Cependant nous avons remarquer un retard lors de l'affichage du caractère. Nous avons essayer plusieurs méthode comme sectionner ce que l'on voulait faire en 3 taches mais cela n'a pas fonctionner. Apres longues observation de l'exécution de notre programme, nous avons vu que nous pouvions taper nos caractères sur Minicom, mais l'écran LCD ne se mettait a jour seulement lorsque la LED2 était allumée. Cela montre que le problème était que la LED puisqu'elle était connectée au pin CS. Le fait de la faire clignoter empêchait l'affichage. Apres correction (la LED2 devait rester allumée) :
[[Fichier:Fin Ordonnanceur 7 Segment.mp4|centré|vignette|400x300px|7 segment et minicom]]

== Tests de la RAM SPI ==

Pour tester la mémoire RAM SPI, plusieurs étapes ont été mises en œuvre pour garantir la bonne communication et la gestion des données. Voici les principales actions réalisées :

=== Fonctions de gestion de l'accès à la RAM ===
* Les fonctions <code>ram_select</code> et <code>ram_deselect</code> ont été ajoutées pour assurer un accès exclusif à la mémoire :
<syntaxhighlight lang="c">
void ram_select() {
SPI_PORT &= ~(1 << SPI_SS); // Sélectionne la RAM
}

void ram_deselect() {
SPI_PORT |= (1 << SPI_SS); // Désélectionne la RAM
}
</syntaxhighlight>

* Les fonctions <code>select_microcontroller</code> et <code>select_shield</code> ont été introduites pour basculer entre le Microcontrôleur et le Shield :
<syntaxhighlight lang="c">
void select_microcontroller() {
PORTC |= (1 << DATA0); // Active le microcontrôleur
_delay_ms(1); // Temps de stabilisation
}

void select_shield() {
PORTC &= ~(1 << DATA0); // Active le Shield
_delay_ms(1); // Temps de stabilisation
}
</syntaxhighlight>

=== Opérations de base sur la RAM ===
* Lecture (<code>RAM_read</code>), écriture (<code>RAM_write</code>), et effacement (<code>RAM_clear</code>) ont été implémentés pour interagir avec la mémoire via le bus SPI.
* Exemple d'écriture :
<syntaxhighlight lang="c">
void RAM_write(uint16_t address, char *data) {
RAM_write_enable();
CS_LOW();
spi_exch(WRITE);
spi_exch((address >> 8) & 0xFF);
spi_exch(address & 0xFF);
for (uint8_t i = 0; i < strlen(data); i++) {
spi_exch(data[i]);
}
RAM_write_disable();
CS_HIGH();
}
</syntaxhighlight>

* Exemple de lecture :
<syntaxhighlight lang="c">
void RAM_read(uint16_t address, char *buffer, uint8_t length) {
CS_LOW();
spi_exch(READ);
spi_exch((address >> 8) & 0xFF);
spi_exch(address & 0xFF);
for (uint8_t i = 0; i < length; i++) {
buffer[i] = spi_exch(0x00);
}
buffer[length] = '\0';
CS_HIGH();
}
</syntaxhighlight>

=== Validation des fonctionnalités ===
* Un test basique avec des données simples a été effectué pour vérifier que les données écrites pouvaient être lues sans erreur.
* Un test de stress par brute force a été réalisé pour écrire et lire des données massivement tout en affichant les résultats avec un <code>printf</code>. Cela a permis de confirmer la robustesse du système.

=== Résultat des tests ===
* Le premier test (illustré dans l'image ci-dessous) montre que la RAM SPI fonctionne correctement, avec des données transmises et récupérées sans perte. Cependant, on remarque l'apparition de différents symboles avant notre message affiché depuis la RAM. On a donc émis deux hypothèses : => Il existe des zones mémoire de la RAM qui contient des données ne pouvant être modifiées et ce sont ces données là que nous lisons avant notre message. => Notre fonction pour clear la RAM avec des '0' n'est pas bien fonctionnelle. Avec une lecture plus approfondie de la datasheet, il n'est fait nulle part mention d' "une zone interdite" ou quelque chose qui pourrait s'en rapprocher. C'est pourquoi on pense que notre seconde hypothèse est la plus probable malgré une fonction qui, au premier regard, semble correcte.
[[Fichier:Ram fonctionne.png|centré|vignette|527x527px|La RAM fonctionne]]
* Dans une tentative de faire disparaître ces symboles non désirés, nous avons essayé une commande printf de dernier espoir ("Printf ici"). A notre grande surprise, le message de cette commande était directement affiché sur notre écran. Nous avons donc fait des recherches sur ce sujet et il semblerait qu'initialement, il aurait fallu réalisé une fonction de redirection de flux afin de pouvoir visualiser le contenu du print. Or nous n'avons rien réalisé de tel. D'après ce que nous avons trouvé sur Internet, certains dispositif tel que des boards Arduino ou autres, ont directement une fonction de redirection de flux d'implémentée. Nous soupçonnons donc le programmateur ou le microcontrôleur utilisé d'en avoir une également. [[Fichier:Printf.jpg|centré|vignette]]

== Conclusion ==

=== Tests de la RAM SPI ===
La mémoire RAM SPI ne fonctionne pas encore comme prévu avec notamment ces caractères non souhaités.

Malgré nos efforts, nous avons remarqué une chute de tension significative de 1,5 V entre le Shield et la carte écran. Cette chute pourrait expliquer les dysfonctionnements observés dans la communication SPI. Bien que la carte écran fonctionne correctement lorsqu’elle est utilisée seule, elle ne parvient pas à établir une communication via le Shield. Cependant, les différentes étapes de conception et de test nous semblent alignées, et nous pensons être sur la bonne voie pour résoudre ce problème.

=== Ordonnanceur et Gestion des Tâches ===
Concernant l’ordonnanceur, toutes les consignes ont été respectées et implémentées avec succès. Le scheduler suit une approche Round-Robin efficace pour gérer les tâches concurrentes. Grâce aux interruptions et à une gestion des délais non bloquants, il permet une répartition optimale du temps CPU entre les tâches, tout en garantissant une bonne réponse pour les processus critiques. Les tests ont validé le bon fonctionnement des différentes tâches, comme la gestion des LEDs, la communication série et l’affichage.

=== Pistes d’amélioration ===
Pour améliorer le fonctionnement global et résoudre les problèmes liés au SPI, voici quelques pistes à explorer :
* Identifier la ou les causes de la chute de tension entre le Shield et la carte écran, éventuellement en vérifiant les connexions, la qualité des câbles ou l’alimentation.
* Tester la communication SPI avec d'autres configurations ou composants pour valider chaque élément individuellement.

En résumé, bien que des défis restent à résoudre pour la partie SPI, nous avons validé l’ensemble des fonctionnalités de l’ordonnanceur. Nous sommes confiants que les ajustements proposés nous permettront d’obtenir un système pleinement fonctionnel.

SE4Binome2024-2

2024-12-16T12:08:09Z

Mbarret :

SE4Binome2024-2

2024-11-07T19:46:47Z

Mbarret : /* Pico Ordinateur */

SE4Binome2024-2

2024-10-23T10:19:55Z

Mbarret : /* Bilan de puissances */

SE4Binome2024-2

2024-10-23T09:12:35Z

Mbarret : /* Tests Réalisés */

SE4Binome2024-2

2024-10-23T09:12:07Z

Mbarret : /* Connectivité SPI */

SE4Binome2024-2

2024-10-23T09:11:12Z

Mbarret : /* Connectivité SPI */

SE4Binome2024-2

2024-10-23T08:45:00Z

Mbarret : /* Ajout d'une RAM SPI */

SE4Binome2024-2

2024-10-15T13:39:17Z

Mbarret :

=== Carte Shield ===

Nous avons soudé et réalisé les différents tests concernant la carte Shield Arduino.
Nous avons réussi à faire clignoter les LED, tester les différents connecteurs à l'aide d'un afficheur 7 segments ainsi que le lecteur de carte SD.

Pour ce faire, nous avons utiliser les différents codes exemples directement mis à disposition dans le logiciel Arduino.

=== Ordonnanceur ===

Pour l'ordonnanceur, nous avons initialisé le timer ainsi que les différentes tâches. Malheureusement, nous avons pas encore réussi à réaliser ces différentes tâches en utilisant notre ordonnanceur.

=== Carte fille afficheur ===

Nous avons commencé à réaliser le schématique de notre carte fille.

SE4Binome2024-2

2024-10-15T13:32:16Z

Mbarret :

SE3Binome2023-3

2024-06-12T20:13:16Z

Mbarret : /* Séance du 6 Juin 2024 */

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #33AFDE; vertical-align: top; width: 98%;"> Voiture VigiCar </div>=
''Notre projet est une voiture commandée par USB. Lorsqu'elle détecte un obstacle, elle s'arrête et déclenche un signal d'alerte (Warning). Quand l'obstacle est enlevé, elle continue son chemin.''

''L'utilisateur peut donner différentes instructions : avancer, reculer, s’arrêter pendant une durée définie, ou exécuter une instruction tant qu'aucun obstacle n'est détecté.''

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #97D8F0; vertical-align: top; width: 98%;"> Limitations et fonctionnalités</div>=

* Taille de la carte : 10x10 cm maximum

* Éclairage :
** 4 LEDs oranges à l'avant et à l'arrière pour les feux de warning
** 2 LEDs jaunes à l'avant pour les phares avant
** 2 LEDs blanches à l'arrière pour les feux de recul
** 2 LEDs rouges à l'arrière pour les feux stop

* Programmation : Par USB
* Gestion de l’énergie : Par batterie LiPo
* Détection d'obstacles : Capteur de proximité placé à l'avant

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #97D8F0; vertical-align: top; width: 98%;">Matériel</div>=
[[Fichier:Composants.png|droite|sans_cadre|400x400px]]

* [https://www.farnell.com/datasheets/2369105.pdf Batterie LiPo]
* [https://www.analog.com/media/cn/technical-documentation/data-sheets/2536.pdf Puce de contrôle MAX1811]
* 4 LEDs <span style="color: DarkOrange;">oranges</span>
* 2 LEDs <span style="color: Gold;">jaunes</span> (qui ressortent oranges au final)
* 2 LEDs <span style="color: Silver;">blanches</span>
* 2 LEDs <span style="color: Red;">rouges</span>
* 2 Mini moteurs continus & Pilotes des moteurs
* Capteur de proximité
* Port USB

<br><br><br><br><br><br>

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #97D8F0; vertical-align: top; width: 98%;">Déroulé du Projet</div>=

==Séance du 5 Mars 2024==
Nous avons choisi d'intégrer un capteur de proximité à notre voiture pour améliorer sa réactivité aux obstacles. Pour assurer une autonomie adéquate, nous utiliserons une alimentation par batterie. De plus, la voiture sera capable d'exécuter divers programmes prédéfinis, lui permettant de naviguer de manière autonome tout en répondant aux commandes de l'utilisateur.

== Séance du 12 Mars 2024 ==
Nous avons finalisé le choix des composants et commencé la conception du schéma électrique de notre PCB. Cependant, le problème qu'il pourrait y avoir en mettant les LEDs en série comme nous l'avons fait est qu'elle ne seront pas alimentées correctement. Nous allons donc les mettre en parallèle afin de résoudre cette complication. Dans tout les cas, cela ne posera pas de problème pour la programmation des LEDs.

[[Fichier:Schematics1.pdf|centre|800x800px|sans_cadre]]

==Séance du 19 Mars 2024==
Le schéma électrique est terminé. Nous avons corrigé le layout du PCB en respectant les contraintes de taille, le problème d'alimentation des LEDs, et nous avons rajouté les éléments manquants tels que l'alimentation et le contrôleur moteur.

[[Fichier:SE3-pad.pdf|gauche|500x500px|sans_cadre]][[Fichier:SE3-pad-Alim_+_gestion_moteur.pdf|sans_cadre|500x500px]][[Fichier:Mypcb.png|gauche|500x500px|sans_cadre]][[Fichier:Myvue3d.png|sans_cadre|450x450px]]

==Séance du 2 Avril 2024==
Création de notre archive GIT pour la gestion des versions et le suivi du projet.
*Voici notre lien git : [https://archives.plil.fr/mbarret/voiture.git VigiCar Git Archive]

== Séance du 7 Mai 2024==
[[Fichier:Soudure part 1.jpg|gauche|300x300px|bordure|sans_cadre]]

<br><br><br>
Nous avons reçu notre PCB. Nous commençons à souder les composants (ATmega16u4, Quartz, Port USB, ISP, etc.). L'ATmega16u4 a déjà un Bootloader préinstallé.
<br><br><br><br><br><br>

==Séance du 14 Mai 2024==
Nous avons continué les soudures, en particulier le contrôleur de moteur. Il reste maintenant à le tester.

==Séance du 21 Mai 2024==
Lors de la séance précédente, nous avions fini de souder le contrôleur de moteur. Nous soudons un des moteurs à l'aide de fils que nous replierons sur eux-mêmes à la fin. Pour tester le moteur, nous écrivons un programme.

Dans un premier temps, nous écrivons un programme qui consiste seulement à faire tourner le moteur :
[[Fichier:Code1.png|gauche|sans_cadre|412x412px]]
[[Fichier:Moteur_1.mp4|600x550px]]
<br><br><br><br><br>

Ensuite, nous cherchons à manipuler la vitesse de rotation du moteur. Nous écrivons un programme permettant d'augmenter progressivement la vitesse de ce dernier :
[[Fichier:Code2.png|gauche|500x500px|sans_cadre]]
[[Fichier:Moteur prog.mp4|néant|bordure|500x500px]]

==Séance du 28 Mai 2024==
Lors de cette séance, nous nous sommes séparés pour, d'une part, réparer les problèmes de soudure des LEDs, souder le capteur de proximité et d'autre part, préparer un code pour manipuler les LEDs et vérifier leur fonctionnement.

Concernant la soudure du capteur de proximité, nous avons opté pour du "bricolage". En effet, le capteur devant être monté à la verticale, il faut relier les PINs du dessus à la carte. Pour cela nous utiliserons des fils.
[[Fichier:Tst nvx capteur.mp4|gauche|sans_cadre|250x250px]]
[[Fichier:Capteur off.png|droite|sans_cadre|306x306px]]
[[Fichier:Datasheet proxi.png|centré|sans_cadre|418x418px]]
A la première tentative, le capteur ne fonctionnait pas, nous avons donc cherché la cause de ce problème (test de la camera, mesure de la tension dans les PINs, etc.). En regardant la datasheet du capteur nous voyons que le capteur ne supporte une température de 260°C que pendant 10 secondes. Nous l'avions donc bien rendu inutilisable. Nous testons un nouveau capteur avant toute soudure. Nous le mettons en place sur la carte:
[[Fichier:Capteur is on.jpg|centré|sans_cadre|548x548px]]

Nous avons donc ressoudé un autre capteur en faisant plus attention. Reste maintenant à le programmer. Voici une première version de notre code :
<syntaxhighlight lang="c" line>
#include <util/delay.h>
#include <avr/io.h>

#define PWM_DDRB DDRB
#define PWM_PORTB PORTB
#define PWM_DDRD DDRD
#define PWM_PORTD PORTD
#define CAPTEUR 5
#define AIN1 6
#define AIN2 5
#define BIN1 1
#define BIN2 2
#define PWM1 7
#define PWM2 0

#define LED_G1 PF0
#define LED_G2 PF4
#define LED_D1 PC6
#define LED_D2 PD4
#define LED_STOP_G PF6
#define LED_STOP_D PD5
#define LED_PHARES_G PF1
#define LED_PHARES_D PC7
#define LED_RECUL_G PF7
#define LED_RECUL_D PD3
#define JTD 7

void PWM_init(void){ // Initialisation de la PWM
PWM_DDRB |= (1<<PWM1); // Les ports PWM sont des sorties
PWM_DDRD |= (1<<PWM2);
TCCR0A |= (1<<COM0A1)|(1<<COM0B1); // Les ports PWM se comportent normalement
TCCR0A |= (1<<WGM01)|(1<<WGM00); // Minuteur mis en mode PWM
TCCR0B |= (1<<CS00); // Pas de pré-diviseur, démarre le compteur
}

void LED_init(void)
{
DDRD |= (1<<LED_D2) |(1<<LED_STOP_D)|(1<<LED_RECUL_D);
DDRC |= (1<<LED_D1) |(1<<LED_PHARES_D);
DDRF |= (1<<LED_G1) |(1<<LED_G2)|(1<<LED_STOP_G)|(1<<LED_PHARES_G) |(1<<LED_RECUL_G);
}

void capteur_init(void)
{
DDRF &= ~(1<<CAPTEUR);
}
int main(void){

CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)

MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);
PWM_init();
LED_init();
capteur_init();
int pwm=0;
PWM_DDRB |= (1<<AIN1)|(1<<AIN2);
PWM_PORTB |= (1<<AIN1)|(0<<AIN2);
PWM_DDRD |= (1<<BIN1)|(1<<BIN2);
PWM_PORTD |= (0<<BIN1)|(1<<BIN2);
while (1)
{
pwm++;
if ((PORTF>>CAPTEUR) &1){
pwm=0;
PORTC|=0x00;
}
if (pwm >255) pwm=0;
OCR0A=pwm;
OCR0B=pwm;
PORTC |=0b11000000;
PORTD |=0b00111000;
PORTF |=0b11010011;
_delay_ms(100);
}
return 0;
}
</syntaxhighlight>Ce code nous a permi de vérifier le fonctionnement des LEDs mais pas celui du capteur pour le moment.

==Séance du 4 Juin 2024==

Aujourd'hui nous avons avancé sur le contrôle des LEDs et du capteur de proximité que nous avons enfin fait fonctionner.
Nous avons désormais une voiture qui roule, phares allumés. Si elle rencontre un obstacle, elle s'arrête puis déclenche ses warnings. Elle possède aussi un bouton start qui lance le programme. Nous avons alors ajouter des fonctions à notre programme.
[[Fichier:Proxi feux stop.mp4|bordure|gauche|600x600px]]
Cet ajout permet d'avoir une voiture qui s'arrête dès la détection d'un obstacle et qui donc allume ses feux stop.

<syntaxhighlight lang="c" line="1">
void init_boutton(void)
{
DDRD &= ~(1<<START);
PORTD |= (1<<START);
}

void init_moteur(void)
{
PWM_DDRB |= (1<<AIN1)|(1<<AIN2);
PWM_DDRD |= (1<<BIN1)|(1<<BIN2);
}

void avancer(void)
{
PWM_PORTB |= (1<<AIN1);
PWM_PORTB &= ~(1<<AIN2);

PWM_PORTD &= ~(1<<BIN1);
PWM_PORTD |= (1<<BIN2);

//PWM_PORTB |= (1<<AIN1)|(0<<AIN2);
//PWM_PORTD |= (0<<BIN1)|(1<<BIN2);
OCR0A=180;
OCR0B=180;
}

void arret(void)
{
PWM_PORTB &= ~(1<<AIN1);
PWM_PORTB &= ~(1<<AIN2);

PWM_PORTD &= ~(1<<BIN1);
PWM_PORTD &= ~(1<<BIN2);

//PWM_PORTB |= (0<<AIN1)|(0<<AIN2);
//PWM_PORTD |= (0<<BIN1)|(0<<BIN2);
OCR0A=0;
OCR0B=0;
}

</syntaxhighlight>

Explication sur la programmation du capteur:

Dans notre programme, nous utilisons le capteur OPB733TR pour mesurer une condition spécifique en lisant des valeurs analogiques. Ces valeurs, qui représentent les informations captées par le capteur, sont converties en signaux numériques que notre microcontrôleur peut traiter. Pour réaliser cette conversion, nous utilisons un Convertisseur Analogique-Numérique (ADC) intégré.

L'ADC agit comme un traducteur qui transforme les niveaux de tension analogiques en valeurs numériques compréhensibles par le microcontrôleur. Cette opération se déroule très rapidement grâce à l'ADC de notre microcontrôleur, qui peut effectuer des conversions en un temps très court. Cela nous permet de capturer et de traiter les informations du capteur presque instantanément.

Dans notre boucle principale, le microcontrôleur lit périodiquement les valeurs analogiques converties par l'ADC. Ces valeurs sont comparées à une limite prédéfinie (`LIMITE`), configurée pour déclencher des actions spécifiques lorsque les conditions détectées par le capteur le nécessitent. Si le capteur détecte une certaine condition (définie lorsque les valeurs analogiques sont inférieures à la limite), notre programme réagit en arrêtant la voiture, activant les feux de stop, les clignotants et même en mettant la voiture en marche arrière si nécessaire.

En parallèle, un compteur est utilisé pour comptabiliser le nombre de fois où les lectures du capteur sont en dessous de la limite spécifiée. Lorsque ce compteur dépasse un certain seuil (7 dans ce cas), cela indique qu'un obstacle est présent. Cette gestion du compteur permet à notre système de prendre des décisions en fonction des conditions détectées par le capteur, garantissant ainsi la vigilance de notre VigiCar.

Ce processus en temps réel, facilité par l'ADC rapide et le compteur intégré, nous permet de surveiller efficacement les conditions environnementales et de répondre à la présence d'un obstacle en faisant reculer la voiture, qui par la même occasion allume ses feux de recul.

==Séance du 6 Juin 2024==
Lors de cette séance nous avons terminé notre VigiCar en installant l'alimentation par batterie.

Pour ce faire, nous avons voulu isoler la partie du circuit concernant la batterie du reste. Pour cela nous avons donc décidé d’intégrer un deuxième port USB-mini consacré à la charge d’une batterie de 3.7V afin de garantir une alimentation non filaire.

Afin de vérifier le bon rechargement de la batterie, nous avons installer une LED orange D4 qui s’allume en cas de recharge.

Pour utiliser l’alimentation sur batterie, il nous suffit de placer un cavalier sur le connecteur J9. Et pour la recharger, on doit en utiliser deux sur les connecteurs J5 et J6. Il faut cependant faire très attention au placement des cavaliers selon l’utilisation. Si on désire modifier le code (par USB donc), nous devons impérativement vérifier que le cavalier en J9 est bien enlevé. Si ce n’est pas le cas, nous avons donc donc deux alimentations simultanées (USB et batterie) ce qui peut provoquer des dysfonctionnements.

Nous avons également installer une diode (D5) pour envoyer le courant de la batterie dans le capteur IR en l’absence de source USB.

Enfin, nous avons décider d’installer le connecteur de la batterie (J7) sous la carte pour des questions pratiques.

SE3Binome2023-3

2024-06-12T20:04:10Z

Mbarret : /* Séance du 6 Juin 2024 */

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #33AFDE; vertical-align: top; width: 98%;"> Voiture VigiCar </div>=
''Notre projet est une voiture commandée par USB. Lorsqu'elle détecte un obstacle, elle s'arrête et déclenche un signal d'alerte (Warning). Quand l'obstacle est enlevé, elle continue son chemin.''

''L'utilisateur peut donner différentes instructions : avancer, reculer, s’arrêter pendant une durée définie, ou exécuter une instruction tant qu'aucun obstacle n'est détecté.''

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #97D8F0; vertical-align: top; width: 98%;"> Limitations et fonctionnalités</div>=

* Taille de la carte : 10x10 cm maximum

* Éclairage :
** 4 LEDs oranges à l'avant et à l'arrière pour les feux de warning
** 2 LEDs jaunes à l'avant pour les phares avant
** 2 LEDs blanches à l'arrière pour les feux de recul
** 2 LEDs rouges à l'arrière pour les feux stop

* Programmation : Par USB
* Gestion de l’énergie : Par batterie LiPo
* Détection d'obstacles : Capteur de proximité placé à l'avant

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #97D8F0; vertical-align: top; width: 98%;">Matériel</div>=
[[Fichier:Composants.png|droite|sans_cadre|400x400px]]

* [https://www.farnell.com/datasheets/2369105.pdf Batterie LiPo]
* [https://www.analog.com/media/cn/technical-documentation/data-sheets/2536.pdf Puce de contrôle MAX1811]
* 4 LEDs <span style="color: DarkOrange;">oranges</span>
* 2 LEDs <span style="color: Gold;">jaunes</span> (qui ressortent oranges au final)
* 2 LEDs <span style="color: Silver;">blanches</span>
* 2 LEDs <span style="color: Red;">rouges</span>
* 2 Mini moteurs continus & Pilotes des moteurs
* Capteur de proximité
* Port USB

<br><br><br><br><br><br>

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #97D8F0; vertical-align: top; width: 98%;">Déroulé du Projet</div>=

==Séance du 5 Mars 2024==
Nous avons choisi d'intégrer un capteur de proximité à notre voiture pour améliorer sa réactivité aux obstacles. Pour assurer une autonomie adéquate, nous utiliserons une alimentation par batterie. De plus, la voiture sera capable d'exécuter divers programmes prédéfinis, lui permettant de naviguer de manière autonome tout en répondant aux commandes de l'utilisateur.

== Séance du 12 Mars 2024 ==
Nous avons finalisé le choix des composants et commencé la conception du schéma électrique de notre PCB. Cependant, le problème qu'il pourrait y avoir en mettant les LEDs en série comme nous l'avons fait est qu'elle ne seront pas alimentées correctement. Nous allons donc les mettre en parallèle afin de résoudre cette complication. Dans tout les cas, cela ne posera pas de problème pour la programmation des LEDs.

[[Fichier:Schematics1.pdf|centre|800x800px|sans_cadre]]

==Séance du 19 Mars 2024==
Le schéma électrique est terminé. Nous avons corrigé le layout du PCB en respectant les contraintes de taille, le problème d'alimentation des LEDs, et nous avons rajouté les éléments manquants tels que l'alimentation et le contrôleur moteur.

[[Fichier:SE3-pad.pdf|gauche|500x500px|sans_cadre]][[Fichier:SE3-pad-Alim_+_gestion_moteur.pdf|sans_cadre|500x500px]][[Fichier:Mypcb.png|gauche|500x500px|sans_cadre]][[Fichier:Myvue3d.png|sans_cadre|450x450px]]

==Séance du 2 Avril 2024==
Création de notre archive GIT pour la gestion des versions et le suivi du projet.
*Voici notre lien git : [https://archives.plil.fr/mbarret/voiture.git VigiCar Git Archive]

== Séance du 7 Mai 2024==
[[Fichier:Soudure part 1.jpg|gauche|300x300px|bordure|sans_cadre]]

<br><br><br>
Nous avons reçu notre PCB. Nous commençons à souder les composants (ATmega16u4, Quartz, Port USB, ISP, etc.). L'ATmega16u4 a déjà un Bootloader préinstallé.
<br><br><br><br><br><br>

==Séance du 14 Mai 2024==
Nous avons continué les soudures, en particulier le contrôleur de moteur. Il reste maintenant à le tester.

==Séance du 21 Mai 2024==
Lors de la séance précédente, nous avions fini de souder le contrôleur de moteur. Nous soudons un des moteurs à l'aide de fils que nous replierons sur eux-mêmes à la fin. Pour tester le moteur, nous écrivons un programme.

Dans un premier temps, nous écrivons un programme qui consiste seulement à faire tourner le moteur :
[[Fichier:Code1.png|gauche|sans_cadre|412x412px]]
[[Fichier:Moteur_1.mp4|600x550px]]
<br><br><br><br><br>

Ensuite, nous cherchons à manipuler la vitesse de rotation du moteur. Nous écrivons un programme permettant d'augmenter progressivement la vitesse de ce dernier :
[[Fichier:Code2.png|gauche|500x500px|sans_cadre]]
[[Fichier:Moteur prog.mp4|néant|bordure|500x500px]]

==Séance du 28 Mai 2024==
Lors de cette séance, nous nous sommes séparés pour, d'une part, réparer les problèmes de soudure des LEDs, souder le capteur de proximité et d'autre part, préparer un code pour manipuler les LEDs et vérifier leur fonctionnement.

Concernant la soudure du capteur de proximité, nous avons opté pour du "bricolage". En effet, le capteur devant être monté à la verticale, il faut relier les PINs du dessus à la carte. Pour cela nous utiliserons des fils.
[[Fichier:Tst nvx capteur.mp4|gauche|sans_cadre|250x250px]]
[[Fichier:Capteur off.png|droite|sans_cadre|306x306px]]
[[Fichier:Datasheet proxi.png|centré|sans_cadre|418x418px]]
A la première tentative, le capteur ne fonctionnait pas, nous avons donc cherché la cause de ce problème (test de la camera, mesure de la tension dans les PINs, etc.). En regardant la datasheet du capteur nous voyons que le capteur ne supporte une température de 260°C que pendant 10 secondes. Nous l'avions donc bien rendu inutilisable. Nous testons un nouveau capteur avant toute soudure. Nous le mettons en place sur la carte:
[[Fichier:Capteur is on.jpg|centré|sans_cadre|548x548px]]

Nous avons donc ressoudé un autre capteur en faisant plus attention. Reste maintenant à le programmer. Voici une première version de notre code :
<syntaxhighlight lang="c" line>
#include <util/delay.h>
#include <avr/io.h>

#define PWM_DDRB DDRB
#define PWM_PORTB PORTB
#define PWM_DDRD DDRD
#define PWM_PORTD PORTD
#define CAPTEUR 5
#define AIN1 6
#define AIN2 5
#define BIN1 1
#define BIN2 2
#define PWM1 7
#define PWM2 0

#define LED_G1 PF0
#define LED_G2 PF4
#define LED_D1 PC6
#define LED_D2 PD4
#define LED_STOP_G PF6
#define LED_STOP_D PD5
#define LED_PHARES_G PF1
#define LED_PHARES_D PC7
#define LED_RECUL_G PF7
#define LED_RECUL_D PD3
#define JTD 7

void PWM_init(void){ // Initialisation de la PWM
PWM_DDRB |= (1<<PWM1); // Les ports PWM sont des sorties
PWM_DDRD |= (1<<PWM2);
TCCR0A |= (1<<COM0A1)|(1<<COM0B1); // Les ports PWM se comportent normalement
TCCR0A |= (1<<WGM01)|(1<<WGM00); // Minuteur mis en mode PWM
TCCR0B |= (1<<CS00); // Pas de pré-diviseur, démarre le compteur
}

void LED_init(void)
{
DDRD |= (1<<LED_D2) |(1<<LED_STOP_D)|(1<<LED_RECUL_D);
DDRC |= (1<<LED_D1) |(1<<LED_PHARES_D);
DDRF |= (1<<LED_G1) |(1<<LED_G2)|(1<<LED_STOP_G)|(1<<LED_PHARES_G) |(1<<LED_RECUL_G);
}

void capteur_init(void)
{
DDRF &= ~(1<<CAPTEUR);
}
int main(void){

CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)

MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);
PWM_init();
LED_init();
capteur_init();
int pwm=0;
PWM_DDRB |= (1<<AIN1)|(1<<AIN2);
PWM_PORTB |= (1<<AIN1)|(0<<AIN2);
PWM_DDRD |= (1<<BIN1)|(1<<BIN2);
PWM_PORTD |= (0<<BIN1)|(1<<BIN2);
while (1)
{
pwm++;
if ((PORTF>>CAPTEUR) &1){
pwm=0;
PORTC|=0x00;
}
if (pwm >255) pwm=0;
OCR0A=pwm;
OCR0B=pwm;
PORTC |=0b11000000;
PORTD |=0b00111000;
PORTF |=0b11010011;
_delay_ms(100);
}
return 0;
}
</syntaxhighlight>Ce code nous a permi de vérifier le fonctionnement des LEDs mais pas celui du capteur pour le moment.

==Séance du 4 Juin 2024==

Aujourd'hui nous avons avancé sur le contrôle des LEDs et du capteur de proximité que nous avons enfin fait fonctionner.
Nous avons désormais une voiture qui roule, phares allumés. Si elle rencontre un obstacle, elle s'arrête puis déclenche ses warnings. Elle possède aussi un bouton start qui lance le programme. Nous avons alors ajouter des fonctions à notre programme.
[[Fichier:Proxi feux stop.mp4|bordure|gauche|600x600px]]
Cet ajout permet d'avoir une voiture qui s'arrête dès la détection d'un obstacle et qui donc allume ses feux stop.

<syntaxhighlight lang="c" line="1">
void init_boutton(void)
{
DDRD &= ~(1<<START);
PORTD |= (1<<START);
}

void init_moteur(void)
{
PWM_DDRB |= (1<<AIN1)|(1<<AIN2);
PWM_DDRD |= (1<<BIN1)|(1<<BIN2);
}

void avancer(void)
{
PWM_PORTB |= (1<<AIN1);
PWM_PORTB &= ~(1<<AIN2);

PWM_PORTD &= ~(1<<BIN1);
PWM_PORTD |= (1<<BIN2);

//PWM_PORTB |= (1<<AIN1)|(0<<AIN2);
//PWM_PORTD |= (0<<BIN1)|(1<<BIN2);
OCR0A=180;
OCR0B=180;
}

void arret(void)
{
PWM_PORTB &= ~(1<<AIN1);
PWM_PORTB &= ~(1<<AIN2);

PWM_PORTD &= ~(1<<BIN1);
PWM_PORTD &= ~(1<<BIN2);

//PWM_PORTB |= (0<<AIN1)|(0<<AIN2);
//PWM_PORTD |= (0<<BIN1)|(0<<BIN2);
OCR0A=0;
OCR0B=0;
}

</syntaxhighlight>

Explication sur la programmation du capteur:

Dans notre programme, nous utilisons le capteur OPB733TR pour mesurer une condition spécifique en lisant des valeurs analogiques. Ces valeurs, qui représentent les informations captées par le capteur, sont converties en signaux numériques que notre microcontrôleur peut traiter. Pour réaliser cette conversion, nous utilisons un Convertisseur Analogique-Numérique (ADC) intégré.

L'ADC agit comme un traducteur qui transforme les niveaux de tension analogiques en valeurs numériques compréhensibles par le microcontrôleur. Cette opération se déroule très rapidement grâce à l'ADC de notre microcontrôleur, qui peut effectuer des conversions en un temps très court. Cela nous permet de capturer et de traiter les informations du capteur presque instantanément.

Dans notre boucle principale, le microcontrôleur lit périodiquement les valeurs analogiques converties par l'ADC. Ces valeurs sont comparées à une limite prédéfinie (`LIMITE`), configurée pour déclencher des actions spécifiques lorsque les conditions détectées par le capteur le nécessitent. Si le capteur détecte une certaine condition (définie lorsque les valeurs analogiques sont inférieures à la limite), notre programme réagit en arrêtant la voiture, activant les feux de stop, les clignotants et même en mettant la voiture en marche arrière si nécessaire.

En parallèle, un compteur est utilisé pour comptabiliser le nombre de fois où les lectures du capteur sont en dessous de la limite spécifiée. Lorsque ce compteur dépasse un certain seuil (7 dans ce cas), cela indique qu'un obstacle est présent. Cette gestion du compteur permet à notre système de prendre des décisions en fonction des conditions détectées par le capteur, garantissant ainsi la vigilance de notre VigiCar.

Ce processus en temps réel, facilité par l'ADC rapide et le compteur intégré, nous permet de surveiller efficacement les conditions environnementales et de répondre à la présence d'un obstacle en faisant reculer la voiture, qui par la même occasion allume ses feux de recul.

==Séance du 6 Juin 2024==
Lors de cette séance nous avons terminer notre VigiCar en installant l'alimentation par batterie.

Pour ce faire, nous avons voulu isoler la partie du circuit concernant la batterie du reste. Pour cela nous avons donc décidé d’intégrer un deuxième port USB-mini consacré à la charge d’une batterie de 3.7V afin de garantir une alimentation non filière.

Afin de vérifier le bon rechargement de la batterie, nous avons installer une LED orange D4 qui s’allume en cas de recharge.

Pour utiliser l’alimentation sur batterie, il nous suffit de placer un cavalier sur le connecteur J9. Et pour la recharger, on doit en utiliser deux sur les connecteurs J5 et J6. Il faut cependant faire très attention au placement des cavaliers selon l’utilisation. Si on désire modifier le code (par USB donc), nous devons impérativement vérifier que le cavalier en J9 est bien enlevé. Si ce n’est pas le cas, nous avons donc donc deux alimentations simultanées (USB et batterie) ce qui peut provoquer des dysfonctionnements.

Nous avons également installer une diode (D5) pour envoyer le courant de la batterie dans le capteur IR en l’absence de source USB.

Enfin, nous avons décider d’installer le connecteur de la batterie (J7) sous la carte pour des questions pratiques.

Fichier:2023-SE3-VOITURE-B3-kicad.zip

2024-03-26T13:12:43Z

Mbarret :

Fichier:2023-SE3-PSE-B1-kicad.zip

2024-03-18T12:52:22Z

Mbarret : Mbarret a annulé Fichier:2023-SE3-PSE-B1-kicad.zip vers une ancienne version

SE3Binome2023-3

2024-03-18T12:51:19Z

Mbarret : /* Matériel */

Fichier:2023-SE3-PSE-B1-kicad.zip

2024-03-12T14:49:28Z

Mbarret : Mbarret a téléversé une nouvelle version de Fichier:2023-SE3-PSE-B1-kicad.zip

SE3Binome2023-3

2024-03-12T14:49:00Z

Mbarret :

SE3 PSE Binome2023-1

2024-03-11T17:01:23Z

Mbarret :

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #33AFDE; vertical-align: top; width: 98%;"> Joystick Space Invader </div>=
''Notre projet est de créer une manette de jeu compatible avec le jeu Space Invader.''

<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #97D8F0; vertical-align: top; width: 98%;"> Limitations et fonctionnalités</div>

* Taille de la carte : 10x10 cm maximum
* Utilisation de LEDs rouge selon ce qu'il se passe dans le jeu (victoire, défaite, tir, etc.)
* 4 boutons : deux de déplacement (gauche et droite), un de tire et un dernier pour toute actions supplémentaire que nous déterminerons par la suite

Voici l'archive de notre fichier à la fin de la 2e séance :

[[File:2023-SE3-PSE-B1-kicad.zip]]

SE3 PSE Binome2023-1

2024-03-11T17:01:04Z

Mbarret :

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #33AFDE; vertical-align: top; width: 98%;"> Joystick Space Invader </div>=
''Notre projet est de créer une manette de jeu compatible avec le jeu Space Invader.''

<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #97D8F0; vertical-align: top; width: 98%;"> Limitations et fonctionnalités</div>

* Taille de la carte : 10x10 cm maximum
* Utilisation de LEDs rouge selon ce qu'il se passe dans le jeu (victoire, défaite, tir, etc.)
* 4 boutons : deux de déplacement (gauche et droite), un de tire et un dernier pour toute actions supplémentaire que nous déterminerons par la suite

Voici l'archive de notre fichier à la fin de la 2e séance :

= [[File:2023-SE3-PSE-B1-kicad.zip]]=

SE3 PSE Binome2023-1

2024-03-11T16:54:20Z

Mbarret :

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #33AFDE; vertical-align: top; width: 98%;"> Joystick Space Invader </div>=
Notre projet est de creer une manette de jeu compatible avec le jeu Space Invader. Cette manette

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #97D8F0; vertical-align: top; width: 98%;"> Limitations et fonctionnalités</div>=

* Taille de la carte : 10x10 cm maximum
* Utilisation de LEDs jaunes à l'avant et à l'arrière (4 LEDs)
* Utilisation de LEDs blanches à l'arrière pour les feux de recul (2 LEDs)
* Utilisation de LEDs rouges à l'arrière pour les feux stop (2 LEDs)
* Programmation par USB
* Gestion de l’énergie par batterie LiPo
* Détection d'obstacles à l'aide d'un capteur de proximité placé à l'avant

= [[File:2023-SE3-PSE-B1-kicad.zip]]=

SE3 PSE Binome2023-1

2024-03-11T16:54:04Z

Mbarret :

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #33AFDE; vertical-align: top; width: 98%;"> Joystick Space Invader </div>=
Notre projet est de creer une manette de jeu compatible avec le jeu Space Invader. Cette manette

= [[File:2023-SE3-PSE-B1-kicad.zip]]=

Fichier:2023-SE3-PSE-B1-kicad.zip

2024-03-11T16:50:50Z

Mbarret :

SE3 PSE Binome2023-1

2024-03-11T16:49:37Z

Mbarret :

SE3 PSE Binome2023-1

2024-03-11T16:46:35Z

Mbarret :

Fichier:Mannete ElBachiri Barret.zip

2024-03-11T16:45:25Z

Mbarret :

Archive projet Manette

SE3 PSE Binome2023-1

2024-03-11T16:40:57Z

Mbarret :

PSE SE3 2023/2024

2024-03-11T13:00:08Z

Mbarret : /* Réalisations des binômes */

= Objectif =

Pour l'année académique 2023/2024 il est toujours demandé de réaliser un système embarqué.

== Microcontrôleur ==

Pour éviter les problème avec les conversions analogique vers numérique vous utiliserez un ATmega16u4 ou un ATmega32u4. La programmation peut ainsi se faire très simplement par DFU/USB.

== Energie ==

Vos cartes doivent pouvoir être alimentées de façon hybride :
* par un port USB, méthode utilisée pour la programmation et les tests ;
* par une batterie Lithium, en mode autonome.

<gallery>
File:puce_max1811.jpg|Puce de contrôle de charge
File:batteries_LiPo.jpg|Batteries 100mAh et 300mAh, connecteur molex mâle
File:batterie_LiPo_FQ777.jpg|Batterie 100mAh 15x20x5mm
</gallery>

Il est conseillé de séparer au maximum les deux alimentations, voir la seconde version de la carte de test de chargement de batterie.

== Fonctionnalités ==

Vos cartes doivent toutes comporter des LED commandées par le microcontrôleur. Les autres fonctionnalités peuvent être choisies dans la liste suivante (non exhaustive). Les fonctionnalités doivent être validées par un intervenant.

* Vous pouvez partir sur le projet voiture de l'an passé en simplifiant l'aspect mécanique : deux moteurs pour les deux roues motrices, des roues directement enfilées sur les méplats des moteurs continus ou sur des engrenages montés en force sur l'axe des moteurs pas à pas. Le comportement de la voiture est téléchargé par une liaison USB/série et permet de spécifier une suite de commandes sur les deux moteurs et les lampes de la voiture.

<gallery>
file:2023-chassis-simple-dessus.png|Chassis vu de dessus
file:2023-chassis-simple-cote.png|Chassis vu de coté
File:micro-moteur-pas-a-pas-simple.jpg|Micro-moteur pas à pas propulsion
File:mini-motoreducteur.jpg|Mini-moteur continu avec réducteur
File:pilote-moteur-TB6612FNG.png|Pilote pour le mini-moteur continu (TB6612FNG)
File:detecteur-proximite-OPB733.png|Puce de détection d'obstacle (OPB733)
</gallery>

* Vous pouvez partir sur un objet autonome communicant de type capteur, par exemple un capteur de température ou un micro espion. Le coté autonome est donné par la batterie, le coté communicant est à travailler à partir de la puce NRF24L01. Cette puce est une puce radio générale. Vous pouvez la tester à partir de la carte de test présenté dans la suite de ce sujet. Pour la réception des données de votre objet plusieurs alternatives sont possibles : mettre rapidement au point un récepteur à base de module basé sur un NRF24L01 et un Arduino ou vous entendre avec un autre binôme dont l'objet est soit :
** une centrale d'affichage des données des objets communicants sur des afficheurs 7 segments, un écran LCD alphanumérique ou un écran LCD graphique ;
** un périphérique USB de type carte son permettant de récupérer le flux du micro espion, dans ce dernier cas attention à bien sélectionner un microcontrôleur adapté.

<gallery>
File:module_nrf24L01.jpg|Module de communication 2,4Ghz
File:puce_nrf24L01.jpg|Puce de communication (soudure complexe)
</gallery>

* Vous pouvez tenter un objet autonome communicant de type actionneur, par exemple un haut-parleur diffusant les sons envoyés par un module radio. Là encore les sons peuvent être envoyés par un prototype à base d'Arduino ou par la carte d'un autre binôme réalisant un périphérique USB de type audio. Dans ce dernier cas attention à bien sélectionner un microcontrôleur adapté.

* Enfin si vous ne vous sentez pas trop sûr de vous il reste toujours la possibilité de l'objet complétement autonome comportant des capteurs et des actionneurs et réagissant en fonction de son environnement. Un exemple est un détecteur de mouvement à base de capteur PIR (Passive Infra-Red) donnant lieu à une séquence animée à base de LED ou à une séquence sonore.

= Cartes de test =

Cette année, plutôt que vous proposer des schémas complets de voitures, il a été décidé de vous proposer des cartes démontrant, chacune, une fonctionnalité éventuellement intégrable dans votre voiture.

== Test du chargeur ==

[[Fichier:2023-ChargeurLiPo-Schema.pdf|thumb|left|400px]]
[[Fichier:2023-ChargeurLiPo-PCB.jpg|thumb|right|400px]]

Les schéma et routage de la carte. Avec une erreur de base, le microcontrôleur est un ATmega32u2, c'est à dire un AVR sans ADC donc récupérer la tension de la batterie sera en tout ou rien. Un autre problème de conception est la trop faible charge de la LED qui peine à décharger la batterie.

Projet KiCAD : [[Fichier:2023-ChargeurLiPo-KiCAD.zip]]

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

[[Fichier:2023-ChargeurLiPo-Complete1.jpg|thumb|left|150px]]
[[Fichier:2023-ChargeurLiPo-Complete2.jpg|thumb|right|400px]]

Vous trouvez ici deux photos de la carte soudée.

Vous avez aussi un programme LUFA basé sur la démonstration <code>VirtualSerial</code> pour contrôler la carte, en particulier lancer la charge de la batterie et voir si sa tension se traduit par un état haut ou bas. Tapez n'importe quoi avec un retour chariot dans un terminal série pour voir la liste des commandes possibles.

Programme : [[Média:2023-ChargeurLiPo-VirtualSerial.zip]].

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

Les tests de la première version de la carte n'ont pas été super-concluant. Il faut dire qu'il y avait quelques erreurs de conception :
* le plus grave : le condensateur en parallèle de la batterie était noté 100nF au lieu des 2,2µF indiqué dans les documents technique, de plus le condensateur de 4,7µF demandé sur l'alimentation de la puce n'était pas implanté ;
* l'idée de commander la LED d'éclairage via le 5V du connecteur USB n'était pas très malin, cela interdisait une utilisation de la LED la carte non connectée sur une alimentation USB ;
* comme indiqué plus haut, il vaut mieux utiliser un ATmega16u4 qu'un ATmega16u2 ;
* plus généralement déconnecter au maximum la partie "utilisation" de la batterie de la partie "recharge" de la batterie réduit les problèmes potentiels.

[[Fichier:2023-ChargeurLiPo-Schema-V2.pdf|thumb|left|400px]]
[[Fichier:2023-ChargeurLiPo-PCB-V2.png|thumb|right|400px]]

Nouvelle version de la carte avec deux connecteurs USB : un USB A pour sa programmation et son fonctionnement USB, un USB mini pour la recharge de la batterie. Un interrupteur permet d'utiliser la LED, un autre de démarrer le microcontrôleur.

Projet KiCAD : [[Fichier:2023-ChargeurLiPo-KiCAD-V2.zip]]

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

== Test du transmetteur radio ==

[[Fichier:2023-BlueTooth-Schema.pdf|thumb|left|400px]]
[[Fichier:2023-BlueTooth-PCB.jpg|thumb|right|400px]]

Contrairement au titre du projet KiCAD cette carte est un transmetteur/récepteur radio générique.

Projet KiCAD : [[Fichier:2023-BlueTooth-KiCAD.zip]]

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

= Réalisations des binômes =

{| class="wikitable"
! Numéro !! Elèves !! Page
|-
| Binôme 1
| Victorien DETREZ & Benjamin CART
| [[SE3Binome2023-1|Binôme 1 2023/2024]]
|-
| Binôme 2
| Bilal MOUSSA & Yassine YAHIANI
| [[SE3Binome2023-2|Binôme 2 2023/2024]]
|-
| Binôme 3
| Kaoutar EL BACHIRI & Maxime BARRET
| [[SE3Binome2023-3|Binôme 3 2023/2024]]
|-
| Binôme 4
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-4|Binôme 4 2023/2024]]
|-
| Binôme 5
| Antoine LECOMTE & Rémi BOURSAULT
| [[SE3Binome2023-5|Binôme 5 2023/2024]]
|-
| Binôme 6
| Lililan GREVIN & Pierre CASIMIRI
| [[SE3Binome2023-6|Binôme 6 2023/2024]]
|-
| Binôme 7
| Augustin DJAJDJA-AVONYO & Kévan TOURON
| [[SE3Binome2023-7|Binôme 7 2023/2024]]
|-
| Binôme 8
| Justin WACQUET & Ibrahim TEPELI
| [[SE3Binome2023-8|Binôme 8 2023/2024]]
|-
| Monôme 9
| Mahmoud RABIA
| [[SE3Binome2023-9|Monôme 9 2023/2024]]
|-
| Binôme 10
| Camille CARIAT & Louis BONNINGRE
| [[SE3Binome2023-10|Binôme 10 2023/2024]]
|-
|}

= Réalisations en programmation des systèmes embarqués =

== Binômes ==

{| class="wikitable"
! Numéro !! Elèves !! Page
|-
| Binôme 1
| Kaoutar EL BACHIRI & Maxime BARRET
| [[SE3_PSE_Binome2023-1|Binôme 1 2023/2024]]
|-
| Binôme 2
| Sarah Deparis & Agathe Houdusse
| [[SE3_PSE_Binome2023-2|Binôme 2 2023/2024]]
|-
| Binôme 3
| Victorien DETREZ & Benjamin CART
| [[SE3_PSE_Binome2023-3|Binôme 3 2023/2024]]
|-
| Binôme 4
| Bilal MOUSSA & Yassine YAHIANI
| [[SE3_PSE_Binome2023-4|Binôme 4 2023/2024]]
|-
| Binôme 5
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-5|Binôme 5 2023/2024]]
|-
| Binôme 6
| Lilian GREVIN & Pierre CASIMIRI
| [[SE3_PSE_Binome2023-6|Binôme 6 2023/2024]]
|-
| Binôme 7
| Kévan TOURON & Augustin DJADJA-AVONYO
| [[SE3_PSE_Binome2023-7|Binôme 7 2023/2024]]
|-
| Binôme 8
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-8|Binôme 8 2023/2024]]
|-
| Binôme 9
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-9|Binôme 9 2023/2024]]
|-
| Binôme 10
| Camille CARIAT & RABIA Mahmoud
| [[SE3_PSE_Binome2023-10|Binôme 10 2023/2024]]
|-
|}

== Manette USB ==

Projet KiCAD de base pour les manettes : [[Fichier:2023-ManetteSE3-KiCAD.zip]]

Utilisez vos pages Wiki pour :
* attacher votre projet KiCAD ;
* déposer une photo de la carte soudée.

== Programmateur AVR ==

Utilisez vos pages Wiki pour :
* attacher vos programmes C (LUFA et libusb) ;
* déposer une photo de la carte soudée ;
* déposer une très courte vidéo de la carte avec les LED clignotantes ;
* déposer une copie écran montrant l'affichage de la communication entre votre programme libusb, votre carte et le microcontrôleur AVR.

SE3Binome2023-3

2024-03-05T14:03:40Z

Mbarret :

Projet: Voiture commandée par USB

Limitations et fonctionnalités:<br>
-taille de la carte 10x10cm maximum <br>
-Utilisation de LEDs (jaunes) comme clignotants de la voiture ainsi que pour les feux de recul (blanc) et feux de stop à l’arrêt (Rouge). <br>
-Présence d'un port USB pour la programmation<br>
-Gestion de l'énergie par batterie LiPo

-détection d'obstacle<br>

Composants prévus à la conception: Batterie LiPo + Puce de controle MAX1811, 4 Leds jaunes, 2 leds blanches et 2 leds rouges, utilisation des mini-moteurs continus et du pilote des moteurs, microcontrôleur ATMega16u4, capteur de proximité à l'avant .

SE3Binome2023-3

2024-03-05T13:58:11Z

Mbarret :

SE3Binome2023-3

2024-03-05T13:43:42Z

Mbarret : Page créée avec « Projet: Voiture commandée par USB Limitations et fonctionnalités:<br> -taille de la carte 10x10cm maximum <br> -Utilisation de LEDs (jaunes) comme clignotants de la voiture ainsi que pour les feux de recul (blanc) et feux de stop à l’arrêt (Rouge). Clignotants si partie mécanique réalisée.<br> -Présence d'un port USB pour la programmation<br> -Gestion de l'énergie par batterie LiPo<br> Composants prévus à la conception: Batterie LiPo + Puce de con... »

Projet: Voiture commandée par USB

Limitations et fonctionnalités:<br>
-taille de la carte 10x10cm maximum <br>
-Utilisation de LEDs (jaunes) comme clignotants de la voiture ainsi que pour les feux de recul (blanc) et feux de stop à l’arrêt (Rouge). Clignotants si partie mécanique réalisée.<br>
-Présence d'un port USB pour la programmation<br>
-Gestion de l'énergie par batterie LiPo<br>

Composants prévus à la conception: Batterie LiPo + Puce de controle MAX1811, 4 Leds jaunes, 2 leds blanches et 2 leds rouges, utilisation des mini-moteurs continus et du pilote des moteurs, microcontrôleur ATMega16u4.

SE3 PSE Binome2023-1

2024-03-05T13:43:29Z

Mbarret : Page blanchie

PSE SE3 2023/2024

2024-03-05T13:42:42Z

Mbarret : /* Réalisations des binômes */

= Objectif =

Pour l'année académique 2023/2024 il est toujours demandé de réaliser un système embarqué.

== Microcontrôleur ==

Pour éviter les problème avec les conversions analogique vers numérique vous utiliserez un ATmega16u4 ou un ATmega32u4. La programmation peut ainsi se faire très simplement par DFU/USB.

== Energie ==

Vos cartes doivent pouvoir être alimentées de façon hybride :
* par un port USB, méthode utilisée pour la programmation et les tests ;
* par une batterie Lithium, en mode autonome.

<gallery>
File:puce_max1811.jpg|Puce de contrôle de charge
File:batteries_LiPo.jpg|Batteries 100mAh et 300mAh, connecteur molex mâle
File:batterie_LiPo_FQ777.jpg|Batterie 100mAh 15x20x5mm
</gallery>

Il est conseillé de séparer au maximum les deux alimentations, voir la seconde version de la carte de test de chargement de batterie.

== Fonctionnalités ==

Vos cartes doivent toutes comporter des LED commandées par le microcontrôleur. Les autres fonctionnalités peuvent être choisies dans la liste suivante (non exhaustive). Les fonctionnalités doivent être validées par un intervenant.

* Vous pouvez partir sur le projet voiture de l'an passé en simplifiant l'aspect mécanique : deux moteurs pour les deux roues motrices, des roues directement enfilées sur les méplats des moteurs continus ou sur des engrenages montés en force sur l'axe des moteurs pas à pas. Le comportement de la voiture est téléchargé par une liaison USB/série et permet de spécifier une suite de commandes sur les deux moteurs et les lampes de la voiture.

<gallery>
file:2023-chassis-simple-dessus.png|Chassis vu de dessus
file:2023-chassis-simple-cote.png|Chassis vu de coté
File:micro-moteur-pas-a-pas-simple.jpg|Micro-moteur pas à pas propulsion
File:mini-motoreducteur.jpg|Mini-moteur continu avec réducteur
File:pilote-moteur-TB6612FNG.png|Pilote pour le mini-moteur continu (TB6612FNG)
</gallery>

* Vous pouvez partir sur un objet autonome communicant de type capteur, par exemple un capteur de température ou un micro espion. Le coté autonome est donné par la batterie, le coté communicant est à travailler à partir de la puce NRF24L01. Cette puce est une puce radio générale. Vous pouvez la tester à partir de la carte de test présenté dans la suite de ce sujet. Pour la réception des données de votre objet plusieurs alternatives sont possibles : mettre rapidement au point un récepteur à base de module basé sur un NRF24L01 et un Arduino ou vous entendre avec un autre binôme dont l'objet est soit :
** une centrale d'affichage des données des objets communicants sur des afficheurs 7 segments, un écran LCD alphanumérique ou un écran LCD graphique ;
** un périphérique USB de type carte son permettant de récupérer le flux du micro espion, dans ce dernier cas attention à bien sélectionner un microcontrôleur adapté.

<gallery>
File:module_nrf24L01.jpg|Module de communication 2,4Ghz
File:puce_nrf24L01.jpg|Puce de communication (soudure complexe)
</gallery>

* Vous pouvez tenter un objet autonome communicant de type actionneur, par exemple un haut-parleur diffusant les sons envoyés par un module radio. Là encore les sons peuvent être envoyés par un prototype à base d'Arduino ou par la carte d'un autre binôme réalisant un périphérique USB de type audio. Dans ce dernier cas attention à bien sélectionner un microcontrôleur adapté.

* Enfin si vous ne vous sentez pas trop sûr de vous il reste toujours la possibilité de l'objet complétement autonome comportant des capteurs et des actionneurs et réagissant en fonction de son environnement. Un exemple est un détecteur de mouvement à base de capteur PIR (Passive Infra-Red) donnant lieu à une séquence animée à base de LED ou à une séquence sonore.

= Cartes de test =

Cette année, plutôt que vous proposer des schémas complets de voitures, il a été décidé de vous proposer des cartes démontrant, chacune, une fonctionnalité éventuellement intégrable dans votre voiture.

== Test du chargeur ==

[[Fichier:2023-ChargeurLiPo-Schema.pdf|thumb|left|400px]]
[[Fichier:2023-ChargeurLiPo-PCB.jpg|thumb|right|400px]]

Les schéma et routage de la carte. Avec une erreur de base, le microcontrôleur est un ATmega32u2, c'est à dire un AVR sans ADC donc récupérer la tension de la batterie sera en tout ou rien. Un autre problème de conception est la trop faible charge de la LED qui peine à décharger la batterie.

Projet KiCAD : [[Fichier:2023-ChargeurLiPo-KiCAD.zip]]

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

[[Fichier:2023-ChargeurLiPo-Complete1.jpg|thumb|left|150px]]
[[Fichier:2023-ChargeurLiPo-Complete2.jpg|thumb|right|400px]]

Vous trouvez ici deux photos de la carte soudée.

Vous avez aussi un programme LUFA basé sur la démonstration <code>VirtualSerial</code> pour contrôler la carte, en particulier lancer la charge de la batterie et voir si sa tension se traduit par un état haut ou bas. Tapez n'importe quoi avec un retour chariot dans un terminal série pour voir la liste des commandes possibles.

Programme : [[Média:2023-ChargeurLiPo-VirtualSerial.zip]].

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

Les tests de la première version de la carte n'ont pas été super-concluant. Il faut dire qu'il y avait quelques erreurs de conception :
* le plus grave : le condensateur en parallèle de la batterie était noté 100nF au lieu des 2,2µF indiqué dans les documents technique, de plus le condensateur de 4,7µF demandé sur l'alimentation de la puce n'était pas implanté ;
* l'idée de commander la LED d'éclairage via le 5V du connecteur USB n'était pas très malin, cela interdisait une utilisation de la LED la carte non connectée sur une alimentation USB ;
* comme indiqué plus haut, il vaut mieux utiliser un ATmega16u4 qu'un ATmega16u2 ;
* plus généralement déconnecter au maximum la partie "utilisation" de la batterie de la partie "recharge" de la batterie réduit les problèmes potentiels.

[[Fichier:2023-ChargeurLiPo-Schema-V2.pdf|thumb|left|400px]]
[[Fichier:2023-ChargeurLiPo-PCB-V2.png|thumb|right|400px]]

Nouvelle version de la carte avec deux connecteurs USB : un USB A pour sa programmation et son fonctionnement USB, un USB mini pour la recharge de la batterie. Un interrupteur permet d'utiliser la LED, un autre de démarrer le microcontrôleur.

Projet KiCAD : [[Fichier:2023-ChargeurLiPo-KiCAD-V2.zip]]

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

== Test du transmetteur radio ==

[[Fichier:2023-BlueTooth-Schema.pdf|thumb|left|400px]]
[[Fichier:2023-BlueTooth-PCB.jpg|thumb|right|400px]]

Contrairement au titre du projet KiCAD cette carte est un transmetteur/récepteur radio générique.

Projet KiCAD : [[Fichier:2023-BlueTooth-KiCAD.zip]]

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

= Réalisations des binômes =

{| class="wikitable"
! Numéro !! Elèves !! Page
|-
| Binôme 1
| Victorien DETREZ & Benjamin CART
| [[SE3Binome2023-1|Binôme 1 2023/2024]]
|-
| Binôme 2
| Bilal MOUSSA & Yassine YAHIANI
| [[SE3Binome2023-2|Binôme 2 2023/2024]]
|-
| Binôme 3
| Kaoutar El Bachiri & Maxime BARRET
| [[SE3Binome2023-3|Binôme 3 2023/2024]]
|-
| Binôme 4
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-4|Binôme 4 2023/2024]]
|-
| Binôme 5
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-5|Binôme 5 2023/2024]]
|-
| Binôme 6
| Lililan GREVIN & Pierre CASIMIRI
| [[SE3Binome2023-6|Binôme 6 2023/2024]]
|-
| Binôme 7
| Augustin DJAJDJA-AVONYO & Kévan TOURON
| [[SE3Binome2023-7|Binôme 7 2023/2024]]
|-
| Binôme 8
| Justin WACQUET & Ibrahim TEPELI
| [[SE3Binome2023-8|Binôme 8 2023/2024]]
|-
| Monôme 9
| Mahmoud RABIA
| [[SE3Binome2023-9|Monôme 9 2023/2024]]
|-
| Binôme 10
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-10|Binôme 10 2023/2024]]
|-
|}

= Réalisations en programmation des systèmes embarqués =

== Binômes ==

{| class="wikitable"
! Numéro !! Elèves !! Page
|-
| Binôme 1
| Kaoutar EL BACHIRI & Maxime BARRET
| [[SE3_PSE_Binome2023-1|Binôme 1 2023/2024]]
|-
| Binôme 2
| Sarah Deparis & Agathe Houdusse
| [[SE3_PSE_Binome2023-2|Binôme 2 2023/2024]]
|-
| Binôme 3
| Victorien DETREZ & Benjamin CART
| [[SE3_PSE_Binome2023-3|Binôme 3 2023/2024]]
|-
| Binôme 4
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-4|Binôme 4 2023/2024]]
|-
| Binôme 5
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-5|Binôme 5 2023/2024]]
|-
| Binôme 6
| Lilian GREVIN & Pierre CASIMIRI
| [[SE3_PSE_Binome2023-6|Binôme 6 2023/2024]]
|-
| Binôme 7
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-7|Binôme 7 2023/2024]]
|-
| Binôme 8
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-8|Binôme 8 2023/2024]]
|-
| Binôme 9
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-9|Binôme 9 2023/2024]]
|-
| Binôme 10
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-10|Binôme 10 2023/2024]]
|-
|}

== Manette USB ==

Projet KiCAD de base pour les manettes : [[Fichier:2023-ManetteSE3-KiCAD.zip]]

Utilisez vos pages Wiki pour :
* attacher votre projet KiCAD ;
* déposer une photo de la carte soudée.

== Programmateur AVR ==

Utilisez vos pages Wiki pour :
* attacher vos programmes C (LUFA et libusb) ;
* déposer une photo de la carte soudée ;
* déposer une très courte vidéo de la carte avec les LED clignotantes ;
* déposer une copie écran montrant l'affichage de la communication entre votre programme libusb, votre carte et le microcontrôleur AVR.

SE3 PSE Binome2023-1

2024-03-05T13:40:34Z

Mbarret :

Projet: Voiture commandée par USB

Limitations et fonctionnalités:<br>
-taille de la carte 10x10cm maximum <br>
-Utilisation de LEDs (jaunes) comme clignotants de la voiture ainsi que pour les feux de recul (blanc) et feux de stop à l’arrêt (Rouge). Clignotants si partie mécanique réalisée.<br>
-Présence d'un port USB pour la programmation<br>
-Gestion de l'énergie par batterie LiPo<br>

Composants prévus à la conception: Batterie LiPo + Puce de controle MAX1811, 4 Leds jaunes, 2 leds blanches et 2 leds rouges, utilisation des mini-moteurs continus et du pilote des moteurs, microcontrôleur ATMega16u4.

SE3 PSE Binome2023-1

2024-03-05T13:36:17Z

Mbarret :

Projet: Voiture commandée par USB

Limitations et fonctionnalités:<br>
-taille de la carte 10x10cm maximum <br>
-Utilisation de LEDs (jaunes) comme clignotants de la voiture ainsi que pour les feux de recul (blanc) et feux de stop à l’arrêt (Rouge).<br>
-Présence d'un port USB pour la programmation<br>
-Gestion de l'énergie par batterie LiPo<br>

Composants prévus à la conception: Batterie LiPo, 4 Leds jaunes, 2 leds blanches et 2 leds rouges.

SE3 PSE Binome2023-1

2024-03-05T13:36:06Z

Mbarret :

Projet: Voiture commandée par USB

Limitations et fonctionnalités:
-taille de la carte 10x10cm maximum <br>
-Utilisation de LEDs (jaunes) comme clignotants de la voiture ainsi que pour les feux de recul (blanc) et feux de stop à l’arrêt (Rouge).<br>
-Présence d'un port USB pour la programmation<br>
-Gestion de l'énergie par batterie LiPo<br>

Composants prévus à la conception: Batterie LiPo, 4 Leds jaunes, 2 leds blanches et 2 leds rouges.

SE3 PSE Binome2023-1

2024-03-05T13:35:53Z

Mbarret :

Projet: Voiture commandée par USB

Limitations et fonctionnalités:
-taille de la carte 10x10cm maximum <br>
-Utilisation de LEDs (jaunes) comme clignotants de la voiture ainsi que pour les feux de recul (blanc) et feux de stop à l’arrêt (Rouge).
-Présence d'un port USB pour la programmation
-Gestion de l'énergie par batterie LiPo

Composants prévus à la conception: Batterie LiPo, 4 Leds jaunes, 2 leds blanches et 2 leds rouges.

SE3 PSE Binome2023-1

2024-03-05T13:35:36Z

Mbarret :

Projet: Voiture commandée par USB

Limitations et fonctionnalités:
-taille de la carte 10x10cm maximum
-Utilisation de LEDs (jaunes) comme clignotants de la voiture ainsi que pour les feux de recul (blanc) et feux de stop à l’arrêt (Rouge).
-Présence d'un port USB pour la programmation
-Gestion de l'énergie par batterie LiPo

Composants prévus à la conception: Batterie LiPo, 4 Leds jaunes, 2 leds blanches et 2 leds rouges.

SE3 PSE Binome2023-1

2024-03-05T13:33:13Z

Mbarret :

SE3 PSE Binome2023-1

2024-03-05T13:27:56Z

Mbarret :

Projet: Voiture commandée par USB

Limitations:
-taille de la carte 10x10cm maximum

PSE SE3 2023/2024

2024-03-05T13:24:01Z

Mbarret : /* Binômes */

= Objectif =

Pour l'année académique 2023/2024 il est toujours demandé de réaliser un système embarqué.

== Microcontrôleur ==

Pour éviter les problème avec les conversions analogique vers numérique vous utiliserez un ATmega16u4 ou un ATmega32u4. La programmation peut ainsi se faire très simplement par DFU/USB.

== Energie ==

Vos cartes doivent pouvoir être alimentées de façon hybride :
* par un port USB, méthode utilisée pour la programmation et les tests ;
* par une batterie Lithium, en mode autonome.

<gallery>
File:puce_max1811.jpg|Puce de contrôle de charge
File:batteries_LiPo.jpg|Batteries 100mAh et 300mAh, connecteur molex mâle
File:batterie_LiPo_FQ777.jpg|Batterie 100mAh 15x20x5mm
</gallery>

Il est conseillé de séparer au maximum les deux alimentations, voir la seconde version de la carte de test de chargement de batterie.

== Fonctionnalités ==

Vos cartes doivent toutes comporter des LED commandées par le microcontrôleur. Les autres fonctionnalités peuvent être choisies dans la liste suivante (non exhaustive). Les fonctionnalités doivent être validées par un intervenant.

* Vous pouvez partir sur le projet voiture de l'an passé en simplifiant l'aspect mécanique : deux moteurs pour les deux roues motrices, des roues directement enfilées sur les méplats des moteurs continus ou sur des engrenages montés en force sur l'axe des moteurs pas à pas. Le comportement de la voiture est téléchargé par une liaison USB/série et permet de spécifier une suite de commandes sur les deux moteurs et les lampes de la voiture.

<gallery>
file:2023-chassis-simple-dessus.png|Chassis vu de dessus
file:2023-chassis-simple-cote.png|Chassis vu de coté
File:micro-moteur-pas-a-pas-simple.jpg|Micro-moteur pas à pas propulsion
File:mini-motoreducteur.jpg|Mini-moteur continu avec réducteur
File:pilote-moteur-TB6612FNG.png|Pilote pour le mini-moteur continu (TB6612FNG)
</gallery>

* Vous pouvez partir sur un objet autonome communicant de type capteur, par exemple un capteur de température ou un micro espion. Le coté autonome est donné par la batterie, le coté communicant est à travailler à partir de la puce NRF24L01. Cette puce est une puce radio générale. Vous pouvez la tester à partir de la carte de test présenté dans la suite de ce sujet. Pour la réception des données de votre objet plusieurs alternatives sont possibles : mettre rapidement au point un récepteur à base de module basé sur un NRF24L01 et un Arduino ou vous entendre avec un autre binôme dont l'objet est soit :
** une centrale d'affichage des données des objets communicants sur des afficheurs 7 segments, un écran LCD alphanumérique ou un écran LCD graphique ;
** un périphérique USB de type carte son permettant de récupérer le flux du micro espion, dans ce dernier cas attention à bien sélectionner un microcontrôleur adapté.

<gallery>
File:module_nrf24L01.jpg|Module de communication 2,4Ghz
File:puce_nrf24L01.jpg|Puce de communication (soudure complexe)
</gallery>

* Vous pouvez tenter un objet autonome communicant de type actionneur, par exemple un haut-parleur diffusant les sons envoyés par un module radio. Là encore les sons peuvent être envoyés par un prototype à base d'Arduino ou par la carte d'un autre binôme réalisant un périphérique USB de type audio. Dans ce dernier cas attention à bien sélectionner un microcontrôleur adapté.

* Enfin si vous ne vous sentez pas trop sûr de vous il reste toujours la possibilité de l'objet complétement autonome comportant des capteurs et des actionneurs et réagissant en fonction de son environnement. Un exemple est un détecteur de mouvement à base de capteur PIR (Passive Infra-Red) donnant lieu à une séquence animée à base de LED ou à une séquence sonore.

= Cartes de test =

Cette année, plutôt que vous proposer des schémas complets de voitures, il a été décidé de vous proposer des cartes démontrant, chacune, une fonctionnalité éventuellement intégrable dans votre voiture.

== Test du chargeur ==

[[Fichier:2023-ChargeurLiPo-Schema.pdf|thumb|left|400px]]
[[Fichier:2023-ChargeurLiPo-PCB.jpg|thumb|right|400px]]

Les schéma et routage de la carte. Avec une erreur de base, le microcontrôleur est un ATmega32u2, c'est à dire un AVR sans ADC donc récupérer la tension de la batterie sera en tout ou rien. Un autre problème de conception est la trop faible charge de la LED qui peine à décharger la batterie.

Projet KiCAD : [[Fichier:2023-ChargeurLiPo-KiCAD.zip]]

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

[[Fichier:2023-ChargeurLiPo-Complete1.jpg|thumb|left|150px]]
[[Fichier:2023-ChargeurLiPo-Complete2.jpg|thumb|right|400px]]

Vous trouvez ici deux photos de la carte soudée.

Vous avez aussi un programme LUFA basé sur la démonstration <code>VirtualSerial</code> pour contrôler la carte, en particulier lancer la charge de la batterie et voir si sa tension se traduit par un état haut ou bas. Tapez n'importe quoi avec un retour chariot dans un terminal série pour voir la liste des commandes possibles.

Programme : [[Media:2023-ChargeurLiPo-VirtualSerial.zip]].

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

Les tests de la première version de la carte n'ont pas été super-concluant. Il faut dire qu'il y avait quelques erreurs de conception :
* le plus grave : le condensateur en parallèle de la batterie était noté 100nF au lieu des 2,2µF indiqué dans les documents technique, de plus le condensateur de 4,7µF demandé sur l'alimentation de la puce n'était pas implanté ;
* l'idée de commander la LED d'éclairage via le 5V du connecteur USB n'était pas très malin, cela interdisait une utilisation de la LED la carte non connectée sur une alimentation USB ;
* comme indiqué plus haut, il vaut mieux utiliser un ATmega16u4 qu'un ATmega16u2 ;
* plus généralement déconnecter au maximum la partie "utilisation" de la batterie de la partie "recharge" de la batterie réduit les problèmes potentiels.

[[Fichier:2023-ChargeurLiPo-Schema-V2.pdf|thumb|left|400px]]
[[Fichier:2023-ChargeurLiPo-PCB-V2.png|thumb|right|400px]]

Nouvelle version de la carte avec deux connecteurs USB : un USB A pour sa programmation et son fonctionnement USB, un USB mini pour la recharge de la batterie. Un interrupteur permet d'utiliser la LED, un autre de démarrer le microcontrôleur.

Projet KiCAD : [[Fichier:2023-ChargeurLiPo-KiCAD-V2.zip]]

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

== Test du transmetteur radio ==

[[Fichier:2023-BlueTooth-Schema.pdf|thumb|left|400px]]
[[Fichier:2023-BlueTooth-PCB.jpg|thumb|right|400px]]

Contrairement au titre du projet KiCAD cette carte est un transmetteur/récepteur radio générique.

Projet KiCAD : [[Fichier:2023-BlueTooth-KiCAD.zip]]

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

= Réalisations des binômes =

{| class="wikitable"
! Numéro !! Elèves !! Page
|-
| Binôme 1
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-1|Binôme 1 2023/2024]]
|-
| Binôme 2
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-2|Binôme 2 2023/2024]]
|-
| Binôme 3
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-3|Binôme 3 2023/2024]]
|-
| Binôme 4
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-4|Binôme 4 2023/2024]]
|-
| Binôme 5
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-5|Binôme 5 2023/2024]]
|-
| Binôme 6
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-6|Binôme 6 2023/2024]]
|-
| Binôme 7
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-7|Binôme 7 2023/2024]]
|-
| Binôme 8
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-8|Binôme 8 2023/2024]]
|-
| Binôme 9
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-9|Binôme 9 2023/2024]]
|-
| Binôme 10
| Prénom NOM & Prénom NOM
| [[SE3Binome2023-10|Binôme 10 2023/2024]]
|-
|}

= Réalisations en programmation des systèmes embarqués =

== Binômes ==

{| class="wikitable"
! Numéro !! Elèves !! Page
|-
| Binôme 1
| Kaoutar EL BACHIRI & Maxime BARRET
| [[SE3_PSE_Binome2023-1|Binôme 1 2023/2024]]
|-
| Binôme 2
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-2|Binôme 2 2023/2024]]
|-
| Binôme 3
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-3|Binôme 3 2023/2024]]
|-
| Binôme 4
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-4|Binôme 4 2023/2024]]
|-
| Binôme 5
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-5|Binôme 5 2023/2024]]
|-
| Binôme 6
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-6|Binôme 6 2023/2024]]
|-
| Binôme 7
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-7|Binôme 7 2023/2024]]
|-
| Binôme 8
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-8|Binôme 8 2023/2024]]
|-
| Binôme 9
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-9|Binôme 9 2023/2024]]
|-
| Binôme 10
| Prénom NOM & Prénom NOM
| [[SE3_PSE_Binome2023-10|Binôme 10 2023/2024]]
|-
|}

== Manette USB ==

Projet KiCAD de base pour les manettes : [[Fichier:2023-ManetteSE3-KiCAD.zip]]

Utilisez vos pages Wiki pour :
* attacher votre projet KiCAD ;
* déposer une photo de la carte soudée.

== Programmateur AVR ==

Utilisez vos pages Wiki pour :
* attacher vos programmes C (LUFA et libusb) ;
* déposer une photo de la carte soudée ;
* déposer une très courte vidéo de la carte avec les LED clignotantes ;
* déposer une copie écran montrant l'affichage de la communication entre votre programme libusb, votre carte et le microcontrôleur AVR.