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

[Gavin Lambert]

On 28 April 2017 11:59, quoth Graeme Foot:
> First off, I also prefer #3.  I use buildroot to create my Linux
environment and
> buildroot applies patches in alphabetical order (at least in my version
which is
> now pretty old), so the number at the front is important.  Buildroot also
> requires that the patch starts with the name of the package (and
optionally a
> revision number), but that is easy for me to prefix.

FWIW, it looks like buildroot does follow a series file if one is present,
so you could just take the series file that's supplied with the patchset and
comment or delete from it the patches you're uninterested in, and add
additional ones of your own.

> When I tried to use your patchset (and the EtherCAT revision they were
for)
> the computer would freeze just after starting my application and going
> realtime.  We use RTAI and I read your notes re that it wasn't tested with
> RTAI.  I didn't have much time to look into problem but I suspect there
may
> have been a lock that ended up in a call from the realtime context that
was
> blocked due to be held in the master thread.

I suspect this is probably either patch 0007, patch 0011, or patch 0030.  If
you do get a chance to look into it, it'd be good to confirm that.  I'm
considering wrapping one or more of these in a configure --enable (or
otherwise disabling them when RTDM is enabled).

> I ended up cherry picking the changes I needed (patch 0054 (sdo requests 
> via slave fsm) and 0038 (sdo write request)).

That could be a little dangerous; the 005x patches are highly dependent on
prior patches and it's probably very bad to run 0054 without 0050-0053.

> As to other potential patches (Note: my patches are against 2526
> (2eff7c993a63) on the stable-1.5 branch):

Thanks, I'll look at including these too.

> 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.