Fala, pessoal! Blz?

Estou tentando fazer um detector de presença com ESP32 usando BLE e enviar algumas informações para outro ESP32 pelo esp-now, no entanto não consigo por pura falta de espaço.

Só de importar a biblioteca WiFi.h e BLEDevice.h já bate mais de 100% do espaço de armazenamento de programas.

Alguém sabe se existem outras bibliotecas mais leves com as quais eu consiga concluir o projeto?

Resumo do projeto:

Em uma das placas ESP32 estão conectados um sim808, um JM-101B e um rc522.

Na outra placa, pretendo usar apenas o detector de presença usando BLE.

Gostaria que, usando o esp-now, as duas placas pudessem trocar informações entre si para que algumas ações possam ser tomadas.

Obrigado pela ajuda!

Abraços!

Exibições: 109

Responder esta

Respostas a este tópico

Boa noite NPR, (se não gosta que te chame pelas iniciais, avise),

posso estar  engando, mas o BLE e o Wifi não podem ser usados juntos no ESP32.

RV mineirin

Boa noite, Mineirin.
Nunca tinha ouvido falar dessa impossibilidade. Vou pesquisar a respeito.
Valeu.

Boa noite NPR,

do fórum do  ESP32:

Re: WIFI / BLE simultaneamente

O problema é que eles compartilham um rádio; em outras palavras, enquanto o ESP32 está enviando / recebendo um pacote BT, ele não pode escutar ou enviar um pacote WiFi. É como tentar acompanhar os talk shows de um antigo rádio FM: você fica trocando de lugar e geralmente consegue acompanhar os dois por causa de alguma redundância nas frases usadas, mas se eles falarem rápido demais, você vai perder o controle.
ref:
RV mineirin
Boa noite, RV.
É... Pelo jeito vou ter que abrir mão da ideia.

Muito obrigado pelas referências que enviou.

Boa noite Nelson!
Tem jeito sim, baixei um projeto que você comunica o ESP32 em um APP via BLE para passa as informações do SSID e do password para conectar a internet. 
 
Experimente trocar a partição na aba de Ferramentas-> Partition Scheme -> NO OTA (Large APP)

Boa noite, Yuri.
Vou tentar a sua dica.
Muito obrigado!

olá Nelson.

      Algo semelhante já foi feito por aqui.

      Veja no tópico deste link:   "WiFi e Bluetooth - ESP32"

      Ali naquela implementação,  criei uma camada de abstração (uma Biblioteca) para facilitar o uso,  o que acabou "escondendo" a parte realmente interessante.  Mas como o código está totalmente documentado (tanto no próprio código,  como nos documentos associados),  então pode-se explorar o mesmo com relativa facilidade.

      Então na sua empreitada,  acredito que poderá aproveitar alguma ideia daquele tópico.

      abrçs,

      Elcids

Olá, Elcids.
Li o tópico que você recomendou e fiquei com uma dúvida:
Essa restrição no uso do wi-fi com o bt ocorre também ao usar o esp-now? Pergunto pq, diferente do caso que você citou, as minhas placas não vão se conectar a nenhum AP, apenas usarão o esp-now para comunicarem entre si. No entanto o esp-now faz uso da biblioteca wi-fi.h, e é essa a origem da minha dúvida.

Obrigado.

olá Nelson.

      Vou tentar responder sua pergunta de uma forma que possa esclarecer a questão tanto para vc (que acredito tenha conhecimentos mais avançados, já que é Analista de Sistemas),  quanto para outras pessoas que tenham dúvida semelhante.

      Mas antes,  para que possamos ter uma visão melhor do seu Sistema, eu preparei um diagrama que talvez possa representar o mesmo.  Pelo que entendi, em um ESP32 que chamaremos ESP32(A),  vc teria um Sensor de Presença,  e este  ESP32(A) teria um canal de comunicação Bluetooth.  Acredito que este canal Bluetooth seja para conexão com um Smartphone,  de onde vc poderia configurar parâmetros e/ou ler o status do Sensor de Presença  ou de outros Dispositivos conectados ao ESP32.  Este ESP32(A) então faria parte de uma Rede Mesh,  onde haveriam outros ESP32,  que chamaríamos de ESP32(1)ESP32(2)ESP32(3), etc.   Cada um destes ESP32 na Rede Mesh, poderia estar monitorando algo ou executando qualquer outro processo,  e cada um reportaria dados, status, etc,  para o ESP32(A).  Por consequente,  isto permitiria que os demais ESP na Rede Mesh também recebessem parâmetros de configuração via ESP32(A) e seu canal Bluetooth, por onde também seria possível obter os dados "coletados" dos ESP na Rede Mesh.  Este diagrama é mostrado a seguir:

