I assume I should buy the ARM version and also order RISC-V board separate? The modules seem easily swappable but I’m not sure if it’s that easy in practice or if I need more preparation.
Is there any advantage to buying the whole kit with RISC-V, will I need to be more organised e.g. is it difficult to obtain the right SD cards if not bought as a full kit? Is there likely to be wear & tear or other risks if I change the CPU a few times, or any other reason not to experiment with both ways in the one box? Is there any sort of recommended “full package” setup for developers? I’m also sceptical of why the ARM modules seem sold out, I assume they’re still shipping in the kits.
It would be nice to have some bundle or explanation for people who’ve come here for the RISC-V version but may want an ARM option for practicality. As it’s a bit of an oversized investment given the relatively low end RISC-V chip (which I’d like to experiment with) my main motivation in asking is just to ensure I’m not wasting the hardware with an underpowered option, and making sure I don’t order some totally broken setup.
I’m also interested in the future of the RISC-V models, e.g. are more powerful updates planned, will the same device still be upgradeable if new CPU boards are planned etc. However this is my first post so please take my lack of clarity asa sign of enthusiasm!
Pros and Cons to each of the options. I have a DevTerm with a CM3 in it. Works well and has good battery life. The quad core of the CM3 and even more powerful CM4 outrun the R-01 RISC-V module by a large margin. I do have the R-01 unit in the uConsole. The other real advantage of the CM3 and CM4 is they run Raspian, a version of Debian that is very well supported. I don’t have the A04 or A06 units so can’t comment about those. The other con with the RISC-V unit is it is a work in progress. Knowledge of how things work is assumed more often. The other con, is it is rather slow as a single core unit without a GPU. Command line is ok, but using it with a GUI, the lack of GUI becomes obvious. The price point is low enough and if you want to play with the RISC-V, go for it. As you noticed, it really isn’t that hard to swap modules.
There is a real limitation of the main board for I/O speed as it only supports the USB-2 so I wouldn’t expect that many future modules to be designed to work with this main board. SD cards also have their limits for lifetime and speed. Maybe someone can comment on the CM4 with built in eMMC on it.
I would argue that you go with one of the ARM-based modules in any DevTerm or uConsole to intend to use as a “daily driver”. And get a RISC-V based Arduino or system-on-module if you want to experiment with RV. The RISC-V systems in general are still pretty weak on graphics support and the industry is still very much focused on using RISC-V in its microcontroller role.
That’s not to say you can’t use RISC-V if you want. I ordered an RISC-V in my uConsole. And I also have a very cheap system-on-module, Sipeed Lichee RV Dock and module (Allwinner D1 RISC-V) that I use for most of my experiments. That D1 chip worked first try for me with the patched up version of Linux they offer, but it suffers from not having most of those patch upstream making it harder to upgrade the kernel or use a different distro. While writing this post, I noticed that it appears people have gotten more distros and kernel versions working). I imagine some of this could be leverages for CPi R-01 modules as well.
That’s the sort of battle you will find if you stray off the popular ARM chips and onto more obscure chips and architectures. You will have an advantage going with the ClockworkPi R-01 versus that Allwinner board I mentioned, as there is distro support from CPi and a forum to help you. But it’s the same chip and I anticipate worse case is that the same problems with software support will crop up.
Putting together a good workflow where you can edit, compile, upload, and run code is a big part of this embedded development. Making little shell aliases or scripts can take a lot of strain off your brain too.
And as always, keeping a notebook (electronic or physical) on what you’re doing and what you’ve done is tremendously helpful when you want to go back and look at something months later.
Actually kernel support and u-boot support is pushing into mainline, but I’m waiting my uConsole to try mainline kernel boot up the build-in screen (HDMI should be fine, but dual-display probably will not work).