just a quick thought since I'm too lazy to pour over the spec sheet...
maybe you have a count overflow someplace? have you tried different
interrupt time periods to see how the count changes?
MS
Lima GANSE Kenneth wrote:
Hi,
actually it doesnt. In other words the same application works as long as
hardware interrupts are not used to either start or stop the timer3. I
am suggesting it has to do with how the interrupts are internally
scheduled by Tinyos, but i dont know how i can get help on that. Maybe
*tinyos schedules it to start sometime later than i am expecting*.
On the other hand i read the value of the timer even before i stop it,
and it still doesnt give me any different values.
regards
Kenneth
------------------------------------------------------------------------
From: /Harri Siirtola <[EMAIL PROTECTED]>/
To: /"Lima GANSE Kenneth" <[EMAIL PROTECTED]>,
[email protected]/
Subject: /Re: [Tinyos-help] Timer3 in TinyOS/
Date: /Thu, 17 Nov 2005 12:52:32 +0200/
>
>This is still a bit confusing. Is the "Receive.stopCount" function
>the same in both configurations? Or is the atomic statement absent
>in scenario 1? I'm not familiar with those TCCR3B bits but are you
>sure clearing them doesn't reset the counter?
>
>Regards,
>
> Harri
>
>At 10:33 AM 11/17/2005 +0000, Lima GANSE Kenneth wrote:
>
>>Hallo,
>>
>>This is what the code for scenario 2 looks like.
>>
>>/* INIT Interrupts and Timer */
>>
>>command result_t StdControl.init() {
>> sbi(EICRB, ISC51);
>> sbi(EICRB, ISC50); // Rising edge of INT1 generates an
>>interrupt
>> cbi(DDRE,5); // Making INT pin input
>> sbi(EIMSK, 5); /* Enable INT1 */
>>
>>
>> sbi(EICRB, ISC41);
>> sbi(EICRB, ISC40); // Rising edge of INT0 generates an
>>interrupt
>> cbi(DDRE,4); // Making INT pin input
>> sbi(EIMSK, 4); /* Enable INT0 */
>>
>> sbi(ETIMSK, TOIE3); // Enable Timer3 overflow
>>
>> return SUCCESS;
>> }
>>/* After Interrupt(INT1) call start to count */
>>
>> TOSH_SIGNAL(SIG_INTERRUPT5) {
>> cbi(EIMSK, 5);
>> __nesc_enable_interrupt();
>> call Receive.startCount();
>> }
>>
>>/* Start count */
>> command result_t Receive.startCount() {
>>
>> atomic {
>> outp(0, TCNT3L); // reset TIMER3
>> outp(0, TCNT3H); // reset TIMER3
>>
>> sbi(TCCR3B, CS30);
>> sbi(TCCR3B, CS31); /* Timer3 on */
>> call Leds.greenToggle();
>> //call Timer.start(TIMER_ONE_SHOT, 500); /* Version 1:
>>Timer should run for 500ms */
>> }
>> return SUCCESS;
>> }
>>
>> //event result_t Timer.fired()
>> // {
>> // call Receive.stopCount();
>> // atomic{
>> // timebtw = __inw_atomic(TCNT3L);
>> // }
>> // return SUCCESS;
>> // }
>>
>>/* After Interrupt(INT0) call stop count - comes 500ms after INT1*/
>>
>> TOSH_SIGNAL(SIG_INTERRUPT4) {
>> cbi(EIMSK, 4);
>> __nesc_enable_interrupt();
>> call Receive.stopCount();
>> }
>>
>> command result_t Receive.stopCount() {
>> sbi(EIMSK, 5);
>> sbi(EIMSK,4);
>> cbi(TCCR3B, CS30);
>> cbi(TCCR3B, CS31); /* Timer3 off */
>>
>> atomic{
>> timebtw = __inw_atomic(TCNT3L); //Read the value of
>>Timer3
>> }
>>
>> outp(0x00, TCCR3B);
>> return SUCCESS;
>> }
>>
>>/* Timer3 */
>> TOSH_SIGNAL(SIG_OVERFLOW3) {
>>
>>
>> }
>>
>>
>>
>>If you look at the code, there are two versions actually. The first
>>one(commented) starts the Timers(Timer1) and Timer3 and then waits
>>for Timer1 to fire and then reads the value of Timer3. The variable
>>timebtw is in 95% of the runs 1 and then at certain runs it goes up
>>to about 56 which is still low and wrong. I will expect that at all
>>runs it should give me about the same value.
>>
>>The other one starts a timer(Timer3) after an interrupt(INT1), and
>>then after the next interrupt comes(INT0), stops the timer and then
>>reads the value of Timer3. It behaves just the same like the
>>scenario above, which is wrong.
>>
>>Thanks again
>>
>>
>>
>>
>>
>>
>>
>>
>>From: Harri Siirtola <[EMAIL PROTECTED]>
>>To: "Lima GANSE Kenneth" <[EMAIL PROTECTED]>,
>>[email protected]
>>Subject: Re: [Tinyos-help] Timer3 in TinyOS
>>Date: Thu, 17 Nov 2005 10:36:46 +0200
>> >
>> >What platform are you on? If you could attach your interrupt
>>code,
>> >it would be easier to figure something out. How are you
>> >distinguishing between the two situations when you enter the int
>> >routine? Is it possible that you accidentally restart the timer
>>when
>> >it should just be read? I'm assuming it's the same interrupt
>>which
>> >causes both start and read.
>> >
>> >Regards,
>> >
>> > Harri
>> >
>> >At 10:30 PM 11/16/2005 +0000, Lima GANSE Kenneth wrote:
>> >>Hi TinyOS team,
>> >>
>> >>I have spent the greater part of a month trying to solve a
>>problem
>> >>without much success. These are the scenarios i have:
>> >>
>> >>Scenario 1
>> >>
>> >>1. Start two timers (SingleTimer - Timer1) and also Timer3
>> >>(SIG_INTERRUPT).
>> >>2. After 500 ms when timer1 fires, read the value of TCNT3L, to
>> >>make sure that timer3 worked
>> >> correctly.
>> >>3. The results are perfect since TCNT3L reads a value of about
>> >>15300, which matches 500ms.
>> >>
>> >>Scenario 2
>> >>
>> >>1. Now instead of two timers, use a hardware interrupt
>> >>(SIG_INTERRUP4) and Timer3.
>> >>2. When the first interrupt is detected, start timer3.
>> >>3. 500 ms after the first interrupt was detected, send another
>> >>interrupt to the mote and then
>> >> read the value of TCNT3L immediately.
>> >>4. The result makes no sense, since TCNT3L has a value between 1
>> >>and 5, which is a lot
>> >> less than 500ms.
>> >>
>> >>Is this a tinyos scheduling problem, or there is something
>> >>diffeerent that has to be done with interrupts on tinyos?
>> >>
>> >>Thanks
>> >>Kenneth
>> >>_______________________________________________
>> >>Tinyos-help mailing list
>> >>[email protected]
>>
>>https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>> >
>
------------------------------------------------------------------------
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help