* RISCV interrupt vectoring
- Adds support for vectoring peripheral interrupts to PAC handlers
- Currently supports level interrupts with priorities from 1-15
- Updated the gpio interrupt example to reflect the new changes
* remove .vscode files
* Support vectored edge interrupts
This is as simple as making sure we clear the CPU interrupt whenever we
receive one. This also documents further what APIs are safe to call when
the `vectored` feature is enabled.
* fix all examples to use vectoring
* doc & cleanup
* run handlers from ram
* make xtensa::interrupt::vectored private, we rexport public items
* fix default handlers
* pass interrupt into EspDefaultHandler
* Xtensa interrupt vectoring: peripheral source
- Initial Xtensa vectoring, updated esp32 gpio example to use new interrupt macro.
- Only peripheral sources supported.
- Only level one priority supported.
- CPU & Edge interrupts still need to be handled.
* Xtensa interrupt vectoring: CPU & EDGE
- Add support for handling CPU interrupts and edge interrupts
- PR required to xtensa-lx-rt for CPU handlers
* Xtensa interrupt vectoring: Priority
- Finally implement priortization
- Only three priorities available at the moment. Xtensa programmer guide
discourages using highpri interrupts in Rust/C. Guide also mentions
using software priortization to increase the number of Priorities
available
* support CPU interrupts, using patch xtensa-lx-rt
* Update example
* Add support & examples for the s2 & s3 too
* Fix formatting and missing imports
* Run interrupt handling in ram, optionally run the vector handler in ram in the examples
* Use xtensa_lx::Mutex CS when enabling interrupts
* Run clippy on each target
* Remove redundant features
* Fix C3 builds
* make enable unsafe. Add note about preallocated interrupts in vectored mode.
* Remove `INTERRUPT_LEVELS` static
The interrupt levels static introduces a few issues
- A lock is needed when configuring interrupts to keep
INTERRUPT_LEVELS in a consistent state
- Interrupts enabled from outside the Rust domain wouldn't be
serviced, this is the case with the wifi blobs
To remove it, the prioty configuration is now calculated dynamically in
the interrupt handler. Essentially INTERRUPT_LEVELS is now created once
the interrupt triggers. It has some benefits, such as only having to
look at interrupts configured on the current core, not both, but there
is of course an overhead with doing this in the interrupt.
* Allow raw interrupts on levels 4-7, whilst also supporting vectoring on levels 1-3
* rename core number features
* Fix examples and formatting
* use xtensa-lx-rt release, update pacs
* Support passing the trap frame into interrupt handlers
* cfg away the #[interrupt] macro when not using vectoring
* rename enable to map
move vectored feature to chip specific hals
* export vectored functions
- rename `enable_with_priority` to `enable`
- add docs for interrupt macro
* Update all examples to use vectored interrupts
* Add direct-boot support for ESP32-S3
* Make sure to use correct alignments
* Only enable naked_functions and asm_experimental_arch when direct-boot feature is selected
* initial systimer impl
* Add systimer example
* Make Alarms real singletons
* Remove runtime Option, turn into compile error
* Make Systimer::now() not take self
* refactor shared alarm methods
* Implement esp32c3 delay with monotonic SystemTimer::now()
* Add extend systimer support to esp32s3 and add example
* systimer: esp32s2 support
* Use fugit time types for SPI peripheral, update examples
* initial WIP
* fix CI build errors
* Use extension trait in examples
Co-authored-by: Jesse Braham <jesse@beta7.io>
- Add RMT output channel support for ESP32, ESP32-S2, ESP32-S3, ESP32-C3
- Add add RMT adapter for `smart-leds` crate
- Add example `hello_rgb` for ESP32-S2, ESP32-S3 and ESP32-C3 that either
drives one LED at the pin where a LED is located on the official devkits
- Add example `hello_rgb` for ESP32 that is driving a 12-element RGB ring.
