Pessoal, estou em um impasse em meu projeto de automação. Eu utilizo um esp-01 para controlar o projeto via web conectado via serial a um Arduino uno que, por sua vez, controla vários PCF8574. Porém a comunicação I2C interfere na comunicação serial, o que torna o controle do projeto bem incômodo.

Se eu eliminar o espaço fico sem acesso a internet. Se eu eliminar o Arduino fico sem confiabilidade na questão da memória (utilizo memória EEPROM para guardar algumas informações). Se eu eliminar os PCFs não tenho portas digitais suficientes para o projeto.

Alguma sugestão do que posso fazer? Existe outra forma de comunicação entre o esp e o Arduino?

Exibições: 735

Responder esta

Respostas a este tópico

olá Raphael.

      Há uma enormidade de soluções para seu problema. Este tipo de problema que vc está enfrentando, é comum, e para solucionar, se utilizam técnicas mais avançadas de controle e automação.

      No entanto, faltam informações que realmente possibilitem te dar uma solução realmente efetiva. Vejamos algumas:

     1) quantos PCF você realmente está utilizando? Todos são usados como saída, ou há também alguns utilizados como entradas? Se há I/Os, você está mixando Entrada e Saída em um mesmo PCF?  Nos informe as quantidades:  quantos são fisicamente, quantos são saídas, quantos são entradas, e quantos estão mixados com saídas e entradas.

    2) qual velocidade (9600, 115200, etc) da serial entre Arduino e ESP-01 ?

    3) qual a massa de dados (dezenas, centenas de bytes, etc) é trocada entre ESP e Arduino? Essa massa de dados é assimétrica, ou seja, um envia mais dados que o outro, e qual essa divisão? Com que frequência essa massa de dados circula entre eles (não confundir isso com a velocidade da Serial) ?

    4) está usando algum protocolo padrão usado na troca de dados entre Arduino e ESP, ou vc está usando um protocolo que vc mesmo desenvolveu ?  se vc estiver usando um protocolo que vc mesmo desenvolveu, este protocolo tem algum handshake?

    5) há algum vínculo entre a frequência de troca de dados (ESP e Arduino), e a taxa de atualização do PCF (e eventualmente também leitura de ports deste)?

    6) além da tarefa de atualizar o PCF e trocar dados com o ESP,  no Arduino há alguma outra tarefa sendo feita?

    7) no seu Sistema, vc está usando um módulo comercial com o PCF (uma "plaquinha"), ou no seu Sistema o PCF é apenas um componente convencional ?

    8) há possibilidade de vc usar componentes convencionais no seu Sistema, caso façamos sugestões para substituir o PCF ? ou por especificação, no seu Sistema vc só pode trabalhar com módulos ("plaquinhas") ?

     Então Rafhael, vc fornecendo estas informações adicionais, poderemos ajudá-lo mais precisamente, evitando "tiros no escuro".

      Veja:  não mencionei nada sobre Bibliotecas específicas (sem serem as padrões, como a "Wire"), mas caso esteja usando alguma no Arduino, se possível nos informe. Se também puder passar um "print" da memória usada no Arduino (aquele nas mensagens de compilação), ajudará bem.

     Abrçs,

     Elcids

Elcids, muito obrigado pela rápida resposta. A completude dela me faz ver que, apesar do quanto tenho estudado automação e arduíno sou um completo amador ainda.

Vamos lá.

1) Estou em fase de testes, usando apenas um PCF no momento, mas no projeto final usarei 4 do mesmo. Todos serão I/O.

2) Utilizo 9600 pois tem (estava antes de adicionar os PCFs) me atendido bem. 

3) O ESP é utilizado apenas para comunicação com a internet e a transmissão de dados é bem pequena. Ao receber um sinal ele envia apenas um ou dois bytes ao arduíno via serial que interpreta, faz o que tem que fazer (algumas vezes atualizando algum dos PCFs) e envia um único byte de volta, também via serial ao ESP. Como eu disse, isso vai acontecer todas as vezes que um usuário enviar um sinal via web, no resto do tempo, essa comunicação é nula.

4) Protocolo padrão

5) Além da atualização que o Arduíno faz ao receber certos sinais do ESP ele espera constantemente por algum sinal dos PCFs através de Wire.requestFrom no loop.

6) Gravação e leitura de dados na memória EEPROM.

7) Nenhum módulo comercial. As placas que utilizo eu mesmo fabrico. Na verdade, utilizo um conversor de nível lógico da Robocore na comunicação entre os controladores.

