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

SE4Binome2023-9

2023-09-20T08:32:47Z

Yelqasta : /* Test du bouclier */

== Ordonnanceur / SE ==

=== Matériel pour l'ordonnanceur ===
[[Fichier:Carte du bouclier avant soudure.jpg|vignette|gauche|Carte du bouclier avant soudure|304x304px]]
[[Fichier:Carte après soudure.jpg|vignette|droite|Carte du bouclier après première soudure|285x285px]][[Fichier:He10 cable.jpg|vignette|centre|2 câbles HE10/HE10|317x317px]]
[[Fichier:Adaptateur le.jpg|vignette|Adaptateur|gauche|287x287px]][[Fichier:Adaptateur l.jpg|vignette|Bouclier soudé|306x306px]]

=== Test du bouclier ===
Pour tester le bon fonctionnement des LED, nous avons simplement écrit un code avec <code>PORTB</code>, <code>PORTC</code>et<code>PORTD</code>à <code>0xFF</code>(le code est disponible sur le git) :[[Fichier:Video test led.mov|vignette|Test des LED du shield|centré]]
<p style="clear: both;" />

=== Programmation du timer1 ===
Il est demandé de générer une interruption toutes les 20 ms. En nous inspirant du code présent sur cette [https://rex.plil.fr/Enseignement/Systeme/Systeme.PSE/systeme038.html page], nous avons pu, par le biais d'interruptions, allumer la LED d'un Arduino Uno.

Pour générer une interruption toutes les 20 ms, il est nécessaire de régler le nombre de "ticks" et donc la valeur du registre <code>OCR1A</code>.

== Carte FPGA / VHDL ==

== Carte électronique numérique ==

=== Type carte choisi ===

Carte mère
=== Caractéristiques de la carte mère ===

ReX : a mettre comme sous-section de la section "Carte électronique numérique"*

ReX : utilisez la syntaxe mediawiki pour les items.

* Alimentation : USB

* Tension alimentation : 5V avec régulateur

* Programmation par AVR ISP

= Rendus =

== GIT ==
https://archives.plil.fr/yelqasta/pico_ybenmbar_yelqasta_se4.git

SE4Binome2023-9

2023-09-12T13:20:24Z

Yelqasta :

== Caractéristiques de la carte mère ==
- alimentation : usb

- tension alimentation : 5V avec regulateur

- programmmation par avr isp

== Ordonnanceur ==

== Carte FPGA / VHDL ==

== Carte électronique numérique ==

== Type carte choisi ==

Carte mère

SE4Binome2023-9

2023-09-12T13:15:15Z

Yelqasta : /* Type carte choisi */

== Ordonnanceur ==

== Carte FPGA / VHDL ==

== Carte électronique numérique ==

== Type carte choisi ==

Carte mère

SE4Binome2023-9

2023-09-12T13:14:18Z

Yelqasta : Page créée avec « == Ordonnanceur == == Carte FPGA / VHDL == == Carte électronique numérique == == Type carte choisi == »

== Ordonnanceur ==

== Carte FPGA / VHDL ==

== Carte électronique numérique ==

== Type carte choisi ==

Pico SE4 2023/2024

2023-09-12T12:47:12Z

Yelqasta : /* Réalisations des élèves */

= Objectif =

Pour l'année académique 2023/2024 nous vous demandons de construire un pico-ordinateur comprenant les éléments suivants :
* un processeur de type microcontrôleur ;
* un clavier ;
* un dispositif d'affichage ;
* un système d'exploitation stocké dans la mémoire flash du microcontrôleur ;
* une mémoire de masse allant au delà de la mémoire flash sus-citée ;
* un dispositif de communication avec l'extérieur.

Pour faire en sorte que tous les éléments puissent communiquer entre eux nous vous demandons d'utiliser un bus série.

= Compétences évaluées =

Les compétences suivantes doivent être acquises durant ce module.
* Savoir comprendre, ou à défaut être actif en séances pour poser les questions pertinentes aux encadrants.
* Savoir produire un travail régulier et documenté durant la totalité de la période.
* Savoir concevoir et réaliser des cartes électroniques fonctionnelles.
* Savoir concevoir et programmer un circuit FPGA en VHDL.
* Savoir structurer et écrire des pilotes pour cartes électroniques.
* Savoir concevoir et implanter des primitives systèmes et un micro-système d'exploitation.

= Organisation du travail =

Vous aurez, comme d'habitude, la lourde tâche de tester ce module de travaux pratiques.

Ce sera d'autant moins facile que nous vous demandons de vous coordonner pour réaliser le pico-ordinateur : un seul exemplaire fonctionnel est attendu par groupes de 4 binômes.

Vous allez donc devoir vous organiser pour que chaque binôme réalise une partie de l'ensemble. Cela dit des tâches identiques sont à réaliser par tous les binômes, ces tâches vous permettront de vous exercer mais aussi de tester vos réalisations spécifiques.

== Matériel fourni ==

[[file:2023_Bouclier_Pico.pdf||thumb|right|400px]]

Pour que chaque binôme puisse avoir un minimum d'autonomie, un matériel de base est fourni :
* un Arduino Uno pour prototyper le coeur d'une carte mère ;
* un bouclier Arduino pour disposer d'une mémoire de masse (carte SD) et de connecteurs vers les cartes filles, voir le schéma et le PCB ci-contre ;
* d'une matrice de LED et d'un afficheur 7-segments tous les deux gérables par SPI pour pouvoir écrire les briques de votre système d'exploitation.

Le projet KiCAD pour le bouclier Arduino est disponible : [[Média:2023_Bouclier_Pico.zip]]

Les projets KiCAD pour connecter les périphériques via un connecteur sont disponibles : [[Média:2023_HE10-periph.zip]]

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

[[file:2023_Bouclier_Pico_PCB.png||thumb|center|300px]]

Vision de la carte partiellement montée. L'accès à la carte SD est fonctionnel.

[[file:2023_Bouclier_Pico_Test.jpg||thumb|center|300px]]

Pour la partie programmation concernant la carte SD vous pouvez vous appuyer sur le projet ci-contre utilisant <code>avr-gcc</code> comme compilateur : [[Fichier:TestSD_avrgcc.zip]].

== Réalisations par binôme ==

Chaque binôme réalise :
* un système d'exploitation basé sur un ordonnanceur ;
* une carte fille FPGA programmée par VHDL, le binôme écrit aussi le code pour que la carte puisse être gérée par le système d'exploitation ;
* une carte mère ou une carte fille à base de microcontrôleur, le binôme écrit aussi le code pour que la carte puisse être gérée par le système d'exploitation, le binôme peut réaliser plusieurs cartes pour maximiser sa note.

== Réalisation par groupe de binômes ==

Par groupe de 4 binômes vous devez réaliser un pico-ordinateur complet :
* une carte mère ;
* une carte fille FPGA/VHDL fonctionnelle et supportée par votre carte mère ;
* au moins 3 cartes filles fonctionnelles et supportées par votre carte mère (clavier, écran, réseau) ;
* vous pouvez ajouter une cinquième carte fille optionnelle de type carte son.

= Cahier des charges =

== Ordonnanceur ==

Vous n'avez pas besoin d'avoir conçu et réalisé des cartes électroniques pour commencer à écrire le système d'exploitation du pico-ordinateur et en particulier l'ordonnanceur sous-jacent.

Le principe est d'utiliser un minuteur du microcontrôleur pour lancer périodiquement une fonction d'interruption que vous allez transformer en ordonnanceur.

Dans un premier temps vous testerez votre ordonnanceur en créant deux tâches statiques pour faire clignoter, avec des périodes différentes, deux LED du bouclier fourni.

Par la suite vous allez complexifier votre ordonnanceur en ajoutant :
* une tâche de lecture de caractère par le port série (stocké en mémoire partagé) ;
* une tâche d'écriture sur le port série (du caractère lu sur le port série) ;
* une tâche d'écriture sur la matrice (du caractère lu sur le port série) ;
* une tâche d'écriture sur l'afficheur 7 segments (du caractère lu sur le port série).

Les deux dernières tâches sont plus compliquées à réaliser dans la mesure où elles utilisent une ressource commune.

== Cartes filles FPGA ==

Les cartes filles FPGA doivent être programmées en VHDL. Tous les binômes doivent implanter en VHDL :
* un contrôleur de bus série SPI ;
* un décodeur des commandes reçues par SPI (commandes sur un octet avec éventuellement des paramètres à suivre) ;
* un contrôleur d'écran VGA affichant le contenu graphique de la RAM de la carte FPGA.

A minima il faut une commande pour insérer un pixel d'une couleur donnée dans la RAM d'affichage.

Vous pouvez aussi ajouter des fonctionnalités supplémentaires à votre carte FPGA :
* mémoire de masse par accès direct à une carte mémoire SD ;
* carte réseau Ethernet en utilisant un module PHY Ethernet.

Pour les fonctionnalités supplémentaires vous devez prévoir des commandes supplémentaire au niveau du décodeur.

== Cartes électroniques ==

Vous devez réaliser deux type de cartes électroniques à base de microcontrôleur : une carte mère et des cartes filles.
La carte FPGA/VHDL décrite dans la section précédente est considérée comme une carte fille.

Les cartes filles sont connectées via un bus série à la carte mère. C'est aussi la carte mère qui alimente les cartes filles.
Enfin la carte mère dispose d'une mémoire permanente pour stocker des fichiers.

Les cartes filles peuvent être de différents types :
* carte fille clavier ;
* carte fille d'affichage ;
* carte fille série (se comporte comme un clavier et comme un dispositif d'affichage) ;
* carte fille réseau ;
* carte fille mémoire de masse (alternative à la mémoire de masse de la carte mère) ;
* carte fille son.

Pour un type donné vous avez le choix entre plusieurs technologies pour réaliser votre carte. Par exemple une carte fille clavier peut être implantée par une matrice de touches ou en utilisant un clavier USB.

== Programmation système ==

Le système d'exploitation du pico-ordinateur doit avoir les fonctionnalités d'un DOS (Disk Operating System), à savoir :
* lecture des commandes tapées par l'utilisateur ;
* téléchargement d'exécutables ou de sources via le dispositif de communication extérieur ;
* sauvegarde et chargement d'exécutables ou de sources via la mémoire de masse ;
* permettre l'affichage de chaînes de caractères ;
* comprend un interpréteur micro-python pour faire tourner les sources ;
* les différentes fonctionnalités sont réalisées sous forme de tâches gérées par un ordonnanceur.

=== Commandes de base ===

Ces commandes sont les commandes les plus simples à implanter :

{| class="wikitable"
! Commande !! Description
|-
| VERSION || Affiche la version du système d'exploitation
|-
| DEVICES || Affiche la liste des cartes filles connectées
|-
| ECHO || Affiche les arguments de la commande
|}

=== Commandes liées aux processus ===

{| class="wikitable"
! Commande !! Description
|-
| PS || Liste les processus disponibles et leur état
|-
| SLEEP || Met un processus en sommeil
|-
| WAKE || Relance un processus dormant
|-
| EXEC || Création d'un processus à partir d'un fichier exécutable
|}

La commande EXEC est complexe à réaliser, elle est optionnelle pour l'année 2023/2024.

=== Commandes liées au système de fichiers ===

Commandes pour gérer le système de fichiers :

{| class="wikitable"
! Commande !! Description
|-
| FORMAT || Formate le système de fichiers
|-
| LIST || Affiche les fichiers du répertoire principal
|-
| CREATE || Création d'un fichier avec l'entrée standard
|-
| TYPE || Affiche le contenu d'un fichier
|-
| COPY || Copie un fichier
|-
| RENAME || Renomme un fichier
|}

=== Commandes liées au réseau ===

{| class="wikitable"
! Commande !! Description
|-
| REMOTE || Liste les fichiers disponibles sur le réseau
|-
| GET || Télécharge un fichier en provenance du réseau
|-
| PUT || Sauve un fichier sur le réseau
|}

== Programmation des pilotes ==

La programmation c'est aussi l'écriture des sous-systèmes ou des pilotes liés à chaque cartes :
* pour la carte mère, il faut écrire un sous-système de gestion de fichiers ;
* pour la carte fille comportant une matrice de touches, il faut écrire le pilote identifiant les touches actionnées et gérant l'envoi de ces touches à la carte mère ;
* pour la carte fille gérant un clavier USB, il faut utiliser un projet LUFA pour scanner régulièrement le clavier USB et envoyer d'éventuels événements à la carte mère ;
* pour la carte fille gérant un écran LCD, il faut écrire le pilote capable de gérer l'écran et la partie récupérant les données de la carte mère ;
* pour la carte fille gérant une clé USB, il faut utiliser un projet LUFA pour l'accès à la clé et écrire un sous-système de gestion de fichiers ;
* la carte fille gérant une connexion série ne nécessite qu'un modeste pilote de communication avec la carte mère ;
* pour la carte fille permettant une connexion avec le monde extérieur via de simples points d'accès USB de volume (EP Bulk), il faut écrire le pilote pour communication avec la carte mère mais aussi le programme sur le PC permettant la réception ou l'envoi de fichiers ;
* pour la carte fille permettant une connexion Ethernet au dessus d'USB (RNDIS), il faut écrire une micro-pile réseau capable de récupérer et d'envoyer des fichiers au travers de paquets Ethernet mais aussi le programme sur le PC cible capable de comprendre ces paquets Ethernet ;
* pour la carte fille incluant une puce Ethernet, il faut implanter la micro-pile réseau et le programme évoquée ci-dessus mais aussi le pilote capable de gérer la puce Ethernet ;
* pour la carte fille son, il faut écrire la partie permettant de récupérer les échantillons, les copier en mémoire, et les jouer à la vitesse d'échantillonnage préalablement transmise.

= Spécifications techniques =

== Ordonnanceur ==

Pour réaliser votre ordonnanceur commencez par programmer le minuteur 1 de l'ATMega328p de sorte à ce qu'il génère une interruption toutes
les 20ms. L'interruption va déclencher une fonction de gestion d'interruption (ISR pour Interrupt Service Routine). Vous utiliserez une ISR nue pour éviter les interférences du compilateur sur la pile d'exécution :
ISR(TIMER1_COMPA_vect,ISR_NAKED)
{
/* Sauvegarde du contexte de la tâche interrompue */
...
/* Appel à l'ordonnanceur */
scheduler();
/* Récupération du contexte de la tâche ré-activée */
...
asm volatile ( "reti" );
}
Vous constatez qu'il vous reste à écrire, dans l'ISR, le code pour sauvegarder et récupérer le contexte d'exécution d'une tâche. Pour cela réfléchissez aux éléments d'un microcontrôleur qui sont nécessaires pour l'exécution d'un programme puis réfléchissez à une méthode pour sauver l'état de ces éléments.

Au moins dans un premier temps, les tâches seront définies de façon statique. Toutes les tâches doivent être définies dans un tableau global, seront lancées dès le démarrage du microcontrôleur et ne se termineront que lorsque le microcontrôleur sera arrêté ou relancé. Une tâche est à définir par une structure dont un des champs doit être la fonction réalisant la tâche. A vous de définir les autres champs.

Avant de démarrer l'ordonnanceur, il faut prendre soin à ce que la récupération du contexte dans l'ISR fonctionne alors que les tâches n'auront pas encore été lancées. Il faut donc une fonction permettant d'initialiser le contexte pour chaque tâche.

== Cartes électroniques à microcontrôleur ==

Le bus série préconisé pour la communication entre la carte mère et les cartes filles est un bus SPI. Au niveau physique, les connexions entre cartes mères et cartes filles doivent être réalisées via des connecteurs HE-10 à 8 broches :
* 2 broches pour l'alimentation ;
* 3 broches pour les signaux SPI (MISO, MOSI, SCK) ;
* 1 broche pour le CS (Chip Select) ;-
* 1 broche pour une éventuelle ligne d'interruption ;
* 1 broche pour une eventuelle réinitialisation de la carte (Reset).

Il est conseillé d'organiser les broches sur les connecteurs HE-10 sur le modèle du bouclier Arduino fourni.

La carte mère est constituée autour d'un ATMega328p et d'une puce mémoire de type AT45DB641E de 8 Mo. Il faut réflechir à l'alimentation sachant que :
* l'alimentation de la carte mère doit être suffisante pour alimenter les cartes filles ;
* l'alimentation du microcontrôleur doit être compatible avec l'alimentation de la puce mémoire sauf à prévoir une conversion de niveaux logiques entre les deux puces ;
* les cartes filles d'un même pico-ordinateur doivent être alimentées avec la même tension.

Voici quelques exemples d'architectures de cartes filles :
* une carte fille SPI avec un ATMega328p et une matrice de touches ;
* une carte fille SPI avec un AT90USB647 pour connexion à un clavier USB ou une clef USB ;
* une carte fille SPI avec un ATMega328p et un écran LCD 2 lignes HD44780 ;
* une carte fille SPI avec un ATMega16u2 pour une connexion série USB ;
* une carte fille SPI avec un ATMega328p et un DAC R-2R comme carte son ;
* une carte fille SPI avec un ATMega16u2 (ou supérieur) pour une connexion réseau (périphérique USB générique EP bulk ou périphérique USB RNDIS) ;
* une carte fille SPI avec un ATMega328p et un ENC28J60 pour une connexion Ethernet 10Mb/s.

Toutes les cartes doivent permettre un accès au port série de leur microcontrôleur pour un déverminage via un FTDI. Vous devez aussi ajouter des points de test pour les lignes importantes : lignes du bus SPI, horloge, alimentations, etc.

Toutes les cartes filles répondent à la commande SPI constituée de l'octet de commande 0x00 et de l'octet de donnée 0x00. Le résultat se lit sur le second octet de réponse et détermine le type de la carte fille. Le chiffre de poid fort de la réponse est un code magique : 0xa. Le chiffre de poid faible est donné par le tableau ci-dessous :
{| class="wikitable"
! Chiffre !! Type de carte
|-
| 0x1 || Clavier
|-
| 0x2 || Affichage
|-
| 0x4 || Réseau
|-
| 0x8 || Carte son
|}

Il est bon aussi de prévoir que les cartes filles puissent répondre à une commande SPI permettant de savoir si elles sont occupées ou non. L'octet de commande serait 0xFF et l'octet de donnée 0xFF. En cas de succès les deux octets de réponse sont à 0x55. Les cartes filles doivent prendre soin d'initialiser leur réponse SPI à autre chose que 0x55 lorsqu'elles se lancent dans un traitement autre qu'une écoute SPI.

== Electronique et programmation système ==

=== Carte mère ===

La carte mère doit comporter un microcontrôleur ATMega328p, une puce mémoire AT45DB641E et 5 connecteurs HE10 pour connecter une carte fille FPGA et 4 cartes filles à microcontrôleur.

Vous avez aussi quelques points à approfondir.
# La source d'alimentation de votre pico-ordinateur, le plus simple semble être un connecteur USB pour utiliser soit un PC soit une batterie comme source ;
# La tension d'alimentation du microcontrôleur et des cartes filles :
#* soit vous optez pour du 5V auquel cas il faut prévoir un régulateur de tension pour la puce mémoire et une adaptation des niveaux logiques pour cette même puce (voir le schéma des boucliers Arduino),
#* soit vous partez sur du 3.3V et vos cartes filles doivent tourner en 3.3V, vu que vous aurez probablement un adaptateur 5V il faut quand même prévoir un régulateur 3.3V assez costaud sur la carte mère, de plus vous ne pouvez pas dépasser 8Mhz comme horloge ;
# La méthode de programmation de la carte mère :
#* soit vous programmez le microcontrôleur via un connecteur AVR ISP, un programmateur et l'utilitaire <code>avrdude</code> ;
#* soit vous ajoutez une puce pour réaliser un pont USB vers série vous pourrez alors programmer le microcontrôleur avec <code>dfu-programmer</code>, attention il faut tout de même prévoir des connecteurs AVR ISP pour charger l'amorceur sur l'ATMega328p et l'éventuel ATMega8u2 (vous utilisez cette puce pour l'USB/série plutôt qu'une puce FTDI).

Du coté programmation vous êtes chargés d'écrire les fonctions d'accès à la mémoire, des primitives systèmes implantant un micro-système de fichiers et des primitives de communication via le bus SPI.

Les fonctions de base d'accès à la mémoire sont facilement trouvables, par exemple sur les sites du bureau d'études systèmes embarqués des PeiP.

Concernant le micro-système de fichiers, les fonctionnalités suivantes doivent être implantées :

* le système de fichiers doit résider dans la mémoire de 8 Mo, les accès à la mémoire se font par blocs de 256 octets ;
* l'accès au système de fichiers se fait par des primitives système ;
* le micro-système de fichiers ne comporte qu'un répertoire : le répertoire principal, ce dernier peut comporter au maximum 64 fichiers, un fichier est caractérisé par un nom de 16 caractères au maximum, sa taille et ses blocs de données, un fichier est décrit par un maximum de 16 blocs de données ;
* le superbloc du système de fichiers comprend, en plus de la description du répertoire racine, une carte bit à bit des blocs de données libres, cette carte nécessite 16 blocs ;
* les différentes primitives à implanter sont :
** <code>append</code> pour créer un fichier si non existant et ajouter des données en fin de fichier, les paramètres sont le nom du fichier, les données à ajouter et la taille des données,
** <code>read</code> pour lire des données dans un fichier, les paramètres sont le nom du fichier, le tableau dans lequel stocker les données, la taille du tableau et le déplacement par rapport au début du fichier,
** <code>remove</code> pour détruire un fichier, le seul paramètre est le nom du fichier,
** <code>rename</code> pour renommer un fichier, les paramètres sont l'ancien et le nouveau noms du fichier,
** <code>copy</code> pour copier un fichier, les paramètres sont le nom du fichier original et le nom de la copie.

Les primitives pour le bus SPI doivent être :
* une fonction d'initialisation avec le mode SPI désiré et la vitesse d'horloge souhaitée ;
* une primitive pour envoyer quelques octets via le bus SPI :
** les paramètres de la primitive sont le tableau des octets à envoyer, le tableau des octets à recevoir, le nombre d'octets à envoyer et la spécification de la sortie CS de sélection du périphérique SPI,
** la primitive stocke l'opération dans une file et effectue l'envoi dès que le bus est libre,
** si la file est pleine la primitive peut retourner un code d'erreur sinon la primitive retourne l'identifiant unique de l'opération,
** les octets de réponse du périphérique sont stockés dans le tableau des octets à recevoir, si le pointeur est nul les réponses ne sont pas stockées ;
* une primitive pour attendre la fin d'un envoi SPI, il faut donner en unique paramètre l'identifiant de l'opération, l'attente s'effectue en mettant le processus appelant en mode sommeil et en le réveillant dès que l'opération est effectuée.

Précisons que les tableaux stockés dans la file d'attente (requête et réponse SPI) le sont sous la forme de pointeurs. Ces pointeurs peuvent être librérés une fois l'opération effectuée.

=== Carte fille clavier "matrice de touches" ===

La réalisation de la carte est simple, il s'agit de scanner une matrice de touches à l'aide d'un ATMega328p. N'oubliez pas le connecteur HE10 pour la connexion de cette carte fille à une carte mère. Sur le connecteur HE10 il faut prévoir à la fois la ligne de sélection SPI (utilisez la broche SS par défaut sur votre carte) et une ligne pour générer une interruption sur la carte mère. Vous devez faire avec l'alimentation fournie par la carte mère. Regardez aussi la problèmatique sur la programmation décrite dans la section sur la carte mère.

Du coté programmation, c'est plus compliqué, vous êtes déjà chargés d'écrire la fonction de scan des touches :
* le scan des touches consiste juste à passer les lignes de la matrice en sorties, les colonnes en entrées avec résistance de charge et de rentrer dans une boucle pour passer une sortie à GND tandis que les autres restent à VCC, il suffit alors de consulter les entrées pour voir si une touche est appuyée (ou plusieurs) ;
* si une touche est appuyée la touche est stockée dans un tampon et la ligne d'interruption est activée ;
* si une requête SPI de code commande 0x01 est reçue, le nombre de touches dans le tampon est envoyé suivi des touches elles-mêmes.

Ensuite, au niveau de la carte mère vous devez écrire la primitive gérant les claviers. Cette primitive prend en paramètre la ligne de sélection SPI du clavier ciblé et un tampon pour stocker les codes des touches. La taille du tampon est aussi passée en paramètre. La primitive prépare une transmission SPI constituée du seul octet de valeur 0x01 en prenant soin de préciser un tableau pour stocker d'éventuelles touches. Attention, la transmission SPI est constituée de l'octet 0x01 mais aussi d'autant d'octets de valeurs indéterminées qu'il est attendu d'octets dans la réponse SPI. La primitive se met alors en attente de la réponse.

Au niveau du système d'exploitation les comportements suivants sont à implanter :
* à l'initialisation de la carte mère les périphériques SPI doivent être contactés pour déterminer lequels sont des claviers, des commandes SPI 0x00 sont donc envoyées avec attente des réponses SPI ;
* le processus SHELL toujours présent dans le système d'exploitation doit avoir le comportement suivant :
** si une interruption est reçue qui correspond à un périphérique clavier, le SHELL doit utiliser la primitive de lecture clavier pour obtenir la ou les touches appuyées ;
** dans un premier temps, les caractères reçus sont affichés en utilisant la primitive d'affichage (echo) ;
** à terme les lignes de caractères reçues sont analysées pour en extraire des commandes et les exécuter.

=== Carte fille clavier "USB" ===

Votre carte électronique doit tourner autour d'un AT90USB647 (ou supérieur). Ce microcontrôleur peut être programmé, en utilisant la bibliothèque LUFA, comme hôte USB. Il est donc possible de gérer, de cette façon un clavier USB et de faire interface avec la carte mère. Le schéma de la carte est très semblable à celui d'une carte comportant un ATMega16u2. Vous pouvez vous appuyer sur ce [https://wiki-se.plil.fr/mediawiki/index.php/SE4_2022/2023_EC5 projet keylogger]. Le plus simple est de programmer le microcontrôleur en utilisant l'utilitaire <code>dfu-programmer</code>, pour cela il faut prévoir, en plus d'un connecteur USB A femelle pour le clavier, un connecteur USB mâle pour la programmation.

La programmation pour la gestion du clavier USB doit se reposer sur la démonstration <code>KeyboardHost</code> de la bibliothèque LUFA. La conversion des modificateurs et des codes de touches en caractères ASCII sont à votre charge.

Pour le reste de la programmation voir la section sur la carte fille "matrice de touches".

=== Carte fille écran LCD ===

Cette carte comporte un ATMega328p et un écran LCD à base de contrôleur HD44780. L'écran LCD nécessite un potentiomètre pour régler la luminosité des cristaux liquides. N'oubliez pas le connecteur HE10 pour la connexion de cette carte fille à une carte mère. Sur le connecteur HE10 il faut prévoir une ligne de sélection SPI. Aucune ligne d'interruption n'est nécessaire pour cette carte. Enfin il vous faut prévoir un connecteur AVR ISP pour programmer le microcontrôleur.

Le microcontrôleur de la carte fille doit être programmé pour gérer le contrôleur HD44780 ou compatible :
* les écrans avec 1, 2, 3 ou 4 lignes doivent être gérés ;
* les caractères ASCII doivent être affichés sur l'écran ;
* les caractères spéciaux <code>\n</code> et <code>\r</code> doivent être pris en compte pour le saut de ligne et le retour chariot ;
* les codes VT100 doivent être pris en compte, en particulier pour le déplacement du curseur doivent être pris en compte ;
* le contrôleur HD44780 ou compatible doit être configuré en mode défilement automatique.

Les caractères à afficher ou spéciaux (y compris les séquences VT100) sont reçus par le bus SPI par la carte fille préfixés par le code commande 0x01.

Au niveau de la carte mère vous devez écrire la primitive système. Cette primitive prend en paramètre la ligne de sélection SPI de l'écran ciblé et la chaîne des caractères à envoyer. La primitive prépare une transmission SPI constituée de l'octet de commande 0x01 et des octets correspondant aux caractères.

Il ne faut pas demander un affichage si un autre affichage est en cours. C'est possible à réaliser avec la ligne prévue pour une interruption. La carte fille peut mettre cette ligne en état haut quand un affichage est en cours. Du coup la primitive peut se mettre en attente sur un état bas avant d'envoyer la requête SPI. C'est aussi possible de lancer des commandes 0xFF sur la carte jusqu'à obtenir les octets de réponse indiquant que la carte est libre.

Cette primitive est utilisée par le système d'exploitation pour réaliser l'écho des commandes dans le SHELL et aussi par toutes les commandes qui nécessitent un affichage. Tous les écrans doivent être sollicités lors des affichages, il faut donc que le système d'exploitation scanne les périphériques SPI pour trouver les écrans comme il le fait pour les claviers.

=== Carte fille réseau RNDIS ===

Le but de cette carte est de permettre au pico-ordinateur de converser avec l'extérieur. Une carte RNDIS permet de faire transister des paquets Ethernet au dessus d'une liaison USB. La carte n'a besoin que d'un microcontrôleur avec capacités USB pour fonctionner. Vous pouvez utiliser un
ATMega16u2, un ATMega32u4 ou un AT90USB suivant la taille mémoire dont vous souhaitez disposer. Gardez en mémoire qu'un paquet Ethernet peut comporter jusqu'à 1500 octets. La programmation du microcontrôleur se fera par DFU USB. Il est notable que la programmation du microcontrôleur et la communication vers l'extérieur se fait par le même connecteur USB.

La communication se fait forcément via le PC auquel la carte fille est connectée par USB. Cela dit si ce PC est connecté en réseau, les fichiers auxquels le pico-ordinateur accède peuvent se trouver sur un autre PC. Si votre carte fille est correctement programmée comme carte RNDIS USB, le PC sous Linux va automatiquement créer une interface réseau <code>usb0</code>. A vous de la démarrer avec la commande <code>ip link set usb0 up</code> ou une commande du type <code>ip address add @IP/masque dev usb0</code>.

La base de la programmation de cette carte est la démonstration LUFA RNDIS. Des versions de cette démonstration incluent une implantation de pile TCP/IP. A vous de voir à quel niveau vous souhaitez que votre carte réseau opère :
* si vous visez Ethernet, votre projet LUFA sera assez simple à écrire mais l'application sur le PC sera un peu exotique, il vous faudra utiliser la programmation socket en mode RAW ;
* si vous visez UDP, votre projet LUFA sera plus complexe mais l'application sur le PC pourra se faire avec des sockets en mode non connecté standard ;
* si vous visez TCP, votre projet LUFA sera complexe et nécessitera un microcontrôleur avec pas mal de mémoire, par contre vous pourrez utiliser des applications standard sur le PC (serveur Web ou FTP).

Au niveau de la carte, en plus de votre pile réseau vous devez écrire les fonctions permettant de lister des fichiers distants, de les recevoir et d'en envoyer :
* Si la commande SPI est 0x01, la carte mère vous demande de lister les fichiers distants, vous devez donc former les paquets réseau nécessaires pour envoyer la demande, la commande SPI peut comporter un argument supplémentaire pour préciser la localisation des fichiers. A la suite d'une commande 0x01, la carte mère doit envoyer des commandes 0x11 pour récupérer tous les noms de fichiers, idéalement un nom par commande 0x11 pour ne pas déborder la mémoire du microcontrôleur. Si le fichier n'est pas le dernier la réponse SPI est 0x01 sinon 0x00. Si vous utilisez Ethernet ou UDP, il faut prévoir un délai maximal pour la réception des paquets de sorte à ne pas bloquer la commande. En cas de non réception de paquet, il faut retourner un code SPI d'erreur, par exemple 0x02.

* Si la commande SPI est 0x02, la carte mère souhaite récupérer un fichier. Vous devez former les paquets réseau nécessaires pour demander le fichier précisé dans la suite de la commande SPI. De la même façon que pour la liste, des commandes SPI ultérieures 0x12 doivent être envoyées pour récupérer le contenu du fichier, la carte mère précise dans la commande la taille de données qu'elle est prête à accepter par requête. Même principe pour les réponses SPI que pour les commandes 0x11. Si vous utilisez Ethernet ou UDP, il faut mettre en place le même dispositif de surveillance de perte de paquets que pour la liste.

* Si la commande SPI est 0x03, la carte mère souhaite envoyer un fichier. Vous devez former les paquets réseau nécessaires pour préparer la réception du fichier précisé dans la suite de la commande SPI. De la même façon que pour la liste, des commandes SPI ultérieures 0x13 doivent être envoyées pour passer les fragements de fichier. Si vous utilisez Ethernet ou UDP, les paquets envoyés pour transmettre les fragments comportent un numéro de séquence. La carte mère termine par un fragment vide pour indiquer que le fichier est totalement transféré. Dans ce dernier cas un paquet particulier doit être envoyé pour indiquer la fin du fichier. Une réponse est requise pour ce paquet, cette réponse peut être un succès (tous les fragments ont été reçus) ou échec. Il convient de répercuter cette réponse en tant que réponse SPI : 0x00 pour succès ou 0x02 en cas d'erreur que ce soit une erreur remontée ou une absence de paquet réponse.

Au niveau de la carte mère vous devez écrire les primitives système permettant de préparer et de réaliser les listes, récupération et envois de fichiers. Ces primitives sont de simples encapsulation des commandes SPI décrites ci-dessus avec attente des réponses SPI pour les commandes de chiffre de poid fort 0x1. Il faut cependant s'assurer, avant chaque requête SPI, que la carte RNDIS est libre en utilisant la commande 0xFF.

Ces primitives sont utilisées par le système d'exploitation pour réaliser les commandes de sauvegarde et de chargement de fichiers. Il est supposé qu'il n'existe qu'une carte réseau par pico-ordinateur avec une ligne de sélection de périphérique SPI fixe.

=== Carte fille réseau "points d'accès de volume" ===

Cette carte est identique, au niveau électronique, à la carte réseau RNDIS. La seule différence réside dans la façon de faire transiter les paquets réseau de la carte vers le PC auquel elle est connectée en USB. Pour cette carte, il vous est proposé de faire ce transfert en utilisant deux points d'accès USB de type volume (bulk), un entrant et un sortant. Cette fois vous n'aurez pas l'aide du noyau Linux pour la création de l'interface réseau. Vous allez devoir écrire votre propre programme PC pour faire le pont entre la carte et une interface réseau virtuelle.

Sous Linux la création d'une interface virtuelle est possible avec la fonction ci-dessous.

int allocateNetworkDevice(char *name,int flags){
struct ifreq ifr;
int fd,err;
char *clonedev = "/dev/net/tun";
/* Open the clone device */
if((fd=open(clonedev,O_RDWR))<0) return fd;
/* Preparation of the struct ifr, of type "struct ifreq" */
memset(&ifr,0,sizeof(ifr));
ifr.ifr_flags=flags; /* IFF_TUN or IFF_TAP, plus maybe IFF_NO_PI */
if(name!=NULL) strncpy(ifr.ifr_name,name,IFNAMSIZ);
/* Try to create the device */
if((err=ioctl(fd,TUNSETIFF,(void *)&ifr))<0){ close(fd); return err; }
/* Write back the name of the * interface to the variable "name" */
if(name!=NULL) strcpy(name,ifr.ifr_name);
return fd;
}

Le descripteur de fichier retourné est utilisable avec <code>read</code> pour récupérer les paquets Ethernet entrants et avec <code>write</code> pour envoyer des paquets sur l'interface. Pour transmettre les paquets à la carte ou lire ceux provenant de la carte vous pouvez utiliser la bibliothèque <code>libusb-1.0</code>.

Pour le reste de la programmation liée à cette carte vous reporter à ce qui est demandé pour la carte réseau RNDIS.

=== Carte fille réseau Ethernet ===

Cette version de la carte réseau se connecte à un commutateur Ethernet et non pas à un PC pour communiquer avec le monde extérieur.

Au niveau électronique une puce Ethernet ENC28J60 (ou supérieur) est supervisée par un microcontrôleur ATMega328p. Toutes les précisions concernant les cartes à base d'ATMega328p s'appliquent (voir par exemple la carte fille clavier "matrice de touches). Vous trouverez la documentation de la puce Ethernet à l'adresse http://ww1.microchip.com/downloads/en/devicedoc/39662c.pdf. Un exemple de programmtion de la puce ENC624J600 est disponible à l'adresse https://github.com/2xs/smews/tree/develop/targets/Arduino_ethernet/drivers. Vous pouvez vous en inspirer pour la programmation de la puce ENC28J60.

La programmation spécifique à cette carte concerne l'envoi des paquets à la puce ENC28J60 et la récupération des paquets en provenance de la puce ENC28J60. Comme pour la liaison RNDIS, trois options s'ouvrent à vous pour l'implémentation de votre pile réseau :

*programmation Ethernet, votre projet sera assez simple à écrire mais l'application sur le PC sera un peu exotique, il vous faudra utiliser la programmation socket en mode RAW ;
* programmation UDP, votre projet sera plus complexe mais l'application sur le PC pourra se faire avec des sockets en mode non connecté standard ;
* programmation TCP, votre projet sera plus complexe; par contre vous pourrez utiliser des applications standard sur le PC (serveur Web ou FTP).

Le reste de la programmation (communication avec la carte mère et ajouts dans le système d'exploitation) est identique à ce qui est décrit pour la carte réseau RNDIS.

=== Carte fille son ===

D'un point de vue électronique la carte n'est pas très compliquée, elle comporte un ATMega328p comme coeur et sa spécificité est un convertisseur numérique vers analogique dit R-2R utilisant un réseau de résistance pour implanter la conversion. Utilisez au moins un DAC sur 8 bits, vous devez pouvoir pousser jusqu'à 12 bits en utilisant pratiquement toutes les sorties disponibles. En sortie du DAC utilisez un montage Darligton pour commander le haut-parleur. N'oubliez pas le connecteur HE10 pour connecter votre carte à une carte mère. Utilisez la ligne de sélection SPI par défaut pour que la carte mère puisse commander votre carte et prévoyez une ligne d'interruption. Enfin il vous faut prévoir un connecteur AVR ISP pour programmer le microcontrôleur.

Le microcontrôleur de la carte fille doit être programmé pour pouvoir jouer des sons déjà enregistrés :
* des variables globales doivent être configurées pour spécifier les caractéristiques des enregistrements à jouer :
** précision d'échantillonnage (8 à 24 bits même si au-delà de 14 bits vous devez abandonner les bits de poids faibles),
** vitesse d'acquisition (vous trouverez la vitesse maximale par essais et erreurs),
** format des enregistrements (vous vous limiterez à un format PCM entier classique avec représentation petit-boutiste) ;
* une fonction permettant d'envoyer les échantillons, à la bonne vitesse, sur le DAC.

Les échantillons sonores sont reçus par le bus SPI préfixés par le code commande 0x02. Les 2 valeurs de configuration, précision sur un octet et vitesse sur quatre octets sont envoyées préfixés par le code commande 0x01.

Au niveau de la carte mère vous devez écrire les primitives système :
* la première primitive correspond au message SPI de code commande 0x01 et passe les paramètres de configuration à la carte fille ;
* la seconde primitive correspond au message SPI de code commande 0x02 et passe les échantillons sonores à jouer à la carte fille, la primitive s'assure auparavent que la carte n'est pas déjà occupée à jouer des échantillons avec la commande SPI 0xFF, en cas de carte occupée le code 0xFF est retourné.

Ces primitives sont utilisées utilisée par le système d'exploitation pour implanter une nouvelle commande <code>PLAY</code> permettant de jouer un fichier WAV :
* l'entête du fichier est récupéré avec la primitive <code>read</code> ;
* l'entête WAV est analysée pour récupérer la fréquence et la précision d'échantillonnage, ces données sont passées à la carte son via la première primitive décrite ci-dessus ;
* le nombre de canaux est récupéré dans l'entête, les echantillons du premier canal sont alors lus grâce à <code>read</code> et envoyés à la carte son en utilisant la seconde primitive ;
* si les échantillons sont envoyés trop vite et donnent lieu à un code d'erreur de la seconde primitive, les mêmes échantillons sont à nouveau envoyés et ainsi de suite ;
* éventuellement, si votre système d'exploitation dispose d'une primitive <code>usleep</code> vous pouvez mettre en place un algorithme d'attente après chaque appel à la primitive, ce temps peut être calculé en fonction de la vitesse de restitution et du nombre d'échantillons envoyés.

= Réalisations des élèves =

{| class="wikitable"
! Numéro du binôme !! Numéro du groupe !! Elèves !! Page
|-
| Binôme 1
| Groupe 1
| Taha Nehari & Martin Chauveliere
| [[SE4Binome2023-1|Binôme 1 2023/2024]]
|-
| Binôme 2
| Groupe 1
| Simon CRUCHET & Amaury BECQUET
| [[SE4Binome2023-2|Binôme 2 2023/2024]]
|-
| Binôme 3
| Groupe 1
| Louis DERYCKERE & Romain DUHR
| [[SE4Binome2023-3|Binôme 3 2023/2024]]
|-
| Binôme 4
| Groupe 1
| Thomas NAVE & Thibault DUYCK
| [[SE4Binome2023-4|Binôme 4 2023/2024]]
|-
| Binôme 5
| Groupe 2
| Stéphane KADER ISSACK & Marion NORMAND
| [[SE4Binome2023-5|Binôme 5 2023/2024]]
|-
| Binôme 6
| Groupe 2
| Dylan Ling
| [[SE4Binome2023-6|Binôme 6 2023/2024]]
|-
| Binôme 7
| Groupe 2
| Louis Wijsman & Adrien Paliferro
| [[SE4Binome2023-7|Binôme 7 2023/2024]]
|-
| Binôme 8
| Groupe 2
| Némo CAZIN & Némo
| [[SE4Binome2023-8|Binôme 8 2023/2024]]
|-
| Binôme 9
| Groupe 3
| Younes BENMBAREK & Youness EL QASTALANI
| [[SE4Binome2023-9|Binôme 9 2023/2024]]
|-
| Binôme 10
| Groupe 3
| Prénom Nom & Prénom Nom
| [[SE4Binome2023-10|Binôme 10 2023/2024]]
|-
| Binôme 11
| Groupe 3
| Prénom Nom & Prénom Nom
| [[SE4Binome2023-11|Binôme 11 2023/2024]]
|-
|}

Pico SE4 2023/2024

2023-09-12T12:24:38Z

Yelqasta : /* Réalisations des élèves */

= Objectif =

Pour l'année académique 2023/2024 nous vous demandons de construire un pico-ordinateur comprenant les éléments suivants :
* un processeur de type microcontrôleur ;
* un clavier ;
* un dispositif d'affichage ;
* un système d'exploitation stocké dans la mémoire flash du microcontrôleur ;
* une mémoire de masse allant au delà de la mémoire flash sus-citée ;
* un dispositif de communication avec l'extérieur.

Pour faire en sorte que tous les éléments puissent communiquer entre eux nous vous demandons d'utiliser un bus série.

= Compétences évaluées =

Les compétences suivantes doivent être acquises durant ce module.
* Savoir comprendre, ou à défaut être actif en séances pour poser les questions pertinentes aux encadrants.
* Savoir produire un travail régulier et documenté durant la totalité de la période.
* Savoir concevoir et réaliser des cartes électroniques fonctionnelles.
* Savoir concevoir et programmer un circuit FPGA en VHDL.
* Savoir structurer et écrire des pilotes pour cartes électroniques.
* Savoir concevoir et implanter des primitives systèmes et un micro-système d'exploitation.

= Organisation du travail =

Vous aurez, comme d'habitude, la lourde tâche de tester ce module de travaux pratiques.

Ce sera d'autant moins facile que nous vous demandons de vous coordonner pour réaliser le pico-ordinateur : un seul exemplaire fonctionnel est attendu par groupes de 4 binômes.

Vous allez donc devoir vous organiser pour que chaque binôme réalise une partie de l'ensemble. Cela dit des tâches identiques sont à réaliser par tous les binômes, ces tâches vous permettront de vous exercer mais aussi de tester vos réalisations spécifiques.

== Matériel fourni ==

[[file:2023_Bouclier_Pico.pdf||thumb|right|400px]]

Pour que chaque binôme puisse avoir un minimum d'autonomie, un matériel de base est fourni :
* un Arduino Uno pour prototyper le coeur d'une carte mère ;
* un bouclier Arduino pour disposer d'une mémoire de masse (carte SD) et de connecteurs vers les cartes filles, voir le schéma et le PCB ci-contre ;
* d'une matrice de LED et d'un afficheur 7-segments tous les deux gérables par SPI pour pouvoir écrire les briques de votre système d'exploitation.

Le projet KiCAD pour le bouclier Arduino est disponible : [[Média:2023_Bouclier_Pico.zip]]

Les projets KiCAD pour connecter les périphériques via un connecteur sont disponibles : [[Média:2023_HE10-periph.zip]]

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

[[file:2023_Bouclier_Pico_PCB.png||thumb|center|300px]]

Vision de la carte partiellement montée. L'accès à la carte SD est fonctionnel.

[[file:2023_Bouclier_Pico_Test.jpg||thumb|center|300px]]

Pour la partie programmation concernant la carte SD vous pouvez vous appuyer sur le projet ci-contre utilisant <code>avr-gcc</code> comme compilateur : [[Fichier:TestSD_avrgcc.zip]].

== Réalisations par binôme ==

Chaque binôme réalise :
* un système d'exploitation basé sur un ordonnanceur ;
* une carte fille FPGA programmée par VHDL, le binôme écrit aussi le code pour que la carte puisse être gérée par le système d'exploitation ;
* une carte mère ou une carte fille à base de microcontrôleur, le binôme écrit aussi le code pour que la carte puisse être gérée par le système d'exploitation, le binôme peut réaliser plusieurs cartes pour maximiser sa note.

== Réalisation par groupe de binômes ==

Par groupe de 4 binômes vous devez réaliser un pico-ordinateur complet :
* une carte mère ;
* une carte fille FPGA/VHDL fonctionnelle et supportée par votre carte mère ;
* au moins 3 cartes filles fonctionnelles et supportées par votre carte mère (clavier, écran, réseau) ;
* vous pouvez ajouter une cinquième carte fille optionnelle de type carte son.

= Cahier des charges =

== Ordonnanceur ==

Vous n'avez pas besoin d'avoir conçu et réalisé des cartes électroniques pour commencer à écrire le système d'exploitation du pico-ordinateur et en particulier l'ordonnanceur sous-jacent.

Le principe est d'utiliser un minuteur du microcontrôleur pour lancer périodiquement une fonction d'interruption que vous allez transformer en ordonnanceur.

Dans un premier temps vous testerez votre ordonnanceur en créant deux tâches statiques pour faire clignoter, avec des périodes différentes, deux LED du bouclier fourni.

Par la suite vous allez complexifier votre ordonnanceur en ajoutant :
* une tâche de lecture de caractère par le port série (stocké en mémoire partagé) ;
* une tâche d'écriture sur le port série (du caractère lu sur le port série) ;
* une tâche d'écriture sur la matrice (du caractère lu sur le port série) ;
* une tâche d'écriture sur l'afficheur 7 segments (du caractère lu sur le port série).

Les deux dernières tâches sont plus compliquées à réaliser dans la mesure où elles utilisent une ressource commune.

== Cartes filles FPGA ==

Les cartes filles FPGA doivent être programmées en VHDL. Tous les binômes doivent implanter en VHDL :
* un contrôleur de bus série SPI ;
* un décodeur des commandes reçues par SPI (commandes sur un octet avec éventuellement des paramètres à suivre) ;
* un contrôleur d'écran VGA affichant le contenu graphique de la RAM de la carte FPGA.

A minima il faut une commande pour insérer un pixel d'une couleur donnée dans la RAM d'affichage.

Vous pouvez aussi ajouter des fonctionnalités supplémentaires à votre carte FPGA :
* mémoire de masse par accès direct à une carte mémoire SD ;
* carte réseau Ethernet en utilisant un module PHY Ethernet.

Pour les fonctionnalités supplémentaires vous devez prévoir des commandes supplémentaire au niveau du décodeur.

== Cartes électroniques ==

Vous devez réaliser deux type de cartes électroniques à base de microcontrôleur : une carte mère et des cartes filles.
La carte FPGA/VHDL décrite dans la section précédente est considérée comme une carte fille.

Les cartes filles sont connectées via un bus série à la carte mère. C'est aussi la carte mère qui alimente les cartes filles.
Enfin la carte mère dispose d'une mémoire permanente pour stocker des fichiers.

Les cartes filles peuvent être de différents types :
* carte fille clavier ;
* carte fille d'affichage ;
* carte fille série (se comporte comme un clavier et comme un dispositif d'affichage) ;
* carte fille réseau ;
* carte fille mémoire de masse (alternative à la mémoire de masse de la carte mère) ;
* carte fille son.

Pour un type donné vous avez le choix entre plusieurs technologies pour réaliser votre carte. Par exemple une carte fille clavier peut être implantée par une matrice de touches ou en utilisant un clavier USB.

== Programmation système ==

Le système d'exploitation du pico-ordinateur doit avoir les fonctionnalités d'un DOS (Disk Operating System), à savoir :
* lecture des commandes tapées par l'utilisateur ;
* téléchargement d'exécutables ou de sources via le dispositif de communication extérieur ;
* sauvegarde et chargement d'exécutables ou de sources via la mémoire de masse ;
* permettre l'affichage de chaînes de caractères ;
* comprend un interpréteur micro-python pour faire tourner les sources ;
* les différentes fonctionnalités sont réalisées sous forme de tâches gérées par un ordonnanceur.

=== Commandes de base ===

Ces commandes sont les commandes les plus simples à implanter :

{| class="wikitable"
! Commande !! Description
|-
| VERSION || Affiche la version du système d'exploitation
|-
| DEVICES || Affiche la liste des cartes filles connectées
|-
| ECHO || Affiche les arguments de la commande
|}

=== Commandes liées aux processus ===

{| class="wikitable"
! Commande !! Description
|-
| PS || Liste les processus disponibles et leur état
|-
| SLEEP || Met un processus en sommeil
|-
| WAKE || Relance un processus dormant
|-
| EXEC || Création d'un processus à partir d'un fichier exécutable
|}

La commande EXEC est complexe à réaliser, elle est optionnelle pour l'année 2023/2024.

=== Commandes liées au système de fichiers ===

Commandes pour gérer le système de fichiers :

{| class="wikitable"
! Commande !! Description
|-
| FORMAT || Formate le système de fichiers
|-
| LIST || Affiche les fichiers du répertoire principal
|-
| CREATE || Création d'un fichier avec l'entrée standard
|-
| TYPE || Affiche le contenu d'un fichier
|-
| COPY || Copie un fichier
|-
| RENAME || Renomme un fichier
|}

=== Commandes liées au réseau ===

{| class="wikitable"
! Commande !! Description
|-
| REMOTE || Liste les fichiers disponibles sur le réseau
|-
| GET || Télécharge un fichier en provenance du réseau
|-
| PUT || Sauve un fichier sur le réseau
|}

== Programmation des pilotes ==

La programmation c'est aussi l'écriture des sous-systèmes ou des pilotes liés à chaque cartes :
* pour la carte mère, il faut écrire un sous-système de gestion de fichiers ;
* pour la carte fille comportant une matrice de touches, il faut écrire le pilote identifiant les touches actionnées et gérant l'envoi de ces touches à la carte mère ;
* pour la carte fille gérant un clavier USB, il faut utiliser un projet LUFA pour scanner régulièrement le clavier USB et envoyer d'éventuels événements à la carte mère ;
* pour la carte fille gérant un écran LCD, il faut écrire le pilote capable de gérer l'écran et la partie récupérant les données de la carte mère ;
* pour la carte fille gérant une clé USB, il faut utiliser un projet LUFA pour l'accès à la clé et écrire un sous-système de gestion de fichiers ;
* la carte fille gérant une connexion série ne nécessite qu'un modeste pilote de communication avec la carte mère ;
* pour la carte fille permettant une connexion avec le monde extérieur via de simples points d'accès USB de volume (EP Bulk), il faut écrire le pilote pour communication avec la carte mère mais aussi le programme sur le PC permettant la réception ou l'envoi de fichiers ;
* pour la carte fille permettant une connexion Ethernet au dessus d'USB (RNDIS), il faut écrire une micro-pile réseau capable de récupérer et d'envoyer des fichiers au travers de paquets Ethernet mais aussi le programme sur le PC cible capable de comprendre ces paquets Ethernet ;
* pour la carte fille incluant une puce Ethernet, il faut implanter la micro-pile réseau et le programme évoquée ci-dessus mais aussi le pilote capable de gérer la puce Ethernet ;
* pour la carte fille son, il faut écrire la partie permettant de récupérer les échantillons, les copier en mémoire, et les jouer à la vitesse d'échantillonnage préalablement transmise.

= Spécifications techniques =

== Ordonnanceur ==

Pour réaliser votre ordonnanceur commencez par programmer le minuteur 1 de l'ATMega328p de sorte à ce qu'il génère une interruption toutes
les 20ms. L'interruption va déclencher une fonction de gestion d'interruption (ISR pour Interrupt Service Routine). Vous utiliserez une ISR nue pour éviter les interférences du compilateur sur la pile d'exécution :
ISR(TIMER1_COMPA_vect,ISR_NAKED)
{
/* Sauvegarde du contexte de la tâche interrompue */
...
/* Appel à l'ordonnanceur */
scheduler();
/* Récupération du contexte de la tâche ré-activée */
...
asm volatile ( "reti" );
}
Vous constatez qu'il vous reste à écrire, dans l'ISR, le code pour sauvegarder et récupérer le contexte d'exécution d'une tâche. Pour cela réfléchissez aux éléments d'un microcontrôleur qui sont nécessaires pour l'exécution d'un programme puis réfléchissez à une méthode pour sauver l'état de ces éléments.

Au moins dans un premier temps, les tâches seront définies de façon statique. Toutes les tâches doivent être définies dans un tableau global, seront lancées dès le démarrage du microcontrôleur et ne se termineront que lorsque le microcontrôleur sera arrêté ou relancé. Une tâche est à définir par une structure dont un des champs doit être la fonction réalisant la tâche. A vous de définir les autres champs.

Avant de démarrer l'ordonnanceur, il faut prendre soin à ce que la récupération du contexte dans l'ISR fonctionne alors que les tâches n'auront pas encore été lancées. Il faut donc une fonction permettant d'initialiser le contexte pour chaque tâche.

== Cartes électroniques à microcontrôleur ==

Le bus série préconisé pour la communication entre la carte mère et les cartes filles est un bus SPI. Au niveau physique, les connexions entre cartes mères et cartes filles doivent être réalisées via des connecteurs HE-10 à 8 broches :
* 2 broches pour l'alimentation ;
* 3 broches pour les signaux SPI (MISO, MOSI, SCK) ;
* 1 broche pour le CS (Chip Select) ;-
* 1 broche pour une éventuelle ligne d'interruption ;
* 1 broche pour une eventuelle réinitialisation de la carte (Reset).

Il est conseillé d'organiser les broches sur les connecteurs HE-10 sur le modèle du bouclier Arduino fourni.

La carte mère est constituée autour d'un ATMega328p et d'une puce mémoire de type AT45DB641E de 8 Mo. Il faut réflechir à l'alimentation sachant que :
* l'alimentation de la carte mère doit être suffisante pour alimenter les cartes filles ;
* l'alimentation du microcontrôleur doit être compatible avec l'alimentation de la puce mémoire sauf à prévoir une conversion de niveaux logiques entre les deux puces ;
* les cartes filles d'un même pico-ordinateur doivent être alimentées avec la même tension.

Voici quelques exemples d'architectures de cartes filles :
* une carte fille SPI avec un ATMega328p et une matrice de touches ;
* une carte fille SPI avec un AT90USB647 pour connexion à un clavier USB ou une clef USB ;
* une carte fille SPI avec un ATMega328p et un écran LCD 2 lignes HD44780 ;
* une carte fille SPI avec un ATMega16u2 pour une connexion série USB ;
* une carte fille SPI avec un ATMega328p et un DAC R-2R comme carte son ;
* une carte fille SPI avec un ATMega16u2 (ou supérieur) pour une connexion réseau (périphérique USB générique EP bulk ou périphérique USB RNDIS) ;
* une carte fille SPI avec un ATMega328p et un ENC28J60 pour une connexion Ethernet 10Mb/s.

Toutes les cartes doivent permettre un accès au port série de leur microcontrôleur pour un déverminage via un FTDI. Vous devez aussi ajouter des points de test pour les lignes importantes : lignes du bus SPI, horloge, alimentations, etc.

Toutes les cartes filles répondent à la commande SPI constituée de l'octet de commande 0x00 et de l'octet de donnée 0x00. Le résultat se lit sur le second octet de réponse et détermine le type de la carte fille. Le chiffre de poid fort de la réponse est un code magique : 0xa. Le chiffre de poid faible est donné par le tableau ci-dessous :
{| class="wikitable"
! Chiffre !! Type de carte
|-
| 0x1 || Clavier
|-
| 0x2 || Affichage
|-
| 0x4 || Réseau
|-
| 0x8 || Carte son
|}

Il est bon aussi de prévoir que les cartes filles puissent répondre à une commande SPI permettant de savoir si elles sont occupées ou non. L'octet de commande serait 0xFF et l'octet de donnée 0xFF. En cas de succès les deux octets de réponse sont à 0x55. Les cartes filles doivent prendre soin d'initialiser leur réponse SPI à autre chose que 0x55 lorsqu'elles se lancent dans un traitement autre qu'une écoute SPI.

== Electronique et programmation système ==

=== Carte mère ===

La carte mère doit comporter un microcontrôleur ATMega328p, une puce mémoire AT45DB641E et 5 connecteurs HE10 pour connecter une carte fille FPGA et 4 cartes filles à microcontrôleur.

Vous avez aussi quelques points à approfondir.
# La source d'alimentation de votre pico-ordinateur, le plus simple semble être un connecteur USB pour utiliser soit un PC soit une batterie comme source ;
# La tension d'alimentation du microcontrôleur et des cartes filles :
#* soit vous optez pour du 5V auquel cas il faut prévoir un régulateur de tension pour la puce mémoire et une adaptation des niveaux logiques pour cette même puce (voir le schéma des boucliers Arduino),
#* soit vous partez sur du 3.3V et vos cartes filles doivent tourner en 3.3V, vu que vous aurez probablement un adaptateur 5V il faut quand même prévoir un régulateur 3.3V assez costaud sur la carte mère, de plus vous ne pouvez pas dépasser 8Mhz comme horloge ;
# La méthode de programmation de la carte mère :
#* soit vous programmez le microcontrôleur via un connecteur AVR ISP, un programmateur et l'utilitaire <code>avrdude</code> ;
#* soit vous ajoutez une puce pour réaliser un pont USB vers série vous pourrez alors programmer le microcontrôleur avec <code>dfu-programmer</code>, attention il faut tout de même prévoir des connecteurs AVR ISP pour charger l'amorceur sur l'ATMega328p et l'éventuel ATMega8u2 (vous utilisez cette puce pour l'USB/série plutôt qu'une puce FTDI).

Du coté programmation vous êtes chargés d'écrire les fonctions d'accès à la mémoire, des primitives systèmes implantant un micro-système de fichiers et des primitives de communication via le bus SPI.

Les fonctions de base d'accès à la mémoire sont facilement trouvables, par exemple sur les sites du bureau d'études systèmes embarqués des PeiP.

Concernant le micro-système de fichiers, les fonctionnalités suivantes doivent être implantées :

* le système de fichiers doit résider dans la mémoire de 8 Mo, les accès à la mémoire se font par blocs de 256 octets ;
* l'accès au système de fichiers se fait par des primitives système ;
* le micro-système de fichiers ne comporte qu'un répertoire : le répertoire principal, ce dernier peut comporter au maximum 64 fichiers, un fichier est caractérisé par un nom de 16 caractères au maximum, sa taille et ses blocs de données, un fichier est décrit par un maximum de 16 blocs de données ;
* le superbloc du système de fichiers comprend, en plus de la description du répertoire racine, une carte bit à bit des blocs de données libres, cette carte nécessite 16 blocs ;
* les différentes primitives à implanter sont :
** <code>append</code> pour créer un fichier si non existant et ajouter des données en fin de fichier, les paramètres sont le nom du fichier, les données à ajouter et la taille des données,
** <code>read</code> pour lire des données dans un fichier, les paramètres sont le nom du fichier, le tableau dans lequel stocker les données, la taille du tableau et le déplacement par rapport au début du fichier,
** <code>remove</code> pour détruire un fichier, le seul paramètre est le nom du fichier,
** <code>rename</code> pour renommer un fichier, les paramètres sont l'ancien et le nouveau noms du fichier,
** <code>copy</code> pour copier un fichier, les paramètres sont le nom du fichier original et le nom de la copie.

Les primitives pour le bus SPI doivent être :
* une fonction d'initialisation avec le mode SPI désiré et la vitesse d'horloge souhaitée ;
* une primitive pour envoyer quelques octets via le bus SPI :
** les paramètres de la primitive sont le tableau des octets à envoyer, le tableau des octets à recevoir, le nombre d'octets à envoyer et la spécification de la sortie CS de sélection du périphérique SPI,
** la primitive stocke l'opération dans une file et effectue l'envoi dès que le bus est libre,
** si la file est pleine la primitive peut retourner un code d'erreur sinon la primitive retourne l'identifiant unique de l'opération,
** les octets de réponse du périphérique sont stockés dans le tableau des octets à recevoir, si le pointeur est nul les réponses ne sont pas stockées ;
* une primitive pour attendre la fin d'un envoi SPI, il faut donner en unique paramètre l'identifiant de l'opération, l'attente s'effectue en mettant le processus appelant en mode sommeil et en le réveillant dès que l'opération est effectuée.

Précisons que les tableaux stockés dans la file d'attente (requête et réponse SPI) le sont sous la forme de pointeurs. Ces pointeurs peuvent être librérés une fois l'opération effectuée.

=== Carte fille clavier "matrice de touches" ===

La réalisation de la carte est simple, il s'agit de scanner une matrice de touches à l'aide d'un ATMega328p. N'oubliez pas le connecteur HE10 pour la connexion de cette carte fille à une carte mère. Sur le connecteur HE10 il faut prévoir à la fois la ligne de sélection SPI (utilisez la broche SS par défaut sur votre carte) et une ligne pour générer une interruption sur la carte mère. Vous devez faire avec l'alimentation fournie par la carte mère. Regardez aussi la problèmatique sur la programmation décrite dans la section sur la carte mère.

Du coté programmation, c'est plus compliqué, vous êtes déjà chargés d'écrire la fonction de scan des touches :
* le scan des touches consiste juste à passer les lignes de la matrice en sorties, les colonnes en entrées avec résistance de charge et de rentrer dans une boucle pour passer une sortie à GND tandis que les autres restent à VCC, il suffit alors de consulter les entrées pour voir si une touche est appuyée (ou plusieurs) ;
* si une touche est appuyée la touche est stockée dans un tampon et la ligne d'interruption est activée ;
* si une requête SPI de code commande 0x01 est reçue, le nombre de touches dans le tampon est envoyé suivi des touches elles-mêmes.

Ensuite, au niveau de la carte mère vous devez écrire la primitive gérant les claviers. Cette primitive prend en paramètre la ligne de sélection SPI du clavier ciblé et un tampon pour stocker les codes des touches. La taille du tampon est aussi passée en paramètre. La primitive prépare une transmission SPI constituée du seul octet de valeur 0x01 en prenant soin de préciser un tableau pour stocker d'éventuelles touches. Attention, la transmission SPI est constituée de l'octet 0x01 mais aussi d'autant d'octets de valeurs indéterminées qu'il est attendu d'octets dans la réponse SPI. La primitive se met alors en attente de la réponse.

Au niveau du système d'exploitation les comportements suivants sont à implanter :
* à l'initialisation de la carte mère les périphériques SPI doivent être contactés pour déterminer lequels sont des claviers, des commandes SPI 0x00 sont donc envoyées avec attente des réponses SPI ;
* le processus SHELL toujours présent dans le système d'exploitation doit avoir le comportement suivant :
** si une interruption est reçue qui correspond à un périphérique clavier, le SHELL doit utiliser la primitive de lecture clavier pour obtenir la ou les touches appuyées ;
** dans un premier temps, les caractères reçus sont affichés en utilisant la primitive d'affichage (echo) ;
** à terme les lignes de caractères reçues sont analysées pour en extraire des commandes et les exécuter.

=== Carte fille clavier "USB" ===

Votre carte électronique doit tourner autour d'un AT90USB647 (ou supérieur). Ce microcontrôleur peut être programmé, en utilisant la bibliothèque LUFA, comme hôte USB. Il est donc possible de gérer, de cette façon un clavier USB et de faire interface avec la carte mère. Le schéma de la carte est très semblable à celui d'une carte comportant un ATMega16u2. Vous pouvez vous appuyer sur ce [https://wiki-se.plil.fr/mediawiki/index.php/SE4_2022/2023_EC5 projet keylogger]. Le plus simple est de programmer le microcontrôleur en utilisant l'utilitaire <code>dfu-programmer</code>, pour cela il faut prévoir, en plus d'un connecteur USB A femelle pour le clavier, un connecteur USB mâle pour la programmation.

La programmation pour la gestion du clavier USB doit se reposer sur la démonstration <code>KeyboardHost</code> de la bibliothèque LUFA. La conversion des modificateurs et des codes de touches en caractères ASCII sont à votre charge.

Pour le reste de la programmation voir la section sur la carte fille "matrice de touches".

=== Carte fille écran LCD ===

Cette carte comporte un ATMega328p et un écran LCD à base de contrôleur HD44780. L'écran LCD nécessite un potentiomètre pour régler la luminosité des cristaux liquides. N'oubliez pas le connecteur HE10 pour la connexion de cette carte fille à une carte mère. Sur le connecteur HE10 il faut prévoir une ligne de sélection SPI. Aucune ligne d'interruption n'est nécessaire pour cette carte. Enfin il vous faut prévoir un connecteur AVR ISP pour programmer le microcontrôleur.

Le microcontrôleur de la carte fille doit être programmé pour gérer le contrôleur HD44780 ou compatible :
* les écrans avec 1, 2, 3 ou 4 lignes doivent être gérés ;
* les caractères ASCII doivent être affichés sur l'écran ;
* les caractères spéciaux <code>\n</code> et <code>\r</code> doivent être pris en compte pour le saut de ligne et le retour chariot ;
* les codes VT100 doivent être pris en compte, en particulier pour le déplacement du curseur doivent être pris en compte ;
* le contrôleur HD44780 ou compatible doit être configuré en mode défilement automatique.

Les caractères à afficher ou spéciaux (y compris les séquences VT100) sont reçus par le bus SPI par la carte fille préfixés par le code commande 0x01.

Au niveau de la carte mère vous devez écrire la primitive système. Cette primitive prend en paramètre la ligne de sélection SPI de l'écran ciblé et la chaîne des caractères à envoyer. La primitive prépare une transmission SPI constituée de l'octet de commande 0x01 et des octets correspondant aux caractères.

Il ne faut pas demander un affichage si un autre affichage est en cours. C'est possible à réaliser avec la ligne prévue pour une interruption. La carte fille peut mettre cette ligne en état haut quand un affichage est en cours. Du coup la primitive peut se mettre en attente sur un état bas avant d'envoyer la requête SPI. C'est aussi possible de lancer des commandes 0xFF sur la carte jusqu'à obtenir les octets de réponse indiquant que la carte est libre.

Cette primitive est utilisée par le système d'exploitation pour réaliser l'écho des commandes dans le SHELL et aussi par toutes les commandes qui nécessitent un affichage. Tous les écrans doivent être sollicités lors des affichages, il faut donc que le système d'exploitation scanne les périphériques SPI pour trouver les écrans comme il le fait pour les claviers.

=== Carte fille réseau RNDIS ===

Le but de cette carte est de permettre au pico-ordinateur de converser avec l'extérieur. Une carte RNDIS permet de faire transister des paquets Ethernet au dessus d'une liaison USB. La carte n'a besoin que d'un microcontrôleur avec capacités USB pour fonctionner. Vous pouvez utiliser un
ATMega16u2, un ATMega32u4 ou un AT90USB suivant la taille mémoire dont vous souhaitez disposer. Gardez en mémoire qu'un paquet Ethernet peut comporter jusqu'à 1500 octets. La programmation du microcontrôleur se fera par DFU USB. Il est notable que la programmation du microcontrôleur et la communication vers l'extérieur se fait par le même connecteur USB.

La communication se fait forcément via le PC auquel la carte fille est connectée par USB. Cela dit si ce PC est connecté en réseau, les fichiers auxquels le pico-ordinateur accède peuvent se trouver sur un autre PC. Si votre carte fille est correctement programmée comme carte RNDIS USB, le PC sous Linux va automatiquement créer une interface réseau <code>usb0</code>. A vous de la démarrer avec la commande <code>ip link set usb0 up</code> ou une commande du type <code>ip address add @IP/masque dev usb0</code>.

La base de la programmation de cette carte est la démonstration LUFA RNDIS. Des versions de cette démonstration incluent une implantation de pile TCP/IP. A vous de voir à quel niveau vous souhaitez que votre carte réseau opère :
* si vous visez Ethernet, votre projet LUFA sera assez simple à écrire mais l'application sur le PC sera un peu exotique, il vous faudra utiliser la programmation socket en mode RAW ;
* si vous visez UDP, votre projet LUFA sera plus complexe mais l'application sur le PC pourra se faire avec des sockets en mode non connecté standard ;
* si vous visez TCP, votre projet LUFA sera complexe et nécessitera un microcontrôleur avec pas mal de mémoire, par contre vous pourrez utiliser des applications standard sur le PC (serveur Web ou FTP).

Au niveau de la carte, en plus de votre pile réseau vous devez écrire les fonctions permettant de lister des fichiers distants, de les recevoir et d'en envoyer :
* Si la commande SPI est 0x01, la carte mère vous demande de lister les fichiers distants, vous devez donc former les paquets réseau nécessaires pour envoyer la demande, la commande SPI peut comporter un argument supplémentaire pour préciser la localisation des fichiers. A la suite d'une commande 0x01, la carte mère doit envoyer des commandes 0x11 pour récupérer tous les noms de fichiers, idéalement un nom par commande 0x11 pour ne pas déborder la mémoire du microcontrôleur. Si le fichier n'est pas le dernier la réponse SPI est 0x01 sinon 0x00. Si vous utilisez Ethernet ou UDP, il faut prévoir un délai maximal pour la réception des paquets de sorte à ne pas bloquer la commande. En cas de non réception de paquet, il faut retourner un code SPI d'erreur, par exemple 0x02.

* Si la commande SPI est 0x02, la carte mère souhaite récupérer un fichier. Vous devez former les paquets réseau nécessaires pour demander le fichier précisé dans la suite de la commande SPI. De la même façon que pour la liste, des commandes SPI ultérieures 0x12 doivent être envoyées pour récupérer le contenu du fichier, la carte mère précise dans la commande la taille de données qu'elle est prête à accepter par requête. Même principe pour les réponses SPI que pour les commandes 0x11. Si vous utilisez Ethernet ou UDP, il faut mettre en place le même dispositif de surveillance de perte de paquets que pour la liste.

* Si la commande SPI est 0x03, la carte mère souhaite envoyer un fichier. Vous devez former les paquets réseau nécessaires pour préparer la réception du fichier précisé dans la suite de la commande SPI. De la même façon que pour la liste, des commandes SPI ultérieures 0x13 doivent être envoyées pour passer les fragements de fichier. Si vous utilisez Ethernet ou UDP, les paquets envoyés pour transmettre les fragments comportent un numéro de séquence. La carte mère termine par un fragment vide pour indiquer que le fichier est totalement transféré. Dans ce dernier cas un paquet particulier doit être envoyé pour indiquer la fin du fichier. Une réponse est requise pour ce paquet, cette réponse peut être un succès (tous les fragments ont été reçus) ou échec. Il convient de répercuter cette réponse en tant que réponse SPI : 0x00 pour succès ou 0x02 en cas d'erreur que ce soit une erreur remontée ou une absence de paquet réponse.

Au niveau de la carte mère vous devez écrire les primitives système permettant de préparer et de réaliser les listes, récupération et envois de fichiers. Ces primitives sont de simples encapsulation des commandes SPI décrites ci-dessus avec attente des réponses SPI pour les commandes de chiffre de poid fort 0x1. Il faut cependant s'assurer, avant chaque requête SPI, que la carte RNDIS est libre en utilisant la commande 0xFF.

Ces primitives sont utilisées par le système d'exploitation pour réaliser les commandes de sauvegarde et de chargement de fichiers. Il est supposé qu'il n'existe qu'une carte réseau par pico-ordinateur avec une ligne de sélection de périphérique SPI fixe.

=== Carte fille réseau "points d'accès de volume" ===

Cette carte est identique, au niveau électronique, à la carte réseau RNDIS. La seule différence réside dans la façon de faire transiter les paquets réseau de la carte vers le PC auquel elle est connectée en USB. Pour cette carte, il vous est proposé de faire ce transfert en utilisant deux points d'accès USB de type volume (bulk), un entrant et un sortant. Cette fois vous n'aurez pas l'aide du noyau Linux pour la création de l'interface réseau. Vous allez devoir écrire votre propre programme PC pour faire le pont entre la carte et une interface réseau virtuelle.

Sous Linux la création d'une interface virtuelle est possible avec la fonction ci-dessous.

int allocateNetworkDevice(char *name,int flags){
struct ifreq ifr;
int fd,err;
char *clonedev = "/dev/net/tun";
/* Open the clone device */
if((fd=open(clonedev,O_RDWR))<0) return fd;
/* Preparation of the struct ifr, of type "struct ifreq" */
memset(&ifr,0,sizeof(ifr));
ifr.ifr_flags=flags; /* IFF_TUN or IFF_TAP, plus maybe IFF_NO_PI */
if(name!=NULL) strncpy(ifr.ifr_name,name,IFNAMSIZ);
/* Try to create the device */
if((err=ioctl(fd,TUNSETIFF,(void *)&ifr))<0){ close(fd); return err; }
/* Write back the name of the * interface to the variable "name" */
if(name!=NULL) strcpy(name,ifr.ifr_name);
return fd;
}

Le descripteur de fichier retourné est utilisable avec <code>read</code> pour récupérer les paquets Ethernet entrants et avec <code>write</code> pour envoyer des paquets sur l'interface. Pour transmettre les paquets à la carte ou lire ceux provenant de la carte vous pouvez utiliser la bibliothèque <code>libusb-1.0</code>.

Pour le reste de la programmation liée à cette carte vous reporter à ce qui est demandé pour la carte réseau RNDIS.

=== Carte fille réseau Ethernet ===

Cette version de la carte réseau se connecte à un commutateur Ethernet et non pas à un PC pour communiquer avec le monde extérieur.

Au niveau électronique une puce Ethernet ENC28J60 (ou supérieur) est supervisée par un microcontrôleur ATMega328p. Toutes les précisions concernant les cartes à base d'ATMega328p s'appliquent (voir par exemple la carte fille clavier "matrice de touches). Vous trouverez la documentation de la puce Ethernet à l'adresse http://ww1.microchip.com/downloads/en/devicedoc/39662c.pdf. Un exemple de programmtion de la puce ENC624J600 est disponible à l'adresse https://github.com/2xs/smews/tree/develop/targets/Arduino_ethernet/drivers. Vous pouvez vous en inspirer pour la programmation de la puce ENC28J60.

La programmation spécifique à cette carte concerne l'envoi des paquets à la puce ENC28J60 et la récupération des paquets en provenance de la puce ENC28J60. Comme pour la liaison RNDIS, trois options s'ouvrent à vous pour l'implémentation de votre pile réseau :

*programmation Ethernet, votre projet sera assez simple à écrire mais l'application sur le PC sera un peu exotique, il vous faudra utiliser la programmation socket en mode RAW ;
* programmation UDP, votre projet sera plus complexe mais l'application sur le PC pourra se faire avec des sockets en mode non connecté standard ;
* programmation TCP, votre projet sera plus complexe; par contre vous pourrez utiliser des applications standard sur le PC (serveur Web ou FTP).

Le reste de la programmation (communication avec la carte mère et ajouts dans le système d'exploitation) est identique à ce qui est décrit pour la carte réseau RNDIS.

=== Carte fille son ===

D'un point de vue électronique la carte n'est pas très compliquée, elle comporte un ATMega328p comme coeur et sa spécificité est un convertisseur numérique vers analogique dit R-2R utilisant un réseau de résistance pour implanter la conversion. Utilisez au moins un DAC sur 8 bits, vous devez pouvoir pousser jusqu'à 12 bits en utilisant pratiquement toutes les sorties disponibles. En sortie du DAC utilisez un montage Darligton pour commander le haut-parleur. N'oubliez pas le connecteur HE10 pour connecter votre carte à une carte mère. Utilisez la ligne de sélection SPI par défaut pour que la carte mère puisse commander votre carte et prévoyez une ligne d'interruption. Enfin il vous faut prévoir un connecteur AVR ISP pour programmer le microcontrôleur.

Le microcontrôleur de la carte fille doit être programmé pour pouvoir jouer des sons déjà enregistrés :
* des variables globales doivent être configurées pour spécifier les caractéristiques des enregistrements à jouer :
** précision d'échantillonnage (8 à 24 bits même si au-delà de 14 bits vous devez abandonner les bits de poids faibles),
** vitesse d'acquisition (vous trouverez la vitesse maximale par essais et erreurs),
** format des enregistrements (vous vous limiterez à un format PCM entier classique avec représentation petit-boutiste) ;
* une fonction permettant d'envoyer les échantillons, à la bonne vitesse, sur le DAC.

Les échantillons sonores sont reçus par le bus SPI préfixés par le code commande 0x02. Les 2 valeurs de configuration, précision sur un octet et vitesse sur quatre octets sont envoyées préfixés par le code commande 0x01.

Au niveau de la carte mère vous devez écrire les primitives système :
* la première primitive correspond au message SPI de code commande 0x01 et passe les paramètres de configuration à la carte fille ;
* la seconde primitive correspond au message SPI de code commande 0x02 et passe les échantillons sonores à jouer à la carte fille, la primitive s'assure auparavent que la carte n'est pas déjà occupée à jouer des échantillons avec la commande SPI 0xFF, en cas de carte occupée le code 0xFF est retourné.

Ces primitives sont utilisées utilisée par le système d'exploitation pour implanter une nouvelle commande <code>PLAY</code> permettant de jouer un fichier WAV :
* l'entête du fichier est récupéré avec la primitive <code>read</code> ;
* l'entête WAV est analysée pour récupérer la fréquence et la précision d'échantillonnage, ces données sont passées à la carte son via la première primitive décrite ci-dessus ;
* le nombre de canaux est récupéré dans l'entête, les echantillons du premier canal sont alors lus grâce à <code>read</code> et envoyés à la carte son en utilisant la seconde primitive ;
* si les échantillons sont envoyés trop vite et donnent lieu à un code d'erreur de la seconde primitive, les mêmes échantillons sont à nouveau envoyés et ainsi de suite ;
* éventuellement, si votre système d'exploitation dispose d'une primitive <code>usleep</code> vous pouvez mettre en place un algorithme d'attente après chaque appel à la primitive, ce temps peut être calculé en fonction de la vitesse de restitution et du nombre d'échantillons envoyés.

= Réalisations des élèves =

{| class="wikitable"
! Numéro du binôme !! Numéro du groupe !! Elèves !! Page
|-
| Binôme 1
| Groupe 1
| Taha Nehari & Martin Chauveliere
| [[SE4Binome2023-1|Binôme 1 2023/2024]]
|-
| Binôme 2
| Groupe 1
| Simon CRUCHET & Amaury BECQUET
| [[SE4Binome2023-2|Binôme 2 2023/2024]]
|-
| Binôme 3
| Groupe 1
| Louis DERYCKERE & Romain DUHR
| [[SE4Binome2023-3|Binôme 3 2023/2024]]
|-
| Binôme 4
| Groupe 1
| Prénom Nom & Prénom Nom
| [[SE4Binome2023-4|Binôme 4 2023/2024]]
|-
| Binôme 5
| Groupe 2
| Stéphane Kader Issack - Marion Normand
| [[SE4Binome2023-5|Binôme 5 2023/2024]]
|-
| Binôme 6
| Groupe 2
| Prénom Nom & Prénom Nom
| [[SE4Binome2023-6|Binôme 6 2023/2024]]
|-
| Binôme 7
| Groupe 2
| Younes BENMBAREK & Youness EL QASTALANI
| [[SE4Binome2023-7|Binôme 7 2023/2024]]
|-
| Binôme 8
| Groupe 2
| Prénom Nom & Prénom Nom
| [[SE4Binome2023-8|Binôme 8 2023/2024]]
|-
| Binôme 9
| Groupe 3
| Prénom Nom & Prénom Nom
| [[SE4Binome2023-9|Binôme 9 2023/2024]]
|-
| Binôme 10
| Groupe 3
| Prénom Nom & Prénom Nom
| [[SE4Binome2023-10|Binôme 10 2023/2024]]
|-
| Binôme 11
| Groupe 3
| Prénom Nom & Prénom Nom
| [[SE4Binome2023-11|Binôme 11 2023/2024]]
|-
|}

SE3Binome2022-5

2023-06-04T16:03:10Z

Yelqasta : /* Visual 3D */

== '''<big>Présentation du projet</big>''' ==

=== '''<big>Objectif</big>''' ===
Concevoir un modèle de voiture 1:43 équipée d'un microcontrôleur ATMega16u2 permettant de commander la voiture en se basant sur un programme. Nous avons choisi de rajouter une option de suivi d'une ligne droite, ceci se fera à l'aide d'un capteur QRE1113gr.

=== '''<big>Composants</big>''' ===
les composants à utiliser dans notre projet sont les suivants :

* Un microcontrôleur ATMega16u2
* Un capteur QRE1113gr
* Un mini-moteur à courant continu
* Un pilote du mini-moteur à courant continu (DRV8210DRLR)
* Un micro-moteur glissière pas à pas
* Une batterie LiPo
* Une puce de contrôle de charge de la batterie (MAX1811)
* Des leds pour simuler le système d'éclairage
* Des résistances
* Des capacités
* Un quartz
* Un port USB
*Des diodes
*Un AVR-ISP 6
*Des connecteurs

=== '''<big>Caractéristiques et limites de notre système</big>''' ===

==== caractéristiques ====
Pour comprendre le fonctionnement de suivi de ligne souhaité, il faut d'abord comprendre le fonctionnement du capteur QRE. C'est un capteur de réflexion infrarouge, il est utilisé pour détecter la présence ou l'absence d'objets réfléchissants à proximité. Il se compose d'une LED infrarouge émettant de la lumière infrarouge et d'un phototransistor qui mesure la quantité de lumière réfléchie. Lorsqu'un objet se trouve devant le capteur, il réfléchit la lumière infrarouge émise par la LED vers le phototransistor. Le phototransistor détecte cette lumière réfléchie et génère un courant proportionnel à son intensité. La valeur mesurée par le capteur dépend de la quantité de lumière infrarouge réfléchie par l'objet. Si l'objet est réfléchissant et renvoie une grande quantité de lumière infrarouge, le phototransistor générera un courant plus élevé, ce qui se traduira par une valeur positive lorsqu'elle est lue par le microcontrôleur. En revanche, si aucun objet réfléchissant n'est présent devant le capteur, la quantité de lumière infrarouge réfléchie sera faible. Par conséquent, le phototransistor générera un courant plus faible ou nul, ce qui se traduira par une valeur de capteur égale à zéro lorsqu'elle est lue par le microcontrôleur.

==== Limites ====
Les composants cités ci-dessus étaient soudés et utilisés dans notre carte, sauf la batterie et sa puce de contrôle, les diodes, l'AVR-ISP et les connecteurs.

Pour réinitialiser le microprocesseur afin de mettre un nouveau code, il faut à chaque fois utiliser un fil entre la masse et la broche de reset du AVR-ISP. Le rajout d'un bouton aurait était mieux.

Lors du routage de la carte, nous n'avons pas fait attention que le capteur doit être placé en bas, afin de détecter la ligne.

Après avoir fini le code pour tester le mini-moteur dc, nous nous rendons compte que le microprocessur n'est plus détectable en utilisant la commande lsusb. Nous avons vérifié les connections, essayé de changer le port usb mais sans résultat (pourtant que les leds et le capteur marchait bien). Nous avons alors tester le code sur la carte du groupe 2 en ajustant un peu la structure et en supprimant les parties correspondantes au capteur.

=== '''<big>Avancement du projet</big>''' ===

==== le 14/02 : ====
- Compréhension de l'idée directrice du projet

- Recherche de l'option à rajouter

==== le 28/02 : ====
- Début de conception de la schématique

==== le 21/03 : ====
- début du rajout des empreintes des composants

==== le 07/04 : ====
- Fin de la schématique

==== le 13/04 : ====
- Fin du routage de la carte

- Envoi du modèle aux enseignants pour le valider et commander la carte

==== le 02/05: ====
- Réception de la carte

- Soudure de quelques résistances et capacités

==== le 09/05: ====
- Les composants suivants sont déjà soudés par l'enseignant : ATMega16u2, le quartz

- Rajout des leds et des résistances restantes

- Début du code pour tester les leds

==== le 16/05: ====
- Fin du code pour tester les leds

- Réorganisation de la schématique

==== le 23/05: ====
- Soudure du capteur

- Implémentation du code pour tester le capteur

- Soudure du mini-moteur dc

==== le 29/05: ====
- Soudure du micro-moteur pas à pas

- Implémentation du code pour tester le mini-moteur dc

==== le 03/06: ====
- Test du code de moteur sur la carte du groupe 2

=== '''<big>GIT</big>''' ===
le lien de notre archive GIT : https://archives.plil.fr/yelqasta/pse-g5.git

== '''Conception de la carte électronique''' ==

=== Composants et empreintes créés ===
nous avons créer le symbole du pilote du moteur DC via Kicad :
[[Fichier:Driver.png|vignette|250x250px|centré|Symbole du pilote DRV8210DRLR]]

Après avoir mesurer les dimensions du mini-moteur continu on a pu créer l'empreinte suivante :
[[Fichier:Dc moteur.png|centré|vignette|Empreinte du mini-moteur dc]]

=== '''schéma''' ===

Réalisation du schématique du PCB sur le logiciel KiCad : [[Fichier:Schématique de la carte.png|centré|vignette|439x439px|schématique]]lors de la phase de soudure, l'enseignant nous a mentionné que le schéma du capteur n'est pas bon. Nous avons pu corriger le problème avec l'aide de l'enseignant en se basant sur le schéma suivant : https://cdn.sparkfun.com/datasheets/Sensors/Proximity/QRE1113-Digital-Breakout-v11.pdf

=== '''Visual 3D''' ===
[[Fichier:Voiture 3D.png|vignette|502x502px|visualisation 3D de la carte |centré]]

=== '''Routage de la carte''' ===
[[Fichier:Routage de la carte .png|centré|vignette|670x670px|carte routée]]

=== '''Carte imprimée''' ===
[[Fichier:Carte imprimee bas.jpg|néant|vignette|Carte en vue de bas]]
[[Fichier:Notre carte.jpg|néant|vignette|carte en vue de haut]]

=== Carte en étape intermédiaire ===
[[Fichier:Carte soudée entièrement.jpg|centré|vignette]]
== '''Premier Test de la carte''' ==
[[Fichier:Test.png|vignette|611x611px|résultat de la commande lsusb|néant]]Comme vous le voyez dessus, le microcontrôleur est détecté en utilisant la commande lsusb. Néanmoins, après avoir fini le code du mini-moteur dc, le microcontrôleur n'est plus détectable pour une raison inconnue.

== Eclairage ==
[[Fichier:Clignotement des Leds.mp4|vignette|néant|Clignotement des Leds]]Les leds marchent bien ce qui nous a permi de passer à l'étape suivante ( souder le capteur et le coder )

== Capteur ==
Le capteur marche bien, puisqu'il permet aux leds de s'allumer s'il détecte quelquechose, et s'éteignent sinon.[[Fichier:Fonctionnement capteur.mov|vignette|néant|Vidéo du fonctionnement du capteur]]

== '''Moteurs''' ==
Nous avons soudé le pilote du mini-moteur dc, le mini-moteur DC et le micro-moteur glissière pas à pas.[[Fichier:Soudure.jpg|gauche|vignette|résultat final 1]]
[[Fichier:Photo.jpg|vignette|néant|505x505px|résultat final 2]]

===== Vidéo du fonctionnement du mini-moteur dc =====
Comme indiqué, nous ne pouvions plus programmer le microprocesseur. Pour cela , nous avons testé notre code sur la carte du groupe 2 :
[[Fichier:Vidéo moteur dc.mov|vignette|Vidéo du fonctionnement du mini-moteur dc|néant]]Voici le code utilisé pour tester le moteur sur la carte du groupe 2, il ne reste qu'à changer les pins pour convenir à leur structure :<syntaxhighlight lang="c" line="1">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}
int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);
while (1) {
control_motor(1);
_delay_ms(300);
control_motor(0);
inputs_init(imasks, pullup);
}
return 0;
}
</syntaxhighlight>Voici le code final en se basant sur les mêmes fonctions utilisées ci-dessus :<syntaxhighlight lang="c">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}
// The motor here is running anti clock-wise

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}

int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);

while (1) {
// Get the value read by the sensor
unsigned char qre_value = input_get(qre1113gr);

if (qre_value > 0) {
// Infra-red light detected, set everything on
output_set(leds, 0);
output_set(leds, 1);
output_set(leds, 2);
output_set(leds, 3);
control_motor(1);

} else {
// Nothing detected, set everything off
output_unset(leds, 0);
output_unset(leds, 1);
output_unset(leds, 2);
output_unset(leds, 3);
control_motor(0);
}

inputs_init(imasks, pullup); // reset the values

}

return 0;
}
</syntaxhighlight>

== '''Conclusion''' ==
Nous avons appris beaucoup de nouvelles compétences, notamment la conception et le routage d'une carte électronique, la soudure des composants et la manipulation d'un capteur.

Nous aurions pu avancer sur la partie LUFA et micro-moteur glissière pas à pas si nous n'avons pas eu le problème de détection du microcontrôleur. La batterie aussi reste à faire.

SE3Binome2022-5

2023-06-04T16:02:16Z

Yelqasta : /* Conclusion */

== '''<big>Présentation du projet</big>''' ==

=== '''<big>Objectif</big>''' ===
Concevoir un modèle de voiture 1:43 équipée d'un microcontrôleur ATMega16u2 permettant de commander la voiture en se basant sur un programme. Nous avons choisi de rajouter une option de suivi d'une ligne droite, ceci se fera à l'aide d'un capteur QRE1113gr.

=== '''<big>Composants</big>''' ===
les composants à utiliser dans notre projet sont les suivants :

* Un microcontrôleur ATMega16u2
* Un capteur QRE1113gr
* Un mini-moteur à courant continu
* Un pilote du mini-moteur à courant continu (DRV8210DRLR)
* Un micro-moteur glissière pas à pas
* Une batterie LiPo
* Une puce de contrôle de charge de la batterie (MAX1811)
* Des leds pour simuler le système d'éclairage
* Des résistances
* Des capacités
* Un quartz
* Un port USB
*Des diodes
*Un AVR-ISP 6
*Des connecteurs

=== '''<big>Caractéristiques et limites de notre système</big>''' ===

==== caractéristiques ====
Pour comprendre le fonctionnement de suivi de ligne souhaité, il faut d'abord comprendre le fonctionnement du capteur QRE. C'est un capteur de réflexion infrarouge, il est utilisé pour détecter la présence ou l'absence d'objets réfléchissants à proximité. Il se compose d'une LED infrarouge émettant de la lumière infrarouge et d'un phototransistor qui mesure la quantité de lumière réfléchie. Lorsqu'un objet se trouve devant le capteur, il réfléchit la lumière infrarouge émise par la LED vers le phototransistor. Le phototransistor détecte cette lumière réfléchie et génère un courant proportionnel à son intensité. La valeur mesurée par le capteur dépend de la quantité de lumière infrarouge réfléchie par l'objet. Si l'objet est réfléchissant et renvoie une grande quantité de lumière infrarouge, le phototransistor générera un courant plus élevé, ce qui se traduira par une valeur positive lorsqu'elle est lue par le microcontrôleur. En revanche, si aucun objet réfléchissant n'est présent devant le capteur, la quantité de lumière infrarouge réfléchie sera faible. Par conséquent, le phototransistor générera un courant plus faible ou nul, ce qui se traduira par une valeur de capteur égale à zéro lorsqu'elle est lue par le microcontrôleur.

==== Limites ====
Les composants cités ci-dessus étaient soudés et utilisés dans notre carte, sauf la batterie et sa puce de contrôle, les diodes, l'AVR-ISP et les connecteurs.

Pour réinitialiser le microprocesseur afin de mettre un nouveau code, il faut à chaque fois utiliser un fil entre la masse et la broche de reset du AVR-ISP. Le rajout d'un bouton aurait était mieux.

Lors du routage de la carte, nous n'avons pas fait attention que le capteur doit être placé en bas, afin de détecter la ligne.

Après avoir fini le code pour tester le mini-moteur dc, nous nous rendons compte que le microprocessur n'est plus détectable en utilisant la commande lsusb. Nous avons vérifié les connections, essayé de changer le port usb mais sans résultat (pourtant que les leds et le capteur marchait bien). Nous avons alors tester le code sur la carte du groupe 2 en ajustant un peu la structure et en supprimant les parties correspondantes au capteur.

=== '''<big>Avancement du projet</big>''' ===

==== le 14/02 : ====
- Compréhension de l'idée directrice du projet

- Recherche de l'option à rajouter

==== le 28/02 : ====
- Début de conception de la schématique

==== le 21/03 : ====
- début du rajout des empreintes des composants

==== le 07/04 : ====
- Fin de la schématique

==== le 13/04 : ====
- Fin du routage de la carte

- Envoi du modèle aux enseignants pour le valider et commander la carte

==== le 02/05: ====
- Réception de la carte

- Soudure de quelques résistances et capacités

==== le 09/05: ====
- Les composants suivants sont déjà soudés par l'enseignant : ATMega16u2, le quartz

- Rajout des leds et des résistances restantes

- Début du code pour tester les leds

==== le 16/05: ====
- Fin du code pour tester les leds

- Réorganisation de la schématique

==== le 23/05: ====
- Soudure du capteur

- Implémentation du code pour tester le capteur

- Soudure du mini-moteur dc

==== le 29/05: ====
- Soudure du micro-moteur pas à pas

- Implémentation du code pour tester le mini-moteur dc

==== le 03/06: ====
- Test du code de moteur sur la carte du groupe 2

=== '''<big>GIT</big>''' ===
le lien de notre archive GIT : https://archives.plil.fr/yelqasta/pse-g5.git

== '''Conception de la carte électronique''' ==

=== Composants et empreintes créés ===
nous avons créer le symbole du pilote du moteur DC via Kicad :
[[Fichier:Driver.png|vignette|250x250px|centré|Symbole du pilote DRV8210DRLR]]

Après avoir mesurer les dimensions du mini-moteur continu on a pu créer l'empreinte suivante :
[[Fichier:Dc moteur.png|centré|vignette|Empreinte du mini-moteur dc]]

'''schéma'''

Réalisation du schématique du PCB sur le logiciel KiCad : [[Fichier:Schématique de la carte.png|centré|vignette|439x439px|schématique]]lors de la phase de soudure, l'enseignant nous a mentionné que le schéma du capteur n'est pas bon. Nous avons pu corriger le problème avec l'aide de l'enseignant en se basant sur le schéma suivant : https://cdn.sparkfun.com/datasheets/Sensors/Proximity/QRE1113-Digital-Breakout-v11.pdf

=== '''Visual 3D''' ===
[[Fichier:Voiture 3D.png|vignette|502x502px|visualisation 3D de la carte |centré]]

=== '''Routage de la carte''' ===
[[Fichier:Routage de la carte .png|centré|vignette|670x670px|carte routée]]

=== '''Carte imprimée''' ===
[[Fichier:Carte imprimee bas.jpg|néant|vignette|Carte en vue de bas]]
[[Fichier:Notre carte.jpg|néant|vignette|carte en vue de haut]]

=== Carte en étape intermédiaire ===
[[Fichier:Carte soudée entièrement.jpg|centré|vignette]]
== '''Premier Test de la carte''' ==
[[Fichier:Test.png|vignette|611x611px|résultat de la commande lsusb|néant]]Comme vous le voyez dessus, le microcontrôleur est détecté en utilisant la commande lsusb. Néanmoins, après avoir fini le code du mini-moteur dc, le microcontrôleur n'est plus détectable pour une raison inconnue.

== Eclairage ==
[[Fichier:Clignotement des Leds.mp4|vignette|néant|Clignotement des Leds]]Les leds marchent bien ce qui nous a permi de passer à l'étape suivante ( souder le capteur et le coder )

== Capteur ==
Le capteur marche bien, puisqu'il permet aux leds de s'allumer s'il détecte quelquechose, et s'éteignent sinon.[[Fichier:Fonctionnement capteur.mov|vignette|néant|Vidéo du fonctionnement du capteur]]

== '''Moteurs''' ==
Nous avons soudé le pilote du mini-moteur dc, le mini-moteur DC et le micro-moteur glissière pas à pas.[[Fichier:Soudure.jpg|gauche|vignette|résultat final 1]]
[[Fichier:Photo.jpg|vignette|néant|505x505px|résultat final 2]]

===== Vidéo du fonctionnement du mini-moteur dc =====
Comme indiqué, nous ne pouvions plus programmer le microprocesseur. Pour cela , nous avons testé notre code sur la carte du groupe 2 :
[[Fichier:Vidéo moteur dc.mov|vignette|Vidéo du fonctionnement du mini-moteur dc|néant]]Voici le code utilisé pour tester le moteur sur la carte du groupe 2, il ne reste qu'à changer les pins pour convenir à leur structure :<syntaxhighlight lang="c" line="1">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}
int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);
while (1) {
control_motor(1);
_delay_ms(300);
control_motor(0);
inputs_init(imasks, pullup);
}
return 0;
}
</syntaxhighlight>Voici le code final en se basant sur les mêmes fonctions utilisées ci-dessus :<syntaxhighlight lang="c">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}
// The motor here is running anti clock-wise

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}

