Problème de démarrage

International Français
1

Bonjour à tous...

Nouveau problème... A nouveau 1 pat en avant et 3 en arrière.
Tout allait bien, j'étais en train de debugger un bout de code, et là sans rien changer, ma carte arduino se remet à déconner.

Le téléversement depuis l'IDE semble OK (pas d'erreur) mais mon programme ne fonctionne pas, du moins plus.

C'est comme s'il ne démarrait pas !
Et quand j'ouvre la console, j'ai aucun log... qu'une ligne imbitable du style : =)?! []
Que des caractères spéciaux tout pourri...
J'ai redémarré mon PC, essayé tous les autres ports USB... désinstallé l'IDE et réinstallé la dernière version, rien n'y fait...

Quelqu'un aurait une idée ou aurait déjà eu ce type de problème ?

2

Ce qu'il y a d'étrange, c'est que je viens d'essayer de brancher un autre arduino et quand je le branche, la diode Tx clignote...
Et sur le mega c'est pas le cas...
La diode verte "ON" s'allume mais aucune des diodes L / Tx / Rx ne s'allume...
Quand je televerse, les 3 "scintillent", puis une fois que l'IDE me dit que le televersement est terminé, plus rien... Juste la diode verte "ON" reste allumée...

3

Bonsoir

Et quand j'ouvre la console, j'ai aucun log... qu'une ligne imbitable du style : =)?! []
Que des caractères spéciaux tout pourri...
J'ai redémarré mon PC, essayé tous les autres ports USB... désinstallé l'IDE et réinstallé la dernière version, rien n'y fait...

Quelqu'un aurait une idée ou aurait déjà eu ce type de problème ?

Je constate ce problème comportement à chaque fois que la vitesse du port série de mon sketch ne correspond pas à la vitesse du terminal série
Par exemple Serial.begin(9600) dans le code et 115200 bauds en bas à droite dans le terminal

4

Je regarderai mais il me semble que j'ai bien 9600 des deux côtés...
Cette différence devrait impacter seulement la sortie de textes sur la console via le port COM, non ?
Ça ne devrait pas empêcher la carte de démarrer de son côté ?!
Là rien ne démarre.
A moins que cela bloque tout.
Je vais vérifier et je vais essayer de faire démarrer la carte en autonomie, via une pile 9V...

5

Bon bah j'ai vérifié le baudrate, la vitesse est bien la même des deux côtés... J'ai essayé de la changer, pas d'amélioration.

Dans mon setup() j'avais mis une boucle du style :

while (!serial) {
// wait
}

Je l'ai aussi enlevé... Je me suis dit que s'il y avait un souci sur la liaison série, ça pouvait peut-être être impactant, mais pas d'amélioration non plus.

J'ai essayé de faire tourner le tout sans être câblé au PC par USB mais en autonomie via une pile 9V... tjrs rien.

Je sais à nouveau plus où ni quoi / comment orienter mes recherches.

Je dois recevoir une nouvelle carte arduino mega... Mais bon c'est pas la solution, si j'ai cramé celle que j'utilise actuellement sans comprendre pourquoi, je risque d'en faire de même sur l'autre...

M'enfin pour l'instant, à part tester sur une nouvelle carte ou tester un petit programme rapide sur ma carte Uno pour être sûr que le problème ne vient pas de mon environnement (Windows 10 + IDE + pilotes + USB) et que ça vient de ma carte mega actuelle, je vois pas trop quoi faire d'autre...

Ce qui est fou c'est que tout fonctionnait bien... Je debuggais, certes, un truc bizarre mais je vois pas en quoi ça peut être lié à ça !

6

quand il y a un truc étrange comme ça, une solution que j'emploie est de téléverser un des exemples arduino dans la carte "douteuse", par exemple blink. Ça permet de se faire tout de suite une idée sur l'origine du soucis : si la carte fonctionne comme attendu avec l'exemple officiel, alors c'est ton programme qui est faux. Si la carte ne fonctionne pas correctement, alors elle a probablement un soucis matériel

7

Oui, c'est ce que j'ai fait... Mais au final, j'ai repris ma carte avec mon programme en ré-décommantant les unes après les autres toutes les fonctions et tout refonctionne correctement...
Du coup, c'est un peu emmerdant d'avoir tout qui plante d'un coup sans comprendre... De passer une journée à tout retester pas à pas et qu'au final tout refonctionne de nouveau sans avoir compris ce qui s'est passé...
Ça fait déjà 2 fois...

8

sans voir le code, ni savoir ce qu'il est censé faire, comment veux tu de l'aide?
un débordement de mémoire sur une fonction par exemple.
un bug de la carte.
un mauvais contact.
etc...

en général, en électronique, ca fonctionne ou ca coince, pas une fois sur deux

9

Bah pourtant c'est bien le cas... Quand tu change rien ni au niveau électronique ni au niveau programme, que ça marche 4 fois d'affilé et qu'à la 5ème ça merde... Y a de quoi se poser des questions.
Mais effectivement, je penche plus pour un problème de type faux contact...
Après mettre le code, je veux bien, mais mon sketch est long et utilise une 10aine de librairie... C'est pas non plus évident de mettre tout ça en lien.
Ce qui me fait un peu peur, effectivement, et que je ne sais pas trop gérer en C/C++, c'est la gestion mémoire...

10

Une première action est de bien dimentionner les déclarations de variables.
Avec le compilateur avr-gcc un type int occupe 2 octets,Arduino a créé un type byte qui occupe un seul octet.
Il est préférable d'utiliser la définition int8_t , int16_t, int32_t qui est plus universelle.
D'ailleurs dans les fichiers arduino le type byte est défini comme étant un uint8_t .

Pour déclarer une pin ou toute variable dont tu sais qu'elle ne dépassera pas la valeur 255 en non signé ou sera compprise entre -127 et + 128 en signé il ne faut pas écrire :
int variable_surdimentionnée

mais il faut utiliser :
uint8_t variable_machin
ou
int8_t variable_truc

Les variables de service dont la valeur ne change pas doivent être déclarées constante (const).
Avec les avr il est possible d'écrire les variables en Flash au lieu de la Ram (voir PROGMEN).
Il faut éviter les variables globales dans la mesure du possible.
Une variable ne vit qu'à l'intérieur de son champs d'application, ainsi le compteur dans une boucle for nait à l'entrée dans la boucle et meurt à sa sortie libérant la place. Il vaut mieux éviter de les déclarer avant l'entrée dans la boucle et plutôt écrire :
for ( uint8_t i = 0; i...............);

Rien que cela devrait permettre une première optimisation basique.

Mais le compilateur réalise automatiquement des optimisations et ce ne sera peut être pas miraculeux.

Si ce n'est pas suffisant il existe d'autres méthodes plus savantes mais pour celà il faut le code et des aidants plus qualifiés que moi, ou lire des tutos de C/C++.

11

En parlant de mémoire, j'ai justement un truc étrange...
Quand je compile mon sketch, j'obtiens 2 lignes d'informations :

  • 1 ligne sur la taille du sketch en octets
  • 1 ligne sur le "volume" de variable globale vs le reste de mémoire disponible à l'allocation dynamique en cours d'exécution.

Concernant cette notion de "variable globale", je pensais que c'était un peu comme en Java que j'ai plus l'habitude d'utiliser et que ces variables étaient celles déclarées en tête de classe / sketch, visibles et utilisables par toutes les fonctions.
C'est pourtant la définition que j'ai pu trouver concernant arduino.

... Et pourtant, quelque chose m'échappe...

Dans mon sketch principal, j'ai une fonction dédiée au Bluetooth.
Cette fonction doit recevoir une "trame" de données par Bluetooth, la décoder et effectuer des traitements en fonction...
Mes trames sont par exemple "101:30&5" :

  • 101 correspondant à mon id de commande (par exemple modifier température).
  • et ce qui suit les : sont les données, ici 30&5 pouvant être 30°C le jour avec 5°C de variation la nuit.

Dans ma fonction j'ai donc un "gros" switch case sur l'id de commande, puis dans les différents case, je décode les trames de données qui n'ont pas forcément toutes le même format.

Pour décoder ces trames, la seule fonction que j'ai trouvé et réussi à utiliser et la fonction sscanf() que j'utilise par exemple comme cela :

char* data = '30&5';
char* pattern = '%d&%d';

int temp, var;

sscanf(data, pattern, &temp, &var);

updateParam(temp, var);

J'ai effectivement une variable globale de type enum me permettant d'avoir les ids de commande et de les utiliser dans mon switch case...

Les autres variables (data, pattern, temp, var...) pour chaque case sont déclarées en local au sein de la fonction !

Et mon souci... Quand je compile, j'obtiens un message du type "les variables globales occupent 76% de l'espace, problème potentiel de mémoire à l'exécution"...
Et si je commente tous le switch case, je descends à 50% de variables globales !!!

Du coup, j'ai testé en remplaçant le switch case par une bonne succession de if à l'ancienne (je sais qu'en Java, le switch est gourmand)... Et au final, idem avec les if.
Alors je vais essayer tout à l'heure en commentant juste le contenu des if, voire si ça change quelque chose et si c'est lié aux déclarations de variables et utilisation du sscanf à répétition mais dans ce cas, je comprends pas bien le message de compilation et la notion de variable globale !