search

OpenEtherCATsociety / SOEM

Simple Open Source EtherCAT Master
Other
1.23k stars 653 forks source link

iomap size as reported in `slavelist[0]` appears incorrect after `ecx_config_overlap_map_group` #808

Closed kj4tmp closed 3 weeks ago

kj4tmp commented 1 month ago

My iomap size appears incorrect as returned from ecx_config_overlap_map_group.

I am using ecx_config_overlap_map_group(0) to produce my iomap, which returns 66.

Here are stats from my slavelist (in bytes):

0 (master):  inputs.size= 41  outputs.size= 25
1 (EK1100):  inputs.size= 0   outputs.size= 0
2 (EL3314):  inputs.size= 16  outputs.size= 0
3 (EL2088):  inputs.size= 0   outputs.size= 1
4 (EL3681):  inputs.size= 8   outputs.size= 2
5 (EL3204):  inputs.size= 16  outputs.size= 0

Ostartbit and Istartbit is zero for all slaves (as expected since overlap_map is byte aligned.

Doing some math:

41 + 25 = 66 (as expected, the return of config_overlap_map = inputs + outputs)
16 + 8 + 16 = 40 != 41 (1 extra input byte)
1 + 2 = 3 != 25 (22 extra output bytes)
  1. What is the additional 1 byte in the input and 22 bytes in the outputs?
  2. Could we please have some additional documentation regarding the iomap, especially since we have the byte aligned option too?

I am not extremely memory contrained, I am just trying to gain better understanding of the IOmap so i can use it correctly. I have found no issues using the IOmap via pointer and bitshifts etc but I may need to process the iomap as one giant struct in the future for performance reasons, which would require me to know how the entire iomap is constructed, including gaps between slaves, etc.

ArthurKetels commented 1 month ago

We have excellent documentation, it's called the source code ;-)

You first have to understand what the principle behind overlapped mapping is. It means that the input and output bytes -per slave- share the same logical memory space (FMMU). This automatically has the consequence that the largest of the input or output size determines the memory occupied.

If you take the effort of printing out the FMMU logical addresses of each slave you would see how this works out. So for each slave we calculate the maximum of the input or output size. One extra rule is that we skip allocating logical memory space for outputs if the output size is zero and we are the last slave.

So slave 3 gets one extra input space because output size is 1. Slave 3 get 16 output bytes (instead of 0). Slave 4 gets 8 output bytes (instead of 2).

But you could have read that from the source just a easy.