* Fix Async UART
The uart handler was `writing` to the enable register instead of
`modify`, which meant any wake would see the cleared enabled bit and
think the event had occurred. This wasn't seen before the split of uart
because it was only possible to listen to one thing at a time.
This PR also removes the ReadBufferFull error in favour of returning the
max bytes in the buffer.
The serial examples has been updated to actually have some cross task
communication.
* changelog
* fix dev deps
* Move SPI-related traits into their own preludes in the `spi` module
* Remove the `embedded-hal-async` trait re-exports and the `eh1` module from the prelude
* Update `CHANGELOG.md`
* Refactor the `spi` and `spi_slave` modules into a single `spi` module
* Update import paths in examples as needed
* Extract some common types from `spi::master` into the root `spi` module
* Fix imports in examples (again)
* Documentation fixes/improvements
* Remove unnecessary re-exports
* Update `CHANGELOG.md`
* Duplicate spi to spi_slave
* Restore spi
* Add barebones SPI slave mode, DMA only.
This setup allows registering buffers for future transactions the master
does (lowering cs, toggling sclk, and raising cs again). The transfer
struct returned from the registration API will complete its wait() or
return true from is_done() after cs has been raised.
Copied from spi.rs, so most of the changes are deleting code that
handles e.g. segmented transfers or synchronous operations.
Fix non-c3 devices' builds
* Limit spi_slave to non-pdma devices
* SPI slave DMA example
Ensure the API "feels" right.
Since there's no way to route GPIOs to other peripherals, we choose four
other wires and bit-bang SPI for the master side, relying on the person
running the example to connect the bus. This way we ensure the slave
code works, since we created the master ourselves.
Also, it's not really possible to use a second ESP device as the master
anyway: all the digital lines have glitches on startup, and those
glitches cause the slave's DMA engine to skip descriptors (it thinks
they're intended CS indicators); this causes it to lose data.
Then, fix the bitbang master (recording the progression here)
- When bitbanging, iterate the bits by "for _ in 0..8", instead of the
broken "for _ in [0..8]". The latter only runs the iteration once,
since there's only one list given ... and because the code uses _
instead of a real loop variable, type checking didn't save us.
- When bitbanging, send the bits out (and read them in) MSB first, since
that's actually how we have the slave configured.
* Add changelog entry
* Split DMA prepare_transfer into two fns.
The first does everything but write to the start bit and check for an
error. The second does those. We need 2 fns because the SPI slave needs
to start the transfer only after resetting the various afifo hardware
components (if it starts the transfer before, the first 8 bytes will be
lost when that reset happens).
Use the split fns everywhere.
Also split flush(). It needs to be pollable, so split it into one fn that
polls and one that waits until the poll returns clear. Also call the poll
fn from the is_done() fn, so we don't trample in-progress transfers.
* Make example code fill rx buffer before transfer
This way we can tell if it's ever touching certain bytes - 0xff is never
added to the master transmit buffer.
While I'm changing this, make the slave tx buffer never contain 0xff
either (go from 254 to 0).
---------
Co-authored-by: Jesse Braham <jessebraham@users.noreply.github.com>
* Make sure examples can build with defmt
* Remove duplicate example checks
* Fix examples
* Add changelog entry
* Actually build some examples with defmt feature enabled
* Add the defmt linker script in each package's build script
* 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
* Adding async support for RSA peripheral
* Add esp32 support (doesn't work properly yet)
* Xtensa chips are supported (except of esp32)
Add modular multiplication for esp32
Adding a CHANGELOG entry
Rebase issue fix
* Code cleanup
* Add `.await` on `RsaFuture::new()` calls
* Refactor and rebase
Made `read_results` functions to be `async`, got rid of `nb` usage
* Change API methods naming + refactor `start_step2` method
* Adjust example to the API change + documentation
* Code cleaning + refactoring
Update examples
* 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
* Ensure that uart is configured to account for clock changes, not just boot defaults
* fix examples
* changelog
---------
Co-authored-by: Jesse Braham <jessebraham@users.noreply.github.com>
* Add support for splitting esp32 uart into TX and RX
* Keeps existing API for uart, but wraps it in Tx and Rx sub-types
* Adds split() method similar to embassy-rs nRF/stm32/rp for getting indepdendent TX and RX
parts
* Implements e-h traits for TX and RX types
* Add esp32s3 example
* finish implementing
* rebase examples
* declare new examples
* fix fmt
* rebase on 0.12.0
* fix fmt
* fix fmt
* merge embassy_serial_split example with embassy_serial
* fix changelog
* fix changelog
* Rework watchdog timer drivers to allow enabling/disabling and feeding without traits
* Disable all watchdogs prior to `main` using the `__post_init` hook
* Update all watchdog-related examples
* Update CHANGELOG
* Address review comment
* Update a bunch of dependencies
* Implement `embedded-io` and `embedded-io-async` traits for USB Serial JTAG
* Implement `embedded-io` and `embedded-io-async` traits for UART
* Fix `embassy_serial` examples
* Update CHANGELOG
* Address review comments
* Use all remaining memory for stack(s)
* Remove HEAP related code from RISCV linker scripts
* Fix direct-boot / mcu-boot linker scripts
* Use a statically allocated stack for core-1
* Remove the old `pulse_control` driver
* Update `esp-hal-smartled` to use the new `rmt` driver instead
* Update the `hello_rgb` example for each chip
* Update CHANGELOG
* deep sleep api for esp32
* move to list of wakeup sources
* improve Ext0WakeupSource - still WIP
* add deep sleep with timer wakeup example
add Ext0 wakeup source (WIP/Non-working)
* removed alloc (using heapless now)
* Sleep: ext0 wakeup working
* add sleep_timer_ext0 example
* API change: move sleep into RTC as sleep, sleep_deep, sleep_light
* fix sleep examples for new API
* sleep only implemented for esp32 at this time
* sleep only implemented for esp32 at this time
* Implement a simple RTCPin trait to support sleep
* implement RTCPin for all xtensa SOC
* cargo fmt & update changelog
* fix change log order (accidentally swaped during rebase)
* implement Drop for Ext0WakeupSource
* added Ext1 wakeup source
* cargo fmt
* healpess was unused, removed
* fix pase macro usage
* Introduce a trait for DMA channels
This trait is then used to hold types related to the particular DMA channel. This change allows us to simplify user-facing types.
* Remove private type from I2s
* Remove redundant spi3 example, update examples
* Merge markdown sections
* Add changelog entry
* Add ROM MD5 definitions in linker and devices
* Add initial MD5 support
* Implement traits and add comments to MD5 module
* Add MD5 example to ESP32-C3
* Test MD5 context on the quick brown fox
* Implemenr From<Context> for Digest
* Add MD5 to the rest of the examples
* Add docs for MD5
* Remove #[repr(transparent)] from md5::Digest
* Update CHANGELOG.md
* 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>
* H2: Add initial i2s support and i2s_read and i2s_sound examples
* Add I2S_SCLK and I2S_DEFAULT_CLK_SRC constants for all chips
* Update I2S driver
* fmt
* Add changelog
* Change DIN GPIO17 to GPIO14 in ESP32 i2s_read example
* Use built-in LED pin (gpio2) in blinky example
Hi, I was just running the blinky example and noticed the comments about an LED
being connected to pin GPIO25. I was thinking it might makes more sense to use
the built-in LED pin instead, and no external hardware would be required.
* Add note on GPIO2 led
* Add GPIO2 LED pin change to changelog
For now, only the -c3.
---
Open up LEDC fade support to all chips.
The C6 chip needs some special handling because its fade registers also
handle gamma, and the ESP chip needs some special handling because it
has two banks of channels. The code to handle these is already present
in channel.rs, but needs to be copied and adapted. Do that, and drop
all the esp32c3 feature checks.
---
Add a function to poll the duty-fade state
Use the unmasked interrupt bit in the LEDC register block, since that
will get updated by the hardware whether or not we've connected anything
to the interrupt source. Also be sure to clear that bit before starting
a new fade, so it's always clear while fading.
This will allow dumb (non-async-code) polling of the fade state after
one is started by the start_duty_fade API.
---
Fix non-C3 devices to use the right int_raw bits
These are inconsistently named between the esp32 variants.
---
Add examples of hardware duty-cycle fading
Just a relatively simple zero to 100 and back to zero, over a total of 2
seconds, to get a breathing effect.
This does make the main loop{} have a 2-second period instead of the
current nearly-zero period, but nothing else is happening so that's
fine.
---
Fix two bugs in hardware fading
When figuring out how many duty-cycle changes need to happen per counter
overflow, we need to use the absolute value of the difference between
the start and end duty values, not the raw difference. When fading from
(e.g.) 100% to 0, this will overflow, and both the debug-mode panic and
the release-mode wrapping behavior give the wrong delta value.
So calculate an absolute value difference first, and use that.
Then, when running through the while loop that allocates bits between
pwm_cycles and duty_cycle, the check on pwm_cycles was wrong -- since
the value reduces each time through the loop, we need to keep looping as
long as it's *above* some threshold, not below.
---
Simplify and refactor duty-cycle fade code
I'm not sure if this will fix the extremely-short fade times that we're
seeing with the older code, but we'll see.
Move all the calculations out of the ChannelHW implementations, and make
those *just* set registers. The calculations are the same for all chip
variants, so don't need to be duplicated for each chip feature, like the
register macros are.
Change the calculations from a loop doing bit shifts, to an explicit
division and a couple of range checks. This way we can get a lot closer
to the requested percentages and durations.
Use the u32::abs_diff function instead of open-coding it (now that I see
it exists).
Use u16::try_from() to limit the range of values, and use try_into<u16>
and map_err and the ? operator to more clearly handle numbers out of
range.
Drop the Result<> return type from the ChannelHW function, as it can't
fail anymore.
Fix the duty_range value -- before, when duty_exp was (say) 8,
duty_range would be 256, and if one of the *_duty_pct values was 100,
the start or end duty value would be too big. The range of start and
end duty values is 0..255, so we have to subtract one to handle 100%.
Finally, add a comment on the is_duty_fade_running{,_hw} methods.
---
Some fades can't work; return errors for them.
Add a new Error enum value with a sub-error enum with more details.
Return it from the error cases in the fade method.
If the calculated cycles_per_step is more than 10 bits, fail as well;
the field in the register is only 10 bits wide.
Fix all the examples to run a 1-second fade instead of a 2-second, since
the 2-second fade will run into this error. (Assert that, as well.)
---
When fading on a -c6 chip, set two more registers
The gamma functionality of -c6 chips needs two more fields set. One
tells the chip how many gamma stages it should iterate through, but we
only implement linear fading, so always use 1. The other tells the chip
to latch the value of the other gamma registers into the chosen slot, so
even though its value never changes, the write needs to happen.
---
Add changelog entry
* 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
* implement fetching the rtc timer value in miliseconds and mircroseconds
* fmt cleanup
* add rtc_time examples
* get_time_raw/esp32: delay 1us between time update checks like esp-idf
* cargo fmt
* Initial async_{write|flush} implementations
- ESP32C3 + UART0 example
* Support UART1 & UART2
* Add examples for all chips
* reduce number of wakers depending on uart count
