[Tinyos Core WG] TEP 116 last call

[David Moss]

Sounds good, Phil.  I'll update the CC2420ReceiveP to fill in the actual
size of the payload instead of the maximum size of the payload.
-David


-----Original Message-----
From: Philip Levis [mailto:pal at cs.stanford.edu] 
Sent: Wednesday, March 28, 2007 5:12 PM
To: David Moss
Cc: 'TinyOS Core WG'
Subject: RE: [Tinyos Core WG] TEP 116 last call

On Wed, 2007-03-28 at 14:45, David Moss wrote:
> The Receive interface defines two "len" variables with the same name and
> different meanings.  This is probably intentional due to the reflection of
> the Packet interface in Receive, but it tripped me up.  Maybe the variable
> name itself should indicate what type of length it is?
> 
> "len" in this case is actual size of the payload:
> event message_t *Receive.receive(message_t *msg, void *payload, uint8_t
> len);
> 
> "len" in this case is the maximum size of the payload: 
> command void *Receive.getPayload(message_t *msg, uint8_t *len)
> 
> I expected the latter to be the actual size of the payload like the rest
of
> the Receive interface, but had to refer to the TEP to understand what was
> going on.  On receive, we're interested only in the actual size of the
> payload, not the maximum size the payload could be... even though
> Packet.getPayload() returns the max, which I agree is still completely
> valid.
> 
> Maybe changing "len" in each to "maxLen" or "actualLen" would make it
> clearer?  Alternatively, changing the behavior of Receive.getPayload() so
> that it fills in the actual length would also make sense.

Nice catch! I think your intuition is right. Receive.getPayload() should
fill in the actual length (it does so on the CC1000, serial, tda5250,
and xe1205). But the CC2420 doesn't; this is a bug:

  command void* Receive.getPayload(message_t* m, uint8_t* len) {
    if (len != NULL) {
      *len = TOSH_DATA_LENGTH;
    }
    return m->data;
  }

Phil