Pular para o conteúdo principal

Laboratório 00

TarefaTemplateInícioFimConteúdo
LAB0020-08-202627-08-2026Apresentação da Disciplina; Formação dos grupos;

Checklist — Apresentação da Disciplina; Materiais utilizados na disciplina;​

  • Verificar o Windows e o winget
  • Executar winget source update
  • Instalar o VS Code
  • Instalar o Git
  • Verificar git --version
  • Configurar user.name
  • Configurar user.email
  • Abrir o VS Code
  • Instalar a extensão PlatformIO IDE
  • Instalar a extensão Wokwi
  • Ativar/configurar o Wokwi
  • Criar um projeto ESP32
  • Selecionar o framework Arduino
  • Executar o primeiro Build
  • Criar wokwi.toml
  • Criar diagram.json
  • Executar a simulação
  • Verificar o Serial Monitor
  • Inicializar o Git
  • Criar o primeiro commit
  • Criar o repositório no GitHub
  • Executar git push
  • Confirmar que o projeto está disponível no GitHub
  • Logout
Antes de começar

Confira o ambiente (faça a configuração uma vez por máquina; a verificação, a cada aula):

  1. Instalar as ferramentas — git, GitHub CLI e VS Code
  2. Configurar o git — nome, e-mail e editor padrão (uma vez)
  3. Verificar git, gh e VS Code — deve mostrar as versões e Logged in to github.com

Verificação rápida de versão instalada:

git -v && gh --version && code -v && pio --version && wokwi-cli -V && wsl --version && docker --version

Verificação rápida de autenticação:

git config --get-regexp ^user\. && gh auth status && code --list-extensions --profile "ESP32IO"
Ao terminar — máquina de laboratório

Antes de sair, faça logout para não deixar sua conta do GitHub ativa na máquina (limpa a credencial salva do git e encerra a sessão do gh).

Logout​

O Git é a ferramenta de gerenciamento de código-fonte mais utilizada por desenvolvedores profissionais.

  • O Git é um sistema de controle de versão distribuído gratuito e de código aberto, projetado para lidar com tudo, desde projetos pequenos até muito grandes, com rapidez e eficiência.
winget install --id Git.Git -e --source winget

Configurações do git:

git config --list --show-origin

Configure o git​

Configure o nome de usuário para todos os repositórios locais ligados às suas transações de commit:

git config --global user.name "Your Name"

Configure o email de usuário para todos os repositórios locais ligados às suas transações de commit:

git config --global user.email "you@example.com"

É recomendado verificar se a instalação do seu Git não está realizando nenhuma transformação entre LFs e CRLFs.

git config --global core.autocrlf false

Configure o git para usar o Visual Studio Code como editor padrão para tarefas como escrever mensagens de commit ou rebases interativos

git config --global core.editor "code --wait"

Habilite a coloração automática da saída da linha de comando do Git:

git config --global color.ui auto

Configura o Git para usar main como o nome do branch padrão sempre que você inicializar um novo repositório localmente:

git config --global init.defaultBranch main

Liste as configurações aplicadas:

git config --list --show-origin

Status do git, gh e code:​

Versão do git e configurações:

git --version && git config --list --show-origin

Versão do GitHub CLI e status de login:

gh --version && gh auth status

Versão do Visual Studio Code e extensões instaladas:

code -v && code --list-extensions --profile "ESP32IO"

Parte 01 — Introdução ao Git, GitHub e entrega com CI

Objetivo: usar o repositório do grupo (criado a partir do template), praticar o fluxo Git e verificar o Autograde (CI) que compõe a nota de entrega.

Organização: ELT85B-N21-2026-2
Seu repositório: lab00-grupo-<sua-letra> (ex.: lab00-grupo-a)
Time: Grupo-<LETRA>

0. O que você vai validar neste lab​

