[etherlab-users] Maximum mailbox size?

[Dave Page]

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.]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dave_page.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20140708/9ad808b9/attachment-0005.vcf>