Problèmes d'encodeur EC11

Rebonjour Jean,

Je pense à tout ça ! Un grand merci pour tout. J'ai trouvé ici même sur le forum de quoi faire pour ATTINY et j'ai d'autres sites a écumer.

Il ne me manque que des exemples avec ATMEGA328-PU, mais je n'ai pas terminé mes recherches.

Un détail, si j'ai bien compris, si je développe avec Mega en I2C avec Nano, côté programmation, je pourrai après remplacer le Nano par un ATMEGA328-PU sans rien changer au code source ?

Et si je reste simple en déportant du Mega (pas de bibliothèque exotique), il pourrait en être de même avec ATTINY, à l'exception des numéros des broches qui pourraient varier ?

Là, j'ai sommeil..., bon dimanche !

Merci encore pour tout !

L'ami René

presque rien, sinon l'adressage des pinoches.

LamiRene:

Artouste:
...
bonjour
rapide
par hasard ton"systeme" n'embarquerait pas "déjà" une rtc ds1307 ?

Bonjour Artouste,

Le DS1307, je connais pas. C'est un « 64 x 8, Serial, I2C Real-Time Clock », je ne voie pas ce que cela apporterait de plus au projet qu'un Arduino Nano ou un ATMEGA328-PU ou un ATTINY8X et est-ce programmable par l'IDE Arduino ?

:grin:
si le ds1307 est avant tout une RTC c'est aussi 56 bytes de RAM disponibles et accessibles en ecriture/lecture I²C
et comme le DS1307 doit etre la RTC la plus utilisée "sur arduino" , si je posais a question , c'est que cela "aurait" pu permettre une gestion assez simple de la "passerelle" I2C

Bonjour Jacques,

Voici un complément de réponse à :

JMe87:
Bonjour Rene,
ton probleme est mal pose a la base. Tu parles de quelques encodeurs puis dans le dernier message, ton mega est super-plein.
Pour resoudre ton probleme tu dois passer par des "I/O expanders"
...

Le titre de la discussion reste bon « Problèmes d'encodeur EC11 », car ce n'est qu'avec ce type de composante que j'avais un problème de fonctionnement et d'incohérent, pas un manque de broche disponible.

Le problème de manque de broche est apparu par le fait que la solution du problème des encodeurs passait par des broches avec interrupteur et que sur le Mega il y en a que six et j’envisageais d'en utiliser plus d'encodeurs que cela, mais sans savoir avec exactitude, combien, mais proche d'une douzaine. Mais il me reste une trentaine de broches de disponibles. Ce n'est donc toujours pas le problème. Et la base trouvée du problème était un temps de boucle « loop () » trop long.

De plus, dans mon projet, pour optimiser les broches disponibles, j'utilise un capteur de signaux infrarouge de télécommande. Alors, avec une broche je me retrouve avec 44 boutons a dispositions !

Je pourrais très bien recycler une autre télécommande de plus ou moins 40 boutons, sans broche supplémentaire et redisposée d'une quarantaine de capteurs à disposition et donc, les broches de disponibles n'est pas le problème.

Pour résumer et synthétiser mon propos; dans mon cahier des charges du projet, il y a :

  • Par l'entremise d'un projet concret de réalisation d'un cockpit maison de simulateur de vol, parfaire mon apprentissage de l'électronique programmable et des cartes Arduino.

  • Utiliser une carte Mega et la presque totalité de ses broches pour peupler un tableau de bord et console de manette et bouton d'un cockpit générique avec des écrans LCD texte et des actionneurs de tout type.

  • La limite des composantes étant le très grand nombre de broches d'une carte Arduino Mega.

Soyez tous assurés que je prends bonne note de tous les conseils, suggestions et recommandations que vous me faite. Cela m'ouvre des horizons de possibilités pour ce projet et d'éventuels autres projets.

C'est grâce a vous tous que je découvre l'étendu des possibilités des ... !!! ...

Vraiment, un très grand merci à vous tous de vous prêtez à l'exercice !

Il me reste beaucoup d'études et des recherches a faire, donc j'y retourne.

L'ami René

parmis tes 12 codeurs, tu en a certainement qui ne sont pas critiques, ceux que tu peut faire travailler dans la boucle loop quitte a perdre des pas?
sur le meme principe qu'en IT:

...
#define pinCodeur1A=5;
#define pinCodeur1B=6;
#define pinCodeur2A=7;
#define pinCodeur2B=8;

int codeur1=0;
int codeur1AOld=LOW;
int codeur1AMem=LOW;
int codeur2=0;
int codeur2AOld=LOW;
int codeur2AMem=LOW;

....
  codeur1AMem = digitalRead(pinCodeur1A);
  if ((codeur1AOld == LOW) && (codeur1AMem == HIGH)) {  // front montant uniquement, codeur en x1
    if (digitalRead(pinCodeur1B) == LOW) {
      codeur1--;
    } else {
      codeur1++;
    }
  codeur1AOld = codeur1AMem;

  codeur2AMem = digitalRead(pinCodeur2A);
  if (codeur2AOld != codeur2AMem) {  // front CHANGE, codeur en x2
    if (digitalRead(pinCodeur2B) == codeur2AMem) {
      codeur2++;
    } else {
      codeur2--;
    }
  codeur2AOld = codeur2AMem;

//     AB
// 0 : 00
// 1 : 01
// 2 : 11
// 3 : 10
...

voir:
http://playground.arduino.cc/Main/RotaryEncoders

Bonjour Jean,

Non, je n'en utilise qu'un à la fois, mais quand j'en utilise un, je ne veux pas perdre de pas, quel qu'il soit.

Et le gros des 60 à 85 millisecondes n'est pas dû aux encodeurs, mais par des fonctions d'échange de données avec le simulateur par connexion Ethernet en mode UDP.

Merci pour l'idée.

L'ami René

Bonjour à tous,

Je viens de réussir une première communication I2C entre Arduino Mega et Nano en mode « Master Reader » pour la lecture de l'état d'un bouton pression. C'est d'une grande simplicité !

Est-ce que nous pouvons communiquer par un autre format que par « char » de l'exemple de base, car j'ai eu de la difficulté avec ce format au lieu de binaire et j'ai horreur de triturer les données pour les faire passer par un trou de souris ?

Merci de m'avoir mis sur la piste de l'I2C !

L'ami René

LamiRene:
Je viens de réussir une première communication I2C entre Arduino Mega et Nano en mode « Master Reader » pour la lecture de l'état d'un bouton pression. C'est d'une grande simplicité !

Est-ce que nous pouvons communiquer par un autre format que par « char » de l'exemple de base, car j'ai eu de la difficulté avec ce format au lieu de binaire et j'ai horreur de triturer les données pour les faire passer par un trou de souris ?

Merci de m'avoir mis sur la piste de l'I2C !

Bonjour
Attention à une chose avec ta demarche : I²C ou pas , si tu confie toujour le decodage des A/B à ton MCU (etats des contacts)
tu ne fait que complexifier le/ton probleme, tu reste tributaire de ton temps de boucle (et meme tu l'amplifie par la gestion I²C de simple lecture des contacts)

La solution I²C n'est In fine viable que si tu recupere de la maniere la plus concise les valeurs de compteurs ayant changés.

Bonjour Artouste,

Merci pour l'avertissement !

J'avais pensé à demander à chaque boucle de la « loop () » un compteur (format : byte) par encodeur, depuis la dernière demande du Mega, donc peu importe le temps d'une « loop () ».

Le compteur serait le nombre de pas de l'encodeur. Ce chiffre pouvant être 0 et pouvant aller jusqu'à 255.

Et l'ordre du compteur correspondrait au numéro de l'encodeur.

Alors si j'ai 9 encodeurs sur la carte Nano, il me retournera 9 * un octet « byte », et il remettra ses compteurs à 0.

Est-ce correct ?

Merci encore !

L'ami René

LamiRene:
Merci pour l'avertissement !

J'avais pensé à demander à chaque boucle de la « loop () » un compteur (format : byte) par encodeur, depuis la dernière demande du Mega, donc peu importe le temps d'une « loop () ».

Le compteur serait le nombre de pas de l'encodeur. Ce chiffre pouvant être 0 et pouvant aller jusqu'à 255.

Et l'ordre du compteur correspondrait au numéro de l'encodeur.

Alors si j'ai 9 encodeurs sur la carte Nano, il me retournera 9 * un octet « byte », et il remettra ses compteurs à 0.

perso et rapide reflexion , si je devais faire , je passerais par de la ram I²C (cas du DS1307) evoqué plus haut pour la simplification de programmation.

le MCU dedié encodeur ne faisant qu'ecrire dans une adresse memoire dédiée à son rang (si un byte te suffit c'est encore mieux , mais tu peux etendre la portée) ET generer un flag de mise à jour
avec un octet dédié aux drapeaux et des simples operations bitwise tu peux gerer/verifier 8 encodeurs
si ton octet de flag = 0 il n' a pas eu de MAJ , je passe à autre chose
si ton octet de flag = 1 , le compteur 1 a été mis a jour = à lire la valeur compteur 2 et remettre le bit 1 de l'octet à zero
" " = 2 le compteur 2 " " 2 " "
si ton octet de flag = 5 les compteurs 1 et 3 ont étés mis à jour = agir en consequence bit à bit.
si ton octet de flag = 255 tous les compteurs ont été mis à jour = IDEM

Rebonjour Artouste,

Je note l'exemple et merci !

Les meilleurs résultats que j'ai eus avec les encodeurs étaient en phase de test sans broche d'interruption et prétraitement des signaux. J'ai eu l'impression dans ce cas, que 100 % des changements des valeurs sur mes afficheurs correspondaient aux manipulations que je faisais sur l'encodeur.

Alors, comme le Nano devrait que traiter le signal des encodeurs, il va aussi en faire le prétraitement et ne me retourner que la somme des pas de chaque encodeur, pas la somme des signaux des encodeurs.

J'ai gardé le code source de cette phase de test et je vais le déporter sur le Nano.

Et comme je ne manipule qu'un encodeur à la fois, il ne devrait (le Nano) jamais être débordé de travail.

Donc pour l'avantage du prétraitement du signal, je privilégierais une solution qui permet cette déportation du code source, ce qui n'est pas possible avec le DS1307. Est-ce que je me trompe ?

Merci...

L'ami René

LamiRene:
...
Donc pour l'avantage du prétraitement du signal, je privilégierais une solution qui permet cette déportation du code source, ce qui n'est pas possible avec le DS1307. Est-ce que je me trompe ?

non
l'option RAM DS1307 est/etait dans mon esprit un simple confort de mise ne oeuvre.

si ton/tes "MCU encodeurs" gere lui meme la mise à disposition I²C de la valeurs des compteurs , c'est inutile

Bonjour,

Je viens de recevoir les Tiny (références) :

4 x ATTINY84A-PU

4 x ATTINY85-20PU

4 x ATTINY861A-PU

J'ai téléchargé et installé les bibliothèques suivantes :

Arduino Tiny for 1.0
Arduino Tiny for 1.5

TinyWireM.zip
TinyWireS.zip

Et j'ai réussi à faire faire mon premier Blink par un Tiny (ATTINY85-20PU).

J'utilise sous Linux Kubuntu 14.04 64 bits le paquet des dépôts standards « Arduino 1.0.5+dfsg2-2 », avec ces nouvelles bibliothèques.

Pour passer mon code « Mega_I2C_TinyE_MasterReader », et bien, ça ne passe pas et j'ai besoin de vos lumières.

C'est le même code que « Mega_I2C_NanoE_MasterReader » qui fonctionne bien avec un Nano au lieu d'un Tiny.

Mais les bibliothèques Wire et TinyWireS n'ont pas toutes les mêmes fonctions. Évidemment, « write », je remplace par « send », mais à première vue, pas de « TinyWireS.onRequest » d'un côté et pas de « TinyWireS.available » de l'autre ! Alors, avant de m'arracher les cheveux, je vous sollicite pour résoudre cette situation.

Je suis très loin de ne devoir que changer les numéros des broches.

Toutes formes d'aide sera la bien venue et merci d'avance aux âmes charitables !

L'ami René
P. S. : Tous ces CIs ne sont pas pour le projet cockpit, je prends simplement les devants sur les futurs besoins ou les accidents.

tu as certainement un probleme dans les version des librairies.
ce fil t'aiderai peut etre:
http://forum.arduino.cc/index.php?topic=265217.new%3btopicseen#new

Rebonjour,

J'ai trouvé une de mes sources de problèmes ! J'utilisais des chartes des broches des Tiny84 et Tiny85 erroné et/ou incomplet trouvés ces derniers jours. En voici les liens (donc à ne pas utiliser) :

http://www.ledsandchips.com/upload/cards/attiny.jpg


Voir en pièces jointes.

Il faudrait aviser les gens du premier hyperlien (site anglophone), je me charge de second (francophone) !

Est-ce que vous auriez une charte équivalente, mais qui ne comporte pas d'erreurs ou d'omissions comme ces deux dernières ?

Merci !

L'ami René

La Reference :
www.atmel.com/images/atmel-2586-avr-8-bit-microcontroller-attiny25-attiny45-attiny85_datasheet.pdf
Bonne lecture
Jacques

Bonjour,

Bon, après la découverte des erreurs dans ma documentation sur les Tiny (mon message précédent), soulagement intellectuel de voir que je ne suis pas aussi bête que ça ! Fierté d'avoir surmonté l’embûche et joie de voir mon code source d'échange en i2c entre Mega et Nano fonctionner entre Mega et Tini85 et Tiny84, du fait d'utiliser maintenant les bonnes broches de ces circuits intégrés !

Il me faut maintenant tester l'équivalent avec un ATMEGA328-PU sur planche d'expérimentation, puis, testé les trois types de circuits (Nano, ATMEGA328-PU et Tiny84) avec quelques encodeurs (je pense à 4) pour finalement pouvoir choisir judicieusement quelle CI intégrer à mon projet de cockpit, avant de tout chambouler derrière le cockpit actuel.

Mais, vous, de par vos expériences dans le concret, à ma place, que choisiriez-vous ?

Avez-vous un penchant plus prononcé pour l'une de ces solutions ?

Pour quoi ?

Je suis curieux de vous lire !

Merci pour tout !

L'ami René

JMe87:
La Reference :
www.atmel.com/images/atmel-2586-avr-8-bit-microcontroller-attiny25-attiny45-attiny85_datasheet.pdf
Bonne lecture
Jacques

Bonjour Jacques,

Oui, je sais bien, c'est l'ultime référence, mais c'est en anglais, ça fait 234 pages. Pas pratique au travers des minuscules composantes d'électronique de mon microscopique atelier, qui n'est qu'un bout de table recyclé.

C'est pour cela que je souhaiterais avoir une feuille, une image du type du premier lien « http://www.ledsandchips.com/upload/cards/attiny.jpg », qui fait la corrélation entre les broches des cartes Arduino, des broches des CI ATMEGA328-PU et des broches des CI Tiny85 et Tiny84.

Et j'y pense, je m'y collerais si le logiciel qui a servi à faire ce montage graphique était sous Linux Kubuntu. Alors, connaissez-vous le logiciel qui a servi à ce montage graphique ?

L'ami René

mon avis:

  1. soit tu colle un attiny45/85 derriere chaque codeur,
  2. soit tu mets un 328 pour l'ensemble des codeurs qui te manquerait sur le 2560.

la solution 1 est a previlegier si tu veut un truc modulaire-extensible
la solution 2 est a previlegier si tu veut gerer d'autres chose avec (par exemple les 3 lcd)

la solution 2 a l'avantage d'avoir sa platine UNO pour laquelle tu devrai deja etre familier.

Rebonjour Jean,

Une fois de plus vos recommandations sont très judicieuses et c'est la première fois que le cas des Tiny85 attirent mon attention, je l'est trouvaient trop limité en nombre de broches, mais ici le côté modulaire resurgir plus qu'avant.

Il va vraiment falloir que je réfléchisse bien à tout cela et que je priorise une option ou une autre.

Merci bien !

J'espère que beaucoup d'autres personnes me feront leurs recommandations, la différence d'opinions et de points de vue est une richesse...

L'ami René