smaller tweaks and updates
This commit is contained in:
@ -3,10 +3,10 @@
|
||||
//! The implementation of this GPIO module is heavily based on the
|
||||
//! [ATSAMD HAL implementation](https://docs.rs/atsamd-hal/0.13.0/atsamd_hal/gpio/v2/index.html).
|
||||
//!
|
||||
//! This API provides two different submodules, [`pin`] and [`dynpin`],
|
||||
//! representing two different ways to handle GPIO pins. The default, [`pin`],
|
||||
//! This API provides two different submodules, [`pins`] and [`dynpins`],
|
||||
//! representing two different ways to handle GPIO pins. The default, [`pins`],
|
||||
//! is a type-level API that tracks the state of each pin at compile-time. The
|
||||
//! alternative, [`dynpin`] is a type-erased, value-level API that tracks the
|
||||
//! alternative, [`dynpins`] is a type-erased, value-level API that tracks the
|
||||
//! state of each pin at run-time.
|
||||
//!
|
||||
//! The type-level API is strongly preferred. By representing the state of each
|
||||
@ -14,7 +14,7 @@
|
||||
//! compile-time. Furthermore, the type-level API has absolutely zero run-time
|
||||
//! cost.
|
||||
//!
|
||||
//! If needed, [`dynpin`] can be used to erase the type-level differences
|
||||
//! If needed, [`dynpins`] can be used to erase the type-level differences
|
||||
//! between pins. However, by doing so, pins must now be tracked at run-time,
|
||||
//! and each pin has a non-zero memory footprint.
|
||||
//!
|
||||
|
Reference in New Issue
Block a user