EtapaRecursoComo “testar”
1Repo criado do templateClone e confira a estrutura (src/, platformio.ini, .github/workflows/)
2Git localstatus, add, commit, histórico
3GitHub remotopush, ver commits no site
4CI / AutogradeAba Actions ou gh run list — build verde/vermelho
5Nota de entregaPush na main dispara o workflow; sucesso = entrega válida no CI

1. Pré-requisitos (antes da aula)​

  1. Conta no GitHub e convite aceito na organização / time do grupo
  2. Git instalado
  3. GitHub CLI (gh) instalado
  4. VS Code (perfil da disciplina, se houver — ex. "ESP32IO")

Login (uma vez):

gh auth login
git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

Confira:

gh auth status
Estrutura organizacional dos repositórios
ELT73A-S22-2026-2
├── Times
│   ├── Grupo-A
│   ├── ...
│   ├── Grupo-P  # (Professor)
│   └── Grupo-N  # (Notas)
└── Repositórios
    ├── lab00-template
    ├── lab00-grupo-a
    ├── ...
    ├── lab00-grupo-p  # (Professor)
    └── lab00-grupo-n  # (Notas)

Repositório do Grupo A para Laboratório 00:

ELT85B-N21-2026-2/lab00-grupo-a
  1. Copie o link do repositório acima.
  2. Abra a página de envio da atividade no Moodle (botão abaixo).
  3. Clique em Adicionar envio.
  4. Cole o link no campo Texto online.
  5. Clique em Salvar mudanças.
  6. Confira se o status mudou para Enviado para avaliação.
Abrir envio no Moodle
Avaliação por commits

Cada cartão Ponto de commit é uma tarefa: faça-a, copie o comando do cartão e rode. A mensagem começa com o código (T1:, T2:…) — é como a correção identifica sua entrega. Um commit por tarefa; pode refazer (vale o mais recente); e não esqueça o git push. Detalhes em Como funciona a avaliação.

Estrutura do Laboratório 00​

📂 lab00-grupo-x (git repo)/
  • ├── 📂.github
    • └── 📂workflows
      • ├── 🚀grade.yml
      • └── 🚀teste.yml
  • └── 🔧wokwi.toml

2. Conceitos mínimos (10 min)​

Working area  →  Staging  →  Commit  →  Push  →  GitHub
   (editar)       (git add)  (git commit) (git push)  (remoto)

No GitHub: Actions (CI) roda o Autograde a cada push.
ComandoFunção
git cloneCopia o repositório
git statusO que mudou
git addPrepara arquivos para o commit
git commitSalva um snapshot local
git pushEnvia commits ao GitHub
git pullBaixa commits do GitHub
gh run listVê o resultado do CI

3. Atividade 1 — Clonar o repo do template​

Substitua a pela letra do seu grupo.

gh repo clone ELT85B-N21-2026-2/lab00-grupo-a
cd lab00-grupo-a
code . --profile "ESP32IO"
pio project init -b esp32dev -O "framework=arduino" -O "monitor_speed=115200" --sample-code

Crie ou edite o arquivo src/main.cpp com a seguinte estrutura:

#include <Arduino.h>

// Definição de pinos
#define LED_PIN 2

// Protótipos de funções (obrigatório em C/C++ padrão)
void blinkLed(uint8_t pin, uint16_t delayMs);

void setup() {
  Serial.begin(115200);
  pinMode(LED_PIN, OUTPUT);
  Serial.println("ESP32 Inicializado!");
}

void loop() {
  blinkLed(LED_PIN, 500);
}

// Implementação de funções auxiliares
void blinkLed(uint8_t pin, uint16_t delayMs) {
  digitalWrite(pin, HIGH);
  delay(delayMs);
  digitalWrite(pin, LOW);
  delay(delayMs);
}

Checklist (template ok):

  • Existe README.md
  • Existe platformio.ini (ou estrutura do lab)
  • Existe .github/workflows/grade.yml (ou nome do workflow de CI)
  • Existe pasta src/ (ou equivalente)