int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);

while (1) {
// Get the value read by the sensor
unsigned char qre_value = input_get(qre1113gr);

if (qre_value > 0) {
// Infra-red light detected, set everything on
output_set(leds, 0);
output_set(leds, 1);
output_set(leds, 2);
output_set(leds, 3);
control_motor(1);

} else {
// Nothing detected, set everything off
output_unset(leds, 0);
output_unset(leds, 1);
output_unset(leds, 2);
output_unset(leds, 3);
control_motor(0);
}

inputs_init(imasks, pullup); // reset the values

}

return 0;
}
</syntaxhighlight>

== '''Conclusion''' ==
Nous avons appris beaucoup de nouvelles compétences, notamment la conception et le routage d'une carte électronique, la soudure des composants et la manipulation d'un capteur.

Nous aurions pu avancer sur la partie LUFA et micro-moteur glissière pas à pas si nous n'avons pas eu le problème de détection du microcontrôleur. La batterie aussi reste à faire.

SE3Binome2022-5

2023-06-04T16:01:11Z

Yelqasta : /* Carte imprimée */

== '''<big>Présentation du projet</big>''' ==

=== '''<big>Objectif</big>''' ===
Concevoir un modèle de voiture 1:43 équipée d'un microcontrôleur ATMega16u2 permettant de commander la voiture en se basant sur un programme. Nous avons choisi de rajouter une option de suivi d'une ligne droite, ceci se fera à l'aide d'un capteur QRE1113gr.

=== '''<big>Composants</big>''' ===
les composants à utiliser dans notre projet sont les suivants :

* Un microcontrôleur ATMega16u2
* Un capteur QRE1113gr
* Un mini-moteur à courant continu
* Un pilote du mini-moteur à courant continu (DRV8210DRLR)
* Un micro-moteur glissière pas à pas
* Une batterie LiPo
* Une puce de contrôle de charge de la batterie (MAX1811)
* Des leds pour simuler le système d'éclairage
* Des résistances
* Des capacités
* Un quartz
* Un port USB
*Des diodes
*Un AVR-ISP 6
*Des connecteurs

=== '''<big>Caractéristiques et limites de notre système</big>''' ===

==== caractéristiques ====
Pour comprendre le fonctionnement de suivi de ligne souhaité, il faut d'abord comprendre le fonctionnement du capteur QRE. C'est un capteur de réflexion infrarouge, il est utilisé pour détecter la présence ou l'absence d'objets réfléchissants à proximité. Il se compose d'une LED infrarouge émettant de la lumière infrarouge et d'un phototransistor qui mesure la quantité de lumière réfléchie. Lorsqu'un objet se trouve devant le capteur, il réfléchit la lumière infrarouge émise par la LED vers le phototransistor. Le phototransistor détecte cette lumière réfléchie et génère un courant proportionnel à son intensité. La valeur mesurée par le capteur dépend de la quantité de lumière infrarouge réfléchie par l'objet. Si l'objet est réfléchissant et renvoie une grande quantité de lumière infrarouge, le phototransistor générera un courant plus élevé, ce qui se traduira par une valeur positive lorsqu'elle est lue par le microcontrôleur. En revanche, si aucun objet réfléchissant n'est présent devant le capteur, la quantité de lumière infrarouge réfléchie sera faible. Par conséquent, le phototransistor générera un courant plus faible ou nul, ce qui se traduira par une valeur de capteur égale à zéro lorsqu'elle est lue par le microcontrôleur.

