3 ms·
> This, in fact, where I was really hoping RISC-V would shine. Have a couple of high power RV64I cores (Cortex-A equivalent) that can run an OS in soft real tim
by brucehoult 3y ago
> This, in fact, where I was really hoping RISC-V would shine. Have a couple of high power RV64I cores (Cortex-A equivalent) that can run an OS in soft real time and a couple of low power RV32I cores (Cortex-M equivalent) connected directly to the pins and running in hard real time.
You have perhaps missed the BL808 (C906 applications processor RV64GCV 480MHz, plus RV32GCP 320MHz real-time core, plus RV32EMC 160MHz core primarily controlling the WIFI/BT) and CV1800B (C906 RV64GCV 1 GHz for Linux, plus C906 RV64GC 700 MHz for real-time), both with 64 MB on chip PSRAM and available on boards under $10: Sipeed M1s Dock, Pine64 Ox64, Milk-V Duo.
However, while many things are fine with sequential processing on a few hundred MIPS conventional CPU or PIO, some things need the parallelism of an FPGA fabric. Yes, it's harder to use but that's equally true on your cheap iCE40 (or whatever) attached to an MCU by a few pins.
Beagleboard products are always expensive. They are aimed at purchase-order corporate users, always available in stock in major distributors such as Digikey on the day of announcement, and have got margin built in for the distributor.
- bsder 3y agoI can't seem to get the datasheets (getting 404s after I finally dove into the "Community" section of their website which seems to be where they stash the documentation), no mention of real-time with the few diagrams showing an arbitrated bus (which is anathema to real-time), no availability (can't buy chips from anywhere including LCSC), and low-power current specifications almost an order of magnitude larger than any competitor. Yeah, I'm not surprised I haven't heard of them.
- snvzz 3y ago>I can't seem to get the datasheets For which chip family? e.g. BLxxx ones are infamous for lack of docs and I avoid them for that reason, but I haven't had trouble with CH32V family or ESP32-C family. >getting 404s after I finally dove into the "Community" section of their website which seems to be where they stash the documentation), Oh, do you perhaps mean the CV1800B used in Milk-V Duo? They changed the path in the repository, I found it[0] by visiting the parent in the URL's path. Whoever maintains the wiki should either not have linked the blob but the repository, or should have used an actual commit instead of master for the blob. It's preliminary, but has some 700 pages already (!). https://github.com/milkv-duo/duo-hardware/tree/main/CV1800B https://github.com/milkv-duo/duo-hardware/tree/main/CV1800B
- bsder 3y agoYeah, it was the BLxxx family I was looking at. I'll look at the CH32V family. As for the CV1800B, I note that it has an 8051 in the RTC domain. Which misses the whole bloody point of RISC-V. > It's preliminary, but has some 700 pages already (!). Then they've only got another 4300 pages to go ... :) (By comparison: see the AM3359 Technical Reference Manual from TI which is 5100 pages long).
- snvzz 3y ago>(By comparison: see the AM3359 Technical Reference Manual from TI which is 5100 pages long). It looks that much larger and much more complex design. It's also been around for a while, having released in 2011. Unsurprisingly, a significant amount of pages are used to describe the CPU, interrupt controller, memory management and other such ARM-specific cruft. In contrast, RISC-V is much simpler, cleaner, and much more thoroughly standardized, thus the vendor can simply point to the relevant RISC-V specs. >Then they've only got another 4300 pages to go ... :) At least you are just joking :) The less the documentation needed to describe the same functionality the better. Simplicity is valuable on its own, thus complexity needs be justified.
- bsder 3y ago> In contrast, RISC-V is much simpler, cleaner, and much more thoroughly standardized, thus the vendor can simply point to the relevant RISC-V specs. I doubt it. Even simple questions like "How many clock cycles to access SPI register X?" wind up surprisingly complicated. And the manufacturer needs to document all of it because there just aren't enough users to figure it all out by experiment. Even if your CPU is 100% bog standard (and these are not), documenting the peripherals takes a ton of work. Datasheets, in general, tend to be horrible. However, I find that the Chinese datasheets are particularly dreadful whether the chips are simple or complex.