On 2014-07-08 13:55, Gavin Lambert wrote:
On 8 July 2014, quoth Dave Page:A brief look at the SSC suggests the master is responsible for specifying the mailbox size each transfer via the Length parameter in the mailbox header. The FMMU mailbox protocol requires the last mailbox byte to be accessed to hand over the mailbox buffer. So, the fieldbus must transfer the full mailbox size (or utilize two transfers?).Yes, but the point that I was trying to get at is that the master is responsible for configuring the FMMU size (during the INIT=>PREOP transition) in the first place.
Indeed that was my point as well.
I tend to lean toward the latter option though -- making things robust even in the face of bad setup.
Be liberal in what you accept, and conservative in what you send. - RFC 1122
The mailbox cannot be larger than 1486 octets, so the master shall (must) support mailboxes up to this size. And if the resultant mailbox does not fit in the frame with other data (e.g. process), a new frame shall be generated to contain the entire mailbox absent the other data.
On the other hand, if the SII code were temporarily hacked to force a smaller mailbox, the various slaves could be tested to determine their idiosyncrasies in the context of your proposal. A compiler define such as DEBUG_FORCE_MAILBOX_SIZE would do the trick.
Best regards - Dave
[ Honestly, I would be happier if the ETG would tighten the qual
process so slaves with invalid SII data were rejected (vendor
regardless). This would be enhanced by some better tools to ensure the
SII is properly generated from the XML or whatever. The policy of
ignoring the slave advertised configuration because it is too hard for
vendor to store a few KiBs of data is ill-advised and silly. A 24C64 is
0.165USD. USB has been doing this for decades. It is not even worth the
time to discuss. For my project, I disqualify any product with invalid
SII information -- for if they cannot get that simple problem right,
what other problems do they have? If no customer ever pushes back, what
reason is there for the vendor to do a good job? Moral hazard.]
<<attachment: dave_page.vcf>>
_______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
