Projet informatique - BFH
Transcription
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-