[RESOLU] cycle instable TPIC6B596N

International Français
1

Yep!

Je me suis motivé à tester mes TPIC6B596N (http://www.ti.com/lit/gpn/TPIC6B596).

C'est exactement le même principe de fonctionnement que le 74HC595, data, latch et clock.

Sur le shema ci dessous, il y a un moteur en parallèle de la led et de la resistance, alimenté en 5v, pic de 50 mA :

Le code :

#include <avr/io.h>
#include <avr/interrupt.h>

void setup() {

  DDRB = DDRB | B00011001; // SERIAL SPI digital pins 8, 11, 12 (duemilanove)
  
  PORTB |= B00011001;
 
}

void loop(){
  
  shiftout(B01000000); // toggle Q1
  delay(2500);
  shiftout(B00000000);
  delay(2500);
  
}

void shiftout(uint8_t data) {
  PORTB &= ~(1 << PB0); // LATCH
  for(uint8_t i = 0; i < 8; i++) {
    PORTB &= ~(1<<PB4); // CLK
    PORTB |= (((data & (0x01 << i)) >> i) << PB3); // DATA
    PORTB |= (1<<PB4);
    PORTB &= ~(((data & (0x01 << i)) >> i) << PB3);
    }
  PORTB |= (1<<PB0);
}

Soit, j'ai un problème de cablage, soit mon code est trop rapide, en effet de temps en temps, de manière aléatoire, je perd un cycle. Le moteur fait mine de se lancer, la led clignote trés rapidement et rien.

J'ai ensuite mis un second moteur sur Q2, plus gourmand, je me suis dit que j'allais nourrir la bête, même si au demeurant, le fonctionnement est bien plus stable avec 2 moteurs, j'ai toujours, plus rarement, un cycle perdu.
On dirait que la porte s'ouvre et se referme aussitôt :~

J'ai essayé avec un condo sur la ligne CLOCK, idem.

Y'a-t'il un docteur dans la salle ???

@+

Zoroastre.

2

Yep!

Plus j'ai de moteur mieux çà va :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

Mon Tpic meurt de faim...il mange les ampères comme moi le boudin blanc...(la led power de l'arduino fait la gueule d'ailleurs...usb...)

Sérieusement, je crois que j'ai rien compris au MOS !!! :grin:

@+

Zoroastre.

3

Un moteur avec diode de protection j'espère :grin:

  1. Ton registre à décalage semble moins rapide que le 595.
    TPIC6B596N-->Fhorloge max = 10MHz à Ic =100mA
    595 ---> durée minimale de l'impulsion de commande = 20ns ce qui équivaut à 50MHz.
  2. Tu programmes directement dans les registres donc tu va plus vite.
    Dans ta fonction shiftout tu ne créé pas de "plat" pour l'horloge (1)--> je pense avoir compris que tu met l'horloge à 1 et que la ligne suivante tu l'a met à 0.

Ce n'est peut être pas étonnant que tu loupe des impulsions.
Essayes de mettre un délais après la mise à 1 pour créer un vrai créneau.
J'ai déjà vu des utilisateurs avoir ce genre de problème sur le forum anglais.

(1) C'est pareil dans la fonction de la lib arduino, par contre chez Wiring ils ont rectifié en ajoutant un paramètre "délais" .

4

Yep!

Trés bonne analyse 68tjs !!!

Effectivement, j'ai un gros souci avec les delais. Le problème avec mon code est que j'ai deux lignes pour interpréter le shift bit.

...
PORTB |= (((data & (0x01 << i)) >> i) << PB3);
...
PORTB &= ~(((data & (0x01 << i)) >> i) << PB3); 
...

Cette deuxième ligne d'ailleurs me pose problème dans le sens où je ne peux apposer qu'un seul delai dans ma boucle.

J'avais à l'époque interprété le chronogramme du 74hc et j'aurais pû penser reprendre mon code pour mes tpic, crotte :grin:

68tjs:
Essayes de mettre un délais après la mise à 1 pour créer un vrai créneau.

Je teste immédiatement...

EDIT 1 : J'ai mis des delais dans tous les sens, même résultat.
Le datasheet spécifie en petit caractère que la durée de la pulsation doit être <= 100 uS et avoir un cycle <= 2% (ce dernier chiffre est un mystère).

Je décide donc de reprendre l'experience précedente, même code, je mets un second moteur carrément en parallèle du premier. Je sais......je suis un dingue ]:smiley:
Cà marche beaucoup mieux et sur 5 mn, je dois loupé un cycle ou deux peut être...Le moteur qui me sert de test est un tout tout petit moteur qui tire en fonctionnement nominal 15 mA. Celui que j'ai mis en parallèle est plus imposant et arrache 55 mA facile (5 volts partout)
.
Alors il y a un rapport amperage/temps/mos ??? Je colle pas assez la grille ???

@+

Zoroastre.

5

Yep!

Une capa de 100 nF entre Gnd 19 et Vcc. Et Voilà :smiley:

#include <avr/io.h>

void setup() {

  DDRB = DDRB | B00011001; // SERIAL SPI
  
  PORTB |= B00011001;
  __asm__("nop\n\t");
 
}

void loop(){
  
  shiftout(B01000000);
  delay(2500);
  shiftout(B00000000);
  delay(2500);
  
}

void shiftout(int data) {
  
  PORTB &= ~(1 << PB0); // LATCH
  
  for(int i = 0; i < 8; i++) {
    
    PORTB &= ~(1<<PB4); // CLOCK
    PORTB |= (((data & (0x01 << i)) >> i) << PB3); // DATA
    PORTB |= (1<<PB4);
    PORTB &= ~(((data & (0x01 << i)) >> i) << PB3);
    
    }
  PORTB |= (1<<PB0);
}

@+

Zoroastre.

EDIT 1 : Pour l'explication du pourquoi

http://www.sonelec-musique.com/electronique_theorie_circuit_integre.html:
Découplage d'alimentation de circuits intégrés logiques
Il est de rigueur de placer un condensateur de découplage d'alimentation (en parallèle sur l'alimentation, entre la borne + et la borne - du circuit intégré) de l'ordre de 10 nF pour un boîtier comportant quelques portes logiques basiques (pour un SN7400 par exemple), valeur devant passer à quelque 100 nF pour une vingtaine de portes. Pour des circuits complexes tels que compteurs ou registres à décalage, un condensateur de 100 nF est également requis. Dans tous les cas, le ou les condensateurs de découplage d'alimentation doivent être placés au plus près du circuit logique concerné. Les buffers et les drivers de ligne sont particulièrement exposés aux "grosses" consommations, il convient d'apporter un soin particulier au découplage de leur alimentation. Les réalisations complexes faisant appel à de nombreux circuits numériques, ont tout intérêt à disposer d'une régulation d'alimentation locale, car les circuits numériques produisent des pointes de courant qui se traduisent par l'ajout de bruit sur les lignes d'alimentation, qui peuvent se répercuter sur des sections sensibles et les perturber. Une régulation locale présente l'avantage d'isoler le bruit généré par les circuits logiques, l'empêchant de remonter vers l'alimentation principale.