==== Limites ====
Les composants cités ci-dessus étaient soudés et utilisés dans notre carte, sauf la batterie et sa puce de contrôle, les diodes, l'AVR-ISP et les connecteurs.

Pour réinitialiser le microprocesseur afin de mettre un nouveau code, il faut à chaque fois utiliser un fil entre la masse et la broche de reset du AVR-ISP. Le rajout d'un bouton aurait était mieux.

Lors du routage de la carte, nous n'avons pas fait attention que le capteur doit être placé en bas, afin de détecter la ligne.

Après avoir fini le code pour tester le mini-moteur dc, nous nous rendons compte que le microprocessur n'est plus détectable en utilisant la commande lsusb. Nous avons vérifié les connections, essayé de changer le port usb mais sans résultat (pourtant que les leds et le capteur marchait bien). Nous avons alors tester le code sur la carte du groupe 2 en ajustant un peu la structure et en supprimant les parties correspondantes au capteur.

=== '''<big>Avancement du projet</big>''' ===

==== le 14/02 : ====
- Compréhension de l'idée directrice du projet

- Recherche de l'option à rajouter

==== le 28/02 : ====
- Début de conception de la schématique

==== le 21/03 : ====
- début du rajout des empreintes des composants

==== le 07/04 : ====
- Fin de la schématique

