Arduino, AVR: Le topic des canards électroniques

[Papeyo]

C'est mal, j'aurais laissé Malakit tester un peu en conditions réelles avant de lui donner d'autres solutions :]

J'ai pas lu tout le programme, mais il faut toujours que l'ensemble des actions (hormis le capteur de niveau) soit dans les conditions de securitéActivée, sinon cette condition ne protège pas ton système.
La logique du programme, c'est celle que j'ai mise plus haut, pas besoin de complexifier inutilement. Dans un premier temps, je conseillerais de ne pas gérer l'affichage LCD pour plus de lisibilité.

[LaVaBo]

Une question pas forcément facile, d'autant que j'ai du mal à expliquer le truc avec mes compétences limitées en électronique:

j'ai un arduino Uno, un capteur baromètre/thermomètre (qui indique aussi l'alttitude) et un afficheur 7 segments avec 4 chiffres.

Le capteur et l'affichage de 4 chiffres sur le 7 segments fonctionnent bien indépendamment l'un de l'autre. Mais mon but est d'afficher l'altitude mesurée sur l'afficheur. Et c'est là que le bat blesse, parce que prendre la mesure de l'altitude prend un poil moins de 400ms (~380ms), ce qui donne un délai d'autant entre deux loops.

Or ça décale l'affichage des segments d'autant, et donc je vois chaque segment s'allumer à la suite (un segment sur chacun des 4 chiffres), et jamais des chiffres complets. C'est joli, ça rappelle le snake du nokia 3310, mais ça ne marche pas.
Si je comprends bien, le problème est que mon afficheur 7 segments est multiplexé, et que la fonction de rafraîchissement de la librairie que j'utilise (SevSeg) doit tourner au moins 8 fois/seconde pour que l'affichage ait l'air fixe. Idéalement un peu plus.


Mon loop() est super simple :

Lire l'altitude
Convertir le float de l'altitude en int
Envoyer l'int sur le 7 segments
Rafraîchir l'afficheur

Un loop qui ne ferait qu'afficher une constante sur l'afficheur fonctionne bien tant que je ne lis pas l'altitude, par contre dès que je lis l'altitude, même afficher une constante sur l'afficheur ne marche plus, ça repart en snake.


Une idée de modif software pour désynchroniser la lecture de l'altitude et l'affichage ? Ou je dois forcément changer le matériel ?


[edit]Pour plus de précisions, le code suivant :

void loop() {
    currT = millis();

    altitude = baro.getAltitude();
    int ialt = altitude;

    Serial.print("curr=");
    Serial.print(currT);
    Serial.println();
}

M'affiche les résultats suivants :

curr=391
curr=771
curr=1149
curr=1528
curr=1907
curr=2287
curr=2666
curr=3045
curr=3425
curr=3804
curr=4183
curr=4562
curr=4941
etc...

[Foksadure]

Je n'ai d'expérience qu'avec un LCD 16x2 et des données (MIDI) récupérées sur Serial à 31250 bauds, mais pour limiter l'effet de transition/rémanence entre les valeurs sur l'écran, c'est le rafraîchissement de l'affichage qui est exécuté à fréquence fixe dans le loop, et non pas à chaque fois que les valeurs changent.

Ceci avec la méthode BlinkWithoutDelay ce qui permet à l'Arduino de continuer à recevoir les valeurs des capteurs en parallèle et de les stocker dans des variables (si elles changent par rapport à la dernière mesure).

https://docs.arduino.cc/built-in-exa...kWithoutDelay/
https://docs.arduino.cc/language-ref...s/time/millis/
https://docs.arduino.cc/language-ref...s/time/micros/

Si tu tiens absolument à ce que l'afficheur soit mis à jour à chaque changement de valeur d'altitude, j'imagine qu'il faut jouer avec les interruptions.

[Papeyo]

Sans les libs, les references du matos et le code complet (voir le schema), cela risque d etre compliqué :
- le temps pour le module (au pif un BMP*80) est independant du temps arduino. Donc c'est à voir la librairie pour 1/ lancer une mesure 2/ recuperer une mesure au bout d'un temps T plutot que d'attendre le resultat.
- Je vois pas pourquoi il faut rafraichir le 7 segments
- Je vois pas pourquoi cela ferait un snake

[Cmos]

Je suis en train de devenir fou.

Ce message n'est pas une vraie demande d'aide c'est surtout que je tente la méthode du canard en plastique .

J'ai conçu une carte de contrôle moteur autour d'un ATmega328 pour ma porte de garage. Le contrôle se fait au choix par:

• un bouton
• un module WIFI de mon cru branché en TWI
• un Xbee en mode simplex via UART qui réceptionne le code de ma télécommande

Il y a aussi un affichage par TWI pour indiquer certains états de la porte et l'activation de certaines options. Tout fonctionne depuis environ 2 ans.

