Show page

Differences

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

--- pm:prj2026:theodor_ioan.buliga:bianca.buga [2026/05/04 02:11]
bianca.buga
+++ pm:prj2026:theodor_ioan.buliga:bianca.buga [2026/05/26 16:23] (current)
bianca.buga
@@ Line 3: / Line 3: @@
 <note tip>
-This project implements a password-protected alarm system using the ATmega328P microcontroller board.
+This project implements a password-protected alarm system using the Arduino Nano ATmega328P board.
-  * **What it does:** The system activates a passive buzzer alarm that can only be silenced by entering the correct password via push buttons. A green LED confirms a correct entry, while a red LED and an intensified alarm sound signal an incorrect attempt. A reset button and an LCD display are also integrated.
+  * **What it does:** When triggered (via a start button or a PIR motion sensor), a 30-second countdown begins and the passive buzzer starts beeping. The alarm can only be silenced by entering the correct 4-digit password via 4 push buttons. A green LED and a success jingle confirm correct entry, while a red LED and a continuous alarm signal a wrong attempt. The system also controls a servo motor acting as a physical door lock, stores the password persistently in the internal EEPROM (survives power cycles), and allows secure in-system password changes. A 16x2 I2C LCD and UART serial output provide real-time status feedback.
+  * **Key features:** Password-protected alarm, PIR motion detection with arming delay, servo door lock, EEPROM password persistence, 4-state FSM, UART debug output.
 </note>
 ===== General Description =====
-The system is structured around the following hardware and software modules:
+The system is structured around a **4-state Finite State Machine (FSM)** running on the ATmega328P. All peripherals are driven using direct register manipulation.
 **Hardware Modules:**
-  * **ATmega328P X-Mini** — the central processing unit
+  * **ATmega328P (Arduino Nano)** — central processing unit, 16 MHz, 5V
-  * **Passive Buzzer** — driven by PWM (Timer1) to produce variable-frequency alarm tones
+  * **PIR Sensor (HC-SR501)** — motion detection for automatic arming
-  * **Push Buttons (4x)** — used to input the password digits (e.g. a 4-button combination lock)
+  * **Servo Motor SG90** — actuates the physical door lock mechanism (PC0)
-  * **Reset Button** — triggers a software or hardware reset of the system state
+  * **Passive Buzzer** — variable-frequency acoustic feedback via GPIO toggle (PD7)
-  * **Green LED** — indicates correct password entry
+  * **4x Password Buttons** — 4-digit code input (PD3, PD4, PB0, PB1)
-  * **Red LED** — indicates wrong password entry
+  * **Start/Reset Button** — alarm trigger and system reset (PD2)
-  * **16x2 LCD Display ** — displays system status messages
+  * **Arming Button** — PIR sensor arm/disarm toggle (PB4)
+  * **Password Change Button** — enters secure password-change mode (PC1)
+  * **Green LED** — correct password / system disarmed indicator (PD5)
+  * **Red LED** — active alarm indicator (PD6)
+  * **PIR Status LED** — visual indicator when PIR is armed (PB2)
+  * **16x2 LCD (HD44780 + PCF8574 I2C adapter)** — real-time status messages (A4/A5)
 **Bill of Materials:**
-| Component                  | Quantity | Notes                              |
+| Component                  | Quantity | Notes                                |
-|----------------------------|----------|------------------------------------|
+|----------------------------|----------|--------------------------------------|
-| ATmega328P X-Mini board    | 1        | 16 MHz, 5V                         |
+| Arduino Nano ATmega328P    | 1        | 16 MHz, 5V                           |
-| Passive buzzer             | 1        | Sound                              |
+| Passive buzzer             | 1        | Sound                                |
-| Push buttons               | 4        | Password input, pull-up resistors  |
+| Push buttons               | 7        | Password input, pull-up resistors    |
-| Reset button               | 1        | Reset purpose                      |
+| Reset button               | 1        | Reset purpose                        |
-| Green LED + 220Ω resistor  | 1        | Correct password indicator         |
+| Green LED + 220Ω resistor  | 1        | Correct password indicator           |
-| Red LED + 220Ω resistor    | 1        | Wrong password indicator           |
+| Red LED + 220Ω resistor    | 1        | Wrong password indicator             |
-| 16x2 LCD (HD44780)         | 1        | I2C adapter                        |
+| 16x2 LCD (HD44780)         | 1        | I2C adapter                          |
-| Breadboard + jumper wires  | -        | Prototyping                        |
+| Breadboard + jumper wires  | -        | Prototyping                          |
-| USB cable                  | 1        | For flashing the ATmega328P        |
+| USB cable                  | 1        | For flashing the ATmega328P          |
+| PIR Sensor (HC-SR501)      | 1        | Motion detection for automatic arming|
+| Servo Motor SG90           | 1        | physical door lock mechanism         |
 **Electrical Notes:**
-  * All push buttons are wired with the internal pull-up resistors enabled (INPUT_PULLUP equivalent in bare metal: set DDRx bit to 0 and PORTx bit to 1). Buttons are active-low.
+  * All push buttons use internal pull-up resistors (DDRx bit = 0, PORTx bit = 1). Buttons are active-low: connected between pin and GND. No external resistors needed.
-  * LEDs are connected through 220Ω current-limiting resistors to GND.
+  * LEDs are connected through 220Ω current-limiting resistors to GND. At 5V with a 2V LED forward voltage: (5V − 2V) / 220Ω ≈ 13.6 mA, well within the 40 mA/pin limit of the ATmega328P.
+  * The SG90 servo is powered directly from the Arduino Nano 5V pin. For heavier loads, a separate 5V supply is recommended.
+  * The LCD I2C adapter (PCF8574) typically includes pull-up resistors on SDA/SCL. Default I2C address: 0x27.
+  * The HC-SR501 PIR outputs a digital HIGH (3.3–5V) when motion is detected, directly compatible with the 5V ATmega328P input.
+**Software Design:**
+  * Toolchain: avr-gcc + avrdude (bare-metal, no Arduino Framework)
+  * Editor: VS Code with C and AVR Utils extensions
+  * Debugging: UART serial output (9600 baud) + LED state indicators
+  * Target: ATmega328P on Arduino Nano (16 MHz, 5V)
-**Algorithms and Structures:**
-  * **Password Validation FSM:**
+**Password Validation FSM:**
-    The system uses a simple finite state machine with 5 states:
-    - `IDLE` — system waiting, buzzer silent
+The system uses a finite state machine with 4 states:
-    - `ARMED` — alarm active, buzzer playing alarm melody via PWM
-    - `INPUT` — user is entering the password sequence
+^ State ^ Code ^ Description ^
-    - `CORRECT` — correct password: green LED on, buzzer off, LCD shows "ACCESS GRANTED", auto-return to IDLE after timeout
+| IDLE / Active | ''stare = 0'' | System waiting; allows arming/disarming PIR and password change |
-    - `WRONG` — wrong password: red LED on, buzzer plays intensified tone, LCD shows "ACCESS DENIED", auto-return to ARMED
+| ALARM countdown | ''stare = 1'' | 30s countdown, periodic beep, user enters password |
+| ALARM triggered | ''stare = 2'' | Time expired or wrong password; red LED + continuous buzzer |
+| Password change | ''stare = 3'' | Two-step sub-FSM: verify old password, then set new one |
+**FSM Transitions:**
+  * ''0 → 1'': Start button pressed (PD2) OR PIR armed + motion detected (PB3)
+  * ''1 → 0'' (success): 4 digits entered, password correct → servo opens, system resets
+  * ''1 → 2'' (failure): Timer expires (30s) OR wrong password entered
+  * ''2 → 0'': Correct password entered even in alarm state → system resets
+  * ''0 → 3'': Password-change button pressed (PC1)
+  * ''3 → 0'': Old password verified + new password saved to EEPROM
-**Software design**
-  * Editor: VS Code with the C and "AVR Utils" extensions for syntax highlighting and register lookup
-  * Debugging: LED-based state signaling and logic analyzer on PWM/GPIO lines
-  * Target: ATmega328P X-Mini
-**Libraries and 3rd-party sources:**
+===== Libraries =====
-  * `avr/io.h` — direct register-level access to all ATmega328P peripherals (DDRx, PORTx, PINx, TCCRx, OCRx, etc.)
-  * `avr/interrupt.h` — enabling global interrupts (sei/cli) and defining ISR handlers
+The project uses exclusively **bare-metal avr-libc** — no Arduino Framework. This choice provides full control over peripheral registers, deterministic timing, smaller code size, and compatibility with any AVR toolchain (avr-gcc + avrdude).
-  * `util/delay.h` — used exclusively in the LCD initialization sequence and LED hold timers; all alarm timing is handled via hardware timers
+**''<avr/io.h>''**\\
+Provides symbolic definitions for all ATmega328P peripheral registers (''DDRx'', ''PORTx'', ''PINx'', ''TCCRx'', ''OCRx'', ''TWCR'', ''UBRR0'', etc.). Without this header, raw hexadecimal register addresses would be required, making the code unportable and unreadable. It is an absolute necessity for any bare-metal AVR project.
+**''<util/delay.h>''**\\
+Provides ''_delay_ms()'' and ''_delay_us()'', computed at compile time based on ''F_CPU = 16000000UL''. Used in:
+  * LCD initialization sequence (precise 50 ms, 5 ms, 150 µs boot delays required by HD44780 spec)
+  * Servo soft-PWM pulse generation (1000 µs / 1500 µs control pulses)
+  * Button debouncing (50 ms after edge detection)
+  * Buzzer tone generation (500 µs toggle = 1 kHz; 330 µs ≈ 1.5 kHz; 250 µs = 2 kHz)
+A hardware timer alternative would be more CPU-efficient for long waits, but for short and precise initialization delays, ''_delay_us()'' is the correct approach.
+**''<avr/eeprom.h>''**\\
+Provides ''eeprom_update_byte()'' and ''eeprom_read_byte()'' for safe access to the 1 KB internal EEPROM of the ATmega328P. Critically, ''eeprom_update_byte()'' (unlike ''eeprom_write_byte()'') checks whether the existing value equals the new value before performing a write. This **extends EEPROM lifetime** (rated ~100,000 write cycles per cell) — important when the same password bytes might be rewritten repeatedly. Used to persist the 4-digit password across power cycles.
-**Block Design**
+==Block Design==
-{{:pm:prj2026:theodor_ioan.buliga:block_design.png}}
+ {{:pm:prj2026:theodor_ioan.buliga:schema_bloc-bia.png}}
-**Laboratories Used:**
+===== Element of Novelty =====
+Compared to a basic alarm system, this project introduces several distinctive elements:
+**1. Runtime-changeable password with EEPROM persistence**\\
+The password is not hardcoded in flash. It is stored in EEPROM and can be changed at runtime via a secure two-step protocol: verify the old password first, then enter the new one. On boot, the system checks an initialization flag (''0xAB'' magic byte at address ''0x04'') to detect whether the EEPROM has been previously configured. If not, a safe default password ''[1,2,3,4]'' is used instead of reading uninitialized ''0xFF'' bytes.
+**2. Servo motor as a physical locking mechanism**\\
+Upon correct password entry, a servo motor actuates a physical latch (simulated by moving from a 1000 µs to a 1500 µs PWM pulse). The system returns to the locked state only after the RESET button is pressed, modelling a realistic access-control flow.
+**3. PIR sensor with automatic arming and exit delay**\\
+When the PIR is armed, the system grants a 5-second exit window followed by a wait for the PIR output to go LOW (person fully exits) before fully activating. This simulates the real-world entry/exit delay behaviour of professional alarm panels.
+**4. Dual-trigger FSM**\\
+The alarm can be triggered by two independent sources: the START button or PIR motion detection (when armed). The FSM handles both uniformly, and the UART log distinguishes the trigger source with distinct messages.
+**5. Differentiated acoustic feedback**\\
+Three distinct sound patterns are implemented in software: a periodic beep during countdown (500 µs toggle), a 3-note ascending success jingle on correct password (500 µs → 330 µs → 250 µs delays), and a continuous alarm in state 2. Frequency variation is achieved purely by adjusting GPIO toggle delays — no DAC or PWM hardware needed.
- *The implementation of this project is based on the concepts studied in the following laboratories:
+===== Laboratories Used =====
-    - Laboratory 0 GPIO - Used for basic interfacing. I configured the pins for the LEDs as outputs and the pins for the push buttons as inputs with internal pull-up resistors enabled.
-    - Laboratory 1 UART - Integrated for debugging purposes. The system transmits the current state and the entered sequence to a Serial Monitor, allowing for real-time monitoring of the logic.
+The implementation is directly based on concepts from the following laboratories:
-    - Laboratory 2 Interrupts - Used for the reset button and potentially for handling button presses to ensure immediate response from the microcontroller without constant polling in the main loop.
-    - Laboratory 3 Timers - Essential for the acoustic feedback.
+**Laboratory 0 — GPIO**\\
+Used for all digital inputs and outputs. Pin direction is set via ''DDRx'', output values via ''PORTx'', and input states read via ''PINx''. Internal pull-ups (''PORTx |= (1 << Pxy)'' with ''DDRx &= ~(1 << Pxy)'') eliminate the need for external resistors on all 6 buttons. LED driving, buzzer toggling, and servo signal generation all rely on basic GPIO operations.
+**Laboratory 1 — UART**\\
+Integrated for real-time debugging. Every significant state transition (alarm activation, key press, password change, arming) generates a descriptive UART message transmitted at 9600 baud. Initialization uses the formula ''UBRR = F_CPU / 16 / BAUD − 1 = 103'' for 9600 baud at 16 MHz. Transmission uses polling on the ''UDRE0'' flag in ''UCSR0A''.
+**Laboratory 2 — Interrupts**\\
+Timer1 uses the hardware CTC overflow flag (''OCF1A'' in ''TIFR1'') checked by polling in the main loop. This decouples the 1-second countdown from the rest of the loop execution, ensuring temporal accuracy independent of code execution time. The flag is cleared by writing a logical ''1'' to it (''TIFR1 |= (1 << OCF1A)'') — the AVR write-1-to-clear mechanism. Button edge detection (comparing current and previous state) provides interrupt-like single-trigger behaviour without ISR overhead.
+**Laboratory 3 — Timers**\\
+Timer1 is configured in CTC mode (''WGM12 = 1'') with prescaler 1024 (''CS12 = 1'', ''CS10 = 1'') and ''OCR1A = 15624'', generating a precise 1 Hz event: ''16,000,000 / 1024 / (15624 + 1) = 1 Hz''. ''TCNT1'' is reset to 0 at alarm activation, and the ''OCF1A'' flag is polled each main loop iteration to count elapsed seconds for the 30-second countdown.
+**Laboratory 6 — I2C**\\
+The HD44780 LCD with PCF8574 I2C adapter is controlled via a manually implemented I2C driver (no third-party library). Hardware TWI registers used: ''TWBR = 12'' for ~400 kHz fast mode, ''TWSR = 0'' for prescaler 1, ''TWCR'' for start/stop/write control. Each LCD character requires 2 I2C transactions (upper nibble + lower nibble), each including an enable pulse. This custom implementation allows full control over I2C address, backlight, and LCD command timing.
+===== Project Skeleton =====
+The main ''while(1)'' loop is organized as a sequential state machine. Each iteration evaluates the current state and performs the appropriate actions:
+<code c>
+while(1) {
+    // 1. Update PIR indicator LED (state-independent)
+    // 2. In state 0: check Arming button (PB4) and Password-Change button (PC1)
+    // 3. Check alarm trigger: Start button (PD2) OR PIR + motion (PB3)
+    // 4. In state 1: check Timer1 flag (TIFR1) → decrement countdown, beep
+    // 5. In states 1 and 2: read keypad → validate password
+    // 6. In state 2: toggle buzzer (PD7) for continuous alarm
+    // 7. In state 3: two-step password change sub-FSM
+}
+</code>
+**Key interactions between functionalities:**
+  * **State 0 → 1 transition:** Triggered by Start button (PD2, ''reset_efectuat = 1'') OR PIR armed + motion detected (PB3 HIGH). Resets ''TCNT1 = 0'', ''secunde = 0'', ''taste_apasate = 0''.
+  * **State 1 → 0 (success):** 4 keys entered, password matches ''parola_setata[]''. Servo opens, ''reset_efectuat = 0'' (blocks new start until RESET is pressed).
+  * **State 1 → 2 (failure):** Countdown reaches 30 seconds OR wrong 4-digit password entered.
+  * **State 0 → 3:** Password-change button (PC1) pressed. Enters two-step sub-automaton.
+  * **System reset:** Start button (PD2) pressed in state 0 with ''reset_efectuat = 0'' → confirms reset, sets ''reset_efectuat = 1''.
+  * **EEPROM interaction:** Password is read from EEPROM at boot (''eeprom_citeste_parola()'') and written only when explicitly changed (''eeprom_salveaza_parola()'').
+**Schematics**
+ {{:pm:prj2026:theodor_ioan.buliga:schbb.png}}
+**Schematic notes:**
+  * All 6 buttons are connected between their respective pin and GND. Pull-up resistors are enabled in software.
+  * Green LED (PD5) and Red LED (PD6): each connected in series with a 220Ω resistor to GND.
+  * PIR indicator LED (PB2): connected in series with a 220Ω resistor to GND.
+  * Buzzer: connected directly between PD7 and GND. The buzzer coil impedance limits current.
+  * Servo SG90: signal wire to PC0, VCC to 5V, GND to GND.
+  * LCD I2C adapter: SDA to A4 (PC4), SCL to A5 (PC5), VCC to 5V, GND to GND.
+  * PIR HC-SR501: OUT to PB3, VCC to 5V, GND to GND.
+  * All GND lines share a common ground rail on the breadboard.
+Detailed pin mapping with justification for each choice:
+^ Arduino Nano Pin ^ AVR Pin ^ Direction ^ Connected Component ^ Justification ^
+| A0 | PC0 | Output | Servo SG90 signal | Available digital pin on port C; soft PWM implemented manually with delay loops (1000 µs / 1500 µs pulses). Hardware timer not required. |
+| A1 | PC1 | Input, internal pull-up | Password-change button | Free pin on port C, adjacent to servo. Active-low, internal pull-up enabled. |
+| D2 | PD2 | Input, internal pull-up | Start / Reset button | PD2 doubles as INT0 external interrupt pin — future upgrade potential. Currently used with polling. |
+| D3 | PD3 | Input, internal pull-up | Password button 1 | PD3 doubles as INT1. Available on port D. |
+| D4 | PD4 | Input, internal pull-up | Password button 2 | Available digital pin on port D. |
+| D5 | PD5 | Output | Green LED | PWM-capable pin (OC0B), used as simple GPIO for the OK status indicator. |
+| D6 | PD6 | Output | Red LED | PWM-capable pin (OC0A), used as simple GPIO for the alarm indicator. |
+| D7 | PD7 | Output | Passive buzzer | Simple digital pin; tone frequency generated by GPIO toggle with delays (500 µs ≈ 1 kHz). |
+| D8 | PB0 | Input, internal pull-up | Password button 3 | Available digital pin on port B. |
+| D9 | PB1 | Input, internal pull-up | Password button 4 | Available digital pin on port B. |
+| D10 | PB2 | Output | PIR armed indicator LED | Available pin on port B; visually shows when the PIR sensor is armed. |
+| D11 | PB3 | Input, internal pull-up | PIR sensor output | HC-SR501 digital output (HIGH = motion). Monitored by polling in state 0. |
+| D12 | PB4 | Input, internal pull-up | Arming button | Available pin on port B for the arm/disarm toggle button. |
+| A4 | PC4 | I/O (SDA) | LCD via I2C | **Hardware I2C SDA pin** on ATmega328P. Mandatory for the PCF8574 I2C adapter. |
+| A5 | PC5 | I/O (SCL) | LCD via I2C | **Hardware I2C SCL pin** on ATmega328P. Mandatory for the PCF8574 I2C adapter. |
+| D1 | PD1 | Output (TX) | UART debug | Hardware USART0 TX pin. Transmits debug messages at 9600 baud to Serial Monitor. |
+<note>
+All buttons use internal pull-up resistors activated via ''DDRx &= ~(1 << Pxy); PORTx |= (1 << Pxy);''. Buttons are active-low: logic goes LOW when pressed (connected to GND). No external pull-up resistors needed.
+</note>
+===== Element of Novelty =====
+Compared to a basic alarm system, this project introduces several distinctive elements:
+**1. Runtime-changeable password with EEPROM persistence**\\
+The password is not hardcoded in flash. It is stored in EEPROM and can be changed at runtime via a secure two-step protocol: verify the old password first, then enter the new one. On boot, the system checks an initialization flag (''0xAB'' magic byte at address ''0x04'') to detect whether the EEPROM has been previously configured. If not, a safe default password ''[1,2,3,4]'' is used instead of reading uninitialized ''0xFF'' bytes.
+**2. Servo motor as a physical locking mechanism**\\
+Upon correct password entry, a servo motor actuates a physical latch (simulated by moving from a 1000 µs to a 1500 µs PWM pulse). The system returns to the locked state only after the RESET button is pressed, modelling a realistic access-control flow.
+**3. PIR sensor with automatic arming and exit delay**\\
+When the PIR is armed, the system grants a 5-second exit window followed by a wait for the PIR output to go LOW (person fully exits) before fully activating. This simulates the real-world entry/exit delay behaviour of professional alarm panels.
+**4. Dual-trigger FSM**\\
+The alarm can be triggered by two independent sources: the START button or PIR motion detection (when armed). The FSM handles both uniformly, and the UART log distinguishes the trigger source with distinct messages.
+**5. Differentiated acoustic feedback**\\
+Three distinct sound patterns are implemented in software: a periodic beep during countdown (500 µs toggle), a 3-note ascending success jingle on correct password (500 µs → 330 µs → 250 µs delays), and a continuous alarm in state 2. Frequency variation is achieved purely by adjusting GPIO toggle delays — no DAC or PWM hardware needed.
 ===== Results =====
+ {{:pm:prj2026:theodor_ioan.buliga:alarm.png}}
+The system operates correctly in all tested scenarios:
+  * Alarm activation via Start button and via PIR motion detection
+  * Correct password entry: green LED, success jingle, servo opens, system resets
+  * Wrong password entry: red LED, continuous buzzer alarm
+  * Password change with EEPROM persistence: new password survives power cycle
+  * PIR arm/disarm with visual indicator and exit delay
+  * UART log correctly identifies trigger source and logs all key presses
 ===== Conclusions =====
+This project demonstrates the coherent integration of multiple ATmega328P peripherals — GPIO, Timer, UART, I2C, and EEPROM — into a practical security application, programmed entirely in bare-metal C without the Arduino Framework.
+Key achievements:
+  * Complete bare-metal driver implementations for I2C/LCD, servo PWM, UART, Timer CTC, and EEPROM
+  * A robust 4-state FSM with dual-trigger alarm activation (button + PIR)
+  * Runtime-configurable password with safe EEPROM initialization and wear-reduction optimization
+  * Physical door lock integration via servo motor
+  * Multi-modal feedback: visual (LEDs), acoustic (buzzer), text (LCD + UART)
+The main current limitation is the restricted password keyspace (4 buttons, values 1–4 only). Natural extensions would include a 4×3 matrix keypad for digits 0–9, variable-length passwords, or a numeric PIN entry system.
-===== Download =====
-===== Journal =====
 ===== Bibliography / Resources =====
+* [[https://www.microchip.com/en-us/product/ATmega328P|ATmega328P Datasheet — Microchip Technology]]
+  * [[https://www.nongnu.org/avr-libc/|AVR Libc Reference Manual]]
+  * PM Laboratories — GPIO, UART, Timers, Interrupts, I2C
+  * [[https://www.handsontec.com/dataspecs/module/I2C_1602_LCD.pdf|HD44780 LCD + PCF8574 I2C Adapter Datasheet]]
+  * [[https://www.electronicwings.com/nodemcu/servo-motor-interfacing-with-nodemcu|SG90 Servo Motor — PWM Control Reference (1 ms–2 ms)]]
+  * [[https://www.mpja.com/download/hc-sr501.pdf|HC-SR501 PIR Motion Sensor Datasheet]]