[brucehoult]

Sure there are GPIOs -- didn't you see the "cape" connector?

The SoC had quad C910 OoO cores (similar to A72) as the application processors. There is also a simple E902 (in-order, 2 pipe stages, RV32EMC ... basically Cortex M0 equiv) in the Always-On subsystem and a C906 (64 bit in-order, 5 pipe stages, used as main applications processor in numerous AllWinner D1, Bouffalo BL808 etc boards) in the "audio" subsystem.

[dekhn]

I don't know what machine you're referring to. The BeagleBone, or some other SBC?

Looks like this board (if you mean https://linuxgizmos.com/dev-kit-debuts-risc-v-xuantie-c910-s... or something like it) runs Linux (android or debian). With the BB, you could at least program the PRUs to handle these problems directly in hardware. With the ESP32 you're writing code that runs in an RTOS. Most SBCs I've seen make you use userspace to access GPIOs. unfortunately for my use case, I have about a 100 nanoseconds to move a signal from one GPIO to another, and if I drop an interrupt, it means part of my data ends up missing.

[brucehoult]

I'm referring to the subject of this post, the BeagleV "Ahead", of course.

Why would I be talking about the RVB-ICE? They use the same main CPU cores, but a totally different SoC.

The TH1520 has, as I wrote in my last post, two secondary RISC-V CPUs that are not managed by Linux, and which can be used for real-time tasks.

Of course you don't HAVE to run Linux in the first place if you don't want to. RISC-V chips are very standardised and easy to program bare-metal. The only tough part is usually DRAM and clocks initialisation. You can use the board's standard U-Boot SPL for that if you want, then either replace the Linux kernel by your own code, or also replace the higher level part of U-Boot.

[dekhn]

Is there documentation on how to program real-time on the TH1520 (specifically, running Linux on the main app processor and some interrupt handlers on the secondary CPUs?