Se a estrutura estiver incompleta, avise o professor antes de seguir (problema de template/propagação).

4. Atividade 2 — Primeiro ciclo Git (obrigatório)​

4.1 Ver estado​

git status
git log --oneline -5

4.2 Fazer uma alteração visível​

Edite o README e adicione no final:

## Integrantes — LAB00

- Nome 1
- Nome 2

Salve o arquivo.

4.3 add → commit → push​

git status
git add README.md
git commit -m "lab00: adiciona nomes dos integrantes"
git push

4.4 Conferir no GitHub​

gh repo view --web

Na interface: commits recentes devem mostrar a mensagem acima.

Critério desta atividade: existe pelo menos um commit seu na branch padrão (main) com a mensagem pedida (ou equivalente clara).

5. Atividade 3 — Disparar e ler o CI (Autograde)​

Após o push, o GitHub Actions executa o workflow do template.

gh run list

Abra a execução mais recente:

gh run view

Ou no navegador: repositório → aba Actions.

ResultadoSignificado neste lab
success (verde)Build/CI ok — entrega válida no critério automático
failure (vermelho)Algo quebrou (compile, arquivo faltando, etc.) — corrija e dê push de novo
queued / in_progressAguarde 1–2 minutos e atualize

Se falhou​

  1. Abra o log do job que falhou
  2. Corrija no código
  3. Novamente:
git add .
git commit -m "lab00: corrige falha do CI"
git push
gh run list

Critério: última execução na main com conclusion success.

6. Atividade 4 — Segundo commit (prática de fluxo)​

Altere um arquivo de código do template (ex.: comentário em src/main.cpp):

// LAB00 - Grupo A - teste de commit e CI
git add src/main.cpp
git commit -m "lab00: comentário de identificação no main"
git push
gh run list

Confirme de novo o CI verde.

7. Atividade 5 (opcional) — Branch e Pull Request​

git checkout -b feature/readme-extra
# edite algo pequeno no README
git add README.md
git commit -m "lab00: texto extra no README"
git push -u origin feature/readme-extra
gh pr create --title "LAB00: extra README" --body "Exercício de PR"

No GitHub, veja se o CI também roda no PR. Depois o professor pode orientar merge (ou não usar PR neste lab).

8. Como a “nota” do CI entra na disciplina​

Modelo simples usado neste lab:

CritérioPeso sugerido
Repo do grupo acessível + clone ok (veio do template)20%
Commits dos integrantes na main30%
CI success na última execução da main50%

O professor pode coletar o status com:

gh run list -R ELT85B-N21-2026-2/lab00-grupo-a -L 1

Importante: CI verde valida o pipeline de entrega (template → git → GitHub → Actions). Não substitui, sozinho, toda a correção técnica dos labs seguintes.

9. Comandos de bolso​

clone   →  gh repo clone ELT85B-N21-2026-2/lab00-grupo-a
status  →  git status
salvar  →  git add . && git commit -m "msg" && git push
web     →  gh repo view --web
ci      →  gh run list

10. Problemas comuns​

ProblemaO que fazer
Permission denied no pushgh auth status; confirmar se está no time Grupo-X
Repo 404Nome certo? Convite da org aceito?
CI não apareceExiste .github/workflows/? Push foi na branch certa?
CI vermelhoLer o log; corrigir; novo commit + push
GROUPS=197121 em scriptsNão usar variável Bash chamada GROUPS (reservada)

11. Entrega do LAB00 (resumo)​

  1. Clone de lab00-grupo-<x> (estrutura do template ok)
  2. README com nomes dos integrantes (commit)
  3. Pelo menos um commit de código/comentário
  4. git push na main
  5. Actions com success na execução mais recente

12. Para o professor (bastidor)​

