On Wednesday 12 September 2007 04:59:46 am Leonardo wrote: > Steve McKown ha scritto: > > On Tuesday 11 September 2007 12:27:31 pm Leonardo wrote: > >> Steve McKown ha scritto: > >>> On Tuesday 11 September 2007 08:48:49 am Leonardo wrote: > >>>> Steve McKown ha scritto: > >>>>> On Tuesday 11 September 2007 08:25:14 am Leonardo wrote: > >>>>>> Hy guy, > >>>>>> I need to help. I want to capture the clock of my telosb. I know > >>>>>> that i have to use MSP430 but how? > >>>>>> how can I get the clock with MSP430? > >>>>> > >>>>> Two questions: which clock do you want to get, and how do you want to > >>>>> get it? For the former, the msp430 maintains a number of clocks, for > >>>>> example, MCLK, SMCLK, ACLK. For the latter, are you wanting to > >>>>> expose the clock to a digital output pin for use by a bit of add-on > >>>>> hardware, or do you want to expose it to a software component to > >>>>> trigger some action? > >>>>> > >>>>> Steve > >>>> > >>>> i need to get the clock because i have to sincronized my wireless > >>>> network. i have to get the clock and set the clock on my telosb. i > >>>> didn't know that there are many clock in telosb, but I need to only > >>>> one. Thanks for help me > >>> > >>> You probably want to look at the msp430's Timer B, which is wired in > >>> TinyOS to the 32KHz crystal. This clock runs even in sleep mode, which > >>> is probably what you need to deal with timed radio events. The > >>> standard TinyOS Timer<TMilli> is a software timer attached to Timer B. > >>> There may be a 32KHz resolution Timer<xxx>; I don't recall off the top > >>> of my head. > >>> > >>> So I presume that you'll pass around some kind of timebase or offset in > >>> radio packets between nodes, when the nodes can then use to determine > >>> which next to transmit or receive. You probably can't manage more than > >>> a gross coordination without digging into the radio's software stack. > >>> > >>> If you can, try to use the LPL (low power wireless) mode of the cc2420 > >>> radio stack. It's already there and works pretty well. If you need > >>> something else, check the TEPs; there's one that covers the software > >>> layers in the new stack, and you could create your own layer to > >>> implement a new timing policy if that's what you need. > >>> > >>> Cheers, > >>> Steve > >> > >> Thanks for you help Steve, but I have another problem and i think my > >> english don't help me :D > >> I need to get and set the clock of my process for sicronized my > >> telos..... the problem is that i don't know the way to get and set the > >> clock.... Do you understand me now? Sorry for my english > >> > >> In my project i have to send the clock of master on network in the > >> beacon message. The slave get the clock and set its clock. in this way > >> they are sincronized because in the beacon vector there is the correcly > >> sequence to transmit and receive the data message. and in this way each > >> node rise up at the right moment. > > > > I don't think you need synchronized clocks per se, since you can use the > > the beacon itself to find a common point in time (t0) between beacon > > sender and receivers. Then, to sechedule future events, one schedules t0 > > + deltaT. There's some timing feedback in the radio stack to help find > > t0. So all you need is a clock source with suitable granularity and > > precision, and a way to manage the latency between desired and actual > > event timings. > > > > If you are implementing something like the beaconed protocol that's part > > of 802.15.4, I *think* you can get by with a crystal-derived 32KHz clock, > > as available on the TelosB platforms. Even though the new cc2420 radio > > stack is modular, creating a new layer to implement a beacon-timed > > network protocol is going to be a big job. To get back to your original > > question, I'd expect you might use an Msp430Timer32khzC component for > > scheduling future timed events. You'll need a good understanding of the > > interrupts that can occur in the system which could cause your radio > > events to be deferred for a period. Not to mention getting to know the > > radio stack itself very well. > > > > If, on the other hand, you are creating something with far looser timing > > requirements, say a 100ms or larger granularity, then maybe you can get > > by with using Timer<TMilli> to set future events and using > > ActiveMessageC's SplitControl interface to initiate future communications > > at the right time. > > > > Steve > > Thank Steve, I understand all. But I have another question now: in my > code now write in this way: > > BeaconN.nc > ...... > uses Interface MSP430Timer; > ....... > and in this file: > BeaconC.nc: > .... > components new MSP430Timer32khzC() as MSP430Timer; > .... > BeaconM.MSP430Timer -> MSP430Timer; > > in this way do it caputer the clock that i want? > > when i write: now= call MSP430Timer.get(); in now is there my clock?
Yes, this command returns the current value of the TxR attached via wiring to the Msp430Timer interface. You probably want to look closer at the available capture and compare interfaces instead. The former can be used to get the TxR value when a specific event occurs (usually a GPIO line changing state). The latter can be used to cause an event at a given TxR value. In my experience, get() isn't all that useful because the value returned is associated with the time get() is called. Generally, I'd expect the more interesting is the value of the TxR when a particular event occurs. So, if you can have the event feed into a capture interface (like GpioCapture), then your code gets the clock's time value at the time of the event independent of what software is doing at the time. The cc2420 radio stack uses this approach to provide timing information on SFD state changes. Another comment is to go as high up the architecture as possible with your timing interface. For example, the components implementing GpioCapture interface does most of what you can do with Msp430Capture but in a uC-independent manner. Similarly, perhaps you can use the Alarm interface (implemented by the msp430's Alarm32khz16C component) instead of Msp430Timer32khzC for a more platform-independent timed event controller. Cheers, Steve _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
