Stable driver: GPIO

[MabezDev]

As part of #2491, which has more details on driver analysis.

esp-hal API-GUIDELINE omissions

• Revisit: Private details should not leak into the public API, and should be made private where technically possible.
• parl_io uses InputConnection instead of PeripheralInput #2658
• PeripheralInput and PeripheralOutput are not sealed #2655
• Event, WakeEvent, Level, Pull, DriveStrength & AlternateFunction are missing #[non_exaustive] #2694
• Event, WakeEvent, Level, Pull, DriveStrength & AlternateFunction are missing derives #2695
• Pin drivers should take a Config struct instead of Pull or Level directly. #2696
• GPIO: The author must to use crate::any_peripheral to define the "any" peripheral instance type. #2707
• GPIO: The driver's constructor should take the config struct by value, and it should return Result<Self, ConfigError> #2708
• GPIO: If a driver implements both blocking and async operations, or only implements blocking operations, but may support asynchronous ones in the future, the driver's type signature must include a crate::Mode type parameter. #2709
• GPIO: Prefer compile-time checks over runtime checks where possible, prefer a fallible API over panics. #2710
• GPIO: Avoiding &mut self when &self is safe to use. #2711
• GPIO: If a driver only implements a subset of a peripheral's capabilities, it should be placed in the peripheral::subcategory module. #2712
• GPIO: If a common Instance trait is used for multiple peripherals, those traits should not have any logic implemented in them. #2713

---

Rust API guideline ommissions

• C-COMMON-TRAITS GPIO: Implement common traits #2664
• unwrap() in bind_default_interrupt_handler() and set_interrupt_priority() Double check usage of unwrap / panic #2657
• C-FAILURE: GPIO: C-FAILURE violation #2665
• GPIO C-HIDDEN violations #2697
• C-CUSTOM-TYPE: GPIO: C-CUSTOM-TYPE #2715

---

Hardware feature omissions

• Reading / writing multiple GPIO pins in one go #2652

---

Mode/features of the driver that are lacking

• Direct CPU GPIO access is not supported yet #2649
• Sigma-delta modulation driver #2370
• GPIO filter is not supported yet #2647
• Glitch filter is not supported yet #2648
• Using multiple GPIO interrupts is not supported yet (e.g. 4 on P4) #2650
• Hysteresis Config is not supported yet (e.g. for P4) #2651
• GPIO pin signal chaining (sig_in_func_X) #2700
• Overwritten default GPIO handler: currently no way to use async #2659
• Output, Input and others that wrap Flex should be #[repr(transparent)] #2698
• GPIO input synchronization options aren't configurable currently #2703
• GPIO inverter configuration is missing #2704
• GPIO Pin Hold is not supported #2705

---

Misc

• GPIO unstable items #2693
• Address GPIO FIXME's #2656
• It's possible to safely create pins "from thin air" #2653
• in init_output the condition to include the call to disable_usb_pads should be #[cfg(usb_device)]

[bjoernQ]

Currently unsupported HW features

• SDM
• GPIO Filter
• Glitch Filter
• Direct CPU GPIO Access
• Multiple Interrupts (e.g. INT0..INT3 on P4)
• Configure Hysteresis Functionality

[bjoernQ]

Modules we probably don't want to stabilize yet

• ETM
• LP_IO
• RTC_IO

[bugadani]

We also don't support reading/writing multiple GPIO pins at once, but I think that can be done with a separate driver that is initialized with multiple GPIO pins.

[Dominaezzz]

There's also the thing (on the S3 at least) where you can send the state of a GPIO pin to another one. It's done with the last 4 dummy signals in the signal table.

[bjoernQ]

There's also the thing (on the S3 at least) where you can send the state of a GPIO pin to another one. It's done with the last 4 dummy signals in the signal table.

You mean signal 252-255? Those are for dedicated GPIO / direct GPIO access by the CPU?