SPE IVC echo example application with longer frame size

Hello,

I would need to implement something very similar to Sensor Processing Engine IVC echo example, just with longer TX buffers.

This is the setup I am using:

  • Jetson Xavier NX
  • SPE default SDK and toolchain
  • ENABLE_SPE_FOR_NX := 1 in rt-aux-cpu-demo/soc/t19x/target_specific.mk
  • aon_echo added to device tree

Then:

Linux terminal A
sudo bash -c "echo 01234568 > /sys/devices/aon_echo/data_channel"

Linux terminal B
watch -n 0.1 od -x /sys/devices/aon_echo/data_channel

getting this, correct result:

0000000 3130 3332 3534 3836 000a 0000 0000 0000

The maximum payload allowed for IVC TX is 64 byte, as imposed by #define IVC_ECHO_CH_FRAME_SIZE (TEGRA_IVC_ALIGN * 1) in rt-aux-cpu-demo/include/ivc-config.h.
I would need to transmit longer data chunks, so I tried changing IVC_ECHO_CH_FRAME_SIZE to (TEGRA_IVC_ALIGN * 2) there.
Executing echo example again, I get no run-time errors, but data shown by od command is now zero, and only after some echo retries it is correctly sampled at the expected value. Then it goes back to zero at following echo execution, and so on…
This behavior makes me think that define mismatches might be happening. Maybe changing IVC_ECHO_CH_FRAME_SIZE in SPE is not enough, and others code sections shall be accordingly updated?

Thanks in advance

Andrea

Hello, andrea.pascolini:
That’s a little complicated. I can only provide some suggestions, and you may have to make more diggings and coding/testing. Please note that it involves quite lots of coding tasks.
Generally, the CCPLEX and SPE can exchange data through shared memory. You can take a look at current IVC channel implementation.
My suggestion is to keep current IVC as a ‘control channel’. In another word, keep current aon_echo setting, and define your own control command structure, like command id, data point, data size, etc.
You can allocate another memory bulk in kernel side, and map that in SPE. With correct mapping/syncing, large block of data exchange should be doable.

br
ChenJian

Hello Jachen, and thanks for your answer.

I managed to get an higher payload, 4096 bytes, by applying the following changes:

DTREE - nvidia-l4t/sources/hardware/nvidia/soc/t19x/kernel-dts/tegra194-soc/tegra194-aon.dtsi

before:

        ivc_aon_echo@0 {                                                                                                                                          
            reg = <0x00000>, <0x10000>;
            reg-names = "rx", "tx";
            nvidia,frame-count = <16>;
            nvidia,frame-size = <64>;
        };

now:

        ivc_aon_echo@0 {                                                                                                                                          
            reg = <0x20000>, <0x30000>;
            reg-names = "rx", "tx";
            nvidia,frame-count = <2>;
            nvidia,frame-size = <4096>;
        };

SPE - l4t-rt/rt-aux-cpu-demo/include/ivc-config.h

before:

#define IVC_ECHO_TX_OFFSET  0x00000                                                                                                                                   
#define IVC_ECHO_RX_OFFSET  0x10000
#define IVC_ECHO_CH_NFRAMES 16
#define IVC_ECHO_CH_FRAME_SIZE  (TEGRA_IVC_ALIGN * 1)

now:

#define IVC_ECHO_TX_OFFSET  0x20000                                                                                                                                   
#define IVC_ECHO_RX_OFFSET  0x30000
#define IVC_ECHO_CH_NFRAMES 2
#define IVC_ECHO_CH_FRAME_SIZE  (TEGRA_IVC_ALIGN * 64)

So, I reused IVC aon_echo channel, moving and extending the relative memory space. Tested, now it works as expected. Maybe, according to what you said, defining a dedicated memory chunk could provide better performance. Would that still be based on IVC channel feature, or we should completely avoid IVC?

Thanks

Andrea

Hello, andrea.pascolini:
You changes look good to me.
As long as it serves for your application, it should be OK.
There’s no performance issue with your implementation.
Something to be considered:

  1. 4KB message, maybe not so flexible, compared with control/data implementation.
  2. So now the message number decreases a lot. Make sure no message queue overflow.

Would you mind to share the details about the usage of SPE, or just for study? We also want to know the use case of SPE firmware in Jetson platform, and provide more features if possible.

Thanks.

br
Chenjian

Hello jachen,

we are actually using SPE in a real project, I would be happy to share more about our application if we could continue on a private channel.

Thanks

Andrea

Hello, andrea.pascolini:
Got it. Thanks for your input.
If you have no more questions regarding to this ticket, we can close it.

Feel free to raise a new thread with new problems.

br
ChenJian

Hi Jachen,

yes, no other doubts about this issue, thanks for your kind support

Andrea

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.