Bonjour,

Je souhaite utiliser un driver de leds (MBIXXXX) pour controller 16 leds via une puce ATmega128 (pas d'arduino autour).

J'avais pensé faire un truc dans le genre :

unsigned char leds0 = 0b01001100;
unsigned char leds1 = 0b01010011;
// Init et Transmit tirées de la doc
SPI_MasterInit();
while(1) {
  /* Mes pins LE et OE sont branchées à PE4 et PE5 
     je les mets en output */
  DDRE |= _BV (PE4);
  DDRE |= _BV (PE5);
  // Fonctions données dans la doc de la puce ATmega
  SPI_MasterTransmit(leds0);
  SPI_MasterTransmit(leds1);

  // Tire OE en haut
  PORTE |= _BV (PE5);
  // Tire LE en bas
  PORTE &= ~_BV (PE4);
  // delay ???
}

Malheureusement, ça ne fonctionne pas, les bits ne sont pas transmis au led driver (je boucle infiniment en attendant que le buffer se vide). Qu'est ce que je fais de mal ? Avez vous de bons exemples d'utilisation  de SPI car je galère un peu à en trouver.

Merci.

-
Edité par jdflm 10 décembre 2018 à 19:45:52

Bonjour,

Comme OE est active à l'état bas, si OE=1, les sorties sont désactivées, donc les LEDs sont fixes (probablement éteintes ?). 

Tu peux faire la configuration des broches à l'extérieur de la boucle.

La broche LE transfert le contenu des registres à décalage sur les sorties, sur un front descendant (d'après la datasheet d'un MBIXXXX pris au hasard), le reste du temps elle doit être maintenue à l'état bas, donc elle devrait être pulsé à la fin d'une écriture (si elle est à l'état haut pendant que la broche d'horloge change, d'autres fonctions sont activées).

unsigned char leds0 = 0b01001100;
unsigned char leds1 = 0b01010011;

// Tire OE en haut, pour désactiver les sorties avant la 1ere écriture
PORTE |= _BV (PE5);
// Tire LE en bas
PORTE &= ~_BV (PE4);

/* Mes pins LE et OE sont branchées à PE4 et PE5
   je les mets en output */
DDRE |= _BV (PE4);
DDRE |= _BV (PE5);

// Init et Transmit tirées de la doc
SPI_MasterInit();
while(1) {
  // Fonctions données dans la doc de la puce ATmega
  SPI_MasterTransmit(leds0);
  SPI_MasterTransmit(leds1);

  // Pulse LE pendant à 1 pendant au moins 20ns (l'atmega128 à un cycle d'horloge de 62ns au minimum donc delay n'est pas nécessaire)
  PORTE |= _BV(PE4);
  // Tire LE en bas et OE en bas
  PORTE &= ~_BV (PE4);
  PORTE &= ~_BV (PE5);
}

OE pourrait aussi être mis à 0, dès le début et retirer la dernière ligne de la boucle, mais si le registre du driver n'est pas à 0 à l'allumage, son contenu va être visible pendant une fraction de seconde (mais vu la fréquence de rafraîchissement ça ne serait probablement pas perceptible).

C'est pas encore tout à fait ça mais en effet ça à l'air de mieux coller à ce que donne la doc. J'ai essayé de faire ça :

unsigned char leds0 = 0b11111111;
unsigned char leds1 = 0b00000000;
 
// Tire OE en haut, pour désactiver les sorties avant la 1ere écriture
PORTE |= _BV (PE5);
// Tire LE en bas
PORTE &= ~_BV (PE4);
 
/* Mes pins LE et OE sont branchées à PE4 et PE5
   je les mets en output */
DDRE |= _BV (PE4);
DDRE |= _BV (PE5);
 
// Init et Transmit tirées de la doc
SPI_MasterInit();
while(1) {
  // tire OE en haut
  PORTE |= _BV (PE5);
  _delay_ms (1);
  // Fonctions données dans la doc de la puce ATmega
  SPI_MasterTransmit(leds0);
  SPI_MasterTransmit(leds1);
 
  // Pulse LE pendant à 1 pendant au moins 20ns (l'atmega128 à un cycle d'horloge de 62ns au minimum donc delay n'est pas nécessaire)
  PORTE |= _BV(PE4);
  // Tire LE en bas et OE en bas
  PORTE &= ~_BV (PE4);
  PORTE &= ~_BV (PE5);
  unsigned char tmp = leds0;
  leds0 = leds1;
  leds1 = tmp;
}

Donc normalement là les 8 leds de chaque coté devraien s'allumer alternativement à chaque tour de boucle. Je ne vois pas du tout ce résultat, rien ne s'allume. Quand je ne mets pas de boucle autour du code, les bonnes leds s'allument en revance. Par contre j'ai l'impression que je dois brancher et débrancher mon installation plusieurs fois avant que ça fonctionne. Je ne sais pas si c'est un problème avec l'installation ou avec le buffer SPI qui n'est pas toujours flushé.

Merci pour ta réponse en tous cas.

Il n'y a pas de buffer SPI, puisque la fonction SPI_MasterTransmit de la doc attend que l'octet soit envoyé avant de rendre la main. Il n'y a que la broche LE qui contrôle l'envoie du buffer interne de la puce de driver (le registre à décalage), sur les sorties de ce même driver.

Pourquoi remets tu OE à l'état haut dans la boucle ? Comme je l'ai écrit, ça sert à désactiver les LEDs, tu peux le mettre à 0 avant la boucle et ne plus y toucher après (à moins que tu veuilles éteindre les leds pour une raison ou une autre plus tard).

Est-ce que ce ne serait pas mieux de mettre un délai plus grand entre chaque itération, 1ms (avec "_delay_ms (1);"), ce n'est pas assez pour être visible, et comme dans ton code actuel, le délai est juste après l'extinction des LEDs avec OE à 1, elles sont plus souvent éteintes qu'allumées.

Je viens de m'appercevoir que le problème est un peu différent de ce que je pensais. Je ne rentre jamais la deuxième fois dans ma fonction SPI_MasterTransmit. Au premier appel il n'y a pas de soucis mais la deuxieme fois je ne rentre même pas dedans. Le code de SPI_MasterInit et SPI_MasterTanspmit :

void SPI_MasterInit (void)
{
  // Set these as output
  DDRB =
    (1 << DDB2) | // MOSI
    (1 << DDB1);  // SCK

  SPCR =
    (1<<SPE)  | // SPI enabled
    (1<<MSTR) | // Select master
    (1<<SPR0);  // Fosc / 16 clock speed
}

void SPI_MasterTransmit (unsigned char cData)
{
  /* Start transmission */
  SPDR = cData;
  /* Wait for transmission complete */
  while(!(SPSR & (1<<SPIF)));
}

D'où cela peut-il venir ?

-
Edité par jdflm 14 décembre 2018 à 17:01:09

Même si tu n'utilises pas la broche SS du SPI (PB0), il faut la définir en tant que sortie (peu importe sa valeur) ou au moins en entrée avec résistance de pull-up, parce que si elle est définie en tant qu'entrée et qu'elle passe à l'état bas, le bus SPI va interpréter ce changement comme la présence d'un autre maître sur le bus SPI et passer en mode esclave.

C'est indiqué dans la doc dans la section "SS Pin functionality" juste après le code des 2 fonctions SPI_MasterInit et SPI_MasterTransmit.

En effet c'était ça mon erreur. J'avais pourtant lu cette partie de la doc mais j'ai du mal la comprendre.

Merci pour ton aide !

EDIT : En la relisant elle est pourtant très claire...

-
Edité par jdflm 15 décembre 2018 à 10:05:22