O “Lado Esquerdo” do V)

Clique para a secção anterior: Etapa 2

A Etapa 3 é onde o design se torna físico: design eletrónico e mecânico, que normalmente avançam de mãos dadas. Se já ouviu falar do V-model em engenharia (um modelo clássico de processo de desenvolvimento), o lado esquerdo do “V” é todo sobre design e implementação – e é exatamente onde estamos agora. Por outras palavras, estamos focados em desenhar o hardware que mais tarde será verificado e validado no lado direito do V. (Não se preocupe se não estiver familiarizado com o V-model; a ideia-chave é que o design de hardware tende a ser um processo sequencial que deve abordar com cuidado. Depois de imprimir uma placa de circuito ou moldar uma caixa de plástico, fazer alterações é complicado – leia-se: caro.)

A Etapa 3 pode ser dividida em alguns sub-passos. Importante: esta é também a etapa onde o desenvolvimento de hardware e software começa a trabalhar em paralelo (mais sobre o lado do software na próxima etapa). Na via do hardware, eis como as coisas tipicamente se desenrolam:

Captura de Esquema: A Planta Eletrónica

Todo o produto eletrónico começa como um desenho – não do tipo artístico, mas um esquema. A captura de esquema é onde o design do circuito elétrico é esboçado em detalhe usando ferramentas CAD especializadas (como Altium, Eagle ou KiCad). Pense no esquema como a planta do seu circuito: mostra cada componente (microcontrolador, sensores, condensadores, conectores e mais) e como estão todos eletricamente ligados por nets (fios). É como mapear uma cidade de eletrónica onde cada componente é um edifício e as nets são as estradas que os ligam.

Este passo é crucial porque é muito mais fácil (e barato) corrigir erros num diagrama do que numa placa física. Uma vez o esquema redigido, uma revisão minuciosa é obrigatória. Tipicamente, o engenheiro exporta o esquema para PDF e faz circular para revisão por pares. Olhos frescos podem apanhar algo que lhe escapou – por exemplo, “Ups, o pino de alimentação do sensor de temperatura não está ligado!” ou “Esse valor de resistência parece estranho para o limitador de corrente do LED.” Apanhar estes problemas agora poupa muitas dores de cabeça mais tarde.

Nesta fase, algumas equipas também executam uma FMEA (Failure Modes and Effects Analysis) sobre partes críticas do design, como a fonte de alimentação ou circuitos de segurança. A FMEA é basicamente uma forma estruturada de perguntar “Quais são todas as formas como este circuito pode falhar, e o que acontece se falhar?” Por exemplo, e se o sensor de temperatura falhar em curto-circuito (ou seja, os seus dois terminais ligam-se acidentalmente por dentro)? Isso apenas faria o sensor ler um valor extremo, ou podia danificar a placa inteira ao puxar demasiada corrente? Ao fazer estas perguntas desconfortáveis de “e se” cedo, pode adicionar proteções ou decidir se o risco é aceitável. Este tipo de pensamento antecipado torna o dispositivo mais fiável a longo prazo.

Entretanto – e é aqui que entra o trabalho em paralelo – a equipa de software/firmware não tem de esperar parada que o hardware fique pronto. Com base no esquema, os engenheiros de firmware podem começar a criar uma HAL (Hardware Abstraction Layer) ou pelo menos um esqueleto dela. Essencialmente, configuram as interfaces de software para os periféricos do microcontrolador (timers, interfaces de comunicação como I2C ou SPI para esses sensores, etc.). Podem até escrever testes unitários ou código de simulação para estes drivers num PC. Imagine um programador a escrever código que falsifica leituras de sensores só para testar a lógica – desta forma, a equipa de firmware já está a construir a fundação. Assim, quando a placa de circuito real chega, muito da estrutura de código está pronta e à espera de ser experimentada em hardware real. Este esforço paralelo significa que o pessoal do software não está a coçar os polegares; está a lançar as bases que tornarão o bring-up do hardware mais fácil mais tarde.

Layout da PCB: Do Esquema à Placa Física

Uma vez o design do esquema finalizado e revisto, é tempo de transformar essa planta eletrónica numa placa de circuito real. Esta é a fase de layout da PCB. Usando outro conjunto de ferramentas CAD (frequentemente a mesma suite usada para os esquemas, como Altium ou KiCad, que consegue mudar para o modo de layout), o engenheiro coloca cada footprint de componente numa placa virtual e começa a encaminhar as pistas de cobre que ligam tudo. Se o esquema é a planta, o layout da PCB é o passo onde decide exatamente como essa cidade de componentes vai fisicamente parecer – como decidir onde cada edifício se senta e como as estradas (fios) vão correr entre eles na paisagem real da placa.

O resultado do layout da PCB é um conjunto de ficheiros (os famosos ficheiros Gerber) que os fabricantes usam para fabricar a placa. Outra saída útil é um modelo 3D (frequentemente um ficheiro STEP) da placa. Este modelo 3D é especialmente útil no lado do design mecânico – pode importá-lo para o design do invólucro para verificar que a placa e todos os seus componentes cabem dentro da caixa do produto sem colisões (ninguém quer um conector USB a espreitar onde a caixa não tem furo!).

Durante o layout da PCB, é crítico ter em mente as diretrizes de Design for Manufacturing (DFM) e Design for Test (DFT). Em termos simples, DFM significa desenhar a placa para que possa ser fabricada de forma fiável e económica, e DFT significa desenhá-la para que possa ser facilmente testada mais tarde.

Por exemplo:

• DFM: Evite colocar componentes demasiado perto da borda da placa ou tão apertados que as máquinas de montagem lutem para os soldar. Garanta que o layout pode ser fabricado sem problemas.
• DFT: Adicione test pads ou um conector especial para poder ligar equipamento de teste ou programadores à placa em produção. Desta forma, cada unidade que sai da linha pode ser facilmente verificada (imagine uma ficha conveniente para programar firmware ou medir sinais em cada dispositivo).

É muito mais fácil incluir estas medidas agora do que perceber mais tarde que tem mil unidades acabadas sem forma fácil de verificar se estão totalmente funcionais!

Muitas equipas usam uma checklist durante o layout para garantir que nada é esquecido – coisas como adicionar fiducials (pequenas marcas que ajudam as máquinas de montagem automatizadas a saber como alinhar a placa), manter folgas adequadas entre partes de alta tensão, rotular conectores importantes, e assim por diante.

Enquanto a equipa de hardware está ocupada a encaminhar pistas e a suar sobre os detalhes da placa, o esforço paralelo de software continua. A equipa de firmware, conhecendo os modelos exatos de sensores e componentes do esquema, pode começar a escrever código de driver real (ou pelo menos placeholders) contra os datasheets desses componentes. Podem usar emuladores de sensores ou escrever código fictício que imita o que o sensor faria. A equipa de cloud/backend, se o seu produto IoT tiver uma, também pode avançar: por exemplo, montando uma base de dados cloud básica e endpoints de API para receber dados do dispositivo. Essencialmente, todos estão a preparar a sua parte do puzzle para que, quando as primeiras placas físicas chegarem, não seja um arranque a frio para o resto da equipa. Quando o design da PCB é enviado para fabrico, o seu firmware pode já ter um “hello world” pronto para a placa e a sua cloud pode ter um pequeno servidor de teste à espera de registar o primeiro ponto de dados do dispositivo. Este desenvolvimento concorrente encurta realmente o ciclo de iteração mais tarde.

Construção do Protótipo: Dar Vida ao Hardware

Com o layout da PCB feito e verificado, é agora tempo de passar dos ficheiros digitais para objetos físicos. O primeiro passo é mandar fabricar as placas. Tipicamente, envia esses ficheiros Gerber para um fab de PCB (há muitos fabricantes de PCB quick-turn que conseguem produzir placas em dias). Em paralelo, vai querer garantir que todos os componentes que vão na placa (o microcontrolador, sensores, chips, etc.) estão disponíveis. Dica profissional: Encomende peças críticas ou de lead time longo assim que tiver confiança no seu esquema e seleção de componentes! Durante as faltas globais de chips, muitas equipas aprenderam isto da forma difícil – não quer ficar 12 semanas à espera de um sensor ou chip de rádio específico enquanto as suas placas estão ali vazias.

Uma vez que tem as PCBs nuas e todas as peças, monta algumas unidades protótipo. Isto pode ser feito internamente se tiver um laboratório bem equipado e mão firme para soldar, ou pode usar um serviço de montagem para soldar todos aqueles componentes minúsculos. O resultado é um conjunto (frequentemente uma mão-cheia, como 1 a 5 placas) de dispositivos protótipo.

Agora chega um dos momentos mais entusiasmantes (e stressantes) do desenvolvimento de hardware: o bring-up, que é o termo simples para a primeira vez que liga a placa e vê se funciona. É comum fazer isto com cuidado – por exemplo, usando uma fonte de alimentação de bancada com limite de corrente para evitar fritar coisas se houver um curto-circuito algures. Todos no laboratório podem prender a respiração enquanto carrega no interruptor. A placa liga sem libertar o fumo mágico dos componentes queimados? (Esperemos que sim!)

Após ligar, verifica metodicamente o básico. Todas as linhas de alimentação estão nas tensões esperadas? (Verifique com um multímetro ou osciloscópio.) O microcontrolador (MCU) acorda e corre código? Um primeiro teste clássico é frequentemente verificar se um firmware simples que pisca um LED ou envia uma mensagem “Hello, world” por uma porta série está a correr. Se vir esse LED piscar ou receber essa mensagem no seu computador, é um marco genuíno – significa que o coração da sua placa está vivo e de boa saúde.

A seguir, testará a comunicação com os periféricos-chave: O MCU consegue falar com o sensor por I2C ou SPI como planeado? Os sensores devolvem dados razoáveis? É nesta fase que pode descobrir problemas. Talvez um sensor não esteja a ler por causa de um erro de cablagem ou um bug subtil de firmware. O bring-up é um jogo de detetives, onde engenheiros de hardware e firmware trabalham em conjunto para resolver quaisquer problemas. Por exemplo, se a leitura de temperatura é sempre zero, o engenheiro de firmware pode depurar o código enquanto o engenheiro de hardware testa as ligações com um multímetro – juntos vão descobrir se é um problema de inicialização de software ou se as linhas SDA e SCL do sensor foram trocadas na PCB.

Durante o bring-up do protótipo, também está atento a quaisquer problemas de energia ou térmicos. Há algo a aquecer mais do que devia? (Dica profissional: tocar cuidadosamente nos chips para sentir o calor ou usar uma câmara de infravermelhos pode apanhar pontos quentes.) A placa está a consumir mais corrente do que o esperado (o que pode indicar que algo está mal ligado ou que um componente está defeituoso)? Estes testes garantem que o seu protótipo não só funciona, como é seguro e está a funcionar dentro dos parâmetros esperados.

Se o seu dispositivo se destina a comunicar sem fios ou a cumprir certas normas regulamentares (como emissões FCC para gadgets sem fios nos EUA), esta fase de protótipo é uma boa altura para fazer alguns testes de pré-conformidade. Isto pode significar levar o dispositivo a um laboratório para fazer um scan preliminar de emissões de radiofrequência para apanhar grandes problemas cedo. Não quer descobrir no teste final de certificação que a sua placa está a atuar como um transmissor de rádio acidental numa frequência não aprovada!

Enquanto a equipa de hardware está ocupada com o bring-up, a equipa de firmware está agora a todo o gás a testar o seu código no dispositivo real. Todos aqueles drivers e componentes HAL que iniciaram antes podem ser carregados na placa real. É aqui que o firmware pode precisar de alguma afinação – talvez os pressupostos de timing estivessem um pouco desviados, ou um interrupt precise de ajuste agora que está em silício real. Se está a usar um RTOS (Real-Time Operating System) no microcontrolador, é aqui que começa a afinar prioridades de tarefas ou timing, já que em hardware real consegue observar o desempenho real. A equipa de cloud também pode ver os primeiros dados reais a atravessar o sistema! Por exemplo, o protótipo pode realmente enviar uma leitura de temperatura para um servidor de teste, confirmando que todo o fluxo de ponta a ponta (dispositivo -> cloud -> base de dados) funciona pelo menos em pequena escala.

A Etapa 3 envolve frequentemente algumas iterações. É raro acertar tudo à primeira – e isso é completamente normal. Pode encontrar um erro na placa (como uma pista mal ligada ou um erro de footprint de componente) que exige uma pequena correção cirúrgica nos protótipos (olá, bodge wires e remendos!), ou pode ser significativo o suficiente para justificar rodar uma PCB revista para a próxima ronda de protótipos. Cada iteração é uma oportunidade de melhorar: talvez reposicione um conector que era difícil de alcançar, ou ajuste o circuito para reduzir o ruído numa leitura de sensor, etc. Não se desanime por precisar de iterações; é expectável no desenvolvimento de hardware.

Ao longo desta etapa, a colaboração próxima entre as equipas de hardware e software é vital. Quando surge um problema, ambos os lados têm de pôr o chapéu de detetive e trabalhar em conjunto. O sensor não lê porque o firmware está errado, ou há uma ponte de solda a fazer curto em alguma coisa na PCB? Ao comunicar descobertas e hipóteses, a equipa consegue fechar o cerco ao problema mais depressa. Esta resolução colaborativa de problemas é uma das partes mais educativas do processo – e frequentemente reforça a compreensão da equipa sobre o produto como um todo.

Também mantenha um olho no futuro: se planeia eventualmente fabricar este produto em escala, use esta fase de protótipo para pensar em fabrico e teste a longo prazo. Lembra-se do DFM e DFT? Agora é a altura de validar essas decisões. Por exemplo, se incluiu um header de programação, experimente usá-lo num teste de produção simulado: consegue ligar e programar a placa facilmente? Se adicionou test pads, estão acessíveis a um testador bed-of-nails? É muito mais fácil ajustar o seu design para testabilidade agora do que quando tem uma linha de produção a correr.

No final da Etapa 3, deve ter um ou mais dispositivos protótipo funcionais e um conjunto sólido de lições aprendidas. Terá dados iniciais sobre desempenho (como quanta energia o seu dispositivo realmente consome? O sensor tem um desempenho preciso em condições do mundo real?). Provavelmente terá também uma lista de correções ou melhorias para a próxima versão. Mais importante, construiu a fundação física do seu produto IoT – algo que pode segurar nas mãos e que realmente funciona.

Quando esse primeiro protótipo finalmente ganha vida e envia dados como esperado, uma pequena celebração é bem merecida – a maioria dos engenheiros de hardware já sentiu um lampejo do “Está vivo!” do Dr. Frankenstein nesse momento. Aproveite-o. Hardware é difícil, e acabou de ultrapassar um marco importante no caminho da ideia à realidade.