8) Utilizo o PCF pois sei como ele funciona uma vez que o utilizo desde o começo (meu TCC na faculdade). Se tiver alguma sugestão de troca sou todo ouvidos.

Não utilizo nenhuma biblioteca especial. Envio os prints solicitados.

Muito obrigado.

Anexos

olá Raphael.

      Ok, as informações que vc forneceu já ajudam a traçar alguns aspectos para uma tratativa que solucione os problemas que vc está enfrentando. Note vc que eu não perguntei exatamente qual era seu problema, por dois motivos: 1) estes problemas são algo comum de ocorrer, quando não se utiliza a abordagem adequada, e portanto são bem conhecidos, fazendo com que eu já imagine o que está ocorrendo; 2) neste momento, estou tentando ter uma visualização melhor do panorama do seu Sistema, quais recursos e elementos existem nele, como eles interagem entre si, e como este Sistema deve se comportar.

      Logo, o objetivo neste momento é elucidar o seu Sistema, clarificando alguns aspectos do funcionamento dele, e relacionar comportamentos e efeitos colaterais, em abordagens e cuidados mais comuns que se deve tomar em elementos individuais.
      Posteriormente, podemos abordar diretamente as tratativas, de forma que sejam incisivas e com muito alta confiabilidade.

      Iniciando com suas informações preliminares, podemos fazer um Diagrama em Blocos do seu Sistema, ainda assim com algum caráter genérico, pois não estou fixando a quantidade de PCFs:

