SE4Binome2024-7 - Historique des versions

Rex : /* Envoi de paquet */

2025-01-30T21:37:50Z

Envoi de paquet

← Version précédente		Version du 30 janvier 2025 à 21:37
Ligne 224 :		Ligne 224 :
	![[Fichier:Packetwitdata.png\|vignette\|449x449px]]		![[Fichier:Packetwitdata.png\|vignette\|449x449px]]
	\|}		\|}
	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.		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ère 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.

Rex : /* Envoi de paquet */

2025-01-30T21:36:47Z

Envoi de paquet

← Version précédente		Version du 30 janvier 2025 à 21:36
Ligne 217 :		Ligne 217 :

	=== Envoi de paquet ===		=== Envoi de paquet ===
	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.		Maintenant que la carte est capable de répondre à un paquet suivant notre protocole, nous crééons une fonction <code>int16_t Proto_SendIPPacket(void*OutDataStart, uint8_t data[MAX_COMMAND])</code> (là 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.

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

Rex : /* Envoi de paquet */

2025-01-30T21:36:14Z

Envoi de paquet

← Version précédente		Version du 30 janvier 2025 à 21:36
Ligne 217 :		Ligne 217 :

	=== Envoi de paquet ===		=== Envoi de paquet ===
	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.		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.

	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.		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.
Ligne 238 :		Ligne 238 :

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

	=== Décodage des paquets de l'ordinateur ===		=== Décodage des paquets de l'ordinateur ===
	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".		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".

Rex : /* Modification de ether */

2025-01-30T21:35:51Z

Modification de ether

← Version précédente		Version du 30 janvier 2025 à 21:35
Ligne 207 :		Ligne 207 :

	=== Modification de ether ===		=== Modification de ether ===
	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.		On doit, dans bpf.c, remplacer le protocole 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.
	{\| class="wikitable"		{\| class="wikitable"
	\|+		\|+

Rex : /* Création du protocole */

2025-01-30T21:31:50Z

Création du protocole

← Version précédente		Version du 30 janvier 2025 à 21:31
Ligne 200 :		Ligne 200 :
	<nowiki>#</nowiki>define ETHERTYPE_PROTO 0x8888		<nowiki>#</nowiki>define ETHERTYPE_PROTO 0x8888

	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.		dans EthernetProtocols.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.

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

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

	=== Modification de ether ===		=== Modification de ether ===

Rex : /* Erreur de design */

2025-01-30T21:28:34Z

Erreur de design

← Version précédente		Version du 30 janvier 2025 à 21:28
Ligne 294 :		Ligne 294 :
	\|+		\|+
	![[Fichier:PIN ALIM non connecté.png\|alt=PIN ALIM non connecté\|vignette\|PIN ALIM non connecté]]		![[Fichier:PIN ALIM non connecté.png\|alt=PIN ALIM non connecté\|vignette\|PIN ALIM non connecté]]
	!Comme vous pouvez l'~~observe~~, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC.		!Comme vous pouvez l'observer, le pin ALIM de notre Carte RNDIS n'est pas connecté avec les pins VCC.
	Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand,		Par conséquent, notre carte carte RNDIS ne peut-être alimentée que quand,

Rex : /* Problèmes rencontrés avec la COMMUNICATION SPI */

2025-01-30T21:26:25Z

Problèmes rencontrés avec la COMMUNICATION SPI

← Version précédente		Version du 30 janvier 2025 à 21:26
Ligne 139 :		Ligne 139 :
	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>.		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>.
	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.		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.
	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.		Nous avons donc enlevé 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 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.
	{\| class="wikitable"		{\| class="wikitable"
	\|+		\|+

Rex : /* FONCTION DELAY */

2025-01-30T21:23:32Z

FONCTION DELAY

← Version précédente		Version du 30 janvier 2025 à 21:23
Ligne 75 :		Ligne 75 :
	<syntaxhighlight lang="c">		<syntaxhighlight lang="c">
	void delay(int time)		void delay(int time)

	{		{

	TaskList[currentTask].state = SLEEPING;		TaskList[currentTask].state = SLEEPING;

	TaskList[currentTask].data.data.delay = time;		TaskList[currentTask].data.data.delay = time;

	TCNT1 = 0;		TCNT1 = 0;

	TIMER1_COMPA_vect();		TIMER1_COMPA_vect();

	}		}
	</syntaxhighlight>		</syntaxhighlight>

Rex : /* STRUCTURE DES TÂCHES */

2025-01-30T21:22:51Z

STRUCTURE DES TÂCHES

← Version précédente		Version du 30 janvier 2025 à 21:22
Ligne 36 :		Ligne 36 :
	<syntaxhighlight lang="c">		<syntaxhighlight lang="c">
	typedef struct Task {		typedef struct Task {

	void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien		void (*fonction)(void); // Pointeur vers une fonction prenant aucun paramètre et ne retournant rien

	uint16_t SPointer; // Pointeur de pile		uint16_t SPointer; // Pointeur de pile

	int state; // État de la tâche		int state; // État de la tâche

	struct prog_data data; // Données de la tâche		struct prog_data data; // Données de la tâche

	} Task;		} Task;

	struct prog_data {		struct prog_data {

	int Type;		int Type;

	union {		union {

	int delay; // On peut ajouter d'autres types de données ici si nécessaire		int delay; // On peut ajouter d'autres types de données ici si nécessaire

	} data;		} data;

	};		};
	</syntaxhighlight>		</syntaxhighlight>

Rboursau : /* NOTES */

2025-01-26T17:04:52Z

NOTES

← Version précédente		Version du 26 janvier 2025 à 17:04
Ligne 346 :		Ligne 346 :
	\|PC[0-3]		\|PC[0-3]
	\|}		\|}

			== Conclusion ==
			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.

			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.

			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.

			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.

	== NOTES ==		== NOTES ==

SE4Binome2024-7 - Historique des versions

Rex : /* Envoi de paquet */

Rex : /* Envoi de paquet */

Rex : /* Envoi de paquet */

Rex : /* Modification de ether */

Rex : /* Création du protocole */

Rex : /* Erreur de design */

Rex : /* Problèmes rencontrés avec la COMMUNICATION SPI */

Rex : /* FONCTION DELAY */

Rex : /* STRUCTURE DES TÂCHES */

Rboursau : /* NOTES */

Rex : /* Envoi de paquet */

Rex : /* Envoi de paquet */

Rex : /* Envoi de paquet */

Rex : /* Modification de ether */

Rex : /* Création du protocole */

Rex : /* Erreur de design */

Rex : /* Problèmes rencontrés avec la COMMUNICATION SPI */

Rex : /* FONCTION DELAY */

Rex : /* STRUCTURE DES TÂCHES */

Rboursau : /* NOTES */