(clique na figura para "zoom")

      Observe que através do diagrama, facilita visualizarmos soluções alternativas.

      Agora,  falando sobre a questão do conflito WiFi/Bluetooth  no ESP32.

      Ocorre que o WiFi, Bluetooth, e outras "Redes",  usam a Banda de 2.4GHz. Dentro dessa "banda" existem diversos canais de RF (Rádio),  onde cada canal corresponde a uma faixa mais estreita dentro da Banda.  Não irei falar sobre detalhes dos canais de RF dentro da Banda de 2.4GHz,  uma vez que isso não é relevante para sua questão aqui, além do que,  independente de em qual canal de RF vc esteja,  ele fará parte da Rede, desde que utilizada a mesma forma de modulação (que é o caso).

      Geralmente essa "disputa" de espaço na Rede não constitui um grande problema, pois muitos dispositivos são configurados para estarem em canais diferentes,  e alguns mais "espertos" podem trocar sozinho de canal,  para procurar um que seja mais conveniente (menos disputado).  Então, claramente, este não é o motivo de conflito entre o Bluetooth e o WiFi  no ESP32.   Então onde este conflito ocorre de fato???

      Ele ocorre no Firmware,  especificamente na "BIOS" do ESP32  que gerencia os Packs de Dados  recebidos e enviados via RF.  Vamos entender melhor isso.

      Quando alguém transmite um Pack de Dados na mesma Banda e modulação dos 2.4GHz,  todos aqueles dispositivos que estão usando a mesma Banda e modulação,  recebem este Pack de Dados,  afinal o "ar" é um meio de propagação "livre".  É como quando alguém fala:  o som se propaga pelo ar, e todos que estão ao alcance receberão aquela informação, mas provavelmente sua "fala" é direcionada para alguém específico, e assim todos que receberam aquela "fala" a descartam (ignoram) e apenas o destinatário da sua "fala" é que irá se ater àquela "fala".  Então sua "fala" pode ser algo como "Pedro de Moura me passe o pote de graxa".   Aqui, o "Pedro de Moura" é o destinatário da mensagem, e "me passe o pote de graxa"  é o conteúdo em si da mensagem.  Ou seja:  a própria mensagem permite que se saiba a quem é destinada, já que será percebida por todos que estiverem ao alcance sonoro e entendam a mesma língua utilizada.  Assim no caso do WiFi e Bluetooth,  são "línguas" diferentes,  mas que compartilham o mesmo meio de propagação da mensagem (o ar)  e além disso ainda usam a mesma Banda de 2.4GHz (além do tipo de modulação).

      Mas no caso do ESP32,  embora WiFi e Bluetooth  sejam "línguas" diferentes, ainda é possível que convivam dentro do ESP32,  uma vez que lá existe uma CPU que executa um código,  e portanto capaz de interpretar e tratar as duas "línguas".  Para isso seria necessário que toda vez que um Pack de Dados  fosse recebido via RF,  o código da BIOS analise parte do conteúdo (um "header" ou "preamble") para determinar se encaminha aquele Pack ao Task na BIOS que gerencia o WiFi ou ao Task que gerencia o Bluetooth.  Da mesma forma,  quando um Pack tem que ser enviado via RF,  o código da BIOS é informado se aquele Pack deve ser formatado (via "header" ou "preamble") para WiFi ou para Bluetooth, possibilitando aos receptores determinar para quem aquele Pack foi destinado.

      Conclusão:  seria feito constantemente na raiz da coisa (na BIOS) um constante encaminhamento de Packs para o destino adequado (WiFi ou Bluetooth).  Aqui é que a coisa pega,  pois a Espressif  (a fabricante do ESP32),  não fez isso.  Ela simplesmente assumiu que ou estará ativo o Task da Bios que trata Packs do WiFi, ou estará ativo o Task que trata Packs do Bluetooth,  mas nunca ambos.  Se ela tivesse previsto um "árbitro"  que decidisse quem trataria um Pack de Dados,  ambos os Tasks poderiam estar ativos simultaneamente,  e não haveria problema pois cada um receberia exatamente o Pack que lhe corresponde.  Pra complicar,  cada um destes Tasks,  usa uma quantidade de memória (código e dados) relativamente grande, ou seja:  nenhuma otimização foi inicialmente feita sobre isso,  já que não foi prevista a execução simultânea dos dois Tasks.   Ou seja, o tal conflito é na raiz da coisa, mais especificamente no Firmware (BIOS) do ESP32, e um tanto "engordurado" devido a nenhum tratamento básico ter sido previsto.

      No tópico que sugeri que vc olhasse (deste link:  "Wifi/Bluetooth" ),  a Biblioteca que implementei (chamei de PCOM Wifi-Bluetooth) faz uma comutação entre WiFi e Bluetooth conforme cada um destes esteja disponível.  Isto porque a aplicação original (solicitada pela Marcela de Souza) precisa controlar dispositivos por qual caminho estiver disponível (seja WiFi, seja Bluetooth).  Mas nada impede que também sejam utilizados ambos WiFi e Bluetooth para dispositivos específicos,  mas também observando que devido às comutações no código, sempre haverá uma maior latência na entrega/recepção dos Packs de Dados (latência que pode ser agravada devido à meios de Autenticação).

      Assim no caso da Rede Mesh,  ela nada mais é do que um WiFi com uma outra "assinatura" ("header" ou "preamble"),  que a permite ser distinguida do WiFi convencional e do próprio Bluetooth.  Ou seja, em teoria, todas estas Redes poderiam conviver, se a Espressif tivesse implementado um "árbitro" para encaminhamento de Packs de RF do 2.4GHz.  Portanto, em relação ao conflito com o Bluetooth,  a rede Mesh é o equivalente ao WiFi convencional.

      Assim Nelson,  caso vc não queira se embrenhar na selva de um código para comutação entre estas Redes (o que exige muito cuidado, perícia, e tempo de desenvolvimento),  há soluções alternativas e simples.  Veja a figura a seguir, onde mostro algo assim para o Sistema do diagrama que mostrei anteriormente:

(clique na figura para "zoom")

      Esta é uma topologia simples de se implementar e gerenciar.  Para isto, crie um Protocolo simples (mas eficiente e robusto) entre o ESP32(A) e o ESP32(B), sobre o Pipe I2C.  Não prenda este protocolo a formatos específicos,  ou seja, torne-o geral, independente do conteúdo dos Packs trocados entre (A) e (B).  Com isso, não precisará ficar gerenciando atualizações deste Pipe I2C,  uma vez que mesmo que vc altere formatos e Protocolos nas "pontas" do Sistema (Bluetooth e WiFi),  estes ainda serão transmitidos entre (A) e (B) via Pipe I2C.  E embora o I2C esteja longe de ser um "foguete" em termos de velocidade,  ainda assim será adequado para Sensores e muitos dados do mundo real, que geralmente são "curtos" e com taxas de amostragem baixas (ou mesmo esporádicos).

      Vc pode também usar uma Serial convencional  (UART) entre (A) e (B),  o que permitiria aumentar a velocidade de comunicação em relação ao I2C.   Já o SPI pode ser usado, mas não recomendo,  pois no código tem um Handshake  bem mais difícil de gerenciar,  e que se não for tratado adequadamente leva a muitas falhas de comunicação e travamentos (isto pode ser facilmente contornado, mas seria necessário que estivessem disponíveis dois canais de SPI em cada Processador).

      Espero ter ajudado.

      abrçs,

      Elcids

Caramba, Elcids... Baita aula, hein?

Entendi o conceito (ainda mais pelo favor que você fez de deixar a coisa o mais simples e clara possível), mas dadas todas as questões envolvidas, resolvi desistir da ideia.

Como já coloquei em outras postagens, minha intenção é criar um projeto IoT para a minha velha VW Variant, onde existirá um alarme, monitoramento da localização via GPS, partida por impressão digital, partida por RFID (caso pare o carro num estacionamento), controle remoto de algumas funções, etc.

A ideia do BT era usá-lo como sensor de presença do meu celuar. Assim, quando saísse do carro, o alarme seria ativado automaticamente, mas como o código acabou ficando meio extenso e talvez não coubesse tudo numa única placa, a ideia era ter um ESP32 para fazer praticamente tudo e um segundo para o BT, que enviaria a informação para o primeiro para que o acionamento fosse feito. Resumindo: era uma perfumaria.

Quanto a eu ser analista de sistemas, eu sou, mas apenas de formação. Nunca atuei na área (sempre atuei como suporte) e esse projeto é o primeiro onde preciso me dedicar de forma mais intensa a compreender como esses protocolos de comunicação funcionam na pratica e a me dedicar a programação de forma mais intensa. Por essa razão, explicações tão detalhadas como a sua são de extrema ajuda, e serei sempre grato pela sua dedicação em me ajudar.

Muitíssimo obrigado pela aula!!!!

RSS

© 2021   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço