Peripherals

[Disasm]

• CLINT CLINT (WIP needs 64-bit support in svd2rust) #16
• PLIC
• UARTHS
• GPIOHS
• KPU KPU #14
• FFT FFT #25
• DMAC DMAC #24
• GPIO
• UART1
• SPI{0,1,3}
• SPI2 (slave)
• I2S0
• APU APU #20
• I2C0
• FPIOA
• SHA256
• TIMER0
• WDT0
• OTP
• DVP
• SYSCTL
• AES
• RTC

[burrbull]

As I understand it, you pull them out from SDK?

[Disasm]

@burrbull SYSCTL and FPIOA were parsed from the SDK, but UARTHS and GPIOHS were taken from e310x with minimal changes.

[burrbull]

Попробую I2C набрать.

[Disasm]

@burrbull You can modify my script for this purpose. Automation makes process less boring and error-prone.

[burrbull]

DMAC has 64-bit registers. Is it normal? As I see, svd2rust doesn't support 64.

[Disasm]

@burrbull I'll try to figure out what to do with this, but if there is no way to declare 64-bit register, you can use two 32-bit registers with _lo and _hi siffixes or something like that.

[burrbull]

Are you sure that writing a half of register is safe? I'm not.

[Disasm]

I'm not sure either. I see at least one major problem: such half-accesses may be forbidden in hardware, but this behavior can be checked.

[laanwj]

DMAC has 64-bit registers. Is it normal? As I see, svd2rust doesn't support 64.

Ran into this too for the KPU (#14).

Are you sure that writing a half of register is safe? I'm not.

My experience is that it isn't. I don't know about 32 versus 64 bit but I ran into a problem where the C compiler would optimize accesses to 8-bit subfields of the FPIOA as byte writes which the hardware simply ignored (sipeed/LicheeDan_K210_examples#3).

Edit: also, I expect this to interact badly with FIFO-like registers such as the layer argument FIFO for the KPU. Writing both halves separately, if not ignored completely, would likely fill two slots in the FIFO.

[laanwj]

PRs exist for:

• DMAC DMAC #24
• APU APU #20
• CLINT (WIP needs 64-bit support in svd2rust) CLINT (WIP needs 64-bit support in svd2rust) #16
• KPU (WIP, needs 64-bit registers in svd2rust) KPU #14

This leaves:

• FFT
• SPI2 (slave)

and (but this one is going to be problematic as (AFAIK) no public documentation exists for it):

• OTP

[Disasm]

I have some reverse-engineering results for OTP, but they are far from usable at the moment. Maybe some experiments with it can give more information.

[laanwj]

I tried that for a bit but stopped short where I was afraid of bricking my chip 😄

[Disasm]

No problem, I have three of these 😄