Arduino

[PA5CAL]

Illustration :


-----

[swiip2]

Oulala, sa commence a devenir bizarre...
J'ai fais la mesure sur la broche 4 du LMV 358, j'ai bien du 0V.
Cependant j'ai fais une premiere mesure sur la broche 4 du LP2985, je trouve du 3.3V, logique.
Mais depuis je refais cette mesure et je trouve du 0V tout le temps, je ne comprend pas.

[swiip2]

Alors je te montre sur photo ce sera plus simple :
-En rouge, je releve du 3.3V,
-En noir je releve du 0V

[swiip2]

Je pense u'il y a donc un soucis avec cette pièce ?
arduinouno_r3_front.jpg

[PA5CAL]

Oulala, sa commence a devenir bizarre...
J'ai fais la mesure sur la broche 4 du LMV 358, j'ai bien du 0V.

Ce n'est pas bizarre. Trouver une tension non nulle aurait été significatif (on aurait pu conclure à un défaut d'alimentation situé au niveau du circuit imprimé), mais trouver une tension nulle reste compatible avec tous les autres types de pannes.

Cependant j'ai fais une premiere mesure sur la broche 4 du LP2985, je trouve du 3.3V, logique.
Mais depuis je refais cette mesure et je trouve du 0V tout le temps, je ne comprend pas.

J'imagine que tu veux parler de la broche 5 en haut à gauche (la broche 4 qui est en bas à gauche n'est connectée à rien). Si le régulateur chauffe trop, il finit par disjoncter thermiquement. Et s'il est en panne, cette panne peut aussi s'aggraver.


Tes pièces jointes ne sont pas encore validées...

[swiip2]

Je parle de la brooche en haut a droite du LP2985, je releve du 0V c'est normal ?

[PA5CAL]

Oups... je voulais dire à droite, pas à gauche.

En haut à droite de la puce à 5 pattes (broche 5), on devrait avoir 3,3V normalement.

[swiip2]

Justement j'ai du 0V, pourant sur la "pastille en mi chemin du circuit du LMV358 au LP2985 j'ai du 3v3, et sur la broche j'ai du 0V, donc le seul pb que je vois c'est le composant qui est sur le circuit entre ces deux composants

[swiip2]

Oui bah j'ai pas du 3.3 mais du 0 ^^

[PA5CAL]

Si tu trouves 0V au départ du 3,3V sur le régulateur puis 3,3V au milieu sur la pastille, c'est que sur le premier point la mesure est incorrecte, probablement à cause d'une oxydation du métal.

[swiip2]

Ah bah non, je retrouve du 3.3V, donc pu de soucis de ce côté la..

[PA5CAL]

Je pense u'il y a donc un soucis avec cette pièce ?

Ça reste encore à voir (plusieurs circuits peuvent être touchés). Mais compte tenu des symptômes (notamment la led qui ne s'éteint pas complètement) je pencherais déjà plutôt pour un problème avec le LMV358 (la puce à 8 pattes juste au-dessus).

[swiip2]

Mais pourtant ce n'est pas cette puce qui chauffe, c'est étrange.
Mais a quoi cela peut-il être du ? A un mauvais branchement ? Et c'est irrémédiable ?

[swiip2]

Et sinon si je vire le régulateur 3.3, étant donné que je n'utilise que du 5V, la carte fonctionnera a nouveau normalement ?
Maintenant que j'y pense, je crois avoir relié le +12V au 5V qq secondes sans faire exprès , sa peut etre du a sa ?

[PA5CAL]

Mais pourtant ce n'est pas cette puce qui chauffe, c'est étrange.

Le symptôme ne se manifeste pas forcément là où se situe le problème. Si tu roules en voiture avec les freins serrés, le moteur va chauffer, et pourtant ce n'est pas le moteur qui est en cause.

Rien ne dit que le régulateur n'a pas aussi un problème. En revanche ce qui est sûr, c'est que les amplificateurs du LMV358 ne fonctionnent pas comme attendu, notamment sur une partie qui ne concerne absolument pas le régulateur.

Mais a quoi cela peut-il être du ? A un mauvais branchement ? Et c'est irrémédiable ?

Pour les causes, on a déjà fait la liste plus haut (décharge électrostatique, court-circuit accidentel, défaut de fabrication, ...), et pour l'instant on ne peut en rester qu'aux suppositions (il est difficile de faire des diagnostics par correspondance).

En l'état, la carte est en panne, et nécessite une réparation (si on le fait soi-même) ou un remplacement (moins cher qu'une réparation par un professionel).

Et sinon si je vire le régulateur 3.3, étant donné que je n'utilise que du 5V, la carte fonctionnera a nouveau normalement ?

