[etherlab-dev] Support for multiple mailbox protocols

[Jun Yuan]

I missed that part with slave->config->sdo_configs. You're right. The
ecrt_slave_config_sdo* functions is protected against concurrent CoE
mailbox conversation. Yet still, the etherlabmaster may have concurrent CoE
mailbox conversation with ecrt_master_sdo_download/upload functions on the
one side, and the coe dictionary fetching and slave->config->sdo_requests
on the other side.

I agree with you that it seems the "realtime" SDO requests and the SDO
dictionary fetching should belong to fsm_slave. And even with the current
etherlabmaster, the "realtime" SDO requests also have to wait when the SDO
dictionary fetching ec_fsm_master_state_sdo_dictionary is being executed.
Maybe we could break up the SDO dictionary fetching into small parts to
allow "realtime" SDO requests and slave->sdo_requests to be handled between
them. SDO dictionary fetching should have a low priority.

Regards,
Jun


On 1 July 2014 05:15, Gavin Lambert <gavinl at compacsort.com> wrote:

> On 30 June 2014, quoth Jun Yuan:
> > The slave's CoE FSM instance is not controlled by the master FSM, but
> > by the slave FSM itself. The slave FSM is responsible for the CoE
> > requests in ec_slave_t issued directly by the user via the function
> > ecrt_master_sdo_download, ecrt_master_sdo_download_complete, and
> > ecrt_master_sdo_upload. These functions can be executed either in
> > the user application before the master's activation, or in the
> > terminal in whatever time.
> >
> > The master's CoE FSM instance, on the other hand, is responsible for
> > the CoE requests which should executed in the background by the
> > master FSM, such as automatically fetch slaves' coe dictionary while
> > master is idle, those in the slave->config->sdo_requests, which could
> > be issued via the ecrt_slave_config_sdo functions (which should be
> > configured during the master's activation), or via the function
> > ecrt_slave_config_create_sdo_request (which can be issued afterwards
> > in the user application's RT thread)
>
> Actually the ecrt_slave_config_sdo* functions set up
> slave->config->sdo_configs (not sdo_requests); sending of these is managed
> by fsm_slave_config, which in turn is managed by fsm_master in such a way
> that it can't occur concurrently with anything else, AFAIK.  (fsm_slave is
> disabled until set_ready is called, which occurs later, and fsm_master
> waits for fsm_slave_config to complete before entering the idle state,
> which is where the other SDO requests are processed.)
>
> It does seem odd that fsm_master processes slave->config->sdo_requests
> (from ecrt_slave_config_create_sdo_request), while fsm_slave does
> slave->sdo_requests (from ecrt_master_sdo_*) and also all the *other*
> non-SDO ecrt_slave_config_create_*_requests.
>
> The fsm_master code seems older; maybe it was just never moved once
> fsm_slave was created?  It does mean that "realtime" SDO requests don't
> have to wait for set_ready, but I can't think why that would be desirable
> given that it doesn't apply to the other types of realtime request, and
> given that AFAIK the set_ready calls are all made before fsm_master enters
> idle anyway.
>
> Actually I'm not sure why fsm_slave shouldn't be made responsible for both
> of those things (config->sdo_requests and SDO dictionary scanning).  Doing
> that would avoid the CoE concurrency issue altogether.  (One downside is
> that all kinds of requests would then be delayed until the dictionary scan
> completed, unless this was made less monolithic.  One advantage of Frank's
> locking patch over this is that it would still allow other requests [except
> create_sdo_requests, unless they were moved to fsm_slave] to interleave
> with dictionary scanning, albeit at a slower rate.)
>
> Regards,
> Gavin Lambert
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140701/ea05126d/attachment-0002.htm>