Replies: 17 comments
-
In short, yes we are, there are tentative plans by @rleh to add the gd32vf103cbt6 target with the Sipeed Longan Nano Board since that has similar if not identical peripherals to STM32. However, regardless of the board we first need to implement RISC-V support, ie. There's a lot more detail in the ATSAM port issue here: #189 (comment) I suggest you hack something very minimal into place using whatever method you can get to work, and then we iterate over that, since this is a lot of specialized work and hard to describe for me what to do in detail. |
Beta Was this translation helpful? Give feedback.
-
Ah, you're from the DLR and using OUTPOST, so you already know lbuild pretty well. I would ignore modm-devices for now, since we're only adding one board/target, and there aren't a lot of RISC-V microcontrollers available yet, so the scaling isn't that much of an issue. Our custom device files are placed here. |
Beta Was this translation helpful? Give feedback.
-
I'm not quite sure if there should be a |
Beta Was this translation helpful? Give feedback.
-
I think my blissful ignorance of how RISC-V works is endless 🤦♂️ The users depend on the Don't worry too much about naming things, we'll figure it out on the way. |
Beta Was this translation helpful? Give feedback.
-
I think there are currently at least three RISC-V targets of interest:
Since only compilers and ISA seem to be common to the targets, I agree with @nesos opinion that an E31 variant of modm:platform:core module seems suitable. |
Beta Was this translation helpful? Give feedback.
-
I asked someone from SiFive about machine readable documentation for the E31 and they pointed me to this: https://github.com/sifive/freedom-e-sdk/tree/v201905-branch/bsp/sifive-hifive1-revb @salkinium Does your device file generator infrastructure support reading |
Beta Was this translation helpful? Give feedback.
-
Nope, because there is no code infrastructure for Device Tree outside of the linux kernel (not true, there is one in Zephyr). It's almost like it's not even a standard file format or something. 🙄 But of course it's probably not diffcult to hack something together. |
Beta Was this translation helpful? Give feedback.
-
So, on my quest to set up a minimal blinky example for the HiFive1 I came to the point where i got scons to tell which gcc to use. |
Beta Was this translation helpful? Give feedback.
-
Yes! Our fork is functionally slightly different and more up-to-date than the original DLR one. |
Beta Was this translation helpful? Give feedback.
-
At least it is more standardized than ST's custom XML stuff, right? Is there any other data that you need? Like a register map or similar? |
Beta Was this translation helpful? Give feedback.
-
Last time I looked, Device Trees (in general) are somewhat useless since the ones that exist are completely or partially written by hand and thus even if they are syntactically correct, they do not use the same names or even the same concepts for describing hardware. Similarly the CMSIS-SVD files are standardized, however their content and quality still strongly varies. A standard without sensible enforcement is utterly useless.
Memory sections, GPIO pinmux per package, and peripheral instances would be very good. |
Beta Was this translation helpful? Give feedback.
-
Okay, so I put together a minimal setup to get the HiFive1 running. The setup doesn't do much right now. It is barely more than the startup code and the linker script. But building the example lets the RGB LED light up white. The next steps for me now is to get interrupts and the clock module working so that the LED will actually blink |
Beta Was this translation helpful? Give feedback.
-
I'm currently implementing the clock module and stumbled upon a problem. As far as i understand it, the clock is meant to be driven by a 1ms timer. The E31 core does only have one timer interrupt that is driven by the "RTC" which is basically only a 64 bit timer. The problem there is, that this driven by an external 32.768 kHz crystal and fed to a counter and trigger an interrupt when it reaches a certain value. The setup looks something like this: Crystal --> Core Timer Counter --> Core Timer Interrupt With this setup I can't achieve a 1 kHz time base. Could that be a problem? Can I base the clock on a different time base instead? However I can imagine running on 1 kHz instead could cause some issues Edit: Okay never mind, it looks like the PWM peripheral is meant to be used as timers as well |
Beta Was this translation helpful? Give feedback.
-
Alternatively you could leave the timer free-running, and just do the conversion to ms on call to the But it's easier to use a different timer interrupt instead. |
Beta Was this translation helpful? Give feedback.
-
Oh, thanks for the hint. This is actually a bit easier as I can just read out the RTC Counter to calculate the time and don't need any interrupts. |
Beta Was this translation helpful? Give feedback.
-
The blinky example is now working with the HiFive1 board! You can have a look at it on my fork. |
Beta Was this translation helpful? Give feedback.
-
Do you want to open a Draft PR? That makes it easier to provide feedback and discussion. |
Beta Was this translation helpful? Give feedback.
-
Hey everyone,
I'm thinking about implementing platform support for the HiFive1 board. The board is a somewhat Arduino compatible board with a FE310 RISC-V microcontroller at its heart. You can find some information about the hardware here: https://www.sifive.com/boards/hifive1
I think it would be nice to support RISC-V and this board would be a nice platform to demonstrate this.
My question now is if you guys are interested in supporting RISC-V in general and this board in particular. I'd offer my help to implement the platform drivers.
Greeting, Ben
Beta Was this translation helpful? Give feedback.
All reactions