Compte tours écran OLED trop lent

Bonjour à tous!
Dans le cadre d'une transformation complète d'une moto au style minimaliste, j'ai décidé de créer un compteur lui aussi minimaliste et discret.
J'ai donc fait l acquisition d'un écran Oled 0,96" sur lequel je souhaite afficher la vitesse et le régime moteur. Ce dernier se présente sous forme d'un anneau qui va de 0° à 240° (raison purement ésthétique).
J'ai déja fait un programme à part pour l'acquisition du signal, je parle donc ici uniquement de la partie affichage.
J'utilise un arduino Nano, j'utilise un potentiometre sur l'entrée Analogique 0 pour simuler le signal du régime moteur, je mappe celui ci pour le faire correspondre à un angle que j'utilise pour tracer mon graph. Seulement voila le problème, le graphique s'affiche TRES lentement, par saccades.
Est ce que changer de carte suffirait, ou y a t'il des phases de mon programme qui gagneraient à être optimisées?

#include <U8glib.h>

                                                       //librairie graphique
U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_NO_ACK);                              //configuration I2C specifique a l'afficheur choisi

int pin_accel = A0;                                                         //potentiometre sur entree A0 pour simuler l'accelerateur
int regime_moteur;
int regime_map;
double angle_rad;
double x0;
double y0;
double angle;
float x1;
float y1;


// ==========================FONCTION D'AFFICHAGE=====================================

void draw(void) {
 
for(int i=89 ; i<regime_map ; i++)  //boucle pour tracer les rayons du cercle correspondant au regime moteur
{
   angle = (i*0.017453);            //transformation des degrés en radians
x0= 32+(32*(cos(angle)));           //calcul des coordonnées des points à tracer 
  y0= 32+(32*(sin(angle)));
  u8g.drawLine(x0, y0, 32,32);
}
}




//==========================BOUCLE PRINCIPALE===========================
void setup() {

  pinMode(pin_accel , INPUT);
  
Serial.begin(9600);

}

void loop() {
  regime_moteur = analogRead(pin_accel);                           //acquisition du regime simulé
  regime_map = map(regime_moteur, 0, 1023, 330, 90);               //mappage
  
Serial.println(regime_map);
   angle = (regime_map*0.017453);                                  //transformation des degrés en radians

  
  
   u8g.firstPage();
  do {
    draw();
  } while ( u8g.nextPage() );

  
  


}

Voici le systeme en vidéo

Bonjour,

Tu peux en premier éliminer les calculs trigos en créant deux tableaux de 241 entiers (byte est suffisant) contenant:

32+ 32*(cos(angle)), avec angle allant de 0 à 240, par pas de 1degré.
Ces tableaux seront crées dans le setup().

Et si c'est encore trop lent, changer de carte.

Roger.

Bonjour,
En lisant la réponse de bilbo83 hier soir, c'est la première idée qui m'est venue : trop de temps pour calculer un cosinus...

En relisant ce matin, à la tombée du lit (j'ai un cpu qui travaille quand je dors :slight_smile: ),
il me semble que c'est le contraire, il n'y a pas suffisamment de calculs...

Dans le cadre de la simulation avec un potar, si tu dois t'évertuer à le tourner très lentement, c'est qu'une variation aussi petite soit-elle génère encore un trop grand écart en analogRead...

J'aurais bien essayé :

regime_moteur = analogRead(pin_accel) / 50;                           //acquisition du regime simulé

voire plus:

regime_moteur = analogRead(pin_accel) / 200;                         //acquisition du regime simulé

Ou un potar plus faible générant plus de valeurs pour une course identique...

Mais bon, autant c'est une connerie matinale :wink:

Hello,

En regardant les caractéristiques de l'Oled 0.96'' la résolution annoncée est de 128x64 (c'est bien celui-là ?)
J'ai créé un petit tableau sous Calc pour voir comment évoluent les coordonnées d'un sinus sur la plage 0-90° d'une cercle de 32 pixels de diamètre.
On peut franchement utiliser une résolution de 2° sans perdre en précision.
Pré-calculer les valeurs de coordonnées nécessaires permet d'accélérer le processus de dessin.

D'autre part, si je lis bien ton code tu redessines à chaque fois l'arc complet correspondant au régime.(en recalculant les valeurs).
Tu pourrais plutôt

  • Calculer une seule fois les coordonnées de l'arc complet (régime maximum) et les stocker dans une table à l'initialisation par exemple.
  • A chaque dessin, tu ne dessines que la différence avec le régime précédent
  • S'il est plus élévé, tu dessines les lignes qui manquent
  • s'il est plus bas, tu effaces les lignes en trop.
  • Tu mémorises le régime actuel pour la prochaine comparaison.

Ainsi, tu te limites au strict nécessaire...

Pour la vitesse de réaction, il faut faire tourner le potard à la même vitesse qu'une possible variation de régime afin que la simulation soit valable.

Bonne continuation !

Coyotte

Merci a tous pour vos conseils, mais meme en appliquant tout cela, il faut reconnaitre que l'affichage ne suit pas dans le cas d'une montée de régime... mais est'ce que cela vient du calcul? De l'écran? De la liaison entre les deux?

Pour le savoir, tu dois mesurer le temps pris par le calcul et le temps pris par le dessin.

Tu peux, par exemple, compter le nombre de fois que tu peux faire le calcul durant 1 seconde.
Ensuite, tu comptes le nombre de fois que tu peux faire le dessin sur la même période

Tu auras déjà un ordre de grandeur des temps nécessaires et des optimisations à apporter.

Coyotte

Je crois que si je souhaite avoir la possibilité de varier de moteur en plus. Je crois qu'il serait plus simple d'être en mesure de préconfigurer avec 3 pots, un pour le voltage, ampère et fréquence. En jouant avec les 3 pots pour synchronisé la durée temps de fonctionnement, un flipflop, tu qui pour qu'il compense la différence en temps réel.

Un exemple:

Disons, je met un moteur quelconque. Avec un speedomètre (c'est plus simple et plus précis) en ayant la vitesse d'une rotation, avec l'équation approprié, tu peux obtenir les valeurs aux variable d'un système idéal. Quand tu sais ces infos (V, A, Hz), tu ajustes tes 3 pots et tu valide avec ton speedo. La méthode sans speedo, c'est de le faire à l'oeil ou plutôt à l'oreille lollll. Bon, le but du flip flop et quelques composantes et un timer 555, tu peux almentez son courant nécessaire, il fera toujours le même tour selon VAHz et chaque tick tu timer, ton IC va prendre le VA entrant et s'il fluctue de + ou - x (volt) et + ou - y (ampère) amplifier ou restreindre la différence entre la donnée configuré et celle réel prise au chaque tic du timer.

Tu synchronise ta vitesse de rafraichissement avec le timer 555. Donc aucun calcul ou traitement à faire. Avec des 74h595. reste plus qu'un truc côté du circuit, c'est ce qui va ajuster ta fréquence. C'est la fréquence, tu sais que un tour minute c'est qui sera affiché (le 3e pot que t'a configuré) ce chiffre représente ton tour min. Chaque pulse = une rotation. Chaque tu met en mémoire le compte-TOUR et tu affiche au tic555 à l'écran la valeur. Et le bouton Reset pour effacer.

Bref, mon idée est un peu plus compliqué à première vue, mais un ptit pcb maison avec le circuit que j'ai exposé (dans la plupart des cours électroniques, les premiers exercices pratique d'entrée en matière, le compteur, affichage sur led, etc. Où je veux en venir, avec cette idée, tu peux avec quelques composantes de bases, t'éviter l'utilisation tout court d'un microcontroleur. En ayant que quelques composantes qui requiert presque rien en énergie et ce, au moment où il fonctionne. Ayant aucun besoin de calculer, un simple nombre qui s'incrémente à la fréquence souhaité. Tu affiche et rafraichis la donnée stocker à chaque plusions du timer. Enfin dites-moi si sa fait du sens pour vous, parce que justement j'ai besoin d'une solution semblable....

Tu réponds à un message vieux de presque quatre ans...

Et en plus c'est incompréhensible.

1 an ou 4 ans, c'est pas important, je recherchais de l'aide ou des indices, si cette page est devenu inutile, pourquoi la laisser là ? Je sais pour le côté incompréhensible, j'essayais de voir (donc une suggestion d'idée pour améliorer celle décrit au début) pour voir la solution à un problème d'une manière complètement différente, en ayant pour but de l'optimiser. Dans un futur où on commencera à calculer et couper au max l'énergie consommer à la veille d'une extinction de notre race ! lolll