CS Open CourseWare

Examene și teste - [2026]

mihnea.muraru — 2026-06-02T22:32:45+03:00

@@ -3,7 +3,7 @@
  ===== 2026 =====
-   
-   
+ 
+   * {{:pp:examene:ca-26.pdf|Examen CA}}
    * Test practic: Subiecte: {{:pp:examene:practic-26-a.rkt| A }} {{:pp:examene:practic-26-b.rkt| B }} {{:pp:examene:practic-26-c.rkt| C }} {{:pp:examene:practic-26-d.rkt| D }} ; Soluții {{:pp:examene:practic-26-a-sol.rkt| A }} {{:pp:examene:practic-26-b-sol.rkt| B }} {{:pp:examene:practic-26-c-sol.rkt| C }} {{:pp:examene:practic-26-d-sol.rkt| D }}
  
  ===== 2025 =====

pp:examene:ca-26.pdf - created

mihnea.muraru — 2026-06-02T22:31:40+03:00

FlowBox - Anti-Stress Particle Simulation Toy - Updated text to be more accurate

cristian_ioan.chira — 2026-06-02T21:03:22+03:00

@@ -3,34 +3,34 @@
  
- FlowBox is an interactive anti-stress fidget toy designed to simulate a physical container filled with granular particles (e.g., sand) or fluid (e.g., water, lava). The simulation reacts in real-time to the user's movements, such as tilting or shaking, thanks to an integrated 6-axis inertial measurement unit (IMU). A single-button interface allows users to cycle through different materials via a short press or change the map configuration with a long press.
+ FlowBox is an interactive anti-stress fidget toy designed to simulate a physical container filled with granular particles (e.g., sand) or fluid (e.g., water, lava). The simulation reacts in real-time to the user's movements, such as tilting or shaking, thanks to an integrated inertial measurement unit (IMU) processing accelerometer inputs. A single-button interface allows users to cycle through different materials via a short press, cycle map profiles with a medium hold, or switch operation modes with a long hold.
  
  The inspiration for FlowBox stems from a desire to combat smartphone addiction. During moments of stress (such as when hitting a roadblock while working on projects or assignments), the common reflex is to reach for the phone, a habit that often leads to unproductive "infinite scrolling" and increased negative emotions, usually ending up less rested than before. FlowBox is designed to intercept this behavioral loop. By providing a tactile, aesthetically pleasing, and satisfyingly predictable digital-physical experience, it offers a "short break that stays short", allowing the user to reset without falling into the engagement traps of present-day attention economy.
  
  ===== General Description =====
  
  {{:pm:prj2026:jan.vaduva:flowbox_block_diagram_1.png?direct&800|}}
  
- The device is designed around the ESP32-S3R8 microcontroller, which acts as the central hub for high-speed graphics processing, real-time physics calculation, and power management.
+ The device is designed around the ESP32-S3R8 microcontroller, which acts as the central hub for graphics processing, real-time physics calculation, and power management.
  
  == Central Processing Unit (ESP32-S3R8) ==
  
- The "brain" of the device utilizes a dual-core Xtensa 32-bit LX7 processor. To ensure a smooth user experience, the software is split across both cores.
+ The "brain" of the device utilizes a dual-core Xtensa 32-bit LX7 processor. To ensure a stutter-free execution loop, compute-heavy physics operations are distributed explicitly away from background system operations.
  
  == Sensing and User Interaction ==
  
- **Motion Sensing (QMI8658):** This 6-axis IMU is connected via the I2C protocol. It provides the pitch and roll data necessary for the physics engine to calculate the force for the sand particles.
+ **Motion Sensing (QMI8658):** This inertial measurement unit is connected via the I2C protocol. The software framework isolates and processes the raw 3-axis accelerometer vector streams to calculate real-time tilt data for the physics simulator grid.
  
- **Control (BOOT Button):** Connected to GPIO 0, this single button utilizes hardware interrupts. A software state machine distinguishes between short presses (material cycle) and long presses (map cycle/sync mode), providing a minimalist yet powerful user interface.
+ **Control (BOOT Button):** Connected to GPIO 0, this single button utilizes falling-edge hardware interrupts. A dedicated FreeRTOS button task parses timing duration intervals to differentiate between execution commands, creating a responsive state transition interface.
  
  == Display and Storage ==
- **IPS LCD (RGB565):** The 3.16" display uses a high-speed parallel RGB565 interface driven by the ST7701 controller. This allows for the high data throughput required to render hundreds of moving particles at 60 FPS.
+ **IPS LCD (RGB565):** The 3.16" display uses a high-speed parallel RGB565 interface driven by the ST7701 controller. Frame rendering performance is accelerated by caching textures directly inside external PSRAM.
  
- **MicroSD Storage (SDMMC):** Stores the maps containing wall configurations.
+ **MicroSD Storage (SDMMC):** Houses plain-text map profiles containing structured obstacle/wall layouts.
  
  == Power and Connectivity ==
  **Charging and Regulation:** Power is managed by the ETA6096 switching charger, which handles the transition between USB-C power and the 1000mAh LiPo battery.
  
- **PC Interaction:** The Native USB peripheral of the ESP32-S3 allows the device to act as a USB Mass Storage Class (MSC) device. This enables "Sync Mode," where the device appears as a standard thumb drive on a PC for easy map management without removing the SD card.
+ **PC Interaction:** The native USB peripheral of the ESP32-S3 allows the device to act as a USB Mass Storage Class (MSC) device. When activated, the local simulation idles, allowing the microSD storage partition to mount directly onto a host PC as a standard thumb drive for direct configuration management.
  
  ===== Hardware Design =====
  
  ==== High-level component list ====
@@ -81,95 +81,91 @@
  The software architecture of FlowBox is engineered for high-performance, real-time cellular automata simulations. It leverages a dual-core preemptive multitasking environment managed by FreeRTOS within the Espressif IoT Development Framework (ESP-IDF v4.6). The entire codebase is written in pure C to maximize raw instruction throughput, completely eliminating the overhead found in standard wrapper libraries or interpreted runtime engines.
  
  ==== Core Architecture & Multithreading Matrix ====
  
- To guarantee a stutter-free 60 FPS update loop while performing complex I/O operations, the software workload is distributed across the dual-core Xtensa LX7 architecture:
+ To guarantee a stable physics update loop while performing blocking storage operations, execution routines are distributed strategically across the dual-core Xtensa LX7 architecture:
  
- **Core 0 (System Core):** Dedicated to background asset parsing, physical interface management, and storage block synchronization.
+ **Core 1 (Physics Core):** The compute-heavy //simulation_task// is pinned exclusively to Core 1. It continuously recalculates grid updates and pushes compiled frame pixel blocks to the LCD panel.
  
- **Core 1 (Physics Core):** Isolated completely to run the asynchronous //simulation_task// loop. This avoids visual stuttering when reading configuration profiles or interacting with hardware switches.
+ **Core 0 (System Management):** The main execution pipeline (//app_main//) processes asynchronous background logs, raw telemetry printouts, and light sensor updates. The asynchronous //button_task// evaluates user inputs and acts as the supervisor for file directory operations.
  
  === Project Skeleton & File Structure ===
  
  The source structure is the following:
  <code>
  project_root/
  ├── grid_generator/
  ├── include/
- │   ├── button.h
- │   ├── display.h
- │   ├── i2c.h
- │   ├── particle_grid.h
- │   └── storage.h
+ │   ├── button.h
+ │   ├── display.h
+ │   ├── i2c.h
+ │   ├── particle_grid.h
+ │   └── storage.h
  ├── src/
- │   ├── button.c
- │   ├── display.c
- │   ├── i2c.c
- │   ├── main.c
- │   ├── particle_grid.c
- │   ├── storage.c
- │   ├── CMakeLists.txt
- │   └── idf_component.yml
+ │   ├── button.c
+ │   ├── display.c
+ │   ├── i2c.c
+ │   ├── main.c
+ │   ├── particle_grid.c
+ │   ├── storage.c
+ │   ├── CMakeLists.txt
+ │   └── idf_component.yml
  ├── platformio.ini
  └── CMakeLists.txt
  </code>
  
  The interaction sequence between these distinct modules is mapped in the behavioral topology below:
  <code>
  [Hardware Controls] -> ISR Enqueue -> [button_task (Core 0)] -> Modifies g_system_state
-                                                                      |
-                                   +----------------------------------+
-                                   v
- [simulation_task (Core 1)] -> Checks State -> Reads QMI8658 and TSL2561 -> Runs Cellular Automata -> Renders Frame
-                                   |
-                                   v (if State == USB_STORAGE)
-                        [Simulation Paused] <---> [PC Host mounts microSD Partition via USB MSC]
+                                                                      |
+                                   +----------------------------------+
+                                   v
+ [simulation_task (Core 1)] -> Intercepts Volatile Flags -> Reads Accelerometer -> Runs Physics -> Renders Frame
+                                   |
+                                   v (if State == USB_STORAGE)
+                        [Task Enters vTaskDelay Idling] <---> [PC Host mounts microSD Partition via USB MSC]
  </code>
  
  ==== Implementation Progress & Library Selections ====
  
  The software infrastructure is fully implemented, fully validated, and successfully operating under stable final release parameters. The platform entirely avoids generic or bloated community frameworks (such as Arduino or basic platform wrappers) in favor of lightweight, architecture-optimized drivers.
  ^ Library/Component ^ Selection Motivation ^
  | Native ESP-IDF v4.6 Toolchain | Offers low-level register access, fine-grained FreeRTOS task prioritization, and optimal hardware utilization over standard middleware layers. |
- | FATFS & VFS Driver | Provides standard POSIX file descriptor methods (%%fopen%%, %%fscanf%%) to read plain-text map documents efficiently. |
+ | FATFS & VFS Driver | Provides standard POSIX file descriptor methods (%%fopen%%, %%fscanf%%) to read plain-text map files strictly during initialization or on-demand loading slots. |
  | espressif_esp_tinyusb / espressif_tinyusb | Directly interfaces with the ESP32-S3's native hardware USB peripheral, managing the Mass Storage Class (MSC) descriptors and low-level SCSI commands to bridge the PC host to the storage backend. |
  | espressif_esp_lcd_st7701 | Provides high-performance driver configurations for the 3.16" layout, abstracting initialization commands and setting up optimal timing sequences over the high-speed RGB interface. |
  | espressif_esp_lcd_panel_io_additions | Extends core display control functional hooks, enabling the specialized 3-wire SPI initialization interface alongside the primary parallel data bus channels. |
- | espressif_esp_io_expander | Manages internal chip pin registers dynamically over I2C, offloading hardware control lines to keep the primary microcontroller pins clear for memory communication lanes. |
+ | espressif_esp_io_expander | Manages secondary chip pin registers over I2C, offloading slow static control tasks (such as hardware resets and backlight states) to preserve native pins for the high-speed parallel video bus. |
  | espressif_cmake_utilities | Automates dynamic file indexing, component dependency configurations, and cross-compilation pipeline steps directly within the underlying native build environment. |
  
  ==== Laboratory Concept Integration & Justification ====
  
  The software applies several advanced concepts covered during academic laboratory sessions to solve real-world hardware design constraints:
  
- * 
- **GPIO (Lab 0) & Interrupts (Lab 2):** The control button maps a hardware interrupt handler via %%IRAM_ATTR%%. Short edge changes directly pass small integer memory blocks into a FreeRTOS %%QueueHandle_t%%. This architecture bypasses processor-intensive polling loops and ensures the chip remains in an idle state until an actual input event triggers it.
+ * **GPIO (Lab 0) & Interrupts (Lab 2):** The control button maps a hardware interrupt handler triggering on falling edges. State shifts pass raw GPIO integer signals into a FreeRTOS %%QueueHandle_t%%, bypassing processing-intensive polling loops.
  
  
- * 
- **Timers & PWM (Lab 3):** Display backlighting utilizes hardware LED PWM timers (%%ledc%%). This peripheral generates a high-frequency, flicker-free dimming signal entirely in hardware, saving CPU cycles on Core 0.
+ * **Timers & PWM (Lab 3):** Display backlighting utilizes hardware LED PWM timers (%%ledc%%). This peripheral generates a high-frequency, flicker-free dimming signal entirely in hardware, saving CPU cycles on Core 0.
  
  
- * 
- **I2C (Lab 6):** The inertial measurement system, respectively the light sensor uses a high-speed I2C master bus operating at 400 kHz to pull motion frames from the QMI8658 and the TSL2561 sensors on predictable schedules.
+ * **I2C (Lab 6):** Telemetry communication uses a high-speed I2C master bus operating at 400 kHz to poll raw register bytes on predictable schedules from the QMI8658 IMU and the TSL2561 light sensor.
  
  
- * **SPI (Lab 5) & SDMMC:** The storage backend reads map files across dedicated high-speed lines. This ensures reading cellular data from storage does not lag the user interface.
+ * **SPI (Lab 5) & SDMMC:** The storage backend reads layout arrays using native slot definitions, ensuring file actions add negligible latency when changing environments.
  
  ==== Sensor Calibration & Advanced Optimization ====
  
  === Motion Sensor Calibration ===
- The QMI8658 IMU is calibrated at boot via software offsets. Raw data is read from the low and high byte registers ($0x35$ to $0x3A$), converted into real-world floating-point gravity vectors ($g$), and processed using an explicit **deadband acceleration threshold**:
+ The QMI8658 IMU is calibrated at boot via software offsets. Raw accelerometer data is read from the low and high byte registers ($0x35$ to $0x3A$), converted into real-world floating-point gravity vectors ($g$), and processed using an explicit **deadband acceleration threshold**:
  
  %%ACCELERATION_THRESHOLD = 0.03f%% 
  
  Any small background vibrations below $0.03g$ are discarded. This stops the cellular fluid from moving on its own when the device sits flat on a desk.
  
  === Optimization Strategies ===
- To squeeze high-performance fluid physics out of a microchip, three critical optimization patterns were written from scratch:
+ To squeeze high-performance fluid physics out of a microchip, three critical optimization patterns were implemented:
  
- 1. 
- **In-Place Double Buffering:** The grid configuration context structure instantiates two internal linear byte buffers (%%grid_buffer_0%% and %%grid_buffer_1%%). The simulation task reads data from a %%current_grid%% pointer and records computed cell updates to a %%next_grid%% pointer. At the end of a frame, the code swaps the pointer addresses instantly:
+ 1. **In-Place Double Buffering:** The grid configuration context structure instantiates two internal linear byte buffers (%%grid_buffer_0%% and %%grid_buffer_1%%). The simulation task reads data from a %%current_grid%% pointer and records computed cell updates to a %%next_grid%% pointer. At the end of a frame, the code swaps the pointer addresses instantly:
  
  <code>
  uint8_t *temp = ctx->current_grid;
  ctx->current_grid = ctx->next_grid;
@@ -186,33 +182,31 @@
  if (acc_y > 0.0f) { start_y = GRID_HEIGHT - 2; end_y = 0; step_y = -1; }
  </code>
  
  
- 3. 
- **Hardware Isolation via Race Guards:** To fix race conditions between file streaming on Core 0 and rendering on Core 1, the engine clears the simulation function pointer (%%ctx->update_particle = NULL%%) right as a file opens. This cleanly pauses physics execution without relying on resource-heavy helixes or spinlocks.
+ 3. **Volatile State Isolation:** To prevent resource-heavy mutex locking or race conditions when loading fresh map directories, the engine incorporates a cooperative state check loop. Modifying the global volatile enum %%g_system_state%% signals the core simulation thread to pause compute pipelines and yield bus ownership via standard FreeRTOS ticks, enabling safe, synchronous file loads.
  
  ==== Map Architecture & Dynamic Parsing ====
  
- The custom map layout file format uses plain-text data fields to make map editing simple. Every single file must strictly begin with an absolute validation tag string, followed by an exact 80 $\times$ 205 matrix of space-separated cell enum values:
+ The custom map layout file format uses plain-text data fields to make map editing simple. Every single file must strictly begin with an absolute validation tag string, followed by an exact $80 \times 205$ matrix of cell enum values. 
  
- The system includes a zero-recompilation map loading system. Instead of tracking a fixed list of files, the code uses %%<dirent.h>%% directory streams to scan the root file system at boot. It automatically discovers, sorts, and indexes any file matching the pattern %%grid_X.txt%%. This allows users to drop a brand new map file onto the device via USB, and immediately cycle to it using the button interface without changing a single line of C code.
+ Boundary tracking overhead inside the nested loops is completely eliminated via the map file convention: every layout must define a solid bounding wall along the perimeter margins. This structural rule ensures out-of-bounds pointer checks never trigger during neighbor calculations.
+ 
+ The system includes a zero-recompilation map loading system. Instead of tracking a fixed list of files, the code uses %%<dirent.h>%% directory streams to scan the root file system at boot. It automatically discovers, sorts, and indexes any file matching the pattern %%grid_X.txt%% via basic bubble sorting. This allows users to drop a brand new map file onto the device via USB, and immediately cycle to it using the button interface without changing a single line of C code.
  
  ==== Novelty Elements ====
  
  The core novelty of FlowBox lies in its **fully unified hybrid memory architecture**:
  
  Unlike standard storage setups where an SD card must be physically removed or handled by complex software overhead, FlowBox can **on-the-fly unmount its own active file system partition, reinitialize its internal storage pins, and hand control of the SD card blocks directly to a PC over a native USB Mass Storage bridge.** The entire process is automated through runtime button press timings tracked inside the system state machine:
  
- * 
- **Short Clicks (< 1.5s):** Advances the physics runtime environment configuration through standard material profiles (//SAND// $\rightarrow$ //WATER// $\rightarrow$ //LAVA//).
+ * **Short Clicks (< 1.5s):** Advances the physics runtime environment configuration through standard material profiles (//SAND// $\rightarrow$ //WATER// $\rightarrow$ //LAVA//).
  
  
- * 
- **Medium Hold [1.5s, 5.0s):** Temporarily pauses the physics loops, advances the dynamic map file slot array index, and instantly parses the next map array straight into the active memory buffers.
+ * **Medium Hold [1.5s, 5.0s):** Atomic flags shift the active state configuration, causing the physics loop to pause and yield execution while a directory scan fetches the next structured index directly into active memory buffers.
  
  
- * 
- **Long Hold ($\ge$ 5.0s):** Completely stops the simulation task, tears down the local VFS file paths, mounts the native TinyUSB controller stack, and transforms the device into a generic plug-and-play USB thumb drive on the host PC. Holding it again reverses the process, mounts the local card system, runs a fresh map scan, and resumes the interactive physics game loop.
+ * **Long Hold ($\ge$ 5.0s):** The state engine transitions to storage configuration mode, causing the simulation task to idle via cooperative %%vTaskDelay%% structures. The local VFS partition layer is unmounted safely via %%esp_vfs_fat_sdcard_unmount%%, and the blocks are bound to the native TinyUSB controller stack, transforming the device into a standard thumb drive. Releasing the hold state reverses the initialization sequence, remounting the local card stack seamlessly.
  
  ==== Verification & Validation Demo ====
  
  Peripherals are monitored in real time using logging outputs over UART.
@@ -245,6 +239,4 @@
  
  [[https://cdn-shop.adafruit.com/datasheets/TSL2561.pdf|TSL2561 Datasheet]]
  
  <html><a class="media mediafile mf_pdf" href="?do=export_pdf">Export to PDF</a></html>
- 
-

Untouchable LIMiTS - [Pictures]

alexandru.albu2801 — 2026-06-02T16:54:02+03:00

@@ -47,9 +47,9 @@
  ===== Pictures =====
  
  {{ :pm:prj2026:jan.vaduva:side_picture_pm.jpeg?300 |}}
  {{ :pm:prj2026:jan.vaduva:top_down_pm.jpeg?300 |}}
- {{ :pm:prj2026:jan.vaduva:synth_pm.jpeg |}}
+ {{ :pm:prj2026:jan.vaduva:synth_pm.jpeg?300 |}}
  
  ===== Pinout & Hardware Mapping =====
  
  To ensure stability and prevent conflicts with the ESP32-S3's internal memory and boot processes, several pins were explicitly avoided:

pm:prj2026:jan.vaduva:synth_pm.jpeg - created

alexandru.albu2801 — 2026-06-02T16:52:43+03:00

	current

pm:prj2026:jan.vaduva:flowbox_block_diagram_1.png - created

cristian_ioan.chira — 2026-06-01T00:57:52+03:00

	current

Secure Communication Terminal

catalin.manole1211 — 2026-05-29T16:50:31+03:00

@@ -3,8 +3,9 @@
  ===== Introduction =====
- {{:pm:prj2026:theodor_ioan.buliga:walkie-talkie.jpeg?300|}}
  
  The **Secure Communication Terminal** project is a digital, secured wireless communication device. Unlike a classic radio station, the device allows real-time voice capture, P2P transmission, and playback only if the user passes a **biometric authentication** filter. The system integrates a permission-based access hierarchy (Admin vs. User) and is controlled by an ESP32 microcontroller.
+ 
+ {{:pm:prj2026:theodor_ioan.buliga:walkie-talkie.jpeg?300|}}
  
  **What is its purpose:**
  The main goal is to build a robust physical product, a sort of industrial prototype, capable of combining modern access control technologies (fingerprint sensor) with high-fidelity digital audio processing. At a technical level, the project demonstrates mastery of microcontroller architectures through the simultaneous integration of several studied complex protocols (UART, I2C, I2S) and the efficient use of hardware interrupts for the system's state machine.

pm:prj2026:theodor_ioan.buliga:diagramwt.png - created

catalin.manole1211 — 2026-05-29T16:49:00+03:00

	current

pm:prj2026:theodor_ioan.buliga:walkie-talkie.jpeg - created

catalin.manole1211 — 2026-05-29T16:33:29+03:00

	current

Case Study: Wearable Computing

dan.tudose — 2026-05-29T15:27:54+03:00

@@ -1,10 +1,10 @@
  ====== Case Study: Wearable Computing ======
  
- {{:pm:cursuri:l10_2023.pdf|Slide-uri curs}}
+ {{:pm:cursuri:cursul12_2026.pdf|Slide-uri curs}}
  
  <html>
    <center>
-     <iframe src="https://docs.google.com/viewer?url=http://ocw.cs.pub.ro/courses/_media/pm/cursuri/l10_2023.pdf&embedded=true" width="700" height="400" style="border: none;"></iframe>
+     <iframe src="https://docs.google.com/viewer?url=http://ocw.cs.pub.ro/courses/_media/pm/cursuri/cursul12_2026.pdf&embedded=true" width="700" height="400" style="border: none;"></iframe>
    </center>
  </html>

pm:cursuri:cursul12_2026.pdf - created

dan.tudose — 2026-05-29T15:26:48+03:00

Cursul 0. Intro

dan.tudose — 2026-05-29T15:19:20+03:00

@@ -1,11 +1,11 @@
  ==== Cursul 0. Intro ====
  
- {{:pm:cursuri:cursul0_2024.pdf| Cursul 0}}
+ {{:pm:cursuri:cursul0_2026.pdf| Cursul 0}}
  
  <html>
    <center>
-     <iframe src="https://docs.google.com/viewer?url=http://ocw.cs.pub.ro/courses/_media/pm/cursuri/cursul0_2024.pdf&embedded=true" width="700" height="400" style="border: none;"></iframe>
+     <iframe src="https://docs.google.com/viewer?url=http://ocw.cs.pub.ro/courses/_media/pm/cursuri/cursul0_2026.pdf&embedded=true" width="700" height="400" style="border: none;"></iframe>
    </center>
  </html>

pm:cursuri:cursul0_2026.pdf - created

dan.tudose — 2026-05-29T15:18:58+03:00

pp:26:cursuri:mihnea:cod.zip

mihnea.muraru — 2026-05-29T07:39:41+03:00

Autonomous Systems Bootcamp: Intelligent Robotics and Embodied AI Summer School - [Registration & Resources]

jan.vaduva — 2026-05-29T01:15:42+03:00

@@ -32,9 +32,11 @@
      * **Assignments:** Every team must submit each lab assignment. You have 3 late days per lab, with a maximum of 10 total late days for the entire program (spend them wisely!).
      * **Final Project:** No extensions will be granted for the final project proposal or presentation.
  
  ===== Registration & Resources =====
- You can find the technical resources and full syllabus here: [[Insert Link to Course Materials/GitHub|Technical Resources & Full Syllabus]].
+ You can find the technical resources and full syllabus here: [[https://ocw.cs.pub.ro/courses/rasb|Open CourseWare]].
  
- Register for the **Autonomous Systems Bootcamp: Intelligent Robotics and Embodied AI Summer School** before **[Insert Date]**.
+ Register for the **Autonomous Systems Bootcamp: Intelligent Robotics and Embodied AI Summer School** before **22 June 2026**.
+   * Link for 3rd year students: [[https://connect.upb.ro/propunere/f252e17c-bdd3-4ddf-ad06-93bd85b0b8db?type=ByProfessor|Summer Bootcamp]]
+   * Link for the rest: [[https://connect.upb.ro/propunere/eca969f4-7902-4968-ba5e-d20052b2e461?type=ByProfessor|Summer School]]
  
  //The Autonomous Systems Bootcamp: Intelligent Robotics and Embodied AI Summer School is organized by the Faculty of Automatic Control and Computers, POLITEHNICA Bucharest.//

Cursul 12. DataStore, WorkManager

laura.ruse — 2026-05-28T23:56:58+03:00

@@ -2,14 +2,14 @@
  
  ==== 11.1 DataStore ====
  
  
-   * [[https://docs.google.com/presentation/d/17v7A93hbd1Pf-i6XO-UO7B1yYJVj7Ha0/edit?usp=sharing&ouid=101271510483951552258&rtpof=true&sd=true|Slide-uri]]
+   * [[https://docs.google.com/presentation/d/1sOD-tVub7pbi6-Z88TtmIhvuJTxshmPt/edit?usp=sharing&ouid=101271510483951552258&rtpof=true&sd=true|Slide-uri]]
  
  ==== 11.2 WorkManager ====
  
  
-   * [[https://docs.google.com/presentation/d/1o5Ty66LOkwRD7M3STTppq4IBipALIgqJ/edit?usp=sharing&ouid=101271510483951552258&rtpof=true&sd=true|Slide-uri]]
+   * [[https://docs.google.com/presentation/d/1yWo_VTY5TzeHfAxJfsfZ4q2a9Sybu4Qp/edit?usp=sharing&ouid=101271510483951552258&rtpof=true&sd=true|Slide-uri]]
  
  
  ==== Bibliografie ====

Mini Synth - [4. Audio Output — Triple I2S Architecture]

mihai.brisculescu — 2026-05-28T16:17:27+03:00

@@ -244,10 +244,8 @@
  For VDDIO = 3.3 V (Teensy GPIO), the datasheet's formula ''R_SMALL = 94.0 × VDDIO − 100'' gives 210 kΩ — the resistor that puts ''SD_MODE'' between B1 and B2 (right channel) when the GPIO is HIGH.
  
  <note warning>
  **Required breakout rework:** The Adafruit 3006 breakout (and clones) includes a 1 MΩ SMD pull-up between ''SD_MODE'' and the chip's V_DD (5 V). This must be **desoldered from each breakout before installation** — otherwise the GPIO LOW state would fight the pull-up and shutdown never engages. Once removed, only the chip's internal 100 kΩ pull-down remains.
- 
- **Do NOT bridge any breakout channel-selection solder jumpers** (''L'', ''R'', ''Mono''). If bridged, they hard-tie ''SD_MODE'' to the chip's 5 V VDD, and driving the GPIO LOW would short 5 V to GND through the 3.3 V GPIO pin and damage the Teensy.
  </note>
  
  == Wiring ==

SnowyLink: Butoane wireless inteligente pentru dresajul animalelor - [Bibliografie/Resurse]

alice_maria.dobre — 2026-05-28T13:49:22+03:00

@@ -322,10 +322,8 @@
  
  https://randomnerdtutorials.com/esp32-deep-sleep-arduino-ide-wake-up-sources/
  
  https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_now.html
- 
- https://lastminuteengineers.com/esp32-c3-super-mini-pinout-reference/
  
  https://docs.espressif.com/projects/esp-idf/en/stable/esp32c3/api-reference/system/sleep_modes.html
  
  https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/peripherals/i2s.html
@@ -341,8 +339,9 @@
  https://www.diodes.com/assets/Datasheets/PAM8403.pdf
  
  https://dlnmh9ip6v2uc.cloudfront.net/datasheets/Prototyping/TP4056.pdf
  
+ https://lastminuteengineers.com/esp32-c3-super-mini-pinout-reference/
  
  https://www.waveshare.com/wiki/ESP32-S3-Nano

pm:prj2026:bianca.popa1106:loop_002.wav - created

mihai.brisculescu — 2026-05-28T01:41:40+03:00

Smart Helmet Lock

matei.hutu — 2026-05-28T01:09:13+03:00

@@ -165,9 +165,9 @@
  La un consum mediu de ~50mA, bateria de 2200mAh asigură o **autonomie teoretică de aproximativ 40-44 de ore** de funcționare continuă, ceea ce este mai mult decât suficient pentru a lăsa casca asigurată pe parcursul unei zile de muncă sau la facultate.
  
  **Media:**
  Funcționarea completă a proiectului poate fi urmărită în videoclipul demonstrativ de mai jos, alături de pozele cu ansamblul fizic finalizat.
-   * **Video demonstrație:** [[https://youtu.be/W-My42prAcc|{{https://ocw.cs.pub.ro/courses/_media/pm/prj2026/pozavideo_pm-hutumatei.jpeg?730|Poza Video}}]]
+   * **Video demonstrație:** [[https://youtu.be/W-My42prAcc|{{https://ocw.cs.pub.ro/courses/_media/pm/prj2026/pozavideo_pm-hutumatei.png?730|Poza Video}}]]
    * **Poze asamblare:**
  {{https://ocw.cs.pub.ro/courses/_media/pm/prj2026/poza1_pm-hutumatei.jpeg?730|Poza 1}}
  {{https://ocw.cs.pub.ro/courses/_media/pm/prj2026/poza2_pm-hutumatei.jpeg?730|Poza 2}}
  {{https://ocw.cs.pub.ro/courses/_media/pm/prj2026/poza3_pm-hutumatei.jpeg?730|Poza 3}}