SE4Binome2024-2 - Historique des versions

Rex : /* Résultat des tests */

2025-01-30T11:40:35Z

Résultat des tests

← Version précédente		Version du 30 janvier 2025 à 11:40
Ligne 395 :		Ligne 395 :

	=== Résultat des tests ===		=== Résultat des tests ===
	* Le premier test (illustré dans l'image ci-dessous) montre que la RAM SPI fonctionne correctement, avec des données transmises et récupérées sans perte. Cependant, on remarque l'apparition de différents symboles avant notre message affiché depuis la RAM. On a donc émis deux hypothèses : => Il existe des zones mémoire de la RAM qui contient des données ne pouvant être modifiées et ce sont ces données là que nous lisons avant notre message. => Notre fonction pour clear la RAM avec des '0' n'est pas bien fonctionnelle. Avec une lecture plus approfondie de la datasheet, il n'est fait nulle part mention d' "une zone interdite" ou quelque chose qui pourrait s'en rapprocher. C'est pourquoi on pense que notre seconde hypothèse est la plus probable malgré une fonction qui, au premier regard, semble correcte.		* Le premier test (illustré dans l'image ci-dessous) montre que la RAM SPI fonctionne correctement, avec des données transmises et récupérées sans perte. Cependant, on remarque l'apparition de différents symboles avant notre message affiché depuis la RAM. On a donc émis deux hypothèses :
			** Il existe des zones mémoire de la RAM qui contient des données ne pouvant être modifiées et ce sont ces données là que nous lisons avant notre message.
			** Notre fonction pour clear la RAM avec des '0' n'est pas bien fonctionnelle.

			Avec une lecture plus approfondie de la datasheet, il n'est fait nulle part mention d' "une zone interdite" ou quelque chose qui pourrait s'en rapprocher. C'est pourquoi on pense que notre seconde hypothèse est la plus probable malgré une fonction qui, au premier regard, semble correcte.

	[[Fichier:Ram fonctionne.png\|centré\|vignette\|527x527px\|La RAM fonctionne]]		[[Fichier:Ram fonctionne.png\|centré\|vignette\|527x527px\|La RAM fonctionne]]
	* Dans une tentative de faire disparaître ces symboles non désirés, nous avons essayé une commande printf de dernier espoir ("Printf ici"). A notre grande surprise, le message de cette commande était directement affiché sur notre écran. Nous avons donc fait des recherches sur ce sujet et il semblerait qu'initialement, il aurait fallu réalisé une fonction de redirection de flux afin de pouvoir visualiser le contenu du print. Or nous n'avons rien réalisé de tel. D'après ce que nous avons trouvé sur Internet, certains dispositif tel que des boards Arduino ou autres, ont directement une fonction de redirection de flux d'implémentée. Nous soupçonnons donc le programmateur ou le microcontrôleur utilisé d'en avoir une également. [[Fichier:Printf.jpg\|centré\|vignette]]
			* Dans une tentative de faire disparaître ces symboles non désirés, nous avons essayé une commande printf de dernier espoir ("Printf ici"). A notre grande surprise, le message de cette commande était directement affiché sur notre écran. Nous avons donc fait des recherches sur ce sujet et il semblerait qu'initialement, il aurait fallu réalisé une fonction de redirection de flux afin de pouvoir visualiser le contenu du print. Or nous n'avons rien réalisé de tel. D'après ce que nous avons trouvé sur Internet, certains dispositif tel que des boards Arduino ou autres, ont directement une fonction de redirection de flux d'implémentée. Nous soupçonnons donc le programmateur ou le microcontrôleur utilisé d'en avoir une également.

			[[Fichier:Printf.jpg\|centré\|vignette]]

	== Conclusion ==		== Conclusion ==

Rex : /* Tests de l'Ordonnanceur */

2025-01-30T11:33:58Z

Tests de l'Ordonnanceur

← Version précédente		Version du 30 janvier 2025 à 11:33
Ligne 306 :		Ligne 306 :
	=== Tests de l'Ordonnanceur ===		=== Tests de l'Ordonnanceur ===
	* Gestion des tâches : Nous avons simulé plusieurs tâches, dont l'affichage et la gestion du clavier, et vérifié que l'ordonnanceur passe correctement d'une tâche à l'autre.		* Gestion des tâches : Nous avons simulé plusieurs tâches, dont l'affichage et la gestion du clavier, et vérifié que l'ordonnanceur passe correctement d'une tâche à l'autre.
	* En utilisant le logiciel minicom nous avons ~~pus~~ lancer une 2eme tâche en parallèle d'une première tâche. En tapant "a" une deuxième LED se met à clignoter.		* En utilisant le logiciel minicom nous avons pu lancer une 2eme tâche en parallèle d'une première tâche. En tapant "a" une deuxième LED se met à clignoter.
	[[Fichier:Videoprocess.mp4\|centré\|vignette\|400x300px\|Test de l'ordonnanceur : lancer une tâche. ]]		[[Fichier:Videoprocess.mp4\|centré\|vignette\|400x300px\|Test de l'ordonnanceur : lancer une tâche. ]]

Rex : /* Fonction `main` */

2025-01-30T11:30:59Z

Fonction `main`

← Version précédente		Version du 30 janvier 2025 à 11:30
Ligne 216 :		Ligne 216 :
	</syntaxhighlight>		</syntaxhighlight>

	1. `cli()` : désactive les interruptions.		# `cli()` : désactive les interruptions.
	2. `LED_init()` et `USART_Init()` : initialisent les LED et la communication série.		# `LED_init()` et `USART_Init()` : initialisent les LED et la communication série.
	3. `init_minuteur()` : initialise le minuteur avec une période.		# `init_minuteur()` : initialise le minuteur avec une période.
	4. `init_pile(i)` : initialise la pile pour chaque tâche.		# `init_pile(i)` : initialise la pile pour chaque tâche.
	5. `sei()` : réactive les interruptions.		# `sei()` : réactive les interruptions.

	L'ordonnanceur gère ainsi le contexte des tâches en suivant une séquence de round-robin, tout en assurant que chaque tâche exécute son cycle de manière autonome et en garantissant la disponibilité des ressources matérielles.		L'ordonnanceur gère ainsi le contexte des tâches en suivant une séquence de round-robin, tout en assurant que chaque tâche exécute son cycle de manière autonome et en garantissant la disponibilité des ressources matérielles.

Mbarret : /* Résultat des tests */

2025-01-26T19:01:58Z

Résultat des tests

