[EN COURS] Debug ZeDMD

han j'avais pas vu l'edit du F3

alors, une dalle (128 64 1 pour les réglages)
la mire est OK



Par contre en jeux ça se décalle comme je te disais :

C'est bien du balayage en 1/32? Ce sont les seuls supportés en 64x64 ou 128x64, après, pas forcément tous...
Après, j'aurai sans doute du boulot de debug quand j'aurai mes 4 panneaux en 64x64

oui c'est du 1/32, si je vire le E j'ai un demi affichage

OK, je verrai ça quand j'aurai mes panneaux.
En attendant, pour UltraDMD, j'ai installé FlexDMD comme indiqué ici https://github.com/vbousquet/flexdmd et ça tourne au poil:

Je veux pas foutre le mauvais oeil, mais :

Même pas peur, je suis dessus:
https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/issues/274

Bonjour
Ce que semble dire vortigont, c'est que pour un refresh rate acceptable (à 100Hz, en dessous duquel l'affichage scintille, perso je n'ai pas vérifié quel est la limite acceptable) de la matrice, le bottleneck est coté I2S. La combinaison résolution / colordepth des pixels est limitée par la clock I2S à 10 MHz (je ne sais pas si le chip peut faire mieux).
En augmentant la résolution il faut alors limiter le colordepth ou vice versa.

Je dirais ça aussi, mais du coup ma question est de savoir comment on limite le colordepth, moi j'ai un tableau de valeurs R8G8B8, mais je peux très facilement le convertir en R6G6B6 voire moins c'est juste qu'il me faut la fonction pour transférer avec cette définition

Bonjour
D'après ce lien
il faudrait passer ces arguments à la commande de build :

Code:

PIXEL_COLOR_DEPTH_BITS=5 (ou 6)

J'imagine que le code pack les pixels avec des bitshifts ou autre arrangements magiques...

Super, merci!
Bon pour l'instant, je me heurte à des soucis de transferts en grande quantité de données via l'USB et suis donc en train de changer complètement la méthode. Je verrai ça après une fois que ce problème important sera résolu.

Bonjour,

Bravo pour le ZeDMD, super projet. J'ai un petit soucis que j'aimerai partager au cas ou si quelqu'un à le même soucis.

ZeDMD fonctionne le temps de 2 tables et lorsque je lance une 3eme plus rien. Le DMD reste figé.
J'ai cherché du coté des DLL bloqués, ect... mais rien de cela.

Connaissant le port COM sur lequel je suis. J'ai envoyé un OK1 avec un hyperterminal qui fait bien réagir le DMD donc le problème n'est pas matériel.
Par contre au lancement des tables j'entends les solenoids de ma carte saintsmart qui colle genre conflit de port avec le DMDdevice. J'ai déconnecté cette carte mais le probleme persiste.... 

Ma question est : Peut on dans le fichier INI indiqué le port COM du DMD ?

Cordialement
Sébastien

Hello
Non, on ne peut pas, par contre, est-ce que ta table qui le bloque est une table UltraDMD? Car j'ai le souci avec ces tables et impossible de le résoudre.

Non, le problème est le meme en ultraDMD et en VPINMAME

Tu utilises des tables que tu lances à la main ou tu utilises un frontend?

J'ai testé les deux solutions. Il me semble vraiment que c'est un problème de détection du port COM par le soft. 
D'autre part, j'ai voulu réinstallé mais le lien dmd-ext n'existe plus sur le tuto. Et la version avec installer sur le github n'est pas la dernière.

Actuellement : VPINMAME 3.2 + VP 10.6

Merci

Voici comment ça se passe:
Le programme détecte tous les ports COM occupés. Il envoie un signal de reconnaissance et attend une réponse du device. S'il n'y en a pas, il passe au suivant.
Le truc, c'est que le procédé est absolument identique à l'envoi des frames en jeu. Donc si ça ne marche pas à la reconnaissance, j'ai peur qu'en jeu et même en fournissant le numéro de COM...
À mon avis, c'est que le port ne se ferme pas bien à la fin d'une table et du coup n'est pas disponible ensuite. Mais pourquoi...

Je ne comprends pas l'histoire du dmd-ext qui est plus dispo dans le tuto

zedrummer a écrit:

… À mon avis, c'est que le port ne se ferme pas bien à la fin d'une table et du coup n'est pas disponible ensuite. Mais pourquoi...

Salut Zed, j’y connais rien, mais y aurait pas moyen d’envoyer une commande pour reset le port à chaque fermeture de table ?…

Bah c'est le cas, enfin ça ferme le port, c'est quasi pareil
Ce qui est complètement dingo, c'est que ça marche 1 fois et pas 2

Alors après un grand nombre d'essais et de paramétrage différent des ports COM... 
Il est clair qu'à la fermeture des tables le port COM du ZeDMD ne se ferme pas.
J'imagine que le soucis vient du fichier DLL...

Ça marche 1 fois et pas 2?

---

Il démarre 2 fois mais jamais 3 !

C'est complètement improbable! Donc la fermeture arrive une fois mais pas 2...
Et si tu utilises un frontend, ça marche? Je veux dire que si tu reviens au frontend, il marche à nouveau?

Non même à travers le frontend le port COM reste occupé

Vraiment chelou … Une idée au hasard (bonne ou mauvaise j’en sais rien) Un driver pas à jour ?