The TI E2E™ design support forums will undergo maintenance from Sept. 28 to Oct. 2. If you need design support during this time, contact your TI representative or open a new support request with our customer support center.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/PRU-SWPKG: Application-PRU Support for GNU G++

Part Number: PRU-SWPKG
Other Parts Discussed in Thread: AM5728

Tool/software: TI C/C++ Compiler

I was wondering if it is possible to support the application interface into working with the PRU's from G++. I have integrated the PRU libraries into my G++ application, which remote compiles onto a Sitara AM5728, of which has quite a bit of application specific code already. My team realized we will be needing the real-time-ness of the M4 on the Sitara for interfacing with peripheral devices, but many of the function declarations do not natively compile within G++. For example:

Inside pru_cgf.h:

volatile __far pruCfg CT_CFG __attribute__((cregister("PRU_CFG", near), peripheral));

neither __far nor near are defined in the default G++ compiler.

My understanding would be __far could be #defined as long_call from arm:

https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html#ARM-Function-Attributes

but I am not 100% confident on that. I am not asking for how I would develop the firmware for the M4 using G++ as I fully expect that to be restricted to using CCS or other similar tools, but I am still looking for how to interface G++ with these declarations to interface with the M4 from userspace.

  • Hello Lucas,

    I am unclear on what you are trying to accomplish. Are you actually compiling code for the PRU? Are you just trying to take PRU libraries and use them with a different compiler on a different core?

    The PRU header files were created to make it easier to understand code that modified the PRU registers. For example, it allows us to change the STANDBY_INIT bit of the SYSCFG register in the PRUSS2_CFG registers by using the constants table (CT) entry as our offset:
    CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
    rather than modifying bit 4 of memory location 0x4B2A6000 (which does the same thing, but is much harder to read and understand).

    Regards,
    Nick
  • Hello Nick,

    Sorry for the confusion. I was confused with the difference between the PRU and the IPU subsystem, without recognizing that the PRU is a Risc-32-bit versus and Arm M4.

    Closing the issue as it is arguably a non-issue.