Hi,
I was having a look through the master source and I think I've found a
potential problem, if I'm reading it correctly.
It looks like the master FSMs are expecting that when they poke an FoE
datagram (for example) into the master->slave mailbox then when data appears
in the slave->master mailbox it can only possibly be the corresponding FoE
response, and they'll discard any protocol type that they're not expecting.
(And I'm not just picking on FoE -- CoE does the same thing.)
This doesn't seem correct. Mailboxes are inherently an asynchronicity
mechanism and I would think there's no particular reason why a slave
couldn't post a CoE, EoE, or emergency response to the mailbox before it
posts the FoE response.
While the master could control these to some extent (eg. not posting FoE
requests while waiting for CoE responses) I think there are still some
things (such as emergencies) that the slave is allowed to post unsolicited.
I haven't looked into how things like EoE work but I would think that they
could also be unsolicited.
I think a more robust solution would be to always scan for and fetch data
out of the slave->master mailbox, and then queue these to the appropriate
protocol-specific FSM to handle as they arrive, according to the type
specified in the data itself (so that while FoE was waiting for a response
it could successfully process a CoE or EoE response, for example).
And once this was done the master could then potentially intentionally
interleave its requests to improve performance, eg. to exchange SDOs while
waiting for an FoE or EoE transfer to complete. (Though this might need a
per-slave setting to enable/disable, as some slaves might not support
interleaved requests.)
Does that make sense, or have I missed something?
Regards,
Gavin Lambert
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
