Rapport final - PastoriLucas/Projet_Elec_grp4 GitHub Wiki
Objectifs du projet
Dans le cadre du cours d’électronique digitale et analyse de signaux, la bonne connaissance des PIC’s devient presque incontournable dû à la grande utilisation de celles-ci. En effet, ces PIC’s deviennent des composants universels au sein des différents systèmes électroniques. Le but de ce projet est donc de créer un télémètre à ultrasons dont le résultat sera envoyé au PIC. Pour un affichage efficace, une application Java sera liée à ce projet afin de gérer le seuil limite de distance tolérée, ainsi que d’avoir un autre rendu de la distance reçue.
Répartition du travail au sein du groupe
Lors des premiers jours d’avancement du projet, nous nous sommes tous penchés sur la compréhension des différents logiciels et des différentes applications utilisées lors de l’élaboration de ce projet, principalement Proteus et Eagle. Cette découverte n’a pas été de tout repos, car ces logiciels ne sont pas faciles à utiliser (ou du moins lorsque l’on débute dessus) pour des étudiants comme nous n’ayant jamais utilisé de programmes électroniques comme ceux-ci. Après quelque temps, les premiers résultats fonctionnels apparaissent, chaque membre du groupe apportant sa propre pierre dans la construction de l’édifice.
Tandis que Matthieu et Lucas se sont plus penchés sur Eagle, Nathan et Gauthier se sont plus penchés sur Proteus et le programme en C, chacun ayant rempli sa partie pour l’échéance convenue.
C’est seulement 1 mois plus tard que nous nous sommes relancés dans le projet. La route était encore longue. Le programme en C comportait encore quelques erreurs et nous devions encore nous lancer dans le code Java pour l’interface graphique. La connexion entre cette interface et la simulation devait encore être programmée aussi. Lucas et Matthieu se sont donc intéressés au code Java, tandis que Gauthier a apporté les modifications nécessaires au code C. Une fois les deux parties terminées, nous avons travaillé tous ensemble sur la liaison entre l’interface graphique et Proteus ainsi que sur le rapport.
Résumé par partie : Répartition des tâches.xlsx
Schéma électronique finalisé et définitif de la carte
Les codes :
Code C :
https://github.com/PastoriLucas/Projet_Elec_grp4/tree/master/C
Code Java :
https://github.com/PastoriLucas/Projet_Elec_grp4/tree/master/Java/src/Final
Tests :
Conformité :
Les conditions un peu particulières de la fin de cette année académique ont rendu la réalisation de la partie physique de ce projet impossible. Nous nous sommes donc concentrés sur la simulation avec Proteus et l’interface Java. Notre projet ne suit donc pas totalement le cahier des charges, car celui-ci n’a pas été modifié malgré les changements liés aux conditions exceptionnelles auxquelles nous avons dû faire face. Le reste du projet est conforme aux attentes.
Planning
La première partie a été achevée dans les temps pour la remise du rapport intermédiaire. Nous n’avions cependant pas encore entamé la programmation de l’interface Java et le code pour la simulation n’était pas encore complet. Gauthier c’est donc chargé de terminer cette partie de code C. Lucas et Matthieu ont ensuite codé l’interface Java. Nathan a quant à lui avancé dans le rapport. Ensuite, il restait la partie communication entre ces 2 entités. Nous nous sommes donc tous penchés sur cette tâche. Le projet complet n’a finalement été fonctionnel que ce 10 mai 2020. Matthieu et Nathan ont ensuite continué et clôturé la rédaction de ce rapport.
Problèmes rencontrés et solutions
Les données envoyées sur les ports RS232 sont des bits, envoyés 1 par 1. Nous n'arrivions pas à afficher les 3 chiffres envoyés par Proteus dans le bon ordre (par exemple si la distance est de 124cm, l’application Java reçoit une suite de 1, 2, 4, 1, 2 etc, donc celle-ci ne pouvait pas savoir si la distance était 124, 241 ou 412). Après réflexion, nous avons pensé à utilisation d’un bit supplémentaire, un ‘$’ dans notre cas, pour que Java puisse afficher uniquement les 3 chiffres qui suivent ce ‘$’.
Un autre problème que nous avons rencontré, est assez similaire au précédent. La grande différence est qu’elle implique la communication dans l’autre sens. Nous n’arrivions pas à envoyer des valeurs autres que des chiffres vers Proteus, or il nous fallait absolument un caractère indiquant le début du seuil pour qu’il puisse bien être lu. Nous avons dans un premier temps essayé de commencer la trame par une suite de 4 neufs. Malgré tout, avec cette méthode, un souci était toujours présent. En effet, si par malchance la distance reçue commençait par un neuf, la lecture serait faussée et ferait abstraction de celui-ci. Il a donc fallu persister et trouver une solution pour envoyer ce fameux caractère spécial. Après de longues recherches, la solution est apparue. Il a fallu envoyer le caractère spécial suivi du seuil sous forme de byte, pour que l’OutputStream (le canal de communication sortant de l’application Java) n’affiche pas d’erreur.
Un autre problème que nous avons rencontré a été la réception des données au niveau du PIC. En effet, après l’envoi des données vers l’application Java, nous nous sommes dit que terminer la communication dans l’autre sens ne serait pas tellement différent. Néanmoins, il a été extrêmement compliqué pour nous, car cette communication a révélé être bien plus difficile que ce qu’il paraissait.
Améliorations
Il y a beaucoup d’améliorations possibles sur l’interface Java. Nous avons simplement fait une interface fonctionnelle sans se soucier de l’aspect visuel. Elle reste simple d’utilisation et correctement structurée. Du point de vue fonctionnel, nous pourrions ajouter un système de limite maximale et minimale pour pouvoir vérifier si la distance récupérée par la sonde se situe dans une tranche de valeurs. Une amélioration possible sur Proteus, serait d’afficher les valeurs sur un nombre supérieur d'afficheurs 7-segments ou encore utiliser un écran pour afficher celles-ci. De plus, nous pourrions implémenter un système de sonnerie ou du moins une alerte sonore lorsque la distance dépasse le seuil maximal. Nous pourrions également gérer le débordement des registres dans la simulation Proteus. En effet, au-delà de certaines valeurs de tension, le timer déborde et se réinitialise donc. il serait possible alors de compter les débordements et de les rajouter par la suite. Toutefois, ces valeurs restent difficiles à visionner sur deux afficheurs 7-segment uniquement.
Conclusion
Nous attendions beaucoup la partie pratique avec la carte. Pour nous, elle aurait été la partie la plus ‘ludique’ et chouette à faire. Néanmoins, à cause des conditions exceptionnelles, cette partie du projet a été abandonnée, ce qui a découragé une partie du groupe. Malgré cela, le projet a été très instructif, nous a permis d’approfondir nos connaissances en programmation mais aussi à travailler avec des datasheets et de découvrir de nouveaux programmes. Ce projet nous a également ouvert les yeux sur un nouveau domaine d’application de l’informatique auquel nous n’avions jamais eu affaire. En tant qu’étudiants, c’est toujours un point positif de découvrir de nouveaux horizons dans notre domaine de prédilection.
Bibliographie
Datasheet contrôleur PIC 18F458 : http://ww1.microchip.com/downloads/en/devicedoc/41159e.pdf
Datasheet sonde à ultrasons HC-SR04 : https://cdn.sparkfun.com/datasheets/Sensors/Proximity/HCSR04.pdf https://docs.google.com/document/d/1Y-yZnNhMYy7rwhAgyL_pfa39RsB-x2qR4vP8saG73rE/edit
Datasheet port COM RS232 : https://www.alldatasheet.com/datasheet-pdf/pdf/81905/ETC/RS232.html
Datasheet décodeur CD4511 : https://pdf1.alldatasheet.com/datasheet-pdf/view/50863/FAIRCHILD/CD4511BC.html
RXTX :
https://www.youtube.com/watch?v=8rnCzYv_8WU&t=368s
https://www.youtube.com/watch?v=hteeNdA7pOo&t=262s
Programmation des PIC en C :
https://www.technologuepro.com/microcontroleur-2/chapitre-3-programmation-c-des-pic.pdf
Utilisation de la sonde HC-SR04 en C :
https://howtomechatronics.com/tutorials/arduino/ultrasonic-sensor-hc-sr04/