Arduino - Traitement de l'information

Toutes les discussions sur l'Arduino !

Modérateur : MOD

Guillaume22
Papotier
Messages : 145
Enregistré le : dim. 29 sept. 2013, 08:20

Re: Arduino - Traitement de l'information

Message par Guillaume22 » sam. 18 janv. 2014, 23:34

J'en sais rien je n'ai pas testé en pratique ;), c'est la prochaine étape

Avatar du membre
likiki
Causant
Messages : 296
Enregistré le : dim. 29 avr. 2012, 14:21
Echelle pratiquée : H0 3R
Prénom : Christian
Site Internet : http://passionnement.forumactif.org
Localisation : Corbeil Essonne

Re: Arduino - Traitement de l'information

Message par likiki » sam. 18 janv. 2014, 23:37

Si demain j'ai 5mn (et là c'est pas gagné), je ferais un essais. :siffle:
Cordialement,

Christian.

Avatar du membre
Ramboman
Disert
Messages : 423
Enregistré le : lun. 23 oct. 2006, 17:13
Echelle pratiquée : LGB
Localisation : Waterloo, Belgique

Re: Arduino - Traitement de l'information

Message par Ramboman » jeu. 23 janv. 2014, 07:05

Qui peut le plus peut le moins...
Ma femme souhaitais réduire la puissance d'une animation en LED : "fais au moins quelque chose d'utile" :siffle:
10 LEDs blanches à 20 mA... ça fait un "vieux" nano 2.2 avec un ULN2803 pour la puissance et un pot... je sais, on peut faire moins cher, mais j'avais ça sous la main...
Une plaquette veroboard, deux supports 18 et 30 broches... curieusement le nano a 30 broches, mais un support 30 broches : ça n'existe pas :gne:
Bien, un 32 broches c'est bon... je fais tout le montage et... merde !
Les broches du nano sont trop grosses (ou les trous trop petits)... ça n'entre pas...
Bref... avez-vous déjà désoudé un support 32 broches :mdr2:
Vite fait, bien fait :applause:
La prochaine fois ce sera un rhéostat :ange3:

Avatar du membre
jlb
Fécond
Messages : 684
Enregistré le : jeu. 04 oct. 2012, 15:38
Echelle pratiquée : N
Prénom : Jean-Luc
Site Internet : http://modelleisenbahn.triskell.org

Re: Arduino - Traitement de l'information

Message par jlb » jeu. 23 janv. 2014, 07:09

Faut tester avant de souder :ange3:

Il ne faut pas prendre un support mais deux socles à broche femelle 16 SIL comme ceci :

Image

Tu peux même charcuter au couteau de modéliste pour retirer le rang excédentaire

Avatar du membre
Ramboman
Disert
Messages : 423
Enregistré le : lun. 23 oct. 2006, 17:13
Echelle pratiquée : LGB
Localisation : Waterloo, Belgique

Re: Arduino - Traitement de l'information

Message par Ramboman » jeu. 23 janv. 2014, 07:24

Mea culpa... mea culpa... mea maxima culpa...
J'avais testé le montage sur planche à pain...
Et le connecteur, je l'avais sous la main...
Mais à quoi peut bien servir un connecteur avec d'aussi petits trous ?

Avatar du membre
jlb
Fécond
Messages : 684
Enregistré le : jeu. 04 oct. 2012, 15:38
Echelle pratiquée : N
Prénom : Jean-Luc
Site Internet : http://modelleisenbahn.triskell.org

Re: Arduino - Traitement de l'information

Message par jlb » jeu. 23 janv. 2014, 07:29

Pour un CI en boîtier DIP 32 broches. Les broches d'un CI sont plus fines que les broches d'une barrette.

Avatar du membre
Ramboman
Disert
Messages : 423
Enregistré le : lun. 23 oct. 2006, 17:13
Echelle pratiquée : LGB
Localisation : Waterloo, Belgique

Re: Arduino - Traitement de l'information

Message par Ramboman » jeu. 23 janv. 2014, 07:37

Dans ma prochaine commande il y aura des barrettes ;)

Avatar du membre
Ramboman
Disert
Messages : 423
Enregistré le : lun. 23 oct. 2006, 17:13
Echelle pratiquée : LGB
Localisation : Waterloo, Belgique

Re: Arduino - Traitement de l'information

Message par Ramboman » jeu. 23 janv. 2014, 11:07

