riscv-rust / k210-pac

Peripheral access API crate (PAC) for K210 SoC, generated by svd2rust
29 stars 23 forks source link

Peripherals #1

Open Disasm opened 5 years ago

Disasm commented 5 years ago
burrbull commented 5 years ago

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

Disasm commented 5 years ago

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

burrbull commented 5 years ago

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

Disasm commented 5 years ago

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

burrbull commented 5 years ago

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

Disasm commented 5 years ago

@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 commented 5 years ago

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

Disasm commented 5 years ago

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 commented 5 years ago

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 (https://github.com/sipeed/LicheeDan_K210_examples/pull/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 commented 5 years ago

PRs exist for:

This leaves:

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

Disasm commented 5 years ago

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 commented 5 years ago

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

Disasm commented 5 years ago

No problem, I have three of these :smile: