Duvida sobre mux 4051 e 4076

A todos, salve!

Gostaria de compreender melhor o uso do 4051 e 4067 para criação de novas portas.

Pelo que li o 4067/4051 usam o analogico 0, para fazer sincronia, consigo usar na analogica 0 mais de 1 integrado? Ou isso pode ser em qq outra porta?

Se alguem puder me explica, fico grato!

Pretendo usar o 4067 x 2, afim de liberar as portas necessarias, irei utilizar nelas sensor de distancia/rgb/audio acionamento de leds, é possivel?

O 4051 é um mux/demux analógico, onde você endereça um pino, e esse pode funcionar como entrada ou saída, o 4076 pelo que entendi, não é um mux/demux analógico, mas mais para um roteamento de sinais digitais.
Se você quer ampliar as entradas analógicas o melhor seria o 4051, onde 3 pinos digitais do arduino seriam para endereçamento, usando mais 1 pino para controlar 2 4051 e acrescentando 1 pino para cada outro 4051 que você quiser conectar no pino A0 do arduino.
Se você fosse usar 4x 4051 teria 32 fontes de sinais analógicos mas teria q usar 7 pinos digitais (ou usar um 74595 que você usaria apenas 3 pinos digitais e poderia ter 40 fontes de sinais analógicos)

Compreendo, preciso multiplicar o numero de portas de saida e tambem entrada de sinal. Eu acho muito material falando dele e pouca coisa falando do 4051 e 4076.

Vc acredita que o melhor seria 74hc595?

Usando o 4051 para multiplexar as entradas analógicas vai ter q usar no mínimo 4 pinos digitais para controlar 2x 4051, com o 74595 você ainda ganha de borla as saídas digitais, 4 se usar apenas 1x 74595 ou quantos for
74595 forem necessários para saídas digitais.

mmoscz, obrigado.
Já comprei o 74595, amanha devo receber ele. Entre hoje e amanha vou procurar desenhar como vai ficar, isso, devo montar um circuito com 2(ou 3) deles, já seria o suficiente e preparar para conectar tudo que preciso.

Creio que irei trabalhar:
34 Servos (pq, torque 1.2kg);
4 Servos de metal (torque de 12kg ou +);
5 Motores com Reduçao; (Ponte H 2motor circuito)
3 Motor de passo; (Sild Stepper Driver)
1 Sensor RGB;
1 CMUCam4; (se conseguir comprar)
1 (a 3) LDR;
1 Sensor de distancia;
e mais alguma coisa que nao me lembro agora!

:stuck_out_tongue:

Acho que vais precisar de algo mais complexo que um arduino e muxes... ou talvez menos complexo.

Pode testar com um desses tbm..

http://sanguino.cc/

Hoje faço um teste de mesa (planejamento detalhado)e defino em exato o total das portas!

Testei o 74hc muito bom, agora preciso compreender como definir se on/off cada uma de suas portas, tudo que achei na internet usava cont... bom vou estudar + um pouco e chego lá!

KORSH:
Testei o 74hc muito bom, agora preciso compreender como definir se on/off cada uma de suas portas, tudo que achei na internet usava cont... bom vou estudar + um pouco e chego lá!

Mas você usou a função shiftOut() http://arduino.cc/en/Reference/ShiftOut

mmosczValeu a dica!

Sim os testes que fiz usam shift.

Na verdade estou precisando ler para compreender melhor e sacar como combinar o 74hc com as outras portas, tipo dar comandos para ele e para outras coisas, e tudo que vi falando sobre 74hc sempre trata eles individualmente e em Loop.

Eu criei uma classe que atende ao meu propósito, pois uso apenas 2 74595, onde eu apenas mando ligar ou desligar uma saída e ela cuida do controle. Logo que tiver tempo vou implementar para poder definir quantos 595 estarão sendo usados.
Dá uma olhada nela, talvez ajude a clarear o que pretende

Output595.cpp (1.34 KB)

Output595.h (1.14 KB)

keywords.txt (62 Bytes)

mmoscz
Opa Clareou sim. Muito Obrigado!

Pelo que eu li, no seu projeto vc define o que cada porta vai fazer (de 0 a 13) e depois vc entra com a informacao (porta) que vc quer que ele ative ou nao, correto?

Preciso de algo nesse estilo mesmo, porem eu defino na execução mesmo qual porta liga ou desliga e ao mesmo tempo vou tratando outras rotinas como acionar uma ponte H.

Vou ler reler melhor o seu script.

Essa parte do PULSO é que uso num projeto onde simula um PUSH-BUTTON, então apenas aciona (vai para HIGH) e depois de algum tempo, ele desliga sozinho (vai para LOW), esse foi o grande motivo para criar a classe e abstrair esse tipo de controle no scretch principal.
Estou até pensando em ver se consigo usando alguma função INTERNA (algum timer interno do AVR) para não ter que colocar o .watchDog() na função de loop.
Eu criei no meu scretch até uma função chamada vdigitalWrite

void vdigitalWrite(int PIN, int State)
{
if (PIN < 20)
{
digitalWrite(PIN, State)
}
else
{
PIN = PIN - 20;
Controle.SetaSaida(PIN, State);
}

E não uso a função digitalWrite somente a vdigitalWrite

mmoscz:
Estou até pensando em ver se consigo usando alguma função INTERNA (algum timer interno do AVR) para não ter que colocar o .watchDog() na função de loop.

terás de ocupar mais um timer... o problema é que tendo já o millis a ocupar o T0... ias ficar sem outro para, basicamente, fazer a mesma coisa.

Mas será que há alguma maneira de fazer isso? Sei que os atmega parecem ter dois Timers internos. Que inclusive são compartilhados para executar os PWM, ainda não fui a fundo nisso;

3 timers internos.

é possível... a maneira mais simples, para mim, de fazer isso seria criar um "motor" de IO.
Ou seja, definias uma interrupcão de x em x ms que lidaria com as entradas e saídas mediante a definicão que metesses. Um pouco como fazem os PLC, carregam o estado das entradas para registos internos, correm o programa uma vez, mandam o resultado do programa para as saídas e repetem o ciclo. No arduino, não funciona assim... e como tal torna-se um pouco mais "difícil" de o fazer.

Tendo uma interrupcão temporizada de, imagina, 10 em 10 ms (nota que tinhas de garantir que o ciclo completo do teu programa seria menor que este valor) para ver o estado das entradas e saídas, podias definir que querias que uma entrada apenas fosse lida como um se estivesse ligada permanentemente durante 3 ou 4 ciclos (debouncing) e no caso das saídas podias definir que a saída estaria ligada durante X ciclos.

O problema disto é que para fazer de forma bonita em C++, vai levar imensos recursos (memória e tempo de ciclo do Arduino)... logo para poupar recursos, deve-se usar a mesma estratégia, mas de forma mais simples, isto é em C puro e nada bonito. Mas isso é um compromisso que depende de sistema para sistema. :\

Não compensa o trabalho, vai ficar assim mesmo.