Add basic Charlieplexing scan

[kienvo]

Hey, I just finished some basic initial code for the project.
There are some problems with the interrupt when using xpack's riscv-none-elf-gcc:

• The gpio interrupt handler only runs once
• The timer interrupt handler is so slow

Switching back to riscv-none-embed-gcc seems working, but the timer interrupt handler takes so much time that the main loop doesn't have enough time slice to execute.

Main changes:

• Generate code from SDK
• Add basic Charlieplexing scan

[fcartegnie]

I don't know if we are going to access non 4 bytes aligned offsets, but in that case, it will deref the wrong address

[kienvo]

There is no access to non 4 bytes aligned offsets. But I've just found pre-defined base address in the StdPeriphDriver; I'll use that instead.

[fcartegnie]

I see you just changed the code, so I guess you understood the issue with gpio_base being already uint32_t aligned

*(uint32_t *)(gpio_base + GPIO_PD_DRV) = *cfg;

[kienvo]

I had a workaround for that before the last change:

uint32_t b = (uint32_t)gpio_base; // <--here
*(uint32_t *)(b + GPIO_PD_DRV) = *cfg;

It seems kind of ugly but I changed to use pre-defined base address in the last change anyway.

[fcartegnie]

that is not matching coding style and unneeded

[kienvo]

that is not matching coding style and unneeded

Did you mean commit 817425b? It seem nonsense but for quick testing. I'll remove it here and add changing brightness feature in another PR. How do you think?

[fcartegnie]

Makefile changes

[kienvo]

Makefile changes

954f786
4cece4e
d812e56
208b854
Which one?

[fcartegnie]

Makefile changes

4cece4e

[kienvo]

What coding style do you suggest?

[kienvo]

I see many projects use the old style, but isn't it convenient to have this appending style? It could be

• turned on/off a flag by commenting out a line
• or add an end-line comment without affecting other flags.

[kienvo]

@fcartegnie if there is no other change I think it is time to get this PR merge.

[fcartegnie]

@fcartegnie if there is no other change I think it is time to get this PR merge.

You can't merge do & undos or fixs to those commits.

Please rebase -i and discard reverted and reverter code, and merge intra fix changes

[kienvo]

You can't merge do & undos or fixs to those commits.

Please rebase -i and discard reverted and reverter code, and merge intra fix changes

Then force push or should I make a new PR?

[fcartegnie]

You can't merge do & undos or fixs to those commits.
Please rebase -i and discard reverted and reverter code, and merge intra fix changes

Then force push or should I make a new PR?

use the force, luke

[fcartegnie]

unsure why we need to commit so much code / project template

[kienvo]

I could write a script to automatically download and generate StdPeriphDriver if this is considered as the optimal way.

[simon-budig]

Please keep StdPeriphDriver in the repository. I believe it would be a bad idea to have our repository depend on Code pulled in at build-time from an external source. That creates a dependency we don't want.

(admittedly I don't like the StdPeriphDriver code. I believe at some point we might want to fix/modify it. It is inconsistent within itself and has some stupid design descisions. Being able to fix it is an important reason to keep the code in our repository.)