Arduino Forum

International => Français => Topic started by: Super_Cinci on Aug 19, 2012, 10:50 am

Title: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 19, 2012, 10:50 am
Comme il n'est pas terminé, je ne le mets pas dans "réalisations et projets finis"...

Bonjour à tous,

Depuis plusieurs années, je traine dans ma tête un projet pour ma vieille auto (R11 1.4L 1987) :

un tableau de bord électronisé pour remplacer celui d'origine.

(http://pop.studio.free.fr/imgtmp/120819_1.jpg)

L'idée première était  de remplacer la jauge à essence (qui prend pas mal de place) par un compte-tour. On trouve dans les R19, R21, et même d'autres R11 des TDB avec compte-tour, même gabarit. Puis de fil en aiguille, j'ai fait évoluer les choses, en pensant à un écran LCD, puis aujourd'hui, deux LCD graphiques en conservant les connecteurs d'origine si un jour je veux remettre un tableau de bord d'origine (on ne peut jamais se fier à l'électronique dans une voiture, c'est bien connu).

Petit préliminaire...

Depuis plus d'un an, ma R11 est équipée d'un UNO qui récupère le signal du capteur PMH, en déduit la vitesse de rotation du moteur, et calcul la vitesse de la voiture en 5ème (connaissant les rapports de boîte, périmètre des roues, il suffit de multiplier la vitesse du moteur par un simple facteur pour trouver la vitesse théorique). Ce UNO gère également un servo-moteur qui tire sur le mécanisme d'accélérateur (via une simple ficelle dans une gaine de frein de vélo) et propose un mode "régulateur de vitesse". Ca marche plutôt bien, on peut réguler à 70, 90, 110 et 130. C'est même assez précis, puisqu'en régulant à 90, la vitesse varie de 85 à 92Km/h, et le régulateur se coupe de lui-même dès qu'il détecte la position "pied-levé" du servo moteur (généralement aux alentours de 94Km/h, qui reste en dessous de la limite des radars automatiques :D ), et dès qu'on touche la pédale de frein ou d'embrayage, il se coupe aussi. 5 boutons et un LCD 16x2 en guise d'IHM :

(http://pop.studio.free.fr/imgtmp/110603_4.jpg)

Une petite interface électronique qui se place à côté du moteur (mise en forme signaux PMH, alimentation servomoteur...)

(http://pop.studio.free.fr/imgtmp/110603_2.jpg)

Le servomoteur modifié (ajout d'un engrenage et déport du potentiomètre pour plus de puissance) :

(http://pop.studio.free.fr/imgtmp/110604_0.jpg)

Le système en lui-même :

(http://pop.studio.free.fr/imgtmp/110529_1.jpg)

(http://pop.studio.free.fr/imgtmp/110529_2.jpg)

Bref, j'ai l'intension de combiner le régulateur et les écrans LCD autour d'un MEGA2560.

Alors j'ai désossé un tableau de bord. découpe du plastique et fabrication d'une plaque de support des LCD (du CI double face, c'est super facile à travailler, et j'en ai plusieurs centaines de Kg...)

(http://pop.studio.free.fr/imgtmp/120819_2.jpg)

Les deux LCD "presque" à leurs places, ils ne sont pas encore fixés :

(http://pop.studio.free.fr/imgtmp/120819_3.jpg)

Puis, pour reprogrammer facilement les "serial back-pack" de sparkfun qui étaient complètement buggés d'origine, j'ai fait un shield maison pour arduino/ISP :

(http://pop.studio.free.fr/imgtmp/120819_5.jpg)

Et un autre shield pour relier l'ATMEGA168 du LCD aux RX/TX/RESET/alim d'une carte UNO dépourvue du DIP 328 :

(http://pop.studio.free.fr/imgtmp/120819_4.jpg)

Pour l'instant, j'en suis à la programmation des LCD. Distar (celui fabrique les LCD) n'a pas trop gazé, puisqu'il a forcé le driver T6963C en petite police de 5x7 sur une grille de 8x8. Le T6963C possède une police de 7x8 en interne, mais du coup inaccessible.

Les LCD possèdent une RAM assez importante que l'on peut découper à sa guise en "pages". On définit donc une page graphique (un octet = 8 pixels) et une page texte (1 octet = 1 caractère). J'ai calculé qu'on peut obtenir 22 pages graphiques et autant de pages texte. On peut ainsi écrire dans une page, alors que le LCD en affiche une autre. Je ne détaille pas plus le fonctionnement des LCD, ça ferait plutôt l'objet d'un topic que j'avais déjà créé à ce sujet.

Donc, dans l'idée, je programme le 168 du LCD pour qu'il dessine l'interface graphique voulue, et quand il reçoit une valeur par le port série, il l'affiche sous forme de texte ou de graphique. Côté MEGA2560, c'est super simple, car il me suffira d'envoyer par exemple les octets 0x15 puis 0x45 (0x15 pour "afficher vitesse" et 0x45 la valeur (69)) par port série, et le 168 se débrouille par la suite pour "bouger" l'aiguille sur l'écran et afficher "69 Km/h" à un endroit précis. Bref, je dispose d'une accélération matérielle assez puissante. j'accède aux LCD avec un port série pour chaque, c'est tout.

Le côté ARDUINO :

Le MEGA2560 va mesurer divers signaux et les transformer en valeurs à afficher sur les LCD. La liste non exhaustive :

Mais aussi remplir certaines fonctions...

A suivre!
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 19, 2012, 11:45 am
J'étale un peu sur plusieurs posts pour plus de clarté...

Un peu d'électronique, le choix des capteurs, solutions techniques :

Pour le calcul de la vitesse moteur, j'avais fait un topic pour tenter de trouver une solution de précision. En effet, le signal qui sort du capteur n'est pas très utilisable, puisqu'il donne un signal carré de 44 impulsions par tour moteur, mais il manque deux "dents" à chaque demi tour de moteur. Ce "trou" dans le signal permet au calculateur (AEI) d'allumage de connaître la position des pistons et donc de générer l'étincelle aux bougies au bon moment en fonction de la vitesse de rotation et dépression dans l'admission. Donc je vais utiliser un ATMEGA328 qui va "extraire" deux données du signal du capteur : une impulsion correspondant au PMH des pistons et régénérer les "trous" du signal pour avoir un signal carré parfait pour compter la vitesse de rotation du moteur. voir le topic correspondant : http://arduino.cc/forum/index.php/topic,117531.msg888309.html#msg888309 (http://arduino.cc/forum/index.php/topic,117531.msg888309.html#msg888309)

Pour l'instant, le 328 me génère l'impulsion PMH ainsi qu'un signal carré de 64 impulsions par tour moteur (c'est tombé comme ça, les mesures n'en seront que plus précises...)

Calcul de la vitesse du véhicule :

D'origine, le compteur km est relié mécaniquement à la sortie de la boîte de vitesse par un câble qui tourne dans une gaine. J'avais deux solutions :

soit trouver un câble tout fait dans une casse. C'est le même câble, mais avec un boîtié dessus appelé "générateur d'impulsion" qui donne 1 impulsion tous les 20cm parcourus par la voiture. Dans l'idée, ce serait pas mal, mais malheureusement, selon le type de boîte de vitesse (il en existe plus de 200 qui ont été montées sur super5, R9, R11, R15... jusqu'à la R25, Clio, Twingo...), le câble de sortie de boîte ne tourne pas à la même vitesse, et les générateurs d'impulsions n'ont pas été conçus pour ma boîte, donc je n'aurai pas 1 impulsion par 20cm, mais un truc un peu plus batard (genre 18,55555555cm, 21.3333333cm...).

Reste la solution 2 : construire moi-même ce générateur d'impulsion. Pour celà, j'ai dépouillé un vieux compteur et adapté un petit engrenage qui fait tourner un moteur récupéré sur une imprimante HP.

(http://pop.studio.free.fr/imgtmp/120819_7.jpg)

(http://pop.studio.free.fr/imgtmp/120819_8.jpg)

ce n'est pas le moteur qui m'intéresse, mais le disque encodeur qu'il possède. Si ce moteur est bien connu sur le net comme pièce détachée, je n'ai pas trouvé le nombre de "crans" du disque. Il y a un capteur fourche en quadrature dessus, mais le sens de rotation m'importe peu, car en marche arrière, ça représente aussi des Km pour le moteur, donc autant les compter comme "parcourus". Alors j'ai fait un compteur avec un arduino qui m'affiche la valeur de sortie sur 8 leds (un octet à déchiffrer, mais avec l'expérience, j'arrive à traduire à la volée un octet de leds en valeur hexa...). Bref, pour un tour de câble compteur, j'ai une moyenne de 80 impulsions (j'ai fait une dizaine de relevés, sur un, deux et trois tours en entrée, chaque relevé me donnait la même chose à +/-1 : 335 crans sur le disque). en calculant rapidement, ça me donne une impulsion toutes les 2.0609xxxcm parcourus. pas très précis en fait... si je néglige le 0.06cm, ça me fait une erreur de 3%, soit 300Km sur 10000, ou encore 100Km/h au lieu de 103, pas bon.

A voir, car je connais tous les rapports de toutes les boîtes renault et les caractéristiques des compteurs associés, donc la solution 1 sera finalement peut-être plus précise, car là, je connais exactement le nombre de crans du générateur d'impulsion renault!

La mesure de la consommation :

Il suffit de récupérer sur une twingo ou clio ou R19/21/25 un débitmètre. C'est un petit boîtier qui se place à l'arrivée d'essence du carburateur, et donne une impulsion tous les 80µl qui passent. La conso ne peut pas être précise sur une seule de ces impulsions, même si je peux trouver le déplacement de la voiture à 20cm près, car l'essence qui passe par le débitmètre arrive dans une cuve tampon du carburateur, donc le débit se fait par oscillations (la pompe à essence "pousse" l'essence à chaque fois que le moteur a fait 2 tours, et le pointeau de régulation de remplissage de cuve donne une hystérésis sur le débit) donc une seule impulsion ne sera pas représentative du débit réel. Mais avec un petit calcul, à 100Km/h et une conso de 6l/100 (soit 10ml par seconde), le débitmètre me fournirait une impulsion toutes les 8ms. cela calculé sur 1 seconde (125 impulsions du débitmètre), quitte à moyenner sur 16 secondes (16 mesures), le calcul sera plus précis.
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 19, 2012, 12:09 pm
Un peu de programmation :

Pour ce qui est de la programmation des LCD, j'ai dû créer des tables de caractères pour pouvoir afficher les valeurs en un peu plus gros que les caractères de 5mm d'origine. J'ai fait deux polices, l'une reprenant la classique LCD, et une autre qui ressemble plus à du 7 segments. Comme je n'ai pas trop de mémoire, je n'ai créé que des chiffres. un chiffre représente quand même 9 octets (deux polices de 10 caractères  = 180octets en ram), par exemple, un 2 codé en police classique :

Code: [Select]

caractere_2[9] = {0x1C, 0x3E, 0x63, 0x03, 0x06, 0x18, 0x60, 0x7F, 0x3F}

Lorsque je me suis bien pris la tête à coder mes caractères, j'avais dans l'idée d'afficher en double les lignes de 1 à 6 du tableau pour diminuer la taille en mémoire, afin de sortir un caractère de 7x14 pixels avec seulement 9 octets. le résultat prévu était :
Code: [Select]

   XXX    1C
  XXXXX   3E
XX   XX  63
XX   XX
      XX  03
      XX
     XX   06
     XX
   XX     18
   XX
XX       60
XX
XXXXXXX  7F
  XXXXXX  3F

Sauf que j'avais oublié de doubler les lignes du milieu... ça m'a affiché ça :
Code: [Select]

   XXX    1C
  XXXXX   3E
XX   XX  63
      XX  03
     XX   06
   XX     18
XX       60
XXXXXXX  7F
  XXXXXX  3F

Petite erreur, mais intéressante finalement. Je me suis aperçu que je pouvais garder ça, donc j'ai défini deux tailles : 0 : simple en 7x9 (l'erreur), et 1 : 7x14 (l'idée d'origine) en doublant les lignes du milieu. Mais j'ai fini par élargir mes caractères en transformant mon octet "ligne" en un word, qui double chaque bits de l'octet, ce qui m'a permis d'obtenir deux tailles supplémentaires, taille 2 (14x9) :
Code: [Select]

      XXXXXX      1C
    XXXXXXXXXX    3E
  XXXX      XXXX  63
            XXXX  03
          XXXX    06
      XXXX        18
  XXXX            60
  XXXXXXXXXXXXXX  7F
    XXXXXXXXXXXX  3F

et taille 3 (14x14)
Code: [Select]

      XXXXXX      1C
    XXXXXXXXXX    3E
  XXXX      XXXX  63
  XXXX      XXXX 
            XXXX  03
            XXXX 
          XXXX    06
          XXXX   
      XXXX        18
      XXXX       
  XXXX            60
  XXXX           
  XXXXXXXXXXXXXX  7F
    XXXXXXXXXXXX  3F


Côté écran, ça donne ça :

(http://pop.studio.free.fr/imgtmp/120819_6.jpg)
(http://pop.studio.free.fr/imgtmp/120819_9.jpg)
Avec dans l'ordre des lignes :
- police interne du LCD 5x7
- police perso 0, taille 0
- police perso 1, taille 0
- police perso 0, taille 1
- police perso 1, taille 1
- police perso 0, taille 2
- police perso 1, taille 2
- police perso 0, taille 3
- police perso 1, taille 3

Il faut que je règle le contraste, c'est un peu faiblard...

Pour la rapidité d'affichage, le remplissage de l'écran ci-dessus est invisible. Pour ceux qui me connaissent, ils savent déjà que je n'utilise aucun digitalWrite() ou pinMode() pour envoyer les données du 168 au T6963C, ni aucun delay() dans les impulsions, le T6963 est donné pour des tempos de 100ns, mes signaux font minimum 2 cycles FOSC, donc 123ns, je suis pile-poil dans les temps!

Le rétroéclairage est géré par une PWM du 168, donc par logiciel. Le mec qui avait développé le code d'origine du 168 chez sparkfun avait utilisé le timer2 qui générait une interruption toutes les 0.5ms, et à chaque interruption, il comptait pour savoir où il en était. S'il avait atteint la valeur d'éclairage souhaitée, faisait un bit_set / bit_clear sur la pin de sortie. une belle PWM en soft, sûr, mais qui devait bouffer un temps pas possible dans le code. Il n'avait même pas vu qu'il avait câblé les leds du rétroéclairage sur la pin OC1B, et qu'il suffisait de faire tourner le timer1 en PWM pour se décharger de toute perte de temps. Tout comme il avait défini un buffer de réception série de 512 octets (donc indexé par une variable de 16 bits et occupation du quart de la RAM), alors qu'un buffer de 256 octets était suffisant et tellement plus pratique à gérer : un index sur 8 bits revient tout seul à zéro après 255, même pas besoin de faire un index = index % 256 ou encore un if (index > 255) index = 0... autre bug rigolo : selon l'inclinaison d'un ligne à tracer, il manquait des pixels. Il y a aussi une fonction qui était dans la doc, mais pas implémentée dans le code, quand on l'appelle par port série, le LCD l'affichait sous forme de caractères insensés.

Bref, je ne sais pas comment ils recrutent leurs développeurs chez sparkfun, mais il vaut mieux se méfier de leurs produits...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Aug 19, 2012, 12:17 pm


Bref, pour un tour de câble compteur, j'ai une moyenne de 80 impulsions (j'ai fait une dizaine de relevés, sur un, deux et trois tours en entrée, chaque relevé me donnait la même chose à +/-1 : 335 crans sur le disque). en calculant rapidement, ça me donne une impulsion toutes les 2.0609xxxcm parcourus. pas très précis en fait... si je néglige le 0.06cm, ça me fait une erreur de 3%, soit 300Km sur 10000, ou encore 100Km/h au lieu de 103, pas bon.

Bonjour Super_cinci
tu a aussi l'astuce d'utiliser les deux canaux A et B et de compter tous les flancs (montants et descendants) comme les canaux sont déphasés de 90° ça te multiplie par 4 le nombre de tops vu par tour.
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 19, 2012, 12:58 pm

Bonjour Super_cinci
tu a aussi l'astuce d'utiliser les deux canaux A et B et de compter tous les flancs (montants et descendants) comme les canaux sont déphasés de 90° ça te multiplie par 4 le nombre de tops vu par tour.
Il serait encore plus simple de coller une petite électronique avec un XOR entre les deux signaux A et B pour multiplier par 4 la précision en comptant tous les fronts (et ne pas bouffer plus de ressources de l'arduino, je vais déjà devoir souder des fils sur 8 pins non routées : les entrées de timers, les INT...), mais si tu regardes les photos de mon bricolage, tu vois que j'ai mis un réducteur entre le câble et le disque (ça divise la rotation du câble par 4.2 (10/42)). pour plus de précision, il me suffit de mettre le disque directement sur le câble, voire même d'inverser le réducteur... Mais il faut voire ensuite les capacités de comptage, car les 16 bits pourraient vite déborder... si j'ai 330 impulsions par tour de roue (pas de réducteur), ça me ferait dans les 200 000 impulsions pour 1Km (une imp correspondrait à 5mm, pas besoin d'autant de précision). Les 20cm du générateur d'impulsion Renault me suffiraient bien (puis côté mécanique, c'est étudié pour les vibrations etc etc...).

Puis le câble sur sa longueur (il fait 1m) peut "vibrer" et faire tourner le disque à l’envers de temps en temps, ne serait-ce qu'une seule impulsion générée à l'envers tous les deux tours de câble serait catastrophique pour ma précision...

Je vais aller chercher un générateur en casse pour tester (en notant le numéro de série de la boîte de vitesse sur laquelle il était, je saurai facilement trouver le bon calcul (combien de cm / impulsion).
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Aug 19, 2012, 02:33 pm
Ca c'est du Tuning !

Tu penses pouvoir encore pouvoir passer le contrôle technique avec çà ?

N'oublie pas le TimeCounter :
(http://i.telegraph.co.uk/multimedia/archive/02261/backtothefuture_2261121b.jpg)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Aug 19, 2012, 02:39 pm

Ca c'est du Tuning !

Tu penses pouvoir encore pouvoir passer le contrôle technique avec çà ?

N'oublie pas le TimeCounter :
(http://i.telegraph.co.uk/multimedia/archive/02261/backtothefuture_2261121b.jpg)


bonjour barbudor
je crois que les Delorean  ont eu une carrière  bien plus éphémère que les R11  :smiley-mr-green:
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Aug 19, 2012, 02:49 pm
Y'en a encore quelques unes qui roulent
Avec un peu d'imagination, on peu trouver une similitude avec la R11 (quoi que, plutot avec une Fuego...) XD
Title: Re: [Projet] Un tableau de bord numérisé
Post by: skywodd on Aug 19, 2012, 03:01 pm
Salut,

Un sacré projet que tu nous présente dit donc :smiley-eek:

L'écran LCD enfin le "backpack" pour être précis est complétement buggé, même sparkfun le reconnait ...
Il existe un firmware alternatif pas trop mal sur github (faut aller voir sur la page du produit), tu devrais leur envoyer un lien vers ton firmware ça aiderai beaucoup de personnes ;)

Encore bravo pour le travail accomplit, je suis sûr qu'il ya de longue heures derrière tout ça :smiley-mr-green:
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 19, 2012, 03:33 pm
Mécaniquement, la fuego est une bombe! super solide, surdimensionnée... mais tellement moche... Par contre, elle se rapproche très bien de la delorean... J'ai déjà une horloge à LCD (d'origine...), mais pour le fun, j'ai un emplacement au dessus du cendrillon qui pourrait accueillir ce genre de gadget, bien que je comptais l'utiliser pour ranger un clavier 4x4... Mais le cendrier ne me sert à rien, donc ça fait un emplacement supplémentaire (chiche?)


Salut,

Un sacré projet que tu nous présente dit donc :smiley-eek:

L'écran LCD enfin le "backpack" pour être précis est complétement buggé, même sparkfun le reconnait ...
Il existe un firmware alternatif pas trop mal sur github (faut aller voir sur la page du produit), tu devrais leur envoyer un lien vers ton firmware ça aiderai beaucoup de personnes ;)

Encore bravo pour le travail accomplit, je suis sûr qu'il ya de longue heures derrière tout ça :smiley-mr-green:
Ca va pas être facile de partager mon code, car il faut passer par arduino, donc booloader (mais un bidouilleur peut le récupérer "pour pièces", certaines routines peuvent simplifier la vie). Y'a aussi qu'il n'y a pas beaucoup de commentaires, et un code sans commentaires, c'est pas facile à (ré)utiliser. J'attendrai d'avoir implémenté la gestion du port série (le port est démarré, mais il n'y a pas de code pour lire les entrées)

Pour les heures, la première idée est arrivée vers 2005, a évolué en pensant aux pics fin 2008, et me chatouille un peu tous les jours depuis que j'ai découvert Arduino, mai 2011... Je ne compte plus le nombre de feuilles que j'ai noircies à force de bouts de code et de schémas temporaires, un peu chaque jour, surtout le matin pendant le café-clop, c'est là que mon cerveau me pond tout ce qu'il a inventé pendant la nuit...

Aujourd'hui, je mets tout ça au propre, et à chaque solution technique trouvée, un peu de code s'ajoute à la future version finale (pour l'instant, le code du MEGA ne contient que la gestion de l'accélérateur avec sauvegardes en EEPROM de quelques variables).

Il y a surtout que j'ai 4 ATMEGA à programmer (2 LCD, 1 gestion signaux moteur et 1 maître calculateur...)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Aug 19, 2012, 04:15 pm

Mécaniquement, la fuego est une bombe! super solide, surdimensionnée... mais tellement moche... Par contre, elle se rapproche très bien de la delorean...


[HUM]
La derniere fuego que j'ai vu en réel c'etait rue Pierre Demours  Paris 17, il y a déjà maintenant quelques années,  8)
je ne sais pas ce qu'elle est devenue après.

http://video.google.com/videoplay?docid=2349599298801115250
Title: Re: [Projet] Un tableau de bord numérisé
Post by: chicotore on Aug 19, 2012, 05:36 pm
C'est pas un poil dangereux le régulateur de vitesse ? je pense surtout en cas de défaillance électronique .... Enfin moi j'aurais pas confiance ^^
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 19, 2012, 05:48 pm

C'est pas un poil dangereux le régulateur de vitesse ? je pense surtout en cas de défaillance électronique .... Enfin moi j'aurais pas confiance ^^
Ca fait plus d'un an que je roule avec la version 1.0 (le UNO qui est déjà dessus), et jamais de soucis, que du bonheur.

Avec toute l'énergie qu'on perd à tout le temps faire attention à pas trop appuyer, maintenant, quand je roule 1 ou 2 heures en régulé, je sens bien l'agréable différence... et encore, la version que j'ai faite est assez limitée, il faudrait pouvoir réguler à la vitesse qu'on veut, car à 110, on se retrouve vite derrière quelqu'un qui roule à 109, et pour le dépasser, il faut désactiver le régulateur... Dans le prochain, on appuiera sur un bouton et ça régulera à la vitesse où on est. Ensuite, un bouton + et - pour ajuster au km/h près... Côté sécu, désactivation automatique dès qu'on touche une pédale (frein, embrayage, accélérateur, bouton d'arrêt d'urgence...) ou dès qu'on dépasse de 5km/h.
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 20, 2012, 04:20 pm
Suite : affichage des données sur LCD, programmation des "drivers" (atmega168 : "carte vidéo" série => LCD)

Histoire d'optimiser toujours et encore, aujourd'hui, j'ai travaillé sur l'affichage d'une aiguille et de sa valeur en texte à partir d'une donnée reçue par le port série du 168.

Pour la plus par des valeurs, une échelle de 256 pas suffit :


Coup de bol, si on part d'une valeur reçue sur 8 bits, avec un simple facteur entier (j'aime pas trop les opérations arithmétiques avec des floats quand il faut être rapide) et en plaçant la virgule au bon endroit (variable v), on obtient les valeurs suivantes :











facteurrangepasv=0v=1v=2v=3
10 à 25510 à 255 +/- 10 à 25,5 +/- 0.10 à 2,55 +/- 0.010 à 0,255 +/- 0.001
20 à 51020 à 510 +/- 20 à 51,0 +/- 0.20 à 5,10 +/- 0.020 à 0,510 +/- 0.002
30 à 76530 à 765 +/- 30 à 76,5 +/- 0.30 à 7,65 +/- 0.030 à 0,765 +/- 0.003
40 à 102040 à 1020 +/- 40 à 102,0 +/- 0.40 à 10,20 +/- 0.040 à 1,020 +/- 0.004
50 à 127550 à 1275 +/- 50 à 127,5 +/- 0.50 à 12,75 +/- 0.050 à 1,275 +/- 0.005
60 à 153060 à 1530 +/- 60 à 153,0 +/- 0.60 à 15,30 +/- 0.060 à 1,530 +/- 0.006
70 à 178570 à 1785 +/- 70 à 178,5 +/- 0.70 à 17,85 +/- 0.070 à 1,785 +/- 0.007
80 à 204080 à 2040 +/- 80 à 204,0 +/- 0.80 à 20,40 +/- 0.080 à 2,040 +/- 0.008
90 à 229590 à 2295 +/- 90 à 229,5 +/- 0.90 à 22,95 +/- 0.090 à 2,295 +/- 0.009

[/td][/tr]
[/table]
une fois l'octet reçu précédé de son code d'affectation, je sais donc quel facteur lui est associé et où je dois mettre la virgule pour que l'affichage me donne la valeur finale. tout cela passe par une fonction
Code: [Select]

void affiche_valeur_4_digits(byte octet, byte facteur, byte virgule, byte x, byte y){  // affiche un nombre compris entre 0 et 9999 avec ou sans virgule sur 4 digits
  word afficher = octet * facteur;
  for (byte i = 4; i > 0; i--){
    // extraction du digit i dans la variable "afficher"
    dessine_digit(digit, x + 4 - i, y);
    if ((i == virgule + 1) && (virgule > 0)) dessine_la_virgule_ici();
  }
}

rien de plus simple en fait... Bon, la fonction ci-dessus est beaucoup plus hard en vrai, mais le principe est là.

On peut également continuer avec un facteur jusqu'à 256, ainsi, on couvre toutes les gammes de valeurs que l'on veut avec pas mal de précision, et tout ça en n'envoyant seulement un octet... Plus précis encore si on prend en compte un offset (la valeur mini en dessous de laquelle on ne tombera jamais)...




facteurrangepasv=0v=1v=2v=3
390 à 10200390 à 10200 +/- 390 à 1020.0 +/- 3.90 à 102.00 +/- 0.390 à 10,200 +/- 0.039


Ca, c'est pour l'affichage du texte. Côté aiguille qui bouge, j'ai utilisé Excel pour calculer des tableaux de coordonnées relatives, afin de ne pas avoir à calculer les coordonnées du bout de l'aiguille. J'ai trouvé qu'avec un rayon de 40 pixels, on obtient 64 coordonnées consécutives qui ne se chevauchent pas (64 points distincts) faisant un arc de cercle de 90° pile. Ainsi, l'octet reçu de 256 valeurs, soit je le divise par 4 et ça me donne 64 angles sur 90° (soit mes 64 coordonnées), soit je le laisse telquel, et ça me fait un joli tour complet autour du centre. En plus, les sinus et cosinus se croisent, donc mes 64 coordonnées peuvent être réduites à deux tableaux de 32 octets. En regardant dans quel 1/8 du cercle va se trouver l'aiguille, on choisit l'un ou l'autre des deux tableaux pour ajouter la valeur à X1 ou y1 (centre de l'aiguille) et ainsi trouver l'autre bout de l'aiguille. Avantage, pour plusieurs aiguilles, c'est le même tableau qui sert...

Exemple pour l'aiguille de vitesse, qui doit tourner sur 324°pour 0 à 180km/h sur un rayon de 50 pixels : deux tableaux de 26 ordonnées me permettent de calculer mon aiguille :

Code: [Select]

volatile byte a0_x[26]={50, 50, 50, 50, 50, 49, 49, 49, 48, 48, 48, 47, 46 ,46, 45, 45, 44, 43, 42, 41, 40, 40, 39, 38, 36, 35};
volatile byte a0_y[26]={ 0,  2,  3,  5,  6,  8,  9, 11, 12, 14, 15, 17, 18, 20, 21, 23, 24, 25, 27, 28, 29, 31, 32, 33, 34, 35};

// (x0, y0) est le centre de l'aiguille.
//


void vitesse_affiche(){
  byte v_index;

if(vitesse != vitesse_old){                // ne change l'affichage que si besoin
  v_index = (vitesse + 10) % 25;         // calcule le modulo pour indexation des tableaux de coordonnées relatives
  lcd_line(x0, y0, x00, y00, UNPUT);            // effacer l'ancienne aiguille
  lcd_line(x0 - 4, y0 - 4, x00, y00, UNPUT);
  lcd_line(x0 + 4, y0 + 4, x00, y00, UNPUT);
  lcd_line(x0 - 4, y0 + 4, x00, y00, UNPUT);
  lcd_line(x0 + 4, y0 - 4, x00, y00, UNPUT);
  if (vitesse < 15) {                                //  cherche dans quel 8ième de cercle se trouve la nouvelle aiguille
    x00 = x0 - a0_y[v_index];                    // calcule le bout externe de l'aiguille
    y00 = y0 + a0_x[v_index];
  } else if (vitesse < 40) {
    x00 = x0 - a0_x[25-v_index];
    y00 = y0 + a0_y[25-v_index];
  } else if (vitesse < 65) {
    x00 = x0 - a0_x[v_index];
    y00 = y0 - a0_y[v_index];
  } else if (vitesse < 90) {
    x00 = x0 - a0_y[25-v_index];
    y00 = y0 - a0_x[25-v_index];
  } else if (vitesse < 115) {
    x00 = x0 + a0_y[v_index];
    y00 = y0 - a0_x[v_index];
  } else if (vitesse < 140) {
    x00 = x0 + a0_x[25-v_index];
    y00 = y0 - a0_y[25-v_index];
  } else if (vitesse < 165) {
    x00 = x0 + a0_x[v_index];
    y00 = y0 + a0_y[v_index];
  } else if (vitesse < 190) {
    x00 = x0 + a0_y[25-v_index];
    y00 = y0 + a0_x[25-v_index];
  } else {
    x00 = x0 - a0_y[v_index];
    y00 = y0 + a0_x[v_index];
  }
  lcd_line(x0 - 4, y0 - 4, x00, y00, PUT);  // dessin de l'aiguille en 5 segments
  lcd_line(x0 + 4, y0 + 4, x00, y00, PUT);
  lcd_line(x0 - 4, y0 + 4, x00, y00, PUT);
  lcd_line(x0 + 4, y0 - 4, x00, y00, PUT);
  lcd_line(x0, y0, x00, y00, PUT);
  lcd_set_graph_xy(x0t, y0t);
  lcd_byte_perso(1, 3, vitesse, 0);  // affichage valeur numérique police 1, taille 3
  vitesse_old = vitesse;
}



Le code ci-dessus marche super, je n'ai pas encore testé les aiguilles à rayon de 40px, mais il me tarde de le faire!
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Aug 20, 2012, 04:53 pm

Exemple pour l'aiguille de vitesse, qui doit tourner sur 324°pour 0 à 180km/h ...

Je vois qu'il n'y'a pas que le tableau de bord qui est "tuné" dans cette voiture XD

Quote
Le code ci-dessus marche super, je n'ai pas encore testé les aiguilles à rayon de 40px, mais il me tarde de le faire!


Je vois que tu efface la ligne précédente avant de tracer la nouvelle.
Tu n'as pas de possibilité de travailler en double buffer ?

Code: [Select]
volatile byte a0_x[26]={50, 50, 50, 50, 50, 49, 49, 49, 48, 48, 48, 47, 46 ,46, 45, 45, 44, 43, 42, 41, 40, 40, 39, 38, 36, 35};
volatile byte a0_y[26]={ 0,  2,  3,  5,  6,  8,  9, 11, 12, 14, 15, 17, 18, 20, 21, 23, 24, 25, 27, 28, 29, 31, 32, 33, 34, 35};
...
v_index = (vitesse + 10) % 25;


2 remarques ici. Tu t'en rendras certainement compte tout seul mais comme les vacances sont terminées, je suis vénère d'être rentré alors j'ai envie de faire ch... tout le monde pour des trucs totalement puérils  ]:D (comme sur l'autoroute où je roule a 120 sur la voie de gauche quand y'a des grosses BMW derrière moi :smiley-mr-green:)
- volatile est un mauvais choix ici. volatile s'utilise pour des variables qui peuvent être modifiées en dehors du court normal du programme, par exemple une variable globale utilisée entre une routine d'interruption et le corps du programme, pour éviter que le compilateur optimise l'accès en ne lisant qu'une fois la variable. Dans ton cas, les valeurs sont figées et donc c'est plutôt le mot clefs "const" que tu devrais utiliser.
- l'index étant calculé %25, les valeurs possible sont de 0 à 24. Donc la taille du tableau devrait être a0_xy[25] (index de 0 à 24) au lieu de a0_xy[26] (index de 0 à 25) puis que l'index [25] ne sera jamais utilisé.

Tu peux aussi éviter le %25 qui implique une division entière ce qui coûte pas mal d'instructions (essaye de mesurer son exécution)
Puisque tu fais déjà une série de tests par rapport à 15, 40, .... dans chaque test tu peux calculer index comme une simple addition ou soustraction.

Code: [Select]
  lcd_line(x0 - 4, y0 - 4, x00, y00, PUT);  // dessin de l'aiguille en 5 segments
  lcd_line(x0 + 4, y0 + 4, x00, y00, PUT);
  lcd_line(x0 - 4, y0 + 4, x00, y00, PUT);
  lcd_line(x0 + 4, y0 - 4, x00, y00, PUT);
  lcd_line(x0, y0, x00, y00, PUT);


Les tracés multiples décalés de +/- 4 pixels c'est pour faire plus épais ?


A quand la vidéo ?
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 20, 2012, 06:08 pm
J'aime bien barbudor, car il soulève souvent des questions rigolotes ou utiles.



Exemple pour l'aiguille de vitesse, qui doit tourner sur 324°pour 0 à 180km/h ...

Je vois qu'il n'y'a pas que le tableau de bord qui est "tuné" dans cette voiture XD

Alors pas du tout, j'ai repris le format du compteur d'origine, en calculant l'angle de l'aiguille sur 40 et 90km/h. J'ai pris l'habitude d'avoir l'aiguille à la verticale pour 90Km/h... le compteur d'origine est marqué jusqu'à 180, ce n'est pas pour rien, car j'ai déjà emmené l'aiguille jusque là (sur circuit, hein, parce que sur route, c'est pas vraiment autorisé :smiley-mr-green: ). On prend vite des habitudes et repères visuels, donc je garde le 90 à la verticale et le 0 à 20° en bas...

Quote
Le code ci-dessus marche super, je n'ai pas encore testé les aiguilles à rayon de 40px, mais il me tarde de le faire!

Je vois que tu efface la ligne précédente avant de tracer la nouvelle.
Tu n'as pas de possibilité de travailler en double buffer ?
Qu'entends tu par là? je vois pas trop de quoi tu parles... je me suis posé la question d'utiliser les 22 pages graphiques dispo dans le LCD lui-même, mais il faut de toute façon effacer les vieilles lignes un jour où l'autre...

- volatile est un mauvais choix (...). Dans ton cas, les valeurs sont figées et donc c'est plutôt le mot clefs "const" que tu devrais utiliser.
Je n'ai pas osé définir un tableau de constantes, ne sachant pas comment le compilateur allait réagir. Si tu me dis que c'est mieux, alors je vais y penser. Le code actuel fait 6500 octets sur les 14300 dispos, donc si les tableaux de constantes vont dans la flash, ça m'intéresse! (il y a aussi les tables de caractères en const...) Je crois que les simples variables déclarées en const sont traduites à la compilation, non?

- l'index étant calculé %25, les valeurs possible sont de 0 à 24. Donc la taille du tableau devrait être a0_xy[25] (index de 0 à 24) au lieu de a0_xy[26] (index de 0 à 25) puis que l'index [25] ne sera jamais utilisé.
Oui, et c'est une erreur de ma part. il faut que je recalcule ma série de coordonnées pour tomber sur pile 25 points. Mais de visu sur un sweep, l'aiguille ne semble pas sauter de point. je peux me contenter de virer les index N°25 pour gagner deux octets... :D

Tu peux aussi éviter le %25 qui implique une division entière ce qui coûte pas mal d'instructions (essaye de mesurer son exécution)
Puisque tu fais déjà une série de tests par rapport à 15, 40, .... dans chaque test tu peux calculer index comme une simple addition ou soustraction.
ça, c'est pas con, merci!

Code: [Select]
  lcd_line(x0 - 4, y0 - 4, x00, y00, PUT);  // dessin de l'aiguille en 5 segments

Les tracés multiples décalés de +/- 4 pixels c'est pour faire plus épais ?

Oui, je n'ai pas trouvé comment dessiner une aiguille pleine qui tourne sans perdre de temps. Ca donne un rendu rigolo, on a l'impression que l'aiguille est en 3D et qu'elle tourne sur elle-même... (à défaut...) Pour les petites aiguilles (de 40px), j'ai mis +/-4 aussi, mais je vais descendre à +/-3 voire +/-2, mais ce n'est aussi qu'un détail.

A quand la vidéo?
Malheureusement, je n'ai plus de quoi filmer, et mon apn me sort des .MOV à 5Mo/s, et je n'arrive pas à les réencoder en avi ou mpeg (saloperie de format propriétaire tiens!) Mais dès que je peux, je m'y mets!

une photo en attendant?

(http://pop.studio.free.fr/imgtmp/120820_0.jpg)
les valeurs collées pour la photo : vitesse = 124, jauge haut (carburant 36.4L) = 173 et jauge bas (température eau 89.5°) = 179. les valeurs des petites jauges sont affichées au dessus ou en dessous de l'aiguille selon sa position, on voit même que je n'efface pas la virgule quand le texte passe de l'autre côté, mais ce n'est qu'un détail...

il y a un faux contact dans le potar de contraste (qui fait 2mm de diamètre...), faudra que je le change.

Côté animation, j'ai mis dans le loop() un sweep genre :
Code: [Select]

for (vitesse = 0; vitesse <= 180; vitesse--){
  vitesse_affiche();
  galva_value[0] = vitesse;
  galva_affiche(0);
  galva_value[1] = vitesse;
  galva_affiche(1);
  delay(125);
}
C'est vraiment fluide, et on n'est pas loin des 8 changements par seconde, donc mes codes doivent être assez rapide (je mesurerai à l'oscillo pour avoir une idée précise!)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: SesechXP on Aug 20, 2012, 06:29 pm
La Renault 11 la plus moderne qui soit :smiley-mr-green:


Je n'ai pas osé définir un tableau de constantes, ne sachant pas comment le compilateur allait réagir. Si tu me dis que c'est mieux, alors je vais y penser. Le code actuel fait 6500 octets sur les 14300 dispos, donc si les tableaux de constantes vont dans la flash, ça m'intéresse! (il y a aussi les tables de caractères en const...) Je crois que les simples variables déclarées en const sont traduites à la compilation, non?


Sur AVR avec avr-gcc le mot clé const n'entraîne pas le stockage des variables en flash. ça indique juste que tes valeurs sont constantes, en quelque sorte en lecture seule. Par contre il est effectivement possible de stocker les constantes en flash avec la directive PROGMEM : http://www.nongnu.org/avr-libc/user-manual/pgmspace.html

++
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 20, 2012, 06:47 pm

La Renault 11 la plus moderne qui soit :smiley-mr-green:
Je ne fais que réinventer ce qui existe déjà : http://aebergon.perso.neuf.fr/Renault/page_Renault_11_Electronic_85.htm (http://aebergon.perso.neuf.fr/Renault/page_Renault_11_Electronic_85.htm) La Ronze-tronic, pour info, elle coûtait l'équivalent de 10 000€, aujourd'hui, la moindre voiture en haut de série, c'est 25 à 30000. Je doute qu'en 30 ans, l'inflation ait pris 150%... Mais ces vieilles caisses qui roulent encore (comme la mienne qui n'a "que" 25 ans) montrent qu'elles sont bien plus endurantes que celles d'aujourd'hui et ne coûtent rien en entretien si on sait un peu bricoler.

Il faut que je regarde comment ça marche, le progmem, mais j'ai peur que ça ralentisse beaucoup le code...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Aug 20, 2012, 06:59 pm

J'aime bien barbudor, car il soulève souvent des questions rigolotes ou utiles.

(http://storage.canalblog.com/32/55/171077/6185781.gif)

Quote
Quote

Quote
Le code ci-dessus marche super, je n'ai pas encore testé les aiguilles à rayon de 40px, mais il me tarde de le faire!

Je vois que tu efface la ligne précédente avant de tracer la nouvelle.
Tu n'as pas de possibilité de travailler en double buffer ?
Qu'entends tu par là? je vois pas trop de quoi tu parles... je me suis posé la question d'utiliser les 22 pages graphiques dispo dans le LCD lui-même, mais il faut de toute façon effacer les vieilles lignes un jour où l'autre...

C'est exactement ca le principe.
En double (ou triple) buffer, on dessine dans une page mémoire qui n'est pas affichée puis on commute l'affichage brusquement sur la nouvelle page.
L'avantage c'est que tu ne vois pas le dessin se faire progressivement. Si par exemple dessiner tout ton panneau prend 300 ms, en simple buffer, l'utilisateur va voir le contenu se construire petit a petit ce qui ne donne pas forcément un super rendu dynamique.

Comme tu le notes, il y toujours le problème d'effacement. Mais dans beaucoup de cas, les systèmes d'affichages a plusieurs pages permettent souvent de faire des copies internes rapides entre des pages. Si cette fonction existe, tu peux avoir une des pages qui est dessinée qu'une seul fois au démarrage et qui contient le fond (par exemple, une bitmap dessinée sur PC et stockée sur une carte SD.
Au moment de faire un nouveau dessin, tu demande a l'écran de copier de manière interne l'image du fond sur une page libre non affichée, tu dessines par dessus tes nouveaux éléments, puis tu commutes instantanément l'affichage.

Je ne connais pas ton afficheur donc je ne sais pas si cette méthode est utilisable.

Quote
Je n'ai pas osé définir un tableau de constantes, ne sachant pas comment le compilateur allait réagir. Si tu me dis que c'est mieux, alors je vais y penser. Le code actuel fait 6500 octets sur les 14300 dispos, donc si les tableaux de constantes vont dans la flash, ça m'intéresse! (il y a aussi les tables de caractères en const...) Je crois que les simples variables déclarées en const sont traduites à la compilation, non?

Comme répondu par SesechXP, utiliser const ne va pas placer les données en Flash mais volatile empêche certaines optimisations.
Je ne dis pas que ca va transcender la vitesse de ton code mais c'est déjà mieux.
Pour placer les données en Flash, voir : http://arduino.cc/en/Reference/PROGMEM puis poser plus de questions si nécessaire.
Note que cela va gagner un peu de RAM mais perdre du temps car la lecture d'une table en flash ne se fait pas de manière transparente.

Quote
C'est vraiment fluide, et on n'est pas loin des 8 changements par seconde, donc mes codes doivent être assez rapide (je mesurerai à l'oscillo pour avoir une idée précise!)


Good!
Title: Re: [Projet] Un tableau de bord numérisé
Post by: skywodd on Aug 20, 2012, 07:02 pm

La Renault 11 la plus moderne qui soit :smiley-mr-green:


Je n'ai pas osé définir un tableau de constantes, ne sachant pas comment le compilateur allait réagir. Si tu me dis que c'est mieux, alors je vais y penser. Le code actuel fait 6500 octets sur les 14300 dispos, donc si les tableaux de constantes vont dans la flash, ça m'intéresse! (il y a aussi les tables de caractères en const...) Je crois que les simples variables déclarées en const sont traduites à la compilation, non?


Sur AVR avec avr-gcc le mot clé const n'entraîne pas le stockage des variables en flash. ça indique juste que tes valeurs sont constantes, en quelque sorte en lecture seule. Par contre il est effectivement possible de stocker les constantes en flash avec la directive PROGMEM : http://www.nongnu.org/avr-libc/user-manual/pgmspace.html

Dans les dernières version (nightly) de avr-gcc le fait de mettre une variables en const la stocke en flash.
Mais dans les version stable et/ou obsoléte qui sont fourni avec l'installateur arduino il faut utiliser PROGMEM pour déplacer une variable en flash.

"volatile" force le compilateur à ne pas optimiser la variable, c'est utile (et même obligatoire) dans le cas d'une variable globale partageait entre une fonction standard et une interruption.
"static" sur une variable globale informe le compilateur qu'il peut optimiser l'accès à cette variable en la rendant accesible uniquement dans le fichier .c/.cpp en cours.
"static" sur une variable locale la rend persistante (elle garde sa valeur au prochain appel de la fonction)
"static" sur une fonction la rend optimisable par le compilateur, en la rendant accessible uniquement dans le fichier .c/.cpp en cours.
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 20, 2012, 07:29 pm
En vrac :

PROGMEM : oui pour la place, non pour la rapidité. il faut savoir que mes tableaux sont appelés 9 à 14 fois pour l'affichage d'un seul caractère perso, et une dizaine de fois dans chaque dessin d'aiguille. J'ai peur que leurs lectures en flash ralentisse vraiment mon code. J'optimise au max ma ram, en comptant les gros tableaux à la louche et voir où j'en suis. Comme il n'y a pas d'interruptions (et pas besoin, le code doit juste attendre des données série et les afficher au fur et à mesure), je pense que peut-être un static suffira à la place de volatile? mes tableaux sont déclarés dans les variables globales, donc accessibles à toutes mes fonctions.

Rapidité d'affichage? Dans le setup(), je commence par récupérer la config en EEPROM, puis initialise le LCD, allumer le back-light (PWM hard), et ensuite initialise et dessine l'interface (calcul des positions en fonction du seul point de repère de chaque contrôle, plus facile pour la mise en page), avec toutes les aiguilles à 0 (cercle, lignes, textes graphiques...). Au reset, lorsque ça démarre, au bout d'une seconde, je vois le back-light s'allumer d'un coup, et ça fait comme si mon interface graphique était déjà dessinée, absolument aucun temps mort visible ni scintillement (dois-je en déduire que ça prend moins de 40ms (1/24 sec.)? Le mouvement des aiguilles est super propre, comparé à des programmes que je faisais sous TP7 en 1995...

Pour résumer, il faut que l'affichage réponde tout de suite à l'arrivée d'une nouvelle donnée, le MEGA "maître" enverra des données environ toutes les 200 à 250ms.

Côté 168, bien sûr, je teste mes variables (un if sur un byte ne coûte rien) pour savoir si ça vaut le coup de changer quelque chose (genre si l'aiguille ne doit pas bouger, alors je la laisse tranquille et gagne un peu de temps au passage, pareil si la valeur n'a pas changé, on ne touche à rien). Exemple des aiguilles de 40px : un déplacement de l'aiguille d'un cran représente 4 dans l'octet de valeur, donc il se peut que la valeur numérique affichée bouge, mais pas l'aiguille. Ca prend deux if mais on gagne 6 lignes dessinées sur le LCD.

Il faudra aussi que je prévois ça dans le MEGA : ne pas envoyer une donnée si elle n'a pas changé.

Mais ce n'est pas parce que chaque morceau marche dans son coin que tout marchera une fois dans la boîte...

En tout cas, merci pour vos infos!
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Aug 20, 2012, 08:32 pm

...Tu t'en rendras certainement compte tout seul mais comme les vacances sont terminées, je suis vénère d'être rentré alors j'ai envie de faire ch... tout le monde pour des trucs totalement puérils  ]:D (comme sur l'autoroute où je roule a 120 sur la voie de gauche quand y'a des grosses BMW derrière moi :smiley-mr-green:)

:smiley-mr-green:
ça c'est de la grosse "enervittude"  8)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Aug 20, 2012, 08:51 pm

ça c'est de la grosse "enervittude"  8)

Pourquoi, t'as une grosse BM ?
T'as qu'as avoir une R11-kitté comme Souper Cinque et je te laisse passer  :smiley-yell:
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Aug 20, 2012, 09:53 pm
Aie

Il faudrait donc pouvoir mettre çà devant le tableau de bord original sans le modifier de manière à pouvoir l'enlever en cas de contrôle.
Y a t'il une loi qui interdit de cacher son tableau de bord ?
Title: Re: [Projet] Un tableau de bord numérisé
Post by: CocoVFR on Aug 20, 2012, 10:11 pm
Explicitement, non, mais il est stipuler que le compteur de vitesse et kilométrique sont les deux seul indicateurs obligatoire sur le tableau de bord.
Tu as le droit de tout virer, sauf ces deux truc la.
J'ai pris une prune alors que toute la planche de bord était démonter: la voiture sortait de peinture, et j'avais pas encore remonter une partie du tableau de bord.
Résultat, immobilisation du véhicule: rétention de la carte grise, délivrance d'un certification de circulation provisoire et 48h pour présenter la voiture en état....
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 20, 2012, 10:51 pm
Ouh làààààààaaa... (ouh la la la, pique la baleine, joli baleinier... tra la la comme le disait une vieille chanson de marin)...

Vous avez tous les deux raison, l'indicateur de vitesse et totaliseur kilométrique sont obligatoires, mais la qualité reste floue. En s'appuyant sur les droits de l'homme, article 11, alinéa 1 (texte pas très apprécié des schtroumfs, je reconnais), il faudra prouver que mon appareillage ne répond pas aux normes (précision à +/-10%).

Pour le CT, je m'étais déjà renseigné, il suffit d'avoir un indicateur et totaliseur, mais ils ne vérifient pas le fonctionnement (mon régulateur actuel est passé au CT il y a un an). Pour le côté brigade bleue, il faut tomber sur un débutant, et encore, si mon compteur ne marche pas bien, les radars automatiques me le feront savoir...

N'oublions pas que grâce au net, on peut modifier le kilométrage d'un véhicule moderne avec un simple port RS232.

Bon, je vais retourner à ma bidouille, soyez sage!
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 20, 2012, 11:31 pm

sur se je tenez quand même a préciser que c'est du super taff je voulez faire pareil mai avec un ordi portable desocer est inclus dans la console centrale (directement relier a mon ecu) pour lancer mais log retoucher la carto est afficher le knock,EGT,AFR,temp eau,huile,pression ect ect... mais bon j'en suis pas encore ici pour l'instant c'est perf ^^
outch... c'est un peu dur à lire là... :~ je veux bien faire des efforts pour traduire, mais je ne voudrais pas être le seul si tu vois ce que je veux dire...

A part ça, ton ecu, il faudra le remplacer. j'ai causé avec un gars qui s'est amusé à remplacer l'AEI d'une super5 GTT (le modèle 1.4 turbo, celui-là à 115chx pour pousser 700Kg, je fais pas le poids). C'est exactement le même boîtier que sur ma R11 (même moteur aussi, mais j'ai pas de turbo...). Il a utilisé un pic à 8MHz... mais là, il n'y a pas beaucoup de données à traiter : le signal PMH, la pression / dépression, cliquetis et c'est tout, puis juste pondre une impulsion de durée constante mais bien calée à chaque demi-tour pour l'allumage
(site : neo-tech).

Nos vieux AEI des années 80 n'ont que 6 fils pour faire tourner le moteur, mais l'ECU moderne gère même jusqu'aux clignotants et essuie-glace, une cinquantaine de fils... l'arduino ne suivra pas, là... on est dans les 32bits/400MHz pour ce genre de joujou.

Je reviens à mon "indicateur de vitesse", j'ai revu la procédure, car je m'étais planté : le compteur avec le 40kmh à l'horisontale, il venait d'une super5 ph2... en fait, ça tombe plutôt bien, sur la R11, c'est le 30kmh qui est à l'horizontale, donc le 0 est à 45°, et j'ai trouvé qu'en multipliant 256 par 94 puis en n'affichant pas les deux derniers chiffres, ça me donne 240 (256 x 94 = 24064), soit un tour complet de l'aiguille, et si j'envoie 96, il affichera 90 en numérique, et que le 96 correspond à la verticale... (vous suivez?)

Bref, mon tour complet étant divisé en 8 portions, ça me donne 32 coordonnées relatives, tout propre. Reste à revoir le rayon aussi, car j'aimerais bien avoir de la place pour mettre des repères (0, 10, 30, 50, 70, 90, 110, 130... allez savoir pourquoi, dans les années 80, ils mettaient les repères chiffrés à 20, 40, 60, 80, 100, 120, 140... aujourd'hui, on n'a aucune limitation de vitesse à ces valeurs là). Peut-être pour une histoire de place, car en notant le 30, le 90 et le 150, on était aux horizontales et aux verticales, et que ça prenait plus de place?
Title: Re: [Projet] Un tableau de bord numérisé
Post by: neodelavega on Aug 20, 2012, 11:44 pm
Quote

A part ça, ton ecu, il faudra le remplacer


j'ai oublier de préciser c'est une gestion programmable (AEM series 2)
tu peut loger tout les info moteur puis les relire plus tard voir comment se comporte le moteur a x rpm et a x charge
et tu peux aussi voir toute les sonde ect...

bon ok petite traduction ^^

knock = capteur cliquetis
EGT = exhaust gas temperature = temp echapement
AFR, air fuel ratio = mélange air essence

tu peux faire de l'acquisition en direct par port USB 2.0 d'où l'idée d'inclure un ordi portable ou tablette tactile pour virer toute la guirlande de mano et passer tout en électronique relier a l'ecu en plus de sa je pourrer lancer des log sur les sonde qui autre fois était mecanique
Title: Re: [Projet] Un tableau de bord numérisé
Post by: jfs on Aug 21, 2012, 03:25 pm
La discussion sur la légalité ou non du projet se trouve ici :

http://arduino.cc/forum/index.php/topic,119485.new.html#new

Cet aspect se traitera désormais sur ce nouveau post.

Merci.
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 21, 2012, 05:35 pm
Merci pour le ménage, JF. Si on commence à parler de ce qu'on a envie de faire, ce qu'on a le droit de faire et ce qui est interdit, on ne s'en sortira jamais.

J'ai continué à jouer avec mon interface graphique, et j'ai découvert un truc pas mal sur le LCD : je savais que pour un même écran, on a une page graphique (avec des pixels) et une page texte (avec des caractères comme un LCD alphanum classique), et qu'on peut choisir d'en afficher une des deux, ou les deux en même temps ou aucune. Il y a une fonction qui permet de faire une opération logique entre les pixels de rendu des deux pages : OR, EXOR et AND. le OR est par défaut, les deux pages sont superposées. pour le AND, ben je vois pas trop l'interrêt (n'affiche des pixels que s'il y en a un sur les deux pages au même endroit)... Mais le EXOR est très intéressant. Ainsi, je mets les chiffres de l'indicateur de vitesse en page texte, et l'aiguille en graphique. Quand l'aiguille passe sur le texte, les pixels s'inversent au lieu de se recouvrir bêtement, ça rend la chose plus lisible. de même, pour surligner du texte, il suffit de remplir un rectangle là où il y a du texte, et pouf, le texte devient en inverse dans le rectangle... C'est surtout qu'on n'est pas obligé de réfléchir, les dessins graphiques n'effacent pas le texte (si l'aiguille est sur un nombre, et que j'efface l'aiguille, le nombre reste)

Mauvais point, c'est que le texte pur se pose sur une grille fixe de 20 x 16 caractères, donc c'est au graphique de se positionner par rapport au texte.

J'ai rajouté deux ou trois petits trucs, ça commence à ressembler à quelque chose (rien que les graduations autour de l'aiguille de vitesse, ça remplit tout de suite!) :

(http://pop.studio.free.fr/imgtmp/120821_0.jpg)

la transition entre 114 et 113 :

(http://pop.studio.free.fr/imgtmp/120821_1.jpg)

(toujours pas de vidéo...)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: jfs on Aug 21, 2012, 05:42 pm
J'veux le m'ême pour mon vélo  XD
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Aug 21, 2012, 06:40 pm


J'ai continué à jouer avec mon interface graphique,

sympa comme affichage.
perso je mettrais un petit cercle (ou quart) plein centré à l'origine des aiguilles, mais je ne me rend pas compte si c'est simple
à faire et si ça consomme beaucoup de ressources.
genre ça
(http://cjoint.com/12au/BHvsNYjMElx_120821_m1.jpg)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: unisev on Aug 21, 2012, 07:28 pm
OUaou !!

Chapeau "Super-Sinche", ton sujet a bien vécu, et visuellement tu as déjà un rendu sympa !

Au niveau luminosité tes écrans-TabloD'Bbor c'est suffisant ?

UniseV
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 21, 2012, 08:32 pm

sympa comme affichage.
perso je mettrais un petit cercle (ou quart) plein centré à l'origine des aiguilles, mais je ne me rend pas compte si c'est simple
à faire et si ça consomme beaucoup de ressources.
genre ça
Bien sûr, puisqu'à l'origine, il y a le rond. Maintenant, côté "ressources", c'est pas évident. Pour déplacer l'aiguille, j'efface l'ancienne et dessine la nouvelle, ça effacera une partie de mon rond. dessiner un cercle demande de faire pas mal de tests sur des int (donc 16 bits...), et un rond plein, c'est plusieurs cercles de diamètres différents, et l'algo que j'ai ferait des trous (un problème connu de l'algo de "behsman" ou un truc comme ça). Il y a l'autre solution d'utiliser une fonction assez simple qui permet d'imposer une ligne de 8 pixels via un seul octet, donc tout comme dessiner un caractère, ça pourrait passer si je tombe bien dans la grille des 8 pixels... Je teste ça.

@UniseV : je risque d'avoir des problèmes de reflets, c'est du verre de base...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Aug 21, 2012, 08:59 pm
Pour le petit rond, peut être peut tu coller un O majuscule ou une paire de () ou de <> sur la page texte à l'endroit qui va bien ?
Title: Re: [Projet] Un tableau de bord numérisé
Post by: jfs on Aug 21, 2012, 09:00 pm
Algo de Bresenham (http://fr.wikipedia.org/wiki/Algorithme_de_trac%C3%A9_de_segment_de_Bresenham)   XD
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Aug 21, 2012, 09:19 pm

Pour le petit rond, peut être peut tu coller un O majuscule ou une paire de () ou de <> sur la page texte à l'endroit qui va bien ?

Bonsoir Barbudor
sinon t'en qu'a coller et avec  zero code pour gérer  la rémanence , il y aurait bien ça !  :smiley-mr-green:
http://www.10doigts.fr/gommettes-stickers/gommettes-geometriques-cp145.aspx

---->[]  :smiley-red:

Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 21, 2012, 10:37 pm

Pour le petit rond, peut être peut tu coller un O majuscule ou une paire de () ou de <> sur la page texte à l'endroit qui va bien ?
Ouaip, je pourrais même définir un caractère perso dans la ram du LCD en forme de rond! le O majuscule, c'est pas beau et ça fait bricolage. mais le caractère perso, ça marche! (sauf que mon EXOR ferait des trous...)


Algo de Bresenham (http://fr.wikipedia.org/wiki/Algorithme_de_trac%C3%A9_de_segment_de_Bresenham)   XD
Je parlais de celui-là : http://fr.wikipedia.org/wiki/Algorithme_de_trac%C3%A9_d%27arc_de_cercle_de_Bresenham (http://fr.wikipedia.org/wiki/Algorithme_de_trac%C3%A9_d%27arc_de_cercle_de_Bresenham) que j'ai du le lire pfiou... 3  ou 4 fois! ben pas réussi à le déchiffrer suffisamment pour en pondre un code... mais le code que j'ai piqué en 15 lignes est basé dessus et marche très bien! que des + ou des -, et hop, un cercle. dans l'article wiki, tout en bas, il y un très bel exemple de cercles imbriqués qui font des trous.



Pour le petit rond, peut être peut tu coller un O majuscule ou une paire de () ou de <> sur la page texte à l'endroit qui va bien ?

Bonsoir Barbudor
(...)
:smiley-mr-green:
http://www.10doigts.fr/gommettes-stickers/gommettes-geometriques-cp145.aspx
Oui, ben y'a pas la bonne couleur. Mais ça me rappelle les premiers jeux électroniques avec un mickey qui doit ramasser des oeus de poules, le décors était imprimé sur la vitre du LCD...

En attendant, avec une table de 3 octets, je colle un rond de 7 px de diamètre qui tombe pile-poil sur l'axe de l'aiguille (c'était pas prévu, ouf!) :

(http://pop.studio.free.fr/imgtmp/120821_2.jpg)

c'est ce que j'ai de mieux, mais je crois que je vais laisser le code de cette aiguille tranquille un peu, car je pense être à la limite du raisonnable niveau temps d'exécution...

Pour info, il manque encore la série de switch(Serial.read()){} pour récupérer les données série et les traiter. En gros, j'en suis à 8246 octets de flash sur 14336, et côté ram, il va falloir que je colle un petit memAvailable() en test au milieu du code...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: jfs on Aug 21, 2012, 11:55 pm
Et pourquoi comme indiqué sur ta page wiki ne pas utiliser cet algo qui fait des cercles sans trous ?  XD

http://fr.wikipedia.org/wiki/Algorithme_de_trac%C3%A9_de_cercle_d%27Andres

Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 22, 2012, 05:34 am

Et pourquoi comme indiqué sur ta page wiki ne pas utiliser cet algo qui fait des cercles sans trous ?  XD

http://fr.wikipedia.org/wiki/Algorithme_de_trac%C3%A9_de_cercle_d%27Andres
Pas mal, mais il semble que le périmètre est un peu "gras" aux alentours des angles de 45°... Mon pâté de 7x7px est quand même plus rapide, peut-être lui rajouter un seul cercle pour passer à 9 de diamètre?
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 22, 2012, 08:07 am
Bon, pour les aiguilles, je m'arrête là :

(http://pop.studio.free.fr/imgtmp/120822_0.jpg)
une petite erreur s'est glissée dans mon calcul des petites aiguilles, voir le point en bas à droite qui est en trop sur celle du haut... j'ai pas trouvé où.

Maintenant, il faut que je m'occupe des icônes, en 16x16 (32 octets) ou 24x24 (72 octets), je ne sais pas encore, je pense que je vais les coller directement dans l'EEPROM du 168, comme ça, je m'affranchis du bouffage de ram pour les tableaux d'icônes, et je pourrai les changer en utilisant l'USB du système final. ça me laisse une capacité 10 à 20 icônes (selon la taille) par écran, largement suffisant.

edit : Un premier jet d'icônes en deux tailles (16x16 et 24x24) :

(http://pop.studio.free.fr/imgtmp/120822_0.bmp)

Reste plus qu'à les coder...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Aug 22, 2012, 12:48 pm

Bon, pour les aiguilles, je m'arrête là :

C'est déjà un resultat pas mal et exploitable
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 22, 2012, 04:16 pm
Oui, et je commence à en être fier...

Bon, histoire de perdre du temps, j'ai codé quelques icônes en partant d'un bitmap (va falloir que je fasse un soft en VB qui me donne directement des tables, car c'est bien long...). Je trouvais plus joli en 24x24, donc je les ai faites en 24x24. Oui, sauf qu'en fait :

(http://pop.studio.free.fr/imgtmp/120822_1.jpg)

Ca prend de la place, et pas qu'en mémoire... donc super, je n'ai plus qu'à tout reprendre en 16x16, comme la dernière...

Je ne sais même pas si je vais garder les grandes sous la main, car il faudra de la mémoire, et d'ici là, j'aurai un petit soft qui me transforme un BMP en table d'octets...

EDIT : en 16x16, on va pouvoir en coller un peu plus...

(http://pop.studio.free.fr/imgtmp/120822_2.jpg)
Ces icônes serviront à décorer les petites aiguilles, et sûrement les pages de configuration (où là, je pourrais utiliser les grandes...)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 26, 2012, 03:36 pm
Après avoir passé deux jours à trier des poulets morts non vendables (donc direction usine à "knaki"), j'ai bien eu du mal à me replonger dans le code...

J'ai voulu encadrer les compteurs totaliseurs et journalier...

(http://pop.studio.free.fr/imgtmp/120826_0.jpg)

Pas très concluant. Mais l'idée est là, car pour qu'au passage de l'aiguille sur les zones "sensibles", il faut mettre les graphiques dans la page "text", car rappelons-le, pour un écran, j'ai un écran graphique et un écran texte qui s'affichent ensemble avec un XOR entre les deux... L'idée : le "fond" est en page texte, et ce qui bouge en page graphique.

Donc en attendant de jouer avec les 128 caractères personnalisables, je suis revenu à la base :

(http://pop.studio.free.fr/imgtmp/120826_1.jpg)

Dans l'idée, les icônes seront dans la page texte, et en 4 caractères, je pourrai afficher une icône de 16x16 : gain de temps énorme, et possibilité de faire clignoter une icône (je pense à l'essence... :D ).

Il me reste donc à coller en EEPROM ma table de caractères persos, j'ai déjà commencé à y travailler...

(http://pop.studio.free.fr/imgtmp/120826_2.jpg)

A suivre!
Title: Re: [Projet] Un tableau de bord numérisé
Post by: eti on Aug 27, 2012, 10:46 pm
super bravo j'adore!
Une question me vient à l'esprit en voyant ceci. Sur une voiture plus moderne (je pense à ma 206+), pensez-vous qu'il est possible de réaliser un régulateur de vitesse en se connectant sur le port diagnostique OBD?
Je sais qu'on peut avoir la vitesse, mais est-ce qu'on peut commander le régime moteur (accélerer ralentir à la place du servomoteur+câble)?
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 28, 2012, 08:29 am

super bravo j'adore!
Une question me vient à l'esprit en voyant ceci. Sur une voiture plus moderne (je pense à ma 206+), pensez-vous qu'il est possible de réaliser un régulateur de vitesse en se connectant sur le port diagnostique OBD?
Je sais qu'on peut avoir la vitesse, mais est-ce qu'on peut commander le régime moteur (accélerer ralentir à la place du servomoteur+câble)?
Salut et merci...

Je dis peut-être une co**erie, mais j'ai lu quelque part que les ODB actuels possèdent déjà un régulateur en interne (pour ceux qui ont une commande électromécanique de l'admission). Il suffirait de l'activer (mais là, c'est par la concession, et autant acheter une voiture où c'est déjà activé, vu le prix d'un petit clic de souris qui active le régulateur...). Je ne connais pas trop ces trucs modernes donc je ne peux pas t'en dire plus. J'ai voulu m'intéresser aux prises diag des ODB, mais ça avait l'air un peu compliqué et n'ayant qu'une vieille guimbarde sans ODB, je ne suis pas allé plus loin. Mais si on connait les codes de commande, alors il suffit de se connecter en série dessus et de tester...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 28, 2012, 11:33 am
Quelque modifs encore, dans la gestion des graphiques...

Voilà ce à quoi j'arrive :

(http://pop.studio.free.fr/imgtmp/120828_0.jpg)

Bon, l'encadrement des compteurs km est un peu ambitieux, je ne crois pas qu'il soit nécessaire d'afficher un kilométrage de 9 999 999 km, 6 chiffres suffiront. de même pour le journalier, 999,9km c'est déjà bien assez (là, il peut afficher jusqu'à 6 553,5km... quoique, sur un long trajet, ça peut être intéressant de pouvoir dépasser les 1 000 km).

Pour le fun et que tout le monde comprenne ma gestion graphique, j'ai envoyé un code au LCD pour lui dire de n'afficher que la page texte :

(http://pop.studio.free.fr/imgtmp/120828_1.jpg)

Puis que la page graphique :

(http://pop.studio.free.fr/imgtmp/120828_2.jpg)

le driver interne du LCD (le T6963C) fait un EXOR entre ces deux écrans pour afficher le résultat final.

Comme ça, on voit mieux le "fond" d'écran en mode texte et le "calque" graphique par dessus avec les aiguilles et gros caractères.
On voit également que pour le compteur journalier, la virgule est graphique pour ne pas utiliser la virgule texte qui prend un caractère à elle toute seule et c'est vraiment pas beau...
Je suis bien content d'avoir réussi à coller mes icônes en mode texte/caractères persos ainsi que l'encadrement des compteurs, ça me simplifie grandement la gestion graphique quand l'aiguille passe sur une icône : je n'ai plus rien à gérer!
Ce qui est dommage, c'est qu'il faut envoyer les tables de caractères persos à chaque mise en route du LCD, mais c'est quand même rapide. Ces tables sont collées dans l'EEPROM du "serial back-pack" et transférées dans l'espace mémoire "character Generator" du LCD à l'initialisation.

Il va être temps que je commence à tester les commandes par port série, et trouver des choses à afficher dans la bande du haut du LCD, j'ai trois lignes de 20 caractères ou une zone de 160 x 24 pixels. Je pense que j'y mettrai conso et autonomie à droite et les modes "régulateur" / "limiteur" à gauche. j'ai déjà prévu des icônes pour ça...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Aug 28, 2012, 12:02 pm


Il va être temps que je commence à tester les commandes par port série, et trouver des choses à afficher dans la bande du haut du LCD, j'ai trois lignes de 20 caractères ou une zone de 160 x 24 pixels. Je pense que j'y mettrai conso et autonomie à droite et les modes "régulateur" / "limiteur" à gauche. j'ai déjà prévu des icônes pour ça...

tu n'a pas un petit GPS ?
en dehors de la position il y a des infos derivées qui peuvent etre interessante en voiture
heure
vitesse
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 28, 2012, 12:19 pm

tu n'a pas un petit GPS ?
en dehors de la position il y a des infos derivées qui peuvent etre interessante en voiture
heure
vitesse
Bah... je compte essayer de faire tourner le timer2 du MEGA en RTC si j'arrive à souder directement un quartz de 32768 sur les pins du méga (car elles ne sont pas routées), et la vitesse, ben je la mesure "mécaniquement" sur la sortie de pont (là où se met le câble compteur).

Puis j'ai un second écran à programmer aussi (bien que je ferai un Ctrl-C/Ctrl-V du code du premier, il n'y à qu'à déplacer les aiguilles et faire d'autres jauges, zones de texte...)

Et surtout un banc de test à fabriquer, et le MEGA  à programmer aussi, Bref, c'est pas fini!
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Aug 28, 2012, 02:02 pm

Après avoir passé deux jours à trier des poulets morts non vendables (donc direction usine à "knaki"), j'ai


Tu les as massacrés à coup de R11 ?

Bon, ben sinon ca avance bien...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 28, 2012, 07:32 pm
Ouaip, ça avance. l'épisode poulet m'a permis de prendre du recul...

J'ai aussi utilisé le timer2 pour avoir une base clignotante à 1Hz pour faire clignoter jusqu'à 8 icônes, le rendu est d'un coup plus vivant (enfin en marche normale, aucune icône ne devrait clignoter, je ne verrai peut-être donc jamais mon joli code en fonction...)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 29, 2012, 12:01 am
Ben voilà, j'en ai trop mis...

(http://pop.studio.free.fr/imgtmp/120828_3.jpg)

en inversant la petite voiture et la conso, ça devrait le faire, et en mettant le temps restant un peu plus à droite... (il manque aussi une icône d'horloge)

quel boulet... je vais me coucher!
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Aug 31, 2012, 04:29 pm
Y'en a un qui l'a fait !!!

(http://www.journaldugeek.com/files/2012/08/do2.jpg)

A lire sur http://www.journaldugeek.com/2012/08/31/deloreane-a-vendre/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+LeJournalDuGeek+%28le+Journal+du+Geek%29

:smiley-mr-green: =>[]
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Sep 05, 2012, 10:58 am
La R11 phase 1 s'y prête mieux, car elle a des doubles optiques à l'avant, la mienne est une phase 2 et ne ressemblera jamais à une deloreane! :

(http://pop.studio.free.fr/imgtmp/090629a.jpg)

Les deux LCD sont maintenant fixés dans la boîte (c'était surtout pour qu'ils soient protégés le temps du développement, les verres se rayent trop facilement).

Bon, j'ai enfin branché le second LCD (qui dormait dans son sachet depuis plus d'un an), collé un bootloader dans son 168, fait un copier-coller du code du premier écran, quelques modifs rapides (principalement les x et y des "champs de valeurs"), le résultat est presque sans surprise...

(http://pop.studio.free.fr/imgtmp/120905_3.jpg)

(http://pop.studio.free.fr/imgtmp/120905_4.jpg)

(http://pop.studio.free.fr/imgtmp/120905_5.jpg)

(http://pop.studio.free.fr/imgtmp/120905_10.jpg)

Sur la photo, on voit le mega qui attend ses premières liaisons série avec les LCD (toute la réception / affichage est codé dans les LCD, mais je n'ai encore rien testé!).

pour le fun, quelques extraits de mon cahier de brouillon :

un peu de définissions, dessins d'icônes...
(http://pop.studio.free.fr/imgtmp/120905_6.jpg)

encore des icônes...
(http://pop.studio.free.fr/imgtmp/120905_7.jpg)

des tables de caractères...
(http://pop.studio.free.fr/imgtmp/120905_8.jpg)

le protocole série...
(http://pop.studio.free.fr/imgtmp/120905_9.jpg)

Je vous mets pas toutes les pages, il y en a pas loin de 60 bien noircies...

Il me tarde de faire mes premiers essais de contrôle des LCD avec le mega2560! Je pense utiliser ce petit boîtier maison comme clavier / écran pour choisir une fonction / code à envoyer au LCD, et un potar pour changer les valeurs :

(http://pop.studio.free.fr/imgtmp/120524_0.jpg)

Puis lundi, j'ai trouvé ceci dans une poubelle :

(http://pop.studio.free.fr/imgtmp/120905_2.jpg)

un pèse-monnaie et son imprimante thermique! le pèse-monnaie marche très bien, et pourrait me permettre d'avoir un capteur de poids super précis (ça pèse aussi les billets, et c'est capable de dire combien il y en a, et si dans le tas il y en a qui ne font pas le bon poids). Je ne vais pas tarder à l'ouvrir pour tenter de trouver la précision de la balance! Un joli LCD de 24 x 2, de quoi faire joujou!

Je me demande si je ne vais pas intégrer l'imprimante thermique dans la voiture... il faut encore que je trouve comment la commander, c'est un bête RX/TX, mais est-ce que c'est du simple ascii, ou du plus compliqué...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Sep 05, 2012, 02:02 pm

La R11 phase 1 s'y prête mieux, car elle a des doubles optiques à l'avant, la mienne est une phase 2 et ne ressemblera jamais à une deloreane! :

(http://pop.studio.free.fr/imgtmp/090629a.jpg)

Les deux LCD sont maintenant fixés dans la boîte (c'était surtout pour qu'ils soient protégés le temps du développement, les verres se rayent trop facilement).

Bon, j'ai enfin branché le second LCD (qui dormait dans son sachet depuis plus d'un an), collé un bootloader dans son 168, fait un copier-coller du code du premier écran, quelques modifs rapides (principalement les x et y des "champs de valeurs"), le résultat est presque sans surprise...


(http://pop.studio.free.fr/imgtmp/120905_10.jpg)

Sur la photo, on voit le mega qui attend ses premières liaisons série avec les LCD (toute la réception / affichage est codé dans les LCD, mais je n'ai encore rien testé!).

...

Puis lundi, j'ai trouvé ceci dans une poubelle :

(http://pop.studio.free.fr/imgtmp/120905_2.jpg)

un pèse-monnaie et son imprimante thermique! le pèse-monnaie marche très bien, et pourrait me permettre d'avoir un capteur de poids super précis (ça pèse aussi les billets, et c'est capable de dire combien il y en a, et si dans le tas il y en a qui ne font pas le bon poids). Je ne vais pas tarder à l'ouvrir pour tenter de trouver la précision de la balance! Un joli LCD de 24 x 2, de quoi faire joujou!

Je me demande si je ne vais pas intégrer l'imprimante thermique dans la voiture... il faut encore que je trouve comment la commander, c'est un bête RX/TX, mais est-ce que c'est du simple ascii, ou du plus compliqué...


Bonjour super-cinci
ça avance bien, mais selon l'adage "trop d'infos tue l'info"  tu ne crois pas que 2 LCD bien (sur)chargés ça fait beaucoup ?
La thermique dans la voiture c'est pour t'éditer le ticket de ce que tu doit payer en fin de parcours ?  :smiley-mr-green:
pas de ref sur l'imprimante ?
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Sep 05, 2012, 06:17 pm
Au démarrage, les LCD affichent pratiquement tout, comme les trucs à pas cher, mais il y a la moitié qui disparaît en marche normale...

Pour la thermique, il faut demander un PWD chez ABLE pour peut-être trouver de la doc... Puis je crois qu'elle sera connectée à un arduino, mais pas dans la voiture... il y a déjà assez de bazar comme ça...

J'ai fini de recâbler ma boîte "terminal" sur une DB25, les 25 broches sont utilisées : 5 inters, un potar, le clavier, 2 leds et le LCD. Avec ça, je devrais pouvoir faire ce que je veux pour envoyer des codes aux écrans... Si j'ai assez de place en broches, je pense garder ce boîtier comme "terminal" déporter pour le réglage quand on est sous le capot...

(http://pop.studio.free.fr/imgtmp/120905_11.jpg)

Je suis sûr que vous aimeriez savoir câbler comme moi :

(http://pop.studio.free.fr/imgtmp/120905_12.jpg)

(une fois fermé, on s'en tape!) :D
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Sep 11, 2012, 10:49 am
Salut à tous!

Alors comme j'aime bien que de temps en temps tout soit un minimum rangé, j'ai fixé mon "terminal maison" sur une planche, avec un mega2560, en laissant un peu de place pour une bread-board, histoire de pouvoir envoyer des données aux deux écrans.

(http://pop.studio.free.fr/imgtmp/120911_0.jpg)

Les deux départs (Serial1 et Serial2) vers les écrans sont en haut à gauche. L'espèce d'horloge sous le clavier est un potar multitour (10 tours) connecté à A0... J'ai crame le petit bleu (50cts), car il était en court-jus entre le +5 et 0, on ne peut pas tout réussir du premier coup...

(http://pop.studio.free.fr/imgtmp/120911_1.jpg)

J'ai deux champs sur la première ligne : numéro écran et numéro fonction, 4 champs "data" deuxième ligne. Un bouton fait défiler le curseur de champ en champ, "+" / "-" / "0"-"F" / potar pour modifier la valeur du champ, un bouton pour envoyer le code généré au bon lcd. Avec une fonction d'envoi continu en fonction du potar, ça devrait me permettre de jouer avec mes écrans un petit moment...

Dans la série boulet, le premier envoi vers un écran a bien marché, mais le second a merdé lamentablement... des caractères se sont mis à côté d'une icône clignotante... Ben oui, le timer balance ses INT à tout moment (~2Hz), et ça peut tomber en plein milieu d'une séquence d'écriture LCD, donc envoyer des codes foireux au LCD. Reprogrammation totale des deux back-packs en désactivant le timer pendant chaque écriture sur l'écran... Le clignotement sera peut-être moins fluide, mais il ne perturbera (plus?) l'affichage des données.

Mais le fait que l'écran réagisse à un envoi série montre que je ne suis pas loin du bout!

Reste donc maintenant à tester chaque fonction série. Une fois les écrans validés, je m'attaque à la programmation des comptages et autres réjouissances qui m'attendent...

A suivre...

A noter quand même cette histoire de contraste, car les mini-potars sont bien foireux, et j'ai la PIN OC2A du 168 qui ne sert à rien, il serait intéressant d'utiliser une PWM là-dessus à une fréquence de malade aec un bon passe-bas pour gérer le contraste. Quelqu'un a déjà essayé? il faut que je regarde quel genre de signal (si c'est une impédance ou un signal continu que le géné VSS attend) il faut envoyer sur la pin V0 du LCD, ça m'arrangerait bien, sinon, ça veut dire coller un potar extérieur, mais je crains le pire, ça va pas être joli...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Sep 12, 2012, 07:29 am
Salut
Oui tu peux utiliser un PWM avec un filtre pour le constraste. Pas besoin d'un fréquence de malade, le 470Hz de base avec un filtre lent suffit.
Certains lcd demande une tension négative pour le meilleur contraste. Tu peux aussi faire ca avec une pompe de charge sur le pwm (2 diodes, 2 capas)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Sep 12, 2012, 01:00 pm

Salut
Oui tu peux utiliser un PWM avec un filtre pour le constraste. Pas besoin d'un fréquence de malade, le 470Hz de base avec un filtre lent suffit.
Certains lcd demande une tension négative pour le meilleur contraste. Tu peux aussi faire ca avec une pompe de charge sur le pwm (2 diodes, 2 capas)
J'ai vu pas mal de sujets à ce sujet... en effet, selon le type de commande, soit une PWM + LPF, soit une pompe de charge comme tu le dis. Dans mon cas, le "V0" est connecté à un potar entre le VCC et GND. par précaution, je mesurerai la tension (c'est du sparkfun, ne l'oublions pas...) Comme je ne compte surtout pas utiliser analogWrite() pour ça, je testerai plusieurs fréquences, je n'airai d'ailleurs pas le choix, car j'utilise déjà ce timer (le 2) pour gérer le clignotement des icônes, et il tourne à 1:1024, soit une fréquence de 61 Hz... je vais voir si je peux quand même pas le remonter un peu... ou basculer le clignotement sur le timer0 (je n'utilise ni delay() ni millis()...). Je n'ai pas le choix pour le contraste : je ne peux utiliser que la pin OC2A, toutes les autres sont déjà prises.

Ce matin, j'ai fait quelques activités manuelles...

J'ai percé mes 12 emplacements pour les voyants 12V et collé un vinyl noir mat sur la façade :

(http://pop.studio.free.fr/imgtmp/120912_2.jpg)

(http://pop.studio.free.fr/imgtmp/120912_7.jpg)

Puis posé les chaches des voyants et les écrans :

(http://pop.studio.free.fr/imgtmp/120912_5.jpg)

(http://pop.studio.free.fr/imgtmp/120912_4.jpg)

Et voilà le final :

(http://pop.studio.free.fr/imgtmp/120912_6.jpg)

Bon, en réel, il n'y a pas autant de reflets (le défaut des APN : ils mettent toujours en valeur les reflets). De plus, dans la voiture, il y a une grande casquette au-dessus.

Je suis assez fier de moi, l'ensemble se présente plutôt bien, le noir mat légèrement granuleux apporte vraiment un fini sympa! Je comptais faire des découpes à la machine dedans, mais finalement non, ça restera comme ça!

Bon, maintenant, il ne me reste plus qu'à programmer le MEGA2560 et faire l'interface électronique des capteurs (pis aussi aller chercher des capteurs en casse, je ne les ai pas tous...). Je crains le pire au niveau de la linéarité des capteurs. J'avais déjà fait des relevés sur la jauge carburant, on est bien loin d'un simple facteur... Si pour certains un générateur de courant peut arranger les choses, je crains de devoir utiliser des tables de conversions...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Sep 12, 2012, 01:37 pm


Bon, en réel, il n'y a pas autant de reflets (le défaut des APN : ils mettent toujours en valeur les reflets). De plus, dans la voiture, il y a une grande casquette au-dessus.

Je suis assez fier de moi, l'ensemble se présente plutôt bien, le noir mat légèrement granuleux apporte vraiment un fini sympa! Je comptais faire des découpes à la machine dedans, mais finalement non, ça restera comme ça!


sympa comme rendu, mais pour moi il manque un HA comme affichage  :smiley-mr-green:
et si il n'y en a pas , je ne monte pas !  8)
(http://www.heliforum.com/images/jm/Abreviations/horiz_artif.jpg)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Sep 12, 2012, 02:49 pm
J'en ai vu un il y a bien... fiou! 20 ans... dans une fiat panda 4x4... Il y avait deux cadrans, avec dans chacun une petite voiture (face et profil) qui s'inclinait grâce à un pendule mécanique (à l'époque, les capteurs gyro électroniques étaient peu fiables et réservés à la NASA).

Mais je n'en monterai pas tant que je n'aurai pas terminé l'asservissement par servo du becquet arrière et des ailerons...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: jfs on Sep 13, 2012, 07:44 am

sympa comme rendu, mais pour moi il manque un HA comme affichage  :smiley-mr-green:
et si il n'y en a pas , je ne monte pas !  8)
(http://www.heliforum.com/images/jm/Abreviations/horiz_artif.jpg)


Tu peux utiliser le mien  XD

http://www.youtube.com/watch?v=zseS5c4CExw
Title: Re: [Projet] Un tableau de bord numérisé
Post by: barbudor on Sep 13, 2012, 08:19 am

Tu peux utiliser le mien  XD


Le vélo de JF est encore plus "tunné" que la pire des R11  :smiley-mr-green:
Tu as un IMU pour le contrôle d'assiette ?
Vélo pendulaire pour compenser dans les virages ?
Title: Re: [Projet] Un tableau de bord numérisé
Post by: chabot380 on Sep 14, 2012, 08:10 am
salut
(http://www.ledauphine.com/fr/images/B23E333F-50CA-45AF-92BB-7A10D79D3BA3/LDL_06/lucie-ollivier-le-dl-14-02-2010-montelimar-pascal-rambaud-voiture-pendulaire.jpg)

voir l'article là : http://www.ledauphine.com/drome/2010/04/27/pascal-rambaud-a-invente-la-swing-car-...-un-vehicule-inspire-du-velo-et-de-la-caisse-a-savon (http://www.ledauphine.com/drome/2010/04/27/pascal-rambaud-a-invente-la-swing-car-...-un-vehicule-inspire-du-velo-et-de-la-caisse-a-savon)

A+
Title: Re: [Projet] Un tableau de bord numérisé
Post by: jfs on Sep 14, 2012, 08:19 pm

Le vélo de JF est encore plus "tunné" que la pire des R11  :smiley-mr-green:
Tu as un IMU pour le contrôle d'assiette ?
Vélo pendulaire pour compenser dans les virages ?


J'ai une centrale inertielle que j'avais utilisée pour faire cet HA, mais ce n'est pas monté sur mon vélo.... qui n'est pas encore un tilting trike  :smiley-mr-green:
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Sep 14, 2012, 09:46 pm
Pour revenir au sujet de base, j'ai été "obligé" de le rendre un minimum présentable car j'exposais mon embryon de TDB avec un petit speetch à des élèves du lycée. Les copains profs m'ont bien eu, car c'était des élèves de première, donc pas encore à même de piger les notions que j'abordais. Il espéraient en fait que je déclenche quelques réactions, histoire de repérer quelques uns qui auraient déjà du code dans les doigts, mais non, pas dans cette promo. J'y retournerai quand même pour apporter un oeil "extérieur" sur les TPE

Mais les 4 potars que j'ai mis font bien bouger les aiguilles, les compteurs s'incrémentent quand on le leur demande, c'est pas trop mal.

J'ai soudé un petit transistor et codé une PWM pour la gestion du contraste, mais pas encore essayé...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Sep 15, 2012, 01:02 pm
Et j'ai bien fait de ne pas essayer...

Un coup de metrix sur la broche V0 du LCD : -11.2V, là, tout s'est effondré... Puis finalement, j'ai regardé de plus près, le potar qui gère le contraste est connecté entre le +5 et VEE (VEE = -13.5V). Ouf! on peut donc faire un truc simple avec un PNP :

(http://pop.studio.free.fr/imgtmp/120915_1.jpg)

Rien de plus facile au final, car sur le back-pack, il y a deux rangées de trous pour relier un LCD, puisqu'il est prévu aussi bien pour le LCD 160x128 (le mien) que le 128x64. Donc je fais un circuit qui se soudera sur les trous du 128x64 (pour avoir accès aux pins J1 à J4), et un petit câble plat entre J5 et le connecteur ISP pour récupérer le OC2A qui s'y trouve. J'en profite pour rajouter quelques capas (C2 et C3 erreur de frappe, C3 = 330µF) de filtrage, car les alims sont vraiment pas belles à l'oscillo (ça ondule de +/-0.4V alors qu'à la base, je peux fournir jusqu'à 2A...). J'ai aussi constaté que le contraste est très sensible à l'alim, avec un réglage correct sous 5V, il suffit de descendre à 4.7V et tout disparaît.

Le backpack avec ses deux rangées de connecteurs :

(http://pop.studio.free.fr/imgtmp/111022_2.jpg)

Le typon (que j'ai fait avant de dessiner le circuit, c'est ma spécialité...) :

(http://pop.studio.free.fr/imgtmp/120915_0.jpg)

Cet am, je ferai d'autres circuits puis un peu de gravure (tant qu'à utiliser de l'eau oxygénée, autant faire un max de circuits dans le bain qui sera perdu).
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Sep 16, 2012, 05:56 pm
Et ça marche :

(http://pop.studio.free.fr/imgtmp/120916_11.jpg)

On voit à droite du connecteur ISP la trace du potar que j'ai dessoudé (j'ai arraché la piste sur l'autre écran...)

Bon, il a fallu que je câble autrement mon transistor, car le contrast se règle sur un petit poil (entre -8 et 12V, en dehors, on ne voit plus rien...).

(http://pop.studio.free.fr/imgtmp/120916_12.jpg)

Reste qu'il va falloir peut-être changer les régulateurs de la carte de sparkfun, car ils ne sont vraiment pas bons. le VCC s'écrase pour un rien, alors que le 5V qui rentre dessus ne bouge pas d'un poil...

J'ai finalement trouvé un compromis pour utiliser le timer 2 à la fois pour le clignotement des icônes et pour la PWM du contraste, reste à tester (avec le timer 0, ça clignote pas du tout...)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Sep 18, 2012, 01:04 pm
Un peu d'avancement...

J'ai fait les connecteurs pour brancher le faisceau d'origine et câblé les voyants...

(http://pop.studio.free.fr/imgtmp/120918_1.jpg)

C'est sûr que le tableau de bord d'origine fait plus propre, mais m'en fous, ça se verra pas...

(http://pop.studio.free.fr/imgtmp/120918_2.jpg)

Reste un dernier connecteur à faire qui ira vers l'unité de traitement et normalement, de ce côté, c'est fini (à part certainement encore un peu de prog rectificative sur les écrans...)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: fdufnews on Sep 18, 2012, 04:31 pm
En vibration, un condensateur radial n'est pas très endurant. Personnellement, je mettrais un point de colle sur les capa pour éviter de les retrouver au fond du tableau de bord dans 1 an.
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Oct 12, 2012, 08:06 am
Bon, allez, quelques nouvelles!

Le projet avance lentement, j'en suis à lister les fonctionnalités et les classer par catégories (mesures à intervalles régulières, mesures ponctuelles, interruptions prioritaires...) histoire de définir un ordre hiérarchique. Bon, ben ça fait noircir du papier.

Mais voilà qu'entre temps, j'ai plié ma R11... pas dans un talus, mais juste en mettant le cric en dessous : le châssis était tellement pourri que la caisse est devenue toute molle et s'est pliée en deux sur le cric, plus de tenue de route etc etc. Bref, c'est pas réparable. Donc en attendant, j'ai acheté une autre caisse (un modèle que je lorgnais depuis pas mal de temps : une R21 PH1, le tout premier modèle... oui, je suis assez vintage dans mon genre, ce qui va très bien avec mon budget).

Bien sûr, toutes les renault de 1980 à 1995 ont eu le même tableau de bord (même gabarit, seules les options changent), donc mon projet est transposable sans modifications particulières sur la 21. Mais je pense que je vais commencer par remettre cette nouvelle auto en état (je l'ai achetée comme les autres : sans CT et pas chère) avant de lui coller mes options persos...

(http://pop.studio.free.fr/imgtmp/121009_0.jpg)

Puis là, je vais avoir un max de place pour mettre de l'électronique derrière la planche de bord, contrairement à la R11 qui ne m'aidait pas beaucoup de ce côté...

(http://pop.studio.free.fr/imgtmp/DSCN9711.jpg)

projet en pause...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Oct 27, 2012, 07:49 am
du nouveau? oui et non... Cette nouvelle auto s'est révélée peu satisfaisante (moteur dégonflé : conçu pour donner 90chx, mais la version sur cette voiture est bridée à 76chx), pis beaucoup de frais finalement. Donc je me suis mis en quête d'une autre auto, pareil : pas chère. J'ai trouvé la perle rare : R21GTS en super état, le même moteur, mais celui-là gonflé à 95chx, et avec beaucoup plus d'options (il manque juste la clim en fait). Donc dans la même idée : remise en état, puis après, on reprend le projet pour le mettre dedans.

Tous les capteurs que j'avais imaginé sont déjà dedans, puisque c'est une injection multi-point, voire même il doit y avoir encore plus de capteurs, car il y a deux calculateurs (injection et allumage séparés). En plus, il me suffira d'aller me piquer sur le calculateur pour récupérer tous les signaux, presque trop facile! Peut-être même qu'en utilisant la prise diag, j'aurai accès à des données déjà filtrées :

(http://pop.studio.free.fr/imgtmp/121026_0.jpg)

(http://pop.studio.free.fr/imgtmp/121026_8.jpg)

(http://pop.studio.free.fr/imgtmp/121026_9.jpg)

toujours en pause...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Nov 19, 2012, 04:12 pm

Je désespérais de tomber un jour sur quelqu'un d'aussi taré que moi pour équiper une bagnole avec un régul de conception perso, voilà c'est fait !
merci du compliment et bienvenue dans la zone des malades. ;)

le signal d'allumage n'est pas top pour le calcul RPM, il bouge beaucoup à cause de l'avance à l'allumage. Mieux vaut piquer un signal ailleurs, tout dépend de quel moteur tu as.

De mon côté, j'ai fait une pause, car la nouvelle receveuse n'est pas encore sur route (et vient juste de claquer son joint de culasse, c'était pas prévu).

De plus, comme c'est une injection, et qu'elle ne démarrait pas à froid, j'ai fini par construire vite fait un système avec un léonardo et un LCD pour déchiffrer les infos du calculateur d'injection, et j'ai trouvé la panne en 5 secondes (capteur de température moteur HS). Mais j'ai découvert que ce calculateur m'envoyait des infos en continu par trame d'une 30aine d'infos (par lisaion série, norme "XR25") des capteurs, gestion moteur etc etc. Bref, il me suffit de récupérer ces infos pour m'affranchir d'un tas de calculs (le calculateur envoie par exemple l'avance à l'allumage, vitesse rotation moteur, temps d'injection... et le tout préformaté, une simple multiplication d'un octet donne la bonne valeur). Ca remet toute la prog du proc central en cause. Car en plus, le calculateur envoie ses trames de donnée toutes les 30ms au repos, et toutes les 9ms quand le moteur tourne à 3000tr, pour l'affichage, c'est assez précis (même trop) je pense.

Je me focalise plus sur la mécanique pour l'instant, et la prog sur PC d'un soft pour visualiser mes données (à cause du JDC, je vais devoir démonter la moitié du moteur, un tel diagnostique ne sera pas de trop pour la remise en route...).

Quel moteur as-tu? je peux peut-être te donner des infos utiles...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: bricofoy on Nov 20, 2012, 09:04 am
je suis fan te ton projet :)

mais je ne peux m'empécher de penser qu'il irait mieux dans une R25 ou une XM. série 1 bien entendu !
Title: Re: [Projet] Un tableau de bord numérisé
Post by: bricofoy on Nov 20, 2012, 10:30 am
oui, mais justement, je trouve que ça cadre mieux dans une grosse berline comme la 25 ou la XM, qui en plus, l'une comme l'autre, étaient déja bardées d'électronique quelque peu... capricieuse ! Et ce genre de projet ça va bien avec les tableaux de bord "star trek" de l'époque, en plus :)

ceci dit, je ne critique pas, hein :) je donne juste mon avis
Title: Re: [Projet] Un tableau de bord numérisé
Post by: bricofoy on Nov 20, 2012, 11:41 am
jespère :)

je songe à faire un truc un peu similaire (mais bien plus simple) pour remplacer l'afficheur 2 lignes de l'ODB de ma XM, afin de faire qqch d'un peu plus interactif. Et si possible couplé à une gestion maison de la boite auto... mais c'est comme tout, plein d'idée et pas de temps...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Nov 20, 2012, 01:05 pm
Salut,

Je suis allé loin, en effet, puisque j'ai un premier proto qui fait bouger les aiguilles en fonction des potars qui simulent les capteurs... Mais là où je bloque, c'est qu'ayant changé de voiture, je n'ai plus besoin de capteurs, mais simplement de décoder une trame émis par port série, et surtout que je ne vais pas tarder à démonter mon moteur, donc encore plus en pause... Y'a aussi que j'ai choisi d'orienter le coeur du système vers une STM32F4 discovery, ça va m'obliger à me mettre à un nouveau proc, et l'apprentissage ne sera pas si facile.

Mon moteur est un F3N (1L7 injection multipoint) Pour ton J7T, il est de la mauvaise année, car c'est l'année de l'obligation de la norme ODB2. Je suis en train de travailler sur les versions d'avant, qui n'ont rien à voir. L'ancienne norme RENAULT était caractérisée par une grosse prise diagnostic 12 points "l'électrifil". Vois si tu as cette prise ou une plus petite pour le diagnostique. Dans le premier cas, je peux te dire comment récupérer les infos du calculateur et comment en décoder une partie (je n'ai pas encore tout trouvé, c'est un format propriétaire, donc gardé jalousement dans un coffre fort chez renault). Ce serait du coup bien plus facile de récupérer une valeur sur deux octets de cette trame de données, par exemple pour la vitesse moteur, la formule est tr/min = 15000000 / word(d6, d5).

Pour te donner une idée des infos, un screenshoot de mon soft en cours de développement :

(http://pop.studio.free.fr/imgtmp/121107_1.jpg)

et affichage des courbes lors d'un démarrage par exemple :

(http://pop.studio.free.fr/imgtmp/121118_0.jpg)

le tout est de voir quelle version tu as en sortie de ton calculateur.

Pour Bricofoy, il te suffit de trouver une doc sur ton odb (en général, le brochage est dans la revue technique), ce n'est que des signaux analogiques et des impulsions à mesurer. J'ai fait une étude sur un ODB de super5 avec le format des données et formules de conversion :

(http://pop.studio.free.fr/img/pdf.jpg)super5_-_odb_-_etude_technique_0.pdf (http://pop.studio.free.fr/imgtmp/super5_-_odb_-_etude_technique_0.pdf)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Nov 20, 2012, 08:13 pm
bonsoir supercinci
pour ma culture personnelle
ça se trouve facilement "en occasion"  le débitmètre utilisé ?
quel ordre de "prix" ?
ça peut etre sympa dans certains cas de DIY si le cout n'est pas prohibitif
Title: Re: [Projet] Un tableau de bord numérisé
Post by: bricofoy on Nov 20, 2012, 08:41 pm

Pour ton J7T, il est de la mauvaise année, car c'est l'année de l'obligation de la norme ODB2.



... d'un autre coté, l'ODB2 est il me semble relativement bien documenté, on trouve sur le net à peu près tout ce qu'il faut pour l'utiliser.
Title: Re: [Projet] Un tableau de bord numérisé
Post by: etimou on Nov 20, 2012, 10:22 pm
Bonjour,
Je n'ai toujours pas compris si on pouvait envoyer des commandes (par exemple le taux d'accélération) sur OBD2.
Je ne vois que des exemples de lectures d'informations, mais pas de commandes vers le véhicule...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Nov 21, 2012, 09:21 am

bonsoir supercinci
pour ma culture personnelle
ça se trouve facilement "en occasion"  le débitmètre utilisé ?
quel ordre de "prix" ?
ça peut etre sympa dans certains cas de DIY si le cout n'est pas prohibitif
Salut,

Le débitmètre se trouve dans toutes les casses, il faut regarder sur le tableau de bord de la voiture, s'il y a un ODB, enfin un truc qui affiche la conso, c'est le signe de la présence d'un débitmètre.

Il y a deux types de débitmètres, selon si c'est un moteur à carbu ou injection. Dans le premier cas, il se place juste à l'entrée d'essence du carburateur (deux durits), dans le second, il est sur l'entrée et la sortie du circuit de carburant (4 durits). C'est un truc pas bien gros qui se démonte facilement. Le plus dur étant de réussir à le placer sur le circuit de sa voiture, au bon endroit et dans le bon sens. Attention cependant à ne pas le confondre avec une électrovanne... selon les casses, ça sera 2€ ou 50€...

Un autre truc intéressant à récupérer, du coup, c'est le capteur de vitesse, sur les vieilles autos, il fait partiel du câble qui relie la boîte de vitesse au tableau de bord (récupérer le câble complet et la connectique). l'association des deux permet de refaire soi-même un calculateur de conso / autonomie.

@ 5_cylindres : il faut que tu trouves ta prise diag, son format nous renseignera tout de suite sur le protocole...

C'est sûr que l'OBD2 est plus facile, puisque c'est une norme européenne, donc accessible, mais je ne me suis encore jamais penché dessus (ça viendra, car j'ai la voiture de madame à diagnostiquer également, 1997 ODB2). En effet, l'ODB2 est bidirrectionnel, il peut recevoir des ordres, mais je ne sais pas (encore) comment...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: bricofoy on Nov 21, 2012, 09:27 am

Bonjour,
Je n'ai toujours pas compris si on pouvait envoyer des commandes (par exemple le taux d'accélération) sur OBD2.
Je ne vois que des exemples de lectures d'informations, mais pas de commandes vers le véhicule...


pour ce que j'en sais, non.
par contre l'ODB2, c'est une norme qui définit le protocole de com, et certains messages, mais absolument pas la totalité, il existe d'autres commandes propriétaires propres à chaque fabricant pour dialoguer avec les calculateurs via le protocole et le bus ODB2. Parmis ces commandes, il est possible qu'il existe ce que tu cherche. le problème, c'est que par définition, c'est propriétaire, donc sans doc publique...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Nov 22, 2012, 08:20 am

salut Super_Cinci

pour la prise diag de mon espace 2 : de mémoire il s'agit d'une grosse prise noire sous le capot, env. 4 à 5 cm de côté, avec 12 contacts disposés en 4 x 3, mais je ne peux confirmer car j'ai fixé un relais dessus pour le compresseur de clim et je n'ai aucun collier pour le raccrocher si je le démonte

C'est donc de première génération, celle sur laquelle je m'arrache les cheveux actuellement et je peux te donner tous les renseignements que j'ai. Si tu es patient, je suis en train de monter une doc sur ce que j'ai trouvé, une sorte de rapport d'étude.

sinon, pour rester sérieux, tu penses pouvoir en extraire des données exploitables pendant le fonctionnement ?
Si tu regardes les courbes sur fond noir dans mon post un peu plus haut, c'est un enregistrement que j'ai fait sur 25 secondes.
Comme c'est moi qui ai développé le soft, je suis capable de décoder ces courbes à vue... Mais pour le commun des mortels, ces courbes sont toutes cantonnées sur des valeurs entre 0 et 510 (0-255 x 2) et ne montrent que leur évolution dans le temps.
t = 0 : contact mis, moteur arrêté.
t = 5,5 s : j'actionne le démarreur (ce qui fait naturellement chuter la tension batterie en rouge), on voit le passage des compressions sur la pression du collecteur.
t = 6 s : le calculateur a repéré l'ordre des pistons et commence à injecter l'essence (en violet).
t = 7 s : Le moteur démarre, la pression collecteur chute à 400mb, l'alternateur passe en charge (la tension batterie grimpe à 14V), le moteur monte à environ 1800tr/min.
t = 8 s : La phase de démarrage est terminée, le calculateur passe alors en mode régulation de ralenti (courbe bleue : commande de vanne de ralenti).
t = 18,5 s : la courbe verte (entrées numériques) tombe à 0 parce que j'appuie sur l'accélérateur. Toutes les courbes suivent la montée en régime du moteur.
t = 20,5 s : je relâche l'accélérateur : le moteur retombe au relanti.
t = 23,5 s : je donne un grand coup d'accélérateur (la pression collecteur remonte, ce qui indique au calculateur qu'il faut réagir en injectant plus d'essence, plus d'avance allumage...)

Bref, J'ai en effet toutes les données que je veux. Sur cette portion de graphe, il y a 1500 trames de données environ (c'est assez précis?).

Bien sûr, mon soft décode les données en valeurs humaines en temps réel (voir la fenêtre avec les valeurs numériques, ça te montre les données que l'on peut extraire de la trame).

Il faut juste savoir qu'au coeur du calculateur, c'est un 68HC11, et qu'il n'émet de données que s'il a le temps (dans l'ordre des priorités, gérer l'injection et l'allumage, logique, les données diagnostiques ne sont pas importantes pour lui). Mais comme je l'ai dit, ça ne l'empêche pas d'envoyer des trames toutes les 9 ou 10ms dès qu'il n'a plus à gérer la régulation de ralenti... D'ailleurs, je viens de m'apercevoir qu'il a arrêté l'envoi de trames durant la phase de démarrage (6 < t < 7).

Bon, je suis en plein développement, et je viens de claquer mon joint de culasse, donc je n'ai pas pu faire l'enregistrement d'un trajet (ne serait-ce que le tour du pâté de maison...). Mais je pense que sur ta prise diag, tu trouveras assez d'infos pour ne pas avoir à mettre des capteurs partout...

Sur la R11, j'utilisais la vitesse de rotation du moteur, que je multipliais par un coéf (fonction du type de boîte de vitesse, différentiel, taille des pneus) pour trouver la vitesse en km/h. Comme en général, on ne régule la vitesse que sur route en 5°, mon LCD m'affichait 30 / 33km/h quand j'étais arrêté à un feu rouge... ;) et ça marchait très bien! De plus, tu as dans la trame une info intéressante : le contact "pied levé", qui passe à false dès que tu touches l'accélérateur (donc à ce moment, ça désactive le régulateur, l'humain reprend le contrôle). Tu n'aurais besoin que de rajouter un capteur sur la pédale d'embrayage et piquer le signal sur le frein : dès que tu touches l'une des trois pédales, ça coupe la régulation.

(http://pop.studio.free.fr/imgtmp/110604_2.jpg)

Le capteur pour l'embrayage, il y a un logement sur le pédalier qui permet de mettre le même capteur que celui de la pédale de frein, que du bonheur...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Nov 22, 2012, 10:59 am
Toute la réflexion sur le protocole est là : http://www.forum-super5.fr/index.php?showtopic=9508 (http://www.forum-super5.fr/index.php?showtopic=9508), depuis une bête question...
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Artouste on Nov 22, 2012, 11:38 am

...
Il y a deux types de débitmètres, selon si c'est un moteur à carbu ou injection. Dans le premier cas, il se place juste à l'entrée d'essence du carburateur (deux durits), dans le second, il est sur l'entrée et la sortie du circuit de carburant (4 durits). C'est un truc pas bien gros qui se démonte facilement. Le plus dur étant de réussir à le placer sur le circuit de sa voiture, au bon endroit et dans le bon sens. Attention cependant à ne pas le confondre avec une électrovanne... selon les casses, ça sera 2€ ou 50€...
...

bonjour supercinci
Si à l'occasion de tes peregrinations dans les "casses" tu tombe sur un ou deux debitmetre jusqu'à +/-une dizaine d'€ piece , tu me contacte ?
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Nov 22, 2012, 03:10 pm

bonjour supercinci
Si à l'occasion de tes peregrinations dans les "casses" tu tombe sur un ou deux debitmetre jusqu'à +/-une dizaine d'€ piece , tu me contacte ?
je note. Je n'ai pas prévu de passage en casse prochainement, mais peut-être que je vais tenter d'aller glâner quelque calculateurs pour faire des tests.
Title: Re: [Projet] Un tableau de bord numérisé
Post by: bricofoy on Nov 23, 2012, 10:56 am
il y avait des débimètres de ce genre sur les BX avec ODB (19GT, digit...) et je me suis aperçu que ces débimètres sont aussi employés... dans les machines à expresso ! j'en ai récupéré deux en démontant des machines à la déchetterie :)
Title: Re: [Projet] Un tableau de bord numérisé
Post by: elriri on Jan 31, 2013, 05:14 pm
Pour ceux que ça intéresse voila la solution : http://arduino.cc/forum/index.php?topic=58048.0
Title: Re: [Projet] Un tableau de bord numérisé
Post by: jfs on Jan 31, 2013, 06:23 pm

Pour ceux que ça intéresse voila la solution : http://arduino.cc/forum/index.php?topic=58048.0


La solution à quoi, je vois pas le rapport entre le filtre de Kalmann et le tableau de bord de superCinci  ?
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 09, 2013, 08:50 am
Salut la communauté,

Je reviens d'une semaine de vacances où je n'avais rien à faire de mes soirées une fois ma fille couchée. J'ai donc ressorti mon vieux projet (et oui, toujours d'actualité).

Après quelques changements de véhicule, il était temps de s'y remettre et de revoir certaines choses.

Comme je l'avais précisé, la nouvelle receveuse du gadget me simplifie grandement la tâche grâce à son calculateur d'injection qui me fournit en temps réel une trame de 37 octets sur l'état du moteur (température, rotation, capteurs, durée d'injection, avance allumage, défauts...). Il ne me reste donc plus grand chose à traiter : gestion de l'accélérateur (je remplace le câble par un potar et un servomoteur), vitesse en km/h, conso, quelques capteurs. Je me suis donc rabattu sur un MEGA2560.

Presque toutes les mesures seront traitées par interruptions, ce qui veut dire que loop() sera vide (enfin presque). Voici la liste des INTs que j'ai déjà prévues :

ISR (PCINT0_vect) : gestion d'un clavier matriciel 4x5, les touches sont bufferisées dans un FIFO.
ISR (USART3_RX_vect) : réception de la trame de données série du calculateur d'injection, les données remplissent un tableau de 37 bytes.
ISR (TIMER4_OVF_vect) et ISR (TIMER4_ICP_vect) : calcul de la vitesse en km/h et incrément des compteurs kilométriques
ISR (TIMER5_ICP_vect) : calcul de la consommation (xx,x l/100)
ISR (ADC_vect) : numérisation automatique de 8 entrées analogiques renseignant un tableau de 8 word
ISR (WDT_vect) : timer de déclenchement à intervalles réguliers (256ms) pour le régulateur de vitesse

Bref, l'idée est que toutes les variables de données se mettent à jour automatiquement, il suffit alors de les lire quand on en a besoin, c'est tout... De même, j'aurai 3 sorties servomoteur gérées directement par les sorties hard PWM du timer1, genre un simple OCR1A = valeur; suffit à changer la position du servomoteur. Pour les deux écrans du TDB, j'utilise USART 1 et 2 pour leur envoyer les données à afficher.

Tout ça est bien gentil, mais j'ai eu la chance d'ouvrir le wiring.c et d'y découvrir toute une initialisation barbare des timers, ainsi que de l'ADC. j'ai donc viré tout ça, histoire que le core arduino ne me configure pas les ressources de traviol pour rien (de même pour les fonctions delay(), micros()..., je les ai virées). Je configure le tout directement par les registres, en lisant le datasheet de l'AVR. J'ai aussi viré la gestion de l'USART3 pour pouvoir récupérer l'INT correspondante. J'ai aussi vu quelque part (dans le main.c je crois) qu'entre deux exécutions de loop(), il y avait un "doSerialEvents();", ce qui ne me plait pas trop, il faut que je vois ce que c'est et le virer également au besoin.
Ne serait-ce que pour la conversion analogique numérique, analogRead() prend un temps fou, car elle lance une numérisation et attend les 104µs de la conversion pour obtenir le résultat. Il faut savoir que 104µs représentent 1664 instructions (oh le beau nombre!), et que tout ça, c'est perdu dans un while(...){rien;}. sur 8 conversions à la suite, ça nous fait à peu près 13 500 instructions de perdues. Il faut quand même savoir que le CAN est indépendant, et qu'il fait les conversions tout seul dans son coin sans utiliser le CPU. J'utilise donc l'INT du CAN, déclenchée une fois la conversion terminée, et qui relance elle-même une nouvelle conversion puis rend la main au programme. Ca prend à peine 30 instructions contre les 1700 du core arduino. On apprend beaucoup en déchiffrant les datasheets...

Je pense gérer moi-même la gestion des ports série par la suite, car décidément, l'équipe arduino ne s'est pas trop occupée des temps de traitement...

Restera à voir si les interruptions ne se bouffent pas trop les unes-les-autres, que ça me laisse un peu de temps processeur pour le traitement...

A suivre!
Title: Re: [Projet] Un tableau de bord numérisé
Post by: Super_Cinci on Aug 11, 2013, 07:59 pm
Effectivement, pour l'instant, j'ai fait mes premières brides de code avec PSPad, un éditeur miltulangage (très pratique en PHP qui propose une coloration syntaxique bien plus claire qu'arduino, et qui a l'avantage de lister toutes les fonctions et #define d'un fichier pour se retrouver et naviguer plus vite. On peut lui associer un (des) compilateur(s), il faudrait essayer.

sinon, j'ai monté une platine avec une dizaine de potars et 24 inters, une alim 12V + 5V, et en plus un UNO qui génère la trame "XR25" (trame série du calculateur d'injection) avec de nombreuses données qui bougent (vitesse moteur, durée d'injection, avance allumage, dépression admission...), et quelques signaux d'impulsions (vitesse véhicule, débitmètre...). J'ai donc un banc d'essai (complet?) pour le développement sur le 2560, car ce n'est pas facile de développer un truc en conduisant.
Title: Re: [Projet] Un tableau de bord numérisé
Post by: deco25 on Feb 12, 2015, 09:40 pm
Bonjour monsieur Super_Cinci,

je suis impressionné par votre projet. Je compte effectuer la même chose pour une voiture de course.

J'ai juste une question à vous poser : comment avez-vous récupérer le signal du capteur PMH sans perturber ce signal qui va jusqu'au calculateur.

Dans l'attente de vous lire,

Romain.