• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 101 subscribers
  • Views 358 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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++

Lucas Rolfes
Intellectual 600 points
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.

  • 0
    TI__Guru* 85535 points
    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
  • 0 in reply to Nick Saulnier
    Intellectual 600 points

    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.