Cube à led - Page 2

Godzil: les pins des LEDs sont suffisamment solides pour tenir le cube, y'en a 256 par couche tout de même.

Justement, ca pese son poid quand meme, j'ai peur qu'avec le temps ca s'affaisse.. Surtout si tu as des fils qui partent par LEDs, 4096 LEDs ca commence a faire un poids certain.

Et de toute maniere il va falloir avoir des truc pour passer/ranger les fils, donc quoi de mieux qu'une petite armature sur lequel les fils passent?

y'aura pas de fils (à part les 16 alimentations de couches) tout le reste ce seront des pattes de led soudées entre elles

Jonas (./26) :

Zerosquare (./25) :
Non, c'est super simple.

Jonas : exact, 18 %, erreur de calcul. Ça reste confortable

Mea culpa je lisais 4996 depuis hier ^^

Juste pour info, je me suis fait un petit banc de test pour valider les leds une à une... sur les 256 premières (pour la première couche) j'ai 256 leds qui s'allument, et une dont la coupe des pattes était inversée...

avec le calcul à 18% de spare ça en aurait mis 46 de coté alors qu'il m'a suffit de retailler une patte ^^

je viens de finir d'assembler la première couche...

en fait, 2cm d'espacement c'est cool, mais putain que c'est chiant : les pattes des LEDs ne sont pas suffisantes

squalyl (./11) :
y'a pas moyen d'utiliser des tits mosfets pour faire un allumage 3d?
un BS170 mos-N par LED, éventuellement en SOT23

ensuite genre 16 GPIOs actifs HAUT pour alimenter les anodes de chaque couche.

Ensuite 16 GPIOs actifs HAUT pour alimenter les grilles, par ligne.
et 16 GPIOs actifs BAS pour alimenter les sources, par colonne.

A voir... ca fait 4096 transistors et un peu de soudure, mais ca évite les registres a décalage en grande quantité.

Fichier joint :

Je compte rester sur du traversant (pas envie de faire graver une carte pour CMS). Est-ce qu'il existe une référence en "réseau" ? (plusieurs composants dans un boitier DIP/DIL)

pour les transistors?

Tu as un truc comme le CA3083 mais je doute que tu y soit gagnant question place tu aura toujours autant de broche a cabler et X transistor dans un support DIL a mon avis prendra au final plus de place que des transistors seuls

Godzil (./37) :
pour les transistors?
Tu as un truc comme le CA3083 mais je doute que tu y soit gagnant question place tu aura toujours autant de broche a cabler et X transistor dans un support DIL a mon avis prendra au final plus de place que des transistors seuls

Ok, donc je vais rester sur des transistors à papattes

Mais je comprend ta problematique, je ne connais pas de composant avec transistor en // avec genre l'emeteur ou le collecteur commun, mais ca existe peut etre

ULN2803?

Ce ne sont plus des transistors la, mais ca peux marcher aussi

(ha si ce sont des darlington en interne, pourquoi diable ils representent ca comme des buffers )

M'enfin c'est potentielement plus simple a driver/cabler que des transistors

Par contre a voir au niveau prix: http://fr.farnell.com/webapp/wcs/stores/servlet/Search?catalogId=15001&langId=-2&storeId=10160&gs=true&st=ULN2003AN
Ca remplace 7 transistors, mais c'est pas peu cher quand meme, faut voir avec le prix des transistors seuls

C'est des darlington.

trop tard, j'ai commandé chez conrad (moins cher que farnell ou rs) 300 transistors pour 25 euros (fdpin)

