* adc_cal: c2: Add efuse functions for reading calibration
* adc_cal: c3: Add efuse functions for reading calibration
* adc_cal: c6: Add efuse functions for reading calibration
* adc_cal: Add extra traits to support calibration
- `AdcCalScheme<ADCI>` implemented for each calibration scheme (basic, linear, curved)
- `AdcCalEfuse` implemented for each ADC unit to get calibration data from efuse bits
* adc_cal: Add basic ADC calibration scheme
Basic calibration is related to setting some initial bias value to ADC unit.
Such values usually is stored in efuse bit fields but also can be measured
in runtime by connecting ADC input to ground internally.
* adc_cal: Add line fitting ADC calibration scheme
This scheme also includes basic calibration and implements gain correction based
on reference point.
Reference point is a pair of reference voltage and corresponding mean raw ADC
value. Such raw values usually is stored in efuse bit fields for each supported
attenuation.
Possibly it also can be measured in runtime by connecting ADC to reference
voltage internally.
* adc_cal: Add curve fitting ADC calibration scheme
This scheme also includes basic and linear and implements final polynomial error
correction.
* adc_cal: riscv: Add ADC calibration implementation for riscv chips
* adc_cal: c2: Add calibrated ADC reading example
This example uses line fitting calibration scheme by default.
It periodically prints both raw measured value and computed millivolts.
* adc_cal: c3: Add calibrated ADC reading example
This example uses curve fitting calibration scheme by default.
It periodically prints both raw measured value and computed millivolts.
* adc_cal: c6: Add calibrated ADC reading example
This example uses curve fitting calibration scheme by default.
It periodically prints both raw measured value and computed millivolts.
* adc_cal: riscv: Add changelog entry for ADC calibration
* 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>
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
