Nov 11, 2016
01:12 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 11, 2016
01:12 AM
Hello,
I am trying to figure out the frame processing principle of ESC in XMC4800 MCU. However, the 'Reference Manual' does not explain about it instead it point to datasheet of ET1100. So I guess they have same ESC core. In the datasheet of ET1100, Fig. 5, page I-14 I it is explained that
- Processing direction: frame will get in port#0, passes the EtherCAT processing uint (EPU) and gets out at port#1
- Forwarding direction: when the frame get back port#1 (after passing all slaves), it will directly forwarded to port#0 to return master
As my understanding, all ouput/input data processing for one slave will done once by EPU in the processing direction frame.
I have done a simple test with 2 XMC4800 Relax kits. I put a pin toggle at each APPL_OutputMapping() and APPL_InputMapping() event. And this is my result (two upper signals come from Slave#1 and two lower ones from Slave#2)
As you can see, for each slave there is a delay between output and input events, it can be understood. But why APPL_InputMapping() event of slave#1 happens later than APPL_OutputMapping() event of slave#2. It seems that the APPL_InputMapping() event is processed on the returned frame, not in processing direction frame, can you explain this?
Thank you!
I am trying to figure out the frame processing principle of ESC in XMC4800 MCU. However, the 'Reference Manual' does not explain about it instead it point to datasheet of ET1100. So I guess they have same ESC core. In the datasheet of ET1100, Fig. 5, page I-14 I it is explained that
- Processing direction: frame will get in port#0, passes the EtherCAT processing uint (EPU) and gets out at port#1
- Forwarding direction: when the frame get back port#1 (after passing all slaves), it will directly forwarded to port#0 to return master
As my understanding, all ouput/input data processing for one slave will done once by EPU in the processing direction frame.
I have done a simple test with 2 XMC4800 Relax kits. I put a pin toggle at each APPL_OutputMapping() and APPL_InputMapping() event. And this is my result (two upper signals come from Slave#1 and two lower ones from Slave#2)
As you can see, for each slave there is a delay between output and input events, it can be understood. But why APPL_InputMapping() event of slave#1 happens later than APPL_OutputMapping() event of slave#2. It seems that the APPL_InputMapping() event is processed on the returned frame, not in processing direction frame, can you explain this?
Thank you!
- Tags:
- IFX
4 Replies
Nov 16, 2016
05:15 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 16, 2016
05:15 AM
Hi mophong,
the delay from APPL_OutputMapping to APPL_InputMapping origins from the SW-processing inside Slave#1.
While the EPU is triggering this SW-processing, in parallel it forwards the frame to slave#2 on port#1/out.
While slave is still busy on processing APPL_OutputMapping/APPL_InputMapping the frame arrives on Slave#2. The EPU of slave#2 is than triggering the SW-input/output-processing in parallel.
So the delay of slave#1/OutputMapping to slave#2/OutputMapping is more or less the delay you are looking for and which is introduced by the EPU(s) to forward the packet from slave#1 to slave#2.
There is no need to wait for APPL_InputMapping on slave#1 being finished before the frame is forwarded to slave#2.
Kind Regards
Michael
the delay from APPL_OutputMapping to APPL_InputMapping origins from the SW-processing inside Slave#1.
While the EPU is triggering this SW-processing, in parallel it forwards the frame to slave#2 on port#1/out.
While slave is still busy on processing APPL_OutputMapping/APPL_InputMapping the frame arrives on Slave#2. The EPU of slave#2 is than triggering the SW-input/output-processing in parallel.
So the delay of slave#1/OutputMapping to slave#2/OutputMapping is more or less the delay you are looking for and which is introduced by the EPU(s) to forward the packet from slave#1 to slave#2.
There is no need to wait for APPL_InputMapping on slave#1 being finished before the frame is forwarded to slave#2.
Kind Regards
Michael
Nov 16, 2016
11:17 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 16, 2016
11:17 PM
Thanks MichaelIFX,
So the data updated in APPL_InputMapping (data from Slave to Master) will be sent in next cycle frame, not current frame, am I correct?
So the data updated in APPL_InputMapping (data from Slave to Master) will be sent in next cycle frame, not current frame, am I correct?
Jul 09, 2017
10:41 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 09, 2017
10:41 AM
mophong wrote:
So the data updated in APPL_InputMapping (data from Slave to Master) will be sent in next cycle frame, not current frame, am I correct?
did you find out how this works?
thanks.
Jul 10, 2017
02:00 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 10, 2017
02:00 AM
Hi mophong,
I just got aware of your comment by yoyixms (btw: thank you!) re-triggering this thread.
Yes, you are right!
Kind Regards
Michael
I just got aware of your comment by yoyixms (btw: thank you!) re-triggering this thread.
Yes, you are right!
Kind Regards
Michael