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.

AM3358: AM335x External ADC (i.e. ADE7880) access from PRU0/PRU1

Part Number: AM3358

hello,

we have developed an starter kit based reference board.

and using latest ti sdk i am able ti interface ADE7880 over SPI1.0  with our board and getting perfect count at 2.5 Mhz.

=====> now we want more speed and reduce CPU load for that i want to shift ADE from Main ARM CPU to PRU-ICSS.

yes i have gone through

Rebuilding PRU Firmwares on Target Using Sitara Processors

RPMsg Quick Start Guide

also watch Programmable Real-Time Unit and Industrial Communications Subsystem Training Series

yes i'm getting msg from pru core using RPmsg

using

1. Use the remoteproc sysfs interface to point the remoteproc driver to the newly built firmwares for each PRU
echo 'PRU_Halt.out' > /sys/class/remoteproc/remoteproc1/firmware
echo 'PRU_RPMsg_Echo_Interrupt1.out' > /sys/class/remoteproc/remoteproc2/firmware
2. Once again use the remoteproc sysfs to load and the run the PRU cores
echo 'start' > /sys/class/remoteproc/remoteproc1/state
echo 'start' > /sys/class/remoteproc/remoteproc2/state

ls /dev/ | grep pru
echo "test30" > /dev/rpmsg_pru30
echo "test31" > /dev/rpmsg_pru31
cat /dev/rpmsg_pru30
cat /dev/rpmsg_pru31
You will need to press 'Ctrl + Shift + c' to stop reading and close the character device

but still don't able to define how to write code for ADE7880 such a way that so ti sdk and my ADE7880 code run on PRU simultaneously run

  • Hello Raju,

    Let's back up and look at system design for a moment. It sounds like you are trying to reduce load on the ARM core, right?

    Here is background info on PRU <-> ADC:

    The post you linked is talking about controlling the on-processor ADC from PRU. You can find an example of that in the PRU Software Support Package (in Linux SDK under example-applications/pru-icss-x.x.x/ or at the git repo).

    The PRU core runs bare metal code - you can't run Linux or RTOS on it like the ARM core.

    You are trying to get the PRU to interact with an external ADC instead of the on-chip ADC.

    One option is to use the PRU to control the SPI peripheral on the AM335x. I can give you pointers if that is what you want, but note that a peripheral should have only one master. So you would need to disable the SPI in the Linux DTS file and manually enable clocks, do peripheral initialization & setup, etc from PRU.

    Another option is to directly connect the ADC to the PRU's GPI/GPO pins and control it by implementing a SPI protocol on the PRU. We have examples for that at https://www.ti.com/tool/TIDA-01555 and in the Linux SDK under example-applications/pru-adc.

    Note that any PRU <-> ADC option you implement will take development work on your end. It will not be plug and play, like using a Linux driver.

    Regards,

    Nick

  • hii,

    Thank You for Your Reply

    Let's back up and look at system design for a moment. It sounds like you are trying to reduce load on the ARM core, right?

    Yes

    You are trying to get the PRU to interact with an external ADC instead of the on-chip ADC.

    yes

    One option is to use the PRU to control the SPI peripheral on the AM335x

    yes that is what i'm trying to implement...

    So you would need to disable the SPI in the Linux DTS file and manually enable clocks, do peripheral initialization & setup, etc from PRU.

    yes i have comment spidev@1 node from dts file

    Another option is to directly connect the ADC to the PRU's GPI/GPO pins and control it by implementing a SPI protocol on the PRU.

    yes for that I'm thinking to use

    in our custom board we have access  pru GPI/GPO


    now i am thinking using bit-banging implement spi for External ADC interface

    yes i am able to toggle PRU GPO at 5ns

     

    #include <stdint.h>
    #include <pru_cfg.h>
    
    volatile register uint32_t __R30;
    volatile register uint32_t __R31;
    
    void main(void)
    {
        volatile uint32_t gpo;
    
        /* GPI Mode 0, GPO Mode 0 */
        CT_CFG.GPCFG0 = 0;
    
       /* Clear GPO pins */
        __R30 = 0x0000;
    
        while(1){
             gpo = __R30;
             gpo ^= 0x1;
             __R30 = gpo;
             __delay_cycles(100000000); // half-second delay
             __delay_cycles(100000000); // half-second delay
        }
    }

     

  • Hello Raju,

    Apologies for the delayed response. If you decide to use PRU,

    1) Note that you would either want to use the on-chip SPI, or you would want to directly connect the PRU GPI/GPO signals to the ADC. I do not think you would want to do both.

    2) When disabling a node in the device tree, I do not suggest deleting the node. That is because there might be an earlier DTS file that enables the node. Instead, go to your last DTS file (explanation below). In the SPI node, change "status = "okay";" to "status = "disabled";"

    Why use the last DTS file?
    Let's say dts1 includes dts2 at the top of the file. And dts2 includes dts3 at the top of the file. Then the software will read dts3 first, then dts2, then dts1. If there is conflicting information, then the information from dts3 and dts2 will get overwritten by the information in dts1. That is why you want to make all your changes in dts1, so that what you do is not overwritten by a later file.

    Regards,

    Nick

  • hello

    sorry for discrete information

    initially i have connected external adc with on chip SPI1.0 pins

    but problem was at that time due to spi load CPU used almost 70 to 80% seen in htop.

    so i'm switched to use PRU GPI/GPO for ADC interface

    1) Note that you would either want to use the on-chip SPI, or you would want to directly connect the PRU GPI/GPO signals to the ADC. I do not think you would want to do both.


    ==> would want to directly connect the PRU GPI/GPO signals to the ADC

    yes

  • Hello Raju,

    Ok. If you are interested in doing the PRU custom firmware development work, that sounds like a fine setup.

    Returning to your original question:  https://www.ti.com/tool/TIDA-01555 User Guide includes a discussion of one way for the PRU firmware and the Linux ARM core to send data and interrupts back and forth. If you have further questions about getting the TI Linux SDK and the PRU firmware running, check Labs 4-6. If you have additional questions, feel free to reply here.

    Regards,

    Nick

  • hello

    thank you so much to guide with this matter...

    your help really appreciated.

    i am locking Build SPI Bit banging on PRU GPI/GPO.

    for the time i am resolving my issue..

    Thank You

    Regards

    Raju!..