Vlado, Jan: Thanks for the comments.
It seems to me that there are two distinct points here. The first is setting SMCLK to the DCO frequency, which would allow the SPI clock to go up to DCO/2 (2MHz on the telos). The second is changing the roles of timerA and timerB, which would allow for microsecond timestamping. > 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. Well, the SPI bus clock can still be prescaled, should the peripherals have a cap on the max clock rate. That way both fast and slow peripherals can be supported (if there are no dragons ahead). As Jan wrote, it should be the USART's client component who configures the bus clock speed. If that is the case, I see no dragons ahead over there. Eric and Peter: Would you venture into setting SMCLK=DCO as the default for the new generation msp430 platforms? >>> 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. I just did a quick search for "new Alarm32khz32C()" and "Alarm32khz16C()", and indeed it appears that there is a huge pile of code (eyesIFX, tda5250, tkn154, lib/net/zigbee, etc.) that would break if there were only 3 physical (I mean non-virtualized) 32khz alarms available. I noticed though that the new z1/msp430x code uses virtualized alarms. > But keep in mind: sourcing a Timer from DCO for us-timestamping > will prevent the MCU from sleeping (LPM3), at least during Rx; That's not an issue. We have a software implementation of VHT (virtual high res timer), so we can even run FTPS with microsecond precision without having to prevent the MCU from sleeping. > Also, > the SFD capture is "physically" wired to either TimerA or TimerB pins > (e.g. telos->TimerB, shimmer-> TimerA), which will influence the > decision. Yes, this is exactly the case. I will put together a telos-specific code that allows for choosing compile time whether a) SMCLK should be DCO or DCO/4 (default), and b) selecting the timer configurations (timerB->32khz timerA->micro being the default). Janos _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
