Table of Contents

• Introduction
• The Publisher-Subscriber (Pub/Sub) Design Pattern
  • Embassy Framework and Pub/Sub
• Rust Modules
• Making a Temporary Button for Development
• File Changes
  • button/messaging.rs
  • button/core.rs
  • button/consumer_loop.rs
  • button/mod.rs
  • main.rs
• Let’s Give it a Shot!

Introduction

💻 HACKER In this part, we’ll focus on setting up a fitting code design pattern for our button. Software design patterns are general, reusable templates for solving common programming problems and achieving specific goals.

Design patterns help organize and simplify code, making it more logical, maintainable, scalable, extensible, and, perhaps most importantly, less of a headache to work with.

We have actually already implemented a behavioral design pattern in our program by using a finite state machine. That behavioral pattern is the State pattern, where the program’s flow depends on its internal state and some event.

In our embedded Rust program, we will also need a design pattern that helps loosely couple our code. That is, some parts of the program should not need to know what other parts are specifically doing. For example, some of our code should know that a button press event occurred, but not how it happened or how it was detected.

This kind of program architecture helps us follow the separation of concerns principle, making development cleaner, more modular, and easier to maintain.

The Publisher-Subscriber (Pub/Sub) Design Pattern

The Publisher-Subscriber (Pub/Sub) pattern is a messaging design pattern that enables decoupled communication between different parts of a program. In this pattern, publishers send messages to topics/channels without really knowing who (if anyone) will receive them, while subscribers listen to specific topics without knowing who is sending the messages.

Because the typically used Pub/Sub newspaper analogy has been beaten into the ground, let’s try another analogy:

When a parent (publisher) yells out something important (like “Time for dinner!”), they don’t need to track down each child (subscriber) individually. They broadcast the message and let any interested child respond. The parent doesn’t really care what the children do with the information, and the children don’t really need to know why the parent said it. Both sides are completely independent.

Embassy Framework and Pub/Sub

Our Embassy framework implements Pub/Sub through its concurrency messaging pattern using lightweight in-memory channels. This isn’t a network-based distributed message broker system like MQTT, but rather:

• Local communication: All messaging happens within our single microcontroller firmware
• Zero network overhead: Communication occurs through shared memory with nanosecond latency
• Asynchronous and non-blocking: Tasks can publish and subscribe without blocking other operations
• No dynamic memory allocations: Uses compile-time allocated channels
• Power efficient: No busy-waiting or polling required

In our embedded application, we will use Embassy’s Pub/Sub implementation for button event handling: PubSubChannel

The publisher will be the button monitoring task that detects physical button presses and publishes button press events. Any component interested in button press events (state machine, LED controller, buzzer, etc.) can subscribe and listen to the topic/channel.

This architecture allows us to easily add new features (like logging button presses or sending network requests) by simply adding new subscribers, without modifying the core button detection logic.

Rust Modules

Imagine if all of your project code had to be included within a single directory, or even worse, one single file. Wouldn’t that be fun?! 😭

Rust modules are a way to organize and structure your code into logical, reusable pieces. Think of them as containers or folders that group related functionality together, making your code more organized and maintainable.

In our specific case, we want to group all code and files that are related to similar functionality (i.e., code for the button). This allows us to neatly separate and even potentially re-use/share our grouped module code.

Working with Rust modules you will have to become familiar with four things: a file defining the module, mod, pub, and use.

A simple example of how to use these concepts can be found here.

We will use Rust modules for distinctly separate components, such as all code that handles button functionality.

Making a Temporary Button for Development

💻 MAKER By the end of this part we will have code that works with a button press input. This means that in order to test and troubleshoot our current code, we need some way to electrically generate a button input event.

To achieve this, instead of buying that giant red button now, we will simply touch two stripped wires together.

1. Take the 26 AWG wire suggested in the previous part and cut two 4-inch long pieces.

2. Strip about 0.25 to 0.5 inches off each end of the wire pieces

3. Insert and fasten each wire into the development board. Connect one wire into GP15 and the other wire into any open GND terminal.

Once the two wire pieces are connected, your set up should look something like the following.

Then when you want to simulate a “button press”, simply touch the two wires together.

Don’t worry, we will get to connect and build all the cool hardware in subsequent parts. Now, our main concern is developing the Rust code for our project.

File Changes

For a quick indicator of what files we will add or change in this part, expand the following file tree. Here we are only showing the src project directory.

Note that we are adding an entire directory for anything related to the button and button press. This will keep code structure clearer and more organized.

10 collapsed lines
src
├── button
│   ├── consumer_loop.rs  # <--- New
│   ├── core.rs           # <--- New
│   ├── messaging.rs      # <--- New
│   └── mod.rs            # <--- New
├── clocks_config.rs
├── main.rs               # <--- Changes
├── state_machine.rs
└── utility.rs

button/messaging.rs

First, let’s define the logic that will be critical to our Publisher-Subscriber pattern. Here we will be defining anything that is involved in our messaging.

Although it would be easy to just have one kind of button press type, we are anticipating a variety of different press types (i.e., short press, long press, hold). For now, let’s define a PressType enum with one single press type: RegularPress.

1
//! Button module - Messaging - Pub-Sub
2

3
#![allow(dead_code)] // only used for development
4

5
use embassy_sync::blocking_mutex::raw::ThreadModeRawMutex; // Ensure thread-safety across tasks
6
use embassy_sync::pubsub::PubSubChannel;
7
use embassy_time::Instant;
8

9
/// Button press type
10
#[derive(Debug, Copy, Clone, PartialEq)]
11
pub enum PressType {
12
    /// Regular button press type
13
    RegularPress,
14
}

We will next define the message structure that is passed by the publisher into the Pub/Sub channel. This message should be specific to the button press and tell us some useful information about the button press event.

16
/// Button pub-sub message item definition/structure that is passed via channel
17
#[derive(Debug, Copy, Clone)]
18
pub struct ButtonMessage {
19
    /// Button ID
20
    pub id: u8,
21
    /// Timestamp of button press start
22
    pub timestamp_start: Instant,
23
    /// Timestamp of button press end
24
    pub timestamp_end: Instant,
25
    /// The type of button press
26
    pub press_type: PressType,
27
}

This button press message structure is defined in ButtonMessage and contains things like button press timing and the button press type. We are also including the id in case there are other buttons that are pressed.

Lastly, let’s define our Pub/Sub topic/channel with PubSubChannel. This is the conduit, or pipe, into which the message is fed by a publisher, and from which subscribers read these messages.

29
/// Button pub-sub topic channel
30
/// Other program parts can listen to this topic to get button press events
31
/// 2 total capacity/messages, 3 subscribers, and 1 publisher
32
pub static BUTTON_PUBSUB_CHANNEL: PubSubChannel<ThreadModeRawMutex, ButtonMessage, 2, 3, 1> = PubSubChannel::new();

A few things to note in this channel definition:

• Given our embedded no-std nature of the program, we must define: how many messages can this channel hold, how many subscribers can read from this channel, and how many publishers can post to this channel
• ThreadModeRawMutex ensures our publisher and subscribers can safely share the channel without stepping on each other’s toes (race conditions).

button/core.rs

Now we will add the main logic for the button functionality. This file will contain everything that the button actually does. In this part we only are going to add the fundamental and basic code to it, however in later parts we will add more code.

Although there are relatively many additions to this file, we will step-by-step define and explain this code.

To make this code less verbose and more understandable, let’s introduce a few Rust type aliases. Type aliases define a new name for an existing type. For example, here we are defining our ItemId, ItemHandle, and ItemInfo.

1
//! Button module
2

3
use defmt::*;
4
use defmt_rtt as _;
5
use panic_probe as _;
6

7
use embassy_rp::gpio::Input;
8
use embassy_sync::blocking_mutex::raw::ThreadModeRawMutex; // Ensure thread-safety across tasks
9
use embassy_sync::pubsub::{Error, Publisher};
10
use embassy_time::Instant;
11
use embassy_time::Timer;
12

13
use super::{BUTTON_PUBSUB_CHANNEL, ButtonMessage, PressType};
14

15
// Custom type aliases
16
type ItemId = u8;
17
type ItemHandle = Input<'static>;
18
type ItemInfo = [(ItemId, ItemHandle); 1];

The Button Struct

Next, we will define our Button struct which will manage our button hardware. The struct holds two key properties:

• item_info: An array of button definitions, where each button has an ID and its GPIO input handle
• button_pubsub_publisher: A publisher that will send button events through our pub-sub channel

The constructor takes our button definitions and creates a publisher from the global channel we defined earlier. This publisher will allow us to broadcast button press events to any subscribers listening on the channel. Notice that our publisher matches our previously defined pub/sub definition of 2 total messages, 3 subscribers, and 1 publisher.

20
/// Handle for individual Buttons - Button has all provisioned buttons defined
21
pub struct Button<'a> {
22
    /// Button definitions - `[(<BUTTON ID>, <`[Input]` HANDLE>), ...]`
23
    pub item_info: ItemInfo,
24
    /// Button pub-sub publisher for message publishing
25
    pub button_pubsub_publisher: Publisher<'a, ThreadModeRawMutex, ButtonMessage, 2, 3, 1>,
26
}

Now let’s add some helper methods to our Button implementation. These utility functions will make working with buttons more convenient:

• get_ids(): Extracts all button IDs from our button definitions into an array. This is useful when we need to know which buttons are available.

• check_ids(): Validates whether given button IDs actually exist in our configuration. This prevents us from trying to monitor non-existent buttons.

These helper methods establish a pattern we’ll use throughout: always validate inputs before performing operations. This defensive programming approach is especially important in embedded systems where runtime errors can be difficult to debug.

28
impl<'a> Button<'a> {
29
    /// Constructor
30
    ///
31
    /// * `item_info` - Button definitions
32
    pub fn new(item_info: ItemInfo) -> Result<Self, Error> {
33
        let button_pubsub_publisher = BUTTON_PUBSUB_CHANNEL.publisher()?;
34
        Ok(Self {
35
            item_info,
36
            button_pubsub_publisher,
37
        })
38
    }
39

40
    /// Get all IDs
41
    pub fn get_ids(&self) -> [u8; 1] {
42
        let mut ids = [0; 1];
43
        for (index, (id, _)) in self.item_info.iter().enumerate() {
44
            ids[index] = *id;
45
        }
46
        ids
47
    }
48

49
    /// Check if specified IDs are valid and within the pre-defined item info
50
    ///
51
    /// * `ids` - Item IDs to check. Empty ids array will return `true`
52
    pub async fn check_ids(&self, ids: &[u8]) -> bool {
53
        if ids.is_empty() {
54
            return true;
55
        }
56
        for id in ids.iter() {
57
            if !self.get_ids().contains(id) {
58
                return false;
59
            }
60
        }
61
        true
62
    }
63
}

Finally, we implement the Format trait from the defmt crate. This trait enables our Button struct to be printed using defmt::info!, defmt::debug!, and similar logging macros.

The implementation creates a human-readable representation showing all configured button IDs. For example, if we have buttons with IDs 1 and 2, it would format as: Button { Buttons: {ID: 1} {ID: 2} }. This formatting capability is invaluable during development and debugging.

55
/// Implement the `Format` trait for debugging
56
/// This allows us to print the struct with `defmt::info!` and friends
57
impl<'a> Format for Button<'a> {
58
    fn format(&self, f: defmt::Formatter) {
59
        defmt::write!(f, "Button {{");
60
        defmt::write!(f, " Buttons: ");
61
        for (id, _) in self.item_info.iter() {
62
            defmt::write!(f, "{{ID: {}}} ", id);
63
        }
64
        defmt::write!(f, "}}");
65
    }
66
}

Debouncing a Button Press

When you press a physical button, it doesn’t create a clean transition from HIGH to LOW (or vice versa). Instead, the electrical contacts inside the button physically bounce against each other for a few milliseconds, creating multiple rapid transitions. This “bouncing” can cause a single button press to be interpreted as multiple presses by our microcontroller.

Debouncing solves this by waiting for the signal to stabilize before accepting it as a valid state change.

You might notice that debounce_high_to_low() and debounce_low_to_high() are nearly identical. We could combine them into a single function with a parameter to specify the direction, but for this tutorial, we’re keeping them separate for two reasons: clarity and understanding.

