Skip to content

Commit a5c522b

Browse files
committed
generic: add comment about the new design
The bit about redesigning could be removed after it's finished, but I'd leave the principles and maybe even add some information for aspiring contributors.
1 parent cbfb118 commit a5c522b

File tree

1 file changed

+32
-0
lines changed

1 file changed

+32
-0
lines changed

avr-hal-generic/src/lib.rs

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,38 @@
11
#![no_std]
22
#![cfg_attr(avr_hal_asm_macro, feature(asm_experimental_arch))]
33
#![cfg_attr(not(avr_hal_asm_macro), feature(llvm_asm))]
4+
//! Defines the internal API used to generate the per-device external API
5+
//! (user-facing) in the HAL crates.
6+
//!
7+
//! # Macro Design (WIP)
8+
//!
9+
//! As part of an effort to make the macros here more maintainable and less
10+
//! repetitive, they are being restructured module-by-module. Currently revised
11+
//! modules are:
12+
//! - [`adc`]
13+
//! - [`port`]
14+
//!
15+
//! The general guiding principals are:
16+
//! 1. What goes inside the macro invocation should look like regular code as
17+
//! much as possible;
18+
//! 2. Information related to groups of implementations of a feature should be
19+
//! encoded as alternative matchers in the macro, rather than by introducing
20+
//! many metavariables that each invocation will need to repeat;
21+
//! As an example of such information, take the ADC's reference voltage. All
22+
//! Atmega processors can be abstracted with the same definition of the
23+
//! `ReferenceVoltage` type, but Attiny processors differ among themselves and
24+
//! also from the Atmega implementation. Rather than leave that type up to the
25+
//! invocation, write one fully general matcher and write smaller matchers that
26+
//! expand to pre-filled versions of the former. The HAL crates then use these
27+
//! as much as possible, falling back only when there is singular hardware
28+
//! that would need its own matcher but would use it only once.
29+
//! 3. Information unique to each implementation should be left to the
30+
//! invocation, but make the macro smart enough to avoid repeating ourselves.
31+
//! An example of this is the mapping between ADC channels and pins. The best
32+
//! scenario here is a mapping like `<channel> = <pin>`, maybe `<channel>:
33+
//! <type> = <pin>`, if there's more information needed to encode the mapping.
34+
//! [`paste::paste`] can be used for gluing the information into adequate
35+
//! identifiers.
436
537
pub extern crate embedded_hal as hal;
638

0 commit comments

Comments
 (0)