C'est tout simple... mais ça ne marche pas...
Le nano sort gentiment un PWM sur sa pin #3, pas de problème...
Le pot contrôle gentiment le voltage, pas de problème...
La pin #3 est branchée en parallèle sur les entrées 6 et 7 de l'ULN2803... rien n'en sort :(
J'ai vérifié les soudures, le câblage, j'ai remplacé l'ULN2803... rien...
Pourtant il n'y a pas plus simple...
Je recommence sur la planche à pain... peut-être un pont invisible sur mon veroboard !?

Avatar du membre
jlb
Fécond
Messages : 684
Enregistré le : jeu. 04 oct. 2012, 15:38
Echelle pratiquée : N
Prénom : Jean-Luc
Site Internet : http://modelleisenbahn.triskell.org

Re: Arduino - Traitement de l'information

Message par jlb » jeu. 23 janv. 2014, 11:40

À tout hasard, l'alim de l'ULN est mal soudée, mesure là directement sur les broches du composant

Avatar du membre
Ramboman
Disert
Messages : 423
Enregistré le : lun. 23 oct. 2006, 17:13
Echelle pratiquée : LGB
Localisation : Waterloo, Belgique

Re: Arduino - Traitement de l'information

Message par Ramboman » jeu. 23 janv. 2014, 11:54

Trouvé ;)
Erreur de câblage...
Merci

Avatar du membre
Arduino
Prolixe
Messages : 1698
Enregistré le : mer. 25 sept. 2013, 16:14

Re: Arduino - Traitement de l'information

Message par Arduino » dim. 09 févr. 2014, 00:16

Les interruptions externes avec Arduino

Qu'est-ce qu'une interruption ?
C'est ce qui arrive dans la vie de tous les jours. Imaginez que vous soyez au téléphone et que l'on sonne à votre porte. Vous demandez à votre interlocuteur de patienter, vous posez votre téléphone puis vous allez ouvrir. C'est le facteur qui vous apporte un colis. Une fois celui-ci réceptionné et la porte refermée, vous retournez prendre votre téléphone pour continuer votre conversation. L'interruption (sonnerie) vous a fait vous détourner de votre programme principal (conversation téléphonique) pour aller réaliser un sous-programme (ouvrir la porte) puis vous avez repris votre programme principal là où vous l'aviez laissé (si vous n'avez pas perdu le fil de votre conversation :lol:  !) .

Pourquoi interruption externe ?
Le micro-contrôleur peut gérer un événement extérieur comme quelque chose de prioritaire et pour cela exécuter un sous-programme. On parle d'interruption externe car c'est un événement extérieur au microcontrôleur qui crée l'interruption (par exemple l'appui d'un poussoir). Le microcontrôleur est informé de cet événement (car le poussoir est connecté à une de ses broches) ; il va immédiatement arrêter son programme principal pour aller exécuter un sous-programme de gestion de l'événement, et lorsque ce sous-programme est entièrement exécuté, le microcontrôleur reprend l'exécution du programme principal, là où il s'était arrêté.

Quel est l'intérêt ?
Entre chaque interruption, le microcontrôleur peut faire autre chose, sans être obligé de surveiller les événements extérieurs. Prenons l'exemple de notre poussoir : le programme principal peut surveiller périodiquement le poussoir, tout en faisant autre chose entre chaque surveillance. Mais si le poussoir est appuyé (très brièvement) entre deux surveillances, le risque est grand de louper l'événement, malgré le fait que les microcontrôleurs travaillent très rapidement :roll: . Avec une interruption, l'appui sur le poussoir « prévient » le microcontrôleur qu'il doit immédiatement réaliser la tâche que vous avez définie pour l'appui du poussoir. :wink:

Concrètement avec Arduino Uno ?
Arduino Uno est conçu autour du microcontrôleur ATMega328, capable de gérer beaucoup d'interruptions internes ou externes (une interruption interne vient du microcontrôleur lui-même, mais ce n'est pas le sujet de ce post). Le langage Arduino (compilateur qui transforme notre programme en code machine) n'en fait pas autant :( , mais a prévu toutefois de gérer deux interruptions externes (c'est mieux que rien ! :applause: ). L'événement extérieur doit provoquer un changement d'état (changement de tension) sur les broches numériques 2 ou 3. Par exemple, un poussoir monté sur la broche 2 ou la broche 3, selon le schéma de la figure 4 de l'article paru dans LR798, peut provoquer un changement d'état sur la broche (passage de 0 à 5 V, ou l'inverse). La broche 2 (ou la broche 3) est donc une entrée et doit être déclarée comme tel par pinMode (2, INPUT). Mais cela ne suffit pas  :twisted: ; il faut également faire savoir au microcontrôleur, que la broche est utilisée pour créer une interruption, quel sous-programme réaliser alors, et quel type de signal doit créer l'interruption (car on a le choix, comme nous allons le voir :wink: ).

Quatre fonctions pour nos interruptions externes
attachInterrupt (entrée, ISR, mode)
entrée = 0 si vous utilisez la broche 2 et 1 si vous utilisez la broche 3
ISR (Interrupt Service Routine) est le nom de la fonction à exécuter lorsqu'il y a interruption
mode détermine le type de changement sur la broche, devant déclencher l'interruption, et est égal à :
LOW si le niveau logique bas (0 V) doit déclencher l'interruption
CHANGE pour n'importe quel changement de niveau logique (0 à 5 V ou 5 V à 0)
RISING passage du niveau bas (0 V) à haut (5 V) encore appelé front montant
FALLING passage du niveau haut (5 V) à bas (0 V) encore appelé front descendant

Le contraire de cette fonction est detachInterrupt(entrée) qui permet d'arrêter la génération d'interruption sur une entrée préalablement affectée par attachInterupt (entrée vaut 0 ou 1 selon que la broche utilisée est 2 ou 3).

Parfois, il est nécessaire qu'une portion de code ne soit pas interrompue (code sensible au temps écoulé par exemple), dans ce cas, on utilise juste avant noInterrupts() (il n'y a rien dans la parenthèse). Pour ensuite permettre à nouveau les interruptions (une fois le code sensible exécuté), on utilise interrupts().

Dans le cas d'Arduino, les interruptions sont autorisées par défaut car utilisées dans des fonctions comme delay, millis ou bien Serial ; il faut donc être extrêmement prudent lorsqu'on interdit les interruptions ! :diable:

Le sous-programme d'interruption (ISR)
Ce sous-programme se présente comme une fonction ; il ne faut donc pas oublier le return à la fin :diable:  ! Cette fonction ne peut recevoir aucun paramètre et ne retourne aucun résultat. Si cette fonction modifie des variables du programme principal, ces variables doivent être déclarées comme « volatile » ; cela indique au compilateur de charger ces variables en mémoire RAM et non dans des registres du microcontrôleur afin qu'elles ne soient pas écrasées accidentellement :mort: . A l'intérieur de la fonction ISR, delay ne fonctionne pas et millis n'est plus incrémentée. De plus, des données éventuellement reçues par Serial peuvent être perdues :diable: .