==== le 13/04 : ====
- Fin du routage de la carte

- Envoi du modèle aux enseignants pour le valider et commander la carte

==== le 02/05: ====
- Réception de la carte

- Soudure de quelques résistances et capacités

==== le 09/05: ====
- Les composants suivants sont déjà soudés par l'enseignant : ATMega16u2, le quartz

- Rajout des leds et des résistances restantes

- Début du code pour tester les leds

==== le 16/05: ====
- Fin du code pour tester les leds

- Réorganisation de la schématique

==== le 23/05: ====
- Soudure du capteur

- Implémentation du code pour tester le capteur

- Soudure du mini-moteur dc

==== le 29/05: ====
- Soudure du micro-moteur pas à pas

- Implémentation du code pour tester le mini-moteur dc

==== le 03/06: ====
- Test du code de moteur sur la carte du groupe 2

=== '''<big>GIT</big>''' ===
le lien de notre archive GIT : https://archives.plil.fr/yelqasta/pse-g5.git

== '''Conception de la carte électronique''' ==

=== Composants et empreintes créés ===
nous avons créer le symbole du pilote du moteur DC via Kicad :
[[Fichier:Driver.png|vignette|250x250px|centré|Symbole du pilote DRV8210DRLR]]

Après avoir mesurer les dimensions du mini-moteur continu on a pu créer l'empreinte suivante :
[[Fichier:Dc moteur.png|centré|vignette|Empreinte du mini-moteur dc]]

'''schéma'''

Réalisation du schématique du PCB sur le logiciel KiCad : [[Fichier:Schématique de la carte.png|centré|vignette|439x439px|schématique]]lors de la phase de soudure, l'enseignant nous a mentionné que le schéma du capteur n'est pas bon. Nous avons pu corriger le problème avec l'aide de l'enseignant en se basant sur le schéma suivant : https://cdn.sparkfun.com/datasheets/Sensors/Proximity/QRE1113-Digital-Breakout-v11.pdf

=== '''Visual 3D''' ===
[[Fichier:Voiture 3D.png|vignette|502x502px|visualisation 3D de la carte |centré]]

=== '''Routage de la carte''' ===
[[Fichier:Routage de la carte .png|centré|vignette|670x670px|carte routée]]

=== '''Carte imprimée''' ===
[[Fichier:Carte imprimee bas.jpg|néant|vignette|Carte en vue de bas]]

=== Carte en étape intermédiaire ===
[[Fichier:Carte soudée entièrement.jpg|centré|vignette|premièr]]
== '''Premier Test de la carte''' ==
[[Fichier:Test.png|vignette|611x611px|résultat de la commande lsusb|néant]]Comme vous le voyez dessus, le microcontrôleur est détecté en utilisant la commande lsusb. Néanmoins, après avoir fini le code du mini-moteur dc, le microcontrôleur n'est plus détectable pour une raison inconnue.

== Eclairage ==
[[Fichier:Clignotement des Leds.mp4|vignette|néant|Clignotement des Leds]]Les leds marchent bien ce qui nous a permi de passer à l'étape suivante ( souder le capteur et le coder )

== Capteur ==
Le capteur marche bien, puisqu'il permet aux leds de s'allumer s'il détecte quelquechose, et s'éteignent sinon.[[Fichier:Fonctionnement capteur.mov|vignette|néant|Vidéo du fonctionnement du capteur]]

== '''Moteurs''' ==
Nous avons soudé le pilote du mini-moteur dc, le mini-moteur DC et le micro-moteur glissière pas à pas.[[Fichier:Soudure.jpg|gauche|vignette|résultat final 1]]
[[Fichier:Photo.jpg|vignette|néant|505x505px|résultat final 2]]

===== Vidéo du fonctionnement du mini-moteur dc =====
Comme indiqué, nous ne pouvions plus programmer le microprocesseur. Pour cela , nous avons testé notre code sur la carte du groupe 2 :
[[Fichier:Vidéo moteur dc.mov|vignette|Vidéo du fonctionnement du mini-moteur dc|néant]]Voici le code utilisé pour tester le moteur sur la carte du groupe 2, il ne reste qu'à changer les pins pour convenir à leur structure :<syntaxhighlight lang="c" line="1">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}
int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);
while (1) {
control_motor(1);
_delay_ms(300);
control_motor(0);
inputs_init(imasks, pullup);
}
return 0;
}
</syntaxhighlight>Voici le code final en se basant sur les mêmes fonctions utilisées ci-dessus :<syntaxhighlight lang="c">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}
// The motor here is running anti clock-wise

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}

int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);

while (1) {
// Get the value read by the sensor
unsigned char qre_value = input_get(qre1113gr);

if (qre_value > 0) {
// Infra-red light detected, set everything on
output_set(leds, 0);
output_set(leds, 1);
output_set(leds, 2);
output_set(leds, 3);
control_motor(1);

} else {
// Nothing detected, set everything off
output_unset(leds, 0);
output_unset(leds, 1);
output_unset(leds, 2);
output_unset(leds, 3);
control_motor(0);
}

inputs_init(imasks, pullup); // reset the values

}

return 0;
}
</syntaxhighlight>

== '''Conclusion''' ==
Nous avons appris beaucoup de nouvelles compétences, notamment la conception et le routage d'une carte électronique, la soudure des composants et la manipulation d'un capteur.

Nous aurions pu avancer sur la partie LUFA et micro-moteur glissière pas à pas si nous n'avons pas eu le problème de détection du microcontrôleur. La batterie aussi reste à faire.

Fichier:Carte imprimee bas.jpg

2023-06-04T15:59:20Z

Yelqasta :

carte en bas

SE3Binome2022-5

2023-06-04T15:56:42Z

Yelqasta : /* Capteur */

== '''<big>Présentation du projet</big>''' ==

=== '''<big>Objectif</big>''' ===
Concevoir un modèle de voiture 1:43 équipée d'un microcontrôleur ATMega16u2 permettant de commander la voiture en se basant sur un programme. Nous avons choisi de rajouter une option de suivi d'une ligne droite, ceci se fera à l'aide d'un capteur QRE1113gr.

=== '''<big>Composants</big>''' ===
les composants à utiliser dans notre projet sont les suivants :

* Un microcontrôleur ATMega16u2
* Un capteur QRE1113gr
* Un mini-moteur à courant continu
* Un pilote du mini-moteur à courant continu (DRV8210DRLR)
* Un micro-moteur glissière pas à pas
* Une batterie LiPo
* Une puce de contrôle de charge de la batterie (MAX1811)
* Des leds pour simuler le système d'éclairage
* Des résistances
* Des capacités
* Un quartz
* Un port USB
*Des diodes
*Un AVR-ISP 6
*Des connecteurs

=== '''<big>Caractéristiques et limites de notre système</big>''' ===

==== caractéristiques ====
Pour comprendre le fonctionnement de suivi de ligne souhaité, il faut d'abord comprendre le fonctionnement du capteur QRE. C'est un capteur de réflexion infrarouge, il est utilisé pour détecter la présence ou l'absence d'objets réfléchissants à proximité. Il se compose d'une LED infrarouge émettant de la lumière infrarouge et d'un phototransistor qui mesure la quantité de lumière réfléchie. Lorsqu'un objet se trouve devant le capteur, il réfléchit la lumière infrarouge émise par la LED vers le phototransistor. Le phototransistor détecte cette lumière réfléchie et génère un courant proportionnel à son intensité. La valeur mesurée par le capteur dépend de la quantité de lumière infrarouge réfléchie par l'objet. Si l'objet est réfléchissant et renvoie une grande quantité de lumière infrarouge, le phototransistor générera un courant plus élevé, ce qui se traduira par une valeur positive lorsqu'elle est lue par le microcontrôleur. En revanche, si aucun objet réfléchissant n'est présent devant le capteur, la quantité de lumière infrarouge réfléchie sera faible. Par conséquent, le phototransistor générera un courant plus faible ou nul, ce qui se traduira par une valeur de capteur égale à zéro lorsqu'elle est lue par le microcontrôleur.

==== Limites ====
Les composants cités ci-dessus étaient soudés et utilisés dans notre carte, sauf la batterie et sa puce de contrôle, les diodes, l'AVR-ISP et les connecteurs.

Pour réinitialiser le microprocesseur afin de mettre un nouveau code, il faut à chaque fois utiliser un fil entre la masse et la broche de reset du AVR-ISP. Le rajout d'un bouton aurait était mieux.

Lors du routage de la carte, nous n'avons pas fait attention que le capteur doit être placé en bas, afin de détecter la ligne.

Après avoir fini le code pour tester le mini-moteur dc, nous nous rendons compte que le microprocessur n'est plus détectable en utilisant la commande lsusb. Nous avons vérifié les connections, essayé de changer le port usb mais sans résultat (pourtant que les leds et le capteur marchait bien). Nous avons alors tester le code sur la carte du groupe 2 en ajustant un peu la structure et en supprimant les parties correspondantes au capteur.

=== '''<big>Avancement du projet</big>''' ===

==== le 14/02 : ====
- Compréhension de l'idée directrice du projet

- Recherche de l'option à rajouter

==== le 28/02 : ====
- Début de conception de la schématique

==== le 21/03 : ====
- début du rajout des empreintes des composants

==== le 07/04 : ====
- Fin de la schématique

==== le 13/04 : ====
- Fin du routage de la carte

- Envoi du modèle aux enseignants pour le valider et commander la carte

==== le 02/05: ====
- Réception de la carte

- Soudure de quelques résistances et capacités

==== le 09/05: ====
- Les composants suivants sont déjà soudés par l'enseignant : ATMega16u2, le quartz

- Rajout des leds et des résistances restantes

- Début du code pour tester les leds

==== le 16/05: ====
- Fin du code pour tester les leds

- Réorganisation de la schématique

==== le 23/05: ====
- Soudure du capteur

- Implémentation du code pour tester le capteur

- Soudure du mini-moteur dc

==== le 29/05: ====
- Soudure du micro-moteur pas à pas

- Implémentation du code pour tester le mini-moteur dc

==== le 03/06: ====
- Teste du code de moteur sur la carte du groupe 2

=== '''<big>GIT</big>''' ===
le lien de notre archive GIT : https://archives.plil.fr/yelqasta/pse-g5.git

== '''Conception de la carte électronique''' ==

=== Composants et empreintes créés ===
nous avons créer le symbole du pilote du moteur DC via Kicad :
[[Fichier:Driver.png|vignette|250x250px|centré|Symbole du pilote DRV8210DRLR]]

Après avoir mesurer les dimensions du mini-moteur continu on a pu créer l'empreinte suivante :
[[Fichier:Dc moteur.png|centré|vignette|Empreinte du mini-moteur dc]]

'''schéma'''

Réalisation du schématique du PCB sur le logiciel KiCad : [[Fichier:Schématique de la carte.png|centré|vignette|439x439px|schématique]]lors de la phase de soudure, l'enseignant nous a mentionné que le schéma du capteur n'est pas bon. Nous avons pu corriger le problème avec l'aide de l'enseignant en se basant sur le schéma suivant : https://cdn.sparkfun.com/datasheets/Sensors/Proximity/QRE1113-Digital-Breakout-v11.pdf

=== '''Visual 3D''' ===
[[Fichier:Voiture 3D.png|vignette|502x502px|visualisation 3D de la carte |centré]]

=== '''Routage de la carte''' ===
[[Fichier:Routage de la carte .png|centré|vignette|670x670px|carte routée]]

=== '''Carte imprimée''' ===
la carte imprimée et soudure du capteur, leds, résistances et microcontrôleur ATMega16U2 :
[[Fichier:Carte soudée entièrement.jpg|centré|vignette]]
== '''Premier Test de la carte''' ==
[[Fichier:Test.png|vignette|611x611px|résultat de la commande lsusb|néant]]Comme vous le voyez dessus, le microcontrôleur est détecté en utilisant la commande lsusb. Néanmoins, après avoir fini le code du mini-moteur dc, le microcontrôleur n'est plus détectable pour une raison inconnue.

== Eclairage ==
[[Fichier:Clignotement des Leds.mp4|vignette|néant]]Les leds marchent bien ce qui nous a permi de passer à l'étape suivante ( souder le capteur et le coder )

== Capteur ==
Le capteur marche bien, puisqu'il permet aux leds de s'allumer s'il détecte quelquechose, et s'éteignent sinon.[[Fichier:Fonctionnement capteur.mov|vignette|néant|Vidéo du fonctionnement du capteur]]

== '''Moteurs''' ==
Nous avons soudé le pilote du mini-moteur dc, le mini-moteur DC et le micro-moteur glissière pas à pas.[[Fichier:Soudure.jpg|gauche|vignette|résultat final 1]]
[[Fichier:Photo.jpg|vignette|néant|505x505px|résultat final 2]]

===== Vidéo du fonctionnement du mini-moteur dc =====
Comme indiqué, nous ne pouvions plus programmer le microprocesseur. Pour cela , nous avons testé notre code sur la carte du groupe 2 :
[[Fichier:Vidéo moteur dc.mov|vignette|Vidéo du fonctionnement du mini-moteur dc|néant]]Voici le code utilisé pour tester le moteur sur la carte du groupe 2, il ne reste qu'à changer les pins pour convenir à leur structure :<syntaxhighlight lang="c" line="1">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}
int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);
while (1) {
control_motor(1);
_delay_ms(300);
control_motor(0);
inputs_init(imasks, pullup);
}
return 0;
}
</syntaxhighlight>Voici le code final en se basant sur les mêmes fonctions utilisées ci-dessus :<syntaxhighlight lang="c">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}
// The motor here is running anti clock-wise

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}

int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);

while (1) {
// Get the value read by the sensor
unsigned char qre_value = input_get(qre1113gr);

if (qre_value > 0) {
// Infra-red light detected, set everything on
output_set(leds, 0);
output_set(leds, 1);
output_set(leds, 2);
output_set(leds, 3);
control_motor(1);

} else {
// Nothing detected, set everything off
output_unset(leds, 0);
output_unset(leds, 1);
output_unset(leds, 2);
output_unset(leds, 3);
control_motor(0);
}

inputs_init(imasks, pullup); // reset the values

}

return 0;
}
</syntaxhighlight>

== '''Conclusion''' ==
Nous avons appris beaucoup de nouvelles compétences, notamment la conception et le routage d'une schématique, la soudure des composants et la manipulation d'un capteur.

Nous aurions pu avancer sur la partie LUFA et micro-moteur glissière pas à pas si nous n'avons pas eu le problème de détection du microcontrôleur. La batterie aussi reste à faire.

SE3Binome2022-5

2023-06-04T15:47:51Z

Yelqasta : /* Vidéo en fonctionnement */

== '''<big>Présentation du projet</big>''' ==

=== '''<big>Objectif</big>''' ===
Concevoir un modèle de voiture 1:43 équipée d'un microcontrôleur ATMega16u2 permettant de commander la voiture en se basant sur un programme. Nous avons choisi de rajouter une option de suivi d'une ligne droite, ceci se fera à l'aide d'un capteur QRE1113gr.

=== '''<big>Composants</big>''' ===
les composants à utiliser dans notre projet sont les suivants :

* Un microcontrôleur ATMega16u2
* Un capteur QRE1113gr
* Un mini-moteur à courant continu
* Un pilote du mini-moteur à courant continu (DRV8210DRLR)
* Un micro-moteur glissière pas à pas
* Une batterie LiPo
* Une puce de contrôle de charge de la batterie (MAX1811)
* Des leds pour simuler le système d'éclairage
* Des résistances
* Des capacités
* Un quartz
* Un port USB
*Des diodes
*Un AVR-ISP 6
*Des connecteurs

=== '''<big>Caractéristiques et limites de notre système</big>''' ===

