* docs: C-example for i2c
* docs: C-example for gpio
* feat: Mark Flex as unstable
* docs: Remove outdate fixmes
* fix: Clippy lint
* docs: Add time doc examples
* docs: Dont hide imports
* docs: Add link to Peripheral section
* docs: Avoid unsafe when posible
* feat: Generate api baseline
* Handle GPIOs as stable peripherals
* Define interrupts in create_peripheral
* Remove the rest of paste from the peripherals macro
* Move create_peripheral calls out of peripherals!
* Merge macros
* Merge peripherals files
* Delete the peripheral module
* Replace the peripherals macro with for_each generated code
* Do not generate code directly in GPIO metadata
* Update MSRV to 1.88
* Clean up lints
* Generate new baseline
* Bump MSRV of xtensa-lx-rt
* Do not try to replace in semver baseline, bump dependent msrvs
* Changelog
* Expand peripheral metadata
* Generate peripherals macro call
* Remove paste from peripherals
* Add missing peris
* Fix ETM and TRACE0 naming
* Remove redundant tsens symbol
* Remove RTCIO stuff from h2
* Rename S2 RTC_CNTL
* Add missing SYSCON back to S2
* Do not mark the GPIO singleton stable
* Treat unlisted drivers as not available
* Assign stability based on driver info
* Fmt
* Remove unused info
* Move ROM function definitions to esp-hal-rom crate
* Patch ESP32 ROM-functions, use it in esp-storage
* Allow placing additional code in IRAM
* esp-storage depends on esp-hal-rom
* Move ROM function wrappers from esp-hal to esp-hal-rom
* Make bootloader-support crate use CRC ROM function
* Minor polishing
* changelogs
* Make CI green
* Define (some) spiflash ROM functions in esp-hal-rom
* Lint
* Avoid duplicate definition of `__assert_func`
* Rename to `esp-rom-sys`
* Mention versioning this crate in the README
* Fixes
* Check self-version
* Docs
* Clippy
* Check if version bump is allowed
* Unconditionally place spiflash ROM function patches (if present) in rwtext
* Cleanup
* Change how unacceptable version bump requests are detected
* Initial version 0.1.0
* Docs
* Use correct version
* Force esp-rom-sys bumps to patch
* Fix
* feat: Add examples to Uart
* feat: Simplify doc examples based on review comments
* feat: Use `uart` as variable name and use UART0
* feat: Remove empty lines
* feat: Include initialization lines
* docs: Add general into_blocking/async examples
* Clean up esp-metadata a bit
* Update esp-metadata/src/cfg/gpio.rs
Co-authored-by: Juraj Sadel <jurajsadel@gmail.com>
* Document public API, arrange structs better
---------
Co-authored-by: Juraj Sadel <jurajsadel@gmail.com>
* RMT: make rmt::Error non_exhaustive
It probably should have been in the first place: It seems reasonable
that new variants might be added, such as in this patch series. The
Error enum also covers the entire RMT API (e.g. both rx and tx), such
that it's probably mostly not useful to match all variants anyway.
* RMT: remove spurious read of ch_tx_thr_event in rx code
esp32 and esp32s2 don't have ch_rx_thr_event, since they don't support
wrapping rx
* RMT: remove an unnecessary Iterator.take() that was a no-op
* RMT: Move some methods from (Tx|Rx)ChannelInternal to ChannelInternal
Adds a new `ChannelInternal` trait implemented on `Channel`s, which
bundles some methods that conceptually make sense for both rx and tx
channels (whether the implementation is exactly the same is
chip-specific).
This avoids a small amount of code duplication.
* RMT: Define input/output signals via a const array
Allowing a default implementation of the getter functions in the ChannelInternal
trait, and more importantly, paving the way for type-erased channels
(where it will become necessary to map Channel number to signal at runtime).
The array is indexed by ch_index, i.e. the index of the channel among
channels of the same type (for devices with separate rx/tx channels).
* RMT: move some `Sized` bounds from methods to trait
To avoid repetition. There's no downside, since the trait is only
implemented for a single type anyway, which is Sized.
These traits are user-visible, but since they can't be implemented by users,
and this only makes the bounds stricter, it should require not changes
to user code.
* RMT: Use composition with ConstChannelAccess, reduces macro usage
instead of an extension trait implemened via the impl_*_channel macros.
This reduces macro usage, making the code easier to reason about, and it also
paves the way for type-erased channels by adding a second implementation
of RawChannelAccess.
This touches many lines, but is a fairly mechanical change that should
be easier to review by ignoring whitespace changes.
Previously, channel architecture was as follows:
- `Channel` is parameterized by a const generic `CHANNEL: u8` number
- low-level hardware operations are implemented via the
*ChannelInternal traits directly on `Channel`. This is done via the
`impl_*x_channel` macros to account for the different channel
capabilities (rx/tx only or rx+tx)
This PR changes this to:
- `Channel` contains an `Raw: RawChannelAccess<Dir=Rx|Tx>` where `Rx`
and `Tx` are ZSTs used as markers for a channel configured for a given
direction.
- low-level operations are implemented on the `Raw` type, depending on
a bound on RawChannelAccess::Dir
- the `Raw` types can only be constructed safely from the
`ChannelCreator`, which ensures that only valid combinations of channel
number and `Dir=Rx|Tx` can exist.
- currently, the only implementation of `RawChannelAccess` is
`ConstChannelAccess`, which has a `CHANNEL: u8` const generic
parameter, just as `Channel` did before. Thus, the compiler should be
able to inline and const-propagate code just as before.
These new types are user-visible. Thus, if code directly names `Channel`
types, it needs to be adapted. If it just uses a method chain such as
`rmt.channelX.configure(...).transmit(...)`, no changes should be
required.
* RMT: rm (Rx|Tx)ChannelCreatorAsync, use mode generic on (Rx|Tx)ChannelCreator
this de-duplicates some code,
and may be useful to implement user code (e.g. setup functions) that is
independent of DriverMode
* RMT: Rewrite pending_interrupt_for_channel using indexed PAC accessors
This deduplicates some code. I've also changed the return type
(usize -> u8) for better consistency, since channel indices are generally
typed as u8.
* RMT: add DynChannelAccess as basis for type-erased channels
Channels can now be `degrade`d to their type-erased variants.
* RMT: Move around some code
The channel definition used to be somewhere in the middle of channel
implementation. There's no change to the code other than its location.
* RMT: slightly more readable subsclicing
* RMT: Move some chip-specific code to a cfg_if! switch
There's no reason for these to reside in separate modules, and this
restructuring meshes well with moving the Rmt definition to a macro as
well, which will be done next.
* RMT: Declare Rmt struct via macro to avoid repetition
Reduces boilerplate at the cost of a somewhat complex macro.
* RMT: Move RmtState
Which was previously in the middle of channel implementation, but
conceptually is more global to the module, thus more natural define
earlier.
* RMT: explicity mark a few private functions in submodule as pub(super)
* RMT: use DynChannelAccess::conjure to simplify async_interrupt_handler
If the compiler decides to unroll the loops, the resulting code should
be essentially the same. Otherwise, it should be more compact. In any
case, from a developer point of view, this is much more concise and
removes one chip-specific case.
* RMT: Use type-erased channels for some HIL tests
* RMT: don't reset clock divider in start_tx
This seems to fix flaky loopback tests where tx/rx pulse code length
differs by 1.
This matches IDF, which also doesn't reset channels on each transmit
operation, but only once on channel creation, and when a sync_manager is
used (which the Rust driver doesn't support, and which would also need
to be handled differently anyway).
* RMT: implement degrade() even if the channel is already type-erased
This makes wrapping channels in custom structs slightly more convenient
since it allows taking any channel and type-erasing it in that structs
constructor.
* RMT: rename (Rx|Tx)ChannelCreator methods to avoid trait disambiguation problems
For devices with channels that support both Rx and Tx, Rust cannot
disambiguate the trait at the call site (because it doesn't look at the
argument types to do so).
Renaming the methods avoids that. The alternative is to use
fully-qualified names to call the trait methods (i.e. left-side
turbofish), or to import the traits only in a limited scope. Both are
much more verbose than the _rx/_tx suffixes to method names.
* RMT: add basic async HIL test
* RMT: remove overcomplicated WithMode trait from tests
according to a suggestion by @bugadani
---------
Co-authored-by: Scott Mabin <scott@mabez.dev>
* Fix incorrect usage of MaybeUninit
* CHANGELOG.md
* Run tests in CI
* Address review comments
* Fix wrong path
* Less transmutes
* Don't use link_section on MacOS
* Fix a search+replace gone wrong
* Fix unaligned write buffer, make sure we test all relevant branches
* Fix
