Já criei um tópico no Forum do ESP32, mas se alguém quiser e puder me ajudar ficarei grato ! 

https://www.esp32.com/viewtopic.php?f=19&t=11261#p45725

Em fevereiro de 2018, eu rodei o Sketch (arduino IDE) no meu projeto - voltímetro digital ESP32 e funcionou perfeitamente - Arduino IDE 1.8.5 e ESP32 Board versão 1.0.0. 


A comunicação do voltímetro digital é feita com o chip PCF8574 através da interface I2C.

 Resistores de Pullups são 3K3 ohms (VCC = 3.3V) 

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

https://github.com/Gustavomurta/ESP32-DVM

O sketch completo para teste do voltímetro ESP32 é esse :

https://github.com/Gustavomurta/ESP32-DVM/blob/master/ESP32_DVM7135...

Agora, com o Arduino 1.8.9 e o ESP32 Board versão 1.0.2, a interface I2C funciona em um modo louco. O pino SCL envia pulsos contínuos e o SDA envia dados errados (verificados com o analisador lógico). 


Meu ESP32 é DOIT ESP32 DevKit V1 e o hardware está OK e verificado com meu scanner I2C. (baseado em Nick Gammon). 

https://github.com/Gustavomurta/ESP32-DVM/blob/1bc07438e89eac39ae83...


Pesquisando este problema com a opção Debug (Arduino IDE), encontrei essas mensagens, mas não sei o que significam :

debugFlags=0x00000000
[I][esp32-hal-i2c.c:311] i2cDumpDqData(): Debug Buffer not Enabled
[I][esp32-hal-i2c.c:354] i2cDumpInts(): Debug Buffer not Enabled
[D][esp32-hal-i2c.c:1336] i2cProcQueue(): Busy Timeout start=0x303a4, end=0x303a4, =0, max=50 error=0
[E][esp32-hal-i2c.c:318] i2cDumpI2c(): i2c=0x3ffbebe0
[I][esp32-hal-i2c.c:319] i2cDumpI2c(): dev=0x60013000 date=0x16042000
[I][esp32-hal-i2c.c:321] i2cDumpI2c(): lock=0x3ffb84ec
[I][esp32-hal-i2c.c:323] i2cDumpI2c(): num=0
[I][esp32-hal-i2c.c:324] i2cDumpI2c(): mode=1
[I][esp32-hal-i2c.c:325] i2cDumpI2c(): stage=3
[I][esp32-hal-i2c.c:326] i2cDumpI2c(): error=0
[I][esp32-hal-i2c.c:327] i2cDumpI2c(): event=0x3ffb8570 bits=0
[I][esp32-hal-i2c.c:328] i2cDumpI2c(): intr_handle=0x3ffb85a0
[I][esp32-hal-i2c.c:329] i2cDumpI2c(): dq=0x3ffb854c
[I][esp32-hal-i2c.c:330] i2cDumpI2c(): queueCount=1
[I][esp32-hal-i2c.c:331] i2cDumpI2c(): queuePos=0
[I][esp32-hal-i2c.c:332] i2cDumpI2c(): errorByteCnt=0
[I][esp32-hal-i2c.c:333] i2cDumpI2c(): errorQueue=0
[I][esp32-hal-i2c.c:334] i2cDumpI2c(): debugFlags=0x00000000

Alguém pode me ajudar? Obrigado ! 

Exibições: 2458

Responder esta

Respostas a este tópico

Abri um problema  no ESP32 Arduino  GitHub.

https://github.com/espressif/arduino-esp32/issues/2949

Eu suspeito que há agora um conflito entre I2C e PWM Channel 0 que eu uso para gerar clock de 480 KHz para TLC 7135 (chip voltímetro). 

Observe que meu projeto funcionava bem com as bibliotecas antigas.

Visualizando o problema :

Logic analyzer diagrama com o ESP32 Core version 1.0.0  (fev/2018)


https://github.com/Gustavomurta/ESP32-DVM/blob/master/ESP32_DVM7135...

ESP32 Core 1.0.2 :

Agora o funcionamento maluco da Interface I2C. O pino SCL fica enviando pulsos (100KHz) e quando tem que enviar os dados, para de pulsar. Os dados no pino SDA são retornados incorretamente. 


https://github.com/Gustavomurta/ESP32-DVM/blob/master/ESP32_DVM7135...

Corrigindo uma informação importante ! 

Consegui fazer alguns testes do ESP32 Voltmeter no meu Laptop.

A versão da Arduino IDE é 1.8.5 e a versão do CORE 1.0.0. 

O sintoma é diferente, mas também não funciona ! Só que agora não aparece Over Voltage. 

A interface I2C continua com problema. 

Lembrei-me que a primeira versão do Core que eu usei foi a anterior do 1.0.0. 

E usei o método antigo para instalar o package :

Método antigo para instalação do ESP32 na IDE do Arduino :

https://jgamblog.wordpress.com/2018/02/08/conhecendo-o-esp32-usando...

Tentarei recriar o ambiente original, quando eu fiz o projeto funcionar 

Ufa ! 

Fiquei algumas horas com o Chuck (StickBreaker) me ajudando ! 

Foi muito legal. 

A conclusão dele :

Don't call Wire() from an interrupt context, Set a flag, then let the main loop do the work.

Ele recomendou não chamar uma rotina de leitura de I2C dentro de uma interrupção. 

A cada interrupção, devo gerar um Flag e depois tratar a leitura da interface I2C. 

Alguma coisa ele deve ter mudado nas rotinas de I2C, pois antes tudo funcionava bem.

Mas de toda forma fiquei muito agradecido pela ajuda dele.

Muito obrigado Rui e Elcids pelos esforços em me ajudar. 

A gente esta sempre aprendendo, quando tentamos ajudar o colega. 

Grande abraço ! 

Estou cansado. Depois mostrarei o resultado final. 

Mas podem dar uma olhada na proposta da solução. Terei que modificar o meu programa. 

https://github.com/espressif/arduino-esp32/issues/2949

Quando tudo funcionava perfeitamente :

olá novamente Murta.

      Tenho boas notícias.

      Consegui emular o TCL7135 (via HW e FW), e como o PCF8574 tenho aqui, pude fazer testes mais realísticos, e inclusive medindo as temporizações com Osciloscópio.

      Fiz alguns ajustes no código que eu postei ontem, e o Sistema funcionou perfeitamente, sincronizando os dados confiavelmente.

      Foi utilizada a IDF 1.0.2 do ESP32. A placa que utilizei também é a "DOIT ESP32 DevKit V1".

      Implementei também um mecanismo de Timeout, de forma que se o I2C vier a travar em algum momento, o Sistema se recupera sozinho.  Nos testes, não ocorreu nenhuma falha (deixei funcionando por mais de 1 hora). Então forcei a falha desconectando o sinal SCL do PCF8574 , e o Sistema detectou a falha (informando no Terminal do Arduino),  e se recuperou imediatamente logo que reconectei o sinal SCL (repeti o teste inúmeras vezes e por períodos longos de falha).

      Segue o código para teste:   ESP32_DVM7135_PT_V1_02.zip

      Assim que possível, postarei detalhes da implementação.

      Abrçs,

      Elcids

Hoje com calma, 

Pensando em tudo que o Chuck me informou ontem,  ele me deu algumas dicas das mudanças  que ele fez na Biblioteca I2C do ESP32 Arduino que fizeram o meu programa parar de funcionar. 

Em um momento ele começou a dar algumas justificativas esfarrapadas da possível causa do problema no meu programa. Mas de imediato descartei essas justificativas :

(um especialista de SW tentando dar justificativas para um especialista de HW) 

Chuck : você pode estar vendo várias interrupções por / strobe, Se a borda de descida não for rápida (MHz) o esp32 pode ver várias transições devido a ruídos do sinal (micro volts).

EuNo meu projeto não há ruídos. A frequência de interrupção é baixa. O sinal está claro! 
(vendo no meu osciloscópio)

Se um Microcontrolador  pode sofrer interrupções provocadas por ruídos (glitches) de apenas microvolts, jogue fora o projeto desse Microcontrolador e comece tudo de novo! 

E esse não é o caso do ESP32 ! Uma das etapas do desenvolvimento do meu projeto foi o teste das interrupções. E as interrupções no ESP32 funcionam perfeitamente ! 

Em outro momento ele me indicou esse link e essas informações :

if during the Wire.begin() it senses a hung bus, the recovery procedure is to produce upto 9 clock cycles on SCL while monitoring SDA as soon as SDA goes high the recovery procedure ends.

so, something is happening on the bus, The busy error is generated by the hardware peripheral. Try looking at the signal with your scope, something is not right.

No meu entender o travamento do I2C bus ocorria pois o pino SCL ficava enviando pulsos indefinidamente (situação anormal). E quem envia esses pulsos é o ESP32 e não o periférico PCF8574. (bug de SW)

the pulses you are seeing is the i2c subsystem trying to clear the bus. If a READ operation is in progress and there is a esp32 reset, the slave i2c device could be in the middle of outputting a request. It could be driving SDA low. When the ESP32 boots and Wire.begin() is executed and it sees SCL /SDA not in an idle state it tries to recover the bus. It does this by manually generating SCL pulses in checklinestate. I think that is what you are seeing.

ESP32 Reset? Não era o meu caso! Momento de Boot? Não era o meu caso. 

Esse é o link que informado por ele, que eu acho que ocasionou o problema no meu programa:

https://github.com/espressif/arduino-esp32/blob/7d7824701fe5e22f085...

// if the bus is not 'clear' try the cycling SCL until SDA goes High or 9 cycles

OK, o negócio agora é eu modificar todo o meu programa para se adequar as mudanças da Biblioteca I2C do ESP32 Arduino. Vivendo e aprendendo. Eu ainda tentarei simular o funcionamento novamente com as bibliotecas antigas. 

Bom dia Elcids, 

Obrigado pelo esforço em me ajudar ! 

Com o clock gerado de 100 KHz - apareceu a mensagem =  ocorreu Timeout!

#define TLC_freq   100000    // frequencia do CLK para o TLC, em [Hz].

Testei com 480 KHz (frequencia do meu projeto). Mesma mensagem =  ocorreu Timeout!

Acho que vai ser praticamente impossível você simular o funcionamento do meu projeto se não souber o timing dos vários pinos. 

Você tem algum analisador lógico ai ? Recomendo esse aqui - Analisador Lógico 8ch Saleae (procure no ML). É barato e ótimo! 

Mesmo se não tiver, instale esse programa do analisador Lógico :

https://www.saleae.com/downloads/

E abra esse arquivo do meu projeto que eu anexei.

ESP32_VDM7135_V3 B

Vai ver como o meu ESP32 DVM funcionava perfeitamente antes das alterações na Biblioteca I2C. 

Grande abraço e muito obrigado. 

O arquivo excedeu o limite do Forum. 

Enviei o arquivo para o Github. Baixe o arquivo:

https://github.com/Gustavomurta/ESP32-DVM/blob/master/ESP32_VDM7135...

Elcids, curiosidade. 

Qual simulador esta usando? 

Obrigado. 

olá Murta.

      O que fiz, não foi uma simulação (que ocorre apenas em SW). Foi uma emulação (HW e SW).

      Para tal, programei o Timer0  do ESP32 para gerar a temporização, e com isso ir cadenciando sequencialmente os sinais gerados pelo TCL7135. O Timer0, gera Interrupções (IRQs) na mesma temporização do TCL7135. Quando uma dessas IRQs ocorre, ela gera o Sinal "Strobe" fisicamente através de um I/O do ESP32 (usei o pino 16), e este "Strobe" está conectado ao pino "STB" original que vc usa (o pino 4). Então isso provoca uma nova IRQ para o ESP32, exatamente a mesma do TCL7135. E na ISR desta IRQ, eu faço um IntACK (Interrupt Acknowledge), restaurando o sinal "Strobe" para o estado inativo (ou seja, "High"). A partir desse ponto, é feito o restante do processamento normal para o TCL7135.

      Este processo se repete 5 vezes, já que existem 5 pulsos de Strobe. Após isso, a própria ISR do Timer0, muda sua temporização, para emular um novo ciclo de conversão (que para o TCL7135 é a cada 40002 ciclos de CLK).

      Em cada ISR do Timer0, além do próprio sinal "Strobe" do TCL7135, são gerados também os demais bits, correspondentes ao B1, B2, B4, e B8, e aos sinais de status D5, POL, e OVR. Claro o D5 é gerado apenas no primeiro dos 5 Strobes.

      Assim, na emulação há 8 sinais gerados no HW: 7 entram no PCF8574, e um (o Strobe) entra no "STB" original do que já existia (pino 4). Observe que não gerei o sinal "UNR" (Under Range), já que vc não o estava usando no DVM.

      Um detalhe importante:  o código que postei acima, não é o que tem a emulação. Ele já é o código para rodar na sua placa DVM com o "TCL7135". Se vc rodar ele em um ESP32 sem o seu circuito do DVM,  ele vai realmente dar "Timeout", pois não existirá a geração do "STB" pelo TCL7135. Peço desculpas por não eu não ter mencionado isto (devido à correria, fiz um post mais suscinto).

      Assim o código postado é para seu Hardware do DVM. Aconselho testar primeiro com 100 kHz, e depois que estiver vendo as medições no Terminal do Arduino, vá aumentando a frequência do CLK. Os cálculos que fiz e as medições com o Osciloscópio, indicam que ele vai funcionar mesmo a 480 Khz, pois medi uma latência de menos de 10us entre o Strobe e a subsequente leitura I2C. Mas mesmo assim, inicie com 100 kHz para o primeiro teste.

      Ainda sobre a emulação: para permitir que outras pessoas também testem o Sistema, assim que possível irei preparar as figuras e postar as ligações externas para a placa "DOIT ESP32 DevKit V1" (e que também poderão ser usadas para outras placas ESP32), juntamente com o código da emulação. Observe que o código da emulação apenas tem a parte da emulação com o Timer0, e o restante é totalmente igual ao código que postei hoje.

      Abrçs,

      Elcids

Grande Elcids, se gostou do projeto recomendo que monte ele.

Esse projeto pode ser útil para inúmeras aplicações ! 

Os testes que eu fiz do seu programa foi com o ESP32 Voltmeter conectado.

Mas todos sem sucesso. 

Veja o que o Indiano fez ! Ele que reclamou que o meu projeto não estava funcionando. E agora ele conseguiu fazer funcionar com o Core 1.0.0 ! 

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

PADAKATHU R RANGASAMY July 2, 2019 | 11:32
Thank you so much Gustavo and Chuck (StickBreaker) for discuss and find solution. i used ESP32 ARDUINO CORE 1.0.1 and now using 1.0.0. Working GOOD now, reading voltages from ICL7135. checked all three board by follow up the discussed code.
Below attached serial monitor working one photos.

Oi Murta, irei pedir um TCL7135 lá no ML.

      Sobre o código que postei hoje, peço que verifique com seu Analisador Lógico, se o Strobe está sendo gerado pelo TCL7135,  ou seja se ele está realmente gerando os pulsos, pois caso não esteja, não vai cadenciar o funcionamento do código.

      No teste, para não comprometer a temporização, não acrescente nenhuma outra funcionalidade (como WiFi ou Bluetooth). Isto seria feito posteriormente, após constatado o funcionamento.

      Ah sim:  realmente as justificativas do "StickBreaker" deixam um pouco a desejar. Mas eu já tenho a resposta para o seu Sistema original não estar mais funcionando na 1.0.2, pois como eu havia dito inicialmente, eu havia feito uma análise detalhada de toda a LIB Wire na versão AVR (a qual tem algumas limitações preocupantes). Logo que possível, postarei aqui detalhadamente sobre isso.

      Abrçs,

      Elcids

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço