2x 74HC595 > et debuggage avec analyseur logique

International Français
1

Bonjour

Je suis en train de travailler sur un projet qui va utiliser 2 matrices de led bicolor (à anode commune)
Je travail actuellement sur une breadboard pour voir si mon driver fonctionne.
Pour simplifier, pour le moment j'essaye d'en piloter une seule et je la gère juste comme une matrice d'une seule couleur.
Je fais sur "col scanning":
Mon montage est à base de uln2003 et de 74hc595 (pour piloter les lignes et les colonnes)
Les deux 74hc595 partagent la même horloge et la même latch.
Évidement, leur "serial input" n'est pas la même.

Voici un test de code TRES SIMPLE que j'ai fais:

int latchPin = 6;
int clockPin = 7;
int colDataPin = 4;
int rowDataPin = 5;


byte index=B10000000;



void setup() {     
	
	Serial.begin(9600);

	pinMode(latchPin, OUTPUT);
	
	pinMode(clockPin, OUTPUT);
	pinMode(colDataPin, OUTPUT);
	pinMode(rowDataPin, OUTPUT);
	
}



void loop() {
 
	
	digitalWrite(latchPin, 0);
	
	shiftOut(colDataPin, clockPin,MSBFIRST, index);
	shiftOut(rowDataPin, clockPin,MSBFIRST, index);
	
	digitalWrite(latchPin, 1);

	
	if(index == B00000001){
		index = B10000000;
	}else{
		index = index >> 1;
	}
	
	//Serial.println(index, BIN);
	
}

Je debugge le tout avec un analyseur logique.
Voici à quoi son branché les pins:

Ch00: clock
Ch01: Serial IN des rangées
Ch02: Sortie QA du 1er registre à décalage
Ch03: Sortie QB du 1er registre à décalage
Ch04: Sortie QC du 1er registre à décalage
Ch05: Sortie QD du 1er registre à décalage
Ch06: Sortie QE du 1er registre à décalage
Ch07: Sortie QF du 1er registre à décalage

Ch08: Serial IN des colonnes
Ch09: Sortie QA du 2eme registre à décalage
Ch10: Sortie QB du 2eme registre à décalage
Ch11: Sortie QC du 2eme registre à décalage
Ch12: Sortie QD du 2eme registre à décalage
Ch13: Sortie QE du 2eme registre à décalage
Ch14: Sortie QF du 2eme registre à décalage

Ch15: Latch pin commune au DEUX registres

Voici le chronogramme:

https://dl.dropboxusercontent.com/u/138037/web/chrono.png

Je ne comprends pas pourquoi celui qui concerne le 2eme registre ne donne pas la même chose que le premier.

Si je change mon code et que je met en commentaire le shiftout des rangées pour ne laisser que celui des colonnes, cette fois ci le 2eme registre donne la bonne chose comme ici:

https://dl.dropboxusercontent.com/u/138037/web/chrono2.png

je ne comprend pas pourquoi le sur le premier, quand les deux shiftout sont ensemble, que les données du 2eme registre a décalage ne sont pas "dealé"

Est ce que quelqu'un est capable de me l'expliquer?

merci beaucoup

2

Les deux registres ont la même horloge donc lorsque tu décales la donnée dans l'un des registres tu fais avancer aussi l'autre.

	shiftOut(colDataPin, clockPin,MSBFIRST, index);
	shiftOut(rowDataPin, clockPin,MSBFIRST, index);
	
	digitalWrite(latchPin, 1);

Dans la première ligne du programme tu "charges" le registre colonne avec index et le registre rangée avec l'état du dernier bit présenté sur la sortie rowDataPin
Dans la deuxième ligne du programme tu "charges" le registre rangée avec index et le registre colonne avec l'état du dernier bit présenté sur la sortie colDataPin
Donc lorsque du fait basculer latchPin tu as dans tes registres:
rangée = index
colonne = toutes les sorties à la valeur du dernier bit présenté sur la sortie colDataPin

Pour résoudre le problème, Il faudrait :
soit avoir des horloges distinctes (dans ce cas tu peux avoir la donnée commune)
soit une horloge commune et cascader les registres le Q7S du premier registre dans le DS du second

3

Merci pour la réponse!

Je l'ai lu au moins 10 fois mais je ne suis pas sur de comprendre à 100%

En fait dès que l'horloge est en marche, cela fait "active" le registre a decalage c'est bien cela? Donc comme l'horloge ce met en marche a cause de la premiere ligne, cela active automatiquement le 2eme? C'est bien cela le problème?

Est ce que pourrais me servir de SRCLR avant d'utiliser le 2eme shift register?

Je vais essayer :slight_smile:

EDIT: en fait je me rend compte qu'il me faut donc une autre pin pour gerer cela. Du coup je pourrais la prendre pour rajouter une horloge, ca revient au meme.

4

Si tu comptes gérer séparément les 2 registres à décalage il faut avoir 2 horloges distinctes.
Si tu modifies le contenu des 2 registres à chaque fois alors il est plus simple de les cascader

5

Je l'ai lu au moins 10 fois mais je ne suis pas sur de comprendre à 100%
En fait dès que l'horloge est en marche, cela fait "active" le registre a decalage c'est bien cela?

Ce qu'il faut garder en tête c'est qu'au front montant du signal horloge systématiquement tout se décale d'un cran que tu change la valeur sur l'entrée "Donnée" ou pas.
Quand tu envoie un octet le bit de haut rang passera en premier par Q0 puis Q1, Q2...et enfin au 8eme front d'horloge il arrivera en Q7.
Il est des utilisations où voir ne serait-ce qu'un temps très bref des états intermédiaires comme un 0L au lieu d'un 1L peut avoir des conséquences catastrophiques.
C'est pour cela qu'il y a un latch qui empêche que l'on voit l'état les états intermédiaires des sorties Q7 à Q0 tant que les 8 bits de l'octet ne sont pas tous arrivés à leur destination finale.
Le Latch ne peut que bloquer ou autoriser la mise à jour des sorties du 74HC595.
Tant que l'application peut supporter des états intermédiaires son utilisation n'est pas obligatoire.

6

Merci

Je n'avais pas compris tout de suite que même si je ne donnais pas de "data" en serie, cela decallait quand même car l'horloge etait active.

Je vais essayer de les mettre en cascade. Mais j'ai du mal a me rendre compte si cela va poser des problèmes pour ma matrice.
En tout j'ai 3 registres à décalage (1 pour les rangé, et 2 pour les colonnes car c'est une matrice BI color)
Donc là je vas essayer de mettre les 3 en cascades sauf que cela va être plus long pour envoyé l'ensembles des données. Est ce que cela ne risque pas d'être trop long et faire un effet de "scintillement" vu que la fréquence de rafraîchissement sera trop faible?

En tout cas, je suis en train de l'essayer. On verra bien