Projet informatique - BFH

Haute école spécialisée bernoise
Technique et Informatique
Section Electricité et systèmes de communication
Laboratoire d'Informtique technique
Projet informatique
Micro-contrôleur dans
les systèmes embarqués
 2012, BFH-TI, FUE1
Nom du fichier
Auteur:
Version:
Dernier changement:
Definition_du_projet_UCESY_2012.ODT
Dr. Elham Firouzi
3.1
1.04.2012
1 But du projet
Les étudiants sont en mesure de:
• Implémenter une application pour un système embarqué.
• Programmer l'interface CAN pour un micro-contrôleur.
• Implémenter correctement le traitement d'interruption.
• Inclure la notion de fiabilité dans la programmation des systèmes.
2 Cahier de charge
Les pilotes pour les différents types de nœud CAN, qui font parti du modèle de robot Stellaris, doivent être
implémentés durant ce projet informatique. Les différents types de nœud du robot modèle devrait être répartis
entre les différents groupes afin d'avoir un système fonctionnel à la fin du projet. Discutez entre vous afin de
répartir la programmation de différents types de nœud entre vous.
Exigence pour un nœud :
• La fonctionnalité requise doit être implémentée correctement.
• Tous les objets messages du protocole CAN doivent être soutenus correctement. Les télégrammes non
définis ou les paramètres faux doivent pouvoir être reconnus.
• Le nœud ne devrait pas perdre des objets messages. En particulier, il doit être en mesure de pouvoir
réagir correctement aux requêtes récurrents
• Le nœud doit être stable. Une utilisation prolongée ou des événements extérieurs ne devrait pas pouvoir
engendrer des blocages du système.
Taille des groupes:
Le projet devrait être réalisé en groupe. La taille des groupes peut varier entre 2 et 4 étudiants. L'évaluation
dépend de la taille du groupe. Les exigences sont plus importantes pour un groupe de 4 étudiants que pour un
groupe de 2 étudiants.
3 Les documents à livrer
1.
La documentation doit décrire la conception (design) et ne devrait pas dépasser les 10 pages. Elle doit
faciliter la prise en charge de votre programme. La documentation doit contenir au minimum les
informations suivantes :
a) Une vue d'ensemble des différents modules avec une brève description de chacun d'eux.
b) Des structogrammes (Nassi Shneiderman), des diagrammes de séquences, des diagrammes d'activités
et/ou d'autres types de diagramme (de préférence UML), qui document le programme principale, les
fonctions particulièrement importantes ou des séquences temporelles.
c) Certaines fonctions ne doivent pas être décrites dans cette documentation. Commentez ces fonctions
dans le code source en utilisant le format Doxygen.
La forme de la documentation n'est pas décisive pour l'évaluation (page d’en-tête, table des matières,
représentation) mais uniquement la qualité de la conception.
2.
Le code source y compris les fichiers de projet de Code Composer Studios (comprimez de préférence le
projet en entier dans un fichier zip). J'accorde beaucoup d'importance aux commentaires dans le code.
Vous pouvez m'envoyer la documentation soit par Email ou avec un CD, que vous pouvez déposer dans ma boîte
à lettre (salle 307 du bâtiment principale).
Délai en fonction des informations transmises durant le cours.
-2-