umsh_ux_tracker/
lib.rs

1#![no_std]
2
3//! UX mechanism for tracker-class UMSH boards.
4//!
5//! This crate is the user-experience layer for boards whose physical
6//! UX is: one button, one status LED, one piezo buzzer, battery
7//! power, no display, no speaker, no keyboard. Both Seeed Studio
8//! SenseCap T1000-E and SenseCap Solar P1 fall in this class.
9//!
10//! The crate provides only **mechanism**, not policy:
11//!
12//! - [`button`] — recognize Single / Double / Triple / Long button
13//!   events from raw debounced edges + a monotonic-millisecond clock.
14//! - [`led`] — drive a single-LED heartbeat with one-shot sequences
15//!   layered on top (power-on, power-off, location-advert, …).
16//! - [`buzzer`] — play short tone melodies on a piezo buzzer with
17//!   silence-mode support.
18//! - [`power`] — vocabulary ([`PowerIntent`](power::PowerIntent),
19//!   [`PowerIntentSource`](power::PowerIntentSource)) shared by every
20//!   source that wants to take the device out of normal operation,
21//!   plus a [`LowBatteryDetector`](power::LowBatteryDetector) that
22//!   protects the Li-ion cell when no hardware undervoltage cutoff
23//!   exists.
24//!
25//! Policy (which event maps to which action, which CLI commands
26//! exist, how the MAC integrates) belongs in the consuming app
27//! crate, e.g. `umsh-app-ulcp-cli`.
28//!
29//! Devices in a different class (handheld with screen + speaker +
30//! keyboard, headless mesh nodes) need their own `umsh-ux-<class>`
31//! crate because the abstractions here — single-LED heartbeat,
32//! piezo-tone melodies, gesture-on-one-button — do not generalize
33//! meaningfully across classes.
34//!
35//! See `docs/firmware-architecture.md` for the broader BSP / UX / App
36//! / Binary layering.
37
38pub mod battery;
39pub mod button;
40pub mod buzzer;
41pub mod led;
42pub mod power;
43pub mod state;
umsh_ux_tracker/lib.rs

umsh_ux_tracker/
lib.rs
