bug: OS_DelayTS gives wrong delay in AVRs

[lattenzaun]

Hello,

I am using salvo lite for Atmel AVR v3.2.3 with avr-gcc3.3.1. When calling OS_DelayTS in a task together with some runtime exessive code the delay time is wrong. If the "runtime exessice code" takes more the 1 system tick the delay time of OS_DelayTS is shorter then expected.

I changed salvo ut u5main.c in this way:

code:

---

void TaskBlink( void )
{
static int16_t someTime;
    InitPORT();
    for (; ;) {
        someTime=0;
        do{
           someTime++;
        }while (someTime < 500);     //this calculation takes 5 ticks
        PORT ^= 0x01;
        OS_DelayTS(20, TaskBlink1);  //the for-loop repeats all 15 ticks instead of all 20 ticks!
    }
}

---

I would be grateful for some help or bug-fix!

Regards,
Martin

[This message has been edited by lattenzaun (edited January 05, 2004).]

[This message has been edited by lattenzaun (edited January 05, 2004).]

[lattenzaun]

x

[This message has been edited by lattenzaun (edited January 05, 2004).]

[aek]

Hi Martin.

At what rate are you calling OSTimer()?

And what results do you see if you use OS_Delay()? 25 ticks between port toggles?

------------------

[lattenzaun]

Hello,

the problem is not the rate I'm calling OSTimer(), but it is an incompatibility of salvo with runtime-use of more than 1 tick of salvos system timer.

Now I have changed the rate of OSTimer() to 4ms and the while-loop to ...}while (someTime < 20000); it takes 25.2ms run-time.

I expected to get 80ms scheduling in the for-loop, but it runs all 56ms.

code:

---

void Init( void )
{
    TIMSK  = 1<<TOIE0;    /* Timer0 Overflow Interrupt enable */ 
    TCCR0  = 0x03;        /* Start Timer0 with clk/64 */ 
}
SIGNAL(SIG_OVERFLOW0)
{	
    TCNT0 = TCNT0 + 6;    /* 256-250=6 250*64/4MHz = 4ms timer rate */ 
    PORTB ^= 0x02;        /* I have double checked that - really 4ms! */
    OSTimer();
}
....
void TaskBlink( void )
{
static int16_t someTime;
    InitPORT();
    for (;;) {                       /* for-loop repeats all 56ms, but it should all 80ms */
        someTime=0;
        do{
          someTime++;
        }while (someTime < 20000);   /* while-loop takes 25.2ms */
        PORT ^= 0x01;
        OS_DelayTS(20, TaskBlink1);
  }
}
void main( void )
{
    Init();
    OSInit();
    OSCreateTask(TaskCount, TASK_COUNT_P, PRIO_COUNT);
    OSCreateTask(TaskShow,  TASK_SHOW_P,  PRIO_SHOW);
    OSCreateTask(TaskBlink, TASK_BLINK_P, PRIO_BLINK);
    OSCreateBinSem(BINSEM_UPDATE_PORT_P, 0);
    counter = 0;
    OSEi();
    for (;;)
        OSSched();
}

---

Regards,
Martin

[aek]

Hi Martin.

quote:

---

the problem is not the rate I'm calling OSTimer(), but it is an incompatibility of salvo with runtime-use of more than 1 tick of salvos system timer.

---

I doubt that ... the latest version of Salvo can accumulate up to 255 "lost ticks" before losing sync.

I don't know what the effect of lost ticks is on OS_DelayTS() .... but it should handle OS_Delay() just fine.

Which AVR is your target? I'll take a look at it here ...

------------------

[This message has been edited by aek (edited January 06, 2004).]

[lattenzaun]

Hello,

I am using an ATmega8 at 4Mhz.

Now I again replaced OS_DelayTS by OS_Delay in the example below. In this case the for-loop repeats all 80ms. But I expected it to repeat all 108ms (108ms = 80ms + 25.2ms rounded to next 4ms tick). So I think even OS_Delay does not work properly.

Regards,
Martin

[aek]

Hi Martin.

1st test (8515 @ 4MHz, ICCAVR (because I find it easier to use ...), someTime < 2000, OS_Delay(), breakpoint on TaskBlink()'s PORT ^= line ...:

Breakpoints occur every 80ms, no problem.

2nd test: same as #1, but with OS_DelayTS():

1st breakpoint at 72ms, 2nd @ 144ms, 3rd @ 216ms ... looks like there's a timing issue when ticks are lost using OS_DelayTS() ... not terribly surprising, as Salvo does expect OSTimer() to be called every system tick. Will look into this further.

3rd test: use AVR-GCC instead:

Results make no sense -- it's as if OS_Delay() isn't doing anything ... will investigate further.

------------------

[aek]

Hi Martin.

quote:

---

So I think even OS_Delay does not work properly.

---

No, OS_Delay() is working properly.

OS_Delay() will delay the task by the specified number of ticks. Therefore successive calls to OS_Delay() should be the specified number of ticks apart, as you observe. Salvo's "lost tick counter" is handling the fact that you are staying inside a task's for() loop for longer than one tick correctly.

So, OS_Delay() is working exactly as it should.

OS_DelayTS() seeks to minimize the error that occurs when more than one tick occurs between when the task's delay expires and when the task calls OS_DelayTS() again. IOW, it's there to handle the case where higher-priority tasks run while the lower-priority task (with OS_DelayTS()) is eligible, but not able to run because of its low priority.

Make sense?

------------------

[This message has been edited by aek (edited January 06, 2004).]

[lattenzaun]

Hello,

so you got the bug reproduced in your 1st and 2nd test.

quote:

---

Originally posted by aek:

1st test (8515 @ 4MHz, ICCAVR (because I find it easier to use ...), someTime < 2000, OS_Delay(), breakpoint on TaskBlink()'s PORT ^= line ...:

Breakpoints occur every 80ms, no problem.

---

It is also a problem, because it should be >80ms. You must add the runtime of the while-loop.

Regards,
Martin

[aek]

I wrote:

quote:

---

3rd test: use AVR-GCC instead:

Results make no sense -- it's as if OS_Delay() isn't doing anything ... will investigate further.

---

OK, I figured that out -- I had a typo in the ISR (SIG_SIG_OVERFLOW0). Oddly, it compiled fine, without error.

Anyway, I now have the same results as you (though an 8515 takes 35.2ms in the for() loop).

------------------