Je suis actuellement en train d'étudier l'architecture des PIC32 qui, de premier abord, semble très intéressante. Je vous conseille d'ailleurs ce très bon livre qui l'explique de A à Z.

Mais pour ceux qui, comme moi, préfèrent mettre les mains dans le camboui et effectuer des tests au fur et à mesure de la lecture, je vais vous expliquer les premiers pas à faire pour travailler avec un PIC32.

J'ai utilisé un PIC32MX320F128H car il n'a "que" 64 pins au lieu de 100, c'est plus simple à souder et ca sera plus que suffisant pour de premiers tests. J'ai profité d'une commande pour acheter un adaptateur LQFP-64 vers DIP, à 1.25€ pièce c'est plus rentable que le graver soi-même (surtout vu le faible espacement entre les pins).

Le PIC se soude assez facilement dessus avec un bon fer et beaucoup de patience. Il suffit en fait d'étamer toute une face d'un coup (sans se tracasser des court-circuits), puis d'enlever l'excédent de soudure avec un tresse à dessouder. La preuve en image (vous voyez le PIC soudé sur son adaptateur, et des connecteurs tulipes sur les I/O pour facilement y brancher un fil).

Les connexions minimales à effectuer sont donc :

• Pins 9, 25, 41 (VSS) : masse.
• Pins 10, 26, 38 (VDD) : 3.3V.
• Pin 19 (AVDD) : 3.3V.
• Pin 20 (AVSS) : masse.
• Pin 56 (VCAP) : condensateur tantale 10 µF vers la masse.
• Pin 57 (ENVREG) : 3.3V.

Attention, pour ceux qui viennent du monde des PIC16 ou PIC18, vous remarquerez tout de suite que l'alimentation se fait maintenant en 3.3V et non plus 5V !
Vous remarquerez aussi les pins AVSS et AVDD qui servent respectivement de masse et d'alimentation pour les périphériques analogiques du PIC. Il ne faut pas oublier de les connecter, le PIC ne fonctionnerait pas sans.

La pin ENVREG sert, elle, à activer le régulateur interne fournissant la tension de 1.8V au coeur du PIC. Il faut alors mettre une capa de découplage entre la pin VCAP et la masse.
Une autre alternative serait de mettre ENVREG à la masse et d'alimenter VCAP directement en 1.8V, mais cela nous obligerait à utiliser un régulateur externe.

La suite des connexions sera expliquée dans un prochain post :

• Oscillateur.
  
• Connecteur ICSP. 
• I/O 3.3V (5V tolerant).
  

Maintenant que je suis ré-équipé en matériel, j'ai enfin pu utiliser l'oscilloscope pour vérifier les timings.

Comme je le pensais, le problème venait bien de là !
Après ajustement des timings, le résultat est beaucoup mieux

Mes problèmes d'oscilloscope sont presque réglés. Le fabriquant du DSO-2150 (Hantek) à confirmé qu'il s'agit d'un problème matériel et le vendeur accepte de le reprendre.
Cependant je dois le renvoyer en chine puis attendre que le vendeur l'ait testé avant d'espérer être remboursé... Pour mon prochain achat, j'y réfléchirai à deux fois avant d'acheter du matériel de cette valeur aussi loin...

Entre temps, j'ai fait une super affaire sur Ebay. Un laboratoire pas loin de chez moi (20km) revendait un oscilloscope PCSU1000 et un générateur de fonction PCGU1000, pour moins de la moitié du prix en magasin !!!
Le matériel est neuf et était toujours emballé, il était revendu pour cause de double emploi.

Mais (pourquoi y a-t-il toujours un mais?), c'est maintenant mon programmateur de PIC qui fait des siennes...
Une erreur se produit lors de l'écriture, et il faut recommencer l'opération une dizaine de fois avant que cela feuille bien fonctionner. De nouveau, je suis en contact avec le fabriquant pour trouver une solution... mais cela retarde encore le projet de matrices de leds.

J'ai pourtant pu y bosser quelques heures ce week-end, et ai presque éliminé le problème de ghosting grâce à l'oscilloscope.

Cela fait un moment que j'en avais envie (et besoin), je me suis enfin décidé à acheter un oscilloscope.

N'ayant pas la place pour un modèle traditionnel, j'ai opté pour un modèle USB.
 J'ai d'abord voulu prendre un PCSU100 de chez Velleman, mais son prix me semblait injustifié pour l'utilisation que j'aurai.

J'ai donc opté pour un modèle moins cher, un DSO-2150 de chez Hantek, moins performant modèle de chez Velleman, mais à priori tout à fait suffisant pour une utilisation occasionelle.

Pas de chance, celui que j'ai reçu semble défectueux

Je suis en discussion avec le support du fabriquant pour confirmer qu'il s'agit bien d'un problème matériel, mais cela retarde malheureusement mon projet à base de matrices de leds...

Maintenant que le fonctionnement de la matrice est confirmé, j'ai décidé de tirer un premier PCB afin de valider le principe de l'électronique de contrôle. Afin de simplifier le PCB (et de ne pas gâcher trop de composants si cela ne marchait pas), j'ai décidé de ne câbler qu'une seule couleur (vert). Le principe que j'ai choisi est d'utiliser des registres à décalage, qui permettront de chaîner plusieurs matrices sans augmenter le nombre d'I/O utilisé sur le microcontrôleur.

Pour les registres à décalage, j'ai utilisé des 74HC595 (datasheet (139,65 kb)) car ils se trouvent facilement en CMS.
Ces registres n'étant pas capable de fournir/collecter assez de courant, il faut les faire suivre de transistors. Pour les colonnes, il faut des transistors NPN, et pour les lignes, des PNP. Là j'ai fait avec ce que j'avais sous la main :

• 1x ULN2803 pour les colonnes (datasheet (98,94 kb))
• 8x MIC2514 pour les lignes (datasheet (230,99 kb)

J'ai utilisé les MIC2514 car je les avais sous la main, et qu'ils facilitent bien les choses pour ce genre de prototype. Il s'agit en fait, dans un même chip, d'un transistor PNP et de son électronique de contrôle (résistance de base,...).

Quelques photos du PCB en cours de soudage :

Petite remarque, je n'avais pas bu avant de percer les trous, mais ma perceuse sur colonne m'a honteusement lâché, j'ai donc du percer à main levée au dremel (pas facile quand on utilise des forets de 0.6mm ). Quant à la soudure des CMS, soyez indulgents, c'était la première fois que j'en faisais

Et le premier test une fois que tout est soudé :

Comme on peut le voir, il y a un énorme effet de ghosting. Bien que le latch des deux registres soit synchronisé, les transistors NPN et PNP ne commutent certainement pas à la même fréquence, ce qui provoque cet effet. Je n'ai pas d'oscilloscope pour confirmer, mais j'espère pouvoir régler le problème en ajustant certaines des temporisations.

Pour le reste, le fait d'utiliser des registres à décalage fonctionne très bien, ce qui est déjà un premier pas

Premier test de la matrice de leds, juste pour valider le pinout

J'ai donc connecté les 8 lignes (GND) et les 8 colonnes rouges (VCC) en direct sur un PIC18F,  sans électronique de puissance pour les leds, mais ca suffira pour le test ! J'ai ensuite écrit une boucle toute simple pour itérer chaque ligne et sortir la bonne valeur pour la colone. Et voila le résultat, un smiley tout moche, mais au moins ça marche

Le tout est connecté sur des breadboard en fil volant...
J'en profite aussi pour vous montrer mon programmateur de PIC, une clone de l'ICD2 de Michrochip, qui se trouve pour pas cher sur ebay, et qui est vraiment super pour programmer et debugger les PIC !!!

J'ai récemment acheté une matrice de 8x8 leds RGB afin de faire quelques "expérimentations"

Elle vient de chez sparkfun mais ne semble plus être disponible à l'expédition pour le moment.

Il s'agit donc de 192 leds (8 x 8 x 3 couleurs) agencées en matrice à cathode commune. Elle se pilote via 32 pins : 8 pour la sélection des lignes, 3 x 8 pour la sélection des colonnes.

La datasheet est disponible ici :
FYM-23881ABxxx.pdf (99,96 kb)

Malheureusement le pinout n'est pas lisible dans la datasheet, j'ai donc du le determiner au multimètre pour le remettre au propre :

Je n'ai pas non plus trouvé ce composant sous Eagle,j'ai donc créé la librairie correspondante :
FYM-23881ARGB.lbr (6,66 kb)

Il ne reste plus qu'a créér l'électronique de pilotage
Le but est de créer un PCB de la même taille que la matrice, qui contiendra tout l'électronique. Les PCB seront "chainables"pour créer une grande matrice rectangulaire ou carrée composé de plusieurs modules de 8x8 led.