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

SE4Binome2025-1

2026-01-24T11:48:13Z

Abiernac :

= Shield Arduino =
== Hardware ==
Afin de tester notre futur carte réseau, nous avons fait un shield d'arduino qui prendra le rôle de la carte mère.

=== Schématique ===
Nous nous sommes évidemment aidés de la datasheet de l'atmega328p ainsi que celle de l'arduino uno afin de sélectionner les bon pins.
[[Fichier:Atmel-7810-Automotive-Microcontrollers-ATmega328P Datasheet.pdf|centré|vignette|Datasheet ATmega328p]]
[[Fichier:A000066-datasheet.pdf|centré|vignette|Datasheet Arduino Uno R3]]
Plus précisément nous nous sommes inspirés très fortement du schéma page 10 de la datasheet de l'arduino :
[[Fichier:Screenshot 2025-11-07 11-08-46.png|centré|vignette|Schéma pinouts]]
Nous sommes donc parti de l'exemple fourni par Mr Redon. Mais nous avons utilisé une template disponible dans kicad permettant de créer des shields d'arduino Uno R3.[[Fichier:Tyetyuy.png|vignette|Schématique shield arduino|centré|438x438px]]
=== Routage ===
Au niveau du routage, nous avons tenté de faire simple (sans trop abuser des vias). Nous avons positionné le lecteur de carte SD au bord de la carte afin de ne pas avoir de problèmes avec d'autres composants lorsque nous voudrons mettre ou enlever la carte SD.
[[Fichier:Routage shield arduino.png|vignette|Routage shield arduino|centré|434x434px]]

===Soudage===
La schématique et le routage terminés, nous avons soudé les différents pins permettant de connecter la carte shield à l'arduino, le reste n'étant pas forcément utile pour le moment (il est important de noter que notre shield est arrivé avec des composants pré-soudés).
[[Fichier:Shield soudage de base .jpg|centré|vignette]]

===Tests===
====Leds====

Il faudra ensuite faire des test d'allumage des leds, afin de vérifier le bon fonctionnement du shield
[[Fichier:VID leds.mp4|centré|vignette]]

Les leds fonctionnent à merveille.

====Carte SD====

Nous vérifions maintenant la carte SD (même si elle nous sera inutile pour notre projet).

Nous utilisons le programme fourni par arduino qui permet de récupérer les informations de la carte SD.
[[Fichier:Test sd card.png|centré|vignette]]
La carte SD est bien identifié, le lecteur de carte fonctionne donc normalement.

== Software ==

=== Ordonnanceur basique ===
La première étape consiste à définir la structure d'un process, il sera composé :

*D'un pointeur de pile
*De l'adresse de la fonction
*D'un temps de sommeil
*D'un état : 0 pour en cours et 1 pour terminé ou vide

Ces deux derniers points nous serviront plus tard.<syntaxhighlight lang="c" line="1">
typedef struct {
uint16_t stackPointer;
void (*functionAddress)(void);
int sleep_time;
int state;
} process;

</syntaxhighlight>On initialise donc notre tableau de processus de la façon suivante : <syntaxhighlight lang="c" line="1">
process Tasks_list[NBTASKS] = {
{0, led1_blink, 0,0},
...
};

</syntaxhighlight>Concernant les fonction liées aux leds, nous utilisons une simple boucle while contenant un changement d'état. <syntaxhighlight lang="c" line="1">
void led_init() {
...
}
void led1_blink() {
while(1) {
PORTC ^= (1<<PLED1);
_delay_ms(100);
}
}
void led2_blink() {
...
</syntaxhighlight>La fonction init_stackPointer_tasks() permet de diviser la pile "réel" en plusieurs piles de taille fixe pour chacun des processus. Ces sous piles commencent à la position FIRST_STACK_POSITION, afin de ne pas réécrire par dessus des données. Toutes les sous piles disposent d'une même taille de pile STACK_LENGTH. La fonction init_piles() initialise correctement la pile avec le tableau de processus si le processus est actif. Elle sauvegarde d'abord le pointeur de pile actuel (pas celui du processus) afin de revenir là où elle en était. Ensuite l'adresse de retour de la fonction (sur 16 bits) dans la pile de la tâche, sauvegarde les registres, puis restaure le pointeur de pile initial.<syntaxhighlight lang="c" line="1">
void init_stackPointer_tasks(int Cprocess) { //initialise le pointer de pile
if(Tasks_list[Cprocess].state == 0) {
Tasks_list[Cprocess].stackPointer = FIRST_STACK_POSITION - (Cprocess * STACK_LENGTH);
}
}

void init_piles(int Cprocess){ //initilalise la pile
if(Tasks_list[Cprocess].state == 0) {
int save = SP;
SP = Tasks_list[Cprocess].stackPointer;
uint16_t address = (uint16_t)Tasks_list[Cprocess].functionAddress;
asm volatile("push %0" : : "r" (address & 0x00ff) );
asm volatile("push %0" : : "r" ((address & 0xff00)>>8) );
SAVE_REGISTERS();
Tasks_list[Cprocess].stackPointer = SP;
SP = save;
}
}

</syntaxhighlight>Le scheduler permet de passer à la tâche suivante<syntaxhighlight lang="c" line="1">
void scheduler() {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}

</syntaxhighlight>L'atmega328p ne dispose pas de fonction en assembleur permettant de push ou de pop tout les registres, on doit donc en créer par nous mêmes. On défini alors les macros suivantes : <syntaxhighlight lang="c" line="1">
#define SAVE_REGISTERS() \
asm volatile ( \
"push r0 \n\t" \
...\
)

#define RESTORE_REGISTERS() \
asm volatile ( \
"pop r31 \n\t" \
...\
)

</syntaxhighlight>L'ISR gère les interruptions, en commençant par sauvegarder l'état de la pile ainsi que le stack pointeur propre au processus qui s'interrompt. L'appel au schedruler permet de changer de processus pour cela il faut restaurer le stack pointer propre au nouveau processus actif et de la pile liée à ce processus. La dernière ligne arrête l'ISR.<syntaxhighlight lang="c" line="1">
ISR(TIMER1_COMPA_vect, ISR_NAKED) {
SAVE_REGISTERS();
Tasks_list[Current_task].stackPointer = SP;
scheduler();
SP = Tasks_list[Current_task].stackPointer;
RESTORE_REGISTERS();
asm volatile("reti");
}
</syntaxhighlight>

==== Test ====

Les processus de clignotement de leds ont tous un délai d'attente différent, l'interruption se produit toutes les millisecondes. On obtient ceci :[[Fichier:Ordonnanceur basique.mp4|centré|vignette]]Il est intéressant de remarqué que la vitesse à laquelle les leds changent d'état ne correspond pas au délai qui leur a été donnée. Cela parait logique puisque l'interruption met la fonction _delay_ms en pause, ainsi la vitesse se voit divisé par le nombre de processus actif.

=== Ordonnanceur plus complexe ===

==== Ajout d'un système d'endormissement des processus ====

La fonction wait va permettre d'endormir un processus, elle va donné un temps de sommeil au processus puis lancer une interruption (car on veut changer de processus directement après que le précédent ait été endormi).<syntaxhighlight lang="c" line="1">
void wait(int time) { // met un process en veille pour une durée donné
// valeur max de time 32000 car int sur atmega328p code sur 16 bits donc 32000 max
cli();
Tasks_list[Current_task].sleep_time = time;
TCNT1=0;
sei();
TIMER1_COMPA_vect();

</syntaxhighlight>Pour vérifier si un processus a besoin d'être lancé, on ajoute une boucle while dans le scheduler afin de vérifier si il y a un temps de sommeil. Le scheduler va aussi servir à diminuer le temps de sommeil de tout les processus (avec un minimum de 0).<syntaxhighlight lang="c" line="1">
void scheduler() {
for (int i=0 ; i<NBTASKS ; i++) {
if (Tasks_list[i].sleep_time - SLEEP_DEC < 0) {
Tasks_list[i].sleep_time = 0;
} else {
Tasks_list[i].sleep_time -= SLEEP_DEC;
}
}

do {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}
} while (Tasks_list[Current_task].sleep_time > 0);
}

</syntaxhighlight>
====Tableau dynamique des tâches====

En premier lieu on va initialiser les état de tout les cases du tableau de processus. On choisit 1 la case est vide, 0 sinon.<syntaxhighlight lang="c" line="1">
void init_state() { //initialise state
for (int i= 0; i<NBTASKS; i++) {
if (Tasks_list[i].functionAddress == NULL) {
Tasks_list[i].state = 1;
}
else {
Tasks_list[i].state = 0;
}
}
}
</syntaxhighlight>Nous avons programmé deux fonction d'arrêt et une fonction d'ajout de processus :

* finish : stop le processus en cours et le supprime de tableau, puis lance une interruption

* kill : stop un processus donné et le supprime du tableau

* add : ajoute un processus sur la première case vide du tableau, initialise son pointeur de position et sa pile.

Pour finish et kill, on met le temps de sommeil à 0 au cas où on arrête un processus endormi. C'est une mesure de sécurité pour finish, mais une obligation pour kill.<syntaxhighlight lang="c" line="1">
void finish() { //supprime un process lorsque celui-ci est terminé
cli();
Tasks_list[Current_task].state =1;
Tasks_list[Current_task].sleep_time = 0;
Tasks_list[Current_task].functionAddress = NULL;
TCNT1=0;
sei();
TIMER1_COMPA_vect();
}

void kill(void (*function)(void)) { //tue le process passé en paramètre
cli();
for(int i = 0; i<NBTASKS; i++) {
if(Tasks_list[i].functionAddress == function) {
Tasks_list[i].state =1;
Tasks_list[i].sleep_time = 0;
Tasks_list[i].functionAddress = NULL;
}
}
sei();
}

void add(void (*newFunction)(void)) { //ajoute un process
cli();
int i =0;
while(Tasks_list[i].state != 1) {
i++;
}
Tasks_list[i].functionAddress = newFunction;
Tasks_list[i].state = 0;
init_stackPointer_tasks(i);
init_piles(i);

sei();

}
</syntaxhighlight>Il suffit maintenant de modifier le scheduler afin de ne pas prendre les processus terminé, puis utiliser add, finish et kill dans les fonctions choisies.

==== Test ====
Pour tester les fonction add et finish, on réalise le test suivant :

* on créer un process qui ajoute le process led2_blink (avec add) au bout d'un certain temps
* le process led2_blink s'arrête (avec finish) au bout de 20 changement d'état (c'est à dire 10 clignotement).

On obtient le résultat escompté qui est le suivant :[[Fichier:Demo fonction add et finish.mp4|centré|vignette]]
====Lecture et écriture sur le port série====
Afin de lire et écrire sur le port série, on utilise les fonctions USART_Init, USART_Transmit et USART_Receive vu en cours de microP l'année précédente. Le but sera donc d'écrire le message qui vient d'être reçu, on utilise donc le processus suivant :<syntaxhighlight lang="c" line="1">
void Serial_Message(){
unsigned char data;
while(1){
data = USART_Receive();
USART_Transmit(data);
}
}
</syntaxhighlight>

==== Test ====

Pour tester notre processus de communication, on utilise minicom.[[Fichier:Test lecture et écriture port série.mp4|centré|vignette]]On notera que si la période entre les interruptions est trop élevé, certains caractères ne seront pas lus.

====Afficheur 7 segments====
<syntaxhighlight lang="c" line="1">
void seven_seg() {
while (1) {
spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x7E);
spi_echange(0b1101111);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);

spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x76);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);
}
}
</syntaxhighlight>Le processus seven_seg est ajouté au tableau des processus. Avant d'échanger en spi il faut activer la communication, et la désactiver après l'échange. La ligne 4 permet de sélectionner le 7 seg sur lequel on souhaite modifier l'affichage. La ligne 5 permet d'afficher le chiffre 9. Enfin la ligne 11 permet de clear le display. Voir tableau ci-dessous.
[[Fichier:Tab 7 seg sparkfun.png|centré|vignette]]
<syntaxhighlight lang="c" line="1">
void spi_init(void) { // Initialisation du bus SPI
SPI_DDR |= (1<<SPI_MOSI)|(1<<SPI_SCK); // Définition des sorties
SPI_DDR &= ~(1<<SPI_MISO); // Définition de l'entrée
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1); // Activation SPI (SPE) en état maître (MSTR)
// horloge F_CPU/64 (SPR1=1,SPR0=0)
SPI_DDR |= (1<<CS1) | (1<<CS4);;
DDRD |= (1<<CS5) | (1<<CS6);
DDRC |= (1<<CS2) | (1<<CS3);
}

void spi_activer(uint16_t port, uint8_t cs) { // Activer le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg &= ~(1<<cs); // Ligne SS à l'état bas
}

void spi_desactiver(uint16_t port, uint8_t cs) { // Désactiver le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg |= (1<<cs); // Ligne SS à l'état haut
}

uint8_t spi_echange(uint8_t envoi) { // Communication sur le bus SPI
SPDR = envoi; // Octet a envoyer
while(!(SPSR & (1<<SPIF))); // Attente fin envoi (drapeau SPIF du statut)
return SPDR; // Octet reçu
}

</syntaxhighlight>Afin de rendre nos fonctions les plus réutilisables possibles nous avons passer en paramètre le port ainsi que le CS qui correspond au slave select. Le type réel du port est volatile uint8* cependant le compilateur n'accepte que le uint16* ce qui explique le cast un peu étrange.

=====Implémentation=====
[[Fichier:Video7segvideo.mp4|vignette|centré]]L'implémentation correspond à nos attentes, seul un 7 seg affiche le chiffre 9.

====Choix du processus sur le port série====
Afin de pouvoir démontrer le bon fonctionnement de la partie dynamique, on décide de pouvoir ajouter et tuer des processus à partir des touches du clavier. On utilisera donc les fonction de l'USART défini plus au au travers de la fonction suivante :<syntaxhighlight lang="c">
void call_process() {
unsigned char data;
while(1) {
data = USART_Receive();
if(data == '1') {
add(led1_blink);
}
...
else if(data == '6') {
kill(led1_blink);
}
...
USART_Transmit(data);
}
}

</syntaxhighlight>On remarquera que c'est une sorte d'amélioration de la fonction Serial_Message vu plus haut.

Cette fonction aura la fonction de process de base, toujours présent dans l'ordonnaceur.

==== Démonstation ====
[[Fichier:Process via USART.mp4|centré|vignette]]

Ici on lance les processus ledN_blink avec les touches 1 à 5 et on les tues avec les touches 6 à 0. Pour le 7 segments, on l'ajoute avec s et le tue avec d.

=Carte Réseau=
Lors de la répartition des tâches, nous avons opté pour la carte réseau.
==Description==
Le sujet nous permettait de choisir parmi plusieurs microcontrôleurs. Nous avons retenu l’ATmega32U4, qui nous semble représenter un juste milieu entre l’ATmega16U2 et l’AT90USB. Cependant ce choix se révélera peu judicieux par la suite du projet. En effet la capacité de la mémoire est un point clé pour une carte réseau qui gère des paquets souvent de tailles conséquentes.
==Hardware==
Notre carte intègre des LED permettant d’afficher différents états de communication (que nous définirons ultérieurement).

À la demande de M. Redon, nous avons ajouté un MAX232 ainsi que des connecteurs DB9 et DB25. Nous savons que ces éléments pourront être utiles et servirons à utiliser la carte sur un terminal.

En dehors de ça, la carte reste assez basique car son composant principal reste l'ATmega.
===Schématique===
les broches PF n'étant pas utilisé, on les branches à un connecteur 6x1, notre carte pourra donc être utiliser pour d'autre projet si nécéssaire.

On fait le choix d'utiliser 5 leds pour la connections, 1 led de power et 1 pour la connection ISP.[[Fichier:Schématique CReseau.png|vignette|540x540px|centré]]
===Routage===
[[Fichier:Routage Creseau.png|vignette|521x521px|centré]]Après avoir soudé les composants principaux, il est temps de passer à la partie programmation de la carte.

==Programmation==

Notre carte utilisant un connecteur USB, nous allons donc faire passer notre carte pour une carte réseau en utilisant la demo RNDIS de la LUFA.

Il est important de noter que nous avons choisi un Atmega32u4. Ainsi des modification devrons être apporté à la taille des paquets ethernet et sur le choix des protocoles.

===Protocoles impémentés===

La demo RNDISEthernet de la LUFA inclut les protocole suivant

* ARP : Résolution d'adresses MAC.
* IP : Gestion des paquets IPv4.
* ICMP : Messages de contrôle (ping).
* TCP : Communication fiable (exemple : serveur TCP).
* UDP : Communication non fiable (exemple : serveur UDP).
* DHCP : Attribution dynamique d'adresse IP.

Aussi, on remarquera que la démo utilise un modèle en quatre couche : Le modèle TCP/IP.

le sujet nous propose trois possibilité :

* viser Ethernet
* viser UDP
* viser TCP

En regardant ce qui à été fait les années précédentes, on a remarqué que les groupes partaient principalement sur la première option. Nous nous avons décidé de viser UDP.

Ainsi, afin de d'alléger notre code pour le faire rentrer dans notre carte, nous avons choisi de ne pas inclure le protocole TCP et de modifier la taille max de paquets ethernet à 400 octets.

Il nous restera donc de l'espace pour recevoir des paquets Ethernet :<syntaxhighlight>
avr-size --mcu=atmega32u4 --format=avr RNDISEthernet.elf
AVR Memory Usage
----------------
Device: atmega32u4

Program: 9434 bytes (28.8% Full)
(.text + .data + .bootloader)

Data: 1037 bytes (40.5% Full)
(.data + .bss + .noinit)
</syntaxhighlight>Une fois la LUFA réduite et flashé, on donne une adresse IP à notre interface avec ip link eth2 up et ip address add 10.0.0.1/24 dev eth2. on test un ping sur l'adresse IP de la carte (10.0.0.2).[[Fichier:Ping creseau.mp4|centré|vignette]]Le premier test que nous décidons de faire, afin de vérifié notre compréhension du code de la LUFA, est de faire clignoter une LED si la carte reçoit un paquet ethernet. Pour cela on ajoute l'allumage de la LED dans la fonction EthernetTask du fichier principal (RNDISEthernet.c) :[[Fichier:Ping allume led.mov|vignette|La led s'éteint à chaque ping reçue|centré]]

===Création du protocole===

En plus de pouvoir communiquer, notre carte dois être capable d'effectuer 3 fonction.

On décide de créer notre propre protocole ProtocolAntique décrit ci-dessous :

ProtocolAntique (256 octets)

Entete du ProtocolAntique (3 octets)

operation (1 octet)

longueur (1 octet)

numero (1 octet)

Contenu du ProtocolAntique (256 - 3 = 253 octets)

Exemples :

LS :

Carte reseau :

-operation = 0x01 // requete LS

-longueur = [0-252]

-numero = 0 // la requete n'est pas fragmentée

-contenu // chemin ou effectuer le ls

Serveur :

-operation = 0x11 // reponse au LS

-longueur = [0-252]

-numero = [0-255] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // nom de fichier ou rien si numero = 0

READ :

Carte reseau :

-operation = 0x02 // requete READ

-longueur = [0-252]

-numero = 0 // la requete n'est pas fragmentée

-contenu // chemin/nom_fichier

Serveur :

-operation = 0x12 // reponse au READ

-longueur = [0-252]

-numero = [0-255] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // contenu d'une ligne ou rien si numero = 0

WRITE :

Carte reseau :

-operation = 0x03 // requete WRITE creation du fichier

-longueur = [0-252]

-numero = 0 // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // Chemin pour ouvrir le fichier avce le nom du fichier : chemin/fichier

Carte reseau :

-operation = 0x13 // requete WRITE ecriture dans le fichier

-longueur = [0-252]

-numero = [1-252] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // ligne a ecrire

Carte reseau :

-operation = 0x23 // requete WRITE fin

-longueur = [0-252]

-numero = 0 // 0 dernier paquet

-contenu // rien

Comme nous avons choisit de viser UDP, le protocole doit pocédé un numéro de port, on choisit un numéro supérieur à 1023 pour ne pas devoir passer en root, Le port choisi est 3333.

Dans le programme UDP.c on peut maintenant inclure notre protocole de la façon suivante :<syntaxhighlight lang="c">
switch (SwapEndian_16(UDPHeaderIN->DestinationPort))
{
/*
case UDP_PORT_DHCP_REQUEST:
RetSize = DHCP_ProcessDHCPPacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;
*/
case UDP_PORT_PROTOCOL_ANTIQUE:
RetSize = ProtocolAntique_ProcessProtocolAntiquePacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;

</syntaxhighlight>

=== Partie serveur ===
Lorsque la carte mère a besoin de faire une action (ls, read, write) sur l'ordinateur qui est connecté en USB via la carte réseau elle transmet son besoin à la carte réseau. Cette dernière créer un requête UDP qui encapsule notre protocole (ProtocolAntique) et la transmet donc au PC. Sur ce dernier un serveur doit donc fonctionner afin de recevoir les rêquetes de la carte réseau, les traiter et y répondre. Cette partie est donc consacrée au code ainsi qu'aux tests du serveur.

==== Code du serveur ====
Pour pouvoir fonctionner correctement le serveur doit initialiser une socket UDP et ensuite doit lancer un fonctionne qui boucle indéfiniment afin de recevoir chaque message UDP. Cette partie n'a pas été codé par nous et est trouvable sur rex.plil.fr (Département IMA -> support de cours de la programmation réseau -> exemple de serveur 2/2). Il en est de même du code la fonction pour envoyer un message UDP qui est trouvable au même endroit section exemple de client 2/2.

La carte réseau est toujours à l'initiative des requêtes, par conséquent le serveur commence par recevoir un requête et la traiter. Pour ce faire à chaque requête reçue par la fonction boucleServeurUDP la fonction traitementMessageUDP est appelée.<syntaxhighlight lang="c" line="1">
int traitementMessageUDP (unsigned char* message, int nboctets);
</syntaxhighlight>Cette fonction s'occupe d'extraire la partie opération de l'entête de protocolAntique et d'appeler la fonction de traitement correspondante à l'opération
{| class="wikitable"
!Opération
!Requête
!Fonction appelée
|-
|0x01
|LS
|void traitement_ls (unsigned char*);
|-
|0x02
|READ
|void traitement_read (unsigned char*);
|-
|0x03
|WRITE (début)
|void traitement_write (unsigned char*);
|-
|0x13
|WRITE (données et fin)
|void traitement_write (unsigned char*);
|}

===== Traitement LS =====
La fonction traitement_ls commence par récupérer le chemin (relatif ou absolu) où effectuer le LS. Si la section longueur de l'entête de la requête est à 0 alors le chemin par défaut est celui depuis où le serveur à été lancé. Le code pour récupérer le chemin est le suivant :<syntaxhighlight lang="c" line="1">
unsigned char chemin[longueur+1];
for (int i=0 ; i<longueur ; i++) {
chemin[i] = message[i+3]; // Recuperation du chemin
}
chemin[longueur] = '\0';
</syntaxhighlight>Par la suite le dossier est correspondant au chemin est ouvert via la fonction opendir puis chaque entrée du dossier est récupérée et engendre un message de réponse du serveur (un message par entrée).<syntaxhighlight lang="c" line="1">
while ((entree = readdir(dossier)) != NULL) {
// Message UDP pour chaque entree
strcpy(contenu, entree->d_name);
printf(" %s ", contenu);
reponse[OPERATION] = REPONSE_LS;
reponse[LONGUEUR] = strlen(contenu);
reponse[NUMERO] = num++;
for (int i=0 ; i<reponse[LONGUEUR] ; i++) {
reponse[i+3] = contenu[i];
}
messageUDP(IP_CARTE, PORT_CARTE, (unsigned char *)reponse, (int)reponse[LONGUEUR] + LONGUEUR_ENTETE);
}
</syntaxhighlight>OPERATION est la premiére section et vaut donc 0, LONGUEUR 2 et NUMERO 3. OPERATION est une réponse à un LS donc 0x11, LONGUEUR dépend de l'entrée du dossier et NUMERO augmente de 1 à chaque entrée. Enfin on remplie la requête du nom de l'entrée et on envoie le message.

Enfin une fois tous les entrées envoyées on envoie un dernier message UDP de type reponse_LS de longueur 0 et de numéro 0 afin d'indiquer que la transmission est terminée et ce correctement.

===== Traitement READ =====
Cette requête est très proche de celle du LS. On commence par récupérer le chemin avec le nom du fichier de la même façon que pour le LS. Cependant ici si le message ne contient pas de chemin aucun traitement ne sera effectué. Pour ouvrir le fichier on utilise la fonction fopen. Chaque ligne, récupérée via fgets, engendre une réponse UDP formulée de la même façon que pour les entrées de dossier. Evidemment l'opération est de type réponse read soit 0x12. Enfin un message similaire de fin de transmission est envoyé seulement si il n'y a pas eu d'erreur et que la dernière ligne à été lue.

===== Traitement WRITE =====
Cette requête est un peu plus complexe à gérer niveau serveur par conséquent que je vais commencer par décrire le principe de la fonction.

* La carte réseau envoie un message de type début de write (OPERATION 0x03) avec le chemin et nom du fichier que le serveur va récupérer et mémoriser.

* La carte réseau envoie un massage pour chaque ligne à écrite (OPERATION 0x13). Le serveur va vérifier si la section NUMERO des entêtes se suivent afin de s'assurer que aucun message n'est été perdu.

* La carte réseau envoie un message de type fin de write (OPERATION 0x013) mais de numéro 0. Le serveur indique que tout s'est bien passé en envoyant une réponse au write (OPERATION 0x23) donc le contenu est 0x00.
* Si un message a été perdu un message d'erreur est envoyé de la par du serveur (OPERATION 0x23) de contenu 0x01.

La récupération du contenu de la requête est du même type que celle du LS. Les messages de retour sont construits de la même façon que pour le message de retour du LS. Enfin on utilise fopen une nouvelle fois pour ouvrir le fichier, fwrite pour y écrire et fclose pour le fermer.

==== Préparation du test ====
Avant de pouvoir tester notre serveur avec la carte réseau (ce qui n'aura jamais été fait car la carte réseau n'envoie rien) nous avons souhaité validé le fonctionnement du serveur en simulant des requêtes de la carte réseau. On voit ce que le serveur fait via des printf et en créant un autre serveur (plus rudimentaire) on peut vérifier que le serveur répond correctement. Sur notre git le dossier testUDP est consacré à cette phase de tests.

* Les requêtes simulées de la carte réseau sont envoyées sur l'IP loopback de la machine et sur le port du serveur (ici 4242)
* Le serveur écoute le port serveur (4242) et répond en loopback sur le port du serveur qui simule la carte (ici 3333)
* Le serveur qui simule la carte écoute le port 3333

On lance ces différents serveurs et les requêtes via les commandes du fichiers fonctionnement.txt de notre git.

==== Tests ====
Le test est réalisé via 3 commandes :

* LS sans chemin
* WRITE de 3 lignes dans un fichier test.txt créé par la commande
* READ du fichier test.txt

[[Fichier:Test1.png|centré|vignette|Requêtes envoyées]]
[[Fichier:Test2.png|centré|vignette|Traitement du serveur]]
[[Fichier:Test3.png|centré|vignette|Réponse reçu du serveur]]On peut constater que les tests fonctionnent. En effet le serveur a envoyé 9 res ls (8 entrées + fin de transmissions), 1 res write (fin d'écriture correcte) et 6 res read (5 lignes + 1 fin de transmissions).

Enfin on décide de tester la réception des paquets UDP, on fait à nouveau clignoter une led quand un paquet UDP et reçu. Ici on envoi la réponse d'un LS, d'où la reception de plusieurs paquets:
[[Fichier:Test udp.mp4|centré|vignette]]
== Conclusion ==
La partie shield et ordonnanceur est finie et testée. La carte réseau n'a pas pu être finie par manque de temps. En faisant allumer une LED lorsqu'elle reçoit une trame Ethernet, UDP, STMP nous avons constaté qu'elle reçoit correctement ces protocoles. Cependant lorsque que nous avons voulu modifier la LUFA pour qu'une LED en plus s'allume lorsque UDP contient protocole antique cela ne fonctionnait pas. La carte ne trouvait jamais le protocole Antique. La communication avec la carte mère (shield) n'a pas été faite par manque de temps (cependant la communication SPI est vérifiée à l'étape de l'ordonnanceur). Le serveur côté PC qui doit communiquer avec la carte réseau est fini et testé.

Notre problème peut venir du fait que l'atmega32u4 n'a pas assez de mémoire. Il ne faut donc pas choisir ce micro contrôleur pour ce projet mais un avec plus de mémoire.

SE4Binome2025-1

2026-01-24T11:32:56Z

Abiernac :

= Shield Arduino =
== Hardware ==
Afin de tester notre futur carte réseau, nous avons fait un shield d'arduino qui prendra le rôle de la carte mère.

=== Schématique ===
Nous nous sommes évidemment aidés de la datasheet de l'atmega328p ainsi que celle de l'arduino uno afin de sélectionner les bon pins.
[[Fichier:Atmel-7810-Automotive-Microcontrollers-ATmega328P Datasheet.pdf|centré|vignette|Datasheet ATmega328p]]
[[Fichier:A000066-datasheet.pdf|centré|vignette|Datasheet Arduino Uno R3]]
Plus précisément nous nous sommes inspirés très fortement du schéma page 10 de la datasheet de l'arduino :
[[Fichier:Screenshot 2025-11-07 11-08-46.png|centré|vignette|Schéma pinouts]]
Nous sommes donc parti de l'exemple fourni par Mr Redon. Mais nous avons utilisé une template disponible dans kicad permettant de créer des shields d'arduino Uno R3.[[Fichier:Tyetyuy.png|vignette|Schématique shield arduino|centré|438x438px]]
=== Routage ===
Au niveau du routage, nous avons tenté de faire simple (sans trop abuser des vias). Nous avons positionné le lecteur de carte SD au bord de la carte afin de ne pas avoir de problèmes avec d'autres composants lorsque nous voudrons mettre ou enlever la carte SD.
[[Fichier:Routage shield arduino.png|vignette|Routage shield arduino|centré|434x434px]]

===Soudage===
La schématique et le routage terminés, nous avons soudé les différents pins permettant de connecter la carte shield à l'arduino, le reste n'étant pas forcément utile pour le moment (il est important de noter que notre shield est arrivé avec des composants pré-soudés).
[[Fichier:Shield soudage de base .jpg|centré|vignette]]

===Tests===
====Leds====

Il faudra ensuite faire des test d'allumage des leds, afin de vérifier le bon fonctionnement du shield
[[Fichier:VID leds.mp4|centré|vignette]]

Les leds fonctionnent à merveille.

====Carte SD====

Nous vérifions maintenant la carte SD (même si elle nous sera inutile pour notre projet).

Nous utilisons le programme fourni par arduino qui permet de récupérer les informations de la carte SD.
[[Fichier:Test sd card.png|centré|vignette]]
La carte SD est bien identifié, le lecteur de carte fonctionne donc normalement.

== Software ==

=== Ordonnanceur basique ===
La première étape consiste à définir la structure d'un process, il sera composé :

*D'un pointeur de pile
*De l'adresse de la fonction
*D'un temps de sommeil
*D'un état : 0 pour en cours et 1 pour terminé ou vide

Ces deux derniers points nous serviront plus tard.<syntaxhighlight lang="c" line="1">
typedef struct {
uint16_t stackPointer;
void (*functionAddress)(void);
int sleep_time;
int state;
} process;

</syntaxhighlight>On initialise donc notre tableau de processus de la façon suivante : <syntaxhighlight lang="c" line="1">
process Tasks_list[NBTASKS] = {
{0, led1_blink, 0,0},
...
};

</syntaxhighlight>Concernant les fonction liées aux leds, nous utilisons une simple boucle while contenant un changement d'état. <syntaxhighlight lang="c" line="1">
void led_init() {
...
}
void led1_blink() {
while(1) {
PORTC ^= (1<<PLED1);
_delay_ms(100);
}
}
void led2_blink() {
...
</syntaxhighlight>La fonction init_stackPointer_tasks() permet de diviser la pile "réel" en plusieurs piles de taille fixe pour chacun des processus. Ces sous piles commencent à la position FIRST_STACK_POSITION, afin de ne pas réécrire par dessus des données. Toutes les sous piles disposent d'une même taille de pile STACK_LENGTH. La fonction init_piles() initialise correctement la pile avec le tableau de processus si le processus est actif. Elle sauvegarde d'abord le pointeur de pile actuel, place l'adresse de la fonction (sur 16 bits) dans la pile de la tâche, sauvegarde les registres, puis restaure le pointeur de pile initial.<syntaxhighlight lang="c" line="1">
void init_stackPointer_tasks(int Cprocess) { //initialise le pointer de pile
if(Tasks_list[Cprocess].state == 0) {
Tasks_list[Cprocess].stackPointer = FIRST_STACK_POSITION - (Cprocess * STACK_LENGTH);
}
}

void init_piles(int Cprocess){ //initilalise la pile
if(Tasks_list[Cprocess].state == 0) {
int save = SP;
SP = Tasks_list[Cprocess].stackPointer;
uint16_t address = (uint16_t)Tasks_list[Cprocess].functionAddress;
asm volatile("push %0" : : "r" (address & 0x00ff) );
asm volatile("push %0" : : "r" ((address & 0xff00)>>8) );
SAVE_REGISTERS();
Tasks_list[Cprocess].stackPointer = SP;
SP = save;
}
}

</syntaxhighlight>Le scheduler permet de passer à la tâche suivante<syntaxhighlight lang="c" line="1">
void scheduler() {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}

</syntaxhighlight>L'atmega328p ne dispose pas de fonction en assembleur permettant de push ou de pop tout les registres, on doit donc en créer par nous mêmes. On défini alors les macros suivantes : <syntaxhighlight lang="c" line="1">
#define SAVE_REGISTERS() \
asm volatile ( \
"push r0 \n\t" \
...\
)

#define RESTORE_REGISTERS() \
asm volatile ( \
"pop r31 \n\t" \
...\
)

</syntaxhighlight>L'ISR gère les interruptions, en commençant par sauvegarder l'état de la pile ainsi que le stack pointeur propre au processus qui s'interrompt. L'appel au schedruler permet de changer de processus pour cela il faut restaurer le stack pointer propre au nouveau processus actif et de la pile liée à ce processus. La dernière ligne arrête l'ISR.<syntaxhighlight lang="c" line="1">
ISR(TIMER1_COMPA_vect, ISR_NAKED) {
SAVE_REGISTERS();
Tasks_list[Current_task].stackPointer = SP;
scheduler();
SP = Tasks_list[Current_task].stackPointer;
RESTORE_REGISTERS();
asm volatile("reti");
}
</syntaxhighlight>

==== Test ====

Les processus de clignotement de leds ont tous un délai d'attente différent, l'interruption se produit toutes les millisecondes. On obtient ceci :[[Fichier:Ordonnanceur basique.mp4|centré|vignette]]Il est intéressant de remarqué que la vitesse à laquelle les leds changent d'état ne correspond pas au délai qui leur a été donnée. Cela parait logique puisque l'interruption met la fonction _delay_ms en pause, ainsi la vitesse se voit divisé par le nombre de processus actif.

=== Ordonnanceur plus complexe ===

==== Ajout d'un système d'endormissement des processus ====

La fonction wait va permettre d'endormir un processus, elle va donné un temps de sommeil au processus puis lancer une interruption (car on veut changer de processus directement après que le précédent ait été endormi).<syntaxhighlight lang="c" line="1">
void wait(int time) { // met un process en veille pour une durée donné
// valeur max de time 32000 car int sur atmega328p code sur 16 bits donc 32000 max
cli();
Tasks_list[Current_task].sleep_time = time;
TCNT1=0;
sei();
TIMER1_COMPA_vect();

</syntaxhighlight>Pour vérifier si un processus a besoin d'être lancé, on ajoute une boucle while dans le scheduler afin de vérifier si il y a un temps de sommeil. Le scheduler va aussi servir à diminuer le temps de sommeil de tout les processus (avec un minimum de 0).<syntaxhighlight lang="c" line="1">
void scheduler() {
for (int i=0 ; i<NBTASKS ; i++) {
if (Tasks_list[i].sleep_time - SLEEP_DEC < 0) {
Tasks_list[i].sleep_time = 0;
} else {
Tasks_list[i].sleep_time -= SLEEP_DEC;
}
}

do {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}
} while (Tasks_list[Current_task].sleep_time > 0);
}

</syntaxhighlight>
====Tableau dynamique des tâches====

En premier lieu on va initialiser les état de tout les cases du tableau de processus. On choisit 1 la case est vide, 0 sinon.<syntaxhighlight lang="c" line="1">
void init_state() { //initialise state
for (int i= 0; i<NBTASKS; i++) {
if (Tasks_list[i].functionAddress == NULL) {
Tasks_list[i].state = 1;
}
else {
Tasks_list[i].state = 0;
}
}
}
</syntaxhighlight>Nous avons programmé deux fonction d'arrêt et une fonction d'ajout de processus :

* finish : stop le processus en cours et le supprime de tableau, puis lance une interruption

* kill : stop un processus donné et le supprime du tableau

* add : ajoute un processus sur la première case vide du tableau, initialise son pointeur de position et sa pile.

Pour finish et kill, on met le temps de sommeil à 0 au cas où on arrête un processus endormi. C'est une mesure de sécurité pour finish, mais une obligation pour kill.<syntaxhighlight lang="c" line="1">
void finish() { //supprime un process lorsque celui-ci est terminé
cli();
Tasks_list[Current_task].state =1;
Tasks_list[Current_task].sleep_time = 0;
Tasks_list[Current_task].functionAddress = NULL;
TCNT1=0;
sei();
TIMER1_COMPA_vect();
}

void kill(void (*function)(void)) { //tue le process passé en paramètre
cli();
for(int i = 0; i<NBTASKS; i++) {
if(Tasks_list[i].functionAddress == function) {
Tasks_list[i].state =1;
Tasks_list[i].sleep_time = 0;
Tasks_list[i].functionAddress = NULL;
}
}
sei();
}

void add(void (*newFunction)(void)) { //ajoute un process
cli();
int i =0;
while(Tasks_list[i].state != 1) {
i++;
}
Tasks_list[i].functionAddress = newFunction;
Tasks_list[i].state = 0;
init_stackPointer_tasks(i);
init_piles(i);

sei();

}
</syntaxhighlight>Il suffit maintenant de modifier le scheduler afin de ne pas prendre les processus terminé, puis utiliser add, finish et kill dans les fonctions choisies.

==== Test ====
Pour tester les fonction add et finish, on réalise le test suivant :

* on créer un process qui ajoute le process led2_blink (avec add) au bout d'un certain temps
* le process led2_blink s'arrête (avec finish) au bout de 20 changement d'état (c'est à dire 10 clignotement).

On obtient le résultat escompté qui est le suivant :[[Fichier:Demo fonction add et finish.mp4|centré|vignette]]
====Lecture et écriture sur le port série====
Afin de lire et écrire sur le port série, on utilise les fonctions USART_Init, USART_Transmit et USART_Receive vu en cours de microP l'année précédente. Le but sera donc d'écrire le message qui vient d'être reçu, on utilise donc le processus suivant :<syntaxhighlight lang="c" line="1">
void Serial_Message(){
unsigned char data;
while(1){
data = USART_Receive();
USART_Transmit(data);
}
}
</syntaxhighlight>

==== Test ====

Pour tester notre processus de communication, on utilise minicom.[[Fichier:Test lecture et écriture port série.mp4|centré|vignette]]On notera que si la période entre les interruptions est trop élevé, certains caractères ne seront pas lus.

====Afficheur 7 segments====
<syntaxhighlight lang="c" line="1">
void seven_seg() {
while (1) {
spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x7E);
spi_echange(0b1101111);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);

spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x76);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);
}
}
</syntaxhighlight>Le processus seven_seg est ajouté au tableau des processus. Avant d'échanger en spi il faut activer la communication, et la désactiver après l'échange. La ligne 4 permet de sélectionner le 7 seg sur lequel on souhaite modifier l'affichage. La ligne 5 permet d'afficher le chiffre 9. Enfin la ligne 11 permet de clear le display. Voir tableau ci-dessous.
[[Fichier:Tab 7 seg sparkfun.png|centré|vignette]]
<syntaxhighlight lang="c" line="1">
void spi_init(void) { // Initialisation du bus SPI
SPI_DDR |= (1<<SPI_MOSI)|(1<<SPI_SCK); // Définition des sorties
SPI_DDR &= ~(1<<SPI_MISO); // Définition de l'entrée
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1); // Activation SPI (SPE) en état maître (MSTR)
// horloge F_CPU/64 (SPR1=1,SPR0=0)
SPI_DDR |= (1<<CS1) | (1<<CS4);;
DDRD |= (1<<CS5) | (1<<CS6);
DDRC |= (1<<CS2) | (1<<CS3);
}

void spi_activer(uint16_t port, uint8_t cs) { // Activer le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg &= ~(1<<cs); // Ligne SS à l'état bas
}

void spi_desactiver(uint16_t port, uint8_t cs) { // Désactiver le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg |= (1<<cs); // Ligne SS à l'état haut
}

uint8_t spi_echange(uint8_t envoi) { // Communication sur le bus SPI
SPDR = envoi; // Octet a envoyer
while(!(SPSR & (1<<SPIF))); // Attente fin envoi (drapeau SPIF du statut)
return SPDR; // Octet reçu
}

</syntaxhighlight>Afin de rendre nos fonctions les plus réutilisables possibles nous avons passer en paramètre le port ainsi que le CS qui correspond au slave select. Le type réel du port est volatile uint8* cependant le compilateur n'accepte que le uint16* ce qui explique le cast un peu étrange.

=====Implémentation=====
[[Fichier:Video7segvideo.mp4|vignette|centré]]L'implémentation correspond à nos attentes, seul un 7 seg affiche le chiffre 9.

====Choix du processus sur le port série====
Afin de pouvoir démontrer le bon fonctionnement de la partie dynamique, on décide de pouvoir ajouter et tuer des processus à partir des touches du clavier. On utilisera donc les fonction de l'USART défini plus au au travers de la fonction suivante :<syntaxhighlight lang="c">
void call_process() {
unsigned char data;
while(1) {
data = USART_Receive();
if(data == '1') {
add(led1_blink);
}
...
else if(data == '6') {
kill(led1_blink);
}
...
USART_Transmit(data);
}
}

</syntaxhighlight>On remarquera que c'est une sorte d'amélioration de la fonction Serial_Message vu plus haut.

Cette fonction aura la fonction de process de base, toujours présent dans l'ordonnaceur.

==== Démonstation ====
[[Fichier:Process via USART.mp4|centré|vignette]]

Ici on lance les processus ledN_blink avec les touches 1 à 5 et on les tues avec les touches 6 à 0. Pour le 7 segments, on l'ajoute avec s et le tue avec d.

=Carte Réseau=
Lors de la répartition des tâches, nous avons opté pour la carte réseau.
==Description==
Le sujet nous permettait de choisir parmi plusieurs microcontrôleurs. Nous avons retenu l’ATmega32U4, qui nous semble représenter un juste milieu entre l’ATmega16U2 et l’AT90USB.
==Hardware==
Notre carte intègre des LED permettant d’afficher différents états de communication (que nous définirons ultérieurement).

À la demande de M. Redon, nous avons ajouté un MAX232 ainsi que des connecteurs DB9 et DB25. Nous savons que ces éléments pourront être utiles et servirons à utiliser la carte sur un terminal.

En dehors de ça, la carte reste assez basique car son composant principal reste l'ATmega.
===Schématique===
les broches PF n'étant pas utilisé, on les branches à un connecteur 6x1, notre carte pourra donc être utiliser pour d'autre projet si nécéssaire.

On fait le choix d'utiliser 5 leds pour la connections, 1 led de power et 1 pour la connection ISP.[[Fichier:Schématique CReseau.png|vignette|540x540px|centré]]
===Routage===
[[Fichier:Routage Creseau.png|vignette|521x521px|centré]]Après avoir soudé les composants principaux, il est temps de passer à la partie programmation de la carte.

==Programmation==

Notre carte utilisant un connecteur USB, nous allons donc faire passer notre carte pour une carte réseau en utilisant la demo RNDIS de la LUFA.

Il est important de noter que nous avons choisi un Atmega32u4. Ainsi des modification devrons être apporté à la taille des paquets ethernet et sur le choix des protocoles.

===Protocoles impémentés===

La demo RNDISEthernet de la LUFA inclut les protocole suivant

* ARP : Résolution d'adresses MAC.
* IP : Gestion des paquets IPv4.
* ICMP : Messages de contrôle (ping).
* TCP : Communication fiable (exemple : serveur TCP).
* UDP : Communication non fiable (exemple : serveur UDP).
* DHCP : Attribution dynamique d'adresse IP.

Aussi, on remarquera que la démo utilise un modèle en quatre couche : Le modèle TCP/IP.

le sujet nous propose trois possibilité :

* viser Ethernet
* viser UDP
* viser TCP

En regardant ce qui à été fait les années précédentes, on a remarqué que les groupes partaient principalement sur la première option. Nous nous avons décidé de viser UDP.

Ainsi, afin de d'alléger notre code pour le faire rentrer dans notre carte, nous avons choisi de ne pas inclure le protocole TCP et de modifier la taille max de paquets ethernet à 400 octets.

Il nous restera donc de l'espace pour recevoir des paquets Ethernet :<syntaxhighlight>
avr-size --mcu=atmega32u4 --format=avr RNDISEthernet.elf
AVR Memory Usage
----------------
Device: atmega32u4

Program: 9434 bytes (28.8% Full)
(.text + .data + .bootloader)

Data: 1037 bytes (40.5% Full)
(.data + .bss + .noinit)
</syntaxhighlight>Une fois la LUFA réduite et flashé, on donne une adresse IP à notre interface avec ip link eth2 up et ip address add 10.0.0.1/24 dev eth2. on test un ping sur l'adresse IP de la carte (10.0.0.2).[[Fichier:Ping creseau.mp4|centré|vignette]]Le premier test que nous décidons de faire, afin de vérifié notre compréhension du code de la LUFA, est de faire clignoter une LED si la carte reçoit un paquet ethernet. Pour cela on ajoute l'allumage de la LED dans la fonction EthernetTask du fichier principal (RNDISEthernet.c) :[[Fichier:Ping allume led.mov|vignette|La led s'éteint à chaque ping reçue|centré]]

===Création du protocole===

En plus de pouvoir communiquer, notre carte dois être capable d'effectuer 3 fonction.

On décide de créer notre propre protocole ProtocolAntique décrit ci-dessous :

ProtocolAntique (256 octets)

Entete du ProtocolAntique (3 octets)

operation (1 octet)

longueur (1 octet)

numero (1 octet)

Contenu du ProtocolAntique (256 - 3 = 253 octets)

Exemples :

LS :

Carte reseau :

-operation = 0x01 // requete LS

-longueur = [0-252]

-numero = 0 // la requete n'est pas fragmentée

-contenu // chemin ou effectuer le ls

Serveur :

-operation = 0x11 // reponse au LS

-longueur = [0-252]

-numero = [0-255] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // nom de fichier ou rien si numero = 0

READ :

Carte reseau :

-operation = 0x02 // requete READ

-longueur = [0-252]

-numero = 0 // la requete n'est pas fragmentée

-contenu // chemin/nom_fichier

Serveur :

-operation = 0x12 // reponse au READ

-longueur = [0-252]

-numero = [0-255] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // contenu d'une ligne ou rien si numero = 0

WRITE :

Carte reseau :

-operation = 0x03 // requete WRITE creation du fichier

-longueur = [0-252]

-numero = 0 // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // Chemin pour ouvrir le fichier avce le nom du fichier : chemin/fichier

Carte reseau :

-operation = 0x13 // requete WRITE ecriture dans le fichier

-longueur = [0-252]

-numero = [1-252] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // ligne a ecrire

Carte reseau :

-operation = 0x23 // requete WRITE fin

-longueur = [0-252]

-numero = 0 // 0 dernier paquet

-contenu // rien

Comme nous avons choisit de viser UDP, le protocole doit pocédé un numéro de port, on choisit un numéro supérieur à 1023 pour ne pas devoir passer en root, Le port choisi est 3333.

Dans le programme UDP.c on peut maintenant inclure notre protocole de la façon suivante :<syntaxhighlight lang="c">
switch (SwapEndian_16(UDPHeaderIN->DestinationPort))
{
/*
case UDP_PORT_DHCP_REQUEST:
RetSize = DHCP_ProcessDHCPPacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;
*/
case UDP_PORT_PROTOCOL_ANTIQUE:
RetSize = ProtocolAntique_ProcessProtocolAntiquePacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;

</syntaxhighlight>

=== Partie serveur ===
Lorsque la carte mère a besoin de faire une action (ls, read, write) sur l'ordinateur qui est connecté en USB via la carte réseau elle transmet son besoin à la carte réseau. Cette dernière créer un requête UDP qui encapsule notre protocole (ProtocolAntique) et la transmet donc au PC. Sur ce dernier un serveur doit donc fonctionner afin de recevoir les rêquetes de la carte réseau, les traiter et y répondre. Cette partie est donc consacrée au code ainsi qu'aux tests du serveur.

==== Code du serveur ====
Pour pouvoir fonctionner correctement le serveur doit initialiser une socket UDP et ensuite doit lancer un fonctionne qui boucle indéfiniment afin de recevoir chaque message UDP. Cette partie n'a pas été codé par nous et est trouvable sur rex.plil.fr (Département IMA -> support de cours de la programmation réseau -> exemple de serveur 2/2). Il en est de même du code la fonction pour envoyer un message UDP qui est trouvable au même endroit section exemple de client 2/2.

La carte réseau est toujours à l'initiative des requêtes, par conséquent le serveur commence par recevoir un requête et la traiter. Pour ce faire à chaque requête reçue par la fonction boucleServeurUDP la fonction traitementMessageUDP est appelée.<syntaxhighlight lang="c" line="1">
int traitementMessageUDP (unsigned char* message, int nboctets);
</syntaxhighlight>Cette fonction s'occupe d'extraire la partie opération de l'entête de protocolAntique et d'appeler la fonction de traitement correspondante à l'opération
{| class="wikitable"
!Opération
!Requête
!Fonction appelée
|-
|0x01
|LS
|void traitement_ls (unsigned char*);
|-
|0x02
|READ
|void traitement_read (unsigned char*);
|-
|0x03
|WRITE (début)
|void traitement_write (unsigned char*);
|-
|0x13
|WRITE (données et fin)
|void traitement_write (unsigned char*);
|}

===== Traitement LS =====
La fonction traitement_ls commence par récupérer le chemin (relatif ou absolu) où effectuer le LS. Si la section longueur de l'entête de la requête est à 0 alors le chemin par défaut est celui depuis où le serveur à été lancé. Le code pour récupérer le chemin est le suivant :<syntaxhighlight lang="c" line="1">
unsigned char chemin[longueur+1];
for (int i=0 ; i<longueur ; i++) {
chemin[i] = message[i+3]; // Recuperation du chemin
}
chemin[longueur] = '\0';
</syntaxhighlight>Par la suite le dossier est correspondant au chemin est ouvert via la fonction opendir puis chaque entrée du dossier est récupérée et engendre un message de réponse du serveur (un message par entrée).<syntaxhighlight lang="c" line="1">
while ((entree = readdir(dossier)) != NULL) {
// Message UDP pour chaque entree
strcpy(contenu, entree->d_name);
printf(" %s ", contenu);
reponse[OPERATION] = REPONSE_LS;
reponse[LONGUEUR] = strlen(contenu);
reponse[NUMERO] = num++;
for (int i=0 ; i<reponse[LONGUEUR] ; i++) {
reponse[i+3] = contenu[i];
}
messageUDP(IP_CARTE, PORT_CARTE, (unsigned char *)reponse, (int)reponse[LONGUEUR] + LONGUEUR_ENTETE);
}
</syntaxhighlight>OPERATION est la premiére section et vaut donc 0, LONGUEUR 2 et NUMERO 3. OPERATION est une réponse à un LS donc 0x11, LONGUEUR dépend de l'entrée du dossier et NUMERO augmente de 1 à chaque entrée. Enfin on remplie la requête du nom de l'entrée et on envoie le message.

Enfin une fois tous les entrées envoyées on envoie un dernier message UDP de type reponse_LS de longueur 0 et de numéro 0 afin d'indiquer que la transmission est terminée et ce correctement.

===== Traitement READ =====
Cette requête est très proche de celle du LS. On commence par récupérer le chemin avec le nom du fichier de la même façon que pour le LS. Cependant ici si le message ne contient pas de chemin aucun traitement ne sera effectué. Pour ouvrir le fichier on utilise la fonction fopen. Chaque ligne, récupérée via fgets, engendre une réponse UDP formulée de la même façon que pour les entrées de dossier. Evidemment l'opération est de type réponse read soit 0x12. Enfin un message similaire de fin de transmission est envoyé seulement si il n'y a pas eu d'erreur et que la dernière ligne à été lue.

===== Traitement WRITE =====
Cette requête est un peu plus complexe à gérer niveau serveur par conséquent que je vais commencer par décrire le principe de la fonction.

* La carte réseau envoie un message de type début de write (OPERATION 0x03) avec le chemin et nom du fichier que le serveur va récupérer et mémoriser.

* La carte réseau envoie un massage pour chaque ligne à écrite (OPERATION 0x13). Le serveur va vérifier si la section NUMERO des entêtes se suivent afin de s'assurer que aucun message n'est été perdu.

* La carte réseau envoie un message de type fin de write (OPERATION 0x013) mais de numéro 0. Le serveur indique que tout s'est bien passé en envoyant une réponse au write (OPERATION 0x23) donc le contenu est 0x00.
* Si un message a été perdu un message d'erreur est envoyé de la par du serveur (OPERATION 0x23) de contenu 0x01.

La récupération du contenu de la requête est du même type que celle du LS. Les messages de retour sont construits de la même façon que pour le message de retour du LS. Enfin on utilise fopen une nouvelle fois pour ouvrir le fichier, fwrite pour y écrire et fclose pour le fermer.

==== Préparation du test ====
Avant de pouvoir tester notre serveur avec la carte réseau (ce qui n'aura jamais été fait car la carte réseau n'envoie rien) nous avons souhaité validé le fonctionnement du serveur en simulant des requêtes de la carte réseau. On voit ce que le serveur fait via des printf et en créant un autre serveur (plus rudimentaire) on peut vérifier que le serveur répond correctement. Sur notre git le dossier testUDP est consacré à cette phase de tests.

* Les requêtes simulées de la carte réseau sont envoyées sur l'IP loopback de la machine et sur le port du serveur (ici 4242)
* Le serveur écoute le port serveur (4242) et répond en loopback sur le port du serveur qui simule la carte (ici 3333)
* Le serveur qui simule la carte écoute le port 3333

On lance ces différents serveurs et les requêtes via les commandes du fichiers fonctionnement.txt de notre git.

==== Tests ====
Le test est réalisé via 3 commandes :

* LS sans chemin
* WRITE de 3 lignes dans un fichier test.txt créé par la commande
* READ du fichier test.txt

[[Fichier:Test1.png|centré|vignette|Requêtes envoyées]]
[[Fichier:Test2.png|centré|vignette|Traitement du serveur]]
[[Fichier:Test3.png|centré|vignette|Réponse reçu du serveur]]On peut constater que les tests fonctionnent. En effet le serveur a envoyé 9 res ls (8 entrées + fin de transmissions), 1 res write (fin d'écriture correcte) et 6 res read (5 lignes + 1 fin de transmissions).

Enfin on décide de tester la réception des paquets UDP, on fait à nouveau clignoter une led quand un paquet UDP et reçu. Ici on envoi la réponse d'un LS, d'où la reception de plusieurs paquets:
[[Fichier:Test udp.mp4|centré|vignette]]
== Conclusion ==
La partie shield et ordonnanceur est finie et testée. La carte réseau n'a pas pu être finie par manque de temps. En faisant allumer une LED lorsqu'elle reçoit une trame Ethernet, UDP, STMP nous avons constaté qu'elle reçoit correctement ces protocoles. Cependant lorsque que nous avons voulu modifier la LUFA pour qu'une LED en plus s'allume lorsque UDP contient protocole antique cela ne fonctionnait pas. La carte ne trouvait jamais le protocole Antique. La communication avec la carte mère (shield) n'a pas été faite par manque de temps (cependant la communication SPI est vérifiée à l'étape de l'ordonnanceur). Le serveur côté PC qui doit communiquer avec la carte réseau est fini et testé.

Notre problème peut venir du fait que l'atmega32u4 n'a pas assez de mémoire. Il ne faut donc pas choisir ce micro contrôleur pour ce projet mais un avec plus de mémoire.

SE4Binome2025-1

2026-01-24T11:21:34Z

Abiernac :

= Shield Arduino =
== Hardware ==
Afin de tester notre futur carte réseau, nous avons fait un shield d'arduino qui prendra le rôle de la carte mère.
=== Schématique ===
Nous nous sommes évidemment aidés de la datasheet de l'atmega328p ainsi que celle de l'arduino uno afin de sélectionner les bon pins.
[[Fichier:Atmel-7810-Automotive-Microcontrollers-ATmega328P Datasheet.pdf|centré|vignette|Datasheet ATmega328p]]
[[Fichier:A000066-datasheet.pdf|centré|vignette|Datasheet Arduino Uno R3]]
Plus précisément nous nous sommes inspirés très fortement du schéma page 10 de la datasheet de l'arduino :
[[Fichier:Screenshot 2025-11-07 11-08-46.png|centré|vignette|Schéma pinouts]]
Nous sommes donc parti de l'exemple fourni par Mr Redon. Mais nous avons utilisé une template disponible dans kicad permettant de créer des shields d'arduino Uno R3.[[Fichier:Tyetyuy.png|vignette|Schématique shield arduino|centré|438x438px]]
=== Routage ===
Au niveau du routage, nous avons tenté de faire simple (sans trop abuser des vias). Nous avons positionné le lecteur de carte SD au bord de la carte afin de ne pas avoir de problèmes avec d'autres composants lorsque nous voudrons mettre ou enlever la carte SD.
[[Fichier:Routage shield arduino.png|vignette|Routage shield arduino|centré|434x434px]]

===Soudage===
La schématique et le routage terminés, nous avons soudé les différents pins permettant de connecter la carte shield à l'arduino, le reste n'étant pas forcément utile pour le moment (il est important de noter que notre shield est arrivé avec des composants pré-soudés).
[[Fichier:Shield soudage de base .jpg|centré|vignette]]

===Tests===
====Leds====

Il faudra ensuite faire des test d'allumage des leds, afin de vérifier le bon fonctionnement du shield
[[Fichier:VID leds.mp4|centré|vignette]]

Les leds fonctionnent à merveille.

====Carte SD====

Nous vérifions maintenant la carte SD (même si elle nous sera inutile pour notre projet).

Nous utilisons le programme fourni par arduino qui permet de récupérer les informations de la carte SD.
[[Fichier:Test sd card.png|centré|vignette]]
La carte SD est bien identifié, le lecteur de carte fonctionne donc normalement.

== Software ==
=== Ordonnanceur ===
==== Ordonnanceur basique ====
La première étape consiste à définir la structure d'un process, il sera composé :

*D'un pointeur de pile
*De l'adresse de la fonction
*D'un temps de sommeil
*D'un état : 0 pour en cours et 1 pour terminé ou vide

Ces deux derniers points nous serviront plus tard.<syntaxhighlight lang="c" line="1">
typedef struct {
uint16_t stackPointer;
void (*functionAddress)(void);
int sleep_time;
int state;
} process;

</syntaxhighlight>On initialise donc notre tableau de processus de la façon suivante : <syntaxhighlight lang="c" line="1">
process Tasks_list[NBTASKS] = {
{0, led1_blink, 0,0},
...
};

</syntaxhighlight>Concernant les fonction liées aux leds, nous utilisons une simple boucle while contenant un changement d'état. <syntaxhighlight lang="c" line="1">
void led_init() {
...
}
void led1_blink() {
while(1) {
PORTC ^= (1<<PLED1);
_delay_ms(100);
}
}
void led2_blink() {
...
</syntaxhighlight>La fonction init_stackPointer_tasks() permet de diviser la pile "réel" en plusieurs piles de taille fixe pour chacun des processus. Ces sous piles commencent à la position FIRST_STACK_POSITION, afin de ne pas réécrire par dessus des données. Toutes les sous piles disposent d'une même taille de pile STACK_LENGTH. La fonction init_piles() initialise correctement la pile avec le tableau de processus si le processus est actif. Elle sauvegarde d'abord le pointeur de pile actuel, place l'adresse de la fonction (sur 16 bits) dans la pile de la tâche, sauvegarde les registres, puis restaure le pointeur de pile initial.<syntaxhighlight lang="c" line="1">
void init_stackPointer_tasks(int Cprocess) { //initialise le pointer de pile
if(Tasks_list[Cprocess].state == 0) {
Tasks_list[Cprocess].stackPointer = FIRST_STACK_POSITION - (Cprocess * STACK_LENGTH);
}
}

void init_piles(int Cprocess){ //initilalise la pile
if(Tasks_list[Cprocess].state == 0) {
int save = SP;
SP = Tasks_list[Cprocess].stackPointer;
uint16_t address = (uint16_t)Tasks_list[Cprocess].functionAddress;
asm volatile("push %0" : : "r" (address & 0x00ff) );
asm volatile("push %0" : : "r" ((address & 0xff00)>>8) );
SAVE_REGISTERS();
Tasks_list[Cprocess].stackPointer = SP;
SP = save;
}
}

</syntaxhighlight>Le scheduler permet de passer à la tâche suivante<syntaxhighlight lang="c" line="1">
void scheduler() {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}

</syntaxhighlight>L'atmega328p ne dispose pas de fonction en assembleur permettant de push ou de pop tout les registres, on doit donc en créer par nous mêmes. On défini alors les macros suivantes : <syntaxhighlight lang="c" line="1">
#define SAVE_REGISTERS() \
asm volatile ( \
"push r0 \n\t" \
...\
)

#define RESTORE_REGISTERS() \
asm volatile ( \
"pop r31 \n\t" \
...\
)

</syntaxhighlight>L'ISR gère les interruptions, en commençant par sauvegarder l'état de la pile ainsi que le stack pointeur propre au processus qui s'interrompt. L'appel au schedruler permet de changer de processus pour cela il faut restaurer le stack pointer propre au nouveau processus actif et de la pile liée à ce processus. La dernière ligne arrête l'ISR.<syntaxhighlight lang="c" line="1">
ISR(TIMER1_COMPA_vect, ISR_NAKED) {
SAVE_REGISTERS();
Tasks_list[Current_task].stackPointer = SP;
scheduler();
SP = Tasks_list[Current_task].stackPointer;
RESTORE_REGISTERS();
asm volatile("reti");
}
</syntaxhighlight>
=====Test=====
Les processus de clignotement de leds ont tous un délai d'attente différent, l'interruption se produit toutes les millisecondes. On obtient ceci :[[Fichier:Ordonnanceur basique.mp4|centré|vignette]]Il est intéressant de remarqué que la vitesse à laquelle les leds changent d'état ne correspond pas au délai qui leur a été donnée. Cela parait logique puisque l'interruption met la fonction _delay_ms en pause, ainsi la vitesse se voit divisé par le nombre de processus actif.

====Ajout d'un système d'endormissement des processus====

La fonction wait va permettre d'endormir un processus, elle va donné un temps de sommeil au processus puis lancer une interruption (car on veut changer de processus directement après que le précédent ait été endormi).<syntaxhighlight lang="c" line="1">
void wait(int time) { // met un process en veille pour une durée donné
// valeur max de time 32000 car int sur atmega328p code sur 16 bits donc 32000 max
cli();
Tasks_list[Current_task].sleep_time = time;
TCNT1=0;
sei();
TIMER1_COMPA_vect();

</syntaxhighlight>Pour vérifier si un processus a besoin d'être lancé, on ajoute une boucle while dans le scheduler afin de vérifier si il y a un temps de sommeil. Le scheduler va aussi servir à diminuer le temps de sommeil de tout les processus (avec un minimum de 0).<syntaxhighlight lang="c" line="1">
void scheduler() {
for (int i=0 ; i<NBTASKS ; i++) {
if (Tasks_list[i].sleep_time - SLEEP_DEC < 0) {
Tasks_list[i].sleep_time = 0;
} else {
Tasks_list[i].sleep_time -= SLEEP_DEC;
}
}

do {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}
} while (Tasks_list[Current_task].sleep_time > 0);
}

</syntaxhighlight>
====Tableau dynamique des tâches====

En premier lieu on va initialiser les état de tout les cases du tableau de processus. On choisit 1 la case est vide, 0 sinon.<syntaxhighlight lang="c" line="1">
void init_state() { //initialise state
for (int i= 0; i<NBTASKS; i++) {
if (Tasks_list[i].functionAddress == NULL) {
Tasks_list[i].state = 1;
}
else {
Tasks_list[i].state = 0;
}
}
}
</syntaxhighlight>Nous avons programmé deux fonction d'arrêt et une fonction d'ajout de processus :

* finish : stop le processus en cours et le supprime de tableau, puis lance une interruption

* kill : stop un processus donné et le supprime du tableau

* add : ajoute un processus sur la première case vide du tableau, initialise son pointeur de position et sa pile.

Pour finish et kill, on met le temps de sommeil à 0 au cas où on arrête un processus endormi. C'est une mesure de sécurité pour finish, mais une obligation pour kill.<syntaxhighlight lang="c" line="1">
void finish() { //supprime un process lorsque celui-ci est terminé
cli();
Tasks_list[Current_task].state =1;
Tasks_list[Current_task].sleep_time = 0;
Tasks_list[Current_task].functionAddress = NULL;
TCNT1=0;
sei();
TIMER1_COMPA_vect();
}

void kill(void (*function)(void)) { //tue le process passé en paramètre
cli();
for(int i = 0; i<NBTASKS; i++) {
if(Tasks_list[i].functionAddress == function) {
Tasks_list[i].state =1;
Tasks_list[i].sleep_time = 0;
Tasks_list[i].functionAddress = NULL;
}
}
sei();
}

void add(void (*newFunction)(void)) { //ajoute un process
cli();
int i =0;
while(Tasks_list[i].state != 1) {
i++;
}
Tasks_list[i].functionAddress = newFunction;
Tasks_list[i].state = 0;
init_stackPointer_tasks(i);
init_piles(i);

sei();

}
</syntaxhighlight>Il suffit maintenant de modifier le scheduler afin de ne pas prendre les processus terminé, puis utiliser add, finish et kill dans les fonctions choisies.

=====Test=====
Pour tester les fonction add et finish, on réalise le test suivant :

* on créer un process qui ajoute le process led2_blink (avec add) au bout d'un certain temps
* le process led2_blink s'arrête (avec finish) au bout de 20 changement d'état (c'est à dire 10 clignotement).

On obtient le résultat escompté qui est le suivant :[[Fichier:Demo fonction add et finish.mp4|centré|vignette]]
====Lecture et écriture sur le port série====
Afin de lire et écrire sur le port série, on utilise les fonctions USART_Init, USART_Transmit et USART_Receive vu en cours de microP l'année précédente. Le but sera donc d'écrire le message qui vient d'être reçu, on utilise donc le processus suivant :<syntaxhighlight lang="c" line="1">
void Serial_Message(){
unsigned char data;
while(1){
data = USART_Receive();
USART_Transmit(data);
}
}
</syntaxhighlight>

=====Test=====
Pour tester notre processus de communication, on utilise minicom.[[Fichier:Test lecture et écriture port série.mp4|centré|vignette]]On notera que si la période entre les interruptions est trop élevé, certains caractères ne seront pas lus.

====Afficheur 7 segments====
<syntaxhighlight lang="c" line="1">
void seven_seg() {
while (1) {
spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x7E);
spi_echange(0b1101111);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);

spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x76);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);
}
}
</syntaxhighlight>Le processus seven_seg est ajouté au tableau des processus. Avant d'échanger en spi il faut activer la communication, et la désactiver après l'échange. La ligne 4 permet de sélectionner le 7 seg sur lequel on souhaite modifier l'affichage. La ligne 5 permet d'afficher le chiffre 9. Enfin la ligne 11 permet de clear le display. Voir tableau ci-dessous.
[[Fichier:Tab 7 seg sparkfun.png|centré|vignette]]
<syntaxhighlight lang="c" line="1">
void spi_init(void) { // Initialisation du bus SPI
SPI_DDR |= (1<<SPI_MOSI)|(1<<SPI_SCK); // Définition des sorties
SPI_DDR &= ~(1<<SPI_MISO); // Définition de l'entrée
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1); // Activation SPI (SPE) en état maître (MSTR)
// horloge F_CPU/64 (SPR1=1,SPR0=0)
SPI_DDR |= (1<<CS1) | (1<<CS4);;
DDRD |= (1<<CS5) | (1<<CS6);
DDRC |= (1<<CS2) | (1<<CS3);
}

void spi_activer(uint16_t port, uint8_t cs) { // Activer le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg &= ~(1<<cs); // Ligne SS à l'état bas
}

void spi_desactiver(uint16_t port, uint8_t cs) { // Désactiver le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg |= (1<<cs); // Ligne SS à l'état haut
}

uint8_t spi_echange(uint8_t envoi) { // Communication sur le bus SPI
SPDR = envoi; // Octet a envoyer
while(!(SPSR & (1<<SPIF))); // Attente fin envoi (drapeau SPIF du statut)
return SPDR; // Octet reçu
}

</syntaxhighlight>Afin de rendre nos fonctions les plus réutilisables possibles nous avons passer en paramètre le port ainsi que le CS qui correspond au slave select. Le type réel du port est volatile uint8* cependant le compilateur n'accepte que le uint16* ce qui explique le cast un peu étrange.

=====Implémentation=====
[[Fichier:Video7segvideo.mp4|vignette|centré]]L'implémentation correspond à nos attentes, seul un 7 seg affiche le chiffre 9.

====Choix du processus sur le port série====
Afin de pouvoir démontrer le bon fonctionnement de la partie dynamique, on décide de pouvoir ajouter et tuer des processus à partir des touches du clavier. On utilisera donc les fonction de l'USART défini plus au au travers de la fonction suivante :<syntaxhighlight lang="c">
void call_process() {
unsigned char data;
while(1) {
data = USART_Receive();
if(data == '1') {
add(led1_blink);
}
...
else if(data == '6') {
kill(led1_blink);
}
...
USART_Transmit(data);
}
}

</syntaxhighlight>On remarquera que c'est une sorte d'amélioration de la fonction Serial_Message vu plus haut.

Cette fonction aura la fonction de process de base, toujours présent dans l'ordonnaceur.

=====Démonstation=====
[[Fichier:Process via USART.mp4|centré|vignette]]

Ici on lance les processus ledN_blink avec les touches 1 à 5 et on les tues avec les touches 6 à 0. Pour le 7 segments, on l'ajoute avec s et le tue avec d.

=Carte Réseau=
Lors de la répartition des tâches, nous avons opté pour la carte réseau.
==Description==
Le sujet nous permettait de choisir parmi plusieurs microcontrôleurs. Nous avons retenu l’ATmega32U4, qui nous semble représenter un juste milieu entre l’ATmega16U2 et l’AT90USB.
==Hardware==
Notre carte intègre des LED permettant d’afficher différents états de communication (que nous définirons ultérieurement).

À la demande de M. Redon, nous avons ajouté un MAX232 ainsi que des connecteurs DB9 et DB25. Nous savons que ces éléments pourront être utiles et servirons à utiliser la carte sur un terminal.

En dehors de ça, la carte reste assez basique car son composant principal reste l'ATmega.
===Schématique===
les broches PF n'étant pas utilisé, on les branches à un connecteur 6x1, notre carte pourra donc être utiliser pour d'autre projet si nécéssaire.

On fait le choix d'utiliser 5 leds pour la connections, 1 led de power et 1 pour la connection ISP.[[Fichier:Schématique CReseau.png|vignette|540x540px|centré]]
===Routage===
[[Fichier:Routage Creseau.png|vignette|521x521px|centré]]Après avoir soudé les composants principaux, il est temps de passer à la partie programmation de la carte.

==Programmation==

Notre carte utilisant un connecteur USB, nous allons donc faire passer notre carte pour une carte réseau en utilisant la demo RNDIS de la LUFA.

Il est important de noter que nous avons choisi un Atmega32u4. Ainsi des modification devrons être apporté à la taille des paquets ethernet et sur le choix des protocoles.

===Protocoles impémentés===

La demo RNDISEthernet de la LUFA inclut les protocole suivant

* ARP : Résolution d'adresses MAC.
* IP : Gestion des paquets IPv4.
* ICMP : Messages de contrôle (ping).
* TCP : Communication fiable (exemple : serveur TCP).
* UDP : Communication non fiable (exemple : serveur UDP).
* DHCP : Attribution dynamique d'adresse IP.

Aussi, on remarquera que la démo utilise un modèle en quatre couche : Le modèle TCP/IP.

le sujet nous propose trois possibilité :

* viser Ethernet
* viser UDP
* viser TCP

En regardant ce qui à été fait les années précédentes, on a remarqué que les groupes partaient principalement sur la première option. Nous nous avons décidé de viser UDP.

Ainsi, afin de d'alléger notre code pour le faire rentrer dans notre carte, nous avons choisi de ne pas inclure le protocole TCP et de modifier la taille max de paquets ethernet à 400 octets.

Il nous restera donc de l'espace pour recevoir des paquets Ethernet :<syntaxhighlight>
avr-size --mcu=atmega32u4 --format=avr RNDISEthernet.elf
AVR Memory Usage
----------------
Device: atmega32u4

Program: 9434 bytes (28.8% Full)
(.text + .data + .bootloader)

Data: 1037 bytes (40.5% Full)
(.data + .bss + .noinit)
</syntaxhighlight>Une fois la LUFA réduite et flashé, on donne une adresse IP à notre interface avec ip link eth2 up et ip address add 10.0.0.1/24 dev eth2. on test un ping sur l'adresse IP de la carte (10.0.0.2).[[Fichier:Ping creseau.mp4|centré|vignette]]Le premier test que nous décidons de faire, afin de vérifié notre compréhension du code de la LUFA, est de faire clignoter une LED si la carte reçoit un paquet ethernet. Pour cela on ajoute l'allumage de la LED dans la fonction EthernetTask du fichier principal (RNDISEthernet.c) :[[Fichier:Ping allume led.mov|vignette|La led s'éteint à chaque ping reçue|centré]]

===Création du protocole===

En plus de pouvoir communiquer, notre carte dois être capable d'effectuer 3 fonction.

On décide de créer notre propre protocole ProtocolAntique décrit ci-dessous :

ProtocolAntique (256 octets)

Entete du ProtocolAntique (3 octets)

operation (1 octet)

longueur (1 octet)

numero (1 octet)

Contenu du ProtocolAntique (256 - 3 = 253 octets)

Exemples :

LS :

Carte reseau :

-operation = 0x01 // requete LS

-longueur = [0-252]

-numero = 0 // la requete n'est pas fragmentée

-contenu // chemin ou effectuer le ls

Serveur :

-operation = 0x11 // reponse au LS

-longueur = [0-252]

-numero = [0-255] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // nom de fichier ou rien si numero = 0

READ :

Carte reseau :

-operation = 0x02 // requete READ

-longueur = [0-252]

-numero = 0 // la requete n'est pas fragmentée

-contenu // chemin/nom_fichier

Serveur :

-operation = 0x12 // reponse au READ

-longueur = [0-252]

-numero = [0-255] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // contenu d'une ligne ou rien si numero = 0

WRITE :

Carte reseau :

-operation = 0x03 // requete WRITE creation du fichier

-longueur = [0-252]

-numero = 0 // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // Chemin pour ouvrir le fichier avce le nom du fichier : chemin/fichier

Carte reseau :

-operation = 0x13 // requete WRITE ecriture dans le fichier

-longueur = [0-252]

-numero = [1-252] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // ligne a ecrire

Carte reseau :

-operation = 0x23 // requete WRITE fin

-longueur = [0-252]

-numero = 0 // 0 dernier paquet

-contenu // rien

Comme nous avons choisit de viser UDP, le protocole doit pocédé un numéro de port, on choisit un numéro supérieur à 1023 pour ne pas devoir passer en root, Le port choisi est 3333.

Dans le programme UDP.c on peut maintenant inclure notre protocole de la façon suivante :<syntaxhighlight lang="c">
switch (SwapEndian_16(UDPHeaderIN->DestinationPort))
{
/*
case UDP_PORT_DHCP_REQUEST:
RetSize = DHCP_ProcessDHCPPacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;
*/
case UDP_PORT_PROTOCOL_ANTIQUE:
RetSize = ProtocolAntique_ProcessProtocolAntiquePacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;

</syntaxhighlight>

=== Partie serveur ===
Lorsque la carte mère a besoin de faire une action (ls, read, write) sur l'ordinateur qui est connecté en USB via la carte réseau elle transmet son besoin à la carte réseau. Cette dernière créer un requête UDP qui encapsule notre protocole (ProtocolAntique) et la transmet donc au PC. Sur ce dernier un serveur doit donc fonctionner afin de recevoir les rêquetes de la carte réseau, les traiter et y répondre. Cette partie est donc consacrée au code ainsi qu'aux tests du serveur.

==== Code du serveur ====
Pour pouvoir fonctionner correctement le serveur doit initialiser une socket UDP et ensuite doit lancer un fonctionne qui boucle indéfiniment afin de recevoir chaque message UDP. Cette partie n'a pas été codé par nous et est trouvable sur rex.plil.fr (Département IMA -> support de cours de la programmation réseau -> exemple de serveur 2/2). Il en est de même du code la fonction pour envoyer un message UDP qui est trouvable au même endroit section exemple de client 2/2.

La carte réseau est toujours à l'initiative des requêtes, par conséquent le serveur commence par recevoir un requête et la traiter. Pour ce faire à chaque requête reçue par la fonction boucleServeurUDP la fonction traitementMessageUDP est appelée.<syntaxhighlight lang="c" line="1">
int traitementMessageUDP (unsigned char* message, int nboctets);
</syntaxhighlight>Cette fonction s'occupe d'extraire la partie opération de l'entête de protocolAntique et d'appeler la fonction de traitement correspondante à l'opération
{| class="wikitable"
!Opération
!Requête
!Fonction appelée
|-
|0x01
|LS
|void traitement_ls (unsigned char*);
|-
|0x02
|READ
|void traitement_read (unsigned char*);
|-
|0x03
|WRITE (début)
|void traitement_write (unsigned char*);
|-
|0x13
|WRITE (données et fin)
|void traitement_write (unsigned char*);
|}

===== Traitement LS =====
La fonction traitement_ls commence par récupérer le chemin (relatif ou absolu) où effectuer le LS. Si la section longueur de l'entête de la requête est à 0 alors le chemin par défaut est celui depuis où le serveur à été lancé. Le code pour récupérer le chemin est le suivant :<syntaxhighlight lang="c" line="1">
unsigned char chemin[longueur+1];
for (int i=0 ; i<longueur ; i++) {
chemin[i] = message[i+3]; // Recuperation du chemin
}
chemin[longueur] = '\0';
</syntaxhighlight>Par la suite le dossier est correspondant au chemin est ouvert via la fonction opendir puis chaque entrée du dossier est récupérée et engendre un message de réponse du serveur (un message par entrée).<syntaxhighlight lang="c" line="1">
while ((entree = readdir(dossier)) != NULL) {
// Message UDP pour chaque entree
strcpy(contenu, entree->d_name);
printf(" %s ", contenu);
reponse[OPERATION] = REPONSE_LS;
reponse[LONGUEUR] = strlen(contenu);
reponse[NUMERO] = num++;
for (int i=0 ; i<reponse[LONGUEUR] ; i++) {
reponse[i+3] = contenu[i];
}
messageUDP(IP_CARTE, PORT_CARTE, (unsigned char *)reponse, (int)reponse[LONGUEUR] + LONGUEUR_ENTETE);
}
</syntaxhighlight>OPERATION est la premiére section et vaut donc 0, LONGUEUR 2 et NUMERO 3. OPERATION est une réponse à un LS donc 0x11, LONGUEUR dépend de l'entrée du dossier et NUMERO augmente de 1 à chaque entrée. Enfin on remplie la requête du nom de l'entrée et on envoie le message.

Enfin une fois tous les entrées envoyées on envoie un dernier message UDP de type reponse_LS de longueur 0 et de numéro 0 afin d'indiquer que la transmission est terminée et ce correctement.

===== Traitement READ =====
Cette requête est très proche de celle du LS. On commence par récupérer le chemin avec le nom du fichier de la même façon que pour le LS. Cependant ici si le message ne contient pas de chemin aucun traitement ne sera effectué. Pour ouvrir le fichier on utilise la fonction fopen. Chaque ligne, récupérée via fgets, engendre une réponse UDP formulée de la même façon que pour les entrées de dossier. Evidemment l'opération est de type réponse read soit 0x12. Enfin un message similaire de fin de transmission est envoyé seulement si il n'y a pas eu d'erreur et que la dernière ligne à été lue.

===== Traitement WRITE =====
Cette requête est un peu plus complexe à gérer niveau serveur par conséquent que je vais commencer par décrire le principe de la fonction.

* La carte réseau envoie un message de type début de write (OPERATION 0x03) avec le chemin et nom du fichier que le serveur va récupérer et mémoriser.

* La carte réseau envoie un massage pour chaque ligne à écrite (OPERATION 0x13). Le serveur va vérifier si la section NUMERO des entêtes se suivent afin de s'assurer que aucun message n'est été perdu.

* La carte réseau envoie un message de type fin de write (OPERATION 0x013) mais de numéro 0. Le serveur indique que tout s'est bien passé en envoyant une réponse au write (OPERATION 0x23) donc le contenu est 0x00.
* Si un message a été perdu un message d'erreur est envoyé de la par du serveur (OPERATION 0x23) de contenu 0x01.

La récupération du contenu de la requête est du même type que celle du LS. Les messages de retour sont construits de la même façon que pour le message de retour du LS. Enfin on utilise fopen une nouvelle fois pour ouvrir le fichier, fwrite pour y écrire et fclose pour le fermer.

==== Préparation du test ====
Avant de pouvoir tester notre serveur avec la carte réseau (ce qui n'aura jamais été fait car la carte réseau n'envoie rien) nous avons souhaité validé le fonctionnement du serveur en simulant des requêtes de la carte réseau. On voit ce que le serveur fait via des printf et en créant un autre serveur (plus rudimentaire) on peut vérifier que le serveur répond correctement. Sur notre git le dossier testUDP est consacré à cette phase de tests.

* Les requêtes simulées de la carte réseau sont envoyées sur l'IP loopback de la machine et sur le port du serveur (ici 4242)
* Le serveur écoute le port serveur (4242) et répond en loopback sur le port du serveur qui simule la carte (ici 3333)
* Le serveur qui simule la carte écoute le port 3333

On lance ces différents serveurs et les requêtes via les commandes du fichiers fonctionnement.txt de notre git.

==== Tests ====
Le test est réalisé via 3 commandes :

* LS sans chemin
* WRITE de 3 lignes dans un fichier test.txt créé par la commande
* READ du fichier test.txt

[[Fichier:Test1.png|centré|vignette|Requêtes envoyées]]
[[Fichier:Test2.png|centré|vignette|Traitement du serveur]]
[[Fichier:Test3.png|centré|vignette|Réponse reçu du serveur]]On peut constater que les tests fonctionnent. En effet le serveur a envoyé 9 res ls (8 entrées + fin de transmissions), 1 res write (fin d'écriture correcte) et 6 res read (5 lignes + 1 fin de transmissions).

Enfin on décide de tester la reception des paquets UDP, on fait à nouveau clignotter une led quand un paquet UDP et reçu. Ici on envoi la réponse d'un LS, d'où la reception de plusieurs paquets:
[[Fichier:Test udp.mp4|centré|vignette]]
== Conclusion ==
La partie shield et ordonnanceur est finie et testée. La carte réseau n'a pas pu être finie par manque de temps. En faisant allumer une LED lorsqu'elle reçoit une trame Ethernet, UDP, STMP nous avons constaté qu'elle reçoit correctement ces protocoles. Cependant lorsque que nous avons voulu modifier la LUFA pour qu'une LED en plus s'allume lorsque UDP contient protocole antique cela ne fonctionnait pas. La carte ne trouvait jamais le protocole Antique. La communication avec la carte mère (shield) n'a pas été faite par manque de temps (cependant la communication SPI est vérifiée à l'étape de l'ordonnanceur). Le serveur côté PC qui doit communiquer avec la carte réseau est fini et testé.

Notre problème peut venir du fait que l'atmega32u4 n'a pas assez de mémoire. Il ne faut donc pas choisir ce micro contrôleur pour ce projet mais un avec plus de mémoire.

SE4Binome2025-1

2026-01-04T16:41:23Z

Abiernac :

= Shield Arduino =
== Hardware ==
Afin de tester notre futur carte réseau, nous avons fait un shield d'arduino qui prendra le rôle de la carte mère durant.
=== Schématique ===
Nous nous sommes évidemment aider de la datasheet de l'atmega328p ainsi que celle de l'arduino uno afin de sélectionner les bon pins.
[[Fichier:Atmel-7810-Automotive-Microcontrollers-ATmega328P Datasheet.pdf|centré|vignette|Datasheet ATmega328p]]
[[Fichier:A000066-datasheet.pdf|centré|vignette|Datasheet Arduino Uno R3]]
Plus précisément nous nous inspirons très fortement du schéma page 10 de la datasheet de l'arduino :
[[Fichier:Screenshot 2025-11-07 11-08-46.png|centré|vignette|Schéma pinouts]]
Nous sommes donc parti de l'exemple fourni par Mr Redon. Mais nous avons utilisé une template disponible dans kicad permettant de créer des shields d'arduino Uno R3.[[Fichier:Tyetyuy.png|vignette|Schématique shield arduino|centré|438x438px]]
=== Routage ===
Au niveau du routage, nous avons tenté de faire simple (sans trop abuser sur les vias. Nous avons positionner le lecteur de carte sd au bord de la carte afin de ne pas avoir de problèmes avec d'autres composants lorsque nous voudrons mettre ou enlever la carte sd.
[[Fichier:Routage shield arduino.png|vignette|Routage shield arduino|centré|434x434px]]

===Soudage===
La schématique et le routage terminés, nous avons soudé les différents pins permettant de souder la carte shield à l'arduino, le reste n'étant pas forcément utile pour le moment (il est important de noter que notre shield est arrivé avec des composants pré-soudés).
[[Fichier:Shield soudage de base .jpg|centré|vignette]]

===Tests===
====Leds====

Il faudra ensuite faire des test d'allumage des leds, afin de vérifier le bon fonctionnement du shield
[[Fichier:VID leds.mp4|centré|vignette]]

Les leds fonctionnent à merveille.

====Carte SD====

Nous vérifions maintenant la carte sd (même si elle nous sera inutile pour notre projet)

Nous utilisons le programme fourni par arduino qui permet de récuopéré les informatiuons de la carte sd.
[[Fichier:Test sd card.png|centré|vignette]]
La carte SD est bien identifié, le lecteur de carte fonctionne donc normalement.

== Software ==
=== Ordonnanceur ===
[à completer et commenter , seulement des codes pour le moment !!!!]
==== Ordonnanceur basique ====
La première étape consiste à définir la structure d'un process, il sera composé :

-d'un pointeur de pile

-de l'adresse de la fonction

-d'un temps de sommeil

-d'un état : 0 pour en cours et 1 pour terminé ou vide

Ces deux derniers points nous servirons plus tard.<syntaxhighlight lang="c" line="1">
typedef struct {
uint16_t stackPointer;
void (*functionAddress)(void);
int sleep_time;
int state;
} process;

</syntaxhighlight>On initialise donc notre tableau de processus de la façon suivante : <syntaxhighlight lang="c" line="1">
process Tasks_list[NBTASKS] = {
{0, led1_blink, 0,0},
...
};

</syntaxhighlight>Concernant les fonction liés leds, on utilise une simple boucle while contenant un changement d'état <syntaxhighlight lang="c" line="1">
void led_init() {
...
}
void led1_blink() {
while(1) {
PORTC ^= (1<<PLED1);
_delay_ms(100);
}
}
void led2_blink() {
...
</syntaxhighlight>La fonction init_stackPointer_tasks() permet de diviser la pile "réel" en plusieurs piles pour chaque processus. Ces sous piles commence à la position FIRST_STACK_POSITION, afin de ne pas réécrire par dessus des données. Toutes les sous piles diposent d'une même taille de pile STACK_LENGTH.

La fonction init_piles() initialise correctement la pile avec le tableau de processus si le processus est actif.<syntaxhighlight lang="c" line="1">
void init_stackPointer_tasks(int Cprocess) { //initialise le pointer de pile
if(Tasks_list[Cprocess].state == 0) {
Tasks_list[Cprocess].stackPointer = FIRST_STACK_POSITION - (Cprocess * STACK_LENGTH);
}
}

void init_piles(int Cprocess){ //initilalise la pile
if(Tasks_list[Cprocess].state == 0) {
int save = SP;
SP = Tasks_list[Cprocess].stackPointer;
uint16_t address = (uint16_t)Tasks_list[Cprocess].functionAddress;
asm volatile("push %0" : : "r" (address & 0x00ff) );
asm volatile("push %0" : : "r" ((address & 0xff00)>>8) );
SAVE_REGISTERS();
Tasks_list[Cprocess].stackPointer = SP;
SP = save;
}
}

</syntaxhighlight>le scheduler permet de passer à la tâche suivante<syntaxhighlight lang="c" line="1">
void scheduler() {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}

</syntaxhighlight>l'atmega328p ne dispose pas de de fonction en assembleur permettant de push ou de pop tout les registres. on doit donc le faire un par un.

On défini alors les macros suivantes : <syntaxhighlight lang="c" line="1">
#define SAVE_REGISTERS() \
asm volatile ( \
"push r0 \n\t" \
...\
)

#define RESTORE_REGISTERS() \
asm volatile ( \
"pop r31 \n\t" \
...\
)

</syntaxhighlight>L'ISR gère les interruptions, en commençant par sauvegarder l'état de la pile ainsi que le stack pointeur propre au processus qui s'interrompt. L'appel au schedruler permet de changer de processus pour cela il faut restorer le stack pointer propre au nouveau processus actif et de la pile liée à ce processus. La dernière ligne arrête l'ISR.<syntaxhighlight lang="c" line="1">
ISR(TIMER1_COMPA_vect, ISR_NAKED) {
SAVE_REGISTERS();
Tasks_list[Current_task].stackPointer = SP;
scheduler();
SP = Tasks_list[Current_task].stackPointer;
RESTORE_REGISTERS();
asm volatile("reti");
}
</syntaxhighlight>
=====test=====
Les processus de clignotement de leds ont tous un délai d'attente différent, l'interruption se produit toutes les millisecondes. On obtient ceci :[[Fichier:Ordonnanceur basique.mp4|centré|vignette]]Il est intéressant de remarqué que la vitesse à laquelle les leds changent d'état ne correspond pas au délai qui leur à été donné. Cela parait logique puisque l'interruption met la fonction _delay_ms en pause, ainsi la vitesse se voit divisé par le nombre de processus actif.

====Ajout d'un système d'endormissement des processus====

La fonction wait va permettre d'endormir un processus, elle va donné un temps de sommeil au processus puis lancer une interruption (car on veut changer de processus directement après que le précédent ait été endormi).<syntaxhighlight lang="c" line="1">
void wait(int time) { // met un process en veille pour une durée donné
// valeur max de time 32000 car int sur atmega328p code sur 16 bits donc 32000 max
cli();
Tasks_list[Current_task].sleep_time = time;
TCNT1=0;
sei();
TIMER1_COMPA_vect();

</syntaxhighlight>Pour verifier si un processus a besoin d'être lancé, on ajoute une boucle while dans le scheduler afin de vérifier si il y a un temps de sommeil. Le scheduler va aussi servir à diminuer le temps de sommeil de tout les processus (avec un minimum de 0).<syntaxhighlight lang="c" line="1">
void scheduler() {
for (int i=0 ; i<NBTASKS ; i++) {
if (Tasks_list[i].sleep_time - SLEEP_DEC < 0) {
Tasks_list[i].sleep_time = 0;
} else {
Tasks_list[i].sleep_time -= SLEEP_DEC;
}
}

do {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}
} while (Tasks_list[Current_task].sleep_time > 0);
}

</syntaxhighlight>
====Tableau dynamique des tâches====

En premier lieu on va initialiser les état de tout les cases du tableau de processus. On choisit 1 la case est vide, 0 sinon.<syntaxhighlight lang="c" line="1">
void init_state() { //initialise state
for (int i= 0; i<NBTASKS; i++) {
if (Tasks_list[i].functionAddress == NULL) {
Tasks_list[i].state = 1;
}
else {
Tasks_list[i].state = 0;
}
}
}
</syntaxhighlight>Nous avons programmé deux fonction d'arrêt et une fonction d'ajout de processus :

-finish stop le processus en cours et le supprime de tableau, puis lance une interruption

-kill stop un processus donné et le supprime du tableau

-add ajoute un processus sur la première case vide du tableau, initialise son pointeur de position et sa pile.

Pour finish et kill, on met le temps de sommeil à 0 au cas où on arrête un processus endormi. C'est une mesure de sécurité pour finish, mais une obligation pour kill.<syntaxhighlight lang="c" line="1">
void finish() { //supprime un process lorsque celui-ci est terminé
cli();
Tasks_list[Current_task].state =1;
Tasks_list[Current_task].sleep_time = 0;
Tasks_list[Current_task].functionAddress = NULL;
TCNT1=0;
sei();
TIMER1_COMPA_vect();
}

void kill(void (*function)(void)) { //tue le process passé en paramètre
cli();
for(int i = 0; i<NBTASKS; i++) {
if(Tasks_list[i].functionAddress == function) {
Tasks_list[i].state =1;
Tasks_list[i].sleep_time = 0;
Tasks_list[i].functionAddress = NULL;
}
}
sei();
}

void add(void (*newFunction)(void)) { //ajoute un process
cli();
int i =0;
while(Tasks_list[i].state != 1) {
i++;
}
Tasks_list[i].functionAddress = newFunction;
Tasks_list[i].state = 0;
init_stackPointer_tasks(i);
init_piles(i);

sei();

}
</syntaxhighlight>Il suffit maintenant de modifier le scheduler afin de ne pas prendre les processus terminé, puis utiliser add, finish et kill dans les fonctions choisis.

=====test=====
Pour tester les fonction add et finish, on fait le test suivant :

-on créer un process qui ajoute le process led2_blink (avec add) au bout d'un certain temps

-le process led2_blink s'arrête (avec finish) au bout de 20 changement d'état (c'est à dire 10 clignotement).

on obtient le résultat suivant :[[Fichier:Demo fonction add et finish.mp4|centré|vignette]]
====lecture et écriture sur le port série====
Afin de lire et écrire sur le port série, on utilise les fonctions USART_Init, USART_Transmit et USART_Receive vu en cours de microP l'année précédente. Le but sera donc d'écrire le message qui vient d'être reçu, on utilise donc le processus suivant :<syntaxhighlight lang="c" line="1">
void Serial_Message(){
unsigned char data;
while(1){
data = USART_Receive();
USART_Transmit(data);
}
}
</syntaxhighlight>

=====test=====
Pour tester notre processus de communication, on utilise minicom.[[Fichier:Test lecture et écriture port série.mp4|centré|vignette]]On notera que si la période entre les interruptions est trop élevé, certains caractères ne seront pas lus.

====afficheur 7 segments====
<syntaxhighlight lang="c" line="1">
void seven_seg() {
while (1) {
spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x7E);
spi_echange(0b1101111);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);

spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x76);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);
}
}
</syntaxhighlight>Le processus seven_seg est ajouté au tableau des processus. Avant d'échanger en spi il faut activer la communication, et la désactiver après l'échange. La ligne 4 permet de sélectionner le 7 seg sur lequel on souhaite modifier l'affichage. La ligne 5 permet d'afficher le chiffre 9. Enfin la ligne 11 permet de clear le display. Voir tableau ci-dessous.
[[Fichier:Tab 7 seg sparkfun.png|centré|vignette]]
<syntaxhighlight lang="c" line="1">
void spi_init(void) { // Initialisation du bus SPI
SPI_DDR |= (1<<SPI_MOSI)|(1<<SPI_SCK); // Définition des sorties
SPI_DDR &= ~(1<<SPI_MISO); // Définition de l'entrée
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1); // Activation SPI (SPE) en état maître (MSTR)
// horloge F_CPU/64 (SPR1=1,SPR0=0)
SPI_DDR |= (1<<CS1) | (1<<CS4);;
DDRD |= (1<<CS5) | (1<<CS6);
DDRC |= (1<<CS2) | (1<<CS3);
}

void spi_activer(uint16_t port, uint8_t cs) { // Activer le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg &= ~(1<<cs); // Ligne SS à l'état bas
}

void spi_desactiver(uint16_t port, uint8_t cs) { // Désactiver le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg |= (1<<cs); // Ligne SS à l'état haut
}

uint8_t spi_echange(uint8_t envoi) { // Communication sur le bus SPI
SPDR = envoi; // Octet a envoyer
while(!(SPSR & (1<<SPIF))); // Attente fin envoi (drapeau SPIF du statut)
return SPDR; // Octet reçu
}

</syntaxhighlight>Afin de rendre nos fonctions les plus réutilisables possibles nous avons passer en paramètre le port ainsi que le CS qui correspond au slave select. Le type réel du port est volatile uint8* cependant le compilateur n'accepte que le uint16* ce qui explique le cast un peu étrange.

=====Implémentation=====
[[Fichier:Video7segvideo.mp4|vignette|centré]]L'implémentation correspond à nos attentes, seul un 7 seg affiche le chiffre 9.

====choix du processus sur le port série====

afin de pouvoir démontrer le bon fonctionnement de la partie dynamique, on décide de pouvoir ajouter et tuer des processus à partir des touches du clavier. On utilisera donc les fonction de l'USART défini plus au au travers de la fonction suivante:<syntaxhighlight lang="c">
void call_process() {
unsigned char data;
while(1) {
data = USART_Receive();
if(data == '1') {
add(led1_blink);
}
...
else if(data == '6') {
kill(led1_blink);
}
...
USART_Transmit(data);
}
}

</syntaxhighlight>On remarquera que c'est une sorte d'amélioration de la fonction Serial_Message vu plus haut.

Cette fonction aura la fonction de process de base, toujours présent dans l'ordonnaceur.

=====Démonstation=====
[[Fichier:Process via USART.mp4|centré|vignette]]

Ici on lance les processus ledN_blink avec les touches 1 à 5 et on les tues avec les touches 6 à 0. Pour le 7 segments, on l'ajoute avec s et le tue avec d.

=Carte Réseau=
Lors de la répartition des tâches, nous avons opté pour la carte réseau.
==Description==
Le sujet nous permettait de choisir parmi plusieurs microcontrôleurs. Nous avons retenu l’ATmega32U4, qui nous semble représenter un juste milieu entre l’ATmega16U2 et l’AT90USB.
==Hardware==
Notre carte intègre des LED permettant d’afficher différents états de communication (que nous définirons ultérieurement).

À la demande de M. Redon, nous avons ajouté un MAX232 ainsi que des connecteurs DB9 et DB25. Nous espérons que ces éléments pourront être utiles.

En dehors de ça, la carte reste assez basique car son composant principal reste l'ATmega.
===Schématque===
les broches PF n'étant pas utilisé, on les branches à un connecteur 6x1, notre carte pourra donc être utiliser pour d'autre projet si nécéssaire.

On fait le choix d'utiliser 5 leds pour la connections, 1 led de power et 1 pour la connection ISP.[[Fichier:Schématique CReseau.png|vignette|540x540px|centré]]
===Routage===
[[Fichier:Routage Creseau.png|vignette|521x521px|centré]]Après avoir soudé les composants pricnipaux. il est temps de passer à la partie programmation de la carte.

==Programmation==

Notre carte utilsant un USB, on va donc la faire passer pour une carte réseau en utilisant la demo RNDIS de la LUFA.

Il est important de noter que nous avons choisi un Atmega32u4. Ainsi des modification devrons être apporté à la taille des paquets ethernet et sur le choix des protocoles.

===Protocoles impémentés===

La demo RNDISEthernet de la LUFA inclut les protocole suivant

* ARP : Résolution d'adresses MAC.
* IP : Gestion des paquets IPv4.
* ICMP : Messages de contrôle (ping).
* TCP : Communication fiable (exemple : serveur TCP).
* UDP : Communication non fiable (exemple : serveur UDP).
* DHCP : Attribution dynamique d'adresse IP.

Aussi, on remarquera que la démo utilise un modèle en quatre couche : Le modèle TCP/IP.

le sujet nous propose trois possibilité :

* viser Ethernet
* viser UDP
* viser TCP

En regardant ce qui à été fait les années précédentes, on a remarqué que les groupes partaient principalement sur la première option. Nous nous avons décidé de viser UDP.

Ainsi, afin de d'alléger notre code pour le faire rentrer dans notre carte, nous avons choisi de ne pas inclure le protocole TCP et de modifier la taille max de paquets ethernet à 400 octets.

Il nous restera donc de l'espace pour recevoir des paquets Ethernet :<syntaxhighlight>
avr-size --mcu=atmega32u4 --format=avr RNDISEthernet.elf
AVR Memory Usage
----------------
Device: atmega32u4

Program: 9434 bytes (28.8% Full)
(.text + .data + .bootloader)

Data: 1037 bytes (40.5% Full)
(.data + .bss + .noinit)
</syntaxhighlight>Une fois la lufa réduite et flashé, on donne une adresse ip à notre inteface avec ip link eth2 up et ip address add 10.0.0.1/24 dev eth2. on test un ping sur l'adresse ip de la carte (10.0.0.2).[[Fichier:Ping creseau.mp4|centré|vignette]]
[[Fichier:Ping allume led.mov|vignette|centré]]Le premier test que nous décidons de faire, afin de vérifié notre comprehesion du code de la LUFA est de de faire clignioter si la carte reçoit un paquet ethernet, pour celà on ajoute l'allumage de la led dans la fonction EthernetTask du fichier principal ( RNDISEthernet.c) :[[Fichier:Ping allume led.mov|vignette|La led s'éteint à chaque ping reçue|centré]]

===Création du protocole===

En plus de pouvoir communiquer, notre carte dois être capable d'effectuer 3 fonction.

On décide de créer notre propre protocole ProtocolAntique décrit ci-dessous :

ProtocolAntique (256 octets)

Entete du ProtocolAntique (3 octets)

operation (1 octet)

longueur (1 octet)

numero (1 octet)

Contenu du ProtocolAntique (256 - 3 = 253 octets)

Exemples :

LS :

Carte reseau :

-operation = 0x01 // requete LS

-longueur = [0-252]

-numero = 0 // la requete n'est pas fragmentée

-contenu // chemin ou effectuer le ls

Serveur :

-operation = 0x11 // reponse au LS

-longueur = [0-252]

-numero = [0-255] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // nom de fichier ou rien si numero = 0

READ :

Carte reseau :

-operation = 0x02 // requete READ

-longueur = [0-252]

-numero = 0 // la requete n'est pas fragmentée

-contenu // chemin/nom_fichier

Serveur :

-operation = 0x12 // reponse au READ

-longueur = [0-252]

-numero = [0-255] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // contenu d'une ligne ou rien si numero = 0

WRITE :

Carte reseau :

-operation = 0x03 // requete WRITE creation du fichier

-longueur = [0-252]

-numero = 0 // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // Chemin pour ouvrir le fichier avce le nom du fichier : chemin/fichier

Carte reseau :

-operation = 0x13 // requete WRITE ecriture dans le fichier

-longueur = [0-252]

-numero = [1-252] // entre 1 et 255 => numero du paquet => reponse fragmentée, si 0 dernier paquet

-contenu // ligne a ecrire

Carte reseau :

-operation = 0x23 // requete WRITE fin

-longueur = [0-252]

-numero = 0 // 0 dernier paquet

-contenu // rien

Comme nous avons choisit de viser UDP, le protocole doit pocédé un numéro de port, on choisit un numéro supérieur à 1023 pour ne pas devoir passer en root, Le port choisi est 3333.

Dans le programme UDP.c on peut maintenant inclure notre protocole de la façon suivante :<syntaxhighlight lang="c">
switch (SwapEndian_16(UDPHeaderIN->DestinationPort))
{
/*
case UDP_PORT_DHCP_REQUEST:
RetSize = DHCP_ProcessDHCPPacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;
*/
case UDP_PORT_PROTOCOL_ANTIQUE:
RetSize = ProtocolAntique_ProcessProtocolAntiquePacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;

</syntaxhighlight>

===Partie Application===

(A compléter)

Afin de tester la reception du paquet UDP, on fait à nouveau clignotter une led quand un paquet UDP et reçu (video)

=== Partie serveur ===
Lorsque la carte mère a besoin de faire une action (ls, read, write) sur l'ordinateur qui est connecté en USB via la carte réseau elle transmet son besoin à la carte réseau. Cette dernière créer un requête UDP qui encapsule notre protocole (ProtocolAntique) et la transmet donc au PC. Sur ce dernier un serveur doit donc fonctionner afin de recevoir les rêquetes de la carte réseau, les traiter et y répondre. Cette partie est donc consacrée au code ainsi qu'aux tests du serveur.

==== Code du serveur ====
Pour pouvoir fonctionner correctement le serveur doit initialiser une socket UDP et ensuite doit lancer un fonctionne qui boucle indéfiniment afin de recevoir chaque message UDP. Cette partie n'a pas été codé par nous et est trouvable sur rex.plil.fr (Département IMA -> support de cours de la programmation réseau -> exemple de serveur 2/2). Il en est de même du code la fonction pour envoyer un message UDP qui est trouvable au même endroit section exemple de client 2/2.

La carte réseau est toujours à l'initiative des requêtes, par conséquent le serveur commence par recevoir un requête et la traiter. Pour ce faire à chaque requête reçue par la fonction boucleServeurUDP la fonction traitementMessageUDP est appelée.<syntaxhighlight lang="c" line="1">
int traitementMessageUDP (unsigned char* message, int nboctets);
</syntaxhighlight>Cette fonction s'occupe d'extraire la partie opération de l'entête de protocolAntique et d'appeler la fonction de traitement correspondante à l'opération
{| class="wikitable"
!Opération
!Requête
!Fonction appelée
|-
|0x01
|LS
|void traitement_ls (unsigned char*);
|-
|0x02
|READ
|void traitement_read (unsigned char*);
|-
|0x03
|WRITE (début)
|void traitement_write (unsigned char*);
|-
|0x13
|WRITE (données et fin)
|void traitement_write (unsigned char*);
|}

===== Traitement LS =====
La fonction traitement_ls commence par récupérer le chemin (relatif ou absolu) où effectuer le LS. Si la section longueur de l'entête de la requête est à 0 alors le chemin par défaut est celui depuis où le serveur à été lancé. Le code pour récupérer le chemin est le suivant :<syntaxhighlight lang="c" line="1">
unsigned char chemin[longueur+1];
for (int i=0 ; i<longueur ; i++) {
chemin[i] = message[i+3]; // Recuperation du chemin
}
chemin[longueur] = '\0';
</syntaxhighlight>Par la suite le dossier est correspondant au chemin est ouvert via la fonction opendir puis chaque entrée du dossier est récupérée et engendre un message de réponse du serveur (un message par entrée).<syntaxhighlight lang="c" line="1">
while ((entree = readdir(dossier)) != NULL) {
// Message UDP pour chaque entree
strcpy(contenu, entree->d_name);
printf(" %s ", contenu);
reponse[OPERATION] = REPONSE_LS;
reponse[LONGUEUR] = strlen(contenu);
reponse[NUMERO] = num++;
for (int i=0 ; i<reponse[LONGUEUR] ; i++) {
reponse[i+3] = contenu[i];
}
messageUDP(IP_CARTE, PORT_CARTE, (unsigned char *)reponse, (int)reponse[LONGUEUR] + LONGUEUR_ENTETE);
}
</syntaxhighlight>OPERATION est la premiére section et vaut donc 0, LONGUEUR 2 et NUMERO 3. OPERATION est une réponse à un LS donc 0x11, LONGUEUR dépend de l'entrée du dossier et NUMERO augmente de 1 à chaque entrée. Enfin on remplie la requête du nom de l'entrée et on envoie le message.

Enfin une fois tous les entrées envoyées on envoie un dernier message UDP de type reponse_LS de longueur 0 et de numéro 0 afin d'indiquer que la transmission est terminée et ce correctement.

===== Traitement READ =====
Cette requête est très proche de celle du LS. On commence par récupérer le chemin avec le nom du fichier de la même façon que pour le LS. Cependant ici si le message ne contient pas de chemin aucun traitement ne sera effectué. Pour ouvrir le fichier on utilise la fonction fopen. Chaque ligne, récupérée via fgets, engendre une réponse UDP formulée de la même façon que pour les entrées de dossier. Evidemment l'opération est de type réponse read soit 0x12. Enfin un message similaire de fin de transmission est envoyé seulement si il n'y a pas eu d'erreur et que la dernière ligne à été lue.

===== Traitement WRITE =====
Cette requête est un peu plus complexe à gérer niveau serveur par conséquent que je vais commencer par décrire le principe de la fonction.

* La carte réseau envoie un message de type début de write (OPERATION 0x03) avec le chemin et nom du fichier que le serveur va récupérer et mémoriser.

* La carte réseau envoie un massage pour chaque ligne à écrite (OPERATION 0x13). Le serveur va vérifier si la section NUMERO des entêtes se suivent afin de s'assurer que aucun message n'est été perdu.

* La carte réseau envoie un message de type fin de write (OPERATION 0x013) mais de numéro 0. Le serveur indique que tout s'est bien passé en envoyant une réponse au write (OPERATION 0x23) donc le contenu est 0x00.
* Si un message a été perdu un message d'erreur est envoyé de la par du serveur (OPERATION 0x23) de contenu 0x01.

La récupération du contenu de la requête est du même type que celle du LS. Les messages de retour sont construits de la même façon que pour le message de retour du LS. Enfin on utilise fopen une nouvelle fois pour ouvrir le fichier, fwrite pour y écrire et fclose pour le fermer.

==== Préparation du test ====
Avant de pouvoir tester notre serveur avec la carte réseau (ce qui n'aura jamais été fait car la carte réseau n'envoie rien) nous avons souhaité validé le fonctionnement du serveur en simulant des requêtes de la carte réseau. On voit ce que le serveur fait via des printf et en créant un autre serveur (plus rudimentaire) on peut vérifier que le serveur répond correctement. Sur notre git le dossier testUDP est consacré à cette phase de tests.

* Les requêtes simulées de la carte réseau sont envoyées sur l'IP loopback de la machine et sur le port du serveur (ici 4242)
* Le serveur écoute le port serveur (4242) et répond en loopback sur le port du serveur qui simule la carte (ici 3333)
* Le serveur qui simule la carte écoute le port 3333

On lance ces différents serveurs et les requêtes via les commandes du fichiers fonctionnement.txt de notre git.

==== Tests ====
Le test est réalisé via 3 commandes :

* LS sans chemin
* WRITE de 3 lignes dans un fichier test.txt créé par la commande
* READ du fichier test.txt

[[Fichier:Test1.png|centré|vignette|Requêtes envoyées]]
[[Fichier:Test2.png|centré|vignette|Traitement du serveur]]
[[Fichier:Test3.png|centré|vignette|Réponse reçu du serveur]]On peut constater que les tests fonctionnent. En effet le serveur a envoyé 9 res ls (8 entrées + fin de transmissions), 1 res write (fin d'écriture correcte) et 6 res read (5 lignes + 1 fin de transmissions).

== Conclusion ==
La partie shield et ordonnanceur est finie et testée. La carte réseau n'a pas pu être finie par manque de temps. En faisant allumer une LED lorsqu'elle reçoit une trame Ethernet, UDP, STMP nous avons constaté qu'elle reçoit correctement ces protocoles. Cependant lorsque que nous avons voulu modifier la LUFA pour qu'une LED en plus s'allume lorsque UDP contient protocole antique cela ne fonctionnait pas. La carte ne trouvait jamais le protocole Antique. La communication avec la carte mère (shield) n'a pas été faite par manque de temps (cependant la communication SPI est vérifiée à l'étape de l'ordonnanceur). Le serveur côté PC qui doit communiquer avec la carte réseau est fini et testé.

Notre problème peut venir du fait que l'atmega32u4 n'a pas assez de mémoire. Il ne faut donc pas choisir ce micro contrôleur pour ce projet mais un avec plus de mémoire.

SE4Binome2025-1

2026-01-04T16:08:03Z

Abiernac :

SE4Binome2025-1

2026-01-04T16:00:22Z

Abiernac :

= Shield Arduino =
== Hardware ==
Afin de tester notre futur carte réseau, nous avons fait un shield d'arduino qui prendra le rôle de la carte mère durant.
=== Schématique ===
Nous nous sommes évidemment aider de la datasheet de l'atmega328p ainsi que celle de l'arduino uno afin de sélectionner les bon pins.
[[Fichier:Atmel-7810-Automotive-Microcontrollers-ATmega328P Datasheet.pdf|centré|vignette|Datasheet ATmega328p]]
[[Fichier:A000066-datasheet.pdf|centré|vignette|Datasheet Arduino Uno R3]]
Plus précisément nous nous inspirons très fortement du schéma page 10 de la datasheet de l'arduino :
[[Fichier:Screenshot 2025-11-07 11-08-46.png|centré|vignette|Schéma pinouts]]
Nous sommes donc parti de l'exemple fourni par Mr Redon. Mais nous avons utilisé une template disponible dans kicad permettant de créer des shields d'arduino Uno R3.[[Fichier:Tyetyuy.png|vignette|Schématique shield arduino|centré|438x438px]]
=== Routage ===
Au niveau du routage, nous avons tenté de faire simple (sans trop abuser sur les vias. Nous avons positionner le lecteur de carte sd au bord de la carte afin de ne pas avoir de problèmes avec d'autres composants lorsque nous voudrons mettre ou enlever la carte sd.
[[Fichier:Routage shield arduino.png|vignette|Routage shield arduino|centré|434x434px]]

===Soudage===
La schématique et le routage terminés, nous avons soudé les différents pins permettant de souder la carte shield à l'arduino, le reste n'étant pas forcément utile pour le moment (il est important de noter que notre shield est arrivé avec des composants pré-soudés).
[[Fichier:Shield soudage de base .jpg|centré|vignette]]

===Tests===
====Leds====

Il faudra ensuite faire des test d'allumage des leds, afin de vérifier le bon fonctionnement du shield
[[Fichier:VID leds.mp4|centré|vignette]]

Les leds fonctionnent à merveille.

====Carte SD====

Nous vérifions maintenant la carte sd (même si elle nous sera inutile pour notre projet)

Nous utilisons le programme fourni par arduino qui permet de récuopéré les informatiuons de la carte sd.
[[Fichier:Test sd card.png|centré|vignette]]
La carte SD est bien identifié, le lecteur de carte fonctionne donc normalement.

== Software ==
=== Ordonnanceur ===
[à completer et commenter , seulement des codes pour le moment !!!!]
==== Ordonnanceur basique ====
La première étape consiste à définir la structure d'un process, il sera composé :

-d'un pointeur de pile

-de l'adresse de la fonction

-d'un temps de sommeil

-d'un état : 0 pour en cours et 1 pour terminé ou vide

Ces deux derniers points nous servirons plus tard.<syntaxhighlight lang="c" line="1">
typedef struct {
uint16_t stackPointer;
void (*functionAddress)(void);
int sleep_time;
int state;
} process;

</syntaxhighlight>On initialise donc notre tableau de processus de la façon suivante : <syntaxhighlight lang="c" line="1">
process Tasks_list[NBTASKS] = {
{0, led1_blink, 0,0},
...
};

</syntaxhighlight>Concernant les fonction liés leds, on utilise une simple boucle while contenant un changement d'état <syntaxhighlight lang="c" line="1">
void led_init() {
...
}
void led1_blink() {
while(1) {
PORTC ^= (1<<PLED1);
_delay_ms(100);
}
}
void led2_blink() {
...
</syntaxhighlight>La fonction init_stackPointer_tasks() permet de diviser la pile "réel" en plusieurs piles pour chaque processus. Ces sous piles commence à la position FIRST_STACK_POSITION, afin de ne pas réécrire par dessus des données. Toutes les sous piles diposent d'une même taille de pile STACK_LENGTH.

La fonction init_piles() initialise correctement la pile avec le tableau de processus si le processus est actif.<syntaxhighlight lang="c" line="1">
void init_stackPointer_tasks(int Cprocess) { //initialise le pointer de pile
if(Tasks_list[Cprocess].state == 0) {
Tasks_list[Cprocess].stackPointer = FIRST_STACK_POSITION - (Cprocess * STACK_LENGTH);
}
}

void init_piles(int Cprocess){ //initilalise la pile
if(Tasks_list[Cprocess].state == 0) {
int save = SP;
SP = Tasks_list[Cprocess].stackPointer;
uint16_t address = (uint16_t)Tasks_list[Cprocess].functionAddress;
asm volatile("push %0" : : "r" (address & 0x00ff) );
asm volatile("push %0" : : "r" ((address & 0xff00)>>8) );
SAVE_REGISTERS();
Tasks_list[Cprocess].stackPointer = SP;
SP = save;
}
}

</syntaxhighlight>le scheduler permet de passer à la tâche suivante<syntaxhighlight lang="c" line="1">
void scheduler() {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}

</syntaxhighlight>l'atmega328p ne dispose pas de de fonction en assembleur permettant de push ou de pop tout les registres. on doit donc le faire un par un.

On défini alors les macros suivantes : <syntaxhighlight lang="c" line="1">
#define SAVE_REGISTERS() \
asm volatile ( \
"push r0 \n\t" \
...\
)

#define RESTORE_REGISTERS() \
asm volatile ( \
"pop r31 \n\t" \
...\
)

</syntaxhighlight>L'ISR gère les interruptions, en commençant par sauvegarder l'état de la pile ainsi que le stack pointeur propre au processus qui s'interrompt. L'appel au schedruler permet de changer de processus pour cela il faut restorer le stack pointer propre au nouveau processus actif et de la pile liée à ce processus. La dernière ligne arrête l'ISR.<syntaxhighlight lang="c" line="1">
ISR(TIMER1_COMPA_vect, ISR_NAKED) {
SAVE_REGISTERS();
Tasks_list[Current_task].stackPointer = SP;
scheduler();
SP = Tasks_list[Current_task].stackPointer;
RESTORE_REGISTERS();
asm volatile("reti");
}
</syntaxhighlight>
=====test=====
Les processus de clignotement de leds ont tous un délai d'attente différent, l'interruption se produit toutes les millisecondes. On obtient ceci :[[Fichier:Ordonnanceur basique.mp4|centré|vignette]]Il est intéressant de remarqué que la vitesse à laquelle les leds changent d'état ne correspond pas au délai qui leur à été donné. Cela parait logique puisque l'interruption met la fonction _delay_ms en pause, ainsi la vitesse se voit divisé par le nombre de processus actif.

====Ajout d'un système d'endormissement des processus====

La fonction wait va permettre d'endormir un processus, elle va donné un temps de sommeil au processus puis lancer une interruption (car on veut changer de processus directement après que le précédent ait été endormi).<syntaxhighlight lang="c" line="1">
void wait(int time) { // met un process en veille pour une durée donné
// valeur max de time 32000 car int sur atmega328p code sur 16 bits donc 32000 max
cli();
Tasks_list[Current_task].sleep_time = time;
TCNT1=0;
sei();
TIMER1_COMPA_vect();

</syntaxhighlight>Pour verifier si un processus a besoin d'être lancé, on ajoute une boucle while dans le scheduler afin de vérifier si il y a un temps de sommeil. Le scheduler va aussi servir à diminuer le temps de sommeil de tout les processus (avec un minimum de 0).<syntaxhighlight lang="c" line="1">
void scheduler() {
for (int i=0 ; i<NBTASKS ; i++) {
if (Tasks_list[i].sleep_time - SLEEP_DEC < 0) {
Tasks_list[i].sleep_time = 0;
} else {
Tasks_list[i].sleep_time -= SLEEP_DEC;
}
}

do {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}
} while (Tasks_list[Current_task].sleep_time > 0);
}

</syntaxhighlight>
====Tableau dynamique des tâches====

En premier lieu on va initialiser les état de tout les cases du tableau de processus. On choisit 1 la case est vide, 0 sinon.<syntaxhighlight lang="c" line="1">
void init_state() { //initialise state
for (int i= 0; i<NBTASKS; i++) {
if (Tasks_list[i].functionAddress == NULL) {
Tasks_list[i].state = 1;
}
else {
Tasks_list[i].state = 0;
}
}
}
</syntaxhighlight>Nous avons programmé deux fonction d'arrêt et une fonction d'ajout de processus :

-finish stop le processus en cours et le supprime de tableau, puis lance une interruption

-kill stop un processus donné et le supprime du tableau

-add ajoute un processus sur la première case vide du tableau, initialise son pointeur de position et sa pile.

Pour finish et kill, on met le temps de sommeil à 0 au cas où on arrête un processus endormi. C'est une mesure de sécurité pour finish, mais une obligation pour kill.<syntaxhighlight lang="c" line="1">
void finish() { //supprime un process lorsque celui-ci est terminé
cli();
Tasks_list[Current_task].state =1;
Tasks_list[Current_task].sleep_time = 0;
Tasks_list[Current_task].functionAddress = NULL;
TCNT1=0;
sei();
TIMER1_COMPA_vect();
}

void kill(void (*function)(void)) { //tue le process passé en paramètre
cli();
for(int i = 0; i<NBTASKS; i++) {
if(Tasks_list[i].functionAddress == function) {
Tasks_list[i].state =1;
Tasks_list[i].sleep_time = 0;
Tasks_list[i].functionAddress = NULL;
}
}
sei();
}

void add(void (*newFunction)(void)) { //ajoute un process
cli();
int i =0;
while(Tasks_list[i].state != 1) {
i++;
}
Tasks_list[i].functionAddress = newFunction;
Tasks_list[i].state = 0;
init_stackPointer_tasks(i);
init_piles(i);

sei();

}
</syntaxhighlight>Il suffit maintenant de modifier le scheduler afin de ne pas prendre les processus terminé, puis utiliser add, finish et kill dans les fonctions choisis.

=====test=====
Pour tester les fonction add et finish, on fait le test suivant :

-on créer un process qui ajoute le process led2_blink (avec add) au bout d'un certain temps

-le process led2_blink s'arrête (avec finish) au bout de 20 changement d'état (c'est à dire 10 clignotement).

on obtient le résultat suivant :[[Fichier:Demo fonction add et finish.mp4|centré|vignette]]
====lecture et écriture sur le port série====
Afin de lire et écrire sur le port série, on utilise les fonctions USART_Init, USART_Transmit et USART_Receive vu en cours de microP l'année précédente. Le but sera donc d'écrire le message qui vient d'être reçu, on utilise donc le processus suivant :<syntaxhighlight lang="c" line="1">
void Serial_Message(){
unsigned char data;
while(1){
data = USART_Receive();
USART_Transmit(data);
}
}
</syntaxhighlight>

=====test=====
Pour tester notre processus de communication, on utilise minicom.[[Fichier:Test lecture et écriture port série.mp4|centré|vignette]]On notera que si la période entre les interruptions est trop élevé, certains caractères ne seront pas lus.

====afficheur 7 segments====
<syntaxhighlight lang="c" line="1">
void seven_seg() {
while (1) {
spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x7E);
spi_echange(0b1101111);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);

spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x76);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);
}
}
</syntaxhighlight>Le processus seven_seg est ajouté au tableau des processus. Avant d'échanger en spi il faut activer la communication, et la désactiver après l'échange. La ligne 4 permet de sélectionner le 7 seg sur lequel on souhaite modifier l'affichage. La ligne 5 permet d'afficher le chiffre 9. Enfin la ligne 11 permet de clear le display. Voir tableau ci-dessous.
[[Fichier:Tab 7 seg sparkfun.png|centré|vignette]]
<syntaxhighlight lang="c" line="1">
void spi_init(void) { // Initialisation du bus SPI
SPI_DDR |= (1<<SPI_MOSI)|(1<<SPI_SCK); // Définition des sorties
SPI_DDR &= ~(1<<SPI_MISO); // Définition de l'entrée
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1); // Activation SPI (SPE) en état maître (MSTR)
// horloge F_CPU/64 (SPR1=1,SPR0=0)
SPI_DDR |= (1<<CS1) | (1<<CS4);;
DDRD |= (1<<CS5) | (1<<CS6);
DDRC |= (1<<CS2) | (1<<CS3);
}

void spi_activer(uint16_t port, uint8_t cs) { // Activer le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg &= ~(1<<cs); // Ligne SS à l'état bas
}

void spi_desactiver(uint16_t port, uint8_t cs) { // Désactiver le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg |= (1<<cs); // Ligne SS à l'état haut
}

uint8_t spi_echange(uint8_t envoi) { // Communication sur le bus SPI
SPDR = envoi; // Octet a envoyer
while(!(SPSR & (1<<SPIF))); // Attente fin envoi (drapeau SPIF du statut)
return SPDR; // Octet reçu
}

</syntaxhighlight>Afin de rendre nos fonctions les plus réutilisables possibles nous avons passer en paramètre le port ainsi que le CS qui correspond au slave select. Le type réel du port est volatile uint8* cependant le compilateur n'accepte que le uint16* ce qui explique le cast un peu étrange.

=====Implémentation=====
[[Fichier:Video7segvideo.mp4|vignette|centré]]L'implémentation correspond à nos attentes, seul un 7 seg affiche le chiffre 9.

====choix du processus sur le port série====

afin de pouvoir démontrer le bon fonctionnement de la partie dynamique, on décide de pouvoir ajouter et tuer des processus à partir des touches du clavier. On utilisera donc les fonction de l'USART défini plus au au travers de la fonction suivante:<syntaxhighlight lang="c">
void call_process() {
unsigned char data;
while(1) {
data = USART_Receive();
if(data == '1') {
add(led1_blink);
}
...
else if(data == '6') {
kill(led1_blink);
}
...
USART_Transmit(data);
}
}

</syntaxhighlight>On remarquera que c'est une sorte d'amélioration de la fonction Serial_Message vu plus haut.

Cette fonction aura la fonction de process de base, toujours présent dans l'ordonnaceur.

=====Démonstation=====
[[Fichier:Process via USART.mp4|centré|vignette]]

Ici on lance les processus ledN_blink avec les touches 1 à 5 et on les tues avec les touches 6 à 0. Pour le 7 segments, on l'ajoute avec s et le tue avec d.

=Carte Réseau=
Lors de la répartition des tâches, nous avons opté pour la carte réseau.
==Description==
Le sujet nous permettait de choisir parmi plusieurs microcontrôleurs. Nous avons retenu l’ATmega32U4, qui nous semble représenter un juste milieu entre l’ATmega16U2 et l’AT90USB.
==Hardware==
Notre carte intègre des LED permettant d’afficher différents états de communication (que nous définirons ultérieurement).

À la demande de M. Redon, nous avons ajouté un MAX232 ainsi que des connecteurs DB9 et DB25. Nous espérons que ces éléments pourront être utiles.

En dehors de ça, la carte reste assez basique car son composant principal reste l'ATmega.
===Schématque===
les broches PF n'étant pas utilisé, on les branches à un connecteur 6x1, notre carte pourra donc être utiliser pour d'autre projet si nécéssaire.

On fait le choix d'utiliser 5 leds pour la connections, 1 led de power et 1 pour la connection ISP.[[Fichier:Schématique CReseau.png|vignette|540x540px|centré]]
===Routage===
[[Fichier:Routage Creseau.png|vignette|521x521px|centré]]Après avoir soudé les composants pricnipaux. il est temps de passer à la partie programmation de la carte.

==Programmation==

Notre carte utilsant un USB, on va donc la faire passer pour une carte réseau en utilisant la demo RNDIS de la LUFA.

Il est important de noter que nous avons choisi un Atmega32u4. Ainsi des modification devrons être apporté à la taille des paquets ethernet et sur le choix des protocoles.

===Protocoles impémentés===

La demo RNDISEthernet de la LUFA inclut les protocole suivant

* ARP : Résolution d'adresses MAC.
* IP : Gestion des paquets IPv4.
* ICMP : Messages de contrôle (ping).
* TCP : Communication fiable (exemple : serveur TCP).
* UDP : Communication non fiable (exemple : serveur UDP).
* DHCP : Attribution dynamique d'adresse IP.

Aussi, on remarquera que la démo utilise un modèle en quatre couche : Le modèle TCP/IP.

le sujet nous propose trois possibilité :

* viser Ethernet
* viser UDP
* viser TCP

En regardant ce qui à été fait les années précédentes, on a remarqué que les groupes partaient principalement sur la première option. Nous nous avons décidé de viser UDP.

Ainsi, afin de d'alléger notre code pour le faire rentrer dans notre carte, nous avons choisi de ne pas inclure le protocole TCP et de modifier la taille max de paquets ethernet à 400 octets.

Il nous restera donc de l'espace pour recevoir des paquets Ethernet :<syntaxhighlight>
avr-size --mcu=atmega32u4 --format=avr RNDISEthernet.elf
AVR Memory Usage
----------------
Device: atmega32u4

Program: 9434 bytes (28.8% Full)
(.text + .data + .bootloader)

Data: 1037 bytes (40.5% Full)
(.data + .bss + .noinit)
</syntaxhighlight>Une fois la lufa réduite et flashé, on donne une adresse ip à notre inteface avec ip link eth2 up et ip address add 10.0.0.1/24 dev eth2. on test un ping sur l'adresse ip de la carte (10.0.0.2).[[Fichier:Ping creseau.mp4|centré|vignette]]
[[Fichier:Ping allume led.mov|vignette|centré]]Le premier test que nous décidons de faire, afin de vérifié notre comprehesion du code de la LUFA est de de faire clignioter si la carte reçoit un paquet ethernet, pour celà on ajoute l'allumage de la led dans la fonction EthernetTask du fichier principal ( RNDISEthernet.c) :[[Fichier:Ping allume led.mov|vignette|La led s'éteint à chaque ping reçue|centré]]

===Création du protocole===

En plus de pouvoir communiquer, notre carte dois être capable d'effectuer 3 fonction.

On décide donc de créer un protocole (nommé ProtocolAntique) dont l'un des octet va transporter le choix de la focntion, le modèle du protocole sera le suivant : <syntaxhighlight lang="c">
typedef struct {
uint8_t operation; /* 0x01 ls, 0x02 send, 0x03 recieve */
uint8_t longeur;
uint8_t numero;
} ProtocolAntique_Header_t;

</syntaxhighlight>Comme nous avons choisit de viser UDP, le protocole doit pocédé un numéro de port, on choisit un numéro supérieur à 1023 pour ne pas devoir passer en root, Le port choisi est 3333.

Dans le programme UDP.c on peut maintenant inclure notre protocole de la façon suivante :<syntaxhighlight lang="c">
switch (SwapEndian_16(UDPHeaderIN->DestinationPort))
{
/*
case UDP_PORT_DHCP_REQUEST:
RetSize = DHCP_ProcessDHCPPacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;
*/
case UDP_PORT_PROTOCOL_ANTIQUE:
RetSize = ProtocolAntique_ProcessProtocolAntiquePacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;

</syntaxhighlight>

===Partie Application===

(A compléter)

Afin de tester la reception du paquet UDP, on fait à nouveau clignotter une led quand un paquet UDP et reçu (video)

=== Partie serveur ===
Lorsque la carte mère a besoin de faire une action (ls, read, write) sur l'ordinateur qui est connecté en USB via la carte réseau elle transmet son besoin à la carte réseau. Cette dernière créer un requête UDP qui encapsule notre protocole (ProtocolAntique) et la transmet donc au PC. Sur ce dernier un serveur doit donc fonctionner afin de recevoir les rêquetes de la carte réseau, les traiter et y répondre. Cette partie est donc consacrée au code ainsi qu'aux tests du serveur.

==== Code du serveur ====
Pour pouvoir fonctionner correctement le serveur doit initialiser une socket UDP et ensuite doit lancer un fonctionne qui boucle indéfiniment afin de recevoir chaque message UDP. Cette partie n'a pas été codé par nous et est trouvable sur rex.plil.fr (Département IMA -> support de cours de la programmation réseau -> exemple de serveur 2/2). Il en est de même du code la fonction pour envoyer un message UDP qui est trouvable au même endroit section exemple de client 2/2.

La carte réseau est toujours à l'initiative des requêtes, par conséquent le serveur commence par recevoir un requête et la traiter. Pour ce faire à chaque requête reçue par la fonction boucleServeurUDP la fonction traitementMessageUDP est appelée.<syntaxhighlight lang="c" line="1">
int traitementMessageUDP (unsigned char* message, int nboctets);
</syntaxhighlight>Cette fonction s'occupe d'extraire la partie opération de l'entête de protocolAntique et d'appeler la fonction de traitement correspondante à l'opération
{| class="wikitable"
!Opération
!Requête
!Fonction appelée
|-
|0x01
|LS
|void traitement_ls (unsigned char*);
|-
|0x02
|READ
|void traitement_read (unsigned char*);
|-
|0x03
|WRITE (début)
|void traitement_write (unsigned char*);
|-
|0x13
|WRITE (données et fin)
|void traitement_write (unsigned char*);
|}

===== Traitement LS =====
La fonction traitement_ls commence par récupérer le chemin (relatif ou absolu) où effectuer le LS. Si la section longueur de l'entête de la requête est à 0 alors le chemin par défaut est celui depuis où le serveur à été lancé. Le code pour récupérer le chemin est le suivant :<syntaxhighlight lang="c" line="1">
unsigned char chemin[longueur+1];
for (int i=0 ; i<longueur ; i++) {
chemin[i] = message[i+3]; // Recuperation du chemin
}
chemin[longueur] = '\0';
</syntaxhighlight>Par la suite le dossier est correspondant au chemin est ouvert via la fonction opendir puis chaque entrée du dossier est récupérée et engendre un message de réponse du serveur (un message par entrée).<syntaxhighlight lang="c" line="1">
while ((entree = readdir(dossier)) != NULL) {
// Message UDP pour chaque entree
strcpy(contenu, entree->d_name);
printf(" %s ", contenu);
reponse[OPERATION] = REPONSE_LS;
reponse[LONGUEUR] = strlen(contenu);
reponse[NUMERO] = num++;
for (int i=0 ; i<reponse[LONGUEUR] ; i++) {
reponse[i+3] = contenu[i];
}
messageUDP(IP_CARTE, PORT_CARTE, (unsigned char *)reponse, (int)reponse[LONGUEUR] + LONGUEUR_ENTETE);
}
</syntaxhighlight>OPERATION est la premiére section et vaut donc 0, LONGUEUR 2 et NUMERO 3. OPERATION est une réponse à un LS donc 0x11, LONGUEUR dépend de l'entrée du dossier et NUMERO augmente de 1 à chaque entrée. Enfin on remplie la requête du nom de l'entrée et on envoie le message.

Enfin une fois tous les entrées envoyées on envoie un dernier message UDP de type reponse_LS de longueur 0 et de numéro 0 afin d'indiquer que la transmission est terminée et ce correctement.

===== Traitement READ =====
Cette requête est très proche de celle du LS. On commence par récupérer le chemin avec le nom du fichier de la même façon que pour le LS. Cependant ici si le message ne contient pas de chemin aucun traitement ne sera effectué. Pour ouvrir le fichier on utilise la fonction fopen. Chaque ligne, récupérée via fgets, engendre une réponse UDP formulée de la même façon que pour les entrées de dossier. Evidemment l'opération est de type réponse read soit 0x12. Enfin un message similaire de fin de transmission est envoyé seulement si il n'y a pas eu d'erreur et que la dernière ligne à été lue.

===== Traitement WRITE =====
Cette requête est un peu plus complexe à gérer niveau serveur par conséquent que je vais commencer par décrire le principe de la fonction.

* La carte réseau envoie un message de type début de write (OPERATION 0x03) avec le chemin et nom du fichier que le serveur va récupérer et mémoriser.

* La carte réseau envoie un massage pour chaque ligne à écrite (OPERATION 0x13). Le serveur va vérifier si la section NUMERO des entêtes se suivent afin de s'assurer que aucun message n'est été perdu.

* La carte réseau envoie un message de type fin de write (OPERATION 0x013) mais de numéro 0. Le serveur indique que tout s'est bien passé en envoyant une réponse au write (OPERATION 0x23) donc le contenu est 0x00.
* Si un message a été perdu un message d'erreur est envoyé de la par du serveur (OPERATION 0x23) de contenu 0x01.

La récupération du contenu de la requête est du même type que celle du LS. Les messages de retour sont construits de la même façon que pour le message de retour du LS. Enfin on utilise fopen une nouvelle fois pour ouvrir le fichier, fwrite pour y écrire et fclose pour le fermer.

==== Préparation du test ====
Avant de pouvoir tester notre serveur avec la carte réseau (ce qui n'aura jamais été fait car la carte réseau n'envoie rien) nous avons souhaité validé le fonctionnement du serveur en simulant des requêtes de la carte réseau. On voit ce que le serveur fait via des printf et en créant un autre serveur (plus rudimentaire) on peut vérifier que le serveur répond correctement. Sur notre git le dossier testUDP est consacré à cette phase de tests.

* Les requêtes simulées de la carte réseau sont envoyées sur l'IP loopback de la machine et sur le port du serveur (ici 4242)
* Le serveur écoute le port serveur (4242) et répond en loopback sur le port du serveur qui simule la carte (ici 3333)
* Le serveur qui simule la carte écoute le port 3333

On lance ces différents serveurs et les requêtes via les commandes du fichiers fonctionnement.txt de notre git.

==== Tests ====
Le test est réalisé via 3 commandes :

* LS sans chemin
* WRITE de 3 lignes dans un fichier test.txt créé par la commande
* READ du fichier test.txt

[[Fichier:Test1.png|centré|vignette|Requêtes envoyées]]
[[Fichier:Test2.png|centré|vignette|Traitement du serveur]]
[[Fichier:Test3.png|centré|vignette|Réponse reçu du serveur]]On peut constater que les tests fonctionnent. En effet le serveur a envoyé 9 res ls (8 entrées + fin de transmissions), 1 res write (fin d'écriture correcte) et 6 res read (5 lignes + 1 fin de transmissions).

SE4Binome2025-1

2026-01-04T15:57:05Z

Abiernac :

= Shield Arduino =
== Hardware ==
Afin de tester notre futur carte réseau, nous avons fait un shield d'arduino qui prendra le rôle de la carte mère durant.
=== Schématique ===
Nous nous sommes évidemment aider de la datasheet de l'atmega328p ainsi que celle de l'arduino uno afin de sélectionner les bon pins.
[[Fichier:Atmel-7810-Automotive-Microcontrollers-ATmega328P Datasheet.pdf|centré|vignette|Datasheet ATmega328p]]
[[Fichier:A000066-datasheet.pdf|centré|vignette|Datasheet Arduino Uno R3]]
Plus précisément nous nous inspirons très fortement du schéma page 10 de la datasheet de l'arduino :
[[Fichier:Screenshot 2025-11-07 11-08-46.png|centré|vignette|Schéma pinouts]]
Nous sommes donc parti de l'exemple fourni par Mr Redon. Mais nous avons utilisé une template disponible dans kicad permettant de créer des shields d'arduino Uno R3.[[Fichier:Tyetyuy.png|vignette|Schématique shield arduino|centré|438x438px]]
=== Routage ===
Au niveau du routage, nous avons tenté de faire simple (sans trop abuser sur les vias. Nous avons positionner le lecteur de carte sd au bord de la carte afin de ne pas avoir de problèmes avec d'autres composants lorsque nous voudrons mettre ou enlever la carte sd.
[[Fichier:Routage shield arduino.png|vignette|Routage shield arduino|centré|434x434px]]

===Soudage===
La schématique et le routage terminés, nous avons soudé les différents pins permettant de souder la carte shield à l'arduino, le reste n'étant pas forcément utile pour le moment (il est important de noter que notre shield est arrivé avec des composants pré-soudés).
[[Fichier:Shield soudage de base .jpg|centré|vignette]]

===Tests===
====Leds====

Il faudra ensuite faire des test d'allumage des leds, afin de vérifier le bon fonctionnement du shield
[[Fichier:VID leds.mp4|centré|vignette]]

Les leds fonctionnent à merveille.

====Carte SD====

Nous vérifions maintenant la carte sd (même si elle nous sera inutile pour notre projet)

Nous utilisons le programme fourni par arduino qui permet de récuopéré les informatiuons de la carte sd.
[[Fichier:Test sd card.png|centré|vignette]]
La carte SD est bien identifié, le lecteur de carte fonctionne donc normalement.

== Software ==
=== Ordonnanceur ===
[à completer et commenter , seulement des codes pour le moment !!!!]
==== Ordonnanceur basique ====
La première étape consiste à définir la structure d'un process, il sera composé :

-d'un pointeur de pile

-de l'adresse de la fonction

-d'un temps de sommeil

-d'un état : 0 pour en cours et 1 pour terminé ou vide

Ces deux derniers points nous servirons plus tard.<syntaxhighlight lang="c" line="1">
typedef struct {
uint16_t stackPointer;
void (*functionAddress)(void);
int sleep_time;
int state;
} process;

</syntaxhighlight>On initialise donc notre tableau de processus de la façon suivante : <syntaxhighlight lang="c" line="1">
process Tasks_list[NBTASKS] = {
{0, led1_blink, 0,0},
...
};

</syntaxhighlight>Concernant les fonction liés leds, on utilise une simple boucle while contenant un changement d'état <syntaxhighlight lang="c" line="1">
void led_init() {
...
}
void led1_blink() {
while(1) {
PORTC ^= (1<<PLED1);
_delay_ms(100);
}
}
void led2_blink() {
...
</syntaxhighlight>La fonction init_stackPointer_tasks() permet de diviser la pile "réel" en plusieurs piles pour chaque processus. Ces sous piles commence à la position FIRST_STACK_POSITION, afin de ne pas réécrire par dessus des données. Toutes les sous piles diposent d'une même taille de pile STACK_LENGTH.

La fonction init_piles() initialise correctement la pile avec le tableau de processus si le processus est actif.<syntaxhighlight lang="c" line="1">
void init_stackPointer_tasks(int Cprocess) { //initialise le pointer de pile
if(Tasks_list[Cprocess].state == 0) {
Tasks_list[Cprocess].stackPointer = FIRST_STACK_POSITION - (Cprocess * STACK_LENGTH);
}
}

void init_piles(int Cprocess){ //initilalise la pile
if(Tasks_list[Cprocess].state == 0) {
int save = SP;
SP = Tasks_list[Cprocess].stackPointer;
uint16_t address = (uint16_t)Tasks_list[Cprocess].functionAddress;
asm volatile("push %0" : : "r" (address & 0x00ff) );
asm volatile("push %0" : : "r" ((address & 0xff00)>>8) );
SAVE_REGISTERS();
Tasks_list[Cprocess].stackPointer = SP;
SP = save;
}
}

</syntaxhighlight>le scheduler permet de passer à la tâche suivante<syntaxhighlight lang="c" line="1">
void scheduler() {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}

</syntaxhighlight>l'atmega328p ne dispose pas de de fonction en assembleur permettant de push ou de pop tout les registres. on doit donc le faire un par un.

On défini alors les macros suivantes : <syntaxhighlight lang="c" line="1">
#define SAVE_REGISTERS() \
asm volatile ( \
"push r0 \n\t" \
...\
)

#define RESTORE_REGISTERS() \
asm volatile ( \
"pop r31 \n\t" \
...\
)

</syntaxhighlight>L'ISR gère les interruptions, en commençant par sauvegarder l'état de la pile ainsi que le stack pointeur propre au processus qui s'interrompt. L'appel au schedruler permet de changer de processus pour cela il faut restorer le stack pointer propre au nouveau processus actif et de la pile liée à ce processus. La dernière ligne arrête l'ISR.<syntaxhighlight lang="c" line="1">
ISR(TIMER1_COMPA_vect, ISR_NAKED) {
SAVE_REGISTERS();
Tasks_list[Current_task].stackPointer = SP;
scheduler();
SP = Tasks_list[Current_task].stackPointer;
RESTORE_REGISTERS();
asm volatile("reti");
}
</syntaxhighlight>
=====test=====
Les processus de clignotement de leds ont tous un délai d'attente différent, l'interruption se produit toutes les millisecondes. On obtient ceci :[[Fichier:Ordonnanceur basique.mp4|centré|vignette]]Il est intéressant de remarqué que la vitesse à laquelle les leds changent d'état ne correspond pas au délai qui leur à été donné. Cela parait logique puisque l'interruption met la fonction _delay_ms en pause, ainsi la vitesse se voit divisé par le nombre de processus actif.

====Ajout d'un système d'endormissement des processus====

La fonction wait va permettre d'endormir un processus, elle va donné un temps de sommeil au processus puis lancer une interruption (car on veut changer de processus directement après que le précédent ait été endormi).<syntaxhighlight lang="c" line="1">
void wait(int time) { // met un process en veille pour une durée donné
// valeur max de time 32000 car int sur atmega328p code sur 16 bits donc 32000 max
cli();
Tasks_list[Current_task].sleep_time = time;
TCNT1=0;
sei();
TIMER1_COMPA_vect();

</syntaxhighlight>Pour verifier si un processus a besoin d'être lancé, on ajoute une boucle while dans le scheduler afin de vérifier si il y a un temps de sommeil. Le scheduler va aussi servir à diminuer le temps de sommeil de tout les processus (avec un minimum de 0).<syntaxhighlight lang="c" line="1">
void scheduler() {
for (int i=0 ; i<NBTASKS ; i++) {
if (Tasks_list[i].sleep_time - SLEEP_DEC < 0) {
Tasks_list[i].sleep_time = 0;
} else {
Tasks_list[i].sleep_time -= SLEEP_DEC;
}
}

do {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}
} while (Tasks_list[Current_task].sleep_time > 0);
}

</syntaxhighlight>
====Tableau dynamique des tâches====

En premier lieu on va initialiser les état de tout les cases du tableau de processus. On choisit 1 la case est vide, 0 sinon.<syntaxhighlight lang="c" line="1">
void init_state() { //initialise state
for (int i= 0; i<NBTASKS; i++) {
if (Tasks_list[i].functionAddress == NULL) {
Tasks_list[i].state = 1;
}
else {
Tasks_list[i].state = 0;
}
}
}
</syntaxhighlight>Nous avons programmé deux fonction d'arrêt et une fonction d'ajout de processus :

-finish stop le processus en cours et le supprime de tableau, puis lance une interruption

-kill stop un processus donné et le supprime du tableau

-add ajoute un processus sur la première case vide du tableau, initialise son pointeur de position et sa pile.

Pour finish et kill, on met le temps de sommeil à 0 au cas où on arrête un processus endormi. C'est une mesure de sécurité pour finish, mais une obligation pour kill.<syntaxhighlight lang="c" line="1">
void finish() { //supprime un process lorsque celui-ci est terminé
cli();
Tasks_list[Current_task].state =1;
Tasks_list[Current_task].sleep_time = 0;
Tasks_list[Current_task].functionAddress = NULL;
TCNT1=0;
sei();
TIMER1_COMPA_vect();
}

void kill(void (*function)(void)) { //tue le process passé en paramètre
cli();
for(int i = 0; i<NBTASKS; i++) {
if(Tasks_list[i].functionAddress == function) {
Tasks_list[i].state =1;
Tasks_list[i].sleep_time = 0;
Tasks_list[i].functionAddress = NULL;
}
}
sei();
}

void add(void (*newFunction)(void)) { //ajoute un process
cli();
int i =0;
while(Tasks_list[i].state != 1) {
i++;
}
Tasks_list[i].functionAddress = newFunction;
Tasks_list[i].state = 0;
init_stackPointer_tasks(i);
init_piles(i);

sei();

}
</syntaxhighlight>Il suffit maintenant de modifier le scheduler afin de ne pas prendre les processus terminé, puis utiliser add, finish et kill dans les fonctions choisis.

=====test=====
Pour tester les fonction add et finish, on fait le test suivant :

-on créer un process qui ajoute le process led2_blink (avec add) au bout d'un certain temps

-le process led2_blink s'arrête (avec finish) au bout de 20 changement d'état (c'est à dire 10 clignotement).

on obtient le résultat suivant :[[Fichier:Demo fonction add et finish.mp4|centré|vignette]]
====lecture et écriture sur le port série====
Afin de lire et écrire sur le port série, on utilise les fonctions USART_Init, USART_Transmit et USART_Receive vu en cours de microP l'année précédente. Le but sera donc d'écrire le message qui vient d'être reçu, on utilise donc le processus suivant :<syntaxhighlight lang="c" line="1">
void Serial_Message(){
unsigned char data;
while(1){
data = USART_Receive();
USART_Transmit(data);
}
}
</syntaxhighlight>

=====test=====
Pour tester notre processus de communication, on utilise minicom.[[Fichier:Test lecture et écriture port série.mp4|centré|vignette]]On notera que si la période entre les interruptions est trop élevé, certains caractères ne seront pas lus.

====afficheur 7 segments====
<syntaxhighlight lang="c" line="1">
void seven_seg() {
while (1) {
spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x7E);
spi_echange(0b1101111);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);

spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x76);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);
}
}
</syntaxhighlight>Le processus seven_seg est ajouté au tableau des processus. Avant d'échanger en spi il faut activer la communication, et la désactiver après l'échange. La ligne 4 permet de sélectionner le 7 seg sur lequel on souhaite modifier l'affichage. La ligne 5 permet d'afficher le chiffre 9. Enfin la ligne 11 permet de clear le display. Voir tableau ci-dessous.
[[Fichier:Tab 7 seg sparkfun.png|centré|vignette]]
<syntaxhighlight lang="c" line="1">
void spi_init(void) { // Initialisation du bus SPI
SPI_DDR |= (1<<SPI_MOSI)|(1<<SPI_SCK); // Définition des sorties
SPI_DDR &= ~(1<<SPI_MISO); // Définition de l'entrée
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1); // Activation SPI (SPE) en état maître (MSTR)
// horloge F_CPU/64 (SPR1=1,SPR0=0)
SPI_DDR |= (1<<CS1) | (1<<CS4);;
DDRD |= (1<<CS5) | (1<<CS6);
DDRC |= (1<<CS2) | (1<<CS3);
}

void spi_activer(uint16_t port, uint8_t cs) { // Activer le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg &= ~(1<<cs); // Ligne SS à l'état bas
}

void spi_desactiver(uint16_t port, uint8_t cs) { // Désactiver le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg |= (1<<cs); // Ligne SS à l'état haut
}

uint8_t spi_echange(uint8_t envoi) { // Communication sur le bus SPI
SPDR = envoi; // Octet a envoyer
while(!(SPSR & (1<<SPIF))); // Attente fin envoi (drapeau SPIF du statut)
return SPDR; // Octet reçu
}

</syntaxhighlight>Afin de rendre nos fonctions les plus réutilisables possibles nous avons passer en paramètre le port ainsi que le CS qui correspond au slave select. Le type réel du port est volatile uint8* cependant le compilateur n'accepte que le uint16* ce qui explique le cast un peu étrange.

=====Implémentation=====
[[Fichier:Video7segvideo.mp4|vignette|centré]]L'implémentation correspond à nos attentes, seul un 7 seg affiche le chiffre 9.

====choix du processus sur le port série====

afin de pouvoir démontrer le bon fonctionnement de la partie dynamique, on décide de pouvoir ajouter et tuer des processus à partir des touches du clavier. On utilisera donc les fonction de l'USART défini plus au au travers de la fonction suivante:<syntaxhighlight lang="c">
void call_process() {
unsigned char data;
while(1) {
data = USART_Receive();
if(data == '1') {
add(led1_blink);
}
...
else if(data == '6') {
kill(led1_blink);
}
...
USART_Transmit(data);
}
}

</syntaxhighlight>On remarquera que c'est une sorte d'amélioration de la fonction Serial_Message vu plus haut.

Cette fonction aura la fonction de process de base, toujours présent dans l'ordonnaceur.

=====Démonstation=====
[[Fichier:Process via USART.mp4|centré|vignette]]

Ici on lance les processus ledN_blink avec les touches 1 à 5 et on les tues avec les touches 6 à 0. Pour le 7 segments, on l'ajoute avec s et le tue avec d.

=Carte Réseau=
Lors de la répartition des tâches, nous avons opté pour la carte réseau.
==Description==
Le sujet nous permettait de choisir parmi plusieurs microcontrôleurs. Nous avons retenu l’ATmega32U4, qui nous semble représenter un juste milieu entre l’ATmega16U2 et l’AT90USB.
==Hardware==
Notre carte intègre des LED permettant d’afficher différents états de communication (que nous définirons ultérieurement).

À la demande de M. Redon, nous avons ajouté un MAX232 ainsi que des connecteurs DB9 et DB25. Nous espérons que ces éléments pourront être utiles.

En dehors de ça, la carte reste assez basique car son composant principal reste l'ATmega.
===Schématque===
les broches PF n'étant pas utilisé, on les branches à un connecteur 6x1, notre carte pourra donc être utiliser pour d'autre projet si nécéssaire.

