https://projets-se.plil.fr/mediawiki/api.php?action=feedcontributions&feedformat=atom&user=Rboursauprojets-se.plil.fr - Contributions [fr]2026-09-21T05:41:55ZContributionsMediaWiki 1.39.1https://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=7398SE4Binome2024-72025-01-26T17:04:52Z<p>Rboursau : /* NOTES */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=== Problèmes rencontrés avec la COMMUNICATION SPI ===<br />
<br />
Lors de la programmation de notre carte RNDIS, nous avons rencontré un problème de communication SPI de notre carte RNDIS vers notre Shield. <br />
Nous pouvons envoyer des paquets/données du Shield vers la carte RNDIS mais pas dans l'autre sens. Le problème résidait sur le Shield. Plus particulièrement sur le releveur de niveau de tension. La résistance soudée à la sortie du <code>PIN MOSI_1</code> ne devrait pas être ici. Dû à cette erreur de design, le releveur de niveau faisait l'inverse de ce qu'il doit normalement faire : il baissait notre niveau de tension.<br />
Normalement, le releveur de niveau doit augmenter la tension pour quelle puisse être utilisée/utilisable par le MicroP. Lors de nos tests sur oscilloscope, nous avions <code>+5V</code> du Shield vers notre carte RNDIS, ce qui est la tension optimale mais n'obtenons que <code>+1.5V</code> de notre carte RNDIS vers notre Shield ce qui est bien insuffisant car les MicroP que nous avons ne fonctionne qu'avec des tensions à minima de <code>+3.3V</code>.<br />
Nous avons d'abord tenter de couper la piste à l'entrée du <code>PIN MISO</code> et d'y mettre la résistance qui est en sortie du <code>PIN MISO_1</code> et de remplacer la résistance en sortie du <code>PIN MISO_1</code> par un fil. Cela régla notre problème de tension mais nous ne pouvions plus détecter la carte SD.<br />
Nous avons donc enlever toutes les résistances et fils des pistes <code>MOSI</code> à l'entrée et sortie du releveur de niveau et avons court-circuité les deux pistes. Il faut aussi sectionner le fil de cuivre <code>MOSI</code> sinon le courant ira en sur le fil de cuivre <code>MISO_1</code> ET le fil <code>MOSI</code> et nous voulons que le courant aille uniquement sur <code>MISO_1</code> . Cela régla notre problème de tension ET de détection de carte SD.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Releveur de niveau PinMISO test1.png|gauche|vignette|Schéma montrant les tests que nous avons fait pour régler le problème de tension du MISO]]<br />
![[Fichier:Releveur de niveau PinMISO.png|alt=Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD|vignette|Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD]]<br />
|-<br />
|<br />
|<br />
|}<br />
<br />
== Programmation de la carte RNDIS ==<br />
<br />
Pour utiliser la carte RNDIS, nous allons créer notre protocole Ethernet en s'inspirant de l'ARP. Cela permettra de ne traiter que les paquets associés au projet, et de donner une structure adaptée à nos besoins. Pour rappel, le but est d'envoyer des paquets de la carte réseau chaque fois que la carte mère envoie une commande à la carte réseau. La commande contiendra éventuellement des données supplémentaires (si la commande est un ls, il faut préciser le chemin du dossier dans lequel l'éxecuter) qui seront traitées par le PC dans un programme qui tournera en continu. Ce programme réceptionne les paquets, les interprète et envoie les réponses à la carte RNDIS. Puis la carte RNDIS décode le paquet réponse, et envoie les données par SPI à la carte mère.<br />
<br />
Pour résumer, la carte RNDIS a 4 tâches principales :<br />
<br />
* Recevoir les commandes SPI envoyées par la carte mère<br />
* Interpréter ces commandes et former puis envoyer les paquets correspondants<br />
* Recevoir les réponses envoyées par le PC<br />
* Envoyer les données contenu dans les réponses par SPI à la carte mère<br />
<br />
=== Test avec protocole connu ===<br />
Tout d'abord, nous allons vérifier que la carte fonctionne avec un protocole connu. Nous allons donc utiliser l'exemple de carte RNDIS fourni dans la LUFA donnée au semestre précédent. <br />
<br />
En uploadant la LUFA, on voit bien après un lsusb que le périphérique apparaît dans la liste :<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Ipa apres configuration ip.png|vignette|408x408px|center]]<br />
|}<br />
<br />
<br />
Nous allons tester le fonctionnement de la carte avec un ping. Nous devons donc ajouter des addresses IP associées à l'interface de la carte. On efffectue la commande ip address add 10.0.0.100/24, on up l'interface avec ip link set usb0 up puis on vérifie avec ip a que l'interface a bien les addresses ip et est à l'état haut : <br />
<br />
<br />
On voit que ç'est le cas.<br />
En utilisant le programme ether fourni en TP de réseau, nous allons regarder les paquets passant sur l'interface usb0 tout en effectuant un ping sur l'addresse 10.0.0.2. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Video ping.mp4|vignette|center]]<br />
|}<br />
<br />
<br />
<br />
Finalement on voit que la carte fonctionne : elle reçoit le ping envoyé par le pc et répond. On peut s'atteler à la suite.<br />
<br />
=== Création du protocole ===<br />
Voici la structure de notre Protocole Ethernet, elle est fortement inspiré de la structure d'un paquet ARP. L'opération/commande sera le premier octet dans les données, suivi d'éventuels arguments supplémentaires.<syntaxhighlight lang="c"><br />
typedef struct<br />
{<br />
uint16_t Operation;/**< Type of operation, either PROTO_OPERATION_REQUEST or PROTO_OPERATION_REPLY */<br />
uint16_t ProtocolType; /** ETHERTYPE_PROTO**/<br />
MAC_Address_t Sender_MACADD; /**< Sender's hardware address */<br />
MAC_Address_t Target_MACADD; /**< Target's hardware address */<br />
uint16_t Length;<br />
uint8_t Data[MAX_COMMAND];<br />
<br />
} Proto_Header_t;<br />
</syntaxhighlight>Cette structure a été ajoutée dans un nouveau fichier appelé Proto.h accompagné de son .c . Dans ce .c, on crée une fonction Proto_ProcessIPPacket(void* InDataStart, void* OutDataStart) (mauvais nom de fonction, il n'y a pas d'IP)qui enverra une réponse lorsque la carte reçoit un paquet. Pour que ce protocole soit effectivement traité, il faut inclure ce fichier dans Ethernet.c, et ajouter un cas correspondant à notre protocole dans le traitement de paquet. On ajoute le protocole en ajoutant la ligne <br />
<br />
<nowiki>#</nowiki>define ETHERTYPE_PROTO 0x8888 <br />
<br />
dans EtherrnetProtocols.h. Ensuite, on doit créé une fonction DecodeProtoHeader dans ProtocolDecoders.c, comme pour les autres protocoles déjà existants, en l'adaptant à la structure de protocole choisi. <br />
<br />
Pour alléger le programme, nous enlevons les autres protocoles qui ne nous serons pas utiles dans le Makefile et sur les fichiers déjà cités. <br />
<br />
On upload le résultat sur la carte RNDIS, on remet l'interface à l'état haut. On veut maintenant utiliser ether mais il y a un problème : ce programme ne connaît pas notre protocole. Nous allons devoir le modifier pour qu'il corresponde à nos besoins. <br />
<br />
=== Modification de ether ===<br />
On doit, dans bpf.c, remplacer le pro tocole dummy (qui est un protocole non utilisé et destiné à être remplacé) par le nôtre. Ensuite, nous allons faire en sorte que les paquets reçus soient enregistrés dans des fichiers textes, de sorte à ce qu'ils puissent être analysés par la suite. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Led ether.mp4|vignette|Vidéo montrant une led clignoter quand nous recevons un paquet avec notre protocole Ethernet (0x8888)]]<br />
!Vous pouvez retrouver notre ether customisé dans notre git à la racine<br />
S8-Pico-Binome-7/Programs/ListeningEther/customether<br />
|}<br />
En envoyant des paquets avec ether -s suivant notre protocole, on constate bien que la carte RNDIS renvoie un paquet réponse forgé par la fonction Proto_ProcessIPPacket et que ce dernier est stocké dans un fichier à chaque fois.<br />
<br />
=== Envoi de paquet ===<br />
Maintenant que la carte est capable de répondre à un paquet suivant notre protocole, nous créons une fonction int16_t Proto_SendIPPacket(void*OutDataStart, uint8_t data[MAX_COMMAND]) (la encore, nom mal choisi) dans Proto.c, qui permet d'envoyer spontanément un paquet suivant notre protocole. Cela se fait grâce à FrameOut. Lorsque l'on ajoute un paquet dans FrameOut, celui-ci est envoyé automatiquement par la carte grâce à la LUFA. Dans la fonction Proto_SendIPPacket, nous allons construire un paquet contenant les données data. Celui ci sera alors envoyé par la carte.<br />
<br />
Pour la suite, nous avons eu des problèmes. Il s'agissait d'ajouter un ISR et la communication SPI sur la LUFA. Pour cela, nous avons dû ajouter un bit à 1 sur SPCR : SPCR |= (1<<SPIE); Pour activer les interruptions sur la SPI. Ensuite, dans le fichier RNDISEthernet.c, nous ajoutons un ISR qui va donc s'activer chaque fois qu'une commande est reçue pour la traiter. Pour tester, nous avons d'abord essayé d'envoyer des paquets avec des données incrémentant de 1 à chaque octet, chaque fois qu'une commande SPI est reçue. En dernier octet des données se trouve un compteur de paquets comptant les paquets envoyés.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Packetwitdata.png|vignette|449x449px]]<br />
|}<br />
En faisant cela, et en utilisant notre ether modifié, on constate que ça fonctionne, seulement nous avons des pertes inexpliqués: le compteur de paquets passe de manièere aléatoire des paquets. Deux causes nous semble possibles : soit le délai entre deux envois de paquets est trop court, soit quelque chose dans la LUFA fait que l'ISR n'est pas appelé à chaque fois. En ajoutant un xor sur une led à chaque appel de l'ISR, et en envoyant un ordre toutes les secondes via la carte mère, nous constatons que la LED clignote deux fois plus lentement qu'elle devrait. Il est donc possible que nous ayons également un problème de configuration de fréquence sur la carte réseau.<br />
<br />
<br />
Nous essayons alors de faire un programme tout simple pour la carte réseau en mettant un ISR (dans ./Programs/TestsSPI/Slave). En utilisant le programme maître fourni par Monsieur Redon (dans PingPongSPI), nous constatons que l'envoi et la réception de commande avec l'ISR fonctionne (nous avons bien la même chose que dans le test SPI avec Pong), mais la LED clignote quand même deux fois plus lentement que ce qu'elle devrait), et nous ne savons pas comment expliquer ce phénomène.<br />
<br />
<br />
Notre méthode fonctionne donc bien mais nous avons à priori un problème dans notre application de celle-ci.<br />
<br />
Le but était par la suite d'introduire une machine à états dans l'ISR: <br />
<br />
* Un état LISTENING qui attend un ordre<br />
* Un état pour chaque commande demandée qui attend la réponse du PC puis qui la traduit en une réponse SPI pour la carte mère. Une fois l'état fini, on revient à l'état Listening.<br />
<br />
Grâce à cela, nous aurions pû gérer chaque commande envoyée par la carte mère puis faire en sorte que la carte réseau ait le comportement approprié.<br />
=== Décodage des paquets de l'ordinateur ===<br />
A la racine S8-Pico-Binome-7/Programs/SPIfichierDistants/PC/ProtoPC.c de notre git, se trouve le code permettant à l'ordinateur d'interpréter les paquets réseau envoyé par la carte RNDIS. Les paquets RNDIS sont enregistrés/écrasés dans des fichiers texte sur le PC. Ces fichiers textes sont décodés par le code et décortiqués. Chaque capsule du paquet et enregistre chaque partie de des capsules Ethernet et de notre Protocole Personnalisé dans des variables pour être réutilisés plus tard. Par exemple, on enregistre les adresses mac destination et sources pour les inverser lors du renvoie du paquet. Ou encore l'enregistrement de la commande (1er octet des données) qui est ensuite interprété en "ls". La suite des données est ensuite interprété comme le path à exécuté avec le "ls". <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Paquet réseau exemple.png|alt=paquet réseau exemple|vignette|paquet réseau exemple]]<br />
!Les deux premières ligne sont notre paquet.txt. Notre code décortique ensuite chaque partie des capsules Ethernet/Notre Protocole et les enregistre et les print.<br />
Vous pouvez aussi voir l'interprétation des données en ASCII. Ces données retranscrites en ASCII sont ensuite utilisés pour exécuté un ls. <br />
Le résultat de ce ls sera ensuite enregistré dans un autre fichier texte qui sera retransformé en paquet Réseau Ethernet encapsulation notre Proto. <br />
On enverra ensuite chaque nom de fichier dans ce fichier texte un par un avec la commande 0x11 pour dire à la carte réseau qu'il y a encore un fichier.<br />
|}<br />
<br />
=== Limitations dû à la SPI ===<br />
Nous avions un bon rythme de travail, dû à la conception du Shield et à d'autres problèmes rencontrés, nous avons été ralenti par ces problèmes. Une fois ces problèmes réglés nous avons pu aider les autre élèves à les surpasser pour qu'ils pussent avancer de leur coté.<br />
<br />
==== Test de la SPI avec PONG ====<br />
Dû a l'erreur causé par le redresseur et la communication SPI, Monsieur REDON nous a donné un code <code>pong.c</code> qui communique par SPI entre la carte réseau et le Shield. Le Shield envoie un octet et la carte-réseau renvoie l'octet du coup d'horloge précédent. Il y a un problèmes, les câbles SPI reliant nos cartes sont défectueux et peuvent parfois renvoyés un octet qui n'a pas lieu d'être. Par exemple, nous envoyons un octet de 16 et nous recevons au coup d'horloge suivant, 192, 108 ou encore 65,..., qui ne sont pas des octets envoyables par le code <code>pong.c</code>. Ces cas sont rares mais ils peuvent amener à des problèmes de communication de paquets réseaux<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Pong screen.png|alt=Pong montrant la comm SPI entre le shield et la carte RNDIS|vignette|Pong montrant la comm SPI entre le shield et la carte RNDIS]]<br />
!Voici un exemple de la fonction PONG fonctionnelle<br />
|}<br />
<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div><br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet. <br />
<br />
Dû à une erreur de design, la carte réseau ne peut être alimentée qu'avec la carte mère alimentée<br />
|-<br />
|[[Fichier:CarteRNDISsoudée.jpg|alt=Carte RNDIS soudée|vignette|357x357px|Carte RNDIS soudée|center]]<br />
|[[Fichier:Visu 3D RNDIS.png|alt=visu 3D RNDIS|vignette|visu 3D RNDIS|center]]<br />
|}<br />
<br />
===== Erreur de design =====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:PIN ALIM non connecté.png|alt=PIN ALIM non connecté|vignette|PIN ALIM non connecté]]<br />
!Comme vous pouvez l'observe, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC. <br />
Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand, <br />
<br />
le Shield où la carte mère est alimentée en 5V.<br />
<br />
Solution : connecter cette PIN ALIM avec les VCC en plus de la PIN ALIM de l'USB + mettre un cavalier pour basculer entre l'alimentation<br />
par la carte-mère où directement par USB<br />
|-<br />
|[[Fichier:PIN ALIM non connecté USB.png|alt=PIN ALIM non connecté USB|vignette|PIN ALIM non connecté USB]]<br />
|<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== Conclusion ==<br />
En conclusion, ce projet nous a permis de mettre en application les différentes parties du programme de ce semestre. Nous avons revu la CAO, avons vu en détail comment l'ordonnancement fonctionnait et comment les éléments constituant des échanges réseaux intéragissaient. <br />
<br />
Nous avons réussi à effectuer toutes les communications nécessaires au projet final, en faisant cela nous avons une preuve que nous pouvons, à partir de notre travail, concevoir le soft prenant en charge toutes les commandes demandées.<br />
<br />
Cependant, ayant rencontrés de nombreux problèmes en essayant de faire fonctionner ces interactions (problème sur le releveur de niveau, problème de perte de paquets, ...) nous n'avons pas pu automatiser ces différentes interactions pour concevoir la LUFA finale.<br />
<br />
Malgré tout, grâce à cela, nous avons beaucoup mis à l'épreuve notre capacité à résoudre des problèmes sur tous les plans (électronique et informatique) et cela nous a sans doute plus appris que si nous n'avions eu aucun problème et avions réussi du premier coup chaque partie du projet.<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=7393SE4Binome2024-72025-01-26T16:50:00Z<p>Rboursau : /* Envoi de paquet */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=== Problèmes rencontrés avec la COMMUNICATION SPI ===<br />
<br />
Lors de la programmation de notre carte RNDIS, nous avons rencontré un problème de communication SPI de notre carte RNDIS vers notre Shield. <br />
Nous pouvons envoyer des paquets/données du Shield vers la carte RNDIS mais pas dans l'autre sens. Le problème résidait sur le Shield. Plus particulièrement sur le releveur de niveau de tension. La résistance soudée à la sortie du <code>PIN MOSI_1</code> ne devrait pas être ici. Dû à cette erreur de design, le releveur de niveau faisait l'inverse de ce qu'il doit normalement faire : il baissait notre niveau de tension.<br />
Normalement, le releveur de niveau doit augmenter la tension pour quelle puisse être utilisée/utilisable par le MicroP. Lors de nos tests, nous avions <code>+5V</code> du Shield vers notre carte RNDIS, ce qui est la tension optimale mais n'obtenons que <code>+1.5V</code> de notre carte RNDIS vers notre Shield ce qui est bien insuffisant car les MicroP que nous avons ne fonctionne qu'avec des tensions à minima de <code>+3.3V</code>.<br />
Nous avons d'abord tenter de couper la piste à l'entrée du <code>PIN MISO</code> et d'y mettre la résistance qui est en sortie du <code>PIN MISO_1</code> et de remplacer la résistance en sortie du <code>PIN MISO_1</code> par un fil. Cela régla notre problème de tension mais nous ne pouvions plus détecter la carte SD.<br />
Nous avons donc enlever toutes les résistances et fils des pistes <code>MOSI</code> à l'entrée et sortie du releveur de niveau et avons court-circuité les deux pistes. Il faut aussi sectionner le fil de cuivre <code>MOSI</code> sinon le courant ira en sur le fil de cuivre <code>MISO_1</code> ET le fil <code>MOSI</code> et nous voulons que le courant aille uniquement sur <code>MISO_1</code> . Cela régla notre problème de tension ET de détection de carte SD.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Releveur de niveau PinMISO test1.png|gauche|vignette|Schéma montrant les tests que nous avons fait pour régler le problème de tension du MISO]]<br />
![[Fichier:Releveur de niveau PinMISO.png|alt=Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD|vignette|Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD]]<br />
|-<br />
|<br />
|<br />
|}<br />
<br />
== Programmation de la carte RNDIS ==<br />
<br />
Pour utiliser la carte RNDIS, nous allons créer notre protocole Ethernet en s'inspirant de l'ARP. Cela permettra de ne traiter que les paquets associés au projet, et de donner une structure adaptée à nos besoins. Pour rappel, le but est d'envoyer des paquets de la carte réseau chaque fois que la carte mère envoie une commande à la carte réseau. La commande contiendra éventuellement des données supplémentaires (si la commande est un ls, il faut préciser le chemin du dossier dans lequel l'éxecuter) qui seront traitées par le PC dans un programme qui tournera en continu. Ce programme réceptionne les paquets, les interprète et envoie les réponses à la carte RNDIS. Puis la carte RNDIS décode le paquet réponse, et envoie les données par SPI à la carte mère.<br />
<br />
Pour résumer, la carte RNDIS a 4 tâches principales :<br />
<br />
* Recevoir les commandes SPI envoyées par la carte mère<br />
* Interpréter ces commandes et former puis envoyer les paquets correspondants<br />
* Recevoir les réponses envoyées par le PC<br />
* Envoyer les données contenu dans les réponses par SPI à la carte mère<br />
<br />
=== Test avec protocole connu ===<br />
Tout d'abord, nous allons vérifier que la carte fonctionne avec un protocole connu. Nous allons donc utiliser l'exemple de carte RNDIS fourni dans la LUFA donnée au semestre précédent. <br />
<br />
En uploadant la LUFA, on voit bien après un lsusb que le périphérique apparaît dans la liste :<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Ipa apres configuration ip.png|vignette|408x408px|center]]<br />
|}<br />
<br />
<br />
Nous allons tester le fonctionnement de la carte avec un ping. Nous devons donc ajouter des addresses IP associées à l'interface de la carte. On efffectue la commande ip address add 10.0.0.100/24, on up l'interface avec ip link set usb0 up puis on vérifie avec ip a que l'interface a bien les addresses ip et est à l'état haut : <br />
<br />
<br />
On voit que ç'est le cas.<br />
En utilisant le programme ether fourni en TP de réseau, nous allons regarder les paquets passant sur l'interface usb0 tout en effectuant un ping sur l'addresse 10.0.0.2. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Video ping.mp4|vignette|center]]<br />
|}<br />
<br />
<br />
<br />
Finalement on voit que la carte fonctionne : elle reçoit le ping envoyé par le pc et répond. On peut s'atteler à la suite.<br />
<br />
=== Création du protocole ===<br />
Voici la structure de notre Protocole Ethernet, elle est fortement inspiré de la structure d'un paquet ARP. L'opération/commande sera le premier octet dans les données, suivi d'éventuels arguments supplémentaires.<syntaxhighlight lang="c"><br />
typedef struct<br />
{<br />
uint16_t Operation;/**< Type of operation, either PROTO_OPERATION_REQUEST or PROTO_OPERATION_REPLY */<br />
uint16_t ProtocolType; /** ETHERTYPE_PROTO**/<br />
MAC_Address_t Sender_MACADD; /**< Sender's hardware address */<br />
MAC_Address_t Target_MACADD; /**< Target's hardware address */<br />
uint16_t Length;<br />
uint8_t Data[MAX_COMMAND];<br />
<br />
} Proto_Header_t;<br />
</syntaxhighlight>Cette structure a été ajoutée dans un nouveau fichier appelé Proto.h accompagné de son .c . Dans ce .c, on crée une fonction Proto_ProcessIPPacket(void* InDataStart, void* OutDataStart) (mauvais nom de fonction, il n'y a pas d'IP)qui enverra une réponse lorsque la carte reçoit un paquet. Pour que ce protocole soit effectivement traité, il faut inclure ce fichier dans Ethernet.c, et ajouter un cas correspondant à notre protocole dans le traitement de paquet. On ajoute le protocole en ajoutant la ligne <br />
<br />
<nowiki>#</nowiki>define ETHERTYPE_PROTO 0x8888 <br />
<br />
dans EtherrnetProtocols.h. Ensuite, on doit créé une fonction DecodeProtoHeader dans ProtocolDecoders.c, comme pour les autres protocoles déjà existants, en l'adaptant à la structure de protocole choisi. <br />
<br />
Pour alléger le programme, nous enlevons les autres protocoles qui ne nous serons pas utiles dans le Makefile et sur les fichiers déjà cités. <br />
<br />
On upload le résultat sur la carte RNDIS, on remet l'interface à l'état haut. On veut maintenant utiliser ether mais il y a un problème : ce programme ne connaît pas notre protocole. Nous allons devoir le modifier pour qu'il corresponde à nos besoins. <br />
<br />
=== Modification de ether ===<br />
On doit, dans bpf.c, remplacer le pro tocole dummy (qui est un protocole non utilisé et destiné à être remplacé) par le nôtre. Ensuite, nous allons faire en sorte que les paquets reçus soient enregistrés dans des fichiers textes, de sorte à ce qu'ils puissent être analysés par la suite. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Led ether.mp4|vignette|Vidéo montrant une led clignoter quand nous recevons un paquet avec notre protocole Ethernet (0x8888)]]<br />
!Vous pouvez retrouver notre ether customisé dans notre git à la racine<br />
S8-Pico-Binome-7/Programs/ListeningEther/customether<br />
|}<br />
En envoyant des paquets avec ether -s suivant notre protocole, on constate bien que la carte RNDIS renvoie un paquet réponse forgé par la fonction Proto_ProcessIPPacket et que ce dernier est stocké dans un fichier à chaque fois.<br />
<br />
=== Envoi de paquet ===<br />
Maintenant que la carte est capable de répondre à un paquet suivant notre protocole, nous créons une fonction int16_t Proto_SendIPPacket(void*OutDataStart, uint8_t data[MAX_COMMAND]) (la encore, nom mal choisi) dans Proto.c, qui permet d'envoyer spontanément un paquet suivant notre protocole. Cela se fait grâce à FrameOut. Lorsque l'on ajoute un paquet dans FrameOut, celui-ci est envoyé automatiquement par la carte grâce à la LUFA. Dans la fonction Proto_SendIPPacket, nous allons construire un paquet contenant les données data. Celui ci sera alors envoyé par la carte.<br />
<br />
Pour la suite, nous avons eu des problèmes. Il s'agissait d'ajouter un ISR et la communication SPI sur la LUFA. Pour cela, nous avons dû ajouter un bit à 1 sur SPCR : SPCR |= (1<<SPIE); Pour activer les interruptions sur la SPI. Ensuite, dans le fichier RNDISEthernet.c, nous ajoutons un ISR qui va donc s'activer chaque fois qu'une commande est reçue pour la traiter. Pour tester, nous avons d'abord essayé d'envoyer des paquets avec des données incrémentant de 1 à chaque octet, chaque fois qu'une commande SPI est reçue. En dernier octet des données se trouve un compteur de paquets comptant les paquets envoyés.<br />
<br />
En faisant cela, et en utilisant notre ether modifié, on constate que ça fonctionne, seulement nous avons des pertes inexpliqués: le compteur de paquets passe de manièere aléatoire des paquets. Deux causes nous semble possibles : soit le délai entre deux envois de paquets est trop court, soit quelque chose dans la LUFA fait que l'ISR n'est pas appelé à chaque fois. En ajoutant un xor sur une led à chaque appel de l'ISR, et en envoyant un ordre toutes les secondes via la carte mère, nous constatons que la LED clignote deux fois plus lentement qu'elle devrait. Il est donc possible que nous ayons également un problème de configuration de fréquence sur la carte réseau.<br />
<br />
<br />
Nous essayons alors de faire un programme tout simple pour la carte réseau en mettant un ISR (dans ./Programs/TestsSPI/Slave). En utilisant le programme maître fourni par Monsieur Redon (dans PingPongSPI), nous constatons que l'envoi et la réception de commande avec l'ISR fonctionne (nous avons bien la même chose que dans le test SPI avec Pong), mais la LED clignote quand même deux fois plus lentement que ce qu'elle devrait), et nous ne savons pas comment expliquer ce phénomène.<br />
<br />
<br />
Notre méthode fonctionne donc bien mais nous avons à priori un problème dans notre application de celle-ci.<br />
<br />
Le but était par la suite d'introduire une machine à états dans l'ISR: <br />
<br />
* Un état LISTENING qui attend un ordre<br />
* Un état pour chaque commande demandée qui attend la réponse du PC puis qui la traduit en une réponse SPI pour la carte mère. Une fois l'état fini, on revient à l'état Listening.<br />
<br />
Grâce à cela, nous aurions pû gérer chaque commande envoyée par la carte mère puis faire en sorte que la carte réseau ait le comportement approprié.<br />
[[Fichier:Packetwitdata.png|vignette]]<br />
<br />
=== Décodage des paquets de l'ordinateur ===<br />
A la racine S8-Pico-Binome-7/Programs/SPIfichierDistants/PC/ProtoPC.c de notre git, se trouve le code permettant à l'ordinateur d'interpréter les paquets réseau envoyé par la carte RNDIS. Les paquets RNDIS sont enregistrés/écrasés dans des fichiers texte sur le PC. Ces fichiers textes sont décodés par le code et décortiqués. Chaque capsule du paquet et enregistre chaque partie de des capsules Ethernet et de notre Protocole Personnalisé dans des variables pour être réutilisés plus tard. Par exemple, on enregistre les adresses mac destination et sources pour les inverser lors du renvoie du paquet. Ou encore l'enregistrement de la commande (1er octet des données) qui est ensuite interprété en "ls". La suite des données est ensuite interprété comme le path à exécuté avec le "ls". <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Paquet réseau exemple.png|alt=paquet réseau exemple|vignette|paquet réseau exemple]]<br />
!Les deux premières ligne sont notre paquet.txt. Notre code décortique ensuite chaque partie des capsules Ethernet/Notre Protocole et les enregistre et les print.<br />
Vous pouvez aussi voir l'interprétation des données en ASCII. Ces données retranscrites en ASCII sont ensuite utilisés pour exécuté un ls. <br />
Le résultat de ce ls sera ensuite enregistré dans un autre fichier texte qui sera retransformé en paquet Réseau Ethernet encapsulation notre Proto. <br />
On enverra ensuite chaque nom de fichier dans ce fichier texte un par un avec la commande 0x11 pour dire à la carte réseau qu'il y a encore un fichier.<br />
|}<br />
<br />
=== Limitations dû à la SPI ===<br />
Nous avions un bon rythme de travail, dû à la conception du Shield et à d'autres problèmes rencontrés, nous avons été ralenti par ces problèmes. Une fois ces problèmes réglés nous avons pu aider les autre élèves à les surpasser pour qu'ils pussent avancer de leur coté.<br />
<br />
==== Test de la SPI avec PONG ====<br />
Dû a l'erreur causé par le redresseur et la communication SPI, Monsieur REDON nous a donné un code <code>pong.c</code> qui communique par SPI entre la carte réseau et le Shield. Le Shield envoie un octet et la carte-réseau renvoie l'octet du coup d'horloge précédent. Il y a un problèmes, les câbles SPI reliant nos cartes sont défectueux et peuvent parfois renvoyés un octet qui n'a pas lieu d'être. Par exemple, nous envoyons un octet de 16 et nous recevons au coup d'horloge suivant, 192, 108 ou encore 65,..., qui ne sont pas des octets envoyables par le code <code>pong.c</code>. Ces cas sont rares mais ils peuvent amener à des problèmes de communication de paquets réseaux<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Pong screen.png|alt=Pong montrant la comm SPI entre le shield et la carte RNDIS|vignette|Pong montrant la comm SPI entre le shield et la carte RNDIS]]<br />
!Voici un exemple de la fonction PONG fonctionnelle<br />
|}<br />
<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div><br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet. <br />
<br />
Dû à une erreur de design, la carte réseau ne peut être alimentée qu'avec la carte mère alimentée<br />
|-<br />
|[[Fichier:CarteRNDISsoudée.jpg|alt=Carte RNDIS soudée|vignette|357x357px|Carte RNDIS soudée|center]]<br />
|[[Fichier:Visu 3D RNDIS.png|alt=visu 3D RNDIS|vignette|visu 3D RNDIS|center]]<br />
|}<br />
<br />
===== Erreur de design =====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:PIN ALIM non connecté.png|alt=PIN ALIM non connecté|vignette|PIN ALIM non connecté]]<br />
!Comme vous pouvez l'observe, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC. <br />
Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand, <br />
<br />
le Shield où la carte mère est alimentée en 5V.<br />
<br />
Solution : connecter cette PIN ALIM avec les VCC en plus de la PIN ALIM de l'USB + mettre un cavalier pour basculer entre l'alimentation<br />
par la carte-mère où directement par USB<br />
|-<br />
|[[Fichier:PIN ALIM non connecté USB.png|alt=PIN ALIM non connecté USB|vignette|PIN ALIM non connecté USB]]<br />
|<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Packetwitdata.png&diff=7387Fichier:Packetwitdata.png2025-01-26T16:39:23Z<p>Rboursau : </p>
<hr />
<div>paquet</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=7375SE4Binome2024-72025-01-26T16:19:57Z<p>Rboursau : /* Envoi de paquet */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=== Problèmes rencontrés avec la COMMUNICATION SPI ===<br />
<br />
Lors de la programmation de notre carte RNDIS, nous avons rencontré un problème de communication SPI de notre carte RNDIS vers notre Shield. <br />
Nous pouvons envoyer des paquets/données du Shield vers la carte RNDIS mais pas dans l'autre sens. Le problème résidait sur le Shield. Plus particulièrement sur le releveur de niveau de tension. La résistance soudée à la sortie du <code>PIN MOSI_1</code> ne devrait pas être ici. Dû à cette erreur de design, le releveur de niveau faisait l'inverse de ce qu'il doit normalement faire : il baissait notre niveau de tension.<br />
Normalement, le releveur de niveau doit augmenter la tension pour quelle puisse être utilisée/utilisable par le MicroP. Lors de nos tests, nous avions <code>+5V</code> du Shield vers notre carte RNDIS, ce qui est la tension optimale mais n'obtenons que <code>+1.5V</code> de notre carte RNDIS vers notre Shield ce qui est bien insuffisant car les MicroP que nous avons ne fonctionne qu'avec des tensions à minima de <code>+3.3V</code>.<br />
Nous avons d'abord tenter de couper la piste à l'entrée du <code>PIN MISO</code> et d'y mettre la résistance qui est en sortie du <code>PIN MISO_1</code> et de remplacer la résistance en sortie du <code>PIN MISO_1</code> par un fil. Cela régla notre problème de tension mais nous ne pouvions plus détecter la carte SD.<br />
Nous avons donc enlever toutes les résistances et fils des pistes <code>MOSI</code> à l'entrée et sortie du releveur de niveau et avons court-circuité les deux pistes. Il faut aussi sectionner le fil de cuivre <code>MOSI</code> sinon le courant ira en sur le fil de cuivre <code>MISO_1</code> ET le fil <code>MOSI</code> et nous voulons que le courant aille uniquement sur <code>MISO_1</code> . Cela régla notre problème de tension ET de détection de carte SD.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Releveur de niveau PinMISO test1.png|gauche|vignette|Schéma montrant les tests que nous avons fait pour régler le problème de tension du MISO]]<br />
![[Fichier:Releveur de niveau PinMISO.png|alt=Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD|vignette|Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD]]<br />
|-<br />
|<br />
|<br />
|}<br />
<br />
== Programmation de la carte RNDIS ==<br />
<br />
Pour utiliser la carte RNDIS, nous allons créer notre protocole Ethernet en s'inspirant de l'ARP. Cela permettra de ne traiter que les paquets associés au projet, et de donner une structure adaptée à nos besoins. Pour rappel, le but est d'envoyer des paquets de la carte réseau chaque fois que la carte mère envoie une commande à la carte réseau. La commande contiendra éventuellement des données supplémentaires (si la commande est un ls, il faut préciser le chemin du dossier dans lequel l'éxecuter) qui seront traitées par le PC dans un programme qui tournera en continu. Ce programme réceptionne les paquets, les interprète et envoie les réponses à la carte RNDIS. Puis la carte RNDIS décode le paquet réponse, et envoie les données par SPI à la carte mère.<br />
<br />
Pour résumer, la carte RNDIS a 4 tâches principales :<br />
<br />
* Recevoir les commandes SPI envoyées par la carte mère<br />
* Interpréter ces commandes et former puis envoyer les paquets correspondants<br />
* Recevoir les réponses envoyées par le PC<br />
* Envoyer les données contenu dans les réponses par SPI à la carte mère<br />
<br />
=== Test avec protocole connu ===<br />
Tout d'abord, nous allons vérifier que la carte fonctionne avec un protocole connu. Nous allons donc utiliser l'exemple de carte RNDIS fourni dans la LUFA donnée au semestre précédent. <br />
<br />
En uploadant la LUFA, on voit bien après un lsusb que le périphérique apparaît dans la liste :<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Ipa apres configuration ip.png|vignette|408x408px|center]]<br />
|}<br />
<br />
<br />
Nous allons tester le fonctionnement de la carte avec un ping. Nous devons donc ajouter des addresses IP associées à l'interface de la carte. On efffectue la commande ip address add 10.0.0.100/24, on up l'interface avec ip link set usb0 up puis on vérifie avec ip a que l'interface a bien les addresses ip et est à l'état haut : <br />
<br />
<br />
On voit que ç'est le cas.<br />
En utilisant le programme ether fourni en TP de réseau, nous allons regarder les paquets passant sur l'interface usb0 tout en effectuant un ping sur l'addresse 10.0.0.2. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Video ping.mp4|vignette|center]]<br />
|}<br />
<br />
<br />
<br />
Finalement on voit que la carte fonctionne : elle reçoit le ping envoyé par le pc et répond. On peut s'atteler à la suite.<br />
<br />
=== Création du protocole ===<br />
Voici la structure de notre Protocole Ethernet, elle est fortement inspiré de la structure d'un paquet ARP. L'opération/commande sera le premier octet dans les données, suivi d'éventuels arguments supplémentaires.<syntaxhighlight lang="c"><br />
typedef struct<br />
{<br />
uint16_t Operation;/**< Type of operation, either PROTO_OPERATION_REQUEST or PROTO_OPERATION_REPLY */<br />
uint16_t ProtocolType; /** ETHERTYPE_PROTO**/<br />
MAC_Address_t Sender_MACADD; /**< Sender's hardware address */<br />
MAC_Address_t Target_MACADD; /**< Target's hardware address */<br />
uint16_t Length;<br />
uint8_t Data[MAX_COMMAND];<br />
<br />
} Proto_Header_t;<br />
</syntaxhighlight>Cette structure a été ajoutée dans un nouveau fichier appelé Proto.h accompagné de son .c . Dans ce .c, on crée une fonction Proto_ProcessIPPacket(void* InDataStart, void* OutDataStart) (mauvais nom de fonction, il n'y a pas d'IP)qui enverra une réponse lorsque la carte reçoit un paquet. Pour que ce protocole soit effectivement traité, il faut inclure ce fichier dans Ethernet.c, et ajouter un cas correspondant à notre protocole dans le traitement de paquet. On ajoute le protocole en ajoutant la ligne <br />
<br />
<nowiki>#</nowiki>define ETHERTYPE_PROTO 0x8888 <br />
<br />
dans EtherrnetProtocols.h. Ensuite, on doit créé une fonction DecodeProtoHeader dans ProtocolDecoders.c, comme pour les autres protocoles déjà existants, en l'adaptant à la structure de protocole choisi. <br />
<br />
Pour alléger le programme, nous enlevons les autres protocoles qui ne nous serons pas utiles dans le Makefile et sur les fichiers déjà cités. <br />
<br />
On upload le résultat sur la carte RNDIS, on remet l'interface à l'état haut. On veut maintenant utiliser ether mais il y a un problème : ce programme ne connaît pas notre protocole. Nous allons devoir le modifier pour qu'il corresponde à nos besoins. <br />
<br />
=== Modification de ether ===<br />
On doit, dans bpf.c, remplacer le pro tocole dummy (qui est un protocole non utilisé et destiné à être remplacé) par le nôtre. Ensuite, nous allons faire en sorte que les paquets reçus soient enregistrés dans des fichiers textes, de sorte à ce qu'ils puissent être analysés par la suite. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Led ether.mp4|vignette|Vidéo montrant une led clignoter quand nous recevons un paquet avec notre protocole Ethernet (0x8888)]]<br />
!Vous pouvez retrouver notre ether customisé dans notre git à la racine<br />
S8-Pico-Binome-7/Programs/ListeningEther/customether<br />
|}<br />
En envoyant des paquets avec ether -s suivant notre protocole, on constate bien que la carte RNDIS renvoie un paquet réponse forgé par la fonction Proto_ProcessIPPacket et que ce dernier est stocké dans un fichier à chaque fois.<br />
<br />
=== Envoi de paquet ===<br />
Maintenant que la carte est capable de répondre à un paquet suivant notre protocole, nous créons une fonction int16_t Proto_SendIPPacket(void*OutDataStart, uint8_t data[MAX_COMMAND]) (la encore, nom mal choisi), qui permet d'envoyer spontanément un paquet suivant notre protocole. Cela se fait grâce à FrameOut. Lorsque l'on ajoute un paquet dans FrameOut, celui-ci est envoyé automatiquement par la carte grâce à la LUFA.<br />
<br />
=== Décodage des paquets de l'ordinateur ===<br />
A la racine S8-Pico-Binome-7/Programs/SPIfichierDistants/PC/ProtoPC.c de notre git, se trouve le code permettant à l'ordinateur d'interpréter les paquets réseau envoyé par la carte RNDIS. Les paquets RNDIS sont enregistrés/écrasés dans des fichiers texte sur le PC. Ces fichiers textes sont décodés par le code et décortiqués. Chaque capsule du paquet et enregistre chaque partie de des capsules Ethernet et de notre Protocole Personnalisé dans des variables pour être réutilisés plus tard. Par exemple, on enregistre les adresses mac destination et sources pour les inverser lors du renvoie du paquet. Ou encore l'enregistrement de la commande (1er octet des données) qui est ensuite interprété en "ls". La suite des données est ensuite interprété comme le path à exécuté avec le "ls". <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Paquet réseau exemple.png|alt=paquet réseau exemple|vignette|paquet réseau exemple]]<br />
!Les deux premières ligne sont notre paquet.txt. Notre code décortique ensuite chaque partie des capsules Ethernet/Notre Protocole et les enregistre et les print.<br />
Vous pouvez aussi voir l'interprétation des données en ASCII. Ces données retranscrites en ASCII sont ensuite utilisés pour exécuté un ls. <br />
Le résultat de ce ls sera ensuite enregistré dans un autre fichier texte qui sera retransformé en paquet Réseau Ethernet encapsulation notre Proto. <br />
On enverra ensuite chaque nom de fichier dans ce fichier texte un par un avec la commande 0x11 pour dire à la carte réseau qu'il y a encore un fichier.<br />
|}<br />
<br />
=== Limitations dû à la SPI ===<br />
Nous avions un bon rythme de travail, dû à la conception du Shield et à d'autres problèmes rencontrés, nous avons été ralenti par ces problèmes. Une fois ces problèmes réglés nous avons pu aider les autre élèves à les surpasser pour qu'ils pussent avancer de leur coté.<br />
<br />
==== Test de la SPI avec PONG ====<br />
Dû a l'erreur causé par le redresseur et la communication SPI, Monsieur REDON nous a donné un code <code>pong.c</code> qui communique par SPI entre la carte réseau et le Shield. Le Shield envoie un octet et la carte-réseau renvoie l'octet du coup d'horloge précédent. Il y a un problèmes, les câbles SPI reliant nos cartes sont défectueux et peuvent parfois renvoyés un octet qui n'a pas lieu d'être. Par exemple, nous envoyons un octet de 16 et nous recevons au coup d'horloge suivant, 192, 108 ou encore 65,..., qui ne sont pas des octets envoyables par le code <code>pong.c</code>. Ces cas sont rares mais ils peuvent amener à des problèmes de communication de paquets réseaux<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Pong screen.png|alt=Pong montrant la comm SPI entre le shield et la carte RNDIS|vignette|Pong montrant la comm SPI entre le shield et la carte RNDIS]]<br />
!Voici un exemple de la fonction PONG fonctionnelle<br />
|}<br />
<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div><br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet. <br />
<br />
Dû à une erreur de design, la carte réseau ne peut être alimentée qu'avec la carte mère alimentée<br />
|-<br />
|[[Fichier:CarteRNDISsoudée.jpg|alt=Carte RNDIS soudée|vignette|357x357px|Carte RNDIS soudée|center]]<br />
|[[Fichier:Visu 3D RNDIS.png|alt=visu 3D RNDIS|vignette|visu 3D RNDIS|center]]<br />
|}<br />
<br />
===== Erreur de design =====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:PIN ALIM non connecté.png|alt=PIN ALIM non connecté|vignette|PIN ALIM non connecté]]<br />
!Comme vous pouvez l'observe, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC. <br />
Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand, <br />
<br />
le Shield où la carte mère est alimentée en 5V.<br />
<br />
Solution : connecter cette PIN ALIM avec les VCC en plus de la PIN ALIM de l'USB + mettre un cavalier pour basculer entre l'alimentation<br />
par la carte-mère où directement par USB<br />
|-<br />
|[[Fichier:PIN ALIM non connecté USB.png|alt=PIN ALIM non connecté USB|vignette|PIN ALIM non connecté USB]]<br />
|<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=7359SE4Binome2024-72025-01-26T16:02:29Z<p>Rboursau : /* Envoi de paquet */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=== Problèmes rencontrés avec la COMMUNICATION SPI ===<br />
<br />
Lors de la programmation de notre carte RNDIS, nous avons rencontré un problème de communication SPI de notre carte RNDIS vers notre Shield. <br />
Nous pouvons envoyer des paquets/données du Shield vers la carte RNDIS mais pas dans l'autre sens. Le problème résidait sur le Shield. Plus particulièrement sur le releveur de niveau de tension. La résistance soudée à la sortie du <code>PIN MOSI_1</code> ne devrait pas être ici. Dû à cette erreur de design, le releveur de niveau faisait l'inverse de ce qu'il doit normalement faire : il baissait notre niveau de tension.<br />
Normalement, le releveur de niveau doit augmenter la tension pour quelle puisse être utilisée/utilisable par le MicroP. Lors de nos tests, nous avions <code>+5V</code> du Shield vers notre carte RNDIS, ce qui est la tension optimale mais n'obtenons que <code>+1.5V</code> de notre carte RNDIS vers notre Shield ce qui est bien insuffisant car les MicroP que nous avons ne fonctionne qu'avec des tensions à minima de <code>+3.3V</code>.<br />
Nous avons d'abord tenter de couper la piste à l'entrée du <code>PIN MISO</code> et d'y mettre la résistance qui est en sortie du <code>PIN MISO_1</code> et de remplacer la résistance en sortie du <code>PIN MISO_1</code> par un fil. Cela régla notre problème de tension mais nous ne pouvions plus détecter la carte SD.<br />
Nous avons donc enlever toutes les résistances et fils des pistes <code>MOSI</code> à l'entrée et sortie du releveur de niveau et avons court-circuité les deux pistes. Il faut aussi sectionner le fil de cuivre <code>MOSI</code> sinon le courant ira en sur le fil de cuivre <code>MISO_1</code> ET le fil <code>MOSI</code> et nous voulons que le courant aille uniquement sur <code>MISO_1</code> . Cela régla notre problème de tension ET de détection de carte SD.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Releveur de niveau PinMISO test1.png|gauche|vignette|Schéma montrant les tests que nous avons fait pour régler le problème de tension du MISO]]<br />
![[Fichier:Releveur de niveau PinMISO.png|alt=Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD|vignette|Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD]]<br />
|-<br />
|<br />
|<br />
|}<br />
<br />
== Programmation de la carte RNDIS ==<br />
<br />
Pour utiliser la carte RNDIS, nous allons créer notre protocole Ethernet en s'inspirant de l'ARP. Cela permettra de ne traiter que les paquets associés au projet, et de donner une structure adaptée à nos besoins. Pour rappel, le but est d'envoyer des paquets de la carte réseau chaque fois que la carte mère envoie une commande à la carte réseau. La commande contiendra éventuellement des données supplémentaires (si la commande est un ls, il faut préciser le chemin du dossier dans lequel l'éxecuter) qui seront traitées par le PC dans un programme qui tournera en continu. Ce programme réceptionne les paquets, les interprète et envoie les réponses à la carte RNDIS. Puis la carte RNDIS décode le paquet réponse, et envoie les données par SPI à la carte mère.<br />
<br />
Pour résumer, la carte RNDIS a 4 tâches principales :<br />
<br />
* Recevoir les commandes SPI envoyées par la carte mère<br />
* Interpréter ces commandes et former puis envoyer les paquets correspondants<br />
* Recevoir les réponses envoyées par le PC<br />
* Envoyer les données contenu dans les réponses par SPI à la carte mère<br />
<br />
=== Test avec protocole connu ===<br />
Tout d'abord, nous allons vérifier que la carte fonctionne avec un protocole connu. Nous allons donc utiliser l'exemple de carte RNDIS fourni dans la LUFA donnée au semestre précédent. <br />
<br />
En uploadant la LUFA, on voit bien après un lsusb que le périphérique apparaît dans la liste :<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Ipa apres configuration ip.png|vignette|408x408px|center]]<br />
|}<br />
<br />
<br />
Nous allons tester le fonctionnement de la carte avec un ping. Nous devons donc ajouter des addresses IP associées à l'interface de la carte. On efffectue la commande ip address add 10.0.0.100/24, on up l'interface avec ip link set usb0 up puis on vérifie avec ip a que l'interface a bien les addresses ip et est à l'état haut : <br />
<br />
<br />
On voit que ç'est le cas.<br />
En utilisant le programme ether fourni en TP de réseau, nous allons regarder les paquets passant sur l'interface usb0 tout en effectuant un ping sur l'addresse 10.0.0.2. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Video ping.mp4|vignette|center]]<br />
|}<br />
<br />
<br />
<br />
Finalement on voit que la carte fonctionne : elle reçoit le ping envoyé par le pc et répond. On peut s'atteler à la suite.<br />
<br />
=== Création du protocole ===<br />
Voici la structure de notre Protocole Ethernet, elle est fortement inspiré de la structure d'un paquet ARP. L'opération/commande sera le premier octet dans les données, suivi d'éventuels arguments supplémentaires.<syntaxhighlight lang="c"><br />
typedef struct<br />
{<br />
uint16_t Operation;/**< Type of operation, either PROTO_OPERATION_REQUEST or PROTO_OPERATION_REPLY */<br />
uint16_t ProtocolType; /** ETHERTYPE_PROTO**/<br />
MAC_Address_t Sender_MACADD; /**< Sender's hardware address */<br />
MAC_Address_t Target_MACADD; /**< Target's hardware address */<br />
uint16_t Length;<br />
uint8_t Data[MAX_COMMAND];<br />
<br />
} Proto_Header_t;<br />
</syntaxhighlight>Cette structure a été ajoutée dans un nouveau fichier appelé Proto.h accompagné de son .c . Dans ce .c, on crée une fonction Proto_ProcessIPPacket(void* InDataStart, void* OutDataStart) (mauvais nom de fonction, il n'y a pas d'IP)qui enverra une réponse lorsque la carte reçoit un paquet. Pour que ce protocole soit effectivement traité, il faut inclure ce fichier dans Ethernet.c, et ajouter un cas correspondant à notre protocole dans le traitement de paquet. On ajoute le protocole en ajoutant la ligne <br />
<br />
<nowiki>#</nowiki>define ETHERTYPE_PROTO 0x8888 <br />
<br />
dans EtherrnetProtocols.h. Ensuite, on doit créé une fonction DecodeProtoHeader dans ProtocolDecoders.c, comme pour les autres protocoles déjà existants, en l'adaptant à la structure de protocole choisi. <br />
<br />
Pour alléger le programme, nous enlevons les autres protocoles qui ne nous serons pas utiles dans le Makefile et sur les fichiers déjà cités. <br />
<br />
On upload le résultat sur la carte RNDIS, on remet l'interface à l'état haut. On veut maintenant utiliser ether mais il y a un problème : ce programme ne connaît pas notre protocole. Nous allons devoir le modifier pour qu'il corresponde à nos besoins. <br />
<br />
=== Modification de ether ===<br />
On doit, dans bpf.c, remplacer le pro tocole dummy (qui est un protocole non utilisé et destiné à être remplacé) par le nôtre. Ensuite, nous allons faire en sorte que les paquets reçus soient enregistrés dans des fichiers textes, de sorte à ce qu'ils puissent être analysés par la suite. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Led ether.mp4|vignette|Vidéo montrant une led clignoter quand nous recevons un paquet avec notre protocole Ethernet (0x8888)]]<br />
!Vous pouvez retrouver notre ether customisé dans notre git à la racine<br />
S8-Pico-Binome-7/Programs/ListeningEther/customether<br />
|}<br />
En envoyant des paquets avec ether -s suivant notre protocole, on constate bien que la carte RNDIS renvoie un paquet réponse forgé par la fonction Proto_ProcessIPPacket et que ce dernier est stocké dans un fichier à chaque fois.<br />
<br />
=== Envoi de paquet ===<br />
<br />
=== Décodage des paquets de l'ordinateur ===<br />
A la racine S8-Pico-Binome-7/Programs/SPIfichierDistants/PC/ProtoPC.c de notre git, se trouve le code permettant à l'ordinateur d'interpréter les paquets réseau envoyé par la carte RNDIS. Les paquets RNDIS sont enregistrés/écrasés dans des fichiers texte sur le PC. Ces fichiers textes sont décodés par le code et décortiqués. Chaque capsule du paquet et enregistre chaque partie de des capsules Ethernet et de notre Protocole Personnalisé dans des variables pour être réutilisés plus tard. Par exemple, on enregistre les adresses mac destination et sources pour les inverser lors du renvoie du paquet. Ou encore l'enregistrement de la commande (1er octet des données) qui est ensuite interprété en "ls". La suite des données est ensuite interprété comme le path à exécuté avec le "ls". <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Paquet réseau exemple.png|alt=paquet réseau exemple|vignette|paquet réseau exemple]]<br />
!Les deux premières ligne sont notre paquet.txt. Notre code décortique ensuite chaque partie des capsules Ethernet/Notre Protocole et les enregistre et les print.<br />
Vous pouvez aussi voir l'interprétation des données en ASCII. Ces données retranscrites en ASCII sont ensuite utilisés pour exécuté un ls. <br />
Le résultat de ce ls sera ensuite enregistré dans un autre fichier texte qui sera retransformé en paquet Réseau Ethernet encapsulation notre Proto. <br />
On enverra ensuite chaque nom de fichier dans ce fichier texte un par un avec la commande 0x11 pour dire à la carte réseau qu'il y a encore un fichier.<br />
|}<br />
<br />
=== Limitations dû à la SPI ===<br />
Nous étions les élèves les plus en avance sur les autres groupes, dû à la conception du Shield et à d'autres problèmes rencontrés, nous avons été ralenti par ces problèmes et devions tracer le chemin des autres équipes lors de la résolution de ces problèmes.<br />
<br />
==== Test de la SPI avec PONG ====<br />
Dû a l'erreur causé par le redresseur et la communication SPI, Monsieur REDON nous a donné un code <code>pong.c</code> qui communique par SPI entre la carte réseau et le Shield. Le Shield envoie un octet et la carte-réseau renvoie l'octet du coup d'horloge précédent. Il y a un problèmes, les câbles SPI reliant nos cartes sont défectueux et peuvent parfois renvoyés un octet qui n'a pas lieu d'être. Par exemple, nous envoyons un octet de 16 et nous recevons au coup d'horloge suivant, 192, 108 ou encore 65,..., qui ne sont pas des octets envoyables par le code <code>pong.c</code>. Ces cas sont rares mais ils peuvent amener à des problèmes de communication de paquets réseaux<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Pong screen.png|alt=Pong montrant la comm SPI entre le shield et la carte RNDIS|vignette|Pong montrant la comm SPI entre le shield et la carte RNDIS]]<br />
!<br />
|}<br />
<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div><br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== Erreur de design =====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:PIN ALIM non connecté.png|alt=PIN ALIM non connecté|vignette|PIN ALIM non connecté]]<br />
!Comme vous pouvez l'observe, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC. <br />
Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand, <br />
<br />
le Shield où la carte mère est alimentée en 5V.<br />
<br />
Solution : connecter cette PIN ALIM avec les VCC en plus de la PIN ALIM de l'USB + mettre un cavalier pour basculer entre l'alimentation<br />
par la carte-mère où directement par USB<br />
|-<br />
|[[Fichier:PIN ALIM non connecté USB.png|alt=PIN ALIM non connecté USB|vignette|PIN ALIM non connecté USB]]<br />
|<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=7353SE4Binome2024-72025-01-26T15:56:50Z<p>Rboursau : /* Création du protocole */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=== Problèmes rencontrés avec la COMMUNICATION SPI ===<br />
<br />
Lors de la programmation de notre carte RNDIS, nous avons rencontré un problème de communication SPI de notre carte RNDIS vers notre Shield. <br />
Nous pouvons envoyer des paquets/données du Shield vers la carte RNDIS mais pas dans l'autre sens. Le problème résidait sur le Shield. Plus particulièrement sur le releveur de niveau de tension. La résistance soudée à la sortie du <code>PIN MOSI_1</code> ne devrait pas être ici. Dû à cette erreur de design, le releveur de niveau faisait l'inverse de ce qu'il doit normalement faire : il baissait notre niveau de tension.<br />
Normalement, le releveur de niveau doit augmenter la tension pour quelle puisse être utilisée/utilisable par le MicroP. Lors de nos tests, nous avions <code>+5V</code> du Shield vers notre carte RNDIS, ce qui est la tension optimale mais n'obtenons que <code>+1.5V</code> de notre carte RNDIS vers notre Shield ce qui est bien insuffisant car les MicroP que nous avons ne fonctionne qu'avec des tensions à minima de <code>+3.3V</code>.<br />
Nous avons d'abord tenter de couper la piste à l'entrée du <code>PIN MISO</code> et d'y mettre la résistance qui est en sortie du <code>PIN MISO_1</code> et de remplacer la résistance en sortie du <code>PIN MISO_1</code> par un fil. Cela régla notre problème de tension mais nous ne pouvions plus détecter la carte SD.<br />
Nous avons donc enlever toutes les résistances et fils des pistes <code>MOSI</code> à l'entrée et sortie du releveur de niveau et avons court-circuité les deux pistes. Il faut aussi sectionner le fil de cuivre <code>MOSI</code> sinon le courant ira en sur le fil de cuivre <code>MISO_1</code> ET le fil <code>MOSI</code> et nous voulons que le courant aille uniquement sur <code>MISO_1</code> . Cela régla notre problème de tension ET de détection de carte SD.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Releveur de niveau PinMISO test1.png|gauche|vignette|Schéma montrant les tests que nous avons fait pour régler le problème de tension du MISO]]<br />
![[Fichier:Releveur de niveau PinMISO.png|alt=Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD|vignette|Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD]]<br />
|-<br />
|<br />
|<br />
|}<br />
<br />
== Programmation de la carte RNDIS ==<br />
<br />
Pour utiliser la carte RNDIS, nous allons créer notre protocole Ethernet en s'inspirant de l'ARP. Cela permettra de ne traiter que les paquets associés au projet, et de donner une structure adaptée à nos besoins. Pour rappel, le but est d'envoyer des paquets de la carte réseau chaque fois que la carte mère envoie une commande à la carte réseau. La commande contiendra éventuellement des données supplémentaires (si la commande est un ls, il faut préciser le chemin du dossier dans lequel l'éxecuter) qui seront traitées par le PC dans un programme qui tournera en continu. Ce programme réceptionne les paquets, les interprète et envoie les réponses à la carte RNDIS. Puis la carte RNDIS décode le paquet réponse, et envoie les données par SPI à la carte mère.<br />
<br />
Pour résumer, la carte RNDIS a 4 tâches principales :<br />
<br />
* Recevoir les commandes SPI envoyées par la carte mère<br />
* Interpréter ces commandes et former puis envoyer les paquets correspondants<br />
* Recevoir les réponses envoyées par le PC<br />
* Envoyer les données contenu dans les réponses par SPI à la carte mère<br />
<br />
=== Test avec protocole connu ===<br />
Tout d'abord, nous allons vérifier que la carte fonctionne avec un protocole connu. Nous allons donc utiliser l'exemple de carte RNDIS fourni dans la LUFA donnée au semestre précédent. <br />
<br />
En uploadant la LUFA, on voit bien après un lsusb que le périphérique apparaît dans la liste :<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Ipa apres configuration ip.png|vignette|408x408px|center]]<br />
|}<br />
<br />
<br />
Nous allons tester le fonctionnement de la carte avec un ping. Nous devons donc ajouter des addresses IP associées à l'interface de la carte. On efffectue la commande ip address add 10.0.0.100/24, on up l'interface avec ip link set usb0 up puis on vérifie avec ip a que l'interface a bien les addresses ip et est à l'état haut : <br />
<br />
<br />
On voit que ç'est le cas.<br />
En utilisant le programme ether fourni en TP de réseau, nous allons regarder les paquets passant sur l'interface usb0 tout en effectuant un ping sur l'addresse 10.0.0.2. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Video ping.mp4|vignette|center]]<br />
|}<br />
<br />
<br />
<br />
Finalement on voit que la carte fonctionne : elle reçoit le ping envoyé par le pc et répond. On peut s'atteler à la suite.<br />
<br />
=== Création du protocole ===<br />
Voici la structure de notre Protocole Ethernet, elle est fortement inspiré de la structure d'un paquet ARP. L'opération/commande sera le premier octet dans les données, suivi d'éventuels arguments supplémentaires.<syntaxhighlight lang="c"><br />
typedef struct<br />
{<br />
uint16_t Operation;/**< Type of operation, either PROTO_OPERATION_REQUEST or PROTO_OPERATION_REPLY */<br />
uint16_t ProtocolType; /** ETHERTYPE_PROTO**/<br />
MAC_Address_t Sender_MACADD; /**< Sender's hardware address */<br />
MAC_Address_t Target_MACADD; /**< Target's hardware address */<br />
uint16_t Length;<br />
uint8_t Data[MAX_COMMAND];<br />
<br />
} Proto_Header_t;<br />
</syntaxhighlight>Cette structure a été ajoutée dans un nouveau fichier appelé Proto.h accompagné de son .c . Dans ce .c, on crée une fonction Proto_ProcessIPPacket(void* InDataStart, void* OutDataStart) qui enverra une réponse lorsque la carte reçoit un paquet. Pour que ce protocole soit effectivement traité, il faut inclure ce fichier dans Ethernet.c, et ajouter un cas correspondant à notre protocole dans le traitement de paquet. On ajoute le protocole en ajoutant la ligne <br />
<br />
<nowiki>#</nowiki>define ETHERTYPE_PROTO 0x8888 <br />
<br />
dans EtherrnetProtocols.h. Ensuite, on doit créé une fonction DecodeProtoHeader dans ProtocolDecoders.c, comme pour les autres protocoles déjà existants, en l'adaptant à la structure de protocole choisi. <br />
<br />
Pour alléger le programme, nous enlevons les autres protocoles qui ne nous serons pas utiles dans le Makefile et sur les fichiers déjà cités. <br />
<br />
On upload le résultat sur la carte RNDIS, on remet l'interface à l'état haut. On veut maintenant utiliser ether mais il y a un problème : ce programme ne connaît pas notre protocole. Nous allons devoir le modifier pour qu'il corresponde à nos besoins. <br />
<br />
=== Modification de ether ===<br />
On doit, dans bpf.c, remplacer le pro tocole dummy (qui est un protocole non utilisé et destiné à être remplacé) par le nôtre. Ensuite, nous allons faire en sorte que les paquets reçus soient enregistrés dans des fichiers textes, de sorte à ce qu'ils puissent être analysés par la suite. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Led ether.mp4|vignette|Vidéo montrant une led clignoter quand nous recevons un paquet avec notre protocole Ethernet (0x8888)]]<br />
!Vous pouvez retrouver notre ether customisé dans notre git à la racine<br />
S8-Pico-Binome-7/Programs/ListeningEther/customether<br />
|}<br />
Nous allons maintenant pouvoir vérifier que notre protocole fonctionne.<br />
<br />
=== Envoi de paquet ===<br />
=== Décodage des paquets de l'ordinateur ===<br />
A la racine S8-Pico-Binome-7/Programs/SPIfichierDistants/PC/ProtoPC.c de notre git, se trouve le code permettant à l'ordinateur d'interpréter les paquets réseau envoyé par la carte RNDIS. Les paquets RNDIS sont enregistrés/écrasés dans des fichiers texte sur le PC. Ces fichiers textes sont décodés par le code et décortiqués. Chaque capsule du paquet et enregistre chaque partie de des capsules Ethernet et de notre Protocole Personnalisé dans des variables pour être réutilisés plus tard. Par exemple, on enregistre les adresses mac destination et sources pour les inverser lors du renvoie du paquet. Ou encore l'enregistrement de la commande (1er octet des données) qui est ensuite interprété en "ls". La suite des données est ensuite interprété comme le path à exécuté avec le "ls". <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Résultat décorticage d'un paquet réseau par notre code .png|alt=résultat décorticage d'un paquet réseau par notre code |vignette|379x379px|résultat décorticage d'un paquet réseau par notre code ]]<br />
|}<br />
<br />
=== Limitations dû à la SPI ===<br />
Nous étions les élèves les plus en avance sur les autres groupes, dû à la conception du Shield et à d'autres problèmes rencontrés, nous avons été ralenti par ces problèmes et devions tracer le chemin des autres équipes lors de la résolution de ces problèmes.<br />
<br />
==== Test de la SPI avec PONG ====<br />
Dû a l'erreur causé par le redresseur et la communication SPI, Monsieur REDON nous a donné un code <code>pong.c</code> qui communique par SPI entre la carte réseau et le Shield. Le Shield envoie un octet et la carte-réseau renvoie l'octet du coup d'horloge précédent. Il y a un problèmes, les câbles SPI reliant nos cartes sont défectueux et peuvent parfois renvoyés un octet qui n'a pas lieu d'être. Par exemple, nous envoyons un octet de 16 et nous recevons au coup d'horloge suivant, 192, 108 ou encore 65,..., qui ne sont pas des octets envoyables par le code <code>pong.c</code>. Ces cas sont rares mais ils peuvent amener à des problèmes de communication de paquets réseaux<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Pong screen.png|alt=Pong montrant la comm SPI entre le shield et la carte RNDIS|vignette|Pong montrant la comm SPI entre le shield et la carte RNDIS]]<br />
!<br />
|}<br />
<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div><br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== Erreur de design =====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:PIN ALIM non connecté.png|alt=PIN ALIM non connecté|vignette|PIN ALIM non connecté]]<br />
!Comme vous pouvez l'observe, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC. <br />
Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand, <br />
<br />
le Shield où la carte mère est alimentée en 5V.<br />
<br />
Solution : connecter cette PIN ALIM avec les VCC en plus de la PIN ALIM de l'USB + mettre un cavalier pour basculer entre l'alimentation<br />
par la carte-mère où directement par USB<br />
|-<br />
|[[Fichier:PIN ALIM non connecté USB.png|alt=PIN ALIM non connecté USB|vignette|PIN ALIM non connecté USB]]<br />
|<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=7334SE4Binome2024-72025-01-26T15:14:20Z<p>Rboursau : /* Programmation de la carte RNDIS */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=== Problèmes rencontrés avec la COMMUNICATION SPI ===<br />
<br />
Lors de la programmation de notre carte RNDIS, nous avons rencontré un problème de communication SPI de notre carte RNDIS vers notre Shield. <br />
Nous pouvons envoyer des paquets/données du Shield vers la carte RNDIS mais pas dans l'autre sens. Le problème résidait sur le Shield. Plus particulièrement sur le releveur de niveau de tension. La résistance soudée à la sortie du <code>PIN MOSI_1</code> ne devrait pas être ici. Dû à cette erreur de design, le releveur de niveau faisait l'inverse de ce qu'il doit normalement faire : il baissait notre niveau de tension.<br />
Normalement, le releveur de niveau doit augmenter la tension pour quelle puisse être utilisée/utilisable par le MicroP. Lors de nos tests, nous avions <code>+5V</code> du Shield vers notre carte RNDIS, ce qui est la tension optimale mais n'obtenons que <code>+1.5V</code> de notre carte RNDIS vers notre Shield ce qui est bien insuffisant car les MicroP que nous avons ne fonctionne qu'avec des tensions à minima de <code>+3.3V</code>.<br />
Nous avons d'abord tenter de couper la piste à l'entrée du <code>PIN MISO</code> et d'y mettre la résistance qui est en sortie du <code>PIN MISO_1</code> et de remplacer la résistance en sortie du <code>PIN MISO_1</code> par un fil. Cela régla notre problème de tension mais nous ne pouvions plus détecter la carte SD.<br />
Nous avons donc enlever toutes les résistances et fils des pistes <code>MOSI</code> à l'entrée et sortie du releveur de niveau et avons court-circuité les deux pistes. Il faut aussi sectionner le fil de cuivre <code>MOSI</code> sinon le courant ira en sur le fil de cuivre <code>MISO_1</code> ET le fil <code>MOSI</code> et nous voulons que le courant aille uniquement sur <code>MISO_1</code> . Cela régla notre problème de tension ET de détection de carte SD.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Releveur de niveau PinMISO test1.png|gauche|vignette|Schéma montrant les tests que nous avons fait pour régler le problème de tension du MISO]]<br />
![[Fichier:Releveur de niveau PinMISO.png|alt=Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD|vignette|Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD]]<br />
|-<br />
|<br />
|<br />
|}<br />
<br />
== Programmation de la carte RNDIS ==<br />
<br />
Pour utiliser la carte RNDIS, nous allons créer notre protocole Ethernet en s'inspirant de l'ARP. Cela permettra de ne traiter que les paquets associés au projet, et de donner une structure adaptée à nos besoins. Pour rappel, le but est d'envoyer des paquets de la carte réseau chaque fois que la carte mère envoie une commande à la carte réseau. La commande contiendra éventuellement des données supplémentaires (si la commande est un ls, il faut préciser le chemin du dossier dans lequel l'éxecuter) qui seront traitées par le PC dans un programme qui tournera en continu. Ce programme réceptionne les paquets, les interprète et envoie les réponses à la carte RNDIS. Puis la carte RNDIS décode le paquet réponse, et envoie les données par SPI à la carte mère.<br />
<br />
Pour résumer, la carte RNDIS a 4 tâches principales :<br />
<br />
* Recevoir les commandes SPI envoyées par la carte mère<br />
* Interpréter ces commandes et former puis envoyer les paquets correspondants<br />
* Recevoir les réponses envoyées par le PC<br />
* Envoyer les données contenu dans les réponses par SPI à la carte mère<br />
<br />
=== Test avec protocole connu ===<br />
Tout d'abord, nous allons vérifier que la carte fonctionne avec un protocole connu. Nous allons donc utiliser l'exemple de carte RNDIS fourni dans la LUFA donnée au semestre précédent. <br />
<br />
En uploadant la LUFA, on voit bien après un lsusb que le périphérique apparaît dans la liste :<br />
<br />
<br />
Nous allons tester le fonctionnement de la carte avec un ping. Nous devons donc ajouter des addresses IP associées à l'interface de la carte. On efffectue la commande ip address add 10.0.0.100/24, on up l'interface avec ip link set usb0 up puis on vérifie avec ip a que l'interface a bien les addresses ip et est à l'état haut : <br />
[[Fichier:Ipa apres configuration ip.png|vignette]]<br />
<br />
<br />
On voit que ç'est le cas.<br />
[[Fichier:Video ping.mp4|vignette]]<br />
En utilisant le programme ether fourni en TP de réseau, nous allons regarder les paquets passant sur l'interface usb0 tout en effectuant un ping sur l'addresse 10.0.0.2. <br />
<br />
<br />
<br />
Finalement on voit que la carte fonctionne : elle reçoit le ping envoyé par le pc et répond. On peut s'atteler à la suite.<br />
<br />
=== Création du protocole ===<br />
Voici la structure de notre Protocole Ethernet, elle est fortement inspiré de la structure d'un paquet ARP. L'opération/commande sera le premier octet dans les données, suivi d'éventuels arguments supplémentaires.<syntaxhighlight lang="c"><br />
typedef struct<br />
{<br />
uint16_t Operation;/**< Type of operation, either PROTO_OPERATION_REQUEST or PROTO_OPERATION_REPLY */<br />
uint16_t ProtocolType; /** ETHERTYPE_PROTO**/<br />
MAC_Address_t Sender_MACADD; /**< Sender's hardware address */<br />
MAC_Address_t Target_MACADD; /**< Target's hardware address */<br />
uint16_t Length;<br />
uint8_t Data[MAX_COMMAND];<br />
<br />
} Proto_Header_t;<br />
</syntaxhighlight>Cette structure a été ajoutée dans un nouveau fichier appelé Proto.h accompagné de son .c . Pour que ce protocole soit effectivement traité, il faut inclure ce fichier dans Ethernet.c, et ajouter un cas correspondant à notre protocole dans le traitement de paquet. <br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Led ether.mp4|vignette|Vidéo montrant une led clignoter quand nous recevons un paquet avec notre protocole Ethernet (0x8888)]]<br />
!Vous pouvez retrouver notre ether customisé dans notre git à la racine<br />
S8-Pico-Binome-7/Programs/ListeningEther/customether<br />
|}<br />
=== Envoi de paquet ===<br />
=== Décodage des paquets de l'ordinateur ===<br />
<br />
=== Limitations dû à la SPI ===<br />
Nous étions les élèves les plus en avance sur les autres groupes, dû à la conception du shield et à d'autres problèmes rencontrés, nous avons été ralenti par ces problèmes et devions tracer le chemin des autres équipes lors de la résolution de ces problèmes.<br />
<br />
==== Test de la SPI avec PONG ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Pong screen.png|alt=Pong montrant la comm SPI entre le shield et la carte RNDIS|vignette|Pong montrant la comm SPI entre le shield et la carte RNDIS]]<br />
!<br />
|}<br />
<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div><br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== Erreur de design =====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:PIN ALIM non connecté.png|alt=PIN ALIM non connecté|vignette|PIN ALIM non connecté]]<br />
!Comme vous pouvez l'observe, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC. <br />
Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand, <br />
<br />
le Shield où la carte mère est alimentée en 5V.<br />
<br />
Solution : connecter cette PIN ALIM avec les VCC en plus de la PIN ALIM de l'USB + mettre un cavalier pour basculer entre l'alimentation<br />
par la carte-mère où directement par USB<br />
|-<br />
|[[Fichier:PIN ALIM non connecté USB.png|alt=PIN ALIM non connecté USB|vignette|PIN ALIM non connecté USB]]<br />
|<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Video_ping.mp4&diff=7332Fichier:Video ping.mp42025-01-26T15:08:03Z<p>Rboursau : </p>
<hr />
<div>ping</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Ipa_apres_configuration_ip.png&diff=7331Fichier:Ipa apres configuration ip.png2025-01-26T15:01:27Z<p>Rboursau : </p>
<hr />
<div>ipa</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=7330SE4Binome2024-72025-01-26T14:12:51Z<p>Rboursau : /* Programmation de la carte RNDIS */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=== Problèmes rencontrés avec la COMMUNICATION SPI ===<br />
<br />
Lors de la programmation de notre carte RNDIS, nous avons rencontré un problème de communication SPI de notre carte RNDIS vers notre Shield. <br />
Nous pouvons envoyer des paquets/données du Shield vers la carte RNDIS mais pas dans l'autre sens. Le problème résidait sur le Shield. Plus particulièrement sur le releveur de niveau de tension. La résistance soudée à la sortie du <code>PIN MOSI_1</code> ne devrait pas être ici. Dû à cette erreur de design, le releveur de niveau faisait l'inverse de ce qu'il doit normalement faire : il baissait notre niveau de tension.<br />
Normalement, le releveur de niveau doit augmenter la tension pour quelle puisse être utilisée/utilisable par le MicroP. Lors de nos tests, nous avions <code>+5V</code> du Shield vers notre carte RNDIS, ce qui est la tension optimale mais n'obtenons que <code>+1.5V</code> de notre carte RNDIS vers notre Shield ce qui est bien insuffisant car les MicroP que nous avons ne fonctionne qu'avec des tensions à minima de <code>+3.3V</code>.<br />
Nous avons d'abord tenter de couper la piste à l'entrée du <code>PIN MISO</code> et d'y mettre la résistance qui est en sortie du <code>PIN MISO_1</code> et de remplacer la résistance en sortie du <code>PIN MISO_1</code> par un fil. Cela régla notre problème de tension mais nous ne pouvions plus détecter la carte SD.<br />
Nous avons donc enlever toutes les résistances et fils des pistes <code>MOSI</code> à l'entrée et sortie du releveur de niveau et avons court-circuité les deux pistes. Il faut aussi sectionner le fil de cuivre <code>MOSI</code> sinon le courant ira en sur le fil de cuivre <code>MISO_1</code> ET le fil <code>MOSI</code> et nous voulons que le courant aille uniquement sur <code>MISO_1</code> . Cela régla notre problème de tension ET de détection de carte SD.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Releveur de niveau PinMISO test1.png|gauche|vignette|Schéma montrant les tests que nous avons fait pour régler le problème de tension du MISO]]<br />
![[Fichier:Releveur de niveau PinMISO.png|alt=Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD|vignette|Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD]]<br />
|-<br />
|<br />
|<br />
|}<br />
<br />
== Programmation de la carte RNDIS ==<br />
<br />
Pour utiliser la carte RNDIS, nous allons créer notre protocole Ethernet en s'inspirant de l'ARP. Cela permettra de ne traiter que les paquets associés au projet, et de donner une structure adaptée à nos besoins. Pour rappel, le but est d'envoyer des paquets de la carte réseau chaque fois que la carte mère envoie une commande à la carte réseau. La commande contiendra éventuellement des données supplémentaires (si la commande est un ls, il faut préciser le chemin du dossier dans lequel l'éxecuter) qui seront traitées par le PC dans un programme qui tournera en continu. Ce programme réceptionne les paquets, les interprète et envoie les réponses à la carte RNDIS. Puis la carte RNDIS décode le paquet réponse, et envoie les données par SPI à la carte mère.<br />
<br />
Pour résumer, la carte RNDIS a 4 tâches principales :<br />
<br />
* Recevoir les commandes SPI envoyées par la carte mère<br />
* Interpréter ces commandes et former puis envoyer les paquets correspondants<br />
* Recevoir les réponses envoyées par le PC<br />
* Envoyer les données contenu dans les réponses par SPI à la carte mère<br /><br />
<br />
=== Ether customisé ===<br />
Voici la structure de notre Protocole Ethernet, elle est fortement inspiré de la structure d'un paquet ARP. L'opération est la commande qui est demandé par la carte-mère donc 0x01: listing des fichiers, 0x11 : téléchargement des fichiers, 0x03,... Où nous en sommes nous n'avons pas utilisé cet octet. L'opération/commande est le premier octet dans les données.<syntaxhighlight lang="c"><br />
typedef struct<br />
{<br />
uint16_t Operation;/**< Type of operation, either PROTO_OPERATION_REQUEST or PROTO_OPERATION_REPLY */<br />
uint16_t ProtocolType; /** ETHERTYPE_PROTO**/<br />
MAC_Address_t Sender_MACADD; /**< Sender's hardware address */<br />
MAC_Address_t Target_MACADD; /**< Target's hardware address */<br />
uint16_t Length;<br />
uint8_t Data[MAX_COMMAND];<br />
<br />
} Proto_Header_t;<br />
</syntaxhighlight>De cette façon, lorsqu'une trame respectant notre forme et utilisant notre protocole est envoyée sur l'interface, la LED de la carte devrait clignoter. Enfin, il faut aussi adapter le fichier "ProtocolsDecoders" afin que la LUFA arrive à décoder notre trame <br />
<br />
<br />
Après cela, nous pouvons envoyer une trame sur l'interface "usb0" utilisant notre protocole. Pour cela, nous avons modifié l'outil "ether" pour observer directement l'interface "usb0" et aussi pour que le filtre accepte notre protocole. En envoyant alors la trame, la LED s'allume bien correctement.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Led ether.mp4|vignette|Vidéo montrant une led clignoter quand nous recevons un paquet avec notre protocole Ethernet (0x8888)]]<br />
!Vous pouvez retrouver notre ether customisé dans notre git à la racine<br />
S8-Pico-Binome-7/Programs/ListeningEther/customether<br />
|}<br />
=== Envoi de paquet ===<br />
=== Décodage des paquets de l'ordinateur ===<br />
<br />
=== Limitations dû à la SPI ===<br />
Nous étions les élèves les plus en avance sur les autres groupes, dû à la conception du shield et à d'autres problèmes rencontrés, nous avons été ralenti par ces problèmes et devions tracer le chemin des autres équipes lors de la résolution de ces problèmes.<br />
<br />
==== Test de la SPI avec PONG ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Pong screen.png|alt=Pong montrant la comm SPI entre le shield et la carte RNDIS|vignette|Pong montrant la comm SPI entre le shield et la carte RNDIS]]<br />
!<br />
|}<br />
<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div><br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== Erreur de design =====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:PIN ALIM non connecté.png|alt=PIN ALIM non connecté|vignette|PIN ALIM non connecté]]<br />
!Comme vous pouvez l'observe, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC. <br />
Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand, <br />
<br />
le Shield où la carte mère est alimentée en 5V.<br />
<br />
Solution : connecter cette PIN ALIM avec les VCC en plus de la PIN ALIM de l'USB + mettre un cavalier pour basculer entre l'alimentation<br />
par la carte-mère où directement par USB<br />
|-<br />
|[[Fichier:PIN ALIM non connecté USB.png|alt=PIN ALIM non connecté USB|vignette|PIN ALIM non connecté USB]]<br />
|<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=7329SE4Binome2024-72025-01-26T14:12:28Z<p>Rboursau : /* Programmation de la carte RNDIS */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=== Problèmes rencontrés avec la COMMUNICATION SPI ===<br />
<br />
Lors de la programmation de notre carte RNDIS, nous avons rencontré un problème de communication SPI de notre carte RNDIS vers notre Shield. <br />
Nous pouvons envoyer des paquets/données du Shield vers la carte RNDIS mais pas dans l'autre sens. Le problème résidait sur le Shield. Plus particulièrement sur le releveur de niveau de tension. La résistance soudée à la sortie du <code>PIN MOSI_1</code> ne devrait pas être ici. Dû à cette erreur de design, le releveur de niveau faisait l'inverse de ce qu'il doit normalement faire : il baissait notre niveau de tension.<br />
Normalement, le releveur de niveau doit augmenter la tension pour quelle puisse être utilisée/utilisable par le MicroP. Lors de nos tests, nous avions <code>+5V</code> du Shield vers notre carte RNDIS, ce qui est la tension optimale mais n'obtenons que <code>+1.5V</code> de notre carte RNDIS vers notre Shield ce qui est bien insuffisant car les MicroP que nous avons ne fonctionne qu'avec des tensions à minima de <code>+3.3V</code>.<br />
Nous avons d'abord tenter de couper la piste à l'entrée du <code>PIN MISO</code> et d'y mettre la résistance qui est en sortie du <code>PIN MISO_1</code> et de remplacer la résistance en sortie du <code>PIN MISO_1</code> par un fil. Cela régla notre problème de tension mais nous ne pouvions plus détecter la carte SD.<br />
Nous avons donc enlever toutes les résistances et fils des pistes <code>MOSI</code> à l'entrée et sortie du releveur de niveau et avons court-circuité les deux pistes. Il faut aussi sectionner le fil de cuivre <code>MOSI</code> sinon le courant ira en sur le fil de cuivre <code>MISO_1</code> ET le fil <code>MOSI</code> et nous voulons que le courant aille uniquement sur <code>MISO_1</code> . Cela régla notre problème de tension ET de détection de carte SD.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Releveur de niveau PinMISO test1.png|gauche|vignette|Schéma montrant les tests que nous avons fait pour régler le problème de tension du MISO]]<br />
![[Fichier:Releveur de niveau PinMISO.png|alt=Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD|vignette|Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD]]<br />
|-<br />
|<br />
|<br />
|}<br />
<br />
== Programmation de la carte RNDIS ==<br />
<br />
Pour utiliser la carte RNDIS, nous allons créer notre protocole Ethernet en s'inspirant de l'ARP. Cela permettra de ne traiter que les paquets associés au projet, et de donner une structure adaptée à nos besoins. Pour rappel, le but est d'envoyer des paquets de la carte réseau chaque fois que la carte mère envoie une commande à la carte réseau. La commande contiendra éventuellement des données supplémentaires (si la commande est un ls, il faut préciser le chemin du dossier dans lequel l'éxecuter) qui seront traitées par le PC dans un programme qui tournera en continu. Ce programme réceptionne les paquets, les interprète et envoie les réponses à la carte RNDIS. Puis la carte RNDIS décode le paquet réponse, et envoie les données par SPI à la carte mère.<br />
<br />
Pour résumer, la carte RNDIS a 4 tâches principales :<br />
<br />
* Recevoir les commandes SPI envoyées par la carte mère<br />
* Interpréter ces commandes et former puis envoyer les paquets correspondants<br />
* Recevoir les réponses envoyées par le PC.<br />
* Envoyer les données contenu dans les réponses par SPI à la carte mère.<br /><br />
<br />
=== Ether customisé ===<br />
Voici la structure de notre Protocole Ethernet, elle est fortement inspiré de la structure d'un paquet ARP. L'opération est la commande qui est demandé par la carte-mère donc 0x01: listing des fichiers, 0x11 : téléchargement des fichiers, 0x03,... Où nous en sommes nous n'avons pas utilisé cet octet. L'opération/commande est le premier octet dans les données.<syntaxhighlight lang="c"><br />
typedef struct<br />
{<br />
uint16_t Operation;/**< Type of operation, either PROTO_OPERATION_REQUEST or PROTO_OPERATION_REPLY */<br />
uint16_t ProtocolType; /** ETHERTYPE_PROTO**/<br />
MAC_Address_t Sender_MACADD; /**< Sender's hardware address */<br />
MAC_Address_t Target_MACADD; /**< Target's hardware address */<br />
uint16_t Length;<br />
uint8_t Data[MAX_COMMAND];<br />
<br />
} Proto_Header_t;<br />
</syntaxhighlight>De cette façon, lorsqu'une trame respectant notre forme et utilisant notre protocole est envoyée sur l'interface, la LED de la carte devrait clignoter. Enfin, il faut aussi adapter le fichier "ProtocolsDecoders" afin que la LUFA arrive à décoder notre trame <br />
<br />
<br />
Après cela, nous pouvons envoyer une trame sur l'interface "usb0" utilisant notre protocole. Pour cela, nous avons modifié l'outil "ether" pour observer directement l'interface "usb0" et aussi pour que le filtre accepte notre protocole. En envoyant alors la trame, la LED s'allume bien correctement.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Led ether.mp4|vignette|Vidéo montrant une led clignoter quand nous recevons un paquet avec notre protocole Ethernet (0x8888)]]<br />
!Vous pouvez retrouver notre ether customisé dans notre git à la racine<br />
S8-Pico-Binome-7/Programs/ListeningEther/customether<br />
|}<br />
=== Envoi de paquet ===<br />
=== Décodage des paquets de l'ordinateur ===<br />
<br />
=== Limitations dû à la SPI ===<br />
Nous étions les élèves les plus en avance sur les autres groupes, dû à la conception du shield et à d'autres problèmes rencontrés, nous avons été ralenti par ces problèmes et devions tracer le chemin des autres équipes lors de la résolution de ces problèmes.<br />
<br />
==== Test de la SPI avec PONG ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Pong screen.png|alt=Pong montrant la comm SPI entre le shield et la carte RNDIS|vignette|Pong montrant la comm SPI entre le shield et la carte RNDIS]]<br />
!<br />
|}<br />
<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div><br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== Erreur de design =====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:PIN ALIM non connecté.png|alt=PIN ALIM non connecté|vignette|PIN ALIM non connecté]]<br />
!Comme vous pouvez l'observe, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC. <br />
Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand, <br />
<br />
le Shield où la carte mère est alimentée en 5V.<br />
<br />
Solution : connecter cette PIN ALIM avec les VCC en plus de la PIN ALIM de l'USB + mettre un cavalier pour basculer entre l'alimentation<br />
par la carte-mère où directement par USB<br />
|-<br />
|[[Fichier:PIN ALIM non connecté USB.png|alt=PIN ALIM non connecté USB|vignette|PIN ALIM non connecté USB]]<br />
|<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=7328SE4Binome2024-72025-01-26T14:11:37Z<p>Rboursau : /* Programmation de la carte RNDIS */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=== Problèmes rencontrés avec la COMMUNICATION SPI ===<br />
<br />
Lors de la programmation de notre carte RNDIS, nous avons rencontré un problème de communication SPI de notre carte RNDIS vers notre Shield. <br />
Nous pouvons envoyer des paquets/données du Shield vers la carte RNDIS mais pas dans l'autre sens. Le problème résidait sur le Shield. Plus particulièrement sur le releveur de niveau de tension. La résistance soudée à la sortie du <code>PIN MOSI_1</code> ne devrait pas être ici. Dû à cette erreur de design, le releveur de niveau faisait l'inverse de ce qu'il doit normalement faire : il baissait notre niveau de tension.<br />
Normalement, le releveur de niveau doit augmenter la tension pour quelle puisse être utilisée/utilisable par le MicroP. Lors de nos tests, nous avions <code>+5V</code> du Shield vers notre carte RNDIS, ce qui est la tension optimale mais n'obtenons que <code>+1.5V</code> de notre carte RNDIS vers notre Shield ce qui est bien insuffisant car les MicroP que nous avons ne fonctionne qu'avec des tensions à minima de <code>+3.3V</code>.<br />
Nous avons d'abord tenter de couper la piste à l'entrée du <code>PIN MISO</code> et d'y mettre la résistance qui est en sortie du <code>PIN MISO_1</code> et de remplacer la résistance en sortie du <code>PIN MISO_1</code> par un fil. Cela régla notre problème de tension mais nous ne pouvions plus détecter la carte SD.<br />
Nous avons donc enlever toutes les résistances et fils des pistes <code>MOSI</code> à l'entrée et sortie du releveur de niveau et avons court-circuité les deux pistes. Il faut aussi sectionner le fil de cuivre <code>MOSI</code> sinon le courant ira en sur le fil de cuivre <code>MISO_1</code> ET le fil <code>MOSI</code> et nous voulons que le courant aille uniquement sur <code>MISO_1</code> . Cela régla notre problème de tension ET de détection de carte SD.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Releveur de niveau PinMISO test1.png|gauche|vignette|Schéma montrant les tests que nous avons fait pour régler le problème de tension du MISO]]<br />
![[Fichier:Releveur de niveau PinMISO.png|alt=Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD|vignette|Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD]]<br />
|-<br />
|<br />
|<br />
|}<br />
<br />
== Programmation de la carte RNDIS ==<br />
<br />
Pour utiliser la carte RNDIS, nous allons créer notre protocole Ethernet en s'inspirant de l'ARP. Cela permettra de ne traiter que les paquets dont on a besoin, et de donner une structure adaptée à nos besoins. Pour rappel, le but est d'envoyer des paquets de la carte réseau chaque fois que la carte mère envoie une commande à la carte réseau. La commande contiendra éventuellement des données supplémentaires (si la commande est un ls, il faut préciser le chemin du dossier dans lequel l'éxecuter) qui seront traitées par le PC dans un programme qui tournera en continu. Ce programme réceptionne les paquets, les interprète et envoie les réponses à la carte RNDIS. Puis la carte RNDIS décode le paquet réponse, et envoie les données par SPI à la carte mère.<br />
<br />
Pour résumer, la carte RNDIS a 4 tâches principales :<br />
<br />
* Recevoir les commandes SPI envoyées par la carte mère<br />
* Interpréter ces commandes et former puis envoyer les paquets correspondants<br />
* Recevoir les réponses envoyées par le PC.<br />
* Envoyer les données contenu dans les réponses par SPI à la carte mère.<br /><br />
<br />
=== Ether customisé ===<br />
Voici la structure de notre Protocole Ethernet, elle est fortement inspiré de la structure d'un paquet ARP. L'opération est la commande qui est demandé par la carte-mère donc 0x01: listing des fichiers, 0x11 : téléchargement des fichiers, 0x03,... Où nous en sommes nous n'avons pas utilisé cet octet. L'opération/commande est le premier octet dans les données.<syntaxhighlight lang="c"><br />
typedef struct<br />
{<br />
uint16_t Operation;/**< Type of operation, either PROTO_OPERATION_REQUEST or PROTO_OPERATION_REPLY */<br />
uint16_t ProtocolType; /** ETHERTYPE_PROTO**/<br />
MAC_Address_t Sender_MACADD; /**< Sender's hardware address */<br />
MAC_Address_t Target_MACADD; /**< Target's hardware address */<br />
uint16_t Length;<br />
uint8_t Data[MAX_COMMAND];<br />
<br />
} Proto_Header_t;<br />
</syntaxhighlight>De cette façon, lorsqu'une trame respectant notre forme et utilisant notre protocole est envoyée sur l'interface, la LED de la carte devrait clignoter. Enfin, il faut aussi adapter le fichier "ProtocolsDecoders" afin que la LUFA arrive à décoder notre trame <br />
<br />
<br />
Après cela, nous pouvons envoyer une trame sur l'interface "usb0" utilisant notre protocole. Pour cela, nous avons modifié l'outil "ether" pour observer directement l'interface "usb0" et aussi pour que le filtre accepte notre protocole. En envoyant alors la trame, la LED s'allume bien correctement.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Led ether.mp4|vignette|Vidéo montrant une led clignoter quand nous recevons un paquet avec notre protocole Ethernet (0x8888)]]<br />
!Vous pouvez retrouver notre ether customisé dans notre git à la racine<br />
S8-Pico-Binome-7/Programs/ListeningEther/customether<br />
|}<br />
=== Envoi de paquet ===<br />
=== Décodage des paquets de l'ordinateur ===<br />
<br />
=== Limitations dû à la SPI ===<br />
Nous étions les élèves les plus en avance sur les autres groupes, dû à la conception du shield et à d'autres problèmes rencontrés, nous avons été ralenti par ces problèmes et devions tracer le chemin des autres équipes lors de la résolution de ces problèmes.<br />
<br />
==== Test de la SPI avec PONG ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Pong screen.png|alt=Pong montrant la comm SPI entre le shield et la carte RNDIS|vignette|Pong montrant la comm SPI entre le shield et la carte RNDIS]]<br />
!<br />
|}<br />
<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div><br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== Erreur de design =====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:PIN ALIM non connecté.png|alt=PIN ALIM non connecté|vignette|PIN ALIM non connecté]]<br />
!Comme vous pouvez l'observe, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC. <br />
Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand, <br />
<br />
le Shield où la carte mère est alimentée en 5V.<br />
<br />
Solution : connecter cette PIN ALIM avec les VCC en plus de la PIN ALIM de l'USB + mettre un cavalier pour basculer entre l'alimentation<br />
par la carte-mère où directement par USB<br />
|-<br />
|[[Fichier:PIN ALIM non connecté USB.png|alt=PIN ALIM non connecté USB|vignette|PIN ALIM non connecté USB]]<br />
|<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=7319SE4Binome2024-72025-01-26T13:58:10Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=== Problèmes rencontrés avec la COMMUNICATION SPI ===<br />
<br />
Lors de la programmation de notre carte RNDIS, nous avons rencontré un problème de communication SPI de notre carte RNDIS vers notre Shield. <br />
Nous pouvons envoyer des paquets/données du Shield vers la carte RNDIS mais pas dans l'autre sens. Le problème résidait sur le Shield. Plus particulièrement sur le releveur de niveau de tension. La résistance soudée à la sortie du <code>PIN MOSI_1</code> ne devrait pas être ici. Dû à cette erreur de design, le releveur de niveau faisait l'inverse de ce qu'il doit normalement faire : il baissait notre niveau de tension.<br />
Normalement, le releveur de niveau doit augmenter la tension pour quelle puisse être utilisée/utilisable par le MicroP. Lors de nos tests, nous avions <code>+5V</code> du Shield vers notre carte RNDIS, ce qui est la tension optimale mais n'obtenons que <code>+1.5V</code> de notre carte RNDIS vers notre Shield ce qui est bien insuffisant car les MicroP que nous avons ne fonctionne qu'avec des tensions à minima de <code>+3.3V</code>.<br />
Nous avons d'abord tenter de couper la piste à l'entrée du <code>PIN MISO</code> et d'y mettre la résistance qui est en sortie du <code>PIN MISO_1</code> et de remplacer la résistance en sortie du <code>PIN MISO_1</code> par un fil. Cela régla notre problème de tension mais nous ne pouvions plus détecter la carte SD.<br />
Nous avons donc enlever toutes les résistances et fils des pistes <code>MOSI</code> à l'entrée et sortie du releveur de niveau et avons court-circuité les deux pistes. Il faut aussi sectionner le fil de cuivre <code>MOSI</code> sinon le courant ira en sur le fil de cuivre <code>MISO_1</code> ET le fil <code>MOSI</code> et nous voulons que le courant aille uniquement sur <code>MISO_1</code> . Cela régla notre problème de tension ET de détection de carte SD.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Releveur de niveau PinMISO test1.png|gauche|vignette|Schéma montrant les tests que nous avons fait pour régler le problème de tension du MISO]]<br />
![[Fichier:Releveur de niveau PinMISO.png|alt=Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD|vignette|Schéma montrant comment nous avons pu régler le problème de tension en MISO et de détection de la carte SD]]<br />
|-<br />
|<br />
|<br />
|}<br />
<br />
== Programmation de la carte RNDIS ==<br />
<br />
<br />
<br />
=== Ether customisé ===<br />
Voici la structure de notre Protocole Ethernet, elle est fortement inspiré de la structure d'un paquet ARP. L'opération est la commande qui est demandé par la carte-mère donc 0x01: listing des fichiers, 0x11 : téléchargement des fichiers, 0x03,... Où nous en sommes nous n'avons pas utilisé cet octet. L'opération/commande est le premier octet dans les données.<syntaxhighlight lang="c"><br />
typedef struct<br />
{<br />
uint16_t Operation;/**< Type of operation, either PROTO_OPERATION_REQUEST or PROTO_OPERATION_REPLY */<br />
uint16_t ProtocolType; /** ETHERTYPE_PROTO**/<br />
MAC_Address_t Sender_MACADD; /**< Sender's hardware address */<br />
MAC_Address_t Target_MACADD; /**< Target's hardware address */<br />
uint16_t Length;<br />
uint8_t Data[MAX_COMMAND];<br />
<br />
} Proto_Header_t;<br />
</syntaxhighlight>De cette façon, lorsqu'une trame respectant notre forme et utilisant notre protocole est envoyée sur l'interface, la LED de la carte devrait clignoter. Enfin, il faut aussi adapter le fichier "ProtocolsDecoders" afin que la LUFA arrive à décoder notre trame <br />
<br />
<br />
Après cela, nous pouvons envoyer une trame sur l'interface "usb0" utilisant notre protocole. Pour cela, nous avons modifié l'outil "ether" pour observer directement l'interface "usb0" et aussi pour que le filtre accepte notre protocole. En envoyant alors la trame, la LED s'allume bien correctement.<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Led ether.mp4|vignette|Vidéo montrant une led clignoter quand nous recevons un paquet avec notre protocole Ethernet (0x8888)]]<br />
!Vous pouvez retrouver notre ether customisé dans notre git à la racine<br />
S8-Pico-Binome-7/Programs/ListeningEther/customether<br />
|}<br />
=== Envoi de paquet ===<br />
=== Décodage des paquets de l'ordinateur ===<br />
<br />
=== Limitations dû à la SPI ===<br />
Nous étions les élèves les plus en avance sur les autres groupes, dû à la conception du shield et à d'autres problèmes rencontrés, nous avons été ralenti par ces problèmes et devions tracer le chemin des autres équipes lors de la résolution de ces problèmes.<br />
<br />
<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div><br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6771SE4Binome2024-72024-11-19T13:58:05Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction <code>delay</code>, nous changeons l'état de la tâche à endormir en <code>SLEEPING</code>, puis assignons la valeur <code>time</code> donnée en paramètre au <code>delay</code> de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le <code>delay</code> soit le bon(la fonction <code>delay</code> s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le <code>delay</code>).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état <code>SLEEPING</code>. <br />
<br />
*Si la <code>currentTask</code> est en mode <code>SLEEPING</code>:<br />
**Si son <code>delay</code> est positif, nous soustrayons une durée <code>elapsed_time</code> fixe correspondant à une période d'éxecution au <code>delay</code> de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque <code>elapsed_time</code> est fixe et indépendant du timer <code>TCNT1</code>, il ne prend pas en compte le temps auquel s'est éxecuté le <code>delay</code> (le timer n'était pas à un multiple fixe de la période).<br />
**Si son <code>delay</code> est négatif ou nul, nous restaurons l'état de tâche à <code>ACTIVE</code>.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est <code>SLEEPING</code>. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode <code>ACTIVE</code>, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans <code>comm_spi.c</code>.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction <code>spi_init</code>, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions <code>spi_select</code> et <code>spi_deselect</code> qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à <code>spi_activer</code> et <code>spi_desactiver</code> avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction <code>spi_echange</code> envoie un octet sur le port SPI, correspondant à <code>output</code> qui est en paramètre.<br />
<br />
Finalement nous avons <code>spi_clearDisplay</code> qui réinitialise l'affichage à l'aide de la commande <code>0x76</code>, et <code>spi_setLight</code> qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de <code>spi_échange</code>, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction <code>sevenseg</code>, disponible dans <code>ordonnanceur1.c </code><br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6764SE4Binome2024-72024-11-19T13:04:41Z<p>Rboursau : /* COMMUNICATION SPI */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction delay, nous changeons l'état de la tâche à endormir en SLEEPING, puis assignons la valeur time donnée en paramètre au delay de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le delay soit le bon(la fonction delay s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le delay).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état SLEEPING. <br />
<br />
<nowiki>*</nowiki>Si la currentTask est en mode SLEEPING:<br />
<br />
<nowiki>**</nowiki>Si son delay est positif, nous soustrayons une durée elapsed_time fixe correspondant à une période d'éxecution au delay de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque elapsed_time est fixe et indépendant du timer TCNT1, il ne prend pas en compte le temps auquel s'est éxecuté le delay (le timer n'était pas à un multiple fixe de la période).<br />
<br />
<nowiki>**</nowiki>Si son delay est négatif ou nul, nous restaurons l'état de tâche à ACTIVE.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est SLEEPING. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode ACTIVE, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans comm_spi.c.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction spi_init, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions spi_select et spi_deselect qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à spi_activer et spi_desactiver avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction spi_echange envoie un octet sur le port SPI, correspondant à output qui est en paramètre.<br />
<br />
Finalement nous avons spi_clearDisplay qui réinitialise l'affichage à l'aide de la commande 0x76, et spi_setLight qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de spi_échange, et désactiver le périphérique. <br />
<br />
Vous trouverez ci-dessous une photo de l'afficheur en fonctionnement, puis une vidéo montrant l'éxecution de la tâche associée à la fonction sevenseg, disponible dans ordonnanceur1.c <br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6758SE4Binome2024-72024-11-18T11:21:01Z<p>Rboursau : /* COMMUNICATION SPI */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction delay, nous changeons l'état de la tâche à endormir en SLEEPING, puis assignons la valeur time donnée en paramètre au delay de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le delay soit le bon(la fonction delay s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le delay).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état SLEEPING. <br />
<br />
<nowiki>*</nowiki>Si la currentTask est en mode SLEEPING:<br />
<br />
<nowiki>**</nowiki>Si son delay est positif, nous soustrayons une durée elapsed_time fixe correspondant à une période d'éxecution au delay de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque elapsed_time est fixe et indépendant du timer TCNT1, il ne prend pas en compte le temps auquel s'est éxecuté le delay (le timer n'était pas à un multiple fixe de la période).<br />
<br />
<nowiki>**</nowiki>Si son delay est négatif ou nul, nous restaurons l'état de tâche à ACTIVE.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est SLEEPING. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode ACTIVE, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans <code>comm_serie.c</code>. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions <code>serie_recevoir</code> et <code>serie_envoyer</code> ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tapons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans <code>serie_envoyer</code>, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur <code>UDR0</code> correspondant au port série. Puis, la fonction donne la valeur 0 a <code>is_data_received</code> (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeur nulle.<br />
<br />
Dans <code>serie_recevoir</code>, nous attendons qu'une valeur soit écrite sur <code>UDR0</code> puis assignons cette valeur à data, et passons <code>is_data_received</code> à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
<br />
Plus simplement, lorsqu'on écrit un caractère sur le clavier de l'ordinateur, ce dernier est transmis à l'Arduino via la connexion USB. Dès que l'Arduino reçoit ce caractère, la variable <code>is_data_received</code> passe à 1 grâce à la fonction <code>serie_recevoir</code>. Ensuite, l'Arduino renvoie ce même caractère au terminal (Minicom) en utilisant la fonction <code>serie_envoyer</code>. Ainsi, on peut voir ce caractère affiché sur le terminal, ce qui confirme que la communication série fonctionne correctement.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
Après la communication série, passons à la SPI. Par manque d'originalité, toutes les fonctions sont regroupées dans comm_spi.c.<br />
<br />
Notre but est de communiquer avec un afficheur 7 segments. Celui utilisé accepte des messages de 4x8octets, avec chaque octet correspondant à un des chiffres affichés sur le 7 Segment. Il y a également des commandes spéciales pour réinitialiser l'affichage.<br />
<br />
Nous commençons par initialiser la communication. Pour cela, nous avons au préalable défini des macros conçernant nos PIN de MISO, MOSI, et les pins reliés à un connecteur HE-10, (qui dépendent de comment à été routé le shield). Nous les utilisons dans une fonction spi_init, qui va définir les entrées et sorties, et activer la communication spi en mode maître sur l'arduino.<br />
<br />
Nous avons des fonctions spi_select et spi_deselect qui (dé)sélectionnent le pin slave sur lequel communiquer.<br />
<br />
A chaque message ou commande spéciale à envoyer, nous devrons faire appel à spi_activer et spi_desactiver avant et après respectivement, pour (dés)activer le périphérique.<br />
<br />
La fonction spi_echange envoie un octet sur le port SPI, correspondant à output qui est en paramètre.<br />
<br />
Finalement nous avons spi_clearDisplay qui réinitialise l'affichage à l'aide de la commande 0x76, et spi_setLight qui configure la luminosité de l'afficheur.<br />
<br />
Pour afficher des caractères nous devons donc activer le périphérique puis envoyer 4 fois un octet à l'aide de spi_échange, et désactiver le périphérique. <br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6740SE4Binome2024-72024-11-18T10:59:35Z<p>Rboursau : /* COMMUNICATION SERIE */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Les tâches à éxecuter seront toutes regroupées dans une liste de tâches Task TaskList[NB_TASKS] dans l'ordonnanceur.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
<code>currentTask = (currentTask + 1) % NB_TASKS;</code><br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction delay, nous changeons l'état de la tâche à endormir en SLEEPING, puis assignons la valeur time donnée en paramètre au delay de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le delay soit le bon(la fonction delay s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le delay).<br />
<syntaxhighlight lang="c"><br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
</syntaxhighlight><br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état SLEEPING. <br />
<br />
<nowiki>*</nowiki>Si la currentTask est en mode SLEEPING:<br />
<br />
<nowiki>**</nowiki>Si son delay est positif, nous soustrayons une durée elapsed_time fixe correspondant à une période d'éxecution au delay de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque elapsed_time est fixe et indépendant du timer TCNT1, il ne prend pas en compte le temps auquel s'est éxecuté le delay (le timer n'était pas à un multiple fixe de la période).<br />
<br />
<nowiki>**</nowiki>Si son delay est négatif ou nul, nous restaurons l'état de tâche à ACTIVE.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est SLEEPING. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode ACTIVE, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
<br />
<br />
Maintenant que tout est fonctionnel, nous nous attaquons à la communication série. Toutes les fonctions sont disponibles dans comm_serie.c. Nous commençons par initialiser la communication en définissant la vitesse, configurons le mode (envoi et réception), puis programmons deux fonctions serie_recevoir et serie_envoyer ayant un nom peu équivoque. Le but est pour l'instant d'échanger via minicom, nous tappons des caractères au clavier qui seront renvoyés par l'arduino dans le terminal.<br />
<br />
Dans serie_envoyer, nous vérifions si nous avons reçu un caractère. Si c'est le cas, nous écrivons la data reçue sur UDR0 correspondant au port série. Puis, la fonction donne la valeur 0 a is_data_received (variable globale), signifiant qu'il n'y a plus de data à envoyer, et remettons data a une valeure nulle.<br />
<br />
Dans serie_recevoir, nous attendons qu'une valeur soit écrite sur UDR0 puis assignons cette valeur à data, et passons is_data_received à 1, signifiant que nous avons reçu une data qu'il faut envoyer.<br />
<br />
Finalement, nous intégrons ces deux fonctions dans des tâches que nous ajoutons à note liste de tâches à éxecuter. Vous pouvez trouver ci-dessous le résultat.<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
Nous avons choisi de réaliser la carte réseau RNDIS, car nous pensons que ce projet était aussi en lien avec nos cours de réseau et de système d'exploitation, cette carte était pour nous un moyen d'en apprendre plus sur ces aspects.<br />
<br />
La première chose à faire était de réaliser la carte électronique. Pour cela, des informations nous sont fournies. On sait alors que le microcontrôleur à utiliser doit avoir des capacités USB et que l'on peut utiliser soit un ATMega16u2, un ATMega32u4 ou un AT90USB suivant la mémoire que l'on veut disposer. Nous avons choisi d'utiliser un AT90USB1286-A pour sa mémoire plus grande. Nous avons pu observer sur les projets SE4 de l'année dernière que les élèves n'avait pas assez de mémoire pour des paquets réseaux importants.<br />
<br />
Ensuite, nous avons commencé à faire le schéma électrique de la carte réseau. Nous avons commencé à mettre les composants pour faire fonctionner le microcontrôleur de la même façon que sur le projet de SE3. Après cela, nous avons commencé à faire les entrées et sorties. On sait que la carte va communiquer avec la carte mère via un connecteur HE10, des signaux MISO, MOSI, SCK et CS sont alors à connecter au microcontrôleur. Nous avons choisi d'utiliser les ports suivants :<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6730SE4Binome2024-72024-11-18T10:24:57Z<p>Rboursau : /* FONCTION DELAY */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
Finalement, nous ajoutons cette ligne : <br />
<br />
currentTask = (currentTask + 1) % NB_TASKS;<br />
<br />
dans l'ordonnanceur, ce qui permet de passer d'une tâche à la suivante à chaque interruption.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans <code>ordonnanceur1.c</code> à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème concernant la manière dont ces tâches sont programmées : nous utilisons la fonction <code>_delay_ms</code> de la bibliothèque <code>delay.h</code>, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même exécutée et ne fait qu'attendre pendant son temps d'exécution. Plutôt que de faire ça, on va créer une fonction <code>delay</code>, qui va endormir la tâche pendant le temps désiré et qui permettra de libérer ce temps de travail inutile pour plutôt exécuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|<br />
|}<br />
<br />
<br />
==== FONCTION DELAY ====<br />
Pour cette fonction delay, nous changeons l'état de la tâche à endormir en SLEEPING, puis assignons la valeur time donnée en paramètre au delay de la tâche. Nous remettons le compteur à 0 et appelons l'ISR pour être sûr que le delay soit le bon(la fonction delay s'éxecute pendant une éxecution de tâche, on verra juste après pourquoi cela risque de fausser le delay).<br />
<br />
void delay(int time)<br />
<br />
{<br />
<br />
TaskList[currentTask].state = SLEEPING;<br />
<br />
TaskList[currentTask].data.data.delay = time;<br />
<br />
TCNT1 = 0;<br />
<br />
TIMER1_COMPA_vect();<br />
<br />
}<br />
<br />
Ensuite, nous allons changer l'ordonnanceur pour qu'il puisse gérer l'état SLEEPING. <br />
<br />
<nowiki>*</nowiki>Si la currentTask est en mode SLEEPING:<br />
<br />
<nowiki>**</nowiki>Si son delay est positif, nous soustrayons une durée elapsed_time fixe correspondant à une période d'éxecution au delay de cette tâche. C'est ici qu'on voit l'intérêt de reset le timer et d'appeler l'ISR : puisque elapsed_time est fixe et indépendant du timer TCNT1, il ne prend pas en compte le temps auquel s'est éxecuté le delay (le timer n'était pas à un multiple fixe de la période).<br />
<br />
<nowiki>**</nowiki>Si son delay est négatif ou nul, nous restaurons l'état de tâche à ACTIVE.<br />
<br />
Puis, dans la sélection de tâche à éxecuter ensuite, nous testons si l'état de la tâche est SLEEPING. Si c'est le cas, nous regardons la suivante, jusqu'à tomber sur une tâche en mode ACTIVE, que l'on va alors éxecuter.<br />
<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
|[[Fichier:PCB RNDIS.png|500px|PCB de la carte RNDIS]]<br />
|-<br />
|[[Fichier:Connecteur USB ALIM DATA.png|vignette|upright=1.75|Connecteur USB permettant l'ALIM de la carte en solo et le transfert DATA en réseau avec un ordinateur connecté à Internet]]<br />
|Connecteur USB permettant l'ALIM de la carte en solo (sans shield et carte-mère) et le transfert de DATA <br />
en réseau avec un ordinateur connecté à Internet<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6705SE4Binome2024-72024-11-18T10:00:08Z<p>Rboursau : /* COMMUNICATION SPI */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans ordonnanceur1.c à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème conçernant la manière dont ces tâches sont programmées : nous utilisons la fonction _delay_ms de la bibliothèque delay.h, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même éxecutée et ne fait qu'attendre pendant son temps d'éxecution. Plutôt que de faire ça, on va créer une fonction delay, qui va endormir la tâche pendant le temps désiré et qui permetttra de libérer ce temps de travail inutile pour plutôt éxecuter d'autres tâches à la place.<br />
[[Fichier:LEDBlinking.mp4|vignette]]<br />
<br />
==== FONCTION DELAY ====<br />
<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
<br />
<br />
<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
!<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6704SE4Binome2024-72024-11-18T09:59:11Z<p>Rboursau : /* CLIGNOTEMENT DES LEDs */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans ordonnanceur1.c à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème conçernant la manière dont ces tâches sont programmées : nous utilisons la fonction _delay_ms de la bibliothèque delay.h, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même éxecutée et ne fait qu'attendre pendant son temps d'éxecution. Plutôt que de faire ça, on va créer une fonction delay, qui va endormir la tâche pendant le temps désiré et qui permetttra de libérer ce temps de travail inutile pour plutôt éxecuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|}<br />
<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
==== FONCTION DELAY ====<br />
<br />
<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
!<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6702SE4Binome2024-72024-11-18T09:58:35Z<p>Rboursau : /* CLIGNOTEMENT DES LEDs */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans ordonnanceur1.c à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème conçernant la manière dont ces tâches sont programmées : nous utilisons la fonction _delay_ms de la bibliothèque delay.h, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même éxecutée et ne fait qu'attendre pendant son temps d'éxecution. Plutôt que de faire ça, on va créer une fonction sleep, qui va endormir la tâche pendant le temps désiré et qui permetttra de libérer ce temps de travail inutile pour plutôt éxecuter d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|}<br />
<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
==== FONCTION SLEEP ====<br />
<br />
<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
!<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6701SE4Binome2024-72024-11-18T09:58:02Z<p>Rboursau : /* CLIGNOTEMENT DES LEDs */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, <code>task_led1</code> et <code>task_led2</code>, dans ordonnanceur1.c à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat. Cependant, il y a un léger problème conçernant la manière dont ces tâches sont programmées : nous utilisons la fonction _delay_ms de la bibliothèque delay.h, plutôt que d'endormir la tâche. Cela signifie que la tâche est quand même éxecutée et ne fait qu'attendre pendant son temps d'éxecution. Plutôt que de faire ça, on va créer une fonction sleep, qui va endormir la tâche pendant le temps désiré et qui permetttra de libérer ce temps de travail inutile pour plutôt d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|}<br />
<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
==== FONCTION SLEEP ====<br />
<br />
<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
!<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6697SE4Binome2024-72024-11-18T09:53:11Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
<br />
<br />
Nous avons utilisé cette structure pour créer deux tâches de clignotement de LEDs, task_led1 et task_led2, dans ordonnanceur1.c à des fréquences premières entre elles. Vous trouverez ci-dessous une vidéo du résultat.<br />
<br />
Cependant, il y a un léger problème conçernant la manière dont ces tâches sont programmées : nous utilisons la fonction _delay_ms de la bibliothèque delay.h, plutôt que d'endormir la tâche. Cela signifie que la tâche est<br />
<br />
quand même éxecutée et ne fait qu'attendre pendant son temps d'éxecution. Plutôt que de faire ça, on va créer une fonction sleep, qui va endormir la tâche pendant le temps désiré et qui permetttra de libérer ce temps<br />
<br />
de travail inutile pour plutôt d'autres tâches à la place.<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|}<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
==== FONCTION SLEEP ====<br />
<br />
<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:SCHEMATIQUE CarteRNDIS.pdf|vignette|SCHEMATIQUE de la Carte RNDIS]]<br />
!<br />
|}<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6658SE4Binome2024-72024-11-13T11:11:02Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino, et que celles-ci nous semblent simultanées. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<syntaxhighlight lang="c"><br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
</syntaxhighlight><br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. Cela est vital car lorsque l'on voudra continuer l'exécution de cette fonction par la suite, nous devons savoir l'état dans lequel elle s'était arrêtée. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|}<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
==== FONCTION SLEEP ====<br />
<br />
<br />
<br />
=== Makefile ===<br />
<syntaxhighlight lang="makefile"><br />
export CC = avr-gcc<br />
<br />
export MCU = atmega328p<br />
export TARGET_ARCH = -mmcu=$(MCU)<br />
<br />
export CFLAGS = -Wall -I. -DF_CPU=16000000 -Os #-g<br />
export LDFLAGS = -g $(TARGET_ARCH) -lm -Wl,--gc-sections # -Os<br />
<br />
<br />
TARGET = ordonnanceur1<br />
#TERM = /dev/ttyUSB0<br />
TERM = /dev/ttyACM0<br />
CPPFLAGS = -mmcu=$(MCU)<br />
PGMER = -c arduino -b 115200 -P $(TERM)<br />
PGMERISP = -c arduino -b 115200 -P $(TERM)<br />
ARVDUDECONF= -C /usr/local/arduino/arduino-0021/hardware/tools/avrdude.conf<br />
export DUDE = /usr/bin/avrdude -F -v -p $(MCU) $(AVRDUDECONF)<br />
<br />
C_SRC = $(wildcard *.c)<br />
OBJS = $(C_SRC:.c=.o)<br />
<br />
<br />
all: $(TARGET).hex<br />
<br />
ass:$(C_SRC)<br />
$(CC) -S $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
clean:<br />
rm -f *.o<br />
<br />
%.o:%.c<br />
$(CC) -c $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
<br />
$(TARGET).elf: $(OBJS)<br />
$(CC) $(LDFLAGS) -o $@ $(OBJS)<br />
<br />
$(TARGET).hex: $(TARGET).elf<br />
avr-objcopy -j .text -j .data -O ihex $(TARGET).elf $(TARGET).hex<br />
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex $(TARGET).elf eeprom.hex<br />
<br />
upload: $(TARGET).hex<br />
stty -F $(TERM) hupcl # reset<br />
$(DUDE) $(PGMER) -U flash:w:$(TARGET).hex<br />
# $(DUDE) $(PGMERISP) -U flash:w:$(TARGET).hex<br />
<br />
size: $(TARGET).elf<br />
avr-size --format=avr --mcu=$(MCU) $(TARGET).elf<br />
</syntaxhighlight><br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6650SE4Binome2024-72024-11-13T11:05:21Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (<code>diviseur</code>), le mode de la minuterie (<code>CTC1</code>)) et la période (<code>periode</code>)).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros <code>SAVE_REGISTERS()</code> et <code>RESTORE_REGISTERS()</code> que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
<br />
La structure des tâches est la suivante : <br />
<br />
typedef struct Task {<br />
<br />
void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien<br />
<br />
uint16_t SPointer; // Pointeur de pile<br />
<br />
int state; // État de la tâche<br />
<br />
struct prog_data data; // Données de la tâche<br />
<br />
} Task;<br />
<br />
struct prog_data {<br />
<br />
int Type;<br />
<br />
union {<br />
<br />
int delay; // On peut ajouter d'autres types de données ici si nécessaire<br />
<br />
} data;<br />
<br />
};<br />
<br />
Nous avons un pointeur destiné à pointer vers la fonction à exécuter pour cette tâche. Le pointeur SPointer sert à sauvegarder la position du pointeur de pile pour cette fonction à l'interruption, chaque fonction ayant sa propre pile d'exécution. L'état permet d'intégrer une fonction sleep par la suite, qui rendra la tâche inactive pendant le delai delay contenu dans data.<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|}<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
==== FONCTION SLEEP ====<br />
<br />
<br />
<br />
=== Makefile ===<br />
<syntaxhighlight lang="makefile"><br />
export CC = avr-gcc<br />
<br />
export MCU = atmega328p<br />
export TARGET_ARCH = -mmcu=$(MCU)<br />
<br />
export CFLAGS = -Wall -I. -DF_CPU=16000000 -Os #-g<br />
export LDFLAGS = -g $(TARGET_ARCH) -lm -Wl,--gc-sections # -Os<br />
<br />
<br />
TARGET = ordonnanceur1<br />
#TERM = /dev/ttyUSB0<br />
TERM = /dev/ttyACM0<br />
CPPFLAGS = -mmcu=$(MCU)<br />
PGMER = -c arduino -b 115200 -P $(TERM)<br />
PGMERISP = -c arduino -b 115200 -P $(TERM)<br />
ARVDUDECONF= -C /usr/local/arduino/arduino-0021/hardware/tools/avrdude.conf<br />
export DUDE = /usr/bin/avrdude -F -v -p $(MCU) $(AVRDUDECONF)<br />
<br />
C_SRC = $(wildcard *.c)<br />
OBJS = $(C_SRC:.c=.o)<br />
<br />
<br />
all: $(TARGET).hex<br />
<br />
ass:$(C_SRC)<br />
$(CC) -S $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
clean:<br />
rm -f *.o<br />
<br />
%.o:%.c<br />
$(CC) -c $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
<br />
$(TARGET).elf: $(OBJS)<br />
$(CC) $(LDFLAGS) -o $@ $(OBJS)<br />
<br />
$(TARGET).hex: $(TARGET).elf<br />
avr-objcopy -j .text -j .data -O ihex $(TARGET).elf $(TARGET).hex<br />
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex $(TARGET).elf eeprom.hex<br />
<br />
upload: $(TARGET).hex<br />
stty -F $(TERM) hupcl # reset<br />
$(DUDE) $(PGMER) -U flash:w:$(TARGET).hex<br />
# $(DUDE) $(PGMERISP) -U flash:w:$(TARGET).hex<br />
<br />
size: $(TARGET).elf<br />
avr-size --format=avr --mcu=$(MCU) $(TARGET).elf<br />
</syntaxhighlight><br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|-<br />
|LED[1-4]<br />
|PC[0-3]<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6643SE4Binome2024-72024-11-13T10:54:32Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (diviseur), le mode de la minuterie (CTC1) et la période (periode).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros SAVE_REGISTERS() et RESTORE_REGISTERS() que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Puis nous créons notre fonction ordonnanceur, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|}<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
==== FONCTION SLEEP ====<br />
<br />
<br />
<br />
=== Makefile ===<br />
<syntaxhighlight lang="makefile"><br />
export CC = avr-gcc<br />
<br />
export MCU = atmega328p<br />
export TARGET_ARCH = -mmcu=$(MCU)<br />
<br />
export CFLAGS = -Wall -I. -DF_CPU=16000000 -Os #-g<br />
export LDFLAGS = -g $(TARGET_ARCH) -lm -Wl,--gc-sections # -Os<br />
<br />
<br />
TARGET = ordonnanceur1<br />
#TERM = /dev/ttyUSB0<br />
TERM = /dev/ttyACM0<br />
CPPFLAGS = -mmcu=$(MCU)<br />
PGMER = -c arduino -b 115200 -P $(TERM)<br />
PGMERISP = -c arduino -b 115200 -P $(TERM)<br />
ARVDUDECONF= -C /usr/local/arduino/arduino-0021/hardware/tools/avrdude.conf<br />
export DUDE = /usr/bin/avrdude -F -v -p $(MCU) $(AVRDUDECONF)<br />
<br />
C_SRC = $(wildcard *.c)<br />
OBJS = $(C_SRC:.c=.o)<br />
<br />
<br />
all: $(TARGET).hex<br />
<br />
ass:$(C_SRC)<br />
$(CC) -S $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
clean:<br />
rm -f *.o<br />
<br />
%.o:%.c<br />
$(CC) -c $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
<br />
$(TARGET).elf: $(OBJS)<br />
$(CC) $(LDFLAGS) -o $@ $(OBJS)<br />
<br />
$(TARGET).hex: $(TARGET).elf<br />
avr-objcopy -j .text -j .data -O ihex $(TARGET).elf $(TARGET).hex<br />
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex $(TARGET).elf eeprom.hex<br />
<br />
upload: $(TARGET).hex<br />
stty -F $(TERM) hupcl # reset<br />
$(DUDE) $(PGMER) -U flash:w:$(TARGET).hex<br />
# $(DUDE) $(PGMERISP) -U flash:w:$(TARGET).hex<br />
<br />
size: $(TARGET).elf<br />
avr-size --format=avr --mcu=$(MCU) $(TARGET).elf<br />
</syntaxhighlight><br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6642SE4Binome2024-72024-11-13T10:53:50Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== TESTS PRELIMINAIRES ===<br />
<br />
==== Vérification des connecteurs HE-10 ====<br />
Nous avons testé un 7-segments sur tous les connecteurs HE-10. Vous pouvez le voir dans la sous-section COMMUNICATION SPI de la section ORDONNANCEUR.<br />
<br />
==== Lecture Carte SD ====<br />
Cette image montre la detection de la carte SD sur le Shield par l'ordinateur. On peut observer son type ou sa taille et d'autres informations.<br />
{|class="wikitable"<br />
|-<br />
|[[Fichier:CarteSD.png|500px]]<br />
|}<br />
<br />
==== Fonctionnement des LEDs ====<br />
Avant de nous aventurer dans les méandres de l'ordonnanceur, nous devons vérifier que toutes les LEDs sont bien connectées. Nous n'avons pas de photos du dit test mais nous vous invitons à aller voir la sous-section CLIGNOTEMENT DES LEDs dans la section ORDONNANCEUR. Vous pouvez même observer une différence de fréquence entre les clignotements.<br />
<br />
=== ORDONNANCEUR ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
Le but de l'ordonnanceur est de répartir l'éxecution des multiples tâches que doit exécuter l'arduino. Pour faire cela, à intervalle régulier (puisque nous fonctionnons en Round Robin),l'Interrupt Service Routine (ISR) va sauvegarder l'état des registres, interrompre la tâche en cours, puis appeler l'ordonnanceur qui va choisir quelle tâche doit maintenant s'exécuter, puis restaurer l'état des registres.<br />
<br />
Pour réaliser l'ordonnanceur, nous commençons par initialiser un minuteur qui va définir la fréquence d'interruption (diviseur), le mode de la minuterie (CTC1) et la période (periode).<br />
<br />
Ensuite, nous définissons le comportement qu'il va adopter à chaque interruption. Cela est géré par la fonction ISR en mode NAKED, ce qui implique que l'on va devoir gérer les sauvegardes <br />
<br />
des registres nous mêmes (lors d'une interruption, nous commençons toujours par sauvegarder l'état des registres et les restaurons à la fin, sans quoi nous perdons tout le contexte la précédant).<br />
<br />
Nous définissons donc en parallèle deux macros SAVE_REGISTERS() et RESTORE_REGISTERS() que nous appelons respectivement au début et à la fin de chaque interruption.<br />
<br />
Nous définissons alors notre fonction ordonnanceur appelée à chaque interruption, qui est pour l'instant vide, puisque les tâches n'ont pas encore été construites, et c'est ce à quoi nous allons maintenant nous atteler.<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
|}<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|500px|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|500px]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|500px]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|500px]]<br />
|}<br />
==== FONCTION SLEEP ====<br />
<br />
<br />
<br />
=== Makefile ===<br />
<syntaxhighlight lang="makefile"><br />
export CC = avr-gcc<br />
<br />
export MCU = atmega328p<br />
export TARGET_ARCH = -mmcu=$(MCU)<br />
<br />
export CFLAGS = -Wall -I. -DF_CPU=16000000 -Os #-g<br />
export LDFLAGS = -g $(TARGET_ARCH) -lm -Wl,--gc-sections # -Os<br />
<br />
<br />
TARGET = ordonnanceur1<br />
#TERM = /dev/ttyUSB0<br />
TERM = /dev/ttyACM0<br />
CPPFLAGS = -mmcu=$(MCU)<br />
PGMER = -c arduino -b 115200 -P $(TERM)<br />
PGMERISP = -c arduino -b 115200 -P $(TERM)<br />
ARVDUDECONF= -C /usr/local/arduino/arduino-0021/hardware/tools/avrdude.conf<br />
export DUDE = /usr/bin/avrdude -F -v -p $(MCU) $(AVRDUDECONF)<br />
<br />
C_SRC = $(wildcard *.c)<br />
OBJS = $(C_SRC:.c=.o)<br />
<br />
<br />
all: $(TARGET).hex<br />
<br />
ass:$(C_SRC)<br />
$(CC) -S $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
clean:<br />
rm -f *.o<br />
<br />
%.o:%.c<br />
$(CC) -c $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
<br />
$(TARGET).elf: $(OBJS)<br />
$(CC) $(LDFLAGS) -o $@ $(OBJS)<br />
<br />
$(TARGET).hex: $(TARGET).elf<br />
avr-objcopy -j .text -j .data -O ihex $(TARGET).elf $(TARGET).hex<br />
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex $(TARGET).elf eeprom.hex<br />
<br />
upload: $(TARGET).hex<br />
stty -F $(TERM) hupcl # reset<br />
$(DUDE) $(PGMER) -U flash:w:$(TARGET).hex<br />
# $(DUDE) $(PGMERISP) -U flash:w:$(TARGET).hex<br />
<br />
size: $(TARGET).elf<br />
avr-size --format=avr --mcu=$(MCU) $(TARGET).elf<br />
</syntaxhighlight><br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|500px]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
<br />
===== PINOUT =====<br />
{| class="wikitable"<br />
|+<br />
!PIN UTILITY<br />
!PIN NAME<br />
|-<br />
|ChipSelect<br />
|PB0<br />
|-<br />
|CLK/SCK<br />
|PB1<br />
|-<br />
|MOSI<br />
|PB2<br />
|-<br />
|MISO<br />
|PB3<br />
|-<br />
|Pin d'Interruption<br />
|PB4<br />
|}<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6610SE4Binome2024-72024-11-13T10:22:00Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== Ordonnanceur ===<br />
==== SQUELETTE BASIQUE DE L'ORDONNANCEUR ====<br />
<br />
==== STRUCTURE DES TÂCHES ====<br />
<br />
==== CLIGNOTEMENT DES LEDs ====<br />
{| class="wikitable"<br />
|-<br />
|[[Fichier:LEDBlinking.mp4|vignette]]<br />
<br />
|}<br />
==== COMMUNICATION SERIE ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:Minicom .mp4|vignette|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|[[Fichier:Blinkleds.mp4|vignette]]<br />
|}<br />
<br />
==== COMMUNICATION SPI ====<br />
{| class="wikitable"<br />
|+<br />
|[[Fichier:7SegmentPicture.jpg|vignette]]<br />
|<br />
|[[Fichier:7SegDisplay.mp4|vignette]]<br />
|}<br />
==== FONCTION SLEEP ====<br />
<br />
<br />
<br />
=== Makefile ===<br />
<syntaxhighlight lang="makefile"><br />
export CC = avr-gcc<br />
<br />
export MCU = atmega328p<br />
export TARGET_ARCH = -mmcu=$(MCU)<br />
<br />
export CFLAGS = -Wall -I. -DF_CPU=16000000 -Os #-g<br />
export LDFLAGS = -g $(TARGET_ARCH) -lm -Wl,--gc-sections # -Os<br />
<br />
<br />
TARGET = ordonnanceur1<br />
#TERM = /dev/ttyUSB0<br />
TERM = /dev/ttyACM0<br />
CPPFLAGS = -mmcu=$(MCU)<br />
PGMER = -c arduino -b 115200 -P $(TERM)<br />
PGMERISP = -c arduino -b 115200 -P $(TERM)<br />
ARVDUDECONF= -C /usr/local/arduino/arduino-0021/hardware/tools/avrdude.conf<br />
export DUDE = /usr/bin/avrdude -F -v -p $(MCU) $(AVRDUDECONF)<br />
<br />
C_SRC = $(wildcard *.c)<br />
OBJS = $(C_SRC:.c=.o)<br />
<br />
<br />
all: $(TARGET).hex<br />
<br />
ass:$(C_SRC)<br />
$(CC) -S $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
clean:<br />
rm -f *.o<br />
<br />
%.o:%.c<br />
$(CC) -c $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
<br />
$(TARGET).elf: $(OBJS)<br />
$(CC) $(LDFLAGS) -o $@ $(OBJS)<br />
<br />
$(TARGET).hex: $(TARGET).elf<br />
avr-objcopy -j .text -j .data -O ihex $(TARGET).elf $(TARGET).hex<br />
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex $(TARGET).elf eeprom.hex<br />
<br />
upload: $(TARGET).hex<br />
stty -F $(TERM) hupcl # reset<br />
$(DUDE) $(PGMER) -U flash:w:$(TARGET).hex<br />
# $(DUDE) $(PGMERISP) -U flash:w:$(TARGET).hex<br />
<br />
size: $(TARGET).elf<br />
avr-size --format=avr --mcu=$(MCU) $(TARGET).elf<br />
</syntaxhighlight><br />
<br />
=== Communication Série ===<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
==== Shield ====<br />
{| class="wikitable"<br />
! Photos et vidéos || description<br />
|+<br />
|[[Fichier:Carte-mère soudée.jpg|vignette]]<br />
|Le shield soudée avec juste le BootLoader dans le microP<br />
|}<br />
[[Fichier:CarteSD.png|vignette]]<br />
<br />
==== Carte RNDIS ====<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:CarteSD.png&diff=6609Fichier:CarteSD.png2024-11-13T10:21:52Z<p>Rboursau : </p>
<hr />
<div>Détection SD par l'arduino</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6558SE4Binome2024-72024-11-13T09:52:29Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== Ordonnanceur ===<br />
==== INCLUDE & VARIABLES ====<br />
<syntaxhighlight lang="c"><br />
<br />
#include <avr/io.h><br />
#include <util/delay.h><br />
#include <avr/interrupt.h><br />
#include "ordonnanceur1.h"<br />
<br />
#define CTC1 WGM12<br />
#define PERIODE 20<br />
#define NB_TASKS 2<br />
int currentTask = 0;<br />
<br />
Task TaskList[NB_TASKS]={<br />
{task_led1, 0x600, 1},<br />
{task_led2, 0x700, 1}<br />
};<br />
<br />
</syntaxhighlight><br />
==== Initialisation du minuteur et PRESCALER ====<br />
<syntaxhighlight lang="c"><br />
void init_minuteur(int diviseur,long periode)<br />
{<br />
TCCR1A=0; // Le mode choisi n'utilise pas ce registre<br />
TCCR1B=(1<<CTC1); // Réinitialisation du minuteur sur expiration<br />
switch(diviseur)<br />
{<br />
case 8: TCCR1B |= (1<<CS11); break;<br />
case 64: TCCR1B |= (1<<CS11 | 11<<CS10); break;<br />
case 256: TCCR1B |= (1<<CS12); break;<br />
case 1024: TCCR1B |= (1<<CS12 | 1<<CS10); break;<br />
}<br />
// Un cycle prend 1/F_CPU secondes.<br />
// Un pas de compteur prend diviseur/F_CPU secondes.<br />
// Pour une periode en millisecondes, il faut (periode/1000)/(diviseur/F_CPU) pas<br />
// soit (periode*F_CPU)/(1000*diviseur)<br />
OCR1A=F_CPU/1000*periode/diviseur; // Calcul du pas<br />
TCNT1=0; // Compteur initialisé<br />
TIMSK1=(1<<OCIE1A); // Comparaison du compteur avec OCR1A<br />
}<br />
</syntaxhighlight><br />
<syntaxhighlight lang="c"><br />
void ordonnanceur()<br />
{<br />
currentTask = (currentTask + 1) % NB_TASKS;<br />
}<br />
<br />
</syntaxhighlight><br />
==== ISR ====<br />
<syntaxhighlight lang="c"><br />
ISR(TIMER1_COMPA_vect, ISR_NAKED)<br />
{<br />
SAVE_REGISTERS();<br />
TaskList[currentTask].SPointer = SP;<br />
ordonnanceur();<br />
SP = TaskList[currentTask].SPointer;<br />
RESTORE_REGISTERS();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
==== Initialisation des taches ====<br />
<syntaxhighlight lang="c"><br />
void init_task(int n)<br />
{<br />
int saveSP = SP;<br />
SP = TaskList[n].SPointer;<br />
int16_t address = (uint16_t)TaskList[n].fonction;<br />
asm volatile ("push %0 \n\t" : : "r" (address & 0x00ff));<br />
asm volatile ("push %0 \n\t" : : "r" ((address & 0xff00) >> 8));<br />
SAVE_REGISTERS();<br />
TaskList[n].SPointer = SP;<br />
SP = saveSP;<br />
}<br />
</syntaxhighlight><br />
==== MAIN ====<br />
<syntaxhighlight lang="c"><br />
<br />
int main(void)<br />
{<br />
init_minuteur(256,PERIODE);<br />
for(int i=1;i<NB_TASKS;i++) init_task(i);<br />
sei();<br />
SP = TaskList[currentTask].SPointer;<br />
TaskList[currentTask].fonction();<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
==== TACHE LED 1 ====<br />
<syntaxhighlight lang="c"><br />
void task_led1()<br />
{<br />
DDRC |= 0b00000001;<br />
while(1)<br />
{<br />
_delay_ms(100);<br />
PORTC ^= 0b00000001;<br />
}<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
==== TACHE LED 2 ====<br />
<br />
<syntaxhighlight lang="c"><br />
void task_led2()<br />
{<br />
DDRC |= 0b00001000;<br />
while(1)<br />
{<br />
_delay_ms(173);<br />
PORTC ^= 0b00001000;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Makefile ===<br />
<syntaxhighlight lang="makefile"><br />
export CC = avr-gcc<br />
<br />
export MCU = atmega328p<br />
export TARGET_ARCH = -mmcu=$(MCU)<br />
<br />
export CFLAGS = -Wall -I. -DF_CPU=16000000 -Os #-g<br />
export LDFLAGS = -g $(TARGET_ARCH) -lm -Wl,--gc-sections # -Os<br />
<br />
<br />
TARGET = ordonnanceur1<br />
#TERM = /dev/ttyUSB0<br />
TERM = /dev/ttyACM0<br />
CPPFLAGS = -mmcu=$(MCU)<br />
PGMER = -c arduino -b 115200 -P $(TERM)<br />
PGMERISP = -c arduino -b 115200 -P $(TERM)<br />
ARVDUDECONF= -C /usr/local/arduino/arduino-0021/hardware/tools/avrdude.conf<br />
export DUDE = /usr/bin/avrdude -F -v -p $(MCU) $(AVRDUDECONF)<br />
<br />
C_SRC = $(wildcard *.c)<br />
OBJS = $(C_SRC:.c=.o)<br />
<br />
<br />
all: $(TARGET).hex<br />
<br />
ass:$(C_SRC)<br />
$(CC) -S $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
clean:<br />
rm -f *.o<br />
<br />
%.o:%.c<br />
$(CC) -c $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
<br />
$(TARGET).elf: $(OBJS)<br />
$(CC) $(LDFLAGS) -o $@ $(OBJS)<br />
<br />
$(TARGET).hex: $(TARGET).elf<br />
avr-objcopy -j .text -j .data -O ihex $(TARGET).elf $(TARGET).hex<br />
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex $(TARGET).elf eeprom.hex<br />
<br />
upload: $(TARGET).hex<br />
stty -F $(TERM) hupcl # reset<br />
$(DUDE) $(PGMER) -U flash:w:$(TARGET).hex<br />
# $(DUDE) $(PGMERISP) -U flash:w:$(TARGET).hex<br />
<br />
size: $(TARGET).elf<br />
avr-size --format=avr --mcu=$(MCU) $(TARGET).elf<br />
</syntaxhighlight><br />
<br />
=== Communication Série ===<br />
{| class="wikitable" style=text-align:left<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
void serie_init(long int vitesse){<br />
UBRR0=F_CPU/(((unsigned long int)speed)<<4)-1; // configure la vitesse<br />
UCSR0B=(1<<TXEN0 | 1<<RXEN0); // autorise l'envoi et la réception<br />
UCSR0C=(1<<UCSZ01 | 1<<UCSZ00); // 8 bits et 1 bit de stop<br />
UCSR0A &= ~(1 << U2X0); // double vitesse désactivée<br />
}<br />
<br />
void serie_envoyer(char c){<br />
loop_until_bit_is_set(UCSR0A,UDRE0);<br />
UDR0=c;<br />
}<br />
<br />
char serie_recevoir(void){<br />
loop_until_bit_is_set(UCSR0A, RXC0);<br />
return UDR0;<br />
}<br />
<br />
int main(void){<br />
serie_init(9600);<br />
while(1){<br />
unsigned char c=serie_recevoir();<br />
serie_envoyer(c);<br />
}<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
| [[Fichier:Minicom .mp4|vignette|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|}<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
[[Fichier:7SegmentPicture.jpg|vignette]]<br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Carte-mère soudée.jpg|vignette]]<br />
![[Fichier:7SegDisplay.mp4|vignette]]La carte-mère soudée mais pas encore programmée<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
[[Fichier:Blinkleds.mp4|vignette]]<br />
<br />
== NOTES ==<br />
[[Fichier:LEDBlinking.mp4|vignette]]<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:7SegmentPicture.jpg&diff=6557Fichier:7SegmentPicture.jpg2024-11-13T09:52:17Z<p>Rboursau : </p>
<hr />
<div>Image du 7 Segment</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:7SegDisplay.mp4&diff=6555Fichier:7SegDisplay.mp42024-11-13T09:51:42Z<p>Rboursau : </p>
<hr />
<div>Afficheur 7 Segments fonctionnant grâce à l'ordonnanceur.</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:LEDBlinking.mp4&diff=6553Fichier:LEDBlinking.mp42024-11-13T09:50:51Z<p>Rboursau : </p>
<hr />
<div>LED clignotantes à deux féquences premières entre elles</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6549SE4Binome2024-72024-11-13T09:49:27Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== Ordonnanceur ===<br />
==== INCLUDE & VARIABLES ====<br />
<syntaxhighlight lang="c"><br />
<br />
#include <avr/io.h><br />
#include <util/delay.h><br />
#include <avr/interrupt.h><br />
#include "ordonnanceur1.h"<br />
<br />
#define CTC1 WGM12<br />
#define PERIODE 20<br />
#define NB_TASKS 2<br />
int currentTask = 0;<br />
<br />
Task TaskList[NB_TASKS]={<br />
{task_led1, 0x600, 1},<br />
{task_led2, 0x700, 1}<br />
};<br />
<br />
</syntaxhighlight><br />
==== Initialisation du minuteur et PRESCALER ====<br />
<syntaxhighlight lang="c"><br />
void init_minuteur(int diviseur,long periode)<br />
{<br />
TCCR1A=0; // Le mode choisi n'utilise pas ce registre<br />
TCCR1B=(1<<CTC1); // Réinitialisation du minuteur sur expiration<br />
switch(diviseur)<br />
{<br />
case 8: TCCR1B |= (1<<CS11); break;<br />
case 64: TCCR1B |= (1<<CS11 | 11<<CS10); break;<br />
case 256: TCCR1B |= (1<<CS12); break;<br />
case 1024: TCCR1B |= (1<<CS12 | 1<<CS10); break;<br />
}<br />
// Un cycle prend 1/F_CPU secondes.<br />
// Un pas de compteur prend diviseur/F_CPU secondes.<br />
// Pour une periode en millisecondes, il faut (periode/1000)/(diviseur/F_CPU) pas<br />
// soit (periode*F_CPU)/(1000*diviseur)<br />
OCR1A=F_CPU/1000*periode/diviseur; // Calcul du pas<br />
TCNT1=0; // Compteur initialisé<br />
TIMSK1=(1<<OCIE1A); // Comparaison du compteur avec OCR1A<br />
}<br />
</syntaxhighlight><br />
<syntaxhighlight lang="c"><br />
void ordonnanceur()<br />
{<br />
currentTask = (currentTask + 1) % NB_TASKS;<br />
}<br />
<br />
</syntaxhighlight><br />
==== ISR ====<br />
<syntaxhighlight lang="c"><br />
ISR(TIMER1_COMPA_vect, ISR_NAKED)<br />
{<br />
SAVE_REGISTERS();<br />
TaskList[currentTask].SPointer = SP;<br />
ordonnanceur();<br />
SP = TaskList[currentTask].SPointer;<br />
RESTORE_REGISTERS();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
==== Initialisation des taches ====<br />
<syntaxhighlight lang="c"><br />
void init_task(int n)<br />
{<br />
int saveSP = SP;<br />
SP = TaskList[n].SPointer;<br />
int16_t address = (uint16_t)TaskList[n].fonction;<br />
asm volatile ("push %0 \n\t" : : "r" (address & 0x00ff));<br />
asm volatile ("push %0 \n\t" : : "r" ((address & 0xff00) >> 8));<br />
SAVE_REGISTERS();<br />
TaskList[n].SPointer = SP;<br />
SP = saveSP;<br />
}<br />
</syntaxhighlight><br />
==== MAIN ====<br />
<syntaxhighlight lang="c"><br />
<br />
int main(void)<br />
{<br />
init_minuteur(256,PERIODE);<br />
for(int i=1;i<NB_TASKS;i++) init_task(i);<br />
sei();<br />
SP = TaskList[currentTask].SPointer;<br />
TaskList[currentTask].fonction();<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
==== TACHE LED 1 ====<br />
<syntaxhighlight lang="c"><br />
void task_led1()<br />
{<br />
DDRC |= 0b00000001;<br />
while(1)<br />
{<br />
_delay_ms(100);<br />
PORTC ^= 0b00000001;<br />
}<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
==== TACHE LED 2 ====<br />
<br />
<syntaxhighlight lang="c"><br />
void task_led2()<br />
{<br />
DDRC |= 0b00001000;<br />
while(1)<br />
{<br />
_delay_ms(173);<br />
PORTC ^= 0b00001000;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Makefile ===<br />
<syntaxhighlight lang="makefile"><br />
export CC = avr-gcc<br />
<br />
export MCU = atmega328p<br />
export TARGET_ARCH = -mmcu=$(MCU)<br />
<br />
export CFLAGS = -Wall -I. -DF_CPU=16000000 -Os #-g<br />
export LDFLAGS = -g $(TARGET_ARCH) -lm -Wl,--gc-sections # -Os<br />
<br />
<br />
TARGET = ordonnanceur1<br />
#TERM = /dev/ttyUSB0<br />
TERM = /dev/ttyACM0<br />
CPPFLAGS = -mmcu=$(MCU)<br />
PGMER = -c arduino -b 115200 -P $(TERM)<br />
PGMERISP = -c arduino -b 115200 -P $(TERM)<br />
ARVDUDECONF= -C /usr/local/arduino/arduino-0021/hardware/tools/avrdude.conf<br />
export DUDE = /usr/bin/avrdude -F -v -p $(MCU) $(AVRDUDECONF)<br />
<br />
C_SRC = $(wildcard *.c)<br />
OBJS = $(C_SRC:.c=.o)<br />
<br />
<br />
all: $(TARGET).hex<br />
<br />
ass:$(C_SRC)<br />
$(CC) -S $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
clean:<br />
rm -f *.o<br />
<br />
%.o:%.c<br />
$(CC) -c $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
<br />
$(TARGET).elf: $(OBJS)<br />
$(CC) $(LDFLAGS) -o $@ $(OBJS)<br />
<br />
$(TARGET).hex: $(TARGET).elf<br />
avr-objcopy -j .text -j .data -O ihex $(TARGET).elf $(TARGET).hex<br />
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex $(TARGET).elf eeprom.hex<br />
<br />
upload: $(TARGET).hex<br />
stty -F $(TERM) hupcl # reset<br />
$(DUDE) $(PGMER) -U flash:w:$(TARGET).hex<br />
# $(DUDE) $(PGMERISP) -U flash:w:$(TARGET).hex<br />
<br />
size: $(TARGET).elf<br />
avr-size --format=avr --mcu=$(MCU) $(TARGET).elf<br />
</syntaxhighlight><br />
<br />
=== Communication Série ===<br />
{| class="wikitable" style=text-align:left<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
void serie_init(long int vitesse){<br />
UBRR0=F_CPU/(((unsigned long int)speed)<<4)-1; // configure la vitesse<br />
UCSR0B=(1<<TXEN0 | 1<<RXEN0); // autorise l'envoi et la réception<br />
UCSR0C=(1<<UCSZ01 | 1<<UCSZ00); // 8 bits et 1 bit de stop<br />
UCSR0A &= ~(1 << U2X0); // double vitesse désactivée<br />
}<br />
<br />
void serie_envoyer(char c){<br />
loop_until_bit_is_set(UCSR0A,UDRE0);<br />
UDR0=c;<br />
}<br />
<br />
char serie_recevoir(void){<br />
loop_until_bit_is_set(UCSR0A, RXC0);<br />
return UDR0;<br />
}<br />
<br />
int main(void){<br />
serie_init(9600);<br />
while(1){<br />
unsigned char c=serie_recevoir();<br />
serie_envoyer(c);<br />
}<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
| [[Fichier:Minicom .mp4|vignette|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|}<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
<br />
==== Shield ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Carte-mère soudée.jpg|vignette]]<br />
!La carte-mère soudée mais pas encore programmée<br />
|}<br />
<br />
==== Carte RNDIS ====<br />
[[Fichier:Blinkleds.mp4|vignette]]<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Blinkleds.mp4&diff=6545Fichier:Blinkleds.mp42024-11-13T09:48:44Z<p>Rboursau : </p>
<hr />
<div>LEDs clignotent a deux fréquences premières entre elles</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6519SE4Binome2024-72024-11-09T15:49:30Z<p>Rboursau : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;"> Code Source et autre programmes</div>=<br />
<br />
=== Ordonnanceur ===<br />
==== INCLUDE & VARIABLES ====<br />
<syntaxhighlight lang="c"><br />
<br />
#include <avr/io.h><br />
#include <util/delay.h><br />
#include <avr/interrupt.h><br />
#include "ordonnanceur1.h"<br />
<br />
#define CTC1 WGM12<br />
#define PERIODE 20<br />
#define NB_TASKS 2<br />
int currentTask = 0;<br />
<br />
Task TaskList[NB_TASKS]={<br />
{task_led1, 0x600, 1},<br />
{task_led2, 0x700, 1}<br />
};<br />
<br />
</syntaxhighlight><br />
==== Initialisation du minuteur et PRESCALER ====<br />
<syntaxhighlight lang="c"><br />
void init_minuteur(int diviseur,long periode)<br />
{<br />
TCCR1A=0; // Le mode choisi n'utilise pas ce registre<br />
TCCR1B=(1<<CTC1); // Réinitialisation du minuteur sur expiration<br />
switch(diviseur)<br />
{<br />
case 8: TCCR1B |= (1<<CS11); break;<br />
case 64: TCCR1B |= (1<<CS11 | 11<<CS10); break;<br />
case 256: TCCR1B |= (1<<CS12); break;<br />
case 1024: TCCR1B |= (1<<CS12 | 1<<CS10); break;<br />
}<br />
// Un cycle prend 1/F_CPU secondes.<br />
// Un pas de compteur prend diviseur/F_CPU secondes.<br />
// Pour une periode en millisecondes, il faut (periode/1000)/(diviseur/F_CPU) pas<br />
// soit (periode*F_CPU)/(1000*diviseur)<br />
OCR1A=F_CPU/1000*periode/diviseur; // Calcul du pas<br />
TCNT1=0; // Compteur initialisé<br />
TIMSK1=(1<<OCIE1A); // Comparaison du compteur avec OCR1A<br />
}<br />
</syntaxhighlight><br />
<syntaxhighlight lang="c"><br />
void ordonnanceur()<br />
{<br />
currentTask = (currentTask + 1) % NB_TASKS;<br />
}<br />
<br />
</syntaxhighlight><br />
==== ISR ====<br />
<syntaxhighlight lang="c"><br />
ISR(TIMER1_COMPA_vect, ISR_NAKED)<br />
{<br />
SAVE_REGISTERS();<br />
TaskList[currentTask].SPointer = SP;<br />
ordonnanceur();<br />
SP = TaskList[currentTask].SPointer;<br />
RESTORE_REGISTERS();<br />
asm volatile ("reti");<br />
}<br />
</syntaxhighlight><br />
==== Initialisation des taches ====<br />
<syntaxhighlight lang="c"><br />
void init_task(int n)<br />
{<br />
int saveSP = SP;<br />
SP = TaskList[n].SPointer;<br />
int16_t address = (uint16_t)TaskList[n].fonction;<br />
asm volatile ("push %0 \n\t" : : "r" (address & 0x00ff));<br />
asm volatile ("push %0 \n\t" : : "r" ((address & 0xff00) >> 8));<br />
SAVE_REGISTERS();<br />
TaskList[n].SPointer = SP;<br />
SP = saveSP;<br />
}<br />
</syntaxhighlight><br />
==== MAIN ====<br />
<syntaxhighlight lang="c"><br />
<br />
int main(void)<br />
{<br />
init_minuteur(256,PERIODE);<br />
for(int i=1;i<NB_TASKS;i++) init_task(i);<br />
sei();<br />
SP = TaskList[currentTask].SPointer;<br />
TaskList[currentTask].fonction();<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
==== MACROS ====<br />
<syntaxhighlight lang="c"><br />
#define SAVE_REGISTERS() \<br />
asm volatile ( \<br />
"push r0 \n\t" \<br />
"in r0, __SREG__ \n\t" \<br />
"push r0 \n\t" \<br />
"push r1 \n\t" \<br />
"push r2 \n\t" \<br />
"push r3 \n\t" \<br />
"push r4 \n\t" \<br />
"push r5 \n\t" \<br />
"push r6 \n\t" \<br />
"push r7 \n\t" \<br />
"push r8 \n\t" \<br />
"push r9 \n\t" \<br />
"push r10 \n\t" \<br />
"push r11 \n\t" \<br />
"push r12 \n\t" \<br />
"push r13 \n\t" \<br />
"push r14 \n\t" \<br />
"push r15 \n\t" \<br />
"push r16 \n\t" \<br />
"push r17 \n\t" \<br />
"push r18 \n\t" \<br />
"push r19 \n\t" \<br />
"push r20 \n\t" \<br />
"push r21 \n\t" \<br />
"push r22 \n\t" \<br />
"push r23 \n\t" \<br />
"push r24 \n\t" \<br />
"push r25 \n\t" \<br />
"push r26 \n\t" \<br />
"push r27 \n\t" \<br />
"push r28 \n\t" \<br />
"push r29 \n\t" \<br />
"push r30 \n\t" \<br />
"push r31 \n\t" \<br />
)<br />
<br />
#define RESTORE_REGISTERS() \<br />
asm volatile ( \<br />
"pop r31 \n\t" \<br />
"pop r30 \n\t" \<br />
"pop r29 \n\t" \<br />
"pop r28 \n\t" \<br />
"pop r27 \n\t" \<br />
"pop r26 \n\t" \<br />
"pop r25 \n\t" \<br />
"pop r24 \n\t" \<br />
"pop r23 \n\t" \<br />
"pop r22 \n\t" \<br />
"pop r21 \n\t" \<br />
"pop r20 \n\t" \<br />
"pop r19 \n\t" \<br />
"pop r18 \n\t" \<br />
"pop r17 \n\t" \<br />
"pop r16 \n\t" \<br />
"pop r15 \n\t" \<br />
"pop r14 \n\t" \<br />
"pop r13 \n\t" \<br />
"pop r12 \n\t" \<br />
"pop r11 \n\t" \<br />
"pop r10 \n\t" \<br />
"pop r9 \n\t" \<br />
"pop r8 \n\t" \<br />
"pop r7 \n\t" \<br />
"pop r6 \n\t" \<br />
"pop r5 \n\t" \<br />
"pop r4 \n\t" \<br />
"pop r3 \n\t" \<br />
"pop r2 \n\t" \<br />
"pop r1 \n\t" \<br />
"pop r0 \n\t" \<br />
"out __SREG__, r0 \n\t" \<br />
"pop r0 \n\t" \<br />
)<br />
</syntaxhighlight><br />
==== TACHE LED 1 ====<br />
<syntaxhighlight lang="c"><br />
void task_led1()<br />
{<br />
DDRC |= 0b00000001;<br />
while(1)<br />
{<br />
_delay_ms(100);<br />
PORTC ^= 0b00000001;<br />
}<br />
}<br />
<br />
</syntaxhighlight><br />
<br />
==== TACHE LED 2 ====<br />
<br />
<syntaxhighlight lang="c"><br />
void task_led2()<br />
{<br />
DDRC |= 0b00001000;<br />
while(1)<br />
{<br />
_delay_ms(173);<br />
PORTC ^= 0b00001000;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Makefile ===<br />
<syntaxhighlight lang="makefile"><br />
export CC = avr-gcc<br />
<br />
export MCU = atmega328p<br />
export TARGET_ARCH = -mmcu=$(MCU)<br />
<br />
export CFLAGS = -Wall -I. -DF_CPU=16000000 -Os #-g<br />
export LDFLAGS = -g $(TARGET_ARCH) -lm -Wl,--gc-sections # -Os<br />
<br />
<br />
TARGET = ordonnanceur1<br />
#TERM = /dev/ttyUSB0<br />
TERM = /dev/ttyACM0<br />
CPPFLAGS = -mmcu=$(MCU)<br />
PGMER = -c arduino -b 115200 -P $(TERM)<br />
PGMERISP = -c arduino -b 115200 -P $(TERM)<br />
ARVDUDECONF= -C /usr/local/arduino/arduino-0021/hardware/tools/avrdude.conf<br />
export DUDE = /usr/bin/avrdude -F -v -p $(MCU) $(AVRDUDECONF)<br />
<br />
C_SRC = $(wildcard *.c)<br />
OBJS = $(C_SRC:.c=.o)<br />
<br />
<br />
all: $(TARGET).hex<br />
<br />
ass:$(C_SRC)<br />
$(CC) -S $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
clean:<br />
rm -f *.o<br />
<br />
%.o:%.c<br />
$(CC) -c $(CPPFLAGS) $(CFLAGS) $< -o $@<br />
<br />
<br />
$(TARGET).elf: $(OBJS)<br />
$(CC) $(LDFLAGS) -o $@ $(OBJS)<br />
<br />
$(TARGET).hex: $(TARGET).elf<br />
avr-objcopy -j .text -j .data -O ihex $(TARGET).elf $(TARGET).hex<br />
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex $(TARGET).elf eeprom.hex<br />
<br />
upload: $(TARGET).hex<br />
stty -F $(TERM) hupcl # reset<br />
$(DUDE) $(PGMER) -U flash:w:$(TARGET).hex<br />
# $(DUDE) $(PGMERISP) -U flash:w:$(TARGET).hex<br />
<br />
size: $(TARGET).elf<br />
avr-size --format=avr --mcu=$(MCU) $(TARGET).elf<br />
</syntaxhighlight><br />
<br />
=== Communication Série ===<br />
{| class="wikitable" style=text-align:left<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
void serie_init(long int vitesse){<br />
UBRR0=F_CPU/(((unsigned long int)speed)<<4)-1; // configure la vitesse<br />
UCSR0B=(1<<TXEN0 | 1<<RXEN0); // autorise l'envoi et la réception<br />
UCSR0C=(1<<UCSZ01 | 1<<UCSZ00); // 8 bits et 1 bit de stop<br />
UCSR0A &= ~(1 << U2X0); // double vitesse désactivée<br />
}<br />
<br />
void serie_envoyer(char c){<br />
loop_until_bit_is_set(UCSR0A,UDRE0);<br />
UDR0=c;<br />
}<br />
<br />
char serie_recevoir(void){<br />
loop_until_bit_is_set(UCSR0A, RXC0);<br />
return UDR0;<br />
}<br />
<br />
int main(void){<br />
serie_init(9600);<br />
while(1){<br />
unsigned char c=serie_recevoir();<br />
serie_envoyer(c);<br />
}<br />
return 0;<br />
}<br />
<br />
</syntaxhighlight><br />
| [[Fichier:Minicom .mp4|vignette|Minicom démontrant le bon fonctionnement du code à gauche]]<br />
|}<br />
<br />
=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #ED254E; vertical-align: top; width: 98%;">Schéma, PCB & KiCAD</div>=<br />
<br />
==== Carte soudée ====<br />
{| class="wikitable"<br />
|+<br />
![[Fichier:Carte-mère soudée.jpg|vignette]]<br />
!La carte-mère soudée mais pas encore programmée<br />
|}<br />
<br />
==== Carte mère soudée ====<br />
<br />
==== Carte Fille réseau RNDIS soudée ====<br />
<br />
== NOTES ==<br />
deux ports USB pour la carte fille : un pour la connexion en ISP/Réseau à l'ordinateur et un pour la programmation. Possibilité de faire une connexion SPI avec un câble RJ45<br />
<br />
== Ressources & Sources ==<br />
<br />
===== Lien Git : https://gitea.plil.fr/rboursau/S8-Pico-Binome-7 =====</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE4Binome2024-7&diff=6100SE4Binome2024-72024-10-02T13:31:05Z<p>Rboursau : </p>
<hr />
<div><nowiki>#</nowiki>include <avr/io.h><br />
<br />
<nowiki>#</nowiki>include <avr/interrupt.h><br />
<br />
<nowiki>#</nowiki>define CTC1 WGM12 // Meilleur nom pour le bit<br />
<br />
<nowiki>#</nowiki>define PERIODE 1000<br />
<br />
void init_minuteur(int diviseur,long periode){<br />
<br />
TCCR1A=0; // Le mode choisi n'utilise pas ce registre<br />
<br />
TCCR1B=(1<<CTC1); // Réinitialisation du minuteur sur expiration<br />
<br />
switch(diviseur){<br />
<br />
case 8: TCCR1B |= (1<<CS11); break;<br />
<br />
case 64: TCCR1B |= (1<<CS11 | 11<<CS10); break;<br />
<br />
case 256: TCCR1B |= (1<<CS12); break;<br />
<br />
case 1024: TCCR1B |= (1<<CS12 | 1<<CS10); break;<br />
<br />
}<br />
<br />
OCR1A=F_CPU/1000*periode/diviseur;<br />
<br />
TCNT1=0;<br />
<br />
TIMSK1=(1<<OCIE1A);<br />
<br />
}<br />
<br />
ISR(TIMER1_COMPA_vect){<br />
<br />
}<br />
<br />
int main(void){<br />
<br />
DDRC &= 0b000000001; // Chenillard sur 4 LED<br />
<br />
PORTB ^= ~0b00000001; // LED éteintes<br />
<br />
init_minuteur(256,PERIODE);<br />
<br />
sei();<br />
<br />
while(1);<br />
<br />
}</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Pico_SE4_2024/2025&diff=6022Pico SE4 2024/20252024-09-23T10:22:07Z<p>Rboursau : </p>
<hr />
<div>= Objectif =<br />
<br />
Voir le sujet dans le menu englobant.<br />
<br />
= Organisation du travail =<br />
<br />
Vous déposerez votre travail dans un projet GIT sur le serveur [https://gitea.plil.fr Gitea de la platforme informatique].<br />
<br />
= Bouclier ordonnanceur =<br />
<br />
Vous devez réaliser le bouclier Arduino Uno pour l'ordonnancement et pour que chaque binôme puisse simuler une carte mère.<br />
<br />
A la base le bouclier permet de connecter 5 périphériques SPI via des connecteurs IDC HE10 8 contacts. 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.<br />
<br />
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 a utiliser est la 74LV125.<br />
<br />
[[File:2024_picoshield_schematic.pdf|thumb|left|500px|Schéma PicoShield]]<br />
<br />
[[File:2024_picoshield_footprints.png|thumb|right|500px|Empreintes]]<br />
<br />
<br style="clear: both;" /><br />
<br />
= Réalisations des élèves =<br />
<br />
{| class="wikitable"<br />
! Numéro du binôme !! Numéro du groupe !! Elèves !! Page <br />
|-<br />
| Binôme 1<br />
| Groupe 1<br />
| Lilian GREVIN & Sarah DEPARIS<br />
| [[SE4Binome2024-1|Binôme 1 2024/2025]]<br />
|-<br />
| Binôme 2<br />
| Groupe 1<br />
| Kaoutar EL BACHIRI & Maxime BARRET<br />
| [[SE4Binome2024-2|Binôme 2 2024/2025]]<br />
|-<br />
| Binôme 3<br />
| Groupe 1<br />
| DETREZ Victorien & CART Benjamin<br />
| [[SE4Binome2024-3|Binôme 3 2024/2025]]<br />
|-<br />
| Binôme 4<br />
| Groupe 1<br />
|WACQUET Justin & TEPELI Ibrahim<br />
| [[SE4Binome2024-4|Binôme 4 2024/2025]]<br />
|-<br />
| Binôme 5<br />
| Groupe 2<br />
| Augustin DJADJA-AVONYO & Kévan TOURON<br />
| [[SE4Binome2024-5|Binôme 5 2024/2025]]<br />
|-<br />
| Binôme 6<br />
| Groupe 2<br />
| Yassine YAHIANI & Abdel ZONGO<br />
| [[SE4Binome2024-6|Binôme 6 2024/2025]]<br />
|-<br />
| Binôme 7<br />
| Groupe 2<br />
| Rémi BOURSAULT & Prénom NOM<br />
| [[SE4Binome2024-7|Binôme 7 2024/2025]]<br />
|-<br />
| Binôme 8<br />
| Groupe 2<br />
| Louis BONNINGRE & Prénom NOM<br />
| [[SE4Binome2024-8|Binôme 8 2024/2025]]<br />
|-<br />
| Binôme 9<br />
| Groupe 3<br />
| Camille CARIAT & Agathe HOUDUSSE<br />
| [[SE4Binome2024-9|Binôme 9 2024/2025]]<br />
|-<br />
|}</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3_PSE_Binome2023-5&diff=5979SE3 PSE Binome2023-52024-06-15T14:13:35Z<p>Rboursau : /* Ajout des Diodes Électro-Luminescentes (la classe) */</p>
<hr />
<div>= Projet système embarqué de Rémi BOURSAULT et Antoine LECOMTE =<br />
L'objectif de ce module est de modéliser une manette, puis de la rendre fonctionnelle, pour jouer au jeu Space Invaders qui est codé dans le même module.<br />
<br />
Les professeurs avaient préalablement fourni un dossier contenant un modèle de PCB incomplet et différents fichiers ".c" et ".h" pour nous aider à démarrer. <br />
<br />
== Création de Manette ==<br />
La création de la manette commence par la création sur kicad d'un PCB. Nous avons pris celui fourni sur le wiki du projet qui possède tous les composants mais non routés. <br />
<br />
<br />
<br />
<br />
<br />
== Modélisation PCB ==<br />
A partir du fichier KiCad fourni, nous avons modélisé un PCB déstiné à être utilisé comme manette. Nous avons donc ajouté des boutons, replacé ces derniers. Grâce au schéma nous avons sélectionné des PIN pour connecter les boutons, ainsi que des LEDs et des résistances que nous avons aussi ajouté. <br />
<br />
Voyant que nous avions encore de l'espace de libre sur notre carte, étant un peu ambitieux et voyant que le procédé n'est pas bien compliqué, nous décidons alors de rajouter quelque boutons et quelques LEDs en plus pour que notre manette soit un peu plus crédibles. <br />
<br />
Il nous a alors fallu rajouté les dit composants sur notre schéma pour que ceux-ci soient rajoutés automatiquement sur le PCB lors de l'utilisation de la fonction "Update PCB with changes made to schematic" <br />
<br />
<br />
<gallery><br />
File:Image boutons.png|Schéma des boutons<br />
File:Connecteur ISP.png|Schéma du connecteur ISP<br />
File:Schéma des LEDs.png|Schéma des LEDs<br />
File:Connecteur USB.png|Schéma du connecteur USB<br />
File:Microcontroleur.png|Schéma du microcontrôleur<br />
</gallery><br />
<br />
<br />
[[Fichier:Plan pcb.jpg|thumb|center|500px| Ajout du plan de masse et des via]]<br />
<br />
<br />
<br />
Une fois le routage effectué, nous avons ajouté un plan de masse et ajouté une grande quantité de via à différent endroits de la carte pour que la masse soit bien connectée et éviter les fuites thermiques de certains composants. <br />
<br />
Ensuite le fichier a été envoyé pour impression en Chine, grâce au fichier Gerber généré par KiCad que vous pouvez retrouvez sur notre GIT:<br />
<br />
<br />
[[Fichier:Vue3d.jpg|thumb|center|500px| Rendu 3D final de la carte]]<br />
<br />
== Programmateur AVR ==<br />
En attendant de recevoir les cartes, nous nous sommes initiés à la programmation d'un périphérique USB, nous avons utilisé les bibliothèques LUFA et LibUSB pour utilisé un programmateur AVR. Il nous a fallu également modifier des fichiers Descripteurs, en ".c" et ".h" qui permettent, une fois téléversés dans le programmateur, d'être détecter par le PC et que celui-ci reconnaisse les fonctionnalités du périphérique (InPoint et EndPoint). <br />
<br />
<br />
== Soudure de la carte ==<br />
Une fois la carte reçu, nous avons pris tous nos composants et avons commencé à les souder. N'ayant que très peu d'expérience dans ce domaine ce n'était pas quelque chose de facile au début. Il nous a fallu un peu d'aide et pas mal de flux pour comprendre comment faire des soudures propres. Une fois le coup de main pris, la fin du montage de la carte était assez rapide. Nous avons donc pu passer à la programmation pour la reconnaissance par l'ordinateur de notre carte.<br />
[[Fichier:Carte vierge.jpg|thumb|left|500px| Carte vierge]]<br />
<br />
[[Fichier:Carte soudée manette.jpg|thumb|center|500px| Carte avec tous les composants soudés]]<br />
<br />
<br />
<br />
Une fois la carte soudée il a fallu pouvoir la configurer pour par la suite pouvoir la programmer. Pour se faire il faut lui injecter un bootloader via son programmateur ISP. Ce qui passe la manette en mode DFU et elle est alors reconnu par l'ordinateur.<br />
[[Fichier:Manette reconnu en mode dfu.png|thumb|center|500px| Manette reconnu en mode DFU]]<br />
<br />
== LUFA de la manette ==<br />
Après avoir reçu les cartes et terminé de souder les composants nous avons pu attaquer la programmation du microcontrôleur pour pouvoir utiliser la manette. Nous avons procédés étape par étape, en commençant par allumé les LEDs puis réceptionner les signaux des boutons pour finir par fusionner les deux pour avoir une manette fonctionnelle.<br />
<br />
=== LEDs ===<br />
Pour éviter un décalage sur le portF il faut désactiver le JTAG en copiant deux fois cette ligne au niveau de la déclaration des pins : <code>MCUCR |= (1<<JTD);</code>cela permet d'accéder aux LEDs sur les pins PF4 et PF5.<br />
Une fois la configuration terminé, nous avons testé nos LEDs avec la fonction suivante : <syntaxhighlight lang="c"><br />
void blink_leds(void){<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
_delay_ms(200);<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
}<br />
</syntaxhighlight><br />
Ce qui nous donne ce résultat [[Fichier:Vidéo clignotement LEDs.mp4|center|vignette]]<br />
<br />
<br />
<br />
<br />
Nous avons également fait la fonction EtatLED dans le fichier USBFinal.c (fichier servant à détecter et communiquer avec la manette par le port USB) qui se trouve dans le dossier libUSB, qui sert à allumer ou éteindre la LED de son choix.<br />
<br />
Celle ci utilise le device, handle et configuration descriptor qui ont été définies dans des fonctions précédentes, disponible sur le git dans usbfinal.c ,grandement inspirées de ce qui est donné sur le site de Monsieur Redon, qui sélectionnent la manette et le config descriptor. On aurait dû également sélectionner l'interface dans cette fonction précédente plutôt que de le faire dans EtatLED mais nous nous en sommes rendus compte trop tard.<syntaxhighlight lang="c"><br />
void EtatLED(int etat, int numLED, libusb_device *manette, libusb_device_handle *handle, struct libusb_config_descriptor *configdesc)<br />
{<br />
int indint=0;/* e.g. première interface */<br />
int indalt=0; /* e.g. première alternative */<br />
int interface=1; //;configdesc->interface[indint].altsetting[indalt].bInterfaceNumber;<br />
int status=libusb_claim_interface(handle,interface);<br />
<br />
if(status!=0)<br />
{<br />
printf("bij\n");<br />
perror("libusb_claim_interface");<br />
exit(-1);<br />
}<br />
<br />
printf("Interface %d claimed\n",interface);<br />
<br />
unsigned char data = 0;<br />
if(etat){<br />
switch (numLED){<br />
case 1:<br />
data = 0x01;<br />
break;<br />
case 2:<br />
data = 0x02;<br />
break;<br />
case 3:<br />
data = 0x03;<br />
break;<br />
case 4:<br />
data = 0x04;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}else{<br />
switch (numLED){<br />
case 1:<br />
data = 0x11;<br />
break;<br />
case 2:<br />
data = 0x12;<br />
break;<br />
case 3:<br />
data = 0x13;<br />
break;<br />
case 4:<br />
data = 0x14;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}<br />
</syntaxhighlight><br />
Exemple d'appel dans le main <code>EtatLED(0,1, manette, handle, configdesc);</code>. La fonction va éteindre la LED 1.<br />
<br />
=== Boutons ===<br />
Les LEDs étant configuré il est temps de passer à l'utilisation des boutons. Le principe reste globalement le même, on modifie les fichiers descriptors et minimal selon nos besoins. Pour nous faciliter un peu la tâche nous avons pris les fichiers déjà existant pour des joysticks. Nous allons considérer que si un de nos boutons est appuyé cela reviendra au même que si un joystick est dirigée au maximum dans une direction donnée.<br />
<br />
<br />
La modification majeure à faire pour que nos boutons soit détecté était sur la fonction <syntaxhighlight lang="c"><br />
bool GetNextReport(USB_JoystickReport_Data_t* const ReportData)<br />
{<br />
static uint8_t PrevJoyStatus = 0;<br />
static uint8_t PrevButtonStatus = 0;<br />
bool InputChanged = false;<br />
<br />
/* Clear the report contents */<br />
memset(ReportData, 0, sizeof(USB_JoystickReport_Data_t));<br />
<br />
if(~(PIND>>PD4) & 1){<br />
ReportData->X = -100;<br />
}<br />
if(~(PIND>>PD7) & 1){<br />
ReportData->X = 100;<br />
}<br />
if(~(PIND>>PD6) & 1){<br />
ReportData->Y = -100;<br />
}<br />
if(~(PINB>>PB4) & 1){<br />
ReportData->Y = 100;<br />
}<br />
if(~(PINF>>PF7) & 1){<br />
ReportData->Button |= (1 << 0);<br />
}<br />
if(~(PINF>>PF6) & 1){<br />
ReportData->Button |= (1 << 1);<br />
}<br />
/* Return whether the new report is different to the previous report or not */<br />
return InputChanged;<br />
}<br />
</syntaxhighlight>Cela nous permet de dire que si un bouton que nous avons configuré est enfoncé, on met la direction X ou Y à plus ou moins 100. Nous les avons tester avec jstest-gtk qui permet de visualiser les directions et appuis d'un joystick, tous nos boutons sont reconnus et configurés comme nous le souhaitons.<br />
<br />
=== Regroupement des deux ===<br />
Pour avoir une manette fonctionnelle à 100% la dernière étape est de fusionner les différents fichiers pour les LEDs et pour les boutons pour que tout soit utilisable en même temps. Pour cela il a fallu modifié le fichier Descritors.c, dans la fonction<br />
<br />
<code>const USB_Descriptor_Configuration_t PROGMEM ConfigurationDescriptor</code>il faut indiquer le nombre d'interface à deux, puis rajouter une interface. Dans notre cas étant parti du fichier des boutons nous avons rajouté celle des LEDs. Une fois ceci fais, il ne restait plus qu'à rajouter les fonctions de chaque partie dans un même fichier .c et nous avons fini la configuration et la programmation de notre manette.<br />
<br />
== Implémentation dans le Space Invaders ==<br />
<br />
=== Ajout des boutons ===<br />
On va dans cette partie utiliser tout ce qui a été implémenté pour rendre la manette utilisable avec le jeu Space Invaders codé en parallèle. <br />
<br />
D'abord, on a, grâce au tutoriel fourni, ajouté l'utilisation des boutons avec la librairie SDL. Il nous a suffit de créer une fonction qui d'abord initialise notre manette en détectant le nombre de Joystick que celle ci possède. <br />
<br />
[[Fichier:JoystickInit.png|thumb|center|700px|Initialisation de la manette]] <br />
<br />
<br />
Ensuite, on a créé une fonction handleControllerReformed qui pendant que le jeu tourne vient récupérer les valeurs des axes et des boutons de la manette en utilisant le pointeur initialisé par JoystickInitialisation.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-21-04.png|thumb|center|700px|Fonction récupérant la valeur des axes et des boutons]]<br />
<br />
<p style="clear: both;" /><br />
<br />
Maintenant que nous avons les valeurs des boutons et des axes à chaque instant, nous pouvons les utiliser comme input dans nos programmes pour, par exemple, les déplacements du vaisseau et le lancer de missiles. La valeur des axes est toujours maximale car notre joystick est en fait 4 boutons interprétés comme un Joystick, c'est pour cela qu'on vient comparer leurs valeurs aux valeurs maximales envoyés par un Joystick (32767 et -32768). Les boutons sont des booléens qui retournent 1 quand ils sont à l'état bas et 0 à l'état haut.[[Fichier:Screenshot from 2024-06-10 22-21-55.png|thumb|left|700px|Fonction permettant de faire se déplacer le joueur au clavier ou à la manette]]<br />
[[Fichier:Screenshot from 2024-06-10 22-22-34.png|thumb|right|700px|Fonction permettant d'ajouter un missile si l'on appuie sur e ou sur un bouton.]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Vous pouvez voir le résultat de l'implémentation totale des boutons :<br />
[[Fichier:TestBoutons.mp4|thumb|center|700px]]<br />
<br />
<br />
<br />
<br />
=== Ajout des Diodes Électro-Luminescentes (la classe) ===<br />
<br />
<br />
Pour utiliser les LEDs, c'est légèrement plus compliqué. Le code que nous avions fait précédemment dans usbfinal.c, notamment EtatLED, va nous être utile. On va transformer ce fichier usbfinal.c en une librairie dynamique en .so. Grâce à ça, on va pouvoir réutiliser la fonction EtatLED dans notre programme pour le jeu et l'appeler directement dans des fonctions.<br />
<br />
Pour faire cela, on va compiler en utilisant des options particulières pour gcc. La commande est <code>gcc -fPIC -shared -o libusbfinal.so usbfinal.c -lusb-1.0</code>. L'option <code>-fPIC</code> permet de génerer du code indépendant de l'emplacement mémoire auquel il est chargé. L'option <code>-shared</code> permet de génerer une bibliotèque partager plutôt qu'un executable, et <code>-lusb-1.0</code> permet d'indiquer au compilateur qu'on utilise libusb 1.0 dans ce fichier C.<br />
<br />
On se retrouve alors avec un fichier .so disponible dans le git (dans les fichiers LUFA, répértoire libUSB, le chemin précis est spécifié dans le readme).<br />
<br />
Ce fichier est la bibliothèque dynamique qu'on peut appeler dans notre makefile.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-19-26.png|thumb|center|700px|Makefile pour le jeu, adapté à l'utilisation de la manette]]<br />
<br />
<br />
<br />
On voit qu'il faut rajouter dans l'éxecution la commande <code>export LD_LIBRARY_PATH=./src/include:$$LD_LIBRARY_PATH && ./$(TARGET) </code>(nécessaire pour indiquer l'emplacement des bibliothèques dynamiques), et éxecuter la commande sudo make run pour lancer le jeu (libusb nécessite d'avoir les droits administrateurs).<br />
<br />
On peut alors dans le fichier source C spaceinvaders ajouter le fichier d'en-tête associé à la librairie usbfinal.h également disponible dans le git, et utiliser toutes les fonctions crééés dans usbfinal.c. On a finalement créé une fonction displayLivesLEDs qui vient alumer le nombre de LEDs correspondant au nombre de vies restantes, qu'on appelle à chaque fois que le joueur est touché pour éviter des appels inutiles (tant que l'on ne fait rien, les LEDs gardent leur état).<br />
[[Fichier:Screenshot from 2024-06-10 22-18-12.png|thumb|center|500px|Fonction de gestion des LEDs]]<br />
<br />
Le résultat final avec implémentation des LEDs :<br />
<br />
[[Fichier:TestLEDs.mp4|thumb|center|700px]]<br />
<br />
<br />
<br />
On peut également vous fournir le .zip du jeu spaceinvaders avec l'implémentation de la manette si besoin (trop volumineux pour le wiki) en nous contactant par mail (remi.boursault@polytech-lille.net).<br />
<br />
== CONCLUSION ==<br />
On a fini.<br />
<br />
Plus sérieusement, la manette possède les fonctionnalités attendues. Les fichiers LUFA permettent de faire comprendre à un PC qu'elle est constitué d'un Joystick, de deux boutons et de 4 LEDs. On a également réussi à utiliser tous ces éléments dans notre jeu comme il était demandé.<br />
<br />
== GIT ==<br />
Vous pouvez consulter le [https://archives.plil.fr/rboursau/S6-manette.git dépôt Git] des projet. Celui-ci contient le fichier gerber de la manette crée sur KiCad. Les fichiers utilisé pour le programmateur AVR sont dans le dossier projet-info-manette/ProgrammateurAVR. Et les fichiers utilisé pour la manette sont eux dans le dossier projet-info-manette/fichier_lufa_libusb.</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:TestBoutons.mp4&diff=5978Fichier:TestBoutons.mp42024-06-15T14:12:19Z<p>Rboursau : </p>
<hr />
<div>dd</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3_PSE_Binome2023-5&diff=5977SE3 PSE Binome2023-52024-06-15T14:08:00Z<p>Rboursau : /* Ajout des Diodes Électro-Luminescentes (la classe) */</p>
<hr />
<div>= Projet système embarqué de Rémi BOURSAULT et Antoine LECOMTE =<br />
L'objectif de ce module est de modéliser une manette, puis de la rendre fonctionnelle, pour jouer au jeu Space Invaders qui est codé dans le même module.<br />
<br />
Les professeurs avaient préalablement fourni un dossier contenant un modèle de PCB incomplet et différents fichiers ".c" et ".h" pour nous aider à démarrer. <br />
<br />
== Création de Manette ==<br />
La création de la manette commence par la création sur kicad d'un PCB. Nous avons pris celui fourni sur le wiki du projet qui possède tous les composants mais non routés. <br />
<br />
<br />
<br />
<br />
<br />
== Modélisation PCB ==<br />
A partir du fichier KiCad fourni, nous avons modélisé un PCB déstiné à être utilisé comme manette. Nous avons donc ajouté des boutons, replacé ces derniers. Grâce au schéma nous avons sélectionné des PIN pour connecter les boutons, ainsi que des LEDs et des résistances que nous avons aussi ajouté. <br />
<br />
Voyant que nous avions encore de l'espace de libre sur notre carte, étant un peu ambitieux et voyant que le procédé n'est pas bien compliqué, nous décidons alors de rajouter quelque boutons et quelques LEDs en plus pour que notre manette soit un peu plus crédibles. <br />
<br />
Il nous a alors fallu rajouté les dit composants sur notre schéma pour que ceux-ci soient rajoutés automatiquement sur le PCB lors de l'utilisation de la fonction "Update PCB with changes made to schematic" <br />
<br />
<br />
<gallery><br />
File:Image boutons.png|Schéma des boutons<br />
File:Connecteur ISP.png|Schéma du connecteur ISP<br />
File:Schéma des LEDs.png|Schéma des LEDs<br />
File:Connecteur USB.png|Schéma du connecteur USB<br />
File:Microcontroleur.png|Schéma du microcontrôleur<br />
</gallery><br />
<br />
<br />
[[Fichier:Plan pcb.jpg|thumb|center|500px| Ajout du plan de masse et des via]]<br />
<br />
<br />
<br />
Une fois le routage effectué, nous avons ajouté un plan de masse et ajouté une grande quantité de via à différent endroits de la carte pour que la masse soit bien connectée et éviter les fuites thermiques de certains composants. <br />
<br />
Ensuite le fichier a été envoyé pour impression en Chine, grâce au fichier Gerber généré par KiCad que vous pouvez retrouvez sur notre GIT:<br />
<br />
<br />
[[Fichier:Vue3d.jpg|thumb|center|500px| Rendu 3D final de la carte]]<br />
<br />
== Programmateur AVR ==<br />
En attendant de recevoir les cartes, nous nous sommes initiés à la programmation d'un périphérique USB, nous avons utilisé les bibliothèques LUFA et LibUSB pour utilisé un programmateur AVR. Il nous a fallu également modifier des fichiers Descripteurs, en ".c" et ".h" qui permettent, une fois téléversés dans le programmateur, d'être détecter par le PC et que celui-ci reconnaisse les fonctionnalités du périphérique (InPoint et EndPoint). <br />
<br />
<br />
== Soudure de la carte ==<br />
Une fois la carte reçu, nous avons pris tous nos composants et avons commencé à les souder. N'ayant que très peu d'expérience dans ce domaine ce n'était pas quelque chose de facile au début. Il nous a fallu un peu d'aide et pas mal de flux pour comprendre comment faire des soudures propres. Une fois le coup de main pris, la fin du montage de la carte était assez rapide. Nous avons donc pu passer à la programmation pour la reconnaissance par l'ordinateur de notre carte.<br />
[[Fichier:Carte vierge.jpg|thumb|left|500px| Carte vierge]]<br />
<br />
[[Fichier:Carte soudée manette.jpg|thumb|center|500px| Carte avec tous les composants soudés]]<br />
<br />
<br />
<br />
Une fois la carte soudée il a fallu pouvoir la configurer pour par la suite pouvoir la programmer. Pour se faire il faut lui injecter un bootloader via son programmateur ISP. Ce qui passe la manette en mode DFU et elle est alors reconnu par l'ordinateur.<br />
[[Fichier:Manette reconnu en mode dfu.png|thumb|center|500px| Manette reconnu en mode DFU]]<br />
<br />
== LUFA de la manette ==<br />
Après avoir reçu les cartes et terminé de souder les composants nous avons pu attaquer la programmation du microcontrôleur pour pouvoir utiliser la manette. Nous avons procédés étape par étape, en commençant par allumé les LEDs puis réceptionner les signaux des boutons pour finir par fusionner les deux pour avoir une manette fonctionnelle.<br />
<br />
=== LEDs ===<br />
Pour éviter un décalage sur le portF il faut désactiver le JTAG en copiant deux fois cette ligne au niveau de la déclaration des pins : <code>MCUCR |= (1<<JTD);</code>cela permet d'accéder aux LEDs sur les pins PF4 et PF5.<br />
Une fois la configuration terminé, nous avons testé nos LEDs avec la fonction suivante : <syntaxhighlight lang="c"><br />
void blink_leds(void){<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
_delay_ms(200);<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
}<br />
</syntaxhighlight><br />
Ce qui nous donne ce résultat [[Fichier:Vidéo clignotement LEDs.mp4|center|vignette]]<br />
<br />
<br />
<br />
<br />
Nous avons également fait la fonction EtatLED dans le fichier USBFinal.c (fichier servant à détecter et communiquer avec la manette par le port USB) qui se trouve dans le dossier libUSB, qui sert à allumer ou éteindre la LED de son choix.<br />
<br />
Celle ci utilise le device, handle et configuration descriptor qui ont été définies dans des fonctions précédentes, disponible sur le git dans usbfinal.c ,grandement inspirées de ce qui est donné sur le site de Monsieur Redon, qui sélectionnent la manette et le config descriptor. On aurait dû également sélectionner l'interface dans cette fonction précédente plutôt que de le faire dans EtatLED mais nous nous en sommes rendus compte trop tard.<syntaxhighlight lang="c"><br />
void EtatLED(int etat, int numLED, libusb_device *manette, libusb_device_handle *handle, struct libusb_config_descriptor *configdesc)<br />
{<br />
int indint=0;/* e.g. première interface */<br />
int indalt=0; /* e.g. première alternative */<br />
int interface=1; //;configdesc->interface[indint].altsetting[indalt].bInterfaceNumber;<br />
int status=libusb_claim_interface(handle,interface);<br />
<br />
if(status!=0)<br />
{<br />
printf("bij\n");<br />
perror("libusb_claim_interface");<br />
exit(-1);<br />
}<br />
<br />
printf("Interface %d claimed\n",interface);<br />
<br />
unsigned char data = 0;<br />
if(etat){<br />
switch (numLED){<br />
case 1:<br />
data = 0x01;<br />
break;<br />
case 2:<br />
data = 0x02;<br />
break;<br />
case 3:<br />
data = 0x03;<br />
break;<br />
case 4:<br />
data = 0x04;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}else{<br />
switch (numLED){<br />
case 1:<br />
data = 0x11;<br />
break;<br />
case 2:<br />
data = 0x12;<br />
break;<br />
case 3:<br />
data = 0x13;<br />
break;<br />
case 4:<br />
data = 0x14;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}<br />
</syntaxhighlight><br />
Exemple d'appel dans le main <code>EtatLED(0,1, manette, handle, configdesc);</code>. La fonction va éteindre la LED 1.<br />
<br />
=== Boutons ===<br />
Les LEDs étant configuré il est temps de passer à l'utilisation des boutons. Le principe reste globalement le même, on modifie les fichiers descriptors et minimal selon nos besoins. Pour nous faciliter un peu la tâche nous avons pris les fichiers déjà existant pour des joysticks. Nous allons considérer que si un de nos boutons est appuyé cela reviendra au même que si un joystick est dirigée au maximum dans une direction donnée.<br />
<br />
<br />
La modification majeure à faire pour que nos boutons soit détecté était sur la fonction <syntaxhighlight lang="c"><br />
bool GetNextReport(USB_JoystickReport_Data_t* const ReportData)<br />
{<br />
static uint8_t PrevJoyStatus = 0;<br />
static uint8_t PrevButtonStatus = 0;<br />
bool InputChanged = false;<br />
<br />
/* Clear the report contents */<br />
memset(ReportData, 0, sizeof(USB_JoystickReport_Data_t));<br />
<br />
if(~(PIND>>PD4) & 1){<br />
ReportData->X = -100;<br />
}<br />
if(~(PIND>>PD7) & 1){<br />
ReportData->X = 100;<br />
}<br />
if(~(PIND>>PD6) & 1){<br />
ReportData->Y = -100;<br />
}<br />
if(~(PINB>>PB4) & 1){<br />
ReportData->Y = 100;<br />
}<br />
if(~(PINF>>PF7) & 1){<br />
ReportData->Button |= (1 << 0);<br />
}<br />
if(~(PINF>>PF6) & 1){<br />
ReportData->Button |= (1 << 1);<br />
}<br />
/* Return whether the new report is different to the previous report or not */<br />
return InputChanged;<br />
}<br />
</syntaxhighlight>Cela nous permet de dire que si un bouton que nous avons configuré est enfoncé, on met la direction X ou Y à plus ou moins 100. Nous les avons tester avec jstest-gtk qui permet de visualiser les directions et appuis d'un joystick, tous nos boutons sont reconnus et configurés comme nous le souhaitons.<br />
<br />
=== Regroupement des deux ===<br />
Pour avoir une manette fonctionnelle à 100% la dernière étape est de fusionner les différents fichiers pour les LEDs et pour les boutons pour que tout soit utilisable en même temps. Pour cela il a fallu modifié le fichier Descritors.c, dans la fonction<br />
<br />
<code>const USB_Descriptor_Configuration_t PROGMEM ConfigurationDescriptor</code>il faut indiquer le nombre d'interface à deux, puis rajouter une interface. Dans notre cas étant parti du fichier des boutons nous avons rajouté celle des LEDs. Une fois ceci fais, il ne restait plus qu'à rajouter les fonctions de chaque partie dans un même fichier .c et nous avons fini la configuration et la programmation de notre manette.<br />
<br />
== Implémentation dans le Space Invaders ==<br />
<br />
=== Ajout des boutons ===<br />
On va dans cette partie utiliser tout ce qui a été implémenté pour rendre la manette utilisable avec le jeu Space Invaders codé en parallèle. <br />
<br />
D'abord, on a, grâce au tutoriel fourni, ajouté l'utilisation des boutons avec la librairie SDL. Il nous a suffit de créer une fonction qui d'abord initialise notre manette en détectant le nombre de Joystick que celle ci possède. <br />
<br />
[[Fichier:JoystickInit.png|thumb|center|700px|Initialisation de la manette]] <br />
<br />
<br />
Ensuite, on a créé une fonction handleControllerReformed qui pendant que le jeu tourne vient récupérer les valeurs des axes et des boutons de la manette en utilisant le pointeur initialisé par JoystickInitialisation.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-21-04.png|thumb|center|700px|Fonction récupérant la valeur des axes et des boutons]]<br />
<br />
<p style="clear: both;" /><br />
<br />
Maintenant que nous avons les valeurs des boutons et des axes à chaque instant, nous pouvons les utiliser comme input dans nos programmes pour, par exemple, les déplacements du vaisseau et le lancer de missiles. La valeur des axes est toujours maximale car notre joystick est en fait 4 boutons interprétés comme un Joystick, c'est pour cela qu'on vient comparer leurs valeurs aux valeurs maximales envoyés par un Joystick (32767 et -32768). Les boutons sont des booléens qui retournent 1 quand ils sont à l'état bas et 0 à l'état haut.[[Fichier:Screenshot from 2024-06-10 22-21-55.png|thumb|left|700px|Fonction permettant de faire se déplacer le joueur au clavier ou à la manette]]<br />
[[Fichier:Screenshot from 2024-06-10 22-22-34.png|thumb|right|700px|Fonction permettant d'ajouter un missile si l'on appuie sur e ou sur un bouton.]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Vous pouvez voir le résultat de l'implémentation totale des boutons en cliquant [https://www.youtube.com/watch?v=TwVJ7-ZU8_8&ab_channel=R%C3%A9mi sur ce lien].<br />
<br />
=== Ajout des Diodes Électro-Luminescentes (la classe) ===<br />
<br />
<br />
Pour utiliser les LEDs, c'est légèrement plus compliqué. Le code que nous avions fait précédemment dans usbfinal.c, notamment EtatLED, va nous être utile. On va transformer ce fichier usbfinal.c en une librairie dynamique en .so. Grâce à ça, on va pouvoir réutiliser la fonction EtatLED dans notre programme pour le jeu et l'appeler directement dans des fonctions.<br />
<br />
Pour faire cela, on va compiler en utilisant des options particulières pour gcc. La commande est <code>gcc -fPIC -shared -o libusbfinal.so usbfinal.c -lusb-1.0</code>. L'option <code>-fPIC</code> permet de génerer du code indépendant de l'emplacement mémoire auquel il est chargé. L'option <code>-shared</code> permet de génerer une bibliotèque partager plutôt qu'un executable, et <code>-lusb-1.0</code> permet d'indiquer au compilateur qu'on utilise libusb 1.0 dans ce fichier C.<br />
<br />
On se retrouve alors avec un fichier .so disponible dans le git (dans les fichiers LUFA, répértoire libUSB, le chemin précis est spécifié dans le readme).<br />
<br />
Ce fichier est la bibliothèque dynamique qu'on peut appeler dans notre makefile.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-19-26.png|thumb|center|700px|Makefile pour le jeu, adapté à l'utilisation de la manette]]<br />
<br />
<br />
<br />
On voit qu'il faut rajouter dans l'éxecution la commande <code>export LD_LIBRARY_PATH=./src/include:$$LD_LIBRARY_PATH && ./$(TARGET) </code>(nécessaire pour indiquer l'emplacement des bibliothèques dynamiques), et éxecuter la commande sudo make run pour lancer le jeu (libusb nécessite d'avoir les droits administrateurs).<br />
<br />
On peut alors dans le fichier source C spaceinvaders ajouter le fichier d'en-tête associé à la librairie usbfinal.h également disponible dans le git, et utiliser toutes les fonctions crééés dans usbfinal.c. On a finalement créé une fonction displayLivesLEDs qui vient alumer le nombre de LEDs correspondant au nombre de vies restantes, qu'on appelle à chaque fois que le joueur est touché pour éviter des appels inutiles (tant que l'on ne fait rien, les LEDs gardent leur état).<br />
[[Fichier:Screenshot from 2024-06-10 22-18-12.png|thumb|center|500px|Fonction de gestion des LEDs]]<br />
<br />
Le résultat final avec implémentation des LEDs :<br />
<br />
[[Fichier:TestLEDs.mp4|thumb|center|700px]]<br />
<br />
<br />
<br />
On peut également vous fournir le .zip du jeu spaceinvaders avec l'implémentation de la manette si besoin (trop volumineux pour le wiki) en nous contactant par mail (remi.boursault@polytech-lille.net).<br />
<br />
== CONCLUSION ==<br />
On a fini.<br />
<br />
Plus sérieusement, la manette possède les fonctionnalités attendues. Les fichiers LUFA permettent de faire comprendre à un PC qu'elle est constitué d'un Joystick, de deux boutons et de 4 LEDs. On a également réussi à utiliser tous ces éléments dans notre jeu comme il était demandé.<br />
<br />
== GIT ==<br />
Vous pouvez consulter le [https://archives.plil.fr/rboursau/S6-manette.git dépôt Git] des projet. Celui-ci contient le fichier gerber de la manette crée sur KiCad. Les fichiers utilisé pour le programmateur AVR sont dans le dossier projet-info-manette/ProgrammateurAVR. Et les fichiers utilisé pour la manette sont eux dans le dossier projet-info-manette/fichier_lufa_libusb.</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3_PSE_Binome2023-5&diff=5976SE3 PSE Binome2023-52024-06-15T14:07:43Z<p>Rboursau : /* Ajout des Diodes Électro-Luminescentes (la classe) */</p>
<hr />
<div>= Projet système embarqué de Rémi BOURSAULT et Antoine LECOMTE =<br />
L'objectif de ce module est de modéliser une manette, puis de la rendre fonctionnelle, pour jouer au jeu Space Invaders qui est codé dans le même module.<br />
<br />
Les professeurs avaient préalablement fourni un dossier contenant un modèle de PCB incomplet et différents fichiers ".c" et ".h" pour nous aider à démarrer. <br />
<br />
== Création de Manette ==<br />
La création de la manette commence par la création sur kicad d'un PCB. Nous avons pris celui fourni sur le wiki du projet qui possède tous les composants mais non routés. <br />
<br />
<br />
<br />
<br />
<br />
== Modélisation PCB ==<br />
A partir du fichier KiCad fourni, nous avons modélisé un PCB déstiné à être utilisé comme manette. Nous avons donc ajouté des boutons, replacé ces derniers. Grâce au schéma nous avons sélectionné des PIN pour connecter les boutons, ainsi que des LEDs et des résistances que nous avons aussi ajouté. <br />
<br />
Voyant que nous avions encore de l'espace de libre sur notre carte, étant un peu ambitieux et voyant que le procédé n'est pas bien compliqué, nous décidons alors de rajouter quelque boutons et quelques LEDs en plus pour que notre manette soit un peu plus crédibles. <br />
<br />
Il nous a alors fallu rajouté les dit composants sur notre schéma pour que ceux-ci soient rajoutés automatiquement sur le PCB lors de l'utilisation de la fonction "Update PCB with changes made to schematic" <br />
<br />
<br />
<gallery><br />
File:Image boutons.png|Schéma des boutons<br />
File:Connecteur ISP.png|Schéma du connecteur ISP<br />
File:Schéma des LEDs.png|Schéma des LEDs<br />
File:Connecteur USB.png|Schéma du connecteur USB<br />
File:Microcontroleur.png|Schéma du microcontrôleur<br />
</gallery><br />
<br />
<br />
[[Fichier:Plan pcb.jpg|thumb|center|500px| Ajout du plan de masse et des via]]<br />
<br />
<br />
<br />
Une fois le routage effectué, nous avons ajouté un plan de masse et ajouté une grande quantité de via à différent endroits de la carte pour que la masse soit bien connectée et éviter les fuites thermiques de certains composants. <br />
<br />
Ensuite le fichier a été envoyé pour impression en Chine, grâce au fichier Gerber généré par KiCad que vous pouvez retrouvez sur notre GIT:<br />
<br />
<br />
[[Fichier:Vue3d.jpg|thumb|center|500px| Rendu 3D final de la carte]]<br />
<br />
== Programmateur AVR ==<br />
En attendant de recevoir les cartes, nous nous sommes initiés à la programmation d'un périphérique USB, nous avons utilisé les bibliothèques LUFA et LibUSB pour utilisé un programmateur AVR. Il nous a fallu également modifier des fichiers Descripteurs, en ".c" et ".h" qui permettent, une fois téléversés dans le programmateur, d'être détecter par le PC et que celui-ci reconnaisse les fonctionnalités du périphérique (InPoint et EndPoint). <br />
<br />
<br />
== Soudure de la carte ==<br />
Une fois la carte reçu, nous avons pris tous nos composants et avons commencé à les souder. N'ayant que très peu d'expérience dans ce domaine ce n'était pas quelque chose de facile au début. Il nous a fallu un peu d'aide et pas mal de flux pour comprendre comment faire des soudures propres. Une fois le coup de main pris, la fin du montage de la carte était assez rapide. Nous avons donc pu passer à la programmation pour la reconnaissance par l'ordinateur de notre carte.<br />
[[Fichier:Carte vierge.jpg|thumb|left|500px| Carte vierge]]<br />
<br />
[[Fichier:Carte soudée manette.jpg|thumb|center|500px| Carte avec tous les composants soudés]]<br />
<br />
<br />
<br />
Une fois la carte soudée il a fallu pouvoir la configurer pour par la suite pouvoir la programmer. Pour se faire il faut lui injecter un bootloader via son programmateur ISP. Ce qui passe la manette en mode DFU et elle est alors reconnu par l'ordinateur.<br />
[[Fichier:Manette reconnu en mode dfu.png|thumb|center|500px| Manette reconnu en mode DFU]]<br />
<br />
== LUFA de la manette ==<br />
Après avoir reçu les cartes et terminé de souder les composants nous avons pu attaquer la programmation du microcontrôleur pour pouvoir utiliser la manette. Nous avons procédés étape par étape, en commençant par allumé les LEDs puis réceptionner les signaux des boutons pour finir par fusionner les deux pour avoir une manette fonctionnelle.<br />
<br />
=== LEDs ===<br />
Pour éviter un décalage sur le portF il faut désactiver le JTAG en copiant deux fois cette ligne au niveau de la déclaration des pins : <code>MCUCR |= (1<<JTD);</code>cela permet d'accéder aux LEDs sur les pins PF4 et PF5.<br />
Une fois la configuration terminé, nous avons testé nos LEDs avec la fonction suivante : <syntaxhighlight lang="c"><br />
void blink_leds(void){<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
_delay_ms(200);<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
}<br />
</syntaxhighlight><br />
Ce qui nous donne ce résultat [[Fichier:Vidéo clignotement LEDs.mp4|center|vignette]]<br />
<br />
<br />
<br />
<br />
Nous avons également fait la fonction EtatLED dans le fichier USBFinal.c (fichier servant à détecter et communiquer avec la manette par le port USB) qui se trouve dans le dossier libUSB, qui sert à allumer ou éteindre la LED de son choix.<br />
<br />
Celle ci utilise le device, handle et configuration descriptor qui ont été définies dans des fonctions précédentes, disponible sur le git dans usbfinal.c ,grandement inspirées de ce qui est donné sur le site de Monsieur Redon, qui sélectionnent la manette et le config descriptor. On aurait dû également sélectionner l'interface dans cette fonction précédente plutôt que de le faire dans EtatLED mais nous nous en sommes rendus compte trop tard.<syntaxhighlight lang="c"><br />
void EtatLED(int etat, int numLED, libusb_device *manette, libusb_device_handle *handle, struct libusb_config_descriptor *configdesc)<br />
{<br />
int indint=0;/* e.g. première interface */<br />
int indalt=0; /* e.g. première alternative */<br />
int interface=1; //;configdesc->interface[indint].altsetting[indalt].bInterfaceNumber;<br />
int status=libusb_claim_interface(handle,interface);<br />
<br />
if(status!=0)<br />
{<br />
printf("bij\n");<br />
perror("libusb_claim_interface");<br />
exit(-1);<br />
}<br />
<br />
printf("Interface %d claimed\n",interface);<br />
<br />
unsigned char data = 0;<br />
if(etat){<br />
switch (numLED){<br />
case 1:<br />
data = 0x01;<br />
break;<br />
case 2:<br />
data = 0x02;<br />
break;<br />
case 3:<br />
data = 0x03;<br />
break;<br />
case 4:<br />
data = 0x04;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}else{<br />
switch (numLED){<br />
case 1:<br />
data = 0x11;<br />
break;<br />
case 2:<br />
data = 0x12;<br />
break;<br />
case 3:<br />
data = 0x13;<br />
break;<br />
case 4:<br />
data = 0x14;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}<br />
</syntaxhighlight><br />
Exemple d'appel dans le main <code>EtatLED(0,1, manette, handle, configdesc);</code>. La fonction va éteindre la LED 1.<br />
<br />
=== Boutons ===<br />
Les LEDs étant configuré il est temps de passer à l'utilisation des boutons. Le principe reste globalement le même, on modifie les fichiers descriptors et minimal selon nos besoins. Pour nous faciliter un peu la tâche nous avons pris les fichiers déjà existant pour des joysticks. Nous allons considérer que si un de nos boutons est appuyé cela reviendra au même que si un joystick est dirigée au maximum dans une direction donnée.<br />
<br />
<br />
La modification majeure à faire pour que nos boutons soit détecté était sur la fonction <syntaxhighlight lang="c"><br />
bool GetNextReport(USB_JoystickReport_Data_t* const ReportData)<br />
{<br />
static uint8_t PrevJoyStatus = 0;<br />
static uint8_t PrevButtonStatus = 0;<br />
bool InputChanged = false;<br />
<br />
/* Clear the report contents */<br />
memset(ReportData, 0, sizeof(USB_JoystickReport_Data_t));<br />
<br />
if(~(PIND>>PD4) & 1){<br />
ReportData->X = -100;<br />
}<br />
if(~(PIND>>PD7) & 1){<br />
ReportData->X = 100;<br />
}<br />
if(~(PIND>>PD6) & 1){<br />
ReportData->Y = -100;<br />
}<br />
if(~(PINB>>PB4) & 1){<br />
ReportData->Y = 100;<br />
}<br />
if(~(PINF>>PF7) & 1){<br />
ReportData->Button |= (1 << 0);<br />
}<br />
if(~(PINF>>PF6) & 1){<br />
ReportData->Button |= (1 << 1);<br />
}<br />
/* Return whether the new report is different to the previous report or not */<br />
return InputChanged;<br />
}<br />
</syntaxhighlight>Cela nous permet de dire que si un bouton que nous avons configuré est enfoncé, on met la direction X ou Y à plus ou moins 100. Nous les avons tester avec jstest-gtk qui permet de visualiser les directions et appuis d'un joystick, tous nos boutons sont reconnus et configurés comme nous le souhaitons.<br />
<br />
=== Regroupement des deux ===<br />
Pour avoir une manette fonctionnelle à 100% la dernière étape est de fusionner les différents fichiers pour les LEDs et pour les boutons pour que tout soit utilisable en même temps. Pour cela il a fallu modifié le fichier Descritors.c, dans la fonction<br />
<br />
<code>const USB_Descriptor_Configuration_t PROGMEM ConfigurationDescriptor</code>il faut indiquer le nombre d'interface à deux, puis rajouter une interface. Dans notre cas étant parti du fichier des boutons nous avons rajouté celle des LEDs. Une fois ceci fais, il ne restait plus qu'à rajouter les fonctions de chaque partie dans un même fichier .c et nous avons fini la configuration et la programmation de notre manette.<br />
<br />
== Implémentation dans le Space Invaders ==<br />
<br />
=== Ajout des boutons ===<br />
On va dans cette partie utiliser tout ce qui a été implémenté pour rendre la manette utilisable avec le jeu Space Invaders codé en parallèle. <br />
<br />
D'abord, on a, grâce au tutoriel fourni, ajouté l'utilisation des boutons avec la librairie SDL. Il nous a suffit de créer une fonction qui d'abord initialise notre manette en détectant le nombre de Joystick que celle ci possède. <br />
<br />
[[Fichier:JoystickInit.png|thumb|center|700px|Initialisation de la manette]] <br />
<br />
<br />
Ensuite, on a créé une fonction handleControllerReformed qui pendant que le jeu tourne vient récupérer les valeurs des axes et des boutons de la manette en utilisant le pointeur initialisé par JoystickInitialisation.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-21-04.png|thumb|center|700px|Fonction récupérant la valeur des axes et des boutons]]<br />
<br />
<p style="clear: both;" /><br />
<br />
Maintenant que nous avons les valeurs des boutons et des axes à chaque instant, nous pouvons les utiliser comme input dans nos programmes pour, par exemple, les déplacements du vaisseau et le lancer de missiles. La valeur des axes est toujours maximale car notre joystick est en fait 4 boutons interprétés comme un Joystick, c'est pour cela qu'on vient comparer leurs valeurs aux valeurs maximales envoyés par un Joystick (32767 et -32768). Les boutons sont des booléens qui retournent 1 quand ils sont à l'état bas et 0 à l'état haut.[[Fichier:Screenshot from 2024-06-10 22-21-55.png|thumb|left|700px|Fonction permettant de faire se déplacer le joueur au clavier ou à la manette]]<br />
[[Fichier:Screenshot from 2024-06-10 22-22-34.png|thumb|right|700px|Fonction permettant d'ajouter un missile si l'on appuie sur e ou sur un bouton.]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Vous pouvez voir le résultat de l'implémentation totale des boutons en cliquant [https://www.youtube.com/watch?v=TwVJ7-ZU8_8&ab_channel=R%C3%A9mi sur ce lien].<br />
<br />
=== Ajout des Diodes Électro-Luminescentes (la classe) ===<br />
<br />
<br />
Pour utiliser les LEDs, c'est légèrement plus compliqué. Le code que nous avions fait précédemment dans usbfinal.c, notamment EtatLED, va nous être utile. On va transformer ce fichier usbfinal.c en une librairie dynamique en .so. Grâce à ça, on va pouvoir réutiliser la fonction EtatLED dans notre programme pour le jeu et l'appeler directement dans des fonctions.<br />
<br />
Pour faire cela, on va compiler en utilisant des options particulières pour gcc. La commande est <code>gcc -fPIC -shared -o libusbfinal.so usbfinal.c -lusb-1.0</code>. L'option <code>-fPIC</code> permet de génerer du code indépendant de l'emplacement mémoire auquel il est chargé. L'option <code>-shared</code> permet de génerer une bibliotèque partager plutôt qu'un executable, et <code>-lusb-1.0</code> permet d'indiquer au compilateur qu'on utilise libusb 1.0 dans ce fichier C.<br />
<br />
On se retrouve alors avec un fichier .so disponible dans le git (dans les fichiers LUFA, répértoire libUSB, le chemin précis est spécifié dans le readme).<br />
<br />
Ce fichier est la bibliothèque dynamique qu'on peut appeler dans notre makefile.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-19-26.png|thumb|center|700px|Makefile pour le jeu, adapté à l'utilisation de la manette]]<br />
<br />
<br />
<br />
On voit qu'il faut rajouter dans l'éxecution la commande <code>export LD_LIBRARY_PATH=./src/include:$$LD_LIBRARY_PATH && ./$(TARGET) </code>(nécessaire pour indiquer l'emplacement des bibliothèques dynamiques), et éxecuter la commande sudo make run pour lancer le jeu (libusb nécessite d'avoir les droits administrateurs).<br />
<br />
On peut alors dans le fichier source C spaceinvaders ajouter le fichier d'en-tête associé à la librairie usbfinal.h également disponible dans le git, et utiliser toutes les fonctions crééés dans usbfinal.c. On a finalement créé une fonction displayLivesLEDs qui vient alumer le nombre de LEDs correspondant au nombre de vies restantes, qu'on appelle à chaque fois que le joueur est touché pour éviter des appels inutiles (tant que l'on ne fait rien, les LEDs gardent leur état).<br />
[[Fichier:Screenshot from 2024-06-10 22-18-12.png|thumb|center|500px|Fonction de gestion des LEDs]]<br />
<br />
Le résultat final avec implémentation des LEDs :<br />
<br />
[[Fichier:TestLEDs.mp4|thumb|center|700px]]<br />
<br />
<br />
<br />
On peut également vous fournir le .zip du jeu spaceinvaders avec l'implémentation de la manette si besoin (trop volumineux pour le wiki) en nous contactant par mail (remi.boursault@polytech-lille.net).<br />
<br />
== CONCLUSION ==<br />
On a fini.<br />
<br />
Plus sérieusement, la manette possède les fonctionnalités attendues. Les fichiers LUFA permettent de faire comprendre à un PC qu'elle est constitué d'un Joystick, de deux boutons et de 4 LEDs. On a également réussi à utiliser tous ces éléments dans notre jeu comme il était demandé.<br />
<br />
== GIT ==<br />
Vous pouvez consulter le [https://archives.plil.fr/rboursau/S6-manette.git dépôt Git] des projet. Celui-ci contient le fichier gerber de la manette crée sur KiCad. Les fichiers utilisé pour le programmateur AVR sont dans le dossier projet-info-manette/ProgrammateurAVR. Et les fichiers utilisé pour la manette sont eux dans le dossier projet-info-manette/fichier_lufa_libusb.</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3_PSE_Binome2023-5&diff=5975SE3 PSE Binome2023-52024-06-15T14:07:22Z<p>Rboursau : </p>
<hr />
<div>= Projet système embarqué de Rémi BOURSAULT et Antoine LECOMTE =<br />
L'objectif de ce module est de modéliser une manette, puis de la rendre fonctionnelle, pour jouer au jeu Space Invaders qui est codé dans le même module.<br />
<br />
Les professeurs avaient préalablement fourni un dossier contenant un modèle de PCB incomplet et différents fichiers ".c" et ".h" pour nous aider à démarrer. <br />
<br />
== Création de Manette ==<br />
La création de la manette commence par la création sur kicad d'un PCB. Nous avons pris celui fourni sur le wiki du projet qui possède tous les composants mais non routés. <br />
<br />
<br />
<br />
<br />
<br />
== Modélisation PCB ==<br />
A partir du fichier KiCad fourni, nous avons modélisé un PCB déstiné à être utilisé comme manette. Nous avons donc ajouté des boutons, replacé ces derniers. Grâce au schéma nous avons sélectionné des PIN pour connecter les boutons, ainsi que des LEDs et des résistances que nous avons aussi ajouté. <br />
<br />
Voyant que nous avions encore de l'espace de libre sur notre carte, étant un peu ambitieux et voyant que le procédé n'est pas bien compliqué, nous décidons alors de rajouter quelque boutons et quelques LEDs en plus pour que notre manette soit un peu plus crédibles. <br />
<br />
Il nous a alors fallu rajouté les dit composants sur notre schéma pour que ceux-ci soient rajoutés automatiquement sur le PCB lors de l'utilisation de la fonction "Update PCB with changes made to schematic" <br />
<br />
<br />
<gallery><br />
File:Image boutons.png|Schéma des boutons<br />
File:Connecteur ISP.png|Schéma du connecteur ISP<br />
File:Schéma des LEDs.png|Schéma des LEDs<br />
File:Connecteur USB.png|Schéma du connecteur USB<br />
File:Microcontroleur.png|Schéma du microcontrôleur<br />
</gallery><br />
<br />
<br />
[[Fichier:Plan pcb.jpg|thumb|center|500px| Ajout du plan de masse et des via]]<br />
<br />
<br />
<br />
Une fois le routage effectué, nous avons ajouté un plan de masse et ajouté une grande quantité de via à différent endroits de la carte pour que la masse soit bien connectée et éviter les fuites thermiques de certains composants. <br />
<br />
Ensuite le fichier a été envoyé pour impression en Chine, grâce au fichier Gerber généré par KiCad que vous pouvez retrouvez sur notre GIT:<br />
<br />
<br />
[[Fichier:Vue3d.jpg|thumb|center|500px| Rendu 3D final de la carte]]<br />
<br />
== Programmateur AVR ==<br />
En attendant de recevoir les cartes, nous nous sommes initiés à la programmation d'un périphérique USB, nous avons utilisé les bibliothèques LUFA et LibUSB pour utilisé un programmateur AVR. Il nous a fallu également modifier des fichiers Descripteurs, en ".c" et ".h" qui permettent, une fois téléversés dans le programmateur, d'être détecter par le PC et que celui-ci reconnaisse les fonctionnalités du périphérique (InPoint et EndPoint). <br />
<br />
<br />
== Soudure de la carte ==<br />
Une fois la carte reçu, nous avons pris tous nos composants et avons commencé à les souder. N'ayant que très peu d'expérience dans ce domaine ce n'était pas quelque chose de facile au début. Il nous a fallu un peu d'aide et pas mal de flux pour comprendre comment faire des soudures propres. Une fois le coup de main pris, la fin du montage de la carte était assez rapide. Nous avons donc pu passer à la programmation pour la reconnaissance par l'ordinateur de notre carte.<br />
[[Fichier:Carte vierge.jpg|thumb|left|500px| Carte vierge]]<br />
<br />
[[Fichier:Carte soudée manette.jpg|thumb|center|500px| Carte avec tous les composants soudés]]<br />
<br />
<br />
<br />
Une fois la carte soudée il a fallu pouvoir la configurer pour par la suite pouvoir la programmer. Pour se faire il faut lui injecter un bootloader via son programmateur ISP. Ce qui passe la manette en mode DFU et elle est alors reconnu par l'ordinateur.<br />
[[Fichier:Manette reconnu en mode dfu.png|thumb|center|500px| Manette reconnu en mode DFU]]<br />
<br />
== LUFA de la manette ==<br />
Après avoir reçu les cartes et terminé de souder les composants nous avons pu attaquer la programmation du microcontrôleur pour pouvoir utiliser la manette. Nous avons procédés étape par étape, en commençant par allumé les LEDs puis réceptionner les signaux des boutons pour finir par fusionner les deux pour avoir une manette fonctionnelle.<br />
<br />
=== LEDs ===<br />
Pour éviter un décalage sur le portF il faut désactiver le JTAG en copiant deux fois cette ligne au niveau de la déclaration des pins : <code>MCUCR |= (1<<JTD);</code>cela permet d'accéder aux LEDs sur les pins PF4 et PF5.<br />
Une fois la configuration terminé, nous avons testé nos LEDs avec la fonction suivante : <syntaxhighlight lang="c"><br />
void blink_leds(void){<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
_delay_ms(200);<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
}<br />
</syntaxhighlight><br />
Ce qui nous donne ce résultat [[Fichier:Vidéo clignotement LEDs.mp4|center|vignette]]<br />
<br />
<br />
<br />
<br />
Nous avons également fait la fonction EtatLED dans le fichier USBFinal.c (fichier servant à détecter et communiquer avec la manette par le port USB) qui se trouve dans le dossier libUSB, qui sert à allumer ou éteindre la LED de son choix.<br />
<br />
Celle ci utilise le device, handle et configuration descriptor qui ont été définies dans des fonctions précédentes, disponible sur le git dans usbfinal.c ,grandement inspirées de ce qui est donné sur le site de Monsieur Redon, qui sélectionnent la manette et le config descriptor. On aurait dû également sélectionner l'interface dans cette fonction précédente plutôt que de le faire dans EtatLED mais nous nous en sommes rendus compte trop tard.<syntaxhighlight lang="c"><br />
void EtatLED(int etat, int numLED, libusb_device *manette, libusb_device_handle *handle, struct libusb_config_descriptor *configdesc)<br />
{<br />
int indint=0;/* e.g. première interface */<br />
int indalt=0; /* e.g. première alternative */<br />
int interface=1; //;configdesc->interface[indint].altsetting[indalt].bInterfaceNumber;<br />
int status=libusb_claim_interface(handle,interface);<br />
<br />
if(status!=0)<br />
{<br />
printf("bij\n");<br />
perror("libusb_claim_interface");<br />
exit(-1);<br />
}<br />
<br />
printf("Interface %d claimed\n",interface);<br />
<br />
unsigned char data = 0;<br />
if(etat){<br />
switch (numLED){<br />
case 1:<br />
data = 0x01;<br />
break;<br />
case 2:<br />
data = 0x02;<br />
break;<br />
case 3:<br />
data = 0x03;<br />
break;<br />
case 4:<br />
data = 0x04;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}else{<br />
switch (numLED){<br />
case 1:<br />
data = 0x11;<br />
break;<br />
case 2:<br />
data = 0x12;<br />
break;<br />
case 3:<br />
data = 0x13;<br />
break;<br />
case 4:<br />
data = 0x14;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}<br />
</syntaxhighlight><br />
Exemple d'appel dans le main <code>EtatLED(0,1, manette, handle, configdesc);</code>. La fonction va éteindre la LED 1.<br />
<br />
=== Boutons ===<br />
Les LEDs étant configuré il est temps de passer à l'utilisation des boutons. Le principe reste globalement le même, on modifie les fichiers descriptors et minimal selon nos besoins. Pour nous faciliter un peu la tâche nous avons pris les fichiers déjà existant pour des joysticks. Nous allons considérer que si un de nos boutons est appuyé cela reviendra au même que si un joystick est dirigée au maximum dans une direction donnée.<br />
<br />
<br />
La modification majeure à faire pour que nos boutons soit détecté était sur la fonction <syntaxhighlight lang="c"><br />
bool GetNextReport(USB_JoystickReport_Data_t* const ReportData)<br />
{<br />
static uint8_t PrevJoyStatus = 0;<br />
static uint8_t PrevButtonStatus = 0;<br />
bool InputChanged = false;<br />
<br />
/* Clear the report contents */<br />
memset(ReportData, 0, sizeof(USB_JoystickReport_Data_t));<br />
<br />
if(~(PIND>>PD4) & 1){<br />
ReportData->X = -100;<br />
}<br />
if(~(PIND>>PD7) & 1){<br />
ReportData->X = 100;<br />
}<br />
if(~(PIND>>PD6) & 1){<br />
ReportData->Y = -100;<br />
}<br />
if(~(PINB>>PB4) & 1){<br />
ReportData->Y = 100;<br />
}<br />
if(~(PINF>>PF7) & 1){<br />
ReportData->Button |= (1 << 0);<br />
}<br />
if(~(PINF>>PF6) & 1){<br />
ReportData->Button |= (1 << 1);<br />
}<br />
/* Return whether the new report is different to the previous report or not */<br />
return InputChanged;<br />
}<br />
</syntaxhighlight>Cela nous permet de dire que si un bouton que nous avons configuré est enfoncé, on met la direction X ou Y à plus ou moins 100. Nous les avons tester avec jstest-gtk qui permet de visualiser les directions et appuis d'un joystick, tous nos boutons sont reconnus et configurés comme nous le souhaitons.<br />
<br />
=== Regroupement des deux ===<br />
Pour avoir une manette fonctionnelle à 100% la dernière étape est de fusionner les différents fichiers pour les LEDs et pour les boutons pour que tout soit utilisable en même temps. Pour cela il a fallu modifié le fichier Descritors.c, dans la fonction<br />
<br />
<code>const USB_Descriptor_Configuration_t PROGMEM ConfigurationDescriptor</code>il faut indiquer le nombre d'interface à deux, puis rajouter une interface. Dans notre cas étant parti du fichier des boutons nous avons rajouté celle des LEDs. Une fois ceci fais, il ne restait plus qu'à rajouter les fonctions de chaque partie dans un même fichier .c et nous avons fini la configuration et la programmation de notre manette.<br />
<br />
== Implémentation dans le Space Invaders ==<br />
<br />
=== Ajout des boutons ===<br />
On va dans cette partie utiliser tout ce qui a été implémenté pour rendre la manette utilisable avec le jeu Space Invaders codé en parallèle. <br />
<br />
D'abord, on a, grâce au tutoriel fourni, ajouté l'utilisation des boutons avec la librairie SDL. Il nous a suffit de créer une fonction qui d'abord initialise notre manette en détectant le nombre de Joystick que celle ci possède. <br />
<br />
[[Fichier:JoystickInit.png|thumb|center|700px|Initialisation de la manette]] <br />
<br />
<br />
Ensuite, on a créé une fonction handleControllerReformed qui pendant que le jeu tourne vient récupérer les valeurs des axes et des boutons de la manette en utilisant le pointeur initialisé par JoystickInitialisation.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-21-04.png|thumb|center|700px|Fonction récupérant la valeur des axes et des boutons]]<br />
<br />
<p style="clear: both;" /><br />
<br />
Maintenant que nous avons les valeurs des boutons et des axes à chaque instant, nous pouvons les utiliser comme input dans nos programmes pour, par exemple, les déplacements du vaisseau et le lancer de missiles. La valeur des axes est toujours maximale car notre joystick est en fait 4 boutons interprétés comme un Joystick, c'est pour cela qu'on vient comparer leurs valeurs aux valeurs maximales envoyés par un Joystick (32767 et -32768). Les boutons sont des booléens qui retournent 1 quand ils sont à l'état bas et 0 à l'état haut.[[Fichier:Screenshot from 2024-06-10 22-21-55.png|thumb|left|700px|Fonction permettant de faire se déplacer le joueur au clavier ou à la manette]]<br />
[[Fichier:Screenshot from 2024-06-10 22-22-34.png|thumb|right|700px|Fonction permettant d'ajouter un missile si l'on appuie sur e ou sur un bouton.]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Vous pouvez voir le résultat de l'implémentation totale des boutons en cliquant [https://www.youtube.com/watch?v=TwVJ7-ZU8_8&ab_channel=R%C3%A9mi sur ce lien].<br />
<br />
=== Ajout des Diodes Électro-Luminescentes (la classe) ===<br />
<br />
<br />
Pour utiliser les LEDs, c'est légèrement plus compliqué. Le code que nous avions fait précédemment dans usbfinal.c, notamment EtatLED, va nous être utile. On va transformer ce fichier usbfinal.c en une librairie dynamique en .so. Grâce à ça, on va pouvoir réutiliser la fonction EtatLED dans notre programme pour le jeu et l'appeler directement dans des fonctions.<br />
<br />
Pour faire cela, on va compiler en utilisant des options particulières pour gcc. La commande est <code>gcc -fPIC -shared -o libusbfinal.so usbfinal.c -lusb-1.0</code>. L'option <code>-fPIC</code> permet de génerer du code indépendant de l'emplacement mémoire auquel il est chargé. L'option <code>-shared</code> permet de génerer une bibliotèque partager plutôt qu'un executable, et <code>-lusb-1.0</code> permet d'indiquer au compilateur qu'on utilise libusb 1.0 dans ce fichier C.<br />
<br />
On se retrouve alors avec un fichier .so disponible dans le git (dans les fichiers LUFA, répértoire libUSB, le chemin précis est spécifié dans le readme).<br />
<br />
Ce fichier est la bibliothèque dynamique qu'on peut appeler dans notre makefile.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-19-26.png|thumb|center|700px|Makefile pour le jeu, adapté à l'utilisation de la manette]]<br />
<br />
<br />
<br />
On voit qu'il faut rajouter dans l'éxecution la commande <code>export LD_LIBRARY_PATH=./src/include:$$LD_LIBRARY_PATH && ./$(TARGET) </code>(nécessaire pour indiquer l'emplacement des bibliothèques dynamiques), et éxecuter la commande sudo make run pour lancer le jeu (libusb nécessite d'avoir les droits administrateurs).<br />
<br />
On peut alors dans le fichier source C spaceinvaders ajouter le fichier d'en-tête associé à la librairie usbfinal.h également disponible dans le git, et utiliser toutes les fonctions crééés dans usbfinal.c. On a finalement créé une fonction displayLivesLEDs qui vient alumer le nombre de LEDs correspondant au nombre de vies restantes, qu'on appelle à chaque fois que le joueur est touché pour éviter des appels inutiles (tant que l'on ne fait rien, les LEDs gardent leur état).<br />
[[Fichier:Screenshot from 2024-06-10 22-18-12.png|thumb|center|500px|Fonction de gestion des LEDs]]<br />
<br />
Le résultat final avec implémentation des LEDs :<br />
<br />
[[Fichier:TestLEDs.mp4|thumb|center|700px]]<br />
<br />
<br />
<br />
On peut également vous fournir le .zip du jeu spaceinvaders avec l'implémentation de la manette si besoin (trop volumineux pour le wiki) en nous contactant par mail (remi.boursault@polytech-lille.net).<br />
<br />
== CONCLUSION ==<br />
On a fini.<br />
<br />
Plus sérieusement, la manette possède les fonctionnalités attendues. Les fichiers LUFA permettent de faire comprendre à un PC qu'elle est constitué d'un Joystick, de deux boutons et de 4 LEDs. On a également réussi à utiliser tous ces éléments dans notre jeu comme il était demandé.<br />
<br />
== GIT ==<br />
Vous pouvez consulter le [https://archives.plil.fr/rboursau/S6-manette.git dépôt Git] des projet. Celui-ci contient le fichier gerber de la manette crée sur KiCad. Les fichiers utilisé pour le programmateur AVR sont dans le dossier projet-info-manette/ProgrammateurAVR. Et les fichiers utilisé pour la manette sont eux dans le dossier projet-info-manette/fichier_lufa_libusb.</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3_PSE_Binome2023-5&diff=5974SE3 PSE Binome2023-52024-06-15T14:06:44Z<p>Rboursau : </p>
<hr />
<div>= Projet système embarqué de Rémi BOURSAULT et Antoine LECOMTE =<br />
L'objectif de ce module est de modéliser une manette, puis de la rendre fonctionnelle, pour jouer au jeu Space Invaders qui est codé dans le même module.<br />
<br />
Les professeurs avaient préalablement fourni un dossier contenant un modèle de PCB incomplet et différents fichiers ".c" et ".h" pour nous aider à démarrer. <br />
<br />
== Création de Manette ==<br />
La création de la manette commence par la création sur kicad d'un PCB. Nous avons pris celui fourni sur le wiki du projet qui possède tous les composants mais non routés. <br />
<br />
<br />
<br />
<br />
<br />
== Modélisation PCB ==<br />
A partir du fichier KiCad fourni, nous avons modélisé un PCB déstiné à être utilisé comme manette. Nous avons donc ajouté des boutons, replacé ces derniers. Grâce au schéma nous avons sélectionné des PIN pour connecter les boutons, ainsi que des LEDs et des résistances que nous avons aussi ajouté. <br />
<br />
Voyant que nous avions encore de l'espace de libre sur notre carte, étant un peu ambitieux et voyant que le procédé n'est pas bien compliqué, nous décidons alors de rajouter quelque boutons et quelques LEDs en plus pour que notre manette soit un peu plus crédibles. <br />
<br />
Il nous a alors fallu rajouté les dit composants sur notre schéma pour que ceux-ci soient rajoutés automatiquement sur le PCB lors de l'utilisation de la fonction "Update PCB with changes made to schematic" <br />
<br />
<br />
<gallery><br />
File:Image boutons.png|Schéma des boutons<br />
File:Connecteur ISP.png|Schéma du connecteur ISP<br />
File:Schéma des LEDs.png|Schéma des LEDs<br />
File:Connecteur USB.png|Schéma du connecteur USB<br />
File:Microcontroleur.png|Schéma du microcontrôleur<br />
</gallery><br />
<br />
<br />
[[Fichier:Plan pcb.jpg|thumb|center|500px| Ajout du plan de masse et des via]]<br />
<br />
<br />
<br />
Une fois le routage effectué, nous avons ajouté un plan de masse et ajouté une grande quantité de via à différent endroits de la carte pour que la masse soit bien connectée et éviter les fuites thermiques de certains composants. <br />
<br />
Ensuite le fichier a été envoyé pour impression en Chine, grâce au fichier Gerber généré par KiCad que vous pouvez retrouvez sur notre GIT:<br />
<br />
<br />
[[Fichier:Vue3d.jpg|thumb|center|500px| Rendu 3D final de la carte]]<br />
<br />
== Programmateur AVR ==<br />
En attendant de recevoir les cartes, nous nous sommes initiés à la programmation d'un périphérique USB, nous avons utilisé les bibliothèques LUFA et LibUSB pour utilisé un programmateur AVR. Il nous a fallu également modifier des fichiers Descripteurs, en ".c" et ".h" qui permettent, une fois téléversés dans le programmateur, d'être détecter par le PC et que celui-ci reconnaisse les fonctionnalités du périphérique (InPoint et EndPoint). <br />
<br />
<br />
== Soudure de la carte ==<br />
Une fois la carte reçu, nous avons pris tous nos composants et avons commencé à les souder. N'ayant que très peu d'expérience dans ce domaine ce n'était pas quelque chose de facile au début. Il nous a fallu un peu d'aide et pas mal de flux pour comprendre comment faire des soudures propres. Une fois le coup de main pris, la fin du montage de la carte était assez rapide. Nous avons donc pu passer à la programmation pour la reconnaissance par l'ordinateur de notre carte.<br />
[[Fichier:Carte vierge.jpg|thumb|left|500px| Carte vierge]]<br />
<br />
[[Fichier:Carte soudée manette.jpg|thumb|center|500px| Carte avec tous les composants soudés]]<br />
<br />
<br />
<br />
Une fois la carte soudée il a fallu pouvoir la configurer pour par la suite pouvoir la programmer. Pour se faire il faut lui injecter un bootloader via son programmateur ISP. Ce qui passe la manette en mode DFU et elle est alors reconnu par l'ordinateur.<br />
[[Fichier:Manette reconnu en mode dfu.png|thumb|center|500px| Manette reconnu en mode DFU]]<br />
<br />
== LUFA de la manette ==<br />
Après avoir reçu les cartes et terminé de souder les composants nous avons pu attaquer la programmation du microcontrôleur pour pouvoir utiliser la manette. Nous avons procédés étape par étape, en commençant par allumé les LEDs puis réceptionner les signaux des boutons pour finir par fusionner les deux pour avoir une manette fonctionnelle.<br />
<br />
=== LEDs ===<br />
Pour éviter un décalage sur le portF il faut désactiver le JTAG en copiant deux fois cette ligne au niveau de la déclaration des pins : <code>MCUCR |= (1<<JTD);</code>cela permet d'accéder aux LEDs sur les pins PF4 et PF5.<br />
Une fois la configuration terminé, nous avons testé nos LEDs avec la fonction suivante : <syntaxhighlight lang="c"><br />
void blink_leds(void){<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
_delay_ms(200);<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
}<br />
</syntaxhighlight><br />
Ce qui nous donne ce résultat [[Fichier:Vidéo clignotement LEDs.mp4|center|vignette]]<br />
<br />
<br />
<br />
<br />
Nous avons également fait la fonction EtatLED dans le fichier USBFinal.c (fichier servant à détecter et communiquer avec la manette par le port USB) qui se trouve dans le dossier libUSB, qui sert à allumer ou éteindre la LED de son choix.<br />
<br />
Celle ci utilise le device, handle et configuration descriptor qui ont été définies dans des fonctions précédentes, disponible sur le git dans usbfinal.c ,grandement inspirées de ce qui est donné sur le site de Monsieur Redon, qui sélectionnent la manette et le config descriptor. On aurait dû également sélectionner l'interface dans cette fonction précédente plutôt que de le faire dans EtatLED mais nous nous en sommes rendus compte trop tard.<syntaxhighlight lang="c"><br />
void EtatLED(int etat, int numLED, libusb_device *manette, libusb_device_handle *handle, struct libusb_config_descriptor *configdesc)<br />
{<br />
int indint=0;/* e.g. première interface */<br />
int indalt=0; /* e.g. première alternative */<br />
int interface=1; //;configdesc->interface[indint].altsetting[indalt].bInterfaceNumber;<br />
int status=libusb_claim_interface(handle,interface);<br />
<br />
if(status!=0)<br />
{<br />
printf("bij\n");<br />
perror("libusb_claim_interface");<br />
exit(-1);<br />
}<br />
<br />
printf("Interface %d claimed\n",interface);<br />
<br />
unsigned char data = 0;<br />
if(etat){<br />
switch (numLED){<br />
case 1:<br />
data = 0x01;<br />
break;<br />
case 2:<br />
data = 0x02;<br />
break;<br />
case 3:<br />
data = 0x03;<br />
break;<br />
case 4:<br />
data = 0x04;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}else{<br />
switch (numLED){<br />
case 1:<br />
data = 0x11;<br />
break;<br />
case 2:<br />
data = 0x12;<br />
break;<br />
case 3:<br />
data = 0x13;<br />
break;<br />
case 4:<br />
data = 0x14;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}<br />
</syntaxhighlight><br />
Exemple d'appel dans le main <code>EtatLED(0,1, manette, handle, configdesc);</code>. La fonction va éteindre la LED 1.<br />
<br />
=== Boutons ===<br />
Les LEDs étant configuré il est temps de passer à l'utilisation des boutons. Le principe reste globalement le même, on modifie les fichiers descriptors et minimal selon nos besoins. Pour nous faciliter un peu la tâche nous avons pris les fichiers déjà existant pour des joysticks. Nous allons considérer que si un de nos boutons est appuyé cela reviendra au même que si un joystick est dirigée au maximum dans une direction donnée.<br />
<br />
<br />
La modification majeure à faire pour que nos boutons soit détecté était sur la fonction <syntaxhighlight lang="c"><br />
bool GetNextReport(USB_JoystickReport_Data_t* const ReportData)<br />
{<br />
static uint8_t PrevJoyStatus = 0;<br />
static uint8_t PrevButtonStatus = 0;<br />
bool InputChanged = false;<br />
<br />
/* Clear the report contents */<br />
memset(ReportData, 0, sizeof(USB_JoystickReport_Data_t));<br />
<br />
if(~(PIND>>PD4) & 1){<br />
ReportData->X = -100;<br />
}<br />
if(~(PIND>>PD7) & 1){<br />
ReportData->X = 100;<br />
}<br />
if(~(PIND>>PD6) & 1){<br />
ReportData->Y = -100;<br />
}<br />
if(~(PINB>>PB4) & 1){<br />
ReportData->Y = 100;<br />
}<br />
if(~(PINF>>PF7) & 1){<br />
ReportData->Button |= (1 << 0);<br />
}<br />
if(~(PINF>>PF6) & 1){<br />
ReportData->Button |= (1 << 1);<br />
}<br />
/* Return whether the new report is different to the previous report or not */<br />
return InputChanged;<br />
}<br />
</syntaxhighlight>Cela nous permet de dire que si un bouton que nous avons configuré est enfoncé, on met la direction X ou Y à plus ou moins 100. Nous les avons tester avec jstest-gtk qui permet de visualiser les directions et appuis d'un joystick, tous nos boutons sont reconnus et configurés comme nous le souhaitons.<br />
<br />
=== Regroupement des deux ===<br />
Pour avoir une manette fonctionnelle à 100% la dernière étape est de fusionner les différents fichiers pour les LEDs et pour les boutons pour que tout soit utilisable en même temps. Pour cela il a fallu modifié le fichier Descritors.c, dans la fonction<br />
<br />
<code>const USB_Descriptor_Configuration_t PROGMEM ConfigurationDescriptor</code>il faut indiquer le nombre d'interface à deux, puis rajouter une interface. Dans notre cas étant parti du fichier des boutons nous avons rajouté celle des LEDs. Une fois ceci fais, il ne restait plus qu'à rajouter les fonctions de chaque partie dans un même fichier .c et nous avons fini la configuration et la programmation de notre manette.<br />
<br />
== Implémentation dans le Space Invaders ==<br />
<br />
=== Ajout des boutons ===<br />
On va dans cette partie utiliser tout ce qui a été implémenté pour rendre la manette utilisable avec le jeu Space Invaders codé en parallèle. <br />
<br />
D'abord, on a, grâce au tutoriel fourni, ajouté l'utilisation des boutons avec la librairie SDL. Il nous a suffit de créer une fonction qui d'abord initialise notre manette en détectant le nombre de Joystick que celle ci possède. <br />
<br />
[[Fichier:JoystickInit.png|thumb|center|700px|Initialisation de la manette]] <br />
<br />
<br />
Ensuite, on a créé une fonction handleControllerReformed qui pendant que le jeu tourne vient récupérer les valeurs des axes et des boutons de la manette en utilisant le pointeur initialisé par JoystickInitialisation.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-21-04.png|thumb|center|700px|Fonction récupérant la valeur des axes et des boutons]]<br />
<br />
<p style="clear: both;" /><br />
<br />
Maintenant que nous avons les valeurs des boutons et des axes à chaque instant, nous pouvons les utiliser comme input dans nos programmes pour, par exemple, les déplacements du vaisseau et le lancer de missiles. La valeur des axes est toujours maximale car notre joystick est en fait 4 boutons interprétés comme un Joystick, c'est pour cela qu'on vient comparer leurs valeurs aux valeurs maximales envoyés par un Joystick (32767 et -32768). Les boutons sont des booléens qui retournent 1 quand ils sont à l'état bas et 0 à l'état haut.[[Fichier:Screenshot from 2024-06-10 22-21-55.png|thumb|left|700px|Fonction permettant de faire se déplacer le joueur au clavier ou à la manette]]<br />
[[Fichier:Screenshot from 2024-06-10 22-22-34.png|thumb|right|700px|Fonction permettant d'ajouter un missile si l'on appuie sur e ou sur un bouton.]]<br />
<br />
<br />
<br />
Vous pouvez voir le résultat de l'implémentation totale des boutons en cliquant [https://www.youtube.com/watch?v=TwVJ7-ZU8_8&ab_channel=R%C3%A9mi sur ce lien].<br />
<br />
=== Ajout des Diodes Électro-Luminescentes (la classe) ===<br />
<br />
<br />
Pour utiliser les LEDs, c'est légèrement plus compliqué. Le code que nous avions fait précédemment dans usbfinal.c, notamment EtatLED, va nous être utile. On va transformer ce fichier usbfinal.c en une librairie dynamique en .so. Grâce à ça, on va pouvoir réutiliser la fonction EtatLED dans notre programme pour le jeu et l'appeler directement dans des fonctions.<br />
<br />
Pour faire cela, on va compiler en utilisant des options particulières pour gcc. La commande est <code>gcc -fPIC -shared -o libusbfinal.so usbfinal.c -lusb-1.0</code>. L'option <code>-fPIC</code> permet de génerer du code indépendant de l'emplacement mémoire auquel il est chargé. L'option <code>-shared</code> permet de génerer une bibliotèque partager plutôt qu'un executable, et <code>-lusb-1.0</code> permet d'indiquer au compilateur qu'on utilise libusb 1.0 dans ce fichier C.<br />
<br />
On se retrouve alors avec un fichier .so disponible dans le git (dans les fichiers LUFA, répértoire libUSB, le chemin précis est spécifié dans le readme).<br />
<br />
Ce fichier est la bibliothèque dynamique qu'on peut appeler dans notre makefile.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-19-26.png|thumb|center|700px|Makefile pour le jeu, adapté à l'utilisation de la manette]]<br />
<br />
<br />
<br />
On voit qu'il faut rajouter dans l'éxecution la commande <code>export LD_LIBRARY_PATH=./src/include:$$LD_LIBRARY_PATH && ./$(TARGET) </code>(nécessaire pour indiquer l'emplacement des bibliothèques dynamiques), et éxecuter la commande sudo make run pour lancer le jeu (libusb nécessite d'avoir les droits administrateurs).<br />
<br />
On peut alors dans le fichier source C spaceinvaders ajouter le fichier d'en-tête associé à la librairie usbfinal.h également disponible dans le git, et utiliser toutes les fonctions crééés dans usbfinal.c. On a finalement créé une fonction displayLivesLEDs qui vient alumer le nombre de LEDs correspondant au nombre de vies restantes, qu'on appelle à chaque fois que le joueur est touché pour éviter des appels inutiles (tant que l'on ne fait rien, les LEDs gardent leur état).<br />
[[Fichier:Screenshot from 2024-06-10 22-18-12.png|thumb|center|500px|Fonction de gestion des LEDs]]<br />
<br />
Le résultat final avec implémentation des LEDs :<br />
<br />
[[Fichier:TestLEDs.mp4|thumb|center|700px|vignette]]<br />
<br />
<br />
<br />
On peut également vous fournir le .zip du jeu spaceinvaders avec l'implémentation de la manette si besoin (trop volumineux pour le wiki) en nous contactant par mail (remi.boursault@polytech-lille.net).<br />
<br />
== CONCLUSION ==<br />
On a fini.<br />
<br />
Plus sérieusement, la manette possède les fonctionnalités attendues. Les fichiers LUFA permettent de faire comprendre à un PC qu'elle est constitué d'un Joystick, de deux boutons et de 4 LEDs. On a également réussi à utiliser tous ces éléments dans notre jeu comme il était demandé.<br />
<br />
== GIT ==<br />
Vous pouvez consulter le [https://archives.plil.fr/rboursau/S6-manette.git dépôt Git] des projet. Celui-ci contient le fichier gerber de la manette crée sur KiCad. Les fichiers utilisé pour le programmateur AVR sont dans le dossier projet-info-manette/ProgrammateurAVR. Et les fichiers utilisé pour la manette sont eux dans le dossier projet-info-manette/fichier_lufa_libusb.</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3_PSE_Binome2023-5&diff=5973SE3 PSE Binome2023-52024-06-15T14:04:02Z<p>Rboursau : </p>
<hr />
<div>= Projet système embarqué de Rémi BOURSAULT et Antoine LECOMTE =<br />
L'objectif de ce module est de modéliser une manette, puis de la rendre fonctionnelle, pour jouer au jeu Space Invaders qui est codé dans le même module.<br />
<br />
Les professeurs avaient préalablement fourni un dossier contenant un modèle de PCB incomplet et différents fichiers ".c" et ".h" pour nous aider à démarrer. <br />
<br />
== Création de Manette ==<br />
La création de la manette commence par la création sur kicad d'un PCB. Nous avons pris celui fourni sur le wiki du projet qui possède tous les composants mais non routés. <br />
<br />
<br />
<br />
<br />
<br />
== Modélisation PCB ==<br />
A partir du fichier KiCad fourni, nous avons modélisé un PCB déstiné à être utilisé comme manette. Nous avons donc ajouté des boutons, replacé ces derniers. Grâce au schéma nous avons sélectionné des PIN pour connecter les boutons, ainsi que des LEDs et des résistances que nous avons aussi ajouté. <br />
<br />
Voyant que nous avions encore de l'espace de libre sur notre carte, étant un peu ambitieux et voyant que le procédé n'est pas bien compliqué, nous décidons alors de rajouter quelque boutons et quelques LEDs en plus pour que notre manette soit un peu plus crédibles. <br />
<br />
Il nous a alors fallu rajouté les dit composants sur notre schéma pour que ceux-ci soient rajoutés automatiquement sur le PCB lors de l'utilisation de la fonction "Update PCB with changes made to schematic" <br />
<br />
<br />
<gallery><br />
File:Image boutons.png|Schéma des boutons<br />
File:Connecteur ISP.png|Schéma du connecteur ISP<br />
File:Schéma des LEDs.png|Schéma des LEDs<br />
File:Connecteur USB.png|Schéma du connecteur USB<br />
File:Microcontroleur.png|Schéma du microcontrôleur<br />
</gallery><br />
<br />
<br />
[[Fichier:Plan pcb.jpg|thumb|center|500px| Ajout du plan de masse et des via]]<br />
<br />
<br />
<br />
Une fois le routage effectué, nous avons ajouté un plan de masse et ajouté une grande quantité de via à différent endroits de la carte pour que la masse soit bien connectée et éviter les fuites thermiques de certains composants. <br />
<br />
Ensuite le fichier a été envoyé pour impression en Chine, grâce au fichier Gerber généré par KiCad que vous pouvez retrouvez sur notre GIT:<br />
<br />
<br />
[[Fichier:Vue3d.jpg|thumb|center|500px| Rendu 3D final de la carte]]<br />
<br />
== Programmateur AVR ==<br />
En attendant de recevoir les cartes, nous nous sommes initiés à la programmation d'un périphérique USB, nous avons utilisé les bibliothèques LUFA et LibUSB pour utilisé un programmateur AVR. Il nous a fallu également modifier des fichiers Descripteurs, en ".c" et ".h" qui permettent, une fois téléversés dans le programmateur, d'être détecter par le PC et que celui-ci reconnaisse les fonctionnalités du périphérique (InPoint et EndPoint). <br />
<br />
<br />
== Soudure de la carte ==<br />
Une fois la carte reçu, nous avons pris tous nos composants et avons commencé à les souder. N'ayant que très peu d'expérience dans ce domaine ce n'était pas quelque chose de facile au début. Il nous a fallu un peu d'aide et pas mal de flux pour comprendre comment faire des soudures propres. Une fois le coup de main pris, la fin du montage de la carte était assez rapide. Nous avons donc pu passer à la programmation pour la reconnaissance par l'ordinateur de notre carte.<br />
[[Fichier:Carte vierge.jpg|thumb|left|500px| Carte vierge]]<br />
<br />
[[Fichier:Carte soudée manette.jpg|thumb|center|500px| Carte avec tous les composants soudés]]<br />
<br />
<br />
<br />
Une fois la carte soudée il a fallu pouvoir la configurer pour par la suite pouvoir la programmer. Pour se faire il faut lui injecter un bootloader via son programmateur ISP. Ce qui passe la manette en mode DFU et elle est alors reconnu par l'ordinateur.<br />
[[Fichier:Manette reconnu en mode dfu.png|thumb|center|500px| Manette reconnu en mode DFU]]<br />
<br />
== LUFA de la manette ==<br />
Après avoir reçu les cartes et terminé de souder les composants nous avons pu attaquer la programmation du microcontrôleur pour pouvoir utiliser la manette. Nous avons procédés étape par étape, en commençant par allumé les LEDs puis réceptionner les signaux des boutons pour finir par fusionner les deux pour avoir une manette fonctionnelle.<br />
<br />
=== LEDs ===<br />
Pour éviter un décalage sur le portF il faut désactiver le JTAG en copiant deux fois cette ligne au niveau de la déclaration des pins : <code>MCUCR |= (1<<JTD);</code>cela permet d'accéder aux LEDs sur les pins PF4 et PF5.<br />
Une fois la configuration terminé, nous avons testé nos LEDs avec la fonction suivante : <syntaxhighlight lang="c"><br />
void blink_leds(void){<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
_delay_ms(200);<br />
PORTF |= 0b00110011;<br />
_delay_ms(200);<br />
PORTF &= ~0b00110011;<br />
}<br />
</syntaxhighlight><br />
Ce qui nous donne ce résultat [[Fichier:Vidéo clignotement LEDs.mp4|center|vignette]]<br />
<br />
<br />
<br />
<br />
Nous avons également fait la fonction EtatLED dans le fichier USBFinal.c (fichier servant à détecter et communiquer avec la manette par le port USB) qui se trouve dans le dossier libUSB, qui sert à allumer ou éteindre la LED de son choix.<br />
<br />
Celle ci utilise le device, handle et configuration descriptor qui ont été définies dans des fonctions précédentes, disponible sur le git dans usbfinal.c ,grandement inspirées de ce qui est donné sur le site de Monsieur Redon, qui sélectionnent la manette et le config descriptor. On aurait dû également sélectionner l'interface dans cette fonction précédente plutôt que de le faire dans EtatLED mais nous nous en sommes rendus compte trop tard.<syntaxhighlight lang="c"><br />
void EtatLED(int etat, int numLED, libusb_device *manette, libusb_device_handle *handle, struct libusb_config_descriptor *configdesc)<br />
{<br />
int indint=0;/* e.g. première interface */<br />
int indalt=0; /* e.g. première alternative */<br />
int interface=1; //;configdesc->interface[indint].altsetting[indalt].bInterfaceNumber;<br />
int status=libusb_claim_interface(handle,interface);<br />
<br />
if(status!=0)<br />
{<br />
printf("bij\n");<br />
perror("libusb_claim_interface");<br />
exit(-1);<br />
}<br />
<br />
printf("Interface %d claimed\n",interface);<br />
<br />
unsigned char data = 0;<br />
if(etat){<br />
switch (numLED){<br />
case 1:<br />
data = 0x01;<br />
break;<br />
case 2:<br />
data = 0x02;<br />
break;<br />
case 3:<br />
data = 0x03;<br />
break;<br />
case 4:<br />
data = 0x04;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}else{<br />
switch (numLED){<br />
case 1:<br />
data = 0x11;<br />
break;<br />
case 2:<br />
data = 0x12;<br />
break;<br />
case 3:<br />
data = 0x13;<br />
break;<br />
case 4:<br />
data = 0x14;<br />
break;<br />
default:<br />
printf("Selectionnez un chiffre entre 1 et 4");<br />
}<br />
}<br />
</syntaxhighlight><br />
Exemple d'appel dans le main <code>EtatLED(0,1, manette, handle, configdesc);</code>. La fonction va éteindre la LED 1.<br />
<br />
=== Boutons ===<br />
Les LEDs étant configuré il est temps de passer à l'utilisation des boutons. Le principe reste globalement le même, on modifie les fichiers descriptors et minimal selon nos besoins. Pour nous faciliter un peu la tâche nous avons pris les fichiers déjà existant pour des joysticks. Nous allons considérer que si un de nos boutons est appuyé cela reviendra au même que si un joystick est dirigée au maximum dans une direction donnée.<br />
<br />
<br />
La modification majeure à faire pour que nos boutons soit détecté était sur la fonction <syntaxhighlight lang="c"><br />
bool GetNextReport(USB_JoystickReport_Data_t* const ReportData)<br />
{<br />
static uint8_t PrevJoyStatus = 0;<br />
static uint8_t PrevButtonStatus = 0;<br />
bool InputChanged = false;<br />
<br />
/* Clear the report contents */<br />
memset(ReportData, 0, sizeof(USB_JoystickReport_Data_t));<br />
<br />
if(~(PIND>>PD4) & 1){<br />
ReportData->X = -100;<br />
}<br />
if(~(PIND>>PD7) & 1){<br />
ReportData->X = 100;<br />
}<br />
if(~(PIND>>PD6) & 1){<br />
ReportData->Y = -100;<br />
}<br />
if(~(PINB>>PB4) & 1){<br />
ReportData->Y = 100;<br />
}<br />
if(~(PINF>>PF7) & 1){<br />
ReportData->Button |= (1 << 0);<br />
}<br />
if(~(PINF>>PF6) & 1){<br />
ReportData->Button |= (1 << 1);<br />
}<br />
/* Return whether the new report is different to the previous report or not */<br />
return InputChanged;<br />
}<br />
</syntaxhighlight>Cela nous permet de dire que si un bouton que nous avons configuré est enfoncé, on met la direction X ou Y à plus ou moins 100. Nous les avons tester avec jstest-gtk qui permet de visualiser les directions et appuis d'un joystick, tous nos boutons sont reconnus et configurés comme nous le souhaitons.<br />
<br />
=== Regroupement des deux ===<br />
Pour avoir une manette fonctionnelle à 100% la dernière étape est de fusionner les différents fichiers pour les LEDs et pour les boutons pour que tout soit utilisable en même temps. Pour cela il a fallu modifié le fichier Descritors.c, dans la fonction<br />
<br />
<code>const USB_Descriptor_Configuration_t PROGMEM ConfigurationDescriptor</code>il faut indiquer le nombre d'interface à deux, puis rajouter une interface. Dans notre cas étant parti du fichier des boutons nous avons rajouté celle des LEDs. Une fois ceci fais, il ne restait plus qu'à rajouter les fonctions de chaque partie dans un même fichier .c et nous avons fini la configuration et la programmation de notre manette.<br />
<br />
== Implémentation dans le Space Invaders ==<br />
<br />
=== Ajout des boutons ===<br />
On va dans cette partie utiliser tout ce qui a été implémenté pour rendre la manette utilisable avec le jeu Space Invaders codé en parallèle. <br />
<br />
D'abord, on a, grâce au tutoriel fourni, ajouté l'utilisation des boutons avec la librairie SDL. Il nous a suffit de créer une fonction qui d'abord initialise notre manette en détectant le nombre de Joystick que celle ci possède. <br />
<br />
[[Fichier:JoystickInit.png|thumb|center|700px|Initialisation de la manette]] <br />
<br />
<br />
Ensuite, on a créé une fonction handleControllerReformed qui pendant que le jeu tourne vient récupérer les valeurs des axes et des boutons de la manette en utilisant le pointeur initialisé par JoystickInitialisation.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-21-04.png|thumb|center|700px|Fonction récupérant la valeur des axes et des boutons]]<br />
<br />
<p style="clear: both;" /><br />
<br />
Maintenant que nous avons les valeurs des boutons et des axes à chaque instant, nous pouvons les utiliser comme input dans nos programmes pour, par exemple, les déplacements du vaisseau et le lancer de missiles. La valeur des axes est toujours maximale car notre joystick est en fait 4 boutons interprétés comme un Joystick, c'est pour cela qu'on vient comparer leurs valeurs aux valeurs maximales envoyés par un Joystick (32767 et -32768). Les boutons sont des booléens qui retournent 1 quand ils sont à l'état bas et 0 à l'état haut.[[Fichier:Screenshot from 2024-06-10 22-21-55.png|thumb|left|700px|Fonction permettant de faire se déplacer le joueur au clavier ou à la manette]]<br />
[[Fichier:Screenshot from 2024-06-10 22-22-34.png|thumb|right|700px|Fonction permettant d'ajouter un missile si l'on appuie sur e ou sur un bouton.]]<br />
<br />
<p style="clear: both;" /><br />
[[Fichier:TestLEDs.mp4|vignette]]<br />
<p style="clear: both;" /><br />
<br />
Vous pouvez voir le résultat de l'implémentation totale des boutons en cliquant [https://www.youtube.com/watch?v=TwVJ7-ZU8_8&ab_channel=R%C3%A9mi sur ce lien].<br />
<br />
=== Ajout des Diodes Électro-Luminescentes (la classe) ===<br />
<br />
<br />
Pour utiliser les LEDs, c'est légèrement plus compliqué. Le code que nous avions fait précédemment dans usbfinal.c, notamment EtatLED, va nous être utile. On va transformer ce fichier usbfinal.c en une librairie dynamique en .so. Grâce à ça, on va pouvoir réutiliser la fonction EtatLED dans notre programme pour le jeu et l'appeler directement dans des fonctions.<br />
<br />
Pour faire cela, on va compiler en utilisant des options particulières pour gcc. La commande est <code>gcc -fPIC -shared -o libusbfinal.so usbfinal.c -lusb-1.0</code>. L'option <code>-fPIC</code> permet de génerer du code indépendant de l'emplacement mémoire auquel il est chargé. L'option <code>-shared</code> permet de génerer une bibliotèque partager plutôt qu'un executable, et <code>-lusb-1.0</code> permet d'indiquer au compilateur qu'on utilise libusb 1.0 dans ce fichier C.<br />
<br />
On se retrouve alors avec un fichier .so disponible dans le git (dans les fichiers LUFA, répértoire libUSB, le chemin précis est spécifié dans le readme).<br />
<br />
Ce fichier est la bibliothèque dynamique qu'on peut appeler dans notre makefile.<br />
<br />
[[Fichier:Screenshot from 2024-06-10 22-19-26.png|thumb|center|700px|Makefile pour le jeu, adapté à l'utilisation de la manette]]<br />
<br />
<br />
<br />
On voit qu'il faut rajouter dans l'éxecution la commande <code>export LD_LIBRARY_PATH=./src/include:$$LD_LIBRARY_PATH && ./$(TARGET) </code>(nécessaire pour indiquer l'emplacement des bibliothèques dynamiques), et éxecuter la commande sudo make run pour lancer le jeu (libusb nécessite d'avoir les droits administrateurs).<br />
<br />
On peut alors dans le fichier source C spaceinvaders ajouter le fichier d'en-tête associé à la librairie usbfinal.h également disponible dans le git, et utiliser toutes les fonctions crééés dans usbfinal.c. On a finalement créé une fonction displayLivesLEDs qui vient alumer le nombre de LEDs correspondant au nombre de vies restantes, qu'on appelle à chaque fois que le joueur est touché pour éviter des appels inutiles (tant que l'on ne fait rien, les LEDs gardent leur état).<br />
[[Fichier:Screenshot from 2024-06-10 22-18-12.png|thumb|center|500px|Fonction de gestion des LEDs]]<br />
<br />
<br />
<br />
Le résultat final avec implémentation des LEDs est disponible [https://www.youtube.com/watch?v=zt6Xmwq_HsA&ab_channel=R%C3%A9mi sur ce lien.]<br />
<br />
On peut également vous fournir le .zip du jeu spaceinvaders avec l'implémentation de la manette si besoin (trop volumineux pour le wiki) en nous contactant par mail (remi.boursault@polytech-lille.net).<br />
<br />
== CONCLUSION ==<br />
On a fini.<br />
<br />
Plus sérieusement, la manette possède les fonctionnalités attendues. Les fichiers LUFA permettent de faire comprendre à un PC qu'elle est constitué d'un Joystick, de deux boutons et de 4 LEDs. On a également réussi à utiliser tous ces éléments dans notre jeu comme il était demandé.<br />
<br />
== GIT ==<br />
Vous pouvez consulter le [https://archives.plil.fr/rboursau/S6-manette.git dépôt Git] des projet. Celui-ci contient le fichier gerber de la manette crée sur KiCad. Les fichiers utilisé pour le programmateur AVR sont dans le dossier projet-info-manette/ProgrammateurAVR. Et les fichiers utilisé pour la manette sont eux dans le dossier projet-info-manette/fichier_lufa_libusb.</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:TestLEDs.mp4&diff=5972Fichier:TestLEDs.mp42024-06-15T14:03:36Z<p>Rboursau : </p>
<hr />
<div></div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=Fichier:Coucouuu_%E2%80%90_R%C3%A9alis%C3%A9e_avec_Clipchamp.mp4&diff=5971Fichier:Coucouuu ‐ Réalisée avec Clipchamp.mp42024-06-15T13:58:39Z<p>Rboursau : </p>
<hr />
<div>a</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3Binome2023-5&diff=5643SE3Binome2023-52024-06-12T15:35:54Z<p>Rboursau : </p>
<hr />
<div>= Projet Groupe 5 : Voiture Programmable =<br />
Cette page est consacrée à la présentation du projet SE3 réalisé par BOURSAULT Rémi & LECOMTE Antoine, qui est porté sur la création d'une voiture contrôlé par programmation.<br />
<br />
== Présentation : ==<br />
<br />
=== Objectifs ===<br />
Les objectifs du projets sont : <br />
<br />
* Concevoir une voiture fonctionnant sur batterie, avec un ATMega.<br />
* Intégrer des clignotants fonctionnels.<br />
* Permettre à la voiture d'avancer ou reculer, toujours en utilisant l'ATMega.<br />
* Ajout d'un gyrophare.<br />
<br />
=== Ressources ===<br />
Pour atteindre ces différents objectifs, nous aurons besoins des ressources suivantes :<br />
<br />
* Un microcontrôleur ATMega16U4/ATMega32U4<br />
* Des LEDS<br />
* Deux moteurs à courant continu<br />
* Un châssis <br />
* Des dipôles classiques<br />
* Un gyrophare<br />
<br />
<br />
<br />
Après avoir choisi notre projet et nos différents objectifs pour ce projet, nous avons commencé à travailler sur le schéma de montage sur KiCAD afin de pouvoir ensuite faire le PCB et le routage qui sera envoyé à une usine pour imprimer nos cartes. Les fonctions et composants principaux de notre projet sont les suivants.<br />
<br />
== Fonction sur le schéma : ==<br />
<br />
<br />
=== Microcontrôleur ===<br />
La partie indispensable de tous montages électroniques, le cerveau de la voiture. Sans le microcontrôleur rien dans ce projet n'est possible, il permet de gérer les informations. qui sont transmises dans toutes la carte. C'est un microcontrôleur ATMega32u4, ce n'est pas le plus puissant, mais pour la taille du projet que nous faisons c'est bien assez. Il possède assez d'entrées/sorties pour ce que nous voulons en faire.[[Fichier:Microcontroleu.png||thumb|left|300px|Schéma du microcontrôleur]]<br />
[[Fichier:Pin configuration atmega.png||thumb|center|300px|Configuration des pins sur l'atmega]]<br />
<br />
=== Commande Moteur ===<br />
Ce bloc est celui qui actionne les moteurs et leur dit quand s'arrêter. Celui-ci est composé d'un TB6612FNG, un driver pour moteur qui ne sert qu'à ça. Il prend sept signaux en entrée trois pour gérer chaque moteur et un signal de standby. Nous avons utilisé la datasheet pour savoir comment le schématiser et quels composants utilisé pour que celui-ci fonctionne dans des conditions optimales. <br />
<br />
Il est nécessaire d'ajouter ce composant, car les signaux de sortie délivrés par l'ATMega sont trop faibles pour alimenter un moteur. Ce driver vient, à partir d'une tension d'alimentation Vcc amplifier le signal de commande délivré par l'ATMega pour que les moteurs aient l'alimentation adéquate. <br />
<br />
<br />
<br />
<br />
[[Fichier:Datasheet TB6612.png||thumb|left|300px|PCB routé de la carte]]<br />
[[Fichier:Commande Moteur.png||thumb|center|300px|Schéma du bloc de commande des moteurs]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
=== Chargeur LI-PO ===<br />
Comme notre voiture fonctionnera sur batterie, il faut un moyen de la recharger, ceci se faisant par l'intermédiaire d'un port USB, il faut un bloc pour adapter le courant que reçoit l'USB pour que cela corresponde aux caractéristiques de notre batterie.<br />
<br />
<br />
[[Fichier:Chargeur lipo.png||thumb|center|300px|Schéma du chargeur]]<br />
<br />
<br />
=== Utilisation de la Batterie ===<br />
Ce bloc permet de séparer l'alimentation en USB et sur batterie. Lorsqu'un cavalier est présent sur J6, VBAT est directement relié à Vcc et ainsi la batterie sert d'alimentation pour la carte. Il est impératif de débrancher l'USB avant de mettre le cavalier, pour éviter tout court-circuit. Lorsqu'on enlève le cavalier, on peut brancher l'USB et la carte fonctionne en filaire.[[Fichier:Utilisation baterie.png||thumb|center|300px|Schéma du switch batterie]]<br />
=== Connecteur USB ===<br />
On dispose de deux connecteurs USB, un pour recharger la batterie, et un autre pour transmettre les données, qui servira à implanter un programme dans notre microcontrôleur.[[Fichier:Connecteur USBs.png||thumb|center|300px|Schéma des connecteur USB]]<br />
=== Connecteur ISP ===<br />
Pour charger le bootloader sur le microcontrôleur si besoin.[[Fichier:Connecteur ISP.png||thumb|center|300px|Schéma du connecteur ISP]]<br />
=== Diodes Électroluminescentes ===<br />
[[Fichier:LED voiture.png||thumb|center|300px|Schéma des LEDS]]<br />
<br />
== PCB et routage : ==<br />
Après avoir fini toutes nos fonctions et le schéma, nous nous sommes attaqué au PCB de la carte, il nous a fallu quelque essais pour obtenir une disposition qui nous convienne et qui facilite le routage.[[Fichier:Vue3D.png||thumb|left|300px|Vue 3D de la carte]]<br />
[[Fichier:PCB voiture.png||thumb|center|300px|PCB routé de la carte]]<br />
<br />
<br />
<br />
== Brasage des composants ==<br />
Une fois les cartes reçues, nous nous sommes attaqués à la brasure des différents composants. Nous avons commencé par le microcontrôleur, le cristal et les résistances et capacités associées. Dès le départ nous avons eu des problèmes avec le brasage, des pattes soudées entre elles, le cristal mal posé. Mais notre plus gros problème a été l'allocation des pins du microcontrôleur. Nous ne le savions pas au moment de la création de notre PCB et nous n'y avons pas fait attention, mais des pins sont spécialement attribuées au MISO, MOSI et SOCKET. Pins que nous devons utilisés pour envoyer le bootloader sur la microcontrôleur via le programmateur ISP (en orange sur le schéma). Nous avons donc dû improviser une solution. Nous avons coupé les pistes et relié par des fils les broches de l'ISP aux pins correspondantes. À cause de cette erreur nos LEDs D2 et D3 ne sont plus utilisables.<br />
<br />
[[Fichier:Atmega pin mosi.png|thumb|center|800x|Pins de l'atmega utilisés pour l'ISP]]<br />
<br />
<br />
<br />
Une fois ce problème réglé, nous avons pu passer à la suite, la gestion des moteurs. Pour ce faire il n'y a pas eu autant de problèmes que sur la partie microcontrôleur, nous avons simplement soudé le contrôleur de moteurs, un TB6612FNG, puis les broches sur lesquelles nous allons venir brancher les moteurs, et enfin les fils directement sur les broches des moteurs. Nous avons également utilisé du plastique thermo rétractable pour que les fils soient protégés et restent soudés aux moteurs durant toute la durée du projet. Les moteurs étant prêt à l'emploi, nous les avons testé pour savoir si tout était fonctionnelle. Une fois confirmé, ayant en tête le contexte écologique actuel, nous avons pris des bouchons de bouteilles comme roues et mis des élastiques autour pour avoir de la traction lors de nos différents essais.<br />
<br />
[[Fichier:Moteur et roues.jpg|thumb|center|300px|Moteurs et roues]]<br />
<br />
Pour tester toute notre carte, nous avons créé un code sous le nom de helloworld.c qui rempli différente fonctions (disponible sur le GIT), allumer ou faire clignoter les LEDs en fonction du déplacement de la voiture et, bien évidemment, déplacer la voiture. La voiture réagissant comme nous le souhaitons, nous décidons donc de passer à l'étape suivante, le fonctionnement sur batterie. Ce n'est pas la partie la plus compliquée, il suffit de braser les broches permettant d'accueillir la batterie puis celles destinées au cavalier. Une fois le tout installé sur notre carte, nous la testons et tout fonctionne normalement. <syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#define __DELAY_BACKWARD_COMPATIBLE__<br />
#include <util/delay.h><br />
<br />
#define PWM1 PB7<br />
#define PWM2 PD0<br />
#define AIN1 PF6<br />
#define AIN2 PF7<br />
#define BIN1 PF4<br />
#define BIN2 PF1<br />
#define STBY PF5<br />
#define D3 PB0<br />
#define D2 PE6<br />
#define D6 PC6<br />
#define D7 PC7<br />
#define D8 PD4<br />
#define D9 PD6<br />
#define START PF0<br />
<br />
<br />
void blink_droit()<br />
{<br />
for(int i = 0; i<50; i++)<br />
{<br />
PORTB |= (1<<D3);<br />
PORTC |= (1<< D7);<br />
_delay_ms(200);<br />
PORTB &= ~(1<<D3);<br />
PORTC &= ~(1<< D7);<br />
_delay_ms(200);<br />
}<br />
}<br />
<br />
void blink_gauche()<br />
{<br />
for(int i = 0; i<50; i++)<br />
{<br />
PORTD |= (1<<D8);<br />
_delay_ms(200);<br />
PORTD &= ~(1<<D8);<br />
_delay_ms(200);<br />
}<br />
}<br />
<br />
void avancer(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN2) | (1<< BIN1) | (1<< STBY);<br />
PORTF &= ~(1<< AIN1);<br />
PORTF &= ~(1<< BIN2);<br />
PORTE |= (1<< D2);<br />
PORTD |= (1<<PWM2);<br />
_delay_ms(time);<br />
PORTE &= ~(1<< D2);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
void reculer(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN1) | (1<< BIN2) | (1<< STBY);<br />
PORTF &= ~(1<< AIN2);<br />
PORTC |= (1<< D6);<br />
PORTF &= ~(1<< BIN1);<br />
PORTD |= (1<<PWM2) | (1<< D9);<br />
_delay_ms(time);<br />
PORTC &= ~(1<< D6);<br />
PORTD &= ~(1<< D9);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
void gauche(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN1) | (1<< BIN1) | (1<< STBY);<br />
PORTF &= ~(1<< AIN2);<br />
PORTF &= ~(1<< BIN2);<br />
PORTD |= (1<<PWM2);<br />
// blink_gauche();<br />
_delay_ms(time);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
void droite(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN2) | (1<< BIN2) | (1<< STBY);<br />
PORTF &= ~(1<< AIN1);<br />
PORTF &= ~(1<< BIN1);<br />
PORTD |= (1<<PWM2);<br />
// blink_droit();<br />
_delay_ms(time);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
int main()<br />
{<br />
uint16_t time = 4000, half = 1200, full = 2400;<br />
CLKSEL0 = 0b00010101;<br />
CLKSEL1 = 0b00001111;<br />
CLKPR = 0b10000000;<br />
CLKPR = 0;<br />
<br />
MCUCR |= (1<<JTD);<br />
MCUCR |= (1<<JTD);<br />
<br />
<br />
DDRB |= (1<< PWM1) | (1<< PB0);<br />
DDRF |= (1<< AIN1) | (1<< AIN2) | (1<< BIN1) | (1<<BIN2) | (1<< STBY);<br />
DDRF &= ~(1<<START);<br />
PORTF |= (1<<START);<br />
DDRD |= (1<< PWM2) | (1<< D8) | (1<< D9);<br />
DDRE |= (1<< D2);<br />
DDRC |= (1<< D6) | (1<< D7);<br />
<br />
while(1)<br />
{<br />
if(~(PINF>>START) & 1)<br />
{<br />
avancer(time);<br />
_delay_ms(1000);<br />
reculer(time);<br />
_delay_ms(1000);<br />
gauche(half);<br />
_delay_ms(1000);<br />
droite(full);<br />
_delay_ms(1000);<br />
}<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight>[[Fichier:LED allumée sur batterie.jpg|thumb|left|150px|LED allumée en fonctionnement sur batterie]]<br />
[[Fichier:Voiture appui bouton.mp4|thumb|center|Voiture fonctionnant sur batterie]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Comme il nous reste encore un peu de temps, nous décidons de nous attaquer à la dernière partie, la recharge de la batterie. Comme pour la partie de fonctionnement sur batterie, il n'y a aucune partie de code, il suffit de souder des composants en plus sur la carte pour que la nouvelle fonctionnalité soit active. Donc nous nous y sommes mis et encore une fois il n'y a aucun problème.<br />
<br />
<br />
<br />
<br />
[[Fichier:Voiture déchargée.mp4|thumb|left|500px|Voiture déchargée]]<br />
[[Fichier:Voiture en charge.mp4|thumb|center|500px|Voiture en charge]]<br />
[[Fichier:Voiture après recharge.mp4|thumb|center|500px|Voiture après recharge]]<br />
<br />
<br />
== CONCLUSION ==<br />
Lors de ce projet, nous avons pu acquérir des compétences de base dans la Conception Assistée par Ordinateur et nous avons appris beaucoup sur la manière dont un système embarqué fonctionne précisément, notamment sur le fonctionnement nomade. Grâce à nos erreurs concernant l'attribution de certains PINs (les PINs MISO MOSI et SLK, et la non utilisation de port adaptés au PWM pour le réglage de la puissance délivrée par les moteurs), nous avons compris l'extrême importance de porter la plus grande attention à la CAO, pour éviter d'avoir de gros problèmes par la suite. Nous avons tout de même réussi à atteindre les objectifs fixés dans les temps, et l'intégralité des modules présents sur la carte ont bien été intégrés sur le prototype.<br />
<br />
<br />
== GIT ==<br />
Vous trouverez dans le lien [https://archives.plil.fr/rboursau/premier-systeme-embarque.git GIT] de notre projet, tous les fichiers de création de la carte se trouvent dans le dossier projet_voiture, le code envoyé pour tester la voiture dans le dossier cod.</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3Binome2023-5&diff=5642SE3Binome2023-52024-06-12T15:34:11Z<p>Rboursau : </p>
<hr />
<div>= Projet Groupe 5 : Voiture Programmable =<br />
Cette page est consacrée à la présentation du projet SE3 réalisé par BOURSAULT Rémi & LECOMTE Antoine, qui est porté sur la création d'une voiture contrôlé par programmation.<br />
<br />
== Présentation : ==<br />
<br />
=== Objectifs ===<br />
Les objectifs du projets sont : <br />
<br />
* Concevoir une voiture fonctionnant sur batterie, avec un ATMega.<br />
* Intégrer des clignotants fonctionnels.<br />
* Permettre à la voiture d'avancer ou reculer, toujours en utilisant l'ATMega.<br />
* Ajout d'un gyrophare.<br />
<br />
=== Ressources ===<br />
Pour atteindre ces différents objectifs, nous aurons besoins des ressources suivantes :<br />
<br />
* Un microcontrôleur ATMega16U4/ATMega32U4<br />
* Des LEDS<br />
* Deux moteurs à courant continu<br />
* Un châssis <br />
* Des dipôles classiques<br />
* Un gyrophare<br />
<br />
<br />
<br />
Après avoir choisi notre projet et nos différents objectifs pour ce projet, nous avons commencé à travailler sur le schéma de montage sur KiCAD afin de pouvoir ensuite faire le PCB et le routage qui sera envoyé à une usine pour imprimer nos cartes. Les fonctions et composants principaux de notre projet sont les suivants.<br />
<br />
== Fonction sur le schéma : ==<br />
<br />
<br />
=== Microcontrôleur ===<br />
La partie indispensable de tous montages électroniques, le cerveau de la voiture. Sans le microcontrôleur rien dans ce projet n'est possible, il permet de gérer les informations. qui sont transmises dans toutes la carte. C'est un microcontrôleur ATMega32u4, ce n'est pas le plus puissant, mais pour la taille du projet que nous faisons c'est bien assez. Il possède assez d'entrées/sorties pour ce que nous voulons en faire.[[Fichier:Microcontroleu.png||thumb|left|300px|Schéma du microcontrôleur]]<br />
[[Fichier:Pin configuration atmega.png||thumb|center|300px|Configuration des pins sur l'atmega]]<br />
<br />
=== Commande Moteur ===<br />
Ce bloc est celui qui actionne les moteurs et leur dit quand s'arrêter. Celui-ci est composé d'un TB6612FNG, un driver pour moteur qui ne sert qu'à ça. Il prend sept signaux en entrée trois pour gérer chaque moteur et un signal de standby. Nous avons utilisé la datasheet pour savoir comment le schématiser et quels composants utilisé pour que celui-ci fonctionne dans des conditions optimales. <br />
<br />
Il est nécessaire d'ajouter ce composant, car les signaux de sortie délivrés par l'ATMega sont trop faibles pour alimenter un moteur. Ce driver vient, à partir d'une tension d'alimentation Vcc amplifier le signal de commande délivré par l'ATMega pour que les moteurs aient l'alimentation adéquate. <br />
<br />
<br />
<br />
<br />
[[Fichier:Datasheet TB6612.png||thumb|left|300px|PCB routé de la carte]]<br />
[[Fichier:Commande Moteur.png||thumb|center|300px|Schéma du bloc de commande des moteurs]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
=== Chargeur LI-PO ===<br />
Comme notre voiture fonctionnera sur batterie, il faut un moyen de la recharger, ceci se faisant par l'intermédiaire d'un port USB, il faut un bloc pour adapter le courant que reçoit l'USB pour que cela corresponde aux caractéristiques de notre batterie.<br />
<br />
<br />
[[Fichier:Chargeur lipo.png||thumb|center|300px|Schéma du chargeur]]<br />
<br />
<br />
=== Utilisation de la Batterie ===<br />
Ce bloc permet de séparer l'alimentation en USB et sur batterie. Lorsqu'un cavalier est présent sur J6, VBAT est directement relié à Vcc et ainsi la batterie sert d'alimentation pour la carte. Il est impératif de débrancher l'USB avant de mettre le cavalier, pour éviter tout court-circuit. Lorsqu'on enlève le cavalier, on peut brancher l'USB et la carte fonctionne en filaire.[[Fichier:Utilisation baterie.png||thumb|center|300px|Schéma du switch batterie]]<br />
=== Connecteur USB ===<br />
On dispose de deux connecteurs USB, un pour recharger la batterie, et un autre pour transmettre les données, qui servira à implanter un programme dans notre microcontrôleur.[[Fichier:Connecteur USBs.png||thumb|center|300px|Schéma des connecteur USB]]<br />
=== Connecteur ISP ===<br />
Pour charger le bootloader sur le microcontrôleur si besoin.[[Fichier:Connecteur ISP.png||thumb|center|300px|Schéma du connecteur ISP]]<br />
=== Diodes Électroluminescentes ===<br />
[[Fichier:LED voiture.png||thumb|center|300px|Schéma des LEDS]]<br />
<br />
== PCB et routage : ==<br />
Après avoir fini toutes nos fonctions et le schéma, nous nous sommes attaqué au PCB de la carte, il nous a fallu quelque essais pour obtenir une disposition qui nous convienne et qui facilite le routage.[[Fichier:Vue3D.png||thumb|left|300px|Vue 3D de la carte]]<br />
[[Fichier:PCB voiture.png||thumb|center|300px|PCB routé de la carte]]<br />
<br />
<br />
<br />
== Brasage des composants ==<br />
Une fois les cartes reçues, nous nous sommes attaqués à la brasure des différents composants. Nous avons commencé par le microcontrôleur, le cristal et les résistances et capacités associées. Dès le départ nous avons eu des problèmes avec le brasage, des pattes soudées entre elles, le cristal mal posé. Mais notre plus gros problème a été l'allocation des pins du microcontrôleur. Nous ne le savions pas au moment de la création de notre PCB et nous n'y avons pas fait attention, mais des pins sont spécialement attribuées au MISO, MOSI et SOCKET. Pins que nous devons utilisés pour envoyer le bootloader sur la microcontrôleur via le programmateur ISP (en orange sur le schéma). Nous avons donc dû improviser une solution. Nous avons coupé les pistes et relié par des fils les broches de l'ISP aux pins correspondantes. À cause de cette erreur nos LEDs D2 et D3 ne sont plus utilisables.<br />
<br />
[[Fichier:Atmega pin mosi.png|thumb|center|800x|Pins de l'atmega utilisés pour l'ISP]]<br />
<br />
<br />
<br />
Une fois ce problème réglé, nous avons pu passer à la suite, la gestion des moteurs. Pour ce faire il n'y a pas eu autant de problèmes que sur la partie microcontrôleur, nous avons simplement soudé le contrôleur de moteurs, un TB6612FNG, puis les broches sur lesquelles nous allons venir brancher les moteurs, et enfin les fils directement sur les broches des moteurs. Nous avons également utilisé du plastique thermo rétractable pour que les fils soient protégés et restent soudés aux moteurs durant toute la durée du projet. Les moteurs étant prêt à l'emploi, nous les avons testé pour savoir si tout était fonctionnelle. Une fois confirmé, ayant en tête le contexte écologique actuel, nous avons pris des bouchons de bouteilles comme roues et mis des élastiques autour pour avoir de la traction lors de nos différents essais.<br />
<br />
[[Fichier:Moteur et roues.jpg|thumb|center|300px|Moteurs et roues]]<br />
<br />
Pour tester toute notre carte, nous avons créé un code sous le nom de helloworld.c qui rempli différente fonctions (disponible sur le GIT), allumer ou faire clignoter les LEDs en fonction du déplacement de la voiture et, bien évidemment, déplacer la voiture. La voiture réagissant comme nous le souhaitons, nous décidons donc de passer à l'étape suivante, le fonctionnement sur batterie. Ce n'est pas la partie la plus compliquée, il suffit de braser les broches permettant d'accueillir la batterie puis celles destinées au cavalier. Une fois le tout installé sur notre carte, nous la testons et tout fonctionne normalement. <syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#define __DELAY_BACKWARD_COMPATIBLE__<br />
#include <util/delay.h><br />
<br />
#define PWM1 PB7<br />
#define PWM2 PD0<br />
#define AIN1 PF6<br />
#define AIN2 PF7<br />
#define BIN1 PF4<br />
#define BIN2 PF1<br />
#define STBY PF5<br />
#define D3 PB0<br />
#define D2 PE6<br />
#define D6 PC6<br />
#define D7 PC7<br />
#define D8 PD4<br />
#define D9 PD6<br />
#define START PF0<br />
<br />
<br />
void blink_droit()<br />
{<br />
for(int i = 0; i<50; i++)<br />
{<br />
PORTB |= (1<<D3);<br />
PORTC |= (1<< D7);<br />
_delay_ms(200);<br />
PORTB &= ~(1<<D3);<br />
PORTC &= ~(1<< D7);<br />
_delay_ms(200);<br />
}<br />
}<br />
<br />
void blink_gauche()<br />
{<br />
for(int i = 0; i<50; i++)<br />
{<br />
PORTD |= (1<<D8);<br />
_delay_ms(200);<br />
PORTD &= ~(1<<D8);<br />
_delay_ms(200);<br />
}<br />
}<br />
<br />
void avancer(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN2) | (1<< BIN1) | (1<< STBY);<br />
PORTF &= ~(1<< AIN1);<br />
PORTF &= ~(1<< BIN2);<br />
PORTE |= (1<< D2);<br />
PORTD |= (1<<PWM2);<br />
_delay_ms(time);<br />
PORTE &= ~(1<< D2);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
void reculer(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN1) | (1<< BIN2) | (1<< STBY);<br />
PORTF &= ~(1<< AIN2);<br />
PORTC |= (1<< D6);<br />
PORTF &= ~(1<< BIN1);<br />
PORTD |= (1<<PWM2) | (1<< D9);<br />
_delay_ms(time);<br />
PORTC &= ~(1<< D6);<br />
PORTD &= ~(1<< D9);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
void gauche(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN1) | (1<< BIN1) | (1<< STBY);<br />
PORTF &= ~(1<< AIN2);<br />
PORTF &= ~(1<< BIN2);<br />
PORTD |= (1<<PWM2);<br />
// blink_gauche();<br />
_delay_ms(time);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
void droite(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN2) | (1<< BIN2) | (1<< STBY);<br />
PORTF &= ~(1<< AIN1);<br />
PORTF &= ~(1<< BIN1);<br />
PORTD |= (1<<PWM2);<br />
// blink_droit();<br />
_delay_ms(time);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
int main()<br />
{<br />
uint16_t time = 4000, half = 1200, full = 2400;<br />
CLKSEL0 = 0b00010101;<br />
CLKSEL1 = 0b00001111;<br />
CLKPR = 0b10000000;<br />
CLKPR = 0;<br />
<br />
MCUCR |= (1<<JTD);<br />
MCUCR |= (1<<JTD);<br />
<br />
<br />
DDRB |= (1<< PWM1) | (1<< PB0);<br />
DDRF |= (1<< AIN1) | (1<< AIN2) | (1<< BIN1) | (1<<BIN2) | (1<< STBY);<br />
DDRF &= ~(1<<START);<br />
PORTF |= (1<<START);<br />
DDRD |= (1<< PWM2) | (1<< D8) | (1<< D9);<br />
DDRE |= (1<< D2);<br />
DDRC |= (1<< D6) | (1<< D7);<br />
<br />
while(1)<br />
{<br />
if(~(PINF>>START) & 1)<br />
{<br />
avancer(time);<br />
_delay_ms(1000);<br />
reculer(time);<br />
_delay_ms(1000);<br />
gauche(half);<br />
_delay_ms(1000);<br />
droite(full);<br />
_delay_ms(1000);<br />
}<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight>[[Fichier:LED allumée sur batterie.jpg|thumb|left|150px|LED allumée en fonctionnement sur batterie]]<br />
[[Fichier:Voiture appui bouton.mp4|thumb|center|Voiture fonctionnant sur batterie]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Comme il nous reste encore un peu de temps, nous décidons de nous attaquer à la dernière partie, la recharge de la batterie. Comme pour la partie de fonctionnement sur batterie, il n'y a aucune partie de code, il suffit de souder des composants en plus sur la carte pour que la nouvelle fonctionnalité soit active. Donc nous nous y sommes mis et encore une fois il n'y a aucun problème.<br />
<br />
<br />
<br />
<br />
[[Fichier:Voiture déchargée.mp4|thumb|left|500px|Voiture déchargée]]<br />
[[Fichier:Voiture en charge.mp4|thumb|center|500px|Voiture en charge]]<br />
[[Fichier:Voiture après recharge.mp4|thumb|left|500px|Voiture après recharge]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
== CONCLUSION ==<br />
Lors de ce projet, nous avons pu acquérir des compétences de base dans la Conception Assistée par Ordinateur et nous avons appris beaucoup sur la manière dont un système embarqué fonctionne précisément, notamment sur le fonctionnement nomade. Grâce à nos erreurs concernant l'attribution de certains PINs (les PINs MISO MOSI et SLK, et la non utilisation de port adaptés au PWM pour le réglage de la puissance délivrée par les moteurs), nous avons compris l'extrême importance de porter la plus grande attention à la CAO, pour éviter d'avoir de gros problèmes par la suite. Nous avons tout de même réussi à atteindre les objectifs fixés dans les temps, et l'intégralité des modules présents sur la carte ont bien été intégrés sur le prototype.<br />
<br />
<br />
== GIT ==<br />
Vous trouverez dans le lien [https://archives.plil.fr/rboursau/premier-systeme-embarque.git GIT] de notre projet, tous les fichiers de création de la carte se trouvent dans le dossier projet_voiture, le code envoyé pour tester la voiture dans le dossier cod.</div>Rboursauhttps://projets-se.plil.fr/mediawiki/index.php?title=SE3Binome2023-5&diff=5641SE3Binome2023-52024-06-12T15:34:00Z<p>Rboursau : </p>
<hr />
<div>= Projet Groupe 5 : Voiture Programmable =<br />
Cette page est consacrée à la présentation du projet SE3 réalisé par BOURSAULT Rémi & LECOMTE Antoine, qui est porté sur la création d'une voiture contrôlé par programmation.<br />
<br />
== Présentation : ==<br />
<br />
=== Objectifs ===<br />
Les objectifs du projets sont : <br />
<br />
* Concevoir une voiture fonctionnant sur batterie, avec un ATMega.<br />
* Intégrer des clignotants fonctionnels.<br />
* Permettre à la voiture d'avancer ou reculer, toujours en utilisant l'ATMega.<br />
* Ajout d'un gyrophare.<br />
<br />
=== Ressources ===<br />
Pour atteindre ces différents objectifs, nous aurons besoins des ressources suivantes :<br />
<br />
* Un microcontrôleur ATMega16U4/ATMega32U4<br />
* Des LEDS<br />
* Deux moteurs à courant continu<br />
* Un châssis <br />
* Des dipôles classiques<br />
* Un gyrophare<br />
<br />
<br />
<br />
Après avoir choisi notre projet et nos différents objectifs pour ce projet, nous avons commencé à travailler sur le schéma de montage sur KiCAD afin de pouvoir ensuite faire le PCB et le routage qui sera envoyé à une usine pour imprimer nos cartes. Les fonctions et composants principaux de notre projet sont les suivants.<br />
<br />
== Fonction sur le schéma : ==<br />
<br />
<br />
=== Microcontrôleur ===<br />
La partie indispensable de tous montages électroniques, le cerveau de la voiture. Sans le microcontrôleur rien dans ce projet n'est possible, il permet de gérer les informations. qui sont transmises dans toutes la carte. C'est un microcontrôleur ATMega32u4, ce n'est pas le plus puissant, mais pour la taille du projet que nous faisons c'est bien assez. Il possède assez d'entrées/sorties pour ce que nous voulons en faire.[[Fichier:Microcontroleu.png||thumb|left|300px|Schéma du microcontrôleur]]<br />
[[Fichier:Pin configuration atmega.png||thumb|center|300px|Configuration des pins sur l'atmega]]<br />
<br />
=== Commande Moteur ===<br />
Ce bloc est celui qui actionne les moteurs et leur dit quand s'arrêter. Celui-ci est composé d'un TB6612FNG, un driver pour moteur qui ne sert qu'à ça. Il prend sept signaux en entrée trois pour gérer chaque moteur et un signal de standby. Nous avons utilisé la datasheet pour savoir comment le schématiser et quels composants utilisé pour que celui-ci fonctionne dans des conditions optimales. <br />
<br />
Il est nécessaire d'ajouter ce composant, car les signaux de sortie délivrés par l'ATMega sont trop faibles pour alimenter un moteur. Ce driver vient, à partir d'une tension d'alimentation Vcc amplifier le signal de commande délivré par l'ATMega pour que les moteurs aient l'alimentation adéquate. <br />
<br />
<br />
<br />
<br />
[[Fichier:Datasheet TB6612.png||thumb|left|300px|PCB routé de la carte]]<br />
[[Fichier:Commande Moteur.png||thumb|center|300px|Schéma du bloc de commande des moteurs]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
=== Chargeur LI-PO ===<br />
Comme notre voiture fonctionnera sur batterie, il faut un moyen de la recharger, ceci se faisant par l'intermédiaire d'un port USB, il faut un bloc pour adapter le courant que reçoit l'USB pour que cela corresponde aux caractéristiques de notre batterie.<br />
<br />
<br />
[[Fichier:Chargeur lipo.png||thumb|center|300px|Schéma du chargeur]]<br />
<br />
<br />
=== Utilisation de la Batterie ===<br />
Ce bloc permet de séparer l'alimentation en USB et sur batterie. Lorsqu'un cavalier est présent sur J6, VBAT est directement relié à Vcc et ainsi la batterie sert d'alimentation pour la carte. Il est impératif de débrancher l'USB avant de mettre le cavalier, pour éviter tout court-circuit. Lorsqu'on enlève le cavalier, on peut brancher l'USB et la carte fonctionne en filaire.[[Fichier:Utilisation baterie.png||thumb|center|300px|Schéma du switch batterie]]<br />
=== Connecteur USB ===<br />
On dispose de deux connecteurs USB, un pour recharger la batterie, et un autre pour transmettre les données, qui servira à implanter un programme dans notre microcontrôleur.[[Fichier:Connecteur USBs.png||thumb|center|300px|Schéma des connecteur USB]]<br />
=== Connecteur ISP ===<br />
Pour charger le bootloader sur le microcontrôleur si besoin.[[Fichier:Connecteur ISP.png||thumb|center|300px|Schéma du connecteur ISP]]<br />
=== Diodes Électroluminescentes ===<br />
[[Fichier:LED voiture.png||thumb|center|300px|Schéma des LEDS]]<br />
<br />
== PCB et routage : ==<br />
Après avoir fini toutes nos fonctions et le schéma, nous nous sommes attaqué au PCB de la carte, il nous a fallu quelque essais pour obtenir une disposition qui nous convienne et qui facilite le routage.[[Fichier:Vue3D.png||thumb|left|300px|Vue 3D de la carte]]<br />
[[Fichier:PCB voiture.png||thumb|center|300px|PCB routé de la carte]]<br />
<br />
<br />
<br />
== Brasage des composants ==<br />
Une fois les cartes reçues, nous nous sommes attaqués à la brasure des différents composants. Nous avons commencé par le microcontrôleur, le cristal et les résistances et capacités associées. Dès le départ nous avons eu des problèmes avec le brasage, des pattes soudées entre elles, le cristal mal posé. Mais notre plus gros problème a été l'allocation des pins du microcontrôleur. Nous ne le savions pas au moment de la création de notre PCB et nous n'y avons pas fait attention, mais des pins sont spécialement attribuées au MISO, MOSI et SOCKET. Pins que nous devons utilisés pour envoyer le bootloader sur la microcontrôleur via le programmateur ISP (en orange sur le schéma). Nous avons donc dû improviser une solution. Nous avons coupé les pistes et relié par des fils les broches de l'ISP aux pins correspondantes. À cause de cette erreur nos LEDs D2 et D3 ne sont plus utilisables.<br />
<br />
[[Fichier:Atmega pin mosi.png|thumb|center|800x|Pins de l'atmega utilisés pour l'ISP]]<br />
<br />
<br />
<br />
Une fois ce problème réglé, nous avons pu passer à la suite, la gestion des moteurs. Pour ce faire il n'y a pas eu autant de problèmes que sur la partie microcontrôleur, nous avons simplement soudé le contrôleur de moteurs, un TB6612FNG, puis les broches sur lesquelles nous allons venir brancher les moteurs, et enfin les fils directement sur les broches des moteurs. Nous avons également utilisé du plastique thermo rétractable pour que les fils soient protégés et restent soudés aux moteurs durant toute la durée du projet. Les moteurs étant prêt à l'emploi, nous les avons testé pour savoir si tout était fonctionnelle. Une fois confirmé, ayant en tête le contexte écologique actuel, nous avons pris des bouchons de bouteilles comme roues et mis des élastiques autour pour avoir de la traction lors de nos différents essais.<br />
<br />
[[Fichier:Moteur et roues.jpg|thumb|center|300px|Moteurs et roues]]<br />
<br />
Pour tester toute notre carte, nous avons créé un code sous le nom de helloworld.c qui rempli différente fonctions (disponible sur le GIT), allumer ou faire clignoter les LEDs en fonction du déplacement de la voiture et, bien évidemment, déplacer la voiture. La voiture réagissant comme nous le souhaitons, nous décidons donc de passer à l'étape suivante, le fonctionnement sur batterie. Ce n'est pas la partie la plus compliquée, il suffit de braser les broches permettant d'accueillir la batterie puis celles destinées au cavalier. Une fois le tout installé sur notre carte, nous la testons et tout fonctionne normalement. <syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#define __DELAY_BACKWARD_COMPATIBLE__<br />
#include <util/delay.h><br />
<br />
#define PWM1 PB7<br />
#define PWM2 PD0<br />
#define AIN1 PF6<br />
#define AIN2 PF7<br />
#define BIN1 PF4<br />
#define BIN2 PF1<br />
#define STBY PF5<br />
#define D3 PB0<br />
#define D2 PE6<br />
#define D6 PC6<br />
#define D7 PC7<br />
#define D8 PD4<br />
#define D9 PD6<br />
#define START PF0<br />
<br />
<br />
void blink_droit()<br />
{<br />
for(int i = 0; i<50; i++)<br />
{<br />
PORTB |= (1<<D3);<br />
PORTC |= (1<< D7);<br />
_delay_ms(200);<br />
PORTB &= ~(1<<D3);<br />
PORTC &= ~(1<< D7);<br />
_delay_ms(200);<br />
}<br />
}<br />
<br />
void blink_gauche()<br />
{<br />
for(int i = 0; i<50; i++)<br />
{<br />
PORTD |= (1<<D8);<br />
_delay_ms(200);<br />
PORTD &= ~(1<<D8);<br />
_delay_ms(200);<br />
}<br />
}<br />
<br />
void avancer(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN2) | (1<< BIN1) | (1<< STBY);<br />
PORTF &= ~(1<< AIN1);<br />
PORTF &= ~(1<< BIN2);<br />
PORTE |= (1<< D2);<br />
PORTD |= (1<<PWM2);<br />
_delay_ms(time);<br />
PORTE &= ~(1<< D2);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
void reculer(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN1) | (1<< BIN2) | (1<< STBY);<br />
PORTF &= ~(1<< AIN2);<br />
PORTC |= (1<< D6);<br />
PORTF &= ~(1<< BIN1);<br />
PORTD |= (1<<PWM2) | (1<< D9);<br />
_delay_ms(time);<br />
PORTC &= ~(1<< D6);<br />
PORTD &= ~(1<< D9);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
void gauche(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN1) | (1<< BIN1) | (1<< STBY);<br />
PORTF &= ~(1<< AIN2);<br />
PORTF &= ~(1<< BIN2);<br />
PORTD |= (1<<PWM2);<br />
// blink_gauche();<br />
_delay_ms(time);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
void droite(int time)<br />
{<br />
PORTB |= (1<< PWM1);<br />
PORTF |= (1<< AIN2) | (1<< BIN2) | (1<< STBY);<br />
PORTF &= ~(1<< AIN1);<br />
PORTF &= ~(1<< BIN1);<br />
PORTD |= (1<<PWM2);<br />
// blink_droit();<br />
_delay_ms(time);<br />
PORTF &= ~(1<< STBY);<br />
}<br />
<br />
int main()<br />
{<br />
uint16_t time = 4000, half = 1200, full = 2400;<br />
CLKSEL0 = 0b00010101;<br />
CLKSEL1 = 0b00001111;<br />
CLKPR = 0b10000000;<br />
CLKPR = 0;<br />
<br />
MCUCR |= (1<<JTD);<br />
MCUCR |= (1<<JTD);<br />
<br />
<br />
DDRB |= (1<< PWM1) | (1<< PB0);<br />
DDRF |= (1<< AIN1) | (1<< AIN2) | (1<< BIN1) | (1<<BIN2) | (1<< STBY);<br />
DDRF &= ~(1<<START);<br />
PORTF |= (1<<START);<br />
DDRD |= (1<< PWM2) | (1<< D8) | (1<< D9);<br />
DDRE |= (1<< D2);<br />
DDRC |= (1<< D6) | (1<< D7);<br />
<br />
while(1)<br />
{<br />
if(~(PINF>>START) & 1)<br />
{<br />
avancer(time);<br />
_delay_ms(1000);<br />
reculer(time);<br />
_delay_ms(1000);<br />
gauche(half);<br />
_delay_ms(1000);<br />
droite(full);<br />
_delay_ms(1000);<br />
}<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight>[[Fichier:LED allumée sur batterie.jpg|thumb|left|150px|LED allumée en fonctionnement sur batterie]]<br />
[[Fichier:Voiture appui bouton.mp4|thumb|center|Voiture fonctionnant sur batterie]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Comme il nous reste encore un peu de temps, nous décidons de nous attaquer à la dernière partie, la recharge de la batterie. Comme pour la partie de fonctionnement sur batterie, il n'y a aucune partie de code, il suffit de souder des composants en plus sur la carte pour que la nouvelle fonctionnalité soit active. Donc nous nous y sommes mis et encore une fois il n'y a aucun problème.<br />
<br />
<br />
<br />
<br />
[[Fichier:Voiture déchargée.mp4|thumb|left|500px|Voiture déchargée]]<br />
[[Fichier:Voiture en charge.mp4|thumb|center|500px|Voiture en charge]]<br />
[[Fichier:Voiture après recharge.mp4|thumb|left|500px|Voiture après recharge]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
== CONCLUSION ==<br />
Lors de ce projet, nous avons pu acquérir des compétences de base dans la Conception Assistée par Ordinateur et nous avons appris beaucoup sur la manière dont un système embarqué fonctionne précisément, notamment sur le fonctionnement nomade. Grâce à nos erreurs concernant l'attribution de certains PINs (les PINs MISO MOSI et SLK, et la non utilisation de port adaptés au PWM pour le réglage de la puissance délivrée par les moteurs), nous avons compris l'extrême importance de porter la plus grande attention à la CAO, pour éviter d'avoir de gros problèmes par la suite. Nous avons tout de même réussi à atteindre les objectifs fixés dans les temps, et l'intégralité des modules présents sur la carte ont bien été intégrés sur le prototype.<br />
<br />
<br />
== GIT ==<br />
Vous trouverez dans le lien [https://archives.plil.fr/rboursau/premier-systeme-embarque.git GIT] de notre projet, tous les fichiers de création de la carte se trouvent dans le dossier projet_voiture, le code envoyé pour tester la voiture dans le dossier cod.</div>Rboursau