feat(Button): add example to turn on LEDs with buttons A, B and menu

[DumontALINE]

close #1

This code allows you to control the RGB LED of the STeaMi board using the three onboard buttons.

• Pressing button A turns on the red LED
• Pressing button B turns on the green LED
• Pressing button Menu turns on the blue LED

Each LED stays on for 200ms when its corresponding button is pressed, and each interaction is logged to the serial consoleHow to test

1 Flash the firmware onto the STEAMI board via PlatformIO
2 Open the serial monitor at 115200 baud
3 Press button A — the red LED should toggle on, press again and it should toggle off
4 Press button B — the green LED should toggle on, press again and it should toggle off
5 Press the MENU button — the blue LED should toggle on, press again and it should toggle off
7 Hold a button down and verify the LED toggles only once and does not flicker
8 Press multiple buttons and verify multiple LEDs can be on at the same time

Checklist

• make build passes (PlatformIO)
• Tested on hardware
• Commit messages follow conventional commits format

[Copilot]

Pull request overview

Adds a new Arduino/PlatformIO sample that uses the STeaMi onboard buttons (A, B, Menu) to pulse the corresponding RGB LED channel and log to Serial, and switches the project entrypoint to run that sample.

Changes:

• Added BUTTON/led_on.cpp example implementing button-driven RGB LED pulses with Serial logging.
• Updated src/main.cpp to run the new setup_led_on() / loop_led_on() example.
• Set upload_protocol = dfu in platformio.ini.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
src/main.cpp	Switches the selected sample to led_on (but still includes blink.cpp).
platformio.ini	Forces DFU as the upload protocol for the environment.
BUTTON/led_on.cpp	New example: reads A/B/Menu buttons and pulses red/green/blue LED channels.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

main.cpp now includes both ../LED/blink.cpp and ../BUTTON/led_on.cpp. The README documents that only one sample should be included at a time (comment/uncomment the #include lines), so the blink include should be commented out/removed when switching to led_on to avoid compiling multiple examples together.

Suggested change

	#include "../LED/blink.cpp"
	// #include "../LED/blink.cpp"

[DumontALINE]

fix in commit 2b8b927

[Copilot]

This loop triggers repeatedly while a button is held (and can also retrigger due to contact bounce), so a single press can log multiple times and pulse the LED multiple times. If the intent is "one 200ms pulse per press", add edge detection + debouncing (e.g., track previous button states and ignore changes within a debounce window using millis(), or use a debouncing helper/library).

[Copilot]

Using Serial.print("...\n") works, but it’s inconsistent with the existing example (blink.cpp) which uses Serial.println(...). Prefer Serial.println("A_BUTTON pressed") / etc. for readability and consistent newline handling.

Suggested change

	Serial.print("A_BUTTON pressed\n");
	digitalWrite(LED_RED, HIGH);
	delay(200);
	digitalWrite(LED_RED, LOW);
	}
	else if (digitalRead(B_BUTTON) == LOW)
	{
	Serial.print("B_BUTTON pressed\n");
	digitalWrite(LED_GREEN, HIGH);
	delay(200);
	digitalWrite(LED_GREEN, LOW);
	}
	else if (digitalRead(MENU_BUTTON) == LOW)
	{
	Serial.print("MENU_BUTTON pressed\n");
	Serial.println("A_BUTTON pressed");
	digitalWrite(LED_RED, HIGH);
	delay(200);
	digitalWrite(LED_RED, LOW);
	}
	else if (digitalRead(B_BUTTON) == LOW)
	{
	Serial.println("B_BUTTON pressed");
	digitalWrite(LED_GREEN, HIGH);
	delay(200);
	digitalWrite(LED_GREEN, LOW);
	}
	else if (digitalRead(MENU_BUTTON) == LOW)
	{
	Serial.println("MENU_BUTTON pressed");

[DumontALINE]

fix in commit 4cb2ad0

[Copilot]

Setting upload_protocol = dfu changes the default upload behavior for the whole project, but the board definition (boards/steami.json) doesn’t list dfu as a supported protocol. Consider either leaving the default protocol alone, or adding a separate environment (e.g. [env:steami_dfu]) so users can opt into DFU without breaking the standard upload flow.

Suggested change

	framework = arduino
	framework = arduino
	[env:steami_dfu]
	extends = env:steami

[DumontALINE]

fix in commit 4cb2ad0

[Charly-sketch]

Bon travail sur cette PR, c’est une bonne base et ça va clairement dans le bon sens pour fournir un exemple Arduino exploitable.

Comportement vs issue (point principal)

L’issue demande un toggle de LED à chaque appui, alors que l’implémentation actuelle allume simplement la LED pendant 200 ms.

Cela ne respecte pas :

• “Toggle each LED on button press”
• “One press = one toggle”

Suggestion :
Introduire un état par LED (par exemple bool ledState[]) et inverser cet état à chaque appui détecté :

ledState[i] = !ledState[i];
digitalWrite(ledPin[i], ledState[i]);

---

Debounce non conforme

Le delay(200) ne constitue pas un vrai debounce :

• il bloque la loop
• il ne garantit pas un seul événement par appui
• un appui long peut générer plusieurs activations

Suggestion :
Mettre en place un debounce basé sur millis() avec :

• mémorisation du dernier état du bouton
• détection de front (HIGH → LOW avec INPUT_PULLUP)
• délai minimal entre deux activations

---

Gestion des boutons (else if)

L’utilisation de else if empêche la gestion simultanée de plusieurs boutons.

Suggestion :
Remplacer par des if indépendants pour traiter chaque bouton séparément.

---

Logs série

Les Serial.println("... \n") ajoutent une ligne vide supplémentaire.

Suggestion :
Supprimer \n :

Serial.println("A_BUTTON pressed");

---

delay(2000) dans setup

Le delay(2000) au démarrage n’est pas expliqué.

Suggestion :

• soit le documenter (ex : attente du moniteur série)
• soit le supprimer si non nécessaire

---

Nommage et intention

Le nom du fichier et des fonctions (led_on) reflète un comportement “allumer”, alors que l’objectif est un toggle.

Suggestion :
Adapter le nommage pour refléter l’intention (ex : led_toggle).

---

Absence d’état des LEDs

Il manque une structure pour stocker l’état courant de chaque LED, ce qui empêche de faire un toggle correct.

Suggestion :
Ajouter une variable d’état par LED.

---

Description de la PR

Quelques points d’amélioration côté description :

• Pour fermer automatiquement l’issue, utiliser closes #1
• La description pourrait être un peu plus détaillée (cf [feat(hts221): Add basic examples])
• Bonne pratique d’indiquer quel commit répond à un commentaire Copilot, mais préciser aussi ce que fait le commit et comment il résout le problème facilitera la relecture

---

Dans l’ensemble, c’est du bon travail et la structure est déjà en place. Avec les ajustements sur le toggle et le debounce, la PR sera parfaitement alignée avec l’issue.