Non. Le 3,3V et un LMV358 en état de marche sont nécessaires pour alimenter correctement la carte à partir de la prise USB.

Maintenant que j'y pense, je crois avoir relié le +12V au 5V qq secondes sans faire exprès , sa peut etre du a sa ?

... Ah ...

Cette manipulation aurait pu endommager le régulateur 5V et les microcontrôleurs. Le symptôme de la LED qui ne s'éteint pas pourrait en découler, sans toutefois expliquer le reste (le régulateur 3,3V et les amplis auraient dû supporter cette erreur de manip).

Pourrais-tu vérifier que la sortie 13 de l'Arduino présente bien une tension de 0V lorsque la led est éteinte ?
NB: faire tourner un programme avec seulement :

void setup() {
  pinMode(13,OUTPUT);
  digitalRead(13,0);
}
void loop(){}

[swiip2]

Non, j'ai du 1.1V en sortie de la broche 13...
Mais comme je t'ai dit précedemment, la led ne s'éteint plus.

[PA5CAL]

Cela indique que la sortie 13 semble encore fonctionnelle, mais que l'ampli suiveur associé à la LED (partie gauche du LMV358 sur le schéma) ne fonctionne pas. Avec 1,1V à l'entrée de l'ampli, on devrait aussi avoir 1,1V à la sortie, et avec cette tension la LED devrait être éteinte.

Par ailleurs, le fait que la tension soit de 1,1V au lieu de 0V suggère que la sortie 13 absorbe un courant notable (≈30mA), ce qui rejoint le symptôme de montée en température du régulateur 3,3V qui est branché de la même manière sur l'autre amplificateur de la puce.

Pour moi, il y a 99% de chance (si l'on peut dire) que la panne provienne du LMV358.

[swiip2]

Je te fais confiance pour le coup car je n'y connais rien du tout la dedans.
Mais un composant de si petite taille n'est pas remplaçable, je veux dire avec un fer a souder ?

[PA5CAL]

Si, ça peut se faire. Il y a d'ailleurs des vidéos de démonstration sur YouTube. Mais ce n'est pas simple, et ça demande de la dextérité, de l'entraînement et une bonne vue.

Sinon, tu dis que l'Arduino n'est pas à toi, tu ferais mieux de le rapporter à ton prof en l'état, et il décidera de la meilleure suite à donner selon son point de vue. En effet, comme on ne sait pas si la carte a subi d'autres dommages, si vous n'avez pas le matériel et l'expérience nécessaires pour un dépannage dans les règles, un remplacement pur et simple de la carte serait beaucoup plus sûr.

Même en faisant bien attention, ce type de matériel est malheureusement appelé à tomber en panne parfois. Il faut se faire une raison.

[swiip2]

Même en faisant bien attention, ce type de matériel est malheureusement appelé à tomber en panne parfois. Il faut se faire une raison.

Oui et j'en ait fais les frais..
Je vais suivre ton conseil et attendre lundi pour rendre la carte a mon prof, le problème c'est que sa m'empêche de travailler maintenant:/

[PA5CAL]

le problème c'est que sa m'empêche de travailler maintenant:/

Je ne sais pas à quel stade de ton projet tu te trouves, mais ça pourrait être l'occasion de modifier un peu ta méthode de travail (i.e. privilégier la réflexion et l'anticipation devant l'expérimentation).

Dans l'industrie, on a souvent accès au matériel seulement dans les derniers jours ou les dernières heures du projet, après que tout a été conçu et développé. On se contente alors de vérifier, à l'aide d'un minimum de tests élaborés à l'avance, si tout fonctionne comme cela a été prévu.

[f6exb]

Tu peux tenter un émulateur d'Arduino. On en trouve avec gogole. Celui-ci par exemple est totalement fonctionnel 30 jours. ( Je ne l'ai pas testé)

http://www.smashingrobotics.com/ardu...ut-real-board/

[swiip2]

Merci pour l'émulateur je vais tester sa .
PA5CAL j'en suis au stade final, je passe mon oral le 2 juin donc pu trop le temps de modifier ^^.
Mais que veux tu dire par "modifier mes méthodes de travail" ?

[PA5CAL]

j'en suis au stade final, je passe mon oral le 2 juin donc pu trop le temps de modifier ^^.
Mais que veux tu dire par "modifier mes méthodes de travail" ?

Si tu es vers la fin, il est peut-être trop tard pour changer…

Mais sur le principe, un projet peut être organisé selon une méthode incrémentale et itérative, adossée à un énoncé de spécifications très précises et de plus en plus détaillées, et à une vérification des développements matériels et logiciels correspondants à l'aide de tests réalisés le plus tôt possible et correspondant à chaque niveau de détail. L'ordre choisi pour l'incrémentation permet de limiter la durée et repousser au plus tard l'utilisation de ressources posant un problème de disponibilité.

Par exemple cette façon de faire peut être employée pour développer un appareil embarqué dans un avion, sans disposer de l'aéronef avant les tests finaux, ni faire exagérément appel à des simulateurs adaptés mais coûteux à l'usage.

Sans aller jusqu'à donner dans le développement professionnel, on peut s'inspirer de ces principes pour mener des projets personnels ou de petite taille afin de pallier un manque temporaire de moyens matériels ou une limitation des moyens financiers.

[swiip2]

D'accord je vois ce que tu veux dire mais.. il est trop tard maintenant ^^.
Et... je sais pourquoi j'ai cramer le composant, et quand j'y pense c'est tellement... stupide, j'ai Oublier de relier les masses du coup bah au lieu d'avoir du 5V sur tous mes composants de ma bearbord, j'avais du 12V...

[PA5CAL]

C'est peut-être l'heure tardive, mais en relisant ce que j'ai écrit, je n'ai pas l'impression que ce soit d'une grande limpidité. Je vais donc préciser :

"… adossée à un énoncé de spécifications très précises et de plus en plus détaillées" : on commence par décrire clairement ce qu'on veut obtenir, d'abord d'un point de vue très général et fonctionnel, puis on reprend les points énoncés un par un pour en faire une description encore plus précise, qu'on re-précise à nouveau, et ainsi de suite. Puis on procède de la même manière pour préciser comment réaliser techniquement les fonctionnalités qu'on a spécifiées.

"… et à une vérification des développements matériels et logiciels correspondants" : chaque fois qu'on spécifie un détail de ce qu'on souhaite obtenir, on conçoit la façon de s'assurer que cet objectif est effectivement atteint. Chacun des tests qu'on imagine dans ce but doit porter exclusivement sur ce qu'énonce le point particulier de spécification, qu'il porte sur le comportement d'une partie de logiciel, ou d'un composant électronique, ou d'un circuit, ou d'un sous-système mécanique, etc. .

"… à l'aide de tests réalisés le plus tôt possible et correspondant à chaque niveau de détail" : dès que le développement d'un détail spécifié est terminé, on le teste de la manière prévue pour savoir si on ne s'est pas trompé, afin de ne pas faire porter sur la suite du projet un éventuel problème qui aurait pu être détecté et réglé sur le moment. Quand tous les éléments d'une partie spécifiée ont été développés et validés, on peut procéder au test de cette partie. Dans le cas où un test s'avérerait négatif, si la conception et le travail de spécification ont bien été faits, il suffit de corriger seulement la partie affectée au niveau de détail considéré.


D'un point de vue pratique, dans le cas qui nous intéresse (développement sans carte dispo), cela reviendrait :
- à dire d'abord ce qu'on doit faire, conformément aux documents de référence disponibles (datasheets, notes d'application, algorithmes, etc.), et ensuite seulement faire ce qu'on a dit (au lieu d'attendre de voir les résultats des dernières lignes de code tapées sur le fonctionnement de l'Arduino avant de décider de la suite) ;
- à adopter une structure de programme, organiser une chronologie du codage et écrire des routines de test permettant de vérifier au fur et à mesure que les fonctions et sous-fonctions produites donnent bien les résultats attendus (cela suggère notamment de construire des bibliothèques présentant certains niveaux d'abstraction, dont on peut plus ou moins valider individuellement le comportement à l'aide de routines de test exécutables sous Windows ou Linux - ainsi, il n'est nul besoin d'un Arduino pour trouver et corriger la majorité des bugs, et le code résultant est portable).

[swiip2]

Ne t'inquiète pas, j'avais compris ce que tu voulais me dire .
C'est ce que j'ai fais, mais en moins détailler, j'ai commencer par écrire toutes mes idées sur brouillon, puis algorigrame, puis schéma de montage et enfin le vrai câblage ^^. Bon heureusement j'avais toujours ma petite Arduino a côté de moi pour faire des tests car, on fais toujours des petites erreurs ^^. Mais dinon, il m'arrivait d'écrire un code (pour l'ajout d'un capteur par exemple, ou d'un écran LCD) et de l'insérer directement dans mon programme et le tout était fonctionnel.
Mais merci de m'avoir rappeler les étapes a ne pas brûler, mais il est vrai qu'à mon niveau, il vaut mieux faire des tests régulièrement que de compiler mon programme sur ma Arduino le dernier jour et me rendre compte qu'il ne marche pas, j'aurais l'air bête