A new kid on the block? 2021-12-08
Geen categorie
0 Comment

Browsing AliExpress, I notice a new offer. A microcontroller board with a price tag that reminds of pre-silicon-crisis prices. This board has a WinnerMicro W806 microcontroller. I am not familiar with this brand, and curious what this is. It ain’t no ARM Cortex-M microcontroller. It’s neither a RISC-V microcontroller. This is an architecture I’ve not heard about before: C-SKY. Anyhow, I’ve ordered a couple last week, so I am expecting them to arrive beginning of the next year.

Well… what is this beast? CNX software covered this board last month. Even though it is a brief mention, it got a link to an SDK. Some call it SDK, others Peripheral Library. Whatever you like to call it, the drivers for the peripherals are in there. That is one of the things we’ll need if we want to write a firmware for this thing.

As this is yet another architecture… we need a compiler for the thing. Where to find that? Well… it seems, there is something in AUR. That turns out to be a rather old compiler, it’s a GCC 6. But hey, it seems c-sky support is upstreamed, so let’s build a GCC 11 compiler for this architecture instead.

How to approach that? I’m kinda lazy, I look the PKGBUILDS for the arm-none-eabi toolchain, and replaced the target

_target=csky-none-elf
#_target=arm-none-eabi

as simple as that. Does it work? It does for binutils. That’s also what I used to determine it should be called csky-none-elf, rather then csky-abiv2-elf used by that binary distro I mentioned before.

In binutils-2.37/bfd/config.bfd it says

  csky-*-elf* | csky-*-linux* )
    targ_defvec=csky_elf32_le_vec
    targ_selvecs="csky_elf32_be_vec csky_elf32_le_vec"
    ;;

So our triplet needs to match. As we are not looking for a linux, we should go for the elf. Thus something like csky-none-elf would do.

As for newlib and gcc, there is a circular dependency. This is the headache bootstrapping a cross-compiler is. That’s why tools like buildroot exists, even though that targets hosted environment (with operating system), while what we are looking at here is a freestanding environment (without operating system, bare metal). Oh well… we have that binary distribution, so we don’t need to go through the hassle of bootstrapping a cross compiler, we can use the gcc from the binary distribution to compile our newlib to compile our gcc.

The compiler is still being compiled. But I don’t expect much trouble there, and even if it fails, we got that old GCC 6. That ain’t what is troubling me about being able to use those boards I’ve ordered. What I am concerned about is it looks like there is no debugger support. When I looked at OpenOCD, I saw it mentioned the WinnerMicro W6xx series. And what I’ve ordered is the W806. So, that’s a different family, it seems the W6xx series are ARM Cortex-M. So, it looks like, there is no debugger support for this thing. That might be a problem, making those boards useless.

There is an USB UART chip on that thing. I suppose they can be used to load a firmware on the board, but that means debugging support is limited to Arduino-style printf-debugging, in other words, none.