Depuração de Microprocessadores: 1980–2016 – Uma História Abrangente

Desde o alvorecer do design eletrônico, bugs são inevitáveis, e a depuração tem sido a disciplina essencial para lidar com falhas e erros, determinando quais prevalecerão — e quão completamente.

A tecnologia de depuração evoluiu tão fascinantemente quanto os designs que suporta. De abordagens simples de estímulo-resposta-observação às ferramentas, equipamentos e metodologias sofisticadas de hoje, o campo cresceu em tandem com sistemas cada vez mais complexos. Em 2017, uma nova era começou com a introdução de depuração sobre I/O funcional, prometendo eficiência e capacidade ainda maiores.

Após décadas de inovação global, envolvo-me com depuração desde 1984. Para apreciar a mudança de paradigma que agora experimentamos, é útil revisitar os marcos que moldaram a indústria.

Anos 1970–1980

O design de sistema então diferia marcadamente do atual. Uma placa típica compreendia CPU, (EP)ROM, RAM e ICs periféricos como PICs, UARTs, controladores DMA, timers e dispositivos I/O, cada um implementado em chips separados.

Computador de placa única (SBC) anos 1980
(Fonte: https://oldcomputers.net/ampro-little-board.html)

Desenvolvedores escreviam código em assembly ou C, compilavam, linkavam e produziam arquivo HEX para imagem da ROM. O processo envolvia apagar EPROMs manualmente com apagador UV, programá-las via interface serial ou paralela, e reinstalar os chips na placa. Se o programa não se comportava como esperado, várias técnicas de depuração estavam disponíveis.

Inspeção de Código:

A abordagem mais fundamental, ainda usada por muitos, envolve percorrer código mentalmente ou com editor de texto, habilidade que permanece valiosa quando ferramentas não estão disponíveis ou são muito custosas.

LEDs:

Método clássico usa LEDs onboard ou outros indicadores para sinalizar estado do programa. Inserindo toggles de LED em pontos-chave, desenvolvedores rastreiam visualmente fluxo de execução. Quando pinos I/O adicionais e analisador lógico estão disponíveis, rastreamento de estado em tempo real torna-se possível.

Monitor On-Target:

Placas com porta serial e memória suficiente podiam hospedar pequeno programa monitor. Saltando para este monitor, desenvolvedor podia dar step no assembly, inspecionar registradores e memória via comandos RS‑232 como s (step) ou m 83C4,16 (exibir memória).

Emulador In-Circuit (ICE):

Para quem podia pagar, o ICE era o depurador definitivo. Substituía a CPU por circuito de emulação que podia observar e controlar sinais internos. Embora grande e caro — frequentemente custando milhares de dólares — ICEs forneciam breakpoints avançados, trace e capacidade de trocar EPROMs por RAM de emulação, eliminando necessidade de apagar e re-flash durante desenvolvimento.

Motorola Exorciser ICE
(Fonte: https://www.exorciser.net/personal/exorciser/Original%20Files/exorciser.jpg)

Intel MDS ICE
(Fonte: https://www.computinghistory.org.uk/userdata/images/large/PRODPIC-731.jpg)

1982–1990

Três mudanças-chave surgiram para desenvolvedores embarcados:

• ICs Integrados: CPUs passaram a incluir periféricos — ex.: Intel 80186/80188 (evolução do 8086/8088), Zilog Z180 (do Z80), e família Motorola CPU32 (ex.: 68302) do 68000.
• ICEs Acessíveis: Fabricantes produziram ICEs de menor custo sem chips bond-out, reduzindo preço para abaixo de $10.000 para ICE 80186.
• Desafios de Velocidade de Clock: Velocidades crescentes de CPU tensionaram cabos e lógica de controle do ICE. Solução foi circuitaria de debug on-chip (OCD), fornecendo single-step, acesso a registradores e breakpoints na velocidade total da CPU, embora implementações iniciais carecessem capacidade de trace completa.

Acesso OCD tipicamente usava interfaces proprietárias como Background Debug Mode (BDM) ou o mais comum JTAG, tradicionalmente usado para teste de produção. Enquanto algumas ferramentas podiam acessar memória enquanto CPU rodava, outras não podiam, levando a variações entre implementações.

1990–2000

Trace externo tornou-se impraticável devido a altas velocidades de clock e cache interno. Em vez disso, fabricantes introduziram dados de trace de núcleo comprimidos — capturando apenas mudanças não sequenciais de program counter e comprimindo para transporte off-chip. Isso permitiu ao depurador reconstruir caminhos de execução usando conhecimento do programa em execução. Arquiteturas-chave incluíram PowerPC da IBM, ColdFire da Motorola, e núcleos ARM 7TDMI.

2000–2010

Datasets de trace comprimidos permitiram buffers de trace on-chip como Embedded Trace Buffer (ETB) da ARM, acessíveis via JTAG. O tamanho do buffer podia ser configurado, balanceando área de silício contra performance de trace. SoCs multi-core introduziram novos desafios: cadeias de scan JTAG desapareciam quando núcleos desligavam. Arquitetura CoreSight da ARM resolveu isso fornecendo porta de acesso de debug baseada em JTAG única que podia alcançar todos componentes CoreSight mapeados em memória, incluindo múltiplos núcleos que podiam ciclar energia independentemente.

2010–Presente

Com ascensão de núcleos 64-bit e uso generalizado de Linux/Android, debug on-device ganhou tração. Drivers de kernel agora expõem componentes CoreSight, permitindo captura de trace on-target via subsistema perf. O ARM Embedded Logic Analyzer (ELA) traz de volta a riqueza dos ICEs iniciais, oferecendo breakpoints complexos, gatilhos e acesso a sinais internos do SoC — tudo dentro do silício.

Após 40 anos de inovação incansável, o campo está à beira de novo capítulo: depuração e trace sobre I/O funcional existente. Essa mudança promete soluções mais enxutas que reduzem tempo e custo de desenvolvimento enquanto aumentam capacidade, continuando a longa guerra contra bugs.