Circuito e código com 74hc595 funciona no simulador, mas não funciona ao vivo

[Thiago Miotto]

Estou com um problema num circuito para acionar várias coisas, que tinha feito com o 74hc595

No tinkercad ele funcionou perfeitamente. Mas estou tentando fazer a mesma montagem no mundo real e não funciona.

Estou somente com 2 74hc595. Estou desconfiado que podem ser falsos, ou eu os estraguei c/ alguma mancada, ou ainda, eles estão loucos e precisam ser zerados.
Cheguei a ler algo, que se recomenda usar um capacitor no latch, mas estava em inglês e eu numa leitura rápida não consegui entender muito bem.
Eu tentei baixar uns exemplos prontos da net, e parece que funciona a 1º vez e depois não funciona. Algo meio s/ sentido.

Além do óbvio, comprar mais 2 demultiplexadores para verificar se o problema é neles, alguém tem mais  algum conselho/dica do que eu poderia fazer?

Segue código e circuito.

obs:  desconsiderem o loop do código, ele está assim só para testar se o procedimento atualiza595 vai funcionar como pensei

 

int latchPin = 6;  // Latch pin of 74HC595 is connected to Digital pin 5
int clockPin = 5; // Clock pin of 74HC595 is connected to Digital pin 6
int dataPin = 4;  // Data pin of 74HC595 is connected to Digital pin 4

byte led1, led2, mot1, mot2, mot3, mot4, mot5, mot6, beep, resist, bomba;



void setup()
{
  led1=0;
  led2=0;
  mot1=0;
  mot2=0;
  mot3=0;
  mot4=0;
  mot5=0;
  mot6=0;
  beep=0;
  resist=0;
  bomba=0;  
}

void loop()
{
led1=1;
atualiza595();
delay(1000);


led2=1;
atualiza595();
delay(1000);
  
led1=0;
led2=0;  
mot5=1;  
atualiza595();
delay(1000);
  
  
beep=1;  
atualiza595();
delay(1000);
  
  
  
}

void atualiza595()
{
  byte seq=0;
  digitalWrite(latchPin, LOW);  
  bitWrite(seq, 0, resist);
  bitWrite(seq, 1, bomba);
  bitWrite(seq, 7, beep);  
  shiftOut(dataPin, clockPin, MSBFIRST, seq);                    
  
  
  bitWrite(seq, 0, led1);
  bitWrite(seq, 1, led2);
  bitWrite(seq, 2, mot1);  
  bitWrite(seq, 3, mot2);
  bitWrite(seq, 4, mot3);
  bitWrite(seq, 5, mot4);
  bitWrite(seq, 6, mot5);
  bitWrite(seq, 7, mot6);  
  shiftOut(dataPin, clockPin, MSBFIRST, seq);
           
  digitalWrite(latchPin, HIGH);    
}

 

[.if]

Isto daí não é esquema e o 595 é bem simples de controlar. O problema é que você (como todo o mundo) está querendo usar funções arduínas mastigadas e obscuras e nem quer saber como opera. A essência: 8 chutinhos pra rolagem de bits internamente e um chutão pra pô-los pra fora.

 

Já publiquei artigo sobre ele com fonte e tudo o+ ... preguiça de procurar

 

5 horas atrás, Thiago Miotto disse:

mas estava em inglês e eu numa leitura rápida não consegui entender muito bem.

Vou escrever bem devagar pra você entender...conhecer inglês pelo menos o técnico é condição sine qua non neste ramo.

[Thiago Miotto]

Deixa eu ver se entendi a recomendação (vulgo, traduzo para mais  leigos):

1- Reset - enviar 8 bits com zero

2-  Ao invés de usar os bitwrite e shiftout, devo fazer comandos individuais de acionamento com digitalwrite high e low para cada função.
3-Entender o porque do   funcionamento do 595. Depois disso fazer um led piscar em cada uma das saídas com o código mais simples possível. Se o 595 falhar nesse teste, concluo que   algum transistor interno morreu e devo condenar este 595.

[.if]

1-reset é opcional

2-

#define RCLK 3
#define SRCLK 4
#define SER 5

void saida595(unsigned char dado)
{
unsigned char i;
for (i=0;i<8;i++)
	{
	digitalwrite(SER,dado&1);
	digitalwrite(SRCLK,1);digitalwrite(SRCLK,0);
	dado>>=1;
	}
digitalwrite(RCLK,1);digitalwrite(RCLK,0);
}

 

3-

loop()
{
saida595(0x55)
delay(tempo);
saida595(0xaa)
delay(tempo);
}

 

Do meu phd em pisca led saiu este minimalismo tradicional. Vai um cafezinho também?

Ah e não te esqueças OE=0 e SRCLR=1

[Thiago Miotto]

Comprei os leds que faltavam para fazer um pisca led completo e testar.

Mas resolvi arrancar todos fios da protoboard e remontar do zero
Ao olhar c/ mais atenção, percebi que montei os fios espelhados...(vcc na saida serial, gnd na saida 2 e assim por diante.....)


Obs 1: eu não havia declarado os PinMode. No Tinkercad funciona, no Arduino não. Mas esta aí mais uma coisa que a "querida" IDE não acusa que o programador fez caca


Aproveitando, uma dúvida aos entendidos de código e consumo de recursos. Acabei fazendo de 2 formas diferentes até perceber meu erro de declaração,. Qual consome menos recursos:
 

void atualiza595() //versao 1
{
digitalWrite(latchPin, LOW);
byte seq=(resist*2)+(bomba*4)+(beep*128);
shiftOut(dataPin, clockPin, MSBFIRST, seq);
seq=(led1*1)+(led2*2)+(mot1*4)+(mot2*8)+(mot3*16)+(mot4*32)+(mot5*64)+(mot6*128);
shiftOut(dataPin, clockPin, MSBFIRST, seq);
digitalWrite(latchPin, HIGH);
}



void atualiza595() //versao 2
byte seq=0;
  digitalWrite(latchPin, LOW);  
  bitWrite(seq, 1, resist);
  bitWrite(seq, 2, bomba);
  bitWrite(seq, 7, beep);  
  shiftOut(dataPin, clockPin, MSBFIRST, seq);                    
  bitWrite(seq, 0, led1);
  bitWrite(seq, 1, led2);
  bitWrite(seq, 2, mot1);  
  bitWrite(seq, 3, mot2);
  bitWrite(seq, 4, mot3);
  bitWrite(seq, 5, mot4);
  bitWrite(seq, 6, mot5);
  bitWrite(seq, 7, mot6);  
  shiftOut(dataPin, clockPin, MSBFIRST, seq);
  digitalWrite(latchPin, HIGH);   
}

obs2: Uma coisa que tinha estranhado, e pensando em como o 595 funciona entendi. A 1ª sequencia informada, ocorre no último e não no 1º. Pelo que entendi, o funcionamento do 595 é +- assim, a cada bit mandado, ele empurra os bits para a casa seguinte. Então, ao mandar 8 bits seguintes, os 1ºs são enviados ao 2º 595. Outra coisa, o comando shifOut c/ a opção MSBFIRST faz essa inversão, mandando o byte 7, depois o 6, 5, 4, 3, 2, 1 e por fim o 0. Viu, @.if, o puxão de orelha virtual funcionou bastante.
 

[.if]

10 horas atrás, Thiago Miotto disse:

Qual consome menos recursos:

Compile os 2 e compare. Algo me diz que vai ficar maior que o meu

Dica (avançada) pra controle de bit...

static volatile unsigned char rele;
static volatile bit resist @ (unsigned)&rele*8+0;
static volatile bit bomba  @ (unsigned)&rele*8+1;
static volatile bit beep   @ (unsigned)&rele*8+2;
static volatile bit led1   @ (unsigned)&rele*8+3;
static volatile bit led2   @ (unsigned)&rele*8+4;
static volatile bit mot1   @ (unsigned)&rele*8+5;
static volatile bit mot2   @ (unsigned)&rele*8+6;
static volatile bit mot3   @ (unsigned)&rele*8+7;

//...

...seu compilador pode chiar. Assim ele não chia:
 

struct b_r
{
unsigned bit7 : 1;
unsigned bit6 : 1;
unsigned bit5 : 1;
unsigned bit4 : 1;
unsigned bit3 : 1;
unsigned bit2 : 1;
unsigned bit1 : 1;
unsigned bit0 : 1;
};

union
{
struct b_r b_rele;
unsigned char _rl;
} rele_byte;

#define rele rele_byte._rl //o byte todo

//bit a bit
#define resist         rele_byte.b_rele.bit7
#define bomba          rele_byte.b_rele.bit6
#define beep           rele_byte.b_rele.bit5
#define led1           rele_byte.b_rele.bit4
#define led2           rele_byte.b_rele.bit3
#define mot1           rele_byte.b_rele.bit2
#define mot2           rele_byte.b_rele.bit1
#define mot3           rele_byte.b_rele.bit0

 

 

//...
resist=1;
beep=led1=led2=0;
mot1=bomba=1;
//..etc
saida595(rele);

 

Apesar do "tamanho" do fonte, o assemply gerado (depende da otimização do compilador) fica minúsculo se limitando a setbit e clrbit. Qualquer dia eu testo...

 

A saidêra... e minha preferida

#define setbit(var,bitno) ((var) |= 1 << (bitno))
#define clrbit(var,bitno) ((var) &= ~(1 << (bitno)))
#define xorbit(var,bitno) ((var) ^= 1 << (bitno))

#define resist         7
#define bomba          6
#define beep           5
#define led1           4
#define led2           3
#define mot1           2
#define mot2           1
#define mot3           0

setbit(rele,resist); //liga
setbit(rele,bomba); //liga
clrbit(rele,mot1); //desliga
setbit(rele,mot2); //liga

saida595(rele);