(clique na figura para "zoom")

      Observe que apesar do Barramento I2C poder ter velocidade de 400 KHz, marquei como sendo de 100 Khz, pois você está conectando apenas os PCF8574, os quais tem a limitação de até 100 Khz no I2C (conforme datasheet).

      Sobre o ESP-01, marquei como rodando a 80MHz (mais usado), já que vc não disse a velocidade (80 ou 160 MHz).

      Sobre a configuração de I/Os dos PCFs, está um tanto genérica (apenas saídas, apenas entradas, e um "mix" de saídas/entradas em um mesmo PCF). O total de PCFs neste Sistema, é "n".

      Finalmente, como provavelmente você estará acionando (On/Off) dispositivos ligados às saídas digitais, e provavelmente lendo status ("On/Off" ou "1/0") via entradas digitais, então marquei desta forma no diagrama.

      Então, vamos comentar cada um dos itens que enumerei no post anterior, de acordo com as informações que vc forneceu, e acrescentando um panorama sobre cada um:

      1) você informou estar usando neste momento apenas um PCF, mas que acabará por ter quatro (e talvez até mais, já que especificações de Projeto podem mudar mesmo durante o andamento das coisas). Bem, isto é o primeiro e principal indicativo de que vc tem de fato uma encrenca, pois um controle adequado deste único PCF no Sistema, não deveria de forma alguma resultar em problema.

      O PCF8574 vai até 100KHz (no I2C). Você pode até aumentar esta velocidade (apenas via código), e provavelmente funcionará (talvez até uns 200KHz, ou até mais), porém estará indo contra o especificado no Datasheet do PCF8574 o que seria um dos primeiros passos para o "dark side".

      Para análise, vamos considerar as transações mais simples do I2C, onde em um ciclo com um dispositivo, ou é enviado um Byte, ou é lido um Byte deste dispositivo. Isto pode ser bem observado na Especificação I2C (ver neste link da NXPI2C Bus Specification), conforme mostrado na figura a seguir:

      Veja que para a transmissão mais simples do "Master" (Arduino) para o "Device" (neste caso o PCF, no I2C chamado de "Slave"), ou seja para enviar apenas um Byte ao "Device", teríamos 20 bits (faça a contagem na figura anterior: "Fig 11"). Façamos o cálculo de quanto tempo leva isso no I2C@100KHztempo de envio = 20/100000 = 200 us (duzentos micro segundos, ou 0.2 mili segundos).

      Na direção contrária, ou seja para ler um Byte do "Device", confira (na "Fig 12") e veja que são os mesmos 20 bits. Logo também gasta-se 200us, ou 0.2 ms.

      Observe que estas transações são cerca de 1500 vezes mais lentas que um I/O convencional no Arduino UNO (instruções "OUT" e "IN" do AVR@16MHz), e cerca de 250 vezes mais lentas que uma transação SPI (SCLK@10MHz). Tendo estas comparações em mente, permite-se avaliar abordagens das soluções e seus resultados preliminares.

      Se essas transações estivessem sendo gerenciadas por DMA, não haveria muito que se preocupar com estes tempos. Mas Raphael, não é o caso no seu Sistema (o UNO não tem DMA). No seu Sistema, a forma como funciona a "Wire" força o código a acompanhar bem de perto a transação I2C que ocorre no Hardware, o que tem um impacto direto na performance de execução do código. Se vc abrir a "wire.c" e "twi.c", vai ficar espantado com toda a tratativa burocrática que é feita para fazer a cadência de controle do I2C. Claro, isto tem seus motivos (filosofia), mas não vou entrar nesta questão.

     Eu ainda não medi o impacto sobre a execução do código no UNO, que essa burocracia toda do I2C tem. Mas quando tiver algum tempo irei medir, a fim de ter dados mais precisos sobre isto. Independente disso, dando uma rápida olhada no código interno das Libs "wire.c" e "twi.c" (isso sem contar a Lib dos próprios dispositivos, como por exemplo um RTC que usa I2C), sabemos que não podemos esperar nenhum código executando como um "foguete" no UNO (que já não é "rápido" por natureza).

      Para cada PCF que vc utiliza, uma transação ocorre para atualizar as saídas ou para ler entradas. Se um PCF tem um "mix" de entradas e saídas, então para cada PCF assim, pode-se dizer que ocorrerá no mínimo duas transações (uma para ler, outra para escrever). Então, aqui já temos um ponto para abordar na tratativa, onde considera-se também o gerenciamento da taxa de atualização dos PCFs (o que já deu pra perceber, tem tudo a ver).


      2) Você disse estar usando 9600 bps entre Arduino e ESP. Não é porque seu Sistema trabalha e controla "elementos" lentos (como Motores, Relés, Chaves, etc), que seu Sistema deve ser "taxado" para baixo em termos de velocidade de comunicação. A taxa de 9600 é considerada uma das mais baixas. Será ela adequada neste caso? Isto depende do que mais há no seu Sistema, e do impacto que estas "outras coisas" tem na execução do seu código.

      Nessa velocidade de 9600, um Byte será transmitido ou recebido em cerca de 1ms (faça a s contas: [1 start bit + 8 bits dados + 1 stop bit]/9600 = 10/9600 = ~1ms) . Parece rápido, principalmente porque o Hardware da UART do Atmega328 (assim como no ESP) gerencia o streaming de bits na transmissão/recepção (claro, no I2C também é assim). Porém, vc não pode esquecer que assim como ocorria no I2C, também há uma burocracia associada à Serial, e ela não deve ser ignorada (esse é um erro quase fatal, dependendo das suas necessidades de transferência de dados e do Protocolo usado).

      Para mostrar parte desta "burocracia", sem entrar em análise de código em Libs, vamos dar uma olhada na função "Main.c" do Arduino, que é a "mãezona" que cadencia a execução de seu código no Arduino. Lá esperamos encontrar um código de inicialização, um código em loop infinito, e algumas coisinhas mais. Vejamos:

     Vemos que há algumas funções de inicialização ("init", "initVariant", etc), uma das quais é o "setup" do Arduino que conhecemos bem. Depois disso, o código do Arduino entra no "for(;;)", que é um loop infinito. Dentro desse "for", encontramos o famoso "loop" do Arduino, que o mundo Ocidental e Oriental adora como se ele fosse um Faraó do Egito ou Deus Asteca.


      Uma vez dentro da função "loop", temos "total" controle (pelo menos é o que todo mundo pensa, né?). Mas note, o que ocorre depois que se encerra um ciclo de execução da função "loop": há um "if", onde o código no Arduino vai dar tratamento para eventos da Serial ("serialEventRun"). Isto é apenas parte da burocracia que mencionei sobre a Serial. E vc não tem como evitá-la: ela vai consumir clocks de execução do seu Processador. Pode parecer que isto é um prelúdio do fim pras nossas esperanças. Mas não é.

      Sabendo adequar de forma favorável a temporização do seu Sistema, e tendo uma taxa de bits também adequada (Serial), você pode garantir um funcionamento "suave", sem trancos e barrancos. Neste caso específico da Serial, é quase imprescindível que o Protocolo entre Arduino e ESP tenha sido implementado de forma adequada. Do contrário...


      3) como vc informou que a "massa de dados" entre Arduino e ESP é mínima e esporádica, isso é uma enorme boa notícia para vc, pois implica que é relativamente muito tranquilo e fácil de se fazer a temporização adequada que mencionei acima (item "2"), de forma a garantir o funcionamento "suave" sem trancos e barrancos no seu Sistema. Se no entanto a "massa de dados" fosse centenas de bytes por transação, aí a coisa mudaria de figura, mas não é este o seu caso.


      A questão de haver comunicação esporádica, acrescenta ao seu Sistema, um elemento que chamamos tecnicamente de "Evento Assíncrono", o que significa que durante o funcionamento do seu Sistema e respectiva temporização, ele deve ser capaz de tratar qualquer evento relacionado à comunicação entre o Arduino e ESP, independente do momento em que isto ocorra, e de forma eficiente, pois do contrário poderá prejudicar qualquer outra tarefa que esteja sendo executada no momento em que o evento assíncrono ocorre, comprometendo a confiabilidade do funcionamento.

      Para isto, muitas vezes é preciso não somente olhar com cuidado as tarefas de gerenciamento da comunicação, mas também olhar com mais atenção ainda, as demais tarefas sendo executadas, e analisar qual seria o impacto se uma destas tarefas fosse "interrompida" por um evento assíncrono, ou analisar se o gerenciamento necessário para tratar esse evento pode aguardar até que a tarefa seja concluída (ou pelo menos a parte "crítica" dela).

     Neste ponto, vai aparecer muita gente aqui (e por aí afora) dizendo pra vc:  "ah,  usa logo um RTOS que resolve seu problema". Já vi muita coisa semelhante sendo dita. De fato, é quase certo que o uso de um RTOS ajuda muito nisso. Mas é o que vc procura? ou será que vc quer não somente ver seu Sistema funcionando, mas também ter o prazer de dominar as técnicas adequadas e poder sentir que aquilo tudo está nas suas mãos. Aí é com vc, né Raphael?

     Mas já te digo: é relativamente fácil implementar seu Sistema sem precisar de um RTOS, e ainda assim ele se manter simples e eficiente. Além disso, o ESP já funciona (mesmo que vc não perceba e não use explicitamente) sobre a "casca" de um RTOS, e isso não é a solução escancarada na nossa cara, e nem foi até o momento a solução para seu Sistema. Mas e quanto ao Arduino UNO que tem baixa performance de execução, um RTOS funcionará de forma eficiente nele? essa é outra questão que não abordarei, para não destoar mais ainda aqui, mas vc pode pensar (ou pesquisar) sobre isso, sem esquecer que o Arduino não é apenas Hardware e Código, ele é todo um Sistema, com uma infinidade de dispositivos e módulos disponíveis no mercado para uso imediato, em uma Plataforma aberta, com abrangência praticamente imensurável. Atente pra isto: qualquer coisa funciona no Windows? sim, desde que esta coisa se adeque e respeite as regras do Windows. O mesmo vale para um RTOS (o Windows é um deles).

      4) vc disse que está usando um Protocolo "padrão" entre Arduino e ESP, mas não disse se há algum "handshaking" nesse processo, e por conta disso tenho que desconfiar que vc não está usando um Protocolo de fato, uma vez que qualquer um deles bem sedimentado, tem "handshaking". Acredito que o que vc está entendendo como Protocolo, é o enviar e receber Bytes via Serial do Arduino e ESP. Mas isso não é um Protocolo, isso é o "streaming" de dados entre Hardware/Firmware.


      Usar um Protocolo, mesmo que seja um muito simples e desenvolvido por vc, é quase imprescindível para que seu Sistema funcione de forma confiável, e novamente: sem trancos e barrancos.
      Há duas coisas antagônicas entre si a respeito de Protocolos de Comunicação: primeiro, eles são uma chatice (porque cada um faz o seu e quer que ele seja engolido guela abaixo de todos, tornando o Mundo cada vez mais complicado), e segundo: eles são sensacionais (porque vc tem a liberdade de fazer o que é adequado para vc, eventualmente sem depender de nenhum outro Protocolo já zanzando por aí).

      Pelo que vc informou no item 3, sobre a "massa de dados", parece claro que vc precisa de um Protocolo simples e eficiente. E felizmente, isto é bem fácil de se fazer (dada a simplicidade dos elementos no seu Hardware), e tornaria o seu Sistema praticamente 100% confiável. E claro, isto contribuiria para a execução suave do seu código, mesmo que diversas tarefas estejam sendo executadas nele (a única questão mais delicada e que exige mais atenção, que vejo neste momento, é a Gravação de dados na EEPROM, mas dando a tratativa adequada, não há com que se preocupar).

      5) ok, eu já imaginava que seria algo assim como vc descreveu, devido à informações que vc passou no item "3". Aqui há duas abordagens semelhantes.
