Eric: >> Currently, the DCO is used as a clock source for MCLK, and MCLK/4 is >> the source for SMCLK. TimerA is driven by SMCLK without prescaling. >> The SPI clock is SMCLK/2, which is 500kHz. By reprogramming the clock >> subsystem such that MCLK without prescaling is used for SMCLK, and >> using a prescaler of 4 to drive the 1uis clock (SMCLK/4), the SPI >> clock speed will jump to 2MHz. This way, the radio stack (and other >> SPI-limited operations) will be _much_ faster. > > That is a good. thing. On the mm4 mote (2618 based) I have a SD card that > is > driven off of an SPI and I want it to run as fast as possible so I did > something > similar. All the peripherals are run off SMCLK. In general the SMCLK > should > be run as fast as possible. It is unclear why the original choice of SMCLK > = DCO/4 > was chosen. Maybe Vlado can comment, I'm pretty sure he was there. Interestingly, the msp430x also uses DCO/4 for SMCLK. Any rational for that?
>> The SFD pin of the CC2420 is connected to pin on the MSP430 that can >> capture timer/counter B but not timer/counter A. Therefore, to be able >> to timestamp with the microsecond clock, timer B must be clocked at >> 1uis, and timer A should be programmed as the 32kHz clock. (Currently, >> timer A is running at 1uis, and timer B at 32kHz.) > > okay now I understand. What exactly are you doing with SFD? Why the need > for 1uis granularity? The SFD pin is asserted when the SFD byte (after the preamble but before the payload) are received or transmitted. This is the best possible synchronization point between two motes. >> I'd really appreciate if you could comment on this. Can you think of a >> particular reason why SMCLK was set to MCLK/4?. > > I've been through the code pretty extensively and don't think that would > break anything. Anyother msp430 folks see a problem? > > With Timer B clocked off the 32KiHz clock the minimum capture granularity > is 30.5us. Do you really need uis precision? Microsecond precision timestamping is goal #1. Fast SPI is goal #2. > Is this something that the core msp430 code should support by default > because > of the telosb platform? This is clearly a platform dependancy. If you're referring to the fast SPI, than this applies to both msp430 and msp430x. If you're referring to the microsecond timestamping on the telos, then it is obviously telos specific. > Abstractly, a msp430 platform needs to provide a uis tick source and a low > power > mis tick source for long term time. But the application you are discussing > requires > additional capture symantics. What I'm describing is TEP132 and TEP133 compliance. > If the implementation details of the 1st two timing sources is hidden then > it shouldn't > be a problem moving things around to accomodate the capture issue. > >> Would it break anything >> if the clocks were set up as described above? > > I don't beleive so. But this is a platform thing should initially show up > in > platform overrides when building the image. Yes. It should go to platforms/telosb. > Sound good to me. What did you use for the i2c driver? what kind of chip > did you talk > to? A Xilinx Spartan 3 FPGA. Janos _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
