AM2434: PRU - C code application suggest

Hello Bolt,

First, terminology: I usually use "PRU" to refer to all 3 kinds of PRU cores: PRU, RTU, and TX_PRU. So unless I am specifying a core, you can assume I am talking about all 3 kind of cores.

Let's talk about C vs assembly programming

The PRU C compiler can provide pretty good performance. Depending on what you are programming, you may see the C compiler generating assembly code that runs in about the same number of clock cycles as if you had hand-coded your project in assembly. So "average performance" could be about the same.

The difference is how much CONTROL you have over the software.

"Bitbanging" refers to using software to directly drive a processor pin high or low. Most processor cores cannot bitbang signals deterministically, or at very high frequencies, so the ability of the PRU to deterministically implement protocols that are 10s of MHz is one of the PRU's differentiating features. For more about the basic concepts, refer to the AM243x PRU Academy "How are PRU GPIO signals different from regular GPIOs?"

Often when the PRU is bitbanging interfaces, you either need the signal on the pin to transition from low to high at an exact point in time, or you need to make sure that calculation X always occurs within Y clock cycles (e.g., when a slave-side protocol needs to respond to an input signal within a certain number of nanoseconds or microseconds). In these cases, programmers often prefer to program directly in assembly so that they can have 100% control to guarantee that the PRU will always meet timings.

Performance differences between PRU/RTU/TX_PRU cores? 

As a reminder, each PRU_ICSSG subsystem is divided into 2 slices, and each slice has 3 cores: a PRU, RTU, and TX_PRU. That means each PRU_ICSSG has 6 cores total, for 12 PRU cores in the AM243x.

All of these cores are identical INSIDE the cores. So they will all run at the same frequency (if you set PRU to run at 333MHz, TX_PRU will also run at 333MHz), and they will all have access to the same assembly instructions (so they will run the same code in the exact same way).

The differences are the things that are CONNECTED to each core.

Each core has a different amount of instruction memory (IMEM). So you can store bigger programs on PRU cores than RTU or TX_PRU.

The PRU_ICSSG has a lot of useful hardware accelerators, and different cores have different connections to hardware accelerators. For example, the scratchpad memory can be used to pass data between PRU/PRU and PRU/RTU, but NOT between TX_PRU and the other cores. You'd need to check each accelerator to see which one is connected to which cores.

The PRU cores can directly write to the PRU GPO signals or read PRU GPI signals, while the RTU & TX_PRU cores can only read in PRU GPI signals. So I often see customers use the PRU cores to bitbang the protocol interface, and the RTU & TX_PRU cores to handle data movement and manipulation inside the processor.

SDFM / encoder questions? 

I'll let another team member answer those questions.

Regards,

Nick

Bolt

Bolt Hsieh said:

If we want to develop SDFM and Encoder applications on the six cores of the PRU-ICSSG (PRU0/1, RTU0/1, TxPRU0/1), can all of them be developed using C language? Additionally, if assembly language is not used, will there be a significant difference in performance? 

Main advantage of using assembly is to have tight control of PRU cycles in time-critical processing paths.

Firmwares for SDFM and Encoders are available in Motor Control SDK. You can check following pages.

AM243x Motor Control SDK: Position Sense

AM243x Motor Control SDK: Current Sense

Bolt Hsieh said:

Another question: For SDFM and Encoder data processing, are there any specific cores you would recommend for SDFM and which ones for Encoder? And what are the benefits of doing so? 

Additionally, is it possible for the same core to handle both Encoder and SDFM processing? 

I will continue to review the SDK - AM243x Motor Control SDK: Introduction. If there are any relevant pages that provide explanations, I would appreciate it if the experts could share them with me. Thank you

1 PRU-ICSSG has 2 slices, each slice contains PRU, RTU_PRU and TX_PRU each. PRU IO mode can be selected at PRU slice level. Please check this developer guide for more details: AM243x Motor Control SDK: PRU-ICSSG Input/Output Modes

Recommendation would be to do encoder on one slice and SDFM on another slice. Please check this developer guide for more details on PRU allocation: AM243x Motor Control SDK: How to allocate PRUs for different functions within one PRU-ICSSG ?

Regards

Dhaval

Hi Nick & Dhaval,

Thank you for your replies.

I referred to the description on that page - AM243x Motor Control SDK: How to allocate PRUs for different functions within one PRU-ICSSG ?

I want to switch PWM to use the AM2434’s built-in ePWM module so that Tx_PRU0 can be used to update another encoder (for example, in an application where one axis uses dual-encoder feedback). Is this approach feasible, or is it restricted by PRU I/O mode being set at the slice level?

If the above method is not feasible. But we still have to use a single PRU-ICSSG to handle four encoders and SDFM sampling still needs to be performed, do you have any recommended approaches?

Regards
Bolt

Bolt

Pin-mux mode of SD vs encoder is a slice level configuration. It is not possible to mix.

1. Which encoders are you looking to implement?

2. How many SD channels do you need?

Regards

Dhaval

Hi Dhaval,

Thank you for your replies.

And, I found out the information in the Motor Control SDK documentation.

About Q1.

Our team plans to support up to four encoders. The encoder types can be classified into three categories: QEP, asynchronous, and synchronous.

We plan to check the environment configuration required to download different .bin files to the PRU core in order to support various encoder types.

Do you think a single PRU/RTU/Tx_PRU core can handle encoder updates for two channels, or is each PRU/RTU/Tx_PRU core limited to a single encoder channel due to hardware I/O constraints or other limitations?

About Q2.

A minimum of four SD channels is required, with a potential future expansion to six SD channels.

------------------------------------

For a single PRU-ICSSG, is it possible to implement the above Encoder and SDFM requirements?

Regards
Bolt

Bolt

I apologize for the delayed response.

Bolt Hsieh said:

Do you think a single PRU/RTU/Tx_PRU core can handle encoder updates for two channels, or is each PRU/RTU/Tx_PRU core limited to a single encoder channel due to hardware I/O constraints or other limitations?

It depends on the encoder requirements. If you use load share mode, 1 PRU core can only do 1 channel as per HW mapping. If you need to process 2 channels with 1 core, then only PRU core can do it. Without load share mode, only PRU has access to 3 channel peripheral interface pins. Do you plan to use GPIO mode for this?

Bolt Hsieh said:

A minimum of four SD channels is required, with a potential future expansion to six SD channels.

Motor Control SDK contains details on PRU cores needed based on the features required.

Regards

Dhaval