On voit donc qu'il faut prendre beaucoup de précautions quand on veut utiliser les interruptions. Voici quelques conseils concernant l'ISR, prodigués par Nick Gammon sur son site référencé sur le site officiel d'Arduino (c'est dire qu'ils sont de bons conseils :wink: !) :
1 - l'ISR doit être courte
2 - ne pas utiliser delay
3 - ne pas faire de Serial prints
4 - déclarer comme volatile toutes variables partagées avec le programme principal
5 - ne pas tenter d'interdire les interruptions
Vous pouvez retrouver tous les conseils de Nick Gammon à cette adresse :
http://gammon.com.au/interrupts
(il y a beaucoup de choses et c'est plutôt pour des Arduineurs confirmés :geek: )

Lorsqu'une interruption est en cours de traitement, les autres interruptions sont ignorées jusqu'à la fin du traitement de l'interruption en cours ; c'est pourquoi delay et millis (qui utilisent des interruptions) ne fonctionnent plus pendant une interruption en cours, par contre delayMicroseconds fonctionne comme prévu car n'ayant pas recours à un processus d'interruption :wink: .

Malgré toutes ces précautions à prendre, les interruptions offrent beaucoup de possibilités et il serait dommage de préférer s'en passer. Maintenant, c'est à vous de jouer, et si votre programme ne se comporte pas tout à fait comme vous l'espérez, sachez qu'il y a moyen de résoudre cela, surtout si vous avez bien respecté les 5 principes listés plus haut :moi: .

Arduino Mega2560 et Leonardo
Ces modules Arduino possèdent respectivement 6 et 4 broches permettant des interruptions externes. En consultant le site Arduino – Reference – attachInterrupt, vous trouverez la description des broches et leur déclaration dans la fonction attachInterrupt. Le reste est quasiment identique à l'Uno. Enfin, cette fonction est un peu différente pour les modules Due ; l'interruption peut être attachée à toutes broches disponibles, et il existe le mode HIGH (tout comme LOW) en plus (même si le mode HIGH peut parfois fonctionner sur un Uno Rev 3 :wink: ).

Avatar du membre
likiki
Causant
Messages : 296
Enregistré le : dim. 29 avr. 2012, 14:21
Echelle pratiquée : H0 3R
Prénom : Christian
Site Internet : http://passionnement.forumactif.org
Localisation : Corbeil Essonne

Re: Arduino - Traitement de l'information

Message par likiki » dim. 09 févr. 2014, 10:33

Merci pour toutes ces infos, maintenant il vas nous falloir définir les priorités (en plus du reste). :?
Cordialement,

Christian.

Avatar du membre
Arduino
Prolixe
Messages : 1698
Enregistré le : mer. 25 sept. 2013, 16:14

Re: Arduino - Traitement de l'information

Message par Arduino » dim. 09 févr. 2014, 11:11

Bonjour Christian,

Ces infos sont dues à ce que je développe actuellement en robotique (tout en continuant le modélisme ferroviaire :coeur1: ). Mes premiers programmes avec interruptions fonctionnaient très mal, jusqu'à ce que je comprenne. J'ai donc voulu en faire profiter d'autres.

Définir les priorités ? Je pense que chacun d'entre nous l'a déjà fait en fonction de ses affinités et du temps disponible. Lorsqu'un projet est prêt, il faut le publier. Ainsi, jlb continue de développer son pont tournant et il publie régulièrement (et j'ai cru comprendre qu'il avait d'autres projets avec écran et module Xbee...), Hubert continue de publier ses travaux sur la programmation de puces ATtiny (ce qui en intéresse plus d'un !), pour ma part, je continue à découvrir le langage Arduino et les bibliothèques pour en faire bénéficier les autres dès que je serai plus à l'aise. Le seul dont je n'ai plus de nouvelles est Gérard qui ne publie plus rien sur son block automatique. Il finira peut-être par revenir. Sinon, on reprendra le block auto à notre compte, parce qu'il y a aussi une forte attente de la part des lecteurs.

Et toi ? As-tu résolu tes soucis de parasitage sur ton montage ? As-tu d'autres projets à développer ? Si tu es à cours d'idée :idea: , on peut t'en suggérer car il y a beaucoup à faire. :siffle:

Amicalement.

Christian

Avatar du membre
likiki
Causant
Messages : 296
Enregistré le : dim. 29 avr. 2012, 14:21
Echelle pratiquée : H0 3R
Prénom : Christian
Site Internet : http://passionnement.forumactif.org
Localisation : Corbeil Essonne

Re: Arduino - Traitement de l'information

Message par likiki » dim. 09 févr. 2014, 11:43

Bonjour Christian

Quand je disais "définir les priorités" c'était dans le programme Arduino. :mdr2:

En ce qui me concerne, c'est pour le moment un manque de temps. Un petit peut plus de travail en ce moment, et par les temps qui cour, nous ne pouvons pas refuser des clients donc .......... :siffle:

Mais les idées ne manque pas, et puis, Jean-luc me fascine avec son pont tournant, Hubert et son bus Can aussi.

Vas me falloir me couper en 4 ou 5 pour tout suivre.

:ange:
Cordialement,

Christian.

Avatar du membre
Arduino
Prolixe
Messages : 1698
Enregistré le : mer. 25 sept. 2013, 16:14

Re: Arduino - Traitement de l'information

Message par Arduino » dim. 09 févr. 2014, 15:22

Désolé pour la bévue :lol: !

En matière de priorités, les interruptions sont classées dans un certain ordre de priorités (si je ne me trompe pas, l'interruption sur la broche 2 est prioritaire sur celle de la broche 3).

Le mieux est donc de faire avec cet ordre prédéfini, car vouloir faire autrement risque de déboucher sur pas mal de problèmes. :roll:

Comme tu le dis, le boulot ne se refuse pas vu la crise ; mais je constate quand même que tu suis activement les différents forums. Donc, quand tu auras un peu plus de temps pour toi (et pas seulement pour Belle Maman), tu pourras t'y remettre.

Répondre