Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 22 Jun 2010 10:04:16 -0600

> In section 3.1 we are told that the maximum short form 
> payload length is 0x4000 bytes, but in the code the 
> maximum generated payload length appears to be 0xFFFE bytes.
> 

Correct, but payload 8 byte boundary (double) alignment constraints impose
this limit to be, in practice, 0xFFF8 bytes.

> Also, presumably, the statement that extended headers 
> cannot be used for short payloads is unnecessarily restrictive?

Correct

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

> -----Original Message-----
> From: [email protected] [mailto:core-talk-
> [email protected]] On Behalf Of Michael Abbott
> Sent: Wednesday, June 02, 2010 3:22 AM
> To: EPICS core
> Subject: EPICS protocol header
> 
> While working on rsrv/camessage.c, I've noticed a curious discrepancy
> between the header preparation code in cas_copy_in_header() and the
> protocol document at
> 	http://epics.cosylab.com/cosyjava/JCA-
> Common/Documentation/CAproto.html
> 
> In section 3.1 we are told that the maximum short form payload length is
> 0x4000 bytes, but in the code the maximum generated payload length
> appears
> to be 0xFFFE bytes.
> 
> Presumably, as this code has been in use for quite a long time, the
> protocol document is in error, or perhaps is a little unclear?  As I read
> it, the document is saying that the extended header must be used for
> payloads longer than 0x3ff0.
> 
> Also, presumably, the statement that extended headers cannot be used for
> short payloads is unecessarily restrictive?

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System