https://projets-se.plil.fr/mediawiki/api.php?action=feedcontributions&feedformat=atom&user=Ncazinprojets-se.plil.fr - Contributions [fr]2026-05-14T03:34:02ZContributionsMediaWiki 1.39.1https://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2771SE4Binome2023-82024-01-16T12:28:47Z<p>Ncazin : /* Matériel : */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câbles reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus, nous avons dû souder 2 connecteurs permettant la jonction avec les cartes. Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== Ecriture de caractères sur le port série ===<br />
Tout d'abord, avant de commencer la tâche, nous savions que nous devions utiliser l'UART du microcontrôleur. De plus, la tâche suivante devait utiliser aussi l'UART. Puisque 2 tâches utilisent la même ressource, il faut implémenter un système pour savoir quelle tâche utilise la ressource. Nous avons alors utilisé un sémaphore pour chaque tâche, permettant ainsi de limiter l'accès temporairement à la ressource aux autres tâches : <syntaxhighlight lang="c"><br />
void semaphore_write(int action){<br />
if(action == TAKE_RESOURCE){<br />
while(1){<br />
cli();<br />
<br />
/** Ressource Disponible */<br />
if(sem_writing > 0){<br />
sem_writing = 0;<br />
sei();<br />
break;<br />
}<br />
<br />
/** Ressource occupée */<br />
else{<br />
tasks[actuel].reason = WORKING;<br />
tasks[actuel].state = SLEEPING;<br />
TCNT1 = 0;<br />
TIMER1_COMPA_vect();<br />
}<br />
sei();<br />
while(sem_writing == 0);<br />
}<br />
}<br />
if(action == DROP_RESOURCE){<br />
cli();<br />
sem_writing = 1;<br />
sei();<br />
}<br />
}<br />
</syntaxhighlight>Après avoir implémenté ce sémaphore, il fallait que nous comprenions comment utiliser l'UART du microcontrôleur. Pour cela, il faut initialiser correctement l'UART pour pouvoir écrire et lire en série. La fonction suivante permet d'initialiser correctement l'UART : <syntaxhighlight lang="c"><br />
void init_usart(long int speed){<br />
UBRR0 = FREQUENCE/((unsigned long int)speed << 4) -1;<br />
UCSR0B = (1 << TXEN0 | 1 << RXEN0);<br />
UCSR0C = (1 << UCSZ01 | 1 << UCSZ00);<br />
UCSR0A &= ~(1 << U2X0);<br />
}<br />
</syntaxhighlight>Enfin, une fois l'initialisation réalisée, nous pouvons réaliser la tâche utilisant les fonctions permettant d'écrire plusieurs caractères (ici "abc") sur le port série, que l'on peut observer grâce à la commande shell ''"minicom -D /dev/ttyUSB0 -b 9600".'' On utilise alors les fonctions suivantes pour écrire sur le port série :<syntaxhighlight lang="c"><br />
void serial_send(unsigned char c){<br />
loop_until_bit_is_set(UCSR0A, UDRE0);<br />
UDR0 = c;<br />
}<br />
<br />
<br />
void serial_send_str(char chaine[]){<br />
semaphore_write(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
serial_send(chaine[i]);<br />
}<br />
semaphore_write(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut observer que la tâche fonctionne comme sur la vidéo suivante :[[Fichier:Tâche d'écriture sur le port série.mp4|vignette|Tâche d'écriture sur le port série|centré]]<br />
<br />
=== Lecture sur le port série ===<br />
De la même façon que la tâche précédente, pour cette tâche nous devons lire les pressions de touches du clavier et les afficher sur le minicom. L'initialisation est déjà effectuée et le sémaphore et la même que dans la partie précédente, nous ne la traiterons donc pas. On utilise alors les fonctions suivantes pour lire les pressions des touches sur le clavier, et la tâche les fait afficher ensuite : <syntaxhighlight lang="c"><br />
unsigned char serial_read(void){<br />
loop_until_bit_is_set(UCSR0A, RXC0);<br />
return UDR0;<br />
}<br />
<br />
<br />
void serial_read_str(char chaine[]){<br />
semaphore_read(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
chaine[i] = serial_read();<br />
}<br />
semaphore_read(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut alors observer les résultats grâce à la vidéo suivante : <br />
[[Fichier:Tâche de lecture sur le port série.mp4|centré|vignette|Tâche de lecture sur le port série]]<br />
<br />
=== Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8 grâce au SPI. Il faut alors réussir à initialiser le SPI correctement :<syntaxhighlight lang="c"><br />
void SPI_MasterInit(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0);<br />
}<br />
</syntaxhighlight>Ensuite, nous avons rédigé un programme utilisé par notre tâche afin d'afficher différents caractères sur la matrice en allumant les LEDs voulues bit par bit :<syntaxhighlight lang="c"><br />
void loop_matrix(char letter[8]){<br />
int temp;<br />
PORTC &= ~(1 << CS);<br />
for(short int i = 0; i < 8; i++){<br />
<br />
for(short int j = 0; j < 8; j++)<br />
{<br />
temp = letter[i] & (1 << j); <br />
diplayLED(temp); //Envoir de chaque bit sur le SPI<br />
}<br />
}<br />
PORTC |= (1 << CS);<br />
}<br />
</syntaxhighlight>Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Nous pouvons alors voir le changement des LEDs allumées lorsque l'on appuie sur un autre caractère grâce à la vidéo suivante :<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage des caractères sur la matrice]]<br />
<br />
=== Afficheur 7 segments ===<br />
Pour le 7 segments, l'initialisation est différente. En effet, le 7 segments ne fonctionne qu'à une fréquence maximale de 250kHz, il faut alors modifier l'initialisation du SPI de la tâche pour le faire fonctionner en changeant le paramètre SPCR :<syntaxhighlight lang="c"><br />
void SPI_MasterInit_segments(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
PORTB |= (1 << SS);<br />
PORTC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << SPR1); //SPR1 & SPR0 à 1 pour une fréquence en dessous de 250kHz (fréquence de l'afficheur 7 segments)<br />
}<br />
</syntaxhighlight>En envoyant alors la lettre appuyée sur le clavier, le 7 segments convertit (si c'est possible) la lettre en segments à allumer comme nous pouvons le voir sur la vidéo suivante :[[Fichier:7segments.mp4|centré|vignette|Affichage des caractères sur le 7 segments]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
=== Contrôleur de bus série SPI ===<br />
Pour ce programme VHDL, nous avons voulu faire une communication SPI Maitre/Esclave. Pour cela, nous nous sommes documentés sur comment fonctionnait cette communication. Il faut alors réaliser les 4 signaux MOSI, MISO, SS et SCK afin de pouvoir communiquer. On vérifie alors chacun de bits envoyé afin de gérer les signaux de contrôle et de l'entrée MISO. Ensuite, on génère les données de sortie pour la réponse. Enfin, on peut assigner les sorties avec les informations que l'on a. Voici alors les processus utilisés : <syntaxhighlight lang="vhdl"><br />
-- Processus 1 : Gestion des signaux de contrôle et de l'entrée MISO<br />
process (reset, start_transfer, MISO)<br />
begin<br />
if reset = '1' then<br />
-- En cas de réinitialisation, retour à l'état IDLE<br />
state <= IDLE;<br />
bit_counter <= 0;<br />
SS <= '1';<br />
elsif start_transfer = '1' then<br />
-- Au début d'une nouvelle transmission, passage à l'état TRANSFER<br />
state <= TRANSFER;<br />
bit_counter <= 0;<br />
SS <= '0'; -- Sélection du périphérique esclave au début de la transmission<br />
elsif state = TRANSFER then<br />
-- Déplacement du bit reçu dans le tampon<br />
received_data <= MISO & received_data(7 downto 1);<br />
bit_counter <= bit_counter + 1;<br />
if bit_counter = 7 then<br />
-- Si tous les bits ont été déplacés, passage à l'état DONE<br />
state <= DONE;<br />
end if;<br />
elsif state = DONE then<br />
-- Fin de la transmission, désélection du périphérique esclave<br />
SS <= '1';<br />
state <= IDLE;<br />
end if;<br />
end process;<br />
<br />
-- Processus 2 : Génération des données de sortie (data_out)<br />
process (reset, start_transfer, bit_counter)<br />
begin<br />
if reset = '1' then<br />
-- En cas de réinitialisation, les données de sortie sont mises à zéro<br />
data_out <= (others => '0');<br />
elsif start_transfer = '1' then<br />
-- Au début d'une nouvelle transmission, envoi du premier bit<br />
data_out <= data_out(6 downto 0) & '0';<br />
elsif state = TRANSFER then<br />
-- Déplacement du bit à envoyer dans le registre de sortie<br />
data_out <= '0' & data_out(7 downto 1);<br />
end if;<br />
end process;<br />
<br />
-- Assignements des sorties<br />
transfer_done <= '1' when state = DONE else '0';<br />
clk <= not clk after 5 ns; -- Simulation de l'horloge (pour la démo)<br />
MOSI <= data_out(7);<br />
data_in <= received_data;<br />
</syntaxhighlight><br />
<br />
=== Contrôleur VGA ===<br />
Pour ce contrôleur, il faut utiliser le port VGA présent sur la carte Basys-3. Sur ce connecteur VGA, il y a plusieurs sorties à gérer. En effet, il y a les signaux de synchronisation HS et VS qui fonctionnent s'ils ont une certaine forme d'ondes. Ces signaux doivent être à 0 pendant un certain temps. De plus, nous avons les ports permettant de gérer les couleur, vert, bleu et rouge, chacun sur 4 bits. L'horloge du FPGA fonctionnant à 100MHz, nous devons la moduler à 60Hz, car l'écran fonctionne à cette fréquence. Pour cela, nous avons utilisé les IP catalogs. Ce sont des composants existants dans des librairies qui peuvent être utilisés. Dans notre cas, nous avons utilisé un composant qui permet de modifier la fréquence d’un signal.<br />
<br />
Nous avons ensuite reconstitué le signal de HS et VS. En effet, ces signaux ont besoin d’une période très spécifique permettant de bien configurer la taille de notre écran. Nous avons donc configuré un compteur incrémenté à chaque front montant de l’horloge, ce qui permet de mettre à l’état bas nos signaux.<br />
<br />
Le signal HS possède un front descendant à chaque changement de pixel, et lorsque que l’on a fait toute la ligne, un front descendant est envoyé sur VS pour descendre d’une ligne. Voici les programmes fait pour créer ces signaux : <syntaxhighlight lang="vhdl"><br />
Balayage : process(clk_pixel)<br />
begin<br />
if clk_pixel'event and clk_pixel = '1' then<br />
-- Compteur horizontal<br />
if compteur_horizontal < 1343 then<br />
compteur_horizontal <= compteur_horizontal + 1;<br />
else<br />
compteur_horizontal <= 0;<br />
<br />
-- Compteur vertical<br />
if compteur_vertical < 805 then<br />
compteur_vertical <= compteur_vertical + 1;<br />
else<br />
compteur_vertical <= 0;<br />
end if;<br />
end if;<br />
end if;<br />
<br />
-- Création signal HS<br />
if compteur_horizontal > 1047 and compteur_horizontal < 1184 then<br />
HS_out <= '0';<br />
HS_sig <= '0';<br />
else<br />
HS_out <= '1';<br />
HS_sig <= '1';<br />
end if;<br />
<br />
-- Création signal VS<br />
if compteur_vertical > 770 and compteur_vertical < 777 then<br />
VS_out <= '0';<br />
VS_sig <= '0';<br />
else<br />
VS_out <= '1';<br />
VS_sig <= '1';<br />
end if;<br />
</syntaxhighlight>Après avoir fait ces programmes, nous avons fait la simulation pour voir si les signaux étaient bien réalisés. Voici les simulations de ces signaux : <br />
<br />
[[Fichier:VGA signal VS.png|alt=VGA signal VS|centré|vignette|VGA signal VS]]<br />
[[Fichier:VGA signal HS.png|alt=VGA signal HS|centré|vignette|VGA signal HS]]<br />
<br />
<br />
Après avoir fait cela, il fallait s’occuper des sorties des couleurs. Pour cela, nous devons mettre les valeurs des canaux de couleurs au maximum lorsque les boutons correspondants sont appuyés et quand les signaux HS et VS sont eux aussi à 1. Une condition supplémentaire permet de contrôler la taille du carré à afficher. Les programmes de gestion des couleurs étant quasiment les mêmes aux exceptions des boutons à appuyer, nous ne montrerons que celui de la couleur rouge sur l’image ci-dessous : <syntaxhighlight lang="vhdl"><br />
-- Gestion couleur rouge --<br />
if B1_in = '1' and clk_pixel'event and clk_pixel = '1' then<br />
if VS_sig = '1' and HS_sig = '1' then<br />
if compteur_horizontal > 400 and compteur_horizontal < 600 then<br />
if compteur_vertical > 200 and compteur_vertical < 400 then<br />
red_out <= "1111";<br />
else<br />
red_out <= "0000";<br />
end if;<br />
else<br />
red_out <= "0000";<br />
end if;<br />
else<br />
red_out <= "0000";<br />
end if;<br />
end if;<br />
</syntaxhighlight>Au final, après la génération du fichier .bit, de la modification du fichier de contrainte et de l'envoi du programme sur la carte FPGA Basys-3, nous avons bien un carré pouvant changer de couleur lorsque l'on appuie sur un bouton : <br />
[[Fichier:Carré qui change de couleur grâce au contrôleur VGA.mp4|centré|vignette|Carré qui change de couleur grâce au contrôleur VGA]]<br />
Il nous manque alors la gestion de la couleur en mémoire, mais nous n'avons pas eu le temps de réaliser cette fonction. Cependant la gestion du contrôleur VGA et de la création des signaux HS et VS nous ont beaucoup appris sur le fonctionnement du VGA.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utilisé un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecté des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenté un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur ne se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir réalisé le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur, car nous savons comment elles doivent être disposées. Le plus difficile dans ce routage a été de mettre les capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de vias possibles pour ne pas endommager les signaux que l'on souhaite envoyer. Nous avons fait le plan de masse de la carte et au final, nous avons réussi à compacter la carte pour qu'elle fasse une taille de 43mm par 33mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une représentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors routé notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :''<br />
[[Fichier:Carte reconnue après un "lsusb".png|alt=Carte reconnue après un "lsusb"|centré|vignette|Carte reconnue après un "lsusb"]]<br />
Après cela, nous avons entamé la programmation pour avoir une communication RNDIS.<br />
<br />
=== Programmation de la carte électronique RNDIS ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utilisé une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassé. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite, nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créé, mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. <br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par la suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping de l'adresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et vérifiés leur bonne réception sur le terminal. Nous avons alors utilisé l'outil "ether" afin d'observer les paquets reçus sur l'interface "usb0" créée. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette|Réception de paquets IP ]]À ce moment précis, la carte allume bien les LEDs lors de la récéption des mêmes paquets que ceux implémentés dans la pile TCP/IP. Puisque l'on veut utiliser nos propres paquets avec notre protocole, nous devons ajouter dans cette pile le traitement de notre protocole. <br />
<br />
Tout d'abord, dans le fichier "EthernerProtocols.h", nous avons créé notre propre protocole et sera le suivant : "0x0903"<syntaxhighlight lang="c"><br />
#define ETHERTYPE_PICO 0x0903<br />
</syntaxhighlight>Ensuite, il faut créer une structure représentant notre trame dans un fichier permettant son traitement. Ici, le fichier s'appelle "PICO.h". Nous avons alors choisi d'utiliser cette structure de trame : <syntaxhighlight lang="c"><br />
/** Type define for a PICO header. */<br />
typedef struct<br />
{<br />
MAC_Address_t Destination_MAC; /**< MAC address of the packet recipient */<br />
MAC_Address_t Source_MAC; /**< MAC address of the packet source */<br />
IP_Address_t Destination_IP; /**< IP address of the packet recipient */<br />
IP_Address_t Source_IP; /**< IP address of the packet source */<br />
uint16_t PICOType; /**< PICO packet sub-protocol type*/<br />
}PICO_Header_t;<br />
</syntaxhighlight>Dans le fichier c, il faut alors réaliser le traitement de cette trame pour créer la réponse : <syntaxhighlight lang="c"><br />
int16_t PICO_ProcessPICOPacket(void* InDataStart,<br />
void* OutDataStart)<br />
{<br />
PICO_Header_t* PICOHeaderIN = (PICO_Header_t*)InDataStart;<br />
PICO_Header_t* PICOHeaderOUT = (PICO_Header_t*)OutDataStart;<br />
<br />
/* Ensure that the PICO request is a PICO request packet */<br />
if (SwapEndian_16(PICOHeaderIN->PICOType) == ETHERTYPE_PICO)<br />
{<br />
if (IP_COMPARE(&PICOHeaderIN->Destination_IP, &ServerIPAddress)||<br />
MAC_COMPARE(&PICOHeaderIN->Destination_MAC, &ServerMACAddress))<br />
{<br />
/* Fill out the PICO response header */<br />
PICOHeaderOUT->Destination_MAC = PICOHeaderIN->Source_MAC;<br />
PICOHeaderOUT->Source_MAC = ServerMACAddress;<br />
PICOHeaderOUT->Destination_IP = PICOHeaderIN->Source_IP;<br />
PICOHeaderOUT->Source_IP = ServerIPAddress;<br />
PICOHeaderOUT->PICOType = PICOHeaderIN->PICOType;<br />
<br />
/* Blink the LED */<br />
PORTC ^= 0x30;<br />
<br />
/* Return the size of the response so far */<br />
return sizeof(PICO_Header_t);<br />
}<br />
}<br />
<br />
return NO_RESPONSE;<br />
}<br />
</syntaxhighlight>De cette façon, lorsqu'une trame respectant notre forme et utilisant notre protocole est envoyée sur l'interface, la LED de la carte devrait clignoter.<br />
<br />
Enfin, il faut aussi adapter le fichier "ProtocolsDecoders" afin que la LUFA arrive à décoder notre trame : <syntaxhighlight lang="c"><br />
void DecodePICOFrameHeader(void* InDataStart)<br />
{<br />
PICO_Header_t* PICOHeader = (PICO_Header_t*)InDataStart;<br />
<br />
printf_P(PSTR(" \\\r\n PICO\r\n"));<br />
<br />
if (!(IP_COMPARE(&PICOHeader->Destination_IP, &ServerIPAddress)) &&<br />
!(IP_COMPARE(&PICOHeader->Destination_IP, &BroadcastIPAddress)))<br />
{<br />
printf_P(PSTR(" + NOT ADDRESSED TO DEVICE\r\n"));<br />
return;<br />
}<br />
<br />
printf_P(PSTR(" + MAC Dest: %u:%u:%u:%u:%u:%u\r\n"), PICOHeader->Destination_MAC.Octets[0],<br />
PICOHeader->Destination_MAC.Octets[1],<br />
PICOHeader->Destination_MAC.Octets[2],<br />
PICOHeader->Destination_MAC.Octets[3],<br />
PICOHeader->Destination_MAC.Octets[4],<br />
PICOHeader->Destination_MAC.Octets[5]);<br />
<br />
printf_P(PSTR(" + MAC Source : %u:%u:%u:%u:%u:%u\r\n"), PICOHeader->Source_MAC.Octets[0],<br />
PICOHeader->Source_MAC.Octets[1],<br />
PICOHeader->Source_MAC.Octets[2],<br />
PICOHeader->Source_MAC.Octets[3],<br />
PICOHeader->Source_MAC.Octets[4],<br />
PICOHeader->Source_MAC.Octets[5]);<br />
<br />
printf_P(PSTR(" + IP Dest : %u:%u:%u:%u\r\n"), PICOHeader->Destination_IP.Octets[0],<br />
PICOHeader->Destination_IP.Octets[1],<br />
PICOHeader->Destination_IP.Octets[2],<br />
PICOHeader->Destination_IP.Octets[3]);<br />
<br />
printf_P(PSTR(" + IP Source : %u:%u:%u:%u\r\n"), PICOHeader->Source_IP.Octets[0],<br />
PICOHeader->Source_IP.Octets[1],<br />
PICOHeader->Source_IP.Octets[2],<br />
PICOHeader->Source_IP.Octets[3]);<br />
<br />
printf_P(PSTR(" + Protocol : %x\r\n"), SwapEndian_16(PICOHeader->PICOType));<br />
}<br />
</syntaxhighlight>Après cela, nous pouvons envoyer une trame sur l'interface "usb0" utilisant notre protocole. Pour cela, nous avons modifié l'outil "ether" pour observer directement l'interface "usb0" et aussi pour que le filtre accepte notre protocole. En envoyant alors la trame, la LED s'allume bien correctement : <br />
[[Fichier:WhatsApp Video 2023-12-21 at 11.58.12.mp4|centré|vignette|Carte RNDIS réagissant à notre propre trame]]<br />
<br />
Cependant, on remarque que la LED s'allume, c'est-à-dire que la réponse est bien créée, mais elle n'est pas envoyée. En remontant chaque fonction pouvant être la cause du non-envoi de la réponse, nous avons "RNDIS_Task" que nous n'arrivons pas à comprendre. Cependant, nous n'avons pas modifié cette fonction, cela doit provenir de la trame envoyée, mais pourtant, le programme rentre bien complétement dans la fonction. À ce stade, nous n'arrivons toujours pas à trouver la cause du problème.<br />
<br />
== Conclusion : ==<br />
Durant ce projet, nous avons essayé de travailler sur toutes les parties. En effet, nous avons consacré beaucoup de temps sur la partie Ordonnanceur pendant que la carte électronique était expédiée, c'est d'ailleurs comme ça que nous avons réussi à terminer toutes les tâches. Nous avons rencontré beaucoup de difficultés pendant la programmation de l'ordonnanceur, certaines tâches étaient plus compliquées pour nous que d'autres, mais nous avons réussi à nous organiser et à réaliser ces tâches. Ensuite, nous nous sommes séparés en deux, un qui travaillait sur le VHDL et l'autre sur la carte RNDIS. Du côté de la partie VHDL, la gestion du SPI était compliquée à réalisée et nous n'avons pas eu le temps de tester notre programme sur une carte FPGA. Cependant, nous avons pu tester et beaucoup mieux avancer sur le VGA. Enfin, la carte RNDIS a été compliquée à comprendre et nous avons perdu beaucoup de temps sur la réduction de la pile TCP/IP. Nous avons quand même réussi à avancer jusqu'à ce blocage sur la réponse que l'on devait recevoir.<br />
<br />
Globalement, nous sommes contents du résultat de notre travail. Nous avons travaillé sur chaque partie comme nous le voulions afin de renforcer ou d'acquérir de nouvelles compétences. L'organisation entre nous nous a permis de gagner du temps sur notre travail. De plus, nous avons travaillé chez nous, ce qui nous permit aussi de mieux nous organiser et de mieux prévoir les séances de travail qui venaient. <br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2644SE4Binome2023-82023-12-29T10:35:56Z<p>Ncazin : /* Matériel : */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câbles reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus, nous avons dû souder 2 connecteurs permettant la jonction avec les cartes. Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== Ecriture de caractères sur le port série ===<br />
Tout d'abord, avant de commencer la tâche, nous savions que nous devions utiliser l'UART du microcontrôleur. De plus, la tâche suivante devait utiliser aussi l'UART. Puisque 2 tâches utilisent la même ressource, il faut implémenter un système pour savoir quelle tâche utilise la ressource. Nous avons alors utilisé un sémaphore pour chaque tâche, permettant ainsi de limiter l'accès temporairement à la ressource aux autres tâches : <syntaxhighlight lang="c"><br />
void semaphore_write(int action){<br />
if(action == TAKE_RESOURCE){<br />
while(1){<br />
cli();<br />
<br />
/** Ressource Disponible */<br />
if(sem_writing > 0){<br />
sem_writing = 0;<br />
sei();<br />
break;<br />
}<br />
<br />
/** Ressource occupée */<br />
else{<br />
tasks[actuel].reason = WORKING;<br />
tasks[actuel].state = SLEEPING;<br />
TCNT1 = 0;<br />
TIMER1_COMPA_vect();<br />
}<br />
sei();<br />
while(sem_writing == 0);<br />
}<br />
}<br />
if(action == DROP_RESOURCE){<br />
cli();<br />
sem_writing = 1;<br />
sei();<br />
}<br />
}<br />
</syntaxhighlight>Après avoir implémenté ce sémaphore, il fallait que nous comprenions comment utiliser l'UART du microcontrôleur. Pour cela, il faut initialiser correctement l'UART pour pouvoir écrire et lire en série. La fonction suivante permet d'initialiser correctement l'UART : <syntaxhighlight lang="c"><br />
void init_usart(long int speed){<br />
UBRR0 = FREQUENCE/((unsigned long int)speed << 4) -1;<br />
UCSR0B = (1 << TXEN0 | 1 << RXEN0);<br />
UCSR0C = (1 << UCSZ01 | 1 << UCSZ00);<br />
UCSR0A &= ~(1 << U2X0);<br />
}<br />
</syntaxhighlight>Enfin, une fois l'initialisation réalisée, nous pouvons réaliser la tâche utilisant les fonctions permettant d'écrire plusieurs caractères (ici "abc") sur le port série, que l'on peut observer grâce à la commande shell ''"minicom -D /dev/ttyUSB0 -b 9600".'' On utilise alors les fonctions suivantes pour écrire sur le port série :<syntaxhighlight lang="c"><br />
void serial_send(unsigned char c){<br />
loop_until_bit_is_set(UCSR0A, UDRE0);<br />
UDR0 = c;<br />
}<br />
<br />
<br />
void serial_send_str(char chaine[]){<br />
semaphore_write(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
serial_send(chaine[i]);<br />
}<br />
semaphore_write(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut observer que la tâche fonctionne comme sur la vidéo suivante :[[Fichier:Tâche d'écriture sur le port série.mp4|vignette|Tâche d'écriture sur le port série|centré]]<br />
<br />
=== Lecture sur le port série ===<br />
De la même façon que la tâche précédente, pour cette tâche nous devons lire les pressions de touches du clavier et les afficher sur le minicom. L'initialisation est déjà effectuée et le sémaphore et la même que dans la partie précédente, nous ne la traiterons donc pas. On utilise alors les fonctions suivantes pour lire les pressions des touches sur le clavier, et la tâche les fait afficher ensuite : <syntaxhighlight lang="c"><br />
unsigned char serial_read(void){<br />
loop_until_bit_is_set(UCSR0A, RXC0);<br />
return UDR0;<br />
}<br />
<br />
<br />
void serial_read_str(char chaine[]){<br />
semaphore_read(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
chaine[i] = serial_read();<br />
}<br />
semaphore_read(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut alors observer les résultats grâce à la vidéo suivante : <br />
[[Fichier:Tâche de lecture sur le port série.mp4|centré|vignette|Tâche de lecture sur le port série]]<br />
<br />
=== Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8 grâce au SPI. Il faut alors réussir à initialiser le SPI correctement :<syntaxhighlight lang="c"><br />
void SPI_MasterInit(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0);<br />
}<br />
</syntaxhighlight>Ensuite, nous avons rédigé un programme utilisé par notre tâche afin d'afficher différents caractères sur la matrice en allumant les LEDs voulues bit par bit :<syntaxhighlight lang="c"><br />
void loop_matrix(char letter[8]){<br />
int temp;<br />
PORTC &= ~(1 << CS);<br />
for(short int i = 0; i < 8; i++){<br />
<br />
for(short int j = 0; j < 8; j++)<br />
{<br />
temp = letter[i] & (1 << j); <br />
diplayLED(temp); //Envoir de chaque bit sur le SPI<br />
}<br />
}<br />
PORTC |= (1 << CS);<br />
}<br />
</syntaxhighlight>Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Nous pouvons alors voir le changement des LEDs allumées lorsque l'on appuie sur un autre caractère grâce à la vidéo suivante :<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage des caractères sur la matrice]]<br />
<br />
=== Afficheur 7 segments ===<br />
Pour le 7 segments, l'initialisation est différente. En effet, le 7 segments ne fonctionne qu'à une fréquence maximale de 250kHz, il faut alors modifier l'initialisation du SPI de la tâche pour le faire fonctionner en changeant le paramètre SPCR :<syntaxhighlight lang="c"><br />
void SPI_MasterInit_segments(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
PORTB |= (1 << SS);<br />
PORTC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << SPR1); //SPR1 & SPR0 à 1 pour une fréquence en dessous de 250kHz (fréquence de l'afficheur 7 segments)<br />
}<br />
</syntaxhighlight>En envoyant alors la lettre appuyée sur le clavier, le 7 segments convertit (si c'est possible) la lettre en segments à allumer comme nous pouvons le voir sur la vidéo suivante :[[Fichier:7segments.mp4|centré|vignette|Affichage des caractères sur le 7 segments]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
=== Contrôleur de bus série SPI ===<br />
Pour ce programme VHDL, nous avons voulu faire une communication SPI Maitre/Esclave. Pour cela, nous nous sommes documentés sur comment fonctionnait cette communication. Il faut alors réaliser les 4 signaux MOSI, MISO, SS et SCK afin de pouvoir communiquer. On vérifie alors chacun de bits envoyé afin de gérer les signaux de contrôle et de l'entrée MISO. Ensuite, on génère les données de sortie pour la réponse. Enfin, on peut assigner les sorties avec les informations que l'on a. Voici alors les processus utilisés : <syntaxhighlight lang="vhdl"><br />
-- Processus 1 : Gestion des signaux de contrôle et de l'entrée MISO<br />
process (reset, start_transfer, MISO)<br />
begin<br />
if reset = '1' then<br />
-- En cas de réinitialisation, retour à l'état IDLE<br />
state <= IDLE;<br />
bit_counter <= 0;<br />
SS <= '1';<br />
elsif start_transfer = '1' then<br />
-- Au début d'une nouvelle transmission, passage à l'état TRANSFER<br />
state <= TRANSFER;<br />
bit_counter <= 0;<br />
SS <= '0'; -- Sélection du périphérique esclave au début de la transmission<br />
elsif state = TRANSFER then<br />
-- Déplacement du bit reçu dans le tampon<br />
received_data <= MISO & received_data(7 downto 1);<br />
bit_counter <= bit_counter + 1;<br />
if bit_counter = 7 then<br />
-- Si tous les bits ont été déplacés, passage à l'état DONE<br />
state <= DONE;<br />
end if;<br />
elsif state = DONE then<br />
-- Fin de la transmission, désélection du périphérique esclave<br />
SS <= '1';<br />
state <= IDLE;<br />
end if;<br />
end process;<br />
<br />
-- Processus 2 : Génération des données de sortie (data_out)<br />
process (reset, start_transfer, bit_counter)<br />
begin<br />
if reset = '1' then<br />
-- En cas de réinitialisation, les données de sortie sont mises à zéro<br />
data_out <= (others => '0');<br />
elsif start_transfer = '1' then<br />
-- Au début d'une nouvelle transmission, envoi du premier bit<br />
data_out <= data_out(6 downto 0) & '0';<br />
elsif state = TRANSFER then<br />
-- Déplacement du bit à envoyer dans le registre de sortie<br />
data_out <= '0' & data_out(7 downto 1);<br />
end if;<br />
end process;<br />
<br />
-- Assignements des sorties<br />
transfer_done <= '1' when state = DONE else '0';<br />
clk <= not clk after 5 ns; -- Simulation de l'horloge (pour la démo)<br />
MOSI <= data_out(7);<br />
data_in <= received_data;<br />
</syntaxhighlight><br />
<br />
=== Contrôleur VGA ===<br />
Pour ce contrôleur, il faut utiliser le port VGA présent sur la carte Basys-3. Sur ce connecteur VGA, il y a plusieurs sorties à gérer. En effet, il y a les signaux de synchronisation HS et VS qui fonctionnent s'ils ont une certaine forme d'ondes. Ces signaux doivent être à 0 pendant un certain temps. De plus, nous avons les ports permettant de gérer les couleur, vert, bleu et rouge, chacun sur 4 bits. L'horloge du FPGA fonctionnant à 100MHz, nous devons la moduler à 60Hz, car l'écran fonctionne à cette fréquence. Pour cela, nous avons utilisé les IP catalogs. Ce sont des composants existants dans des librairies qui peuvent être utilisés. Dans notre cas, nous avons utilisé un composant qui permet de modifier la fréquence d’un signal.<br />
<br />
Nous avons ensuite reconstitué le signal de HS et VS. En effet, ces signaux ont besoin d’une période très spécifique permettant de bien configurer la taille de notre écran. Nous avons donc configuré un compteur incrémenté à chaque front montant de l’horloge, ce qui permet de mettre à l’état bas nos signaux.<br />
<br />
Le signal HS possède un front descendant à chaque changement de pixel, et lorsque que l’on a fait toute la ligne, un front descendant est envoyé sur VS pour descendre d’une ligne. Voici les programmes fait pour créer ces signaux : <syntaxhighlight lang="vhdl"><br />
Balayage : process(clk_pixel)<br />
begin<br />
if clk_pixel'event and clk_pixel = '1' then<br />
-- Compteur horizontal<br />
if compteur_horizontal < 1343 then<br />
compteur_horizontal <= compteur_horizontal + 1;<br />
else<br />
compteur_horizontal <= 0;<br />
<br />
-- Compteur vertical<br />
if compteur_vertical < 805 then<br />
compteur_vertical <= compteur_vertical + 1;<br />
else<br />
compteur_vertical <= 0;<br />
end if;<br />
end if;<br />
end if;<br />
<br />
-- Création signal HS<br />
if compteur_horizontal > 1047 and compteur_horizontal < 1184 then<br />
HS_out <= '0';<br />
HS_sig <= '0';<br />
else<br />
HS_out <= '1';<br />
HS_sig <= '1';<br />
end if;<br />
<br />
-- Création signal VS<br />
if compteur_vertical > 770 and compteur_vertical < 777 then<br />
VS_out <= '0';<br />
VS_sig <= '0';<br />
else<br />
VS_out <= '1';<br />
VS_sig <= '1';<br />
end if;<br />
</syntaxhighlight>Après avoir fait ces programmes, nous avons fait la simulation pour voir si les signaux étaient bien réalisés. Voici les simulations de ces signaux : <br />
<br />
[[Fichier:VGA signal VS.png|alt=VGA signal VS|centré|vignette|VGA signal VS]]<br />
[[Fichier:VGA signal HS.png|alt=VGA signal HS|centré|vignette|VGA signal HS]]<br />
<br />
<br />
Après avoir fait cela, il fallait s’occuper des sorties des couleurs. Pour cela, nous devons mettre les valeurs des canaux de couleurs au maximum lorsque les boutons correspondants sont appuyés et quand les signaux HS et VS sont eux aussi à 1. Une condition supplémentaire permet de contrôler la taille du carré à afficher. Les programmes de gestion des couleurs étant quasiment les mêmes aux exceptions des boutons à appuyer, nous ne montrerons que celui de la couleur rouge sur l’image ci-dessous : <syntaxhighlight lang="vhdl"><br />
-- Gestion couleur rouge --<br />
if B1_in = '1' and clk_pixel'event and clk_pixel = '1' then<br />
if VS_sig = '1' and HS_sig = '1' then<br />
if compteur_horizontal > 400 and compteur_horizontal < 600 then<br />
if compteur_vertical > 200 and compteur_vertical < 400 then<br />
red_out <= "1111";<br />
else<br />
red_out <= "0000";<br />
end if;<br />
else<br />
red_out <= "0000";<br />
end if;<br />
else<br />
red_out <= "0000";<br />
end if;<br />
end if;<br />
</syntaxhighlight>Au final, après la génération du fichier .bit, de la modification du fichier de contrainte et de l'envoi du programme sur la carte FPGA Basys-3, nous avons bien un carré pouvant changer de couleur lorsque l'on appuie sur un bouton : <br />
[[Fichier:Carré qui change de couleur grâce au contrôleur VGA.mp4|centré|vignette|Carré qui change de couleur grâce au contrôleur VGA]]<br />
Il nous manque alors la gestion de la couleur en mémoire, mais nous n'avons pas eu le temps de réaliser cette fonction. Cependant la gestion du contrôleur VGA et de la création des signaux HS et VS nous ont beaucoup appris sur le fonctionnement du VGA.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utilisé un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecté des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenté un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur ne se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir réalisé le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur, car nous savons comment elles doivent être disposées. Le plus difficile dans ce routage a été de mettre les capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de vias possibles pour ne pas endommager les signaux que l'on souhaite envoyer. Nous avons fait le plan de masse de la carte et au final, nous avons réussi à compacter la carte pour qu'elle fasse une taille de 43mm par 33mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une représentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors routé notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :''<br />
[[Fichier:Carte reconnue après un "lsusb".png|alt=Carte reconnue après un "lsusb"|centré|vignette|Carte reconnue après un "lsusb"]]<br />
Après cela, nous avons entamé la programmation pour avoir une communication RNDIS.<br />
<br />
=== Programmation de la carte électronique RNDIS ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utilisé une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassé. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite, nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créé, mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. <br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par la suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping de l'adresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et vérifiés leur bonne réception sur le terminal. Nous avons alors utilisé l'outil "ether" afin d'observer les paquets reçus sur l'interface "usb0" créée. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette|Réception de paquets IP ]]À ce moment précis, la carte allume bien les LEDs lors de la récéption des mêmes paquets que ceux implémentés dans la pile TCP/IP. Puisque l'on veut utiliser nos propres paquets avec notre protocole, nous devons ajouter dans cette pile le traitement de notre protocole. <br />
<br />
Tout d'abord, dans le fichier "EthernerProtocols.h", nous avons créé notre propre protocole et sera le suivant : "0x0903"<syntaxhighlight lang="c"><br />
#define ETHERTYPE_PICO 0x0903<br />
</syntaxhighlight>Ensuite, il faut créer une structure représentant notre trame dans un fichier permettant son traitement. Ici, le fichier s'appelle "PICO.h". Nous avons alors choisi d'utiliser cette structure de trame : <syntaxhighlight lang="c"><br />
/** Type define for a PICO header. */<br />
typedef struct<br />
{<br />
MAC_Address_t Destination_MAC; /**< MAC address of the packet recipient */<br />
MAC_Address_t Source_MAC; /**< MAC address of the packet source */<br />
IP_Address_t Destination_IP; /**< IP address of the packet recipient */<br />
IP_Address_t Source_IP; /**< IP address of the packet source */<br />
uint16_t PICOType; /**< PICO packet sub-protocol type*/<br />
}PICO_Header_t;<br />
</syntaxhighlight>Dans le fichier c, il faut alors réaliser le traitement de cette trame pour créer la réponse : <syntaxhighlight lang="c"><br />
int16_t PICO_ProcessPICOPacket(void* InDataStart,<br />
void* OutDataStart)<br />
{<br />
PICO_Header_t* PICOHeaderIN = (PICO_Header_t*)InDataStart;<br />
PICO_Header_t* PICOHeaderOUT = (PICO_Header_t*)OutDataStart;<br />
<br />
/* Ensure that the PICO request is a PICO request packet */<br />
if (SwapEndian_16(PICOHeaderIN->PICOType) == ETHERTYPE_PICO)<br />
{<br />
if (IP_COMPARE(&PICOHeaderIN->Destination_IP, &ServerIPAddress)||<br />
MAC_COMPARE(&PICOHeaderIN->Destination_MAC, &ServerMACAddress))<br />
{<br />
/* Fill out the PICO response header */<br />
PICOHeaderOUT->Destination_MAC = PICOHeaderIN->Source_MAC;<br />
PICOHeaderOUT->Source_MAC = ServerMACAddress;<br />
PICOHeaderOUT->Destination_IP = PICOHeaderIN->Source_IP;<br />
PICOHeaderOUT->Source_IP = ServerIPAddress;<br />
PICOHeaderOUT->PICOType = PICOHeaderIN->PICOType;<br />
<br />
/* Blink the LED */<br />
PORTC ^= 0x30;<br />
<br />
/* Return the size of the response so far */<br />
return sizeof(PICO_Header_t);<br />
}<br />
}<br />
<br />
return NO_RESPONSE;<br />
}<br />
</syntaxhighlight>De cette façon, lorsqu'une trame respectant notre forme et utilisant notre protocole est envoyée sur l'interface, la LED de la carte devrait clignoter.<br />
<br />
Enfin, il faut aussi adapter le fichier "ProtocolsDecoders" afin que la LUFA arrive à décoder notre trame : <syntaxhighlight lang="c"><br />
void DecodePICOFrameHeader(void* InDataStart)<br />
{<br />
PICO_Header_t* PICOHeader = (PICO_Header_t*)InDataStart;<br />
<br />
printf_P(PSTR(" \\\r\n PICO\r\n"));<br />
<br />
if (!(IP_COMPARE(&PICOHeader->Destination_IP, &ServerIPAddress)) &&<br />
!(IP_COMPARE(&PICOHeader->Destination_IP, &BroadcastIPAddress)))<br />
{<br />
printf_P(PSTR(" + NOT ADDRESSED TO DEVICE\r\n"));<br />
return;<br />
}<br />
<br />
printf_P(PSTR(" + MAC Dest: %u:%u:%u:%u:%u:%u\r\n"), PICOHeader->Destination_MAC.Octets[0],<br />
PICOHeader->Destination_MAC.Octets[1],<br />
PICOHeader->Destination_MAC.Octets[2],<br />
PICOHeader->Destination_MAC.Octets[3],<br />
PICOHeader->Destination_MAC.Octets[4],<br />
PICOHeader->Destination_MAC.Octets[5]);<br />
<br />
printf_P(PSTR(" + MAC Source : %u:%u:%u:%u:%u:%u\r\n"), PICOHeader->Source_MAC.Octets[0],<br />
PICOHeader->Source_MAC.Octets[1],<br />
PICOHeader->Source_MAC.Octets[2],<br />
PICOHeader->Source_MAC.Octets[3],<br />
PICOHeader->Source_MAC.Octets[4],<br />
PICOHeader->Source_MAC.Octets[5]);<br />
<br />
printf_P(PSTR(" + IP Dest : %u:%u:%u:%u\r\n"), PICOHeader->Destination_IP.Octets[0],<br />
PICOHeader->Destination_IP.Octets[1],<br />
PICOHeader->Destination_IP.Octets[2],<br />
PICOHeader->Destination_IP.Octets[3]);<br />
<br />
printf_P(PSTR(" + IP Source : %u:%u:%u:%u\r\n"), PICOHeader->Source_IP.Octets[0],<br />
PICOHeader->Source_IP.Octets[1],<br />
PICOHeader->Source_IP.Octets[2],<br />
PICOHeader->Source_IP.Octets[3]);<br />
<br />
printf_P(PSTR(" + Protocol : %x\r\n"), SwapEndian_16(PICOHeader->PICOType));<br />
}<br />
</syntaxhighlight>Après cela, nous pouvons envoyer une trame sur l'interface "usb0" utilisant notre protocole. Pour cela, nous avons modifié l'outil "ether" pour observer directement l'interface "usb0" et aussi pour que le filtre accepte notre protocole. En envoyant alors la trame, la LED s'allume bien correctement : <br />
[[Fichier:WhatsApp Video 2023-12-21 at 11.58.12.mp4|centré|vignette|Carte RNDIS réagissant à notre propre trame]]<br />
<br />
Cependant, on remarque que la LED s'allume, c'est-à-dire que la réponse est bien créée, mais elle n'est pas envoyée. En remontant chaque fonction pouvant être la cause du non-envoi de la réponse, nous avons "RNDIS_Task" que nous n'arrivons pas à comprendre. Cependant, nous n'avons pas modifié cette fonction, cela doit provenir de la trame envoyée, mais pourtant, le programme rentre bien complétement dans la fonction. À ce stade nous n'arrivons toujours pas à trouver la cause du problème.<br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2636SE4Binome2023-82023-12-28T13:12:38Z<p>Ncazin : /* Carte FPGA/VHDL : */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== 1) Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== 2) Ecriture de caractères sur le port série ===<br />
Tout d'abord, avant de commencer la tâche, nous savions que nous devions utiliser l'UART du microcontrolleur. De plus, la tâche suivante devait utiliser aussi l'UART. Puisque 2 tâches utilisent la même ressource, il faut implémenter un système pour savoir quelle tâche utilise la ressource. Nous avons alors utiliser une sémaphore pour chaque tâche, permettant ainsi de limiter l'accès temporairement à la ressources aux autres tâches : <syntaxhighlight lang="c"><br />
void semaphore_write(int action){<br />
if(action == TAKE_RESOURCE){<br />
while(1){<br />
cli();<br />
<br />
/** Ressource Disponible */<br />
if(sem_writing > 0){<br />
sem_writing = 0;<br />
sei();<br />
break;<br />
}<br />
<br />
/** Ressource occupée */<br />
else{<br />
tasks[actuel].reason = WORKING;<br />
tasks[actuel].state = SLEEPING;<br />
TCNT1 = 0;<br />
TIMER1_COMPA_vect();<br />
}<br />
sei();<br />
while(sem_writing == 0);<br />
}<br />
}<br />
if(action == DROP_RESOURCE){<br />
cli();<br />
sem_writing = 1;<br />
sei();<br />
}<br />
}<br />
</syntaxhighlight>Après avoir implémenté cette sémaphore, il fallait que nous comprenions comment utiliser l'UART du microcontrôlleur. Pour cela, il faut initialiser correctement l'UART pour pouvoir écrire et lire en série. La fonction suivante permet d'initialiser correctement l'UART : <syntaxhighlight lang="c"><br />
void init_usart(long int speed){<br />
UBRR0 = FREQUENCE/((unsigned long int)speed << 4) -1;<br />
UCSR0B = (1 << TXEN0 | 1 << RXEN0);<br />
UCSR0C = (1 << UCSZ01 | 1 << UCSZ00);<br />
UCSR0A &= ~(1 << U2X0);<br />
}<br />
</syntaxhighlight>Enfin, une fois l'initialisation réalisée, nous pouvons réaliser la tâche utilisant les fonctions permettant d'écrire plusieurs caractères (ici "abc") sur le port série, que l'on peut observer grâce à la commande shell ''"minicom -D /dev/ttyUSB0 -b 9600".'' On utilise alors les fonctions suivantes pour écrire sur le port série :<syntaxhighlight lang="c"><br />
void serial_send(unsigned char c){<br />
loop_until_bit_is_set(UCSR0A, UDRE0);<br />
UDR0 = c;<br />
}<br />
<br />
<br />
void serial_send_str(char chaine[]){<br />
semaphore_write(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
serial_send(chaine[i]);<br />
}<br />
semaphore_write(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut observer que la tâche fonctionne comme sur la vidéo suivante :[[Fichier:Tâche d'écriture sur le port série.mp4|vignette|Tâche d'écriture sur le port série|centré]]<br />
<br />
=== 3) Lecture sur le port série ===<br />
De la même façon que la tâche précédente, pour cette tâche nous devons lire les pressions de touches du clavier et les afficher sur le minicom. L'initialisation est déjà efféctuée et la sémaphore et la même que dans la partie précédente, nous ne la traiterons donc pas. On utilise alors les fonctions suivantes pour lire les pressions des touches sur le clavier, et la tâche les fait afficher ensuite : <syntaxhighlight lang="c"><br />
unsigned char serial_read(void){<br />
loop_until_bit_is_set(UCSR0A, RXC0);<br />
return UDR0;<br />
}<br />
<br />
<br />
void serial_read_str(char chaine[]){<br />
semaphore_read(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
chaine[i] = serial_read();<br />
}<br />
semaphore_read(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut alors observer les résultats grâce à la vidéo suivante : <br />
[[Fichier:Tâche de lecture sur le port série.mp4|centré|vignette|Tâche de lecture sur le port série]]<br />
<br />
=== 4) Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8 grâce au SPI. Il faut alors réussir à initialiser le SPI correctement :<syntaxhighlight lang="c"><br />
void SPI_MasterInit(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0);<br />
}<br />
</syntaxhighlight>Ensuite, nous avons rédiger un programme utilisé par notre tâche afin d'afficher différents caractères sur la matrice en allumant les LEDs voulues bit par bit :<syntaxhighlight lang="c"><br />
void loop_matrix(char letter[8]){<br />
int temp;<br />
PORTC &= ~(1 << CS);<br />
for(short int i = 0; i < 8; i++){<br />
<br />
for(short int j = 0; j < 8; j++)<br />
{<br />
temp = letter[i] & (1 << j); <br />
diplayLED(temp); //Envoir de chaque bit sur le SPI<br />
}<br />
}<br />
PORTC |= (1 << CS);<br />
}<br />
</syntaxhighlight>Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Nous pouvons alors voir le changement des LEDs allumées lorsque l'on appuie sur un autre caractère grâce à la vidéo suivante :<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage des caractères sur la matrice]]<br />
<br />
=== 5) Afficheur 7 segments ===<br />
Pour le 7 segments, l'initialisation est différente. En effet, le 7 segments ne fonctionne qu'à une fréquence maximale de 250kHz, il faut alors modifier l'initialisation du SPI de la tâche pour le faire fonctionner en changeant le paramètre SPCR :<syntaxhighlight lang="c"><br />
void SPI_MasterInit_segments(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
PORTB |= (1 << SS);<br />
PORTC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << SPR1); //SPR1 & SPR0 à 1 pour une fréquence en dessous de 250kHz (fréquence de l'afficheur 7 segments)<br />
}<br />
</syntaxhighlight>En envoyant alors la lettre appuyée sur le clavier, le 7segments convertit (si c'est posible) la lettre en segments à allumer comme nous pouvons le voir sur la vidéo suivante :[[Fichier:7segments.mp4|centré|vignette|Affichage des caractères sur le 7 segments]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
=== '''1) Contrôleur de bus série SPI''' ===<br />
<br />
<br />
Pour ce programme VHDL, nous avons voulu faire une communication SPI Maitre - Esclave. Pour cela =, nous nous sommes documentés sur comment fonctionnait cette communication. Il faut alors réaliser les 4 signaux MOSI, MISO, SS et SCK afin de pouvoir communiquer. On vérifie alors chacun de bits envoyé afin de gérér les signaux de contrôle et de l'entrée MISO. Ensuite, on génère les données de sortie pour la réponse. Enfin on peut assigner les sorties avec les informations que l'on a. Voici alors les processus utilisés : <syntaxhighlight lang="vhdl"><br />
-- Processus 1 : Gestion des signaux de contrôle et de l'entrée MISO<br />
process (reset, start_transfer, MISO)<br />
begin<br />
if reset = '1' then<br />
-- En cas de réinitialisation, retour à l'état IDLE<br />
state <= IDLE;<br />
bit_counter <= 0;<br />
SS <= '1';<br />
elsif start_transfer = '1' then<br />
-- Au début d'une nouvelle transmission, passage à l'état TRANSFER<br />
state <= TRANSFER;<br />
bit_counter <= 0;<br />
SS <= '0'; -- Sélection du périphérique esclave au début de la transmission<br />
elsif state = TRANSFER then<br />
-- Déplacement du bit reçu dans le tampon<br />
received_data <= MISO & received_data(7 downto 1);<br />
bit_counter <= bit_counter + 1;<br />
if bit_counter = 7 then<br />
-- Si tous les bits ont été déplacés, passage à l'état DONE<br />
state <= DONE;<br />
end if;<br />
elsif state = DONE then<br />
-- Fin de la transmission, désélection du périphérique esclave<br />
SS <= '1';<br />
state <= IDLE;<br />
end if;<br />
end process;<br />
<br />
-- Processus 2 : Génération des données de sortie (data_out)<br />
process (reset, start_transfer, bit_counter)<br />
begin<br />
if reset = '1' then<br />
-- En cas de réinitialisation, les données de sortie sont mises à zéro<br />
data_out <= (others => '0');<br />
elsif start_transfer = '1' then<br />
-- Au début d'une nouvelle transmission, envoi du premier bit<br />
data_out <= data_out(6 downto 0) & '0';<br />
elsif state = TRANSFER then<br />
-- Déplacement du bit à envoyer dans le registre de sortie<br />
data_out <= '0' & data_out(7 downto 1);<br />
end if;<br />
end process;<br />
<br />
-- Assignements des sorties<br />
transfer_done <= '1' when state = DONE else '0';<br />
clk <= not clk after 5 ns; -- Simulation de l'horloge (pour la démo)<br />
MOSI <= data_out(7);<br />
data_in <= received_data;<br />
</syntaxhighlight><br />
<br />
=== '''2) Contrôleur VGA''' ===<br />
Pour ce contrôleur, il faut utiliser le port VGA présent sur la carte Basys-3. Sur ce connecteur VGA, il y a plusieurs sorties à gérer. En effet, il y a les signaux de synchronisation HS et VS qui fonctionnent si ils ont une certaines formes d'ondes. Ces signaux doivent être à 0 pendant un certain temps. De plus nous avons les ports permettant de gérer les couleur, vert, bleu et rouge, chacun sur 4 bits. L'horloge du FPGA fonctionnant à 100MHz, nous devons la moduler à 60Hz, car l'écran fonctionne à cette fréquence. Pour cela, nous avons utilisé les IP catalogs. Ce sont des composants existants dans des librairies qui peuvent être utilisés. Dans notre cas, nous avons utilisé un composant qui permet de modifier la fréquence d’un signal.<br />
<br />
Nous avons ensuite reconstitué le signal de HS et VS. En effet, ces signaux ont besoin d’une période très spécifique permettant de bien configurer la taille de notre écran. Nous avons donc configuré un compteur incrémenté à chaque front montant de l’horloge, ce qui permet de mettre à l’état bas nos signaux.<br />
<br />
Le signal HS possède un front descendant à chaque changement de pixel, et lorsque que l’on a fait toute la ligne, un front descendant est envoyé sur VS pour descendre d’une ligne. Voici les programmes fait pour créer ces signaux : <syntaxhighlight lang="vhdl"><br />
Balayage : process(clk_pixel)<br />
begin<br />
if clk_pixel'event and clk_pixel = '1' then<br />
-- Compteur horizontal<br />
if compteur_horizontal < 1343 then<br />
compteur_horizontal <= compteur_horizontal + 1;<br />
else<br />
compteur_horizontal <= 0;<br />
<br />
-- Compteur vertical<br />
if compteur_vertical < 805 then<br />
compteur_vertical <= compteur_vertical + 1;<br />
else<br />
compteur_vertical <= 0;<br />
end if;<br />
end if;<br />
end if;<br />
<br />
-- Création signal HS<br />
if compteur_horizontal > 1047 and compteur_horizontal < 1184 then<br />
HS_out <= '0';<br />
HS_sig <= '0';<br />
else<br />
HS_out <= '1';<br />
HS_sig <= '1';<br />
end if;<br />
<br />
-- Création signal VS<br />
if compteur_vertical > 770 and compteur_vertical < 777 then<br />
VS_out <= '0';<br />
VS_sig <= '0';<br />
else<br />
VS_out <= '1';<br />
VS_sig <= '1';<br />
end if;<br />
</syntaxhighlight>Après avoir fait ces programmes, nous avons fait la simulation pour voir si les signaux étaient bien réalisés. Voici les simulations de ces signaux : <br />
<br />
[[Fichier:VGA signal VS.png|alt=VGA signal VS|centré|vignette|VGA signal VS]]<br />
[[Fichier:VGA signal HS.png|alt=VGA signal HS|centré|vignette|VGA signal HS]]<br />
<br />
<br />
Après avoir fait cela, il fallait s’occuper des sorties des couleurs. Pour cela, nous devons mettre les valeurs des canaux de couleurs au maximum lorsque les boutons correspondants sont appuyés et quand les signaux HS et VS sont eux aussi à 1. Une condition supplémentaire permet de contrôler la taille du carré à afficher. Les programmes de gestion des couleurs étant quasiment les mêmes aux exceptions des boutons à appuyer, nous ne montrerons que celui de la couleur rouge sur l’image ci-dessous : <syntaxhighlight lang="vhdl"><br />
-- Gestion couleur rouge --<br />
if B1_in = '1' and clk_pixel'event and clk_pixel = '1' then<br />
if VS_sig = '1' and HS_sig = '1' then<br />
if compteur_horizontal > 400 and compteur_horizontal < 600 then<br />
if compteur_vertical > 200 and compteur_vertical < 400 then<br />
red_out <= "1111";<br />
else<br />
red_out <= "0000";<br />
end if;<br />
else<br />
red_out <= "0000";<br />
end if;<br />
else<br />
red_out <= "0000";<br />
end if;<br />
end if;<br />
</syntaxhighlight>Au final, après la génération du fichier .bit, de la modification du fichier de contrainte et de l'envoi du programme sur la carte FPGA Basys-3, nous avons bien un carré pouvant changer de couleur lorsque l'on appuie sur un bouton : <br />
[[Fichier:Carré qui change de couleur grâce au contrôleur VGA.mp4|centré|vignette|Carré qui change de couleur grâce au contrôleur VGA]]<br />
Il nous manque alors la gestion de la couleur en mémoire, mais nous n'avons pas eu le temps de réaliser cette fonction. Cependant la gestion du contrôleur VGA et de la création des signaux HS et VS nous ont beaucoup appris sur le fonctionnement du VGA.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecté des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir réalisé le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux que l'on souhaite envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors routé notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :''<br />
[[Fichier:Carte reconnue après un "lsusb".png|alt=Carte reconnue après un "lsusb"|centré|vignette|Carte reconnue après un "lsusb"]]<br />
Après cela, nous allons entamé la programmation pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utilisé une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créé mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. <br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping de l'adresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et vérifiés leur bonne réception sur le terminal. Nous avons alors utiliser l'outil "ether" afin d'observer les paquets reçues sur l'interface "usb0" créée. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette|Réception de paquets IP ]]A ce moment-là, la carte allume bien les LEDs lors de la récéption des mêmes paquets que ceux implémentés dans la pile TCP/IP. Puisque l'on veut utiliser nos propres paquets avec notre protocole, nous devons ajouter dans cette pile le traitement de notre protocole. <br />
<br />
Tout d'abord, dans le fichier "EthernerProtocols.h", nous avons créer notre protocole. Le notre sera "0x0903"<syntaxhighlight lang="c"><br />
#define ETHERTYPE_PICO 0x0903<br />
</syntaxhighlight>Ensuite, il faut créer une structure représentant notre trame dans un fichier permettant son traitement. Ici, e fichier s'appelle "PICO.h". Nous avons alors choisi d'utiliser cette structure de trame : <syntaxhighlight lang="c"><br />
/** Type define for a PICO header. */<br />
typedef struct<br />
{<br />
MAC_Address_t Destination_MAC; /**< MAC address of the packet recipient */<br />
MAC_Address_t Source_MAC; /**< MAC address of the packet source */<br />
IP_Address_t Destination_IP; /**< IP address of the packet recipient */<br />
IP_Address_t Source_IP; /**< IP address of the packet source */<br />
uint16_t PICOType; /**< PICO packet sub-protocol type*/<br />
}PICO_Header_t;<br />
</syntaxhighlight>Dans le fichier c, il faut alors réaliser le traitement de cette trame pour créer la réponse : <syntaxhighlight lang="c"><br />
int16_t PICO_ProcessPICOPacket(void* InDataStart,<br />
void* OutDataStart)<br />
{<br />
PICO_Header_t* PICOHeaderIN = (PICO_Header_t*)InDataStart;<br />
PICO_Header_t* PICOHeaderOUT = (PICO_Header_t*)OutDataStart;<br />
<br />
/* Ensure that the PICO request is a PICO request packet */<br />
if (SwapEndian_16(PICOHeaderIN->PICOType) == ETHERTYPE_PICO)<br />
{<br />
if (IP_COMPARE(&PICOHeaderIN->Destination_IP, &ServerIPAddress)||<br />
MAC_COMPARE(&PICOHeaderIN->Destination_MAC, &ServerMACAddress))<br />
{<br />
/* Fill out the PICO response header */<br />
PICOHeaderOUT->Destination_MAC = PICOHeaderIN->Source_MAC;<br />
PICOHeaderOUT->Source_MAC = ServerMACAddress;<br />
PICOHeaderOUT->Destination_IP = PICOHeaderIN->Source_IP;<br />
PICOHeaderOUT->Source_IP = ServerIPAddress;<br />
PICOHeaderOUT->PICOType = PICOHeaderIN->PICOType;<br />
<br />
/* Blink the LED */<br />
PORTC ^= 0x30;<br />
<br />
/* Return the size of the response so far */<br />
return sizeof(PICO_Header_t);<br />
}<br />
}<br />
<br />
return NO_RESPONSE;<br />
}<br />
</syntaxhighlight>De cette façon, lorsqu'une trame respectant notre forme et utilisant notre protocole est envoyé sur l'interface, la LED de la carte devrait clignoter.<br />
<br />
Enfin, il faut aussi adapter le fichier "ProtocolsDecoders" afin que la LUFA arraive à décoder notre trame : <syntaxhighlight lang="c"><br />
void DecodePICOFrameHeader(void* InDataStart)<br />
{<br />
PICO_Header_t* PICOHeader = (PICO_Header_t*)InDataStart;<br />
<br />
printf_P(PSTR(" \\\r\n PICO\r\n"));<br />
<br />
if (!(IP_COMPARE(&PICOHeader->Destination_IP, &ServerIPAddress)) &&<br />
!(IP_COMPARE(&PICOHeader->Destination_IP, &BroadcastIPAddress)))<br />
{<br />
printf_P(PSTR(" + NOT ADDRESSED TO DEVICE\r\n"));<br />
return;<br />
}<br />
<br />
printf_P(PSTR(" + MAC Dest: %u:%u:%u:%u:%u:%u\r\n"), PICOHeader->Destination_MAC.Octets[0],<br />
PICOHeader->Destination_MAC.Octets[1],<br />
PICOHeader->Destination_MAC.Octets[2],<br />
PICOHeader->Destination_MAC.Octets[3],<br />
PICOHeader->Destination_MAC.Octets[4],<br />
PICOHeader->Destination_MAC.Octets[5]);<br />
<br />
printf_P(PSTR(" + MAC Source : %u:%u:%u:%u:%u:%u\r\n"), PICOHeader->Source_MAC.Octets[0],<br />
PICOHeader->Source_MAC.Octets[1],<br />
PICOHeader->Source_MAC.Octets[2],<br />
PICOHeader->Source_MAC.Octets[3],<br />
PICOHeader->Source_MAC.Octets[4],<br />
PICOHeader->Source_MAC.Octets[5]);<br />
<br />
printf_P(PSTR(" + IP Dest : %u:%u:%u:%u\r\n"), PICOHeader->Destination_IP.Octets[0],<br />
PICOHeader->Destination_IP.Octets[1],<br />
PICOHeader->Destination_IP.Octets[2],<br />
PICOHeader->Destination_IP.Octets[3]);<br />
<br />
printf_P(PSTR(" + IP Source : %u:%u:%u:%u\r\n"), PICOHeader->Source_IP.Octets[0],<br />
PICOHeader->Source_IP.Octets[1],<br />
PICOHeader->Source_IP.Octets[2],<br />
PICOHeader->Source_IP.Octets[3]);<br />
<br />
printf_P(PSTR(" + Protocol : %x\r\n"), SwapEndian_16(PICOHeader->PICOType));<br />
}<br />
</syntaxhighlight>Après cela, nous pouvons envoyer une trame sur l'interface "usb0" utilisant notre protocole. Pour cela, nous avons modifié l'outil "ether" pour observer directement l'interface "usb0" et aussi pour que le filtre accepte notre protocole. En envoyant alors la trame, la LED s'allume bien correctement : <br />
[[Fichier:WhatsApp Video 2023-12-21 at 11.58.12.mp4|centré|vignette|Carte RNDIS réagissant à notre propre trame]]<br />
<br />
<br />
Cependant, on remarque que la LED s'allume, c'est-à-dire que la réponse est bien créée, mais elle n'est pas envoyée. En remontant chaque fonction pouvant être la cause du non-envoi de la réponse, nous avons "RNDIS_Task" que nous n'arrivons pas à comprendre. Cependant, nous n'avons pas modifié cette fonction, cela doit venir de la trame envoyée, mais pourtant le programme rentre bien complétement dans la fonction. A ce stade nous n'arrivons toujours pas à trouver la cause du problème.<br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2635SE4Binome2023-82023-12-28T13:11:03Z<p>Ncazin : /* 2) Soudure de la carte électronique RNDIS */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== 1) Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== 2) Ecriture de caractères sur le port série ===<br />
Tout d'abord, avant de commencer la tâche, nous savions que nous devions utiliser l'UART du microcontrolleur. De plus, la tâche suivante devait utiliser aussi l'UART. Puisque 2 tâches utilisent la même ressource, il faut implémenter un système pour savoir quelle tâche utilise la ressource. Nous avons alors utiliser une sémaphore pour chaque tâche, permettant ainsi de limiter l'accès temporairement à la ressources aux autres tâches : <syntaxhighlight lang="c"><br />
void semaphore_write(int action){<br />
if(action == TAKE_RESOURCE){<br />
while(1){<br />
cli();<br />
<br />
/** Ressource Disponible */<br />
if(sem_writing > 0){<br />
sem_writing = 0;<br />
sei();<br />
break;<br />
}<br />
<br />
/** Ressource occupée */<br />
else{<br />
tasks[actuel].reason = WORKING;<br />
tasks[actuel].state = SLEEPING;<br />
TCNT1 = 0;<br />
TIMER1_COMPA_vect();<br />
}<br />
sei();<br />
while(sem_writing == 0);<br />
}<br />
}<br />
if(action == DROP_RESOURCE){<br />
cli();<br />
sem_writing = 1;<br />
sei();<br />
}<br />
}<br />
</syntaxhighlight>Après avoir implémenté cette sémaphore, il fallait que nous comprenions comment utiliser l'UART du microcontrôlleur. Pour cela, il faut initialiser correctement l'UART pour pouvoir écrire et lire en série. La fonction suivante permet d'initialiser correctement l'UART : <syntaxhighlight lang="c"><br />
void init_usart(long int speed){<br />
UBRR0 = FREQUENCE/((unsigned long int)speed << 4) -1;<br />
UCSR0B = (1 << TXEN0 | 1 << RXEN0);<br />
UCSR0C = (1 << UCSZ01 | 1 << UCSZ00);<br />
UCSR0A &= ~(1 << U2X0);<br />
}<br />
</syntaxhighlight>Enfin, une fois l'initialisation réalisée, nous pouvons réaliser la tâche utilisant les fonctions permettant d'écrire plusieurs caractères (ici "abc") sur le port série, que l'on peut observer grâce à la commande shell ''"minicom -D /dev/ttyUSB0 -b 9600".'' On utilise alors les fonctions suivantes pour écrire sur le port série :<syntaxhighlight lang="c"><br />
void serial_send(unsigned char c){<br />
loop_until_bit_is_set(UCSR0A, UDRE0);<br />
UDR0 = c;<br />
}<br />
<br />
<br />
void serial_send_str(char chaine[]){<br />
semaphore_write(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
serial_send(chaine[i]);<br />
}<br />
semaphore_write(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut observer que la tâche fonctionne comme sur la vidéo suivante :[[Fichier:Tâche d'écriture sur le port série.mp4|vignette|Tâche d'écriture sur le port série|centré]]<br />
<br />
=== 3) Lecture sur le port série ===<br />
De la même façon que la tâche précédente, pour cette tâche nous devons lire les pressions de touches du clavier et les afficher sur le minicom. L'initialisation est déjà efféctuée et la sémaphore et la même que dans la partie précédente, nous ne la traiterons donc pas. On utilise alors les fonctions suivantes pour lire les pressions des touches sur le clavier, et la tâche les fait afficher ensuite : <syntaxhighlight lang="c"><br />
unsigned char serial_read(void){<br />
loop_until_bit_is_set(UCSR0A, RXC0);<br />
return UDR0;<br />
}<br />
<br />
<br />
void serial_read_str(char chaine[]){<br />
semaphore_read(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
chaine[i] = serial_read();<br />
}<br />
semaphore_read(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut alors observer les résultats grâce à la vidéo suivante : <br />
[[Fichier:Tâche de lecture sur le port série.mp4|centré|vignette|Tâche de lecture sur le port série]]<br />
<br />
=== 4) Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8 grâce au SPI. Il faut alors réussir à initialiser le SPI correctement :<syntaxhighlight lang="c"><br />
void SPI_MasterInit(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0);<br />
}<br />
</syntaxhighlight>Ensuite, nous avons rédiger un programme utilisé par notre tâche afin d'afficher différents caractères sur la matrice en allumant les LEDs voulues bit par bit :<syntaxhighlight lang="c"><br />
void loop_matrix(char letter[8]){<br />
int temp;<br />
PORTC &= ~(1 << CS);<br />
for(short int i = 0; i < 8; i++){<br />
<br />
for(short int j = 0; j < 8; j++)<br />
{<br />
temp = letter[i] & (1 << j); <br />
diplayLED(temp); //Envoir de chaque bit sur le SPI<br />
}<br />
}<br />
PORTC |= (1 << CS);<br />
}<br />
</syntaxhighlight>Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Nous pouvons alors voir le changement des LEDs allumées lorsque l'on appuie sur un autre caractère grâce à la vidéo suivante :<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage des caractères sur la matrice]]<br />
<br />
=== 5) Afficheur 7 segments ===<br />
Pour le 7 segments, l'initialisation est différente. En effet, le 7 segments ne fonctionne qu'à une fréquence maximale de 250kHz, il faut alors modifier l'initialisation du SPI de la tâche pour le faire fonctionner en changeant le paramètre SPCR :<syntaxhighlight lang="c"><br />
void SPI_MasterInit_segments(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
PORTB |= (1 << SS);<br />
PORTC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << SPR1); //SPR1 & SPR0 à 1 pour une fréquence en dessous de 250kHz (fréquence de l'afficheur 7 segments)<br />
}<br />
</syntaxhighlight>En envoyant alors la lettre appuyée sur le clavier, le 7segments convertit (si c'est posible) la lettre en segments à allumer comme nous pouvons le voir sur la vidéo suivante :[[Fichier:7segments.mp4|centré|vignette|Affichage des caractères sur le 7 segments]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
'''<big>1) Contrôleur de bus série SPI</big>'''<br />
<br />
Pour ce programme VHDL, nous avons voulu faire une communication SPI Maitre - Esclave. Pour cela =, nous nous sommes documentés sur comment fonctionnait cette communication. Il faut alors réaliser les 4 signaux MOSI, MISO, SS et SCK afin de pouvoir communiquer. On vérifie alors chacun de bits envoyé afin de gérér les signaux de contrôle et de l'entrée MISO. Ensuite, on génère les données de sortie pour la réponse. Enfin on peut assigner les sorties avec les informations que l'on a. Voici alors les processus utilisés : <syntaxhighlight lang="vhdl"><br />
-- Processus 1 : Gestion des signaux de contrôle et de l'entrée MISO<br />
process (reset, start_transfer, MISO)<br />
begin<br />
if reset = '1' then<br />
-- En cas de réinitialisation, retour à l'état IDLE<br />
state <= IDLE;<br />
bit_counter <= 0;<br />
SS <= '1';<br />
elsif start_transfer = '1' then<br />
-- Au début d'une nouvelle transmission, passage à l'état TRANSFER<br />
state <= TRANSFER;<br />
bit_counter <= 0;<br />
SS <= '0'; -- Sélection du périphérique esclave au début de la transmission<br />
elsif state = TRANSFER then<br />
-- Déplacement du bit reçu dans le tampon<br />
received_data <= MISO & received_data(7 downto 1);<br />
bit_counter <= bit_counter + 1;<br />
if bit_counter = 7 then<br />
-- Si tous les bits ont été déplacés, passage à l'état DONE<br />
state <= DONE;<br />
end if;<br />
elsif state = DONE then<br />
-- Fin de la transmission, désélection du périphérique esclave<br />
SS <= '1';<br />
state <= IDLE;<br />
end if;<br />
end process;<br />
<br />
-- Processus 2 : Génération des données de sortie (data_out)<br />
process (reset, start_transfer, bit_counter)<br />
begin<br />
if reset = '1' then<br />
-- En cas de réinitialisation, les données de sortie sont mises à zéro<br />
data_out <= (others => '0');<br />
elsif start_transfer = '1' then<br />
-- Au début d'une nouvelle transmission, envoi du premier bit<br />
data_out <= data_out(6 downto 0) & '0';<br />
elsif state = TRANSFER then<br />
-- Déplacement du bit à envoyer dans le registre de sortie<br />
data_out <= '0' & data_out(7 downto 1);<br />
end if;<br />
end process;<br />
<br />
-- Assignements des sorties<br />
transfer_done <= '1' when state = DONE else '0';<br />
clk <= not clk after 5 ns; -- Simulation de l'horloge (pour la démo)<br />
MOSI <= data_out(7);<br />
data_in <= received_data;<br />
</syntaxhighlight>'''<big>2) Contrôleur VGA</big>'''<br />
<br />
Pour ce contrôleur, il faut utiliser le port VGA présent sur la carte Basys-3. Sur ce connecteur VGA, il y a plusieurs sorties à gérer. En effet, il y a les signaux de synchronisation HS et VS qui fonctionnent si ils ont une certaines formes d'ondes. Ces signaux doivent être à 0 pendant un certain temps. De plus nous avons les ports permettant de gérer les couleur, vert, bleu et rouge, chacun sur 4 bits. L'horloge du FPGA fonctionnant à 100MHz, nous devons la moduler à 60Hz, car l'écran fonctionne à cette fréquence. Pour cela, nous avons utilisé les IP catalogs. Ce sont des composants existants dans des librairies qui peuvent être utilisés. Dans notre cas, nous avons utilisé un composant qui permet de modifier la fréquence d’un signal.<br />
<br />
Nous avons ensuite reconstitué le signal de HS et VS. En effet, ces signaux ont besoin d’une période très spécifique permettant de bien configurer la taille de notre écran. Nous avons donc configuré un compteur incrémenté à chaque front montant de l’horloge, ce qui permet de mettre à l’état bas nos signaux.<br />
<br />
Le signal HS possède un front descendant à chaque changement de pixel, et lorsque que l’on a fait toute la ligne, un front descendant est envoyé sur VS pour descendre d’une ligne. Voici les programmes fait pour créer ces signaux : <syntaxhighlight lang="vhdl"><br />
Balayage : process(clk_pixel)<br />
begin<br />
if clk_pixel'event and clk_pixel = '1' then<br />
-- Compteur horizontal<br />
if compteur_horizontal < 1343 then<br />
compteur_horizontal <= compteur_horizontal + 1;<br />
else<br />
compteur_horizontal <= 0;<br />
<br />
-- Compteur vertical<br />
if compteur_vertical < 805 then<br />
compteur_vertical <= compteur_vertical + 1;<br />
else<br />
compteur_vertical <= 0;<br />
end if;<br />
end if;<br />
end if;<br />
<br />
-- Création signal HS<br />
if compteur_horizontal > 1047 and compteur_horizontal < 1184 then<br />
HS_out <= '0';<br />
HS_sig <= '0';<br />
else<br />
HS_out <= '1';<br />
HS_sig <= '1';<br />
end if;<br />
<br />
-- Création signal VS<br />
if compteur_vertical > 770 and compteur_vertical < 777 then<br />
VS_out <= '0';<br />
VS_sig <= '0';<br />
else<br />
VS_out <= '1';<br />
VS_sig <= '1';<br />
end if;<br />
</syntaxhighlight>Après avoir fait ces programmes, nous avons fait la simulation pour voir si les signaux étaient bien réalisés. Voici les simulations de ces signaux : <br />
<br />
[[Fichier:VGA signal VS.png|alt=VGA signal VS|centré|vignette|VGA signal VS]]<br />
[[Fichier:VGA signal HS.png|alt=VGA signal HS|centré|vignette|VGA signal HS]]<br />
<br />
<br />
Après avoir fait cela, il fallait s’occuper des sorties des couleurs. Pour cela, nous devons mettre les valeurs des canaux de couleurs au maximum lorsque les boutons correspondants sont appuyés et quand les signaux HS et VS sont eux aussi à 1. Une condition supplémentaire permet de contrôler la taille du carré à afficher. Les programmes de gestion des couleurs étant quasiment les mêmes aux exceptions des boutons à appuyer, nous ne montrerons que celui de la couleur rouge sur l’image ci-dessous : <syntaxhighlight lang="vhdl"><br />
-- Gestion couleur rouge --<br />
if B1_in = '1' and clk_pixel'event and clk_pixel = '1' then<br />
if VS_sig = '1' and HS_sig = '1' then<br />
if compteur_horizontal > 400 and compteur_horizontal < 600 then<br />
if compteur_vertical > 200 and compteur_vertical < 400 then<br />
red_out <= "1111";<br />
else<br />
red_out <= "0000";<br />
end if;<br />
else<br />
red_out <= "0000";<br />
end if;<br />
else<br />
red_out <= "0000";<br />
end if;<br />
end if;<br />
</syntaxhighlight>Au final, après la génération du fichier .bit, de la modification du fichier de contrainte et de l'envoi du programme sur la carte FPGA Basys-3, nous avons bien un carré pouvant changer de couleur lorsque l'on appuie sur un bouton : <br />
[[Fichier:Carré qui change de couleur grâce au contrôleur VGA.mp4|centré|vignette|Carré qui change de couleur grâce au contrôleur VGA]]<br />
Il nous manque alors la gestion de la couleur en mémoire, mais nous n'avons pas eu le temps de réaliser cette fonction. Cependant la gestion du contrôleur VGA et de la création des signaux HS et VS nous ont beaucoup appris sur le fonctionnement du VGA.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecté des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir réalisé le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux que l'on souhaite envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors routé notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :''<br />
[[Fichier:Carte reconnue après un "lsusb".png|alt=Carte reconnue après un "lsusb"|centré|vignette|Carte reconnue après un "lsusb"]]<br />
Après cela, nous allons entamé la programmation pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utilisé une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créé mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. <br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping de l'adresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et vérifiés leur bonne réception sur le terminal. Nous avons alors utiliser l'outil "ether" afin d'observer les paquets reçues sur l'interface "usb0" créée. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette|Réception de paquets IP ]]A ce moment-là, la carte allume bien les LEDs lors de la récéption des mêmes paquets que ceux implémentés dans la pile TCP/IP. Puisque l'on veut utiliser nos propres paquets avec notre protocole, nous devons ajouter dans cette pile le traitement de notre protocole. <br />
<br />
Tout d'abord, dans le fichier "EthernerProtocols.h", nous avons créer notre protocole. Le notre sera "0x0903"<syntaxhighlight lang="c"><br />
#define ETHERTYPE_PICO 0x0903<br />
</syntaxhighlight>Ensuite, il faut créer une structure représentant notre trame dans un fichier permettant son traitement. Ici, e fichier s'appelle "PICO.h". Nous avons alors choisi d'utiliser cette structure de trame : <syntaxhighlight lang="c"><br />
/** Type define for a PICO header. */<br />
typedef struct<br />
{<br />
MAC_Address_t Destination_MAC; /**< MAC address of the packet recipient */<br />
MAC_Address_t Source_MAC; /**< MAC address of the packet source */<br />
IP_Address_t Destination_IP; /**< IP address of the packet recipient */<br />
IP_Address_t Source_IP; /**< IP address of the packet source */<br />
uint16_t PICOType; /**< PICO packet sub-protocol type*/<br />
}PICO_Header_t;<br />
</syntaxhighlight>Dans le fichier c, il faut alors réaliser le traitement de cette trame pour créer la réponse : <syntaxhighlight lang="c"><br />
int16_t PICO_ProcessPICOPacket(void* InDataStart,<br />
void* OutDataStart)<br />
{<br />
PICO_Header_t* PICOHeaderIN = (PICO_Header_t*)InDataStart;<br />
PICO_Header_t* PICOHeaderOUT = (PICO_Header_t*)OutDataStart;<br />
<br />
/* Ensure that the PICO request is a PICO request packet */<br />
if (SwapEndian_16(PICOHeaderIN->PICOType) == ETHERTYPE_PICO)<br />
{<br />
if (IP_COMPARE(&PICOHeaderIN->Destination_IP, &ServerIPAddress)||<br />
MAC_COMPARE(&PICOHeaderIN->Destination_MAC, &ServerMACAddress))<br />
{<br />
/* Fill out the PICO response header */<br />
PICOHeaderOUT->Destination_MAC = PICOHeaderIN->Source_MAC;<br />
PICOHeaderOUT->Source_MAC = ServerMACAddress;<br />
PICOHeaderOUT->Destination_IP = PICOHeaderIN->Source_IP;<br />
PICOHeaderOUT->Source_IP = ServerIPAddress;<br />
PICOHeaderOUT->PICOType = PICOHeaderIN->PICOType;<br />
<br />
/* Blink the LED */<br />
PORTC ^= 0x30;<br />
<br />
/* Return the size of the response so far */<br />
return sizeof(PICO_Header_t);<br />
}<br />
}<br />
<br />
return NO_RESPONSE;<br />
}<br />
</syntaxhighlight>De cette façon, lorsqu'une trame respectant notre forme et utilisant notre protocole est envoyé sur l'interface, la LED de la carte devrait clignoter.<br />
<br />
Enfin, il faut aussi adapter le fichier "ProtocolsDecoders" afin que la LUFA arraive à décoder notre trame : <syntaxhighlight lang="c"><br />
void DecodePICOFrameHeader(void* InDataStart)<br />
{<br />
PICO_Header_t* PICOHeader = (PICO_Header_t*)InDataStart;<br />
<br />
printf_P(PSTR(" \\\r\n PICO\r\n"));<br />
<br />
if (!(IP_COMPARE(&PICOHeader->Destination_IP, &ServerIPAddress)) &&<br />
!(IP_COMPARE(&PICOHeader->Destination_IP, &BroadcastIPAddress)))<br />
{<br />
printf_P(PSTR(" + NOT ADDRESSED TO DEVICE\r\n"));<br />
return;<br />
}<br />
<br />
printf_P(PSTR(" + MAC Dest: %u:%u:%u:%u:%u:%u\r\n"), PICOHeader->Destination_MAC.Octets[0],<br />
PICOHeader->Destination_MAC.Octets[1],<br />
PICOHeader->Destination_MAC.Octets[2],<br />
PICOHeader->Destination_MAC.Octets[3],<br />
PICOHeader->Destination_MAC.Octets[4],<br />
PICOHeader->Destination_MAC.Octets[5]);<br />
<br />
printf_P(PSTR(" + MAC Source : %u:%u:%u:%u:%u:%u\r\n"), PICOHeader->Source_MAC.Octets[0],<br />
PICOHeader->Source_MAC.Octets[1],<br />
PICOHeader->Source_MAC.Octets[2],<br />
PICOHeader->Source_MAC.Octets[3],<br />
PICOHeader->Source_MAC.Octets[4],<br />
PICOHeader->Source_MAC.Octets[5]);<br />
<br />
printf_P(PSTR(" + IP Dest : %u:%u:%u:%u\r\n"), PICOHeader->Destination_IP.Octets[0],<br />
PICOHeader->Destination_IP.Octets[1],<br />
PICOHeader->Destination_IP.Octets[2],<br />
PICOHeader->Destination_IP.Octets[3]);<br />
<br />
printf_P(PSTR(" + IP Source : %u:%u:%u:%u\r\n"), PICOHeader->Source_IP.Octets[0],<br />
PICOHeader->Source_IP.Octets[1],<br />
PICOHeader->Source_IP.Octets[2],<br />
PICOHeader->Source_IP.Octets[3]);<br />
<br />
printf_P(PSTR(" + Protocol : %x\r\n"), SwapEndian_16(PICOHeader->PICOType));<br />
}<br />
</syntaxhighlight>Après cela, nous pouvons envoyer une trame sur l'interface "usb0" utilisant notre protocole. Pour cela, nous avons modifié l'outil "ether" pour observer directement l'interface "usb0" et aussi pour que le filtre accepte notre protocole. En envoyant alors la trame, la LED s'allume bien correctement : <br />
[[Fichier:WhatsApp Video 2023-12-21 at 11.58.12.mp4|centré|vignette|Carte RNDIS réagissant à notre propre trame]]<br />
<br />
<br />
Cependant, on remarque que la LED s'allume, c'est-à-dire que la réponse est bien créée, mais elle n'est pas envoyée. En remontant chaque fonction pouvant être la cause du non-envoi de la réponse, nous avons "RNDIS_Task" que nous n'arrivons pas à comprendre. Cependant, nous n'avons pas modifié cette fonction, cela doit venir de la trame envoyée, mais pourtant le programme rentre bien complétement dans la fonction. A ce stade nous n'arrivons toujours pas à trouver la cause du problème.<br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Carr%C3%A9_qui_change_de_couleur_gr%C3%A2ce_au_contr%C3%B4leur_VGA.mp4&diff=2634Fichier:Carré qui change de couleur grâce au contrôleur VGA.mp42023-12-28T13:09:47Z<p>Ncazin : </p>
<hr />
<div>Carré qui change de couleur grâce au contrôleur VGA</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:VGA_signal_VS.png&diff=2633Fichier:VGA signal VS.png2023-12-28T13:00:58Z<p>Ncazin : </p>
<hr />
<div>VGA signal VS</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:VGA_signal_HS.png&diff=2632Fichier:VGA signal HS.png2023-12-28T13:00:23Z<p>Ncazin : </p>
<hr />
<div>VGA signal HS</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2631SE4Binome2023-82023-12-28T11:37:40Z<p>Ncazin : /* 3) Programmation de la carte électronique RNDIS */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== 1) Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== 2) Ecriture de caractères sur le port série ===<br />
Tout d'abord, avant de commencer la tâche, nous savions que nous devions utiliser l'UART du microcontrolleur. De plus, la tâche suivante devait utiliser aussi l'UART. Puisque 2 tâches utilisent la même ressource, il faut implémenter un système pour savoir quelle tâche utilise la ressource. Nous avons alors utiliser une sémaphore pour chaque tâche, permettant ainsi de limiter l'accès temporairement à la ressources aux autres tâches : <syntaxhighlight lang="c"><br />
void semaphore_write(int action){<br />
if(action == TAKE_RESOURCE){<br />
while(1){<br />
cli();<br />
<br />
/** Ressource Disponible */<br />
if(sem_writing > 0){<br />
sem_writing = 0;<br />
sei();<br />
break;<br />
}<br />
<br />
/** Ressource occupée */<br />
else{<br />
tasks[actuel].reason = WORKING;<br />
tasks[actuel].state = SLEEPING;<br />
TCNT1 = 0;<br />
TIMER1_COMPA_vect();<br />
}<br />
sei();<br />
while(sem_writing == 0);<br />
}<br />
}<br />
if(action == DROP_RESOURCE){<br />
cli();<br />
sem_writing = 1;<br />
sei();<br />
}<br />
}<br />
</syntaxhighlight>Après avoir implémenté cette sémaphore, il fallait que nous comprenions comment utiliser l'UART du microcontrôlleur. Pour cela, il faut initialiser correctement l'UART pour pouvoir écrire et lire en série. La fonction suivante permet d'initialiser correctement l'UART : <syntaxhighlight lang="c"><br />
void init_usart(long int speed){<br />
UBRR0 = FREQUENCE/((unsigned long int)speed << 4) -1;<br />
UCSR0B = (1 << TXEN0 | 1 << RXEN0);<br />
UCSR0C = (1 << UCSZ01 | 1 << UCSZ00);<br />
UCSR0A &= ~(1 << U2X0);<br />
}<br />
</syntaxhighlight>Enfin, une fois l'initialisation réalisée, nous pouvons réaliser la tâche utilisant les fonctions permettant d'écrire plusieurs caractères (ici "abc") sur le port série, que l'on peut observer grâce à la commande shell ''"minicom -D /dev/ttyUSB0 -b 9600".'' On utilise alors les fonctions suivantes pour écrire sur le port série :<syntaxhighlight lang="c"><br />
void serial_send(unsigned char c){<br />
loop_until_bit_is_set(UCSR0A, UDRE0);<br />
UDR0 = c;<br />
}<br />
<br />
<br />
void serial_send_str(char chaine[]){<br />
semaphore_write(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
serial_send(chaine[i]);<br />
}<br />
semaphore_write(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut observer que la tâche fonctionne comme sur la vidéo suivante :[[Fichier:Tâche d'écriture sur le port série.mp4|vignette|Tâche d'écriture sur le port série|centré]]<br />
<br />
=== 3) Lecture sur le port série ===<br />
De la même façon que la tâche précédente, pour cette tâche nous devons lire les pressions de touches du clavier et les afficher sur le minicom. L'initialisation est déjà efféctuée et la sémaphore et la même que dans la partie précédente, nous ne la traiterons donc pas. On utilise alors les fonctions suivantes pour lire les pressions des touches sur le clavier, et la tâche les fait afficher ensuite : <syntaxhighlight lang="c"><br />
unsigned char serial_read(void){<br />
loop_until_bit_is_set(UCSR0A, RXC0);<br />
return UDR0;<br />
}<br />
<br />
<br />
void serial_read_str(char chaine[]){<br />
semaphore_read(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
chaine[i] = serial_read();<br />
}<br />
semaphore_read(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut alors observer les résultats grâce à la vidéo suivante : <br />
[[Fichier:Tâche de lecture sur le port série.mp4|centré|vignette|Tâche de lecture sur le port série]]<br />
<br />
=== 4) Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8 grâce au SPI. Il faut alors réussir à initialiser le SPI correctement :<syntaxhighlight lang="c"><br />
void SPI_MasterInit(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0);<br />
}<br />
</syntaxhighlight>Ensuite, nous avons rédiger un programme utilisé par notre tâche afin d'afficher différents caractères sur la matrice en allumant les LEDs voulues bit par bit :<syntaxhighlight lang="c"><br />
void loop_matrix(char letter[8]){<br />
int temp;<br />
PORTC &= ~(1 << CS);<br />
for(short int i = 0; i < 8; i++){<br />
<br />
for(short int j = 0; j < 8; j++)<br />
{<br />
temp = letter[i] & (1 << j); <br />
diplayLED(temp); //Envoir de chaque bit sur le SPI<br />
}<br />
}<br />
PORTC |= (1 << CS);<br />
}<br />
</syntaxhighlight>Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Nous pouvons alors voir le changement des LEDs allumées lorsque l'on appuie sur un autre caractère grâce à la vidéo suivante :<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage des caractères sur la matrice]]<br />
<br />
=== 5) Afficheur 7 segments ===<br />
Pour le 7 segments, l'initialisation est différente. En effet, le 7 segments ne fonctionne qu'à une fréquence maximale de 250kHz, il faut alors modifier l'initialisation du SPI de la tâche pour le faire fonctionner en changeant le paramètre SPCR :<syntaxhighlight lang="c"><br />
void SPI_MasterInit_segments(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
PORTB |= (1 << SS);<br />
PORTC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << SPR1); //SPR1 & SPR0 à 1 pour une fréquence en dessous de 250kHz (fréquence de l'afficheur 7 segments)<br />
}<br />
</syntaxhighlight>En envoyant alors la lettre appuyée sur le clavier, le 7segments convertit (si c'est posible) la lettre en segments à allumer comme nous pouvons le voir sur la vidéo suivante :[[Fichier:7segments.mp4|centré|vignette|Affichage des caractères sur le 7 segments]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecté des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir réalisé le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux que l'on souhaite envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors routé notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :''<br />
[[Fichier:Carte reconnue après un "lsusb".png|alt=Carte reconnue après un "lsusb"|centré|vignette|Carte reconnue après un "lsusb"]]<br />
Après cela, nous allons entamé la programmation pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utilisé une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créé mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. <br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping de l'adresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et vérifiés leur bonne réception sur le terminal. Nous avons alors utiliser l'outil "ether" afin d'observer les paquets reçues sur l'interface "usb0" créée. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette|Réception de paquets IP ]]A ce moment-là, la carte allume bien les LEDs lors de la récéption des mêmes paquets que ceux implémentés dans la pile TCP/IP. Puisque l'on veut utiliser nos propres paquets avec notre protocole, nous devons ajouter dans cette pile le traitement de notre protocole. <br />
<br />
Tout d'abord, dans le fichier "EthernerProtocols.h", nous avons créer notre protocole. Le notre sera "0x0903"<syntaxhighlight lang="c"><br />
#define ETHERTYPE_PICO 0x0903<br />
</syntaxhighlight>Ensuite, il faut créer une structure représentant notre trame dans un fichier permettant son traitement. Ici, e fichier s'appelle "PICO.h". Nous avons alors choisi d'utiliser cette structure de trame : <syntaxhighlight lang="c"><br />
/** Type define for a PICO header. */<br />
typedef struct<br />
{<br />
MAC_Address_t Destination_MAC; /**< MAC address of the packet recipient */<br />
MAC_Address_t Source_MAC; /**< MAC address of the packet source */<br />
IP_Address_t Destination_IP; /**< IP address of the packet recipient */<br />
IP_Address_t Source_IP; /**< IP address of the packet source */<br />
uint16_t PICOType; /**< PICO packet sub-protocol type*/<br />
}PICO_Header_t;<br />
</syntaxhighlight>Dans le fichier c, il faut alors réaliser le traitement de cette trame pour créer la réponse : <syntaxhighlight lang="c"><br />
int16_t PICO_ProcessPICOPacket(void* InDataStart,<br />
void* OutDataStart)<br />
{<br />
PICO_Header_t* PICOHeaderIN = (PICO_Header_t*)InDataStart;<br />
PICO_Header_t* PICOHeaderOUT = (PICO_Header_t*)OutDataStart;<br />
<br />
/* Ensure that the PICO request is a PICO request packet */<br />
if (SwapEndian_16(PICOHeaderIN->PICOType) == ETHERTYPE_PICO)<br />
{<br />
if (IP_COMPARE(&PICOHeaderIN->Destination_IP, &ServerIPAddress)||<br />
MAC_COMPARE(&PICOHeaderIN->Destination_MAC, &ServerMACAddress))<br />
{<br />
/* Fill out the PICO response header */<br />
PICOHeaderOUT->Destination_MAC = PICOHeaderIN->Source_MAC;<br />
PICOHeaderOUT->Source_MAC = ServerMACAddress;<br />
PICOHeaderOUT->Destination_IP = PICOHeaderIN->Source_IP;<br />
PICOHeaderOUT->Source_IP = ServerIPAddress;<br />
PICOHeaderOUT->PICOType = PICOHeaderIN->PICOType;<br />
<br />
/* Blink the LED */<br />
PORTC ^= 0x30;<br />
<br />
/* Return the size of the response so far */<br />
return sizeof(PICO_Header_t);<br />
}<br />
}<br />
<br />
return NO_RESPONSE;<br />
}<br />
</syntaxhighlight>De cette façon, lorsqu'une trame respectant notre forme et utilisant notre protocole est envoyé sur l'interface, la LED de la carte devrait clignoter.<br />
<br />
Enfin, il faut aussi adapter le fichier "ProtocolsDecoders" afin que la LUFA arraive à décoder notre trame : <syntaxhighlight lang="c"><br />
void DecodePICOFrameHeader(void* InDataStart)<br />
{<br />
PICO_Header_t* PICOHeader = (PICO_Header_t*)InDataStart;<br />
<br />
printf_P(PSTR(" \\\r\n PICO\r\n"));<br />
<br />
if (!(IP_COMPARE(&PICOHeader->Destination_IP, &ServerIPAddress)) &&<br />
!(IP_COMPARE(&PICOHeader->Destination_IP, &BroadcastIPAddress)))<br />
{<br />
printf_P(PSTR(" + NOT ADDRESSED TO DEVICE\r\n"));<br />
return;<br />
}<br />
<br />
printf_P(PSTR(" + MAC Dest: %u:%u:%u:%u:%u:%u\r\n"), PICOHeader->Destination_MAC.Octets[0],<br />
PICOHeader->Destination_MAC.Octets[1],<br />
PICOHeader->Destination_MAC.Octets[2],<br />
PICOHeader->Destination_MAC.Octets[3],<br />
PICOHeader->Destination_MAC.Octets[4],<br />
PICOHeader->Destination_MAC.Octets[5]);<br />
<br />
printf_P(PSTR(" + MAC Source : %u:%u:%u:%u:%u:%u\r\n"), PICOHeader->Source_MAC.Octets[0],<br />
PICOHeader->Source_MAC.Octets[1],<br />
PICOHeader->Source_MAC.Octets[2],<br />
PICOHeader->Source_MAC.Octets[3],<br />
PICOHeader->Source_MAC.Octets[4],<br />
PICOHeader->Source_MAC.Octets[5]);<br />
<br />
printf_P(PSTR(" + IP Dest : %u:%u:%u:%u\r\n"), PICOHeader->Destination_IP.Octets[0],<br />
PICOHeader->Destination_IP.Octets[1],<br />
PICOHeader->Destination_IP.Octets[2],<br />
PICOHeader->Destination_IP.Octets[3]);<br />
<br />
printf_P(PSTR(" + IP Source : %u:%u:%u:%u\r\n"), PICOHeader->Source_IP.Octets[0],<br />
PICOHeader->Source_IP.Octets[1],<br />
PICOHeader->Source_IP.Octets[2],<br />
PICOHeader->Source_IP.Octets[3]);<br />
<br />
printf_P(PSTR(" + Protocol : %x\r\n"), SwapEndian_16(PICOHeader->PICOType));<br />
}<br />
</syntaxhighlight>Après cela, nous pouvons envoyer une trame sur l'interface "usb0" utilisant notre protocole. Pour cela, nous avons modifié l'outil "ether" pour observer directement l'interface "usb0" et aussi pour que le filtre accepte notre protocole. En envoyant alors la trame, la LED s'allume bien correctement : <br />
[[Fichier:WhatsApp Video 2023-12-21 at 11.58.12.mp4|centré|vignette|Carte RNDIS réagissant à notre propre trame]]<br />
<br />
<br />
Cependant, on remarque que la LED s'allume, c'est-à-dire que la réponse est bien créée, mais elle n'est pas envoyée. En rem<br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:WhatsApp_Video_2023-12-21_at_11.58.12.mp4&diff=2630Fichier:WhatsApp Video 2023-12-21 at 11.58.12.mp42023-12-28T11:29:33Z<p>Ncazin : </p>
<hr />
<div>Carte RNDIS réagissant à notre propre trame</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2561SE4Binome2023-82023-12-21T08:37:54Z<p>Ncazin : /* 3) Programmation de la carte électronique RNDIS */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== 1) Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== 2) Ecriture de caractères sur le port série ===<br />
Tout d'abord, avant de commencer la tâche, nous savions que nous devions utiliser l'UART du microcontrolleur. De plus, la tâche suivante devait utiliser aussi l'UART. Puisque 2 tâches utilisent la même ressource, il faut implémenter un système pour savoir quelle tâche utilise la ressource. Nous avons alors utiliser une sémaphore pour chaque tâche, permettant ainsi de limiter l'accès temporairement à la ressources aux autres tâches : <syntaxhighlight lang="c"><br />
void semaphore_write(int action){<br />
if(action == TAKE_RESOURCE){<br />
while(1){<br />
cli();<br />
<br />
/** Ressource Disponible */<br />
if(sem_writing > 0){<br />
sem_writing = 0;<br />
sei();<br />
break;<br />
}<br />
<br />
/** Ressource occupée */<br />
else{<br />
tasks[actuel].reason = WORKING;<br />
tasks[actuel].state = SLEEPING;<br />
TCNT1 = 0;<br />
TIMER1_COMPA_vect();<br />
}<br />
sei();<br />
while(sem_writing == 0);<br />
}<br />
}<br />
if(action == DROP_RESOURCE){<br />
cli();<br />
sem_writing = 1;<br />
sei();<br />
}<br />
}<br />
</syntaxhighlight>Après avoir implémenté cette sémaphore, il fallait que nous comprenions comment utiliser l'UART du microcontrôlleur. Pour cela, il faut initialiser correctement l'UART pour pouvoir écrire et lire en série. La fonction suivante permet d'initialiser correctement l'UART : <syntaxhighlight lang="c"><br />
void init_usart(long int speed){<br />
UBRR0 = FREQUENCE/((unsigned long int)speed << 4) -1;<br />
UCSR0B = (1 << TXEN0 | 1 << RXEN0);<br />
UCSR0C = (1 << UCSZ01 | 1 << UCSZ00);<br />
UCSR0A &= ~(1 << U2X0);<br />
}<br />
</syntaxhighlight>Enfin, une fois l'initialisation réalisée, nous pouvons réaliser la tâche utilisant les fonctions permettant d'écrire plusieurs caractères (ici "abc") sur le port série, que l'on peut observer grâce à la commande shell ''"minicom -D /dev/ttyUSB0 -b 9600".'' On utilise alors les fonctions suivantes pour écrire sur le port série :<syntaxhighlight lang="c"><br />
void serial_send(unsigned char c){<br />
loop_until_bit_is_set(UCSR0A, UDRE0);<br />
UDR0 = c;<br />
}<br />
<br />
<br />
void serial_send_str(char chaine[]){<br />
semaphore_write(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
serial_send(chaine[i]);<br />
}<br />
semaphore_write(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut observer que la tâche fonctionne comme sur la vidéo suivante :[[Fichier:Tâche d'écriture sur le port série.mp4|vignette|Tâche d'écriture sur le port série|centré]]<br />
<br />
=== 3) Lecture sur le port série ===<br />
De la même façon que la tâche précédente, pour cette tâche nous devons lire les pressions de touches du clavier et les afficher sur le minicom. L'initialisation est déjà efféctuée et la sémaphore et la même que dans la partie précédente, nous ne la traiterons donc pas. On utilise alors les fonctions suivantes pour lire les pressions des touches sur le clavier, et la tâche les fait afficher ensuite : <syntaxhighlight lang="c"><br />
unsigned char serial_read(void){<br />
loop_until_bit_is_set(UCSR0A, RXC0);<br />
return UDR0;<br />
}<br />
<br />
<br />
void serial_read_str(char chaine[]){<br />
semaphore_read(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
chaine[i] = serial_read();<br />
}<br />
semaphore_read(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut alors observer les résultats grâce à la vidéo suivante : <br />
[[Fichier:Tâche de lecture sur le port série.mp4|centré|vignette|Tâche de lecture sur le port série]]<br />
<br />
=== 4) Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8 grâce au SPI. Il faut alors réussir à initialiser le SPI correctement :<syntaxhighlight lang="c"><br />
void SPI_MasterInit(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0);<br />
}<br />
</syntaxhighlight>Ensuite, nous avons rédiger un programme utilisé par notre tâche afin d'afficher différents caractères sur la matrice en allumant les LEDs voulues bit par bit :<syntaxhighlight lang="c"><br />
void loop_matrix(char letter[8]){<br />
int temp;<br />
PORTC &= ~(1 << CS);<br />
for(short int i = 0; i < 8; i++){<br />
<br />
for(short int j = 0; j < 8; j++)<br />
{<br />
temp = letter[i] & (1 << j); <br />
diplayLED(temp); //Envoir de chaque bit sur le SPI<br />
}<br />
}<br />
PORTC |= (1 << CS);<br />
}<br />
</syntaxhighlight>Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Nous pouvons alors voir le changement des LEDs allumées lorsque l'on appuie sur un autre caractère grâce à la vidéo suivante :<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage des caractères sur la matrice]]<br />
<br />
=== 5) Afficheur 7 segments ===<br />
Pour le 7 segments, l'initialisation est différente. En effet, le 7 segments ne fonctionne qu'à une fréquence maximale de 250kHz, il faut alors modifier l'initialisation du SPI de la tâche pour le faire fonctionner en changeant le paramètre SPCR :<syntaxhighlight lang="c"><br />
void SPI_MasterInit_segments(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
PORTB |= (1 << SS);<br />
PORTC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << SPR1); //SPR1 & SPR0 à 1 pour une fréquence en dessous de 250kHz (fréquence de l'afficheur 7 segments)<br />
}<br />
</syntaxhighlight>En envoyant alors la lettre appuyée sur le clavier, le 7segments convertit (si c'est posible) la lettre en segments à allumer comme nous pouvons le voir sur la vidéo suivante :[[Fichier:7segments.mp4|centré|vignette|Affichage des caractères sur le 7 segments]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecté des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir réalisé le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux que l'on souhaite envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors routé notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :''<br />
[[Fichier:Carte reconnue après un "lsusb".png|alt=Carte reconnue après un "lsusb"|centré|vignette|Carte reconnue après un "lsusb"]]<br />
Après cela, nous allons entamé la programmation pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utilisé une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créé mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. <br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping de l'adresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et vérifiés leur bonne réception sur le terminal. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette]] <br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Carte_reconnue_apr%C3%A8s_un_%22lsusb%22.png&diff=2560Fichier:Carte reconnue après un "lsusb".png2023-12-21T08:37:15Z<p>Ncazin : </p>
<hr />
<div>Carte reconnue après un "lsusb"</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2530SE4Binome2023-82023-12-20T12:08:36Z<p>Ncazin : /* 2) Lecture de caractères sur le port série */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== 1) Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== 2) Ecriture de caractères sur le port série ===<br />
Tout d'abord, avant de commencer la tâche, nous savions que nous devions utiliser l'UART du microcontrolleur. De plus, la tâche d'après devait utiliser aussi l'UART. Puisque 2 tâches utilisent la même ressource, il faut implémenter un système pour savoir quelle tâche utilise la ressource. Nous avons alors utiliser une sémaphore pour chaque tâche, permettant ainsi de limiter l'accès temporairement à la ressources aux autres tâches : <syntaxhighlight lang="c"><br />
void semaphore_write(int action){<br />
if(action == TAKE_RESOURCE){<br />
while(1){<br />
cli();<br />
<br />
/** Ressource Disponible */<br />
if(sem_writing > 0){<br />
sem_writing = 0;<br />
sei();<br />
break;<br />
}<br />
<br />
/** Ressource occupée */<br />
else{<br />
tasks[actuel].reason = WORKING;<br />
tasks[actuel].state = SLEEPING;<br />
TCNT1 = 0;<br />
TIMER1_COMPA_vect();<br />
}<br />
sei();<br />
while(sem_writing == 0);<br />
}<br />
}<br />
if(action == DROP_RESOURCE){<br />
cli();<br />
sem_writing = 1;<br />
sei();<br />
}<br />
}<br />
</syntaxhighlight>Après avoir implémenté cette sémaphore, il nous fallait comprendre comment utiliser l'UART du microcontrôlleur. Pour cela, il faut initialiser coorectement l'UART pour pouvoir écrire et lire en série. La fonction suivante permet d'initialiser correctement l'UART : <syntaxhighlight lang="c"><br />
void init_usart(long int speed){<br />
UBRR0 = FREQUENCE/((unsigned long int)speed << 4) -1;<br />
UCSR0B = (1 << TXEN0 | 1 << RXEN0);<br />
UCSR0C = (1 << UCSZ01 | 1 << UCSZ00);<br />
UCSR0A &= ~(1 << U2X0);<br />
}<br />
</syntaxhighlight>Enfin, après l'initialisation, nous pouvons réaliser la tâche utilisant les fonctions permettant d'écrire plusieurs caractères (ici "abc") sur le port série, que l'on peut observer grâce à la commande shell ''"minicom -D /dev/ttyUSB0 -b 9600".'' On utilise alors les fonctions suivantes pour écrire sur le port série :<syntaxhighlight lang="c"><br />
void serial_send(unsigned char c){<br />
loop_until_bit_is_set(UCSR0A, UDRE0);<br />
UDR0 = c;<br />
}<br />
<br />
<br />
void serial_send_str(char chaine[]){<br />
semaphore_write(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
serial_send(chaine[i]);<br />
}<br />
semaphore_write(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut observer que la tâche fonctionne comme sur la vidéo suivante :[[Fichier:Tâche d'écriture sur le port série.mp4|vignette|On Tâche d'écriture sur le port série|centré]]<br />
<br />
=== 3) Lecture sur le port série ===<br />
De la même façon que la tâche précédente, pour cette tâche nous devons lire les pressions de touches du clavier et les afficher sur le minicom. L'initialisation est déjà efféctuée et la sémaphore et la même que dans la partie précédente, nous ne la traiterons donc pas. On utilise alors les fonctions suivantes pour lire les pressions des touches du clavier, et la tâche les fait afficher ensuite : <syntaxhighlight lang="c"><br />
unsigned char serial_read(void){<br />
loop_until_bit_is_set(UCSR0A, RXC0);<br />
return UDR0;<br />
}<br />
<br />
<br />
void serial_read_str(char chaine[]){<br />
semaphore_read(TAKE_RESOURCE);<br />
for(int i = 0; i < SIZE_CHAINE; i++){<br />
chaine[i] = serial_read();<br />
}<br />
semaphore_read(DROP_RESOURCE); <br />
}<br />
</syntaxhighlight>On peut alors observer les résultat grâce à la vidéo suivante : <br />
[[Fichier:Tâche de lecture sur le port série.mp4|centré|vignette|Tâche de lecture sur le port série]]<br />
<br />
=== 4) Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8 grâce au SPI. Il faut alors réussir à initialiser le SPI correctement :<syntaxhighlight lang="c"><br />
void SPI_MasterInit(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0);<br />
}<br />
</syntaxhighlight>Ensuite, nous avons rédiger un programme utilisé par notre tâche afin d'afficher différents caractères sur la matrice en allumant les LEDs voulues bit par bit :<syntaxhighlight lang="c"><br />
void loop_matrix(char letter[8]){<br />
int temp;<br />
PORTC &= ~(1 << CS);<br />
for(short int i = 0; i < 8; i++){<br />
<br />
for(short int j = 0; j < 8; j++)<br />
{<br />
temp = letter[i] & (1 << j); <br />
diplayLED(temp); //Envoir de chaque bit sur le SPI<br />
}<br />
}<br />
PORTC |= (1 << CS);<br />
}<br />
</syntaxhighlight>Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Nous pouvons alors voir le changment des LEDs allumées lorsque l'on appuie sur un autre caractère grâce à la vidéo suivante :<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage de caractères sur la matrice]]<br />
<br />
=== 5) Afficheur 7 segments ===<br />
Pour le 7 segments, l'initialisation est différente. En effet, le 7 segments ne fonctionne qu'à une fréquence maximale de 250kHz, il faut alors modifier l'initialisation du SPI de la tâche pour le faire fonctionner en changeant le paramètre SPCR :<syntaxhighlight lang="c"><br />
void SPI_MasterInit_segments(void){<br />
DDRB |= (1 << MOSI) | (1 << SCK) | (1 << SS);<br />
DDRC |= (1 << CS);<br />
PORTB |= (1 << SS);<br />
PORTC |= (1 << CS);<br />
SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << SPR1); //SPR1 & SPR0 à 1 pour une fréquence en dessous de 250kHz (fréquence de l'afficheur 7 segments)<br />
}<br />
</syntaxhighlight>En envoyant alors la lettre appuyée sur le clavier, le 7segments convertit (si c'est posible) la lettre en segments à allumer comme nous pouvons le voir sur la vidéo suivante :[[Fichier:7segments.mp4|centré|vignette|Affichage des caractères sur le 7 segments]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte été pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecter des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir fais le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux qu' l'on va envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors router notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :'' <br />
[[Fichier:Carte reconnue par le "lsusb".png|alt=Carte reconnue par le "lsusb"|centré|vignette|Carte reconnue par le "lsusb"]]<br />
Après cela, nous allons commencer à programmer le programme pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utiliser une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créer mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. Enfn nous avond dû changer les VendorID et les productID dans certains fichiers :<br />
<br />
* VendorID = 0x03EB<br />
* ProductID = 0x2FEF<br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping l'addresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et leur bonne réception sur le terminal. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette]] <br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:T%C3%A2che_de_lecture_sur_le_port_s%C3%A9rie.mp4&diff=2529Fichier:Tâche de lecture sur le port série.mp42023-12-20T11:58:45Z<p>Ncazin : </p>
<hr />
<div>Tâche de lecture sur le port série</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2528SE4Binome2023-82023-12-20T11:47:07Z<p>Ncazin : /* 1) Clignotement de 2 LEDs */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== 1) Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== 2) Lecture de caractères sur le port série ===<br />
Tout d'abord, avant de commencer la tâche, nous savions que nous devions utiliser l'UART du microcontrolleur. De plus, la tâche d'après devait utiliser aussi l'UART. Puisque 2 tâches utilisent la même ressource, il faut implémenter un système pour savoir quelle tâche utilise la ressource. Nous avons alors utiliser une sémaphore pour chaque tâche, permettant ainsi de limiter l'accès temporairement à la ressources aux autres tâches : <syntaxhighlight lang="c"><br />
void semaphore_write(int action){<br />
if(action == TAKE_RESOURCE){<br />
while(1){<br />
cli();<br />
<br />
/** Ressource Disponible */<br />
if(sem_writing > 0){<br />
sem_writing = 0;<br />
sei();<br />
break;<br />
}<br />
<br />
/** Ressource occupée */<br />
else{<br />
tasks[actuel].reason = WORKING;<br />
tasks[actuel].state = SLEEPING;<br />
TCNT1 = 0;<br />
TIMER1_COMPA_vect();<br />
}<br />
sei();<br />
while(sem_writing == 0);<br />
}<br />
}<br />
if(action == DROP_RESOURCE){<br />
cli();<br />
sem_writing = 1;<br />
sei();<br />
}<br />
}<br />
</syntaxhighlight>Après avoir implémenté cette sémaphore, il nous fallait comprendre comment utiliser l'UART du microcontrôlleur. Pour cela, il faut initialiser coorectement l'UART pour pouvoir écrire et lire en série. La fonction suivante permet d'initialiser correctement l'UART : <syntaxhighlight lang="c"><br />
void init_usart(long int speed){<br />
UBRR0 = FREQUENCE/((unsigned long int)speed << 4) -1;<br />
UCSR0B = (1 << TXEN0 | 1 << RXEN0);<br />
UCSR0C = (1 << UCSZ01 | 1 << UCSZ00);<br />
UCSR0A &= ~(1 << U2X0);<br />
}<br />
</syntaxhighlight>Enfin, après l'initialisation, nous pouvons réaliser la tâche utilisant les fonctions permettant d'écrire plusieurs caractères (ici "abc") sur le port série, que l'on peut observer grâce à la commande shell ''"minicom -D /dev/ttyUSB0 -b 9600".'' On voit alors les caractères comme sur la vidéo :<br />
[[Fichier:Tâche d'écriture sur le port série.mp4|vignette|Tâche d'écriture sur le port série]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
=== 3) Ecriture sur le port série ===<br />
<br />
=== 4) Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8.<br />
<br />
Dans un premier temps, nous avons rédiger un programme à part de notre ordonnanceur afin d'afficher différents caractères sur la matrice.<br />
<br />
Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Enfin, dans cette fonction, nous y avons ajouté le fait de pouvoir lire au clavier n'importe quel caractère sur la matrice.<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage de caractères sur la matrice]]<br />
<br />
=== 5) Afficheur 7 segments ===<br />
Pour le 7 segments nous avons fait de la même manière que pour la matrice.<br />
<br />
Si nous appuyons sur un caractère du clavier, il s'affiche sur les quatre 7 segments de l'afficheur.<br />
[[Fichier:7segments.mp4|centré|vignette|Affichage des caractères sur le 7 segments]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte été pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecter des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir fais le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux qu' l'on va envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors router notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :'' <br />
[[Fichier:Carte reconnue par le "lsusb".png|alt=Carte reconnue par le "lsusb"|centré|vignette|Carte reconnue par le "lsusb"]]<br />
Après cela, nous allons commencer à programmer le programme pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utiliser une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créer mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. Enfn nous avond dû changer les VendorID et les productID dans certains fichiers :<br />
<br />
* VendorID = 0x03EB<br />
* ProductID = 0x2FEF<br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping l'addresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et leur bonne réception sur le terminal. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette]] <br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:T%C3%A2che_d%27%C3%A9criture_sur_le_port_s%C3%A9rie.mp4&diff=2527Fichier:Tâche d'écriture sur le port série.mp42023-12-20T11:46:32Z<p>Ncazin : </p>
<hr />
<div>Tâche d'écriture sur le port série</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2492SE4Binome2023-82023-12-14T10:17:19Z<p>Ncazin : /* 3) Ecriture sur le port série */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== 1) Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== 2) Lecture de caractères sur le port série ===<br />
<br />
=== 3) Ecriture sur le port série ===<br />
<br />
=== 4) Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8.<br />
<br />
Dans un premier temps, nous avons rédiger un programme à part de notre ordonnanceur afin d'afficher différents caractères sur la matrice.<br />
<br />
Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Enfin, dans cette fonction, nous y avons ajouté le fait de pouvoir lire au clavier n'importe quel caractère sur la matrice.<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage de caractères sur la matrice]]<br />
<br />
=== 5) Afficheur 7 segments ===<br />
Pour le 7 segments nous avons fait de la même manière que pour la matrice.<br />
<br />
Si nous appuyons sur un caractère du clavier, il s'affiche sur les quatre 7 segments de l'afficheur.<br />
[[Fichier:7segments.mp4|centré|vignette|Affichage des caractères sur le 7 segments]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte été pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecter des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir fais le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux qu' l'on va envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors router notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :'' <br />
[[Fichier:Carte reconnue par le "lsusb".png|alt=Carte reconnue par le "lsusb"|centré|vignette|Carte reconnue par le "lsusb"]]<br />
Après cela, nous allons commencer à programmer le programme pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utiliser une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créer mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. Enfn nous avond dû changer les VendorID et les productID dans certains fichiers :<br />
<br />
* VendorID = 0x03EB<br />
* ProductID = 0x2FEF<br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping l'addresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et leur bonne réception sur le terminal. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette]] <br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2491SE4Binome2023-82023-12-14T10:14:26Z<p>Ncazin : /* 5) Afficheur 7 segments */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== 1) Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== 2) Lecture de caractères par le port série ===<br />
<br />
=== 3) Ecriture sur le port série ===<br />
<br />
=== 4) Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8.<br />
<br />
Dans un premier temps, nous avons rédiger un programme à part de notre ordonnanceur afin d'afficher différents caractères sur la matrice.<br />
<br />
Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Enfin, dans cette fonction, nous y avons ajouté le fait de pouvoir lire au clavier n'importe quel caractère sur la matrice.<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage de caractères sur la matrice]]<br />
<br />
=== 5) Afficheur 7 segments ===<br />
Pour le 7 segments nous avons fait de la même manière que pour la matrice.<br />
<br />
Si nous appuyons sur un caractère du clavier, il s'affiche sur les quatre 7 segments de l'afficheur.<br />
[[Fichier:7segments.mp4|centré|vignette|Affichage des caractères sur le 7 segments]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte été pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecter des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir fais le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux qu' l'on va envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors router notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :'' <br />
[[Fichier:Carte reconnue par le "lsusb".png|alt=Carte reconnue par le "lsusb"|centré|vignette|Carte reconnue par le "lsusb"]]<br />
Après cela, nous allons commencer à programmer le programme pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utiliser une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créer mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. Enfn nous avond dû changer les VendorID et les productID dans certains fichiers :<br />
<br />
* VendorID = 0x03EB<br />
* ProductID = 0x2FEF<br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping l'addresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et leur bonne réception sur le terminal. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette]] <br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2490SE4Binome2023-82023-12-14T10:13:59Z<p>Ncazin : /* 4) Matrice de LEDs */</p>
<hr />
<div>== Matériel : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Ordonnanceur ==<br />
<br />
=== 1) Clignotement de 2 LEDs ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs, à l'aide de deux tâches statiques, avec des périodes différentes. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et de restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
=== 2) Lecture de caractères par le port série ===<br />
<br />
=== 3) Ecriture sur le port série ===<br />
<br />
=== 4) Matrice de LEDs ===<br />
Dans cette partie, nous souhaitons gérer l'affichage d'une matrice de LEDs 8x8.<br />
<br />
Dans un premier temps, nous avons rédiger un programme à part de notre ordonnanceur afin d'afficher différents caractères sur la matrice.<br />
<br />
Après vérification du bon fonctionnement de notre programme, nous avons ajouté la fonction principale dans notre fichier de gestion des tâches. Enfin, dans cette fonction, nous y avons ajouté le fait de pouvoir lire au clavier n'importe quel caractère sur la matrice.<br />
[[Fichier:Matrice2.mov|centré|vignette|Affichage de caractères sur la matrice]]<br />
<br />
=== 5) Afficheur 7 segments ===<br />
Pour le 7 segments nous avons fait de la même manière que pour la matrice.<br />
<br />
Si nous appuyons sur un caractère du clavier, il s'affiche sur les quatre 7 segments de l'afficheur.<br />
[[Fichier:7segments.mp4|centré|vignette]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte été pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecter des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir fais le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux qu' l'on va envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|245x245px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors router notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :'' <br />
[[Fichier:Carte reconnue par le "lsusb".png|alt=Carte reconnue par le "lsusb"|centré|vignette|Carte reconnue par le "lsusb"]]<br />
Après cela, nous allons commencer à programmer le programme pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utiliser une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créer mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. Enfn nous avond dû changer les VendorID et les productID dans certains fichiers :<br />
<br />
* VendorID = 0x03EB<br />
* ProductID = 0x2FEF<br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping l'addresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut maintenant recevoir les paquets envoyés et leur bonne réception sur le terminal. Pour rendre compte des paquets envoyés/reçus, nous allumons une LED à chaque ping : <br />
[[Fichier:Reception .mp4|centré|vignette]] <br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2449SE4Binome2023-82023-12-11T14:49:21Z<p>Ncazin : /* Carte fille réseau RNDIS : */</p>
<hr />
<div>== Ordonnanceur/SE : ==<br />
<br />
=== 1) Matériel ===<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
=== 2) Ordonnanceur ===<br />
Nous avons commencé l'ordonnanceur avec l'objectif de faire clignoter dans un premier temps 2 LEDs. <br />
<br />
Pour cela, nous avons utilisé un ISR permettant de gérer plusieurs tâches en même temps. Avant cela, il y a des fonctions de gestion et restitution des registres afin que l'ISR commence le programme avec tous les registres à 0. Nous avons utilisé le lien suivant pour nous aider : https://tvantroys.plil.fr/IMA4/system/Multitasking%20on%20an%20AVR.pdf. Ensuite, nous avons implémenté un "scheduler" avec tout d'abord une première version où nous utilisions des "_delay_ms_". Par la suite, une mise à jour de ce "scheduler" s'imposait afin de supprimer les _delay_ms_ pour que chaque tâche possède son propre délai.<syntaxhighlight lang="c"><br />
void scheduler(void){<br />
for(int i = 0; i < MAX_TASKS; i++){<br />
if(tasks[i].state == SLEEPING && tasks[i].reason == DELAY){<br />
uint16_t time = 20;<br />
if(TCNT1 != 0){<br />
time = TCNT1 * 200 / OCR1A / 10;<br />
TCNT1 = 0;<br />
}<br />
tasks[i].duration = tasks[i].duration - time;<br />
if(tasks[i].duration <= 0) { tasks[i].state = WORKING; }<br />
}<br />
}<br />
<br />
do{<br />
actuel++;<br />
if(actuel == MAX_TASKS) { actuel = 0; }<br />
} while(tasks[actuel].state == SLEEPING);<br />
}<br />
<br />
<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED){<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
portSAVE_CONTEXT();<br />
tasks[actuel].StackPointeur = SP;<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
SP = tasks[actuel].StackPointeur;<br />
portRESTORE_CONTEXT();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
Au final, nous arrivons à faire clignoter 2 LEDs avec deux périodes différentes : <br />
[[Fichier:Clignotement des LEDs grâce à l'ordonnanceur.mov|alt=Clignotement des LEDs grâce à l'ordonnanceur|vignette|Clignotement des LEDs grâce à l'ordonnanceur|centré]]<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte été pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecter des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir fais le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux qu' l'on va envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|239x239px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors router notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :'' <br />
[[Fichier:Carte reconnue par le "lsusb".png|alt=Carte reconnue par le "lsusb"|centré|vignette|Carte reconnue par le "lsusb"]]<br />
Après cela, nous allons commencer à programmer le programme pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utiliser une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créer mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. Enfn nous avond dû changer les VendorID et les productID dans certains fichiers :<br />
<br />
* VendorID = 0x03EB<br />
* ProductID = 0x2FEF<br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.100/24 dev usb0" qui lui ajoute l'adresse 10.0.0.100 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping l'addresse 10.0.0.2 pour voir si elle répond bien : <br />
[[Fichier:Ping usb0 2.png|alt=Ping vers la carte RNDIS|centré|vignette|Ping vers la carte RNDIS]]<br />
Il faut alors maintenant faire <br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Ping_usb0_2.png&diff=2448Fichier:Ping usb0 2.png2023-12-11T14:46:06Z<p>Ncazin : </p>
<hr />
<div>Ping vers la carte RNDIS</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2125SE4Binome2023-82023-11-20T11:03:59Z<p>Ncazin : /* 3) Programmation de la carte électronique RNDIS */</p>
<hr />
<div>== Ordonnanceur/SE : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte été pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecter des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir fais le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux qu' l'on va envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|239x239px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors router notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|<br />
<br />
* Carte soudée<br />
<br />
]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :'' <br />
[[Fichier:Carte reconnue par le "lsusb".png|alt=Carte reconnue par le "lsusb"|centré|vignette|Carte reconnue par le "lsusb"]]<br />
Après cela, nous allons commencer à programmer le programme pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
Pour la programmation de la carte électronique RNDIS, nous avons utiliser une démonstration LUFA déjà existante qui implémente une pile TCP/IP. En faisant directement un "make", nous avons remarqué que l'espace mémoire était dépassée. En effet, notre microcontrôleur ATMega16u2 n'a que 2k de mémoire.<br />
<br />
Pour réduire la taille du programme, nous avons déjà réduit la taille de la trame Ethernet qui est de 1500 octets à 100 octets. Ensuite nous avons réduit la pile TCP/IP en supprimant les fichiers UDP, TCP et Webserveur qui ne nous étaient pas utiles dans le fonctionnement de notre carte. Après la commande "make", un fichier hex est bien créer mais nous avons dû changer ce fichier Makefile en conséquence pour l'adapter à notre microcontrôleur. Enfn nous avond dû changer les VendorID et les productID dans certains fichiers :<br />
<br />
* VendorID = 0x03EB<br />
* ProductID = 0x2FEF<br />
<br />
Après un upload du programme sur notre carte, nous avons réussi à obtenir une nouvelle interface réseau nommée "usb0" que l'on a pu visualiser grâce à la commande "ip a".<br />
[[Fichier:Interface usb0 créée.png|alt=Interface usb0 créée|centré|vignette|397x397px|Interface usb0 créée]]<br />
Par le suite, nous avons configuré cette nouvelle interface avec la commande "ip address add 10.0.0.2/24 dev usb0" qui lui ajoute l'adresse 10.0.0.2 et un masque de classe C qui convient à nos besoins. A présent, nous pouvons faire un ping sur notre carte pour voir si elle répond bien. <br />
[[Fichier:Ping de la carte électronique RNDIS.png|alt=Ping de la carte électronique RNDIS|centré|vignette|350x350px|Ping de la carte électronique RNDIS]]<br />
Il faut alors maintenant faire <br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Ping_de_la_carte_%C3%A9lectronique_RNDIS.png&diff=2120Fichier:Ping de la carte électronique RNDIS.png2023-11-20T10:57:13Z<p>Ncazin : </p>
<hr />
<div>Ping de la carte électronique RNDIS</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Interface_usb0_cr%C3%A9%C3%A9e.png&diff=2118Fichier:Interface usb0 créée.png2023-11-20T10:53:46Z<p>Ncazin : </p>
<hr />
<div>Interface usb0 créée</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2051SE4Binome2023-82023-11-14T14:36:43Z<p>Ncazin : /* 2) Soudure de la carte électronique RNDIS */</p>
<hr />
<div>== Ordonnanceur/SE : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte été pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecter des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir fais le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux qu' l'on va envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|239x239px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors router notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
Durant deux séances, nous avons réalisé la soudure de la carte électronique sur laquelle nous avons été aidés pour souder le quartz ainsi que le port USB. A noter que sur la carte, deux diodes ont été enlevées au niveau de l'USB car il était impossible de la reconnaître par notre machine grâce à la commande ''"lsusb".'' Hormis les diodes à enlever, aucune difficulté n'a été relevée durant la soudure de la carte.<br />
<br />
Au final, nous avons donc une carte électronique fonctionnelle et prête à être programmée.<br />
<br />
Voici une photo de la carte soudée : <br />
[[Fichier:Carte soudée.jpg|alt=Carte soudée|centré|vignette|237x237px|Carte soudée]]<br />
Au final, la carte est bien reconnue grâce à la commande ''"lsusb" :'' <br />
[[Fichier:Carte reconnue par le "lsusb".png|alt=Carte reconnue par le "lsusb"|centré|vignette|Carte reconnue par le "lsusb"]]<br />
Après cela, nous allons commencer à programmer le programme pour avoir une communication RNDIS.<br />
<br />
=== '''3) Programmation de la carte électronique RNDIS''' ===<br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Carte_reconnue_par_le_%22lsusb%22.png&diff=2050Fichier:Carte reconnue par le "lsusb".png2023-11-14T14:33:46Z<p>Ncazin : </p>
<hr />
<div>Carte reconnue par le "lsusb"</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Carte_soud%C3%A9e.jpg&diff=2049Fichier:Carte soudée.jpg2023-11-14T14:30:30Z<p>Ncazin : </p>
<hr />
<div>Carte soudée</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=2011SE4Binome2023-82023-11-06T11:16:23Z<p>Ncazin : /* Ordonnanceur/SE : */</p>
<hr />
<div>== Ordonnanceur/SE : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder 2 connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte été pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecter des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir fais le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux qu' l'on va envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|239x239px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors router notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=1831SE4Binome2023-82023-10-22T09:58:27Z<p>Ncazin : /* Carte fille réseau RNDIS : */</p>
<hr />
<div>== Ordonnanceur/SE : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder des connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
=== 1) Création de la carte électronique RNDIS ===<br />
Nous avons choisi de réaliser la carte réseau RNDIS car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte été pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur a utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un ATMega16u2 car nous en avions déjà utiliser un lors de notre projet en SE3 et nous étions plus à l'aise avec.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôlleur. Nous avons choisi d'utiliser les ports suivants :<br />
<br />
* SCK ==> PB1<br />
* MOSI ==> PB2<br />
* MISO ==> PB3<br />
* CS ==> PB4<br />
<br />
De cette façon, nous pouvons récupérer et envoyer simplement des informations depuis la carte mère. Nous avons aussi connecter des LEDs sur les ports PC4 à PC7. Les autres ports sont connectés à des testpoints. La communication RNDIS se faisant via le port USB, nous avons aussi implémenter un port USB communicant via D+ et D-. Par sécurité, nous avons aussi mis un AVR-ISP dans le cas où la programmation du microcontrôleur se fasse pas correctement. Voici alors le schéma électrique de notre carte RNDIS :<br />
[[Fichier:Schéma électrique de la carte RNDIS.jpg|alt=Schéma électrique de la carte RNDIS|centré|vignette|234x234px|Schéma électrique de la carte RNDIS]]<br />
Après avoir fais le schéma électrique, nous avons fait le routage de la carte. Le routage était simple, nous avons commencé par router les parties USB et microcontôleur car nous savons comment elles doivent êtres disposées. Le plus difficile dans ce routage a été de mettre le capacités les plus proches du quartz et du microcontôleur car nous avons essayé de faire une carte compacte, et les testpoints prennent beaucoup de place sur la carte. Il fallait donc être précis sur la disposition des composants. Il fallait aussi faire attention à ce que les pistes D+ et D- soient les plus courtes et avec le moins de via possibles pour ne pas endommager les signaux qu' l'on va envoyer. Nous avons fait le plan de masse de la carte et au final nous avons réussi à compacter la carte pour qu'elle fasse une taille de 33mm x 43mm. Voici alors le routage de notre carte RNDIS.<br />
[[Fichier:Routage de la carte RNDIS.jpg|alt=Routage de la carte RNDIS|centré|vignette|239x239px|Routage de la carte RNDIS]]<br />
Voici donc une réprésentation 3D de notre carte RNDIS :<br />
[[Fichier:Représentation 3D de notre carte RNDIS.jpg|alt=Représentation 3D de notre carte RNDIS|centré|vignette|Représentation 3D de notre carte RNDIS]]<br />
Nous avons alors router notre carte, il fallait donc faire un fichier ZIP à partir de ces fichiers afin que la carte puisse être envoyée en production pour que l'on puisse souder les composants par la suite. Nous avons donc suivi les étapes de ce tutoriel : ''https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6''. <br />
<br />
=== 2) Soudure de la carte électronique RNDIS ===<br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Repr%C3%A9sentation_3D_de_notre_carte_RNDIS.jpg&diff=1830Fichier:Représentation 3D de notre carte RNDIS.jpg2023-10-22T09:51:42Z<p>Ncazin : </p>
<hr />
<div>Représentation 3D de notre carte RNDIS</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Routage_de_la_carte_RNDIS.jpg&diff=1829Fichier:Routage de la carte RNDIS.jpg2023-10-22T09:49:14Z<p>Ncazin : </p>
<hr />
<div>Routage de la carte RNDIS</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Sch%C3%A9ma_%C3%A9lectrique_de_la_carte_RNDIS.jpg&diff=1828Fichier:Schéma électrique de la carte RNDIS.jpg2023-10-22T09:41:18Z<p>Ncazin : </p>
<hr />
<div>Schéma électrique de la carte RNDIS</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Sch%C3%A9ma_elec_carte_RNDIS.jpg&diff=1827Fichier:Schéma elec carte RNDIS.jpg2023-10-22T09:39:44Z<p>Ncazin : </p>
<hr />
<div>Schéma électrique de la carte RNDIS</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=1796SE4Binome2023-82023-10-13T06:47:22Z<p>Ncazin : /* Ordonnanceur/SE : */</p>
<hr />
<div>== Ordonnanceur/SE : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder des connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery>https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6 --> générer le fichier zip<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=1572SE4Binome2023-82023-09-19T12:22:00Z<p>Ncazin : </p>
<hr />
<div>== Ordonnanceur/SE : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder des connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <gallery><br />
Fichier:Carte soudee.jpg<br />
Fichier:Connecteur soudee.jpg|Carte et connecteurs soudés<br />
</gallery><br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=1571SE4Binome2023-82023-09-19T12:21:25Z<p>Ncazin : </p>
<hr />
<div>== Ordonnanceur/SE : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quel sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. Nous avons réalisé au total 3 câbles, donc un de plus que le nombre de base au cas où un des câbles ne fonctionne pas. Voici une photo des trois câbles :<br />
<br />
<gallery><br />
Fichier:Trois cables.jpg<br />
Fichier:Câbles de côté.jpg|Photos des trois câbles<br />
</gallery>Par la suite, nous avons dû souder une carte Shield pouvant être ajoutée à un Arduino Uno. Cette carte Shield était déjà partiellement soudée. De plus nous avons dû souder des connecteurs permettant la jonction avec les cartes . Voici une photo de la carte soudée : <br />
[[Fichier:Connecteur soudee.jpg|alt=Connecteurs soudés|vignette|177x177px|Connecteurs soudés]]<br />
[[Fichier:Carte soudee.jpg|alt=Carte soudee|centré|vignette|Carte soudee]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
ReX : utilisez le squelette présenté en séance.<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
== Rendus : ==<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git <br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Connecteur_soudee.jpg&diff=1570Fichier:Connecteur soudee.jpg2023-09-19T12:19:44Z<p>Ncazin : </p>
<hr />
<div>Connecteur soudee</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Carte_soudee.jpg&diff=1569Fichier:Carte soudee.jpg2023-09-19T12:15:36Z<p>Ncazin : </p>
<hr />
<div>Carte soudee</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:C%C3%A2bles_de_c%C3%B4t%C3%A9.jpg&diff=1568Fichier:Câbles de côté.jpg2023-09-19T12:08:56Z<p>Ncazin : </p>
<hr />
<div>Câbles de côté</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Trois_cables.jpg&diff=1567Fichier:Trois cables.jpg2023-09-19T12:05:59Z<p>Ncazin : </p>
<hr />
<div>Trois cables</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=1450SE4Binome2023-82023-09-13T15:54:17Z<p>Ncazin : /* Ordonnanceur/SE : */</p>
<hr />
<div>CAZIN Némo & CEGARRA Antoine<br />
<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git<br />
<br />
== Ordonnanceur/SE : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quelle sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance. ### PHOTOS CABLE ###<br />
<br />
<nowiki>###</nowiki> METTRE PARTIE SOUDURE ANTOINE ###<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=1449SE4Binome2023-82023-09-13T15:53:01Z<p>Ncazin : </p>
<hr />
<div>CAZIN Némo & CEGARRA Antoine<br />
<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git<br />
<br />
== Ordonnanceur/SE : ==<br />
Préparation de la carte Shield :<br />
<br />
Pour la première séance de TP, nous avons dû souder des composants sur la carte Shield fournie. Nous nous sommes alors séparés, un qui faisait la soudure, et un autre préparant les câble reliant la carte Shield aux cartes filles.<br />
<br />
Pour les câbles, nous avons comparé notre travail avec le câble de l'enseignant. Le plus dur était de savoir dans quelle sens mettre les fiches HE10 femelle, un renfoncement permet heureusement de savoir le sens dans lequel insérer le câble. Après cela, le câble est un peu fragile si on tire dessus, nous avons donc replier le câble et mis un bloqueur pour augmenter sa résistance.<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=1432SE4Binome2023-82023-09-12T13:13:39Z<p>Ncazin : </p>
<hr />
<div>CAZIN Némo & CEGARRA Antoine<br />
<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git<br />
<br />
== Ordonnanceur/SE : ==<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
== Carte fille réseau RNDIS : ==<br />
<br />
== Note ==<br />
flatpak run org.kicad.KiCad//stable --> Lance Kicad 7</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2023-8&diff=1429SE4Binome2023-82023-09-12T13:03:24Z<p>Ncazin : Rubrique</p>
<hr />
<div>CAZIN Némo & CEGARRA Antoine<br />
<br />
Lien de notre GIT : https://archives.plil.fr/ncazin/Projet_Pico_SE4.git<br />
<br />
== Ordonnanceur/SE : ==<br />
<br />
== Carte FPGA/VHDL : ==<br />
<br />
== Carte électronique numérique : ==<br />
<br />
== Carte fille réseau RNDIS : ==</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Pico_SE4_2023/2024&diff=1427Pico SE4 2023/20242023-09-12T12:54:55Z<p>Ncazin : /* Réalisations des élèves */</p>
<hr />
<div>= Objectif =<br />
<br />
Pour l'année académique 2023/2024 nous vous demandons de construire un pico-ordinateur comprenant les éléments suivants :<br />
* un processeur de type microcontrôleur ;<br />
* un clavier ;<br />
* un dispositif d'affichage ;<br />
* un système d'exploitation stocké dans la mémoire flash du microcontrôleur ;<br />
* une mémoire de masse allant au delà de la mémoire flash sus-citée ;<br />
* un dispositif de communication avec l'extérieur.<br />
<br />
Pour faire en sorte que tous les éléments puissent communiquer entre eux nous vous demandons d'utiliser un bus série.<br />
<br />
= Compétences évaluées =<br />
<br />
Les compétences suivantes doivent être acquises durant ce module.<br />
* Savoir comprendre, ou à défaut être actif en séances pour poser les questions pertinentes aux encadrants.<br />
* Savoir produire un travail régulier et documenté durant la totalité de la période.<br />
* Savoir concevoir et réaliser des cartes électroniques fonctionnelles.<br />
* Savoir concevoir et programmer un circuit FPGA en VHDL.<br />
* Savoir structurer et écrire des pilotes pour cartes électroniques.<br />
* Savoir concevoir et implanter des primitives systèmes et un micro-système d'exploitation.<br />
<br />
= Organisation du travail =<br />
<br />
Vous aurez, comme d'habitude, la lourde tâche de tester ce module de travaux pratiques.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Matériel fourni ==<br />
<br />
<br />
[[file:2023_Bouclier_Pico.pdf||thumb|right|400px]]<br />
<br />
Pour que chaque binôme puisse avoir un minimum d'autonomie, un matériel de base est fourni :<br />
* un Arduino Uno pour prototyper le coeur d'une carte mère ;<br />
* 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 ;<br />
* 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.<br />
<br />
Le projet KiCAD pour le bouclier Arduino est disponible : [[Média:2023_Bouclier_Pico.zip]]<br />
<br />
Les projets KiCAD pour connecter les périphériques via un connecteur sont disponibles : [[Média:2023_HE10-periph.zip]]<br />
<br />
<p style="clear: both;" /><br />
<br />
[[file:2023_Bouclier_Pico_PCB.png||thumb|center|300px]]<br />
<br />
Vision de la carte partiellement montée. L'accès à la carte SD est fonctionnel.<br />
<br />
[[file:2023_Bouclier_Pico_Test.jpg||thumb|center|300px]]<br />
<br />
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]].<br />
<br />
== Réalisations par binôme ==<br />
<br />
Chaque binôme réalise :<br />
* un système d'exploitation basé sur un ordonnanceur ;<br />
* 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 ;<br />
* 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.<br />
<br />
== Réalisation par groupe de binômes ==<br />
<br />
Par groupe de 4 binômes vous devez réaliser un pico-ordinateur complet :<br />
* une carte mère ;<br />
* une carte fille FPGA/VHDL fonctionnelle et supportée par votre carte mère ;<br />
* au moins 3 cartes filles fonctionnelles et supportées par votre carte mère (clavier, écran, réseau) ;<br />
* vous pouvez ajouter une cinquième carte fille optionnelle de type carte son.<br />
<br />
= Cahier des charges =<br />
<br />
== Ordonnanceur ==<br />
<br />
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.<br />
<br />
Le principe est d'utiliser un minuteur du microcontrôleur pour lancer périodiquement une fonction d'interruption que vous allez transformer en ordonnanceur.<br />
<br />
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.<br />
<br />
Par la suite vous allez complexifier votre ordonnanceur en ajoutant :<br />
* une tâche de lecture de caractère par le port série (stocké en mémoire partagé) ;<br />
* une tâche d'écriture sur le port série (du caractère lu sur le port série) ;<br />
* une tâche d'écriture sur la matrice (du caractère lu sur le port série) ;<br />
* une tâche d'écriture sur l'afficheur 7 segments (du caractère lu sur le port série).<br />
<br />
Les deux dernières tâches sont plus compliquées à réaliser dans la mesure où elles utilisent une ressource commune.<br />
<br />
== Cartes filles FPGA ==<br />
<br />
Les cartes filles FPGA doivent être programmées en VHDL. Tous les binômes doivent implanter en VHDL :<br />
* un contrôleur de bus série SPI ;<br />
* un décodeur des commandes reçues par SPI (commandes sur un octet avec éventuellement des paramètres à suivre) ;<br />
* un contrôleur d'écran VGA affichant le contenu graphique de la RAM de la carte FPGA.<br />
<br />
A minima il faut une commande pour insérer un pixel d'une couleur donnée dans la RAM d'affichage.<br />
<br />
Vous pouvez aussi ajouter des fonctionnalités supplémentaires à votre carte FPGA :<br />
* mémoire de masse par accès direct à une carte mémoire SD ;<br />
* carte réseau Ethernet en utilisant un module PHY Ethernet.<br />
<br />
Pour les fonctionnalités supplémentaires vous devez prévoir des commandes supplémentaire au niveau du décodeur.<br />
<br />
== Cartes électroniques ==<br />
<br />
Vous devez réaliser deux type de cartes électroniques à base de microcontrôleur : une carte mère et des cartes filles.<br />
La carte FPGA/VHDL décrite dans la section précédente est considérée comme une carte fille.<br />
<br />
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.<br />
Enfin la carte mère dispose d'une mémoire permanente pour stocker des fichiers.<br />
<br />
Les cartes filles peuvent être de différents types :<br />
* carte fille clavier ;<br />
* carte fille d'affichage ;<br />
* carte fille série (se comporte comme un clavier et comme un dispositif d'affichage) ;<br />
* carte fille réseau ;<br />
* carte fille mémoire de masse (alternative à la mémoire de masse de la carte mère) ;<br />
* carte fille son.<br />
<br />
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.<br />
<br />
== Programmation système ==<br />
<br />
Le système d'exploitation du pico-ordinateur doit avoir les fonctionnalités d'un DOS (Disk Operating System), à savoir :<br />
* lecture des commandes tapées par l'utilisateur ;<br />
* téléchargement d'exécutables ou de sources via le dispositif de communication extérieur ;<br />
* sauvegarde et chargement d'exécutables ou de sources via la mémoire de masse ;<br />
* permettre l'affichage de chaînes de caractères ;<br />
* comprend un interpréteur micro-python pour faire tourner les sources ;<br />
* les différentes fonctionnalités sont réalisées sous forme de tâches gérées par un ordonnanceur.<br />
<br />
=== Commandes de base ===<br />
<br />
Ces commandes sont les commandes les plus simples à implanter :<br />
<br />
{| class="wikitable"<br />
! Commande !! Description<br />
|-<br />
| VERSION || Affiche la version du système d'exploitation<br />
|-<br />
| DEVICES || Affiche la liste des cartes filles connectées<br />
|-<br />
| ECHO || Affiche les arguments de la commande<br />
|}<br />
<br />
=== Commandes liées aux processus ===<br />
<br />
{| class="wikitable"<br />
! Commande !! Description<br />
|-<br />
| PS || Liste les processus disponibles et leur état<br />
|-<br />
| SLEEP || Met un processus en sommeil<br />
|-<br />
| WAKE || Relance un processus dormant<br />
|-<br />
| EXEC || Création d'un processus à partir d'un fichier exécutable<br />
|}<br />
<br />
La commande EXEC est complexe à réaliser, elle est optionnelle pour l'année 2023/2024.<br />
<br />
=== Commandes liées au système de fichiers ===<br />
<br />
Commandes pour gérer le système de fichiers :<br />
<br />
{| class="wikitable"<br />
! Commande !! Description<br />
|-<br />
| FORMAT || Formate le système de fichiers<br />
|-<br />
| LIST || Affiche les fichiers du répertoire principal<br />
|-<br />
| CREATE || Création d'un fichier avec l'entrée standard<br />
|-<br />
| TYPE || Affiche le contenu d'un fichier<br />
|-<br />
| COPY || Copie un fichier<br />
|-<br />
| RENAME || Renomme un fichier<br />
|}<br />
<br />
=== Commandes liées au réseau ===<br />
<br />
{| class="wikitable"<br />
! Commande !! Description<br />
|-<br />
| REMOTE || Liste les fichiers disponibles sur le réseau<br />
|-<br />
| GET || Télécharge un fichier en provenance du réseau<br />
|-<br />
| PUT || Sauve un fichier sur le réseau<br />
|}<br />
<br />
== Programmation des pilotes ==<br />
<br />
La programmation c'est aussi l'écriture des sous-systèmes ou des pilotes liés à chaque cartes :<br />
* pour la carte mère, il faut écrire un sous-système de gestion de fichiers ;<br />
* 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 ;<br />
* 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 ;<br />
* 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 ;<br />
* 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 ;<br />
* la carte fille gérant une connexion série ne nécessite qu'un modeste pilote de communication avec la carte mère ;<br />
* 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 ;<br />
* 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 ;<br />
* 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 ;<br />
* 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.<br />
<br />
= Spécifications techniques =<br />
<br />
== Ordonnanceur ==<br />
<br />
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<br />
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 :<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED)<br />
{<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
...<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
...<br />
asm volatile ( "reti" );<br />
}<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
== Cartes électroniques à microcontrôleur ==<br />
<br />
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 :<br />
* 2 broches pour l'alimentation ;<br />
* 3 broches pour les signaux SPI (MISO, MOSI, SCK) ;<br />
* 1 broche pour le CS (Chip Select) ;-<br />
* 1 broche pour une éventuelle ligne d'interruption ;<br />
* 1 broche pour une eventuelle réinitialisation de la carte (Reset).<br />
<br />
Il est conseillé d'organiser les broches sur les connecteurs HE-10 sur le modèle du bouclier Arduino fourni.<br />
<br />
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 :<br />
* l'alimentation de la carte mère doit être suffisante pour alimenter les cartes filles ;<br />
* 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 ;<br />
* les cartes filles d'un même pico-ordinateur doivent être alimentées avec la même tension.<br />
<br />
Voici quelques exemples d'architectures de cartes filles :<br />
* une carte fille SPI avec un ATMega328p et une matrice de touches ;<br />
* une carte fille SPI avec un AT90USB647 pour connexion à un clavier USB ou une clef USB ;<br />
* une carte fille SPI avec un ATMega328p et un écran LCD 2 lignes HD44780 ;<br />
* une carte fille SPI avec un ATMega16u2 pour une connexion série USB ;<br />
* une carte fille SPI avec un ATMega328p et un DAC R-2R comme carte son ;<br />
* 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) ;<br />
* une carte fille SPI avec un ATMega328p et un ENC28J60 pour une connexion Ethernet 10Mb/s.<br />
<br />
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.<br />
<br />
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 :<br />
{| class="wikitable"<br />
! Chiffre !! Type de carte<br />
|-<br />
| 0x1 || Clavier<br />
|-<br />
| 0x2 || Affichage<br />
|-<br />
| 0x4 || Réseau<br />
|-<br />
| 0x8 || Carte son<br />
|}<br />
<br />
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.<br />
<br />
== Electronique et programmation système ==<br />
<br />
=== Carte mère ===<br />
<br />
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.<br />
<br />
Vous avez aussi quelques points à approfondir.<br />
# 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 ;<br />
# La tension d'alimentation du microcontrôleur et des cartes filles :<br />
#* 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),<br />
#* 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 ;<br />
# La méthode de programmation de la carte mère :<br />
#* soit vous programmez le microcontrôleur via un connecteur AVR ISP, un programmateur et l'utilitaire <code>avrdude</code> ;<br />
#* 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
Concernant le micro-système de fichiers, les fonctionnalités suivantes doivent être implantées :<br />
<br />
* 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 ;<br />
* l'accès au système de fichiers se fait par des primitives système ;<br />
* 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 ;<br />
* 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 ;<br />
* les différentes primitives à implanter sont :<br />
** <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,<br />
** <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,<br />
** <code>remove</code> pour détruire un fichier, le seul paramètre est le nom du fichier,<br />
** <code>rename</code> pour renommer un fichier, les paramètres sont l'ancien et le nouveau noms du fichier,<br />
** <code>copy</code> pour copier un fichier, les paramètres sont le nom du fichier original et le nom de la copie.<br />
<br />
Les primitives pour le bus SPI doivent être :<br />
* une fonction d'initialisation avec le mode SPI désiré et la vitesse d'horloge souhaitée ;<br />
* une primitive pour envoyer quelques octets via le bus SPI :<br />
** 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,<br />
** la primitive stocke l'opération dans une file et effectue l'envoi dès que le bus est libre,<br />
** si la file est pleine la primitive peut retourner un code d'erreur sinon la primitive retourne l'identifiant unique de l'opération,<br />
** 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 ;<br />
* 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.<br />
<br />
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.<br />
<br />
=== Carte fille clavier "matrice de touches" ===<br />
<br />
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.<br />
<br />
Du coté programmation, c'est plus compliqué, vous êtes déjà chargés d'écrire la fonction de scan des touches :<br />
* 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) ;<br />
* si une touche est appuyée la touche est stockée dans un tampon et la ligne d'interruption est activée ;<br />
* 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.<br />
<br />
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.<br />
<br />
Au niveau du système d'exploitation les comportements suivants sont à implanter :<br />
* à 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 ;<br />
* le processus SHELL toujours présent dans le système d'exploitation doit avoir le comportement suivant :<br />
** 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 ;<br />
** dans un premier temps, les caractères reçus sont affichés en utilisant la primitive d'affichage (echo) ;<br />
** à terme les lignes de caractères reçues sont analysées pour en extraire des commandes et les exécuter.<br />
<br />
=== Carte fille clavier "USB" ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
Pour le reste de la programmation voir la section sur la carte fille "matrice de touches".<br />
<br />
=== Carte fille écran LCD ===<br />
<br />
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.<br />
<br />
Le microcontrôleur de la carte fille doit être programmé pour gérer le contrôleur HD44780 ou compatible :<br />
* les écrans avec 1, 2, 3 ou 4 lignes doivent être gérés ;<br />
* les caractères ASCII doivent être affichés sur l'écran ;<br />
* 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 ;<br />
* les codes VT100 doivent être pris en compte, en particulier pour le déplacement du curseur doivent être pris en compte ;<br />
* le contrôleur HD44780 ou compatible doit être configuré en mode défilement automatique.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Carte fille réseau RNDIS ===<br />
<br />
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 <br />
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.<br />
<br />
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>.<br />
<br />
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 :<br />
* 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 ;<br />
* 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 ;<br />
* 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).<br />
<br />
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 :<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Carte fille réseau "points d'accès de volume" ===<br />
<br />
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.<br />
<br />
Sous Linux la création d'une interface virtuelle est possible avec la fonction ci-dessous.<br />
<br />
int allocateNetworkDevice(char *name,int flags){<br />
struct ifreq ifr;<br />
int fd,err;<br />
char *clonedev = "/dev/net/tun";<br />
/* Open the clone device */<br />
if((fd=open(clonedev,O_RDWR))<0) return fd;<br />
/* Preparation of the struct ifr, of type "struct ifreq" */<br />
memset(&ifr,0,sizeof(ifr));<br />
ifr.ifr_flags=flags; /* IFF_TUN or IFF_TAP, plus maybe IFF_NO_PI */<br />
if(name!=NULL) strncpy(ifr.ifr_name,name,IFNAMSIZ);<br />
/* Try to create the device */<br />
if((err=ioctl(fd,TUNSETIFF,(void *)&ifr))<0){ close(fd); return err; }<br />
/* Write back the name of the * interface to the variable "name" */<br />
if(name!=NULL) strcpy(name,ifr.ifr_name);<br />
return fd;<br />
}<br />
<br />
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>.<br />
<br />
Pour le reste de la programmation liée à cette carte vous reporter à ce qui est demandé pour la carte réseau RNDIS.<br />
<br />
=== Carte fille réseau Ethernet ===<br />
<br />
Cette version de la carte réseau se connecte à un commutateur Ethernet et non pas à un PC pour communiquer avec le monde extérieur.<br />
<br />
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.<br />
<br />
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 :<br />
<br />
*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 ;<br />
* programmation UDP, votre projet sera plus complexe mais l'application sur le PC pourra se faire avec des sockets en mode non connecté standard ;<br />
* programmation TCP, votre projet sera plus complexe; par contre vous pourrez utiliser des applications standard sur le PC (serveur Web ou FTP).<br />
<br />
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.<br />
<br />
=== Carte fille son ===<br />
<br />
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.<br />
<br />
Le microcontrôleur de la carte fille doit être programmé pour pouvoir jouer des sons déjà enregistrés :<br />
* des variables globales doivent être configurées pour spécifier les caractéristiques des enregistrements à jouer :<br />
** précision d'échantillonnage (8 à 24 bits même si au-delà de 14 bits vous devez abandonner les bits de poids faibles),<br />
** vitesse d'acquisition (vous trouverez la vitesse maximale par essais et erreurs),<br />
** format des enregistrements (vous vous limiterez à un format PCM entier classique avec représentation petit-boutiste) ;<br />
* une fonction permettant d'envoyer les échantillons, à la bonne vitesse, sur le DAC.<br />
<br />
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.<br />
<br />
Au niveau de la carte mère vous devez écrire les primitives système :<br />
* la première primitive correspond au message SPI de code commande 0x01 et passe les paramètres de configuration à la carte fille ;<br />
* 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é.<br />
<br />
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 :<br />
* l'entête du fichier est récupéré avec la primitive <code>read</code> ;<br />
* 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 ;<br />
* 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 ;<br />
* 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 ;<br />
* é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.<br />
<br />
= Réalisations des élèves =<br />
<br />
{| class="wikitable"<br />
! Numéro du binôme !! Numéro du groupe !! Elèves !! Page <br />
|-<br />
| Binôme 1<br />
| Groupe 1<br />
| Taha Nehari & Martin Chauveliere<br />
| [[SE4Binome2023-1|Binôme 1 2023/2024]]<br />
|-<br />
| Binôme 2<br />
| Groupe 1<br />
| Simon CRUCHET & Amaury BECQUET<br />
| [[SE4Binome2023-2|Binôme 2 2023/2024]]<br />
|-<br />
| Binôme 3<br />
| Groupe 1<br />
| Louis DERYCKERE & Romain DUHR<br />
| [[SE4Binome2023-3|Binôme 3 2023/2024]]<br />
|-<br />
| Binôme 4<br />
| Groupe 1<br />
| Thomas NAVE & Thibault DUYCK<br />
| [[SE4Binome2023-4|Binôme 4 2023/2024]]<br />
|-<br />
| Binôme 5<br />
| Groupe 2<br />
| Stéphane KADER ISSACK & Marion NORMAND<br />
| [[SE4Binome2023-5|Binôme 5 2023/2024]]<br />
|-<br />
| Binôme 6<br />
| Groupe 2<br />
| Dylan Ling<br />
| [[SE4Binome2023-6|Binôme 6 2023/2024]]<br />
|-<br />
| Binôme 7<br />
| Groupe 2<br />
| Louis Wijsman & Adrien Paliferro<br />
| [[SE4Binome2023-7|Binôme 7 2023/2024]]<br />
|-<br />
| Binôme 8<br />
| Groupe 2<br />
| Némo CAZIN & Antoine CEGARRA <br />
| [[SE4Binome2023-8|Binôme 8 2023/2024]]<br />
|-<br />
| Binôme 9<br />
| Groupe 3<br />
| Younes BENMBAREK & Youness EL QASTALANI<br />
| [[SE4Binome2023-9|Binôme 9 2023/2024]]<br />
|-<br />
| Binôme 10<br />
| Groupe 3<br />
| Heriniaina ANDRIANIRINTSOA & Chaymae RHANIM <br />
| [[SE4Binome2023-10|Binôme 10 2023/2024]]<br />
|-<br />
| Binôme 11<br />
| Groupe 3<br />
| Prénom Nom & Prénom Nom<br />
| [[SE4Binome2023-11|Binôme 11 2023/2024]]<br />
|-<br />
|}</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Pico_SE4_2023/2024&diff=1423Pico SE4 2023/20242023-09-12T12:45:08Z<p>Ncazin : /* Réalisations des élèves */</p>
<hr />
<div>= Objectif =<br />
<br />
Pour l'année académique 2023/2024 nous vous demandons de construire un pico-ordinateur comprenant les éléments suivants :<br />
* un processeur de type microcontrôleur ;<br />
* un clavier ;<br />
* un dispositif d'affichage ;<br />
* un système d'exploitation stocké dans la mémoire flash du microcontrôleur ;<br />
* une mémoire de masse allant au delà de la mémoire flash sus-citée ;<br />
* un dispositif de communication avec l'extérieur.<br />
<br />
Pour faire en sorte que tous les éléments puissent communiquer entre eux nous vous demandons d'utiliser un bus série.<br />
<br />
= Compétences évaluées =<br />
<br />
Les compétences suivantes doivent être acquises durant ce module.<br />
* Savoir comprendre, ou à défaut être actif en séances pour poser les questions pertinentes aux encadrants.<br />
* Savoir produire un travail régulier et documenté durant la totalité de la période.<br />
* Savoir concevoir et réaliser des cartes électroniques fonctionnelles.<br />
* Savoir concevoir et programmer un circuit FPGA en VHDL.<br />
* Savoir structurer et écrire des pilotes pour cartes électroniques.<br />
* Savoir concevoir et implanter des primitives systèmes et un micro-système d'exploitation.<br />
<br />
= Organisation du travail =<br />
<br />
Vous aurez, comme d'habitude, la lourde tâche de tester ce module de travaux pratiques.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Matériel fourni ==<br />
<br />
<br />
[[file:2023_Bouclier_Pico.pdf||thumb|right|400px]]<br />
<br />
Pour que chaque binôme puisse avoir un minimum d'autonomie, un matériel de base est fourni :<br />
* un Arduino Uno pour prototyper le coeur d'une carte mère ;<br />
* 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 ;<br />
* 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.<br />
<br />
Le projet KiCAD pour le bouclier Arduino est disponible : [[Média:2023_Bouclier_Pico.zip]]<br />
<br />
Les projets KiCAD pour connecter les périphériques via un connecteur sont disponibles : [[Média:2023_HE10-periph.zip]]<br />
<br />
<p style="clear: both;" /><br />
<br />
[[file:2023_Bouclier_Pico_PCB.png||thumb|center|300px]]<br />
<br />
Vision de la carte partiellement montée. L'accès à la carte SD est fonctionnel.<br />
<br />
[[file:2023_Bouclier_Pico_Test.jpg||thumb|center|300px]]<br />
<br />
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]].<br />
<br />
== Réalisations par binôme ==<br />
<br />
Chaque binôme réalise :<br />
* un système d'exploitation basé sur un ordonnanceur ;<br />
* 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 ;<br />
* 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.<br />
<br />
== Réalisation par groupe de binômes ==<br />
<br />
Par groupe de 4 binômes vous devez réaliser un pico-ordinateur complet :<br />
* une carte mère ;<br />
* une carte fille FPGA/VHDL fonctionnelle et supportée par votre carte mère ;<br />
* au moins 3 cartes filles fonctionnelles et supportées par votre carte mère (clavier, écran, réseau) ;<br />
* vous pouvez ajouter une cinquième carte fille optionnelle de type carte son.<br />
<br />
= Cahier des charges =<br />
<br />
== Ordonnanceur ==<br />
<br />
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.<br />
<br />
Le principe est d'utiliser un minuteur du microcontrôleur pour lancer périodiquement une fonction d'interruption que vous allez transformer en ordonnanceur.<br />
<br />
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.<br />
<br />
Par la suite vous allez complexifier votre ordonnanceur en ajoutant :<br />
* une tâche de lecture de caractère par le port série (stocké en mémoire partagé) ;<br />
* une tâche d'écriture sur le port série (du caractère lu sur le port série) ;<br />
* une tâche d'écriture sur la matrice (du caractère lu sur le port série) ;<br />
* une tâche d'écriture sur l'afficheur 7 segments (du caractère lu sur le port série).<br />
<br />
Les deux dernières tâches sont plus compliquées à réaliser dans la mesure où elles utilisent une ressource commune.<br />
<br />
== Cartes filles FPGA ==<br />
<br />
Les cartes filles FPGA doivent être programmées en VHDL. Tous les binômes doivent implanter en VHDL :<br />
* un contrôleur de bus série SPI ;<br />
* un décodeur des commandes reçues par SPI (commandes sur un octet avec éventuellement des paramètres à suivre) ;<br />
* un contrôleur d'écran VGA affichant le contenu graphique de la RAM de la carte FPGA.<br />
<br />
A minima il faut une commande pour insérer un pixel d'une couleur donnée dans la RAM d'affichage.<br />
<br />
Vous pouvez aussi ajouter des fonctionnalités supplémentaires à votre carte FPGA :<br />
* mémoire de masse par accès direct à une carte mémoire SD ;<br />
* carte réseau Ethernet en utilisant un module PHY Ethernet.<br />
<br />
Pour les fonctionnalités supplémentaires vous devez prévoir des commandes supplémentaire au niveau du décodeur.<br />
<br />
== Cartes électroniques ==<br />
<br />
Vous devez réaliser deux type de cartes électroniques à base de microcontrôleur : une carte mère et des cartes filles.<br />
La carte FPGA/VHDL décrite dans la section précédente est considérée comme une carte fille.<br />
<br />
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.<br />
Enfin la carte mère dispose d'une mémoire permanente pour stocker des fichiers.<br />
<br />
Les cartes filles peuvent être de différents types :<br />
* carte fille clavier ;<br />
* carte fille d'affichage ;<br />
* carte fille série (se comporte comme un clavier et comme un dispositif d'affichage) ;<br />
* carte fille réseau ;<br />
* carte fille mémoire de masse (alternative à la mémoire de masse de la carte mère) ;<br />
* carte fille son.<br />
<br />
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.<br />
<br />
== Programmation système ==<br />
<br />
Le système d'exploitation du pico-ordinateur doit avoir les fonctionnalités d'un DOS (Disk Operating System), à savoir :<br />
* lecture des commandes tapées par l'utilisateur ;<br />
* téléchargement d'exécutables ou de sources via le dispositif de communication extérieur ;<br />
* sauvegarde et chargement d'exécutables ou de sources via la mémoire de masse ;<br />
* permettre l'affichage de chaînes de caractères ;<br />
* comprend un interpréteur micro-python pour faire tourner les sources ;<br />
* les différentes fonctionnalités sont réalisées sous forme de tâches gérées par un ordonnanceur.<br />
<br />
=== Commandes de base ===<br />
<br />
Ces commandes sont les commandes les plus simples à implanter :<br />
<br />
{| class="wikitable"<br />
! Commande !! Description<br />
|-<br />
| VERSION || Affiche la version du système d'exploitation<br />
|-<br />
| DEVICES || Affiche la liste des cartes filles connectées<br />
|-<br />
| ECHO || Affiche les arguments de la commande<br />
|}<br />
<br />
=== Commandes liées aux processus ===<br />
<br />
{| class="wikitable"<br />
! Commande !! Description<br />
|-<br />
| PS || Liste les processus disponibles et leur état<br />
|-<br />
| SLEEP || Met un processus en sommeil<br />
|-<br />
| WAKE || Relance un processus dormant<br />
|-<br />
| EXEC || Création d'un processus à partir d'un fichier exécutable<br />
|}<br />
<br />
La commande EXEC est complexe à réaliser, elle est optionnelle pour l'année 2023/2024.<br />
<br />
=== Commandes liées au système de fichiers ===<br />
<br />
Commandes pour gérer le système de fichiers :<br />
<br />
{| class="wikitable"<br />
! Commande !! Description<br />
|-<br />
| FORMAT || Formate le système de fichiers<br />
|-<br />
| LIST || Affiche les fichiers du répertoire principal<br />
|-<br />
| CREATE || Création d'un fichier avec l'entrée standard<br />
|-<br />
| TYPE || Affiche le contenu d'un fichier<br />
|-<br />
| COPY || Copie un fichier<br />
|-<br />
| RENAME || Renomme un fichier<br />
|}<br />
<br />
=== Commandes liées au réseau ===<br />
<br />
{| class="wikitable"<br />
! Commande !! Description<br />
|-<br />
| REMOTE || Liste les fichiers disponibles sur le réseau<br />
|-<br />
| GET || Télécharge un fichier en provenance du réseau<br />
|-<br />
| PUT || Sauve un fichier sur le réseau<br />
|}<br />
<br />
== Programmation des pilotes ==<br />
<br />
La programmation c'est aussi l'écriture des sous-systèmes ou des pilotes liés à chaque cartes :<br />
* pour la carte mère, il faut écrire un sous-système de gestion de fichiers ;<br />
* 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 ;<br />
* 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 ;<br />
* 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 ;<br />
* 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 ;<br />
* la carte fille gérant une connexion série ne nécessite qu'un modeste pilote de communication avec la carte mère ;<br />
* 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 ;<br />
* 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 ;<br />
* 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 ;<br />
* 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.<br />
<br />
= Spécifications techniques =<br />
<br />
== Ordonnanceur ==<br />
<br />
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<br />
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 :<br />
ISR(TIMER1_COMPA_vect,ISR_NAKED)<br />
{<br />
/* Sauvegarde du contexte de la tâche interrompue */<br />
...<br />
/* Appel à l'ordonnanceur */<br />
scheduler();<br />
/* Récupération du contexte de la tâche ré-activée */<br />
...<br />
asm volatile ( "reti" );<br />
}<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
== Cartes électroniques à microcontrôleur ==<br />
<br />
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 :<br />
* 2 broches pour l'alimentation ;<br />
* 3 broches pour les signaux SPI (MISO, MOSI, SCK) ;<br />
* 1 broche pour le CS (Chip Select) ;-<br />
* 1 broche pour une éventuelle ligne d'interruption ;<br />
* 1 broche pour une eventuelle réinitialisation de la carte (Reset).<br />
<br />
Il est conseillé d'organiser les broches sur les connecteurs HE-10 sur le modèle du bouclier Arduino fourni.<br />
<br />
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 :<br />
* l'alimentation de la carte mère doit être suffisante pour alimenter les cartes filles ;<br />
* 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 ;<br />
* les cartes filles d'un même pico-ordinateur doivent être alimentées avec la même tension.<br />
<br />
Voici quelques exemples d'architectures de cartes filles :<br />
* une carte fille SPI avec un ATMega328p et une matrice de touches ;<br />
* une carte fille SPI avec un AT90USB647 pour connexion à un clavier USB ou une clef USB ;<br />
* une carte fille SPI avec un ATMega328p et un écran LCD 2 lignes HD44780 ;<br />
* une carte fille SPI avec un ATMega16u2 pour une connexion série USB ;<br />
* une carte fille SPI avec un ATMega328p et un DAC R-2R comme carte son ;<br />
* 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) ;<br />
* une carte fille SPI avec un ATMega328p et un ENC28J60 pour une connexion Ethernet 10Mb/s.<br />
<br />
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.<br />
<br />
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 :<br />
{| class="wikitable"<br />
! Chiffre !! Type de carte<br />
|-<br />
| 0x1 || Clavier<br />
|-<br />
| 0x2 || Affichage<br />
|-<br />
| 0x4 || Réseau<br />
|-<br />
| 0x8 || Carte son<br />
|}<br />
<br />
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.<br />
<br />
== Electronique et programmation système ==<br />
<br />
=== Carte mère ===<br />
<br />
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.<br />
<br />
Vous avez aussi quelques points à approfondir.<br />
# 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 ;<br />
# La tension d'alimentation du microcontrôleur et des cartes filles :<br />
#* 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),<br />
#* 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 ;<br />
# La méthode de programmation de la carte mère :<br />
#* soit vous programmez le microcontrôleur via un connecteur AVR ISP, un programmateur et l'utilitaire <code>avrdude</code> ;<br />
#* 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
Concernant le micro-système de fichiers, les fonctionnalités suivantes doivent être implantées :<br />
<br />
* 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 ;<br />
* l'accès au système de fichiers se fait par des primitives système ;<br />
* 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 ;<br />
* 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 ;<br />
* les différentes primitives à implanter sont :<br />
** <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,<br />
** <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,<br />
** <code>remove</code> pour détruire un fichier, le seul paramètre est le nom du fichier,<br />
** <code>rename</code> pour renommer un fichier, les paramètres sont l'ancien et le nouveau noms du fichier,<br />
** <code>copy</code> pour copier un fichier, les paramètres sont le nom du fichier original et le nom de la copie.<br />
<br />
Les primitives pour le bus SPI doivent être :<br />
* une fonction d'initialisation avec le mode SPI désiré et la vitesse d'horloge souhaitée ;<br />
* une primitive pour envoyer quelques octets via le bus SPI :<br />
** 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,<br />
** la primitive stocke l'opération dans une file et effectue l'envoi dès que le bus est libre,<br />
** si la file est pleine la primitive peut retourner un code d'erreur sinon la primitive retourne l'identifiant unique de l'opération,<br />
** 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 ;<br />
* 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.<br />
<br />
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.<br />
<br />
=== Carte fille clavier "matrice de touches" ===<br />
<br />
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.<br />
<br />
Du coté programmation, c'est plus compliqué, vous êtes déjà chargés d'écrire la fonction de scan des touches :<br />
* 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) ;<br />
* si une touche est appuyée la touche est stockée dans un tampon et la ligne d'interruption est activée ;<br />
* 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.<br />
<br />
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.<br />
<br />
Au niveau du système d'exploitation les comportements suivants sont à implanter :<br />
* à 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 ;<br />
* le processus SHELL toujours présent dans le système d'exploitation doit avoir le comportement suivant :<br />
** 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 ;<br />
** dans un premier temps, les caractères reçus sont affichés en utilisant la primitive d'affichage (echo) ;<br />
** à terme les lignes de caractères reçues sont analysées pour en extraire des commandes et les exécuter.<br />
<br />
=== Carte fille clavier "USB" ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
Pour le reste de la programmation voir la section sur la carte fille "matrice de touches".<br />
<br />
=== Carte fille écran LCD ===<br />
<br />
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.<br />
<br />
Le microcontrôleur de la carte fille doit être programmé pour gérer le contrôleur HD44780 ou compatible :<br />
* les écrans avec 1, 2, 3 ou 4 lignes doivent être gérés ;<br />
* les caractères ASCII doivent être affichés sur l'écran ;<br />
* 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 ;<br />
* les codes VT100 doivent être pris en compte, en particulier pour le déplacement du curseur doivent être pris en compte ;<br />
* le contrôleur HD44780 ou compatible doit être configuré en mode défilement automatique.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Carte fille réseau RNDIS ===<br />
<br />
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 <br />
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.<br />
<br />
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>.<br />
<br />
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 :<br />
* 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 ;<br />
* 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 ;<br />
* 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).<br />
<br />
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 :<br />
* 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.<br />
<br />
* 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.<br />
<br />
* 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Carte fille réseau "points d'accès de volume" ===<br />
<br />
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.<br />
<br />
Sous Linux la création d'une interface virtuelle est possible avec la fonction ci-dessous.<br />
<br />
int allocateNetworkDevice(char *name,int flags){<br />
struct ifreq ifr;<br />
int fd,err;<br />
char *clonedev = "/dev/net/tun";<br />
/* Open the clone device */<br />
if((fd=open(clonedev,O_RDWR))<0) return fd;<br />
/* Preparation of the struct ifr, of type "struct ifreq" */<br />
memset(&ifr,0,sizeof(ifr));<br />
ifr.ifr_flags=flags; /* IFF_TUN or IFF_TAP, plus maybe IFF_NO_PI */<br />
if(name!=NULL) strncpy(ifr.ifr_name,name,IFNAMSIZ);<br />
/* Try to create the device */<br />
if((err=ioctl(fd,TUNSETIFF,(void *)&ifr))<0){ close(fd); return err; }<br />
/* Write back the name of the * interface to the variable "name" */<br />
if(name!=NULL) strcpy(name,ifr.ifr_name);<br />
return fd;<br />
}<br />
<br />
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>.<br />
<br />
Pour le reste de la programmation liée à cette carte vous reporter à ce qui est demandé pour la carte réseau RNDIS.<br />
<br />
=== Carte fille réseau Ethernet ===<br />
<br />
Cette version de la carte réseau se connecte à un commutateur Ethernet et non pas à un PC pour communiquer avec le monde extérieur.<br />
<br />
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.<br />
<br />
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 :<br />
<br />
*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 ;<br />
* programmation UDP, votre projet sera plus complexe mais l'application sur le PC pourra se faire avec des sockets en mode non connecté standard ;<br />
* programmation TCP, votre projet sera plus complexe; par contre vous pourrez utiliser des applications standard sur le PC (serveur Web ou FTP).<br />
<br />
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.<br />
<br />
=== Carte fille son ===<br />
<br />
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.<br />
<br />
Le microcontrôleur de la carte fille doit être programmé pour pouvoir jouer des sons déjà enregistrés :<br />
* des variables globales doivent être configurées pour spécifier les caractéristiques des enregistrements à jouer :<br />
** précision d'échantillonnage (8 à 24 bits même si au-delà de 14 bits vous devez abandonner les bits de poids faibles),<br />
** vitesse d'acquisition (vous trouverez la vitesse maximale par essais et erreurs),<br />
** format des enregistrements (vous vous limiterez à un format PCM entier classique avec représentation petit-boutiste) ;<br />
* une fonction permettant d'envoyer les échantillons, à la bonne vitesse, sur le DAC.<br />
<br />
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.<br />
<br />
Au niveau de la carte mère vous devez écrire les primitives système :<br />
* la première primitive correspond au message SPI de code commande 0x01 et passe les paramètres de configuration à la carte fille ;<br />
* 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é.<br />
<br />
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 :<br />
* l'entête du fichier est récupéré avec la primitive <code>read</code> ;<br />
* 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 ;<br />
* 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 ;<br />
* 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 ;<br />
* é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.<br />
<br />
= Réalisations des élèves =<br />
<br />
{| class="wikitable"<br />
! Numéro du binôme !! Numéro du groupe !! Elèves !! Page <br />
|-<br />
| Binôme 1<br />
| Groupe 1<br />
| Taha Nehari & Martin Chauveliere<br />
| [[SE4Binome2023-1|Binôme 1 2023/2024]]<br />
|-<br />
| Binôme 2<br />
| Groupe 1<br />
| Simon CRUCHET & Amaury BECQUET<br />
| [[SE4Binome2023-2|Binôme 2 2023/2024]]<br />
|-<br />
| Binôme 3<br />
| Groupe 1<br />
| Louis DERYCKERE & Romain DUHR<br />
| [[SE4Binome2023-3|Binôme 3 2023/2024]]<br />
|-<br />
| Binôme 4<br />
| Groupe 1<br />
| Thomas NAVE & Thibault DUYCK<br />
| [[SE4Binome2023-4|Binôme 4 2023/2024]]<br />
|-<br />
| Binôme 5<br />
| Groupe 2<br />
| Stéphane KADER ISSACK & Marion NORMAND<br />
| [[SE4Binome2023-5|Binôme 5 2023/2024]]<br />
|-<br />
| Binôme 6<br />
| Groupe 2<br />
| Dylan Ling<br />
| [[SE4Binome2023-6|Binôme 6 2023/2024]]<br />
|-<br />
| Binôme 7<br />
| Groupe 2<br />
| Louis Wijsman & Adrien Paliferro<br />
| [[SE4Binome2023-7|Binôme 7 2023/2024]]<br />
|-<br />
| Binôme 8<br />
| Groupe 2<br />
| Némo CAZIN & Némo <br />
| [[SE4Binome2023-8|Binôme 8 2023/2024]]<br />
|-<br />
| Binôme 9<br />
| Groupe 3<br />
| Prénom Nom & Prénom Nom<br />
| [[SE4Binome2023-9|Binôme 9 2023/2024]]<br />
|-<br />
| Binôme 10<br />
| Groupe 3<br />
| Prénom Nom & Prénom Nom<br />
| [[SE4Binome2023-10|Binôme 10 2023/2024]]<br />
|-<br />
| Binôme 11<br />
| Groupe 3<br />
| Prénom Nom & Prénom Nom<br />
| [[SE4Binome2023-11|Binôme 11 2023/2024]]<br />
|-<br />
|}</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3Trinome2022-8&diff=1405SE3Trinome2022-82023-09-04T16:31:44Z<p>Ncazin : modif et correction</p>
<hr />
<div>= '''Projet SE3 : Premier Système''' =<br />
CAZIN Némo, CEGARRA Antoine, PALIFERRO Adrien<br />
<br />
'''Lien du git :''' ''https://archives.plil.fr/ncazin/SE3_GROUPE_8.git''<br />
<br />
==Objectifs fixés :==<br />
L'objectif principal de ce projet était de '''réaliser la commande d'une voiture au format 1:43''' capable d'avancer et de reculer à l'aide d'un programme informatique. Avant de commencer le projet, nous nous sommes fixé plusieurs petits objectifs afin de mener au mieux le projet.<br />
<br />
La voiture devait tout d'abord avancer, reculer, tourner à gauche et à droite. Des LEDs devaient être allumées lorsque la voiture effectue un déplacement.<br />
<br />
Pour la commande de la voiture, nous voulions qu'elle soit commandée grâce à une commande Bluetooth et pilotée depuis un smartphone. Une application devait alors être faite pour gérer les déplacements. MIT App Inventor permet de gérer des communications Bluetooth et est simple d'utilisation.<br />
<br />
Afin de pouvoir implémenter toutes ses fonctionnalités, nous devions réaliser une carte électronique gérée par un microcontrôleur ATMega16u2. D'autres module devaient être ajoutés pour la bonne réalisation de nos objectifs fixés.<br />
<br />
==La carte électronique :==<br />
<br />
La réalisation de la carte électronique a débuté par la création du schéma électrique sur KICAD. Nous avons implémenté ce que nous avions déjà prévu (Chargeur, moteurs, microcontrôleur...), cependant, pour certaines fonctionnalités, des composants n'étaient pas disponibles dans les librairies Sparkfun disponibles. <br />
<br />
Nous avons donc créé les schémas de ces composants, c'est-à-dire le module Bluetooth '''FP-BM70BLE01FC2''' ainsi que le driver du moteur '''DRV8210DRL''' grâce aux informations de leurs datasheet disponible sur Internet : <br />
<br />
- Datasheet du module Bluetooth : ''https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/BM70_71-Bluetooth-Low-Energy-BLE-Module-DS60001372L.pdf'' <br />
<br />
- Datasheet du driver du moteur : ''https://www.ti.com/lit/ds/slvsfy8b/slvsfy8b.pdf?ts=1683016270840&ref_url=https%253A%252F%252Fwww.google.com%252F'' <br />
<br />
Au final, nous obtenons au final ce schéma correspondant : <br />
[[Fichier:Schématic voiture.jpg|alt=Schéma de la voiture|centré|vignette|Schéma de la voiture]]<br />
Après avoir fait le schéma de la voiture, nous avons dû faire le routage de la carte électronique. La première chose a faire à été de prendre les côtes de la voiture afin que la carte électronique se mette bien en place dessus. De plus, nous avons dû prendre les mesures des côtes du moteur continu, celui-ci va être soudé au centre de la carte et est imposant, il fallait donc prévoir la place nécessaire que le composant prendrait. <br />
<br />
Ensuite, nous avons dû réaliser les empreintes du module Bluetooth ainsi que du driver du moteur. Les mesures figurant sur leurs datasheet respectives, nous avons réussi simplement à les reproduire. Le plus compliqué a été de repérer les pâtes des composants que nous devions utiliser. Par exemple, sur le module Bluetooth, certaines entrées n'ont pas été utilisées. Nous avons aussi utilisé et adapter les empreintes des moteurs continus et pas à pas fournis par notre professeur M.Redon. <br />
<br />
Après cela, nous avons commencé le routage. Nous avons commencer par router la carte le plus possible sur une seule face jusqu'à ce que ne l'on puisse plus. Sinon nous utilisions des vias afin de router sur l'autre face. Cependant, nous avons dû recommencer une seconde fois le routage, car le premier ne nous convenait pas. Nous avons aussi demandé de l'aide au professeur M.Boé afin de réaliser les plans de masse. <br />
<br />
Voici une image du routage final notre carte électronique : <br />
[[Fichier:Routage voiture.jpg|alt=Routage de la carte électronique|centré|vignette|Routage de la carte électronique]]<br />
Voici aussi une représentation 3D de notre carte électronique : <br />
[[Fichier:Pcb 3D.jpg|alt=Représentation 3D de notre carte électronique|centré|vignette|Représentation 3D de notre carte électronique]]<br />
Le routage fini, nous avons passé commande afin de recevoir notre carte électronique et voici celle-ci avec aucune soudure : <br />
<br />
Enfin, la carte étant vierge, nous devions commencer la soudure des composants. Cette partie a été très compliquée à mettre en oeuvre, car dans le groupe, aucun de nous n'avait fait de soudure dans sa vie. Nous avons donc dû apprendre à ce moment comment faire, d'où les premières soudures un peu compliquées. <br />
<br />
Nous avons eu un problème de reconnaissance du microprocesseur lors de la commande "''lsusb"'', le matériel n'était pas détecté. Nous avons donc dû modifier le circuit qui comportait quelques erreurs, ainsi que remplacer les résistances et condensateurs afin de s'assurer de leur valeur. Finalement, nous avons dû changer le microprocesseur qui avec les précédents branchements avait surchauffé et était défectueux. Après avoir remplacé tous les composants, nous avons réussi à faire reconnaître le microprocesseur grâce à la commande "''lsusb''". Après cela, nous avons pu souder les derniers composants restants. <br />
<br />
Voici une photo de notre carte avec les composants soudés : <br />
[[Fichier:Carte électronique avec les composants soudés.jpg|alt=Carte électronique avec les composants soudés|centré|vignette|Carte électronique avec les composants soudés]]<br />
Nous avions fini la carte électronique, sa réalisation a pris la majeure partie de notre temps lors des séances. Il fallait donc ensuite réaliser un programme permettant de faire fonctionner et avancer la voiture. <br />
<br />
Fichier ZIP de notre carte électronique : [[Fichier:Voiture CCP.zip|vignette|Voiture fichiers de routage et schéma PCB]]<br />
<br />
==Programme de la voiture :==<br />
Le programme informatique était nécessaire pour le bon fonctionnement de la voiture, cependant comme le temps commençait à manquer, nous avons codé son programme en dehors des cours de projet.<br />
<br />
Nous avons donc structuré notre code en plusieurs afin de le simplifier. Les premières fonctions permettent d'initialiser les entrées et les sorties du microcontrôleur afin de bien récupérer et envoyer les bonnes informations. De plus, dans ces fonctions, nous remettons les moteurs et les leds à LOW afin d'avoir une sécurité et qu'ils ne démarrent pas à l'initialisation. Ensuite, nous retrouvons les fonctions de déplacements. Ces fonctions gèrent les moteurs lorsqu'il faut avancer, reculer, tourner à droite, etc...<br />
<br />
De plus, on retrouve une fonction permettant de récupérer les informations envoyées depuis la communication Bluetooth afin de faire fonctionner la voiture à distance. Une seconde fonction permet de traiter ces informations et de faire déplacer la voiture selon l'information reçue.<br />
<br />
Nous pouvons aussi faire fonctionner la voiture en envoyant le programme informatique dans la voiture. Cependant, de cette manière, la voiture ne pourra pas être contrôlée et fera un trajet voulu.<br />
<br />
La communication Bluetooth étant un de nos objectifs fixé, nous avons dû réaliser une application afin de pouvoir utiliser la voiture à distance.<br />
<br />
Voici une vidéo de la carte avec une LED qui clignote : <br />
[[Fichier:PCB clignote.mov|alt=LED qui clignote|centré|vignette|LED qui clignote]]<br />
<br />
==Application Bluetooth :==<br />
Nous nous étions fixé comme objectif que la voiture devait être contrôlée grâce à une application Bluetooth. Nous avons alors décidé de réaliser cette application grâce au site '''MIT App Inventor''', ce site est simple d'utilisation et permet de gérer des communications Bluetooth facilement. De plus, le temps a été investi surtout dans la carte électronique donc apprendre et programmer par nous-même dans un langage de programmation nouveau aurait été compliqué pour nous.<br />
<br />
Nous avons décidé que les informations envoyées par communication Bluetooth serait sous forme hexadécimale. Le programme informatique du côté de l'ATMega16u2 recevra et traitera alors les informations reçues. <br />
<br />
L'application devait avoir un aspect simple d'utilisation et sobre afin de faciliter l'expérience de l'utilisateur. L'application amènerait l'utilisateur sur une page permettant de choisir à quel appareil Bluetooth se connecter. Un statut indiquant si le smartphone est connecté ou non à l'appareil est aussi présent. L'élément le plus important de la page est le bloc de déplacement, composé de 4 boutons représentant des flèches directionnelles afin de piloter la voiture.<br />
<br />
Lorsque nous avions terminé l'application pour piloter grâce à des flèches directionnelles, nous nous sommes rendu compte que nous pourrions réaliser aussi un pilotage par gyroscope. En effet, les informations transmises pour les déplacements restent les mêmes donc du côté du programme informatique, rien ne change. Nous avons deux moyens de piloter la voiture : une par appui sur des flèches directionnelles, et une seconde par inclinaison du smartphone. <br />
<br />
Voilà des captures d'écran montrant l'aspect et les fonctionnalités de l'application : <br />
<br />
<gallery mode="packed" widths="150" heights="150"><br />
Fichier:App Screen Controls.jpg|Contrôle par touche<br />
Fichier:App Screen Gyro.jpg|Contrôle par gyroscope<br />
</gallery><br />
Pour réaliser cette application, il faut du code en interne, voici les codes que nous avons utilisé :<br />
<gallery mode="packed" widths="150" heights="150"><br />
Fichier:Connexion Bluetooth.jpg|Bloc de connexion Bluetooth<br />
Fichier:Gestion des boutons.jpg|Bloc de gestion des touches<br />
Fichier:Gestion gyroscope.jpg|Bloc de gestion du gyroscope<br />
</gallery><br />
<br />
'''Le fichier APK de l'application est disponible dans le GIT du projet.'''<br />
<br />
= '''Epreuve complémentaire CAZIN Némo''' =<br />
'''Lien du git :''' ''https://archives.plil.fr/ncazin/SE3_GROUPE_8.git''<br />
<br />
== Introduction : ==<br />
J’ai dû reprendre le projet lors de mon épreuve complémentaire de Semestre 6<br />
<br />
Avant cela, avec mon groupe de travail, nous avions réussi à faire clignoter une LED malgré tous les problèmes que nous avions rencontrés comme des composants qui ne fonctionnait plus sur la carte ou alors des courts-circuits à faire nous-mêmes. Je ne traiterais donc pas ici la partie du clignotement de la LED.<br />
<br />
== Préparation de la carte électronique : ==<br />
Tout d’abord, lorsque j’ai repris le projet, je savais que les soudures des composants et du moteur continu avaient été faites, mais elles étaient fragiles du fait de la petite épaisseur des pistes reliant le moteur au driver. De plus, le voyage de la boite avec la carte électronique à l’intérieur avait complétement cassé les soudures du moteur. <br />
<br />
Voici l’état de la carte lors de la reprise du projet :<br />
[[Fichier:Carte pas de soudure.jpg|alt=Carte avec le moteur désoudé|centré|vignette|Carte avec le moteur désoudé]]<br />
J’ai donc dû refaire les soudures du moteur, ce qui a été un peu compliqué, car j’ai du mal à souder en général. Mais en m’inspirant des photos que j’avais d’avant la reprise du projet, j’ai pu mieux m’en sortir. Voilà le résultat de la soudure du moteur continu : <br />
[[Fichier:Carte moteur DC.jpg|alt=Carte avec le moteur continu soudé|centré|vignette|Carte avec le moteur continu soudé]]<br />
Après cela, j’ai voulu continuer mon travail en faisant les soudures du moteur pas-à-pas. Ce moteur est très petit et les soudures à faire devaient être très précises. Pour que ce soit plus simple, j’ai utilisé 4 pins que j’ai soudé à la carte et sur les pins, des câbles sont reliés jusqu’aux quatre liaisons du moteur. Le moteur est alors déporté de la carte, mais ce n’est pas très important, car on veut juste le voir fonctionner et aucune roue n’est attachée. Ces soudures étaient vraiment compliquées à réaliser, car elles étaient très minutieuses à réaliser et souvent des soudures se cassaient lorsque j’en soudais une autre. <br />
<br />
Voilà le résultat de la soudure du moteur pas à pas : <br />
[[Fichier:Carte moteur pap.jpg|alt=Carte avec le moteur pas-à-pas soudé|centré|vignette|Carte avec le moteur pas-à-pas soudé]]Après avoir soudé tous les composants que je souhaitais, j'ai vérifié les anciennes soudures pour voir s'il n'y avait pas des câbles qui étaient cassés à cause du voyage. Après vérification, tout était bon et je pouvais commencer la programmation.<br />
<br />
== Problèmes eu pendant la programmation de la carte sur ordinateur : ==<br />
J'ai rencontré plusieurs problèmes lors de la programmation et lors de la reconnaissance de la carte par les machines. <br />
<br />
Tout d'abord, il faut savoir que j'ai commencé développer mes programmes informatiques sur les machines de l’école à distance grâce à l’outil : '''https://tp-info.polytech-lille.fr/#'''<br />
<br />
Ensuite, le premier problème était que certaines bibliothèques utilisées, notamment '''''<avr/io.h>''''' ne sont pas trouvables, ce qui fait que la compilation d'un de mes fichiers de test ne peut pas être réalisée. J'ai comme hypothèse que soit la librairie n'est pas installée sur les machines des salles de TP en C10X, soit il faut être en superutilisateur pour pouvoir compiler le fichier d'après les notes que j'ai des cours. Je ne peux pas me mettre en superutilisateur car il faut le mot de passe de la machine locale que je ne connais pas. Pour contourner ce problème, j'ai défini comme constantes toutes les variables utilisées mais ce n'est qu'une solution temporaire qui ne marchera peut-être pas lors de l'envoi du programme sur la carte, mais au moins j'ai réussi à compiler mes fichiers.<br />
[[Fichier:Erreur include.jpg|alt=Message de l'erreur reçu par rapport à la librairie <avr/io.h>|centré|vignette|Message de l'erreur reçu par rapport à la librairie <avr/io.h>]]<br />
<br />
<br />
<br />
Enfin, pour le second problème, j’ai voulu voir si la carte était reconnue depuis les machines à distance grâce à la commande shell « '''''lsusb''''' ». Cependant, lorsque je me connecte sur ces machines, les périphériques USB de mon ordinateur ne sont pas reconnus. En faisant plusieurs essais pour résoudre ce problème, j’ai compris que ce n’était pas possible et donc qu’il fallait passer par une autre méthode. Sois-je faisais directement la programmation sur Windows, mais télécharger les dépendances et le compilateur C était compliqué. Sois-je téléchargeais une machine virtuelle Ubuntu pour être directement sur un système Linux et plus simplement programmer. J’ai donc choisi la première option, car je craignais que la machine virtuelle ne reconnaisse pas elle aussi les périphériques USB.<br />
<br />
J’ai donc modifié l’option développeur de mon Windows afin de pouvoir télécharger un environnement terminal Ubuntu qui fonctionne grâce à Windows Subsystem for Linux (WSL). J’ai alors rencontré une erreur lors du lancement du terminal Ubuntu : <br />
[[Fichier:Erreur Ubuntu.jpg|alt=Erreur WSL pour Ubuntu|centré|vignette|Erreur WSL pour Ubuntu]]<br />
J’ai alors trouvé une documentation de Microsoft sur le WSL qui m’a permis de résoudre ce problème ('''https://learn.microsoft.com/fr-fr/windows/wsl/troubleshooting'''). Après cela, j’ai voulu donc tester la commande « '''''lsusb''''' » mais encore une fois, une nouvelle erreur apparaît :<br />
[[Fichier:Erreur libusb.jpg|alt=Erreur de la libusb sur Ubuntu|centré|vignette|Erreur de la libusb sur Ubuntu]]<br />
J’ai donc télécharger la librairie libusb grâce à la commande « '''''sudo apt-get install libusb-1.0-0-dev''''' » que j’ai trouvé grâce aux informations de ce site : '''https://askubuntu.com/questions/629619/how-to-install-libusb''' , mais même en faisant cette commande, j’ai toujours eu la même erreur. Donc à ce stade du projet, cette solution n'était pas viable et devait être plus approfondie.<br />
<br />
En parallèle, j'ai essayé d'installer une machine virtuelle Ubuntu sur mon ordinateur, mais Oracle VM VirtualBox n'accepte que les fichiers .xml alors que je me suis procuré un fichier .iso. Après avoir téléchargé le bon fichier, j'ai dû faire la manipulation de la première méthode pour me retrouver avec la même erreur de la libusb.<br />
<br />
Après des essais directement réalisés sur les machines de l'école, j'ai remarqué que le microprocesseur n'était pas reconnu. Il doit y avoir donc une soudure ou une connexion qui a dû se casser, ou alors le microprocesseur qui ne fonctionne plus comme nous l'avions déjà eu au début du projet.<br />
<br />
== Programmation du moteur continu : ==<br />
J’ai donc commencé par la partie du moteur continu, car c’est sur cette partie que nous nous sommes arrêtés.<br />
<br />
Afin de faire fonctionner le moteur, je devais faire un programme informatique afin de gérer cette fonctionnalité. J’ai tout d’abord créé une fonction pour initialiser les ports du moteur comme étant des sorties. Ensuite, j’ai créé une fonction « avancer » où je mets un des ports sous tension et l’autre non. Pour la fonction « reculer », il s’agit de la même chose mais il faut inverser quel port est sous tension. Enfin pour la fonction « arrêter », il suffit de mettre les deux ports à 0.<br />
<br />
Voici donc le code pour faire fonctionner le moteur de cette façon :<syntaxhighlight lang="c"><br />
//////////////////////////////////////////<br />
/// INITIALISATION MOTEUR DC AVEC PORT ///<br />
//////////////////////////////////////////<br />
<br />
void initMotDC_Port(void){<br />
DDRB |= (1<<PB7); //PMW2 en OUTPUT<br />
DDRD |= (1<<PD0); //PMW1 en OUTPUT<br />
PORTB=(0<<PB7); //PMW2 à LOW<br />
PORTD=(0<<PD0); //PMW1 à LOW<br />
}<br />
<br />
////////////////////////////////////<br />
/// CONTROLE MOTEUR DC AVEC PORT ///<br />
////////////////////////////////////<br />
<br />
void move_forwards(void){<br />
PORTB=(1<<PB7); //MOT1 à HIGH<br />
PORTD=(0<<PD0); //MOT2 à LOW<br />
}<br />
<br />
void move_backwards(void){<br />
PORTB=(0<<PB7); //MOT1 à LOW<br />
PORTD=(1<<PD0); //MOT2 à HIGH<br />
}<br />
<br />
void stop(void){<br />
PORTB=(0<<PB7); //MOT1 à LOW<br />
PORTD=(0<<PD0); //MOT2 à LOW <br />
}<br />
</syntaxhighlight>Après avoir fait cela, je me suis demandé si nous pouvions contrôler la vitesse du moteur. J’ai alors regardé trouver une page d’un cours de PSE ('''https://rex.plil.fr/Enseignement/Systeme/Systeme.PSE/systeme053.html''') expliquant comment fonctionne les actionneurs simples grâce aux signaux PWM (Pulse Width Modulation). Une partie du programme pour l’initialisation des ports était donnée, cependant, il s’agissait de la gestion des sorties que je ne comprenais pas (OCR0A, OCR0B …), j’ai donc dû effectuer plusieurs recherches sur cette partie. Voici donc le code pour faire fonctionner le moteur de cette autre façon :<syntaxhighlight lang="c"><br />
//////////////////////////////////////////<br />
/// INITIALISATION MOTEUR DC AVEC OCR1 ///<br />
//////////////////////////////////////////<br />
<br />
void initMotDC_OCR(void){<br />
DDRB |= (1<<PB7); //PMW2 en OUTPUT<br />
DDRD |= (1<<PD0); //PMW1 en OUTPUT<br />
TCCR1A |= (1<<COM1A1)|(1<<COM1C1); // Les ports PWM se comportent normalement<br />
TCCR1A |= (1<<WGM11)|(1<<WGM10); // Minuteur mis en mode PWM<br />
TCCR1B |= (1<<CS10); // Pas de pré-diviseur, démarre le compteur<br />
<br />
///////////////////////////////////<br />
/// CONTROLE MOTEUR DC AVEC OCR ///<br />
///////////////////////////////////<br />
<br />
void move_forwards_OCR(void){<br />
OCR1A = 512;<br />
OCR1C = 0;<br />
}<br />
<br />
void move_backwards_OCR(void){<br />
OCR1A = 0;<br />
OCR1C = 512;<br />
}<br />
<br />
void stop_OCR(void){<br />
OCR1A = 0;<br />
OCR1C = 0; <br />
}<br />
</syntaxhighlight><br />
<br />
== Programmation du moteur pas à pas : ==<br />
Comme je n'avais jamais travaillé sur un moteur pas à pas, j'ai voulu comprendre son fonctionnement. Après plusieurs recherches, j'ai compris que le moteur était constitué d'un rotor magnétique et de bobines. Nous avons ici un moteur pas à pas bipolaire, avec 4 sorties. Le moteur fonctionne par pas successifs comme une montre, ce qui signifie qu'il faut jouer avec chacune des sorties afin de le faire tourner pas par pas. En partant de ce principe, nous pouvons programmer une fonction pour que chaque sortie soit sous tension les unes à la suite des autres.<br />
<br />
Voici le programme pour faire tourner le moteur pas à pas dans un sens :<syntaxhighlight lang="c"><br />
///////////////////////////////////////<br />
/// INITIALISATION MOTEUR PAS A PAS ///<br />
///////////////////////////////////////<br />
<br />
void initMotStepper(void){<br />
DDRC |= (1<<PC4);<br />
DDRC |= (1<<PC5);<br />
DDRC |= (1<<PC6);<br />
DDRC |= (1<<PC7);<br />
}<br />
<br />
/////////////////////////////////<br />
/// CONTROLE MOTEUR PAS A PAS ///<br />
/////////////////////////////////<br />
<br />
void stepper_left(void){<br />
for(int i = 0; i<=100; i++){<br />
//M1_A+ à 1 puis 0<br />
PORTC=(1<<PC7);<br />
_delay_ms(5);<br />
PORTC=(0<<PC7);<br />
<br />
//M1_B- à 1 puis 0<br />
PORTC=(1<<PC4);<br />
_delay_ms(5);<br />
PORTC=(0<<PC4);<br />
<br />
//M1_A- à 1 puis 0<br />
PORTC=(1<<PC6);<br />
_delay_ms(5);<br />
PORTC=(0<<PC6);<br />
<br />
//M1_B+ à 1 puis 0<br />
PORTC=(1<<PC5);<br />
_delay_ms(5);<br />
PORTC=(0<<PC5);<br />
}<br />
}<br />
</syntaxhighlight>Pour aller dans l'autre sens, il suffit d'inverser le sens des broches des sorties :<syntaxhighlight lang="c"><br />
void stepper_right(void){<br />
for(int i = 0; i<=100; i++){<br />
//M1_B+ à 1 puis 0<br />
PORTC=(1<<PC5);<br />
_delay_ms(5);<br />
PORTC=(0<<PC5);<br />
<br />
//M1_A- à 1 puis 0<br />
PORTC=(1<<PC6);<br />
_delay_ms(5);<br />
PORTC=(0<<PC6);<br />
<br />
//M1_B- à 1 puis 0<br />
PORTC=(1<<PC4);<br />
_delay_ms(5);<br />
PORTC=(0<<PC4);<br />
<br />
//M1_A+ à 1 puis 0<br />
PORTC=(1<<PC7);<br />
_delay_ms(5);<br />
PORTC=(0<<PC7);<br />
}<br />
}<br />
</syntaxhighlight>Voici ma documentation :<br />
<br />
- '''https://www.tme.eu/fr/news/library-articles/page/41861/Moteur-pas-a-pas-types-et-exemples-dapplications-des-moteurs-pas-a-pas/'''<br />
<br />
- '''https://www.youtube.com/watch?v=655p1N9tSKQ'''<br />
<br />
- '''http://www.micropython.fr/modules_center/moteurs/pas_a_pas/moteur_pap/#le-principe-dun-moteur-pas-a-pas'''<br />
<br />
== Programmation de la communication Bluetooth : ==<br />
La partie Bluetooth était un de nos objectifs du début de projet afin de contrôler la voiture à distance et grâce à une application. Pour cela, j’ai dû refaire des recherches sur le sujet afin de mieux comprendre comment je pourrai faire. J’ai donc dû regarder la documentation de l’atmega16u2 et des cours en ligne d’autres universités pour bien comprendre. C’est alors que j’ai compris que la communication série UART permettrait de répondre à mes besoins. J’ai donc écrit une fonction qui permet l’initialisation de la communication série UART en activant la transmission (TX) et la réception (RX). Ensuite, dans cette même fonction, j’ai dû définir le format de la trame, elle est donc composée de 8 bits, c’est-à-dire un octet avec un bit d’arrêt.<br />
<br />
Nous n’avons besoin que de recevoir des informations sur la communication série UART, pas d’en envoyer. C’est pour cela que j’ai donc dû faire une seconde fonction permettant de recevoir les informations de l’application sur le port RX de l’Atmega16u2.<br />
<br />
Voici le code de la communication UART :<syntaxhighlight lang="c"><br />
/////////////////////////////////////////<br />
/// INITIALISATION COMMUNICATION UART ///<br />
/////////////////////////////////////////<br />
<br />
void UART_init(unsigned int baud_rate){<br />
// Calculer la valeur de UBRR en fonction du baud_rate<br />
unsigned int ubrr_val = FREQ_CPU / (16UL * baud_rate) - 1; <br />
// Définir les valeurs UBRRH et UBRRL<br />
UBRRH = (unsigned char)(ubrr_val >> 8);<br />
UBRRL = (unsigned char)ubrr_val;<br />
// Activer la transmission et la réception<br />
UCSRB = (1 << TXEN) | (1 << RXEN);<br />
// Définir le format de trame: 8 bits de données, 1 bit d'arrêt<br />
UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0);<br />
}<br />
<br />
/////////////////////////////////////<br />
/// RECUPERATION DES DONNEES UART ///<br />
/////////////////////////////////////<br />
<br />
int UART_receiver(void) {<br />
// Attendre que le tampon d'entrée soit plein<br />
while (!(UCSRA & (1 << RXC)));<br />
// Lire le caractère du tampon d'entrée<br />
return UDR;<br />
}<br />
</syntaxhighlight>Cette fonction ne pouvait pas être testée, car l’antenne Bluetooth n’est pas présente sur la carte électronique de la voiture. Cependant, ces recherches m’ont permis de mieux comprendre la communication série UART que j’avais mal comprise lors des TP du semestre 6.<br />
<br />
== Programmation USB/LUFA ==<br />
Pour cette partie de la programmation via USB/LUFA, j’ai repris le fichier utilisé lors de notre cours de TPI. Ce fichier avait quelques modifications à faire avant d’être utilisé. Tout d’abord, j’ai dû changer les Vendor ID et Product ID de la carte électronique, car celles utilisées maintenant n’est pas la même que pendant le cours de TPI. Normalement grâce à la commande "'''''lsusb -vvv"''''', on peut trouver le microcontrôleur utilisé et ces ID, mais nous les avions déjà noté auparavant. On trouve alors :<br />
<br />
- VENDOR ID : 0x03EB <br />
<br />
- PRODUCT ID : 0x2FEF<br />
<br />
Ensuite, des modifications étaient à faire sur les fichiers du descripteur. En effet, celui-ci avait du code qui faisait référence au joystick utilisé en TPI. J’ai donc juste gardé les fonctions qui faisaient référence aux actionneurs.<br />
<br />
De plus, afin de pouvoir gérer les actionneurs, j’ai préparé en amont comment ils seront activés grâce aux octets à envoyer. Cependant, j’ai décidé d’utiliser qu’un seul octet de contrôle, car 2 était beaucoup trop pour les simples fonctions que nous avions. Nous avons alors un seul octet ayant chaque bit qui représente une fonction de contrôle de la voiture avec de droite à gauche :<br />
<br />
- Bit 0 : Allume la LED<br />
<br />
- Bit 1 : Fait avancer la voiture<br />
<br />
- Bit 2 : Fait reculer la voiture<br />
<br />
- Bit 3 : Fait tourner dans un sens la voiture<br />
<br />
- Bit 4 : Fait tourner dans l’autre sens la voiture<br />
<br />
Par exemple, le schéma ci-dessous permet d’allumer la LED de la voiture, de la faire reculer, et en même temps de la faire tourner dans un sens :<br />
[[Fichier:USB exemple.png|alt=Exemple d'octet|centré|vignette|Exemple d'octet ]]<br />
Voici d'ailleurs le code du programme traitant chaque bit de l'octet pour exécuter les fonctions voulues : <syntaxhighlight lang="c"><br />
void actionneurs_gestion(void){<br />
Endpoint_SelectEndpoint(ACT_EPADDR);<br />
if (Endpoint_IsOUTReceived()){<br />
if (Endpoint_IsReadWriteAllowed()){<br />
uint16_t ACT_Report = Endpoint_Read_16_LE();<br />
<br />
//CONTROLE DES LEDS<br />
if(ACT_Report & (1<<0))<br />
led_on();<br />
else <br />
led_off();<br />
<br />
//CONTROLE DU MOTEUR DC<br />
if(ACT_Report & (1<<1))<br />
move_forwards();<br />
else if(ACT_Report & (1<<2))<br />
move_backwards(); <br />
else<br />
stop();<br />
<br />
//CONTROLE DU MOTEUR PAS A PAS<br />
if(ACT_Report & (1<<3))<br />
stepper_left();<br />
else if(ACT_Report & (1<<4))<br />
stepper_right();<br />
}<br />
/* Handshake the OUT Endpoint - clear endpoint and ready for next report */<br />
Endpoint_ClearOUT();<br />
}<br />
}<br />
</syntaxhighlight>Enfin, nous avons juste à envoyer l’octet de notre choix afin de gérer comme on veut les actionneurs. <br />
<br />
En retravaillant sur cette partie, j’ai mieux compris le fonctionnement de la libusb que je n’avais pas beaucoup compris lors du cours de TPI. J’ai pu me documenter sur le sujet en faisant beaucoup de recherche, et même d’apprendre des nouvelles façons de travailler avec le langage C et d’avoir une meilleure syntaxe de programmation.<br />
<br />
== Conclusion de mon travail durant l'épreuve complémentaire : ==<br />
J'ai rencontré beaucoup de problèmes durant cette épreuve complémentaire. J'en ai résolu la plupart, mais certains étaient beaucoup trop compliqués et m'ont fait passer beaucoup de temps dessus. Il fallait donc que je m'organise pour ne pas passer tout le projet à résoudre certains problèmes et mettre de côté le nécessaire.<br />
<br />
Principalement, je trouve que je me suis bien débrouillé. J'ai surtout pu me remettre à jour en programmation du langage C et sur la libusb. J'ai pu aussi améliorer mes compétences en soudure et en gestion de projet. Mais surtout, j'ai dû faire beaucoup de recherches pour bien comprendre certains aspects qui étaient nécessaires. En général, j'ai beaucoup appris durant cette épreuve et j'ai pu mettre en avant ma détermination à finir le projet.</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3Trinome2022-8&diff=1394SE3Trinome2022-82023-09-04T08:33:16Z<p>Ncazin : /* Connexion de la carte sur ordinateur : */</p>
<hr />
<div>= '''Projet SE3 : Premier Système''' =<br />
CAZIN Némo, CEGARRA Antoine, PALIFERRO Adrien<br />
<br />
'''Lien du git :''' ''https://archives.plil.fr/ncazin/SE3_GROUPE_8.git''<br />
<br />
==Objectifs fixés :==<br />
L'objectif principal de ce projet était de '''réaliser la commande d'une voiture au format 1:43''' capable d'avancer et de reculer à l'aide d'un programme informatique. Avant de commencer le projet, nous nous sommes fixé plusieurs petits objectifs afin de mener au mieux le projet.<br />
<br />
La voiture devait tout d'abord avancer, reculer, tourner à gauche et à droite. Des LEDs devaient être allumées lorsque la voiture effectue un déplacement.<br />
<br />
Pour la commande de la voiture, nous voulions qu'elle soit commandée grâce à une commande Bluetooth et pilotée depuis un smartphone. Une application devait alors être faite pour gérer les déplacements. MIT App Inventor permet de gérer des communications Bluetooth et est simple d'utilisation.<br />
<br />
Afin de pouvoir implémenter toutes ses fonctionnalités, nous devions réaliser une carte électronique gérée par un microcontrôleur ATMega16u2. D'autres module devaient être ajoutés pour la bonne réalisation de nos objectifs fixés.<br />
<br />
==La carte électronique :==<br />
<br />
La réalisation de la carte électronique a débuté par la création du schéma électrique sur KICAD. Nous avons implémenté ce que nous avions déjà prévu (Chargeur, moteurs, microcontrôleur...), cependant, pour certaines fonctionnalités, des composants n'étaient pas disponibles dans les librairies Sparkfun disponibles. <br />
<br />
Nous avons donc créé les schémas de ces composants, c'est-à-dire le module Bluetooth '''FP-BM70BLE01FC2''' ainsi que le driver du moteur '''DRV8210DRL''' grâce aux informations de leurs datasheet disponible sur Internet : <br />
<br />
- Datasheet du module Bluetooth : ''https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/BM70_71-Bluetooth-Low-Energy-BLE-Module-DS60001372L.pdf'' <br />
<br />
- Datasheet du driver du moteur : ''https://www.ti.com/lit/ds/slvsfy8b/slvsfy8b.pdf?ts=1683016270840&ref_url=https%253A%252F%252Fwww.google.com%252F'' <br />
<br />
Au final, nous obtenons au final ce schéma correspondant : <br />
[[Fichier:Schématic voiture.jpg|alt=Schéma de la voiture|centré|vignette|Schéma de la voiture]]<br />
Après avoir fait le schéma de la voiture, nous avons dû faire le routage de la carte électronique. La première chose a faire à été de prendre les côtes de la voiture afin que la carte électronique se mette bien en place dessus. De plus, nous avons dû prendre les mesures des côtes du moteur continu, celui-ci va être soudé au centre de la carte et est imposant, il fallait donc prévoir la place nécessaire que le composant prendrait. <br />
<br />
Ensuite, nous avons dû réaliser les empreintes du module Bluetooth ainsi que du driver du moteur. Les mesures figurant sur leurs datasheet respectives, nous avons réussi simplement à les reproduire. Le plus compliqué a été de repérer les pâtes des composants que nous devions utiliser. Par exemple, sur le module Bluetooth, certaines entrées n'ont pas été utilisées. Nous avons aussi utilisé et adapter les empreintes des moteurs continus et pas à pas fournis par notre professeur M.Redon. <br />
<br />
Après cela, nous avons commencé le routage. Nous avons commencer par router la carte le plus possible sur une seule face jusqu'à ce que ne l'on puisse plus. Sinon nous utilisions des vias afin de router sur l'autre face. Cependant, nous avons dû recommencer une seconde fois le routage, car le premier ne nous convenait pas. Nous avons aussi demandé de l'aide au professeur M.Boé afin de réaliser les plans de masse. <br />
<br />
Voici une image du routage final notre carte électronique : <br />
[[Fichier:Routage voiture.jpg|alt=Routage de la carte électronique|centré|vignette|Routage de la carte électronique]]<br />
Voici aussi une représentation 3D de notre carte électronique : <br />
[[Fichier:Pcb 3D.jpg|alt=Représentation 3D de notre carte électronique|centré|vignette|Représentation 3D de notre carte électronique]]<br />
Le routage fini, nous avons passé commande afin de recevoir notre carte électronique et voici celle-ci avec aucune soudure : <br />
<br />
Enfin, la carte étant vierge, nous devions commencer la soudure des composants. Cette partie a été très compliquée à mettre en oeuvre, car dans le groupe, aucun de nous n'avait fait de soudure dans sa vie. Nous avons donc dû apprendre à ce moment comment faire, d'où les premières soudures un peu compliquées. <br />
<br />
Nous avons eu un problème de reconnaissance du microprocesseur lors de la commande "''lsusb"'', le matériel n'était pas détecté. Nous avons donc dû modifier le circuit qui comportait quelques erreurs, ainsi que remplacer les résistances et condensateurs afin de s'assurer de leur valeur. Finalement, nous avons dû changer le microprocesseur qui avec les précédents branchements avait surchauffé et était défectueux. Après avoir remplacé tous les composants, nous avons réussi à faire reconnaître le microprocesseur grâce à la commande "''lsusb''". Après cela, nous avons pu souder les derniers composants restants. <br />
<br />
Voici une photo de notre carte avec les composants soudés : <br />
[[Fichier:Carte électronique avec les composants soudés.jpg|alt=Carte électronique avec les composants soudés|centré|vignette|Carte électronique avec les composants soudés]]<br />
Nous avions fini la carte électronique, sa réalisation a pris la majeure partie de notre temps lors des séances. Il fallait donc ensuite réaliser un programme permettant de faire fonctionner et avancer la voiture. <br />
<br />
Fichier ZIP de notre carte électronique : [[Fichier:Voiture CCP.zip|vignette|Voiture fichiers de routage et schéma PCB]]<br />
<br />
==Programme de la voiture :==<br />
Le programme informatique était nécessaire pour le bon fonctionnement de la voiture, cependant comme le temps commençait à manquer, nous avons codé son programme en dehors des cours de projet.<br />
<br />
Nous avons donc structuré notre code en plusieurs afin de le simplifier. Les premières fonctions permettent d'initialiser les entrées et les sorties du microcontrôleur afin de bien récupérer et envoyer les bonnes informations. De plus, dans ces fonctions, nous remettons les moteurs et les leds à LOW afin d'avoir une sécurité et qu'ils ne démarrent pas à l'initialisation. Ensuite, nous retrouvons les fonctions de déplacements. Ces fonctions gèrent les moteurs lorsqu'il faut avancer, reculer, tourner à droite, etc...<br />
<br />
De plus, on retrouve une fonction permettant de récupérer les informations envoyées depuis la communication Bluetooth afin de faire fonctionner la voiture à distance. Une seconde fonction permet de traiter ces informations et de faire déplacer la voiture selon l'information reçue.<br />
<br />
Nous pouvons aussi faire fonctionner la voiture en envoyant le programme informatique dans la voiture. Cependant, de cette manière, la voiture ne pourra pas être contrôlée et fera un trajet voulu.<br />
<br />
La communication Bluetooth étant un de nos objectifs fixé, nous avons dû réaliser une application afin de pouvoir utiliser la voiture à distance.<br />
<br />
Voici une vidéo de la carte avec une LED qui clignote : <br />
[[Fichier:PCB clignote.mov|alt=LED qui clignote|centré|vignette|LED qui clignote]]<br />
<br />
==Application Bluetooth :==<br />
Nous nous étions fixé comme objectif que la voiture devait être contrôlée grâce à une application Bluetooth. Nous avons alors décidé de réaliser cette application grâce au site '''MIT App Inventor''', ce site est simple d'utilisation et permet de gérer des communications Bluetooth facilement. De plus, le temps a été investi surtout dans la carte électronique donc apprendre et programmer par nous-même dans un langage de programmation nouveau aurait été compliqué pour nous.<br />
<br />
Nous avons décidé que les informations envoyées par communication Bluetooth serait sous forme hexadécimale. Le programme informatique du côté de l'ATMega16u2 recevra et traitera alors les informations reçues. <br />
<br />
L'application devait avoir un aspect simple d'utilisation et sobre afin de faciliter l'expérience de l'utilisateur. L'application amènerait l'utilisateur sur une page permettant de choisir à quel appareil Bluetooth se connecter. Un statut indiquant si le smartphone est connecté ou non à l'appareil est aussi présent. L'élément le plus important de la page est le bloc de déplacement, composé de 4 boutons représentant des flèches directionnelles afin de piloter la voiture.<br />
<br />
Lorsque nous avions terminé l'application pour piloter grâce à des flèches directionnelles, nous nous sommes rendu compte que nous pourrions réaliser aussi un pilotage par gyroscope. En effet, les informations transmises pour les déplacements restent les mêmes donc du côté du programme informatique, rien ne change. Nous avons deux moyens de piloter la voiture : une par appui sur des flèches directionnelles, et une seconde par inclinaison du smartphone. <br />
<br />
Voilà des captures d'écran montrant l'aspect et les fonctionnalités de l'application : <br />
<br />
<gallery mode="packed" widths="150" heights="150"><br />
Fichier:App Screen Controls.jpg|Contrôle par touche<br />
Fichier:App Screen Gyro.jpg|Contrôle par gyroscope<br />
</gallery><br />
Pour réaliser cette application, il faut du code en interne, voici les codes que nous avons utilisé :<br />
<gallery mode="packed" widths="150" heights="150"><br />
Fichier:Connexion Bluetooth.jpg|Bloc de connexion Bluetooth<br />
Fichier:Gestion des boutons.jpg|Bloc de gestion des touches<br />
Fichier:Gestion gyroscope.jpg|Bloc de gestion du gyroscope<br />
</gallery><br />
<br />
'''Le fichier APK de l'application est disponible dans le GIT du projet.'''<br />
<br />
= '''Epreuve complémentaire CAZIN Némo''' =<br />
<br />
== Introduction : ==<br />
J’ai dû reprendre le projet lors de mon épreuve complémentaire de Semestre 6<br />
<br />
Avant cela, avec mon groupe de travail, nous avions réussi à faire clignoter une LED malgré tous les problèmes que nous avons rencontrés comme des composants qui ne fonctionnait plus sur la carte ou alors des courts circuits à faire nous-mêmes. Je ne traiterais donc pas ici la partie du clignotement de la LED.<br />
<br />
== Préparation de la carte électronique : ==<br />
Tout d’abord, lorsque j’ai repris le projet, je savais que les soudures des composants et du moteur continu avait été faites mais elles étaient fragiles du fait de la petite épaisseur des pistes reliant le moteur au driver. Cependant, le voyage de la boite avec la carte électronique à l’intérieur avait complétement cassé les soudures du moteur. <br />
<br />
Voici l’état de la carte lors de la reprise du projet :<br />
[[Fichier:Carte pas de soudure.jpg|alt=Carte avec le moteur désoudé|centré|vignette|Carte avec le moteur désoudé]]<br />
J’ai donc dû refaire les soudures du moteur, ce qui a été un peu compliqué car j’ai du mal à souder en général. Mais en m’inspirant des photos que j’avais d’avant la reprise du projet, j’ai pu mieux m’en sortir. Voilà le résultat de la soudure du moteur continu : <br />
[[Fichier:Carte moteur DC.jpg|alt=Carte avec le moteur continu soudé|centré|vignette|Carte avec le moteur continu soudé]]<br />
Après cela, j’ai voulu continuer mon travail en faisant les soudures du moteur pas-à-pas. Ce moteur est très petit et les soudures à faire devaient être très précises. Pour que ce soit plus simples, j’ai utilisé 4 pins que j’ai souder à la carte et sur les pins, des câbles sont reliés jusqu’aux quatre liaisons du moteur. Le moteur est alors déporté de la carte mais ce n’est pas très important car on veut juste le voir fonctionner et aucunes roues n’est attachées. Ces soudures étaient vraiment compliquées à réaliser car elles étaient très minutieuses et souvent des soudures se cassaient lorsque j’en soudais une autre. <br />
<br />
Voilà le résultat de la soudure du moteur pas à pas : <br />
[[Fichier:Carte moteur pap.jpg|alt=Carte avec le moteur pas-à-pas soudé|centré|vignette|Carte avec le moteur pas-à-pas soudé]]<br />
<br />
== Problèmes eu pendant la programmation de la carte sur ordinateur : ==<br />
J'ai rencontré plusieurs problèmes lors de la programmation de mes programmes et lors de la reconnaissance de la carte par les machines. <br />
<br />
Tout d'abord, il faut savoir que j'ai commencé développer mes programmes informatiques sur les machines de l’école à distance grâce à l’outil : '''https://tp-info.polytech-lille.fr/#'''<br />
<br />
Ensuite, le premier problème était que certaines bibliothèques utilisées, notamment '''''<avr/io.h>''''' ne sont pas trouvables, ce qui fait que la compilation d'un de mes fichiers de test ne peut pas être réalisée. J'ai comme hypothèse que soit la librairie n'est pas installée sur les machines des salles de TP en C10X, soit il faut être en superutilisateur pour pouvoir compiler le fichier d'après les notes que j'avais des cours. Je ne peux pas me mettre en superutilisateur car il faut le mot de passe de la machine locale que je ne connais pas. Pour contourner ce problème, j'ai défini comme constantes toutes les variables utilisées mais ce n'est qu'une solution temporaire qui ne marchera peut-être pas lors de l'envoi du programme sur la carte, mais au moins j'ai réussi à compiler mes fichiers.<br />
[[Fichier:Erreur include.jpg|alt=Message de l'erreur reçu par rapport à la librairie <avr/io.h>|centré|vignette|Message de l'erreur reçu par rapport à la librairie <avr/io.h>]]<br />
<br />
<br />
Enfin, pour le second problème, j’ai voulu voir si la carte était reconnue depuis les machines à distance grâce à la commande shell « '''''lsusb''''' ». Cependant, lorsque je me connecte sur ces machines, les périphériques USB de mon ordinateur ne sont pas reconnus. En faisant plusieurs essais pour résoudre ce problème, j’ai compris que ce n’était pas possible et donc qu’il fallait passer par une autre méthode. Sois-je faisais directement la programmation sur Windows mais télécharger les dépendances et le compilateur C allait être compliqué. Sois-je téléchargeais une machine virtuelle Ubuntu pour être directement sur un système Linux et plus simplement programmer. J’ai donc choisi la première option car je craignais que la machine virtuelle ne reconnaisse pas elle aussi les périphériques USB.<br />
<br />
J’ai donc modifié l’option développeur de mon Windows afin de pouvoir télécharger un environnement terminal Ubuntu qui fonctionne grâce à Windows Subsystem for Linux (WSL). J’ai alors rencontré une erreur lors du lancement du terminal Ubuntu : <br />
[[Fichier:Erreur Ubuntu.jpg|alt=Erreur WSL pour Ubuntu|centré|vignette|Erreur WSL pour Ubuntu]]<br />
J’ai alors trouvé une documentation de Microsoft sur le WSL qui m’a permis de résoudre ce problème ('''https://learn.microsoft.com/fr-fr/windows/wsl/troubleshooting'''). Après cela, j’ai voulu donc tester la commande « '''''lsusb''''' » mais encore une fois, une nouvelle erreur apparaît :<br />
[[Fichier:Erreur libusb.jpg|alt=Erreur de la libusb sur Ubuntu|centré|vignette|Erreur de la libusb sur Ubuntu]]<br />
J’ai donc télécharger la librairie libusb grâce à la commande « '''''sudo apt-get install libusb-1.0-0-dev''''' » que j’ai trouver grâce aux informations de ce site : '''https://askubuntu.com/questions/629619/how-to-install-libusb''' mais même en faisant cette commande, j’ai toujours eu la même erreur. Donc à ce stade du projet, je ne peux donc pas transférer et tester mes programmes, je vais continuer à chercher une solution.<br />
<br />
En parallèle, j'ai essayé d'installer une machine virtuelle Ubuntu sur mon ordinateur, mais Oracle VM VirtualBox n'accepte que les fichiers .xml alors que je me suis procuré un fichier .iso<br />
<br />
== Programmation du moteur continu : ==<br />
J’ai donc commencé par la partie du moteur continu car c’est sur cette partie que nous nous sommes arrêtés.<br />
<br />
Afin de faire fonctionner le moteur, je devais faire un programme informatique afin de gérer cette fonctionnalité. J’ai tout d’abord créé une fonction pour initialiser les ports du moteur comme étant des sorties. Ensuite, j’ai créé une fonction « avancer » où je mets un des ports sous tension et l’autre non. Pour la fonction « reculer », il s’agit de la même chose mais il faut inverser quel port est sous tension. Enfin pour la fonction « arrêter », il suffit de mettre les deux ports à 0.<br />
<br />
Voici donc le code pour faire fonctionner le moteur de cette façon :<syntaxhighlight lang="c"><br />
//////////////////////////////////////////<br />
/// INITIALISATION MOTEUR DC AVEC PORT ///<br />
//////////////////////////////////////////<br />
<br />
void initMotDC_Port(void){<br />
DDRB |= (1<<PB7); //PMW2 en OUTPUT<br />
DDRD |= (1<<PD0); //PMW1 en OUTPUT<br />
PORTB=(0<<PB7); //PMW2 à LOW<br />
PORTD=(0<<PD0); //PMW1 à LOW<br />
}<br />
<br />
////////////////////////////////////<br />
/// CONTROLE MOTEUR DC AVEC PORT ///<br />
////////////////////////////////////<br />
<br />
void move_forwards(void){<br />
PORTB=(1<<PB7); //MOT1 à HIGH<br />
PORTD=(0<<PD0); //MOT2 à LOW<br />
}<br />
<br />
void move_backwards(void){<br />
PORTB=(0<<PB7); //MOT1 à LOW<br />
PORTD=(1<<PD0); //MOT2 à HIGH<br />
}<br />
<br />
void stop(void){<br />
PORTB=(0<<PB7); //MOT1 à LOW<br />
PORTD=(0<<PD0); //MOT2 à LOW <br />
}<br />
</syntaxhighlight>Après avoir fait cela, je me suis demander si nous pouvions contrôler la vitesse du moteur. J’ai alors regardé trouver une page d’un cours de PSE ('''https://rex.plil.fr/Enseignement/Systeme/Systeme.PSE/systeme053.html''')expliquant comment fonctionne les actionneurs simples grâce au signaux PWM (Pulse Width Modulation). Une partie du programme pour l’initialisation des ports était donnée, cependant il s’agissait de la gestion des sorties que je ne comprenais pas (OCR0A, OCR0B …), j’ai donc dû effectuer plusieurs recherches sur cette partie. Voici donc le code pour faire fonctionner le moteur de cette autre façon :<syntaxhighlight lang="c"><br />
//////////////////////////////////////////<br />
/// INITIALISATION MOTEUR DC AVEC OCR1 ///<br />
//////////////////////////////////////////<br />
<br />
void initMotDC_OCR(void){<br />
DDRB |= (1<<PB7); //PMW2 en OUTPUT<br />
DDRD |= (1<<PD0); //PMW1 en OUTPUT<br />
TCCR1A |= (1<<COM1A1)|(1<<COM1C1); // Les ports PWM se comportent normalement<br />
TCCR1A |= (1<<WGM11)|(1<<WGM10); // Minuteur mis en mode PWM<br />
TCCR1B |= (1<<CS10); // Pas de pré-diviseur, démarre le compteur<br />
<br />
///////////////////////////////////<br />
/// CONTROLE MOTEUR DC AVEC OCR ///<br />
///////////////////////////////////<br />
<br />
void move_forwards_OCR(void){<br />
OCR1A = 512;<br />
OCR1C = 0;<br />
}<br />
<br />
void move_backwards_OCR(void){<br />
OCR1A = 0;<br />
OCR1C = 512;<br />
}<br />
<br />
void stop_OCR(void){<br />
OCR1A = 0;<br />
OCR1C = 0; <br />
}<br />
</syntaxhighlight><br />
<br />
== Programmation du moteur pas à pas : ==<br />
Comme je n'avais jamais travaillé sur un moteur pas à pas, j'ai voulu comprendre son fonctionnement. Après plusieurs recherches, j'ai compris que le moteur était constitué d'un rotor magnétique et de bobines. Nous avons ici un moteur pas à pas bipolaire, avec 4 sorties. Le moteur fonctionne par pas succesifs comme une montre, ce qui signifie qu'il faut jouer avec chacune des sorties afin de faire le faire tourner pas par pas. En partant de ce principe nous pouvons programmer une fonction pour que chaque sorties soit sous tension les unes à la suite des autres.<br />
<br />
Voici le programme pour faire tourner le moteur pas à pas dans un sens :<syntaxhighlight lang="c"><br />
///////////////////////////////////////<br />
/// INITIALISATION MOTEUR PAS A PAS ///<br />
///////////////////////////////////////<br />
<br />
void initMotStepper(void){<br />
DDRC |= (1<<PC4);<br />
DDRC |= (1<<PC5);<br />
DDRC |= (1<<PC6);<br />
DDRC |= (1<<PC7);<br />
}<br />
<br />
/////////////////////////////////<br />
/// CONTROLE MOTEUR PAS A PAS ///<br />
/////////////////////////////////<br />
<br />
void stepper_left(void){<br />
for(int i = 0; i<=100; i++){<br />
//M1_A+ à 1 puis 0<br />
PORTC=(1<<PC7);<br />
_delay_ms(5);<br />
PORTC=(0<<PC7);<br />
<br />
//M1_B- à 1 puis 0<br />
PORTC=(1<<PC4);<br />
_delay_ms(5);<br />
PORTC=(0<<PC4);<br />
<br />
//M1_A- à 1 puis 0<br />
PORTC=(1<<PC6);<br />
_delay_ms(5);<br />
PORTC=(0<<PC6);<br />
<br />
//M1_B+ à 1 puis 0<br />
PORTC=(1<<PC5);<br />
_delay_ms(5);<br />
PORTC=(0<<PC5);<br />
}<br />
}<br />
</syntaxhighlight>Pour aller dans l'autre sens, il suffit d'inverser le sens des broches des sorties :<syntaxhighlight lang="c"><br />
void stepper_right(void){<br />
for(int i = 0; i<=100; i++){<br />
//M1_B+ à 1 puis 0<br />
PORTC=(1<<PC5);<br />
_delay_ms(5);<br />
PORTC=(0<<PC5);<br />
<br />
//M1_A- à 1 puis 0<br />
PORTC=(1<<PC6);<br />
_delay_ms(5);<br />
PORTC=(0<<PC6);<br />
<br />
//M1_B- à 1 puis 0<br />
PORTC=(1<<PC4);<br />
_delay_ms(5);<br />
PORTC=(0<<PC4);<br />
<br />
//M1_A+ à 1 puis 0<br />
PORTC=(1<<PC7);<br />
_delay_ms(5);<br />
PORTC=(0<<PC7);<br />
}<br />
}<br />
</syntaxhighlight>Voici ma documentation :<br />
<br />
- '''https://www.tme.eu/fr/news/library-articles/page/41861/Moteur-pas-a-pas-types-et-exemples-dapplications-des-moteurs-pas-a-pas/'''<br />
<br />
- '''https://www.youtube.com/watch?v=655p1N9tSKQ'''<br />
<br />
- '''http://www.micropython.fr/modules_center/moteurs/pas_a_pas/moteur_pap/#le-principe-dun-moteur-pas-a-pas'''<br />
<br />
== Programmation de la communication Bluetooth : ==<br />
La partie Bluetooth était un de nos objectifs du début de projet afin de contrôler la voiture à distance et grâce à une application. Pour cela, j’ai dû refaire des recherches sur le sujet afin de mieux comprendre comment je pourrai faire. J’ai donc dû regarder la documentation de l’atmega16u2 et des cours en ligne d’autres universités pour bien comprendre. C’est alors que j’ai compris que la communication série UART permettrait de répondre à mes besoins. J’ai donc écrit une fonction qui permet l’initialisation de la communication série UART en activant la transmission (TX) et la réception (RX). Ensuite dans cette même fonction j’ai dû définir le format de la trame, elle est donc composée de 8 bits, c’est-à-dire un octet avec un bit d’arrêt.<br />
<br />
Nous n’avons besoin que de recevoir des informations sur la communication série UART, pas d’en envoyer. C’est pour cela que j’ai donc dû faire une seconde fonction permettant de recevoir les informations de l’application sur le port RX de l’Atmega16U2.<br />
<br />
Voici le code de la communication UART :<syntaxhighlight lang="c"><br />
/////////////////////////////////////////<br />
/// INITIALISATION COMMUNICATION UART ///<br />
/////////////////////////////////////////<br />
<br />
void UART_init(unsigned int baud_rate){<br />
// Calculer la valeur de UBRR en fonction du baud_rate<br />
unsigned int ubrr_val = FREQ_CPU / (16UL * baud_rate) - 1; <br />
// Définir les valeurs UBRRH et UBRRL<br />
UBRRH = (unsigned char)(ubrr_val >> 8);<br />
UBRRL = (unsigned char)ubrr_val;<br />
// Activer la transmission et la réception<br />
UCSRB = (1 << TXEN) | (1 << RXEN);<br />
// Définir le format de trame: 8 bits de données, 1 bit d'arrêt<br />
UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0);<br />
}<br />
<br />
/////////////////////////////////////<br />
/// RECUPERATION DES DONNEES UART ///<br />
/////////////////////////////////////<br />
<br />
int UART_receiver(void) {<br />
// Attendre que le tampon d'entrée soit plein<br />
while (!(UCSRA & (1 << RXC)));<br />
// Lire le caractère du tampon d'entrée<br />
return UDR;<br />
}<br />
</syntaxhighlight>Cette fonction ne pouvait pas être testée car l’antenne Bluetooth n’est pas présente sur la carte électronique de la voiture. Cependant, ces recherches m’ont permis de mieux comprendre la communication série UART que j’avais mal compris lors des TP du semestre 6.<br />
<br />
== Programmation USB/LUFA ==<br />
Pour cette partie de la programmation via USB/LUFA, j’ai repris le fichier utilisé lors de notre cours de TPI. Ce fichier avait quelques modifications à faire avant d’être utilisé. Tout d’abord, j’ai dû changer les ID Vendor et Product de la carte électronique car celle utilisée maintenant n’est pas la même que pendant le cours de TPI. Normalement grâce à la commande "'''''lsusb -vvv"''''', on peut trouver le microcontrôleur utilisé et ces ID, mais nous les avions déjà noté auparavant. On trouve alors :<br />
<br />
- ID VENDOR : 0x03EB <br />
<br />
- ID PRODUCT : 0x2FEF<br />
<br />
Ensuite, des modifications étaient à faire sur les fichiers du descripteur. En effet, celui-ci avait du code qui faisait référence au joystick utilisé en TPI. J’ai donc juste gardé les fonctions qui faisaient référence aux actionneurs.<br />
<br />
De plus, afin de pouvoir gérer les actionneurs, j’ai préparé en amont comment ils seront activés grâce aux octets à envoyer. Cependant, j’ai décidé d’utiliser qu’un seul octet de contrôle car 2 était beaucoup trop pour les simples fonctions que nous avions. Nous avons alors un seul octet ayant chaque bit qui représente une fonction de contrôle de la voiture avec de droite à gauche :<br />
<br />
- Bit 0 à Allume la LED<br />
<br />
- Bit 1 à Fait avancer la voiture<br />
<br />
- Bit 2 à Fait reculer la voiture<br />
<br />
- Bit 3 à Fait tourner dans un sens la voiture<br />
<br />
- Bit 4 à Fait tourner dans l’autre sens la voiture<br />
<br />
Par exemple, le schéma ci-dessous permet d’allumer la LED de la voiture, de la faire reculer, et en même temps de la faire tourner dans un sens :<br />
[[Fichier:USB exemple.png|alt=Exemple d'octet|centré|vignette|Exemple d'octet ]]<br />
Voici d'ailleurs le code du programme traitant chaque bits de l'octet pour éxécuter les fonctions voulues : <syntaxhighlight lang="c"><br />
void actionneurs_gestion(void){<br />
Endpoint_SelectEndpoint(ACT_EPADDR);<br />
if (Endpoint_IsOUTReceived()){<br />
if (Endpoint_IsReadWriteAllowed()){<br />
uint16_t ACT_Report = Endpoint_Read_16_LE();<br />
<br />
//CONTROLE DES LEDS<br />
if(ACT_Report & (1<<0))<br />
led_on();<br />
else <br />
led_off();<br />
<br />
//CONTROLE DU MOTEUR DC<br />
if(ACT_Report & (1<<1))<br />
move_forwards();<br />
else if(ACT_Report & (1<<2))<br />
move_backwards(); <br />
else<br />
stop();<br />
<br />
//CONTROLE DU MOTEUR PAS A PAS<br />
if(ACT_Report & (1<<3))<br />
stepper_left();<br />
else if(ACT_Report & (1<<4))<br />
stepper_right();<br />
}<br />
/* Handshake the OUT Endpoint - clear endpoint and ready for next report */<br />
Endpoint_ClearOUT();<br />
}<br />
}<br />
</syntaxhighlight>Enfin, nous avons juste à envoyer l’octet de notre choix afin de gérer comme on le veut les actionneurs. <br />
<br />
En retravaillant sur cette partie, j’ai mieux compris le fonctionnement de la libusb que je n’avais pas beaucoup compris lors du TPI. J’ai pu me documenter sur le sujet en faisant beaucoup de recherche et même d’apprendre des nouvelles façons de travailler avec le langage C et d’avoir une meilleure syntaxe de programmation.</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Erreur_include.jpg&diff=1393Fichier:Erreur include.jpg2023-09-04T08:21:12Z<p>Ncazin : </p>
<hr />
<div>Erreur include</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3Trinome2022-8&diff=1385SE3Trinome2022-82023-09-01T13:41:40Z<p>Ncazin : /* Epreuve complémentaire CAZIN Némo */</p>
<hr />
<div>= '''Projet SE3 : Premier Système''' =<br />
CAZIN Némo, CEGARRA Antoine, PALIFERRO Adrien<br />
<br />
'''Lien du git :''' ''https://archives.plil.fr/ncazin/SE3_GROUPE_8.git''<br />
<br />
==Objectifs fixés :==<br />
L'objectif principal de ce projet était de '''réaliser la commande d'une voiture au format 1:43''' capable d'avancer et de reculer à l'aide d'un programme informatique. Avant de commencer le projet, nous nous sommes fixé plusieurs petits objectifs afin de mener au mieux le projet.<br />
<br />
La voiture devait tout d'abord avancer, reculer, tourner à gauche et à droite. Des LEDs devaient être allumées lorsque la voiture effectue un déplacement.<br />
<br />
Pour la commande de la voiture, nous voulions qu'elle soit commandée grâce à une commande Bluetooth et pilotée depuis un smartphone. Une application devait alors être faite pour gérer les déplacements. MIT App Inventor permet de gérer des communications Bluetooth et est simple d'utilisation.<br />
<br />
Afin de pouvoir implémenter toutes ses fonctionnalités, nous devions réaliser une carte électronique gérée par un microcontrôleur ATMega16u2. D'autres module devaient être ajoutés pour la bonne réalisation de nos objectifs fixés.<br />
<br />
==La carte électronique :==<br />
<br />
La réalisation de la carte électronique a débuté par la création du schéma électrique sur KICAD. Nous avons implémenté ce que nous avions déjà prévu (Chargeur, moteurs, microcontrôleur...), cependant, pour certaines fonctionnalités, des composants n'étaient pas disponibles dans les librairies Sparkfun disponibles. <br />
<br />
Nous avons donc créé les schémas de ces composants, c'est-à-dire le module Bluetooth '''FP-BM70BLE01FC2''' ainsi que le driver du moteur '''DRV8210DRL''' grâce aux informations de leurs datasheet disponible sur Internet : <br />
<br />
- Datasheet du module Bluetooth : ''https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/BM70_71-Bluetooth-Low-Energy-BLE-Module-DS60001372L.pdf'' <br />
<br />
- Datasheet du driver du moteur : ''https://www.ti.com/lit/ds/slvsfy8b/slvsfy8b.pdf?ts=1683016270840&ref_url=https%253A%252F%252Fwww.google.com%252F'' <br />
<br />
Au final, nous obtenons au final ce schéma correspondant : <br />
[[Fichier:Schématic voiture.jpg|alt=Schéma de la voiture|centré|vignette|Schéma de la voiture]]<br />
Après avoir fait le schéma de la voiture, nous avons dû faire le routage de la carte électronique. La première chose a faire à été de prendre les côtes de la voiture afin que la carte électronique se mette bien en place dessus. De plus, nous avons dû prendre les mesures des côtes du moteur continu, celui-ci va être soudé au centre de la carte et est imposant, il fallait donc prévoir la place nécessaire que le composant prendrait. <br />
<br />
Ensuite, nous avons dû réaliser les empreintes du module Bluetooth ainsi que du driver du moteur. Les mesures figurant sur leurs datasheet respectives, nous avons réussi simplement à les reproduire. Le plus compliqué a été de repérer les pâtes des composants que nous devions utiliser. Par exemple, sur le module Bluetooth, certaines entrées n'ont pas été utilisées. Nous avons aussi utilisé et adapter les empreintes des moteurs continus et pas à pas fournis par notre professeur M.Redon. <br />
<br />
Après cela, nous avons commencé le routage. Nous avons commencer par router la carte le plus possible sur une seule face jusqu'à ce que ne l'on puisse plus. Sinon nous utilisions des vias afin de router sur l'autre face. Cependant, nous avons dû recommencer une seconde fois le routage, car le premier ne nous convenait pas. Nous avons aussi demandé de l'aide au professeur M.Boé afin de réaliser les plans de masse. <br />
<br />
Voici une image du routage final notre carte électronique : <br />
[[Fichier:Routage voiture.jpg|alt=Routage de la carte électronique|centré|vignette|Routage de la carte électronique]]<br />
Voici aussi une représentation 3D de notre carte électronique : <br />
[[Fichier:Pcb 3D.jpg|alt=Représentation 3D de notre carte électronique|centré|vignette|Représentation 3D de notre carte électronique]]<br />
Le routage fini, nous avons passé commande afin de recevoir notre carte électronique et voici celle-ci avec aucune soudure : <br />
<br />
Enfin, la carte étant vierge, nous devions commencer la soudure des composants. Cette partie a été très compliquée à mettre en oeuvre, car dans le groupe, aucun de nous n'avait fait de soudure dans sa vie. Nous avons donc dû apprendre à ce moment comment faire, d'où les premières soudures un peu compliquées. <br />
<br />
Nous avons eu un problème de reconnaissance du microprocesseur lors de la commande "''lsusb"'', le matériel n'était pas détecté. Nous avons donc dû modifier le circuit qui comportait quelques erreurs, ainsi que remplacer les résistances et condensateurs afin de s'assurer de leur valeur. Finalement, nous avons dû changer le microprocesseur qui avec les précédents branchements avait surchauffé et était défectueux. Après avoir remplacé tous les composants, nous avons réussi à faire reconnaître le microprocesseur grâce à la commande "''lsusb''". Après cela, nous avons pu souder les derniers composants restants. <br />
<br />
Voici une photo de notre carte avec les composants soudés : <br />
[[Fichier:Carte électronique avec les composants soudés.jpg|alt=Carte électronique avec les composants soudés|centré|vignette|Carte électronique avec les composants soudés]]<br />
Nous avions fini la carte électronique, sa réalisation a pris la majeure partie de notre temps lors des séances. Il fallait donc ensuite réaliser un programme permettant de faire fonctionner et avancer la voiture. <br />
<br />
Fichier ZIP de notre carte électronique : [[Fichier:Voiture CCP.zip|vignette|Voiture fichiers de routage et schéma PCB]]<br />
<br />
==Programme de la voiture :==<br />
Le programme informatique était nécessaire pour le bon fonctionnement de la voiture, cependant comme le temps commençait à manquer, nous avons codé son programme en dehors des cours de projet.<br />
<br />
Nous avons donc structuré notre code en plusieurs afin de le simplifier. Les premières fonctions permettent d'initialiser les entrées et les sorties du microcontrôleur afin de bien récupérer et envoyer les bonnes informations. De plus, dans ces fonctions, nous remettons les moteurs et les leds à LOW afin d'avoir une sécurité et qu'ils ne démarrent pas à l'initialisation. Ensuite, nous retrouvons les fonctions de déplacements. Ces fonctions gèrent les moteurs lorsqu'il faut avancer, reculer, tourner à droite, etc...<br />
<br />
De plus, on retrouve une fonction permettant de récupérer les informations envoyées depuis la communication Bluetooth afin de faire fonctionner la voiture à distance. Une seconde fonction permet de traiter ces informations et de faire déplacer la voiture selon l'information reçue.<br />
<br />
Nous pouvons aussi faire fonctionner la voiture en envoyant le programme informatique dans la voiture. Cependant, de cette manière, la voiture ne pourra pas être contrôlée et fera un trajet voulu.<br />
<br />
La communication Bluetooth étant un de nos objectifs fixé, nous avons dû réaliser une application afin de pouvoir utiliser la voiture à distance.<br />
<br />
Voici une vidéo de la carte avec une LED qui clignote : <br />
[[Fichier:PCB clignote.mov|alt=LED qui clignote|centré|vignette|LED qui clignote]]<br />
<br />
==Application Bluetooth :==<br />
Nous nous étions fixé comme objectif que la voiture devait être contrôlée grâce à une application Bluetooth. Nous avons alors décidé de réaliser cette application grâce au site '''MIT App Inventor''', ce site est simple d'utilisation et permet de gérer des communications Bluetooth facilement. De plus, le temps a été investi surtout dans la carte électronique donc apprendre et programmer par nous-même dans un langage de programmation nouveau aurait été compliqué pour nous.<br />
<br />
Nous avons décidé que les informations envoyées par communication Bluetooth serait sous forme hexadécimale. Le programme informatique du côté de l'ATMega16u2 recevra et traitera alors les informations reçues. <br />
<br />
L'application devait avoir un aspect simple d'utilisation et sobre afin de faciliter l'expérience de l'utilisateur. L'application amènerait l'utilisateur sur une page permettant de choisir à quel appareil Bluetooth se connecter. Un statut indiquant si le smartphone est connecté ou non à l'appareil est aussi présent. L'élément le plus important de la page est le bloc de déplacement, composé de 4 boutons représentant des flèches directionnelles afin de piloter la voiture.<br />
<br />
Lorsque nous avions terminé l'application pour piloter grâce à des flèches directionnelles, nous nous sommes rendu compte que nous pourrions réaliser aussi un pilotage par gyroscope. En effet, les informations transmises pour les déplacements restent les mêmes donc du côté du programme informatique, rien ne change. Nous avons deux moyens de piloter la voiture : une par appui sur des flèches directionnelles, et une seconde par inclinaison du smartphone. <br />
<br />
Voilà des captures d'écran montrant l'aspect et les fonctionnalités de l'application : <br />
<br />
<gallery mode="packed" widths="150" heights="150"><br />
Fichier:App Screen Controls.jpg|Contrôle par touche<br />
Fichier:App Screen Gyro.jpg|Contrôle par gyroscope<br />
</gallery><br />
Pour réaliser cette application, il faut du code en interne, voici les codes que nous avons utilisé :<br />
<gallery mode="packed" widths="150" heights="150"><br />
Fichier:Connexion Bluetooth.jpg|Bloc de connexion Bluetooth<br />
Fichier:Gestion des boutons.jpg|Bloc de gestion des touches<br />
Fichier:Gestion gyroscope.jpg|Bloc de gestion du gyroscope<br />
</gallery><br />
<br />
'''Le fichier APK de l'application est disponible dans le GIT du projet.'''<br />
<br />
= '''Epreuve complémentaire CAZIN Némo''' =<br />
<br />
== Introduction : ==<br />
J’ai dû reprendre le projet lors de mon épreuve complémentaire de Semestre 6<br />
<br />
Avant cela, avec mon groupe de travail, nous avions réussi à faire clignoter une LED malgré tous les problèmes que nous avons rencontrés comme des composants qui ne fonctionnait plus sur la carte ou alors des courts circuits à faire nous-mêmes. Je ne traiterais donc pas ici la partie du clignotement de la LED.<br />
<br />
== Préparation de la carte électronique : ==<br />
Tout d’abord, lorsque j’ai repris le projet, je savais que les soudures des composants et du moteur continu avait été faites mais elles étaient fragiles du fait de la petite épaisseur des pistes reliant le moteur au driver. Cependant, le voyage de la boite avec la carte électronique à l’intérieur avait complétement cassé les soudures du moteur. <br />
<br />
Voici l’état de la carte lors de la reprise du projet :<br />
[[Fichier:Carte pas de soudure.jpg|alt=Carte avec le moteur désoudé|centré|vignette|Carte avec le moteur désoudé]]<br />
J’ai donc dû refaire les soudures du moteur, ce qui a été un peu compliqué car j’ai du mal à souder en général. Mais en m’inspirant des photos que j’avais d’avant la reprise du projet, j’ai pu mieux m’en sortir. Voilà le résultat de la soudure du moteur continu : <br />
[[Fichier:Carte moteur DC.jpg|alt=Carte avec le moteur continu soudé|centré|vignette|Carte avec le moteur continu soudé]]<br />
Après cela, j’ai voulu continuer mon travail en faisant les soudures du moteur pas-à-pas. Ce moteur est très petit et les soudures à faire devaient être très précises. Pour que ce soit plus simples, j’ai utilisé 4 pins que j’ai souder à la carte et sur les pins, des câbles sont reliés jusqu’aux quatre liaisons du moteur. Le moteur est alors déporté de la carte mais ce n’est pas très important car on veut juste le voir fonctionner et aucunes roues n’est attachées. Ces soudures étaient vraiment compliquées à réaliser car elles étaient très minutieuses et souvent des soudures se cassaient lorsque j’en soudais une autre. <br />
<br />
Voilà le résultat de la soudure du moteur pas à pas : <br />
[[Fichier:Carte moteur pap.jpg|alt=Carte avec le moteur pas-à-pas soudé|centré|vignette|Carte avec le moteur pas-à-pas soudé]]<br />
<br />
== Connexion de la carte sur ordinateur : ==<br />
Avant de commencer la programmation, j’ai voulu voir si la carte était toujours détectée grâce à la commande shell « '''''lsusb''''' » afin de savoir si le microcontrôleur n’avait pas lui aussi eu un problème pendant le voyage. J’ai alors rencontré plusieurs problèmes.<br />
<br />
En effet, j’avais commencé à développer mes programmes informatiques sur les machines de l’école à distance grâce à l’outil : '''https://tp-info.polytech-lille.fr/#''' . J’ai donc voulu voir si la carte était reconnue aussi depuis les machines à distances.<br />
<br />
Cependant, lorsque je me connecte sur ces machines, les périphériques USB de mon ordinateur ne sont pas reconnus. En faisant plusieurs essais pour résoudre ce problème, j’ai compris que ce n’était pas possible et donc qu’il fallait passer par une autre méthode. Sois-je faisais directement la programmation sur Windows mais télécharger les dépendances et le compilateur C allait être compliqué. Sois-je téléchargeais une machine virtuelle Ubuntu pour être directement sur un système Linux et plus simplement programmer. J’ai donc choisi la première option car je craignais que la machine virtuelle ne reconnaisse pas elle aussi les périphériques USB.<br />
<br />
J’ai donc modifié l’option développeur de mon Windows afin de pouvoir télécharger un environnement terminal Ubuntu qui fonctionne grâce à Windows Subsystem for Linux (WSL). J’ai alors rencontré une erreur lors du lancement du terminal Ubuntu : <br />
[[Fichier:Erreur Ubuntu.jpg|alt=Erreur WSL pour Ubuntu|centré|vignette|Erreur WSL pour Ubuntu]]<br />
J’ai alors trouvé une documentation de Microsoft sur le WSL qui m’a permis de résoudre ce problème ('''https://learn.microsoft.com/fr-fr/windows/wsl/troubleshooting'''). Après cela, j’ai voulu donc tester la commande « '''''lsusb''''' » mais encore une fois, une nouvelle erreur apparaît :<br />
[[Fichier:Erreur libusb.jpg|alt=Erreur de la libusb sur Ubuntu|centré|vignette|Erreur de la libusb sur Ubuntu]]<br />
J’ai donc télécharger la librairie libusb grâce à la commande « '''''sudo apt-get install libusb-1.0-0-dev''''' » que j’ai trouver grâce aux informations de ce site : '''https://askubuntu.com/questions/629619/how-to-install-libusb''' mais même en faisant cette commande, j’ai toujours eu la même erreur. Donc à ce stade du projet, je ne peux donc pas transférer et tester mes programmes, je vais continuer à chercher une solution.<br />
<br />
== Programmation du moteur continu : ==<br />
J’ai donc commencé par la partie du moteur continu car c’est sur cette partie que nous nous sommes arrêtés.<br />
<br />
Afin de faire fonctionner le moteur, je devais faire un programme informatique afin de gérer cette fonctionnalité. J’ai tout d’abord créé une fonction pour initialiser les ports du moteur comme étant des sorties. Ensuite, j’ai créé une fonction « avancer » où je mets un des ports sous tension et l’autre non. Pour la fonction « reculer », il s’agit de la même chose mais il faut inverser quel port est sous tension. Enfin pour la fonction « arrêter », il suffit de mettre les deux ports à 0.<br />
<br />
Voici donc le code pour faire fonctionner le moteur de cette façon :<syntaxhighlight lang="c"><br />
//////////////////////////////////////////<br />
/// INITIALISATION MOTEUR DC AVEC PORT ///<br />
//////////////////////////////////////////<br />
<br />
void initMotDC_Port(void){<br />
DDRB |= (1<<PB7); //PMW2 en OUTPUT<br />
DDRD |= (1<<PD0); //PMW1 en OUTPUT<br />
PORTB=(0<<PB7); //PMW2 à LOW<br />
PORTD=(0<<PD0); //PMW1 à LOW<br />
}<br />
<br />
////////////////////////////////////<br />
/// CONTROLE MOTEUR DC AVEC PORT ///<br />
////////////////////////////////////<br />
<br />
void move_forwards(void){<br />
PORTB=(1<<PB7); //MOT1 à HIGH<br />
PORTD=(0<<PD0); //MOT2 à LOW<br />
}<br />
<br />
void move_backwards(void){<br />
PORTB=(0<<PB7); //MOT1 à LOW<br />
PORTD=(1<<PD0); //MOT2 à HIGH<br />
}<br />
<br />
void stop(void){<br />
PORTB=(0<<PB7); //MOT1 à LOW<br />
PORTD=(0<<PD0); //MOT2 à LOW <br />
}<br />
</syntaxhighlight>Après avoir fait cela, je me suis demander si nous pouvions contrôler la vitesse du moteur. J’ai alors regardé trouver une page d’un cours de PSE ('''https://rex.plil.fr/Enseignement/Systeme/Systeme.PSE/systeme053.html''')expliquant comment fonctionne les actionneurs simples grâce au signaux PWM (Pulse Width Modulation). Une partie du programme pour l’initialisation des ports était donnée, cependant il s’agissait de la gestion des sorties que je ne comprenais pas (OCR0A, OCR0B …), j’ai donc dû effectuer plusieurs recherches sur cette partie. <br />
<br />
Voici donc le code pour faire fonctionner le moteur de cette autre façon :<syntaxhighlight lang="c"><br />
//////////////////////////////////////////<br />
/// INITIALISATION MOTEUR DC AVEC OCR1 ///<br />
//////////////////////////////////////////<br />
<br />
void initMotDC_OCR(void){<br />
DDRB |= (1<<PB7); //PMW2 en OUTPUT<br />
DDRD |= (1<<PD0); //PMW1 en OUTPUT<br />
TCCR1A |= (1<<COM1A1)|(1<<COM1C1); // Les ports PWM se comportent normalement<br />
TCCR1A |= (1<<WGM11)|(1<<WGM10); // Minuteur mis en mode PWM<br />
TCCR1B |= (1<<CS10); // Pas de pré-diviseur, démarre le compteur<br />
<br />
///////////////////////////////////<br />
/// CONTROLE MOTEUR DC AVEC OCR ///<br />
///////////////////////////////////<br />
<br />
void move_forwards_OCR(void){<br />
OCR1A = 512;<br />
OCR1C = 0;<br />
}<br />
<br />
void move_backwards_OCR(void){<br />
OCR1A = 0;<br />
OCR1C = 512;<br />
}<br />
<br />
void stop_OCR(void){<br />
OCR1A = 0;<br />
OCR1C = 0; <br />
}<br />
</syntaxhighlight><br />
<br />
== Programmation du moteur pas à pas : ==<br />
Comme je n'avais jamais travaillé sur un moteur pas à pas, j'ai voulu comprendre son fonctionnement. Après plusieurs recherches, j'ai compris que le moteur était constitué d'un rotor magnétique et de bobines. Nous avons ici un moteur pas à pas bipolaire, avec 4 sorties. Le moteur fonctionne par pas succesifs comme une montre, ce qui signigie qu'il faut jouer avec chacune des sorties afin de faire le faire tourner pas par pas. En partant de ce principe nous pouvons programmer une fonction pour que chaque sorties soit sous tension les unes à la suite des autres.<br />
<br />
Voici le programme pour faire tourner le moteur pas à pas dans un sens :<syntaxhighlight lang="c"><br />
///////////////////////////////////////<br />
/// INITIALISATION MOTEUR PAS A PAS ///<br />
///////////////////////////////////////<br />
<br />
void initMotStepper(void){<br />
DDRC |= (1<<PC4);<br />
DDRC |= (1<<PC5);<br />
DDRC |= (1<<PC6);<br />
DDRC |= (1<<PC7);<br />
}<br />
<br />
/////////////////////////////////<br />
/// CONTROLE MOTEUR PAS A PAS ///<br />
/////////////////////////////////<br />
<br />
void stepper_left(void){<br />
for(int i = 0; i<=100; i++){<br />
//M1_A+ à 1 puis 0<br />
PORTC=(1<<PC7);<br />
_delay_ms(5);<br />
PORTC=(0<<PC7);<br />
<br />
//M1_B- à 1 puis 0<br />
PORTC=(1<<PC4);<br />
_delay_ms(5);<br />
PORTC=(0<<PC4);<br />
<br />
//M1_A- à 1 puis 0<br />
PORTC=(1<<PC6);<br />
_delay_ms(5);<br />
PORTC=(0<<PC6);<br />
<br />
//M1_B+ à 1 puis 0<br />
PORTC=(1<<PC5);<br />
_delay_ms(5);<br />
PORTC=(0<<PC5);<br />
}<br />
}<br />
</syntaxhighlight>Pour aller dans l'autre sens, il suffit d'inverser le sens des broches de sorties :<syntaxhighlight lang="c"><br />
void stepper_right(void){<br />
for(int i = 0; i<=100; i++){<br />
//M1_B+ à 1 puis 0<br />
PORTC=(1<<PC5);<br />
_delay_ms(5);<br />
PORTC=(0<<PC5);<br />
<br />
//M1_A- à 1 puis 0<br />
PORTC=(1<<PC6);<br />
_delay_ms(5);<br />
PORTC=(0<<PC6);<br />
<br />
//M1_B- à 1 puis 0<br />
PORTC=(1<<PC4);<br />
_delay_ms(5);<br />
PORTC=(0<<PC4);<br />
<br />
//M1_A+ à 1 puis 0<br />
PORTC=(1<<PC7);<br />
_delay_ms(5);<br />
PORTC=(0<<PC7);<br />
}<br />
}<br />
</syntaxhighlight>Voici ma documentation :<br />
<br />
- '''https://www.tme.eu/fr/news/library-articles/page/41861/Moteur-pas-a-pas-types-et-exemples-dapplications-des-moteurs-pas-a-pas/'''<br />
<br />
- '''https://www.youtube.com/watch?v=655p1N9tSKQ'''<br />
<br />
- '''http://www.micropython.fr/modules_center/moteurs/pas_a_pas/moteur_pap/#le-principe-dun-moteur-pas-a-pas'''<br />
<br />
== Programmation de la communication Bluetooth : ==<br />
La partie Bluetooth était un de nos objectifs du début de projet afin de contrôler la voiture à distance et grâce à une application. Pour cela, j’ai dû refaire des recherches sur le sujet afin d’avancer. J’ai donc dû regarder la documentation de l’atmega16u2 et des cours d’autres universités pour bien comprendre. C’est alors que j’ai compris que la communication série UART permettrait de répondre à mes besoins. J’ai donc écrit une fonction qui permet l’initialisation de la communication série UART en activant la transmission (TX) et la réception (RX). Ensuite dans cette même fonction j’ai dû définir le format de la trame, elle est donc composée de 8 bits, c’est-à-dire un octet avec un bit d’arrêt.<br />
<br />
Nous n’avons besoin que de recevoir des informations sur la communication série UART, pas d’en envoyer. C’est pour cela que j’ai donc dû faire une seconde fonction permettant de recevoir les informations de l’application sur le port RX de l’Atmega16U2.<br />
<br />
Voici le code de la communication UART :<syntaxhighlight lang="c"><br />
/////////////////////////////////////////<br />
/// INITIALISATION COMMUNICATION UART ///<br />
/////////////////////////////////////////<br />
<br />
void UART_init(unsigned int baud_rate){<br />
// Calculer la valeur de UBRR en fonction du baud_rate<br />
unsigned int ubrr_val = FREQ_CPU / (16UL * baud_rate) - 1; <br />
// Définir les valeurs UBRRH et UBRRL<br />
UBRRH = (unsigned char)(ubrr_val >> 8);<br />
UBRRL = (unsigned char)ubrr_val;<br />
// Activer la transmission et la réception<br />
UCSRB = (1 << TXEN) | (1 << RXEN);<br />
// Définir le format de trame: 8 bits de données, 1 bit d'arrêt<br />
UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0);<br />
}<br />
<br />
/////////////////////////////////////<br />
/// RECUPERATION DES DONNEES UART ///<br />
/////////////////////////////////////<br />
<br />
int UART_receiver(void) {<br />
// Attendre que le tampon d'entrée soit plein<br />
while (!(UCSRA & (1 << RXC)));<br />
// Lire le caractère du tampon d'entrée<br />
return UDR;<br />
}<br />
</syntaxhighlight>Cette fonction ne pouvait pas être testée car l’antenne Bluetooth n’est pas présente sur la carte électronique de la voiture. Cependant, ces recherches m’ont permis de mieux comprendre la communication série UART que j’avais mal compris lors des TP du semestre 6.<br />
<br />
== Programmation USB/LUFA ==<br />
Pour cette partie de la programmation via USB/LUFA, j’ai repris le fichier utilisé lors de notre cours de TPI. Ce fichier avait quelques modifications à faire avant d’être utilisé. Tout d’abord, j’ai dû changer les ID Vendor et Product de la carte électronique car celle utilisée maintenant n’est pas la même que pendant le cours de TPI. Normalement grâce à la commande "'''''lsusb -vvv"''''', on peut trouver le microcontrôleur utilisé et ces ID, mais nous les avions déjà noté auparavant. On trouve alors :<br />
<br />
- ID VENDOR : 0x03EB <br />
<br />
- ID PRODUCT : 0x2FEF<br />
<br />
Ensuite, des modifications étaient à faire sur les fichiers du descripteur. En effet, celui-ci avait du code qui faisait référence au joystick utilisé en TPI. J’ai donc juste gardé les fonctions qui faisaient référence aux actionneurs.<br />
<br />
De plus, afin de pouvoir gérer les actionneurs, j’ai préparé en amont comment ils seront activés grâce aux octets à envoyer. Cependant, j’ai décidé d’utiliser qu’un seul octet de contrôle car 2 était beaucoup trop pour les simples fonctions que nous avions. Nous avons alors un seul octet ayant chaque bit qui représente une fonction de contrôle de la voiture avec de droite à gauche :<br />
<br />
- Bit 0 à Allume la LED<br />
<br />
- Bit 1 à Fait avancer la voiture<br />
<br />
- Bit 2 à Fait reculer la voiture<br />
<br />
- Bit 3 à Fait tourner dans un sens la voiture<br />
<br />
- Bit 4 à Fait tourner dans l’autre sens la voiture<br />
<br />
Par exemple, le schéma ci-dessous permet d’allumer la LED de la voiture, de la faire reculer, et en même temps de la faire tourner dans un sens :<br />
[[Fichier:USB exemple.png|alt=Exemple d'octet|centré|vignette|Exemple d'octet ]]<br />
Voici d'ailleurs le code du programme traitant chaque bits de l'octet pour éxécuter les fonctions voulues : <syntaxhighlight lang="c"><br />
void actionneurs_gestion(void){<br />
Endpoint_SelectEndpoint(ACT_EPADDR);<br />
if (Endpoint_IsOUTReceived()){<br />
if (Endpoint_IsReadWriteAllowed()){<br />
uint16_t ACT_Report = Endpoint_Read_16_LE();<br />
<br />
//CONTROLE DES LEDS<br />
if(ACT_Report & (1<<0))<br />
led_on();<br />
else <br />
led_off();<br />
<br />
//CONTROLE DU MOTEUR DC<br />
if(ACT_Report & (1<<1))<br />
move_forwards();<br />
else if(ACT_Report & (1<<2))<br />
move_backwards(); <br />
else<br />
stop();<br />
<br />
//CONTROLE DU MOTEUR PAS A PAS<br />
if(ACT_Report & (1<<3))<br />
stepper_left();<br />
else if(ACT_Report & (1<<4))<br />
stepper_right();<br />
}<br />
/* Handshake the OUT Endpoint - clear endpoint and ready for next report */<br />
Endpoint_ClearOUT();<br />
}<br />
}<br />
</syntaxhighlight>Enfin, nous avons juste à envoyer l’octet de notre choix afin de gérer comme on le veut les actionneurs. <br />
<br />
En retravaillant sur cette partie, j’ai mieux compris le fonctionnement de la libusb que je n’avais pas beaucoup compris lors du TPI. J’ai pu me documenter sur le sujet en faisant beaucoup de recherche et même d’apprendre des nouvelles façons de travailler avec le langage C et d’avoir une meilleure syntaxe de programmation.</div>Ncazinhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3Trinome2022-8&diff=1384SE3Trinome2022-82023-09-01T13:35:40Z<p>Ncazin : Rédaction rattrapages</p>
<hr />
<div>= '''Projet SE3 : Premier Système''' =<br />
CAZIN Némo, CEGARRA Antoine, PALIFERRO Adrien<br />
<br />
'''Lien du git :''' ''https://archives.plil.fr/ncazin/SE3_GROUPE_8.git''<br />
<br />
==Objectifs fixés :==<br />
L'objectif principal de ce projet était de '''réaliser la commande d'une voiture au format 1:43''' capable d'avancer et de reculer à l'aide d'un programme informatique. Avant de commencer le projet, nous nous sommes fixé plusieurs petits objectifs afin de mener au mieux le projet.<br />
<br />
La voiture devait tout d'abord avancer, reculer, tourner à gauche et à droite. Des LEDs devaient être allumées lorsque la voiture effectue un déplacement.<br />
<br />
Pour la commande de la voiture, nous voulions qu'elle soit commandée grâce à une commande Bluetooth et pilotée depuis un smartphone. Une application devait alors être faite pour gérer les déplacements. MIT App Inventor permet de gérer des communications Bluetooth et est simple d'utilisation.<br />
<br />
Afin de pouvoir implémenter toutes ses fonctionnalités, nous devions réaliser une carte électronique gérée par un microcontrôleur ATMega16u2. D'autres module devaient être ajoutés pour la bonne réalisation de nos objectifs fixés.<br />
<br />
==La carte électronique :==<br />
<br />
La réalisation de la carte électronique a débuté par la création du schéma électrique sur KICAD. Nous avons implémenté ce que nous avions déjà prévu (Chargeur, moteurs, microcontrôleur...), cependant, pour certaines fonctionnalités, des composants n'étaient pas disponibles dans les librairies Sparkfun disponibles. <br />
<br />
Nous avons donc créé les schémas de ces composants, c'est-à-dire le module Bluetooth '''FP-BM70BLE01FC2''' ainsi que le driver du moteur '''DRV8210DRL''' grâce aux informations de leurs datasheet disponible sur Internet : <br />
<br />
- Datasheet du module Bluetooth : ''https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/BM70_71-Bluetooth-Low-Energy-BLE-Module-DS60001372L.pdf'' <br />
<br />
- Datasheet du driver du moteur : ''https://www.ti.com/lit/ds/slvsfy8b/slvsfy8b.pdf?ts=1683016270840&ref_url=https%253A%252F%252Fwww.google.com%252F'' <br />
<br />
Au final, nous obtenons au final ce schéma correspondant : <br />
[[Fichier:Schématic voiture.jpg|alt=Schéma de la voiture|centré|vignette|Schéma de la voiture]]<br />
Après avoir fait le schéma de la voiture, nous avons dû faire le routage de la carte électronique. La première chose a faire à été de prendre les côtes de la voiture afin que la carte électronique se mette bien en place dessus. De plus, nous avons dû prendre les mesures des côtes du moteur continu, celui-ci va être soudé au centre de la carte et est imposant, il fallait donc prévoir la place nécessaire que le composant prendrait. <br />
<br />
Ensuite, nous avons dû réaliser les empreintes du module Bluetooth ainsi que du driver du moteur. Les mesures figurant sur leurs datasheet respectives, nous avons réussi simplement à les reproduire. Le plus compliqué a été de repérer les pâtes des composants que nous devions utiliser. Par exemple, sur le module Bluetooth, certaines entrées n'ont pas été utilisées. Nous avons aussi utilisé et adapter les empreintes des moteurs continus et pas à pas fournis par notre professeur M.Redon. <br />
<br />
Après cela, nous avons commencé le routage. Nous avons commencer par router la carte le plus possible sur une seule face jusqu'à ce que ne l'on puisse plus. Sinon nous utilisions des vias afin de router sur l'autre face. Cependant, nous avons dû recommencer une seconde fois le routage, car le premier ne nous convenait pas. Nous avons aussi demandé de l'aide au professeur M.Boé afin de réaliser les plans de masse. <br />
<br />
Voici une image du routage final notre carte électronique : <br />
[[Fichier:Routage voiture.jpg|alt=Routage de la carte électronique|centré|vignette|Routage de la carte électronique]]<br />
Voici aussi une représentation 3D de notre carte électronique : <br />
[[Fichier:Pcb 3D.jpg|alt=Représentation 3D de notre carte électronique|centré|vignette|Représentation 3D de notre carte électronique]]<br />
Le routage fini, nous avons passé commande afin de recevoir notre carte électronique et voici celle-ci avec aucune soudure : <br />
<br />
Enfin, la carte étant vierge, nous devions commencer la soudure des composants. Cette partie a été très compliquée à mettre en oeuvre, car dans le groupe, aucun de nous n'avait fait de soudure dans sa vie. Nous avons donc dû apprendre à ce moment comment faire, d'où les premières soudures un peu compliquées. <br />
<br />
Nous avons eu un problème de reconnaissance du microprocesseur lors de la commande "''lsusb"'', le matériel n'était pas détecté. Nous avons donc dû modifier le circuit qui comportait quelques erreurs, ainsi que remplacer les résistances et condensateurs afin de s'assurer de leur valeur. Finalement, nous avons dû changer le microprocesseur qui avec les précédents branchements avait surchauffé et était défectueux. Après avoir remplacé tous les composants, nous avons réussi à faire reconnaître le microprocesseur grâce à la commande "''lsusb''". Après cela, nous avons pu souder les derniers composants restants. <br />
<br />
Voici une photo de notre carte avec les composants soudés : <br />
[[Fichier:Carte électronique avec les composants soudés.jpg|alt=Carte électronique avec les composants soudés|centré|vignette|Carte électronique avec les composants soudés]]<br />
Nous avions fini la carte électronique, sa réalisation a pris la majeure partie de notre temps lors des séances. Il fallait donc ensuite réaliser un programme permettant de faire fonctionner et avancer la voiture. <br />
<br />
Fichier ZIP de notre carte électronique : [[Fichier:Voiture CCP.zip|vignette|Voiture fichiers de routage et schéma PCB]]<br />
<br />
==Programme de la voiture :==<br />
Le programme informatique était nécessaire pour le bon fonctionnement de la voiture, cependant comme le temps commençait à manquer, nous avons codé son programme en dehors des cours de projet.<br />
<br />
Nous avons donc structuré notre code en plusieurs afin de le simplifier. Les premières fonctions permettent d'initialiser les entrées et les sorties du microcontrôleur afin de bien récupérer et envoyer les bonnes informations. De plus, dans ces fonctions, nous remettons les moteurs et les leds à LOW afin d'avoir une sécurité et qu'ils ne démarrent pas à l'initialisation. Ensuite, nous retrouvons les fonctions de déplacements. Ces fonctions gèrent les moteurs lorsqu'il faut avancer, reculer, tourner à droite, etc...<br />
<br />
De plus, on retrouve une fonction permettant de récupérer les informations envoyées depuis la communication Bluetooth afin de faire fonctionner la voiture à distance. Une seconde fonction permet de traiter ces informations et de faire déplacer la voiture selon l'information reçue.<br />
<br />
Nous pouvons aussi faire fonctionner la voiture en envoyant le programme informatique dans la voiture. Cependant, de cette manière, la voiture ne pourra pas être contrôlée et fera un trajet voulu.<br />
<br />
La communication Bluetooth étant un de nos objectifs fixé, nous avons dû réaliser une application afin de pouvoir utiliser la voiture à distance.<br />
<br />
Voici une vidéo de la carte avec une LED qui clignote : <br />
[[Fichier:PCB clignote.mov|alt=LED qui clignote|centré|vignette|LED qui clignote]]<br />
<br />
==Application Bluetooth :==<br />
Nous nous étions fixé comme objectif que la voiture devait être contrôlée grâce à une application Bluetooth. Nous avons alors décidé de réaliser cette application grâce au site '''MIT App Inventor''', ce site est simple d'utilisation et permet de gérer des communications Bluetooth facilement. De plus, le temps a été investi surtout dans la carte électronique donc apprendre et programmer par nous-même dans un langage de programmation nouveau aurait été compliqué pour nous.<br />
<br />
Nous avons décidé que les informations envoyées par communication Bluetooth serait sous forme hexadécimale. Le programme informatique du côté de l'ATMega16u2 recevra et traitera alors les informations reçues. <br />
<br />
L'application devait avoir un aspect simple d'utilisation et sobre afin de faciliter l'expérience de l'utilisateur. L'application amènerait l'utilisateur sur une page permettant de choisir à quel appareil Bluetooth se connecter. Un statut indiquant si le smartphone est connecté ou non à l'appareil est aussi présent. L'élément le plus important de la page est le bloc de déplacement, composé de 4 boutons représentant des flèches directionnelles afin de piloter la voiture.<br />
<br />
Lorsque nous avions terminé l'application pour piloter grâce à des flèches directionnelles, nous nous sommes rendu compte que nous pourrions réaliser aussi un pilotage par gyroscope. En effet, les informations transmises pour les déplacements restent les mêmes donc du côté du programme informatique, rien ne change. Nous avons deux moyens de piloter la voiture : une par appui sur des flèches directionnelles, et une seconde par inclinaison du smartphone. <br />
<br />
Voilà des captures d'écran montrant l'aspect et les fonctionnalités de l'application : <br />
<br />
<gallery mode="packed" widths="150" heights="150"><br />
Fichier:App Screen Controls.jpg|Contrôle par touche<br />
Fichier:App Screen Gyro.jpg|Contrôle par gyroscope<br />
</gallery><br />
Pour réaliser cette application, il faut du code en interne, voici les codes que nous avons utilisé :<br />
<gallery mode="packed" widths="150" heights="150"><br />
Fichier:Connexion Bluetooth.jpg|Bloc de connexion Bluetooth<br />
Fichier:Gestion des boutons.jpg|Bloc de gestion des touches<br />
Fichier:Gestion gyroscope.jpg|Bloc de gestion du gyroscope<br />
</gallery><br />
<br />
'''Le fichier APK de l'application est disponible dans le GIT du projet.'''<br />
<br />
= Epreuve complémentaire CAZIN Némo =<br />
<br />
== Introduction : ==<br />
J’ai dû reprendre le projet lors de mon épreuve complémentaire de Semestre 6<br />
<br />
Avant cela, avec mon groupe de travail, nous avions réussi à faire clignoter une LED malgré tous les problèmes que nous avons rencontrés comme des composants qui ne fonctionnait plus sur la carte ou alors des courts circuits à faire nous-mêmes. Je ne traiterais donc pas ici la partie du clignotement de la LED.<br />
<br />
== Préparation de la carte électronique : ==<br />
Tout d’abord, lorsque j’ai repris le projet, je savais que les soudures des composants et du moteur continu avait été faites mais elles étaient fragiles du fait de la petite épaisseur des pistes reliant le moteur au driver. Cependant, le voyage de la boite avec la carte électronique à l’intérieur avait complétement cassé les soudures du moteur. <br />
<br />
Voici l’état de la carte lors de la reprise du projet :<br />
[[Fichier:Carte pas de soudure.jpg|alt=Carte avec le moteur désoudé|centré|vignette|Carte avec le moteur désoudé]]<br />
J’ai donc dû refaire les soudures du moteur, ce qui a été un peu compliqué car j’ai du mal à souder en général. Mais en m’inspirant des photos que j’avais d’avant la reprise du projet, j’ai pu mieux m’en sortir. Voilà le résultat de la soudure du moteur continu : <br />
[[Fichier:Carte moteur DC.jpg|alt=Carte avec le moteur continu soudé|centré|vignette|Carte avec le moteur continu soudé]]<br />
Après cela, j’ai voulu continuer mon travail en faisant les soudures du moteur pas-à-pas. Ce moteur est très petit et les soudures à faire devaient être très précises. Pour que ce soit plus simples, j’ai utilisé 4 pins que j’ai souder à la carte et sur les pins, des câbles sont reliés jusqu’aux quatre liaisons du moteur. Le moteur est alors déporté de la carte mais ce n’est pas très important car on veut juste le voir fonctionner et aucunes roues n’est attachées. Ces soudures étaient vraiment compliquées à réaliser car elles étaient très minutieuses et souvent des soudures se cassaient lorsque j’en soudais une autre. <br />
<br />
Voilà le résultat de la soudure du moteur pas à pas : <br />
[[Fichier:Carte moteur pap.jpg|alt=Carte avec le moteur pas-à-pas soudé|centré|vignette|Carte avec le moteur pas-à-pas soudé]]<br />
<br />
== Connexion de la carte sur ordinateur : ==<br />
Avant de commencer la programmation, j’ai voulu voir si la carte était toujours détectée grâce à la commande shell « '''''lsusb''''' » afin de savoir si le microcontrôleur n’avait pas lui aussi eu un problème pendant le voyage. J’ai alors rencontré plusieurs problèmes.<br />
<br />
En effet, j’avais commencé à développer mes programmes informatiques sur les machines de l’école à distance grâce à l’outil : '''https://tp-info.polytech-lille.fr/#''' . J’ai donc voulu voir si la carte était reconnue aussi depuis les machines à distances.<br />
<br />
Cependant, lorsque je me connecte sur ces machines, les périphériques USB de mon ordinateur ne sont pas reconnus. En faisant plusieurs essais pour résoudre ce problème, j’ai compris que ce n’était pas possible et donc qu’il fallait passer par une autre méthode. Sois-je faisais directement la programmation sur Windows mais télécharger les dépendances et le compilateur C allait être compliqué. Sois-je téléchargeais une machine virtuelle Ubuntu pour être directement sur un système Linux et plus simplement programmer. J’ai donc choisi la première option car je craignais que la machine virtuelle ne reconnaisse pas elle aussi les périphériques USB.<br />
<br />
J’ai donc modifié l’option développeur de mon Windows afin de pouvoir télécharger un environnement terminal Ubuntu qui fonctionne grâce à Windows Subsystem for Linux (WSL). J’ai alors rencontré une erreur lors du lancement du terminal Ubuntu : <br />
[[Fichier:Erreur Ubuntu.jpg|alt=Erreur WSL pour Ubuntu|centré|vignette|Erreur WSL pour Ubuntu]]<br />
J’ai alors trouvé une documentation de Microsoft sur le WSL qui m’a permis de résoudre ce problème ('''https://learn.microsoft.com/fr-fr/windows/wsl/troubleshooting'''). Après cela, j’ai voulu donc tester la commande « '''''lsusb''''' » mais encore une fois, une nouvelle erreur apparaît :<br />
[[Fichier:Erreur libusb.jpg|alt=Erreur de la libusb sur Ubuntu|centré|vignette|Erreur de la libusb sur Ubuntu]]<br />
J’ai donc télécharger la librairie libusb grâce à la commande « '''''sudo apt-get install libusb-1.0-0-dev''''' » que j’ai trouver grâce aux informations de ce site : '''https://askubuntu.com/questions/629619/how-to-install-libusb''' mais même en faisant cette commande, j’ai toujours eu la même erreur. Donc à ce stade du projet, je ne peux donc pas transférer et tester mes programmes, je vais continuer à chercher une solution.<br />
<br />
== Programmation du moteur continu : ==<br />
J’ai donc commencé par la partie du moteur continu car c’est sur cette partie que nous nous sommes arrêtés.<br />
<br />
Afin de faire fonctionner le moteur, je devais faire un programme informatique afin de gérer cette fonctionnalité. J’ai tout d’abord créé une fonction pour initialiser les ports du moteur comme étant des sorties. Ensuite, j’ai créé une fonction « avancer » où je mets un des ports sous tension et l’autre non. Pour la fonction « reculer », il s’agit de la même chose mais il faut inverser quel port est sous tension. Enfin pour la fonction « arrêter », il suffit de mettre les deux ports à 0.<br />
<br />
Voici donc le code pour faire fonctionner le moteur de cette façon :<syntaxhighlight lang="c"><br />
//////////////////////////////////////////<br />
/// INITIALISATION MOTEUR DC AVEC PORT ///<br />
//////////////////////////////////////////<br />
<br />
void initMotDC_Port(void){<br />
DDRB |= (1<<PB7); //PMW2 en OUTPUT<br />
DDRD |= (1<<PD0); //PMW1 en OUTPUT<br />
PORTB=(0<<PB7); //PMW2 à LOW<br />
PORTD=(0<<PD0); //PMW1 à LOW<br />
}<br />
<br />
////////////////////////////////////<br />
/// CONTROLE MOTEUR DC AVEC PORT ///<br />
////////////////////////////////////<br />
<br />
void move_forwards(void){<br />
PORTB=(1<<PB7); //MOT1 à HIGH<br />
PORTD=(0<<PD0); //MOT2 à LOW<br />
}<br />
<br />
void move_backwards(void){<br />
PORTB=(0<<PB7); //MOT1 à LOW<br />
PORTD=(1<<PD0); //MOT2 à HIGH<br />
}<br />
<br />
void stop(void){<br />
PORTB=(0<<PB7); //MOT1 à LOW<br />
PORTD=(0<<PD0); //MOT2 à LOW <br />
}<br />
</syntaxhighlight>Après avoir fait cela, je me suis demander si nous pouvions contrôler la vitesse du moteur. J’ai alors regardé trouver une page d’un cours de PSE ('''https://rex.plil.fr/Enseignement/Systeme/Systeme.PSE/systeme053.html''')expliquant comment fonctionne les actionneurs simples grâce au signaux PWM (Pulse Width Modulation). Une partie du programme pour l’initialisation des ports était donnée, cependant il s’agissait de la gestion des sorties que je ne comprenais pas (OCR0A, OCR0B …), j’ai donc dû effectuer plusieurs recherches sur cette partie. <br />
<br />
Voici donc le code pour faire fonctionner le moteur de cette autre façon :<syntaxhighlight lang="c"><br />
//////////////////////////////////////////<br />
/// INITIALISATION MOTEUR DC AVEC OCR1 ///<br />
//////////////////////////////////////////<br />
<br />
void initMotDC_OCR(void){<br />
DDRB |= (1<<PB7); //PMW2 en OUTPUT<br />
DDRD |= (1<<PD0); //PMW1 en OUTPUT<br />
TCCR1A |= (1<<COM1A1)|(1<<COM1C1); // Les ports PWM se comportent normalement<br />
TCCR1A |= (1<<WGM11)|(1<<WGM10); // Minuteur mis en mode PWM<br />
TCCR1B |= (1<<CS10); // Pas de pré-diviseur, démarre le compteur<br />
<br />
///////////////////////////////////<br />
/// CONTROLE MOTEUR DC AVEC OCR ///<br />
///////////////////////////////////<br />
<br />
void move_forwards_OCR(void){<br />
OCR1A = 512;<br />
OCR1C = 0;<br />
}<br />
<br />
void move_backwards_OCR(void){<br />
OCR1A = 0;<br />
OCR1C = 512;<br />
}<br />
<br />
void stop_OCR(void){<br />
OCR1A = 0;<br />
OCR1C = 0; <br />
}<br />
</syntaxhighlight><br />
<br />
== Programmation du moteur pas à pas : ==<br />
Comme je n'avais jamais travaillé sur un moteur pas à pas, j'ai voulu comprendre son fonctionnement. Après plusieurs recherches, j'ai compris que le moteur était constitué d'un rotor magnétique et de bobines. Nous avons ici un moteur pas à pas bipolaire, avec 4 sorties. Le moteur fonctionne par pas succesifs comme une montre, ce qui signigie qu'il faut jouer avec chacune des sorties afin de faire le faire tourner pas par pas. En partant de ce principe nous pouvons programmer une fonction pour que chaque sorties soit sous tension les unes à la suite des autres.<br />
<br />
Voici le programme pour faire tourner le moteur pas à pas dans un sens :<syntaxhighlight lang="c"><br />
///////////////////////////////////////<br />
/// INITIALISATION MOTEUR PAS A PAS ///<br />
///////////////////////////////////////<br />
<br />
void initMotStepper(void){<br />
DDRC |= (1<<PC4);<br />
DDRC |= (1<<PC5);<br />
DDRC |= (1<<PC6);<br />
DDRC |= (1<<PC7);<br />
}<br />
<br />
/////////////////////////////////<br />
/// CONTROLE MOTEUR PAS A PAS ///<br />
/////////////////////////////////<br />
<br />
void stepper_left(void){<br />
for(int i = 0; i<=100; i++){<br />
//M1_A+ à 1 puis 0<br />
PORTC=(1<<PC7);<br />
_delay_ms(5);<br />
PORTC=(0<<PC7);<br />
<br />
//M1_B- à 1 puis 0<br />
PORTC=(1<<PC4);<br />
_delay_ms(5);<br />
PORTC=(0<<PC4);<br />
<br />
//M1_A- à 1 puis 0<br />
PORTC=(1<<PC6);<br />
_delay_ms(5);<br />
PORTC=(0<<PC6);<br />
<br />
//M1_B+ à 1 puis 0<br />
PORTC=(1<<PC5);<br />
_delay_ms(5);<br />
PORTC=(0<<PC5);<br />
}<br />
}<br />
</syntaxhighlight>Pour aller dans l'autre sens, il suffit d'inverser le sens des broches de sorties :<syntaxhighlight lang="c"><br />
void stepper_right(void){<br />
for(int i = 0; i<=100; i++){<br />
//M1_B+ à 1 puis 0<br />
PORTC=(1<<PC5);<br />
_delay_ms(5);<br />
PORTC=(0<<PC5);<br />
<br />
//M1_A- à 1 puis 0<br />
PORTC=(1<<PC6);<br />
_delay_ms(5);<br />
PORTC=(0<<PC6);<br />
<br />
//M1_B- à 1 puis 0<br />
PORTC=(1<<PC4);<br />
_delay_ms(5);<br />
PORTC=(0<<PC4);<br />
<br />
//M1_A+ à 1 puis 0<br />
PORTC=(1<<PC7);<br />
_delay_ms(5);<br />
PORTC=(0<<PC7);<br />
}<br />
}<br />
</syntaxhighlight>Voici ma documentation :<br />
<br />
- '''https://www.tme.eu/fr/news/library-articles/page/41861/Moteur-pas-a-pas-types-et-exemples-dapplications-des-moteurs-pas-a-pas/'''<br />
<br />
- '''https://www.youtube.com/watch?v=655p1N9tSKQ'''<br />
<br />
- '''http://www.micropython.fr/modules_center/moteurs/pas_a_pas/moteur_pap/#le-principe-dun-moteur-pas-a-pas'''<br />
<br />
== Programmation de la communication Bluetooth : ==<br />
La partie Bluetooth était un de nos objectifs du début de projet afin de contrôler la voiture à distance et grâce à une application. Pour cela, j’ai dû refaire des recherches sur le sujet afin d’avancer. J’ai donc dû regarder la documentation de l’atmega16u2 et des cours d’autres universités pour bien comprendre. C’est alors que j’ai compris que la communication série UART permettrait de répondre à mes besoins. J’ai donc écrit une fonction qui permet l’initialisation de la communication série UART en activant la transmission (TX) et la réception (RX). Ensuite dans cette même fonction j’ai dû définir le format de la trame, elle est donc composée de 8 bits, c’est-à-dire un octet avec un bit d’arrêt.<br />
<br />
Nous n’avons besoin que de recevoir des informations sur la communication série UART, pas d’en envoyer. C’est pour cela que j’ai donc dû faire une seconde fonction permettant de recevoir les informations de l’application sur le port RX de l’Atmega16U2.<br />
<br />
Voici le code de la communication UART :<syntaxhighlight lang="c"><br />
/////////////////////////////////////////<br />
/// INITIALISATION COMMUNICATION UART ///<br />
/////////////////////////////////////////<br />
<br />
void UART_init(unsigned int baud_rate){<br />
// Calculer la valeur de UBRR en fonction du baud_rate<br />
unsigned int ubrr_val = FREQ_CPU / (16UL * baud_rate) - 1; <br />
// Définir les valeurs UBRRH et UBRRL<br />
UBRRH = (unsigned char)(ubrr_val >> 8);<br />
UBRRL = (unsigned char)ubrr_val;<br />
// Activer la transmission et la réception<br />
UCSRB = (1 << TXEN) | (1 << RXEN);<br />
// Définir le format de trame: 8 bits de données, 1 bit d'arrêt<br />
UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0);<br />
}<br />
<br />
/////////////////////////////////////<br />
/// RECUPERATION DES DONNEES UART ///<br />
/////////////////////////////////////<br />
<br />
int UART_receiver(void) {<br />
// Attendre que le tampon d'entrée soit plein<br />
while (!(UCSRA & (1 << RXC)));<br />
// Lire le caractère du tampon d'entrée<br />
return UDR;<br />
}<br />
</syntaxhighlight>Cette fonction ne pouvait pas être testée car l’antenne Bluetooth n’est pas présente sur la carte électronique de la voiture. Cependant, ces recherches m’ont permis de mieux comprendre la communication série UART que j’avais mal compris lors des TP du semestre 6.<br />
<br />
== Programmation USB/LUFA ==<br />
Pour cette partie de la programmation via USB/LUFA, j’ai repris le fichier utilisé lors de notre cours de TPI. Ce fichier avait quelques modifications à faire avant d’être utilisé. Tout d’abord, j’ai dû changer les ID Vendor et Product de la carte électronique car celle utilisée maintenant n’est pas la même que pendant le cours de TPI. Normalement grâce à la commande "'''''lsusb -vvv"''''', on peut trouver le microcontrôleur utilisé et ces ID, mais nous les avions déjà noté auparavant. On trouve alors :<br />
<br />
- ID VENDOR : 0x03EB <br />
<br />
- ID PRODUCT : 0x2FEF<br />
<br />
Ensuite, des modifications étaient à faire sur les fichiers du descripteur. En effet, celui-ci avait du code qui faisait référence au joystick utilisé en TPI. J’ai donc juste gardé les fonctions qui faisaient référence aux actionneurs.<br />
<br />
De plus, afin de pouvoir gérer les actionneurs, j’ai préparé en amont comment ils seront activés grâce aux octets à envoyer. Cependant, j’ai décidé d’utiliser qu’un seul octet de contrôle car 2 était beaucoup trop pour les simples fonctions que nous avions. Nous avons alors un seul octet ayant chaque bit qui représente une fonction de contrôle de la voiture avec de droite à gauche :<br />
<br />
- Bit 0 à Allume la LED<br />
<br />
- Bit 1 à Fait avancer la voiture<br />
<br />
- Bit 2 à Fait reculer la voiture<br />
<br />
- Bit 3 à Fait tourner dans un sens la voiture<br />
<br />
- Bit 4 à Fait tourner dans l’autre sens la voiture<br />
<br />
Par exemple, le schéma ci-dessous permet d’allumer la LED de la voiture, de la faire reculer, et en même temps de la faire tourner dans un sens :<br />
[[Fichier:USB exemple.png|alt=Exemple d'octet|centré|vignette|Exemple d'octet ]]<br />
Voici d'ailleurs le code du programme traitant chaque bits de l'octet pour éxécuter les fonctions voulues : <syntaxhighlight lang="c"><br />
void actionneurs_gestion(void){<br />
Endpoint_SelectEndpoint(ACT_EPADDR);<br />
if (Endpoint_IsOUTReceived()){<br />
if (Endpoint_IsReadWriteAllowed()){<br />
uint16_t ACT_Report = Endpoint_Read_16_LE();<br />
<br />
//CONTROLE DES LEDS<br />
if(ACT_Report & (1<<0))<br />
led_on();<br />
else <br />
led_off();<br />
<br />
//CONTROLE DU MOTEUR DC<br />
if(ACT_Report & (1<<1))<br />
move_forwards();<br />
else if(ACT_Report & (1<<2))<br />
move_backwards(); <br />
else<br />
stop();<br />
<br />
//CONTROLE DU MOTEUR PAS A PAS<br />
if(ACT_Report & (1<<3))<br />
stepper_left();<br />
else if(ACT_Report & (1<<4))<br />
stepper_right();<br />
}<br />
/* Handshake the OUT Endpoint - clear endpoint and ready for next report */<br />
Endpoint_ClearOUT();<br />
}<br />
}<br />
</syntaxhighlight>Enfin, nous avons juste à envoyer l’octet de notre choix afin de gérer comme on le veut les actionneurs. <br />
<br />
En retravaillant sur cette partie, j’ai mieux compris le fonctionnement de la libusb que je n’avais pas beaucoup compris lors du TPI. J’ai pu me documenter sur le sujet en faisant beaucoup de recherche et même d’apprendre des nouvelles façons de travailler avec le langage C et d’avoir une meilleure syntaxe de programmation.</div>Ncazin