The Maixduino has 2 CPUs, a ESP32 WROOM and a Dual Core RISC V Kendryte k210. So when using the platformio which chip am I uploading to ? Which toolchain is being used ? I’d like to write some bare metal RISC V, and was hoping to use the k210.
Thanks
If you are using the board definition as here, then, as PlatformIO tells you at the start of the compilation,
CONFIGURATION: https://docs.platformio.org/page/boards/kendryte210/sipeed-maixduino.html
PLATFORM: Kendryte K210 (1.2.4) > Sipeed MAIXDUINO
HARDWARE: K210 400MHz, 6MB RAM, 16MB Flash
DEBUG: Current (iot-bus-jtag) External (iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, sipeed-rv-debugger, tumpa)
PACKAGES:
- framework-kendryte-standalone-sdk 0.5.6
- toolchain-kendryte210 8.2.0
LDF: Library Dependency Finder
[..]
riscv64-unknown-elf-gcc -o .pio\build\sipeed-maixduino\src\main.o [...]
you will be using a GCC 8.2.0 toolchain targeting the RISC-V 64 core of the K210 MCU.
FYI, the toolchain files are in C:\Users\<user>\.platformio\packages\toolchain-kendryte210 by default.
Of course it’s also possible to reprogramming the ESP32’s firmware, see here and schematics. The way I see it, there is a 2-channel USB-serial converter on the board, so you can actually program the ESP32 easily, if it is needed. The default firmware is this which exposes the WiFi functionality to the K210. There are example applications for this.
If you mean bare-metal in the truest sense, i.e. no helping headers, frameworks, not even startup code for the MCU etc, that is also possible. In PlatformIO, you can do a baremetal project by removing the framework = ... line from the platformio.ini. Then only the sources in src/ and lib/ will be compiled in the firmware, with the default settings.
Sadly there is no baremetal example available in the platform, like it is for atmelavr, You will also notice that when you write a simple
[env:sipeed-maixduino]
platform = kendryte210
board = sipeed-maixduino
and a src\main.c of just
int main() {
return 0;
}
you will run into
Linking .pio\build\sipeed-maixduino\firmware.elf
c:/users/max/.platformio/packages/toolchain-kendryte210/bin/…/lib/gcc/riscv64-unknown-elf/8.2.0/…/…/…/…/riscv64-unknown-elf/bin/ld.exe: warning: cannot find entry symbol _start; not setting start address
Which means that the compiler does not even provide a default startup script (and linker script) for you.
In the simplest SDK, GitHub - kendryte/kendryte-standalone-sdk: Standalone SDK for kendryte K210, that is done with crt.S, entry_user.c and also syscalls.c (which handles traps etc.). It also uses this linkerscript.
I’ve setup an unverified starting example at GitHub - maxgerhardt/pio-maixduino-baremetal: A starting point for implementing bare-metal application for the K210 RISC-V MCU on a maixduino board which compiles and changes some implementation details compared to the kendryte SDK if you are interested. Without a JTAG debugger however it may be nearly impossible to debug or develop further, if something low-level goes wrong.
I would say however that programming with the https://github.com/kendryte/kendryte-standalone-sdk sufficiently bare-metal in the sense that the SDK does just enough to get both cores up and running with some initialization and then you can chose to use the other provided libraries or not.
@maxgerhardt - thanks for all the info. Brilliant answer and full of details that would’ve taken me ages to write in here.If I can get the JTAG hooked up to the k210 (from your help on the other post) then I will get some RISC V code written. By bare metal I meant running code without an RTOS, if I could I would be writing the first immutable code, and initializing the chip myself, but if there is a c lib I’ll take that. Thanks again for the useful links to get be a template for a project, and how to configure the ini ! If I get anywhere I’ll post a how-to somewhere.