RecursoComo foi exercitado no LAB00
TemplateAluno confere árvore de arquivos ao clonar
Times + permissãoSó o grupo faz push no próprio repo
Gitadd / commit / push / (opcional) branch + PR
CIWorkflow do template roda no push
NotasScript gh run list por lab00-grupo-*

Antes da aula: template com grade.yml ok; repos lab00-grupo-* criados; times com push; alunos nos times.

Depois da aula: rodar coleta de CI e cruzar com presença/integrantes no README.

Exemplos — nova branch e release

Contexto: repo do grupo ELT85B-N21-2026-2/lab00-grupo-a (troque a letra).

1. Nova branch​

Criar e usar uma branch​

# Garantir que a main está atualizada
git checkout main
git pull

# Criar e já mudar para a nova branch
git checkout -b feature/exercicio-1

# (equivalente mais novo)
# git switch -c feature/exercicio-1

Trabalhar na branch​

# edite arquivos...
git status
git add .
git commit -m "lab00: resolve exercício 1"
git push -u origin feature/exercicio-1

O -u origin feature/exercicio-1 liga a branch local à remota (só precisa na primeira vez).

Abrir Pull Request​

gh pr create --base main --head feature/exercicio-1 \
  --title "LAB00: exercício 1" \
  --body "Implementação do exercício 1"

Ou no navegador:

gh repo view --web

Voltar para main e apagar a branch (depois do merge)​

git checkout main
git pull
git branch -d feature/exercicio-1          # apaga local
git push origin --delete feature/exercicio-1  # apaga no GitHub (opcional)

Nomes de branch sugeridos​

NomeUso
feature/exercicio-1nova funcionalidade / exercício
fix/ci-buildcorreção de build/CI
docs/readme-integrantessó documentação
lab00/entregapreparação da entrega

Evite espaços e acentos no nome da branch.

2. Release (marcar uma versão)​

Release = tag (e opcionalmente página de Release no GitHub) apontando para um commit estável, em geral na main.

Fluxo simples (tag + push)​

git checkout main
git pull

# Tag anotada (recomendado)
git tag -a v0.1.0 -m "LAB00: primeira entrega estável"

# Enviar a tag ao GitHub
git push origin v0.1.0

Criar a Release no GitHub com gh​

gh release create v0.1.0 \
  --title "LAB00 v0.1.0" \
  --notes "Primeira entrega do LAB00.
- README com integrantes
- CI verde na main
- Comentário de identificação no código"

Release a partir de uma tag que já existe​

git tag -a v0.1.0 -m "LAB00 entrega"
git push origin v0.1.0

gh release create v0.1.0 \
  --title "LAB00 v0.1.0" \
  --notes-file RELEASE_NOTES.md

Ver tags e releases​

git tag -l
gh release list
gh release view v0.1.0 --web

3. Exemplo completo (branch → PR → main → release)​

# 1) Branch de trabalho
git checkout main && git pull
git checkout -b feature/lab00-entrega

# 2) Alterações
# ... editar README e código ...
git add .
git commit -m "lab00: finaliza entrega"
git push -u origin feature/lab00-entrega

# 3) Pull Request
gh pr create --title "LAB00: entrega" --body "Pronto para revisão"

# 4) Depois do merge na main (no GitHub ou: gh pr merge)
git checkout main
git pull

# 5) Conferir CI
gh run list -L 3

# 6) Release só se a main estiver verde
git tag -a v0.1.0 -m "LAB00: entrega com CI ok"
git push origin v0.1.0
gh release create v0.1.0 --title "LAB00 v0.1.0" --generate-notes

--generate-notes monta notas automáticas a partir dos PRs/commits.

4. Versionamento simples para a disciplina​

TagSignificado
v0.1.0primeira entrega do lab
v0.1.1correção após feedback (bugfix)
v0.2.0segunda parte / melhoria maior

Padrão comum: MAJOR.MINOR.PATCH (v1.0.0).

Para labs, v0.1.0 = “entregamos o LAB00 com CI verde” já basta.

5. Erros comuns (branch e release)​

Branch​

fatal: A branch named 'feature/exercicio-1' already exists.

→ Use outro nome ou: git checkout feature/exercicio-1

error: Your local changes would be overwritten by checkout

→ Faça commit ou git stash antes de trocar de branch.

Release / tag​

fatal: tag 'v0.1.0' already exists

→ Use v0.1.1 ou apague a tag (só se tiver certeza):

git tag -d v0.1.0
git push origin --delete v0.1.0
gh: HTTP 422 ... Release already exists

→ A release v0.1.0 já foi criada; edite no site ou use outra versão.

6. O que usar no LAB00?​

RecursoObrigatório?Objetivo
Commits + push na mainSimentrega + CI
Nova branch + PROpcionalpraticar colaboração
Release v0.1.0Opcionalmarcar versão “congelada” da entrega

Sugestão pedagógica:

  • Atividade principal: main + CI verde
  • Atividade extra: branch feature/... + PR
  • Atividade extra: tag/release v0.1.0 quando o CI estiver verde

Trecho para colar no material do aluno​

# Nova branch
git checkout main && git pull
git checkout -b feature/exercicio-1
git add . && git commit -m "lab00: exercício 1"
git push -u origin feature/exercicio-1
gh pr create --title "LAB00: exercício 1" --body "Concluído"

# Release (após merge e CI verde na main)
git checkout main && git pull
git tag -a v0.1.0 -m "LAB00: entrega"
git push origin v0.1.0
gh release create v0.1.0 --title "LAB00 v0.1.0" --generate-notes

Tabela do Plano de Aulas​

SemanaItemTema / Conteúdo PrincipalTeoria (2h)Prática (2h)Entregas / Atividades
11Visão Geral sobre IoTO que é IoT, referências, usos, relação Internet × IoT, IoT vs IIoTInstalação de ferramentas (ThingsBoard, Node-RED, Docker, ESP32 IDE)Discussão de casos de uso
22A Internet na IoTModelo OSI, Arquitetura TCP/IP e seu impacto na IoTConfiguração de rede Wi-Fi no ESP32 + testes de conectividadeExercício de rede
33Sensores e Atuadores em IoTTipos de sensores e atuadores IoT/IIoT, princípios e seleçãoConexão e leitura de sensores (DHT22, MPU6050, etc.) com ESP32Relatório de sensores
44Atributos de Protocolos IoTSuporte, escalabilidade, determinismo, segurança e interoperabilidadeComparação prática: HTTP vs MQTT (latência e overhead)Análise comparativa
55Pilha de Protocolos IoTCamadas de enlace, internet, aplicação e serviços de aplicaçãoImplementação de cliente MQTT no ESP32 (publish/subscribe)Código MQTT
66Computação em Nevoeiro (Fog Computing)Definição, drivers, vantagens e tecnologias EdgeProcessamento local de dados no ESP32 (filtros e decisões locais)Exercício Edge
77Plataforma de Serviços IoTFunções das plataformas IoT (gerenciamento, processamento, regras)Introdução ao Node-RED – criação de fluxos básicosFluxo Node-RED
87Plataforma de Serviços IoT (continuação)Integração com bancos de dados e visualizaçãoIntegração ESP32 + MQTT + ThingsBoard (telemetria)Dashboard básico
97Mercados de IoT e Ecosistemas ConectadosAplicações em agricultura, energia, indústria, saúde, transporte, etc.Criação de dashboards interativos no ThingsBoardDashboard avançado
108Padrões de IoTPadrões IEEE, IETF, ITU, OPC UA, oneM2M, IIC, ETSI, etc.Regras de automação e alarmes no ThingsBoardRegras configuradas
11-Revisão e IntegraçãoSíntese dos conteúdos 1 a 8Controle remoto de atuadores + integração completaProposta do Projeto Final (1 página)
12-Desenvolvimento do Projeto FinalBoas práticas de integração IIoTPrototipagem: aquisição de dados + envio MQTTProgresso do projeto
13-Desenvolvimento do Projeto FinalEstudos de caso industriaisDesenvolvimento de dashboard, regras e automaçãoVersão intermediária
14-Desenvolvimento + Aspectos AvançadosSegurança, escalabilidade e integração com sistemas legadosFinalização, testes e implementação de segurançaProjeto quase pronto
15-Apresentação e EncerramentoTendências futuras (IA, 5G, Digital Twins)Apresentações orais + demonstrações ao vivoEntrega Final (Relatório + Vídeo)

Materiais utilizados na disciplina​

ESP32 (Wokwi Supported)​

Sensores​

Display​

Ambiente de desenvolvimento​

Bibliotecas utilizadas​

Updated script snippet (replace the “Create starter folder structure” part)

# 3. Create PlatformIO starter structure
mkdir -p src include lib test .github/workflows

# platformio.ini
cat > platformio.ini << 'EOF'
[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
monitor_speed = 115200
test_framework = unity
EOF

# src/main.cpp
cat > src/main.cpp << EOF
#include <Arduino.h>

void setup() {
  Serial.begin(115200);
  delay(1000);
  Serial.println("LAB$lab started - ESP32 + PlatformIO");
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH);
  delay(500);
  digitalWrite(LED_BUILTIN, LOW);
  delay(500);
}
EOF

# test/test_main.cpp
cat > test/test_main.cpp << 'EOF'
#include <unity.h>
#include <Arduino.h>

void test_example() {
  TEST_ASSERT_TRUE(true);
}

void setup() {
  delay(2000);
  UNITY_BEGIN();
  RUN_TEST(test_example);
  UNITY_END();
}

void loop() {}
EOF

# .gitignore
cat > .gitignore << 'EOF'
.pio
.vscode/.browse.c_cpp.db*
.vscode/c_cpp_properties.json
.vscode/launch.json
.vscode/ipch
.DS_Store
EOF

# README.md
cat > README.md << EOF
# LAB$lab - ESP32 + PlatformIO

## Commands
\`\`\`bash
pio run              # build
pio run -t upload    # upload
pio device monitor   # serial
pio test             # unit tests
\`\`\`
EOF

# GitHub Actions
cat > .github/workflows/grade.yml << 'EOF'
name: Build

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install PlatformIO
        run: pip install platformio
      - name: Build
        run: pio run
EOF

# placeholders
echo "Project headers go here" > include/README
echo "Private libraries go here" > lib/README

LAB00 — VS Code + PlatformIO (ESP32/Arduino) + Wokwi + Git/CI

Objetivo: montar o ambiente, simular no Wokwi, gravar o fluxo de trabalho no GitHub e validar a entrega com CI (Autograde).

Repo do grupo: ELT73A-S22-2026-2/lab00-grupo-<letra>
Stack: VS Code · PlatformIO · ESP32 · framework Arduino · Wokwi · GitHub Actions

0. O que este lab exercita​

CamadaFerramentaVocê pratica
Editor / projetoVS Code + PlatformIOAbrir, build, monitor
Hardware (simulado)WokwiSimular ESP32 sem placa
Hardware (opcional)ESP32 realUpload + serial
VersionamentoGit + GitHubcommit / push
Nota automáticaActions (grade.yml)CI verde na main

1. Instalação (uma vez)​

1.1 Obrigatório​

  1. VS Code
  2. Extensão PlatformIO IDE (no VS Code: Extensions → “PlatformIO IDE”)
  3. Git + GitHub CLI
  4. Conta GitHub no time do seu grupo
gh auth login
git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

1.2 Recomendado para simulação​

  • Extensão Wokwi Simulator no VS Code, ou
  • Uso pelo site wokwi.com (com os arquivos do projeto)

1.3 Opcional (placa física)​

  • Cabo USB dados (não só carga)
  • Driver da USB-UART (CP210x / CH340, conforme a placa)
  • Placa ESP32 (ex.: DevKit)

2. Abrir o projeto do lab​

gh repo clone ELT73A-S22-2026-2/lab00-grupo-a
cd lab00-grupo-a
code .

No VS Code, aceite abrir como projeto PlatformIO (ícone de formiga na barra lateral).

Estrutura esperada (template)​

lab00-grupo-a/
├── platformio.ini          ← ambiente ESP32 + Arduino
├── src/main.cpp            ← setup() / loop()
├── include/
├── lib/
├── test/
├── wokwi/                  ← (se o template tiver) diagrama + diagram.json
├── .github/workflows/      ← CI
└── README.md

platformio.ini (referência)​

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
monitor_speed = 115200

Outras boards comuns: esp32-s3-devkitc-1, az-delivery-devkit-v4 — use a do template da disciplina.

3. PlatformIO no VS Code — comandos essenciais​

Na barra inferior / sidebar do PlatformIO:

AçãoÍcone / comando CLI
Build✓ Build · pio run
Upload→ Upload · pio run -t upload
Monitor serialPlug · pio device monitor
Cleanpio run -t clean
Testpio test

No terminal integrado​

pio run                 # compila
pio run -t upload       # grava na ESP32
pio device monitor      # Serial a 115200
pio run -t upload && pio device monitor

Sair do monitor: Ctrl+C (às vezes Ctrl+])

src/main.cpp mínimo (Arduino)​

#include <Arduino.h>

void setup() {
  Serial.begin(115200);
  delay(1000);
  Serial.println("LAB00 - ESP32 ok");
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH);
  delay(500);
  digitalWrite(LED_BUILTIN, LOW);
  delay(500);
}

Atividade: altere a mensagem do Serial.println para incluir o nome do grupo e faça build.

4. Simulação com Wokwi​

Objetivo: validar lógica sem depender da bancada.

Opção A — Extensão Wokwi no VS Code​

  1. Instale Wokwi Simulator
  2. No projeto, use/crie:
    • diagram.json — circuito (ESP32, LED, fios)
    • wokwi.toml — liga o firmware do PlatformIO ao simulador (conforme docs do template)
  3. Comando típico da extensão: Start Simulator
  4. Abra o monitor serial do Wokwi e veja o mesmo Serial.println

Opção B — Wokwi no navegador​

  1. Acesse wokwi.com
  2. Novo projeto → ESP32
  3. Cole o conteúdo de src/main.cpp
  4. Monte LED no GPIO do LED_BUILTIN (ou no GPIO que o template usar)
  5. Start e observe LED + serial

Exemplo mínimo de ideia de diagram.json (LED no GPIO 2)​

Muitos DevKit tratam LED embutido no GPIO 2 — confirme no template.

Checklist Wokwi

  • Projeto simula e imprime no serial a mensagem do grupo
  • LED pisca conforme o loop()
  • Você não precisou da placa física para esta parte

5. Placa real (opcional, se houver ESP32)​

  1. Conecte o USB
  2. Selecione a porta no PlatformIO (ou pio device list)
  3. Upload + monitor:
pio device list
pio run -t upload
pio device monitor
ProblemaO que tentar
Porta não apareceCabo, driver, outro USB
Upload failSegurar BOOT na gravação (algumas placas)
Serial sem textomonitor_speed = 115200 igual ao Serial.begin

6. Git: salvar o trabalho e entregar​

Depois de build ok (e, se possível, Wokwi ok):

git status
git add src/main.cpp README.md
git commit -m "lab00: mensagem serial do grupo + LED"
git push

README — seção mínima:

## Integrantes

- Nome 1
- Nome 2

## Como rodar

- Build: `pio run`
- Simulação: Wokwi (extensão ou site)
- Placa: `pio run -t upload` && `pio device monitor`

7. CI / Autograde (nota automática)​

O template traz .github/workflows/grade.yml, que no GitHub roda em geral:

pio run    # compila o firmware no runner

Após o push:

gh run list
gh run view
ResultadoSignificado neste lab
successFirmware compila no mesmo tipo de ambiente do curso
failureErro de build — corrija, commit, push de novo

O CI não liga Wokwi nem a placa física.
Ele valida: projeto PlatformIO coerente + código que compila.

8. Roteiro da aula (ordem sugerida)​

TempoAtividade
10 minClone, abrir no VS Code, inspecionar platformio.ini e main.cpp
15 minpio run — primeiro build
20 minWokwi — serial + LED
10 min(Opcional) upload na ESP32 real
15 minREADME, commit, push
10 minConferir Actions verde

9. Critérios de entrega (LAB00)​

CritérioEvidência
Ambiente PlatformIOpio run local ok
Código identificadoSerial.printf / println com grupo
DocumentaçãoREADME com integrantes e como rodar
SimulaçãoDescrição ou print: Wokwi funcionando (pedido pelo professor)
GitHubCommits no repo do grupo
CIÚltimo workflow na main = success

10. Fluxo mental (além do Git)​

Editar main.cpp no VS Code
        ↓
   pio run (build local)
        ↓
   Wokwi (simular)  e/ou  upload na ESP32
        ↓
   git commit + push
        ↓
   GitHub Actions: pio run de novo (nota/CI)

11. Erros comuns (foco PlatformIO / Wokwi / ESP32)​

Build​

Error: Unknown board ID '...'

→ Ajuste board no platformio.ini para o do template.

'Serial' was not declared

→ Faltou #include <Arduino.h> ou framework não é arduino.

Serial​

  • Baud do monitor ≠ Serial.begin(115200) → lixo na tela
  • LED_BUILTIN pode não existir em todas as boards → use GPIO numérico (ex. 2)

Wokwi​

  • GPIO do LED no diagrama ≠ GPIO no código → LED “não pisca”
  • Simulador não usa o último build → rode build de novo / restarte a simulação

CI vermelho, local verde​

  • Arquivo não commitado (git status)
  • Mudança só local; falta git push

Push negado​

  • Repo certo? lab00-grupo-x, não lab00-template
  • gh auth status + membership no time

12. Comandos de bolso​

abrir    →  code .
build    →  pio run
upload   →  pio run -t upload
serial   →  pio device monitor
simular  →  Wokwi (extensão ou site)
salvar   →  git add . && git commit -m "msg" && git push
ci       →  gh run list

13. Branch / release (opcional neste lab)​

# branch de experimento
git checkout -b feature/blink-rapido
# ... muda delays, testa no Wokwi ...
git add . && git commit -m "lab00: blink mais rápido"
git push -u origin feature/blink-rapido
gh pr create --title "Blink rápido" --body "Testado no Wokwi"

# após merge + CI verde
git checkout main && git pull
git tag -a v0.1.0 -m "LAB00: entrega ambiente ESP32"
git push origin v0.1.0
gh release create v0.1.0 --title "LAB00 v0.1.0" --generate-notes

14. Para o professor​

Recurso do cursoComo o LAB00 valida
Template PlatformIO ESP32Clone já vem com ini + main.cpp + workflow
WokwiAtividade de simulação na aula
CIpio run no Actions
TimesPush só no lab00-grupo-x

Template mínimo: platformio.ini (esp32 + arduino), src/main.cpp (blink + Serial), grade.yml com pio run, README com instruções Wokwi.

Resumo em uma frase​

O LAB00 não é só Git: é o ciclo completo — VS Code/PlatformIO → Wokwi (e/ou placa) → commit → CI — base dos labs seguintes de ESP32.

Última atualização em por Adriano Ruseler