Je finalise tout juste mon premier projet Arduino. Durant toute la phase de développement et de test, j'avais mis en place un certain nombre de "serial.print" pour suivre mes variables et afficher dans le terminal certains résultats qui sont enregistrés dans un fichier log sur carte SD.
Tout fonctionne parfaitement maintenant et je souhaite donc débrancher la liaison serie qui n'a pas vocation à être connectée en marche normale.
Et c'est là que je me suis aperçu qu'en l'absence de la liaison serie, le programme reste bloqué sans doute par ce que l'instruction serial.print ne peut pas s'exécuter.
Voici enfin ma question : existe-il un moyen (autre que commenter tous mes "serial.print") pour que le programme puisse suivre sont court en ignorant l'erreur si la liaison serie n'est pas connectée ?
En vous remerciant par avance pour vos avis éclairés.
Bonjour, le plus simple pour séparer l'affichage de "développement" du reste du programme est de mettre une condition if(D_BUG) { } ce qui ne doit pas être utilisé dans le projet final.. Quand on test on déclare D_BUG=true, pour le final on remplace par D_BUG=false...
Certaines librairie utilise une variable debug, par précaution j'en change l'orthographe !
Cela dit, normalement l'instruction serial.print() n'est pas bloquante, sans ton code difficile de dire ce qui coince...
c'est bizarre que ton programme se bloque, tu ne fais que écrire sur le port série, branché ou pas il est toujours présent sur la carte arduino donc il écrit dans le vide il ne dois pas bloquer le programme.
le plus simple pour séparer l'affichage de "développement" du reste du programme est de mettre une condition
Code: [Select]
if(D_BUG) { }
ce qui ne doit pas être utilisé dans le projet final.. Quand on test on déclare D_BUG=true, pour le final on remplace par D_BUG=false...
Certaines librairie utilise une variable debug, par précaution j'en change l'orthographe !
C'est pour celà qu'on utilise plutôt les directives pré-processeur :
c'est bizarre que ton programme se bloque, tu ne fais que écrire sur le port série, branché ou pas il est toujours présent sur la carte arduino donc il écrit dans le vide il ne dois pas bloquer le programme.
Il se peut que j'ai mal interprété ce qui s'est passé. J'ai pensé que c'était la raison du blocage et de fait j'ai donc commenté tous les serial.print. Après quoi j'ai naturellement recompilé et Uploadé le sketch, ce qui évidement provoque un Reset. Et c'est peut être le Reset qui a provoqué le déblocage.
Je vais refaire des essais ce soir...
e plus simple pour séparer l'affichage de "développement" du reste du programme est de mettre une condition
Code: [Select]
if(D_BUG) { }
ce qui ne doit pas être utilisé dans le projet final.. Quand on test on déclare D_BUG=true, pour le final on remplace par D_BUG=false...
Certaines librairie utilise une variable debug, par précaution j'en change l'orthographe !
Merci en tout cas pour l'astuce de la variable D_bug. Je penserai à l'utiliser dans mes prochains projets.
B@tto:
Avec des "simples" if() c'est compilé et donc bien dans le code final.
oui, avec une "simple" variable... j'ai oublié "const" : en utilisant const boolean D_BUG = false; j'ai l'impression que le compilateur "suprime" ce qui ne sert pas :
// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin 13 as an output.
pinMode(13, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(13, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(13, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}
const boolean D_BUG = false;
// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin 13 as an output.
pinMode(13, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(13, HIGH); // turn the LED on (HIGH is the voltage level)
if(D_BUG)
{
delay(1000); // wait for a second
}
delay(1000); // wait for a second
digitalWrite(13, LOW); // turn the LED off by making the voltage LOW
if(D_BUG)
{
delay(1000); // wait for a second
}
delay(1000); // wait for a second
}
fablath:
Les 2 codes blink ci dessus font 4692 octes
Donc c'est bien ce que dit
const sur Arduino ne change rien, mise à par le fait que la variable est verrouillée en lecture seule, mais elle est quand même placée en RAM (d'où le fait qu'ici aussi l'utilisation de #define est généralement plus adapté).
Sur Energia c'est mieux foutu, les const sont placés en flash.
Que neni, mon bon monsieur.
Je m'inscris en faux face à cette affirmation
Une variable simple déclarée en const n'est utilisée qu'au moment de la compilation.
Elle n'est pas présente dans le code compilé, où elle est simplement remplacée par sa valeur dans le code exécutable.
Il n'y a aucune allocation en RAM : ce n'est pas une variable globale.
Seule exception : les tableaux const, comme par exemple les chaînes de caractères. Pour eux, l'utilisation de PROGMEM permet de libérer la RAM de leur empreinte.
Je suis sûr et certain de mon propos, car maintes fois vérifié chez moi sur Arduino.
Perso, je n'utilise d'ailleurs jamais de #define pour définir la valeur d'une variable simple, car cela empêche le compilateur de prendre en compte le type de la variable, sa portée, etc.
Unconst int pin_bouton = 5; est bien plus précis qu'un#define pin_bouton 5
Les deux sources de notre ami donnent le même code compilé car :
il définit une variable const bool toto = false;
il enchaîne par if (toto)
Et là, le compilo s'aperçoit que la condition du if ne peut jamais être vérifiée, donc il dégage cette portion de code mort.
Pour revenir au sujet principal "Suppression des Serial.print de mise au point" :
Normalement (sur presque toutes les cartes arduino), le maintien des Serial.print() alors qu'il n'y a plus de terminal relié, n'est pas gênant.
Les enlever a plusieurs impacts qui peuvent révéler des failles du programme.
Disons que les anomalies qui peuvent apparaître à ce moment là étaient latentes mais sans effet, car masquées par la présence des print().
Il n'y a plus de temps perdu à envoyer des données sur la liaison série. Le reste du code s'exécute donc à une fréquence plus élevée.
Il y a plus de RAM disponible (chaînes de caractères) : cela change les adresses de certaines variables, et d'éventuels débordements mémoire qui étaient sans effet auparavant, peuvent être révélés.
Le plus simple et sûr, c'est de laisser les Serial.print s'ils ne gênent pas
Même enlevés, il faut pouvoir les remettre facilement
Ah bin pour le coup tu m'en apprend une belle ! Autant sur les const que son optimisation du code qui en découle.
Par contre pour en revenir au problème : c'est quelle Arduino ?? Parce que je soupçonne bien une leonardo, le blink compilé faisant chez moi ~1k et non ~4k
Hier soir, j'ai donc refait des essais et je me suis aperçu que j'avais effectivement mal interprété ce qui se passait.
J'ai dé-commenté dans mon code tous les serial.print et j'ai pu vérifier que le programme continue bien de tourner sans problème quand la liaison série est débranchée. Lors de mes essais précédent, j'ai cru que le code bloquait car le programme cessait d’écrire dans le fichier Log. Mais en réalité, le blocage venais précisément de la carte SD.
Depuis le début de ce projet, j'ai pris l'habitude (sans doute mauvaise...) de retirer la carte SD à chaud. Je précise que je le fais à un moment du programme où je sais que le fichier est fermé. Mais les essais que j'ai fait hier soir m'ont montré que lorsque je remets la carte dans le lecteur du Shield, le programme n'accède plus au fichier. Pour cela il suffit de faire un Reset, et ça repart.
