I believe all the instruments are there, it's just a job of the platform(-maintainer) to use them:
- it's a platform-specific decision which Timer module provides the 32 kHz clock, it can be changed by shadowing the Msp430Timer32khzMapC (e.g eyesIFX or shimmer do that). If a platform decides to source TimerA from the 32 kHz quartz, then there may be a penalty (some alarms may need to be virtualized), but I don't see a real problem there. But keep in mind: sourcing a Timer from DCO for us-timestamping will prevent the MCU from sleeping (LPM3), at least during Rx; and also TimerA may temporarily be used by other components (ADC12). Also, the SFD capture is "physically" wired to either TimerA or TimerB pins (e.g. telos->TimerB, shimmer-> TimerA), which will influence the decision. In general I'd tend to leave the default case like it is (TimerB = 32 kHz, TimerA = "unused"). - it should be the USART's client component that configures the SPI bus speed, e.g. for CC2420 it may be max. (DCO/2). The configuration code is platform-specific, and for the CC2420 the hook seems to be HplCC2420SpiC.nc, which is already shadowed by all relevant platforms. The platform could set the configuration for the CC2420 e.g. via Msp430SpiConfigure interface provided by the Msp430SpiXC. - the platform should set intial DCO speed, e.g. to 8 MHz if supported like on Tmote Sky. On msp430 the hook is provided by Msp430ClockC (Msp430ClockInit interface). I'd be happy to help providing/testing some of the code for telosb/tmote sky/telosa, question is: who is currently the official maintainer of those platforms? Jan On Tue, Apr 19, 2011 at 1:16 AM, Vlado Handziski <[email protected]> wrote: > On Mon, Apr 18, 2011 at 23:18, Eric Decker <[email protected]> wrote: >> 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. >> > I guess there are several reasons for the SMCLK=1MHz decision. First this > config has long tradition in the general msp430 community and TI example > code) and was considered a safe choice for the set of peripheral chips that > we had to support at that time. For example, 500 kHz SPI bus clock is > pushing the limits of the TDA5250 radio on eyesIFX. >>> >>> 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.) >> >>> >>> One potential difference from the original clock setup is that in this >>> case we are left with only 3 timer compare interfaces for the >>> 32khz/1mis clocks, versus 7 in the original case. >> >> Actually, putting the 1mis clock on TimerA gives 3 CCRs and the 1uis clock >> on TimerB gives 7 CCRs for the uis clock. >> >>> But since the 1mis >>> clock is virtualized, this should not be a limitation. >> >> In practice the additonal compare capture registers aren't utilized. If >> they do get >> used it is a special app that needs to handle the situation itself. > > There are many platform-specific telosB applications out there that use more > than three jiffy alarms, so I would be very careful with going down this > road only because of the way the CC2420 SFD is wired or not wired to the MCU > on a given platform. > Vlado > _______________________________________________ > tinyos-msp430 mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-msp430 > > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
