Update and improve HAL library and docs
All checks were successful
Rust/va108xx-rs/pipeline/pr-main This commit looks good
All checks were successful
Rust/va108xx-rs/pipeline/pr-main This commit looks good
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/latest/atsamd_hal/gpio/index.html).
|
||||
//!
|
||||
//! This API provides two different submodules, [`mod@pins`] and [`dynpins`],
|
||||
//! representing two different ways to handle GPIO pins. The default, [`mod@pins`],
|
||||
//! This API provides two different submodules, [pin] and [dynpin],
|
||||
//! representing two different ways to handle GPIO pins. The default, [pin],
|
||||
//! is a type-level API that tracks the state of each pin at compile-time. The
|
||||
//! alternative, [`dynpins`] is a type-erased, value-level API that tracks the
|
||||
//! alternative, [dynpin] 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, [`dynpins`] can be used to erase the type-level differences
|
||||
//! If needed, [dynpin] 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.
|
||||
//!
|
||||
@ -101,10 +101,10 @@ macro_rules! common_reg_if_functions {
|
||||
};
|
||||
}
|
||||
|
||||
pub mod dynpins;
|
||||
pub use dynpins::*;
|
||||
pub mod dynpin;
|
||||
pub use dynpin::*;
|
||||
|
||||
pub mod pins;
|
||||
pub use pins::*;
|
||||
pub mod pin;
|
||||
pub use pin::*;
|
||||
|
||||
mod reg;
|
||||
|
Reference in New Issue
Block a user