==== caractéristiques ====
Pour comprendre le fonctionnement de suivi de ligne souhaité, il faut d'abord comprendre le fonctionnement du capteur QRE. C'est un capteur de réflexion infrarouge, il est utilisé pour détecter la présence ou l'absence d'objets réfléchissants à proximité. Il se compose d'une LED infrarouge émettant de la lumière infrarouge et d'un phototransistor qui mesure la quantité de lumière réfléchie. Lorsqu'un objet se trouve devant le capteur, il réfléchit la lumière infrarouge émise par la LED vers le phototransistor. Le phototransistor détecte cette lumière réfléchie et génère un courant proportionnel à son intensité. La valeur mesurée par le capteur dépend de la quantité de lumière infrarouge réfléchie par l'objet. Si l'objet est réfléchissant et renvoie une grande quantité de lumière infrarouge, le phototransistor générera un courant plus élevé, ce qui se traduira par une valeur positive lorsqu'elle est lue par le microcontrôleur. En revanche, si aucun objet réfléchissant n'est présent devant le capteur, la quantité de lumière infrarouge réfléchie sera faible. Par conséquent, le phototransistor générera un courant plus faible ou nul, ce qui se traduira par une valeur de capteur égale à zéro lorsqu'elle est lue par le microcontrôleur.

==== Limites ====
Les composants cités ci-dessus étaient soudés et utilisés dans notre carte, sauf la batterie et sa puce de contrôle, les diodes, l'AVR-ISP et quelques capacités de filtrage de bruit ainsi que les connecteurs.

Pour réinitialiser le microprocesseur afin de mettre un nouveau code, il faut à chaque fois utiliser un fil entre la masse et la broche de reset du AVR-ISP. Le rajout d'un bouton aurait était mieux.

Lors du routage de la carte, nous n'avons pas fait attention que le capteur doit être placé en bas, afin de détecter la ligne.

Après avoir fini le code pour tester le mini-moteur dc, nous nous rendons compte que le microprocessur n'est plus détectable en utilisant la commande lsusb. Nous avons vérifié les connections, essayé de changer le port usb mais sans résultat (pourtant que les leds et le capteur marchait bien). Nous avons alors tester le code sur la carte du groupe 2 en ajustant un peu la structure et en supprimant les parties correspondantes au capteur.

=== '''<big>Avancement du projet</big>''' ===

==== le 14/02 : ====
- Compréhension de l'idée directrice du projet

- Recherche de l'option à rajouter

==== le 28/02 : ====
- Début de conception de la schématique

==== le 21/03 : ====
- début du rajout des empreintes des composants

==== le 07/04 : ====
- Fin de la schématique

==== le 13/04 : ====
- Fin du routage de la carte

- Envoi du modèle aux enseignants pour le valider et commander la carte

==== le 02/05: ====
- Réception de la carte

- Soudure de quelques résistances et capacités

==== le 09/05: ====
- Les composants suivants sont déjà soudés par l'enseignant : ATMega16u2, le quartz

- Rajout des leds et des résistances restantes

- Début du code pour tester les leds

==== le 16/05: ====
- Fin du code pour tester les leds

- Réorganisation de la schématique

==== le 23/05: ====
- Soudure du capteur

- Implémentation du code pour tester le capteur

- Soudure du mini-moteur dc

==== le 29/05: ====
- Soudure du micro-moteur pas à pas

- Implémentation du code pour tester le mini-moteur dc

==== le 03/06: ====
- Teste du code de moteur sur la carte du groupe 2

=== '''<big>GIT</big>''' ===
le lien de notre archive GIT : https://archives.plil.fr/yelqasta/pse-g5.git

== '''Conception de la carte électronique''' ==

=== Composants et empreintes créés ===
nous avons créer le symbole du pilote du moteur DC via Kicad :
[[Fichier:Driver.png|vignette|250x250px|centré|Symbole du pilote DRV8210DRLR]]

Après avoir mesurer les dimensions du mini-moteur continu on a pu créer l'empreinte suivante :
[[Fichier:Dc moteur.png|centré|vignette|Empreinte du mini-moteur dc]]

'''schéma'''

Réalisation du schématique du PCB sur le logiciel KiCad : [[Fichier:Schématique de la carte.png|centré|vignette|439x439px|schématique]]lors de la phase de soudure, l'enseignant nous a mentionné que le schéma du capteur n'est pas bon. Nous avons pu corriger le problème avec l'aide de l'enseignant en se basant sur le schéma suivant : https://cdn.sparkfun.com/datasheets/Sensors/Proximity/QRE1113-Digital-Breakout-v11.pdf

=== '''Visual 3D''' ===
[[Fichier:Voiture 3D.png|vignette|502x502px|visualisation 3D de la carte |centré]]

=== '''Routage de la carte''' ===
[[Fichier:Routage de la carte .png|centré|vignette|670x670px|carte routée]]

=== '''Carte imprimée''' ===
la carte imprimée et soudure du capteur, leds, résistances et microcontrôleur ATMega16U2 :
[[Fichier:Carte soudée entièrement.jpg|centré|vignette]]
== '''Premier Test de la carte''' ==
[[Fichier:Test.png|vignette|611x611px|résultat de la commande lsusb|néant]]Comme vous le voyez dessus, le microcontrôleur est détecté en utilisant la commande lsusb. Néanmoins, après avoir fini le code du mini-moteur dc, le microcontrôleur n'est plus détectable pour une raison inconnue.

== '''Programme''' ==

=== Eclairage ===
[[Fichier:Clignotement des Leds.mp4|vignette|néant]]Les leds marchent bien ce qui nous a permi de passer à l'étape suivante ( souder le capteur et le coder )

=== Capteur ===
Le capteur marche bien, puisqu'il permet aux leds de s'allumer s'il détecte quelquechose.[[Fichier:Fonctionnement capteur.mov|vignette|néant|Vidéo du fonctionnement du capteur]]

== '''Soudure des moteurs''' ==
Nous avons soudé le pilote du mini-moteur dc, le mini-moteur DC et le micro-moteur glissière pas à pas.[[Fichier:Soudure.jpg|gauche|vignette|résultat final 1]]
[[Fichier:Photo.jpg|vignette|néant|505x505px|résultat final 2]]

===== Vidéo du fonctionnement du mini-moteur dc =====
Comme indiqué, nous ne pouvions plus programmer le microprocesseur. Pour cela , nous avons testé notre code sur la carte du groupe 2 :
[[Fichier:Vidéo moteur dc.mov|vignette|Vidéo du fonctionnement du mini-moteur dc|néant]]Voici le code utilisé pour tester le moteur sur la carte du groupe 2, il ne reste qu'à changer les pins pour convenir à leur structure :<syntaxhighlight lang="c" line="1">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}
int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);
while (1) {
control_motor(1);
_delay_ms(300);
control_motor(0);
inputs_init(imasks, pullup);
}
return 0;
}
</syntaxhighlight>Voici le code final en se basant sur les mêmes fonctions utilisées ci-dessus :<syntaxhighlight lang="c">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}
// The motor here is running anti clock-wise

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}

int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);

while (1) {
// Get the value read by the sensor
unsigned char qre_value = input_get(qre1113gr);

if (qre_value > 0) {
// Infra-red light detected, set everything on
output_set(leds, 0);
output_set(leds, 1);
output_set(leds, 2);
output_set(leds, 3);
control_motor(1);

} else {
// Nothing detected, set everything off
output_unset(leds, 0);
output_unset(leds, 1);
output_unset(leds, 2);
output_unset(leds, 3);
control_motor(0);
}

inputs_init(imasks, pullup); // reset the values

}

return 0;
}
</syntaxhighlight>

SE3Binome2022-5

2023-06-04T15:33:05Z

Yelqasta : /* Vidéo en fonctionnement */

== '''<big>Présentation du projet</big>''' ==

=== '''<big>Objectif</big>''' ===
Concevoir un modèle de voiture 1:43 équipée d'un microcontrôleur ATMega16u2 permettant de commander la voiture en se basant sur un programme. Nous avons choisi de rajouter une option de suivi d'une ligne droite, ceci se fera à l'aide d'un capteur QRE1113gr.

=== '''<big>Composants</big>''' ===
les composants à utiliser dans notre projet sont les suivants :

* Un microcontrôleur ATMega16u2
* Un capteur QRE1113gr
* Un mini-moteur à courant continu
* Un pilote du mini-moteur à courant continu (DRV8210DRLR)
* Un micro-moteur glissière pas à pas
* Une batterie LiPo
* Une puce de contrôle de charge de la batterie (MAX1811)
* Des leds pour simuler le système d'éclairage
* Des résistances
* Des capacités
* Un quartz
* Un port USB
*Des diodes
*Un AVR-ISP 6
*Des connecteurs

=== '''<big>Caractéristiques et limites de notre système</big>''' ===

==== caractéristiques ====
Pour comprendre le fonctionnement de suivi de ligne souhaité, il faut d'abord comprendre le fonctionnement du capteur QRE. C'est un capteur de réflexion infrarouge, il est utilisé pour détecter la présence ou l'absence d'objets réfléchissants à proximité. Il se compose d'une LED infrarouge émettant de la lumière infrarouge et d'un phototransistor qui mesure la quantité de lumière réfléchie. Lorsqu'un objet se trouve devant le capteur, il réfléchit la lumière infrarouge émise par la LED vers le phototransistor. Le phototransistor détecte cette lumière réfléchie et génère un courant proportionnel à son intensité. La valeur mesurée par le capteur dépend de la quantité de lumière infrarouge réfléchie par l'objet. Si l'objet est réfléchissant et renvoie une grande quantité de lumière infrarouge, le phototransistor générera un courant plus élevé, ce qui se traduira par une valeur positive lorsqu'elle est lue par le microcontrôleur. En revanche, si aucun objet réfléchissant n'est présent devant le capteur, la quantité de lumière infrarouge réfléchie sera faible. Par conséquent, le phototransistor générera un courant plus faible ou nul, ce qui se traduira par une valeur de capteur égale à zéro lorsqu'elle est lue par le microcontrôleur.

==== Limites ====
Les composants cités ci-dessus étaient soudés et utilisés dans notre carte, sauf la batterie et sa puce de contrôle, les diodes, l'AVR-ISP et quelques capacités de filtrage de bruit ainsi que les connecteurs.

Pour réinitialiser le microprocesseur afin de mettre un nouveau code, il faut à chaque fois utiliser un fil entre la masse et la broche de reset du AVR-ISP. Le rajout d'un bouton aurait était mieux.

Lors du routage de la carte, nous n'avons pas fait attention que le capteur doit être placé en bas, afin de détecter la ligne.

Après avoir fini le code pour tester le mini-moteur dc, nous nous rendons compte que le microprocessur n'est plus détectable en utilisant la commande lsusb. Nous avons vérifié les connections, essayé de changer le port usb mais sans résultat (pourtant que les leds et le capteur marchait bien). Nous avons alors tester le code sur la carte du groupe 2 en ajustant un peu la structure et en supprimant les parties correspondantes au capteur.

=== '''<big>Avancement du projet</big>''' ===

==== le 14/02 : ====
- Compréhension de l'idée directrice du projet

- Recherche de l'option à rajouter

==== le 28/02 : ====
- Début de conception de la schématique

==== le 21/03 : ====
- début du rajout des empreintes des composants

==== le 07/04 : ====
- Fin de la schématique

==== le 13/04 : ====
- Fin du routage de la carte

- Envoi du modèle aux enseignants pour le valider et commander la carte

==== le 02/05: ====
- Réception de la carte

- Soudure de quelques résistances et capacités

==== le 09/05: ====
- Les composants suivants sont déjà soudés par l'enseignant : ATMega16u2, le quartz

- Rajout des leds et des résistances restantes

- Début du code pour tester les leds

==== le 16/05: ====
- Fin du code pour tester les leds

- Réorganisation de la schématique

==== le 23/05: ====
- Soudure du capteur

- Implémentation du code pour tester le capteur

- Soudure du mini-moteur dc

==== le 29/05: ====
- Soudure du micro-moteur pas à pas

- Implémentation du code pour tester le mini-moteur dc

==== le 03/06: ====
- Teste du code de moteur sur la carte du groupe 2

=== '''<big>GIT</big>''' ===
le lien de notre archive GIT : https://archives.plil.fr/yelqasta/pse-g5.git

== '''Conception de la carte électronique''' ==

=== Composants et empreintes créés ===
nous avons créer le symbole du pilote du moteur DC via Kicad :
[[Fichier:Driver.png|vignette|250x250px|centré|Symbole du pilote DRV8210DRLR]]

Après avoir mesurer les dimensions du mini-moteur continu on a pu créer l'empreinte suivante :
[[Fichier:Dc moteur.png|centré|vignette|Empreinte du mini-moteur dc]]

'''schéma'''

Réalisation du schématique du PCB sur le logiciel KiCad : [[Fichier:Schématique de la carte.png|centré|vignette|439x439px|schématique]]lors de la phase de soudure, l'enseignant nous a mentionné que le schéma du capteur n'est pas bon. Nous avons pu corriger le problème avec l'aide de l'enseignant en se basant sur le schéma suivant : https://cdn.sparkfun.com/datasheets/Sensors/Proximity/QRE1113-Digital-Breakout-v11.pdf

=== '''Visual 3D''' ===
[[Fichier:Voiture 3D.png|vignette|502x502px|visualisation 3D de la carte |centré]]

=== '''Routage de la carte''' ===
[[Fichier:Routage de la carte .png|centré|vignette|670x670px|carte routée]]

=== '''Carte imprimée''' ===
la carte imprimée et soudure du capteur, leds, résistances et microcontrôleur ATMega16U2 :
[[Fichier:Carte soudée entièrement.jpg|centré|vignette]]
== '''Premier Test de la carte''' ==
[[Fichier:Test.png|centré|vignette|611x611px|résultat de la commande lsusb]]

== '''Programme''' ==

=== Code de clignotement des Leds ===

==== Vidéo en fonctionnement ====
[[Fichier:Clignotement des Leds.mp4|centré|vignette]]

=== '''Code du suiveur QRE1113GR''' ===

[[Fichier:Fonctionnement capteur.mov|vignette]]

==== Vidéo en fonctionnement ====

== '''Soudure des moteurs''' ==
Nous avons soudé le pilote du mini-moteur dc, le mini-moteur DC et le micro-moteur glissière pas à pas.[[Fichier:Soudure.jpg|gauche|vignette|résultat final 1]]
[[Fichier:Photo.jpg|vignette|néant|505x505px|résultat final 2]]

===== Vidéo du fonctionnement du mini-moteur dc =====
Comme indiqué, nous ne pouvions plus programmer le microprocesseur. Pour cela , nous avons testé notre code sur la carte du groupe 2 :
[[Fichier:Vidéo moteur dc.mov|vignette|Vidéo du fonctionnement du mini-moteur dc|néant]]Voici le code utilisé pour tester le moteur sur la carte du groupe 2, il ne reste qu'à changer les pins pour convenir à leur structure :<syntaxhighlight lang="c" line="1">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}
int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);
while (1) {
control_motor(1);
_delay_ms(300);
control_motor(0);
inputs_init(imasks, pullup);
}
return 0;
}
</syntaxhighlight>Voici le code final en se basant sur les mêmes fonctions utilisées ci-dessus :<syntaxhighlight lang="c">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}
// The motor here is running anti clock-wise

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}

int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);

while (1) {
// Get the value read by the sensor
unsigned char qre_value = input_get(qre1113gr);

if (qre_value > 0) {
// Infra-red light detected, set everything on
output_set(leds, 0);
output_set(leds, 1);
output_set(leds, 2);
output_set(leds, 3);
control_motor(1);

} else {
// Nothing detected, set everything off
output_unset(leds, 0);
output_unset(leds, 1);
output_unset(leds, 2);
output_unset(leds, 3);
control_motor(0);
}

inputs_init(imasks, pullup); // reset the values

}

return 0;
}
</syntaxhighlight>

Fichier:Fonctionnement capteur.mov

2023-06-04T15:32:48Z

Yelqasta :

Vidéo du fonctionnement du capteur

SE3Binome2022-5

2023-06-04T15:28:16Z

Yelqasta : /* Vidéo en fonctionnement */

== '''<big>Présentation du projet</big>''' ==

=== '''<big>Objectif</big>''' ===
Concevoir un modèle de voiture 1:43 équipée d'un microcontrôleur ATMega16u2 permettant de commander la voiture en se basant sur un programme. Nous avons choisi de rajouter une option de suivi d'une ligne droite, ceci se fera à l'aide d'un capteur QRE1113gr.

=== '''<big>Composants</big>''' ===
les composants à utiliser dans notre projet sont les suivants :

* Un microcontrôleur ATMega16u2
* Un capteur QRE1113gr
* Un mini-moteur à courant continu
* Un pilote du mini-moteur à courant continu (DRV8210DRLR)
* Un micro-moteur glissière pas à pas
* Une batterie LiPo
* Une puce de contrôle de charge de la batterie (MAX1811)
* Des leds pour simuler le système d'éclairage
* Des résistances
* Des capacités
* Un quartz
* Un port USB
*Des diodes
*Un AVR-ISP 6
*Des connecteurs

=== '''<big>Caractéristiques et limites de notre système</big>''' ===

==== caractéristiques ====
Pour comprendre le fonctionnement de suivi de ligne souhaité, il faut d'abord comprendre le fonctionnement du capteur QRE. C'est un capteur de réflexion infrarouge, il est utilisé pour détecter la présence ou l'absence d'objets réfléchissants à proximité. Il se compose d'une LED infrarouge émettant de la lumière infrarouge et d'un phototransistor qui mesure la quantité de lumière réfléchie. Lorsqu'un objet se trouve devant le capteur, il réfléchit la lumière infrarouge émise par la LED vers le phototransistor. Le phototransistor détecte cette lumière réfléchie et génère un courant proportionnel à son intensité. La valeur mesurée par le capteur dépend de la quantité de lumière infrarouge réfléchie par l'objet. Si l'objet est réfléchissant et renvoie une grande quantité de lumière infrarouge, le phototransistor générera un courant plus élevé, ce qui se traduira par une valeur positive lorsqu'elle est lue par le microcontrôleur. En revanche, si aucun objet réfléchissant n'est présent devant le capteur, la quantité de lumière infrarouge réfléchie sera faible. Par conséquent, le phototransistor générera un courant plus faible ou nul, ce qui se traduira par une valeur de capteur égale à zéro lorsqu'elle est lue par le microcontrôleur.

==== Limites ====
Les composants cités ci-dessus étaient soudés et utilisés dans notre carte, sauf la batterie et sa puce de contrôle, les diodes, l'AVR-ISP et quelques capacités de filtrage de bruit ainsi que les connecteurs.

Pour réinitialiser le microprocesseur afin de mettre un nouveau code, il faut à chaque fois utiliser un fil entre la masse et la broche de reset du AVR-ISP. Le rajout d'un bouton aurait était mieux.

Lors du routage de la carte, nous n'avons pas fait attention que le capteur doit être placé en bas, afin de détecter la ligne.

Après avoir fini le code pour tester le mini-moteur dc, nous nous rendons compte que le microprocessur n'est plus détectable en utilisant la commande lsusb. Nous avons vérifié les connections, essayé de changer le port usb mais sans résultat (pourtant que les leds et le capteur marchait bien). Nous avons alors tester le code sur la carte du groupe 2 en ajustant un peu la structure et en supprimant les parties correspondantes au capteur.

=== '''<big>Avancement du projet</big>''' ===

==== le 14/02 : ====
- Compréhension de l'idée directrice du projet

- Recherche de l'option à rajouter

==== le 28/02 : ====
- Début de conception de la schématique

==== le 21/03 : ====
- début du rajout des empreintes des composants

==== le 07/04 : ====
- Fin de la schématique

==== le 13/04 : ====
- Fin du routage de la carte

- Envoi du modèle aux enseignants pour le valider et commander la carte

==== le 02/05: ====
- Réception de la carte

- Soudure de quelques résistances et capacités

==== le 09/05: ====
- Les composants suivants sont déjà soudés par l'enseignant : ATMega16u2, le quartz

- Rajout des leds et des résistances restantes

- Début du code pour tester les leds

==== le 16/05: ====
- Fin du code pour tester les leds

- Réorganisation de la schématique

==== le 23/05: ====
- Soudure du capteur

- Implémentation du code pour tester le capteur

- Soudure du mini-moteur dc

==== le 29/05: ====
- Soudure du micro-moteur pas à pas

- Implémentation du code pour tester le mini-moteur dc

==== le 03/06: ====
- Teste du code de moteur sur la carte du groupe 2

=== '''<big>GIT</big>''' ===
le lien de notre archive GIT : https://archives.plil.fr/yelqasta/pse-g5.git

== '''Conception de la carte électronique''' ==

=== Composants et empreintes créés ===
nous avons créer le symbole du pilote du moteur DC via Kicad :
[[Fichier:Driver.png|vignette|250x250px|centré|Symbole du pilote DRV8210DRLR]]

Après avoir mesurer les dimensions du mini-moteur continu on a pu créer l'empreinte suivante :
[[Fichier:Dc moteur.png|centré|vignette|Empreinte du mini-moteur dc]]

'''schéma'''

Réalisation du schématique du PCB sur le logiciel KiCad : [[Fichier:Schématique de la carte.png|centré|vignette|439x439px|schématique]]lors de la phase de soudure, l'enseignant nous a mentionné que le schéma du capteur n'est pas bon. Nous avons pu corriger le problème avec l'aide de l'enseignant en se basant sur le schéma suivant : https://cdn.sparkfun.com/datasheets/Sensors/Proximity/QRE1113-Digital-Breakout-v11.pdf

=== '''Visual 3D''' ===
[[Fichier:Voiture 3D.png|vignette|502x502px|visualisation 3D de la carte |centré]]

=== '''Routage de la carte''' ===
[[Fichier:Routage de la carte .png|centré|vignette|670x670px|carte routée]]

=== '''Carte imprimée''' ===
la carte imprimée et soudure du capteur, leds, résistances et microcontrôleur ATMega16U2 :
[[Fichier:Carte soudée entièrement.jpg|centré|vignette]]
== '''Premier Test de la carte''' ==
[[Fichier:Test.png|centré|vignette|611x611px|résultat de la commande lsusb]]

== '''Programme''' ==

=== Code de clignotement des Leds ===

==== Vidéo en fonctionnement ====
[[Fichier:Clignotement des Leds.mp4|centré|vignette]]

=== '''Code du suiveur QRE1113GR''' ===

==== Vidéo en fonctionnement ====

== '''Soudure des moteurs''' ==
Nous avons soudé le pilote du mini-moteur dc, le mini-moteur DC et le micro-moteur glissière pas à pas.[[Fichier:Soudure.jpg|gauche|vignette|résultat final 1]]
[[Fichier:Photo.jpg|vignette|néant|505x505px|résultat final 2]]

===== Vidéo du fonctionnement du mini-moteur dc =====
Comme indiqué, nous ne pouvions plus programmer le microprocesseur. Pour cela , nous avons testé notre code sur la carte du groupe 2 :
[[Fichier:Vidéo moteur dc.mov|vignette|Vidéo du fonctionnement du mini-moteur dc|néant]]Voici le code utilisé pour tester le moteur sur la carte du groupe 2, il ne reste qu'à changer les pins pour convenir à leur structure :<syntaxhighlight lang="c" line="1">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}
int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);
while (1) {
control_motor(1);
_delay_ms(300);
control_motor(0);
inputs_init(imasks, pullup);
}
return 0;
}
</syntaxhighlight>Voici le code final en se basant sur les mêmes fonctions utilisées ci-dessus :<syntaxhighlight lang="c">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}
// The motor here is running anti clock-wise

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}

int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);

while (1) {
// Get the value read by the sensor
unsigned char qre_value = input_get(qre1113gr);

if (qre_value > 0) {
// Infra-red light detected, set everything on
output_set(leds, 0);
output_set(leds, 1);
output_set(leds, 2);
output_set(leds, 3);
control_motor(1);

} else {
// Nothing detected, set everything off
output_unset(leds, 0);
output_unset(leds, 1);
output_unset(leds, 2);
output_unset(leds, 3);
control_motor(0);
}

inputs_init(imasks, pullup); // reset the values

}

return 0;
}
</syntaxhighlight>

SE3Binome2022-5

2023-06-04T15:23:23Z

Yelqasta : /* Vidéo du fonctionnement du mini-moteur dc */

== '''<big>Présentation du projet</big>''' ==

=== '''<big>Objectif</big>''' ===
Concevoir un modèle de voiture 1:43 équipée d'un microcontrôleur ATMega16u2 permettant de commander la voiture en se basant sur un programme. Nous avons choisi de rajouter une option de suivi d'une ligne droite, ceci se fera à l'aide d'un capteur QRE1113gr.

=== '''<big>Composants</big>''' ===
les composants à utiliser dans notre projet sont les suivants :

* Un microcontrôleur ATMega16u2
* Un capteur QRE1113gr
* Un mini-moteur à courant continu
* Un pilote du mini-moteur à courant continu (DRV8210DRLR)
* Un micro-moteur glissière pas à pas
* Une batterie LiPo
* Une puce de contrôle de charge de la batterie (MAX1811)
* Des leds pour simuler le système d'éclairage
* Des résistances
* Des capacités
* Un quartz
* Un port USB
*Des diodes
*Un AVR-ISP 6
*Des connecteurs

=== '''<big>Caractéristiques et limites de notre système</big>''' ===

==== caractéristiques ====
Pour comprendre le fonctionnement de suivi de ligne souhaité, il faut d'abord comprendre le fonctionnement du capteur QRE. C'est un capteur de réflexion infrarouge, il est utilisé pour détecter la présence ou l'absence d'objets réfléchissants à proximité. Il se compose d'une LED infrarouge émettant de la lumière infrarouge et d'un phototransistor qui mesure la quantité de lumière réfléchie. Lorsqu'un objet se trouve devant le capteur, il réfléchit la lumière infrarouge émise par la LED vers le phototransistor. Le phototransistor détecte cette lumière réfléchie et génère un courant proportionnel à son intensité. La valeur mesurée par le capteur dépend de la quantité de lumière infrarouge réfléchie par l'objet. Si l'objet est réfléchissant et renvoie une grande quantité de lumière infrarouge, le phototransistor générera un courant plus élevé, ce qui se traduira par une valeur positive lorsqu'elle est lue par le microcontrôleur. En revanche, si aucun objet réfléchissant n'est présent devant le capteur, la quantité de lumière infrarouge réfléchie sera faible. Par conséquent, le phototransistor générera un courant plus faible ou nul, ce qui se traduira par une valeur de capteur égale à zéro lorsqu'elle est lue par le microcontrôleur.

==== Limites ====
Les composants cités ci-dessus étaient soudés et utilisés dans notre carte, sauf la batterie et sa puce de contrôle, les diodes, l'AVR-ISP et quelques capacités de filtrage de bruit ainsi que les connecteurs.

Pour réinitialiser le microprocesseur afin de mettre un nouveau code, il faut à chaque fois utiliser un fil entre la masse et la broche de reset du AVR-ISP. Le rajout d'un bouton aurait était mieux.

Lors du routage de la carte, nous n'avons pas fait attention que le capteur doit être placé en bas, afin de détecter la ligne.

Après avoir fini le code pour tester le mini-moteur dc, nous nous rendons compte que le microprocessur n'est plus détectable en utilisant la commande lsusb. Nous avons vérifié les connections, essayé de changer le port usb mais sans résultat (pourtant que les leds et le capteur marchait bien). Nous avons alors tester le code sur la carte du groupe 2 en ajustant un peu la structure et en supprimant les parties correspondantes au capteur.

=== '''<big>Avancement du projet</big>''' ===

==== le 14/02 : ====
- Compréhension de l'idée directrice du projet

- Recherche de l'option à rajouter

==== le 28/02 : ====
- Début de conception de la schématique

==== le 21/03 : ====
- début du rajout des empreintes des composants

==== le 07/04 : ====
- Fin de la schématique

==== le 13/04 : ====
- Fin du routage de la carte

- Envoi du modèle aux enseignants pour le valider et commander la carte

==== le 02/05: ====
- Réception de la carte

- Soudure de quelques résistances et capacités

==== le 09/05: ====
- Les composants suivants sont déjà soudés par l'enseignant : ATMega16u2, le quartz

- Rajout des leds et des résistances restantes

- Début du code pour tester les leds

==== le 16/05: ====
- Fin du code pour tester les leds

- Réorganisation de la schématique

==== le 23/05: ====
- Soudure du capteur

- Implémentation du code pour tester le capteur

- Soudure du mini-moteur dc

==== le 29/05: ====
- Soudure du micro-moteur pas à pas

- Implémentation du code pour tester le mini-moteur dc

==== le 03/06: ====
- Teste du code de moteur sur la carte du groupe 2

=== '''<big>GIT</big>''' ===
le lien de notre archive GIT : https://archives.plil.fr/yelqasta/pse-g5.git

== '''Conception de la carte électronique''' ==

=== Composants et empreintes créés ===
nous avons créer le symbole du pilote du moteur DC via Kicad :
[[Fichier:Driver.png|vignette|250x250px|centré|Symbole du pilote DRV8210DRLR]]

Après avoir mesurer les dimensions du mini-moteur continu on a pu créer l'empreinte suivante :
[[Fichier:Dc moteur.png|centré|vignette|Empreinte du mini-moteur dc]]

'''schéma'''

Réalisation du schématique du PCB sur le logiciel KiCad : [[Fichier:Schématique de la carte.png|centré|vignette|439x439px|schématique]]lors de la phase de soudure, l'enseignant nous a mentionné que le schéma du capteur n'est pas bon. Nous avons pu corriger le problème avec l'aide de l'enseignant en se basant sur le schéma suivant : https://cdn.sparkfun.com/datasheets/Sensors/Proximity/QRE1113-Digital-Breakout-v11.pdf

=== '''Visual 3D''' ===
[[Fichier:Voiture 3D.png|vignette|502x502px|visualisation 3D de la carte |centré]]

=== '''Routage de la carte''' ===
[[Fichier:Routage de la carte .png|centré|vignette|670x670px|carte routée]]

=== '''Carte imprimée''' ===
la carte imprimée et soudure du capteur, leds, résistances et microcontrôleur ATMega16U2 :
[[Fichier:Carte soudée entièrement.jpg|centré|vignette]]
== '''Premier Test de la carte''' ==
[[Fichier:Test.png|centré|vignette|611x611px|résultat de la commande lsusb]]

== '''Programme''' ==

=== Code de clignotement des Leds ===

==== Vidéo en fonctionnement ====
[[Fichier:Clignotement des Leds.mp4|centré|vignette]]

=== '''Code du suiveur QRE1113GR''' ===

==== Vidéo en fonctionnement ====
[[Fichier:Test du capteur.mp4|centré|vignette]]

== '''Soudure des moteurs''' ==
Nous avons soudé le pilote du mini-moteur dc, le mini-moteur DC et le micro-moteur glissière pas à pas.[[Fichier:Soudure.jpg|gauche|vignette|résultat final 1]]
[[Fichier:Photo.jpg|vignette|néant|505x505px|résultat final 2]]

===== Vidéo du fonctionnement du mini-moteur dc =====
Comme indiqué, nous ne pouvions plus programmer le microprocesseur. Pour cela , nous avons testé notre code sur la carte du groupe 2 :
[[Fichier:Vidéo moteur dc.mov|vignette|Vidéo du fonctionnement du mini-moteur dc|néant]]Voici le code utilisé pour tester le moteur sur la carte du groupe 2, il ne reste qu'à changer les pins pour convenir à leur structure :<syntaxhighlight lang="c" line="1">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}
int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);
while (1) {
control_motor(1);
_delay_ms(300);
control_motor(0);
inputs_init(imasks, pullup);
}
return 0;
}
</syntaxhighlight>Voici le code final en se basant sur les mêmes fonctions utilisées ci-dessus :<syntaxhighlight lang="c">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}
// The motor here is running anti clock-wise

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}

int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);

while (1) {
// Get the value read by the sensor
unsigned char qre_value = input_get(qre1113gr);

if (qre_value > 0) {
// Infra-red light detected, set everything on
output_set(leds, 0);
output_set(leds, 1);
output_set(leds, 2);
output_set(leds, 3);
control_motor(1);

} else {
// Nothing detected, set everything off
output_unset(leds, 0);
output_unset(leds, 1);
output_unset(leds, 2);
output_unset(leds, 3);
control_motor(0);
}

inputs_init(imasks, pullup); // reset the values

}

return 0;
}
</syntaxhighlight>

SE3Binome2022-5

2023-06-04T15:13:15Z

Yelqasta : /* Soudure des moteurs */

== '''<big>Présentation du projet</big>''' ==

=== '''<big>Objectif</big>''' ===
Concevoir un modèle de voiture 1:43 équipée d'un microcontrôleur ATMega16u2 permettant de commander la voiture en se basant sur un programme. Nous avons choisi de rajouter une option de suivi d'une ligne droite, ceci se fera à l'aide d'un capteur QRE1113gr.

=== '''<big>Composants</big>''' ===
les composants à utiliser dans notre projet sont les suivants :

* Un microcontrôleur ATMega16u2
* Un capteur QRE1113gr
* Un mini-moteur à courant continu
* Un pilote du mini-moteur à courant continu (DRV8210DRLR)
* Un micro-moteur glissière pas à pas
* Une batterie LiPo
* Une puce de contrôle de charge de la batterie (MAX1811)
* Des leds pour simuler le système d'éclairage
* Des résistances
* Des capacités
* Un quartz
* Un port USB
*Des diodes
*Un AVR-ISP 6
*Des connecteurs

=== '''<big>Caractéristiques et limites de notre système</big>''' ===

==== caractéristiques ====
Pour comprendre le fonctionnement de suivi de ligne souhaité, il faut d'abord comprendre le fonctionnement du capteur QRE. C'est un capteur de réflexion infrarouge, il est utilisé pour détecter la présence ou l'absence d'objets réfléchissants à proximité. Il se compose d'une LED infrarouge émettant de la lumière infrarouge et d'un phototransistor qui mesure la quantité de lumière réfléchie. Lorsqu'un objet se trouve devant le capteur, il réfléchit la lumière infrarouge émise par la LED vers le phototransistor. Le phototransistor détecte cette lumière réfléchie et génère un courant proportionnel à son intensité. La valeur mesurée par le capteur dépend de la quantité de lumière infrarouge réfléchie par l'objet. Si l'objet est réfléchissant et renvoie une grande quantité de lumière infrarouge, le phototransistor générera un courant plus élevé, ce qui se traduira par une valeur positive lorsqu'elle est lue par le microcontrôleur. En revanche, si aucun objet réfléchissant n'est présent devant le capteur, la quantité de lumière infrarouge réfléchie sera faible. Par conséquent, le phototransistor générera un courant plus faible ou nul, ce qui se traduira par une valeur de capteur égale à zéro lorsqu'elle est lue par le microcontrôleur.

==== Limites ====
Les composants cités ci-dessus étaient soudés et utilisés dans notre carte, sauf la batterie et sa puce de contrôle, les diodes, l'AVR-ISP et quelques capacités de filtrage de bruit ainsi que les connecteurs.

Pour réinitialiser le microprocesseur afin de mettre un nouveau code, il faut à chaque fois utiliser un fil entre la masse et la broche de reset du AVR-ISP. Le rajout d'un bouton aurait était mieux.

Lors du routage de la carte, nous n'avons pas fait attention que le capteur doit être placé en bas, afin de détecter la ligne.

Après avoir fini le code pour tester le mini-moteur dc, nous nous rendons compte que le microprocessur n'est plus détectable en utilisant la commande lsusb. Nous avons vérifié les connections, essayé de changer le port usb mais sans résultat (pourtant que les leds et le capteur marchait bien). Nous avons alors tester le code sur la carte du groupe 2 en ajustant un peu la structure et en supprimant les parties correspondantes au capteur.

=== '''<big>Avancement du projet</big>''' ===

==== le 14/02 : ====
- Compréhension de l'idée directrice du projet

- Recherche de l'option à rajouter

==== le 28/02 : ====
- Début de conception de la schématique

==== le 21/03 : ====
- début du rajout des empreintes des composants

==== le 07/04 : ====
- Fin de la schématique

==== le 13/04 : ====
- Fin du routage de la carte

- Envoi du modèle aux enseignants pour le valider et commander la carte

==== le 02/05: ====
- Réception de la carte

- Soudure de quelques résistances et capacités

==== le 09/05: ====
- Les composants suivants sont déjà soudés par l'enseignant : ATMega16u2, le quartz

- Rajout des leds et des résistances restantes

- Début du code pour tester les leds

==== le 16/05: ====
- Fin du code pour tester les leds

- Réorganisation de la schématique

==== le 23/05: ====
- Soudure du capteur

- Implémentation du code pour tester le capteur

- Soudure du mini-moteur dc

==== le 29/05: ====
- Soudure du micro-moteur pas à pas

- Implémentation du code pour tester le mini-moteur dc

==== le 03/06: ====
- Teste du code de moteur sur la carte du groupe 2

=== '''<big>GIT</big>''' ===
le lien de notre archive GIT : https://archives.plil.fr/yelqasta/pse-g5.git

== '''Conception de la carte électronique''' ==

=== Composants et empreintes créés ===
nous avons créer le symbole du pilote du moteur DC via Kicad :
[[Fichier:Driver.png|vignette|250x250px|centré|Symbole du pilote DRV8210DRLR]]

Après avoir mesurer les dimensions du mini-moteur continu on a pu créer l'empreinte suivante :
[[Fichier:Dc moteur.png|centré|vignette|Empreinte du mini-moteur dc]]

'''schéma'''

Réalisation du schématique du PCB sur le logiciel KiCad : [[Fichier:Schématique de la carte.png|centré|vignette|439x439px|schématique]]lors de la phase de soudure, l'enseignant nous a mentionné que le schéma du capteur n'est pas bon. Nous avons pu corriger le problème avec l'aide de l'enseignant en se basant sur le schéma suivant : https://cdn.sparkfun.com/datasheets/Sensors/Proximity/QRE1113-Digital-Breakout-v11.pdf

=== '''Visual 3D''' ===
[[Fichier:Voiture 3D.png|vignette|502x502px|visualisation 3D de la carte |centré]]

=== '''Routage de la carte''' ===
[[Fichier:Routage de la carte .png|centré|vignette|670x670px|carte routée]]

=== '''Carte imprimée''' ===
la carte imprimée et soudure du capteur, leds, résistances et microcontrôleur ATMega16U2 :
[[Fichier:Carte soudée entièrement.jpg|centré|vignette]]
== '''Premier Test de la carte''' ==
[[Fichier:Test.png|centré|vignette|611x611px|résultat de la commande lsusb]]

== '''Programme''' ==

=== Code de clignotement des Leds ===

==== Vidéo en fonctionnement ====
[[Fichier:Clignotement des Leds.mp4|centré|vignette]]

=== '''Code du suiveur QRE1113GR''' ===

==== Vidéo en fonctionnement ====
[[Fichier:Test du capteur.mp4|centré|vignette]]

== '''Soudure des moteurs''' ==
Nous avons soudé le pilote du mini-moteur dc, le mini-moteur DC et le micro-moteur glissière pas à pas.[[Fichier:Soudure.jpg|gauche|vignette|résultat final 1]]
[[Fichier:Photo.jpg|vignette|néant|505x505px|résultat final 2]]

===== Vidéo du fonctionnement du mini-moteur dc =====
Comme indiqué, nous ne pouvions plus programmer le microprocesseur. Pour cela , nous avons testé notre code sur la carte du groupe 2 :
[[Fichier:Vidéo moteur dc.mov|vignette|gauche|Vidéo du fonctionnement du mini-moteur dc]]<syntaxhighlight lang="c" line="1">
#include "io.h"
#include <util/delay.h>

#define MAX_LED 4

#define PORTB_OUTPUT 0x50
#define PORTC_OUTPUT 0x84
#define PORTD_OUTPUT 0x01

unsigned char led1[] = {0x00, 0x80, 0x00}; // PC7
unsigned char led5[] = {0x40, 0x00, 0x00}; // PB6
unsigned char led6[] = {0x10, 0x00, 0x00}; // PB4
unsigned char led8[] = {0x00, 0x04, 0x00}; // PC2
unsigned char *leds[] = {led1, led5, led6, led8};

unsigned char qre1113gr[] = {0x01, 0x00, 0x00}; // PD0

#define PORTB_INPUT 0x00
#define PORTC_INPUT 0x00
#define PORTD_INPUT 0x00

void control_motor(int enable) {
// Set appropriate signals for motor control using DRV8210DRLR
if (enable) {
// Enable the motor in the desired direction (e.g., set appropriate motor pins high/low)
PORTC |= (1 << PC6); // Set PC6 high
PORTB &= ~(1 << PB7); // Set PB7 low
} else {
// Disable the motor (e.g., set all motor pins low)
PORTC &= ~(1 << PC6); // Set PC6 low
PORTB &= ~(1 << PB7); // Set PB7 low
}
}

unsigned char input_get(unsigned char *pin) {
unsigned char port_num = pin[0] >> 4; // Extract the port number from the pin value
unsigned char pin_num = pin[0] & 0x0F; // Extract the pin number from the pin value

switch (port_num) {
case 0: // PORTB
return (PINB >> pin_num) & 0x01;
case 1: // PORTC
return (PINC >> pin_num) & 0x01;
case 2: // PORTD
return (PIND >> pin_num) & 0x01;
default:
return 0; // Invalid port number
}
}
int main(void) {
unsigned char imasks[] = {PORTB_INPUT, PORTC_INPUT, PORTD_INPUT};
unsigned char pullup[] = {0x00, 0x00, 0x01};
inputs_init(imasks, pullup);
unsigned char omasks[] = {PORTB_OUTPUT, PORTC_OUTPUT, PORTD_OUTPUT};
outputs_init(omasks);
while (1) {
control_motor(1);
_delay_ms(300);
control_motor(0);
inputs_init(imasks, pullup);
}
return 0;
}
</syntaxhighlight>

SE3Binome2022-5

2023-06-04T15:02:30Z

Yelqasta : /* Conception de la carte électronique */

Fichier:Vidéo moteur dc.mov

2023-06-04T15:01:54Z

Yelqasta :

Vidéo du moteur dc

SE3Binome2022-5

2023-06-04T14:39:20Z

Yelqasta : /* Limites */

SE3Binome2022-5

2023-06-04T14:25:52Z

Yelqasta : /* le 02/05: */

SE3Binome2022-5

2023-06-04T14:08:09Z

Yelqasta : /* Présentation du projet */

SE3Binome2022-5

2023-06-04T12:51:21Z

Yelqasta : /* Composants */

SE3Binome2022-5

2023-06-04T11:51:25Z

Yelqasta : /* Présentation du projet */

SE3Binome2022-5

2023-06-04T11:44:33Z

Yelqasta : /* Objectif */

== '''Présentation du projet''' ==

=== '''Objectif''' ===
Concevoir un modèle de voiture 1:43 équipée d'un microcontrôleur ATMega16u2 permettant de commander la voiture en se basant sur un programme. Nous avons choisi de rajouter une option de suivi de ligne.

'''<big>Composants</big>'''

les composants à utiliser dans notre projet sont les suivants :

* Un microcontrôleur ATMega16u2
* Un capteur QRE1113gr
* Un mini-moteur à courant continu
* Un pilote du mini-moteur à courant continu (DRV8210DRLR)
* Un micro-moteur glissière pas à pas
* Une batterie LiPo
* Une puce de contrôle de charge de la batterie (MAX1811)
* Des leds pour simuler le système d'éclairage
* Des résistances
* Des capacités
* Un port USB

=== '''Caractéristiques de notre système''' ===

=== '''GIT''' ===
l'URL HTTPS de l'archive GIT : https://archives.plil.fr/yelqasta/pse-g5.git

== '''Conception de la carte électronique''' ==

=== Composants et empreintes créés ===
nous avons créer la schématique du Driver du moteur DC via Kicad :
[[Fichier:Driver.png|vignette|250x250px|centré]]

Après avoir mesurer les dimensions du capteur continu avec réducteur on a pu créer l'empreinte:
[[Fichier:Dc moteur.png|centré|vignette]]

'''schéma'''

Réalisation du schématique du PCB sur le logiciel KiCad : [[Fichier:Schématique de la carte.png|centré|vignette|439x439px|schématique]]

=== '''Visual 3D''' ===
[[Fichier:Voiture 3D.png|vignette|502x502px|visualisation de la carte |centré]]

=== '''Routage de la carte''' ===
[[Fichier:Routage de la carte .png|centré|vignette|670x670px|carte routée]]

=== '''Carte imprimée''' ===
la carte imprimée et soudure du capteur, leds, résistances et microcontrôleur ATmega16U2 :
[[Fichier:Carte soudée entièrement.jpg|centré|vignette]]
== '''Premier Test de la carte''' ==
[[Fichier:Test.png|centré|vignette|611x611px|la commande lsusb]]

== '''Programme''' ==

=== Code de clignotement des Leds ===

==== Vidéo en fonctionnement ====
[[Fichier:Clignotement des Leds.mp4|centré|vignette]]

=== '''Code du suiveur QRE1113GR''' ===

==== Vidéo en fonctionnement ====
[[Fichier:Test du capteur.mp4|centré|vignette]]

== '''Soudure des moteurs''' ==
Nous avons soudé le driver, le moteur DC et le Micro-moteur glissière pas à pas.[[Fichier:Soudure.jpg|gauche|vignette]]
[[Fichier:Photo.jpg|vignette]]

Fichier:Schématique de la carte.png

2023-06-03T20:57:58Z

Yelqasta : Yelqasta a téléversé une nouvelle version de Fichier:Schématique de la carte.png

schema

Fichier:Schématique de la carte.png

2023-06-03T20:45:54Z

Yelqasta : Yelqasta a annulé Fichier:Schématique de la carte.png vers une ancienne version

schema

Fichier:Schématique de la carte.png

2023-06-03T20:44:44Z

Yelqasta : Yelqasta a téléversé une nouvelle version de Fichier:Schématique de la carte.png

schema

PSE SE3 2022/2023

2023-04-12T06:26:54Z

Yelqasta : /* Réalisation "programmateur AVR" */

= Objectif =

Pour l'année académique 2022/2023 il demandé de motoriser un modèle réduit de voiture au 1:87ème ou au 1:43ème avec contrôle par microcontrôleur.

Votre objectif est de concevoir votre propre modèle à l'aide des éléments présentés dans cette page. Vous ne devez pas forcément fusionner l'ensemble
des possibilités, d'ailleurs certaines sont incompatibles entre elles. Partir sur quelque chose de simple n'est pas infamant du moment qu'il est proprement exécuté et qu'il débouche sur un prototype fonctionnel.

Certes si vous nous sortez une voiture au 1:87ème totalement fonctionnelle avec propulsion, roues avant directionnelles, chargeur de batterie intégré et contrôle radio nous serons enchantés et nous aurons assez peu de difficulté à vous noter. Maintenant si vous partez sur un simple chassis au 1:43ème avec propulsion utilisant de simples poulies, roue folle permettant des reculs avec virage (axe de roue non fixe) et contrôle par programmation, vous aurez rempli le contrat.

= Mécanique =

La partie mécanique n'est pas évaluée dans ce projet car elle est hors-sujet pour la filière. Par contre, une démonstration avec une voiture mobile est un excellent moyen de prouver que votre projet fonctionne.

[[file:2022-chassis.png|thumb|400px|right|Image du chassis]]

Pour vous aider nous avons modélisé un chassis avec roues avant directionnelles.

<gallery>
file:2022-chassis-dessus.pdf|Chassis vu de dessus
file:2022-chassis-dessous.pdf|Chassis vu de dessous
file:2022-chassis-cote-1.pdf|Chassis vu de coté
file:2022-chassis-cote-2.pdf|Chassis vu d'un autre coté
</gallery>

