Ian, your view is true for single core CPUs ... if you have a multi core CPU you can assign a single core for polling of incoming frames. I'm planning to use Intel's DPDK as a networking base for EtherCAT ... it's time to get rid of the dependency to kernel versions.
--Armin Steinhoff Ian Prochazka wrote: > Sometime the issue is that etherCAT master loop does not need and > should not be running as tight as possible, because the computer needs > to do also some other tasks. But at the same time, the master needs to > react to slave data as quickly as possible. So master initiates > transaction with fake/not valid transmitted data in order to get data > from slaves. And just here it would be *very* useful to have > notification when data are ready to be read from master, so the master > (or rather the application above the master) could read just received > data and react to them immediately and *only then* go for a longer > EtherCAT loop period sleep. > > Ian > > On 11/21/2013 04:25, Martin Troxler wrote: >> Hi >> >> I watched that discussion about the need for a API to wait (poll) for >> received frames. I still don't get it why that is nessessary. >> >> Here is a clarification of how ethercat (process data transfer) works: >> - Process Data should be regarded as idempotent states, which means it >> doesn't matter how many times you read it. >> - it's a kind of huge shift register from the master through all slaves >> and back to the master where each slave (ESC-Chip) manipulates the >> stream of data on the fly. >> - Slaves (i.e. the firmware on microcontrollers) cannot delay the >> transmission of the frame. If there is no new data the ESC simply >> transfers the actual content of its local memory. >> - The frame transmission time is fixed for a given set of slaves and >> depends largely on the domain size and not on how fast the slave's >> microcontroller can update the data. >> >> Regards >> Martin >> >> Note: >> >> This e-mail is for the named person's use only. It may contain >> confidential and/or privileged information. If you have received this >> e-mail in error, please notify the sender immediately and delete the >> material from any system. Any unauthorized copying, disclosure, >> distribution or other use of this information by persons or entities >> other than the intended recipient is prohibited. >> >> Thank You. >> _______________________________________________ >> etherlab-users mailing list >> etherlab-users@etherlab.org >> http://lists.etherlab.org/mailman/listinfo/etherlab-users > > _______________________________________________ > etherlab-users mailing list > etherlab-users@etherlab.org > http://lists.etherlab.org/mailman/listinfo/etherlab-users > _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users