On Tue, Apr 19, 2011 at 2:45 PM, Janos Sallai <[email protected]>wrote:
> 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. > *Point 1: SMCLK/DCO* With regards to SMCLK. All peripherals can prescale the SMCLK before use so having SMCLK be set to DCO is a reasonable thing. Now what the DCO is set to varies by platform. For example the 1611 has a max clock of 8MHz (decimal). And by default the telosb sets it up for 4MiHz. The x2 parts (2617, 2618) get set up for default of 8MiHz (16MHz max). Seemed like a reasonable thing to do. The x5 default is 16MiHz. This of course makes the configuration blocks platform dependent. And right now config blocks are supplied by Application level stuff. Which of course makes Applications platform dependent which is kind of a pain but a reasonable trade off. See below. I really like config blocks because they are very very efficient by design. This is a good thing in a resource constrained environment using Arbiters. Reconfiguring is very efficient and it happens a lot as devices are obtained and released. What we need is a reasonable minimal spec for the low level OS/platform interface for the msp430 families. I'll start to keep notes along those lines. It needs to include what is provided and why. Also any restrictions/ramifications. For example one restriction with SMCLK. If one makes SMCLK too high then one runs out of prescaler for the timer and can only get 500nis ticks. I don't know how far the assumption of 1uis ticks goes. Note this is only an issue for the x2 parts running > 8MiHz because the prescaler only goes to /8. On the x5 parts they added additional prescalers so we can go > 8MiHz while maintaining the 1uis ticker. The x5 parts can go up to 25MHz (and is why the default is 16MiHz). One question I have is just how buried is the 1uis tick in the T2 code? I know that the 32KiHz clock drives TMilli. I'm pretty sure we should be able to hide a 500nis tick behind the abstraction boundary. But famous last words. *Bottom line is clock set up is a per platform kind of thing. Has to be.* But I don't see any reason not to have the default cranked up to DCO. *Point 2: Roles of TimerA and TimerB* Given that Timing is a per platform thing. There isn't any reason these can't be switched. However, as Vlado mentioned there are some folks who need to have additional clock/timing sources and they make use of the additional h/w resources. But as also mentioned these can either be moved to the other Timer (with more CCR resources) or a virtual interface can be added using underlying support. Clearly a platform thing. But one question is what should the default be. Until sometime becomes pretty obvious I don't see a good argument for changing from the current default. But this of course will perhaps change as we get more experience with newer msp430 chips. Newer chips have different Timer arrangements so will impact this thinking. > > 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. > At the time this probably made sense but is now a historical artifact. Things were much slower back then. This can also be handled by tweaking config blocks to have different prescalers for the SPI bus. > > 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? > The current msp430 integration branch.... has this already set. At least for anything beyond the x1 family. I have to check what is done for the telosb. I'm pretty sure I left that alone because I didn't want to deal with the backward compatability issues and the chance that I would break something. I also managed to lose my telosb. Which makes testing rather difficult. Sigh. I would encourage folks to take a gander at the msp430.git integration branch. The tip is mm-z1 which is the integration of the x2 parts into the main msp430 support. It is the foundation for the next msp430 release which will support x1 (149, 1611), x2 (2617/2618) and x5 (cc430f5137/msp430f5438). It is tracking the main T2 SVN trunk. Email me if you want instructions and/or help looking at it and trying it out with your current code. That would be a really good thing (tm). > 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. > Can you point me at what you were looking at in the z1/msp430x code? I've collapsed most of the z1 code, been through their timer code, and don't recall running into this. So would like to understand what you are looking at. > > 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. > Can you give me a pointer.... I'd really like to look at what your are doing there. > > > 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. > It impacts the decision for how it is implemented for that platform. Which argues for an abstraction that hides it above the Platform level. Its all basically platform stuff. And this also argues that code that has visibility of how many hardware capture registers/alarms is broken and needs to be refactored. That code reached too deep into the h/w. 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). Why compile time? I would think given a platform configuration it should just always be that way for the given platform. Then document it appropriately. I don't see what adding compile time variability does to help folks understand what is going on. Keep it simple. > > > Janos > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
