Had a quick scroll through the docs there, thanks for the link! One thing that's not clear to me is the degree to which the PRU has register-controller peripheral modules like an MCU, or are you essentially bit-banging everything (which definitely has its appeal after the hours you can spend wrangling with the stupid timers and DMAs on a CM3).
How is the community? Are there ready to go modules for common tasks like actively rectified H-bridge control, CANbus control, etc? (I know the processor itself can do CAN too, but say I have a hard realtime requirement on my CAN network...)
It is basically a raw MCU without any peripherals. I think the main purpose is so you can implement just about any basic peripheral and novel ideas in code, so it is essentially a bit bang but like most MCUs you can read/set an entire IO bank in one go. Since it is separate and basically deterministic except for some ram latency jitter whatever you implement that works should be as solid as any purpose built peripheral. It takes some assembly though. It is absolutely great for basic IO stuff that an arduino class MCU could do where the bandwidth is too high for dealing with the GPIOs with standard linux scheduler latency.
I played with it a couple years ago and the community appeared small, but it is straight forward enough that the examples and docs are likely all you need. I bet the community is stronger but it isn't going to be on stack exchange.
Yeah, they are excellent for bit-banging protocols, which is really handy if you come across some weird digital interface. I've used it for interfacing with a scanner head, which is a fairly quirky parallel interface.
I took another look and it looks like the PRU can also use the peripherals, so you might be able to have a simple realtime component utilizing the CAN peripheral.
I used it for a proof of concept for a project and ended up taking a different route for the final design due to BOM cost desires. The original plan was to use the beaglecore, which is the core of the thing on a PCB with an LGA bottom. It actually comes in a giant cut tape form factor for mutant pick and place machines. I had never seen anything like that before.
Sure it's low level in that you're poking at physical memory registers, but to me, low level in this context (thinking microcontrollers) means replacing the Linux kernel binary with your own application that does its own direct memory poking.
Low level: directly accessing hardware. To immediately equate low level with 'you need to roll your own kernel' is a redefinition of terms that makes no sense to me. After all, even a Linux device driver still makes use of all the facilities the kernel provides and yet it is definitely low level programming.
The cambridge tutorial is armv6 assembly only though. Which is kinda neat to poke around with, but not that much fun (imo). But doing baremetal for the raspberry is fun, just because it is a different architecture. The only problem I had with it was that the bcm-datasheet felt not very nice. It's kind of hard reading yourself through this. Or maybe it was so hard, because the topic in itself is pretty complex
No, to really be low level, you have to implement your stuff in FPGA. But that's not truly low level. To truly be low level, you have to forego pre-fab hardware and fully implement your logic in RTL yourself. But to really be low-level, that isn't sufficient. You must shed your digital abstractions and implement the whole thing in analog circuits.
Those instructions are not using QEMU to emulate the Pi. They tell QEMU to emulate an entirely different piece of hardware (the versatilepb board) and run the raspbian userspace on it. You certainly won't be able to test any code for the Pi that directly accesses the hardware like that. (QEMU does have some limited real rpi emulation support, but those instructions don't use it.)