Show page

Differences

This shows you the differences between two versions of the page.

--- pm:prj2026:victor.stoica0203:mihail.necula [2026/05/08 02:20]
mihail.necula [Input Strategy: Interrupts vs. Polling]
+++ pm:prj2026:victor.stoica0203:mihail.necula [2026/05/11 17:04] (current)
mihail.necula [Bill of Materials]
@@ Line 23: / Line 23: @@
 The inspiration for this project was nostalgia for the dedicated MP3 player which I used during my childhood.
 ===== General description =====
 ==== Block Diagram ====
-{{:pm:prj2026:victor.stoica0203:block_diagram_necula_mihail.png?600|}}
+{{:pm:prj2026:victor.stoica0203:block_diagram_necula_mihail_v2.png?600|}}
@@ Line 38: / Line 39: @@
     * **Rotary Encoder & Buttons:** Provide the primary user interface for navigation, volume control, speed control and playback commands.
   * **Audio Subsystem:**
-    * **MP3 Decoder (DFPlayer Mini):** Offloads the heavy task of MP3 processing from the MCU. It accesses the MicroSD Card via **SPI**.
+    * **MP3 Decoder (VS1053B):** Offloads the heavy task of MP3 processing from the MCU. It accesses the MicroSD Card via **SPI**.
     * **MicroSD Card:** Stores the mp3 files.
     * **Amplifier (PAM8403):** Takes the low-level analog output from the decoder and drives the Visaton K50 speaker.
@@ Line 63: / Line 64: @@
 ^  Component  ^  Amout  ^
 |  MEGA 2560 Development Board (16U2)  |  1  |
-|  DFPlayer Mini MP3 Player Module (TF-16P)  |  1  |
+|  3.5mm 3-Pole Male Jack to Terminal Block Adapter  |  1  |
+|  VS1053B MP3 Audio Decoder with MicroSD Card Slot  |  1  |
+|  10-Pin Extra Tall Male Header - Straight  |  1  |
 |  GY-302 Digital Light Sensor (BH1750, I2C)  |  1  |
 |  1.3" White OLED Display (SH1106, I2C)  |  1  |
@@ Line 72: / Line 75: @@
 |  AC/DC Power Adapter  (5V, 2A, 5.5x2.5mm)  |  1  |
 |  Female DC Barrel Jack to Screw Terminal Adapter  |  1  |
-|  Tactile Switch Buttons (12x12x7.3mm)  |  3  |
+|  Tactile Switch Button (12x12x7.3mm)  |  3  |
+|  Tactile Switch Cap (for 12x12x7.3mm button) |  3  |
 |  Encoder Module  |  1  |
 |  5mm Common Cathode RGB LED  |  1  |
-|  220 Ω Resistor (1/4 W)  |  3  |
+|  220 kΩ Resistor (1/4 W)  |  3  |
 |  1 kΩ Resistor (1/4 W)  |  2  |
 |  10 kΩ Resistor (1/4 W)  |  2  |
@@ Line 82: / Line 86: @@
 |  1000 μF Electrolytic Capacitor (25V)  |  1  |
 |  100 nF Ceramic Capacitor (THT, 50V)  |  4  |
-|  10 cm Male-to-Male Jumper Wires  |  ?  |
+|  Clipband  |  1  |
-|  10 cm Female-to-Female Jumper Wires  |  ?  |
+|  10 cm Male-to-Male Jumper Wire  |  ?  |
-|  20 cm Male-to-Male Jumper Wires  |  ?  |
+|  10 cm Female-to-Male Jumper Wire  |  ?  |
-|  20 cm Female-to-Male Jumper Wires  |  ?  |
+|  20 cm Male-to-Male Jumper Wire  |  ?  |
 ===== Software Design =====
-**Development Environment:** I chose the **Arduino IDE** for this project to ensure the delivery of the highest quality result within the required timeframe.
+==== Input Strategy: Interrupts vs. Polling ====
+A critical design choice was made to balance CPU responsiveness with input accuracy. The system distinguishes between high-speed dynamic signals and slow mechanical transitions.
+  * **Encoder Rotation (Hardware Interrupts):**
+    * **Why interrupts?:** Fast rotation generates pulses in the millisecond range. If handled via polling, these pulses would be missed whenever the MCU is busy with I2C communication (OLED) or UART (Audio). Interrupts force the MCU to pause its current task and register every "click" of the rotation instantly.
+    * **Debouncing:** To avoid using CPU-freezing delays during rotation tracking, we implement a Quadrature State Machine. This software logic only validates a step if the transition between signals follows the correct Gray Code sequence (e.g., 01 -> 11 -> 10).
+  * **Tactile Buttons & Encoder Click (Software Polling):**
+    * **High-Frequency Sampling:** Although handled via polling, the button is sampled thousands of times per second. Since a human press is very slow (~100ms) compared to the MCU loop speed (< 10ms), it is impossible to miss a press.
+    * **Why not interrupts?:** Polling is "cheaper" for the CPU. An interrupt forces a full context switch (saving registers, jumping to ISR), which is overkill for a slow button. Mechanical switches bounce violently. Using interrupts would force the MCU to stop and restart dozens of times for a single click, causing audio glitches or UI lag.
+    * **Debouncing:** We use a time-based "lockout" to ensure a single clean press is registered: if (current_time - last_press_time > DEBOUNCE_THRESHOLD). This ensures that after the first detection, any subsequent bounces are ignored for 50ms, while the MCU continues to drive the OLED and Audio without any freezing delays.