On Mon, Apr 18, 2011 at 1:04 PM, Janos Sallai <[email protected]>wrote:
> Eric, > > This actually has nothing to do with the standard interfaces. In fact, > this reconfiguration is absolutely under the hood. Here it is, > explained a bit more in detail: > I thought an interface might be involved because you were talking about timestamping. ie. Obtaining some kind of officially maintained time... that could be used. I timestamp stuff all the time when debugging in the guts of my code. But I do it by just nabbing TAR which is ticking at 1uis. 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. > 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? > > 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? Is this something that the core msp430 code should support by default because of the telosb platform? This is clearly a platform dependancy. 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. 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. Are you perhaps thinking that this should propagate into the core files above platform? We are currently refactoring the core msp430 files with the intent of supporting the different TI families. Current support families defined are x1 (msp430f149, msp430f1611), x2 (msp430f2616-2619), and x5 (cc430f5137, msp430f5438). One of the issues that has yet to be addressed is how to deal with timers and basic clocking. What basic clocks are required by a platform? And other things. What is a reasonable abstraction boundary that for example will allow one to deal with the problem you are describing. So if you want to take a crack at defining this that would be most helpful. I can help but am busy bringing in the x5 support. > We did use this setup in > a live deployment, a fairly complex application that used the SPI bus, > serial, I2C, had multihop routing, periodic timers, allowing the mcu > to sleep, etc. > Sound good to me. What did you use for the i2c driver? what kind of chip did you talk to? > > 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. > > Janos > > > On Mon, Apr 18, 2011 at 1:42 PM, Eric Decker <[email protected]> wrote: > > > > > > On Mon, Apr 18, 2011 at 8:27 AM, Janos Sallai < > [email protected]> > > wrote: > >> > >> Hey Markus, > >> > >> The reason why I have only checked in the micaz version of the cc2420x > >> stack is that the telos timer subsystem must be reconfigured > >> "significantly" in order for the microsecond timestamping to work. > > > > If you are using standard interfaces that may be true. But the TelosB > h/w > > timer is actually ticking at 1uis (binary microsecond ticks). The main > > mis > > (binary millisecond) timer is being clocked off a 32KiHz clock. The > main > > clocks are shut down when the cpu goes to sleep. > > > >> > >> Specifically, we have to make sure two things: a) the SPI bus is fast > >> enough to download from/upload to the FIFO in real time, and b) that > >> the SFD is captured by the microsecond counter (vs. the asynchronous > >> 32khz counter). > >> > >> I have the code for this in tinyos-2.x-contrib/vu. Specifically, the > >> code that configures the timer subsystem in is tos/msp430, and the > >> altered timer map is in platforms/telosa. > >> > >> RADIO_ALARM_MICROSEC can safely be set to 1, since the mote runs close > >> to 4MHz, which when prescaled by 4 will give a microsecond timer (and > >> alarm, therefore). For the same reason, RADIO_ALARM_MILLI_EXP should > >> be set to 10. > >> > >> Janos > >> > >> > >> On Fri, Apr 15, 2011 at 5:04 AM, Markus Becker > >> <[email protected]> wrote: > >> > Hello, > >> > > >> > I was checking out rfxlink and whether it works on TelosB nodes. I > >> > didn't see > >> > support in the repository nor someone working on it on the mailing > list. > >> > > >> > So I got started with it and wired things together for TelosB: > >> > http://www.comnets.uni-bremen.de/gitweb/?p=mab-tinyos- > >> > main.git;a=commit;h=3df542e639efcaea007127b28691d45c99768bf9 > >> > > >> > rfxlink/TestTransmit compiles for telosb now at least. > >> > > >> > I don't know how to calculate the values for RADIO_ALARM_MICROSEC and > >> > RADIO_ALARM_MILLI_EXP , though. Would someone advise me please? > >> > > >> > BR, > >> > mab > >> > > >> > ------------------------------------------------ > >> > | Dipl.-Ing. Markus Becker > >> > | Communication Networks > >> > | Mobile Research Center > >> > | TZI - Center for Computing Technologies > >> > | University Bremen > >> > | Germany > >> > ------------------------------------------------ > >> > _______________________________________________ > >> > Tinyos-help mailing list > >> > [email protected] > >> > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > >> > > >> > >> _______________________________________________ > >> Tinyos-help mailing list > >> [email protected] > >> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > > > > -- > > Eric B. Decker > > Senior (over 50 :-) Researcher > > > > > > > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
