* 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>
This is temporary measure, as the problem cannot be solved cleanly right
now.
The issue is that the msrv check uses the stable compiler, which uses a
stable cargo. With a stable cargo, the unstable `build-std` option is
not respected within `.cargo/config.toml`. This means `core` is never
rebuilt with the atomic cfg flags so we get this error when building log
version 0.4.19. The 0.4.19 release uses the atomic cfg flags instead of
a custom build script, so by switching back to 0.4.188888888 we can avoid this
issue... for now at least.
* 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
* First README prototype
* README update
Fixed link, uncommented Matrix link, made some preparations before docs will be posted
* Added a change to CHANGELOG
* typo: return header sign back
* Process Fosc frequencies for ECO1+ ESP32C6 chips
e3148369f3
* Final update for FOSC calibration (ESP32C6)
+ fixed few errors
* Fix format + add update to Changelog
Formatting
Formatting (1)
* First README prototype
* README update
Fixed link, uncommented Matrix link, made some preparations before docs will be posted
* Added a change to CHANGELOG
* typo: return header sign back
* 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
* H2: Use PLL_48M_CLK in Timg driver and add imer_interrupt example
* Clean timer driver, add helper configure_src_clk and configure_wdt_src_clk methods
* H2: Add imer_interrupt example
* add helper methods for selecting default clk src
* Change PR number in the Changelog
* Add efuse field tables from IDF
* Add efuse fields constants generator
* Fix MAC field in efuse tables
* Add common efuse field impl
* Add efuse fields support for chips
* Add efuse changes to changelog
* Async GPIO multibank fix
- Removes dead code from the default impl of the BankAccess trait
- Adds one new function to the async module to control the interrupt
enable for any pin
* Add changelog entry
* Simplify the `Delay` driver, derive `Clone` and `Copy`
The RISC-V and Xtensa implementations of the delay functionality are both safe to access from multiple contexts, and the `Delay` struct does not take ownership of any peripheral struct, so `Delay` is safe to clone/copy
* Update the CHANGELOG
* Update the `GDMA` driver to support the ESP32-H2
* Update the `SPI` driver to support the ESP32-H2
* Add `SPI` examples for ESP32-H2
* Update CHANGELOG
* Remove copy-pasted references to ESP32-C6
* Update GPIO pins used in SPI examples, add `qspi_flash` example
* Update SPI clock configuration to produce correct clock rate
* Correct comment regarding clock source frequency
Co-authored-by: Sergio Gasquez Arcos <sergio.gasquez@gmail.com>
* H2: Add PLL_48M_CLK src to ClockControl and RawClocks
* H2: Use PLL_48M_CLK as SPI clk src
* H2: cleanup commented block in SPI driver
* H2: update docs comment in embassy_spi example
* fmt
* Add a new line in embassy_spi example
---------
Co-authored-by: Sergio Gasquez Arcos <sergio.gasquez@gmail.com>
Co-authored-by: Juraj Sadel <juraj.sadel@espressif.com>
* feat: relocate riscv isr to iram
Previously, the trap vector itself and its immediate callees
(`_start_trap` and `_start_trap_rust_hal`) were located in the mapped
instruction flash range `0x420..`, increasing cache pressure and adding
variable latency to the very beginning of the interrupt/exception
service flow.
This change places those routines in iram directly:
```
Num: Value Size Type Bind Vis Ndx Name
48177: 40380280 2428 FUNC GLOBAL DEFAULT 6 _start_trap_rust_hal
48197: 40380bfc 54 FUNC GLOBAL DEFAULT 6 _start_trap_rust
48265: 40380200 0 FUNC GLOBAL DEFAULT 6 _vector_table
48349: 40380100 0 NOTYPE GLOBAL DEFAULT 6 default_start_trap
48350: 40380100 0 NOTYPE GLOBAL DEFAULT 6 _start_trap
```
As seen via `readelf -W -s -C ./target/riscv32imc-unknown-none-elf/debug/examples/gpio_interrupt | grep -E _start_trap\|_vector\|Ndx`
* feat(riscv): place .trap in RAM
This change follows through on relocating the `_vector_table`,
`_start_trap`, and `_start_trap_rust` functions for all present
build/link modes for the 'c2, 'c3, 'c6, and 'h2.
It has been tested by running the `software_interrupts` example for the
'c3 in direct-boot and esp-bootloader contexts, but I wasn't able to
identify how to run the `mcu-boot` mode for the 'c3, nor do I have
present access to any of the other devices for testing.
* docs: Update CHANGELOG.md