A primeira é que o recebimento de dados via ESP, força vc a atualizar de forma sistemática (e como se fosse em "tempo real"), os PCFs configurados como saídas. Algo tranquilo, mas que vincula o "Evento de Recepção" via ESP, à atualização pontual dos PCFs, e este vínculo tem que ser bem tratado para não causar um "lag de tempo" estranho ao mundo real.
      A segunda, é que dados lidos dos PCFs devem ser enviados ao ESP via Serial. Vc não deixou claro, se os dados são enviados rotineiramente em uma taxa constante (e portanto interpretados exclusivamente por quem receber estes dados), ou se uma mudança de estado nos Ports de Entrada dos PCFs, dispara um evento que deve ser interpretado e sinalizado através de envio de dados ao ESP via Serial. Claro que a tratativa para estes dois casos é semelhante, mas não é igual, porque uma envia dados numa taxa constante enquanto a outra envia dados devido a um "Evento Assíncrono" (nota: o fato de o "Wire.requestFrom" estar dentro do "loop" do Arduino, não é conclusivo sobre isso). Eu ressaltei esta diferença, porque se for um evento que exige interpretação e cause efeitos mais complexos e pesados em termos de processamento, deve-se tentar desvincular a leitura de dados (do PCF), da tratativa de eventos relacionados aos dados, e do envio de dados propriamente dito (claro: sempre que isto for possível). Não se assuste achando que isso parece complicado, pois não é.

      Sobre o uso do "Wire.requestFrom", tudo bem. Eu tenho usado I2C no Arduino apenas através das Libs de módulos, como por exemplo de RTCs e Displays, e estas Libs já fazem uma tratativa própria, a qual quase sempre não possui a melhor performance. E elas raramente tem algum "callback" que possa ser setado (possivelmente elas usam algum "callback", mas restringem seu uso dentro delas, de forma que a implementação da Classe torna isso "invisível" para nós).


      Um "callback" geralmente está associado a alguma Interrupção do Processador, de forma que é chamado como resultado de algum "hook" que esteja ou dentro da respectiva ISR, ou após o término de um ciclo de execução da função "loop" do Arduino (neste caso, dentro da ISR é setada uma "flag" indicadora de que o "callback" deve ser executado após o "loop" do Arduino). E não se iluda achando que porque vc não conectou o pino "INT#" do PCF a um pino de IRQ do Arduino, não estão ocorrendo Interrupções resultantes do funcionamento do I2C. Veja o capítulo sobre "TWI" no datasheet (versão "full") do Atmega328, e vai obter a resposta a isso (claro, a resposta é bem óbvia, mas se puder ler e aprender sobre isso...).

      Mas por que estou falando sobre isto? Simples: se puder usar alguma forma de "callback" (seja onde for que ele seja chamado), vc poderá setar uma "flag" dentro desse "callback", sinalizando assim um Evento ocorrido ou detectado, e dessa forma estaria tratando o evento de forma assíncrona à ocorrência dele, mas ainda assim rápido o suficiente para parecer "suave" ao mundo real. E claro: o tratamento assíncrono a esta Evento (indicado pela "flag" setada), estaria em perfeita harmonia com todos os outros elementos existentes no código do seu Sistema (incluindo o próprio envio/recepção via Serial para o ESP). Observe que nem sempre é adequado fazer processamento dentro de um "callback", porque muitas vezes vc não sabe de onde ele será chamado. Então usando uma "flag", vc pode isolar a tratativa com total segurança, encaixando-a numa tarefa que concorra de forma controlada com as demais tarefas no seu Sistema, e assim obtendo um funcionamento "suave".

      Por favor: não pense que isto é complicado. Não é. Quando se faz a implementação disto, se constata que é simples (e depois o trabalho pesado fica por conta das Máquinas). É com técnicas assim que se projeta Máquinas para o mundo real (ou pelo menos deveria ser, já que algumas por aí afora funcionam a trancos e barrancos e eventualmente tem comportamentos esquisitos). Pode parecer complicado, mas é apenas aparente, como já dizia nosso grande e saudoso mestre Bêda Marques.

      A coisa pode parecer se resumir em apenas escrever dados nos PCFs e ler dados dos PCFs, mas pode haver muito mais coelhos nesta cartola do que parecia inicialmente. Mas isso não significa a existência de algo complicado (como eu disse antes, não é).

      Continua no post seguinte, para não estourar a capacidade de texto de um post único.

      Continuação do post anterior:

      6) a tarefa de ler dados da EEPROM, é facilmente encaixada junto aos outros processos do seu Sistema (comunicação com ESP e controle dos PCFs), pois nenhum cuidado especial é requerido.
      Já a gravação da EEPROM, embora também seja uma tarefa simples (pois existe apoio de Hardware na CPU AVR), requer algumas atenções. Mas nada pra se preocupar, e também é facilmente encaixada junto aos demais processos do Sistema.

      Mas acho que vale a pena citar alguma coisa aqui sobre estes cuidados com a gravação na EEPROM, que são essencialmente dois. Primeiro, sobre as funções da Lib do Arduino: há meia dúzia de funções, e quatro dessas são para gravação, e embora as quatro tenham como objetivo gravar dados na EEPROM, há ligeiras diferenças entre elas que seria bom você conhecer, e principalmente explorar de forma que o processo de gravação contribua para o funcionamento harmonioso do seu Sistema, além de aumentar a confiabilidade do próprio processo de gravação com o passar do tempo (a vida útil da EEPROM do Arduino, é taxada em 100 mil ciclos de gravação). Segundo cuidado: ver as recomendações sobre o processo de gravação, que estão descritas no datasheet (versão "full") do Atmega328, que essencialmente tratam de Hardware, mas que tem efeito no que vai acontecer no seu Sistema a nível de código. Para evitar que problemas de Hardware impactem na gravação de dados na EEPROM, é preciso aplicar algumas técnicas simples (o que vale para a Flash também), de forma a ficar imune a estes problemas de Hardware. Aparentemente, o que vc está gravando na EEPROM, é alguma espécie de "log" (mesmo que sejam apenas dados, valores), e portanto parece sensato seguir estes cuidados, se vc quer confiar neste "log" gravado.

      7) sobre a plaquinha conversora de níveis lógicos, é uma boa solução para interfacear com o ESP. Eu odeio ter que dizer isto, mas infelizmente é verdade, e preciso dizer (claro que se me prenderem por isso, depois o Gilmar Mendes vai mandar me soltar, como é hábito dele). Sou a favor das plaquinhas conversoras e eu mesmo tenho uma (embora nunca tenha utilizado), mas tenho que dizer que elas não são a forma mais adequada de interfacear estes dispositivos. Há CIs próprios pra isso, ou seja, que foram projetados com esta intenção, e são de baixo custo inclusive. Mas devido aos problemas de disponibilidade do mercado brasileiro (e infelizmente às altíssimas taxas de importação para produtos de alta tecnologia que não há a menor perspectiva de serem fabricados no Brasil), estes CIs nem sempre são uma opção prática e viável.

      Atente que estas plaquinhas conversoras, trabalham com uma base de "pullups". Para sinais estáticos, como por exemplo se vc ligar um sinal do Arduino ao "RESET#" do ESP (com a intenção de resetar o mesmo), não há com que se preocupar muito, a não ser garantir que o "pullup" da plaquinha não prejudique severamente um eventual "pullup" intrínseco que já exista no seu Hardware, e assim altere a constante de tempo de algum circuito "RC" de forma a causar mal funcionamento.
      Já para sinais dinâmicos, como é o caso do TX e RX da Serial (em ambos os lados: do Arduino e do ESP), estes "pullups" podem vir a causar grandes problemas de funcionamento, caso a velocidade de comunicação seja alta (acima de 1 Mbps por exemplo). Como seu Sistema usa 9600 bps na comunicação entre Arduino e ESP, não há com que se preocupar. Mas se em algum outro Projeto estiver usando altas taxas de bps, considere usar conversores próprios, ou seja, CIs projetados para isso (há uma infinidade deles).

      O fato de vc fabricar suas próprias placas, é ótimo. Além disso sinaliza alguns pontos: vc é um grande guerreiro (daqueles que fazem suas próprias armas), e vc tem uma grande flexibilidade no seu Sistema e pode usar isso para obter a solução mais adequada para seu caso (não ficando preso a algumas limitações de Hardware que existem quando se utiliza apenas os "breakout boards" da vida). Acho que vc fabricar suas placas é definitivamente um ponto muito alto em seu projeto.


      Mas atente: no mundo profissional, fabricar placas não se resume a desenhar as mesmas e mandar corroer o cobre. O processo é muito além disso, e há situações que exigem todo um know-how profissional para o desenho do layout, como por exemplo um tratamento adequado para evitar problemas graves de EMI (que quando ocorrem, podem ser o inferno na vida de um Projetista, e o desenho da PCI é um elemento chave para controle do EMI). Mas neste estágio atual das coisas, isso não precisa ser levado em conta.

      8) o PCF que vc está utilizando, acho que foi uma ótima escolha. Ele utiliza o I2C e isso torna muito simples a conexão de Hardware. O I2C usando apenas dois sinais (SCK e SDA), poupa pinos do Arduino, que podem ser destinados a outros dispositivos onde o I2C não é uma opção técnica ou comercial. Cada PCF proporciona de forma fácil, 8 sinais de I/O, os quais podem ser configurados à vontade, e até mesmo reprogramados durante o próprio funcionamento do seu Sistema. Cada pino configurado como saída, tem uma boa capacidade de corrente (10mA, restrito ao nível "0"), permitindo acionar diretamente Transístores Bipolares de Potência (tipo PNP, justamente devido à corrente maior no nível "0" na saída do PCF), e LEDs de sinalização. E há ainda outras características interessantes (como por exemplo o fato de que eles podem ser alimentados com 3.3V).

      É claro que o PCF tem também limitações (como praticamente tudo). A principal é o fato de que o I2C é um barramento considerado "lento", e isto pode impedir seu uso em algumas aplicações. Por exemplo, suponha que vc tenha que gerar um pulso de disparo digital de 10us. Certamente o PCF não poderá ser utilizado para isso, uma vez que o intervalo de tempo entre atualizações consecutivas das saídas do PCF via I2C@100Khz, é bem maior que um pulso com duração de 10us. Mas são raros os casos com necessidade de temporizações assim, e portanto acaba sendo quase irrelevante esta limitação. No entanto é preciso saber que ela existe, pra não descobrir isso apenas depois que já se montou o Hardware (pra evitar esse esquecimento, simular seu Sistemas em simuladores como o Proteus, ajudam a pegar estes deslizes, sem precisar gastar tempo e dinheiro com uma montagem física que tenha sido concebida sem se perceber o problema antes).

      Há alternativas? Certamente. Mas assim como ocorre com o PCF, elas também terão suas próprias limitações. Neste caso, não vou ficar citando exemplos aqui, pra não estender a questão ainda mais. Mas veja que um Projetista tem que ter cartas na manga, sempre. Ou seja, ele tem que conhecer anteriormente, alternativas para pontos fundamentais em seu Projeto. Do contrário, pode se ver em uma "sinuca de bico" (ou "no mato sem cachorro").

      Eventualmente, conhecer alternativas, é a única forma de resolver um problema. Então isso pode vir a significar o sucesso ou não de um Projeto.

      No estágio atual, é interessante que você tenha contato com soluções simples, que eventualmente possam ser usadas em algum momento. Mas se vc fizer isso, estas soluções precisam ser bem dominadas, para que vc realmente possa tomar a decisão de forma efetiva, ou seja, com total confiança na sua escolha.

      Há um tópico aqui no LDG, onde postei uma solução muito interessante e versátil. Naquela solução, tanto a concepção do Hardware como a do Código, acredito que te acrescentará algo. No entanto atente pra isso: naquela solução não é implementada uma "Aplicação Final", pois não era esse o objetivo. A solução lá implementada, tinha como objetivo prover recursos de Hardware e Firmware, e neste sentido ela está bastante completa. Ou seja, provendo estes recursos, cada um pode usá-los da forma que desejar. Inclusive, é possível usar plenamente estes recursos em uma implementação como a sua e implementar na "Aplicação Final", uma temporização harmoniosa que seja necessária.

      Está disponibilizado naquele post, os arquivos para simulação, o que eu incentivo completamente testá-los, para se poder sentir o que vc pode fazer ali, e os resultados que podem ser obtidos. Anexados, há também outros documentos, além obviamente do próprio código fonte. Se possível, não deixe de ver, e atente principalmente para as temporizações que coloquei no post, pois elas são extremamente importantes.
      O link daquele post é este:  Sistema Multi PIO

      E para te incentivar a olhar aquele post, segue o print do Hardware daquele sistema:

