Hi Andreas, I see you're reasons, but I disagree. This bit on the RFA1 is reserved, it's very ugly to use it. There are other small changes in the radio registers, and not all can be worked around with such tricks (for example the PA_LT bits moved to an other register). I think the proper solution would be to create an atmxrfr2 directory in the chips, and include it first in the platform file, than the rfa1 directory. If there are really small changes, we can think about a merge with ifdefs, but for now, it's better to separate them.
Best, Andras On Fri, Oct 17, 2014 at 4:39 PM, Andreas Weigel <andreas.wei...@tuhh.de> wrote: > Hi everyone, > > Suggestion: Add the following line somewhere to the init code: > RX_SYN &= ~(1 << 6); > > Rationale: > I just had some "fun time" with a self-made C-port (not very beautiful, > but it does its job) of the atm128rfa1 RFA1DriverLayerP (and the > corresponding rfxlink layers). > > Letting four ATmega256rfr2-based nodes send out broadcast packets as > fast as possible (having the whole stack in place, including backoffs > etc.), lead to RADIO_ASSERT(!radioIrq) being triggered in the RX_END > ISR. After some happy debugging and thinking (is my protocolstack > actually to slow in processing the tasklet code stuff?) I was sure that > this should not be possible. > > I then stumbled across a new and greatly-documented feature of the rfr2 > named RX_OVERRIDE, which is enabled on this chip by default (who does > such things?). This seems to lead to RX_END interrupts which are > triggered very soon (< 20 us) after the corresponding RX_START. In rare > circumstances when RX_START was interrupted again by the RadioAlarm > interrupt (and correspondingly, the TosRandomCollisionLayer > RadioAlarm.fired() code was executed), service_radio got deferred long > enough to allow for the RX_END to occur and the RADIO_ASSERT to happen. > Deactivating RX_OVERRIDE solved the problem. > > I do not know (as I could not try out or know how fast the actual TinyOS > stack handles the code), if this problem would really affect an > ATmega256rfr2 running TinyOS (which I did not), but I think it at least > very possible. Considering this, I suggest to add the code shown above > to the init function of the driver to make the current radio driver safe > for all rfr2-type chips (also in case someone "ports" the code to rfr2 > and is -- like me -- unaware of this new feature), so that other people > are spared the pain I just lived through during the last few days > > Regards, > Andreas > _______________________________________________ > Tinyos-help mailing list > Tinyos-help@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
