Reprise du message précédent :

oui, je vois une ligne de carrés "blancs". j'ai edit mon message avec plus de détails

Ha les carrés blancs, un classique
 
T'es connecté comment, avec des soudures ou des câbles dupont?

 
l'afficheur LCD est soudé au contrôleur i2c. le tout est relié en câbles dupont au uno

T'as contrôlé l'adresse avec un code arduino?
T'as vérifié les tags A0 A1 A2 de ton module I2C pour être sûr?

GND - GND
VCC - 5V
SDA - ANALOG Pin 4
SCL - ANALOG pin 5
 
Le code pour scanner l'I2C:
 
 

Ca vient ça vient... Le code auquel tu fait référence vient d'ailleurs de M4vrick, je n'ai fait que le modifier, mais bon...
Ma modif: http://forum.hardware.fr/hfr/elect [...] tm#t135956

Non (ça c'est une moyenne "flottante" il me semble non?).
(Je suppose pour la suite que le tableau est plein, soit on a déjà 10 valeurs valides.) Dans la boucle deux choses se font en parallèle: Les anciennes valeurs du tableau descendent tous d'une case pour libérer la case 0 (ligne 15). Ainsi on se retrouve avec 9 anciennes valeurs (cases 1-9) et la case 0 qui est vide. En même temps mais à part on additionne toutes ces anciennes valeurs pour calculer la moyenne plus tard (ligne 16).
Ceci étant fait on fait deux choses ensuite: Déjà on mets la nouvelle valeur dans la case 0 libérée avant (ligne 18). Ensuite on calcule la moyenne tout à fait normalement = les 9 anciennes valeurs + la nouvelle valeur et le tout divisé par 10 (ligne 19).

Je reviens sur ma modification pour garantir des valeurs exactes au début quand on a <10 mesures (Tu dis que tu en as pas besoin, tu peux donc utiliser le code original si tu veux):
Déjà le "static" ligne 10 est très important, ce mot clé fait que la valeur de la variable (NbValeurs) est conservée entre deux appels de la fonction. Normalement chaque variable est recréée (orthographe? horrible ce verbe...) et donc réinitialisée à chaque appel de la fonction. Là c'est pas le cas: Au premier appel NbValeurs aura la valeur indiquée = 0, mais lors du prochain appel ça sera la valeur que la variable avait à la fin de la fonction lors de l'appel précédant (soit 1).
La variable NbValeurs est ensuite utilisée à deux endroits: Déjà pour le calcul de la moyenne, c'est simple, quand on a que p.ex. 5 valeurs faut pas diviser par 10 mais par 5. L'autre apparition c'est dans la boucle (ligne 13). Pour la partie de la boucle qui fait descendre les valeurs d'une case ce n'est pas important (on bougera des valeurs qui ne sont pas significatives mais peu importe), par contre il ne faut surtout pas prendre en compte ces valeurs pour le calcul de la moyenne. (Ceci étant après réflexion cela ne devrait pas être un problème tant que MonTableau est global, car dans ce cas les cases sont initialisées avec 0 ce qui ne change rien à l'addition... On doit donc pouvoir simplifier la boucle en for(int i=TAILLE-1; i>0; i--) mais je n'ai pas testé cela (EDIT: Testé et confirmé).)

C'est clair?

Tu peux mettre du float, mais tu peux aussi travailler à virgule fixe, c'est à dire que tu restes en int mais que tu sauvegardes pas la valeur directement mais la valeur*10 en prenant soin de mettre la virgule au bon endroit si tu réutilises les valeurs plus tard. Mais c'est juste une optimisation, vu le temps que tu as pour le calcul tu peux simplement passer en float.
 

oui l'adresse est bien 0x27, c'est vérifié avec un code pour détecter ça, c'est bien détecté

Pour l'afficheur:
Déjà il faut savoir que les LCD "standard" ou "compatible HD44780" ne le sont pas forcément pour la séquence d'initialisation, ça peut-être une vrai galère...
Question bête mais quoi que: Pour les LCD par I2C tu utilises une librairie Arduino toute faite je suppose? Est-ce que cette librairie est compatible avec le PCA9554D? Je n'ai pas vérifié mais je ne pense pas qu'il s'utilise de la même manière que le PCF8574...

edit: Confirmé, le PCA est plus complexe. Pour le PCF on peut à première vue envoyer directement la valeur à mettre sur le port, pour le PCA il faut envoyer un octet de commande avant.

là j'essaye avec celle-ci: https://bitbucket.org/fmalpartida/n [...] /downloads

j'ai eu beau pas mal chercher à propos du PCA9554D, je n'ai vraiment pas trouvé grand chose. si tu as des infos/liens, je suis preneur!

edit: un truc: je n'utilise pas de pullup. devrais-je essayer avec? si oui, comment le/les connecter? je n'a pas de 4,7k mais j'ai des 1k ou 10k, j'essaye avec des 10k?

Pas de mal, j'ai bien prévenu que j'y panais pas grand chose à l'électronique Je vais essayer ça.

Pour la lib' je vais regarder.
 
 
Si tu reçois une réponse (de la bonne puce = PCA ) en scannant le bus c'est que ce dernier fonctionne. C'est vrai que sans pullup le I2C ne fonctionne pas et que sur le schéma du Uno je n'en vois pas, mais internet me dit qu'elles sont à l'intérieur du AVR.

  tu aurais un lien, de la doc, concernant cela? merci!
je regarderai un peu plus tard ce soir, je dois partir maintenant. mais merci, ça me redonne espoir et courage

(Je m'adressais plus à eeeinstein avec mon excuse.)
Pour la valeur de la résistance externe il faut soit essayer soit faire un calcul. Si tu veux de l'aide pour ça faut brancher ta télécommande directement sur l'ohmmètre, tester les touches (y compris les combinaisons de touches si tu veux en utiliser plus tard) et donner la résistance la plus faible et la plus forte que tu mesures.

Je reviens sur ta question:

en pratique: oui
en théorie: non. Il faut respecter la puissance maximale que peuvent dissiper les résistances et la tension maximale de ses dernières. Autrement dit il ne faudrait pas mettre du 230V (mais je comprends bien que si tu dis "n'importe quelle tension" c'est de la TBT...) et si on veut monter p.ex. à 24V ça peut être prudent de vérifier/mesurer/calculer avant d'y aller. Par contre comme c'est un truc pour voiture toute tension <12V ne présente aucun risque. (edit : En supposant que le truc soit "alimenté" en 12V par la radio, mais même si la tension est inférieure, avec des valeurs supposées dans les kiloOhm on ne risque vraiment rien)

Oui, par "n'importe quelle tension", c'était bien évidemment pas du 220 (mais je me dis que les écarts doivent être plus grands en 12V, ce qui doit être la tension que lui fournit l'auto-radio).
 
Pour la télécommande directement sur l'ohmmètre, j'ai déjà dit que ça fonctionnait pas, je pense qu'il faut que la télécommande soit alimentée.
 
Je vais essayer de comprendre tout seul comment faire le pont diviseur, mais y'a de grandes chances que je revienne poser des questions !

Tu les a donnés toi-même les liens vers les docs. Pour voir la différence il suffit de comparer la fig. 11 p. 10 du PCF avec la fig. 11 p. 10 du PCA (tiens, mêmes valeurs...). Pour le PCA on peut voir un "command byte" en premier, alors que le PCF c'est directement une "data".
 
Pour la lib' LCD, je ne trouve aucune indication qu'elle soit compatible avec le PCA9554D, autrement dit tu ne risque pas d'aller loin avec... Trois possibilités:
1) Trouver une lib' compatible.
2) Modifier la lib' existante.
3) Écrire une lib' soi-même.
 
Pour le 2) en principe cela ne devrait pas être difficile, mais vu que je ne parle pas C++ et surtout que je n'ai pas le matériel pour tester je ne vais pas m'aventurer là-dedans.

Oui les écarts de tension entre les différents boutons doivent être plus grand en 12V, mais selon le nombre de boutons (plutôt 4 ou 40?) cela ne devrait pas trop poser problème, le ADC du AVR c'est 10 bit soit 1024 pas quand même.
 

Si la télécommande ne contient vraiment que "des interrupteurs et des résistances" comme tu disais tu dois mesurer quelque chose à l'ohmmètre (en appuyant un bouton au moins).

Bin j'ai dois me démerder comme un manche, mais comme je disais je ne lis qu'une valeur qui change à chaque fois que j'appuie et qui ne s'affiche qu'une demi-seconde.
 
Bon par contre je viens de tester le pont diviseur avec une résistance de 1K, j'ai des écarts bien plus significatifs, et pour tous les boutons !!!   C'est cool, merci beaucoup pour l'idée.

Faut maintenir le bouton appuyé, tu le fais?

Oui, bien sûr Enfin bon, du coup ça n'a plus trop d'importance vu que le pont diviseur fonctionne nickel

Curieux quand même...

Oui, c'est ce que je me suis dit aussi mais bon, j'ai dû faire n'importe quoi

 
cool merci beaucoup pour ces pistes!
c'est souvent comme ça le monde arduino? par exemple récemment je galérais avec la calibration d'un shield 9dof (pourtant adafruit) en devant chipoter des trucs pas documentés
ceci dit je trouve ça cool que ça marche pas forcément du premier coup et qu'on doive chercher, ça fait apprendre pas mal

C'est souvent comme ça oui

 
tu as essayer de le brancher dans l'autre sens sur le multi ?

autre doc PCA9554: http://www.ti.com/lit/ds/symlink/pca9554.pdf page 18 semble avoir des infos utiles. vais essayer de m'aventurer dans l'adaptation de la lib actuelle (ou mieux chercher)

je remets les 2 autres datasheet ici:
PCA9554D datasheet http://www.nxp.com/documents/data_ [...] _9554A.pdf
PCF8574 datasheet http://www.nxp.com/documents/data_sheet/PCF8574.pdf

Salut,
Je suis en train de gérer des menus/sous-menus utilisateur sur lcd, vous auriez une méthode propre pour implémenter ça?
J'aurais bien essayé de faire une structure un peu à la xml, histoire de garder un code lisible en cas de rajout de nouvelles fonctionnalités. Des suggestions (pas de pont diviseur)?

Quand je vous disais que j'avais dû faire n'imp : en fait je pensais que la résistance allait être faible, du coup j'ai mesuré avec le multimètre sur 200 Ohm. Et là, en réessayant sur 20K, j'ai tout de suite des résultats bien plus probants  

Tu as les mêmes infos dans l'autre doc mais celle-là peut être plus lisible. C'est aussi une question de goûts personnels. Si tu veux essayer d'adapter à mon avis c'est SI2CIO::write() dans le fichier du même nom qu'il faut aller voir.

On a pas intérêt à mettre des résistances trop faibles car cela augmenterait inutilement la consommation de courant. Mais là tu as appris un truc sur l'utilisation de ton multimètre!

EDIT: Je reviens quand même sur la question des difficultés dans le monde Arduino:

Oui, car le monde Arduino c'est une approche de haut niveau: Des shields tout faits, des librairies toutes faites etc, ce qui cache quelque peu la complexité de la chose. Du coup quand quelque chose ne fonctionne pas le problème peut se situer à différents niveaux et il faut (au mieux) procéder de manière méthodique pour trouver la cause. Sauf que pour cela il faut "plonger" dans les détails (code des librairies p.ex.) ce que justement le monde Arduino essaye de cacher au max pour permettre une utilisation facile. Du coup c'est tout de suite plus difficile, surtout quand on a un niveau de compétences limité (je parle bien sûr de manière tout à fait générale sans vouloir insulter qui que ce soit! ).

(désolé, j'ai fait des bêtises du coup les citations sont anonymes)

(mauvais bouton, désolé )

    grâce à tes pistes j'ai réussi à ajuster la lib pour faire marcher mon afficheur!!! ça donne un sacré boost de confiance pour mes futurs projets ça bon j'ai modifié le code comme un goret (je peux pas faire mieux vu mes connaissances actuelles en C). je vais envoyer un mail au dév de la lib pour voir comment "officialiser" ça

pour info, ce que j'ai modifié:
grâce à ça: https://github.com/Sweet-Peas/PCA95 [...] ca9554.cpp j'ai compris que c'était au plus bas niveau que je devais ajuster
j'ai ajusté la fonction (méthode?) I2CIO::write et ajouté un

avant le

et j'ai vu que l'écran clignotait un peu, donc je me suis dit que c'était la bonne piste

ensuite je me suis dit que ce serait plus simple d'avoir 2 méthodes, une pour "config", une pour "data", plutôt que d'incorporer un flag dans la méthode (crado et je suis pas top en C je vous ai dit... ), donc j'ai recopié la méthode, renommé en writecfg et writedta, et ensuite dans LiquidCrystal.cpp j'appelle celle qu'il faut selon que c'est de la config ou du data. et ça marche  

edit2: bon finalement c'était pas si compliqué non plus de rajouter un flag plutôt que de faire une nouvelle méthode

Très bonne idée!

Pour ta modif je pensais à quelque chose comme ça. Si on veut bien faire il faudrait juste rajouter un peu de code pour gérer une éventuelle erreur lors de l'envoi.

Par contre en regardant la doc rapidement j'ai deux doutes. Ton LCD fonctionne déjà réellement?
Il me semble qu'il faudrait d'abord initialiser le PCA (une seule fois) en mettant les broches en sortie avec 0x03, 0xFF. Ensuite pour écrire une nouvelle valeur la commande ce n'est pas 0x03 mais 0x01. À confirmer.

Décidément j'utilise trop la fonction edit.

oui, le LCD fonctionne nickel maintenant
0x01 pour envoyer de la data
0x03 pour configurer
j'imagine que pour tes interrogations, l'initialisation doit être similaire au PCF et juste avec ma modif, ça fonctionne? en tout cas ça fonctionne. j'espère que c'est pas seulement "par chance"

Essayons d'éviter les malentendus...
 
Quand tu parles de writecfg et writedta c'est pour le PCA (soit 0x03 ou 0x01 en premier octet I2C) ou pour l'afficheur (à qui on peut envoyer de la data ou de la config aussi)?
 
Si c'est pour le PCA on est d'accord et tu as bien fait je dirais, c'est donc normal que ton afficheur fonctionne.  D'après la doc le PCF ne doit pas être initialisé (?).

 
voilà les fichiers que j'ai modifiés:
 
http://pastebin.ca/3613884 I2CIO.h, modif ligne 123 (ajout du bool dans la méthode ::write)
http://pastebin.ca/3613885 I2CIO.cpp, modif lignes 139 et suivantes, ajout du bloc lignes 154-161
http://pastebin.ca/3613886 LiquidCrystal_I2C.cpp, ajustement à chaque call de _i2cio.write suivant le type d'écriture

sinon, rien à voir, mails quel intérêt de mettre une résistance avec un dht11? j'ai essayé avec et sans, aucune différence dans les valeurs reportées

Le contenu de ce message a été effacé par son auteur

l'arduino le fait par défaut? car j'ai suivi un montage qui disait d'en mettre un, et avec ou sans ça fonctionne

edit: non ok je pense que la résistance est déjà présente sur mon dht11, j'avais déjà posé la question ici-même il y a quelques semaines/mois mémoire de poisson rouge

Cela ne me paraît pas tout à fait correct. Comme je disais il ne faut pas confondre deux choses:
1) Le LCD (enfin le contrôleur dessus, compatible HD44780) peut soit prendre des octets de données (codes ASCII à afficher), soit des octets de config (p.ex. pour allumer ou éteindre le cursor). Cela doit être géré par la lib directement. Ce qu'il faut comprendre c'est que peu importe ce que un octet représente pour l'afficheur, pour le PCA c'est toujours une donnée à mettre sur ses sorties (connectées au LCD).
2) Ensuite le PCA lui-même peut prendre des octets de données (à mettre sur ses sorties) ou un octet de config pour choisir le mode entrée/sortie pour chaqune de ses 8 broches. Cela se fait une seule fois au début du programme (à moins qu'on veuille lire des données de l'afficheur mais la lib ne semble pas le faire - à confirmer).
Autrement dit, peu importe ce que tu envois vers l'afficheur, pour le PCA c'est toujours une donnée, soit le premier octet à 0x01. Le 0x03 sera utilisé une seule fois au début du programme pour initialiser le PCA avant de pouvoir initialiser le LCD.
Les modifs des deux premiers fichiers sont correctes, mais tu t'en sers mal (dans le troisième fichier = LiquidCrystal_I2C.cpp). Toutes les appels vers _i2cio.write() doivent avoir un 1==data en deuxième argument. L'initialisation du PCA je la mettrais dans SI2CIO::begin() (mais il y a peut-être mieux, j'ai du mal à me retrouver dans toutes ces classes ) en se servant du _dirMask déjà défini dans le fichier. Attention à ne pas confondre, pour le PCA un '0' = sortie et un '1' = entrée (doc NXP p.8 tableau 8).

Petit détail: Pour _i2cio.write() un bool convient très bien pour distinguer donnée/config, mais ce n'est pas très parlant et on peut se tromper facilement. Tu peux définir deux constantes pour rendre ça plus lisible. Perso j'utilise le préprocesseur mais certains considèrent qu'il ne faut pas faire ainsi il me semble.
#define DATA 1
#define CONFIG 0
puis faire _i2cio.write(valeur, DATA/CONFIG).
On pourrait aussi utiliser typedef pour créer un nouveau type de variable.

Et pour l'autre chose, oui, le AVR à des pullup activables sur ses entrées.

merci pour ta réponse, je vais essayer de comprendre
tu parles de SI2CIO, je pense que le S est de trop, sauf si je devrais utiliser la lib LiquidCrystal_SI2C et non LiquidCrystal_I2C?

Oui pardon c'est une erreur, c'est bien I2C sans le S. Le S c'est à priori le I2C en software mais le AVR contient un module hardware pour ça.

hello
j'ai merdé j'ai envoyé du 36v sur l'entrée analogique A0 de mon arduino Uno
du coup, A0 et A1 ne marchent plus.
Vous pensez que je peux réparer ?