Wiki d'activités IMA - Contributions de l’utilisateur [fr]

Analyseur de chronogramme

2013-05-30T12:59:11Z

Dgasnier : /* Video : */

= Présentation du projet : =
==== Etudiants : ====
Bonvalet Quentin et Gasnier Damien
==== Encadrant : ====
Blaise Conrard
==== Objectif : ====
Réaliser un programme d'aide à la mise au point de modules temps-réel par la simulation de leur exécution et la génération d'un chronogramme de la séquence d’ordonnancement de ses tâches.
==== Description : ====
Lors des TP temps-réel, un outil d'aide au développement des modules réalisés pourrait faciliter la mise au point de ces modules. Son principe serait le suivant : il simulerait l'exécution d'un module ; il mémoriserait les instants d'exécution de chacune des tâches et les différents accès aux entrées/sorties réalisés ; puis en final, il retournerait un chronogramme de l'exécution des tâches et de l'évolution des signaux de signaux. Un tel outil serait d'une grande d'aide pour la compréhension et la réalisation des TP temps-réel.
= Video : =
[http://youtu.be/JeaGkZyjC14 lien youtube de la video] 
= Rapport du projet : =
[[Fichier:rapport_projet_P28.pdf]]

= Avancement du projet =
==== 04/02/2013 ====
L'encadrant étant malade, nous avons interprété des objectifs et commencé à définir les tâches de notre projet: 
Programme ( C ), pour les TP temps-réel : 
1. Analyse (Recherche, Mémorisation et Vérification) : 
Avec notre exécutable on :
* Prend un ficher C à tester.
* Recherche et mémorise la définition des ports.
* Recherche et mémorise la « nano_period ».
* Recherche les fonctions (tâches séquentielles et par interruption) et mémorise leur noms.
* Mémorise l'exécution de ces fonctions ?
* Recherche les fonctions d'initialisation des tâches et vérifie la présence leur l'identifiant et leur nom dans fonction principale.
* Recherche les fonctions « make_periodic » et vérifie l'identifiant de la tache, mémorise pour chaque fonction le « now » et la période d'exécution.
* Recherche et vérifie la présence du « rt_task_wait_period(); » dans chaque boucle de tâche séquentielle, et sa non-présence pour une tâche IRQ.
* Recherche et vérifie qu'il y a un seul « stop_rt_timer (); »
* Recherche et vérifier les fonctions de suppression des tâches.
* Recherche-t-on et vérifie-t-on le bon ordre d'appel des tâches dans le « démarrer/arrêter » ?
2. Simulation : 
Grâce à l'analyse, on sait que le programme a bien défini les aspects temps-réel qu'un programme est sensé définir.
On en a dégagé les tâches avec leur départ d'exécution, leur période et leur contenu.
Il faut maintenant qu'on :
* Retourne un chronogramme de l'exécution des tâches.
* Simule l'état des signaux du boîtier d'E/S et les mémorise dans le temps.
* Affiche la simulation des afficheurs 7 segments.
* Simule l'état des signaux de la carte d'acquisition et les mémorise dans le temps.
* Affiche la simulation de ces signaux dans le temps comme sur un oscilloscope.
==== 07/02/2013 ====
comité pilotage avec M. Conrard pour clarifier noter vision du projet et s'assurer d'être en accord. Il s'avère que nous n'avions pas vu le projet de la même manière. 
Nous devons en fait reprendre le programme C créer par l'étudiant, puis l'inclure dans notre programme. Nous ne reprendrons cependant pas les bibliothèques, ce qui permet de ne pas faire une exécution temps-réel, afin justement de pouvoir repérer les éventuelles erreurs pour qu'ensuite l'étudiant puisse lancer sont programme en temps-réel sans faire planter sa machine. 
Nous devons alors créer les fonctions (normalement temps-réelles) que le programme de l'étudiant appel, non pas pour les exécuter en temps-réel mais pour les simuler et générer un chronogramme. 
Nous avons alors créer un fichier étudiant test, et commencé à repérer les fonctions que nous allons devoir créer.

==== 11/02/2013 ====
Nous avons commencé à développer le programme C qui inclura celui de l'étudiant. Nous y avons déclaré toute les fonctions nécessaires. 
Nous avons fait un Makefile permettant d'inclure le programme étudiant, sans ses bibliothèques. La compilation fonctionne et à l'exécution nous arrivons à appeler les fonctions tâches de l'étudiant en dure dans notre main. 

==== 14/02/2013 ====
Nous avons fait des recherches sur l'ordonnancement des tâches. 
Nous avons aussi essayé d'écrire les fonctions d'impressions (affichage) temps-réels et la production d'un fichier texte pour dans un premier temps visualiser une ébauche chronogramme.

==== 25/02/2013 ====
Nous avons créer la page wiki. 
Nous avons essayer d'appeler une fonction en dynamique, car on ne connaîtra pas à l'avance les tâches déclarés par l'étudiant. Et là nous avons rencontré plus de problèmes que de solutions.
==== 27/02/2013 ====
résolution (partielle) du problème de l'appelle d'une fonction inconnue, avec un callback. 
création des structures pour stocker les informations relatives aux taches. 
recherche pour la production d'une image pour le chronogramme. 
recherche pour l'ordonnacement. 
==== 28/02/2013 ====
appropriation de la bibliothèque SDL pour creer une image. 
==== 04/03/2013 ====
réalisation des fonctions pour afficher le squelette des chronogrammes et le boitier 7 segments. 
recherches pour sauvegarder une image PNG. 
création d'un tableau récapitulatif de problèmes sur le projet et des solutions possibles. 
tests et débuggage du code. Écriture du code pour l'ordonnanceur. 
==== 06/03/2013 ====
recherche sur le chargement d'image avec sdl 
tests de .c 
comité pilotage avec M. Conrar : compte-rendu sur l'avancement du projet, réponse aux indéfinies, autre solution graphique 
recherche sur l'ordonnancement 
gestion de projet 
essais d'utilisation de RTAI 
recherche sur le language python 
==== 11/03/2013 ====
utilisation fonctionelle des callbacks dans les structures et appel ultérieur dans les fonctions, plus test. 
Recherches sur le language python.
==== 18/03/2013 ====
Recherches sur le language python.
==== 20/03/2013 ====
Comité pilotage. 
travail sur les sémaphore et mutex à plusieurs tâches, ainsi que les thread. 
Modification du code pour production texte des informations relatives à chaque tâche. 
==== 21/03/2013 ====
Expériences test pour comprendre tous les fonctionnements temps-réels de TP. 
Modification de l'algoritme d'ordonnacement avec sémaphore et mutex.
==== 25/03/2013 ====
modification du wiki. 
Etudes des codes fournis par M. Conrar sur mutex.

Analyseur de chronogramme

2013-05-30T12:58:12Z

Dgasnier : /* Video : */

= Présentation du projet : =
==== Etudiants : ====
Bonvalet Quentin et Gasnier Damien
==== Encadrant : ====
Blaise Conrard
==== Objectif : ====
Réaliser un programme d'aide à la mise au point de modules temps-réel par la simulation de leur exécution et la génération d'un chronogramme de la séquence d’ordonnancement de ses tâches.
==== Description : ====
Lors des TP temps-réel, un outil d'aide au développement des modules réalisés pourrait faciliter la mise au point de ces modules. Son principe serait le suivant : il simulerait l'exécution d'un module ; il mémoriserait les instants d'exécution de chacune des tâches et les différents accès aux entrées/sorties réalisés ; puis en final, il retournerait un chronogramme de l'exécution des tâches et de l'évolution des signaux de signaux. Un tel outil serait d'une grande d'aide pour la compréhension et la réalisation des TP temps-réel.
= Video : =
[http://youtu.be/JeaGkZyjC14 lien youtube de la video]
[[Fichier:rapport_projet_P28.pdf]]

= Avancement du projet =
==== 04/02/2013 ====
L'encadrant étant malade, nous avons interprété des objectifs et commencé à définir les tâches de notre projet: 
Programme ( C ), pour les TP temps-réel : 
1. Analyse (Recherche, Mémorisation et Vérification) : 
Avec notre exécutable on :
* Prend un ficher C à tester.
* Recherche et mémorise la définition des ports.
* Recherche et mémorise la « nano_period ».
* Recherche les fonctions (tâches séquentielles et par interruption) et mémorise leur noms.
* Mémorise l'exécution de ces fonctions ?
* Recherche les fonctions d'initialisation des tâches et vérifie la présence leur l'identifiant et leur nom dans fonction principale.
* Recherche les fonctions « make_periodic » et vérifie l'identifiant de la tache, mémorise pour chaque fonction le « now » et la période d'exécution.
* Recherche et vérifie la présence du « rt_task_wait_period(); » dans chaque boucle de tâche séquentielle, et sa non-présence pour une tâche IRQ.
* Recherche et vérifie qu'il y a un seul « stop_rt_timer (); »
* Recherche et vérifier les fonctions de suppression des tâches.
* Recherche-t-on et vérifie-t-on le bon ordre d'appel des tâches dans le « démarrer/arrêter » ?
2. Simulation : 
Grâce à l'analyse, on sait que le programme a bien défini les aspects temps-réel qu'un programme est sensé définir.
On en a dégagé les tâches avec leur départ d'exécution, leur période et leur contenu.
Il faut maintenant qu'on :
* Retourne un chronogramme de l'exécution des tâches.
* Simule l'état des signaux du boîtier d'E/S et les mémorise dans le temps.
* Affiche la simulation des afficheurs 7 segments.
* Simule l'état des signaux de la carte d'acquisition et les mémorise dans le temps.
* Affiche la simulation de ces signaux dans le temps comme sur un oscilloscope.
==== 07/02/2013 ====
comité pilotage avec M. Conrard pour clarifier noter vision du projet et s'assurer d'être en accord. Il s'avère que nous n'avions pas vu le projet de la même manière. 
Nous devons en fait reprendre le programme C créer par l'étudiant, puis l'inclure dans notre programme. Nous ne reprendrons cependant pas les bibliothèques, ce qui permet de ne pas faire une exécution temps-réel, afin justement de pouvoir repérer les éventuelles erreurs pour qu'ensuite l'étudiant puisse lancer sont programme en temps-réel sans faire planter sa machine. 
Nous devons alors créer les fonctions (normalement temps-réelles) que le programme de l'étudiant appel, non pas pour les exécuter en temps-réel mais pour les simuler et générer un chronogramme. 
Nous avons alors créer un fichier étudiant test, et commencé à repérer les fonctions que nous allons devoir créer.

==== 11/02/2013 ====
Nous avons commencé à développer le programme C qui inclura celui de l'étudiant. Nous y avons déclaré toute les fonctions nécessaires. 
Nous avons fait un Makefile permettant d'inclure le programme étudiant, sans ses bibliothèques. La compilation fonctionne et à l'exécution nous arrivons à appeler les fonctions tâches de l'étudiant en dure dans notre main. 

==== 14/02/2013 ====
Nous avons fait des recherches sur l'ordonnancement des tâches. 
Nous avons aussi essayé d'écrire les fonctions d'impressions (affichage) temps-réels et la production d'un fichier texte pour dans un premier temps visualiser une ébauche chronogramme.

==== 25/02/2013 ====
Nous avons créer la page wiki. 
Nous avons essayer d'appeler une fonction en dynamique, car on ne connaîtra pas à l'avance les tâches déclarés par l'étudiant. Et là nous avons rencontré plus de problèmes que de solutions.
==== 27/02/2013 ====
résolution (partielle) du problème de l'appelle d'une fonction inconnue, avec un callback. 
création des structures pour stocker les informations relatives aux taches. 
recherche pour la production d'une image pour le chronogramme. 
recherche pour l'ordonnacement. 
==== 28/02/2013 ====
appropriation de la bibliothèque SDL pour creer une image. 
==== 04/03/2013 ====
réalisation des fonctions pour afficher le squelette des chronogrammes et le boitier 7 segments. 
recherches pour sauvegarder une image PNG. 
création d'un tableau récapitulatif de problèmes sur le projet et des solutions possibles. 
tests et débuggage du code. Écriture du code pour l'ordonnanceur. 
==== 06/03/2013 ====
recherche sur le chargement d'image avec sdl 
tests de .c 
comité pilotage avec M. Conrar : compte-rendu sur l'avancement du projet, réponse aux indéfinies, autre solution graphique 
recherche sur l'ordonnancement 
gestion de projet 
essais d'utilisation de RTAI 
recherche sur le language python 
==== 11/03/2013 ====
utilisation fonctionelle des callbacks dans les structures et appel ultérieur dans les fonctions, plus test. 
Recherches sur le language python.
==== 18/03/2013 ====
Recherches sur le language python.
==== 20/03/2013 ====
Comité pilotage. 
travail sur les sémaphore et mutex à plusieurs tâches, ainsi que les thread. 
Modification du code pour production texte des informations relatives à chaque tâche. 
==== 21/03/2013 ====
Expériences test pour comprendre tous les fonctionnements temps-réels de TP. 
Modification de l'algoritme d'ordonnacement avec sémaphore et mutex.
==== 25/03/2013 ====
modification du wiki. 
Etudes des codes fournis par M. Conrar sur mutex.

Fichier:Rapport projet P28.pdf

2013-05-30T12:51:39Z

Dgasnier : Rapport du projet p28, IMA 4 2013

Rapport du projet p28, IMA 4 2013

Analyseur de chronogramme

2013-05-30T11:50:31Z

Dgasnier : /* Video : */

= Présentation du projet : =
==== Etudiants : ====
Bonvalet Quentin et Gasnier Damien
==== Encadrant : ====
Blaise Conrard
==== Objectif : ====
Réaliser un programme d'aide à la mise au point de modules temps-réel par la simulation de leur exécution et la génération d'un chronogramme de la séquence d’ordonnancement de ses tâches.
==== Description : ====
Lors des TP temps-réel, un outil d'aide au développement des modules réalisés pourrait faciliter la mise au point de ces modules. Son principe serait le suivant : il simulerait l'exécution d'un module ; il mémoriserait les instants d'exécution de chacune des tâches et les différents accès aux entrées/sorties réalisés ; puis en final, il retournerait un chronogramme de l'exécution des tâches et de l'évolution des signaux de signaux. Un tel outil serait d'une grande d'aide pour la compréhension et la réalisation des TP temps-réel.
= Video : =
[http://youtu.be/JeaGkZyjC14 lien youtube de la video]

= Avancement du projet =
==== 04/02/2013 ====
L'encadrant étant malade, nous avons interprété des objectifs et commencé à définir les tâches de notre projet: 
Programme ( C ), pour les TP temps-réel : 
1. Analyse (Recherche, Mémorisation et Vérification) : 
Avec notre exécutable on :
* Prend un ficher C à tester.
* Recherche et mémorise la définition des ports.
* Recherche et mémorise la « nano_period ».
* Recherche les fonctions (tâches séquentielles et par interruption) et mémorise leur noms.
* Mémorise l'exécution de ces fonctions ?
* Recherche les fonctions d'initialisation des tâches et vérifie la présence leur l'identifiant et leur nom dans fonction principale.
* Recherche les fonctions « make_periodic » et vérifie l'identifiant de la tache, mémorise pour chaque fonction le « now » et la période d'exécution.
* Recherche et vérifie la présence du « rt_task_wait_period(); » dans chaque boucle de tâche séquentielle, et sa non-présence pour une tâche IRQ.
* Recherche et vérifie qu'il y a un seul « stop_rt_timer (); »
* Recherche et vérifier les fonctions de suppression des tâches.
* Recherche-t-on et vérifie-t-on le bon ordre d'appel des tâches dans le « démarrer/arrêter » ?
2. Simulation : 
Grâce à l'analyse, on sait que le programme a bien défini les aspects temps-réel qu'un programme est sensé définir.
On en a dégagé les tâches avec leur départ d'exécution, leur période et leur contenu.
Il faut maintenant qu'on :
* Retourne un chronogramme de l'exécution des tâches.
* Simule l'état des signaux du boîtier d'E/S et les mémorise dans le temps.
* Affiche la simulation des afficheurs 7 segments.
* Simule l'état des signaux de la carte d'acquisition et les mémorise dans le temps.
* Affiche la simulation de ces signaux dans le temps comme sur un oscilloscope.
==== 07/02/2013 ====
comité pilotage avec M. Conrard pour clarifier noter vision du projet et s'assurer d'être en accord. Il s'avère que nous n'avions pas vu le projet de la même manière. 
Nous devons en fait reprendre le programme C créer par l'étudiant, puis l'inclure dans notre programme. Nous ne reprendrons cependant pas les bibliothèques, ce qui permet de ne pas faire une exécution temps-réel, afin justement de pouvoir repérer les éventuelles erreurs pour qu'ensuite l'étudiant puisse lancer sont programme en temps-réel sans faire planter sa machine. 
Nous devons alors créer les fonctions (normalement temps-réelles) que le programme de l'étudiant appel, non pas pour les exécuter en temps-réel mais pour les simuler et générer un chronogramme. 
Nous avons alors créer un fichier étudiant test, et commencé à repérer les fonctions que nous allons devoir créer.

==== 11/02/2013 ====
Nous avons commencé à développer le programme C qui inclura celui de l'étudiant. Nous y avons déclaré toute les fonctions nécessaires. 
Nous avons fait un Makefile permettant d'inclure le programme étudiant, sans ses bibliothèques. La compilation fonctionne et à l'exécution nous arrivons à appeler les fonctions tâches de l'étudiant en dure dans notre main. 

==== 14/02/2013 ====
Nous avons fait des recherches sur l'ordonnancement des tâches. 
Nous avons aussi essayé d'écrire les fonctions d'impressions (affichage) temps-réels et la production d'un fichier texte pour dans un premier temps visualiser une ébauche chronogramme.

==== 25/02/2013 ====
Nous avons créer la page wiki. 
Nous avons essayer d'appeler une fonction en dynamique, car on ne connaîtra pas à l'avance les tâches déclarés par l'étudiant. Et là nous avons rencontré plus de problèmes que de solutions.
==== 27/02/2013 ====
résolution (partielle) du problème de l'appelle d'une fonction inconnue, avec un callback. 
création des structures pour stocker les informations relatives aux taches. 
recherche pour la production d'une image pour le chronogramme. 
recherche pour l'ordonnacement. 
==== 28/02/2013 ====
appropriation de la bibliothèque SDL pour creer une image. 
==== 04/03/2013 ====
réalisation des fonctions pour afficher le squelette des chronogrammes et le boitier 7 segments. 
recherches pour sauvegarder une image PNG. 
création d'un tableau récapitulatif de problèmes sur le projet et des solutions possibles. 
tests et débuggage du code. Écriture du code pour l'ordonnanceur. 
==== 06/03/2013 ====
recherche sur le chargement d'image avec sdl 
tests de .c 
comité pilotage avec M. Conrar : compte-rendu sur l'avancement du projet, réponse aux indéfinies, autre solution graphique 
recherche sur l'ordonnancement 
gestion de projet 
essais d'utilisation de RTAI 
recherche sur le language python 
==== 11/03/2013 ====
utilisation fonctionelle des callbacks dans les structures et appel ultérieur dans les fonctions, plus test. 
Recherches sur le language python.
==== 18/03/2013 ====
Recherches sur le language python.
==== 20/03/2013 ====
Comité pilotage. 
travail sur les sémaphore et mutex à plusieurs tâches, ainsi que les thread. 
Modification du code pour production texte des informations relatives à chaque tâche. 
==== 21/03/2013 ====
Expériences test pour comprendre tous les fonctionnements temps-réels de TP. 
Modification de l'algoritme d'ordonnacement avec sémaphore et mutex.
==== 25/03/2013 ====
modification du wiki. 
Etudes des codes fournis par M. Conrar sur mutex.

Analyseur de chronogramme

2013-05-24T15:19:57Z

Dgasnier : /* Présentation du projet : */

= Présentation du projet : =
==== Etudiants : ====
Bonvalet Quentin et Gasnier Damien
==== Encadrant : ====
Blaise Conrard
==== Objectif : ====
Réaliser un programme d'aide à la mise au point de modules temps-réel par la simulation de leur exécution et la génération d'un chronogramme de la séquence d’ordonnancement de ses tâches.
==== Description : ====
Lors des TP temps-réel, un outil d'aide au développement des modules réalisés pourrait faciliter la mise au point de ces modules. Son principe serait le suivant : il simulerait l'exécution d'un module ; il mémoriserait les instants d'exécution de chacune des tâches et les différents accès aux entrées/sorties réalisés ; puis en final, il retournerait un chronogramme de l'exécution des tâches et de l'évolution des signaux de signaux. Un tel outil serait d'une grande d'aide pour la compréhension et la réalisation des TP temps-réel.
= Video : =

= Avancement du projet =
==== 04/02/2013 ====
L'encadrant étant malade, nous avons interprété des objectifs et commencé à définir les tâches de notre projet: 
Programme ( C ), pour les TP temps-réel : 
1. Analyse (Recherche, Mémorisation et Vérification) : 
Avec notre exécutable on :
* Prend un ficher C à tester.
* Recherche et mémorise la définition des ports.
* Recherche et mémorise la « nano_period ».
* Recherche les fonctions (tâches séquentielles et par interruption) et mémorise leur noms.
* Mémorise l'exécution de ces fonctions ?
* Recherche les fonctions d'initialisation des tâches et vérifie la présence leur l'identifiant et leur nom dans fonction principale.
* Recherche les fonctions « make_periodic » et vérifie l'identifiant de la tache, mémorise pour chaque fonction le « now » et la période d'exécution.
* Recherche et vérifie la présence du « rt_task_wait_period(); » dans chaque boucle de tâche séquentielle, et sa non-présence pour une tâche IRQ.
* Recherche et vérifie qu'il y a un seul « stop_rt_timer (); »
* Recherche et vérifier les fonctions de suppression des tâches.
* Recherche-t-on et vérifie-t-on le bon ordre d'appel des tâches dans le « démarrer/arrêter » ?
2. Simulation : 
Grâce à l'analyse, on sait que le programme a bien défini les aspects temps-réel qu'un programme est sensé définir.
On en a dégagé les tâches avec leur départ d'exécution, leur période et leur contenu.
Il faut maintenant qu'on :
* Retourne un chronogramme de l'exécution des tâches.
* Simule l'état des signaux du boîtier d'E/S et les mémorise dans le temps.
* Affiche la simulation des afficheurs 7 segments.
* Simule l'état des signaux de la carte d'acquisition et les mémorise dans le temps.
* Affiche la simulation de ces signaux dans le temps comme sur un oscilloscope.
==== 07/02/2013 ====
comité pilotage avec M. Conrard pour clarifier noter vision du projet et s'assurer d'être en accord. Il s'avère que nous n'avions pas vu le projet de la même manière. 
Nous devons en fait reprendre le programme C créer par l'étudiant, puis l'inclure dans notre programme. Nous ne reprendrons cependant pas les bibliothèques, ce qui permet de ne pas faire une exécution temps-réel, afin justement de pouvoir repérer les éventuelles erreurs pour qu'ensuite l'étudiant puisse lancer sont programme en temps-réel sans faire planter sa machine. 
Nous devons alors créer les fonctions (normalement temps-réelles) que le programme de l'étudiant appel, non pas pour les exécuter en temps-réel mais pour les simuler et générer un chronogramme. 
Nous avons alors créer un fichier étudiant test, et commencé à repérer les fonctions que nous allons devoir créer.

==== 11/02/2013 ====
Nous avons commencé à développer le programme C qui inclura celui de l'étudiant. Nous y avons déclaré toute les fonctions nécessaires. 
Nous avons fait un Makefile permettant d'inclure le programme étudiant, sans ses bibliothèques. La compilation fonctionne et à l'exécution nous arrivons à appeler les fonctions tâches de l'étudiant en dure dans notre main. 

==== 14/02/2013 ====
Nous avons fait des recherches sur l'ordonnancement des tâches. 
Nous avons aussi essayé d'écrire les fonctions d'impressions (affichage) temps-réels et la production d'un fichier texte pour dans un premier temps visualiser une ébauche chronogramme.

==== 25/02/2013 ====
Nous avons créer la page wiki. 
Nous avons essayer d'appeler une fonction en dynamique, car on ne connaîtra pas à l'avance les tâches déclarés par l'étudiant. Et là nous avons rencontré plus de problèmes que de solutions.
==== 27/02/2013 ====
résolution (partielle) du problème de l'appelle d'une fonction inconnue, avec un callback. 
création des structures pour stocker les informations relatives aux taches. 
recherche pour la production d'une image pour le chronogramme. 
recherche pour l'ordonnacement. 
==== 28/02/2013 ====
appropriation de la bibliothèque SDL pour creer une image. 
==== 04/03/2013 ====
réalisation des fonctions pour afficher le squelette des chronogrammes et le boitier 7 segments. 
recherches pour sauvegarder une image PNG. 
création d'un tableau récapitulatif de problèmes sur le projet et des solutions possibles. 
tests et débuggage du code. Écriture du code pour l'ordonnanceur. 
==== 06/03/2013 ====
recherche sur le chargement d'image avec sdl 
tests de .c 
comité pilotage avec M. Conrar : compte-rendu sur l'avancement du projet, réponse aux indéfinies, autre solution graphique 
recherche sur l'ordonnancement 
gestion de projet 
essais d'utilisation de RTAI 
recherche sur le language python 
==== 11/03/2013 ====
utilisation fonctionelle des callbacks dans les structures et appel ultérieur dans les fonctions, plus test. 
Recherches sur le language python.
==== 18/03/2013 ====
Recherches sur le language python.
==== 20/03/2013 ====
Comité pilotage. 
travail sur les sémaphore et mutex à plusieurs tâches, ainsi que les thread. 
Modification du code pour production texte des informations relatives à chaque tâche. 
==== 21/03/2013 ====
Expériences test pour comprendre tous les fonctionnements temps-réels de TP. 
Modification de l'algoritme d'ordonnacement avec sémaphore et mutex.
==== 25/03/2013 ====
modification du wiki. 
Etudes des codes fournis par M. Conrar sur mutex.

Analyseur de chronogramme

2013-03-25T15:49:10Z

Dgasnier : /* 25/03/2013 */

= Présentation du projet : =
==== Etudiants : ====
Bonvalet Quentin et Gasnier Damien
==== Encadrant : ====
Blaise Conrard
==== Objectif : ====
Réaliser un programme d'aide à la mise au point de modules temps-réel par la simulation de leur exécution et la génération d'un chronogramme de la séquence d’ordonnancement de ses tâches.
==== Description : ====
Lors des TP temps-réel, un outil d'aide au développement des modules réalisés pourrait faciliter la mise au point de ces modules. Son principe serait le suivant : il simulerait l'exécution d'un module ; il mémoriserait les instants d'exécution de chacune des tâches et les différents accès aux entrées/sorties réalisés ; puis en final, il retournerait un chronogramme de l'exécution des tâches et de l'évolution des signaux de signaux. Un tel outil serait d'une grande d'aide pour la compréhension et la réalisation des TP temps-réel.
= Avancement du projet =
==== 04/02/2013 ====
L'encadrant étant malade, nous avons interprété des objectifs et commencé à définir les tâches de notre projet: 
Programme ( C ), pour les TP temps-réel : 
1. Analyse (Recherche, Mémorisation et Vérification) : 
Avec notre exécutable on :
* Prend un ficher C à tester.
* Recherche et mémorise la définition des ports.
* Recherche et mémorise la « nano_period ».
* Recherche les fonctions (tâches séquentielles et par interruption) et mémorise leur noms.
* Mémorise l'exécution de ces fonctions ?
* Recherche les fonctions d'initialisation des tâches et vérifie la présence leur l'identifiant et leur nom dans fonction principale.
* Recherche les fonctions « make_periodic » et vérifie l'identifiant de la tache, mémorise pour chaque fonction le « now » et la période d'exécution.
* Recherche et vérifie la présence du « rt_task_wait_period(); » dans chaque boucle de tâche séquentielle, et sa non-présence pour une tâche IRQ.
* Recherche et vérifie qu'il y a un seul « stop_rt_timer (); »
* Recherche et vérifier les fonctions de suppression des tâches.
* Recherche-t-on et vérifie-t-on le bon ordre d'appel des tâches dans le « démarrer/arrêter » ?
2. Simulation : 
Grâce à l'analyse, on sait que le programme a bien défini les aspects temps-réel qu'un programme est sensé définir.
On en a dégagé les tâches avec leur départ d'exécution, leur période et leur contenu.
Il faut maintenant qu'on :
* Retourne un chronogramme de l'exécution des tâches.
* Simule l'état des signaux du boîtier d'E/S et les mémorise dans le temps.
* Affiche la simulation des afficheurs 7 segments.
* Simule l'état des signaux de la carte d'acquisition et les mémorise dans le temps.
* Affiche la simulation de ces signaux dans le temps comme sur un oscilloscope.
==== 07/02/2013 ====
comité pilotage avec M. Conrard pour clarifier noter vision du projet et s'assurer d'être en accord. Il s'avère que nous n'avions pas vu le projet de la même manière. 
Nous devons en fait reprendre le programme C créer par l'étudiant, puis l'inclure dans notre programme. Nous ne reprendrons cependant pas les bibliothèques, ce qui permet de ne pas faire une exécution temps-réel, afin justement de pouvoir repérer les éventuelles erreurs pour qu'ensuite l'étudiant puisse lancer sont programme en temps-réel sans faire planter sa machine. 
Nous devons alors créer les fonctions (normalement temps-réelles) que le programme de l'étudiant appel, non pas pour les exécuter en temps-réel mais pour les simuler et générer un chronogramme. 
Nous avons alors créer un fichier étudiant test, et commencé à repérer les fonctions que nous allons devoir créer.

==== 11/02/2013 ====
Nous avons commencé à développer le programme C qui inclura celui de l'étudiant. Nous y avons déclaré toute les fonctions nécessaires. 
Nous avons fait un Makefile permettant d'inclure le programme étudiant, sans ses bibliothèques. La compilation fonctionne et à l'exécution nous arrivons à appeler les fonctions tâches de l'étudiant en dure dans notre main. 

==== 14/02/2013 ====
Nous avons fait des recherches sur l'ordonnancement des tâches. 
Nous avons aussi essayé d'écrire les fonctions d'impressions (affichage) temps-réels et la production d'un fichier texte pour dans un premier temps visualiser une ébauche chronogramme.

==== 25/02/2013 ====
Nous avons créer la page wiki. 
Nous avons essayer d'appeler une fonction en dynamique, car on ne connaîtra pas à l'avance les tâches déclarés par l'étudiant. Et là nous avons rencontré plus de problèmes que de solutions.
==== 27/02/2013 ====
résolution (partielle) du problème de l'appelle d'une fonction inconnue, avec un callback. 
création des structures pour stocker les informations relatives aux taches. 
recherche pour la production d'une image pour le chronogramme. 
recherche pour l'ordonnacement. 
==== 28/02/2013 ====
appropriation de la bibliothèque SDL pour creer une image. 
==== 04/03/2013 ====
réalisation des fonctions pour afficher le squelette des chronogrammes et le boitier 7 segments. 
recherches pour sauvegarder une image PNG. 
création d'un tableau récapitulatif de problèmes sur le projet et des solutions possibles. 
tests et débuggage du code. Écriture du code pour l'ordonnanceur. 
==== 06/03/2013 ====
recherche sur le chargement d'image avec sdl 
tests de .c 
comité pilotage avec M. Conrar : compte-rendu sur l'avancement du projet, réponse aux indéfinies, autre solution graphique 
recherche sur l'ordonnancement 
gestion de projet 
essais d'utilisation de RTAI 
recherche sur le language python 
==== 11/03/2013 ====
utilisation fonctionelle des callbacks dans les structures et appel ultérieur dans les fonctions, plus test. 
Recherches sur le language python.
==== 18/03/2013 ====
Recherches sur le language python.
==== 20/03/2013 ====
Comité pilotage. 
travail sur les sémaphore et mutex à plusieurs tâches, ainsi que les thread. 
Modification du code pour production texte des informations relatives à chaque tâche. 
==== 21/03/2013 ====
Expériences test pour comprendre tous les fonctionnements temps-réels de TP. 
Modification de l'algoritme d'ordonnacement avec sémaphore et mutex.
==== 25/03/2013 ====
modification du wiki. 
Etudes des codes fournis par M. Conrar sur mutex.

Analyseur de chronogramme

2013-03-25T15:48:15Z

Dgasnier : /* 06/03/2013 */

= Présentation du projet : =
==== Etudiants : ====
Bonvalet Quentin et Gasnier Damien
==== Encadrant : ====
Blaise Conrard
==== Objectif : ====
Réaliser un programme d'aide à la mise au point de modules temps-réel par la simulation de leur exécution et la génération d'un chronogramme de la séquence d’ordonnancement de ses tâches.
==== Description : ====
Lors des TP temps-réel, un outil d'aide au développement des modules réalisés pourrait faciliter la mise au point de ces modules. Son principe serait le suivant : il simulerait l'exécution d'un module ; il mémoriserait les instants d'exécution de chacune des tâches et les différents accès aux entrées/sorties réalisés ; puis en final, il retournerait un chronogramme de l'exécution des tâches et de l'évolution des signaux de signaux. Un tel outil serait d'une grande d'aide pour la compréhension et la réalisation des TP temps-réel.
= Avancement du projet =
==== 04/02/2013 ====
L'encadrant étant malade, nous avons interprété des objectifs et commencé à définir les tâches de notre projet: 
Programme ( C ), pour les TP temps-réel : 
1. Analyse (Recherche, Mémorisation et Vérification) : 
Avec notre exécutable on :
* Prend un ficher C à tester.
* Recherche et mémorise la définition des ports.
* Recherche et mémorise la « nano_period ».
* Recherche les fonctions (tâches séquentielles et par interruption) et mémorise leur noms.
* Mémorise l'exécution de ces fonctions ?
* Recherche les fonctions d'initialisation des tâches et vérifie la présence leur l'identifiant et leur nom dans fonction principale.
* Recherche les fonctions « make_periodic » et vérifie l'identifiant de la tache, mémorise pour chaque fonction le « now » et la période d'exécution.
* Recherche et vérifie la présence du « rt_task_wait_period(); » dans chaque boucle de tâche séquentielle, et sa non-présence pour une tâche IRQ.
* Recherche et vérifie qu'il y a un seul « stop_rt_timer (); »
* Recherche et vérifier les fonctions de suppression des tâches.
* Recherche-t-on et vérifie-t-on le bon ordre d'appel des tâches dans le « démarrer/arrêter » ?
2. Simulation : 
Grâce à l'analyse, on sait que le programme a bien défini les aspects temps-réel qu'un programme est sensé définir.
On en a dégagé les tâches avec leur départ d'exécution, leur période et leur contenu.
Il faut maintenant qu'on :
* Retourne un chronogramme de l'exécution des tâches.
* Simule l'état des signaux du boîtier d'E/S et les mémorise dans le temps.
* Affiche la simulation des afficheurs 7 segments.
* Simule l'état des signaux de la carte d'acquisition et les mémorise dans le temps.
* Affiche la simulation de ces signaux dans le temps comme sur un oscilloscope.
==== 07/02/2013 ====
comité pilotage avec M. Conrard pour clarifier noter vision du projet et s'assurer d'être en accord. Il s'avère que nous n'avions pas vu le projet de la même manière. 
Nous devons en fait reprendre le programme C créer par l'étudiant, puis l'inclure dans notre programme. Nous ne reprendrons cependant pas les bibliothèques, ce qui permet de ne pas faire une exécution temps-réel, afin justement de pouvoir repérer les éventuelles erreurs pour qu'ensuite l'étudiant puisse lancer sont programme en temps-réel sans faire planter sa machine. 
Nous devons alors créer les fonctions (normalement temps-réelles) que le programme de l'étudiant appel, non pas pour les exécuter en temps-réel mais pour les simuler et générer un chronogramme. 
Nous avons alors créer un fichier étudiant test, et commencé à repérer les fonctions que nous allons devoir créer.

==== 11/02/2013 ====
Nous avons commencé à développer le programme C qui inclura celui de l'étudiant. Nous y avons déclaré toute les fonctions nécessaires. 
Nous avons fait un Makefile permettant d'inclure le programme étudiant, sans ses bibliothèques. La compilation fonctionne et à l'exécution nous arrivons à appeler les fonctions tâches de l'étudiant en dure dans notre main. 

==== 14/02/2013 ====
Nous avons fait des recherches sur l'ordonnancement des tâches. 
Nous avons aussi essayé d'écrire les fonctions d'impressions (affichage) temps-réels et la production d'un fichier texte pour dans un premier temps visualiser une ébauche chronogramme.

==== 25/02/2013 ====
Nous avons créer la page wiki. 
Nous avons essayer d'appeler une fonction en dynamique, car on ne connaîtra pas à l'avance les tâches déclarés par l'étudiant. Et là nous avons rencontré plus de problèmes que de solutions.
==== 27/02/2013 ====
résolution (partielle) du problème de l'appelle d'une fonction inconnue, avec un callback. 
création des structures pour stocker les informations relatives aux taches. 
recherche pour la production d'une image pour le chronogramme. 
recherche pour l'ordonnacement. 
==== 28/02/2013 ====
appropriation de la bibliothèque SDL pour creer une image. 
==== 04/03/2013 ====
réalisation des fonctions pour afficher le squelette des chronogrammes et le boitier 7 segments. 
recherches pour sauvegarder une image PNG. 
création d'un tableau récapitulatif de problèmes sur le projet et des solutions possibles. 
tests et débuggage du code. Écriture du code pour l'ordonnanceur. 
==== 06/03/2013 ====
recherche sur le chargement d'image avec sdl 
tests de .c 
comité pilotage avec M. Conrar : compte-rendu sur l'avancement du projet, réponse aux indéfinies, autre solution graphique 
recherche sur l'ordonnancement 
gestion de projet 
essais d'utilisation de RTAI 
recherche sur le language python 
==== 11/03/2013 ====
utilisation fonctionelle des callbacks dans les structures et appel ultérieur dans les fonctions, plus test. 
Recherches sur le language python.
==== 18/03/2013 ====
Recherches sur le language python.
==== 20/03/2013 ====
Comité pilotage. 
travail sur les sémaphore et mutex à plusieurs tâches, ainsi que les thread. 
Modification du code pour production texte des informations relatives à chaque tâche. 
==== 21/03/2013 ====
Expériences test pour comprendre tous les fonctionnements temps-réels de TP. 
Modification de l'algoritme d'ordonnacement avec sémaphore et mutex.
==== 25/03/2013 ====
modification du wiki.

Analyseur de chronogramme

2013-03-06T16:57:25Z

Dgasnier : /* 04/03/2013 */

= Présentation du projet : =
==== Etudiants : ====
Bonvalet Quentin et Gasnier Damien
==== Encadrant : ====
Blaise Conrard
==== Objectif : ====
Réaliser un programme d'aide à la mise au point de modules temps-réel par la simulation de leur exécution et la génération d'un chronogramme de la séquence d’ordonnancement de ses tâches.
==== Description : ====
Lors des TP temps-réel, un outil d'aide au développement des modules réalisés pourrait faciliter la mise au point de ces modules. Son principe serait le suivant : il simulerait l'exécution d'un module ; il mémoriserait les instants d'exécution de chacune des tâches et les différents accès aux entrées/sorties réalisés ; puis en final, il retournerait un chronogramme de l'exécution des tâches et de l'évolution des signaux de signaux. Un tel outil serait d'une grande d'aide pour la compréhension et la réalisation des TP temps-réel.
= Avancement du projet =
==== 04/02/2013 ====
L'encadrant étant malade, nous avons interprété des objectifs et commencé à définir les tâches de notre projet: 
Programme ( C ), pour les TP temps-réel : 
1. Analyse (Recherche, Mémorisation et Vérification) : 
Avec notre exécutable on :
* Prend un ficher C à tester.
* Recherche et mémorise la définition des ports.
* Recherche et mémorise la « nano_period ».
* Recherche les fonctions (tâches séquentielles et par interruption) et mémorise leur noms.
* Mémorise l'exécution de ces fonctions ?
* Recherche les fonctions d'initialisation des tâches et vérifie la présence leur l'identifiant et leur nom dans fonction principale.
* Recherche les fonctions « make_periodic » et vérifie l'identifiant de la tache, mémorise pour chaque fonction le « now » et la période d'exécution.
* Recherche et vérifie la présence du « rt_task_wait_period(); » dans chaque boucle de tâche séquentielle, et sa non-présence pour une tâche IRQ.
* Recherche et vérifie qu'il y a un seul « stop_rt_timer (); »
* Recherche et vérifier les fonctions de suppression des tâches.
* Recherche-t-on et vérifie-t-on le bon ordre d'appel des tâches dans le « démarrer/arrêter » ?
2. Simulation : 
Grâce à l'analyse, on sait que le programme a bien défini les aspects temps-réel qu'un programme est sensé définir.
On en a dégagé les tâches avec leur départ d'exécution, leur période et leur contenu.
Il faut maintenant qu'on :
* Retourne un chronogramme de l'exécution des tâches.
* Simule l'état des signaux du boîtier d'E/S et les mémorise dans le temps.
* Affiche la simulation des afficheurs 7 segments.
* Simule l'état des signaux de la carte d'acquisition et les mémorise dans le temps.
* Affiche la simulation de ces signaux dans le temps comme sur un oscilloscope.
==== 07/02/2013 ====
comité pilotage avec M. Conrard pour clarifier noter vision du projet et s'assurer d'être en accord. Il s'avère que nous n'avions pas vu le projet de la même manière. 
Nous devons en fait reprendre le programme C créer par l'étudiant, puis l'inclure dans notre programme. Nous ne reprendrons cependant pas les bibliothèques, ce qui permet de ne pas faire une exécution temps-réel, afin justement de pouvoir repérer les éventuelles erreurs pour qu'ensuite l'étudiant puisse lancer sont programme en temps-réel sans faire planter sa machine. 
Nous devons alors créer les fonctions (normalement temps-réelles) que le programme de l'étudiant appel, non pas pour les exécuter en temps-réel mais pour les simuler et générer un chronogramme. 
Nous avons alors créer un fichier étudiant test, et commencé à repérer les fonctions que nous allons devoir créer.

==== 11/02/2013 ====
Nous avons commencé à développer le programme C qui inclura celui de l'étudiant. Nous y avons déclaré toute les fonctions nécessaires. 
Nous avons fait un Makefile permettant d'inclure le programme étudiant, sans ses bibliothèques. La compilation fonctionne et à l'exécution nous arrivons à appeler les fonctions tâches de l'étudiant en dure dans notre main. 

==== 14/02/2013 ====
Nous avons fait des recherches sur l'ordonnancement des tâches. 
Nous avons aussi essayé d'écrire les fonctions d'impressions (affichage) temps-réels et la production d'un fichier texte pour dans un premier temps visualiser une ébauche chronogramme.

==== 25/02/2013 ====
Nous avons créer la page wiki. 
Nous avons essayer d'appeler une fonction en dynamique, car on ne connaîtra pas à l'avance les tâches déclarés par l'étudiant. Et là nous avons rencontré plus de problèmes que de solutions.
==== 27/02/2013 ====
résolution (partielle) du problème de l'appelle d'une fonction inconnue, avec un callback. 
création des structures pour stocker les informations relatives aux taches. 
recherche pour la production d'une image pour le chronogramme. 
recherche pour l'ordonnacement. 
==== 28/02/2013 ====
appropriation de la bibliothèque SDL pour creer une image. 
==== 04/03/2013 ====
réalisation des fonctions pour afficher le squelette des chronogrammes et le boitier 7 segments. 
recherches pour sauvegarder une image PNG. 
création d'un tableau récapitulatif de problèmes sur le projet et des solutions possibles. 
tests et débuggage du code. Écriture du code pour l'ordonnanceur. 
==== 06/03/2013 ====
recherche sur le chargement d'image avec sdl 
tests de .c 
comité pilotage avec M. Conrar : compte-rendu sur l'avancement du projet, réponse aux indéfinies, autre solution graphique 
recherche sur l'ordonnancement 
gestion de projet 
essais d'utilisation de RTAI 
recherche sur le language python

Analyseur de chronogramme

2013-03-04T16:50:16Z

Dgasnier : /* 25/02/2013 */

= Présentation du projet : =
==== Etudiants : ====
Bonvalet Quentin et Gasnier Damien
==== Encadrant : ====
Blaise Conrard
==== Objectif : ====
Réaliser un programme d'aide à la mise au point de modules temps-réel par la simulation de leur exécution et la génération d'un chronogramme de la séquence d’ordonnancement de ses tâches.
==== Description : ====
Lors des TP temps-réel, un outil d'aide au développement des modules réalisés pourrait faciliter la mise au point de ces modules. Son principe serait le suivant : il simulerait l'exécution d'un module ; il mémoriserait les instants d'exécution de chacune des tâches et les différents accès aux entrées/sorties réalisés ; puis en final, il retournerait un chronogramme de l'exécution des tâches et de l'évolution des signaux de signaux. Un tel outil serait d'une grande d'aide pour la compréhension et la réalisation des TP temps-réel.
= Avancement du projet =
==== 04/02/2013 ====
L'encadrant étant malade, nous avons interprété des objectifs et commencé à définir les tâches de notre projet: 
Programme ( C ), pour les TP temps-réel : 
1. Analyse (Recherche, Mémorisation et Vérification) : 
Avec notre exécutable on :
* Prend un ficher C à tester.
* Recherche et mémorise la définition des ports.
* Recherche et mémorise la « nano_period ».
* Recherche les fonctions (tâches séquentielles et par interruption) et mémorise leur noms.
* Mémorise l'exécution de ces fonctions ?
* Recherche les fonctions d'initialisation des tâches et vérifie la présence leur l'identifiant et leur nom dans fonction principale.
* Recherche les fonctions « make_periodic » et vérifie l'identifiant de la tache, mémorise pour chaque fonction le « now » et la période d'exécution.
* Recherche et vérifie la présence du « rt_task_wait_period(); » dans chaque boucle de tâche séquentielle, et sa non-présence pour une tâche IRQ.
* Recherche et vérifie qu'il y a un seul « stop_rt_timer (); »
* Recherche et vérifier les fonctions de suppression des tâches.
* Recherche-t-on et vérifie-t-on le bon ordre d'appel des tâches dans le « démarrer/arrêter » ?
2. Simulation : 
Grâce à l'analyse, on sait que le programme a bien défini les aspects temps-réel qu'un programme est sensé définir.
On en a dégagé les tâches avec leur départ d'exécution, leur période et leur contenu.
Il faut maintenant qu'on :
* Retourne un chronogramme de l'exécution des tâches.
* Simule l'état des signaux du boîtier d'E/S et les mémorise dans le temps.
* Affiche la simulation des afficheurs 7 segments.
* Simule l'état des signaux de la carte d'acquisition et les mémorise dans le temps.
* Affiche la simulation de ces signaux dans le temps comme sur un oscilloscope.
==== 07/02/2013 ====
comité pilotage avec M. Conrard pour clarifier noter vision du projet et s'assurer d'être en accord. Il s'avère que nous n'avions pas vu le projet de la même manière. 
Nous devons en fait reprendre le programme C créer par l'étudiant, puis l'inclure dans notre programme. Nous ne reprendrons cependant pas les bibliothèques, ce qui permet de ne pas faire une exécution temps-réel, afin justement de pouvoir repérer les éventuelles erreurs pour qu'ensuite l'étudiant puisse lancer sont programme en temps-réel sans faire planter sa machine. 
Nous devons alors créer les fonctions (normalement temps-réelles) que le programme de l'étudiant appel, non pas pour les exécuter en temps-réel mais pour les simuler et générer un chronogramme. 
Nous avons alors créer un fichier étudiant test, et commencé à repérer les fonctions que nous allons devoir créer.

==== 11/02/2013 ====
Nous avons commencé à développer le programme C qui inclura celui de l'étudiant. Nous y avons déclaré toute les fonctions nécessaires. 
Nous avons fait un Makefile permettant d'inclure le programme étudiant, sans ses bibliothèques. La compilation fonctionne et à l'exécution nous arrivons à appeler les fonctions tâches de l'étudiant en dure dans notre main. 

==== 14/02/2013 ====
Nous avons fait des recherches sur l'ordonnancement des tâches. 
Nous avons aussi essayé d'écrire les fonctions d'impressions (affichage) temps-réels et la production d'un fichier texte pour dans un premier temps visualiser une ébauche chronogramme.

==== 25/02/2013 ====
Nous avons créer la page wiki. 
Nous avons essayer d'appeler une fonction en dynamique, car on ne connaîtra pas à l'avance les tâches déclarés par l'étudiant. Et là nous avons rencontré plus de problèmes que de solutions.
==== 27/02/2013 ====
résolution (partielle) du problème de l'appelle d'une fonction inconnue, avec un callback. 
création des structures pour stocker les informations relatives aux taches. 
recherche pour la production d'une image pour le chronogramme. 
recherche pour l'ordonnacement. 
==== 28/02/2013 ====
appropriation de la bibliothèque SDL pour creer une image. 
==== 04/03/2013 ====
réalisation des fonctions pour afficher le squelette des chronogrammes et le boitier 7 segments. 
recherches pour sauvegarder une image PNG. 
création d'un tableau récapitulatif de problèmes sur le projet et des solutions possibles. 
tests et débuggage du code. Écriture du code pour l'ordonnanceur.

Analyseur de chronogramme

2013-02-25T17:05:14Z

Dgasnier : /* 25/02/2013 */

= Présentation du projet : =
==== Etudiants : ====
Bonvalet Quentin et Gasnier Damien
==== Encadrant : ====
Blaise Conrard
==== Objectif : ====
Réaliser un programme d'aide à la mise au point de modules temps-réel par la simulation de leur exécution et la génération d'un chronogramme de la séquence d’ordonnancement de ses tâches.
==== Description : ====
Lors des TP temps-réel, un outil d'aide au développement des modules réalisés pourrait faciliter la mise au point de ces modules. Son principe serait le suivant : il simulerait l'exécution d'un module ; il mémoriserait les instants d'exécution de chacune des tâches et les différents accès aux entrées/sorties réalisés ; puis en final, il retournerait un chronogramme de l'exécution des tâches et de l'évolution des signaux de signaux. Un tel outil serait d'une grande d'aide pour la compréhension et la réalisation des TP temps-réel.
= Avancement du projet =
==== 04/02/2013 ====
L'encadrant étant malade, nous avons interprété des objectifs et commencé à définir les tâches de notre projet: 
Programme ( C ), pour les TP temps-réel : 
1. Analyse (Recherche, Mémorisation et Vérification) : 
Avec notre exécutable on :
* Prend un ficher C à tester.
* Recherche et mémorise la définition des ports.
* Recherche et mémorise la « nano_period ».
* Recherche les fonctions (tâches séquentielles et par interruption) et mémorise leur noms.
* Mémorise l'exécution de ces fonctions ?
* Recherche les fonctions d'initialisation des tâches et vérifie la présence leur l'identifiant et leur nom dans fonction principale.
* Recherche les fonctions « make_periodic » et vérifie l'identifiant de la tache, mémorise pour chaque fonction le « now » et la période d'exécution.
* Recherche et vérifie la présence du « rt_task_wait_period(); » dans chaque boucle de tâche séquentielle, et sa non-présence pour une tâche IRQ.
* Recherche et vérifie qu'il y a un seul « stop_rt_timer (); »
* Recherche et vérifier les fonctions de suppression des tâches.
* Recherche-t-on et vérifie-t-on le bon ordre d'appel des tâches dans le « démarrer/arrêter » ?
2. Simulation : 
Grâce à l'analyse, on sait que le programme a bien défini les aspects temps-réel qu'un programme est sensé définir.
On en a dégagé les tâches avec leur départ d'exécution, leur période et leur contenu.
Il faut maintenant qu'on :
* Retourne un chronogramme de l'exécution des tâches.
* Simule l'état des signaux du boîtier d'E/S et les mémorise dans le temps.
* Affiche la simulation des afficheurs 7 segments.
* Simule l'état des signaux de la carte d'acquisition et les mémorise dans le temps.
* Affiche la simulation de ces signaux dans le temps comme sur un oscilloscope.
==== 07/02/2013 ====
comité pilotage avec M. Conrard pour clarifier noter vision du projet et s'assurer d'être en accord. Il s'avère que nous n'avions pas vu le projet de la même manière. 
Nous devons en fait reprendre le programme C créer par l'étudiant, puis l'inclure dans notre programme. Nous ne reprendrons cependant pas les bibliothèques, ce qui permet de ne pas faire une exécution temps-réel, afin justement de pouvoir repérer les éventuelles erreurs pour qu'ensuite l'étudiant puisse lancer sont programme en temps-réel sans faire planter sa machine. 
Nous devons alors créer les fonctions (normalement temps-réelles) que le programme de l'étudiant appel, non pas pour les exécuter en temps-réel mais pour les simuler et générer un chronogramme. 
Nous avons alors créer un fichier étudiant test, et commencé à repérer les fonctions que nous allons devoir créer.

==== 11/02/2013 ====
Nous avons commencé à développer le programme C qui inclura celui de l'étudiant. Nous y avons déclaré toute les fonctions nécessaires. 
Nous avons fait un Makefile permettant d'inclure le programme étudiant, sans ses bibliothèques. La compilation fonctionne et à l'exécution nous arrivons à appeler les fonctions tâches de l'étudiant en dure dans notre main. 

==== 14/02/2013 ====
Nous avons fait des recherches sur l'ordonnancement des tâches. 
Nous avons aussi essayé d'écrire les fonctions d'impressions (affichage) temps-réels et la production d'un fichier texte pour dans un premier temps visualiser une ébauche chronogramme.

==== 25/02/2013 ====
Nous avons créer la page wiki. 
Nous avons essayer d'appeler une fonction en dynamique, car on ne connaitra pas à l'avance les tâches déclarés par l'étudiant. Et là nous avons rencontré plus de problèmes que de solutions.

Analyseur de chronogramme

2013-02-25T17:03:26Z

Dgasnier : /* 25/02/2013 */

= Présentation du projet : =
==== Etudiants : ====
Bonvalet Quentin et Gasnier Damien
==== Encadrant : ====
Blaise Conrard
==== Objectif : ====
Réaliser un programme d'aide à la mise au point de modules temps-réel par la simulation de leur exécution et la génération d'un chronogramme de la séquence d’ordonnancement de ses tâches.
==== Description : ====
Lors des TP temps-réel, un outil d'aide au développement des modules réalisés pourrait faciliter la mise au point de ces modules. Son principe serait le suivant : il simulerait l'exécution d'un module ; il mémoriserait les instants d'exécution de chacune des tâches et les différents accès aux entrées/sorties réalisés ; puis en final, il retournerait un chronogramme de l'exécution des tâches et de l'évolution des signaux de signaux. Un tel outil serait d'une grande d'aide pour la compréhension et la réalisation des TP temps-réel.
= Avancement du projet =
==== 04/02/2013 ====
L'encadrant étant malade, nous avons interprété des objectifs et commencé à définir les tâches de notre projet: 
Programme ( C ), pour les TP temps-réel : 
1. Analyse (Recherche, Mémorisation et Vérification) : 
Avec notre exécutable on :
* Prend un ficher C à tester.
* Recherche et mémorise la définition des ports.
* Recherche et mémorise la « nano_period ».
* Recherche les fonctions (tâches séquentielles et par interruption) et mémorise leur noms.
* Mémorise l'exécution de ces fonctions ?
* Recherche les fonctions d'initialisation des tâches et vérifie la présence leur l'identifiant et leur nom dans fonction principale.
* Recherche les fonctions « make_periodic » et vérifie l'identifiant de la tache, mémorise pour chaque fonction le « now » et la période d'exécution.
* Recherche et vérifie la présence du « rt_task_wait_period(); » dans chaque boucle de tâche séquentielle, et sa non-présence pour une tâche IRQ.
* Recherche et vérifie qu'il y a un seul « stop_rt_timer (); »
* Recherche et vérifier les fonctions de suppression des tâches.
* Recherche-t-on et vérifie-t-on le bon ordre d'appel des tâches dans le « démarrer/arrêter » ?
2. Simulation : 
Grâce à l'analyse, on sait que le programme a bien défini les aspects temps-réel qu'un programme est sensé définir.
On en a dégagé les tâches avec leur départ d'exécution, leur période et leur contenu.
Il faut maintenant qu'on :
* Retourne un chronogramme de l'exécution des tâches.
* Simule l'état des signaux du boîtier d'E/S et les mémorise dans le temps.
* Affiche la simulation des afficheurs 7 segments.
* Simule l'état des signaux de la carte d'acquisition et les mémorise dans le temps.
* Affiche la simulation de ces signaux dans le temps comme sur un oscilloscope.
==== 07/02/2013 ====
comité pilotage avec M. Conrard pour clarifier noter vision du projet et s'assurer d'être en accord. Il s'avère que nous n'avions pas vu le projet de la même manière. 
Nous devons en fait reprendre le programme C créer par l'étudiant, puis l'inclure dans notre programme. Nous ne reprendrons cependant pas les bibliothèques, ce qui permet de ne pas faire une exécution temps-réel, afin justement de pouvoir repérer les éventuelles erreurs pour qu'ensuite l'étudiant puisse lancer sont programme en temps-réel sans faire planter sa machine. 
Nous devons alors créer les fonctions (normalement temps-réelles) que le programme de l'étudiant appel, non pas pour les exécuter en temps-réel mais pour les simuler et générer un chronogramme. 
Nous avons alors créer un fichier étudiant test, et commencé à repérer les fonctions que nous allons devoir créer.

==== 11/02/2013 ====
Nous avons commencé à développer le programme C qui inclura celui de l'étudiant. Nous y avons déclaré toute les fonctions nécessaires. 
Nous avons fait un Makefile permettant d'inclure le programme étudiant, sans ses bibliothèques. La compilation fonctionne et à l'exécution nous arrivons à appeler les fonctions tâches de l'étudiant en dure dans notre main. 

==== 14/02/2013 ====
Nous avons fait des recherches sur l'ordonnancement des tâches. 
Nous avons aussi essayé d'écrire les fonctions d'impressions (affichage) temps-réels et la production d'un fichier texte pour dans un premier temps visualiser une ébauche chronogramme.

==== 25/02/2013 ====
Nous avons créer la page wiki. 
Nous avons essayer d'appeler les fonctions en dynamique, car on ne connaitra pas à l'avance les tâches déclarés par l'étudiant. Et là nous avons rencontré plus de problèmes que de solutions.

Analyseur de chronogramme

2013-02-25T16:58:19Z

Dgasnier : /* 14/02/2013 */

Analyseur de chronogramme

2013-02-25T16:43:07Z

Dgasnier : /* 11/02/2013 */

Analyseur de chronogramme

2013-02-25T16:35:27Z

Dgasnier : /* 07/02/2013 */

Analyseur de chronogramme

2013-02-25T16:33:42Z

Dgasnier : /* Avancement du projet */

Analyseur de chronogramme

2013-02-25T15:47:43Z

Dgasnier : /* Présentation du projet : */

Analyseur de chronogramme

2013-02-25T15:29:44Z

Dgasnier : /*Présentation du projet*/

Communication série, 2011/2012, TD1

2012-04-20T20:48:13Z

Dgasnier :

== Evaluation informatique ==

=== Gestion de projet / rédaction Wiki ===

Pas de test global. La rédaction est minimale mais correcte pour la partie informatique, on note aussi quelques coquilles (note 75%).
Le plus facile des sous-système mais réalisation laborieuse.

=== Test fonctionnels ===

* Sous-système : Fonctionnel mais minimal, beaucoup d'aide (note 75%).
* Système : Pas abordé (note 0%).

=== Qualité de la réalisation ===

* Procédure rédigée sur le Wiki : Un <tt>readme</tt> correct sur la FoxBoard (note 75%).
* Pages HTML et Javascript : Page HTML correcte, beaucoup d'aide (note 66%).
* Scripts PHP ou programmes C : Scripts PHP corrects, beaucoup d'aide (note 66%).
* Installation sur FoxBoard : Incomplète, le démon ne démarre pas à l'initialisation (note 66%).

=== Bilan ===

Tous les points ont un poids équivalent (sauf "système" qui est un bonus).

Note finale : 70% (14/20).

== Rapports des élèves ==

Partie électronique:

'''Mercredi 21 Mars 2012:'''

On a en entrée un signal sur 8 bits en parallèle. 
On a une liaison série qui est toujours à 1, tant qu'on ne transmet pas de données. 
A l'appui sur un bouton, on met le signal en série et on l’envoie sur la liaison. 
Le signal est réceptionné et remit en parallèle. 

'''Mercredi 28 Mars 2012:'''

Schéma d'émission : [[Fichier:schema_emission.png]] 
1: compteur 4 bit 
2: permet de savoir où le compteur en est 
3: entrée (les 8 bits à transmettre) 
4: la sortie du compteur détermine quel bit envoyer 
5: horloge 
6: 9 bascules D (8 pour le message + 1 pour le bit de start) 
7: led en sortie pour nous montrer ce qu'on affiche 

Schéma d'émission (zoom) : [[Fichier:schema-emission-reduit.png]] 
(rouge) 
1: fil indique que le compteur est entre 8 et 15 
2: bouton d'envoi 
3: signal à 1 car le signal doit être à 1 si on n’envoie rien 
4: les bits à envoyer arrivent par là 

(vert) 
1: reset du compteur lorsqu'on arrive à 8 ou lorsqu'on appuie sur le bouton 
2: bascule D passe à 1 si on compte jusqu'à et 1 lorsqu'on appuit sur le bouton 
3: on envoie toujours 1 sauf si on a appuyé sur le bouton 
4: on envoie 1 ou les bits à envoyer 

Sur la nanoboard, la LED est allumée tout le temps. Sauf quand on appuie sur le bouton et on le relâche, au bout de 8 temps d'horloge la LED clignote suivant les entrées qu'on lui a mise (mais au moins une fois pour le bit de start à 0). Et après 9 temps la LED reste allumée.

'''Mercredi 4 Avril 2012:'''

On essaye de faire la partie réception. Lors du test on se rend compte d'un problème au niveau de l'envoi.
Suite à une discussion avec le professeur, apparemment notre schéma est trop compliqué. On aurait dût utiliser un registre à décalage. Faute de temps on modifie seulement le schéma au niveau de la bascule D qui gère l'envoi des bits ou du 1 en continu (la bascule n°2 en vert dans le schéma de la semaine dernière.
On fait un troisième schéma pour relier le schéma d'envoi et le schéma de réception.

nouveau schéma d'émission: [[Fichier:Schema emission2.png]]

schéma de connexion: [[Fichier:Schema global.png]]

schéma de réception: [[Fichier:Schema reception.png]]

1: leds d'affichage du message reçu 
2: liason série 
3: le compteur permet de choisir ou envoyer les bits reçus 
4: horloge fonctionnant deux fois plus vite que l'horloge d'envoi et compteur 5 bits car on décale d'un demi temps d'horloge d'envoit, ainsi on enregistre le signal au milieu de la réception du bit. 
5: reset de l'horloge l'orsqu'on arrive à 16 

Finalement on arrive à envoyer un signal correct. Mais pas correctement car le signal reste à 0 si on reste appuyer sur le bouton d'envoi. La réception semble de pas fonctionner correctement.

Partie informatique:

On veut créer une site web où l'on entre des caractères, qui sont envoyé en parallèle vers une liaison série puis ils nous reviennent en parallèle.

Premierement, il faut rediger une page en html comprenant un champ 'émission' qui servira pour ecrire les caracteres que l'on veut envoyer via un port série. Deuxiement, il faut inclure dans la page web un champ 'réception' qui collectera les les differents caracteres envoyés depuis le champ ''''émision'''.
Nous devrons alors utiliser un formulaire pour cela. D'ou l'utilisation du PHP pour pouvoir rendre notre page web dynamique. Tout ceci represente schematisation du port serie sur via application web.

'''Mercredi 4 Avril 2012:'''

Pour pouvoir lire les caracteres qui seront entrés via le clavier, nous allons creer un fichier '''lecture.php''' se trouvant a l'adresse '''/var/www/serie''' il est inspiré du programme PHP donné en exemple qui utilise le démon. Le démon qui, ici, est un fichier '''serie.c''' devra etre compilé puis exécuté avant de pouvoir rendre l'application web opérationnelle. Nous disposons aussi d'un fichier '''écriture.ph''' qui sera lié à un fichier principal '''pageWebProjet.htm''', devant récupérer l'octet (les caractères) puis l'écrire dans le champ "écriture" de la page web. Ces deux programmes en PHP sont utilisés par un fichier principal en html qui fera appel à des fonctions en javascript par exemple la fonction '''AJAX REQUEST''' qui appellera les deux fichiers cités précédemment.notons aussi qu'un fichier '''prototype.js''' , bibliothèque permettant de lancer des requêtes HTTP asynchrone (objet Ajax.Request) mais aussi de faciliter la programmation javascript.

'''Jeudi 5 Avril 2012:'''

Le site étant opérationnel, nous devons l'adapter pour la FoxBoard. De ce fait, nous devons nous connecter en SSH vers la foxboard en utilisant l'adresse IP de la machine. Tout d'abord, il faut transferer les fichiers sources à savoir les fichiers php et html ainsi que le demon (serie.c) et la bibliotheque prototype.js en tapant la commande '''scp source root@172.26.79.10:/var/www/serie/'''
Un fichier '''readme.txt''' est disponible dans le dossier "root" et le repertoire '''/var/www/serie/'''

Communication série, 2011/2012, TD1

2012-04-20T20:46:19Z

Dgasnier :

== Evaluation informatique ==

=== Gestion de projet / rédaction Wiki ===

Pas de test global. La rédaction est minimale mais correcte pour la partie informatique, on note aussi quelques coquilles (note 75%).
Le plus facile des sous-système mais réalisation laborieuse.

=== Test fonctionnels ===

* Sous-système : Fonctionnel mais minimal, beaucoup d'aide (note 75%).
* Système : Pas abordé (note 0%).

=== Qualité de la réalisation ===

* Procédure rédigée sur le Wiki : Un <tt>readme</tt> correct sur la FoxBoard (note 75%).
* Pages HTML et Javascript : Page HTML correcte, beaucoup d'aide (note 66%).
* Scripts PHP ou programmes C : Scripts PHP corrects, beaucoup d'aide (note 66%).
* Installation sur FoxBoard : Incomplète, le démon ne démarre pas à l'initialisation (note 66%).

=== Bilan ===

Tous les points ont un poids équivalent (sauf "système" qui est un bonus).

Note finale : 70% (14/20).

== Rapports des élèves ==

Partie électronique:

'''Mercredi 21 Mars 2012:'''

On a en entrée un signal sur 8 bits en parallèle. 
On a une liaison série qui est toujours à 1, tant qu'on ne transmet pas de données. 
A l'appui sur un bouton, on met le signal en série et on l’envoie sur la liaison. 
Le signal est réceptionné et remit en parallèle. 

'''Mercredi 28 Mars 2012:'''

Schéma d'émission : [[Fichier:schema_emission.png]] 
1: compteur 4 bit 
2: permet de savoir où le compteur en est 
3: entrée (les 8 bits à transmettre) 
4: la sortie du compteur détermine quel bit envoyer 
5: horloge 
6: 9 bascules D (8 pour le message + 1 pour le bit de start) 
7: led en sortie pour nous montrer ce qu'on affiche 

Schéma d'émission (zoom) : [[Fichier:schema-emission-reduit.png]] 
(rouge) 
1: fil indique que le compteur est entre 8 et 15 
2: bouton d'envoi 
3: signal à 1 car le signal doit être à 1 si on n’envoie rien 
4: les bits à envoyer arrivent par là 

(vert) 
1: reset du compteur lorsqu'on arrive à 8 ou lorsqu'on appuie sur le bouton 
2: bascule D passe à 1 si on compte jusqu'à et 1 lorsqu'on appuit sur le bouton 
3: on envoie toujours 1 sauf si on a appuyé sur le bouton 
4: on envoie 1 ou les bits à envoyer 

Sur la nanoboard, la LED est allumée tout le temps. Sauf quand on appuie sur le bouton et on le relâche, au bout de 8 temps d'horloge la LED clignote suivant les entrées qu'on lui a mise (mais au moins une fois pour le bit de start à 0). Et après 9 temps la LED reste allumée.

'''Mercredi 4 Avril 2012:'''

On essaye de faire la partie réception. Lors du test on se rend compte d'un problème au niveau de l'envoi.
Suite à une discussion avec le professeur, apparemment notre schéma est trop compliqué. On aurait dût utiliser un registre à décalage. Faute de temps on modifie seulement le schéma au niveau de la bascule D qui gère l'envoi des bits ou du 1 en continu (la bascule n°2 en vert dans le schéma de la semaine dernière.
On fait un troisième schéma pour relier le schéma d'envoi et le schéma de réception.

nouveau schéma d'émission: [[Fichier:Schema emission2.png]]

schéma de connexion: [[Fichier:Schema global.png]]

schéma de réception: [[Fichier:Schema reception.png]]

1: leds d'affichage du message reçu 
2: liason série 
3: le compteur permet de choisir ou envoyer les bits reçus 
4: horloge fonctionnant deux fois plus vite que l'horloge d'envoi et compteur 5 bits car on décale d'un demi temps d'horloge d'envoit, ainsi on enregistre le signal au milieu de la réception du bit. 
5: reset de l'horloge l'orsqu'on arrive à 16 

Partie informatique:

On veut créer une site web où l'on entre des caractères, qui sont envoyé en parallèle vers une liaison série puis ils nous reviennent en parallèle.

Premierement, il faut rediger une page en html comprenant un champ 'émission' qui servira pour ecrire les caracteres que l'on veut envoyer via un port série. Deuxiement, il faut inclure dans la page web un champ 'réception' qui collectera les les differents caracteres envoyés depuis le champ ''''émision'''.
Nous devrons alors utiliser un formulaire pour cela. D'ou l'utilisation du PHP pour pouvoir rendre notre page web dynamique. Tout ceci represente schematisation du port serie sur via application web.

'''Mercredi 4 Avril 2012:'''

Pour pouvoir lire les caracteres qui seront entrés via le clavier, nous allons creer un fichier '''lecture.php''' se trouvant a l'adresse '''/var/www/serie''' il est inspiré du programme PHP donné en exemple qui utilise le démon. Le démon qui, ici, est un fichier '''serie.c''' devra etre compilé puis exécuté avant de pouvoir rendre l'application web opérationnelle. Nous disposons aussi d'un fichier '''écriture.ph''' qui sera lié à un fichier principal '''pageWebProjet.htm''', devant récupérer l'octet (les caractères) puis l'écrire dans le champ "écriture" de la page web. Ces deux programmes en PHP sont utilisés par un fichier principal en html qui fera appel à des fonctions en javascript par exemple la fonction '''AJAX REQUEST''' qui appellera les deux fichiers cités précédemment.notons aussi qu'un fichier '''prototype.js''' , bibliothèque permettant de lancer des requêtes HTTP asynchrone (objet Ajax.Request) mais aussi de faciliter la programmation javascript.

'''Jeudi 5 Avril 2012:'''

Le site étant opérationnel, nous devons l'adapter pour la FoxBoard. De ce fait, nous devons nous connecter en SSH vers la foxboard en utilisant l'adresse IP de la machine. Tout d'abord, il faut transferer les fichiers sources à savoir les fichiers php et html ainsi que le demon (serie.c) et la bibliotheque prototype.js en tapant la commande '''scp source root@172.26.79.10:/var/www/serie/'''
Un fichier '''readme.txt''' est disponible dans le dossier "root" et le repertoire '''/var/www/serie/'''

Communication série, 2011/2012, TD1

2012-04-20T20:44:17Z

Dgasnier :

== Evaluation informatique ==

=== Gestion de projet / rédaction Wiki ===

Pas de test global. La rédaction est minimale mais correcte pour la partie informatique, on note aussi quelques coquilles (note 75%).
Le plus facile des sous-système mais réalisation laborieuse.

=== Test fonctionnels ===

* Sous-système : Fonctionnel mais minimal, beaucoup d'aide (note 75%).
* Système : Pas abordé (note 0%).

=== Qualité de la réalisation ===

* Procédure rédigée sur le Wiki : Un <tt>readme</tt> correct sur la FoxBoard (note 75%).
* Pages HTML et Javascript : Page HTML correcte, beaucoup d'aide (note 66%).
* Scripts PHP ou programmes C : Scripts PHP corrects, beaucoup d'aide (note 66%).
* Installation sur FoxBoard : Incomplète, le démon ne démarre pas à l'initialisation (note 66%).

=== Bilan ===

Tous les points ont un poids équivalent (sauf "système" qui est un bonus).

Note finale : 70% (14/20).

== Rapports des élèves ==

Partie électronique:

'''Mercredi 21 Mars 2012:'''

On a en entrée un signal sur 8 bits en parallèle. 
On a une liaison série qui est toujours à 1, tant qu'on ne transmet pas de données. 
A l'appui sur un bouton, on met le signal en série et on l’envoie sur la liaison. 
Le signal est réceptionné et remit en parallèle. 

'''Mercredi 28 Mars 2012:'''

Schéma d'émission : [[Fichier:schema_emission.png]]
1: compteur 4 bit
2: permet de savoir où le compteur en est
3: entrée (les 8 bits à transmettre)
4: la sortie du compteur détermine quel bit envoyer
5: horloge
6: 9 bascules D (8 pour le message + 1 pour le bit de start)
7: led en sortie pour nous montrer ce qu'on affiche

Schéma d'émission (zoom) : [[Fichier:schema-emission-reduit.png]]
(rouge)
1: fil indique que le compteur est entre 8 et 15
2: bouton d'envoi
3: signal à 1 car le signal doit être à 1 si on n’envoie rien
4: les bits à envoyer arrivent par là

(vert)
1: reset du compteur lorsqu'on arrive à 8 ou lorsqu'on appuie sur le bouton
2: bascule D passe à 1 si on compte jusqu'à et 1 lorsqu'on appuit sur le bouton
3: on envoie toujours 1 sauf si on a appuyé sur le bouton
4: on envoie 1 ou les bits à envoyer

Sur la nanoboard, la LED est allumée tout le temps. Sauf quand on appuie sur le bouton et on le relâche, au bout de 8 temps d'horloge la LED clignote suivant les entrées qu'on lui a mise (mais au moins une fois pour le bit de start à 0). Et après 9 temps la LED reste allumée.

'''Mercredi 4 Avril 2012:'''

On essaye de faire la partie réception. Lors du test on se rend compte d'un problème au niveau de l'envoi.
Suite à une discussion avec le professeur, apparemment notre schéma est trop compliqué. On aurait dût utiliser un registre à décalage. Faute de temps on modifie seulement le schéma au niveau de la bascule D qui gère l'envoi des bits ou du 1 en continu (la bascule n°2 en vert dans le schéma de la semaine dernière.
On fait un troisième schéma pour relier le schéma d'envoi et le schéma de réception.

nouveau schéma d'émission: [[Fichier:Schema emission2.png]]

schéma de connexion: [[Fichier:Schema global.png]]

schéma de réception: [[Fichier:Schema reception.png]]

1: leds d'affichage du message reçu
2: liason série
3: le compteur permet de choisir ou envoyer les bits reçus
4: horloge fonctionnant deux fois plus vite que l'horloge d'envoi
et compteur 5 bits car on décale d'un demi temps d'horloge d'envoit, ainsi on enregistre le signal au milieu de la réception du bit.
5: reset de l'horloge l'orsqu'on arrive à 16

Partie informatique:

On veut créer une site web où l'on entre des caractères, qui sont envoyé en parallèle vers une liaison série puis ils nous reviennent en parallèle.

Premierement, il faut rediger une page en html comprenant un champ 'émission' qui servira pour ecrire les caracteres que l'on veut envoyer via un port série. Deuxiement, il faut inclure dans la page web un champ 'réception' qui collectera les les differents caracteres envoyés depuis le champ ''''émision'''.
Nous devrons alors utiliser un formulaire pour cela. D'ou l'utilisation du PHP pour pouvoir rendre notre page web dynamique. Tout ceci represente schematisation du port serie sur via application web.

'''Mercredi 4 Avril 2012:'''

Pour pouvoir lire les caracteres qui seront entrés via le clavier, nous allons creer un fichier '''lecture.php''' se trouvant a l'adresse '''/var/www/serie''' il est inspiré du programme PHP donné en exemple qui utilise le démon. Le démon qui, ici, est un fichier '''serie.c''' devra etre compilé puis exécuté avant de pouvoir rendre l'application web opérationnelle. Nous disposons aussi d'un fichier '''écriture.ph''' qui sera lié à un fichier principal '''pageWebProjet.htm''', devant récupérer l'octet (les caractères) puis l'écrire dans le champ "écriture" de la page web. Ces deux programmes en PHP sont utilisés par un fichier principal en html qui fera appel à des fonctions en javascript par exemple la fonction '''AJAX REQUEST''' qui appellera les deux fichiers cités précédemment.notons aussi qu'un fichier '''prototype.js''' , bibliothèque permettant de lancer des requêtes HTTP asynchrone (objet Ajax.Request) mais aussi de faciliter la programmation javascript.

'''Jeudi 5 Avril 2012:'''

Le site étant opérationnel, nous devons l'adapter pour la FoxBoard. De ce fait, nous devons nous connecter en SSH vers la foxboard en utilisant l'adresse IP de la machine. Tout d'abord, il faut transferer les fichiers sources à savoir les fichiers php et html ainsi que le demon (serie.c) et la bibliotheque prototype.js en tapant la commande '''scp source root@172.26.79.10:/var/www/serie/'''
Un fichier '''readme.txt''' est disponible dans le dossier "root" et le repertoire '''/var/www/serie/'''

Fichier:Schema reception.png

2012-04-20T20:37:44Z

Dgasnier :

Fichier:Schema global.png

2012-04-20T20:37:01Z

Dgasnier :

Fichier:Schema emission2.png

2012-04-20T20:36:05Z

Dgasnier :

Communication série, 2011/2012, TD1

2012-03-21T11:25:46Z

Dgasnier :

'''Mercredi 21 Mars 2012:'''

Partie électronique:

On a en entrée un signal sur 8 bits en parallèle. 
On a une liaison série qui est toujours à 1, tant qu'on ne transmet pas de données. 
A l'appuit sur un bouton, on met le signal en série et on l'envoit sur la liaison. 
Le signal est réceptionné et remit en parallèle. 

Partie informatique:

On veut créer une site web où on entre des caractères, qui sont envoyé en parallèle vers une liaison série puis ils nous reviennent en parallèle.

--DOCTYPE html-- 

<html>
<head>
<meta charset="utf-8" />
<title>Communication Série</title>
</head>

<body>

</body>
</html>

Communication série, 2011/2012, TD1

2012-03-21T11:24:49Z

Dgasnier :

'''Mercredi 21 Mars 2012:'''

Partie électronique:

On a en entrée un signal sur 8 bits en parallèle.
On a une liaison série qui est toujours à 1, tant qu'on ne transmet pas de données.
A l'appuit sur un bouton, on met le signal en série et on l'envoit sur la liaison.
Le signal est réceptionné et remit en parallèle.

Partie informatique:

On veut créer une site web où on entre des caractères, qui sont envoyé en parallèle vers une liaison série puis ils nous reviennent en parallèle.

--DOCTYPE html--

<html>
<head>
<meta charset="utf-8" />
<title>Communication Série</title>
</head>

<body>

</body>
</html>

Communication série, 2011/2012, TD1

2012-03-21T11:23:49Z

Dgasnier :

'''Mercredi 21 Mars 2012:'''

Partie électronique:

On a en entrée un signal sur 8 bits en parallèle.
On a une liaison série qui est toujours à 1, tant qu'on ne transmet pas de données.
A l'appuit sur un bouton, on met le signal en série et on l'envoit sur la liaison.
Le signal est réceptionné et remit en parallèle.

Partie informatique:

On veut créer une site web où on entre des caractères, qui sont envoyé en parallèle vers une liaison série puis ils nous reviennent en parallèle.


<html>
<head>
<meta charset="utf-8" />
<title>Communication Série</title>
</head>

<body>

</body>
</html>

Communication série, 2011/2012, TD1

2012-03-21T11:23:21Z

Dgasnier :

'''Mercredi 21 Mars 2012:'''

Partie électronique:

On a en entrée un signal sur 8 bits en parallèle.
On a une liaison série qui est toujours à 1, tant qu'on ne transmet pas de données.
A l'appuit sur un bouton, on met le signal en série et on l'envoit sur la liaison.
Le signal est réceptionné et remit en parallèle.

Partie informatique:

On veut créer une site web où on entre des caractères, qui sont envoyé en parallèle vers une liaison série puis ils nous reviennent en parallèle.

<--!DOCTYPE html-->
<html>
<head>
<meta charset="utf-8" />
<title>Communication Série</title>
</head>

<body>

</body>
</html>

Communication série, 2011/2012, TD1

2012-03-21T11:20:43Z

Dgasnier :

'''Mercredi 21 Mars 2012:'''

Partie électronique:

On a en entrée un signal sur 8 bits en parallèle.
On a une liaison série qui est toujours à 1, tant qu'on ne transmet pas de données.
A l'appuit sur un bouton, on met le signal en série et on l'envoit sur la liaison.
Le signal est réceptionné et remit en parallèle.

Partie informatique:

On veut créer une site web où on entre des caractères, qui sont envoyé en parallèle vers une liaison série puis ils nous reviennent en parallèle.

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Communication Série</title>
</head>

<body>

</body>
</html>

Communication série, 2011/2012, TD1

2012-03-21T07:36:58Z

Dgasnier :

'''Mercredi 21 Mars 2012:'''

- choix du sujet.

Communication série, 2011/2012, TD1

2012-03-21T07:36:03Z

Dgasnier : Page créée avec « Mercredi 21 Mars 2012: - choix du sujet. »

[[Mercredi 21 Mars 2012:]]

- choix du sujet.

Projets troisième année, 2011/2012, TD1

2012-03-21T07:28:53Z

Dgasnier : /* Répartition des binômes */

== Répartition des binômes ==

<table border="1">
<th>Projet</th>
<th>Elèves</th>
<tr><td>[[Contrôle de matrice leds, 2011/2012, TD1]]</td>
<td>célia amegavie, clément pons</td>
</tr>
<tr>
<td>[[Communication série, 2011/2012, TD1]]</td>
<td>Damien Gasnier, Ana Garcia, Ibrahima Kourouma</td>
</tr>
<tr>
<td>[[Gestion mémoire, 2011/2012, TD1]]</td>
<td>Prénom Nom, Prénom Nom</td>
</tr>
<tr>
<td>[[Gestion afficheurs, 2011/2012, TD1]]</td>
<td>Prénom Nom, Prénom Nom</td>
</tr>
<tr>
<td>[[Contrôle LED 256 couleurs, 2011/2012, TD1]]</td>
<td> Céline Burtaire, Thomas Champagne</td>
</tr>
<tr>
<td>[[Contrôle de sonar, 2011/2012, TD1]]</td>
<td>samir boudjema, robin gouenard, quentin bonvalet</td>
</tr>
<tr>
<td>[[Contrôle d'accéléromètre, 2011/2012, TD1]]</td>
<td>Prénom Nom, Prénom Nom</td>
</tr>
<tr>
<td>[[Contrôle de bras robotique, 2011/2012, TD1]]</td>
<td>Florent Chretien, Philippe Gombault, Stella Loembet</td>
</tr>
</table>