esp32c5: expose LEDC gamma RAM peripheral#397
Conversation
| CH_GAMMA_RANGE%s: | ||
| description: LEDC gamma fade configuration RAM entry %s. | ||
| addressOffset: 0x0 | ||
| dim: 96 |
There was a problem hiding this comment.
Where does this 96 come from? The TRM defines a 64 byte memory block, and esp-idf uses it as an array of 16 entries.
There was a problem hiding this comment.
Yep - per channel.
The TRM’s 64-byte block is one channel (16 x 32-bit entries). ESP32-C5 has 6 LEDC channels, so the gamma RAM window is 6 * 16 = 96 entries (0x180 bytes) starting at DR_REG_LEDC_BASE + 0x400.
In the SVD patch I flattened the 2D [channel][range] layout into a single dim array; index = channel * 16 + range. Happy to restructure it into a 6x16 cluster layout if you’d prefer.
Add the LEDC_GAMMA_RAM peripheral at 0x60007400 and model all 96 gamma range entries with typed duty fields. This provides PAC-level access needed by esp-hal to configure C5 hardware fades without raw MMIO offsets.
Match the hardware layout (channel[6].entry[16]) so downstream HAL code can use typed channel/range access without manual index math.
Veanir
force-pushed
the
fix/esp32c5-ledc-gamma-ram-pac
branch
from
2a4bc63 to
5a505fa
Compare
| size: 0x180 | ||
| usage: "Registers" | ||
|
|
||
| LEDC_GAMMA_RAM: |
There was a problem hiding this comment.
This shouldn't be its own peripheral, but a register block under LEDC, I think? Similar to how ECC and the other crypto drivers define their own little memories.
2 participants
Summary
LEDC_GAMMA_RAMon ESP32-C5 at0x6000_7400, but model the RAM with hardware structure instead of a flattened arrayCHANNEL%scluster (dim: 6,dimIncrement: 0x40) with per-channelENTRY%sregisters (dim: 16,dimIncrement: 0x4)channel(n).entry(m)access rather than manualidx = ch * 16 + rangeVerification
svdtools patch esp32c5/svd/patches/esp32c5.yaml /tmp/esp32c5-pr-validate.svdcargo run -p xtask --target x86_64-unknown-linux-gnu -- generate esp32c5xtask run tests esp32c5 --test ledc --toolchain nightly --repeat 3(all passes)