<div dir="ltr"><div><div><div>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.<br>


<br></div>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.<br>

<br></div>Regards,<br></div>Jun<br><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 1 July 2014 05:15, Gavin Lambert <span dir="ltr"><<a href="mailto:gavinl@compacsort.com" target="_blank">gavinl@compacsort.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 30 June 2014, quoth Jun Yuan:<br>
<div class="">> The slave's CoE FSM instance is not controlled by the master FSM, but<br>
> by the slave FSM itself. The slave FSM is responsible for the CoE<br>
> requests in ec_slave_t issued directly by the user via the function<br>
> ecrt_master_sdo_download, ecrt_master_sdo_download_complete, and<br>
> ecrt_master_sdo_upload. These functions can be executed either in<br>
> the user application before the master's activation, or in the<br>
> terminal in whatever time.<br>
><br>
> The master's CoE FSM instance, on the other hand, is responsible for<br>
> the CoE requests which should executed in the background by the<br>
> master FSM, such as automatically fetch slaves' coe dictionary while<br>
> master is idle, those in the slave->config->sdo_requests, which could<br>
> be issued via the ecrt_slave_config_sdo functions (which should be<br>
> configured during the master's activation), or via the function<br>
> ecrt_slave_config_create_sdo_request (which can be issued afterwards<br>
> in the user application's RT thread)<br>
<br>
</div>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.)<br>


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


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


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


<br>
Regards,<br>
Gavin Lambert<br>
<br>
<br>
</blockquote></div><br><br></div></div></div></div>