S32E2 IPCF latency timings between M33 and R52

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32E2 IPCF latency timings between M33 and R52

30 Views
PrabhanjanKopp
Contributor I

I am working with S32E2 and configuring the IPCF framework and here is my setup

  • Device: S32E288
  • IPCF transport: Shared Memory + MRU notification
  • Communication: M33 ↔ R52
  • IPCF channel type: Managed channel
  • 1 IPCF channel configured
  • Interrupt mode (not polling)
  • Ping/Pong RTT test implemented

Communication is functioning correctly in both directions.

I use STM to measure the timing ticks between the 2 cores.

Measurement flow:

R52:
timestamp
send PING
 
M33:
receive PING
immediately send PONG from RX callback
 
R52:
receive PONG
compute RTT

 

The values computed for a STM running on 24Mhz are close to 200us RTT(Round trip time). My transport overhead is about 30us but the transfer itself takes up bulk of the time. I have tried various things like increasing MRU IRQ notification but has not improved the timings. Having optimisation in code from -o0 to -o1 helped but -o2 didnt make any difference. The payload itself is 16 bytes.

Questions:
1. what is expected IPCF latency for managed /unmanaged channels.

2. can we acheive a low double digit latency?

If you need any more details, please reply back.

0 Kudos
Reply
0 Replies
%3CLINGO-SUB%20id%3D%22lingo-sub-2413097%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3ES32E2%20IPCF%20latency%20timings%20between%20M33%20and%20R52%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2413097%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EI%20am%20working%20with%20S32E2%20and%20configuring%20the%20IPCF%20framework%20and%20here%20is%20my%20setup%3C%2FP%3E%3CDIV%3E%3CUL%3E%3CLI%3EDevice%3A%20S32E288%3C%2FLI%3E%3CLI%3EIPCF%20transport%3A%20Shared%20Memory%20%2B%20MRU%20notification%3C%2FLI%3E%3CLI%3ECommunication%3A%20M33%20%E2%86%94%20R52%3C%2FLI%3E%3CLI%3EIPCF%20channel%20type%3A%20Managed%20channel%3C%2FLI%3E%3CLI%3E1%20IPCF%20channel%20configured%3C%2FLI%3E%3CLI%3EInterrupt%20mode%20(not%20polling)%3C%2FLI%3E%3CLI%3EPing%2FPong%20RTT%20test%20implemented%3C%2FLI%3E%3C%2FUL%3E%3CP%3ECommunication%20is%20functioning%20correctly%20in%20both%20directions.%3C%2FP%3E%3CP%3EI%20use%20STM%20to%20measure%20the%20timing%20ticks%20between%20the%202%20cores.%3C%2FP%3E%3CP%3EMeasurement%20flow%3A%3C%2FP%3E%3CDIV%3E%3CSPAN%3ER52%3A%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3Etimestamp%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3Esend%20PING%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3EM33%3A%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3Ereceive%20PING%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3Eimmediately%20send%20PONG%20from%20RX%20callback%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3ER52%3A%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3Ereceive%20PONG%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3Ecompute%20RTT%3C%2FSPAN%3E%3C%2FDIV%3E%3CBR%20%2F%3E%3CP%3EThe%20values%20computed%20for%20a%20STM%20running%20on%2024Mhz%20are%20close%20to%20200us%20RTT(Round%20trip%20time).%20My%20transport%20overhead%20is%20about%2030us%20but%20the%20transfer%20itself%20takes%20up%20bulk%20of%20the%20time.%20I%20have%20tried%20various%20things%20like%20increasing%20MRU%20IRQ%20notification%20but%20has%20not%20improved%20the%20timings.%20Having%20optimisation%20in%20code%20from%20-o0%20to%20-o1%20helped%20but%20-o2%20didnt%20make%20any%20difference.%20The%20payload%20itself%20is%2016%20bytes.%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3EQuestions%3A%3CBR%20%2F%3E1.%20what%20is%20expected%20IPCF%20latency%20for%20managed%20%2Funmanaged%20channels.%3C%2FP%3E%3CP%3E2.%20can%20we%20acheive%20a%20low%20double%20digit%20latency%3F%3C%2FP%3E%3CP%3EIf%20you%20need%20any%20more%20details%2C%20please%20reply%20back.%3C%2FP%3E%3C%2FDIV%3E%3C%2FLINGO-BODY%3E