[etherlab-dev] Pre-announcement: unofficial patchset update (Gavin Lambert)

Gavin Lambert gavinl at compacsort.com
Fri May 5 06:44:58 CEST 2017

Mere moments ago, quoth I:
> On 28 April 2017 11:59, quoth Graeme Foot:
> > 2) Your 0054 patch successfully moved the slave sdo request processing
> > from the master fsm's idle state to be called every cycle of the master 
> > thread.
> > However, I have my Linux environment set to run at 100Hz, so this
> > thread would only fire once every 10ms.  Each SDO read/write request
> > would take approx. 30ms to complete.  I didn't want to change Linux to
> > run at 1000Hz so I
> > created patch "etherlabmaster-0010-
> > allow_app_to_process_sdo_requests_from_realtime.patch".
> Maybe I'm missing something about how the RTAI version works, but all I
> was to move the logic from inside fsm_master to inside fsm_slave; AFAIK
> both of these execute on the same thread (either the master IDLE or master
> OPERATION thread).  This is independent of the application realtime loop
> either way, so this should not have changed how frequently they run; it
> allows multiple slave requests to run in parallel rather than forcing them
> execute sequentially, so it should be a net performance gain.
> Though it does seem reasonable in your use case to want to run the slave
> FSMs more often.  I don't see how you could do that safely, though -- you
> can't run ec_master_exec_slave_fsms outside of the master_sem lock, and
> your RTAI task might interrupt Linux while it's still holding that lock,
which will
> deadlock your RTAI task.

Are you configuring with --enable-hrtimer?  After having a quick look at the
code, I can see a potential performance degradation from the patch if you
aren't using it (or did enable it but didn't call
ec_master_set_send_interval with an appropriate value after activating the
master).  Perhaps you could try enabling that instead of using your patch
and see if it helps?

More information about the Etherlab-dev mailing list