28
impl<'a> Button<'a> {
29

30
    ....
31

32
    /// Debouncing button press - GPIO Level HIGH to LOW
33
    /// Debouncing is the process of removing noise from a button press signal.
34
    /// Returns when the button press signal is stable.
35
    ///
36
    /// * `id` - Button ID number
37
    async fn debounce_high_to_low(&mut self, id: u8) {
38
        let item = self.item_info.iter_mut().find(|(button_id, _)| *button_id == id);
39

40
        if let Some((_, handle)) = item {
41
            loop {
42
                let pin_level_1 = handle.get_level();
43
                handle.wait_for_low().await;
44
                Timer::after_millis(20).await;
45
                let pin_level_2 = handle.get_level();
46
                if pin_level_1 != pin_level_2 && handle.is_low() {
47
                    break;
48
                }
49
            }
50
        } else {
51
            warn!("Button with ID {} not found", id);
52
        }
53
    }
54

55
    /// Debouncing button press - GPIO Level LOW to HIGH
56
    /// Debouncing is the process of removing noise from a button press signal.
57
    /// Returns when the button press signal is stable.
58
    ///
59
    /// * `id` - Button ID number
60
    async fn debounce_low_to_high(&mut self, id: u8) {
61
        let item = self.item_info.iter_mut().find(|(button_id, _)| *button_id == id);
62

63
        if let Some((_, handle)) = item {
64
            loop {
65
                let pin_level_1 = handle.get_level();
66
                handle.wait_for_high().await;
67
                Timer::after_millis(20).await;
68
                let pin_level_2 = handle.get_level();
69
                if pin_level_1 != pin_level_2 && handle.is_high() {
70
                    break;
71
                }
72
            }
73
        } else {
74
            warn!("Button with ID {} not found", id);
75
        }
76
    }
77
}

Button Press Monitoring Loop

Now we come to the heart of our button module, the monitor_press() function. This is where everything comes together to create a complete button monitoring system.

This function runs a continuous loop in an async task, watching a specific button for press events.

One thing to point out here is the event publishing mechanism. When a complete button press cycle occurs (press down and release), we create a ButtonMessage containing all the relevant information. This message is then published through our pub-sub channel using button_pubsub_publisher.publish().

28
impl<'a> Button<'a> {
29

30
    ....
31

32
    /// Continuously watch specified button edge state and report button press.
33
    ///
34
    /// * `id` - Button ID number
35
    pub async fn monitor_press(&mut self, id: u8) -> () {
36
        if !self.check_ids(&[id]).await {
37
            error!("Failed to find specified Button ID in the pre-defined Button info");
38
            return;
39
        }
40

41
        let mut button_down_press_timestamp: Instant;
42
        let mut button_up_release_timestamp: Instant;
43

44
        loop {
45
            // Wait for button down press
46
            self.debounce_high_to_low(id).await;
47

48
            button_down_press_timestamp = Instant::now();
49
            info!(
50
                "Button ID {} down pressed! - Timestamp: {:?}ms",
51
                id,
52
                button_down_press_timestamp.as_millis()
53
            );
54

55
            // Wait for button up release
56
            self.debounce_low_to_high(id).await;
57
            button_up_release_timestamp = Instant::now();
58
            let release_time = button_up_release_timestamp.duration_since(button_down_press_timestamp);
59
            info!(
60
                "Button ID {} up released! - Timestamp: {:?}ms -> Time Difference: {:?}ms",
61
                id,
62
                button_up_release_timestamp.as_millis(),
63
                release_time.as_millis(),
64
            );
65

66
            // Publish the button press event message to channel
67
            self.button_pubsub_publisher
68
                .publish(ButtonMessage {
69
                    id,
70
                    timestamp_start: button_down_press_timestamp,
71
                    timestamp_end: button_up_release_timestamp,
72
                    press_type: PressType::RegularPress,
73
                })
74
                .await;
75
        }
76
    }
77
}

button/consumer_loop.rs

We will need a separate concurrent non-blocking async task whose sole purpose is simply to monitor the button press. All we are doing here is initializing/creating our Button struct, and calling its monitor_press() method with button ID 0. Remember, the monitor_press() method has an infinite loop within it.

1
//! Button module - Task manager module
2

3
use defmt::*;
4
use defmt_rtt as _;
5
use panic_probe as _;
6

7
use embassy_rp::gpio::Input;
8

9
use super::Button;
10

11
/// Async task - Button
12
/// Continuously monitor and report button press/release events
13
///
14
/// * `button_info` - Button information vector
15
#[embassy_executor::task]
16
pub async fn start_button_monitor(button_info: [(u8, Input<'static>); 1]) {
17
    info!("Running Button monitor async task ...");
18
    let mut button = Button::new(button_info).unwrap();
19

20
    button.monitor_press(0).await;
21
}

Note that this start_button_monitor() async task that we just defined will be called and spawned from our main.rs file.

button/mod.rs

Remember that whole Rust module section above? Well, this is where it comes into play. We will tie all of our button files into a Rust module within a new button/ directory.

After creating the button module directory, let’s add a mod.rs file within it. Within that file, add the following code.

1
//! Button module - Module definition - Responsible for handling system buttons
2

3
// Map all parts of this module
4
mod consumer_loop;
5
mod core;
6
mod messaging;
7

8
// Public re-export of specifics that are available outside of module
9
pub use consumer_loop::start_button_monitor;
10
pub use core::Button;
11
pub use messaging::{BUTTON_PUBSUB_CHANNEL, ButtonMessage, PressType};

Here’s what we’re doing: we’re declaring all the sub-modules (like core and messaging) that make up the button module using the mod keyword.

We use use to import items from the sub-modules into this scope. Then, we prepend pub to make those items publicly accessible outside the module. Anything not explicitly re-exported with pub use remains private and cannot be used outside of this button module.

main.rs

Now that all the pieces are in place, let’s use the button module and wire everything up in main.rs. We’ll create a button on GPIO pin 15, spawn it as an async task, and let it run alongside our state machine.

First, we will use use to include/import our new button module. This will allow us to start our async task start_button_monitor() that is defined in button/consumer_loop.rs.

In order to define our button, we need to know what physical Input PIN it’s connected to on our microcontroller, and also what Pull configuration it uses (pull-up or pull-down).

So effectively, our button definition tuple that we are passing to define our Button struct is this: [(<BUTTON_ID>, <PIN_INPUT>, <PULL_CONFIG), ...];

8 collapsed lines
1
#![no_std]
2
#![no_main]
3
#![allow(unused_variables)] // only used for development
4
#![allow(unused_imports)] // only used for development
5

6
use defmt::*;
7
use defmt_rtt as _;
8
use panic_probe as _;
9

10
use embassy_executor::Spawner;
11
use embassy_rp::config::Config as HalConfig;
12
use embassy_rp::gpio::{Input, Pull};
13
use embassy_time::Timer;
14

15
mod clocks_config;
16
use clocks_config::ClockSettings;
17
mod button;
18
mod state_machine;
19
mod utility;
20

9 collapsed lines
21
// Loading configurations
22
// Note: This comes from the 'configs.rs' file created in 'build.rs' from 'configs.json'
23
// Note: All loaded configurations will be UPPERCASE string slice (&str) constants
24
include!(concat!(env!("OUT_DIR"), "/configs.rs"));
25

26
// Loading obfuscated secrets (XOR_KEY and _OBFUSCATED constants)
27
// Note: Similar considerations as configurations
28
// Note: Load via utility.deobfuscate()
29
include!(concat!(env!("OUT_DIR"), "/secrets.rs"));
30

31
#[embassy_executor::main]
32
async fn main(spawner: Spawner) {
22 collapsed lines
33
    info!("==================================");
34
    info!("    Package: {} v{}", env!("CARGO_PKG_NAME"), env!("CARGO_PKG_VERSION"));
35
    info!("==================================");
36

37
    // Apply default clock configuration
38
    let mut hal_configuration = HalConfig::default();
39

40
    info!("Configuring all system clocks ...");
41
    let clock_settings = ClockSettings {
42
        xosc_crystal_hz: 12_000_000, // RP2350 uses 12MHz crystal
43
        system_frequency_mhz: CLOCK_SYSTEM_FREQUENCY_MHZ.parse::<u32>().unwrap(),
44
        usb_frequency_mhz: CLOCK_USB_FREQUENCY_MHZ.parse::<u32>().unwrap(),
45
        peripheral_clock_divider: CLOCK_PERIPHERAL_DIVIDER.parse::<u8>().unwrap(),
46
        adc_frequency_mhz: CLOCK_ADC_FREQUENCY_MHZ.parse::<u32>().unwrap(),
47
        reference_clock_divider: CLOCK_REFERENCE_DIVIDER.parse::<u8>().unwrap(),
48
    };
49
    clocks_config::configure_all_clocks(&mut hal_configuration, clock_settings);
50
    let peripherals = embassy_rp::init(hal_configuration);
51

52
    // Log and verify system clock frequencies
53
    clocks_config::print_device_frequencies();
54
    clocks_config::verify_clock_with_timer(500).await;
55

56
    // Button - Define and spawn async task
57
    let button_info = [(0_u8, Input::new(peripherals.PIN_15, Pull::Up))];
58
    spawner
59
        .spawn(button::start_button_monitor(button_info))
60
        .expect("Failed spawning button_consumer");
61

62
    // Spawn state machine async task
63
    spawner
64
        .spawn(state_machine::state_machine_task())
65
        .expect("Failed spawning state machine");
66

67
    info!("All Set! Running async loop ...");
68

69
    // General async loop to ensure entire program runs forever while
70
    // asynchronously working on other tasks
71
    loop {
72
        Timer::after_secs(5).await;
73
    }
74
}

Let’s Give it a Shot!

As always, in our terminal run the following command to compile our Rust code, send to the microcontroller, and run it.

cargo run --release

Let’s touch the two wires together… ummm, I mean press a button!

   ....
   Compiling big-button v0.1.0 (/home/you/projects/big-button)
    Finished `release` profile [optimized + debuginfo] target(s) in 0.77s
     Running `probe-rs run --chip=RP235x --log-format '[{t}] {[{L}]%dimmed%bold} {{f:dimmed}:{l:dimmed}%30}: {s}' target/thumbv8m.main-none-eabihf/release/big-button`
      Erasing ✔ 100% [####################]  12.00 KiB @  52.50 KiB/s (took 0s)
     Finished in 1.06s
[0.000510] [INFO ] main.rs:33             : ==================================
[0.000539] [INFO ] main.rs:34             :     Package: big-button v0.1.0
[0.000594] [INFO ] main.rs:35             : ==================================
19 collapsed lines
[0.000611] [INFO ] main.rs:40             : Configuring all system clocks ...
[0.000633] [DEBUG] clocks_config.rs:44           : PLL Config: 133 MHz -> refdiv=1, fbdiv=133, post_div1=6, post_div2=2
[0.000678] [DEBUG] clocks_config.rs:44           : PLL Config: 48 MHz -> refdiv=1, fbdiv=120, post_div1=6, post_div2=5
[0.000553] [DEBUG] clocks_config.rs:151          : Log Device Clock Frequencies:
[0.000564] [DEBUG] clocks_config.rs:152          : [Oscillators]
[0.000575] [DEBUG] clocks_config.rs:153          :   - ROSC (Ring Oscillator): 6500000 Hz
[0.000597] [DEBUG] clocks_config.rs:154          :   - XOSC (Crystal Oscillator): 12000000 Hz
[0.000616] [DEBUG] clocks_config.rs:156          : [PLLs (Phase-Locked Loops)]
[0.000627] [DEBUG] clocks_config.rs:157          :   - SYS PLL: 133000000 Hz
[0.000650] [DEBUG] clocks_config.rs:158          :   - USB PLL: 48000000 Hz
[0.000670] [DEBUG] clocks_config.rs:160          : [System Clocks]
[0.000683] [DEBUG] clocks_config.rs:161          :   - SYS CLK (System Clock): 133000000 Hz
[0.000707] [DEBUG] clocks_config.rs:162          :   - REF CLK (Reference Clock): 12000000 Hz
[0.000726] [DEBUG] clocks_config.rs:163          :   - PERI CLK (Peripheral Clock): 133000000 Hz
[0.000747] [DEBUG] clocks_config.rs:165          : [Specialized Clocks]
[0.000759] [DEBUG] clocks_config.rs:166          :   - USB CLK (USB Clock): 48000000 Hz
[0.000780] [DEBUG] clocks_config.rs:167          :   - ADC CLK (ADC Clock): 48000000 Hz
[0.500830] [DEBUG] clocks_config.rs:131          : [System clock frequency test] Actual: 500000 microseconds -> Measured: 500022 microseconds
[0.500873] [DEBUG] clocks_config.rs:143          : [System clock frequency test] Clock accuracy: 0.00% off
[0.500936] [INFO ] main.rs:71             : All Set! Running async loop ...
[0.500955] [INFO ] state_machine.rs:113   : Running State Machine async task ...
[0.500974] [INFO ] state_machine.rs:63    : [State: Startup - Event: PowerOn]
[0.501003] [INFO ] consumer_loop.rs:17    : Running Button monitor async task ...
[3.820456] [INFO ] core.rs:137            : Button ID 0 down pressed! - Timestamp: 3820ms
[3.966900] [INFO ] core.rs:147            : Button ID 0 up released! - Timestamp: 3966ms -> Time Difference: 146ms
[8.958494] [INFO ] core.rs:137            : Button ID 0 down pressed! - Timestamp: 8958ms
[11.69075] [INFO ] core.rs:147            : Button ID 0 up released! - Timestamp: 11690ms -> Time Difference: 2732ms

The logs show timestamps of the button down and button up events, and also the duration of the entire press. Here I touched the two “button” wires together one time quickly (short press - 146ms) and one time held together for a little while (long press - 2732ms).

Boom! How cool is that!?

If everything is good, git commit your changes and push to GitHub.com.