STM32 Mbed CodeIDE (1/8): primeiro piscar

A programação embarcada costuma começar com uma prova visível simples: seu código consegue alterar um dispositivo físico quando recebe uma instrução? Uma primeira piscada é pequena, mas verifica toda a cadeia — editar, compilar, fazer upload e observar a placa real.

Mbed OS fornece ao seu programa C++ um conjunto de APIs prontas para trabalho com microcontroladores: pinos digitais, entradas analógicas, saídas PWM, temporização, threads e mensagens seriais. Neste laboratório, CodeIDE fornece o ambiente Mbed para a placa STM32 remota. Seu programa reside em main.cpp, inclui mbed.h, inicia em int main() e controla o hardware criando objetos Mbed.

Por exemplo, DigitalOut status_led(PB_5, 0); cria um objeto de saída chamado status_led conectado ao pino STM32 PB_5. Lições posteriores usam outros objetos Mbed, como DigitalIn, AnalogIn e PwmOut.

As explicações desta atividade são suficientes para concluir a tarefa. Se quiser consultar a documentação oficial enquanto trabalha, mantenha estas páginas por perto:

- APIs de entrada e saída do Mbed OS
- Referência da API do Mbed CE

A ideia inicial é piscar: ligar uma saída, esperar, desligar, esperar e repetir.

Em Mbed, você primeiro cria um objeto conectado a um pino:

DigitalOut status_led(PB_5, 0);

Leia essa linha como: "faça uma saída digital chamada status_led no pino PB_5 e inicie-a no valor 0."

A placa que você está programando é a STM32 Nucleo WB55RG.

Dentro de while (true), o programa se repete para sempre:

status_led = !status_led.read();
ThisThread::sleep_for(500ms);

Leia a primeira linha como: "leia o valor atual, altere-o para o valor oposto e armazene o novo valor de volta na saída." O operador ! significa "não" ou "oposto" para um valor 0/1.

Uma mudança de estado é uma transição, como ligado para desligado ou desligado para ligado. Um ciclo completo de piscadas precisa de duas mudanças de estado: uma para ligar e outra para desligar novamente.

Planeje duas compilações e cerca de 18 minutos de tempo de laboratório ativo: primeiro 500ms, depois 1000ms. Se a fila do laboratório remoto estiver ocupada, responda ambas as perguntas de previsão e prepare os títulos para ambas as observações antes da sua vez.

Copie todas as linhas de #include "mbed.h" até o } final. O código inicial contém exatamente um marcador que impede a compilação. Substitua TODO 1 antes de salvar ou compilar; TODO_WAIT_VALUE não é C++ válido.

#include "mbed.h"

DigitalOut status_led(PB_5, 0);

int main() {
    // 1: substitua o espaço reservado por 500 ms para compilação 1.
    const auto wait_time = TODO_WAIT_VALUE;

    while (true) {
        status_led = !status_led.read();
        ThisThread::sleep_for(wait_time);
    }
}

Antes de alterar o tempo de espera, preveja o que acontecerá. Use sua resposta sobre o intervalo entre mudanças de estado para decidir se 1000ms fará o LED mudar mais rápido, mais devagar ou quase no mesmo ritmo.

Como encontrar o LED que muda: após o upload, compare a câmera ao vivo antes e depois de o programa começar. Ignore LEDs que permaneçam sempre acesos ou sempre apagados e breves flashes de upload ou status. Observe o LED que continua mudando no intervalo programado; ao passar de 500ms para 1000ms, o mesmo LED deve continuar mudando, agora no novo ritmo.

O cartão do laboratório possui um botão Marcar prática como concluída. Não clique ainda; use-o somente depois de concluir todas as etapas numeradas, incluindo o novo teste 1000ms.

Registre as duas observações nas caixas abaixo. A razão para cronometrar cinco intervalos é prática: uma alteração LED é curta e difícil de cronometrar com precisão em uma câmera ao vivo, mas cinco alterações fornecem uma estimativa mais estável.

Use este método para cada versão:

1. Inicie o cronômetro quando LED mudar de estado. Esta alteração inicial é o início do intervalo 1.
2. Conte as próximas alterações visíveis em voz alta ou no papel: 1, 2, 3, 4, 5.
3. Pare o cronômetro na mudança que você contou como 5. Sua duração cronometrada agora cobre cinco intervalos de mudança de estado.
4. Divida a duração cronometrada por 5 para estimar um intervalo de mudança de estado.
5. Um ciclo completo de piscada leva duas mudanças de estado, então multiplique seu intervalo de mudança de estado por 2.

Exemplo: se cinco intervalos durarem cerca de 2,6 s, cada mudança de estado levará aproximadamente 0,52 s e um ciclo completo de piscada, cerca de 1,04 s.

A maioria dos programas neste curso segue a mesma estrutura Mbed OS: inclui mbed.h, cria objetos de hardware como DigitalOut, inicia em int main() e coloca o comportamento repetido do controlador dentro de while (true).

Antes de enviar, deixe a versão final do 1000ms salva em main.cpp. Procure mais uma vez por TODO; o arquivo enviado não deve conter espaços reservados TODO.