(clique na figura para "zoom")

      Mas há outros posts, que podem te acrescentar uma pitada de abertura de mente, sobre a implementação de Sistemas de Controle. Especificamente, estou falando de implementar Máquinas de Estado, de forma Sistemática, extremamente simples, e de altíssima confiabilidade. Nestes posts, quase sempre implemento Máquinas de Estado que funcionam no ritmo de Interfaces Homem-Máquina (é uma chatice falar "IHM", pois eu não sou adepto de modismos), pois a implementação é para atender questões publicadas aqui no LDG que são praticamente sempre relacionadas com IHM.


      Mas se nestes posts, vc entender como estas Máquinas de Estado funcionam e ficar claro a técnica sistemática de implementação, vc poderá fazer o mesmo sob um outro aspecto ainda mais sensacional e igualmente simples: Máquinas de Estado que Interfaceam com outras Máquinas de Estado. Raphael, veja que este é o caso do seu Sistema, onde vc tem um Arduino interfaceando com o ESP, que por sua vez tem uma interface com uma outra Máquina remota (na sua rede WiFi ou mesmo na web).
      Assim, seguem os links destes posts:

     e há este, onde algumas temporizações interessantes foram implementadas, sendo um ambiente com maior quantidade de elementos: link  Feed Dog

**********************************************

      Um comentário final, relacionado aos prints da utilização de Memória do Arduino e ESP que eu pedi a vc. Por estes prints, parece realmente que vc está no início de tudo, pois nos códigos resultantes (Arduino e ESP) não foi utilizado uma imensa quantidade de memória (seja para código ou dados). Não que seu Sistema deva resultar em códigos gigantes. Não é isso. Ocorre que o tamanho resultante até este momento (mesmo sem usar Libs pra todo lado, como vc salientou), sugere que possivelmente vc ainda implementará muitas outras funções e "features", que seguramente consumirão mais memória. Sobre isso, é importante conhecer algumas técnicas, especificamente como usar de forma eficiente a memória disponível no Sistema (não me refiro àquelas técnicas que vc encontra fartamente na web), e consequentemente também alcançando outras vantagens, como melhor performance. Mas nada imprescindível neste estágio das coisas, mesmo porque me parece muito bom o resultado de sua compilação em termos de uso de memória. Mas tenha em mente que o resultado do uso de Memória, é um "raio x" do uso adequado dos recursos de Hardware e da implementação harmoniosa entre os processos existentes no seu Sistema (por isso eu pedi que vc mostrasse os prints, para poder ter uma ideia desse "raio x").

