[ PROJETO / 010 ]

BRIDGE
TTL/RS485

Uma aplicação binária transparente entre UART TTL e RS485, construída e validada sobre o hardware reaproveitado de uma unidade ED100.

ELETRÔNICAPROGRAMAÇÃOAUTOMAÇÃOEXPERIMENTAÇÃO
STATUS
● EM TESTE
PLATAFORMA
ED100 / ESP32-WROOM-32E
INTERFACES
UART0 TTL / UART2 RS485
VALIDAÇÃO
BMS JBD / 9600 8N1
Hardware ED100 usado no desenvolvimento e nos testes da Bridge TTL/RS485
Unidade ED100 efetivamente reaproveitada. O levantamento e o firmware são independentes e não representam documentação oficial de outras revisões.
[ 01 / HARDWARE ]

Os blocos usados pela Bridge.

[ CAMINHO DE COMUNICAÇÃO ]
ESP32-WROOM-32E
→
UART2
→
ST485E
→
BARRAMENTO A/B
UART0 / CN2Interface com o computador por conversor USB–TTL de 3,3 V. No exemplar mapeado: RX/GPIO3, TX/GPIO1 e GND.
UART2 / RS485GPIO16 recebe RO e GPIO17 envia dados ao DI do ST485E.
CONTROLE DE DIREÇÃOGPIO4 controla DE e /RE: LOW para recepção, HIGH para transmissão.
INDICAÇÃO DE ATIVIDADEGPIO27 indica transmissão RS485 e GPIO14 indica recepção no firmware desenvolvido.

Wi-Fi, Bluetooth, RTC, servidores e protocolos de rede não são inicializados pelo firmware da Bridge. O objetivo é usar as interfaces seriais existentes como ferramenta direta de comunicação e diagnóstico.

[ 02 / TRANSFORMAÇÃO ]

Do hardware identificado à Bridge TTL/RS485.

[ PROCESSO ]
ED100 ORIGINAL
→
HARDWARE IDENTIFICADO
→
INTERFACES REAPROVEITÁVEIS
→
FIRMWARE INDEPENDENTE
→
ESP RS485 BRIDGE

O hardware comercial foi reaproveitado. O levantamento foi produzido independentemente. O firmware esp-rs485-bridge também foi escrito independentemente e não utiliza nem distribui o firmware original do equipamento.

GITHUB / ESP-RS485-BRIDGE↗
[ 03 / BRIDGE MODE ]

Bytes entre duas interfaces.

[ BRIDGE MODE ]
PC
↔
USB–TTL 3,3 V
↔
ESP32 / ED100
↔
RS485
↔
DISPOSITIVO

A Bridge encaminha dados binários entre UART0 e UART2. Ela não interpreta Modbus ou JBD, não altera frames, não calcula CRC e não acrescenta delimitadores. Bytes como 0x00 e 0x0D são transportados como recebidos.

A transparência é de conteúdo, não necessariamente de temporização. Dados vindos do computador são agrupados até 3,5 tempos de caractere em silêncio ou até o buffer estático atingir 512 bytes. Em 9600 8N1, o intervalo calculado é aproximadamente 3646 µs; pausas maiores e fluxos contínuos acima de 512 bytes podem dividir uma transmissão.

[ 04 / SNIFFER MODE ]

Observar sem transmitir por software.

[ SNIFFER MODE ]
MASTER
→
BARRAMENTO RS485
→
SLAVE
→
ED100 → PC

No modo sniffer, a entrada enviada pelo computador é descartada e GPIO4 permanece LOW, impedindo transmissões comandadas pelo firmware. O tráfego recebido pelo RS485 segue para a UART0.

[ PASSIVIDADE TEM UM LIMITE ]
O modo é passivo no nível do protocolo, mas não eletricamente isolado. Transceiver, proteção e polarização continuam conectados e carregam o barramento. A montagem não deve ser apresentada como analisador totalmente passivo ou isolado.
[ 05 / DIAGNÓSTICO 0x00 ]

O byte que aparecia sem ter sido enviado.

SINTOMA
0x00 ESPÚRIO
HIPÓTESES
FRAME / UART / TRANSCEIVER
TESTES
A/B DESCONECTADOS
CAUSA
RX2 EM LOW DURANTE TX
CORREÇÃO
GPIO MATRIX

Durante transmissão, /RE desabilita o receptor do ST485E e sua saída RO fica em alta impedância. No circuito levantado, o pull-down externo pode levar GPIO16 a LOW, condição capaz de iniciar um BREAK e produzir um 0x00 falso na UART2.

A correção mantém a entrada interna RX2 em nível ocioso HIGH pela GPIO Matrix enquanto o transceiver transmite. Depois de uart_wait_tx_done(), a entrada RX2 é limpa ainda isolada; GPIO4 retorna a LOW e GPIO16 é reconectado imediatamente, sem janela destinada a descartar o primeiro byte real.

[ TRANSIÇÃO TX → RX ]
TX RS485
→
uart_wait_tx_done()
→
LIMPA RX2 ISOLADO
→
DE/RE → RECEIVE
→
RECONECTA GPIO16

Com A e B desconectados, o frame DD A5 03 00 FF FD 77 foi enviado em Bridge Mode. O LED de TX indicou atividade, o de RX permaneceu inativo e nenhum byte retornou ao computador: o 0x00 espúrio deixou de ser produzido.

[ 06 / POLARIDADE A/B ]

Nem todo zero vinha do firmware.

[ INVESTIGAÇÃO ]
HIPÓTESE / PROBLEMA NO FIRMWARE
→
CAUSA / A/B INVERTIDOS
→
RESULTADO / RESPOSTA VÁLIDA

Na primeira ligação ao BMS, eram observados apenas bytes 0x00. Após desenergizar o conjunto e inverter A/B, a comunicação pelo JBDTools funcionou e respostas válidas passaram a começar por DD.

A conclusão vale para o conjunto ensaiado: nomenclaturas A/B variam entre fabricantes. Cor e nome do fio, usados isoladamente, não provam polaridade e não substituem verificação elétrica.

[ 07 / VALIDAÇÃO ]

Validado com o conjunto ensaiado.

Testes físicos realizados em 17/08/2026 com ESP32-WROOM-32E, ST485E, placa reaproveitada de um ED100, BMS JBD SP24S004L24S120A, JBDTools e comunicação em 9600 baud, 8N1.

[ ARRANJO DE VALIDAÇÃO ]
JBDTools
↔
USB–TTL
↔
ED100 / BRIDGE
↔
RS485
↔
BMS JBD
Bridge com A/B desconectados, sem 0x00 falsoAPROVADO
Bridge conectada ao BMS JBD em 9600 8N1APROVADO
Comunicação pelo JBDToolsAPROVADO
Sniffer RS485 conectado em paraleloAPROVADO
Preservação do primeiro byte da respostaAPROVADO
Teste contínuo por 30 minutosPENDENTE
Sequência completa de 0x00 a 0xFFPENDENTE
Verificação com analisador lógicoPENDENTE
Outros formatos seriaisNÃO TESTADOS

Esses resultados demonstram o conjunto ensaiado. Não estabelecem compatibilidade universal com todos os BMS JBD, dispositivos RS485, baud rates, formatos seriais ou revisões do ED100.

PROCEDIMENTOS E RESULTADOS DETALHADOS↗
[ 08 / SEGURANÇA ]

Antes de ligar os cabos.

[ INTERFACE NÃO ISOLADA ]
A interface não possui isolamento galvânico. Verifique referência elétrica, tensão de modo comum e compatibilidade dos níveis lógicos antes de conectar computador, bateria ou barramento. Não conecte indiscriminadamente o negativo de uma bateria de tração ao GND de um computador.
  • GPIOs do ESP32 não toleram 5 V; o conversor USB–TTL deve usar lógica de 3,3 V.
  • Com a placa alimentada normalmente, o VCC do USB–TTL deve permanecer desconectado.
  • O esquema analisado não apresenta terminação integrada de 120 Ω entre A e B.
  • Terminação e polarização dependem da topologia e não são adaptadas pelo firmware.
  • A UART0 é compartilhada com gravação e mensagens de boot do ESP32 podem aparecer nela.
[ 09 / ESCOPO E AUTORIA ]

O que este trabalho afirma — e o que não afirma.

[ ESCOPO E AUTORIA ]

ED100 é identificação de produto/marca de terceiro, utilizada aqui para documentar a plataforma efetivamente analisada. A Galeria -2048 não afirma afiliação, suporte, aprovação ou patrocínio de seu fabricante.

O mapeamento corresponde à unidade examinada, foi produzido independentemente e pode divergir de outras revisões. O esp-rs485-bridge é desenvolvimento independente. Firmware original, layout de PCB e arquivos de fabricação do equipamento não são publicados.

Esse cuidado não substitui precisão técnica: observações de bancada, implementação do firmware, resultados aprovados e testes ainda pendentes permanecem identificados separadamente.

[ 10 / REFERÊNCIAS ]

Hardware, firmware e próximos ensaios.

O artigo do ED100 preserva a exploração da plataforma e o levantamento independente. Este projeto concentra a aplicação desenvolvida sobre aquela unidade, seus modos de operação, diagnóstico e validação.

REFERÊNCIA DE HARDWAREED100 / MAPEAMENTO INDEPENDENTE ↗SOFTWAREESP-RS485-BRIDGE ↗
ETAPA FUTURAJBD BMS MONITOREM DESENVOLVIMENTO

A Bridge não encerra o trabalho com este hardware. Ela transforma a plataforma estudada em uma ferramenta concreta de comunicação e diagnóstico.