Choix d'un FPGA

[naru2to]

Bonjour,

Mon projet est de réaliser un afficheur 128 x 64 pixels avec des matrices de 8 x 8 LEDs. J'ai donc 4 rangées de 16 matrices.
Dans le but de pouvoir rafraîchir l'image plus rapidement, j'ai choisi de piloter cet écran non pas comme une matrice de 32 x 128 pixels mais comme s'il s'agissait de 4 écrans de 8 x 128 pixels.

- Le multiplexage des lignes est fait par un 74HC138N couplé à des P-MOS pour piloter les anodes communes. J'ai un ensemble 74HC138 + P-MOS par rangée de matrices, et ces 4 ensembles sont pilotées de la même manière (entrées de commande en parallèle) pour avoir simultanément les lignes de LED Ln, Ln+8, Ln+16 et Ln+24 actives avec n allant de 0 à 7 (sorties 74HC138).
- Le pilotage des cathodes se fait par registre à décalage 16-bit régulé en courant (TLC5926), il y a donc un circuit pour piloté 16 colonnes de LED, soit 8 circuits par rangée de matrices, et la commande se fait au même titre qu'un registre à décalage classique en Daisy Chain.

Là où ça se "complique" c'est que je veux envoyer simultanément des données différentes aux 4 rangées de matrices (4 entrées horloges et 4 entrées données indépendantes, les entrées Latch et Output Enable seront quant à elles communes à tous les circuits).
Au départ je pensais utiliser un microcontrôleur avec 4 ports SPI (famille PIC24 de Microchip), mais le problème est que je ne peux pas les utiliser en parallèle, lorsqu'un périphérique est occupé à envoyer des données, il faut attendre qu'il ait fini pour faire de même sur un second port, etc, d'où l'idée du FPGA.

Les images sont stockées sous forme de tableau dans une FLASH SPI.

Pour le moment j'ai un FPGA Altera Cyclone II sur carte d'évaluation, mais c'est un FPGA relativement vieux, et plutôt gros pour ce que je veux faire (j'ai pas besoin de 70 Entrées/Sorties).
Autant pour choisir un microcontrôleur je suis assez à l'aise, autant pour choisir un FPGA je suis largué...

Je recherche donc une "méthode" pour sélectionner un FPGA récent (en production chez le fabricant) qui ne soit pas hors de prix et qui n'ait pas 1000 E/S (je n'ai pas besoin d'un FPGA à 200€ avec du LVDS, HDMI, Ethernet et qui tourne à 1GHz) mais juste un petit truc qui me permettra de lire les données de la FLASH, les mettre en forme et les sortir sur les différents circuits logiques, et qui tourne avec un quartz de 25MHz. Et de préférence Altera vu que j'ai le matériel pour le programmer.

J'attends donc vos conseils, merci
-----

[luc_1049]

Bonjour

Vous n'avez pas besoin de trop d'entrée, alors pourquoi ne pas vous orientez vers des cpld ? Avez vous écarté et si oui pourquoi cette solution ?
Avez vous fait une étude de chronogramme pour affirmer que le transfert des 4 spi à tour de rôle serait trop long ?

Vous pourriez peut être à défaut de fpga multiplier les interface spi avec un autre micro ?

Si votre démarche est professionnelle vous devriez contacter un ingénieur d'application pour vous aiguiller sur des familles bas coût ?
Il vous faudrait voir les roadmap sur le site d'altera ou de xilinx par exemple.
Sinon il y a bien des tableaux de choix sur www pour faire un choix économique, pérenne, avec la bonne tension et les contraintes de boîtier, de nombre de broche et de compatibilité si vous deviez migrer vers un boîtier plus gros ou plus économique après mise au point et validation si vous êtes un sous traitant prestataire d'un grand compte ou mieux un grand compte .
cdlt
cdlt

[naru2to]

Bonjour,

C'est dans un cadre hobbyist, je n'ai pas fait d'étude de chronogramme mais je sais que les micro que j'ai sous la main qui disposent de 4 SPI ne peuvent pas faire un envoi simultané sur les 4 SPI à la fois, donc utiliser ces 4 SPI pour commander 4 rangées indépendantes reviendrait en théorie à n'utiliser qu'un seul SPI pour envoyer les données sur une seule longue chaine, et je ne sais pas quel serait le résultat visuel (je n'ai pas encore reçu les matrices de LED). De plus il y a un temps mort entre chaque envoie sur le bus (à cause de la FIFO interne je suppose).

Le problème des CPLD est qu'ils sont, si je ne me trompe pas, programmables une seule fois à cause des fusibles que l'on grille, contrairement aux FPGA qui sont reconfigurables.

Le problème d'avoir 4 microcontrôleurs, c'est qu'il faut en amont leur envoyer les données à afficher. Un point important que j'ai oublié, l'écran est destiné à afficher des animations, donc nuances de gris sur 8 bits, au moins 15 images/s, ce n'est pas juste un journal lumineux avec du texte en ON/OFF.

Du coup le fait de poser la question m'a fait réfléchir sur le sujet, et je viens de penser que le port parallèle (Parallel Master Port) de mon micro pourrait peut-être être suffisant pour faire le job

[jiherve]

Bonjour,
autre piste : utiliser un Propeller de chez Parallax 8 coeurs pouvant fonctionner en // , logiciel de dev gratuit mais langage à apprendre.
JR

[A voir en vidéo sur Futura]

[naru2to]

Wow je connaissais pas ces petites bêtes, ça a l'air quand même assez complexe à comprendre mais super intéressant!

[bobflux]

128 colonnes donc 8xTLC5926.

TLC5926 prend une horloge SPI à 30MHz (si alimenté en 5V). Mettons 16MHz. Donc on rafraîchit tout l'écran en 128*64/16e6 = 0.5 ms

Donc l'argument "vitesse de rafraîchissement" ne tient pas pour se compliquer la vie en découpant l'écran en 4.

Cela pourrait se justifier pour augmenter la luminosité par exemple, en gardant les LEDs allumées plus longtemps (plus exactement avec un rapport cyclique plus élevé). Dans ce cas, en effet on coupe l'écran de 128x64 en 4 lignes de 16 pixels de haut, donc on aura 8xTLC5926 par ligne, donc un total de 32 TLC5926. Ce circuit n'est pas cher, donc ça va.

Ensuite, soit tu raccordes tous les TLC5926 en série sur le SPI (ce qui ne pose pas de problèmes de vitesse) soit tu peux les mettre en parallèle comme tu voulais le faire, mais dans ce cas tu peux commuter l'horloge avec des portes logiques, pour envoyer les données sur chaque ligne, l'une après l'autre. La première solution est plus simple au niveau logiciel, car la DMA liée au périphérique SPI te permettra de rafraîchir l'écran entier en une seule opération.

Il faut voir la taille et le coût des matrices à LED : plus elles sont chères, plus tu peux justifier de compliquer un peu le circuit pour avoir plus de puissance lumineuse et les exploiter au mieux.

Donc, je ne vois pas pourquoi se compliquer la vie avec un CPLD, mais tu as peut-être des précisions à apporter ?

[naru2to]

Pour les matrices de LED elles viennent d'ebay, 40$ pour 70 pièces, j'ai compté une marge de 6 au cas où il y en ait une ou deux qui soit moins lumineuse ou morte dans le lot.

D'ailleurs erreur de ma part c'est 128x32 et non 64, d'où les 4 rangées de matrices.

Pour la question du temps, il y a un coefficient de 256 qui manque et qui permet de gérer l'intensité des pixels (dégradé) en utilisant la technique de la modulation de code binaire (Binary Code Modulation). De plus il y a un temps mort entre chaque envoi sur le bus SPI lié à la FIFO du périphérique.

Donc en théorie il faut 256 niveaux * 128 bits * 32 lignes, à 25 MHz on arrive à 20ms sans compter les temps morts, donc si on part sur une seule ligne ça devrait le faire, reste à voir la luminosité globale

[bobflux]

> Donc en théorie il faut 256 niveaux

Ah OK le minuscule détail qui change tout

Y a des puces genre lui mais c'est de l'I2C donc trop lent pour faire des updates rapides de ton affichage, tu peux peut-être en trouver en SPI...

Tu peux filer les docs des matrices ? Les LEDs sont en quelle tension ?

Tu as plusieurs solutions possibles, chip tout fait, une petite FPGA, ou pourquoi pas un micro pas cher par groupe de matrices...

[naru2to]

Bonjour,

Les matrices que j'ai commandé sont des équivalents decelles-ci, les LEDs sont standard d'un point de vue tension et courant d'alimentation.

Oui le HT16K33 et MAX7219 sont dédiés au pilotage de matrices mais assez limités en terme de taille d'afficheur.
L'autre problème qui se pose est l'intégration sur PCB, j'aimerais rester en deux couches et avoir 4 panneaux de 100mm x 80mm identiques pour réduire le cout, donc un composant en TSSOP ou QFN ne me dérange absolument pas.

Le problème des micro indépendants est qu'il faut d'une part leur transmettre les données à afficher et d'autre part qu'ils aient assez de RAM pour les stocker. Donc en amont le micro principal doit conditionner chaque bloc de données, ensuite il faut mettre en place un protocole de communication assez rapide, sachant que je n'ai pas trouvé le moyen de faire un vrai registre à décalage avec des microcontrôleurs, et d'autre part il faut qu'ils soient synchronisés.

Je pense que de ce côté là la logique est ce qui reste le plus simple à mettre en œuvre

[bobflux]

> j'aimerais rester en deux couches et avoir 4 panneaux de 100mm x 80mm identiques pour réduire le cout,

On trouve le 4 couches à 50$ les 5 cartes

> 256 niveaux * 128 bits * 32 lignes, à 25 MHz on arrive à 20ms

J'ai plutôt 40ms...

Bon. Partons sur 256x128x8 à 25MHz on a donc 10ms soit une rafraichissement à 100Hz, tout à fait acceptable pour éviter le scintillement.

Donc on a 4 groupes de 128x8.... Tu vas faire du Binary Code Modulation. Donc tu allumes les LED pendant un temps de 1 suivant le bit de poids faible, puis un temps de 2 pour le bit suivant, puis un temps de 4 pour le bit suivant, etc, ce qui se traduit par :

temps   envoyé

0       Groupe0 bit0
1       Groupe0 bit1
3       Groupe0 bit2
7       Groupe0 bit3
15      Groupe0 bit4
31      Groupe0 bit5
63      Groupe0 bit6
127     Groupe0 bit7
255     fin

Note: l'unité de temps correspond à la transmission d'un groupe de 128x8, donc 40µs. On remarque que durant certains créneaux (la majorité du temps, en fait) le port SPI ne fait rien du tout. Une idée serait de multiplexer le port SPI entre chaque ligne, en décalant les lignes dans le temps, pour utiliser ces créneaux vides.

temps	Groupe	bit
0	0	0
1	0	1
3	0	2
7	0	3
9	1	0
10	1	1
12	1	2
15	0	4
16	1	3
18	2	0
19	2	1
21	2	2
24	1	4
25	2	3
27	3	0
28	3	1
30	3	2
31	0	5
33	2	4
34	3	3
40	1	5
42	3	4
49	2	5
58	3	5
63	0	6
72	1	6
81	2	6
90	3	6
127	0	7
136	1	7
145	2	7
154	3	7

Après tu peux jouer avec les chip select pour envoyer les bons bits vers le bon chip...