**********************************************
**********************************************

      Há dois Sub-Sistemas no seu Projeto: o do Arduino e o do ESP. Claramente, o Arduino é o Sub-Sistema que precisa grande atenção (porque os PCFs estão conectados a ele, e porque o ESP é de 32 bits e roda a 80MHz tendo uma performance muito além daquela do Arduino e isto ajuda muito). Mas é certo que uma parte da tratativa se estende ao ESP também.

      Com todos estes aspectos que foram enumerados neste post, já é um início para uma tratativa adequada para seu Sistema. Para abordar e fazer isso, é preciso conhecer mais claramente o estágio em que as coisas estão no seu Projeto, para evitar todo um retrabalho (ou mesmo descaracterização) e consequente desgaste.

      Sobre sua afirmação de que vc "é um completo amador", entenda que todos somos. Estamos sempre em constante aprendizado (só não estão aqueles que terminantemente se recusam a isso). O que muda entre uma e outra pessoa, é o tempo de estrada, que sempre será diferente. E esta diferença no tempo de estrada acaba por se traduzir em experiência e know-how (e acaba dando níveis diferentes de confiança a cada um, embora isso não tenha tanto peso). O mais importante nisso tudo, é querer seguir em frente, vencer desafios e alcançar novos patamares. E a força de vontade, em 99,9% das vezes, sempre é maior quanto mais jovem se é, e tem que ser assim, não é?

      Abrçs,

      Elcids

Boa tarde Raphael . 

Minha sugestão - esqueça o Arduino ! Use vários PCF8574 diretamente conectados no ESP-8266.

Mas sugiro que use uma placa NodeMCU-ESP12 .

http://blog.eletrogate.com/nodemcu-esp12-introducao-1/

E a alimentação tem que ser 3,3V . O que pretende controlar com tantas portas digitais ? 

Eu já usei PCF8574 (3,3V) com ESP32 e funcionou perfeitamente. 

https://www.elektormagazine.com/labs/esp32-digital-voltmeter

OBs: o ESP8266 também tem memória não volátil para armazenar dados ( muito mais que a EEPROM do Arduino). 

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço