* RISC-V executors
* Add multiprio example to RISC-V SoCs
* Check new examples
* Hack in support for generic queue
* Reserve SoftwareInterrupt0 for multicore thread-mode executors
* Merge interrupt executors
* Merge thread-mode executors
* Document the new features and expand on time drivers
* Main tasks don't have to return !
* Unify multiprio examples
* Undo C6 log output change
* Unify the system peripheral
Whilst the PCR, SYSTEM and DPORT peripherals are different, we currently
use them all in the same way. This PR unifies the peripheral name in the
hal to `SYSTEM`. The idea is that they all do the same sort of thing, so
we can collect them under the same name, and later down the line we can
being to expose differences under an extended API.
The benifits to this are imo quite big, the examples now are all identical,
which makes things easier for esp-wifi, and paves a path towards the
multichip hal.
Why not do this in the PAC? Imo the pac should be as close to the
hardware as possible, and the HAL is where we should abstractions such
as this.
* changelog
* No longer publicly expose the `PeripheralClockControl` struct
* Update examples as needed to get things building again
* Update CHANGELOG.md
* Address review feedback, fix a warning
* Use a critical section for all devices other than the ESP32-C6/H2, as they modify multiple registers
* Rebase and update `etm` driver to fix build errors
* Create issue_handler.yml
* No longer re-export `embedded-hal`, hide exported macros in documentation
* Add simple package-level documentation for each HAL package
* Clean up/simplify re-exports
* Fix the examples that I broke
* Ensure top-level modules/types/functions have doc comments
* Update CHANGELOG
* Re-export the `soc::psram` module where available
---------
Co-authored-by: Sergio Gasquez Arcos <sergio.gasquez@gmail.com>
* Small refactor to extract functions for setting up reads/writes
* Implement async capabilities for `I2C` driver
* Add async I2C examples for each supported chip
* Update CHANGELOG
