[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
did
> 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
just
> allows multiple slave requests to run in parallel rather than forcing them
to
> 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