(bon, je viens d'attaquer la deuxième couche, je confirme mes stats : il faut 4 heures pour souder une couche, là en deux heures j'ai fait la moitié d'une)

bon courage..

je commence à réfléchir à la suite...

4096 Leds, si on veut du 25 fps, ça va tapper dans les 100kbits/s au moins. Je crois qu'on arrive à la limite des ports série :/

Si je veux me faire un circuit type "buffer d'affichage" auquel on transmet la grille et qui se charge de l'afficher, quelle liaison je peux utiliser (sur un µC pour le coup) ?

tu peux utiliser port série over USB (mais un vrai virtual VCOM, pas quelque chose utilisant un chip FTDI, meme si tu doit pouvoir monter a bien plus que du 115200.

Le 100% virtual COM en USB va a la vitesse max qu'il peux atteindre quelque soit le baudrate que tu met, et c'est relativement elevé

Même un simple FT232 supporte jusqu'à 3 Mbps, ce n'est pas ça qui va limiter la vitesse.

J'essayais d'être safe (mais oui le FT232 supporte bien pus que le 115K, mais le VirtualCOM a l'avantage d'être au max, meme si tu set a 70bps...

C'est vrai, mais l'USB "natif" est tellement relou que pour un projet comme ça, c'est à se demander si ça vaut le coup de s'embêter...

Clair. Une uart haute vitesse est quand meme plus simple.

Je me demande si un chip atmel, celui utilisé dans les feu arduino leonardo qui intègre l'USB (et des truc comme le VCOM) dans le code du bootloader arduino + dans les libs ne pourrais pas être potentiellement une solution, mais on est d'accord, et pas que pour un projet comme ca, l'USB est overkill en soit

C'est une solution, mais il faut voir dans quelle mesure le code USB des libs est propre et "collaboratif" avec le reste (c'est souvent là que ça pêche, quand je m'y étais intéressé Atmel n'était pas brillant dans le domaine, et Microchip j'en parle même pas).

Ya apriori une pile complete CDC dans les lib arduino pour le 32u4, mais ca ne reste pas simple on est d'accord, après pour le FT232, il faut que l'uC derriere supporte des baudrate supérieur a 115K, je ne sais pas si c'est courant ?!

Il l'est tellement que jai préféré recoder ma stack usb au taf.

Bon ben voilà, la messe est dite

Godzil > sur la quasi-totalité des micros que je connais, le baudrate maxi c'est au moins 1/64^ème de la fréquence d'horloge CPU, la plupart du temps 1/16^ème, et souvent il y a un mode high-speed qui permet d'aller jusqu'à 1/8^ème voire 1/4 de la fréquence d'horloge. Donc même dans le pire des cas, et avec un quartz à seulement 8 MHz, tu dépasses déjà les 115 200 bps. Les 115 200 bps maxi c'est surtout un problème avec les ports séries de PC classiques (et le matos prévu pour se brancher dessus), car c'est le standard supporté par tout le monde, même si la plupart des chipsets I/O de carte mère peuvent faire mieux.

Par contre un point auquel il faut faire gaffe, c'est que les baudrates possibles sont contraints par les fréquences d'horloge des deux côtés. Pour les convertisseurs USB-série, un bon choix côté µC est 12 MHz (ou 24 ou 48 MHz, si le µC le supporte), vu que l'USB utilise du 48 MHz* comme référence ; d'ailleurs les FTDI peuvent générer ce signal d'horloge, ça économise un quartz/résonateur côté µC.

* d'ailleurs ça ne tombe pas tout-à-fait juste pour les baudrates classiques de PC, qui utilisent un quartz à 1.8432 MHz, mais pour les vitesses <= 115 200 bps c'est suffisamment proche pour que ça fonctionne.

sinon tu prends un baudrate batard qui convient aux deux cotés
c'est quand même sacrément tolérant un port série.

j'en suis à 5 couches (sur 16), j'ai fini le premier sachet de leds, il en manquait 5 (995 au lieu de 1000) et deux avaient une erreur de longeur de pattes (coupe inversée)

Si j'applique le schéma à base de transistor proposé par squalyl j'ai donc besoin d'un double balayage (couche / ligne) pour afficher les 16 bits (de colonne).

si on vise le 25fps, il faut que je balaye à 6400Hz les lignes et 400Hz pour les couches.

Au niveau élec, j'ai donc maxi 16 leds alimentées à un instant donné.

1) je pensai mettre des condos en série des verticales de led pour créer de la rémanence. C'est nécessaire à votre avis ? Si oui, quelle valeur ?

2) j'aimerai faire un système en deux parties, l'une servirait de driver d'affichage à proprement parler et l'autre à alimenter le buffer d'affichage, vous feriez ça sur un ou deux circuits ?

3) j'aimerai que le système ait un mode "autonome" (avec des infos lues depuis une mémoire interne qui jouerait la même chose en boucle) et mode "commandé" où un appareil tiers (un PC typiquement) transmette le contenu a afficher

4) j'ai un raspberry pi B+ vous pensez que ça vaut le coup de s'en servir ou est ce que je risque de me prendre la tête par rapport à un µC classique ?

5) Dans quelle mesure on peut envisager des niveaux de gris avec un tel système ?


PS : j'ai terminé la 8ième couche today... sans pause je peux en faire une en 2h30~3h00 désormais...

Fichier joint : cube.avi

(timelaps de l'assemblage d'une couche)