3 ms·

It depends on what you want to do in terms of which type of coprocessor is more useful. The PRUs are quite amazing in what they can do, but the development env

by bradfa 4y ago

It depends on what you want to do in terms of which type of coprocessor is more useful. The PRUs are quite amazing in what they can do, but the development environment is let's say less than ideal. The AM6xx series SOCs do have the PRU subsystem in them along with the Cortex-M4.

joezydeco 4y ago
Oh yeah I see it now. My bad.
meatmanek 4y ago
> but the development environment is let's say less than ideal. I agree - lots of wasted potential there. I wish they had implemented an Arduino plugin for the PRUs, as well as a library for both the PRU side and the Linux side for using shared memory with common patterns (FIFOs, etc.). Something newbie-friendly like that would've made the Beaglebones way more popular, IMO.
bsder 4y ago
> the development environment is let's say less than ideal. Developing C on Linux is less than ideal? I suspect you are making the wrong comparison. Using a PRU generally lets me skip an FPGA. That's huge. Now, my firmware team can do development in C on a Linux machine rather than Verilog/VHDL in some horrible vendor (Xilinx/Altera) toolset. If you're programming a PRU, you need to know WHY you're programming a PRU. Otherwise, why wouldn't you just use the main processor?
- bradfa 4y ago
  Although there is a C compiler for the PRU, the last time I checked it produced quite less than optimal performance compared to hand assembly. The instruction set is pretty simple so it’s not horrible to write by hand. Maybe they’ve made big strides in the C compiler capabilities recently?
  - binarycoffee 4y ago
    Not only is the instruction set simple, but the clock-per-instruction cost is deterministic, so assembly code is ideal for real-time I/O. Just like GP, we found that we could often use a PRU in place of an FPGA and dramatically cut development cost (this was for very small production series). One use case for C is communication with the CPU (remoteproc stuff). We commonly had one PRU handle CPU communication with trivial C code while another PRU on the same PRU subsystem was coded with assembly to handle real-time I/O.

by bradfa 4y ago

joezydeco 4y ago

Oh yeah I see it now. My bad.

meatmanek 4y ago

> but the development environment is let's say less than ideal. I agree - lots of wasted potential there. I wish they had implemented an Arduino plugin for the PRUs, as well as a library for both the PRU side and the Linux side for using shared memory with common patterns (FIFOs, etc.). Something newbie-friendly like that would've made the Beaglebones way more popular, IMO.

bsder 4y ago

> the development environment is let's say less than ideal. Developing C on Linux is less than ideal? I suspect you are making the wrong comparison. Using a PRU generally lets me skip an FPGA. That's huge. Now, my firmware team can do development in C on a Linux machine rather than Verilog/VHDL in some horrible vendor (Xilinx/Altera) toolset. If you're programming a PRU, you need to know WHY you're programming a PRU. Otherwise, why wouldn't you just use the main processor?

bradfa 4y ago
Although there is a C compiler for the PRU, the last time I checked it produced quite less than optimal performance compared to hand assembly. The instruction set is pretty simple so it’s not horrible to write by hand. Maybe they’ve made big strides in the C compiler capabilities recently?
- binarycoffee 4y ago
  Not only is the instruction set simple, but the clock-per-instruction cost is deterministic, so assembly code is ideal for real-time I/O. Just like GP, we found that we could often use a PRU in place of an FPGA and dramatically cut development cost (this was for very small production series). One use case for C is communication with the CPU (remoteproc stuff). We commonly had one PRU handle CPU communication with trivial C code while another PRU on the same PRU subsystem was coded with assembly to handle real-time I/O.