Arquitetura do sistema e contratos de interface

Arquitetura não é esquemático

Os requisitos do monitor já dizem o que deve ser atendido. A arquitetura decide quem faz o quê e como as informações, os sinais e a energia percorrem o sistema.

Um diagrama de blocos mostra responsabilidades e interfaces; ele não precisa exibir cada resistor, pino ou fio. O esquemático detalhado virá depois, coerente com essas decisões.

Para este caso de bancada, a arquitetura precisa sustentar a medição de temperatura na faixa definida, a atualização e resposta requeridas e a indicação por LED. Ela ainda não prova desempenho: organiza as decisões que serão verificadas posteriormente.

Observe os três percursos: sinal analógico, energia de 5 V e informação tratada pelo firmware.

Caso de referência: monitor em 5 V

A proposta inicial contém estes blocos:

• Sensor — TMP36: transforma temperatura em uma tensão analógica.
• Condicionamento — MCP6002 não inversor: adapta a tensão do sensor para a aquisição; seus resistores pertencem a este bloco.
• Processamento — ADC do Uno R3 e firmware: digitaliza o sinal e transforma a leitura em decisão de indicação.
• Indicação — LED com resistor: comunica o estado definido pelo firmware.
• Alimentação — USB de 5 V: fornece energia à placa e, na configuração de referência, aos blocos analógicos.

O LED não mede temperatura e o sensor não decide a indicação. Essa separação permite localizar responsabilidades e revisar mudanças sem confundir funções.

Associe cada bloco à sua responsabilidade principal nesta arquitetura inicial.

Verificação de completude

Uma arquitetura está incompleta quando um requisito não encontra um responsável. Por exemplo: se o requisito determina uma indicação visual, mas o diagrama termina no ADC, falta o bloco que apresenta essa decisão ao usuário.

Nesta etapa, registre somente a relação:

requisito → bloco responsável → conexão necessária

Exemplo: “indicação por LED → indicação e firmware → GPIO do Uno até LED com resistor”. Os limites de tensão, os estados de inicialização, o ganho e a escolha de pinos ainda serão contratados adiante.

Nesta configuração, a topologia de alimentação começa com uma única origem: a porta USB conectada ao Uno R3. O Uno distribui sua rede de 5 V para os blocos externos; todos compartilham a mesma referência GND.

Declare o caminho de energia separadamente do caminho de sinal:

• USB → Uno R3;
• pino 5 V do Uno → TMP36 e MCP6002;
• GND do Uno → TMP36, MCP6002 e retorno dos sinais;
• saída do MCP6002 → entrada ADC do Uno;
• GPIO do Uno → resistor → LED.

O diagrama de energia deixa explícito quem alimenta quem. Ele não substitui o esquemático, nem demonstra ainda se a fonte suporta a corrente total: essa verificação virá no orçamento de consumo.

Para esta configuração, não conecte simultaneamente outra fonte ao VIN, ao conector de alimentação ou ao pino 5 V do Uno. Essas conexões criariam fontes independentes potencialmente interligadas à rede já energizada pelo USB.

Também não trate o USB como “somente dados”: dependendo da conexão, ele pode transportar alimentação. A presença do conector não garante isolamento entre energia e dados, nem limita automaticamente a corrente de todos os caminhos externos.

Se um bloco estiver desligado, seus pinos de sinal não devem receber tensão de outro bloco sem que isso esteja previsto no contrato elétrico. Um sinal pode criar um caminho indireto de alimentação por estruturas internas de proteção. Portanto, mantenha alimentação, referência e estados das interfaces coerentes.

Qual diagrama representa a topologia de referência sem unir fontes independentes?

Um contrato elétrico é o acordo verificável entre quem produz um sinal e quem o recebe. Para cada interface, registre:

• direção e grandeza do sinal;
• faixa prevista em relação ao GND comum;
• alimentação e condições de operação;
• carga ou impedância vista pelo produtor;
• corrente contínua ou transitória relevante;
• faixa de funcionamento garantida e limites de sobrevivência.

