[Projet] Un tableau de bord numérisé

Salut,

Un sacré projet que tu nous présente dit donc :astonished:

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 :wink:

Encore bravo pour le travail accomplit, je suis sûr qu'il ya de longue heures derrière tout ça :grin:

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?)

skywodd:
Salut,

Un sacré projet que tu nous présente dit donc :astonished:

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 :wink:

Encore bravo pour le travail accomplit, je suis sûr qu'il ya de longue heures derrière tout ça :grin:

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...)

Super_Cinci:
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

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 ^^

chicotore:
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.

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 :

  • Vitesse : de 0 à 255Km/h par pas de 1km/h, même si on est limité à 130, une résolution de 1 suffit.
  • Niveau carburant : de 0 à 48 litres, 255 valeurs par pas de 0.2l (facteur = 5) donnent un affichage possible de 0 à 51l
  • Température eau moteur : de 0 à 120°, 255 valeurs par pas de 0.5° (facteur = 2) donnent un affichage possible de 0 à 127.5°

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 :

facteur range pas v=0 v=1 v=2 v=3
1 0 à 255 1 0 à 255 +/- 1 0 à 25,5 +/- 0.1 0 à 2,55 +/- 0.01 0 à 0,255 +/- 0.001
2 0 à 510 2 0 à 510 +/- 2 0 à 51,0 +/- 0.2 0 à 5,10 +/- 0.02 0 à 0,510 +/- 0.002
3 0 à 765 3 0 à 765 +/- 3 0 à 76,5 +/- 0.3 0 à 7,65 +/- 0.03 0 à 0,765 +/- 0.003
4 0 à 1020 4 0 à 1020 +/- 4 0 à 102,0 +/- 0.4 0 à 10,20 +/- 0.04 0 à 1,020 +/- 0.004
5 0 à 1275 5 0 à 1275 +/- 5 0 à 127,5 +/- 0.5 0 à 12,75 +/- 0.05 0 à 1,275 +/- 0.005
6 0 à 1530 6 0 à 1530 +/- 6 0 à 153,0 +/- 0.6 0 à 15,30 +/- 0.06 0 à 1,530 +/- 0.006
7 0 à 1785 7 0 à 1785 +/- 7 0 à 178,5 +/- 0.7 0 à 17,85 +/- 0.07 0 à 1,785 +/- 0.007
8 0 à 2040 8 0 à 2040 +/- 8 0 à 204,0 +/- 0.8 0 à 20,40 +/- 0.08 0 à 2,040 +/- 0.008
9 0 à 2295 9 0 à 2295 +/- 9 0 à 229,5 +/- 0.9 0 à 22,95 +/- 0.09 0 à 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

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)...

facteur range pas v=0 v=1 v=2 v=3
39 0 à 10200 39 0 à 10200 +/- 39 0 à 1020.0 +/- 3.9 0 à 102.00 +/- 0.39 0 à 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 :

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!

Super_Cinci:
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

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 ?

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 ]:smiley: (comme sur l'autoroute où je roule a 120 sur la voie de gauche quand y'a des grosses BMW derrière moi :grin:)

  • 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.

  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 ?

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

barbudor:

Super_Cinci:
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é :grin: ). On prend vite des habitudes et repères visuels, donc je garde le 90 à la verticale et le 0 à 20° en bas...

barbudor:

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...

barbudor:

  • 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?

barbudor:

  • 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... :smiley:

barbudor:
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!

barbudor:

  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.

barbudor:
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?


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 :

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!)

La Renault 11 la plus moderne qui soit :grin:

Super_Cinci:
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 : avr-libc: Data in Program Space

++

SesechXP:
La Renault 11 la plus moderne qui soit :grin:

Je ne fais que réinventer ce qui existe déjà : 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...

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

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.

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 : PROGMEM - Arduino Reference 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.

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!

SesechXP:
La Renault 11 la plus moderne qui soit :grin:

Super_Cinci:
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 : avr-libc: Data in Program Space

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.

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!

barbudor:
...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 ]:smiley: (comme sur l'autoroute où je roule a 120 sur la voie de gauche quand y'a des grosses BMW derrière moi :grin:)

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

Artouste:
ç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 :stuck_out_tongue_closed_eyes:

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 ?

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....

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!

neodelavega:
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?

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