On fait le choix d'utiliser 5 leds pour la connections, 1 led de power et 1 pour la connection ISP.[[Fichier:Schématique CReseau.png|vignette|540x540px|centré]]
===Routage===
[[Fichier:Routage Creseau.png|vignette|521x521px|centré]]Après avoir soudé les composants pricnipaux. il est temps de passer à la partie programmation de la carte.

==Programmation==

Notre carte utilsant un USB, on va donc la faire passer pour une carte réseau en utilisant la demo RNDIS de la LUFA.

Il est important de noter que nous avons choisi un Atmega32u4. Ainsi des modification devrons être apporté à la taille des paquets ethernet et sur le choix des protocoles.

===Protocoles impémentés===

La demo RNDISEthernet de la LUFA inclut les protocole suivant

* ARP : Résolution d'adresses MAC.
* IP : Gestion des paquets IPv4.
* ICMP : Messages de contrôle (ping).
* TCP : Communication fiable (exemple : serveur TCP).
* UDP : Communication non fiable (exemple : serveur UDP).
* DHCP : Attribution dynamique d'adresse IP.

Aussi, on remarquera que la démo utilise un modèle en quatre couche : Le modèle TCP/IP.

le sujet nous propose trois possibilité :

* viser Ethernet
* viser UDP
* viser TCP

En regardant ce qui à été fait les années précédentes, on a remarqué que les groupes partaient principalement sur la première option. Nous nous avons décidé de viser UDP.

Ainsi, afin de d'alléger notre code pour le faire rentrer dans notre carte, nous avons choisi de ne pas inclure le protocole TCP et de modifier la taille max de paquets ethernet à 400 octets.

Il nous restera donc de l'espace pour recevoir des paquets Ethernet :<syntaxhighlight>
avr-size --mcu=atmega32u4 --format=avr RNDISEthernet.elf
AVR Memory Usage
----------------
Device: atmega32u4

Program: 9434 bytes (28.8% Full)
(.text + .data + .bootloader)

Data: 1037 bytes (40.5% Full)
(.data + .bss + .noinit)
</syntaxhighlight>Une fois la lufa réduite et flashé, on donne une adresse ip à notre inteface avec ip link eth2 up et ip address add 10.0.0.1/24 dev eth2. on test un ping sur l'adresse ip de la carte (10.0.0.2).[[Fichier:Ping creseau.mp4|centré|vignette]]
[[Fichier:Ping allume led.mov|vignette|centré]]Le premier test que nous décidons de faire, afin de vérifié notre comprehesion du code de la LUFA est de de faire clignioter si la carte reçoit un paquet ethernet, pour celà on ajoute l'allumage de la led dans la fonction EthernetTask du fichier principal ( RNDISEthernet.c) :[[Fichier:Ping allume led.mov|vignette|La led s'éteint à chaque ping reçue|centré]]

===Création du protocole===

En plus de pouvoir communiquer, notre carte dois être capable d'effectuer 3 fonction.

On décide donc de créer un protocole (nommé ProtocolAntique) dont l'un des octet va transporter le choix de la focntion, le modèle du protocole sera le suivant : <syntaxhighlight lang="c">
typedef struct {
uint8_t operation; /* 0x01 ls, 0x02 send, 0x03 recieve */
uint8_t longeur;
uint8_t numero;
} ProtocolAntique_Header_t;

</syntaxhighlight>Comme nous avons choisit de viser UDP, le protocole doit pocédé un numéro de port, on choisit un numéro supérieur à 1023 pour ne pas devoir passer en root, Le port choisi est 3333.

Dans le programme UDP.c on peut maintenant inclure notre protocole de la façon suivante :<syntaxhighlight lang="c">
switch (SwapEndian_16(UDPHeaderIN->DestinationPort))
{
/*
case UDP_PORT_DHCP_REQUEST:
RetSize = DHCP_ProcessDHCPPacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;
*/
case UDP_PORT_PROTOCOL_ANTIQUE:
RetSize = ProtocolAntique_ProcessProtocolAntiquePacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;

</syntaxhighlight>

===Partie Application===

(A compléter)

Afin de tester la reception du paquet UDP, on fait à nouveau clignotter une led quand un paquet UDP et reçu (video)

=== Partie serveur ===
Lorsque la carte mère a besoin de faire une action (ls, read, write) sur l'ordinateur qui est connecté en USB via la carte réseau elle transmet son besoin à la carte réseau. Cette dernière créer un requête UDP qui encapsule notre protocole (ProtocolAntique) et la transmet donc au PC. Sur ce dernier un serveur doit donc fonctionner afin de recevoir les rêquetes de la carte réseau, les traiter et y répondre. Cette partie est donc consacrée au code ainsi qu'aux tests du serveur.

==== Code du serveur ====
Pour pouvoir fonctionner correctement le serveur doit initialiser une socket UDP et ensuite doit lancer un fonctionne qui boucle indéfiniment afin de recevoir chaque message UDP. Cette partie n'a pas été codé par nous et est trouvable sur rex.plil.fr (Département IMA -> support de cours de la programmation réseau -> exemple de serveur 2/2). Il en est de même du code la fonction pour envoyer un message UDP qui est trouvable au même endroit section exemple de client 2/2.

La carte réseau est toujours à l'initiative des requêtes, par conséquent le serveur commence par recevoir un requête et la traiter. Pour ce faire à chaque requête reçue par la fonction boucleServeurUDP la fonction traitementMessageUDP est appelée.<syntaxhighlight lang="c" line="1">
int traitementMessageUDP (unsigned char* message, int nboctets);
</syntaxhighlight>Cette fonction s'occupe d'extraire la partie opération de l'entête de protocolAntique et d'appeler la fonction de traitement correspondante à l'opération
{| class="wikitable"
!Opération
!Requête
!Fonction appelée
|-
|0x01
|LS
|void traitement_ls (unsigned char*);
|-
|0x02
|READ
|void traitement_read (unsigned char*);
|-
|0x03
|WRITE (début)
|void traitement_write (unsigned char*);
|-
|0x13
|WRITE (données et fin)
|void traitement_write (unsigned char*);
|}

===== Traitement LS =====
La fonction traitement_ls commence par récupérer le chemin (relatif ou absolu) où effectuer le LS. Si la section longueur de l'entête de la requête est à 0 alors le chemin par défaut est celui depuis où le serveur à été lancé. Le code pour récupérer le chemin est le suivant :<syntaxhighlight lang="c" line="1">
unsigned char chemin[longueur+1];
for (int i=0 ; i<longueur ; i++) {
chemin[i] = message[i+3]; // Recuperation du chemin
}
chemin[longueur] = '\0';
</syntaxhighlight>Par la suite le dossier est correspondant au chemin est ouvert via la fonction opendir puis chaque entrée du dossier est récupérée et engendre un message de réponse du serveur (un message par entrée).<syntaxhighlight lang="c" line="1">
while ((entree = readdir(dossier)) != NULL) {
// Message UDP pour chaque entree
strcpy(contenu, entree->d_name);
printf(" %s ", contenu);
reponse[OPERATION] = REPONSE_LS;
reponse[LONGUEUR] = strlen(contenu);
reponse[NUMERO] = num++;
for (int i=0 ; i<reponse[LONGUEUR] ; i++) {
reponse[i+3] = contenu[i];
}
messageUDP(IP_CARTE, PORT_CARTE, (unsigned char *)reponse, (int)reponse[LONGUEUR] + LONGUEUR_ENTETE);
}
</syntaxhighlight>OPERATION est la premiére section et vaut donc 0, LONGUEUR 2 et NUMERO 3. OPERATION est une réponse à un LS donc 0x11, LONGUEUR dépend de l'entrée du dossier et NUMERO augmente de 1 à chaque entrée. Enfin on remplie la requête du nom de l'entrée et on envoie le message.

Enfin une fois tous les entrées envoyées on envoie un dernier message UDP de type reponse_LS de longueur 0 et de numéro 0 afin d'indiquer que la transmission est terminée et ce correctement.

===== Traitement READ =====
Cette requête est très proche de celle du LS. On commence par récupérer le chemin avec le nom du fichier de la même façon que pour le LS. Cependant ici si le message ne contient pas de chemin aucun traitement ne sera effectué. Pour ouvrir le fichier on utilise la fonction fopen. Chaque ligne, récupérée via fgets, engendre une réponse UDP formulée de la même façon que pour les entrées de dossier. Evidemment l'opération est de type réponse read soit 0x12. Enfin un message similaire de fin de transmission est envoyé seulement si il n'y a pas eu d'erreur et que la dernière ligne à été lue.

===== Traitement WRITE =====
Cette requête est un peu plus complexe à gérer niveau serveur par conséquent que je vais commencer par décrire le principe de la fonction.

* La carte réseau envoie un message de type début de write (OPERATION 0x03) avec le chemin et nom du fichier que le serveur va récupérer et mémoriser.

* La carte réseau envoie un massage pour chaque ligne à écrite (OPERATION 0x13). Le serveur va vérifier si la section NUMERO des entêtes se suivent afin de s'assurer que aucun message n'est été perdu.

* La carte réseau envoie un message de type fin de write (OPERATION 0x013) mais de numéro 0. Le serveur indique que tout s'est bien passé en envoyant une réponse au write (OPERATION 0x23) donc le contenu est 0x00.
* Si un message a été perdu un message d'erreur est envoyé de la par du serveur (OPERATION 0x23) de contenu 0x01.

La récupération du contenu de la requête est du même type que celle du LS. Les messages de retour sont construits de la même façon que pour le message de retour du LS. Enfin on utilise fopen une nouvelle fois pour ouvrir le fichier, fwrite pour y écrire et fclose pour le fermer.

==== Préparation du test ====
Avant de pouvoir tester notre serveur avec la carte réseau (ce qui n'aura jamais été fait car la carte réseau n'envoie rien) nous avons souhaité validé le fonctionnement du serveur en simulant des requêtes de la carte réseau. On voit ce que le serveur fait via des printf et en créant un autre serveur (plus rudimentaire) on peut vérifier que le serveur répond correctement. Sur notre git le dossier testUDP est consacré à cette phase de tests.

* Les requêtes simulées de la carte réseau sont envoyées sur l'IP loopback de la machine et sur le port du serveur (ici 4242)
* Le serveur écoute le port serveur (4242) et répond en loopback sur le port du serveur qui simule la carte (ici 3333)
* Le serveur qui simule la carte écoute le port 3333

On lance ces différents serveurs et les requêtes via les commandes du fichiers fonctionnement.txt de notre git.

==== Tests ====
Le test est réalisé via 3 commandes :

* LS sans chemin
* WRITE de 3 lignes dans un fichier test.txt créé par la commande
* READ du fichier test.txt

[[Fichier:Test1.png|centré|vignette|Requêtes envoyées]]
[[Fichier:Test2.png|centré|vignette|Traitement du serveur]]
[[Fichier:Test3.png|centré|vignette|Réponse reçu du serveur]]

Fichier:Test3.png

2026-01-04T15:56:10Z

Abiernac :

test3

Fichier:Test2.png

2026-01-04T15:55:17Z

Abiernac :

test2

Fichier:Test1.png

2026-01-04T15:53:31Z

Abiernac :

test1

Fichier:Ls.png

2026-01-04T15:52:01Z

Abiernac :

Fichier:Test 1.png

2026-01-04T15:41:42Z

Abiernac :

test 1

SE4Binome2025-1

2026-01-04T15:33:22Z

Abiernac :

= Shield Arduino =
== Hardware ==
Afin de tester notre futur carte réseau, nous avons fait un shield d'arduino qui prendra le rôle de la carte mère durant.
=== Schématique ===
Nous nous sommes évidemment aider de la datasheet de l'atmega328p ainsi que celle de l'arduino uno afin de sélectionner les bon pins.
[[Fichier:Atmel-7810-Automotive-Microcontrollers-ATmega328P Datasheet.pdf|centré|vignette|Datasheet ATmega328p]]
[[Fichier:A000066-datasheet.pdf|centré|vignette|Datasheet Arduino Uno R3]]
Plus précisément nous nous inspirons très fortement du schéma page 10 de la datasheet de l'arduino :
[[Fichier:Screenshot 2025-11-07 11-08-46.png|centré|vignette|Schéma pinouts]]
Nous sommes donc parti de l'exemple fourni par Mr Redon. Mais nous avons utilisé une template disponible dans kicad permettant de créer des shields d'arduino Uno R3.[[Fichier:Tyetyuy.png|vignette|Schématique shield arduino|centré|438x438px]]
=== Routage ===
Au niveau du routage, nous avons tenté de faire simple (sans trop abuser sur les vias. Nous avons positionner le lecteur de carte sd au bord de la carte afin de ne pas avoir de problèmes avec d'autres composants lorsque nous voudrons mettre ou enlever la carte sd.
[[Fichier:Routage shield arduino.png|vignette|Routage shield arduino|centré|434x434px]]

===Soudage===
La schématique et le routage terminés, nous avons soudé les différents pins permettant de souder la carte shield à l'arduino, le reste n'étant pas forcément utile pour le moment (il est important de noter que notre shield est arrivé avec des composants pré-soudés).
[[Fichier:Shield soudage de base .jpg|centré|vignette]]

===Tests===
====Leds====

Il faudra ensuite faire des test d'allumage des leds, afin de vérifier le bon fonctionnement du shield
[[Fichier:VID leds.mp4|centré|vignette]]

Les leds fonctionnent à merveille.

====Carte SD====

Nous vérifions maintenant la carte sd (même si elle nous sera inutile pour notre projet)

Nous utilisons le programme fourni par arduino qui permet de récuopéré les informatiuons de la carte sd.
[[Fichier:Test sd card.png|centré|vignette]]
La carte SD est bien identifié, le lecteur de carte fonctionne donc normalement.

== Software ==
=== Ordonnanceur ===
[à completer et commenter , seulement des codes pour le moment !!!!]
==== Ordonnanceur basique ====
La première étape consiste à définir la structure d'un process, il sera composé :

-d'un pointeur de pile

-de l'adresse de la fonction

-d'un temps de sommeil

-d'un état : 0 pour en cours et 1 pour terminé ou vide

Ces deux derniers points nous servirons plus tard.<syntaxhighlight lang="c" line="1">
typedef struct {
uint16_t stackPointer;
void (*functionAddress)(void);
int sleep_time;
int state;
} process;

</syntaxhighlight>On initialise donc notre tableau de processus de la façon suivante : <syntaxhighlight lang="c" line="1">
process Tasks_list[NBTASKS] = {
{0, led1_blink, 0,0},
...
};

</syntaxhighlight>Concernant les fonction liés leds, on utilise une simple boucle while contenant un changement d'état <syntaxhighlight lang="c" line="1">
void led_init() {
...
}
void led1_blink() {
while(1) {
PORTC ^= (1<<PLED1);
_delay_ms(100);
}
}
void led2_blink() {
...
</syntaxhighlight>La fonction init_stackPointer_tasks() permet de diviser la pile "réel" en plusieurs piles pour chaque processus. Ces sous piles commence à la position FIRST_STACK_POSITION, afin de ne pas réécrire par dessus des données. Toutes les sous piles diposent d'une même taille de pile STACK_LENGTH.

La fonction init_piles() initialise correctement la pile avec le tableau de processus si le processus est actif.<syntaxhighlight lang="c" line="1">
void init_stackPointer_tasks(int Cprocess) { //initialise le pointer de pile
if(Tasks_list[Cprocess].state == 0) {
Tasks_list[Cprocess].stackPointer = FIRST_STACK_POSITION - (Cprocess * STACK_LENGTH);
}
}

void init_piles(int Cprocess){ //initilalise la pile
if(Tasks_list[Cprocess].state == 0) {
int save = SP;
SP = Tasks_list[Cprocess].stackPointer;
uint16_t address = (uint16_t)Tasks_list[Cprocess].functionAddress;
asm volatile("push %0" : : "r" (address & 0x00ff) );
asm volatile("push %0" : : "r" ((address & 0xff00)>>8) );
SAVE_REGISTERS();
Tasks_list[Cprocess].stackPointer = SP;
SP = save;
}
}

</syntaxhighlight>le scheduler permet de passer à la tâche suivante<syntaxhighlight lang="c" line="1">
void scheduler() {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}

</syntaxhighlight>l'atmega328p ne dispose pas de de fonction en assembleur permettant de push ou de pop tout les registres. on doit donc le faire un par un.

On défini alors les macros suivantes : <syntaxhighlight lang="c" line="1">
#define SAVE_REGISTERS() \
asm volatile ( \
"push r0 \n\t" \
...\
)

#define RESTORE_REGISTERS() \
asm volatile ( \
"pop r31 \n\t" \
...\
)

</syntaxhighlight>L'ISR gère les interruptions, en commençant par sauvegarder l'état de la pile ainsi que le stack pointeur propre au processus qui s'interrompt. L'appel au schedruler permet de changer de processus pour cela il faut restorer le stack pointer propre au nouveau processus actif et de la pile liée à ce processus. La dernière ligne arrête l'ISR.<syntaxhighlight lang="c" line="1">
ISR(TIMER1_COMPA_vect, ISR_NAKED) {
SAVE_REGISTERS();
Tasks_list[Current_task].stackPointer = SP;
scheduler();
SP = Tasks_list[Current_task].stackPointer;
RESTORE_REGISTERS();
asm volatile("reti");
}
</syntaxhighlight>
=====test=====
Les processus de clignotement de leds ont tous un délai d'attente différent, l'interruption se produit toutes les millisecondes. On obtient ceci :[[Fichier:Ordonnanceur basique.mp4|centré|vignette]]Il est intéressant de remarqué que la vitesse à laquelle les leds changent d'état ne correspond pas au délai qui leur à été donné. Cela parait logique puisque l'interruption met la fonction _delay_ms en pause, ainsi la vitesse se voit divisé par le nombre de processus actif.

====Ajout d'un système d'endormissement des processus====

La fonction wait va permettre d'endormir un processus, elle va donné un temps de sommeil au processus puis lancer une interruption (car on veut changer de processus directement après que le précédent ait été endormi).<syntaxhighlight lang="c" line="1">
void wait(int time) { // met un process en veille pour une durée donné
// valeur max de time 32000 car int sur atmega328p code sur 16 bits donc 32000 max
cli();
Tasks_list[Current_task].sleep_time = time;
TCNT1=0;
sei();
TIMER1_COMPA_vect();

</syntaxhighlight>Pour verifier si un processus a besoin d'être lancé, on ajoute une boucle while dans le scheduler afin de vérifier si il y a un temps de sommeil. Le scheduler va aussi servir à diminuer le temps de sommeil de tout les processus (avec un minimum de 0).<syntaxhighlight lang="c" line="1">
void scheduler() {
for (int i=0 ; i<NBTASKS ; i++) {
if (Tasks_list[i].sleep_time - SLEEP_DEC < 0) {
Tasks_list[i].sleep_time = 0;
} else {
Tasks_list[i].sleep_time -= SLEEP_DEC;
}
}

do {
Current_task++;
if (Current_task >= NBTASKS) {
Current_task = 0;
}
} while (Tasks_list[Current_task].sleep_time > 0);
}

</syntaxhighlight>
====Tableau dynamique des tâches====

En premier lieu on va initialiser les état de tout les cases du tableau de processus. On choisit 1 la case est vide, 0 sinon.<syntaxhighlight lang="c" line="1">
void init_state() { //initialise state
for (int i= 0; i<NBTASKS; i++) {
if (Tasks_list[i].functionAddress == NULL) {
Tasks_list[i].state = 1;
}
else {
Tasks_list[i].state = 0;
}
}
}
</syntaxhighlight>Nous avons programmé deux fonction d'arrêt et une fonction d'ajout de processus :

-finish stop le processus en cours et le supprime de tableau, puis lance une interruption

-kill stop un processus donné et le supprime du tableau

-add ajoute un processus sur la première case vide du tableau, initialise son pointeur de position et sa pile.

Pour finish et kill, on met le temps de sommeil à 0 au cas où on arrête un processus endormi. C'est une mesure de sécurité pour finish, mais une obligation pour kill.<syntaxhighlight lang="c" line="1">
void finish() { //supprime un process lorsque celui-ci est terminé
cli();
Tasks_list[Current_task].state =1;
Tasks_list[Current_task].sleep_time = 0;
Tasks_list[Current_task].functionAddress = NULL;
TCNT1=0;
sei();
TIMER1_COMPA_vect();
}

void kill(void (*function)(void)) { //tue le process passé en paramètre
cli();
for(int i = 0; i<NBTASKS; i++) {
if(Tasks_list[i].functionAddress == function) {
Tasks_list[i].state =1;
Tasks_list[i].sleep_time = 0;
Tasks_list[i].functionAddress = NULL;
}
}
sei();
}

void add(void (*newFunction)(void)) { //ajoute un process
cli();
int i =0;
while(Tasks_list[i].state != 1) {
i++;
}
Tasks_list[i].functionAddress = newFunction;
Tasks_list[i].state = 0;
init_stackPointer_tasks(i);
init_piles(i);

sei();

}
</syntaxhighlight>Il suffit maintenant de modifier le scheduler afin de ne pas prendre les processus terminé, puis utiliser add, finish et kill dans les fonctions choisis.

=====test=====
Pour tester les fonction add et finish, on fait le test suivant :

-on créer un process qui ajoute le process led2_blink (avec add) au bout d'un certain temps

-le process led2_blink s'arrête (avec finish) au bout de 20 changement d'état (c'est à dire 10 clignotement).

on obtient le résultat suivant :[[Fichier:Demo fonction add et finish.mp4|centré|vignette]]
====lecture et écriture sur le port série====
Afin de lire et écrire sur le port série, on utilise les fonctions USART_Init, USART_Transmit et USART_Receive vu en cours de microP l'année précédente. Le but sera donc d'écrire le message qui vient d'être reçu, on utilise donc le processus suivant :<syntaxhighlight lang="c" line="1">
void Serial_Message(){
unsigned char data;
while(1){
data = USART_Receive();
USART_Transmit(data);
}
}
</syntaxhighlight>

=====test=====
Pour tester notre processus de communication, on utilise minicom.[[Fichier:Test lecture et écriture port série.mp4|centré|vignette]]On notera que si la période entre les interruptions est trop élevé, certains caractères ne seront pas lus.

====afficheur 7 segments====
<syntaxhighlight lang="c" line="1">
void seven_seg() {
while (1) {
spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x7E);
spi_echange(0b1101111);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);

spi_activer((uint16_t)&PORTB, CS4);
spi_echange(0x76);
spi_desactiver((uint16_t)&PORTB, CS4);

wait(500);
}
}
</syntaxhighlight>Le processus seven_seg est ajouté au tableau des processus. Avant d'échanger en spi il faut activer la communication, et la désactiver après l'échange. La ligne 4 permet de sélectionner le 7 seg sur lequel on souhaite modifier l'affichage. La ligne 5 permet d'afficher le chiffre 9. Enfin la ligne 11 permet de clear le display. Voir tableau ci-dessous.
[[Fichier:Tab 7 seg sparkfun.png|centré|vignette]]
<syntaxhighlight lang="c" line="1">
void spi_init(void) { // Initialisation du bus SPI
SPI_DDR |= (1<<SPI_MOSI)|(1<<SPI_SCK); // Définition des sorties
SPI_DDR &= ~(1<<SPI_MISO); // Définition de l'entrée
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1); // Activation SPI (SPE) en état maître (MSTR)
// horloge F_CPU/64 (SPR1=1,SPR0=0)
SPI_DDR |= (1<<CS1) | (1<<CS4);;
DDRD |= (1<<CS5) | (1<<CS6);
DDRC |= (1<<CS2) | (1<<CS3);
}

void spi_activer(uint16_t port, uint8_t cs) { // Activer le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg &= ~(1<<cs); // Ligne SS à l'état bas
}

void spi_desactiver(uint16_t port, uint8_t cs) { // Désactiver le périphérique
volatile uint8_t *reg = (volatile uint8_t*)port;
*reg |= (1<<cs); // Ligne SS à l'état haut
}

uint8_t spi_echange(uint8_t envoi) { // Communication sur le bus SPI
SPDR = envoi; // Octet a envoyer
while(!(SPSR & (1<<SPIF))); // Attente fin envoi (drapeau SPIF du statut)
return SPDR; // Octet reçu
}

</syntaxhighlight>Afin de rendre nos fonctions les plus réutilisables possibles nous avons passer en paramètre le port ainsi que le CS qui correspond au slave select. Le type réel du port est volatile uint8* cependant le compilateur n'accepte que le uint16* ce qui explique le cast un peu étrange.

=====Implémentation=====
[[Fichier:Video7segvideo.mp4|vignette|centré]]L'implémentation correspond à nos attentes, seul un 7 seg affiche le chiffre 9.

====choix du processus sur le port série====

afin de pouvoir démontrer le bon fonctionnement de la partie dynamique, on décide de pouvoir ajouter et tuer des processus à partir des touches du clavier. On utilisera donc les fonction de l'USART défini plus au au travers de la fonction suivante:<syntaxhighlight lang="c">
void call_process() {
unsigned char data;
while(1) {
data = USART_Receive();
if(data == '1') {
add(led1_blink);
}
...
else if(data == '6') {
kill(led1_blink);
}
...
USART_Transmit(data);
}
}

</syntaxhighlight>On remarquera que c'est une sorte d'amélioration de la fonction Serial_Message vu plus haut.

Cette fonction aura la fonction de process de base, toujours présent dans l'ordonnaceur.

=====Démonstation=====
[[Fichier:Process via USART.mp4|centré|vignette]]

Ici on lance les processus ledN_blink avec les touches 1 à 5 et on les tues avec les touches 6 à 0. Pour le 7 segments, on l'ajoute avec s et le tue avec d.

=Carte Réseau=
Lors de la répartition des tâches, nous avons opté pour la carte réseau.
==Description==
Le sujet nous permettait de choisir parmi plusieurs microcontrôleurs. Nous avons retenu l’ATmega32U4, qui nous semble représenter un juste milieu entre l’ATmega16U2 et l’AT90USB.
==Hardware==
Notre carte intègre des LED permettant d’afficher différents états de communication (que nous définirons ultérieurement).

À la demande de M. Redon, nous avons ajouté un MAX232 ainsi que des connecteurs DB9 et DB25. Nous espérons que ces éléments pourront être utiles.

En dehors de ça, la carte reste assez basique car son composant principal reste l'ATmega.
===Schématque===
les broches PF n'étant pas utilisé, on les branches à un connecteur 6x1, notre carte pourra donc être utiliser pour d'autre projet si nécéssaire.

On fait le choix d'utiliser 5 leds pour la connections, 1 led de power et 1 pour la connection ISP.[[Fichier:Schématique CReseau.png|vignette|540x540px|centré]]
===Routage===
[[Fichier:Routage Creseau.png|vignette|521x521px|centré]]Après avoir soudé les composants pricnipaux. il est temps de passer à la partie programmation de la carte.

==Programmation==

Notre carte utilsant un USB, on va donc la faire passer pour une carte réseau en utilisant la demo RNDIS de la LUFA.

Il est important de noter que nous avons choisi un Atmega32u4. Ainsi des modification devrons être apporté à la taille des paquets ethernet et sur le choix des protocoles.

===Protocoles impémentés===

La demo RNDISEthernet de la LUFA inclut les protocole suivant

* ARP : Résolution d'adresses MAC.
* IP : Gestion des paquets IPv4.
* ICMP : Messages de contrôle (ping).
* TCP : Communication fiable (exemple : serveur TCP).
* UDP : Communication non fiable (exemple : serveur UDP).
* DHCP : Attribution dynamique d'adresse IP.

Aussi, on remarquera que la démo utilise un modèle en quatre couche : Le modèle TCP/IP.

le sujet nous propose trois possibilité :

* viser Ethernet
* viser UDP
* viser TCP

En regardant ce qui à été fait les années précédentes, on a remarqué que les groupes partaient principalement sur la première option. Nous nous avons décidé de viser UDP.

Ainsi, afin de d'alléger notre code pour le faire rentrer dans notre carte, nous avons choisi de ne pas inclure le protocole TCP et de modifier la taille max de paquets ethernet à 400 octets.

Il nous restera donc de l'espace pour recevoir des paquets Ethernet :<syntaxhighlight>
avr-size --mcu=atmega32u4 --format=avr RNDISEthernet.elf
AVR Memory Usage
----------------
Device: atmega32u4

Program: 9434 bytes (28.8% Full)
(.text + .data + .bootloader)

Data: 1037 bytes (40.5% Full)
(.data + .bss + .noinit)
</syntaxhighlight>Une fois la lufa réduite et flashé, on donne une adresse ip à notre inteface avec ip link eth2 up et ip address add 10.0.0.1/24 dev eth2. on test un ping sur l'adresse ip de la carte (10.0.0.2).[[Fichier:Ping creseau.mp4|centré|vignette]]
[[Fichier:Ping allume led.mov|vignette|centré]]Le premier test que nous décidons de faire, afin de vérifié notre comprehesion du code de la LUFA est de de faire clignioter si la carte reçoit un paquet ethernet, pour celà on ajoute l'allumage de la led dans la fonction EthernetTask du fichier principal ( RNDISEthernet.c) :[[Fichier:Ping allume led.mov|vignette|La led s'éteint à chaque ping reçue|centré]]

===Création du protocole===

En plus de pouvoir communiquer, notre carte dois être capable d'effectuer 3 fonction.

On décide donc de créer un protocole (nommé ProtocolAntique) dont l'un des octet va transporter le choix de la focntion, le modèle du protocole sera le suivant : <syntaxhighlight lang="c">
typedef struct {
uint8_t operation; /* 0x01 ls, 0x02 send, 0x03 recieve */
uint8_t longeur;
uint8_t numero;
} ProtocolAntique_Header_t;

</syntaxhighlight>Comme nous avons choisit de viser UDP, le protocole doit pocédé un numéro de port, on choisit un numéro supérieur à 1023 pour ne pas devoir passer en root, Le port choisi est 3333.

