> 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?
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?
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.
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?