Assim, “saída de 0 a 5 V” é uma descrição incompleta: não informa a referência, a carga, a alimentação que torna a afirmação válida nem se 5 V é faixa de conversão, condição de operação ou máximo absoluto.

Neste step, o contrato é uma análise para a configuração alimentada por USB em 5 V. Ele estabelece compatibilidade entre blocos, mas ainda não escolhe numericamente o ganho nem calcula o erro total da medição.

Na configuração de referência, o TMP36 é alimentado pela rede de 5 V e entrega uma tensão em relação ao GND comum. Use seu modelo nominal para definir o sinal esperado:

• a 0 °C: 0,500 V;
• sensibilidade nominal: 10 mV/°C;
• na faixa do monitor, de 0 a 50 °C: 0,500 V a 1,000 V.

Esses números são nominais: descrevem o sinal previsto, não uma garantia de exatidão. A pinagem, a orientação e as condições de alimentação devem ser conferidas na folha de dados da versão do TMP36 efetivamente escolhida. Um encapsulamento TO-92 semelhante não garante a mesma ordem de terminais.

O MCP6002-I/P opera entre 1,8 V e 6,0 V; nesta arquitetura, VDD é a rede de 5 V e VSS é GND.

A saída do MCP6002 deve respeitar simultaneamente a carga, sua excursão garantida e a aquisição do ADC. Para carga de 10 kΩ ligada a VDD/2, a tabela de características DC do MCP6002-I/P garante excursão de saída até 0,15 V acima de VSS e até 0,15 V abaixo de VDD, para VDD entre 2,7 V e 5,5 V e temperatura de −40 °C a +85 °C.

Na condição conservadora que será usada na arquitetura, VDD = 4,75 V. Logo, essa garantia corresponde a aproximadamente 0,15 V a 4,60 V sob a carga declarada. A faixa de projeto reservada para a saída do condicionamento, até 4,20 V, cabe nesse intervalo; restam 0,40 V até o limite superior garantido. A escolha do ganho que leva a essa faixa será feita no próximo step.

Da temperatura à tensão do sensor

A faixa útil do caso é 0 a 50 °C. Para o TMP36, use o modelo nominal já adotado:

V_sensor = 0,500 V + (0,010 V/°C × T)

Assim:

• 0 °C → 0,500 V;
• 50 °C → 1,000 V.

No condicionador não inversor, o ganho atua sobre a tensão inteira do sensor:

V_out = G × V_sensor

Logo, ele amplia não apenas a variação de 500 mV na faixa, mas também o offset nominal de 500 mV existente a 0 °C. Escolher o maior ganho somente para ocupar mais códigos do ADC pode aproximar a saída dos limites do amplificador antes de chegar aos 50 °C.

Esta análise usa valores nominais e limites elétricos declarados para selecionar uma configuração compatível. Ela ainda não comprova erro total, calibração nem desempenho medido.

Limite garantido, teto do ADC e margem escolhida

Na condição conservadora desta arquitetura, a mesma rede alimenta MCP6002 e AVCC. Use VDD = AVCC = 4,75 V.

Para o MCP6002-I/P, a especificação usada no contrato anterior garante excursão entre VSS + 0,15 V e VDD − 0,15 V, com R_L = 10 kΩ ligado a VDD/2, para VDD entre 2,7 V e 5,5 V. Em 4,75 V, o limite superior garantido é:

4,75 − 0,15 = 4,60 V.

Isso não é o teto escolhido para o projeto. Adote duas margens explícitas:

• condicionamento: 0,40 V abaixo da excursão garantida → 4,20 V;
• ADC: 0,50 V abaixo de AVCC → 4,25 V.

A interseção impõe o teto de projeto de 4,20 V. Portanto, como o TMP36 chega nominalmente a 1,00 V, o ganho nominal deve ser no máximo 4,2. Esse valor chega ao teto; uma escolha abaixo dele preserva margem adicional.

Com o TMP36 em 50 °C, sua saída nominal é 1,00 V. Qual ganho máximo levaria a saída exatamente ao teto de projeto de 4,20 V?

Um contrato de interface não termina na operação normal. Para o monitor, declare o comportamento em quatro estados:

• Reset: o microcontrolador ainda não executa a lógica da aplicação.
• Inicialização: o firmware configura periféricos e aguarda a primeira aquisição utilizável.
• Operação válida: há uma aquisição aceita pelo critério definido para o sistema.
• Informação indisponível: ainda não existe leitura aceita ou a aplicação decidiu que a informação não pode ser usada.

Assim, um sinal elétrico presente no ADC não equivale automaticamente a uma medição válida. A validade é uma decisão do contrato de firmware, baseada nas condições que ele consegue observar.

Para um LED ativo em nível alto, o contrato deve registrar a cadeia completa: GPIO em nível alto → resistor limitador → LED → referência. Após o firmware configurar o pino como saída, ele pode comandar LOW para apagar e HIGH para acender.

Durante reset, porém, o GPIO não está sob o controle normal da aplicação. O firmware só atua depois que começa a executar e configura o pino. Logo, “o código começa apagando o LED” não é garantia de LED apagado durante todo o reset — inclusive em uma reinicialização ligada à conexão USB.

O firmware não deve misturar leitura do ADC, conversão física, regra do LED e mensagens de diagnóstico em um único trecho difícil de revisar. Separe-o por responsabilidade:

• Aquisição: lê o ADC e publica uma amostra com código bruto, instante e validade.
• Conversão: transforma a amostra em tensão e temperatura usando a referência e o ganho declarados.
• Decisão de indicação: aplica a política do LED somente a uma medição válida.
• Diagnóstico: registra ou transmite dados publicados; observa o fluxo, mas não comanda a medição.

Essa divisão deixa claro onde cada decisão ocorre. Também impede, por exemplo, que a conversão seja feita uma vez no módulo de medição e novamente, de forma diferente, no módulo do LED.

O contrato entre módulos deve preservar o significado da informação. Uma amostra útil não é apenas um número: registre o código bruto do ADC, a tensão calculada quando aplicável, a temperatura em °C, a validade e o instante de aquisição.

A aquisição publica o código bruto e o instante. A conversão, em um único local, usa a referência do ADC e o ganho analógico da configuração identificada. Assim, produz a tensão estimada do sensor e a temperatura, sem que outro módulo divida novamente pelo ganho ou aplique outra referência.

A decisão do LED recebe temperatura e validade. Se a leitura não for válida — inclusive antes da primeira aquisição aceita — ela aplica o estado apagado definido no contrato de indicação; não interpreta um número antigo ou aparentemente plausível como confiável.

Um contrato mínimo usa tipos simples e mantém a validade como parte explícita dos dados publicados. A referência e o ganho pertencem à conversão, não à decisão do LED.

Organize o caminho que determina o estado do LED. Considere que o diagnóstico observa os dados publicados em paralelo, sem entrar nesta sequência de comando.

Complete a função do módulo de conversão. Ela deve tornar a saída inválida antes de rejeitar uma amostra inválida. Portanto, mesmo que a estrutura medida tenha sido usada em uma conversão anterior, a decisão do LED não poderá reutilizá-la como uma medição válida.

A referência do ADC e o ganho aparecem uma única vez na conversão. A decisão de indicação recebe o resultado pronto; ela não refaz essa conta.

Antes da montagem, transforme a alocação em um mapa de recursos. Para cada recurso do Uno R3, registre: quem o usa, qual configuração ele exige e quais outros usos ficam proibidos ou condicionados.

Esse mapa não é uma lista de pinos solta. Ele revela configurações globais compartilhadas. Uma decisão local — por exemplo, trocar a referência do ADC ou reconfigurar um temporizador — pode alterar o contrato de outro bloco que aparentemente não usa o mesmo pino.

Nesta configuração inicial, o condicionamento entrega o sinal ao ADC; o firmware converte a leitura e decide a indicação; o diagnóstico usa a serial sem assumir o controle da aquisição.

Três conflitos frequentes

• Referência do ADC: um módulo que muda para referência interna torna inválida a conversão que pressupõe AVCC. A leitura pode continuar retornando números, mas com escala errada ou com risco de exceder a faixa admitida.
• Timer0: alterar seus registradores para criar outra base de tempo pode comprometer millis() e, com isso, o período de atualização do monitor. Se millis() é parte do contrato, Timer0 fica reservado.
• D0/D1: são a UART usada pela interface USB serial. Atribuí-los a um LED, sensor ou outro circuito externo pode interferir na gravação, nas mensagens de diagnóstico ou nos dois.

Compartilhar só é aceitável quando há uma decisão única, documentada e compatível. Duas decisões independentes que exigem configurações diferentes caracterizam conflito.

Considere esta proposta de alteração: para “aumentar a resolução”, um módulo modifica a referência do ADC para a referência interna. A aquisição do TMP36 continua em A0, e sua conversão para temperatura permanece calculada para AVCC. O LED segue em D8 e a atualização usa millis().

Qual correção preserva os contratos existentes?

Uma configuração inicial é uma fotografia identificada das decisões de hardware e firmware que foram analisadas em conjunto. Não é apenas uma lista de componentes, uma BOM ou um esquemático isolado.

Ela registra escolhas, suas justificativas, as condições em que valem e os parâmetros que o firmware precisa usar. Assim, um cálculo ou ensaio futuro pode declarar exatamente a qual combinação de hardware e firmware se aplica.

Se uma decisão mudar, crie ou identifique uma revisão e atualize seus dependentes antes de comparar previsões e resultados.

Uma alteração não é local quando muda o significado elétrico ou numérico de outro bloco. Alterar somente o esquemático ou somente uma constante cria uma configuração híbrida, que não corresponde à versão analisada.

Se Rf ou Rg mudar, revise o ganho, a faixa prevista na saída do MCP6002 e a constante GANHO. Se a referência do ADC mudar, revise a escolha elétrica, VREF_ADC_NOMINAL_V e a conversão de código bruto para tensão. O mesmo raciocínio vale para pinos, topologia de alimentação e carga do GPIO.

Revisão integrada

Uma arquitetura só está pronta para a próxima etapa quando suas decisões não se contradizem. Revise cinco dimensões em conjunto:

1. Responsabilidade: sensor mede; condicionamento adapta o sinal; ADC converte; firmware interpreta e decide; LED indica.
2. Interfaces: cada ligação declara direção, faixa, referência comum, carga e estado esperado.
3. Margens: sinal amplificado deve permanecer na região útil do amplificador e do ADC, não apenas abaixo de um limite idealizado.
4. Estados: reset, inicialização e dado inválido também têm comportamento definido.
5. Recursos compartilhados: alimentação, referência do ADC, UART e temporizadores exigem decisões compatíveis.

A pergunta de revisão não é “cada bloco parece funcionar?”. É: os contratos continuam válidos quando os blocos são conectados?

Proposta para analisar

Um monitor de bancada mede 0 a 50 °C com TMP36, MCP6002, Arduino Uno R3 e LED.

A proposta declara: Uno alimentado por USB, mas também uma fonte externa de 5 V conectada ao pino 5V; ganho não inversor de 10; ADC com referência AVCC; LED ativo em nível alto no pino D1; mensagens de diagnóstico pela serial; e LED apagado antes da primeira medição válida.

Considere o TMP36 nominal: 0,50 V a 0 °C e 1,00 V a 50 °C. Localize os conflitos antes de qualquer montagem ou energização.

Registro mínimo da configuração inicial

No seu registro local, identifique a versão de hardware e firmware e anote, para cada decisão, escolha, justificativa e condição de validade. Para este caso, registre pelo menos:

• TMP36 e versão consultada da folha de dados;
• USB como origem exclusiva e caminhos de 5 V e GND;
• MCP6002, ganho inicial 4 e razão de resistores 3:1;
• faixa nominal prevista de 2,0 V a 4,0 V na saída do condicionamento;
• ADC em A0 com AVCC como referência selecionada;
• LED ativo alto em D8, resistor e política para reset/dado inválido;
• D0/D1 reservados à UART e Timer0 sem reconfiguração.

Esse registro muda se mudar ganho, referência, pinos ou hardware correspondente.