atsamd_hal/gpio/
mod.rs

1//! # GPIO
2//!
3//! The GPIO module is used to configure GPIO pins through the
4//! [Port](crate::pac::Port) interface.
5//!
6//! ## Versions
7//!
8//! The inital GPIO API used a macro-heavy implementation, and it contained a
9//! few mistakes. The discussion in issue [#214](https://github.com/atsamd-rs/atsamd/issues/214)
10//! spurred the creation of a new module with fewer macros and a corrected,
11//! refactored API.
12//!
13//! The GPIO module has been completely rewritten (the `v2` module in
14//! pre-`0.15.0` HAL versions). The old module (`v1`) was removed in HAL version
15//! `0.15.0`.
16//!
17//! ## Features
18//!
19//! - Converting between pin modes no longer requires access to the `Port` type.
20//!
21//! As a consequence, pin mode conversions can now be implemented using
22//! [`From`]/[`Into`].
23//! ```
24//! let pins = Pins::new(peripherals.PORT);
25//! let pa08: Pin<PA08, PushPullOutput> = pins.pa08.into();
26//! ```
27//!
28//! - Defines a new [`AnyPin`] trait that can be used to simplify function
29//!   arguments and reduce the number of type parameters required when dealing
30//!   with GPIO pins. See the [`AnyPin`] documentation for more details.
31//!
32//! - Offers a type-erased, [`DynPin`] type, for run-time tracking of pins.
33//! - Provides a new [`bsp_pins`] macro to help BSP authors provide meaningful
34//!   names and type aliases for their GPIO pins.
35//!
36//! [`bsp_pins`]: crate::bsp_pins
37//!
38//! # Pin modules
39//!
40//! The API provides two different submodules, [`pin`] and [`dynpin`],
41//! representing two different ways to handle GPIO pins. The default, [`pin`],
42//! is a type-level API that tracks the state of each pin at compile-time. The
43//! alternative, [`dynpin`] is a type-erased, value-level API that tracks the
44//! state of each pin at run-time.
45//!
46//! The type-level API is strongly preferred. By representing the state of each
47//! pin within the type system, the compiler can detect logic errors at
48//! compile-time. Furthermore, the type-level API has absolutely zero run-time
49//! cost.
50//!
51//! If needed, [`dynpin`] can be used to erase the type-level differences
52//! between pins. However, by doing so, pins must now be tracked at run-time,
53//! and each pin has a non-zero memory footprint.
54
55pub mod pin;
56pub use pin::*;
57
58pub mod dynpin;
59pub use dynpin::*;
60
61mod reg;