* Make sure connect_pin is not generic
* Allow Driver to access Config
* Implement bus clearing
* Explain that the first ever command needs to be a start
* Extract constant
* Fix bumping renamed packages
* Generate new baseline
* Print PR body if too long
* Extract and test version bump code
* Also handle simple dependencies
From a user's perspective, logic based on asynchronous ADC
functionalities using esp-hal v0.23 is no longer possible with
v1.0.0-beta.0. This is due to the fact that asynchronous traits used to
implement the latter are gatekept behind a module, called `asynch`,
accessible only to the esp-hal crate itself. As a result, users cannot
write generic logic that requires the implementation of such traits as
they are currently private.
See https://github.com/esp-rs/esp-hal/discussions/3441 for a concrete
example.
Co-authored-by: Juraj Sadel <juraj.sadel@espressif.com>
* Publish and tag based on release plan
* Update wording
* Update xtask/src/commands/release/execute_plan.rs
Co-authored-by: Juraj Sadel <jurajsadel@gmail.com>
---------
Co-authored-by: Juraj Sadel <jurajsadel@gmail.com>
* Execute plan
* Update plan
* dry-run by default
* dry-run version bumps
* Apply skip-changelog label as well
* cleany uppy
* xtask changes for CI doc generation
* Allow running documentation workflow for release PRs
* Build debug xtask
* Fix docs build for esp-config
* Push release PR to upstream
* Fix base url
* Fall back to default manifest if request is not a success
* Build all documentation regardless of its version
* Restore building landing page
* Build with the correct base url
* Avoid deploying the xtask
* Feature-gate documentation-index
* Add plan subcommand
* Skip binary files when replacing placeholders
* Specify the next step
* Make the plan ordered
* Prevent creating a plan that includes an unpublished crate
* Explain repo_dependencies
* Tweak plan comment
* Check branch during planning
* Tweak logs
* Hint about --allow-non-main
* Add HW and SW flow control option
* Fmt + warnings
* changelog entry
wrong unstable macro
* address reviews
* get away with using 1 pin only
* unnecessary function call
* Address reviews + use "byte" instead of misleading "character" (at_cmd)
* RMT: simplify/avoid a few cfg attributes
* RMT: factor address calculation into new function channel_ram_start()
* RMT: don't repeatedly read *ChannelInternal::memsize()
Moving this into separate variable greatly increases readability of the
code. It also avoids unnecessary repeated volatile reads of the
corresponding register.
* RMT: rework SingleShotTxTransaction offset calculation
This is not a big simplification yet, but will help will help with
simplifying the somewhat obscure `ram_index` calculation.
* RMT: rework SingleShotTxTransaction offset calculation, part 2
This removes the somewhat hard to parse
let ram_index = (((self.index - memsize) / (memsize / 2)) % 2) * (memsize / 2);
calculation, by resorting to the ping-pong method also used by the idf
code.
Importantly, even with the previous code, ram_index cannot in fact assume any
possible in-range value in channel RAM, but only either 0 or memsize / 2
(except at the end of a transaction, when there's no data left).
Thus we can update it via
ram_index = memsize / 2 - ram_index
such that will alternate ("ping-pong") between 0 and memsize / 2.
* RMT: error out on config.memsize == 0
* RMT: fix bogus cfg attributes
This is inside of a #[cfg(any(esp32, esp32s2))] block, so esp32s3 can
never happen: The result of nested cfg attributes was still correct, but
writing it like this doesn't make any sense.
* RMT: remove unnecessary integer literal type annotation
* RMT: remove spurious code from clear_interrupts()
- update() is known to be a no-op here
- For other chips, resetting pointers and setting mem_owner is not done
in clear_interrupts(), but in start_rx. clear_interrupts() is only used in
situations where either the channel was unused before (i.e. should be
stopped), or we explicitly called Self::stop() before. Thus, match
other chips here.
* RMT: clear mem_owner in start_tx
While I haven't seen this happen, it appears to be possible that one of
the subsequent channels (or even the current channel) was used for RX before.
Thus, ensure that mem_owner is set correctly for TX.
* RMT: small refactoring
There should be no functional change, but this should make it even more
obvious that the return value is exactly the number of codes written.
* RMT: in SingleShotTxTransaction, improve error handling
I haven't seen any error here in practise, but it seems that this could
have locked up in the `while !is_threshold_set()` loop before in case of
an error or early stop code in the data.
* RMT: avoid one register access
* RMT: update HIL tests to use wrapping and extended RAM
* RMT: address review regarding data-writing loops
Make the code less startling by performing writes to the hardware in a
more imperative style via the for-loop; slightly refactor slice
splitting.
* RMT: Update changelog
* Parse and update changelog on version bump
* Add check-changelog
* Fix changelogs
* Check changelog format in CI
* Fix log string
* Update readme
* Add tests, remove empty changelog groups
* RMT: Remove duplicate conditionals
The next check,
config.memsize > NUM_CHANNELS - T::CHANNEL
just below includes this case and exits with the same error.
* RMT: move chip-specific code to chip_specific modules
Moves configure_clock and clear_memsizes from Rmt methods to the chip_specific
sub-modules:
- configure_clock dispatches to functions from chip_specific anyway,
using the same #cfg attributes as the chip_specific module
- clear_memsizes also uses the same #cfg attributes, and it deals with
low-level register access, which is generally contained in the chip_specific
module
* RMT: small refactor of divider calculation using let-else
The same check as before, but slightly more concise, and getting rid of
the explicit cast.
* RMT: simplify is_memory_blocks_available and set_memory_blocks_unavailable
by removing unnecessary checks for special-case values that actually behave the
same as the general case that is handled in the loops
* RMT: merge is_memory_blocks_available and set_memory_blocks_unavailable
Both are only used in conjunction anyway.
There's a TOCTOU issue here: ChannelCreator is Send + Sync, so it can be
used from ISR context or on different cores for multicore targets.
This commit does not address that yet, but is a first step to fixing the
race condition, which would require making the check-then-modify atomic
(atomic per channel would probably be sufficient).
* RMT: move reserve_memory from trait to chip_specific module
Mainly, this also fixes incorrect indexig of ch_tx_conf0, ch_rx_conf0
for some chips (esp32s3, esp32c3, ...).
It also allows for some deduplication of the logic in reserve_memory.
Generally, since this function deals with the collection of all channels
rather than just a single one, it feels more natural to move it to the
module rather than the per-channel trait.
* RMT: avoid race condition via critical_section
This is not a great solution, but resolving this in a better way seems
to require more design work: The PAC crates don't seem to provide atomic
CAS operations on registers, thus it is not easily possible to reserve
the memory belonging to another channel than the current one without
causing a race condition: Another channel could be used to concurrently
reserve the same memory, either from an ISR context, or from another
core on multi-core chips.
* RMT: Release channel RAM on Channel drop
This should allow it to be re-used, either by other subsequent channels,
or by the initial channel if it was used for a non-'static lifetime and
is re-initialized.
* RMT: add global STATE and use it to control channel RAM access
Right now, this removes the use of critical_section previously
introduced as a stopgap solution to a race condition.
It will generally be useful to track state in a global static atomic for adding
fully interrupt-driven transfers later on.
* RMT: Fix regression form #3292 where tx transaction doesn't write
enough data
The idea is to fill half of the available RAM in on each threshold
event. Increasing the amount of available RAM in this calculation was
forgotten when adding support for extended channel RAM.