Le fichier <code>freeCAD</code> du chassis [[file:chassis-2022.tar]].

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

Seconde version de chassis.

[[file:2022-chassis2.png|thumb|400px|right|Image du chassis]]

Pour vous aider nous avons modélisé un chassis avec roues avant directionnelles.

<gallery>
file:2022-chassis2-dessus.pdf|Chassis vu de dessus
file:2022-chassis2-dessous.pdf|Chassis vu de dessous
file:2022-chassis2-cote-1.pdf|Chassis vu de coté
file:2022-chassis2-cote-2.pdf|Chassis vu d'un autre coté
</gallery>

Le fichier <code>freeCAD</code> du chassis [[file:chassis2-2022.tar]].

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

[[file:2022-roue_folle.png|thumb|200px|right|Image de la roue]]

Vous avez aussi un modèle de principe pour une roue folle avec recul en virant.

<gallery>
file:2022-roue-folle.pdf|Roue en 3D
</gallery>

Le fichier <code>freeCAD</code> de la roue [[file:roue-folle-2022.tar]].

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

Au niveau accessoires vous pouvez, ou pourrez, disposer des éléments suivants :
* engrenages métal pour axe 0.7mm, disponibles et semblent s'adapter aux micro-moteurs simples ;
* vis sans fin métal pour axe de 1mm (diamètre extérieur 3,8mm), disponibles, prévues pour l'axe des voitures 1:87 ;
* vis sans fil plastique pour axe 2mm, disponibles mais s'adaptent mal aux axes des voitures 1:43 ;
* vis sans fil plastique pour axe <2mm, disponibles, prévues pour l'axe des voitures 1:43 ;
* engrenages plastiques pour axe de 3mm, disponibles, pour les moteurs continus.

= Moteurs =

La commande des moteurs n'est pas, elle, optionnelle.

Plusieurs types de moteurs sont disponibles.

<gallery>
File:micro-moteur-pas-a-pas-simple.jpg|Micro-moteur pas à pas propulsion
File:micro-moteur-pas-a-pas-simple-dims.jpg|Dimensions du micro-moteur propulsion
File:micro-glissiere-pas-a-pas.jpg|Micro-moteur glissière pas à pas
File:micro-glissiere-pas-a-pas-dimensions.jpg|Dimensions du micro-moteur glissière
File:micro-glissiere-pas-a-pas-connecteurs.jpg|Connecteurs du micro-moteur glissière
File:mini-motoreducteur.jpg|Mini-moteur continu avec réducteur
File:pilote-motoreducteur.jpg|Pilote pour le mini-moteur continu (DRV8210DRLR)
</gallery>

[[file:2022-banc-essai-micro-moteurs.jpg|thumb|250px|right|Banc d'essai des micro-moteurs]]

Ressources pour les moteurs :
* les micro-moteurs peuvent éventuellement fonctionner sans pilote (alimentation directe par le microcontrôleur), il reste à vérifier que le couple obtenu suffit et que l'utilisation de plusieurs périphériques n'effondre pas le microcontrôleur ;
* empreintes approximatives pour les microcontrôleurs (à peaufiner) : [[file:KiCAD-lib-micro-motors.tar]] ;
* premier jet du PCB de coté pour le micro-moteur glissière : [[file:KiCAD-slider-side-2022.tar]] ;
* programme C pour les micro-moteurs pas à pas sans pilote (vidéo de démonstration ci-dessous) : [[Média:Programme_moteur_pap.tar]].

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

[[file:2022-demo-micro-moteur.mp4|500px|left|Vidéo pour le micro-moteur]]
[[file:2022-demo-micro-slider.mp4|500px|right|Vidéo pour le micro-moteur glissière]]

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

= Cartes électroniques =

Vous devez concevoir une carte électronique pour contrôler la voiture. La conception doit se faire en utilisant le logiciel KiCAD.

Il est recommandé de reporter au maximum les fonctions mécaniques sur la carte. Le chassis peut ainsi être entièrement constitué de PCB, y compris les pièces mobiles.

Nous vous donnons deux exemples de schémas électroniques.

== Exemple de carte pour la voiture au 1:87 ==

Le schéma électronique de la carte :
[[file:2022-schema-voiture-rex.pdf|thumb|400px|center|Schéma pour une voiture 1:87]]
Dans le schéma vous pouvez trouver les fonctionnalités suivantes :
* une alimentation avec un régulateur pour passer du 5V USB à une tension de 3.3V mais aussi avec un dispositif pour sélectionner une alimentation par USB ou par batterie ;
* le microcontrôleur avec son horloge mais aussi son connecteur de programmation ISP et le connecteur USB ;
* un dispositif de recharge de la batterie LiPo avec une entrée pour tester la tension de la batterie (sur une entrée numérique donc avec peu de sensibilité) ;
* deux moteurs pas à pas et un système d'éclairage ;
* enfin un module de communication radio.

Après le routage les cartes suivantes sont obtenues.
[[file:2022-PCB-voiture-rex.pdf|thumb|400px|center|Cartes pour une voiture 1:87]]

Un total de 8 cartes sont prévues :
* principalement la carte chassis sur laquelle sont implantés les puces microcontrôleur, charge de LiPo et communication radio ;
* le moteur-glissière nécessite une micro-carte de côté pour récupérer les phases ;
* tous les composants ne tiennent pas sur le chassis 50x20mm, une carte fille est donc prévue pour porter l'éclairage, l'antenne radio et même des pistes supplémentaires ;
* 3 petites cartes sont dédiées pour recevoir les roues : deux pour les roues directionnelles et une pour le train arrière, sur ces cartes doivent êtres soudés des morceaux de tube de cuivre recevant les axes ;
* toujours sur le principe que la carte principale ne permet pas de recevoir tous les éléments, une carte fille permet de connecter l'ISP et une autre l'USB.

Les cartes ont été commandées. En aucun cas il est prévu que ces cartes fonctionnent dans leur version initiale. C'est d'ailleurs la démarche "bureau d'études" que nous souhaitons que vous assimiliez. Ces cartes vont permettre d'avancer dans le projet pour éventuellement aboutir sur une seconde version des cartes. Ci-dessous sont listés les points que les premières cartes vont permettre d'éclaircir.
* Le microcontrôleur devrait fonctionner mais le principe des cartes filles pour la programmation ISP et DFU/USB est à valider.
* Il y a peu de chances pour que les empreintes pour les micro-moteurs pas à pas soient exactes mais ce devrait être une bonne base pour aboutir à une seconde version fonctionnelle.
* L'aspect mécanique est aussi à tester et à corriger : les roues directionnelles fonctionnent-elles ? quels problèmes sont rencontrés pour la transmission de la propulsion via l'engrenage et la vis sans fin.
* Le dispositif d'alimentation par USB ou par batterie est-il fonctionnel ? Le test de tension de la batterie donne-t-il quelque chose ? La recharge de la batterie par le MAX1811 marche-t-elle ?
* La transmission radio est-elle fonctionnelle ? En particulier les libertés prises au niveau de l'antenne sur PCB dégradent-elles beaucoup cette transmission ?

Les sources pour le logiciel KiCAD version 5.1 : [[Média:2022-voiture-kicad-rex.tgz|Fichiers KiCAD pour la voiture 1:87]].

Uniquement les sources pour les empreintes des moteurs pas à pas (modifiées) : [[Média:Rex-motors.zip|Empreintes KiCAD pour les moteurs pas à pas]].

== Exemple de carte pour la voiture au 1:43 ==

[[file:2022-schema-voiture-boe.pdf|thumb|400px|right|Schéma pour une voiture 1:43]]

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

== Le microcontrôleur ==

Vous utiliserez un microcontrôleur ATMega16u2 comme coeur de votre circuit imprimé. Prenez exemple sur la partie microcontrôleur des schémas fournis.

La programmation du microcontrôleur se fera par DFU USB.

== Energie ==

La carte électronique de votre voiture est alimentée par une batterie LiPo. La batterie peut être chargée en utilisant une puce MAX1811. Voir les schémas fournis pour avoir une idée de commencer utiliser une puce MAX1811.

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

Les connecteurs adaptés aux batteries FQ777 ont aussi été commandés (micro JST 2 broches 1.25mm).

== Eclairage ==

Vous pouvez vous lâcher sur les LED pour simuler les dispositifs lumineux de votre voiture. Attention cependant votre micro-contrôleur n'a qu'un nombre limité de sorties.

== Contrôle de la voiture ==

=== Contrôle par programmation ===

Il est recommandé d'utiliser la fonctionnalité USB pour pouvoir programmer le comportement de la voiture. A défaut une programmation par port série est acceptable. Le programme PC permettant d'envoyer la suite d'instructions que la voiture doit réaliser est aussi à votre charge.

=== Radio-contrôle ===

Vous avez deux possibilités pour la commande à distance de votre voiture, soit une communication radio classique, soit une communication BlueTooth.

<gallery>
File:module_nrf24L01.jpg|Module de communication 2,4Ghz
File:module_BLE.jpg|Module Bluetooth Low Energy
</gallery>

Les modules RF 2,4Ghz utilisent une puce NRF24L01, ces modules étant un peu encombrants, quelques puces ont été commandées pour intégration directe sur le PCB (disponibilité fin février). Vous avez un exemple d'utilisation sur le premier schéma de carte fourni plus haut. Les puces NRF24L01 doivent être alimentées en 3,3V mais ses E/S sont compatibles 5V. Il n'est donc pas obligatoire de passer l'ATMega16u2 en 3,3V.

= Réalisation des groupes =

{| class="wikitable"
! Numéro !! Elèves !! Page
|-
| Trinôme 1
| Sarra BEZZINE & Heriniaina ANDRIANIRINTSOA & Imen MLIKA
| [[SE3Binome2022-1|Trinôme 1 2022/2023]]
|-
| Trinôme 2
| Younes BENMBAREK & Camille CARIAT & Abdel ZONGO
| [[SE3Trinome2022-2|Trinôme 2 2022/2023]]
|-
| Binôme 3
| Simon CRUCHET & Amaury BECQUET
| [[SE3Binome2022-3|Binôme 3 2022/2023]]
|-
| Binôme 4
| Romain DUHR & Louis DERYCKERE
| [[SE3Binome2022-4|Binôme 4 2022/2023]]
|-
| Binôme 5
| Youness EL QASTALANI & Chaymae Rhanim
| [[SE3Binome2022-5|Binôme 5 2022/2023]]
|-
| Trinôme 6
| Stephane KADER ISSACK & Marion NORMAND & Amaury DA PONTE
| [[SE3Trinome2022-6|Trinôme 6 2022/2023]]
|-
| Binôme 7
| Alexandre BRASSEUR & Louis WIJSMAN
| [[SE3Binome2022-7|Binôme 7 2022/2023]]
|-
| Trinôme 8
| Némo CAZIN & Antoine CEGARRA & Adrien PALIFERRO
| [[SE3Trinome2022-8|Trinôme 8 2022/2023]]
|-
| Binôme 9
| Thomas NAVE & Thibault DUYCK
| [[SE3Binome2022-9|Binôme 9 2022/2023]]
|-
| Monôme 10
| Adrien GONTIER
| [[SE3Monome2022-10|Monôme 10 2022/2023]]
|-
| Binôme 11
| Taha NEHARI & Martin CHAUVELIERE
| [[SE3Binome2022-11|Binôme 11 2022/2023]]
|-
|}
Absents :
* Imen MLIKA
* Ababacar sadikh NDOYE

= Réalisation "programmateur AVR" =

Utilisez ces pages pour :
* indiquer l'URL HTTPS de votre archive GIT sur laquelle trouver le projet KiCAD et les programmes C (LUFA et libusb) ;
* un schéma 3D de votre PCB ;
* une photo de la carte soudée ;
* une très courte vidéo de la carte avec les LED clignotantes ;
* une copie écran montrant l'affichage de la communication entre votre programme libusb, votre carte et le microcontrôleur AVR.

{| class="wikitable"
! Numéro !! Elèves !! Page
|-
| Binôme 1
| Simon CRUCHET & Amaury BECQUET
| [[SE3_PSE_Binome2022-1|Binôme 1 2022/2023]]
|-
| Binôme 2
| Romain DUHR & Louis DERYCKÈRE
| [[SE3_PSE_Binome2022-2|Binôme 2 2022/2023]]
|-
| Binôme 3
| Chaymae RHANIM & Heriniaina ANDRIANIRINTSOA
| [[SE3_PSE_Binome2022-3|Binôme 3 2022/2023]]
|-
| Binôme 4
| Stéphane Kader Issack & Marion Normand
| [[SE3_PSE_Binome2022-4|Binôme 4 2022/2023]]
|-
| Binôme 5
| Thomas NAVE & Thibault DUYCK
| [[SE3_PSE_Binome2022-5|Binôme 5 2022/2023]]
|-
| Binôme 6
| Amaury Da Ponte
| [[SE3_PSE_Binome2022-6|Binôme 6 2022/2023]]
|-
| Binôme 7
| Sarra Bezzine & Imen MLika
| [[SE3_PSE_Binome2022-7|Binôme 7 2022/2023]]
|-
| Binôme 8
| Némo CAZIN & Antoine CEGARRA
| [[SE3_PSE_Binome2022-8|Binôme 8 2022/2023]]
|-
| Binôme 9
| Alexandre BRASSEUR & Louis WIJSMAN
| [[SE3_PSE_Binome2022-9|Binôme 9 2022/2023]]
|-
| Binôme 10
| Taha NEHARI & Martin CHAUVELIERE
| [[SE3_PSE_Binnome2022-10|Binôme 10 2022/2023]]
|-
| Binôme 11
| Younes BENMBAREK & Abdel ZONGO
| [[SE3_PSE_Binome2022-11|Binôme 11 2022/2023]]
|-
|Monôme 12
|Camille Cariat
|[[SE3_PSE_Binome2022-12|Monôme 12 2022/2023]]
|-
|Binôme 13
|Youness EL QASTALANI & Adrien PALIFERRO
|[[Binôme 13 2022/2023]]
|}

SE3Binome2022-5

2023-02-14T14:52:04Z

Yelqasta :

Initial idea :

automated parking system

Approach :

* Line Follower system
* Using a ToF sensor
useful links:

https://docs.rs-online.com/29df/A700000008343421.pdf?cm_mmc=FR-3P-_-SURF-_-DTC_087_0223_SE-_-STMicroelectronics

https://www.academia.edu/32137948/Etude_et_realisation_d_un_robot_suiveur_de_ligne_part

SE3Binome2022-5

2023-02-14T14:48:27Z

Yelqasta : premières idées

Initial idea :

automated parking system

Approach :

* Line Follower system
* Using a ToF sensor

PSE SE3 2022/2023

2023-02-14T13:55:04Z

Yelqasta : /* Réalisation des binômes */

= Objectif =

Pour l'année académique 2022/2023 il demandé de motoriser un modèle réduit de voiture au 1:87ème ou au 1:43ème avec contrôle par microcontrôleur.

<gallery>
File:modele-voiture-1-87.jpg|Modéle réduit au 1:87
File:modele-voiture-1-43.jpg|Modéle réduit au 1:43
</gallery>

Votre objectif est de concevoir votre propre modèle à l'aide des éléments présentés dans cette page. Vous ne devez pas forcément fusionner l'ensemble
des possibilités, d'ailleurs certaines sont incompatibles entre elles. Partir sur quelque chose de simple n'est pas infamant du moment qu'il est proprement exécuté et qu'il débouche sur un prototype fonctionnel.

Certes si vous nous sortez une voiture au 1:87ème totalement fonctionnelle avec propulsion, roues avant directionnelles, chargeur de batterie intégré et contrôle radio nous serons enchantés et nous aurons assez peu de difficulté à vous noter. Maintenant si vous partez sur un simple chassis au 1:43ème avec propulsion utilisant de simples poulies, roue folle permettant des reculs avec virage (axe de roue non fixe) et contrôle par programmation, vous aurez rempli le contrat.

= Mécanique =

La partie mécanique n'est pas évaluée dans ce projet car elle est hors-sujet pour la filière. Par contre, une démonstration avec une voiture mobile est un excellent moyen de prouver que votre projet fonctionne.

[[file:2022-chassis.png|thumb|400px|right|Image du chassis]]

Pour vous aider nous avons modélisé un chassis avec roues avant directionnelles.

<gallery>
file:2022-chassis-dessus.pdf|Chassis vu de dessus
file:2022-chassis-dessous.pdf|Chassis vu de dessous
file:2022-chassis-cote-1.pdf|Chassis vu de coté
file:2022-chassis-cote-2.pdf|Chassis vu d'un autre coté
</gallery>

Le fichier <code>freeCAD</code> du chassis [[file:chassis-2022.tar]].

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

[[file:2022-roue_folle.png|thumb|200px|right|Image de la roue]]

Vous avez aussi un modèle de principe pour une roue folle avec recul en virant.

<gallery>
file:2022-roue-folle.pdf|Roue en 3D
</gallery>

Le fichier <code>freeCAD</code> de la roue [[file:roue-folle-2022.tar]].

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

Au niveau accessoires vous pouvez, ou pourrez, disposer des éléments suivants :
* engrenages métal pour axe 0.7mm, disponibles et semblent s'adapter aux micro-moteurs simples ;
* vis sans fil plastique pour axe 2mm, disponibles mais s'adaptent mal aux axes des voitures 1:43 ;
* vis sans fin 3,8mm pour axe de 1mm, "en cours de livraison", prévues pour l'axe des voitures 1:87 ;
* divers engrenages plastiques pour les voitures 1:43, arrivés en france ;
* engrenages plastique pour axe de 1mm (voitures 1:43), arrivés en france.

= Moteurs =

La commande des moteurs n'est pas, elle, optionnelle.

Plusieurs types de moteurs sont disponibles.

<gallery>
File:micro-moteur-pas-a-pas-simple.jpg|Micro-moteur pas à pas propulsion
File:micro-moteur-pas-a-pas-simple-dims.jpg|Dimensions du micro-moteur propulsion
File:micro-glissiere-pas-a-pas.jpg|Micro-moteur glissière pas à pas
File:micro-glissiere-pas-a-pas-dimensions.jpg|Dimensions du micro-moteur glissière
File:micro-glissiere-pas-a-pas-connecteurs.jpg|Connecteurs du micro-moteur glissière
File:mini-motoreducteur.jpg|Mini-moteur continu avec réducteur
File:pilote-motoreducteur.jpg|Pilote pour le mini-moteur continu (DRV8210DRLR)
</gallery>

[[file:2022-banc-essai-micro-moteurs.jpg|thumb|250px|right|Banc d'essai des micro-moteurs]]

Ressources pour les moteurs :
* les micro-moteurs peuvent éventuellement fonctionner sans pilote (alimentation directe par le microcontrôleur), il reste à vérifier que le couple obtenu suffit et que l'utilisation de plusieurs périphériques n'effondre pas le microcontrôleur ;
* empreintes approximatives pour les microcontrôleurs (à peaufiner) : [[file:KiCAD-lib-micro-motors.tar]] ;
* premier jet du PCB de coté pour le micro-moteur glissière : [[file:KiCAD-slider-side-2022.tar]] ;
* programme C pour les micro-moteurs pas à pas sans pilote (vidéo de démonstration ci-dessous) : [[Média:Programme_moteur_pap.tar]].

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

[[file:2022-demo-micro-moteur.mp4|500px|left|Vidéo pour le micro-moteur]]
[[file:2022-demo-micro-slider.mp4|500px|right|Vidéo pour le micro-moteur glissière]]

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

= Carte électronique =

Vous devez concevoir une carte électronique pour contrôler la voiture. La conception doit se faire en utilisant le logiciel KiCAD.

Il est recommandé de reporter au maximum les fonctions mécaniques sur la carte. Le chassis peut ainsi être entièrement constitué de PCB, y compris les pièces mobiles.

Nous vous donnons deux exemples de schémas électroniques :

[[file:2022-schema-voiture-rex.pdf|thumb|400px|left|Schéma pour une voiture 1:87]]

[[file:2022-schema-voiture-boe.pdf|thumb|400px|right|Schéma pour une voiture 1:43]]

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

== Le microcontrôleur ==

Vous utiliserez un microcontrôleur ATMega16u2 comme coeur de votre circuit imprimé. Prenez exemple sur la partie microcontrôleur des schémas fournis.

La programmation du microcontrôleur se fera par DFU USB.

== Energie ==

La carte électronique de votre voiture est alimentée par une batterie LiPo. La batterie peut être chargée en utilisant une puce MAX1811. Voir les schémas fournis pour avoir une idée de commencer utiliser une puce MAX1811.

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

Des batteries FQ777-124 mAh un peu moins encombrantes ont été commandées (disponibilité fin mars ?). Les connecteurs adaptés ont aussi été commandés (micro JST 2 broches 1.25mm).

== Eclairage ==

Vous pouvez vous lâcher sur les LED pour simuler les dispositifs lumineux de votre voiture. Attention cependant votre micro-contrôleur n'a qu'un nombre limité de sorties.

== Contrôle de la voiture ==

=== Contrôle par programmation ===

Il est recommandé d'utiliser la fonctionnalité USB pour pouvoir programmer le comportement de la voiture. A défaut une programmation par port série est acceptable. Le programme PC permettant d'envoyer la suite d'instructions que la voiture doit réaliser est aussi à votre charge.

=== Radio-contrôle ===

Vous avez deux possibilités pour la commande à distance de votre voiture, soit une communication radio classique, soit une communication BlueTooth.

<gallery>
File:module_nrf24L01.jpg|Module de communication 2,4Ghz
File:module_BLE.jpg|Module Bluetooth Low Energy
</gallery>

Les modules RF 2,4Ghz utilisent une puce NRF24L01, ces modules étant un peu encombrants, quelques puces ont été commandées pour intégration directe sur le PCB (disponibilité fin février). Vous avez un exemple d'utilisation sur le premier schéma de carte fourni plus haut. Les puces NRF24L01 doivent être alimentées en 3,3V mais ses E/S sont compatibles 5V. Il n'est donc pas obligatoire de passer l'ATMega16u2 en 3,3V.

= Réalisation des binômes =

{| class="wikitable"
! Numéro !! Elèves !! Page
|-
| Binôme 1
| Sarra BEZZINE & Heriniaina ANDRIANIRINTSOA
| [[SE3Trinome2022-1|Trinôme 1 2022/2023]]
|-
| Trinôme 2
| Younes BENMBAREK & Camille CARIAT & Abdel ZONGO
| [[SE3Trinome2022-2|Trinôme 2 2022/2023]]
|-
| Binôme 3
| Simon CRUCHET & Amaury BECQUET
| [[SE3Trinome2022-3|Trinôme 3 2022/2023]]
|-
| Binôme 4
| Romain DUHR & Louis DERYCKERE
| [[SE3Trinome2022-4|Trinôme 4 2022/2023]]
|-
| Binôme 5
| Youness EL QASTALANI & Chaymae Rhanim
| [[SE3Trinome2022-5|Trinôme 5 2022/2023]]
|-
| Trinôme 6
| Prénom NOM & Prénom NOM & Prénom NOM
| [[SE3Trinome2022-6|Trinôme 6 2022/2023]]
|-
| Trinôme 7
| Prénom NOM & Prénom NOM & Prénom NOM
| [[SE3Trinome2022-7|Trinôme 7 2022/2023]]
|-
| Trinôme 8
| Prénom NOM & Prénom NOM & Prénom NOM
| [[SE3Trinome2022-8|Trinôme 8 2022/2023]]
|-
| Trinôme 9
| Prénom NOM & Prénom NOM & Prénom NOM
| [[SE3Trinome2022-9|Trinôme 9 2022/2023]]
|-
| Monôme 10
| Adrien Gontier
| [[SE3Trinome2022-10|Trinôme 10 2022/2023]]
|-
|
|}