[etherlab-dev] Support for multiple mailbox protocols

[Gavin Lambert]

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