[etherlab-users] waiting for received frames
armin at steinhoff.de
Fri Nov 22 01:19:48 CET 2013
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.
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.
> On 11/21/2013 04:25, Martin Troxler wrote:
>> 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.
>> 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 at etherlab.org
> etherlab-users mailing list
> etherlab-users at etherlab.org
More information about the Etherlab-users