dinuxbg
commented
6 years ago Hi,
You are welcome to contribute to any area you find interesting. Here are a few ideas:
-
[ ] GDB port. This is a major task. You may check https://github.com/dinuxbg/gnupru/blob/6ec05b2047e3ebe8b23e78ba93065ccb2a750b36/patches/binutils-gdb/0004-gdb-pru-Initial-dummy-port.patch for my initial attempt. It was written for 32-bit register definitions, whereas recent pru-gcc uses 8-bit registers. You will also need to eventually assign copyright to FSF in order to merge your patch into GDB mainline.
-
[ ] Debug info in ELF. https://github.com/dinuxbg/gnupru/issues/30 . This would improve interoperability between TI tools and GCC/Binutils. You will need to eventually assign copyright to FSF in order to merge your patch into Binutils mainline.
-
[ ] Debian packaging. There are existing debian packaging scripts ( https://github.com/dinuxbg/gnupru/tree/master/packaging ), which need to be cleaned up and submitted to debian for inclusion. Wouldn't it be good to "apt install gcc-pru" on any debian x86 or arm host?
-
[ ] Write more examples. It helps new users to see working clean example projects.
-
[ ] Making "volatile register R30 = asm("r30")" work on GCC. This one requires substantial knowledge of GCC internals. I'm not sure if it is even feasible. Would require all volatile accesses to be tracked and handled in each GCC pass. I wouldn't recommend it for a first task.
As for the purpose of GCC, at the very least it was fun to port :) Also, you have Binutils assembler and linker if you prefer assembly programming. And you can always take the best of both worlds by mixing C and ASM: https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/pru/ov7670.c#L141 . Inline assembly in GCC is light years ahead of TI CGT.
Regards, Dimitar
Electron752
Hi,
I've been using the PRU in the BBB for awhile now. All in asm using the pasm tool. I'm interested in possibly helping here and just wanted to check first what would be good areas to contribute to.
Two areas that seem interesting is finishing gdb and cleaning up the debian packages. These are areas I can probably contribute to quite easily and I've been unable to find a working software debugger for the PRU on the web. I know TI does support hardware JTAG based debugging but it's a bit expensive and a software tool would be great as a first try debugging tool.
BTW, I am a bit curious of the purpose of GCC though. Most of the strength of the PRU is the single cycle execution, predictability, and specialization of the instruction set and that often requires writing in ASM to leverage.