slides/lectures/fils_en/04/slides.md

@@ -11,7 +11,7 @@ drawings:
 defaults:
   foo: true
 transition: slide-left
-title: MA - 05 - Asynchronous Development
+title: MA - 04 - Asynchronous Development
 mdc: true
 layout: cover
 themeConfig:
@@ -22,7 +22,7 @@ background:
 ---
 
 # Asynchronous Development
-Lecture 5
+Lecture 4
 
 ---
 ---

slides/lectures/fils_en/05/slides.md

@@ -11,7 +11,7 @@ drawings:
 defaults:
   foo: true
 transition: slide-left
-title: MA - 03 - UART & SPI
+title: MA - 05 - UART & SPI
 mdc: true
 layout: cover
 themeConfig:
@@ -22,12 +22,12 @@ background:
 ---
 
 # UART & SPI
-Lecture 6
+Lecture 5
 
 ---
 
 # UART & SPI
-used by RP2040
+used by RP2350
 
 - Direct Memory Access
 - Buses
@@ -35,7 +35,9 @@ used by RP2040
   - Serial Peripheral Interface
 - Analog and Digital Sensors
 
-<!-- DMA -->
+<!--
+DMA
+-->
 
 ---
 src: ../../resources/dma/slides.md

slides/lectures/fils_en/06/slides.md

@@ -11,7 +11,7 @@ drawings:
 defaults:
   foo: true
 transition: slide-left
-title: MA - 07 - I2C & USB 2.0
+title: MA - 06 - I2C & USB 2.0
 mdc: true
 layout: cover
 themeConfig:
@@ -22,7 +22,7 @@ background:
 ---
 
 # I2C & USB 2.0
-Lecture 7
+Lecture 6
 
 ---
 

slides/lectures/fils_en/07/slides.md

@@ -11,7 +11,7 @@ drawings:
 defaults:
   foo: true
 transition: slide-left
-title: MA - 03 - Exceptions and Interrupts
+title: MA - 07 - Exceptions and Interrupts
 mdc: true
 layout: cover
 themeConfig:
@@ -22,7 +22,7 @@ background:
 ---
 
 # Exceptions and Interrupts
-Lecture 3
+Lecture 7
 
 ---
 

slides/lectures/resources/communication/slides.md

@@ -119,8 +119,8 @@ Embassy provides four types of channels synchronized using `Mutex`s
 |-|-|
 | [`Channel`](https://docs.embassy.dev/embassy-sync/git/default/channel/struct.Channel.html) | A Multiple Producer Multiple Consumer (MPMC) channel. Each message is only received by a single consumer. |
 | [`PriorityChannel`](https://docs.embassy.dev/embassy-sync/git/default/priority_channel/struct.PriorityChannel.html) | A Multiple Producer Multiple Consumer (MPMC) channel. Each message is only received by a single consumer. Higher priority items are shifted to the front of the channel. |
-| [`Signal`](https://docs.embassy.dev/embassy-sync/git/default/pubsub/struct.PubSubChannel.html) | Signalling latest value to a single consumer. |
-| [`PubSubChannel`](https://docs.embassy.dev/embassy-sync/git/default/signal/struct.Signal.html) | A broadcast channel (publish-subscribe) channel. Each message is received by all consumers. |
+| [`Signal`](https://docs.embassy.dev/embassy-sync/git/default/signal/struct.Signal.html) | Signalling latest value to a single consumer. |
+| [`PubSubChannel`](https://docs.embassy.dev/embassy-sync/git/default/pubsub/struct.PubSubChannel.html) | A broadcast channel (publish-subscribe) channel. Each message is received by all consumers. |
 
 ---
 ---
@@ -129,7 +129,7 @@ sends data from one task to another
 
 [`Channel`](https://docs.embassy.dev/embassy-sync/git/default/channel/struct.Channel.html) - A Multiple Producer Multiple Consumer (MPMC) channel. Each message is only received by a single consumer.
 
-[`Signal`](https://docs.embassy.dev/embassy-sync/git/default/pubsub/struct.PubSubChannel.html) - Signalling latest value to a single consumer. 
+[`Signal`](https://docs.embassy.dev/embassy-sync/git/default/signal/struct.Signal.html) - Signalling latest value to a single consumer. 
 
 ```mermaid
 flowchart LR
@@ -166,7 +166,7 @@ flowchart LR
 # PubSubChannel
 sends data from one task to all receiver tasks
 
-[`PubSubChannel`](https://docs.embassy.dev/embassy-sync/git/default/signal/struct.Signal.html) - A broadcast channel (publish-subscribe) channel. Each message is received by all consumers.
+[`PubSubChannel`](https://docs.embassy.dev/embassy-sync/git/default/pubsub/struct.PubSubChannel.html) - A broadcast channel (publish-subscribe) channel. Each message is received by all consumers.
 
 ```mermaid
 flowchart LR
@@ -181,7 +181,7 @@ flowchart LR
 
 # Channel Example
 
-```rust{all|1|2|5,7,14,17-25|5,8-14}
+```rust{1|2|5,7,14,17-25|5,8-14|all}
 enum LedState { On, Off }
 static CHANNEL: Channel<ThreadModeRawMutex, LedState, 64> = Channel::new();
 

slides/lectures/resources/concurrency/slides.md

@@ -22,7 +22,7 @@ layout: two-cols
 }
 </style>
 
-- MCUs are usually *single core*[^rp2040]
+- MCUs are usually *single core*[^rp2350]
 - Tasks in parallel require an OS[^interrupts]
 - Tasks can be suspended at any time
 - **Switching** the task is **expensive**
@@ -54,7 +54,7 @@ sequenceDiagram
     end
 ```
 
-[^rp2040]: RP2040 is a dual core MCU, we use only one core
+[^rp2350]: RP2350 is a dual core MCU, we use only one core
 [^interrupts]: Running in an ISR is not considered a normal task
 
 ---
@@ -79,7 +79,7 @@ layout: two-cols
 
 :: right ::
 
-```mermaid
+```mermaid {scale: 0.6}
 sequenceDiagram
     autonumber
     loop

slides/lectures/resources/dma/slides.md

@@ -6,14 +6,13 @@ layout: section
 Direct Memory Access
 
 ---
----
+
 # Bibliography
 for this section
 
-**Raspberry Pi Ltd**, *[RP2040 Datasheet](https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf)*
-   - Chapter 2 - *System Description*
-     - Chapter 2.5 - *DMA*
-
+**Raspberry Pi Ltd**, *[RP2350 Datasheet](https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf)*
+   - Chapter 12 - *Peripherals*
+     - Chapter 16.6 - *DMA*
 
 ---
 layout: two-cols

slides/lectures/resources/executor/slides.md

@@ -9,10 +9,10 @@ of Embassy
 # Bibliography
 for this section
 
-**Embassy Documentation**, *[Embassy executor](https://embassy.dev/book/dev/runtime.html)*
+**Embassy Documentation**, *[Embassy executor](https://embassy.dev/book/#_embassy_executor)*
 
 ---
----
+
 # Tasks
 
 <div grid="~ cols-2 gap5">
@@ -32,9 +32,9 @@ for this section
 </div>
 
 
-```rust {all|9-22|1-7|18-21|19|3-6|4|5}
+```rust {9-22|1-7|18-21|19|3-6|4|5|all}
 #[embassy_executor::task(pool_size = 2)]
-async fn led_blink(mut led:Output<'static, PIN_X>) {
+async fn led_blink(mut led: AnyPin) {
     loop {
         led.toogle();
         Timer::after_secs(1).await;
@@ -60,7 +60,7 @@ async fn main(spawner: Spawner) {
 </div>
 
 ---
----
+
 # Tasks can stop the executor
 
 <div grid="~ cols-2 gap5">
@@ -73,9 +73,9 @@ async fn main(spawner: Spawner) {
 </div>
 
 
-``` {all|5-8|3-9}
+```rust {5-8|3-9|all}
 #[embassy_executor::task]
-async fn led_blink(mut led:Output<'static, PIN_X>) {
+async fn led_blink(mut led: AnyPin) {
     loop {
         led.toogle();
         // this does not execute anything
@@ -114,6 +114,7 @@ async fn main(spawner: Spawner) {
 ---
 layout: two-cols
 ---
+
 ## Priority Tasks
 
 <style>
@@ -139,7 +140,7 @@ unsafe fn SWI_IRQ_0() {
 
 :: right ::
 
-```rust {all|5,6,22|1,7-10|2,12-15|3,17-21}
+```rust {5,6,22|1,7-10|2,12-15|3,17-21|all}
 static EXECUTOR_HIGH: InterruptExecutor = InterruptExecutor::new();
 static EXECUTOR_MED: InterruptExecutor = InterruptExecutor::new();
 static EXECUTOR_LOW: StaticCell<Executor> = StaticCell::new();

slides/lectures/resources/future/slides.md

@@ -33,7 +33,7 @@ trait Future {
 }
 ```
 
-```rust {all|5,10|6|6,7|6|6,7|6|6,8|1,8}{lines: false}
+```rust {5,10|6|6,7|6|6,7|6|6,8|1,8|all}{lines: false}
 fn execute<F>(mut f: F) -> F::Output
 where
   F: Future
@@ -74,7 +74,7 @@ sequenceDiagram
 
 <div grid="~ cols-2 gap-5">
 
-```rust {all|1-4|6-9|11-18}
+```rust {1-4|6-9|11-18|all}
 enum SleepStatus {
     SetAlarm,
     WaitForAlarm,
@@ -97,7 +97,7 @@ impl Sleep {
 
 <v-click>
 
-```rust {all|1,20|1,2,20|4,19|5,18|6-10|11-17|11,12,13|11,14,15}{lines: false}
+```rust {1,20|1,2,20|4,19|5,18|6-10|11-17|11,12,13|11,14,15|all}{lines: false}
 impl Future for Sleep {
     type Output = ();
 
@@ -130,7 +130,7 @@ impl Future for Sleep {
 
 <div grid="~ cols-2 gap-5">
 
-```rust {all|1,20|1,2,20|4,19|5,18|6-10|11-17|11,12,13|11,14,15}{lines: false}
+```rust {1,20|1,2,20|4,19|5,18|6-10|11-17|11,12,13|11,14,15|all}{lines: false}
 impl Future for Sleep {
     type Output = ();
 
@@ -218,7 +218,7 @@ fn blink(led: Output<'static, PIN_X>) -> Blink {
 
 <v-click>
 
-```rust {4-23|5-22|5,6-10,22|5,11-17,22|12-14|5,11-17,22|12,14,15,16|5,18-21,22}{lines: false}
+```rust {4-23|5-22|5,6-10,22|5,11-17,22|12-14|5,11-17,22|12,14,15,16|5,18-21,22|all}{lines: false}
 impl Future for Blink {
   type Output = ();
   fn poll(&mut self) -> Poll<Self::Output> {
@@ -257,7 +257,7 @@ impl Future for Blink {
 - it does not know how to execute them
 - executors are implemented into third party libraries
 
-```rust {all|12|11,13,15|14}
+```rust {12|11,13,15|14|all}
 use engine::execute;
 
 // Rust rewrites the function to a Future
@@ -280,7 +280,7 @@ fn main() -> ! {
 ---
 # Executor
 
-```rust {all|1|4-16|5-12|14,15}
+```rust {1|4-16|5-12|14,15|all}
 static TASKS: [Option<impl Future>; N] = [None, N];
 
 fn executor() {

slides/lectures/resources/gpio_avr/slides.md

@@ -20,7 +20,7 @@ A simple GPIO
 
 <br>
 
-> <b> DDRx - Data Direction Register. </b> If the data direction bit is 1, the pin is an input. 0 is an output.
+> <b> DDRx - Data Direction Register. </b> If the data direction bit is 0, the pin is an input. 1 is an output.
 
 ```c
 DDRB &= ~(1<<DDB7); // Makes pin PB7 an input

slides/lectures/resources/sensors/slides.md

@@ -81,7 +81,7 @@ using synchronous/asynchronous SPI to read the `press_lsb` register of BMP280
 
 <div grid="~ cols-2 gap-5">
 
-```rust{all|1|3,4|6,7|6,7,8|10,11|13,14}
+```rust {1|3,4|6,7|6,7,8|10,11|13,14|all}
 const REG_ADDR: u8 = 0xf8;
 
 // enable the sensor
@@ -98,7 +98,7 @@ cs.set_high();
 let pressure_lsb = buf[1];
 ```
 
-```rust{none|all|1|3,4|6,7,8|6,7,8,9|11,12|14,15}
+```rust {none|1|3,4|6,7,8|6,7,8,9|11,12|14,15|all}
 const REG_ADDR: u8 = 0xf8;
 
 // enable the sensor
@@ -118,9 +118,8 @@ let pressure_lsb = rx_buf[1];
 
 </div>
 
-
----
 ---
+
 # Writing to a digital sensor
 using synchronous/asynchronous SPI to set up the `ctrl_meas` register of the BMP280 sensor 
 
@@ -128,7 +127,7 @@ using synchronous/asynchronous SPI to set up the `ctrl_meas` register of the BMP
 
 <div grid="~ cols-2 gap-5">
 
-```rust{all|1|3,4|6,7|9,10|9,10,11|13,14}
+```rust {1|3,4|6,7|9,10|9,10,11|13,14|all}
 const REG_ADDR: u8 = 0xf4;
 
 // see subchapters 3.3.2, 3.3.1 and 3.6
@@ -145,7 +144,7 @@ spi.blocking_transfer_in_place(&mut buf);
 cs.set_high();
 ```
 
-```rust{none|all|1|3,4|6,7|9,10|9,10,11|9,10,11,12|14,15}
+```rust {none|1|3,4|6,7|9,10|9,10,11|9,10,11,12|14,15|all}
 const REG_ADDR: u8 = 0xf4;
 
 // see subchapters 3.3.2, 3.3.1 and 3.6

slides/lectures/resources/spi/slides.md

@@ -4,15 +4,14 @@ layout: section
 # SPI
 Serial Peripheral Interface
 
----
 ---
 
 # Bibliography
 for this section
 
-1. **Raspberry Pi Ltd**, *[RP2040 Datasheet](https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf)*
-   - Chapter 4 - *Peripherals*
-     - Chapter 4.4 - *SPI*
+1. **Raspberry Pi Ltd**, *[RP2350 Datasheet](https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf)*
+   - Chapter 12 - *Peripherals*
+     - Chapter 12.3 - *SPI*
 
 2. **Paul Denisowski**, *[Understanding SPI](https://www.youtube.com/watch?v=0nVNwozXsIc)*
 
@@ -213,21 +212,21 @@ activate all the **sub** devices
 | Speed | *no limit* | does not have any limit, it is limited by the **main** clock and the electronics wirings |
 
 ---
----
+
 # Usage
 
 - EEPROMs / Flash (usually in *QSPI* mode)
   - Raspberry Pi Pico has its 2MB Flash connected using *QSPI*
 - sensors
 - small displays
-- RP2040 has two SPI devices
+- RP2350 has two SPI devices
 
 <div align="center">
-<img src="./raspberry_pi_pico_pins.jpg" class="rounded m-5 w-120">
+<img src="../rp2350/pico2w-pinout.svg" class="rounded m-5 w-100">
 </div>
 
 ---
----
+
 # Embassy API
 for RP2040, synchronous
 
@@ -257,7 +256,7 @@ pub enum Polarity {
 
 </div>
 
-```rust{all|1|2|2,3|5-7|5-8|10,11|13|13,14|13,14,15|13,14,15,16}
+```rust {1|2|2,3|5-7|5-8|10,11|13|13,14|13,14,15|13,14,15,16|all}
 use embassy_rp::spi::Config as SpiConfig;
 let mut config = SpiConfig::default();
 config.frequency = 2_000_000;
@@ -277,11 +276,11 @@ cs.set_high();
 ```
 
 ---
----
+
 # Embassy API
 for RP2040, asynchronous
 
-```rust{all|1|2|2,3|5-7|5-8|10,11|13|13,14,15|13,14,15,16|13,14,15,16,17}
+```rust {1|2|2,3|5-7|5-8|10,11|13|13,14,15|13,14,15,16|13,14,15,16,17|all}
 use embassy_rp::spi::Config as SpiConfig;
 let mut config = SpiConfig::default();
 config.frequency = 2_000_000;

slides/lectures/resources/timers/slides.md

@@ -212,7 +212,7 @@ read the number of elapsed μs since reset
 
 #### Reading the time elapsed since restart
 
-```rust{1,5|2,6|4,7,8|all}
+```rust {1,5|2,6|4,7,8|all}
 const TIMERLR: *const u32 = 0x400b_000c;
 const TIMERHR: *const u32 = 0x400b_0008;
 
@@ -228,7 +228,7 @@ The **reading order maters** as reading `TIMELR` latches the value in `TIMEHR` (
 :: right ::
 
 <div align="center">
-    <img src="./rp2350_timer_registers_1.png" class="rounded w-100">
+    <img src="./rp2350_timer_registers_1.png" class="rounded w-90">
 </div>
 
 ---

slides/lectures/resources/uart/slides.md

@@ -5,13 +5,13 @@ layout: section
 Universal Asynchronous Receiver and Transmitter
 
 ---
----
+
 # Bibliography
 for this section
 
-1. **Raspberry Pi Ltd**, *[RP2040 Datasheet](https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf)*
-   - Chapter 4 - *Peripherals*
-     - Chapter 4.2 - *UART*
+1. **Raspberry Pi Ltd**, *[RP2350 Datasheet](https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf)*
+   - Chapter 12 - *Peripherals*
+     - Chapter 12.1 - *UART*
 
 2. **Paul Denisowski**, *[Understanding Serial Protocols](https://www.youtube.com/watch?v=LEz5UCN3aHA)*
 3. **Paul Denisowski**, *[Understanding UART](https://www.youtube.com/watch?v=sTHckUyxwp8)*
@@ -193,21 +193,21 @@ using the 8N1 data format
 </div>
 
 ---
----
+
 # Usage
 
 - print debug information
 - device console
-- RP2040 has two USART devices
+- RP2350 has two USART devices
 
 <div align="center">
-<img src="../rp2040/rp2040_adafruit_pinout.png" class="rounded m-5 w-100">
+<img src="../rp2350/pico2w-pinout.svg" class="rounded m-5 w-100">
 </div>
 
 ---
 
 # Embassy API
-for RP2040, synchronous
+for RP2350, synchronous
 
 <div grid="~ cols-4 gap-5">
 
@@ -250,7 +250,7 @@ pub enum Parity {
 
 </div>
 
-```rust{all|1|1,2|4,5|6,7|9,10,11}
+```rust {1|1,2|4,5|6,7|9,10,11|all}
 use embassy_rp::uart::Config as UartConfig;
 let config = UartConfig::default();
 
@@ -264,13 +264,12 @@ let mut buf = [0; 5];
 uart.blocking_read(&mut buf);
 ```
 
-
 ---
 
 # Embassy API
-for RP2040, asynchronous
+for RP2350, asynchronous
 
-```rust{all|1|3-5|7|9,10|12,13|15,16,17}
+```rust {1|3-5|7|9,10|12,13|15,16,17|all}
 use embassy_rp::uart::Config as UartConfig;
 
 bind_interrupts!(struct Irqs {

website/lab/04/index.md

 ---
 description: Asynchronous Programming with Embassy
 slug: /lab/04
-unlisted: true
 ---
 
 # 04 - Asynchronous Development
@@ -14,23 +13,61 @@ This lab will teach you the principles of asynchronous programming, and its appl
 1. **Bert Peters**, *[How does async Rust work](https://bertptrs.nl/2023/04/27/how-does-async-rust-work.html)* 
 2. **Omar Hiari**, *[Sharing Data Among Tasks in Rust Embassy: Synchronization Primitives](https://dev.to/apollolabsbin/sharing-data-among-tasks-in-rust-embassy-synchronization-primitives-59hk)* 
 
-## Asynchronous functions
+## Asynchronous functions and Tasks
 
-Up to now, during the labs, we've seen that, in order to be able to do multiple different actions "at once", we would use *tasks*. We would let the `main` function run, while also doing another action seemingly "in parallel" inside of another task. 
-Let's take the following example: if we want to blink an LED every second while also waiting for a button press to do something else, we would need to spawn a new task in which we would wait for the button press, while blinking the LED in the `main` function. 
+Until now you've only worked with simple (almost) serial programs. However, not all programs can be designed to run serially/sequentially. Handling multiple I/O events concurrently usually requires separate parallel tasks. 
+Example: Reading a button press while blinking an LED. A single loop would block the button reading event while waiting for the timer to finish.
+
+```mermaid
+sequenceDiagram
+    participant Button as Button
+    participant Timer as Timer
+    participant Task as Main Task (LED + Button)
+    participant LED as LED Control
+    
+    loop
+    %% LED starts blinking
+    Task->>LED: Turn LED ON
+    Timer->>+Task: Delay 1 sec (Blocks everything)
+    
+    %% Button presses button during delay
+    Button-->>Task: Button Press Sent (but microcontroller is busy)
+ 
+    
+    Task->>-Task: Continue with next instruction
+    %% LED continues
+    Task->>LED: Turn LED OFF
+
+    Timer->>+Task: Delay 1 sec (Blocks everything)
+    Button-->>Task:Button Press Sent (but microcontroller is busy)
+
+    Task->>-Task: Continue with next instruction
+
+    %% Now the task checks the button, but it's too late
+
+    Task->>Button: Check if button is pressed
+    Button-->>Task: No press detected (press was missed)
+    end
+    
+    Note over Button, Button: User pressed button, but MCU was busy!
+    Note over Task: Button check happens too late.
 
-When thinking of how exactly this works, you would probably think that the task is running on a separate *thread* than the `main` function. Usually this would be the case when developing a normal computer application. Multithreading is possible, but requires a preemptive operating system. Without one, only one thread can independently run per processor core and that means that, since we are using only one core of the RP2040 (which actually has only 2), we would only be able to run **one thread at a time**. So how exactly does the task wait for the button press in parallel with the LED blinking? 
-Short answer is: it doesn't. In reality, both functions run asynchronously. 
 
-### Tasks
+```
+
+ To address this issue, we would need to spawn a new task in which we would wait for the button press, while blinking the LED in the `main` function. 
+
+When thinking of how exactly this works, you would probably think that the task is running on a separate *thread* than the `main` function. Usually this would be the case when developing a normal computer application. Multithreading is possible, but requires a preemptive operating system. Without one, only one thread can independently run per processor core and that means that, since we are using only one core of the RP2350 (which actually has only 2), we would only be able to run **one thread at a time**. So how exactly does the task wait for the button press in parallel with the LED blinking? 
+Short answer is: it doesn't. In reality, both functions run asynchronously. 
 
 A task in Embassy is represented by an *asynchronous function*. Asynchronous functions are different from normal functions, in the sense that they allow asynchronous code execution. Let's take an example from the previous lab:
 ```rust
 #[embassy_executor::task]
-async fn button_pressed(mut led: Output<'static, PIN_X>, mut button: Input<'static, PIN_X>) {
+async fn button_pressed(mut led: Output<'static>, mut button: Input<'static>) {
     loop {
 	info!("waiting for button press");
         button.wait_for_falling_edge().await;
+        led.toggle();
     }
 }
 
@@ -38,7 +75,7 @@ async fn button_pressed(mut led: Output<'static, PIN_X>, mut button: Input<'stat
 async fn main(spawner: Spawner) {
     let peripherals = embassy_rp::init(Default::default());
 
-    let button = Input::new(peripherals.PIN_X, Pull::Up);
+    let button = Input::new(peripherals.PIN_X, Pull::None);
     let led2 = Output::new(peripherals.PIN_X, Level::Low);
 
     spawner.spawn(button_pressed(led2, button)).unwrap();
@@ -196,7 +233,7 @@ let (res1, res2) = join(button.wait_for_falling_edge(), Timer::after_secs(5)).aw
 `join` returns a tuple containing the results of both `Future`s.
 
 
-## Channels
+## Channel
 
 Up to this point, to be able to share peripherals or data across multiple tasks, we have been using global `Mutex`s or passing them directly as parameters to the tasks. But there are other, more convenient ways to send data to and from tasks. Instead of having to make global, static variables that are shared by tasks, we could choose to only send the information that we need from one task to another. To achieve this, we can use *channels*.
 
@@ -248,107 +285,171 @@ that the value cannot be modified concurrently by two different tasks, or use ch
 To better understand the concepts of ownership and borrowing in Rust, take a look at [chapter 4](https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html) of the Rust Book.
 :::
 
-## Potentiometer
+### `Signal`
 
-A potentiometer is a three-terminal resistor with a sliding or rotating contact that forms an adjustable voltage divider. If only two terminals are used, one end and the wiper, it acts as a variable resistor or rheostat. A volume knob on a speaker is a potentiometer, for instance.
+This is similar to a `Channel` with a buffer size of 1, except “sending” to it (calling `Signal::signal`) when full will overwrite the previous value instead of waiting for the receiver to pop the previous value.
 
-![Potentiometer](images/potentiometer_pins.png)
+It is useful for sending data between tasks when the receiver only cares about the latest data, and therefore it's fine to “lose” messages. This is often the case for “state” updates.
 
-## Exercises
 
-![Pico Explorer Pinout](../images/explorer_pins.jpg)
+```rust
 
-1. Connect an LED to GP0, an RGB LED to GP1, GP2, GP5 and a potentiometer to ADC0. Use Kicad to draw the schematic. (**1p**)
-2. Change the monochromatic LED's intensity, using button A (SW_A) and button B(SW_B) on the Pico Explorer. Button A will increase the intensity, and button B will decrease it. (**2p**)
+use embassy_sync::signal::Signal;
 
-:::tip
-- Use PWM to control the intensity.
-- Create two tasks, one for button A, one for button B. Use a channel to send commands from each button task to the main task.
-:::
+static SIG: Signal<CriticalSectionRawMutex, ()> = Signal::new();
 
-3. Control the RGB LED's color with buttons A, B, X and Y on the Pico Explorer. (**2p**)
-- Button A -> RGB = Red
-- Button B -> RGB = Green
-- Button X -> RGB = Blue
-- Button Y -> RGB = Led Off
-:::tip
-Use a separate task for each button. When a button press is detected, a command will be sent to the main task, and the main task will set the RGB LED's color according to that command.
+#[embassy_executor::task]
+async fn waiter() {
+    SIG.wait().await; // Wait until signaled
+    defmt::info!("Signal received!");
+}
+
+#[embassy_executor::task]
+async fn trigger() {
+    SIG.signal(()); // Notify the waiting task
+}
 
-:::warning
-When building Rust software in *debug mode*, which is what `cargo build` does, Rust will panic if mathematical operations underflow or overflow. This means that:
 
-```rust
-let v = 10u8;
-v -= 12;
 ```
 
-will panic. To avoid this, you can use the [`wrapping_`](https://doc.rust-lang.org/std/primitive.u8.html#method.wrapping_add) and [`saturating_`](https://doc.rust-lang.org/std/primitive.u8.html#method.saturating_add) functions:
+### `PubSubChannel`
 
-```rust
-let v = 10u8;
-// this will store 0 in v
-v = v.saturating_sub(12); 
-```
-:::
+This is a type of channel where any published message can be read by all subscribers. A publisher can choose how it sends its message.
 
-```mermaid
-sequenceDiagram
-    autonumber
-    note right of TaskBtnA: waits for button A press
-    note right of TaskBtnB: waits for button B press
-    note right of TaskBtnX: waits for button X press
-    note right of TaskBtnY: waits for button Y press
-    note right of TaskMain: waits for LED command
-    Hardware-->>TaskBtnA: button A press
-    TaskBtnA-->>TaskMain: LedCommand(LedColor::Red)
-    note right of TaskMain: sets PWM configuration
-    TaskMain-->>Hardware: sets RGB LED color RED
-    Hardware-->>TaskBtnX: button X press
-    TaskBtnX-->>TaskMain: LedCommand(LedColor::Blue)
-    note right of TaskMain: sets PWM configuration
-    TaskMain-->>Hardware: sets RGB LED color BLUE
-```
-:::
+- With Pub::publish() the publisher has to wait until there is space in the internal message queue.
+- With Pub::publish_immediate() the publisher doesn't await and instead lets the oldest message in the queue drop if necessary. This will cause any Subscriber that missed the message to receive an error to indicate that it has lagged.
 
-4. In addition to the four buttons, control the RGB LED's intensity with the potentiometer. (**3p**)
+Example:
 
-:::tip
-You will need another task in which you sample the ADC and send the values over a channel.
-You could do this in one of two ways:
-1. Use a single channel for both changing the color and the intensity of the LED. Button tasks and the potentiometer task will send over the same channel. For this, you will need to change the type of data that is sent over the channel to encapsulate both types of commands. For example, you could use an enum like this:
 ```rust
-enum LedCommand {
-    ChangeColor(Option<LedColor>),
-    ChangeIntensity(u16)
+
+use embassy_sync::pubsub::PubSubChannel;
+
+static PUB: PubSubChannel<CriticalSectionRawMutex, &'static str, 4, 2> = PubSubChannel::new();
+
+#[embassy_executor::task]
+async fn publisher() {
+    PUB.publisher().publish("Hello").await;
 }
-```
-2. Use two separate channels, one for sending the color command (which contains the LedColor), and one for sending the intensity. You can `await` both channel `receive()` futures inside of a `select` to see which command is received first, and handle it.
-Example:
-```rust
-let select = select(COLOR_CHANNEL.receive(), INTENSITY_CHANNEL.receive()).await;
-match select {
-    First(color) => {
-        // ...
-    },
-    Second(intensity) => {
-        // ...
-    }
+
+#[embassy_executor::task]
+async fn subscriber1() {
+    let mut sub = PUB.subscriber().unwrap();
+    let msg = sub.next_message().await;
+    defmt::info!("Sub 1 got: {}", msg);
+}
+
+#[embassy_executor::task]
+async fn subscriber2() {
+    let mut sub = PUB.subscriber().unwrap();
+    let msg = sub.next_message().await;
+    defmt::info!("Sub 2 got: {}", msg);
 }
+
 ```
-:::
 
-5. Print to the screen of the Pico Explorer the color of the RGB LED and its intensity. Use the SPI screen driver provided in the lab skeleton. (**2p**)
+
+## Buzzer
+
+A buzzer is a hardware device that emits sound. There are two types of buzzers:
+- *active buzzer* - connected to VCC and GND, with a resistance - emits a constant frequency
+- *passive buzzer* - connected to a GPIO pin and GND, with a resistance - frequency can be controlled through the pin with PWM
+
+![Buzzer](images/buzzer.png)
+
 :::tip
-To write to the screen, use this example:
-```rust
-let mut text = String::<64>::new();
-write!(text, "Screen print: ", led_color).unwrap(); // led_color must be defined first
+To control the buzzer, all you need to do is to set the `top` value of the PWM config to match the frequency you want!
+:::
+
+#### How to wire an RGB LED
 
-Text::new(&text, Point::new(40, 110), style)
-    .draw(&mut display)
-    .unwrap();
+The buzzer on the development board is connected to a pin in the J9 block.
 
-// Small delay for yielding
-Timer::after_millis(1).await;
+![board_buzzer](./images/board_buzzer.png)
+
+## Exercises
+
+1. Use two separate tasks to make the RED LED and BLUE LED blink 1 time per second. Instead of using `Timer::after_millis(time_interval).await` use *busy waiting* by starting a timer using `Instant::now();` and checking the elapsed time in a `while` loop using 
+
+```rust
+while start_time.elapsed().as_millis() < time_interval {}
 ```
+
+You should notice that one of the tasks is not running. Why? (**1p**)
+    :::tip
+    Use a different task instance for each LED. You can spawn multiple instances of the same task, however you need to specify the pool size with `#[embassy_executor::task(pool_size = 2)]`. Take a look at [task-arena](https://docs.embassy.dev/embassy-executor/git/std/index.html#task-arena) for more info.
+    Use [`AnyPin`](https://docs.embassy.dev/embassy-rp/git/rp2040/gpio/struct.AnyPin.html) and blinking frequency parameters for the task. 
+    :::
+    
+2. Fix the usage of busy waiting from exercise 1 and make the 4 LEDs (YELLOW, RED, GREEN, BLUE) blink at different frequencies. (**1p**)
+
+Blink:
+
+| LED | frequency |
+|-|-|
+| YELLOW | 3 Hz |
+| RED | 4 Hz |
+| GREEN | 5 Hz |
+| BLUE | 1 Hz |
+
+:::tip
+1 Hz means once per second.
 :::
+
+3. Write a firmware that changes the RED LED's intensity, using switch **SW_4** and switch **SW_5**. Switch **SW_4** will increase the intensity, and switch **SW_5** will decrease it. You will implement this in three ways: (**3p**)
+   
+   1. Use three tasks : one task will be the `main` to control the LED and another two tasks for each button (one for switch **SW_4**, one for switch **SW_5**). Use a [`Channel`](#channel) to send commands from each button task to the main task.
+    :::tip
+    Use an `enum` to define the LED Intensity change command for point i.
+    :::
+   2. Use a single task (`main`). Use [`select`](#select) to check which of the buttons were pressed and change the LED intensity accordingly. 
+   3. Use two tasks: one taks will be the `main` to control the LED and another one for both buttons. Use a [`Signal`](#signal) channel to transmit from the buttons task, the new value of the intensity which the LED will be set to. The `main` will wait for a new value on the `Signal` channel and change the intensity accordingly.
+    :::tip
+    Instead of sending commands over the channel like you did at point i, send the intensity value as a number.
+    :::
+
+
+
+4. Simulates a traffic light using the GREEN, YELLOW and RED LEDs on the board. Normally the traffic light goes from one state based on the time elapsed (Green -> 5s , Yellow Blink (4 times) -> 1s , Red -> 2s ).
+However if the switch **SW4** is pressed the state of traffic light changes immediately as shown in the diagram bellow.(**2p**)
+
+    ```mermaid
+    flowchart LR
+        green(GREEN) -- Button pressed --> yellow(Yellow)
+        green(GREEN) -- 5s --> yellow(Yellow)
+
+        
+        yellow(YELLOW - Blink 4 times/second) -- Button pressed --> red(RED)
+
+        yellow(YELLOW - Blink 4 times/second) -- 1s --> red(RED)
+
+        red(RED) -- Button pressed --> red(RED)
+        red(RED) -- 2s --> green(GREEN)
+
+        classDef red fill:#ff0000,stroke:#000000,color: #ffffff
+        classDef yellow fill:#efa200,stroke:#000000
+        classDef green fill:#00ce54,stroke:#000000
+
+        class red red
+        class yellow yellow
+        class green green
+    ```
+
+    :::tip
+    For this exercise you only need one task. Define an `enum` to save the traffic light state (`Green`, `Yellow`,`Red`). Use `match` to check the current state of the traffic light. Then you need to wait for two futures, since the traffic light changes its color either because some time has elapsed or because the button was pressed. Use `select` to check which future completes first (`Timer` or button press).
+    :::
+
+5.  Continue exercise 4: this time, instead of using only the switch **SW4** to change the state of traffic light, we will use the switches **SW4** and **SW7** pressed consecutively to trigger a state change of the traffic light. Use `join` to check that both switches were pressed. (**1p**)
+   :::note
+    The switches don't need to be pressed at the same time, but one after the other. The order does not matter.
+
+    The traffic light transitions between states either based on the elapsed time or through pressing the switches as described above.
+   :::
+
+6. Continue exercise 5:
+   - add a new task to control the buzzer. The buzzer should make a continuous low frequency (200Hz) sound while the traffic light is green or yellow and should start beeping (at 400Hz) on and off while the traffic light is red (Use the [formula from Lab03](./03#calculating-the-top-value) to calculate the frequency) . (**1p**)
+   - add a new task for a servo motor. Set the motor position at 180° when the light is green, 90° the light is yellow, and 0° if its red. (**1p**)
+   :::tip
+    Use a `PubSubChannel` to transmit the state of the traffic light from the LEDs task to both the buzzer and the servo motor tasks.
+   :::
+