Dans le programme UDP.c on peut maintenant inclure notre protocole de la façon suivante :<syntaxhighlight lang="c">
switch (SwapEndian_16(UDPHeaderIN->DestinationPort))
{
/*
case UDP_PORT_DHCP_REQUEST:
RetSize = DHCP_ProcessDHCPPacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;
*/
case UDP_PORT_PROTOCOL_ANTIQUE:
RetSize = ProtocolAntique_ProcessProtocolAntiquePacket(IPHeaderInStart,
&((uint8_t*)UDPHeaderInStart)[sizeof(UDP_Header_t)],
&((uint8_t*)UDPHeaderOutStart)[sizeof(UDP_Header_t)]);
break;

</syntaxhighlight>

===Partie Application===

(A compléter)

Afin de tester la reception du paquet UDP, on fait à nouveau clignotter une led quand un paquet UDP et reçu (video)

=== Partie serveur ===
Lorsque la carte mère a besoin de faire une action (ls, read, write) sur l'ordinateur qui est connecté en USB via la carte réseau elle transmet son besoin à la carte réseau. Cette dernière créer un requête UDP qui encapsule notre protocole (ProtocolAntique) et la transmet donc au PC. Sur ce dernier un serveur doit donc fonctionner afin de recevoir les rêquetes de la carte réseau, les traiter et y répondre. Cette partie est donc consacrée au code ainsi qu'aux tests du serveur.

==== Code du serveur ====
Pour pouvoir fonctionner correctement le serveur doit initialiser une socket UDP et ensuite doit lancer un fonctionne qui boucle indéfiniment afin de recevoir chaque message UDP. Cette partie n'a pas été codé par nous et est trouvable sur rex.plil.fr (Département IMA -> support de cours de la programmation réseau -> exemple de serveur 2/2). Il en est de même du code la fonction pour envoyer un message UDP qui est trouvable au même endroit section exemple de client 2/2.

La carte réseau est toujours à l'initiative des requêtes, par conséquent le serveur commence par recevoir un requête et la traiter. Pour ce faire à chaque requête reçue par la fonction boucleServeurUDP la fonction traitementMessageUDP est appelée.<syntaxhighlight lang="c" line="1">
int traitementMessageUDP (unsigned char* message, int nboctets);
</syntaxhighlight>Cette fonction s'occupe d'extraire la partie opération de l'entête de protocolAntique et d'appeler la fonction de traitement correspondante à l'opération
{| class="wikitable"
!Opération
!Requête
!Fonction appelée
|-
|0x01
|LS
|void traitement_ls (unsigned char*);
|-
|0x02
|READ
|void traitement_read (unsigned char*);
|-
|0x03
|WRITE (début)
|void traitement_write (unsigned char*);
|-
|0x13
|WRITE (données et fin)
|void traitement_write (unsigned char*);
|}

===== Traitement LS =====
La fonction traitement_ls commence par récupérer le chemin (relatif ou absolu) où effectuer le LS. Si la section longueur de l'entête de la requête est à 0 alors le chemin par défaut est celui depuis où le serveur à été lancé. Le code pour récupérer le chemin est le suivant :<syntaxhighlight lang="c" line="1">
unsigned char chemin[longueur+1];
for (int i=0 ; i<longueur ; i++) {
chemin[i] = message[i+3]; // Recuperation du chemin
}
chemin[longueur] = '\0';
</syntaxhighlight>Par la suite le dossier est correspondant au chemin est ouvert via la fonction opendir puis chaque entrée du dossier est récupérée et engendre un message de réponse du serveur (un message par entrée).<syntaxhighlight lang="c" line="1">
while ((entree = readdir(dossier)) != NULL) {
// Message UDP pour chaque entree
strcpy(contenu, entree->d_name);
printf(" %s ", contenu);
reponse[OPERATION] = REPONSE_LS;
reponse[LONGUEUR] = strlen(contenu);
reponse[NUMERO] = num++;
for (int i=0 ; i<reponse[LONGUEUR] ; i++) {
reponse[i+3] = contenu[i];
}
messageUDP(IP_CARTE, PORT_CARTE, (unsigned char *)reponse, (int)reponse[LONGUEUR] + LONGUEUR_ENTETE);
}
</syntaxhighlight>OPERATION est la premiére section et vaut donc 0, LONGUEUR 2 et NUMERO 3. OPERATION est une réponse à un LS donc 0x11, LONGUEUR dépend de l'entrée du dossier et NUMERO augmente de 1 à chaque entrée. Enfin on remplie la requête du nom de l'entrée et on envoie le message.

Enfin une fois tous les entrées envoyées on envoie un dernier message UDP de type reponse_LS de longueur 0 et de numéro 0 afin d'indiquer que la transmission est terminée et ce correctement.

===== Traitement READ =====
Cette requête est très proche de celle du LS. On commence par récupérer le chemin avec le nom du fichier de la même façon que pour le LS. Cependant ici si le message ne contient pas de chemin aucun traitement ne sera effectué. Pour ouvrir le fichier on utilise la fonction fopen. Chaque ligne, récupérée via fgets, engendre une réponse UDP formulée de la même façon que pour les entrées de dossier. Evidemment l'opération est de type réponse read soit 0x12. Enfin un message similaire de fin de transmission est envoyé seulement si il n'y a pas eu d'erreur et que la dernière ligne à été lue.

===== Traitement WRITE =====
Cette requête est un peu plus complexe à gérer niveau serveur par conséquent que je vais commencer par décrire le principe de la fonction.

* La carte réseau envoie un message de type début de write (OPERATION 0x03) avec le chemin et nom du fichier que le serveur va récupérer et mémoriser.

* La carte réseau envoie un massage pour chaque ligne à écrite (OPERATION 0x13). Le serveur va vérifier si la section NUMERO des entêtes se suivent afin de s'assurer que aucun message n'est été perdu.

* La carte réseau envoie un message de type fin de write (OPERATION 0x013) mais de numéro 0. Le serveur indique que tout s'est bien passé en envoyant une réponse au write (OPERATION 0x23) donc le contenu est 0x00.
* Si un message a été perdu un message d'erreur est envoyé de la par du serveur (OPERATION 0x23) de contenu 0x01.

La récupération du contenu de la requête est du même type que celle du LS. Les messages de retour sont construits de la même façon que pour le message de retour du LS. Enfin on utilise fopen une nouvelle fois pour ouvrir le fichier, fwrite pour y écrire et fclose pour le fermer.

==== Préparation du test ====
Avant de pouvoir tester notre serveur avec la carte réseau (ce qui n'aura jamais été fait car la carte réseau n'envoie rien) nous avons souhaité validé le fonctionnement du serveur en simulant des requêtes de la carte réseau. On voit ce que le serveur fait via des printf et en créant un autre serveur (plus rudimentaire) on peut vérifier que le serveur répond correctement. Sur notre git le dossier testUDP est consacré à cette phase de tests.

SE4Binome2025-1

2025-12-11T16:00:10Z

Abiernac :

Fichier:Ping allume led.mov

2025-12-11T15:55:52Z

Abiernac :

La led s'allume à chaque ping reçu

SE4Binome2025-1

2025-11-24T10:15:18Z

Abiernac : /* test */

Fichier:Tab 7 seg sparkfun.png

2025-11-24T10:02:58Z

Abiernac :

SE4Binome2025-1

2025-11-21T11:16:21Z

Abiernac : /* Carte Réseau */

SE4Binome2025-1

2025-11-21T09:52:09Z

Abiernac : complement de documentation

SE4Binome2025-1

2025-09-26T12:36:41Z

Abiernac :

== Shield Arduino ==

=== Schématique et routage ===
[[Fichier:Tyetyuy.png|néant|vignette|Schématique shield arduino]]
[[Fichier:Routage shield arduino.png|néant|vignette|Routage shield arduino]]

La schématique et le routage sont terminés. Nous avons utilisé un template pour l'arduino différent de celui proposé car ce dernier était à l'envers.

== Carte Réseau ==

Fichier:Tyetyuy.png

2025-09-26T12:35:18Z

Abiernac :

rgrt

SE4Binome2025-1

2025-09-26T10:15:46Z

Abiernac : partie schematique/routage du shield arduino complete

== Shield Arduino ==

=== Schématique et routage ===
[[Fichier:Schématique shield arduino.png|néant|vignette|Schématique shield arduino]]
[[Fichier:Routage shield arduino.png|néant|vignette|Routage shield arduino]]

La schématique et le routage sont terminés. Nous avons utilisé un template pour l'arduino différent de celui proposé car ce dernier était à l'envers.

== Carte Réseau ==

Fichier:Routage shield arduino.png

2025-09-26T10:09:23Z

Abiernac :

Routage fini

Fichier:Schématique shield arduino.png

2025-09-26T10:04:41Z

Abiernac :

schématique finie

Pico SE4 2025/2026

2025-09-17T13:19:39Z

Abiernac :

= Objectif =

Voir le sujet dans le menu englobant.

= Organisation du travail =

Vous déposerez votre travail dans un projet GIT sur le serveur [https://gitea.plil.fr Gitea de la platforme informatique].

= Bouclier ordonnanceur =

Vous devez réaliser le bouclier Arduino Uno pour l'ordonnancement et pour que chaque binôme puisse simuler une carte mère.

A la base le bouclier permet de connecter 5 périphériques SPI via des connecteurs 8 contacts sous la forme de cartes filles. A noter qu'en plus des lignes du bus SPI, une ligne réinitialisation et une ligne interruption sont acheminées de et vers les périphériques SPI.

Le bouclier comprend aussi une mémoire. Vous devez prévoir une carte micro-SD via un connecteur Molex 10431 mais aussi une puce mémoire AT45DB641E. Les deux mémoires doivent être prévues sur le circuit imprimé, vous déciderez plus tard laquelle sera soudée. Vu que l'Arduino fonctionne en 5V et les mémoires en 3,3V un releveur de niveau est nécessaire. La puce à utiliser est la 74LV125. Vous pouvez aussi concevoir la mémoire de masse comme une carte fille sans ligne de réinitialisation ou d'initialisation.

[[File:2025_picoshield_schematic.pdf|thumb|left|500px|Schéma PicoShield]]

[[File:2025_picoshield_footprints.png|thumb|right|750px|Empreintes]]

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

= Réalisations des élèves =

{| class="wikitable"
! Numéro du binôme !! Numéro du groupe !! Elèves !! Page
|-
| Binôme 1
| Groupe 1
| Thomas Delobelle & Antonin Biernacki
| [[SE4Binome2025-1|Binôme 1 2025/2026]]
|-
| Binôme 2
| Groupe 1
| Prénom Nom & Prénom Nom
| [[SE4Binome2025-2|Binôme 2 2025/2026]]
|-
| Binôme 3
| Groupe 1
| Prénom Nom & Prénom Nom
| [[SE4Binome2025-3|Binôme 3 2025/2026]]
|-
| Binôme 4
| Groupe 1
| Prénom Nom & Prénom Nom
| [[SE4Binome2025-4|Binôme 4 2025/2026]]
|-
| Binôme 5
| Groupe 1
| Prénom Nom & Prénom Nom
| [[SE4Binome2025-5|Binôme 5 2025/2026]]
|-
| Binôme 6
| Groupe 2
| Cédric Payet & Prénom Nom
| [[SE4Binome2025-6|Binôme 6 2025/2026]]
|-
|}

SE3Groupe2024-5

2025-04-29T12:46:33Z

Abiernac : /* Matériel */

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===
[[Fichier:Schematique-sonar.pdf|alt=schématique de la carte|gauche|vignette|schématique de la carte de pilotage du sonar]]
<p style="clear: both;" />

=== Routage ===
[[Fichier:Routage-sonar.pdf|alt=image du routage de la carte|gauche|vignette|capture d'écran du routage du sonar]]
<p style="clear: both;" />

=== Vue 3D ===
[[Fichier:Vue-3D-sonar.pdf|alt=Vue 3D de la carte|gauche|vignette|Vue 3D de face du routage]]
[[Fichier:Vue3DdosPCB.pdf|alt=capture d'écran de la vue 3D de dos de la carte|gauche|vignette|vue 3D de dos]]
<p style="clear: both;" />

=== CAO de la carte du sonar ===
[[Fichier:Sonar.zip|vignette]]
<p style="clear: both;" />

=== Matériel supplémentaire à commander ===

CD4543 en DIP-16
=== Réalisation ===
<p style="clear: both;" />Afin d'assurer le bon déroulement de la soudure de la carte, nous avons divisé les composants à souder dans des jalons, pour nous assurer étape par étape du bon fonctionnement de la carte.
<p style="clear: both;" />
<p style="clear: both;" />Le premier jalon comporte naturellement le microcontrôleur et les composants nécessaires à son bon fonctionnement, ainsi que la connectique USB pour pouvoir charger des programmes sur la carte.
<p style="clear: both;" />La liste des jalons est disponible ci-contre:
[[Fichier:Jalons.txt|alt=fichier texte comprenant les jalons pour la soudure|vignette]]
<p style="clear: both;" />

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

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

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>En faisant un lsusb, on observe que la carte est reconnue comme un appareil USB, configuré d'après les fichiers de configuration de la LUFA.[[Fichier:Screenshot 2025-03-26 13-23-23.jpg|centré|vignette|800x800px|carte apparaissant comme appareil USB]]Le résultat est présenté dans la vidéo ci-dessous:[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===
https://gitea.plil.fr/abiernac/SE3_2024_B5.git

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

SE3Groupe2024-5

2025-04-29T12:43:33Z

Abiernac : /* Réalisation */

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===
[[Fichier:Schematique-sonar.pdf|alt=schématique de la carte|gauche|vignette|schématique de la carte de pilotage du sonar]]
<p style="clear: both;" />

=== Routage ===
[[Fichier:Routage-sonar.pdf|alt=image du routage de la carte|gauche|vignette|capture d'écran du routage du sonar]]
<p style="clear: both;" />

=== Vue 3D ===
[[Fichier:Vue-3D-sonar.pdf|alt=Vue 3D de la carte|gauche|vignette|Vue 3D de face du routage]]
[[Fichier:Vue3DdosPCB.pdf|alt=capture d'écran de la vue 3D de dos de la carte|gauche|vignette|vue 3D de dos]]
<p style="clear: both;" />

=== CAO de la carte du sonar ===
[[Fichier:Sonar.zip|vignette]]
<p style="clear: both;" />

=== Réalisation ===
<p style="clear: both;" />Afin d'assurer le bon déroulement de la soudure de la carte, nous avons divisé les composants à souder dans des jalons, pour nous assurer étape par étape du bon fonctionnement de la carte.
<p style="clear: both;" />
<p style="clear: both;" />Le premier jalon comporte naturellement le microcontrôleur et les composants nécessaires à son bon fonctionnement, ainsi que la connectique USB pour pouvoir charger des programmes sur la carte.
<p style="clear: both;" />La liste des jalons est disponible ci-contre:
[[Fichier:Jalons.txt|alt=fichier texte comprenant les jalons pour la soudure|vignette]]
<p style="clear: both;" />

=== Matériel ===

CD4543 en DIP-16
<p style="clear: both;" />
== Programmation ==

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

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>En faisant un lsusb, on observe que la carte est reconnue comme un appareil USB, configuré d'après les fichiers de configuration de la LUFA.[[Fichier:Screenshot 2025-03-26 13-23-23.jpg|centré|vignette|800x800px|carte apparaissant comme appareil USB]]Le résultat est présenté dans la vidéo ci-dessous:[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===
https://gitea.plil.fr/abiernac/SE3_2024_B5.git

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

SE3Groupe2024-5

2025-04-29T12:43:00Z

Abiernac : /* Réalisation */

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===
[[Fichier:Schematique-sonar.pdf|alt=schématique de la carte|gauche|vignette|schématique de la carte de pilotage du sonar]]
<p style="clear: both;" />

=== Routage ===
[[Fichier:Routage-sonar.pdf|alt=image du routage de la carte|gauche|vignette|capture d'écran du routage du sonar]]
<p style="clear: both;" />

=== Vue 3D ===
[[Fichier:Vue-3D-sonar.pdf|alt=Vue 3D de la carte|gauche|vignette|Vue 3D de face du routage]]
[[Fichier:Vue3DdosPCB.pdf|alt=capture d'écran de la vue 3D de dos de la carte|gauche|vignette|vue 3D de dos]]
<p style="clear: both;" />

=== CAO de la carte du sonar ===
[[Fichier:Sonar.zip|vignette]]
<p style="clear: both;" />

=== Réalisation ===
<p style="clear: both;" />Afin d'assurer le bon déroulement de la soudure de la carte, nous avons divisé les composants à souder dans des jalons, pour nous assurer étape par étape du bon fonctionnement de la carte.
<p style="clear: both;" />
<p style="clear: both;" />Le premier jalon comporte naturellement le microcontrôleur et les composants nécessaires à son bon fonctionnement, ainsi que la connectique USB pour pouvoir charger des programmes sur la carte.
<p style="clear: both;" />La liste des jalons est disponible ci-dessous:
[[Fichier:Jalons.txt|alt=fichier texte comprenant les jalons pour la soudure|vignette]]
<p style="clear: both;" />
=== Matériel ===

CD4543 en DIP-16
<p style="clear: both;" />
== Programmation ==

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

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>En faisant un lsusb, on observe que la carte est reconnue comme un appareil USB, configuré d'après les fichiers de configuration de la LUFA.[[Fichier:Screenshot 2025-03-26 13-23-23.jpg|centré|vignette|800x800px|carte apparaissant comme appareil USB]]Le résultat est présenté dans la vidéo ci-dessous:[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===
https://gitea.plil.fr/abiernac/SE3_2024_B5.git

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

Fichier:Jalons.txt

2025-04-29T12:41:42Z

Abiernac :

jalons pour la soudure

SE3Groupe2024-5

2025-04-29T12:40:26Z

Abiernac : /* Réalisation */

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===
[[Fichier:Schematique-sonar.pdf|alt=schématique de la carte|gauche|vignette|schématique de la carte de pilotage du sonar]]
<p style="clear: both;" />

=== Routage ===
[[Fichier:Routage-sonar.pdf|alt=image du routage de la carte|gauche|vignette|capture d'écran du routage du sonar]]
<p style="clear: both;" />

=== Vue 3D ===
[[Fichier:Vue-3D-sonar.pdf|alt=Vue 3D de la carte|gauche|vignette|Vue 3D de face du routage]]
[[Fichier:Vue3DdosPCB.pdf|alt=capture d'écran de la vue 3D de dos de la carte|gauche|vignette|vue 3D de dos]]
<p style="clear: both;" />

=== CAO de la carte du sonar ===
[[Fichier:Sonar.zip|vignette]]
<p style="clear: both;" />

=== Réalisation ===
<p style="clear: both;" />Afin d'assurer le bon déroulement de la soudure de la carte, nous avons divisé les composants à souder dans des jalons, pour nous assurer étape par étape du bon fonctionnement de la carte.
<p style="clear: both;" />
<p style="clear: both;" />Le premier jalon comporte naturellement le microcontrôleur et les composants nécessaires à son bon fonctionnement, ainsi que la connectique USB pour pouvoir charger des programmes sur la carte.
<p style="clear: both;" />La liste des jalons est disponible ci-dessous:
<p style="clear: both;" />
=== Matériel ===

CD4543 en DIP-16
<p style="clear: both;" />
== Programmation ==

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

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>En faisant un lsusb, on observe que la carte est reconnue comme un appareil USB, configuré d'après les fichiers de configuration de la LUFA.[[Fichier:Screenshot 2025-03-26 13-23-23.jpg|centré|vignette|800x800px|carte apparaissant comme appareil USB]]Le résultat est présenté dans la vidéo ci-dessous:[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===
https://gitea.plil.fr/abiernac/SE3_2024_B5.git

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

Fichier:Sonar.zip

2025-04-29T12:33:31Z

Abiernac : Abiernac a téléversé une nouvelle version de Fichier:Sonar.zip

Fichiers KiCad de la carte sonar comprenant la schématique et le routage.

SE3Groupe2024-5

2025-04-29T12:31:45Z

Abiernac :

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===
[[Fichier:Schematique-sonar.pdf|alt=schématique de la carte|gauche|vignette|schématique de la carte de pilotage du sonar]]
<p style="clear: both;" />

=== Routage ===
[[Fichier:Routage-sonar.pdf|alt=image du routage de la carte|gauche|vignette|capture d'écran du routage du sonar]]
<p style="clear: both;" />

=== Vue 3D ===
[[Fichier:Vue-3D-sonar.pdf|alt=Vue 3D de la carte|gauche|vignette|Vue 3D de face du routage]]
[[Fichier:Vue3DdosPCB.pdf|alt=capture d'écran de la vue 3D de dos de la carte|gauche|vignette|vue 3D de dos]]
<p style="clear: both;" />

=== CAO de la carte du sonar ===
[[Fichier:Sonar.zip|vignette]]
<p style="clear: both;" />

=== Réalisation ===
<p style="clear: both;" />
=== Matériel ===

CD4543 en DIP-16
<p style="clear: both;" />
== Programmation ==

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

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>En faisant un lsusb, on observe que la carte est reconnue comme un appareil USB, configuré d'après les fichiers de configuration de la LUFA.[[Fichier:Screenshot 2025-03-26 13-23-23.jpg|centré|vignette|800x800px|carte apparaissant comme appareil USB]]Le résultat est présenté dans la vidéo ci-dessous:[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===
https://gitea.plil.fr/abiernac/SE3_2024_B5.git

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

SE3Groupe2024-5

2025-04-29T12:31:14Z

Abiernac : /* Vue 3D */

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===
[[Fichier:Schematique-sonar.pdf|alt=schématique de la carte|gauche|vignette|schématique de la carte de pilotage du sonar]]
<p style="clear: both;" />

=== Routage ===
[[Fichier:Routage-sonar.pdf|alt=image du routage de la carte|gauche|vignette|capture d'écran du routage du sonar]]
<p style="clear: both;" />

=== Vue 3D ===
[[Fichier:Vue-3D-sonar.pdf|alt=Vue 3D de la carte|gauche|vignette|Vue 3D de face du routage]]
[[Fichier:Vue3DdosPCB.pdf|alt=capture d'écran de la vue 3D de dos de la carte|gauche|vue 3D de dos]]
<p style="clear: both;" />

=== CAO de la carte du sonar ===
[[Fichier:Sonar.zip|vignette]]
<p style="clear: both;" />

=== Réalisation ===
<p style="clear: both;" />
=== Matériel ===

CD4543 en DIP-16
<p style="clear: both;" />
== Programmation ==

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

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>En faisant un lsusb, on observe que la carte est reconnue comme un appareil USB, configuré d'après les fichiers de configuration de la LUFA.[[Fichier:Screenshot 2025-03-26 13-23-23.jpg|centré|vignette|800x800px|carte apparaissant comme appareil USB]]Le résultat est présenté dans la vidéo ci-dessous:[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===
https://gitea.plil.fr/abiernac/SE3_2024_B5.git

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

SE3Groupe2024-5

2025-04-29T12:30:11Z

Abiernac :

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===
[[Fichier:Schematique-sonar.pdf|alt=schématique de la carte|gauche|vignette|schématique de la carte de pilotage du sonar]]
<p style="clear: both;" />

=== Routage ===
[[Fichier:Routage-sonar.pdf|alt=image du routage de la carte|gauche|vignette|capture d'écran du routage du sonar]]
<p style="clear: both;" />

=== Vue 3D ===
[[Fichier:Vue-3D-sonar.pdf|alt=Vue 3D de la carte|gauche|vignette|Vue 3D de face du routage]]
<p style="clear: both;" />
[[Fichier:Vue3DdosPCB.pdf|alt=capture d'écran de la vue 3D de dos de la carte|vignette|vue 3D de dos]]
<p style="clear: both;" />
=== CAO de la carte du sonar ===
[[Fichier:Sonar.zip|vignette]]
<p style="clear: both;" />

=== Réalisation ===
<p style="clear: both;" />
=== Matériel ===

CD4543 en DIP-16
<p style="clear: both;" />
== Programmation ==

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

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>En faisant un lsusb, on observe que la carte est reconnue comme un appareil USB, configuré d'après les fichiers de configuration de la LUFA.[[Fichier:Screenshot 2025-03-26 13-23-23.jpg|centré|vignette|800x800px|carte apparaissant comme appareil USB]]Le résultat est présenté dans la vidéo ci-dessous:[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===
https://gitea.plil.fr/abiernac/SE3_2024_B5.git

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

SE3Groupe2024-5

2025-04-29T12:28:59Z

Abiernac : /* Vue 3D */

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===
[[Fichier:Schematique-sonar.pdf|alt=schématique de la carte|gauche|vignette|schématique de la carte de pilotage du sonar]]
<p style="clear: both;" />

=== Routage ===
[[Fichier:Routage-sonar.pdf|alt=image du routage de la carte|gauche|vignette|capture d'écran du routage du sonar]]
<p style="clear: both;" />

=== Vue 3D ===
[[Fichier:Vue-3D-sonar.pdf|alt=Vue 3D de la carte|gauche|vignette|Vue 3D de face du routage]]
[[Fichier:Vue3DdosPCB.pdf|alt=capture d'écran de la vue 3D de dos de la carte|vignette|vue 3D de dos]]
<p style="clear: both;" />
=== CAO de la carte du sonar ===
[[Fichier:Sonar.zip|vignette]]
<p style="clear: both;" />

=== Réalisation ===
<p style="clear: both;" />
=== Matériel ===

CD4543 en DIP-16
<p style="clear: both;" />
== Programmation ==

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

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>En faisant un lsusb, on observe que la carte est reconnue comme un appareil USB, configuré d'après les fichiers de configuration de la LUFA.[[Fichier:Screenshot 2025-03-26 13-23-23.jpg|centré|vignette|800x800px|carte apparaissant comme appareil USB]]Le résultat est présenté dans la vidéo ci-dessous:[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===
https://gitea.plil.fr/abiernac/SE3_2024_B5.git

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

Fichier:Vue3DdosPCB.pdf

2025-04-29T12:26:53Z

Abiernac :

Vue de dos du modèle 3D de la carte

SE3Groupe2024-5

2025-04-29T12:25:47Z

Abiernac : /* Vue 3D */

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===
[[Fichier:Schematique-sonar.pdf|alt=schématique de la carte|gauche|vignette|schématique de la carte de pilotage du sonar]]
<p style="clear: both;" />

=== Routage ===
[[Fichier:Routage-sonar.pdf|alt=image du routage de la carte|gauche|vignette|capture d'écran du routage du sonar]]
<p style="clear: both;" />

=== Vue 3D ===
[[Fichier:Vue-3D-sonar.pdf|alt=Vue 3D de la carte|gauche|vignette|Vue 3D de face du routage]]
<p style="clear: both;" />
=== CAO de la carte du sonar ===
[[Fichier:Sonar.zip|vignette]]
<p style="clear: both;" />

=== Réalisation ===
<p style="clear: both;" />
=== Matériel ===

CD4543 en DIP-16
<p style="clear: both;" />
== Programmation ==

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

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>En faisant un lsusb, on observe que la carte est reconnue comme un appareil USB, configuré d'après les fichiers de configuration de la LUFA.[[Fichier:Screenshot 2025-03-26 13-23-23.jpg|centré|vignette|800x800px|carte apparaissant comme appareil USB]]Le résultat est présenté dans la vidéo ci-dessous:[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===
https://gitea.plil.fr/abiernac/SE3_2024_B5.git

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

Fichier:Vue-3D-sonar.pdf

2025-04-29T12:25:22Z

Abiernac : Abiernac a téléversé une nouvelle version de Fichier:Vue-3D-sonar.pdf

Vue 3D sonar

Fichier:Routage-sonar.pdf

2025-04-29T12:23:00Z

Abiernac : Abiernac a téléversé une nouvelle version de Fichier:Routage-sonar.pdf

routage sonar

SE3Groupe2024-5

2025-03-26T12:34:09Z

Abiernac :

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===

=== Routage ===

=== Réalisation ===

=== Matériel ===

CD4543 en DIP-16

== Programmation ==

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>En faisant un lsusb, on observe que la carte est reconnue comme un appareil USB, configuré d'après les fichiers de configuration de la LUFA.[[Fichier:Screenshot 2025-03-26 13-23-23.jpg|centré|vignette|800x800px|carte apparaissant comme appareil USB]]Le résultat est présenté dans la vidéo ci-dessous:[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

Fichier:Screenshot 2025-03-26 13-23-23.jpg

2025-03-26T12:32:01Z

Abiernac :

terminal linux

SE3Groupe2024-5

2025-03-26T12:28:30Z

Abiernac :

== Description ==

=== Objectif ===
Concevoir et réaliser un mini sonar à partir d'un émetteur-récepteur ultrason, avec un traitement des données effectué par un micro-contrôleur. Les données seront ensuite communiquées par ondes radio à un ordinateur. Le système devra être capable de fonctionner aussi bien sur batterie que connecté en USB à un ordinateur, et devra au minimum comporter des LED d'indication.

=== Cahier des charges ===

* Contrôle et traitement des informations de l'émetteur-récepteur ultrason
* Pilotage par moteur de l'angle de l'émetteur-récepteur ultrason
* Retour de l'information par des LED sur la carte
* Gestion de l'alimentation par USB
* Communication sans fil avec un ordinateur
* Gestion de l'alimentation sur batterie
* Interface pour visualiser les informations sur ordinateur

=== Spécification techniques ===

* angle de détection large (-90°,90°)
* deux émetteurs/récepteurs à ultrason HC-SR04

* Recharge par USB
* transmission des données par onde radio via un module RF (NRFL2401)
* Batteries Li-ion
* une LED tricolore, pour notamment informer des différents niveaux de batterie
* un afficheur 7 segments pour le débogage
* interface machine via une application python
* microcontroleur atmega

== Carte électronique ==

=== Schématique ===

=== Routage ===

=== Réalisation ===

=== Matériel ===

CD4543 en DIP-16

== Programmation ==

== Programmateur AVR ==

=== Tests allumage des LEDs ===
Lorsque nous avons fini de souder les composants sur la carte, nous avons voulu tester que la carte fonctionnait correctement, c'est pourquoi nous avons écrit un petit programme permettant l'allumage des leds jaunes(une qui s'allume à l'appui sur le bouton bleu traversant, une qui clignote à 10 Hz).<syntaxhighlight lang="c" line="1" start="1">
//avr-gcc -mmcu=atmega8u2 -Wall -Werror -I. -DF_CPU=16000000 -Os -o blink.elf blink.c
//avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
// avrdude -v -patmega8u2 -carduino -b115200 -P/dev/ttyACM0 -U flash:w:blink.hex
#include <avr/io.h>
#include <util/delay.h>
int main(void){
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
DDRD |= 0x00; // Sortie pour la LED
DDRC=0x24; // Entrée pour le bouton

while(1){
if(PIND & 0x40) PORTC =0x20; // LED éteinte
else PORTC |= 0x00; // LED allumée
}
PORTC^=0x04;
_delay_ms(100);
}
</syntaxhighlight>Une fois le code compilé et uploadé, on obtient le résultat suivant:[[Fichier:Image pcb.jpg|gauche|vignette|Allumage de 2 LEDs sur la carte.]]

<div style="clear: both;">
Pour que le microcontroleur se comporte comme un programmateur AVR USB, il faut d'abord qu'il puisse être reconnu comme un appareil USB, c'est pourquoi nous avons utilisé la bibliothèque LUFA et avons programmé notre carte avec le code qui suit pour qu'il puisse communiquer en USB:<syntaxhighlight lang="makefile" line="1" start="1">
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
</syntaxhighlight>

<syntaxhighlight lang="c" line="1" start="1">
char* ReportString = NULL;
static bool ActionSent = false;
static bool button = false;

/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a joystick action has occurred */
if (!(PIND & 0x40)){
if(!button){
ReportString = "BOUTON PRESSE\r\n";
ActionSent=false;
}
button=true;
}
else button=false;
</syntaxhighlight>

[[Fichier:Video pcb(1).mp4|gauche|vignette|Communication USB entre ISP et PC visualisée via minicom]]</div>

<div style="clear: both;">

== Tests ==

== Rendus ==

=== Archive GIT ===

=== Autres rendus ===

[[Fichier:SE3_2024_G5_prog_schema.pdf|thumb|left]]
[[Fichier:SE3_2024_G5_prog_PCB.png|thumb|right]]

Projet KiCad programmateur AVR : [[Fichier:SE3-2024-G5-prog-kicad.zip]]

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

SE3Groupe2024-5

2025-03-26T12:19:51Z

Abiernac :

SE3Groupe2024-5

2025-03-26T11:52:27Z

Abiernac : /* Tests allumage des LEDs */

SE3Groupe2024-5

2025-03-26T11:51:54Z

Abiernac : /* Tests allumage des LEDs */

SE3Groupe2024-5

2025-03-26T11:50:46Z

Abiernac : /* Programmateur AVR */

Fichier:Video pcb(1).mp4

2025-03-26T11:43:46Z

Abiernac :

Video pcb

SE3Groupe2024-5

2025-03-26T11:35:57Z

Abiernac : /* Tests allumage des LEDs */

SE3Groupe2024-5

2025-03-26T11:32:41Z

Abiernac : /* Tests allumage des LEDs */

SE3Groupe2024-5

2025-03-26T11:32:03Z

Abiernac : /* Tests allumage des LEDs */