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 <gav...@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 > > >
_______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
