Hello altogether, i am currently developing support for IRIS nodes for the Avrora simulation framework, with a special focus on TinyOS applications. Simulation protocols and further investigations into the RF230 driver source have raised some questions.
According to the AT86RF230 datasheet, a transition from P_ON to TRX_OFF has a typical duration of 880µs. The driver uses a vale of 510 µs (which can be found in Atmels AT86RF230 software programming model) This leads directly to the main issue i would like to discuss: The whole driver behaves very optimistic and uses the typical values found in the datasheet as worst-case values. I have not seen any countermeasures for cases in which the radio device uses more time than this typical value, in those cases the whole radio communication might (and in fact, does if provoked in simulation cases) lock up. I have not found any line of code where the device state gets read before a state change command is issued, and no hard timeouts for cases where the radio is in a different state than expected. The reset timings appear to differ from the datasheet, too (and here again, the software programming model tells something different). According to the datasheet, the device requires a typical value of 120µs after a reset condition until it is operational again. > During the reset procedure the SPI interface shall be inactive ( SEL = H; > SCLK = L). (AT86RF230 Datasheet) To sum it up: The driver uses typical timing values as worst-case timings and does not follow any conservative approach (as stated in the datasheet on page 21). > The radio transceiver state is controlled by two signal pins (SLP_TR, RST ) > and the > register 0x02 (TRX_STATE). A successful state change shall be confirmed by > reading > the radio transceiver status from register 0x01 (TRX_STATUS). (AT86RF230 Datasheet) Despite of all this issues, the driver appears to work on real devices. I assume the datasheet contains values with rather large safety margins, but in my opinion, violating those specifications is not good. Especially because the datasheet provides the only mandatory device characteristics for building a simulation. Regards, Markus Jung Oh, and by the way: The sequence > call RSTN.makeOutput(); > call RSTN.set(); in PlatformInit.init() might issue undefined behaviour (by default, an AVR pin is configured as input/low, by configuring it as output before setting the desired value, there is an state between with output/low). This short glitch violates the minimum reset pulse width of 625ns. _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
