Arduino delai de traitement DATAREF

[avia767]

Bonjour,
J'utilise l'Arduino MEGA + Ethernet pour récupérer un paramètre de vol DATAREF via Ethernet UDP, puis je l'affiche sur un écran LCD 2.8.

paramètre récupéré : vitesse sol (GS)

Problème no 1 : retard a l'affichage sur l'LCD quand les variations de vitesse sont importantes, l'Arduino a du mal a suivre mes commandes, est-ce un problème hardware ? (aucun pb quand la variation est faible)

Problème no 2 : Si je récupère deux ou trois autre paramètres, les performances se dégrade.

[numero_744]

Bonjour.
Un ralentissement dans votre cas est soit un problème réseau soit votre code qui n'est pas bon.
Pourriez-vous nous envoyer votre code ?

[avia767]

Bonjour voici le code avec recuperation de plusieurs paramètres

#include <SPI.h>
#include <UTFT.h>
#include <Ethernet.h>
#include <XPData.h>

//-------------ETHERNET UDP CONNECTION SETUP-----------------------------
byte Ard_MAC[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED}; // MAC-Address of Arduino Ethernet shield
unsigned int XPR = 5080; // port to to receive data from Plugin
unsigned int XPW = 49000; // port to send data to X-Plane
byte IPx[] = {0, 168, 0, 102}; // this Arduino IP address (0,0,0,0 for auto)
//--------------END SETUP-------------------------

//Variables intitialization
extern uint8_t SmallFont[];
extern uint8_t BigFont[];
extern uint8_t SevenSegNumFont[];

float IAS=0.0; // init XPLANE – INDICATED AIR SPEED variable
float GS_F=0.0; // init XPLANE - GROUND SPEED variable
float IRS_LAT=0.0; // init XPLANE - LATITUDE variable
float IRS_LONG=0.0; // init XPLANE - LONGITUDE variable

UTFT myGLCD(SSD1289,38,39,40,41);

void setup()
{

XPDStart (XPR, XPW, IPx, Ard_MAC); //==! init XPlaneData
DataGet(0, 2); // Ground Speed position in OUT.cfg file
DataGet(0, 2); // Ground Speed position in OUT.cfg file
myGLCD.InitLCD(LANDSCAPE); //==! init LCD
myGLCD.clrScr();
myGLCD.setFont(BigFont); //==! init LCD font

myGLCD.print("IAS: ", 25, 20); // text print on LCD
myGLCD.print("GS: ", 25, 50); // text print on LCD
myGLCD.print("LAT: ", 25, 80); // text print on LCD
myGLCD.print("LONG: ", 25, 110); // text print on LCD

}
void loop()
{
// ------ GET DATA FROM XPLANE AND PRINT THEM ON LCD ---------
XPDScan(); // - must be to read data from X-Plane

IAS = ReadData ( 0, 1); // get data from Xplane (IAS speed)
myGLCD.printNumF(IAS, 1, 50, 20); // print values on LCD

GS_F = ReadData ( 0, 2 ); // get data from Xplane (ground speed)
GS_F = GS_F/0.514; // conversion to knots
myGLCD.printNumF(GS_F, 1, 50, 50); // print values on LCD

IRS_LAT = ReadData ( 0, 3); // get data from Xplane (LAT Position)
myGLCD.printNumF(IRS_LAT, 3, 50, 80); // print values on LCD

IRS_LONG = ReadData ( 0, 4); // get data from Xplane (LONG Position)
myGLCD.printNumF(IRS_LONG, 3, 50, 110); // print values on LCD



} // END loop

si j'utilise un paramtere, c'est rapide, avec plusieurs param c'est long :
çà ralenti,
ya peut etre des collision de packet ??
faut il definir un buffer dans mon code ??
ou mémoire hardware insuffisante (Arduino ou bien le LCD) ??

[PhM]

...ça ralenti, ...

Avant de partir dans tous les sens sur les causes possibles d'un fonctionnement jugé pas assez rapide il faut d'abord analyser ce qui se passe.
Le processeur Arduino execute ce qui se trouve dans la boucle loop(), il faut donc regarder ce qui se passe dans les fonctions suivantes :

XPDScan()
ReadData()
printNumF()

Autre chose potentiellement dangereuse :

GS_F = GS_F / 0.514;

Un nombre écrit de cette façon, et non pas 0.514f, représente un double et non pas un float. J'espère que le compilateur pour Arduino n'est pas assez fou pour faire des calculs en double sur un processeur 8 bits, mais il est toujours bon de bien préciser ce que l'on veut faire, et ce quelle que soit la plateforme matérielle utilisée, plutôt que d'espérer que le compilateur fasse tout au mieux.

Dernier point à garder en mémoire : Le processeur est un 8bits, il n'a pas d'unité de calculs flottants, tout se fait en logiciel et est donc lent.

Avant d'avoir le contenu des fonctions citées plus haut pas possible d'en dire plus.

PhM

Edit : Il n'y a pas de type double supporté pour arduino, ce type est silencieusement changé pour un float.

[Pascal]

Quelques remarques :

- La boucle utilise une technique dite "de polling", qui est relativement inefficace et surtout souvent inutilement consommatrice de ressources.

Si PDScan() et/ou ReadData(); provoque l'attente jusqu'à réception du paquet attendu, le processeur est immobilisé jusqu'à réception du paquet et ne peut rien faire pendant l'attente. Si plusieurs valeurs sont attendues et que les paquets n'arrivent pas exactement dans l'ordre programmé, certaines réceptions seront ignorées jusqu'à arrivée du paquet attendu, ce qui va augmenter sensiblement le temps de réaction.

Si PDScan() et/ou ReadData() retourne immédiatement, même s'il n'y a pas de données valide reçue, alors toute la partie qui suit n'a pas de raison d'être traitée...

la structure générale devrait être

si (donnée X reçue) alors
traitement donnée X;

si (donnée Y reçue)alors
traitement donnée Y;


Si la condition "donnée ... recue " le peut, l'idéal serait qu'elle soit traiitée entièrement par interruption. Si sont raitement est trop long, il faudrait que la detection soit faite par interruption et que seul un flag soit passé à la boucle d'attente du programme principal pour demander le traitement, ce qui assure alors une réception immédiate tout en laissant le maximum de ressources à l'application.




Un peu accessoirement, il est toujours plus rapide de multiplier que de diviser. Donc, lorsque que le diviseur est connu préférer :
resultat = A * inverse-du-diviseur
plutôt que
resultat = A / diviseur.

Donc, ici, remplacer :
S_F = GS_F / 0.514;
par
S_F = GS_F * 1.9455; // = GS_F / 0.514


Note : je ne connais pas (pas encore) l'Arduino, mais la programmation embarquée est ma spécialité. Je pense pouvoir dire sans trop me risquer que la puissance de calcul du moindre processeur est ahurissante et que vous ne devriez pas avoir de délais pour un calcul aussi simple, même en utilisant (mal) un format flottant. Dans le cas contraire, la structure générale du programme est à revoir !
Il faudrait toutefois vérifier que l'architecture du "noyau" proposé pour l'arduino (plus ou moins cachée par le compilateur et les "include") est compatible avec votre besoin et n'est pas une horreur. Par exemple, un programme ne devrait jamais (sauf cas très spéciaux) comporter des boucles d'attentes "vides". De telles boucles doivent êtres remplacée par une programmation évènementielle.

[PhM]

Ajoute ces modifications ( je n'ai pas tout recopié) :

void setup()
{
  [COLOR=#ff0000]Serial.begin(9600);[/COLOR]

  XPDStart (XPR, XPW, IPx, Ard_MAC);    //==! init XPlaneData
  DataGet(0, 2);                // Ground Speed position in OUT.cfg file
  DataGet(0, 2);                // Ground Speed position in OUT.cfg file
  myGLCD.InitLCD(LANDSCAPE);        //==! init LCD
  myGLCD.clrScr();
  myGLCD.setFont(BigFont);        //==! init LCD font

  myGLCD.print("IAS: ", 25, 20);        // text print on LCD  
  myGLCD.print("GS: ", 25, 50);        // text print on LCD
  myGLCD.print("LAT: ", 25, 80);        // text print on LCD  
  myGLCD.print("LONG: ", 25, 110);    // text print on LCD
}
void loop()
{
  [COLOR=#ff0000]unsigned long Start = millis();[/COLOR]

  // ------ GET DATA FROM XPLANE AND PRINT THEM ON LCD ---------
  XPDScan();   // - must be to read data from X-Plane
  [COLOR=#ff0000]unsigned long Scan = millis();[/COLOR]

  IAS = ReadData ( 0, 1);        // get data from Xplane (IAS speed)
  myGLCD.printNumF(IAS, 1, 50, 20);    // print values on LCD 
  [COLOR=#ff0000]unsigned long Ias = millis();[/COLOR]

  GS_F = ReadData ( 0, 2 );        // get data from Xplane (ground speed)
  GS_F = GS_F/0.514;             // conversion to knots
  myGLCD.printNumF(GS_F, 1, 50, 50);    // print values on LCD 
  [COLOR=#ff0000]unsigned long Gspd = millis();[/COLOR]
       
  IRS_LAT = ReadData ( 0, 3);        // get data from Xplane (LAT Position)
  myGLCD.printNumF(IRS_LAT, 3, 50, 80);    // print values on LCD 
  [COLOR=#ff0000]unsigned long Lat = millis();[/COLOR]

  IRS_LONG = ReadData ( 0, 4);        // get data from Xplane (LONG Position)
  myGLCD.printNumF(IRS_LONG, 3, 50, 110);    // print values on LCD 
  [COLOR=#ff0000]unsigned long Long = millis();[/COLOR]

[COLOR=#ff0000] Serial.print(Scan - Start);
 Serial.print(" ");
 Serial.print(Ias - Scan);
 Serial.print(" ");
 Serial.print(Gspd - Ias);
 Serial.print(" ");
 Serial.print(Lat - Gspd);
 Serial.print(" ");
 Serial.print(Lon - Lat);
 Serial.print("\n");
[/COLOR]}

Regarde ce qui sort dans le moniteur série et tu sauras le temps passé pour chaque étape. Une fois que tu auras ces résultats tu pourras décider quoi faire ensuite.

PhM

[avia767]

merci pour vos reponses, j'avoue que mon code n'est pas top que je ne suis pas expert comme vous,
j'ai essayer quelques optimisation, mais le resultat est le meme
d'abors les resultas d'execusion par PhM;
Serial.print(Scan - Start); [ 0 ~ 2 ] milisecondes
Serial.print(Ias - Scan); [ 11 ~ 14 ] milisecondes // quand j’accélère, le temps de traitements [ 13 ~ 17 ]
Serial.print(Gspd - Ias); [ 11 ~ 14 ] milisecondes // quand j’accélère, le temps de traitements [ 13 ~ 17 ]
Serial.print(Lat - Gspd); [ 19 ~ 21 ] milisecondes // quand j’accélère, aucun changement, le temps de traitement reste le même.
Serial.print(Lon - Lat); [ 19 ~ 21 ] milisecondes // quand j’accélère, aucun changement, le temps de traitement reste le même.

[avia767]

optimisation du code
-----------------------
1- j'ai essayer de définir une mise a jour de mes paramètres par interruption dans une fonction mais ca ne marche pas.

les exemples du net c'est des interruption avec hardware, c'est n'est pas mon cas

avez vous des suggestions ?

[avia767]

J'ai essayé avec le code suivant, résultat non concluent, c'est toujours long !!!

avez vous des idées ?

float IAS0.0;
float GS=0.0;

int UDP_IAS_Event_Flag = 0;
int UDP_GS_Event_Flag = 0;
int UDP_LAT_Event_Flag = 0;
int UDP_LONG_Event_Flag = 0;

void setup()
{

  XPDStart (XPR, XPW, IPx, Ard_MAC);     //==! init XPlaneData

  //------ screen setup ----------
  myGLCD.InitLCD(LANDSCAPE);
  myGLCD.clrScr();
  myGLCD.setFont(BigFont);
  
  //------ Print Screen ----------
  myGLCD.print("IAS: ", 25, 20);
  myGLCD.print("GS: ", 25, 50);
  myGLCD.print("IRU_LAT: ", 25, 80);
  myGLCD.print("IRU_LONG: ", 25, 110);
  
  
}

void loop()
{
   
          
	  // ------ GET DATA FROM XPLANE ---------
          XPDScan();   // - must be to read data from X-Plane
                                       
                float IAS = GetData (1);            //read received data IAS
		float GS_F = GetData (2);           //read received data GS
		float IRU_LAT = GetData (3);        //read received data LAT
		float IRU_LONG = GetData (4);       //read received data LONG

 
                  if (UDP_IAS_Event_Flag = 1) 
                  {
                    myGLCD.printNumF(IAS, 1,  200, 20);
		    UDP_IAS_Event_Flag = 0;  //reset the Flag for the next iteration
                  }
              
              
                       
                
                  if (UDP_GS_Event_Flag = 1)
                  {
                    GS_F = GS_F*GS_conv_factor;
                    myGLCD.printNumF(GS_F, 1, 200, 50);
                    UDP_GS_Event_Flag = 0;
                  }
             
             
  ....ext
              
 
} // END loop

void MaFonctionTrigeur()
   {
	 if (IAS)
	 {
	  UDP_IAS_Event_Flag = 1;
	 }
         if (GS)
	 {
	  UDP_GS_Event_Flag = 1;
	 }

         ....ect
   }

[Pascal]

Je trouve ces temps très longs. Pour l'affichage sur un module LCD courant (par exemple 4x16 ou 4x20), l'envoi d'un caratère ou d'un déplacement de curseur se compte en microsecondes, la commande la plus longue (effacement de tout l'écran) nécessitant environ 1 ms.

De même, les conversions valeurs -> chaines devraient se compter en dizaine de µs, pas en ms.

Est-il possible d'avoir une idée du contenu des deux routines ReadData() et myGLCD.printNumF() ? (éventuelllement via lien une lib téléchargeable ?)

Ou sinon d'avoir leur durée respective d'exécution, par exemple pour la récupération et affichage de "lon - lat" avec la même technique de chronométrage ?

[Pascal]

Complément...

Je viens de trouver ce site, d'où pourrait venir la librairie de dialogue avec X-Plane : http://arduino.svglobe.com/lcdout.html

Si le module LCD est câblé comme mentionné sur sette page, je suspecte très fortement le mode d'utilisation de l'affichage LCD d'être responsable des délais.
En effet, la ligne "R/W" n'est pas utilisée, ce qui ne permet pas à l'arduino de savoir si le module LCD est prêt. La seule solution consiste alors d'ajouter un délai (> 1 ms) assurant que le traitement de la commande précédente est fini, soit 1 ms (minimum) par caractère affiché + 1 ms par commande (positionnement curseur)...

En outre, les transferts avec le module LCD se font en mode 4 bits, soit 2 écritures pour chaque octet transféré, au lieu d'une seule. C'est dommage. L'arduino ne dispose pas d'un port 8 bit complet pour les échanges de données avec l'afficheur en mode 8b et d'une pin qui pourrait être utilisée pour gérer correctement la ligne R/W ?

[PhM]

Deuxième série de profiling :

void setup()
{
  [COLOR=#ff0000]Serial.begin(9600);[/COLOR]

  XPDStart (XPR, XPW, IPx, Ard_MAC);    //==! init XPlaneData
  DataGet(0, 2);                // Ground Speed position in OUT.cfg file
  DataGet(0, 2);                // Ground Speed position in OUT.cfg file
  myGLCD.InitLCD(LANDSCAPE);        //==! init LCD
  myGLCD.clrScr();
  myGLCD.setFont(BigFont);        //==! init LCD font

  myGLCD.print("IAS: ", 25, 20);        // text print on LCD  
  myGLCD.print("GS: ", 25, 50);        // text print on LCD
  myGLCD.print("LAT: ", 25, 80);        // text print on LCD  
  myGLCD.print("LONG: ", 25, 110);    // text print on LCD
}
void loop()
{
  [COLOR=#ff0000]unsigned long Start = millis();[/COLOR]

  // ------ GET DATA FROM XPLANE AND PRINT THEM ON LCD ---------
  XPDScan();   // - must be to read data from X-Plane
  [COLOR=#ff0000]unsigned long Scan = millis();[/COLOR]

  IAS = ReadData ( 0, 1);        // get data from Xplane (IAS speed)
[COLOR=#ff0000]//[/COLOR]  myGLCD.printNumF(IAS, 1, 50, 20);    // print values on LCD 
  [COLOR=#ff0000]unsigned long Ias = millis();[/COLOR]

  GS_F = ReadData ( 0, 2 );        // get data from Xplane (ground speed)
  GS_F = GS_F/0.514;             // conversion to knots
[COLOR=#ff0000]//[/COLOR]  myGLCD.printNumF(GS_F, 1, 50, 50);    // print values on LCD 
  [COLOR=#ff0000]unsigned long Gspd = millis();[/COLOR]
       
  IRS_LAT = ReadData ( 0, 3);        // get data from Xplane (LAT Position)
[COLOR=#ff0000]//[/COLOR]  myGLCD.printNumF(IRS_LAT, 3, 50, 80);    // print values on LCD 
  [COLOR=#ff0000]unsigned long Lat = millis();[/COLOR]

  IRS_LONG = ReadData ( 0, 4);        // get data from Xplane (LONG Position)
[COLOR=#ff0000]//[/COLOR]  myGLCD.printNumF(IRS_LONG, 3, 50, 110);    // print values on LCD 
  [COLOR=#ff0000]unsigned long Long = millis();[/COLOR]

[COLOR=#ff0000] Serial.print(Scan - Start);
 Serial.print(" ");
 Serial.print(Ias - Scan);
 Serial.print(" ");
 Serial.print(Gspd - Ias);
 Serial.print(" ");
 Serial.print(Lat - Gspd);
 Serial.print(" ");
 Serial.print(Lon - Lat);
 Serial.print("\n");
[/COLOR]}

J'ai vu une horreur que je suppose être la source du problème : il me semble que les caractères sont tracés pixel par pixel . Sous réserve que le UTFT que j'ai trouvé soit le même.

Pour le traitement par interruptions, si tu n'as jamais pratiqué laisse tomber pour l'instant, ça demande de la pratique sinon arrachage de cheveux jusqu'à la calvitie très probable.

Où est-ce que je peux trouver le schéma de câblage de ton LCD sur l'arduino ? Le circuit de contrôle semble être celui-là.

PhM

[avia767]

PhM le deuxieme teste montre clairement que le temps d’exécution de l'affichage graphique par la ligne de code suivante prends un temps de calcule important

myGLCD.printNumF(IAS, 1,  200, 20);

cette commande prends entre 11 a 20ms, j'ai essayé avec un entier ça donne le même résultat.
et en mettant ces lignes en commentaire, je re-descend a <0 ms.

alors quelles sont les causes ?

1) Câblage entre l'Arduino Mega et l’écran TFT LCD 3.2" avec la librairie (SSD1289)
Test : tout a l'aire bien cablé, voici les pin utilisés :


2) Réseau, peut etre puisque j'utilise une carte Ethernet avec l'Arduino
Test : j'ai fais des ping PC -> Arduino, résultat du ping < 1ms
=> ce n'est pas le réseau !

3) Code.

C'est cette partie que je mets le plus en doute, puisque je ne fait aucun traitement sur les packets UDP reçu ??

4) Hardware : l’écran en particulier, taille de la mémoire en cause ??

A vous de voir.

[PhM]

...

myGLCD.printNumF(IAS, 1,  200, 20);

Cette commande prends entre 11 a 20ms, j'ai essayé avec un entier ça donne le même résultat.

Ca semble être ce que j'ai trouvé.

4) Hardware : l’écran en particulier, taille de la mémoire en cause ??

Quel écran utilises-tu ? Où trouver les infos techniques ?

Où as-tu trouvé UTFT ? Histoire d'être sûr que j'ai le même.

PhM

Edit :

Un lien qui confirme mon intuition, la vidéo parle d'elle même, et les sources modifiées. Reste à vérifier si c'est compatible pour toutes les versions d'arduino.

[Pascal]

Bonjour,

Pour compléter ce que dit PhM:

Vu le nom de la capture d'écran (TFT LCD 3-2 SSD1289 ARDUINO MEGA PIN ALLOCATION.jpg), le module est vraisemblablement un module graphique 3.2" doté d'un contrôleur SSD1289 dont la datasheet est disponible ici : Download Link.

Ce contrôleur n'embarque pas de générateur de police -> l'arduino doit effectivement tracer les textes pixel par pixel. Comme en outre l'Arduino n'expose pas les lignes "processeur", les signaux CS/RS/WR[/RD] doivent être émulés depuis des ports ce qui ralentit beaucoup chaque écriture à destination du module LCD (au moins 7x plus long qu'une écriture par un processeur 16b. doté d'un décodage d'adresse).

Je vois aussi que la ligne LCD_RD (/Read) n'est pas utilisée. Il est donc impossible d'utiliser les commandes "Status Read" et "RAM data read" (voir page 18 du datasheet) ce qui oblige l'arduino à conserver en mémoire la copie du contenu de la ram de l'afficheur car il ne peut pas la relire. Cela peut ne pas être trop pénalisant si l'arduino dispose d'assez de mémoire et selon la façon dont le LCD est géré, comme assez pénalisant (double écriture en ram "locale" et "distante").

Bref, il me semble qu'il y a déjà au niveau hardware un compromis de simplicité de mise en oeuvre au détriment de la vitesse d'accès.
Il faut donc d'autant plus que la partie logicielle soit vraiment bien optimisée.