Reprise du message précédent :
C'est ce que les calculateurs me donne (en plus d'un calcul fait maison). Ou j'ai raté un truc?

https://media.discordapp.net/attach [...] y=lossless

[Edit] Si je mets 5mA ça me donne 230Ω mais en même temps j'ai rien dans l'arduino pour lui dire que je veux 2.15v...
[Edit2] Ha ok, c'est 5v la sortie sur un MEGA et non 3.3 comme le DUE
Donc ça donne effectivement plutôt 220 voir plus. Faut que je teste irl déjà ça sera plus simple.

Il me semble aussi que le maxi pour 1 arduino (à vérifier le model exact) c'est 200mA.
Tu veux 14 leds.
Donc 14mA par Led maxi.
Je te conseil 10.
Avec une sortie à 5V et une led classique (rouge) qui a une chute de ~1.2V ça donne 380 ohms.

1,6V plutôt.
 
Sinon 30mA c'est trop, c'est maxi 20mA une LED classique et faut voir aussi les limitations du AVR comme on disait!

Farpait fairpait !!!
Le MAX7219 c'est exactement ce qu'il me faut plutot que de s'emmerder avec des 74HC595

Bon, j'ai lu la doc, le MAX7219 a une résistance globale (de ce que je comprends de la doc, c'est par segment, donc par led) qui se met sur le port ISET. C'est la resistance que tu vois sur ta photo et tu as les 2 condos de la doc pour limiter le drain lors de l'allumage d'une LED.
J'ai pas ton montage, mais tu as d'un côté le + et de l'autre le - (ou différent, mais tu dois avoir 8 port qui sont + et 8 port qui sont -). Donc tu connectes toutes les LEDS au + (led 1 & 9 sur le port 1+, led2 & 10 sur le port 2+, ...) et tu connectes le - des LED par paquet de 8 (ici 8 + 6, donc led [1..8] sur le port 1- et led [9..14] sur le port 2-) sur le -.
Ensuite tu drives via le MAX7219. La version 7221 a un port SPI ce qui n'est pas le cas du 7219 mais je suppose qu'il y a des librairies qui le feront pour toi.

Verifie quand même la valeur de ta resistance (9.53Kohm ce qui me parait très eleve sur le papier mais j'ai pas calculer, je mets toujours 220ohm ) et de ce que cela debite avec une led, mais normalement c'est safe. Tu as le tableau 11 dans la datasheet qui donne le rapport Vled/Iseg en fonction de Rset

--------

En faite en relisant le tableau, je capte pas trop le pourquoi de Rset par defaut, faudrait tester sur le terrain avec une resistance

Le soucis du MAX7219 c'est le prix. Les versions Ali sont des clones ou rejets ou quelque chose, forcément vu la différence de prix.

PS: froggycorp, tu es un doublon de Roger01 ou je commence à m'y perdre?

Du tout
Même si on parle effectivement de trucs proches en ce moment

 
C'est le moment de consulter
 
Je vais tester la version ali, faudrait calculer, mais entre les mosfet, les résistances et le temps à souder, je pense que c'est compétitif (enfin pas mouser). J'ai grosso modo 30 leds, dont 19 avec commande mosfet ce qui fait 3x74HC595 En bidouillant, ca peut atteindre 2.
 
Vaut mieux du full chinois avec du TM ?

Oh eh!
 

J'avais utilisé des TM1637 de mémoire, leur interface c'est du pseudo-I2C sans adresse ou quelque chose, donc faut faire les choses en soft ce qui est assez chiant si on a pas de bibliothèque toute faite. A voir...

Sinon il y a le HT16K33 qu'on peut trouver à 0.70€ piece sur AE : https://fr.aliexpress.com/item/1005006774377871.html
Finalement, je vais prendre le TM1637 qui en plus va pouvoir lire l'état des boutons =)

J'ai trouvé des LEDS de 2 et 10mA, je testerais à l'occasion, ça réglera le problème.

Non mais une LED classique il ne faut pas dépasser 20mA, tu peux très bien rester en dessous! Et les LED "modernes" sont tellement brillantes que pour des indicateurs il faut rester (parfois largement) en dessous du courant max.
 
@froggycorp:
A toute première vue le HT a une vraie interface I2C, alors que le TM c'est pas le cas. Après doit y avoir des trucs tout fait au niveau code pour le TM aussi, sinon je perso je partirais sur le HT par simplicité.

Je ne sais pas comment je peux régler l'intensité, sachant que le programme arduino je ne peux pas y toucher.

L'intensité dépend du courant qui traverse la LED qui est déterminé par la résistance en série avec cette dernière.
 
R=(5-Vf)/I

Salut

On est d'accord.
Si je veux modifier un bit d'un registre d'un escalve I2C, je dois d'abord lire tout le registre, modifier le bit et renvoyer l'octet complet n'est-ce pas?

Je vais devenir fou, ca fait 2h que je suis sur un bug dans mon driver.

On dirait qu'il y a comme un problème de concurrence.
Mais on est d'accord, Arduino c'est mono-thread n'est-ce pas?

J'ai l'impression d'avoir des "glitch" en début de com et ça fout les registres en l'air.

 
LA résistance ne "prend" pas d'intensité également? Enfin il doit bien consommer aussi non?
J'ai toujours du mal entre la tension, la résistance et l'intensité

Quel esclave? Schéma du branchement ou du moins valeurs des résistances pullup? Code?

ESP32 vers ESP32 pour l'instant.
Je me suis farci 500 lignes de code pour l'ESP escalve + un driver pour le maître et ça bug, pas beaucoup, ca marche au 3/4

Les résistances de pull-up je ne sais pas, j'ai pris un module I2C quelconque, avec lequel je ne communique pas, qui a déjà des résistances dessus

Bon d'accord, je vais aller voir si j'ai des 4.7k pour faire ca proprement.
Mais bon même à très basse fréquence ça bug quelque part.

Je veux un oscillo  

Je vois ça.  
Tu devrais relire les bases "branchement série, branchement parallèle, loi d'Ohm, lois de Kirchhoff" (si c'est bien écrit le dernier, pas sûr )
 
En bref:
La LED présente une certaine tension de seuil à un certain courant selon la chimie dedans == la couleur. Pour du rouge c'est environ 1,6V p.ex.
L'intensité du courant qui traverse la LED est identique à l'intensité qui traverse la résistance car branchement série.
 
Il faut donc trouver la résistance telle que avec une certaine alimentation, p.ex. 5V dans ton cas, on se retrouve avec la "différence" entre 5V et 1,6V aux bornes de la résistance et R=U/I.  
 
Tu vas peut-être dire "mais attend, tu disais que les LED se commandent en courant constant" et tu as raison, en théorie il faudrait une source de courant, mais pour les petites LED 20mA une simple résistance suffit, surtout que souvent on reste bien en-dessous du courant max. Ce n'est PAS valable pour les "grosses" LED pour l'éclairage!! En effet la tension de seuil baisse si la LED chauffe -> courant qui augmente -> ça part en vrille. Mais ça c'est pour les LED de plusieurs Watt pour l'éclairage comme je disais. Et c'est aussi pour ça (et les faibles variations de la tension de seuil Vf) qu'il ne faut PAS brancher des LED en parallèle avec une seule résistance pour plusieurs LED (malheureusement ça se fait quand même souvent, mais c'est pas génial. Après pour de l'industriel où on prend des LED strictement identiques du même lot de fabrication ça peut le faire.)

fredo3: Il faut absolument des résistances si il y en a pas!!
 
Et sinon pas besoin d'oscillo, cherche "24 MHz logic analyzer" sur Ali ou similaire et télécharge Sigrok/Pulseview en attendant de recevoir le bidule.

Si si il y en a sur le module, mais je ne connais pas leur valeurs.

Ah mais oui j'ai déjà le Saleae Logic.

Je crois que je vais attendre que mon mini proto arrive, j'ai passé commande hier.

Uniquement pour protéger les utilisateurs qui risquent leurs vie en utilisant des télécommandes de chez Ali qui coûtent 1/20 du prix de l'original!!!!!!!!!!

Y'a le HackRF qui est Open, du coup y'a des "clones" moins chers et ça monte à 5 ou 6 GHz de mémoire, mais c'est pas 10€ ou du genre... Et faut faire attention car on peut émettre avec aussi, faut pas faire ça accidentellement et dans le plus strict respect de la Loi seulement. Bonjour les ennuis si on se met à émettre (par accident ou volontairement) sur certaines bandes genre aviation, ...!

 
 
Si tu veux de l'aide faut fournir des détails. Déjà les résistances de tirage ça se mesure facilement. Ensuite tu fais un exemple aussi petit que possible (au niveau code et composants) et tu postes. Tu écris un pilote toi-même, c'est bien ça?

Doit y avoir un problème de com, surtout que les valeurs sont aléatoires d'un boot à l'autre.

232, mais il se met à échanger des 200...

J'ai commandé un mini proto avec Attiny3226 et quelque autres puces dessus sur JLCPCB, pour des tests, avant d'envoyer la vraie platine complète.
La actuellement je débug le soft avec 2 ESP32.

On va procéder par étape, même si je suis sûr que le problème ne vient pas du driver vu que la moitié du temps ca marche:

Au niveau du driver, la fonction qui permet de lire 1 octet:

Et le write d'un octet:

Vous y voyer un problème?

Et 3 fonctions qui bug:

Il y a 9 registres en tout, j'en suis encore au premier niveau débuggage...

Dans un environnement radio saturé c'est potentiellement pas con notamment pour des trucs type volet roulant solaire sur batteries car ça permet de réduire le nombre de signaux inutiles à traiter par le récepteur donc sa consommation d'énergie.

C'est vrai, mais je ne suis pas certain que c'était ça leur motivation. Après je connais pas les produits de cette marque.

Paraitrait que ca n'aime pas le mode slave en i2c les ESP32:
https://forum.arduino.cc/t/esp32-i2c-problem/964717/3
 
Faut que je teste avec un STM32 demain.

Je connais pas cette lib' , mais pour read8: Faut pas remettre un Wire.beginTransmission() ou du genre (c'est à dire une condition START sur le bus) avant de LIRE l'octet? Car la tu dis quel registre tu veux lire, mais ensuite tu fais un endTransmission et ENSUITE tu essayes de lire? Dans le doute vérifier la doc.  
 
Aussi pour rappel: Les adresses I2C sont sur 7 bits + 1 bit (LSB) qui indique si c'est une lecture ou une écriture. Je ne sais pas si cette lib' gère ça en interne ou si il faut le faire soi-même?
 
Ah et

Quel intérêt de mettre un tableau avec un seul octet? Autant écrire uint8_t octet et si il te faut l'adresse bah utiliser un pointeur: &octet . Non? (Connais pas le C++ moi)

 
J'ai relu un peu les docs. L'interface spécifique du TM est quand même tres proche de l'I2C et l'utilisation des ports I2C doit etre possible à savoir balancer 1 byte dans le registre et laisser faire le uC. Par contre j'avais pas tilter, mais cette version n'a pas de pin de controle d'activation, faut que je recherche l'autre.
Le HT offre également une lecture de boutons, néanmoins un scan complet met 20ms (3x13 boutons soit 6ms pour 10 boutons) ce qui me semble lent pour un jeu de rapidite, mais en soit je ne sais pas trop (google indique un records de 14click/s et une moyenne de 6/s). Second probleme, l'INT ne se declenche que si le bouton a été appuyé pendant 2 cycles, ce qui le rend inutile.
Là ou le TM cité ne détecte que UN bouton à la fois (WTF ?). Je suis pas encore 100% arrêté sur mon choix mais s'il n'y a pas mieux pour les boutons, je vais garder un 74HC165 pour la lecture des boutons, qui permet du 10Mhz max en lecture. C'est con parce que le TM ou le HC me permettait de grandement simplifier la platine joueur.
 
Dans les deux cas, c'est dommage de ne pas pouvoir définir une résistance de base de limitation de courant comme le MAX7219 ou alors je la mets sur VDD.
 

 
Dans ma lib perso, le begin & end transmission sont dans le readfrom. Et elle est compatible avec les autres libs. Pourquoi c'est pas aussi le cas pour le write ? Bonne question et je me souviens plus.

Cherchez plus

Ca marche parfaitement maintenant.

J'ai rien changé au code. J'ai juste débranché un ESP pour y mettre un vieux STM32F4 Discovery, que je n'ai pas réussi à faire fonctionner sous Arduino , puis j'ai remis l'ESP.

Ca devait être un mauvais contact, au sinon le brouillage russe

cet aprem j'ai branché mon shield et mes nema 17, tout marche tout tourne avec ugs, yapuka

haaaaaaaa la bonne doc chinoise : https://www.holtek.com/webapi/116711/HT16K33Av101.pdf
 
Le temps d'une frame est de 9.5ms (page 15, 16x8 Led, 3x13 key) mais le temps de scan des key est de 20ms (page 17).
On peut limiter le scan et l'affichage pour gagner en vitesse et surtout si rien n'est connecté :
"The maximum of thirty-nine keys can only be scanned if the scan-limit register is set to scan the maximum KS0 to KS2"
 
SAUF QUE, il n'y a pas de "scan-limit register"

Bon, j'ai maillé holtek sans aucune certitude d'une quelconque réponse. Leur site est buggé et les .pdf sont majoritairement non accessible \o/

Au final, j'ai fait une version de dev 'bi' pour tester avec un max7221 (a pas cher sur LCSC) + 74HC165 et une version HT16K33. Cela donne ce gros bordel avec des solderjumper pour passer d'une version à une autre

Je me tate a rajouter des headerpins pour voir ce qu'il se passe un peu partout

Salut

J'ai un ESP32 N16R8, ce qui signifie 16Mo de Flash et 8Mo de Ram.
Comment ca se fait que je sature déjà la Flash avec juste 2 lib externe intégré au projet???

Comment ca se fait que l'interface me dit qu'il y a que 1310720 bytes dispo pour le programme?

Edit:
Ah c'est le "partition scheme".

Ok ok

mmh il y a le fichier html d'une lib que j'aimerais bien modifié, le problème c'est qu'elle est encodé je ne sais pas comment:
 

 
Ca peut être quoi???
Comment le convertir en text?
C'est bien du text, car dans le code il l'utilise sans modifier la variable:
 
J'ai essayé un convertisseur ASCII -> texte, mais rien de concluant.
 

C'est un char * tout bête. Par contre ca ressemble à de l'UTF-8. Donc faut faire 3 lignes de code dans un programme à faire tourner en local pour le coller octet par octet dans un fichier texte que tu edite avec un notepad ou assimilé. Et trois lignes de code pour régénérer ton tableau.

C'est pas trop ça encore

C'est pas de l'UTF-8.

Bon ben j'ai tout essayé, ASCII, UTF-7, UNICODE,... nada. Bizarre.

T'as un lien vers ces nombres?

 
Sinon tu recupere la version .html et tu compares quelques chr avec la version array

https://github.com/ayushsharma82/El [...] c/elop.cpp
 

 
Déjà essayé.