La Téléco Xbee aussi mais mal car c'était du bricolage pour dépanner. Trop grosse, avec une batterie Lipo en laquelle je n'ai aucune confiance d'un point de vue sécurité. Le code de ma carte qui gère la réception Xbee n'était pas très bien pensé et il arrivait d'avoir des doubles activations (car la téléco envoyait plusieurs fois un unique octet). En conséquence j'ai vite abandonné son utilisation alors qu'a l'usage c'est le moyen le plus pratique pour moi.


Récemment j'ai décidé de refaire la télécommande. J'ai fini par aboutir à un produit fiable en lequel j'ai confiance (je peux donc la laisser trainer dans ma voiture en été sans craindre un incendie), tout petit et totalement sûr puis qu'elle s'alimente par une pile bouton. Cette fois-ci est envoyé une trame plus élaborée avec checksum et tout le confort moderne.
J'ai réalisé la fonction de réception qui traite la trame reçue sur un arduino. Tout fonctionne à ce stade et j'en ai profité pour tester la fiabilité dans la durée. Tout est au poil.

J'ai ensuite peuplé un PCB en rab de ma "vraie" carte avec juste le nécessaire pour faire un test en situation (régulateur, ATmega+reset+quartz, Xbee, module WIFI et affichage), puis j'ai incorporé la fonction de réception à mon programme. Je test un peu tout, 1fois, 2 fois, 3fois, X fois, tout fonctionne sans problème tout le temps.

Donc, je mets à jour le programme sur la carte qui contrôle ma porte et, vous le devinez, ça ne marche pas! Enfin si mais pas la partie téléco Xbee.


Je démonte la carte du garage et l'embarque pour tester des trucs:

1. Le Xbee récepteur reçoit bien la transmission (il y a des leds sur la platine d'adaptation).
2. La transmission est bien acheminée au ATmega (testé avec un oscilloscope branché directement sur la patte du ATmega).
3. La carte Wifi déconnectée elle n'interfère donc pas.
4. L'affichage déconnecté, il n'interfère pas non plus du coup.
5. Le moteur n'étant contrôlé qu'après une bonne réception, il n'a rien à voir dans l'histoire.
6. L'alim est cette fois la même que la carte de test, ce n'est donc pas ça non plus qui interfère.

Même carte, même programme et ça ne marche toujours pas, truc de dingue.

J'ajoute une fonction qui écrit sur un terminal le contenu du buffer qui contient la trame reçue. Que-dalle, la fonction n'est pas appelé ce qui veut dire que, par un truc inexplicable qui ne se passe que sur la "vraie" carte, l'UART ne voit pas passer de signal alors qu'il est bien acheminé jusqu'à la bonne broche. J'ai donc interverti l'ATmega de la carte de test avec celui de la "vraie" carte, au cas où, et pareil.

[Foksadure]

Je démonte la carte du garage et l'embarque pour tester des trucs:

1. Le Xbee récepteur reçoit bien la transmission (il y a des leds sur la platine d'adaptation).
2. La transmission est bien acheminée au ATmega (testé avec un oscilloscope branché directement sur la patte du ATmega).

Ce ne serait pas typiquement un cas d'usage pour un analyseur logique, même cheapos ?

[Cmos]

Ce ne serait pas typiquement un cas d'usage pour un analyseur logique, même cheapos ?

Wep, mon oscilloscope à des fonctions de décodage, c'est ce que j'ai utilisé avec déclenchement en mode single avec la sonde branché directement sur la patte du ATmega et je reçois bien les octets mais, pour une raison inconnue, le ATmega ne les lis pas sur la carte finale (mais sur la carte d'essai partiellement peuplée, oui).

[Foksadure]

Sorti du MIDI, je n'y connais pas grand chose, mais tu es sûr que le signal qui arrive à l'UART est exactement le même entre le PCB de test et le définitif ?

Fréquence, amplitude, voltage, polarité, synchrone/asynchrone, que sais-je ?

Le fait que - heureusement - les deux ATMega faisant tourner le même code ne sachent pas l'interpréter plaide en la faveur d'un signal qui ne correspond pas à la programmation.

[Helix]

J'écris peut-être une bétise, mais peut-être checker les fusibles de la carte ? Tu as peut-être une config de watchdog ou de reset qui empêche ta fonction de réception d'être appelée ?

[Gnafron]

Je plussoie abondamment la recommandation d'un analyseur logique, ça m'a sorti le cul des ronces un paquet de fois.
Bon le matos Saleae est excellent mais pas dans la même gamme de prix qu'un arduino.

Autre possibilité : une soudure sèche sur une des pattes : tu vois le signal à l'oscillo mais il n'arrive pas au circuit.

[Cmos]

Eurêka!

Hier soir je me résous à regarder la doc technique du micro contrôleur au chapitre UART à la recherche d'indices et le schéma bloc me fait tiquer (sur la partie générateur d'horloge) et je cherche du côté de l'oscillateur externe me disant que possiblement, les capas de découplage sont peut être en cause, que le signal d'horloge est crado et que donc point de décodage possible.

Je dessoude, et en replaçant les neuves, je lis "16000" sur le quartz...

Pendant tout ce temps j'ai compilé un programme pour un quartz 20Mhz et je le fait tourner sur un 16 forcément que ça marche pas
Et donc après remplacement tout marche au poil. (Ceci-dit c'est fou que les autres protocoles de communication utilisés sur la carte n'en aient pas pâti, ne me mettant donc pas la puce à l'oreille plus tôt).
Je crois me souvenir qu'au tout début de ce projet, j'avais fait des expérimentations avec un quartz de 16Mhz en rapport avec le PWM pour le moteur. Je pense l'avoir soudé en lieu et place d'un 20Mhz sur la carte par étourderie.

[Papeyo]

Encore une victoire de canard

[Foksadure]

Juste pour info, Arduino vient de sortir un kit didactique « Plug and Make Kit » articulé autour d'un Uno R4 Wi-Fi, une platine, quelques Modulino® utilitaires (capteurs, actionneurs, leds) reliés via I²C, le tout soutenu par une application Android/Cloud pour l'apprentissage et la visualisation :

https://www.elektormagazine.fr/news/...-plug-and-make

https://store.arduino.cc/en-fr/pages/plug-and-make-kit



La bibliothèque dédiée, qui j'imagine va s'étendre au rythme de la disponibilité de nouveaux Modulino® :

https://github.com/arduino-libraries/Modulino

Pour ~90 euroballes, ça va faire des heureux à Noël.

Shameless plug : j'ai un Adafruit Metro M7 microSD NXP iMX RT1011 (CircuitPython ou prog C++ native NXP) à vendre, en lot avec un Dollatek R3 ESP32, inutilisés. Si un canard est intéressé, MP...

[vectra]

Coucou les coins,

Mon climatiseur a fini par rendre l'âme: cet été l'a achevé je crois
Je l'ai largement démonté à la recherche d'un coupable facile, vu que j'ai un affichage nawak sur le LCD de contrôle. Je ne vois rien de débranché ou dégradé, et à première vue les condensateurs n'ont pas une mauvaise tête.
J'ai déssoudé les condos sur la carte où se trouve le transformateur et j'ai mesuré leur capacitance: on tombe sur les valeurs inscrites, avec -10% pour le plus gros d'entre eux (900 micro-f pour 1 milli d'annoncé). De ce que j'ai pu lire, ce n'est pas assez pour expliquer une panne, non?

Je peux peut-être utiliser d'autres protocoles pour vérifier mes condos, ou bien ils sont tous bons?

Il y a aussi un énorme condensateur en alu (450V 25 micro-f) mais j'ai un peu la trouille d'y toucher; je l'ai mis sous plastique pour ne pas me faire peur.

Je suis à la recherche d'une panne un peu facile à réparer, mais je pense que je n'aurai pas les compétences pour tester tous les composants des deux cartes de contrôle visibles, à supposer que ce soit bien elles qui déconnent (la carte de commande avec le LCD et les boutons poussoirs et 3 microprocesseurs, reliée à la carte principale avec le transfo, les condos, le maousse condo, et d'où partent des fils vers tous les composants de la clim).

[Papeyo]

Les condos sont donnés à 10% 20%
De manière general il faut les decharger à chaque fois avant manipulation sinon ...

Mets une photo du PCB Hig Res ? Il y a peut etre une piste HS ou une connerie comme cela. Sinon cela peut etre les controleurs qui ont grillés.

Une recherche avec le modele et la panne ne donne rien ?

[vectra]

Non, rien sur le net. Climatiseur Ruby ARC 3400. Tout est propre mais je posterai des tofs demain.

Par contre, je me suis renseigné sur comment décharger le gros condo et je m'y suis mis. Aucun voltage n'est apparu sur le multimètre alors que j'avais branché la machine moins de 24h auparavant sur secteur (test court).
J'ai mesuré la capacité: 24,20 uF, donc tout bon. Par contre, le condensateur a une résistance infinie à ses bornes, alors que les autres que j'ai déssoudés ont une résistance faible.
J'y connais pas grand chose mais ça veut pas dire qu'il est niqué?

Pour un visuel, on parle de ce genre de bestiau, mais avec seulement deux pôles:
https://www.youtube.com/watch?v=45oZXnClMD0

[Arthropode]

C'est l'inverse, normalement un condensateur parfait a une résistance infinie. C'est donc étrange que tu mesures une résistance faible sur tes condensateurs. C'est quel ordre de grandeur de résistance ?
Mais si ils sont tous dans le même cas, ce serait surprenant qu'ils aient tous claqué.

[vectra]

Disons que pour les petits condos, j'ai eu du mal à ne pas toucher les pinces croco. Effectivement leur résistance était infinie au départ, réelle ensuite.
J'ai tenté de shunter le gros pareil, mais lui est resté à l'infini.

[vectra]

J'ai réussi à tester les condos correctement: ils ont tous la bonne capacité et ils grimpent tous en résistance correctement vers l'infini ou en M-ohms en tous cas.
Je m'y étais mal pris, avant.

Donc, du coup, tous les condos qui pouvaient expliquer la panne ont été dessoudés pour rien et fonctionnent a priori parfaitement
Une clim à la benne, du coup?

[Papeyo]

Met une photo hi res des deux faces ?