Design Explanations:

• Power Isolation: The water pump is powered directly from the 12V rail via the relay. This prevents the high current draw and electrical noise of the motor from affecting the ATmega328P stability.
• Voltage Regulation: The LM2596 Buck Converter is tuned to exactly 5.0V. It powers the MCU and the servos, which require more current than a standard PC USB port can provide.
• Safety Features: A flyback diode (D1) is placed at the input to prevent damage from reverse polarity. The relay provides galvanic isolation between the water pump circuit and the microcontroller.

To ensure efficient operation and hardware-level precision, the following pins were selected:

• PD2 (INT0): Connected to the Digital Output (DO) of the Flame Sensor.
  • Rationale: PD2 supports External Interrupts. This allows the system to react instantly to a fire detection without waiting for the main code loop to finish other tasks.
• PB1 (OC1A) & PB2 (OC1B): Connected to the PWM pins of Servo 1 and Servo 2.
  • Rationale: These pins are linked to Timer 1 (16-bit). Since we are not using Arduino libraries, Timer 1 provides the high resolution necessary for smooth 50Hz servo pulses (20ms period).
• PD4: Connected to the Relay Input (IN).
  • Rationale: A standard GPIO used to toggle the pump. It is kept on Port D to group it with other digital control signals.
• VCC (5V) & GND: All logic components (MCU, Sensor, Servos) share the 5V rail from the Buck Converter to ensure common ground reference for signals.

The images above show the final wiring on the breadboard, with the Buck Converter supplying power to the flame sensor and the Xplained Mini board.

To verify the system, the Flame Sensor and the integrated LED (PB5) were tested.

• Test Procedure: A flame was introduced near the sensor.
• Result: The sensor's onboard LED triggered, and the ATmega328P successfully pulled the PD2 pin low, subsequently powering up the PB5 BUZZER on the Xplained Mini board.
• Conclusion: The interrupt logic is functional, and the sensor is correctly calibrated via its onboard potentiometer.

The software implementation is fully functional and stable. The application is written in pure C for the ATmega328P microcontroller using PlatformIO. It successfully runs a real-time fire detection and suppression loop. The system concurrently monitors a flame sensor via both digital and analog channels, triggers an instantaneous acoustic alarm via hardware interrupts, controls a high-power water pump through an isolated relay module, and drives a 2-axis sweep mechanism using hardware PWM.

In order to maximize execution speed, minimize memory footprint, and strictly adhere to low-level academic requirements, no external third-party libraries (such as Arduino.h or Servo.h) were used.

• avr/io.h: Selected to provide direct access to the register maps of the ATmega328P (e.g., DDRD, PORTB, ADMUX), ensuring zero-overhead bit manipulation.
• avr/interrupt.h: Chosen to handle the hardware vector management (`ISR(INT0_vect)`) required for sub-microsecond event handling.
• util/delay.h: Used exclusively for minor debouncing and regulating the sweep velocity of the servo motor where strict asynchronous non-blocking timers were not vital.

The primary novelty of this project lies in its Hybrid Dual-Channel Sensor Architecture. Instead of relying on a single data path, the flame sensor is evaluated simultaneously through two distinct subsystems:

1. A **Digital Safety Path** linked directly to a high-priority hardware interrupt line.
2. An **Analog Measurement Path** processed via the ADC.

This creates a fail-safe paradigm: the acoustic alarm bypasses any software delay or loop blockage to guarantee immediate warning, while the analog loop calculates the spatial presence of the threat to dynamically orchestrate physical suppression.

The architecture incorporates core concepts from three foundational PM laboratories:

• Laboratory 1 & 2 (Digital I/O): Used to actuate the isolated relay module on pin PD4 (utilizing an active-low sinking configuration suitable for the lab's relay board) and driving the visual status LED on PB5.
• Laboratory 3 (External Interrupts): Implemented via INT0 on pin PD2. It processes the digital output (DO) of the flame sensor on a falling edge to instantly trigger the emergency buzzer on PD3, guaranteeing deterministic real-time response.
• Laboratory 6 & 7 (Analog-to-Digital Converter - ADC): Implemented on channel ADC0 (PC0) using an AVCC reference and a prescaler of 128. It quantifies the light intensity in the infrared spectrum to distinguish between ambient environmental lighting and an active flame threat.
• Laboratory 5 (Timers & PWM): Utilizes Timer 1 (16-bit) configured in Fast PWM Mode (Mode 14) with `ICR1` acting as TOP to generate a precise 50 Hz frequency (20ms period). This hardware-driven signal operates on pin PB1 (OC1A) to seamlessly position the servo motor.

The software layout is divided into explicit hardware initialization blocks and a single, low-latency execution loop:

+-----------------------------------------------------------------------+
|                         Hardware Initialization                       |
|          (ADC_init()  |  PWM_init()  |  INT0_init()  |  sei())        |
+-----------------------------------------------------------------------+
                                    |
                                    v
+-----------------------------------------------------------------------+
|                           Main Loop [while(1)]                        |
+-----------------------------------------------------------------------+
| 1. Sample raw IR intensity from PC0 (ADC0).                           |
| 2. Evaluate threshold criteria (valoare_foc < 400).                   |
+-----------------------------------------------------------------------+
          |                                            |
 [Fire Detected: FALSE]                        [Fire Detected: TRUE]
          |                                            |
          v                                            v
+------------------------------------+      +------------------------------------+
| - Pull PD4 LOW (Activate Relay)    |      | - Pull PD4 HIGH (Deactivate Relay) |
| - Pull PD3 HIGH (Maintain Buzzer)  |      | - Pull PD3 LOW (Silence Buzzer)    |
| - Increment Servo position         |      | - Snap Servo back to Bisectore     |
|   (Sweep 0° to 120° dynamically)   |      |   (60° Rest Position)              |
+------------------------------------+      +------------------------------------+
          |                                            |
          +---------------------> [_delay_ms(20)] <----+
                                    |
                                    v
                             (Repeat Loop)

Independent of the flow chart above, if pin PD2 drops to 0V at any microsecond, the CPU stops execution instantly:

ISR(INT0_vect) {
    stare_alerta = 1;
    PORTD |= (1 << PD3); // FORCES BUZZER ON IMMEDIATELY
}

System verification was carried out systematically:

• Logic Validation: Probed with an oscilloscope/multimeter on pin `PD4` to verify that state toggles matched the active-low transistor network of the relay module.
• Timing Validation: Verified via the built-in logic analyzer that the Timer 1 configuration outputs an exact pulse width between $1\,\text{ms}$ (`OCR1A = 2000`) and $1.66\,\text{ms}$ (`OCR1A = 3333`), ensuring safe physical operation within bounds.

The infrared phototransistor module required hardware-software co-calibration to avoid false positives caused by laboratory overhead fluorescent lighting:

• Hardware Sizing: The onboard LM393 potentiometer was trimmed under normal ambient conditions until the onboard status LED turned off, isolating the digital output (DO) to trigger only when exposed to highly dense IR spectrums (e.g., a lighter flame within 30cm).
• Software Mapping: Through iterative trial testing, an empirical ADC threshold of 400 units was established. Ambient room light sits safely at $700 - 900$ units ($3.5\text{V} - 4.5\text{V}$), whereas an active flame drops the analog readout sharply under $300$ units ($1.5\text{V}$), providing a robust noise-margin buffer.

• Why & Where: To completely avoid standard CPU processing delays when driving mechanical parts, the servo sweep was optimized via Hardware-driven PWM. Instead of bit-banging pins or calling blocking delays, modifying the `OCR1A` register lets the internal timer handle the waveform generation autonomously.
• Memory Optimization: Global variables are minimized, and critical state indicators (such as `stare_alerta`) are decorated with the `volatile` qualifier. This prevents the compiler from erroneously optimizing the variable into a CPU register, ensuring accurate cross-boundary access between the background ISR and the foreground main loop.

Insert here the URL link or embed player for the laboratory demonstration video.

• VIDEO: Demonstrates system startup. The servo automatically aligns itself to the central $60^\circ$ bisector point, remaining at idle. The buzzer and water pump are silent.