y'a pas moyen de voir comment le calculateur transmet au tableau de bord? (quoi que ça risque d'être difficile à faire bien ça)
sinon ouais un petit microcontroleur muni d'un compteur (un timer en mode comptage) dont la valeur est accessible via une bête lecture de registres (je sais que c'est possible au moins sur certains PIC, je l'ai déjà fait, et je subodore que c'est tout aussi possible sur les autres équivalents MCU 8 bits). du coup tu peux lancer ton compteur, et toutes les secondes (ou moins) lire la valeur faire les calculs pour vérifier si y'a pas eu débordement, éventuellement ajuster, convertir en vitesse, au besoin) et envoyer rapidement une trame I2C à la raspberry Pi. et là tu aurais le droit (privilège? ) d'abuser des fonctions Delay et ses subdivisions sans que je dise que c'est dégueulasse, c'est pas beau ça? (et eskimon est témoin, c'est pas souvent que je dis volontairement d'utiliser Delay, d'ailleurs ça doit bien être la premiere fois, IRL compris ). tu dois même pouvoir le faire faire à l'arduino, si elle ne fait rien d'autre de chronophage...
sinon, il faudra bien penser à utiliser un boitier métallique relié à la masse de la voiture, histoire de pas avoir trop de parasites, je sais que mon pere avait eu des soucis avec ses bricolage (sur une moto) a cause de ça...
Et pourquoi ne pas tout faire sur IT ? Avec des timers matériels pour compter le temps. En plus ça permet de mettre l'I2C de l'arduino en slave, ce qui me semble plus naturel comme architecture.
Merci pour ces informations mais je crains de ne pas tout comprendre... La pin 8 d'un arduino permettrait de mesurer une fréquence sans appels bloquants c'est ça ? Ajouter du hardware ça ne me dérange pas mais ça a un coût donc si c'est possible avec l'arduino directement ou en soft c'est pas plus mal
Pour l'architecture du projet je suis d'accord qu'il serait plus logique que le raspberry soit maitre dans la liaison I2C. Mais c'est l'arduino qui peut déterminer le moment où il doit envoyer des informations. Donc c'est pour cela qu'il est maitre et non pas esclave.
Le principe d'une entrée "capture" c'est que tu as un module (interne au microcontrolleur) qui une fois configuré incrémente une variable à chaque fois qu'il voit un front montant sur une certaine broche. Du coup, en comptant combien de front tu as eu sur une période de temps ca te donne une fréquence .
moi ça me choquait pas de mettre l'arduino en maitre... la RPi est là comme gestionnaire d'UI (en gros il sélectionne l'affichage en fonction de la situation, et le fournit en données), alors que l'arduino regroupe les infos, les envoie selon ce qu'il a, enfin je vois pas trop ce qui est gênant.
si natalya ou eskimon (ou même qui que ce soit d'autre) pouvait m'expliquer en quoi ça les dérange, je serais heureux de savoir.
par contre ça implique de faire de la programmation en évenementiel sur la carte raspberry Pi, pour qu'elle ne soit pas bloquée par l'arduino.
Dans ma tête je voyais bien la raspberryPi qui gérais tout le petit monde et l'Arduino qui s'occupait juste dêtre justement un simple gestionnaire d'I/O... mais après plusieurs approches sont possibles c'est sur !
J'avoue m’être longtemps posé la question dans ma logique Raspberry plus grosse, plus puissante plus forte donc maitre Mais en y reflechissant je me suis dis que non l'arduino ferait un meilleur maitre.
remace a écrit:
par contre ça implique de faire de la programmation en évenementiel sur la carte raspberry Pi, pour qu'elle ne soit pas bloquée par l'arduino.
Oui ça je suis d'accord, mais je vois pas encore bien ce que ça implique ?
ha c'est compliqué à expliquer bien, ça.
(dans mes termes, il est possible qu'eskimon et natalya qui travaillent dans le domaine hurlent "au bûcher!!!" )
pour faire simple, en séquentiel, tu as un seul "élément intelligent" qui envoie des requetes dès qu'il a besoin d'un truc, et attend les réponses pour continuer et comme il peut pas continuer sans les réponses, bah il bloque en attendant. du coup, pendant que la raspberry Pi attend la vitesse de la part de l'arduino, bah elle a arrêté l'affichage.
alors que si la raspberry Pi est programmée "en évenementiel" (toujours avec mon propre vocabulaire, l'inquisition peut prononcer son veto ), bah l'arduino envoie les données en boucle, quand ça l'arrange, et la raspberry Pi met a jour ses variables "dès qu'elle reçoit un truc" ( en programmation microcontroleur, on appellerait ça une interruption qui fait exécuter une routine, mais en prog "informatique", je vois pas trop comment réaliser ça -enfin si, mais c'est ultra crade et je suis pas sûr que ça marche, ou que ça soit académique- ) , et du coup elle a tout le temps qu'elle veut à consacrer à l'affichage (enfin presque, parce qu'il y a quand même le temps ou elle gere la réception des paquets, etc...). mais c'est beaucoup plus long à programmer, la structure du code est plus complexe aussi, mais le résultat permet une évolutivité "plus facile", et de ne pas bloquer tout l'affichage a cause d'un seul capteur, et puis ça fait un affichage plus fluide, et non bloqué par la moindre anomalie.
par contre une panne d'un périphérique (arduino, éventuellement un autre truc que t'auras rajouté en plus, etc...) est plus difficile à déceler, mais tu peux mettre en place un systeme de "derniere update" et gérer si c'est trop vieux...
si vraiment ça t'intéresse tu peux aller voir un peu dans le tuto sur les patterns de conception en POO, y'a de quoi potasser, notamment le modele observateur/observable, qui me semble bien utile dans ton cas, même si c'est pas la réponse à tout.
Ah oui on c'était mal compris Oui non pas de problème pour ça. Moi j'ai pris comme habitude (bonne ou pas j'en sais rien...) de mettre la récupération des infos dans un thread. Au moins, il y a rien de bloquant et on fonctionne comme le mécanisme que tu décrit. Après avec QT et ses signaux et slots je devrais réussir à me débrouiller pour faire marcher tout ce petit monde !
En fait, c'est une question d'évolutivité : l'arduino ne fait qu'agréger des données de capteur pour les rendre disponibles sur I2C. Si tu enrichi l'interface (par exemple en tactile, si tu rajoute un capteur sur le bus, etc, ...) il n'y a aucune raison pour que ça passe par l'arduino. C'est le RaspberryPi qui fait l'IHM, c'est lui qui est susceptible de générer des événements, il vaut mieux qu'il maitrise le bus. Accessoirement, c'est aussi lui qui a l'architecture la plus complexe, et il est plus à même que l'arduino de savoir quand Est-ce qu'il a besoin des données. L'arduino est démarré ou pas démarré, la machine d'état du RaspberryPi est bien plus complexe, et également bien plus instrumentée. Le système est plus facile à débugger avec le RaspberryPi master, à mon sens.
Après, le système est tout à fait fonctionnel avec l'arduino master.
J'ai oublié de vous préciser une toute petite chose. Mais qui au vu des discutions à peu être son importance ! C'est l'alimentation et le démarrage des cartes.
Je m'explique. Mon idée de base mais qui n'est pas encore fixée :
- Le Raspberry Pi démarre avec le contact de clé de la voiture.
- Le Raspberry s'éteint (via un script et les GPIO ou un message de l'arduino je ne sais pas encore) lorsque le contact se coupe, mais pas de manière brutale. Un système de relais et de tempo le maintiennent sous alimentation le temps qu'il s'éteigne.
- L'arduino lui restera sous tension (je vérifierais sa consommation énergétique), pour la simple raison qu'il est relié au module de réception des télécommandes de la voiture. Or si je veux ouvrir mes portières il doit être en fonctionnement pour pouvoir le faire.
Globalement l'arduino fonctionnera en permanence et s'occupera "d'allumer ou d'éteindre" le raspberry. Il y a peu être mieux mais j'ai pas trouvé Voilà ça me semblait important de le préciser, comme on parle de maitre/esclave et d'organisation de l'architecture !
Ad.
PS: La logique de Natalya est plus dans ma logique "naturelle", je me demande si je ne vais pas inverser ma façon de procéder....
Et pourquoi ne pas tout faire sur IT ? Avec des timers matériels pour compter le temps. En plus ça permet de mettre l'I2C de l'arduino en slave, ce qui me semble plus naturel comme architecture.
Ceci est d'autant plus vrai que linux n'opère qu'en mode maitre
En fait, c'est une question d'évolutivité : l'arduino ne fait qu'agréger des données de capteur pour les rendre disponibles sur I2C. Si tu enrichi l'interface (par exemple en tactile, si tu rajoute un capteur sur le bus, etc, ...) il n'y a aucune raison pour que ça passe par l'arduino. C'est le RaspberryPi qui fait l'IHM, c'est lui qui est susceptible de générer des événements, il vaut mieux qu'il maitrise le bus. Accessoirement, c'est aussi lui qui a l'architecture la plus complexe, et il est plus à même que l'arduino de savoir quand Est-ce qu'il a besoin des données. L'arduino est démarré ou pas démarré, la machine d'état du RaspberryPi est bien plus complexe, et également bien plus instrumentée. Le système est plus facile à débugger avec le RaspberryPi master, à mon sens.
Après, le système est tout à fait fonctionnel avec l'arduino master.
J'approuve également cette logique (sauf la dernière phrase biensur).
Je vois que ton projet avance à grand pas
Bon courage
- Edité par zmbongo 18 février 2014 à 12:13:02
Il n'y a pas de honte à ne pas savoir (faire) quelque chose que l'on n'a pas appris
Le fait que tu aies plus de dev à faire n'implique pas que ça ne marche pas. Tu peux tout à fait faire une application avec de l'I2C slave sous linux. J'en ai un exemple sur mon bureau. Cela étant, une fois encore, je le déconseille, c'est chiant à gérer.
Enfin, que l'arduino gère l'alimentation du RPi me semble assez logique, et ne s'oppose pas au fait que le RPi soit I2C master (en fait, ça simplifie même les choses, puisque l'arduino est forcément démarré quand le RPi démarre, ce qui garantit la disponibilité de l'esclave) (et là encore, j'ai un autre système sur mon bureau où un petit cortex-M0 gère l'alimentation d'un cortex-A9, qui lui même contrôle le M0 par I2C) (quand je dis "sur mon bureau, j'inclus les tiroirs, c'est pas tant le bordel que ça sur mon bureau). Par contre, une carte arduino consomme beaucoup, la carte n'est pas prévue pour faire des économies d'énergie. Ca peut être un frein au projet (pense au cas d'usage "je n'utilise pas ma voiture pendant 1 mois").
Désolé du retard beaucoup de boulot en ce moment ! Bon donc au vu des derniers messages je change mon idée. RPi en master et Arduino Mega en slave. Je suis malheureusement bloqué sur ce projet pour le moment car j'attends des composants de Chine et je ne peux pas faire grand chose sans...
Pour le sujet de l'alimentation, j'ai eu cet idée pour éviter au RPi de fonctionner en permanence et de me vider la batterie. Pour l'arduino même si il est vrai qu'il consomme un peu, on parle tout de même d'une batterie de voiture c'est assez costaud. De plus l'alarme d'origine, l'horloge et le système de télécommande sont déconnectés, ces derniers devaient au moins consommer autant qu'un Arduino Mega. Mais j'ai prévu un système de coupure, pour les longues périodes d'inactivité. Pour le moment c'est manuel, mais on peut imaginer l'alimentation de l'arduino qui passe par un relais contrôlé par l'arduino. Au bout d'un certain temps (1 ou 2 semaines) l'arduino se coupe lui-même, bon il faut juste que je trouve un moyen de le réarmer mais ça doit se faire !
Sinon Natalya tu as beaucoup de chance d'avoir des tiroirs sur ton bureau moi tout est dessus et c'est le bordel
c'est ce que j'étais en train de penser, natalya, c'est une personne qui a un ENOOOOOORRRRMMMMMEEEEEEEEEEEE bureau, ou qui en a plusieurs (genre BEAUCOUP), et qui a un nombre hallucinant de trucs électroniques dessus/dedans. parce que ce qu'il faut savoir c'est que c'est pas uniquement sur ton post qu'elle a deux ou 3 montages sur son bureau, c'est partout ou elle répond :-)
sinon, pour ton histoire d'alim commandée, un relais reed en parallele du relais commandé par l'arduino qui relance l'alim, que l'arduino se dépeche de réactiver. et aussi couper le reed (enfin je sais pas trop comment ça marche, en gros le reed doit rester fermé moins d'1s, comme ça il est de nouveau ouvert pour quand l'arduino s'éteint. l'inconvénient c'est qu'avec tes clefs, il faudrait aussi trainer un aimant avec toi, et que c'est à peu près pareil dans la gestuelle que de commuter un interrupteur.
pour un truc vraiment automatique, je vois pas bien comment faire un truc automatique qui a pas besoin d'énergie pour relancer le reste...
Ben après l'écriture de mon post j'ai étudié un montage possible et j'ai trouvé une solution. Un montage d'auto-maintien, j'avais vu ça dans mes cours d'électrotechniques (ça remonte ^^). Voilà le schéma de principe :
Je l'ai modifié pour que le bouton poussoir "On" soit un relais commandé par le 12V après contact (mes clés en faite), et en série avec le bouton poussoir "OFF" j'ai mis un relais normalement fermé commandé lui par l'arduino. Comme ça je peux couper manuellement ou automatiquement l'alimentation. C'est simple efficace et pas cher !
Bon plus qu'à attendre mes composants pour continuer...
c'est ce que j'étais en train de penser, natalya, c'est une personne qui a un ENOOOOOORRRRMMMMMEEEEEEEEEEEE bureau, ou qui en a plusieurs (genre BEAUCOUP), et qui a un nombre hallucinant de trucs électroniques dessus/dedans. parce que ce qu'il faut savoir c'est que c'est pas uniquement sur ton post qu'elle a deux ou 3 montages sur son bureau, c'est partout ou elle répond :-)
L'astuce, c'est de rendre le montage quand on a fini de jouer avec, et le jeter quand on n'en veut plus. Enfin, il faut savoir que ce ne sont pas forcément des montages différents. Il y a beaucoup de choses dans un autoradio android, et, de nous jours, on fait tenir l'équivalent d'un PC dans un circuit intégré de 4cm².
AdChildren a écrit:
Pour l'arduino même si il est vrai qu'il consomme un peu, on parle tout de même d'une batterie de voiture c'est assez costaud. De plus l'alarme d'origine, l'horloge et le système de télécommande sont déconnectés, ces derniers devaient au moins consommer autant qu'un Arduino Mega.
En première approche, il sera toujours possible de mettre l'arduino en veille sur coupure du 12V clef (le montage devrait être alimenté par le 12V général) et de sortir de veille au rétablissement du 12V clef ou autre IT externe (par exemple réception FM pour la télécommande). L'important, c'est de faire l'électronique, et notamment les tirages, dans le bon sens pour consommer le moins possible quand le véhicule est éteint.
En première approche, il sera toujours possible de mettre l'arduino en veille sur coupure du 12V clef (le montage devrait être alimenté par le 12V général) et de sortir de veille au rétablissement du 12V clef ou autre IT externe (par exemple réception FM pour la télécommande). L'important, c'est de faire l'électronique, et notamment les tirages, dans le bon sens pour consommer le moins possible quand le véhicule est éteint.
Qu'appelles-tu en veille ? C'est possible sur un arduino ? Sinon à peut de choses prés c'est exactement ce que j'ai prévu, pour tout les périphériques hormis la partie qui gère l'ouverture de la voiture tout s'éteint avec le 12V Clef.
J'ai bientôt fini le schéma global, vous comprendrais surement mieux avec Il y aura plus qu'à coder, le plus dur quoi...
En veille, je fais référence à "– Six Sleep Modes: Idle, ADC Noise Reduction, Power-save, Power-down, Standby, and Extended Standby" (document 2549Q–AVR–02/2014).
En veille, je fais référence à "– Six Sleep Modes: Idle, ADC Noise Reduction, Power-save, Power-down, Standby, and Extended Standby" (document 2549Q–AVR–02/2014).
J'ai regardé ces modes de veille, très intéressant, surtout power-down. Il faut que je prévoie le montage en conséquence pour avoir le signal des télécommandes sur une interruption et pouvoir réveiller l'arduino. Excellente référence merci !
En parlant de télécommandes je les ai reçues ! Voilà les bestioles :
Avec les sorties D1, D2, D3 et D4 correspondantes aux boutons 1, 2 ,3 et 4. Donc en réfléchissant un peu, j'ai prévu ça comme ordres de commande :
- 1 Appui Court: Fermeture
- 1 Appui Long : Remontées des vitres
- 2 Appui Court : Ouverture
- 2 Appui Long : Ouverture du coffre
- 3 Appui Court : Coupure alarme (Si en train de sonner)
- 3 Appui Long : Désactivation de l'alarme (donc mise en veille arduino, quand voiture verrouillée)
- 4 Appui Court : Signalisation (Clignotants pour trouver sa voiture dans un parking)
- 4 Appui Long : Activation de l'alarme (pas de mise en veille, car l'arduino doit contrôler les différents capteurs)
J'ai pu essayer ces télécommandes chinoises, télécommande pas trop cheap, bon matériaux, relativement bonne portée, temps de réaction rapide et piles pas chères et faciles à trouver. Et surtout prix dérisoire 15€50 l'ensemble...
J'ai aussi une Probe 2.5 V6, et mon voyant ABS reste allumé ; je n'ai malheureusement pas d'élément à te proposer pour ce que tu veux réaliser, mais comme tu as l'air spécialiste pour l'opération démontage du tableau de bord, peux-tu me fournir la marche à suivre pour le déposer, s'il te plaît?
× 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.
Retrouvez moi sur mon blog et ma chaine Youtube !
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 !
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.