[resolvido] Testador de Li-ion (18650) - 4051 / tp4056 - Problema

Olá pessoal, tudo bem?

A um tempo atrás eu resolvi imprimir algumas placas. Até ai, tudo certo.

Fiz o projeto enviei, foi processado, enviado, recebi e agora estou testando e estou parcialmente contente.

Algumas placas, durante a fase de projeto, coloquei na protobard para testar cada detalhe e verificar todos os possíveis problemas, entretanto, existiram algumas que não foram testadas, tornando-se produções 100% teóricas.

Dentre elas, desenvolvi uma plaquinha para me ajudar com dados sobre baterias de li-ion. Então vamos lá.

Objetivo:

1- Carregar até 3 baterias individualmente

2- Obter informação de carga

3- Obter informação de temperatura

Métodos:

- p/ objetivo 1: através de módulos com o tp4056.

- p/ objetivo 2: através da descarga da bateria, utilizando um resistor de 5r e 10w.

- p/ objetivo 3: sensor de temperatura ds18b20

Visualização das informações:

- Tela TFT LCD 1.8"

- 3 Leds RGB

Lista dos materiais utilizados e seu objetivo:

A) 3x 74hc595: Acionar leds, mosfets e alternar o controle do cd4051.

B) 1x 74hc165: Teclado de 6 botões apenas.

C) 1x CD4051:  "expandir" portas de entrada analógica (multiplexando) 

D) 1x Esp8266 (módulo): controle geral e cálculos

E) 3x Resistor 5r 10W:  Dreno das baterias

F) 6x IRF540n: chave para acionar "dreno" ou "recarga"

    *Para dreno, o mosfet se ligará com o resistor

    * Para recarga, o mosfet ligará a alimentação do tp4056

G) um monte de resistores

H) 1x cap. 470uf eletrolítico: Produzir um efeito de esmaecer ao desligar o brilho da tela.

I) 1x cap. 1000uf eletrolítico: Força do hábito (está ligado ao +5v, que alimenta a placa)

Segue imagem em 3D da placa:

Imagem do circuito no proteus:

Imagem do esquema.

obs- a imagem está com uma resolução muito grande, recomendo fortemente a abrir em uma nova janela.

obs- Em anexo está o arquivo do proteus e o gerber, caso seja necessário.

//////////////////////////////////////////////////////////////////////////////////////////////////

Placa chegou, soldas prontas, conectores no lugar, então inicia o teste por etapas.

---Status---

1) Tela de LCD. Funcionando perfeitamente

2) 74hc595: Não funcionou

3) devido ao 74hc595 não funcionar, o 4051 não pode ser testado.

4) devido ao 74hc595 não funcionar, os irf540n não pode ser testado adequadamente.

5) devido ao 74hc595 não funcionar, o tp4056 não pode ser testado com a placa.

6) 74hc165. Funcionando perfeitamente.

Vale lembrar que, devido a um planejamento equivocado, só posso upar o código se o controlador ou o 74hc165 estiver fora da placa, pois o pino "data" do 165, está conectado ao RX, impossibilitando a boa comunicação do a serial.

Quanto ao código, também em anexo, existem 3 pontos que estou utilizando para definir os ci's, por completo, como alto ou baixo (linha 13, 17 e 22), meus resultados estão sendo o seguinte:

74hc595 C = 0 // Off

74hc595 B = 0 // off

74hc595 A = 1 // ON

Resultado: Apenas "A"  ativo.

74hc595 C = 0 // OFF

74hc595 B = 1 // on

74hc595 A = 1 // on

Resultado: A, B e C ativos (deveria ser apenas A e B)

74hc595 C = 0 // OFF

74hc595 B = 1 // on

74hc595 A = 0 // on

Resultado: B e C ativos (deveria ser apenas B)

74hc595 C = 0 // OFF

74hc595 B = 1 // on

74hc595 A = 0 // on

Resultado: NENHUM ativo (Deveria ser apenas C)

obs- na postagem seguinte, irei fazer a lista completa.

Bibliotecas utilizadas:

TFT eSpi: https://github.com/Bodmer/TFT_eSPI

Problemas já encontrados e "resolvido":

Acionamento dos leds.

Existiu uma falha no projeto, onde realizei os links de forma errada. O link deve ser feito através de 1 "apelido" em 2 ou mais terminais distintos. Entretanto, errei o apelido, isto é:

LedR1 (em um terminal) e Led_R1 (em outro terminal), desta forma, os leds ficaram conectados ao resistor, mas os resistores não possuem qualquer conexão no segundo terminal.

Solução: Puxa um fio e solda, por baixo da placa. Fim.

Problemas pendentes

-74hc595 que não funciona como deveria.

Exibições: 1093

Anexos

Responder esta

Respostas a este tópico

olá novamente, Tiago.

      Rapaz, mesmo sendo um código muito simples de teste,  não chame o seu código de "lixo.ino".  Isso não é legal.

      Bem, mas sobre o não funcionamento dos HC595, provavelmente é devido a vc não estar respeitando os tempos de "setup" e "hold" para o sinal "Data" em relação ao edge de subida do "CLK" (o ESP8266 é rápido, e isso piora ainda mais estes tempos).  E também não estar respeitando o "tw" ("time width") do próprio CLK em HIGH e em LOW.

      Veja os apontamentos que fiz no seu código, mostrados na figura a seguir:

(clique na figura para "zoom")

      Aqui está o seu código de testes com estes ajustes:   "cod_teste_02.zip"

      A figura a seguir mostra os ajustes feitos:

(clique na figura para "zoom")

      Sobre seu Hardware, há um ponto muito crítico nele, que mostro na figura a seguir:

(clique na figura para "zoom")

      Na verdade são dois pontos, ambos no sinal "TFT_LED".  Veja, o 74HC595 pode fornecer (ou drenar) entre 6mA e 8mA em um pino de saída.  Vc está usando este sinal para o Backlight do Display. Assim, se este Backlight não tiver um Driver próprio na placa do Display e a corrente drenada for além dos limites "normais" para o HC595,  vc estará em uma região de funcionamento não recomendada, e pode inclusive ir além dos "Limites Máximos Absolutos" do HC595. Logo, se for o caso de um Display sem Driver para o Backligh,  aconselho mudar o circuito.

      Outro problema no mesmo ponto (e sobre este não há dúvida),  é que os MOSFETs de saída do HC595 não foram projetados para "drivar" Capacitâncias como a que vc usou em C3. Veja: em geral, as máximas capacitâncias permitidas nas saídas desses CIs HCMOS, não passam de 100 nF (100 nano farads), e ainda assim costuma-se usar resistências em série, para limitar o pico de corrente de carga/descarga. Veja vc usou 470uF, ou seja, 4700 vezes maior que 100nF.  Isto vai "detonando" a saída do HC595, tanto quando o sinal vai de "0" pra "1" como de "1" pra "0".  Além disso, esta Capacitância tão alta, pode chegar a afetar outras partes internas do CI, corrompendo os estados lógicos internos e provocando anomalias no funcionamento.

      Os Fabricantes de CIs fazem de tudo pra tentar diminuir a "Injeção de Carga" nestes CIs (ela é proporcional à capacitância entre pinos dos MOSFETs). E vc aumentou esta injeção a patamares inacreditáveis com esse C3 de 470uF (mesmo embora vc esteja usando um eletrolítico de alumínio, que tem reatância indutiva alta para mudanças rápidas de sinal, se comportando mesmo como um indutor).  Então já sabe. Sem mais comentários.

      Para fazer uma espécie de "fader" no Backlight, há outras técnicas.

      Sobre o MUX 4051 (o correto seria dizer 4051B), há melhorias significativas que podem ser feitas nos circuitos da conexão dos sinais analógicos.  Fazendo estas outras  melhorias, isto também implica em diminuir o valor de R20. Mas seu circuito não está incorreto. Apenas pode ter uma melhoria muito significativa, ainda que simples. Caso queira saber como seria esta melhoria, pergunte aqui.

      Uma sugestão:  considere usar em um futuro projeto, o HC594.  Eu sempre digo isto, mas o povo é de uma teimosia imensa.

      Aconselho ver estes tópicos, que irão te acrescentar um know-how sobre HC595/594:

           link do LDG:   "Multi I/O com HC595/594"

           link do LDG:   "usando HC595"

      Também sou especialista em layout de PCI (em quase 30 anos de trabalho, imagine vc a quantidade que já projetei, inclusive até 6 Layers). Assim, abri seu Gerber no "View Mate" (é gratuito) e olhei bem rapidamente, quase sem analisar. Mas uma coisa que percebi, é que vc não está usando alguns padrões do mercado.  Tudo bem que é um layout particular, e assim vc faz como achar melhor. Mas é sempre bom seguirmos alguns padrões, pois isto pode nos poupar dores de cabeça (algumas bem terríveis).

      Se tiver algo que eu possa ajudar, não deixe de perguntar.

      abrçs,

      Elcids

