Add GD32VF103 port #5449
Add GD32VF103 port #5449
Conversation
|
Can't comment on the addition of the port itself, but some of these commits would be good in any case. Note te convention is to have the commit header end with a dot, and form a gramaticaly correct sentence normally starting with a verb in the imperative tense so you might want to fix that. And maybe merge the 2 commits for -Wimplicit-fallthrough ? |
|
Cool. I'll fix the headers and merge the implicit fallthrough commits |
esmil
force-pushed
the
gd32vf103
branch
4 times, most recently
from
ad4ad4c
to
086dcab
Compare
|
Hi, I'm interested in this. Is this ready to be merged? |
|
Hi Samir, Thank you for your interest. Unfortunately our whole badge plan was thwarted by the pandemic, so I haven't looked at this since. But I've now updated my branch to the latest master, except for the travis parts. I'll play with those in a separate branch. I'll remove the [RFC] and see if we can get some more attention. There's still missing actual "drivers" for gpio and other peripherals though so you can't do much from python yet. Don't know if that is a requirement for upstreaming this.. |
|
Ok, now only the size test fails which I guess is because of the signed comparisons. That is IMHO a correctness fix. |
|
Rebased on #6510 |
|
Now with a machine.Pin module, so you can actually do something from python :) |
The function scope_find_or_add_id used to take a scope_kind_t enum and save it in an uint8_t. Saving an enum in a uint8_t is fine, but everywhere this function is called it is not actually given a scope_kind_t but an anonymous enum instead. Let's give this enum a name and use that as the argument type. This doesn't change the generated code, but is a C type mismatch that unfortunately doesn't show up unless you enable -Wenum-conversion.
mp_emergency_exception_buf_size is signed, so let's make sure we compare it as such.
On x86 chars are signed, but we're comparing a char to '0' + unsigned int, which is promoted to an unsigned int. Let's promote the char to unsigned before doing the comparison to avoid weird corner cases.
When compiling with -Wextra which includes -Wmissing-field-initializers GCC will warn that the defval field of mp_arg_val_t is not initialized. This is just a warning as it is defined to be zero initialized, but since it is a union it makes sense to be explicit about which member we're going to use, so add the explicit initializers and get rid of the warning.
Like Clang, GCC warns about this file, but only with -Woverride-init which is enabled by -Wextra. Disable the warnings for this file just like we do for Clang to make -Wextra happy.
Newer GCC versions are able to warn about switch cases that fall through. This is usually a sign of a forgotten break statement, but in the few cases where a fall through is intended we annotate it with this macro to avoid the warning.
MicroPython already includes its own implementation of memcpy, memmove, strlen, printf and other functions required to build without a C library. So use stddef.h for size_t since it is provided by the compiler, and leave out stdlib.h where it isn't needed and thus make it easier to compile MicroPython without a C library.
That is include assert.h in files where assert() is used, and don't include assert.h in files where it is not used.
We need to include limits.h for PATH_MAX among other things.
Use the defines from our stream.h rather than SEEK_CUR and SEEK_SET from the C library. This makes it possible to compile even when a C library is not available. We already rely on our own versions being equal to the C library versions in other places, so this shouldn't break any users.
This is useful to enable travis on your own github fork without having to create a coveralls.io account.
|
Sorry but this really went under my radar... looks interesting and will get to it after #6510 |
|
Thanks a lot for raising this PR. It's very interesting to have RISC-V support. It's not possible to yet say whether this would be merged or not, but some general points regarding a new port are (see eg #4557):
|
|
Hi |
Yes. there are many chips based on risc-v. And SHAKTI is an open source project developing risc-v based soft cores to run on fpga. There are many risc-v groups all around. SiFive development boards available. And shakti offers fpga based solution. There is a big competetion happnieng in india based on shakti processors. |
|
Ok, so just to answer for this particular port and not RISC-V in general:
No, unfortunately the GD32VF103 chips themselves are a bit hard to get outside of China. GigaDevice also produces GD32F103 ARM-based chips which are pin-compatible and API compatible with STM's STM32F103 chips, but not register compatible as far as I understand. My understanding is that GD32VF103 is basically the same, but with the ARM core replaced by a Chinese RISC-V implementation. So my guess is that international distributors are wary of selling these chips as they might get into trouble with STM.
Yes! seeedstudio.org sells many different boards by Sipeed with this chip. The cheapest is the Longan Nano for $4.90 that even comes with a small screen. You can even find it cheaper without the screen at other places that ships outside of China as well as other boards not designed Sipeed. However if you want to run this port be sure to get a board with the largest version of the chip with 128kB flash and 32kB sram. They're called GD32VF103xB for x in R, T, V or C depending on the packaging.
Yes! It is upstream in GCC. The README of my https://github.com/esmil/gd32vf103inator/ has some instruction on how to get it on various OSs.
I don't know what GigaDevice's plans are. Maybe someone who speaks Mandarin will be able to pick up news about this better than me.
Yeah, this is the most sticky point. I don't actually know how much I'll use this chip in the future and be around to maintain this port.
Everything in gd32vf104inator is BSD 3-clause, but the code in the port should be the same license as MicroPython. The gd32vf103inator code is based on headers from GigaDevice, so not something I can easily change.
I can definitely submit the preparatory patches to make it easier to compile MicroPython without newlib as a separate pull request. The reason I haven't done so yet, is just that nothing in the CI system checks that this continues to work.
Yeah if GigaDevice creates new versions of this chip maybe something like gd32v would be better. |
|
Is there any progress on this? I have couple Longan Nano and looking forward to have MicroPython on it. |
|
There has been no progress on this from my side. |
|
This is an automated heads-up that we've just merged a Pull Request See #13763 A search suggests this PR might apply the STATIC macro to some C code. If it Although this is an automated message, feel free to @-reply to me directly if |
Hi, I'm making badges for a danish hacker camp and this year we're planning on using this RISC-V chip from GigaDevice. It has a bit more flash compared to the HappyGecko we used to use, so I thought it'd be fun to see if I could make MicroPython run on it.
For now it passes all tests but micropython/extreme_exc.py, but I haven't yet implemented any "drivers" for peripherals and such. I thought I'd send an RFC in early and see if you'd be interesting in merging this upstream at some point.
Unfortunately riscv toolchains for bare-metal aren't yet available in most distributions, but cross-compilers for Linux seem to be. So I've made it so that this port can actually be compiled with such a toolchain without any standard library. MicroPython already comes with implementations of memset, memcpy, printf etc., which is cool, so it just needs a few little extra patches for this to work that I hope you're fine with.
I've ordered the commits such that the ones up to "travis: Compile test gd32vf103" are needed to make the port compile in travis. The rest are mostly just fixes for warnings that I get because I enabled a little more compiler warnings (-Wall -Wextra -Wno-unused-parameter).
In the future it would be nice to also add support for SiFive's HiFive1 board which is also emulated by Qemu, such that the tests can be automatically run on a RISC-V platform by travis.
/Emil