← Version précédente		Version du 26 janvier 2025 à 19:01
Ligne 395 :		Ligne 395 :

	=== Résultat des tests ===		=== Résultat des tests ===
	* Le premier test (illustré dans l'image ci-dessous) montre que la RAM SPI fonctionne correctement, avec des données transmises et récupérées sans perte.		* Le premier test (illustré dans l'image ci-dessous) montre que la RAM SPI fonctionne correctement, avec des données transmises et récupérées sans perte. Cependant, on remarque l'apparition de différents symboles avant notre message affiché depuis la RAM. On a donc émis deux hypothèses : => Il existe des zones mémoire de la RAM qui contient des données ne pouvant être modifiées et ce sont ces données là que nous lisons avant notre message. => Notre fonction pour clear la RAM avec des '0' n'est pas bien fonctionnelle. Avec une lecture plus approfondie de la datasheet, il n'est fait nulle part mention d' "une zone interdite" ou quelque chose qui pourrait s'en rapprocher. C'est pourquoi on pense que notre seconde hypothèse est la plus probable malgré une fonction qui, au premier regard, semble correcte.
	[[Fichier:Ram fonctionne.png\|centré\|vignette\|527x527px\|La RAM fonctionne]]		[[Fichier:Ram fonctionne.png\|centré\|vignette\|527x527px\|La RAM fonctionne]]
	* ~~Le deuxième test~~ (~~illustré dans l'image ci-dessous~~) ~~vérifie la stabilité~~ et ~~la cohérence~~ des ~~données sous un~~ flux ~~massif~~ d'~~écritures/lectures répétées~~.[[Fichier:Printf.jpg\|centré\|vignette]]		* Dans une tentative de faire disparaître ces symboles non désirés, nous avons essayé une commande printf de dernier espoir ("Printf ici"). A notre grande surprise, le message de cette commande était directement affiché sur notre écran. Nous avons donc fait des recherches sur ce sujet et il semblerait qu'initialement, il aurait fallu réalisé une fonction de redirection de flux afin de pouvoir visualiser le contenu du print. Or nous n'avons rien réalisé de tel. D'après ce que nous avons trouvé sur Internet, certains dispositif tel que des boards Arduino ou autres, ont directement une fonction de redirection de flux d'implémentée. Nous soupçonnons donc le programmateur ou le microcontrôleur utilisé d'en avoir une également. [[Fichier:Printf.jpg\|centré\|vignette]]

	== Conclusion ==		== Conclusion ==

	=== Tests de la RAM SPI ===		=== Tests de la RAM SPI ===
	La mémoire RAM SPI ne fonctionne pas encore comme prévu ~~pour l’ensemble des tests~~. Malgré nos efforts, nous avons remarqué une chute de tension significative de 1,5 V entre le Shield et la carte écran. Cette chute pourrait expliquer les dysfonctionnements observés dans la communication SPI. Bien que la carte écran fonctionne correctement lorsqu’elle est utilisée seule, elle ne parvient pas à établir une communication via le Shield. Cependant, les différentes étapes de conception et de test nous semblent alignées, et nous pensons être sur la bonne voie pour résoudre ce problème.		La mémoire RAM SPI ne fonctionne pas encore comme prévu avec notamment ces caractères non souhaités.

			Malgré nos efforts, nous avons remarqué une chute de tension significative de 1,5 V entre le Shield et la carte écran. Cette chute pourrait expliquer les dysfonctionnements observés dans la communication SPI. Bien que la carte écran fonctionne correctement lorsqu’elle est utilisée seule, elle ne parvient pas à établir une communication via le Shield. Cependant, les différentes étapes de conception et de test nous semblent alignées, et nous pensons être sur la bonne voie pour résoudre ce problème.

	=== Ordonnanceur et Gestion des Tâches ===		=== Ordonnanceur et Gestion des Tâches ===
Ligne 409 :		Ligne 411 :
	=== Pistes d’amélioration ===		=== Pistes d’amélioration ===
	Pour améliorer le fonctionnement global et résoudre les problèmes liés au SPI, voici quelques pistes à explorer :		Pour améliorer le fonctionnement global et résoudre les problèmes liés au SPI, voici quelques pistes à explorer :
	* Identifier ~~et réduire~~ la chute de tension entre le Shield et la carte écran, éventuellement en vérifiant les connexions, la qualité des câbles ou l’alimentation.		* Identifier la ou les causes de la chute de tension entre le Shield et la carte écran, éventuellement en vérifiant les connexions, la qualité des câbles ou l’alimentation.
	* Tester la communication SPI avec d'autres configurations ou composants pour valider chaque élément individuellement.		* Tester la communication SPI avec d'autres configurations ou composants pour valider chaque élément individuellement.

	En résumé, bien que des défis restent à résoudre pour la partie SPI, nous avons validé l’ensemble des fonctionnalités de l’ordonnanceur. Nous sommes confiants que les ajustements proposés nous permettront d’obtenir un système pleinement fonctionnel.		En résumé, bien que des défis restent à résoudre pour la partie SPI, nous avons validé l’ensemble des fonctionnalités de l’ordonnanceur. Nous sommes confiants que les ajustements proposés nous permettront d’obtenir un système pleinement fonctionnel.

Kelbachi : /* Pistes d’amélioration */

2025-01-26T17:45:32Z

Pistes d’amélioration

← Version précédente		Version du 26 janvier 2025 à 17:45
Ligne 411 :		Ligne 411 :
	* Identifier et réduire la chute de tension entre le Shield et la carte écran, éventuellement en vérifiant les connexions, la qualité des câbles ou l’alimentation.		* Identifier et réduire la chute de tension entre le Shield et la carte écran, éventuellement en vérifiant les connexions, la qualité des câbles ou l’alimentation.
	* Tester la communication SPI avec d'autres configurations ou composants pour valider chaque élément individuellement.		* Tester la communication SPI avec d'autres configurations ou composants pour valider chaque élément individuellement.
	* Ajouter des résistances de pull-up ou pull-down sur les lignes de données SPI si nécessaire pour stabiliser les signaux.
	* Évaluer la fréquence du bus SPI et expérimenter des réglages plus faibles pour limiter les erreurs de transmission dues à des signaux bruyants ou instables.
	* Intégrer un débogage en temps réel en utilisant des outils comme un analyseur logique ou un oscilloscope pour mieux comprendre le comportement du SPI pendant les échanges.
	* Vérifier la compatibilité des niveaux logiques entre le Shield et la carte écran (3.3V vs 5V) et intégrer un convertisseur de niveau si nécessaire.

	En résumé, bien que des défis restent à résoudre pour la partie SPI, nous avons validé l’ensemble des fonctionnalités de l’ordonnanceur. Nous sommes confiants que les ajustements proposés nous permettront d’obtenir un système pleinement fonctionnel.		En résumé, bien que des défis restent à résoudre pour la partie SPI, nous avons validé l’ensemble des fonctionnalités de l’ordonnanceur. Nous sommes confiants que les ajustements proposés nous permettront d’obtenir un système pleinement fonctionnel.

Kelbachi : /* Conclusion et Axes d'amélioration */

2025-01-26T17:42:50Z

Conclusion et Axes d'amélioration

← Version précédente		Version du 26 janvier 2025 à 17:42
Ligne 399 :		Ligne 399 :
	* Le deuxième test (illustré dans l'image ci-dessous) vérifie la stabilité et la cohérence des données sous un flux massif d'écritures/lectures répétées.[[Fichier:Printf.jpg\|centré\|vignette]]		* Le deuxième test (illustré dans l'image ci-dessous) vérifie la stabilité et la cohérence des données sous un flux massif d'écritures/lectures répétées.[[Fichier:Printf.jpg\|centré\|vignette]]

	== Conclusion et ~~Axes~~ d'~~amélioration ==~~		== Conclusion ==

			=== Tests de la RAM SPI ===
			La mémoire RAM SPI ne fonctionne pas encore comme prévu pour l’ensemble des tests. Malgré nos efforts, nous avons remarqué une chute de tension significative de 1,5 V entre le Shield et la carte écran. Cette chute pourrait expliquer les dysfonctionnements observés dans la communication SPI. Bien que la carte écran fonctionne correctement lorsqu’elle est utilisée seule, elle ne parvient pas à établir une communication via le Shield. Cependant, les différentes étapes de conception et de test nous semblent alignées, et nous pensons être sur la bonne voie pour résoudre ce problème.

			=== Ordonnanceur et Gestion des Tâches ===
			Concernant l’ordonnanceur, toutes les consignes ont été respectées et implémentées avec succès. Le scheduler suit une approche Round-Robin efficace pour gérer les tâches concurrentes. Grâce aux interruptions et à une gestion des délais non bloquants, il permet une répartition optimale du temps CPU entre les tâches, tout en garantissant une bonne réponse pour les processus critiques. Les tests ont validé le bon fonctionnement des différentes tâches, comme la gestion des LEDs, la communication série et l’affichage.

			=== Pistes d’amélioration ===
			Pour améliorer le fonctionnement global et résoudre les problèmes liés au SPI, voici quelques pistes à explorer :
			* Identifier et réduire la chute de tension entre le Shield et la carte écran, éventuellement en vérifiant les connexions, la qualité des câbles ou l’alimentation.
			* Tester la communication SPI avec d'autres configurations ou composants pour valider chaque élément individuellement.
			* Ajouter des résistances de pull-up ou pull-down sur les lignes de données SPI si nécessaire pour stabiliser les signaux.
			* Évaluer la fréquence du bus SPI et expérimenter des réglages plus faibles pour limiter les erreurs de transmission dues à des signaux bruyants ou instables.
			* Intégrer un débogage en temps réel en utilisant des outils comme un analyseur logique ou un oscilloscope pour mieux comprendre le comportement du SPI pendant les échanges.
			* Vérifier la compatibilité des niveaux logiques entre le Shield et la carte écran (3.3V vs 5V) et intégrer un convertisseur de niveau si nécessaire.

			En résumé, bien que des défis restent à résoudre pour la partie SPI, nous avons validé l’ensemble des fonctionnalités de l’ordonnanceur. Nous sommes confiants que les ajustements proposés nous permettront d’obtenir un système pleinement fonctionnel.

Kelbachi : /* Validation des fonctionnalités */

2025-01-26T17:39:07Z

Validation des fonctionnalités

← Version précédente		Version du 26 janvier 2025 à 17:39
Ligne 395 :		Ligne 395 :

	=== Résultat des tests ===		=== Résultat des tests ===
	* Le premier test (illustré dans l'image 1) montre que la RAM SPI fonctionne correctement, avec des données transmises et récupérées sans perte.		* Le premier test (illustré dans l'image ci-dessous) montre que la RAM SPI fonctionne correctement, avec des données transmises et récupérées sans perte.
	* Le deuxième test (image 2) vérifie la stabilité et la cohérence des données sous un flux massif d'écritures/lectures répétées.		[[Fichier:Ram fonctionne.png\|centré\|vignette\|527x527px\|La RAM fonctionne]]
			* Le deuxième test (illustré dans l'image ci-dessous) vérifie la stabilité et la cohérence des données sous un flux massif d'écritures/lectures répétées.[[Fichier:Printf.jpg\|centré\|vignette]]

	== Conclusion et Axes d'amélioration ==		== Conclusion et Axes d'amélioration ==

Kelbachi : /* Tests de la RAM SPI */

2025-01-26T17:29:53Z

Tests de la RAM SPI

← Version précédente		Version du 26 janvier 2025 à 17:29
Ligne 328 :		Ligne 328 :
	[[Fichier:Fin Ordonnanceur 7 Segment.mp4\|centré\|vignette\|400x300px\|7 segment et minicom]]		[[Fichier:Fin Ordonnanceur 7 Segment.mp4\|centré\|vignette\|400x300px\|7 segment et minicom]]

	=== Tests de la RAM SPI ===		== Tests de la RAM SPI ==
	* ~~Nous avons ajouter les fonction ram select~~ et ~~deselect et des foncions select entre le Shield et le Microprocesseur~~ pour assurer l'accès ~~unique~~ à la mémoire:
	<syntaxhighlight lang="~~cpp~~">		Pour tester la mémoire RAM SPI, plusieurs étapes ont été mises en œuvre pour garantir la bonne communication et la gestion des données. Voici les principales actions réalisées :

			=== Fonctions de gestion de l'accès à la RAM ===
			* Les fonctions <code>ram_select</code> et <code>ram_deselect</code> ont été ajoutées pour assurer un accès exclusif à la mémoire :
			<syntaxhighlight lang="c">
	void ram_select() {		void ram_select() {
	SPI_PORT &= ~(1 << SPI_SS); // ~~Select~~ RAM		SPI_PORT &= ~(1 << SPI_SS); // Sélectionne la RAM
	}		}

	void ram_deselect() {		void ram_deselect() {
	SPI_PORT \|= (1 << SPI_SS); // ~~Deselect~~ RAM		SPI_PORT \|= (1 << SPI_SS); // Désélectionne la RAM
	}		}
			</syntaxhighlight>

			* Les fonctions <code>select_microcontroller</code> et <code>select_shield</code> ont été introduites pour basculer entre le Microcontrôleur et le Shield :
			<syntaxhighlight lang="c">
	void select_microcontroller() {		void select_microcontroller() {
	PORTC \|= (1 << DATA0); // ~~Set DATA0 to 1~~		PORTC \|= (1 << DATA0); // Active le microcontrôleur
	_delay_ms(1); // ~~Allow settling time~~		_delay_ms(1); // Temps de stabilisation
	}		}

	void select_shield() {		void select_shield() {
	PORTC &= ~(1 << DATA0); // ~~Set DATA0 to 0~~		PORTC &= ~(1 << DATA0); // Active le Shield
	_delay_ms(1); // ~~Allow settling time~~		_delay_ms(1); // Temps de stabilisation
			}
			</syntaxhighlight>

			=== Opérations de base sur la RAM ===
			* Lecture (<code>RAM_read</code>), écriture (<code>RAM_write</code>), et effacement (<code>RAM_clear</code>) ont été implémentés pour interagir avec la mémoire via le bus SPI.
			* Exemple d'écriture :
			<syntaxhighlight lang="c">
			void RAM_write(uint16_t address, char *data) {
			RAM_write_enable();
			CS_LOW();
			spi_exch(WRITE);
			spi_exch((address >> 8) & 0xFF);
			spi_exch(address & 0xFF);
			for (uint8_t i = 0; i < strlen(data); i++) {
			spi_exch(data[i]);
			}
			RAM_write_disable();
			CS_HIGH();
	}		}
	</syntaxhighlight>		</syntaxhighlight>

	*		* Exemple de lecture :
			<syntaxhighlight lang="c">
			void RAM_read(uint16_t address, char *buffer, uint8_t length) {
			CS_LOW();
			spi_exch(READ);
			spi_exch((address >> 8) & 0xFF);
			spi_exch(address & 0xFF);
			for (uint8_t i = 0; i < length; i++) {
			buffer[i] = spi_exch(0x00);
			}
			buffer[length] = '\0';
			CS_HIGH();
			}
			</syntaxhighlight>

			=== Validation des fonctionnalités ===
			* Un test basique avec des données simples a été effectué pour vérifier que les données écrites pouvaient être lues sans erreur.
			* Un test de stress par brute force a été réalisé pour écrire et lire des données massivement tout en affichant les résultats avec un <code>printf</code>. Cela a permis de confirmer la robustesse du système.

			=== Résultat des tests ===
			* Le premier test (illustré dans l'image 1) montre que la RAM SPI fonctionne correctement, avec des données transmises et récupérées sans perte.
			* Le deuxième test (image 2) vérifie la stabilité et la cohérence des données sous un flux massif d'écritures/lectures répétées.

	== Conclusion et Axes d'amélioration ==		== Conclusion et Axes d'amélioration ==

Kelbachi : /* Tests de la RAM SPI */

2025-01-26T17:26:10Z

Tests de la RAM SPI

← Version précédente		Version du 26 janvier 2025 à 17:26
Ligne 349 :		Ligne 349 :
	}		}
	</syntaxhighlight>		</syntaxhighlight>

			*

	== Conclusion et Axes d'amélioration ==		== Conclusion et Axes d'amélioration ==

Kelbachi : /* Conclusion */

2025-01-23T14:06:18Z

Conclusion

← Version précédente		Version du 23 janvier 2025 à 14:06
Ligne 350 :		Ligne 350 :
	</syntaxhighlight>		</syntaxhighlight>

	== Conclusion ==		== Conclusion et Axes d'amélioration ==

SE4Binome2024-2 - Historique des versions

Rex : /* Résultat des tests */

Rex : /* Tests de l'Ordonnanceur */

Rex : /* Fonction `main` */

Mbarret : /* Résultat des tests */

Kelbachi : /* Pistes d’amélioration */

Kelbachi : /* Conclusion et Axes d'amélioration */

Kelbachi : /* Validation des fonctionnalités */

Kelbachi : /* Tests de la RAM SPI */

Kelbachi : /* Tests de la RAM SPI */

Kelbachi : /* Conclusion */

Rex : /* Résultat des tests */

Rex : /* Tests de l'Ordonnanceur */

Rex : /* Fonction `main` */

Mbarret : /* Résultat des tests */

Kelbachi : /* Pistes d’amélioration */

Kelbachi : /* Conclusion et Axes d'amélioration */

Kelbachi : /* Validation des fonctionnalités */

Kelbachi : /* Tests de la RAM SPI */

Kelbachi : /* Tests de la RAM SPI */

Kelbachi : /* Conclusion */