We don't have to worry about platform specific word alignment peculiarities as long as we stick to nx_structs and nx_unions. The cc2420x stack I wrote using rfxlink works on the both the msp430 and the atmega128 with the same message_t definition.
Regarding Packet.clear(): would it make sense for the new message_t to have a dirty flag in message_t which wouldn't allow the message buffer to be reused without calling Packet.clear() first? Sure, checking it would have a runtime overhead, but we could just have a define to turn that off for production builds. Janos On Thu, Dec 9, 2010 at 1:57 PM, Stephen Dawson-Haggerty <[email protected]> wrote: > On Thu, Dec 9, 2010 at 12:29 AM, Miklos Maroti <[email protected]> > wrote: >> Hi Stephen, >> >> On Thu, Dec 9, 2010 at 2:17 AM, Stephen Dawson-Haggerty >> <[email protected]> wrote: >>> On Thu, Dec 9, 2010 at 1:05 AM, Miklos Maroti <[email protected]> >>> wrote: >>>> Hi Stephen, >>>> >>>> Ok, I understand that. Then what about updating the retry count ONLY >>>> if it is nonzero? >>> >>> What if we updated it to really be the number of retries, rather than >>> the number of tries? That would be okay with me, I think, and would >>> make it all consistent. >> >> Morten's former email described the situation as: >> >> 0: on retry, leave packet ack intact (can be with or without ack) >> 1: no retry, enable packet ack >> 2: one retry, enable packet ack >> >> We should make all programs behave the same was if it does not care >> about packet link. This means, that if the retry count is 0, then we >> should 1) not disable packet ack, 2) we should not update the retry >> count. > > If the programs want consistency, they need to call Packet.clear() > before reusing a message buffer, which will set retries to zero -- > they have always needed to do this independent of packetlink. Just > worth noting. > > Anyways, this describes how it *currently* works? And the only change > we're discussing is to NOT update the retry field when it was > initially zero? > >> >> By the way, I think currently the code is actually sets the retry >> count to the actual send count. So we should change the code as I >> suggested first. >> >>>> Also, as Morten writes it here: >>>> https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-February/004239.html >>>> we should CLEAR the ACK flags if the retry count is 0, no? >>> >>> I agree with that change. >> >> With my previous analysis this change should not be made since it >> would alter the behavior of programs that do not care about packet >> link. >> >>>> By the way, does the retry count need to be 16-bit? >>> >>> I doubt it :), although it would probably be padded out on 16-bit >>> platforms anyways... >> >> No, I think it would not, but I am not sure. If the MCU is padding >> 8-bit numbers with an extra byte, then that would have very bad >> consequences in the message_t. Again, I do not know the padding >> behavior, but I would like to know more about this on the msp430. > > The MCU doesn't insert the padding -- the compiler does. Pretty much > everything is going to be word-aligned on the msp430 which means a > char will often end up being 16 bytes; the alignments are actually set > in the .platform file. > > Steve > >> >> Best, >> Miklos >> >>> >>>> >>>> No more questions :) Best, >>>> Miklos >>>> >>>> On Thu, Dec 9, 2010 at 1:24 AM, Stephen Dawson-Haggerty >>>> <[email protected]> wrote: >>>>> As I remember, the reason is so the app can determine how many >>>>> link-layer retransmissions actually occurred. If we remove it we >>>>> should provide another way to determine this information since it's >>>>> important for link estimation. >>>>> >>>>> Steve >>>>> >>>>> On Thu, Dec 9, 2010 at 12:20 AM, Miklos Maroti <[email protected]> >>>>> wrote: >>>>>> Hi Guys, >>>>>> >>>>>> Morten and Philipp suspect that there is a bug in the >>>>>> PacketLinkLayerP, which was adopted from the CC2420 PacketLinkP file. >>>>>> The problem is that before signalling the sendDone event the code >>>>>> CHANGES the currently set retry count to the number of times the >>>>>> packet was actually sent. Read Philipp description below. >>>>>> >>>>>> Can someone tell WHY the CC2420 code changes the retry count before >>>>>> the sendDone event? This has subtle consequences, and I think it >>>>>> should be removed BOTH from the RFXLINK and CC2420 drivers. >>>>>> >>>>>> Best, >>>>>> Miklos >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Philipp Sommer <[email protected]> >>>>>> Date: Wed, Dec 8, 2010 at 4:20 PM >>>>>> Subject: Possible bug in PacketLinkLayerP >>>>>> To: Miklos Maroti <[email protected]> >>>>>> >>>>>> >>>>>> Hi Miklos, >>>>>> >>>>>> I think there is a bug related to acknowledgment request in the packet >>>>>> link layer: >>>>>> >>>>>> The signalDone() method in PacketLinkLayerP sets the number of retries >>>>>> for each successfully transmitted packet (even when no retransmits >>>>>> were requested). Therefore, the "maxRetries" field in the metadata is >>>>>> greater than zero when the message_t buffer is passed back to the >>>>>> application. When the same buffer is used for the next outgoing >>>>>> message, PacketLinkLayerP.send() will request an ACK for this packet >>>>>> (even if it should not) since maxRetries is larger than zero. The >>>>>> problem is that maxRetries is never cleared (since the application >>>>>> might not even know that the packet link layer is being used, for >>>>>> example RadioCountToLeds). >>>>>> >>>>>> Regards, >>>>>> >>>>>> Philipp >>>>>> >>>>>> >>>>>> tos/lib/rfxlink/layers/PacketLinkLayerP.nc: >>>>>> ================================= >>>>>> void signalDone(error_t error) { >>>>>> message_t* msg = currentSendMsg; >>>>>> currentSendMsg = NULL; >>>>>> >>>>>> // AT: A bit of a hack to be able to keep track of the number of >>>>>> retries >>>>>> // printfUART("Signaling done with total retries at 0x%x\n", >>>>>> totalRetries); >>>>>> >>>>>> call DelayTimer.stop(); >>>>>> call PacketLink.setRetries(msg, totalRetries); >>>>>> signal Send.sendDone(msg, error); >>>>>> } >>>>>> >>>>>> _______________________________________________ >>>>>> Tinyos-devel mailing list >>>>>> [email protected] >>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> stephen dawson-haggerty >>>>> http://cs.berkeley.edu/~stevedh >>>>> uc berkeley wireless and embedded systems lab >>>>> berkeley, ca 94720 >>>>> >>>> >>> >>> >>> >>> -- >>> stephen dawson-haggerty >>> http://cs.berkeley.edu/~stevedh >>> uc berkeley wireless and embedded systems lab >>> berkeley, ca 94720 >>> >> > > > > -- > stephen dawson-haggerty > http://cs.berkeley.edu/~stevedh > uc berkeley wireless and embedded systems lab > berkeley, ca 94720 > > _______________________________________________ > Tinyos-devel mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
