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