Olá Elcids, muito obrigado pela sua resposta.

Quanto ao "lixo".ino, peço desculpas. Tenho 5 sketch que utilizo para testes rápidos, nomeados de "lixo 0~5.ino". Com isso, evito de fazer modificações equivocadas ou criar um monte de arquivos desnecessariamente. Em todo caso, para publicar o arquivo, eu deveria ter alterado o nome.

Quanto a velocidade do esp8266, eu não imaginei que isso pudesse ser um problema, tendo em vista que utilizei diretamente com os registradores do esp32 (que acredito ser mais rápido), sem delay, e foi um sucesso. Toda via, meu conhecimento sobre os controladores é bem superficial, limitando-se apenas a funcionalidade, então pode ser que exista alguma questão no meio que eu desconheça (99% de chance disso acontecer).

Sobre o capacitor. Bem observado, não me atentei a este detalhe. Meu pensamento inicial era só para gerar um efeito de "esmaecer", isto é, ao desligar, a tela ir apagando lentamente. Nesse pensamento, eu deveria ter terceirizado o serviço, adicionando um transistor ou adicionado um resistor para limitar a corrente. Fiz o projeto baseado no ili9488 (3.5"), que possui um transistor interno para os leds.

Acreditei que todas as telas tivessem o controle do backlight, entretanto, para minha sorte (ou azar), a tela que chegou (st7735 1.8") não possui o controle do backlight, ao menos através de um pino. Em todo caso, foi um alerta muito importante. Acabei de por até o ferro de solda pra esquentar, para remover logo esse capacitor. Fiquei preocupado, achando que talvez ele estivesse contribuindo também para estes problemas.

"Para fazer uma espécie de "fader" no Backlight, há outras técnicas."

No momento, eu só consigo imaginar 2 formas, a primeira é com capacitor (595 -> diodo -> resistor -> capacitor) a segunda é com pwm (vai caindo de 100->0).  Indicaria mais alguma? Apesar da placa já ta pronta, mas conhecimento é sempre bom, e evita que a gente cometa o mesmo erro novamente.

Sobre o R20

Veja a imagem a seguir (pode abrir para ficar maior)

O esp8266, suporta até 1v no analogico, mas veja na imagem, em especial no canto central da direita, é apresentado a montagem do ADC da placa de desenvolvimento do esp. Existe um resistor de pulldown de 100k e um no sinal de 220k. Isso gera um divisor de tensão possibilitando que receba sinais de até 3v3. 

Como a ideia é obter sinais de até 4v2, seria necessário ainda um novo divisor de tensão. Entretanto, vendo esta montagem, adicionei + 1 resistor, no sinal, de 180k, deixando 400k no sinal + 100k de pulldown. Desta forma, poderia ser utilizado sinais próximos de 5v, gerando uma margem de segurança de 0v5~0v8.

"Se tiver algo que eu possa ajudar, não deixe de perguntar."

1- pq usar o 594 ao invés do 595?

2- Como já questionado: Quais outras técnicas podemos usar para o fade do backlight?

3- "Caso queira saber como seria esta melhoria, pergunte aqui.". Quais seriam as sugestões de melhorias?

4- Sobre os padrões. Sou iniciante na área, um curioso ou hobista, desconheço muita coisa. Vou coletando informações, testando, perguntando, liberando a fumaça mágica dos componentes (como diz RV), e colocando pra funcionar. Mas gostaria de saber: Assim que abriu o arquivo, no primeiro segundo ("Mas uma coisa que percebi, é que vc não está usando alguns padrões do mercado."), o que mais chamou a atenção para a ausência dos padrões? E onde posso conseguir informações sobre os padrões?

A única coisa que costumo colocar em excesso (não me recordo se coloquei nessa), são as larguras das trilhas de gnd. Se o projeto pede trlha de 1A, eu coloco para 3a ou mais. É excesso? Certamente. Mas como não tenho experiência, é melhor sobrar do que faltar. Ainda mais que já ouvi muitos problemas sobre as trlhas de gnd.

=== Pausa para remover o capacitor e testar o seu código ===

Já sem o capacitor, testei seu código, mas o problema persiste.

Algo curioso:

Coloquei o CI_A alternando entre 1 e 0. funcionou perfeitamente. coloquei o CI_B para ter 4 "1" e 4 "0". ficou tudo com zero.

Vou testar várias combinações para tentar trazer mais dados.

olá Tiago.

       Vou seguir de forma enumerada os pontos que vc salientou.

      1)  sobre os nomes dos arquivos, mesmo que sejam "draft",  procure usar nomes mais relevantes, que reflitam o que aquele código faz.

      2)  sobre a questão da velocidade do Processador.  Veja:  no UNO o clock do Processador é de 16 MHz, o que dá um ciclo de 62.5 ns, que é o tempo de execução da instrução mais curta do AVR.  Isto é bem maior que os tempos mínimos necessários para o HC595 (setup, hold, twH e twL,  @5V).  Além disso sabemos que a função "digitalWrite" é bem mais lenta que isso.  Então no UNO não há problemas.  Mas no ESP8266 vc pode estar usando o clock de 80 MHz ou o de 160 MHz, correspondendo a períodos de 12.5 ns  e  6.5 ns,  respectivamente.  Veja que estes tempos podem não atender as especificações de temporização do HC595, caso o código de I/O resulte efetivamente em uma única instrução (o que é perfeitamente possível de ocorrer).  Isto vai depender do Compilador C/C++,  e de otimizações feitas por ele. Uma vez que o código tenha sido lido da Flash para a RAM do ESP8266,  ele executará absurdamente mais rápido que o UNO. Então cuidados devem ser tomados para não depender do resultado da Compilação.  Os tempos de 1us que acrescentei, garantem isso, sem acrescentar um "overhead" no funcionamento do seu Sistema, então aconselho manter essa temporização.

      3)  sobre o Capacitor C3.  Nenhum CI Digital convencional tolera altas capacitâncias ligadas às suas saídas (sejam MOSFETs ou BJTs). E estamos falando de dezenas a centenas de nF (nano Farad). Então imagina esse C3 que vc usou.  A consequência disto, irá variar conforme a tecnologia do CI, podendo apenas causar anomalias no funcionamento,  ou mesmo um dano permanente. Cuidado aqui,  pois danos permanentes nos circuitos internos dos CIs HCMOS,  são extremamente traiçoeiros,  podendo levar vc a confundir o que está de fato causando o problema (o motivo disso é que a coisa é digital, ou seja, se vc estiver no "limiar",  poderá ser decidido para "0" ou para "1", e isto poderá corresponder ou não ao resultado que vc espera, o que certamente vai te pregar uma grande peça, e uma grande dor de cabeça).

      Se vc ligou a alimentação, e acionou de "0" para "1", ou de "1" para "0", aquele C3 pode ter feito um estrago interno no HC595 (ou seja: não se restringe apenas aos dois MOSFETs de saída daquele pino 5),  e portanto este CI não é mais confiável. Então a regra é clara:   elimine o C3, e substitua aquele HC595. Mas veja:  não adianta eliminar C3 e manter o dreno de corrente para o Backlight do Display,  se esta corrente for demasiada para uma saída do HC595. 

      Sobre o "fader", não adianta vc colocar "Diodo-->Resistor-->Capacitor",  pois provavelmente a corrente DC drenada será muito além dos limites do HC595.  Então essa topologia não adiantaria.   Use um MOSFET canal P para drivar o Anodo do Backlight do Display.  Entre o pino do Backlight e o GND, coloque um Resistor de 10k, para fechar o circuito do MOSFET. Acrescente também um Resistor de 1k entre o Source e o Gate do MOSFET,  e outro Resistor entre o Gate e o pino de controle (HC595 ou ESP).  Então vc pode usar PWM para controlar a intensidade luminosa do Backlight,  ou simplesmente fazer um ON/OFF simples. Claro, se usar um MOSFET adequado,  poderá acrescentar uma Capacitância alta como seu C3.  Mas veja:  temporizações são muitas vezes controladas pela constante de tempo "RC"  (acredite: Resistência Elétrica multiplicada pela Capacitância,  resulta em unidades de tempo),  e assim um "RC" adequado em um circuito onde "C" tem baixa capacitância pode eventualmente ser uma opção.

      A outra técnica (que já usei também),  é implementar uma Fonte de Corrente para o Backlight, e controlar esta corrente (pode ser via DAC discreto, aproveitando saídas que estão sobrando dos HC595).  O circuito é simples, mas como sua placa já está pronta, teria que ser feito fora dela.  Isso é mais usado quando há DACs disponíveis na CPU.  A opção do PWM via MOSFET, é mais efetiva e mais simples, e portanto a melhor opção.

      4)  sobre o "R20".  Ficou clara sua jsutificativa. Porém em Projetos não fazemos isso.  O "correto" seria acrescentar um AmpOp configurado como seguidor de tensão após o 4051,  e então fazer o divisor de tensão após o AmpOp, mas usando Resistores entre 1k e 3k3.  Ou seja:  para sinais enviados a um ADC,  não se usa divisores com altas impedâncias. O motivo?  Basicamente dois:  garantir que o sample_&_hold se complete corretamente no ADC,  e impedir que ruídos de alta frequência tenham amplitude considerável em relação do step do ADC (ou seja, garantir uma boa relação sinal ruído,  do contrário pode ser um desastre, pois implicaria em sub-amostragem  e nenhum DSP no planeta conseguiria eliminar esse ruído com pós-processamento digital).

      5)  sobre o HC594 x HC595, peço que veja os links que mostrei no post anterior.  Uma coisa que ajuda vc a entender, é o olhar o circuito lógico interno  dos dois CIs, e certamente isso irá lhe acrescentar know-how.  O HC595 é mais adequado para barramentos tri-state. o HC594 é mais adequado para I/Os convencionais, onde um "PUC"  (Power Up Clear) é desejado.

      6)  sobre o layout.  Rapaz, quase dá pra dizer que não há padrão no seu layout.  Mas isto seria uma injustiça, pois vc pode usar um padrão que vc determinou, e sempre seguir o mesmo em todas as suas placas.  O assunto layout é algo extremamente denso e minucioso.  Há uma infinidade de aspectos a serem considerados.   Além disso, a prática e o tempo de experiência acumulados são essenciais.  Então isso poderia nos levar a pensar:  "ah, então qualquer um que comece a fazer layouts, nunca irá ter bom resultados".  Mas não é bem assim, afinal existem cursos de layout e técnicas para aprender.

      Quando eu carreguei o layer de cobre  "Bottom",  o View Mate já indicou um problema, que mostro na figura a seguir:

(clique nas figuras para "zoom")

      Este problema em específico geralmente ocorre devido a uma distração do layoutista.  Mas se vc usar programas de layout que façam verificação de erros (Design Errors Check), eles irão apontar isso antes, e vc poderá corrigir.

      O Polígono problemático em questão, eu salientei na figura a seguir.

(clique na figura para "zoom")

      Confira ele no seu layout. A versão do Proteus que tenho aqui não abre seus arquivos, pois eles são de uma versão mais recente.  Por isso usei o View Mate para ver o Gerber.  Mas essencialmente, em algum ponto vc "dobrou" o Polígono sobre ele mesmo, e dependendo de onde isto ocorreu,  poderá ou não ser um problema para seu circuito (isto não dá pra explicar aqui, pois estenderia muito).

      A sua placa,  com "Top", "Bottom", "Sold Masks", e "Silk", mostrada na figura a seguir (capturada do Gerber), revela algumas coisas estranhas.

(clique na figura para "zoom")

      Veja no "Bottom" alguns pontos que salientei:

(clique na figura para "zoom")

      Além disso,  nem sempre um sinal correndo paralelo a uma trilha de GND, é a opção adequada, pois isto aumenta a capacitância entre o sinal e o GND, e se a frequência desse sinal for alta, já sabe o que pode acontecer.  Outro exemplo que contraria o que seria corretamente óbvio, é quando vc tem AmpOps de alta-frequência:  colocar um plano de GND ou VCC  logo abaixo dos sinais, provavelmente será um desastre (por exemplo, veja o datasheet do THS4131 neste link ).  Então "espalhar" áreas de cobre de GND pela placa, pode não combinar com alguns circuitos.

      Sobre padrões,  certamente uma coisa que chama a atenção no seu layout,  é a referência para os CIs.  Geralmente se usa "U" para essa referência.  Vc usou o próprio nome dos CIs.  Na indústria isso não seria tolerável, mas como o layout é particular e seu, tudo bem, é vc quem irá usá-lo e assim faz do jeito que achar mais adequado.

      Mas ainda há uma série de outros pontos, que não dá pra abordar aqui, por exemplo as regras de Design.  Eu uso o Eagle,  e capturei algumas figuras para mostrar alguns settings:

(clique nas figuras para "zoom")

      Veja, vc pode especificar os settings. Mas há regras, há limites, há padrões.  Uma fábrica de PCIs que se preze, irá reportar a vc problemas relacionados a esses padrões, antes de iniciar a fabricação, te dando a chance de corrigir esses "problemas".

      Uma boa maneira de aprender sobre layout (além da prática é claro),  é ler "APP-Notes" dos Fabricantes.  Eles são mais curtos para se ler do que livros, e vão mais direto ao ponto, reduzindo o tempo de aprendizado. Bons fabricantes tem muitos "APP-Notes" para isso, como é o caso da Texas (recomendo muito),  Microchip, NXP, e até mesmo Intel.  Geralmente são ótimos.  Mas estão em inglês, e exigem também outros conhecimentos técnicos (principalmente em Circuitos).  Então nem sempre será um caminho fácil, já que é um assunto denso e muito técnico.

      Sobre o problema com o HC595,  vamos torcer pra que seja algo pontual nesta placa.  O mais provável é que seja uma bobagem (estas coisas são muito traiçoeiras e confundem muito, dando pistas erradas).  Mas uma técnica adequada de depuração do Hardware, sempre irá convergir para o problema.

      abrçs,

      Elcids

estava observanso seu projeto, e vi que esta usando o GPIO01 para conectar ao 74hc595, observe que no esp8266 o boot falha na inialização se puxado para baixo.

verifique se o esp realmente esta iniciando ?

olá Rasteiro.

      De fato vc tem razão em relação ao GPIO1.

      No circuito do Tiago,  o GPIO1 é o "CLK" dos HC595, conforme podemos conferir pela figura a seguir:

(clique na figura para "zoom")

      Observe no entanto no circuito, que o sinal "CLK" está conectado a entradas de alta impedância (os pinos 11 dos três HC595). Então isto não influencia algum Pullup que exista no GPIO1 na placa do NodeMCU, e portanto não afeta o BOOT.

      Já sobre o GPIO0, GPIO2, e GPIO15,  não se pode dizer o mesmo, pois estão conectados aos sinais do Display,  e assim vai depender do circuito na placa desse Display, que não sabemos como é.  Mas acredito que não esteja havendo conflito, uma vez que o Tiago afirmou que o Display e outras partes já funcionaram nos testes.

      Ah, te enviei contato pelo email daqui do LDG. Também moro em SJC.

      abrçs,

      Elcids

O display utilizado é este:

https://pt.aliexpress.com/item/32924266468.html?spm=a2g0s.9042311.0...

Mas, está 100% funcional. Entretanto, para minimizar erros, só estou utilizando os mosfest, resistores, 595 e 4051b no momento.

Tiago,

    Nesta placa do Link que vc informou,  não há um sinal para drive do Backlight.  Tem certeza de que é essa mesmo?

    Outra coisa que achei estranho, é que no seu esquemático está constando Resistores de 10k para os LEDs RGB.  É isto mesmo?

    abrçs,

    Elcids

Olá.

Não estou tendo problemas na inicialização, entretanto, como já citado, não é possível fazer comunicação serial, pois os pinos TX e RX estão em uso.

Para subir o código, tenho que remover o 74hc165 ou o controlador, e após isso, coloca-lo no local novamente.

Tiago,

      Vc pode interromper a trilha que liga o "DOUT" do HC165 ao ESP, e interconectá-la conforme a figura a seguir:

(clique na figura para "zoom")

      Com isso, quando for programar,  vc retira o Jumper.  Quando for executar o código, recoloca o Jumper.  Isso é mais fácil que ficar retirando o HC165, mesmo que do soquete, pois em algum momento vc pode danificar ou o próprio soquete,  ou o HC165 com alguma descarga ESD  (não sei onde vc está geograficamente, mas se estiver seco por aí, o ESD é potencializado ao máximo).

       Claro, isto é só para os testes.

      abrçs,

      Elcids

Bom dia,

O ideal seria conferir todo o diagrama do circuito, antes de fazer a placa. 

Você pode colorir com caneta de destacar, as partes do circuito conferidas. Assim que eu faço. 

Não entendi a ligação com o TP4056. 

Porque os 74HC595 não funcionaram? O código estava incorreto?

https://www.arduino.cc/en/Tutorial/Foundations/ShiftOut

Olá abreu, tudo bem? Obrigado pela sua resposta.

Existiu uma falha minha. Conferi, mas meu check não foi bom.

Quanto ao 74hc595 não funcionar, eu também não estou entendendo. A ligação é simples, o código é simples. Vou realizar novos testes e posto aqui o resultado.

Quanto ao Tp4056, bem... foi meio que uma "gambiarra" para realizar minha tarefa. Eu ia usar rele para chavear, mas acabei usando mosfet. E existe um circuito que impede o acionamento dos dois, ao mesmo tempo.

Novo teste realizado.

1- Removi todos os 74hc595

2- adicionei apenas o 74hc595_A (que é o receptor principal).

3- rodei o código, funcionou lindamente.

4- Adicionei o 74hc595_B (referencia ao circuito). 

5- rodei o código. o 74hc595_A continua perfeito, entretanto, o 74hc595_B fica tudo alto ou baixo, mesmo emitindo dados para que ele ficasse intercalado (11001100)

====== EDITADO ========

Realizei um novo teste bem grosseiro. Deixei apenas o 74hc595_B no circuito, e fiz uma ponte, como pode ser visto na imagem. O resultado: pino 15, 1 e 2, low. 3, 4, 5, 6 e 7, high. (sendo que era para ser 00110011)

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço