Suite à la discussion dans ce post, j'ai besoin de vos conseils pour choisir l'OS et le langage le plus adapté. Voici le détail de mon projet :
Description :
Je suis l'heureux propriétaire d'une Ford Probe, qui à l'origine dispose de ce compteur dans le tableau de bord :
Comme je suis bricoleur et que je trouvais ces aiguilles trop tristes, j'ai réalisé quelques modifications pour avoir un afficheur digital. Ceci grâce à un compteur de Mercury Villager voilà ce que ça donne :
Mais voilà petit problème les afficheurs étant assez grands, je n'ai plus la place en dessous pour remettre la rampe de lampes qui servent à l'affichage des états de la voiture ( Réserve d'essence, problème moteur, frein à main, ABS, etc... ). J'ai donc pensé à mettre un écran LCD piloté avec une Raspberry Pi pour afficher tous ces messages.
Mais petit à petit plein d'idées me sont venus en tête, outre l'affichage des 10 indicateurs d'origines, je souhaiterais indiquer des informations supplémentaires :
Température Intérieure / Extérieure
Humidité extérieure (j'ai le capteur qui traine donc autant l'utiliser ^^)
Info radar de recul (Déjà monté dans la voiture) et image caméra de recul (l'écran à deux entrées AV dont une qui lance l'image de la caméra automatiquement donc rien à faire pour ce point)
Vitesse du régulateur de vitesse
Animation au démarrage (succession d'images suffisamment rapide pour donner l'effet d'une animation ou vidéo à voir)
Temps depuis démarrage du moteur (pour la pause toutes les deux heures)
Heure / Date (Module RTC à ajouter)
Compteurs kilométriques personnalisés (Pour vidange, usure des pneus, courroie de distribution, ...)
GPS intégré
Et d'autres qui me viendront au fur et à mesure
Et enfin un petit HP pour avertir des choses importantes, manque d'huile ou autre. Voir peut être de la synthèse vocale (le Rpi est plein de possibilité autant en profiter )
Ecran :
Pour l'écran je vais prendre un écran de ce type. 3.5" double entrée AV et ça fonctionne en 12V.
On les trouvent pas cher sur Ebay et au moins la caméra de recul s'affichera automatiquement.
Donc je suis obligé de prendre ce type d'écran, pour la connectique (ma caméra de recul n'a qu'une sortie AV). Mais aussi pour la taille assez limité sur le tableau de bord (au plus large 8.3 cm voir moins). Bien évidemment je vais démonter l’écran Ebay, pour ne garder que la dalle et l’électronique et l'insérer sur la gauche du compteur (il y avait un autres écran d'origine mais c'était pour l'affichage de la consommation et comme ma voiture à pas de débitmètre il me servait pas je l'ai retiré).
Il ne sera pas tactile comme vous le voyez l’écran est derrière le volant et derrière une vitre, donc pas super pratique pour appuyer dessus et puis vu la taille...
Sur ma voiture je dispose de 5 boutons sur le volant je pense que l'on peut les détourner pour les utiliser avec le RPi (on voit les boutons sur la deuxième photo à gauche et à droite du logo Probe sur le volant)
Voilà le gros de mon projet, la récupération des informations n'est pas un problème, j'ai pour la plupart déjà tous les signaux 12V disponibles. En réalité c'est des signaux entre 12-14V donc pour récupérer les signaux et pas cramer la RPi, j'ai pensé à mettre des diodes Zener 3.3V ou 5V aux entrées pour diminuer la tension (des meilleures idées peut être ?)
Donc quelles solutions logicielles, langage de programmation, OS me conseillez-vous ? Voilà pour le moment, je n'ai encore rien acheter donc je suis ouvert à tous vos avis, critiques, ou conseils !
Ad.
- Edité par AdChildren 12 décembre 2013 à 15:24:38
Alors pour ce que tu veux faire, il te faudra certainement programmer en C (il me semble adapté pour du multi tache et/ou temp réel), étant donné que tu souhaiterai faire plusieurs acquisitions en parallele(?).
Rassure toi d'avoir les pin (broches) nécessaires pour y connecter les différent module (spi? i2C? Can? bus écran?)
Si tu ne veux pas te casser la tête, tu peux télécharger l'os raspbian, gratuitement et bidouiller à ta sauce. Si non, tu peu creer un OS from scratch, n'y integrer que les modules dont tu aura besoin, bref le personnaliser à ta sauce (mais c'est un peu compliqué si tu débute)
N'empêche, je pourrai t'aider dans l'avancement si besoin est
Cordialement
Il n'y a pas de honte à ne pas savoir (faire) quelque chose que l'on n'a pas appris
En effet pour du tactile , c'est un tiroir coulissant motorisé , qui pourrait entrer et sortir l'écran .
Ou fixation directe sur le volant . Un volant se remplace , ce que j'ai fais plusieurs fois .
- Edité par abuche le 12 décembre 2013 à 15:49:29
Euh changer mon volant, non... Pour des raisons d'esthétique de sécurité et de légalité. Après le tactile je n'y tiens vraiment pas ! J'ai vu des mini clavier + pad, je pense que ça fera l'affaire pour entrer les adresses dans le GPS ou autre.
zmbongo a écrit:
Alors pour ce que tu veux faire, il te faudra certainement programmer en C (il me semble adapté pour du multi tache et/ou temp réel), étant donné que tu souhaiterai faire plusieurs acquisitions en parallele(?).
Rassure toi d'avoir les pin (broches) nécessaires pour y connecter les différent module (spi? i2C? Can? bus écran?)
Si tu ne veux pas te casser la tête, tu peux télécharger l'os raspbian, gratuitement et bidouiller à ta sauce. Si non, tu peu creer un OS from scratch, n'y integrer que les modules dont tu aura besoin, bref le personnaliser à ta sauce (mais c'est un peu compliqué si tu débute)
N'empêche, je pourrai t'aider dans l'avancement si besoin est
Cordialement
Le C me parait être une bonne idée aussi, et en plus c'est le langage que je maitrise le plus. Après oui il y aura comme tu dis plusieurs acquisitions en parallèle. Pour le nombre de broches pas vraiment un problème, je pense mettre un petit microcontrôleur genre arduino UNO entre deux, il récupérera les infos et les transmettra au RPi via le port série (ou I2C à la limite si il y a un intérêt). Pour l'ecran j'utilise directement le port composite du RPi donc pas de problème non plus.
Concernant l'OS, c'est plus là où je suis dans le flou. Un OS from scratch pourquoi pas, je ne mettrais que le strict minimum et ça gagnera en efficacité et en rapidité. Problème, là ça dépasse mes compétences... La programmation ça va, mais là je n'ai jamais essayé. Tu as des infos sur le sujet ?
En tout cas merci pour ta proposition Tu as déjà réalisé des projets similaires ?
abuche a écrit:
C'est le projet qu'il faut écrire , vu que sortir des signaux ne mène nul part .
Il faut cerner des paramètres pour optimiser un fonctionnement .
Une Bdd enregistre tout et après tracé de courbe et calcul ..
Résultat , le moteur est bien réglé avec une conso
optimale entre 6 et 12 degrés extérieur au mois de Décembre . En Novembre , j'ai plus roulé sur autoroute
et c'est différent , vu que le moteur est mieux refroidit entre 12 et 15 degrés .
Je ne comprend pas tout là désolé Tu parles de gestion moteur là ? Pas besoin pour mon projet, pour la gestion moteur j'ai autre chose bien plus adapté, éprouvé et puissant => MegaSquirt
Merci à vous et bonne soirée,
Ad.
- Edité par AdChildren 16 décembre 2013 à 21:58:45
Désolé du retard mais entre le boulot et la préparation des fêtes j'ai pas eu le temps de poster ! J'avoue ne plus me souvenir comment on les fait, j'ai donc était voir le tuto de ce site. Voilà une ébauche de CdC :
L'introduction au problème posé :
Gestion d'un afficheur intégré dans un compteur de voiture. Le but de ce projet est de pouvoir utiliser un écran pour afficher des informations diverses sur le véhicule, mais également ajouter des fonctionnalités qui n'étaient pas présentes à l'origine.
On peut diviser les affichages en 3 catégories : - importants (ex: Erreurs moteurs, Airbags, ABs, etc.) - informatifs (Cruise control, clignotants, plein phare, etc.) - fonctionnels (GPS, caméra de recul, température, humidité, etc.)
Pour les interactions avec l'electronique du projet, un système de clavier/souris et de boutons sera utilisé. Vu l'emplacement de l'ecran derrière le volant l'utilisation d'un écran tactile est à éviter. Le projet devra également être capable de pouvoir émettre du son.
L'expression fonctionnelle du besoin :
1\ nom : Affichages "importants"
critères : Les affichages importants doivent être signalés par un message ou icônes sur l'afficheur. Un son devra également être émis. Voici la liste des informations considérées comme importantes :
Frein à main/frein
ABS
Portes ouvertes
Ceinture non bouclée
Airbag
Problèmes moteur
Son niveau : L'affichage doit être visible et rapide à comprendre. La puissance sonore doit être suffisament élévée pour être entendu dans un environnement bruyant (autoroute, musique, bouchons, etc.)
Sa flexibilité : Aucune
2\ nom : Affichages "informatifs"
critères : Les affichages informatifs doivent être signalés par un message ou icônes sur l'afficheur. Voici la liste des informations considérées comme informatives :
Plein phare
clignotants G/D
Cruise control
Vitesse du régulateur de vitesse
Heure, date
Temps depuis démarrage
Son niveau : L'affichage doit être visible et rapide à comprendre.
Sa flexibilité : Aucune
3\ nom : Affichages "fonctionnels"
critères : Les affichages fonctionnels doivent afficher le résultat d'une fonction du projet. Voici la liste des informations considérées comme fonctionnelles :
GPS
Température int/ext
Humidité extérieure
Compteur kilométriques personnalisés
Son niveau : L'affichage peut être moins visible que les autres ou occulté momentanément de façon partielle ou compléte, si une informations plus importantes est à afficher.
Sa flexibilité : Aucune
4\ nom : GPS
critères : Afficher la position du véhicule et le parcours à suivre. Une antenne GPS sera utilisé mais pas de connexion à internet, les a-GPS (GPS connectés) sont donc à proscrire.
Son niveau : N/A
Sa flexibilité : N/A
5\ nom : Prise de température
critères : Un système de capteurs doit être ajouter pour pouvoir relever la temperature exterieure et interieure du véhicule. Une fonctionnalité supplémentaire consiste à emmètre un son et un messgae mlorsque la temperature descend sous un certains seuil. Seuil en dessous du quel il y a un risque de gel.
Son niveau : Les températures relevées doivent être de -20°C à +50°C, précision de 0.5°C.
Sa flexibilité : Précision minimum de 1°C. Les seuils peuvent être plus importants.
6\ nom : Compteur Kilométriques personnalisés
critères : Relever la distance depuis un certains événement. Peut être remis à zéro. Liste des événements :
Changement pneus
Plein d'essence effectué
Changement courroie de distribution
Changement plaquette de freins
Son niveau : Le véhicule fournit un signal carré de 0-5V avec une fréquence proportionnel à la vitesse, il faut donc convertir ce signal en une distance.
Sa flexibilité : N/A
Les solutions proposées pour répondre à ce besoin :
Pour les interactions, il est possible d'utiliser les boutons du régulateur de vitesse placés sur le volant. Ils sont au nombre de 5 et accessible via un connecteur à 3 fils (un fil de masse et mesure de résistances sur les 2 autres fils pour connaitre le bouton appuyé). Pour l'ecriture de texte un mini clavier/souris USB sans fils peut être utilisé.
Voilà c'est un début de quelque chose, après je ne vois pas d'autre chose pour le moment. Je vais commander mon RPi dans la semaine et l'ecran devrait arriver milieu du mois de janvier. En atendant vos idées et conseils, bonnes fêtes à vous !
Ad.
- Edité par AdChildren 24 décembre 2013 à 19:35:06
HA CA C'EST UN CAHIER DES CHARGES COMME ON AIMERAIT EN VOIR PLUS SOUVENT!!!
hésite pas à poster quand tu auras un peu avancé sur ton projet, ça m'intéresse.
traine un peu sur le forum, tu verras que c'est de la vraie joie non-simulée .
sinon, ouais je suis un peu intéressé par tout ce qui touche de près ou de loin à ces cartes "PC embarqué", et tout ce qui y touche. et ton projet m'intéressait pour la partie affichage. mais j'ai remarqué que sur ma carte j'ai pas de "prise RCA jaune composite", qui te servira surement pour l'affichage (j'ai pas pris une raspberri Pi mais une cubieboard 2). du coup bah ça l'intéressera, mais pas pour l'affichage
traine un peu sur le forum, tu verras que c'est de la vraie joie non-simulée .
sinon, ouais je suis un peu intéressé par tout ce qui touche de près ou de loin à ces cartes "PC embarqué", et tout ce qui y touche. et ton projet m'intéressait pour la partie affichage. mais j'ai remarqué que sur ma carte j'ai pas de "prise RCA jaune composite", qui te servira surement pour l'affichage (j'ai pas pris une raspberri Pi mais une cubieboard 2). du coup bah ça l'intéressera, mais pas pour l'affichage
Ah ben dans ce cas là merci J'ai regardé ta carte vraiment intéressante mais même problème pour mon projet que beaucoup d'autre, un unique port HDMI... J'avoue que la RPi c'est uniquement pour le port composite.
zmbongo a écrit:
bien défini ton cahier de charge
Dans ce cas dès que tu as tes élément, n'hésite pas à faire signe
Je t'aiderai au fur et à mesure de l'avancement donc n'hésite pas à poster
courage
Merci également, je vais passer la commande du Raspberry. L'ecran est en route mais les livraison de chine ça peut être long. Très sympa de proposer ton aide, j'en aurais surement besoin !
Vorex a écrit:
ça m'a l'air pas mal du tout comme projet, je vais suivre tout ça attentivement essaye de nous donner des nouvelles régulièrement !
Java , Android s'adapte à la taille des écrans . Le système d'origine de RsPi sera insuffisant pour mener à bien ce projet .
T'as une source pour ce que tu avances ? A ma connaissance, c'est linux qui s'occupe de gérer l'écran (via V4L2 par exemple), Android s'occupe juste de sortir la texture de la taille adaptée à la zone qu'on lui fournis, mais ça c'est pas compliqué, tout le monde le fait très bien (par exemple Qt, qui est assez utilisé dans le domaine).
RaspberryPi n'est pas un système complet, ce n'est qu'une carte électronique. Tu peux développer ce que tu veux au dessus. Tu récupère le linux et le BSP, tu configure ton système par un shell sur UART/USB/Ethernet/Whatever, et tu peux garder la sortie vidéo pour faire tourner un Qt sur V4L2, et afficher ce que tu veux sur l'écran avec une lib graphique moderne.
Tu récupère le linux et le BSP, tu configure ton système par un shell sur UART/USB/Ethernet/Whatever, et tu peux garder la sortie vidéo pour faire tourner un Qt sur V4L2, et afficher ce que tu veux sur l'écran avec une lib graphique moderne.
Je dois avouer que j'ai pas tout compris là Mais bon je ne doute pas de réussir à faire ce que je veux avec cette carte. Le premier problème ça va être trouver un OS qui boot très vite, léger et sans fonctionnalités superflues. Après le language C et Qt me plaise bien, mais je vais avoir besoin de me rafraichir les souvenirs et trouver de la doc sur Qt et Raspberry. Mais bon avec Google ça doit se trouver
Ad.
- Edité par AdChildren 27 décembre 2013 à 19:45:47
RsPi est un système complet . Avec que de l'affichage et sur un petit écran , c'est là où réside la difficulté .
Java , Android s'adapte à la taille des écrans . Le système d'origine de RsPi sera insuffisant pour mener
à bien ce projet .
FAUX! un simple microcontroleur 8 bits serait capable de réaliser tout le projet sauf rediriger le flux de la caméra de recul. donc le peu que ça demande, la Rpi en est capable.
autre remarque concernant la partie son, sur certains autoradios il y a un "flux interrupteur" qui coupe la radio et qui passe un son à la place (un truc qui sert pour infotrafic je crois, enfin à vérifier...) peut-être est-il possible de passer par là pour faire du bruit "fort"en cas de besoin.
sinon bah... il va falloir faire un trou pour passer un haut parleur, quelque part (pour aller facilement avec la sortie jack, il doit y avoir des "trucs pour téléphone" qui fonctionnent bien, ou directement des petites enceintes.
C'est beaucoup de jargon technique pour pas grand chose. L'idée est d'installer un linux qui va faire tourner une application en plein écran, plutôt que d'afficher un environnement de bureau comme le fait Raspbian. Comme l'écran sera utilisé par l'application que tu auras créée, la gestion du linux (pour le debug, notamment) se fera via une autre interface, par exemple un terminal sur une liaison série. Tout le reste, c'est des noms de technos pour que abuche puisse vérifier par lui même que les solutions existent. La liste n'est pas exhaustive, j'ai juste cité celles que je vois tous les jours au boulot (sur des produits de ce type)
RsPi est un système complet . Avec que de l'affichage et sur un petit écran , c'est là où réside la difficulté .
Java , Android s'adapte à la taille des écrans . Le système d'origine de RsPi sera insuffisant pour mener
à bien ce projet .
Ben de ce que j'ai vu sur différents blogs ou site, il y a pas mal de projet sur ce genre d'écran et cela ne semble pas poser de problème, à la différnece que moi j'ai pas le coté tactile mais bon ça je gère... Après le système d'origine qui n'est pas adapté j'en suis convaincu, c'est d'ailleurs le but de ce topic, c'est trouver ce qui marcherait le mieux
remace a écrit:
FAUX! un simple microcontroleur 8 bits serait capable de réaliser tout le projet sauf rediriger le flux de la caméra de recul. donc le peu que ça demande, la Rpi en est capable.
Oui ça j'en doutais pas A part les truc genre GPS sinon à la base j'étais partis sur de l'arduino mais pas assez évolutif à mon gout !
remace a écrit:
autre remarque concernant la partie son, sur certains autoradios il y a un "flux interrupteur" qui coupe la radio et qui passe un son à la place (un truc qui sert pour infotrafic je crois, enfin à vérifier...) peut-être est-il possible de passer par là pour faire du bruit "fort"en cas de besoin.
sinon bah... il va falloir faire un trou pour passer un haut parleur, quelque part (pour aller facilement avec la sortie jack, il doit y avoir des "trucs pour téléphone" qui fonctionnent bien, ou directement des petites enceintes.
Hum, pas bête ça je vais regarder ! Sinon oui mettre un HP ou passer un cable c'est pas un problème vu ce que ma voiture à déjà subit...
Natalya a écrit:
AdChildren a écrit:
Je dois avouer que j'ai pas tout compris là
C'est beaucoup de jargon technique pour pas grand chose. L'idée est d'installer un linux qui va faire tourner une application en plein écran, plutôt que d'afficher un environnement de bureau comme le fait Raspbian. Comme l'écran sera utilisé par l'application que tu auras créée, la gestion du linux (pour le debug, notamment) se fera via une autre interface, par exemple un terminal sur une liaison série. Tout le reste, c'est des noms de technos pour que abuche puisse vérifier par lui même que les solutions existent. La liste n'est pas exhaustive, j'ai juste cité celles que je vois tous les jours au boulot (sur des produits de ce type)
Ah ben d'un coup c'est beaucoup plus clair ça serait même parfaitement adapté à mon besoin ! Tu bosses là dedans ( Edit: c'est comme pour le port-salut c'est écrit dans le profil. Parrot, mon cousin bossait là bas, pas mal vos autoradio ) ? Je vais me renseigner sur ces choses, si tu as des articles intéressants je suis preneur !
Merci à vous,
Ad.
- Edité par AdChildren 27 décembre 2013 à 22:22:09
ou alors, comme il l'avait prévu, il utilise sa commande au volant (pourquoi un menu, tout se fait automatiquement pour les voyants, et apparemment pour le GPS il va prendre un mini clavier avec touchpad sans fil...)
Pour l'écran je vais prendre un écran de ce type. 3.5" double entrée AV et ça fonctionne en 12V.
3.5 " , c'est la taille smartphone . Qt a l'option mobile application avec ( Qt SDK ) .
Avec cette taille , il y aura 5 jauges et 3 textbox . Avec un mini pavet numérique usb
c'est un complément pour passer d'un menu à l'autre .
J'ai déjà pensé à ce genre de clavier voir même des mini claviers usb mais le fil en voiture ça va pas être pratique... Faut penser à la sécurité et à garder les yeux sur la route.
remace a écrit:
ou alors, comme il l'avait prévu, il utilise sa commande au volant (pourquoi un menu, tout se fait automatiquement pour les voyants, et apparemment pour le GPS il va prendre un mini clavier avec touchpad sans fil...)
Exactement, ça me semble le meilleur compromis, commandes au volant pour les petites actions (passer d'un affichage à l'autre, changer les données affichées, etc... ) et le clavier complet dans la boite à gants que l'on sort pour entrer une adresse.
Bon j'avance petit à petit sur mon projet. J'ai reçu et pris en main le raspberry et l’écran, tout fonctionne bien et j'ai créé une petite application en C++ avec QT. Impeccable !
Actuellement je suis en train de créer le schéma de toutes les cartes et composants du système. C'est pas évident mais ça avance. Globalement voici le principe :
Un arduino Méga récupère tous les signaux du véhicule et contrôle plusieurs relais afin d'agir sur le véhicule. Le raspberry lui reçoit des informations venant de cet arduino et les affiche sur l’écran LCD. Sachant que je souhaiterais gérer le régulateur de vitesse avec l'arduino Méga, et que la mesure de la vitesse se fait via des interruptions. Que me conseillez-vous pour la communication entre le Pi et l'arduino ? J'étais parti sur une liaison série mais j'ai lu que celle-ci s’arrêtait lors des interruptions. Est-ce le même avec une liaison I2C ? J'imagine que oui... Quelle liaison serait la plus efficace et la plus rapide ? UART ou I2C ? Sachant que les seules donnés à faire transiter, sont des nombres ou des états ( true / false ).
Enfin est-il judicieux d'employer un autre arduino (Uno) pour ne gérer que la régulation de vitesse et laisser la méga gérer l'acquisition des donnés et la communication avec le Pi ? Sachant que dans ce cas une liaison entre la méga et la Uno serait tout de même nécessaire pour faire transiter l'état des commandes aux volant.
J’espère être clair Je finis au plus vite le schéma global et je vous le post ça sera surement plus clair !
pour répondre à ta question, je dirais que c'est mieux de mettre la régulation de vitesse sur le même microcontroleur que l'acquisition de la vitesse. enfin que ta régulation soit totalement indépendante du reste (la régulation passe aussi par la mesure ou l'estimation de la grandeur à réguler).
après, j'avais pas vu que tu voulais bricoler un régulateur, rappelle toi que c'est pas franchement facile, et que c'est pas forcément une bonne idée d'un point de vue sécurité de faire ça "maison". certains se rappelleront des défauts de fabrication des régulateurs renault sur les mégane 2, là ou les personnes qui ont "dessiné" le système étaient nombreux et payés pour ça avec des exigences de résultats. rappelle-toi que les modifications de ta voiture, quand elles touchent à son fonctionnement, peuvent être des motifs de rupture de contrat pour ton assureur, a moins que tu aie un certificat des mines comme quoi ta voiture est toujours sécuritaire, et ça coute suuuper cher. dans tous les cas, garde ton code de coté une fois que tu se valide comme définitif, il risque de te servir.
évidemment, dans ton cas, j'utiliserais un bus CAN, mais ni raspberry Pi ni l'arduino n'en sont équipés. dans tous les cas, je me tournerais vers un bus synchrone, donc SPI ou I²C (aussi appelé TWI sur les composants ATMEL, parce qu'I²C est un nom déposé par philips).
Gros +1 pour l'avertissement sécurité de remace...
Faire de la supervision : OK
Jouer avec les leves-vitres et l'autoradio : OK
Jouer avec les élèments critiques : moteur, frein, phares... NOT OK !!
Donc tu conseil plutôt l'utilisation de l'I2C (TWI), ok ben je vais voir comment faire ça. Arduino maitre et Raspberry esclave ça devrait le faire.
Pour le régulateur c'est pas la top priorité, si ça se fait ça se fera en dernier mais autant prévoir tout de suite.Après pour les raisons de sécurité j'en suis conscient évidemment et j'ai réfléchis à un système mécanique d’arrêt d'urgence qui coupe la dépression d'air et force les électrovanne à s'ouvrir au moins pas de risque que ça s'emballe. J'ai le régulateur d'origine sur la voiture, mais il est assez basique c'est ça qui me dérange. Pas de possibilité de fixer une vitesse précise, pas moyen d’incrémenter de 10km/h ou des vitesses préfixées ( 90, 110, 130) c'est surtout pour ça que je veux gérer la régulation moi même ! Et surtout je suis pas sur qu'il marche encore... (il a été démonté pour installer le GPL et je l'ai pas encore remonté... )
Mais bon je vais déjà réaliser tout le reste De toute façon régulateur ou pas ma question tient toujours puisque j'utilise des interruptions pour d'autres choses...
en fait, les interruptions tu en as plusieurs sortes, si je me rappelle bien sur la carte arduino. tu as les prioritaires sur tout (coupure de l'alim, bouton reset, et autres trucs de ce type auxquels on ne pense jamais), tu as ce qu'on pourrait appeler des interruptions externes, qui peuvent servir pour faire des comptages sur des passages de dents d'engrenages, enfin c'est quelque chose qui peut surveiller l'état d'une tension sur une broche, et tu as des interruptions internes qui se font sur les périphériques internes, comme par exemple sur un controleur de bus CAN (qui génere des interruptions quand un message transite sur le bus, et qu'il t' est destiné), ou un timer (registre qui s'incrémente, et qui interrompt le microcontroleur sur certains évenements, programmables évidemment). le truc avec ces interruptions, c'est que déjà ça "coupe le microcontroleur, pour prioriser une série d'action" donc tu n'as plus vraiment de notion du temps si tu fais des mesures longues, par exemple pour de la vitesse, ça commence à être diffficile. ensuite, dans ton cas, tu as un autre probleme, c'est que ces mêmes timers, qui servent pour faire des mesures, du comptage, etc... sont aussi utilisés par les libs Arduino (et sans vergogne en plus...) pour la liaison USB avec le PC par exemple, ou les interfaces de communications comme tu le souligne.
par contre, je continue de te déconseiller de bricoler un régulateur. c'est compliqué, pas à la portée du premier venu, et ça met en jeu la sécurité (et pas que la tienne, soit dit en passant). comme le dit eskimon, il y a des trucs qu'on peut bricoler, et d'autres qu'on ne peut pas. et comme lui, je pense que tout ce qui touche à la bonne marche du véhicule, donc moteur, freins, etc... n'a pas à être modifié. des équipes completes chez ford se sont occupés de concevoir ta voiture, même si ça fait 10 ans, ils avaient des moyens que tu n'as pas, notamment peut-être 500 ingénieurs pour faire le calculateur de la voiture, que tu essaie de remplacer par un arduino mega programmé tout seul à l'arrache.
voilà. personnellement, pour la partie régulateur, je ne t'aiderai pas. tout le reste du systeme, c'est sympa, ça mange pas de pain, OK, mais pour la sécurité je plaisante pas.
Ok très bien oublions le régulateur alors ! Si c'est si dangereux que ça je suis pas super chaud. Mais je dois tout de même mesurer les RPM et la vitesse ( fermeture automatique des portières par exemple ). Connais-tu un autre moyen de mesurer ce type de donnés (Signal carré de fréquence variable) sans interruption ? Ou un moyen de repérer un front montant autrement qu'avec une interruption ?
Sinon autre technique : mesurer la vitesse, arrêter les interruptions, envoyer les donnés au Pi et reprendre les mesures... A moins que je puisse réaliser une carte externe qui mesure tout ça et qui l'envoi à l'arduino mais j'avoue ne pas franchement voir comment là...
C'est dommage c'est deux mesures sont les deux points bloquants de mon projet ! Le reste fonctionne relativement bien. Il me reste la grosse partie Raspberry c'est plus long là et j'arrive pas à gérer la liaison série (ou I2C) en Qt... Je vais attaquer ça sérieusement dans la semaine. Je posterai les différentes avancés.
Avec Arduino tu peux utiliser PulseIn pour mesurer une durée d'état haut ou bas (et du coup déterminer une fréquence)... par contre c'est bloquant comme fonction
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
Retrouvez moi sur mon blog et ma chaine Youtube !
oui. non. enfin je regarde et je te dis.
Retrouvez moi sur mon blog et ma chaine Youtube !