 |
 |
| View previous topic :: View next topic |
| Author |
Message |
VanHauser
Joined: 03 Oct 2005
Posts: 88
Location: Ploiesti, Romania
|
| RTOS tasks execution rates |
 Posted: Tue Feb 06, 2007 4:58 pm |
 |
|
I noticed that RTOS task rates are actually larger than what I specify in the program. Here are my tasks:
| Code: | #use rtos(timer=0, minor_cycle=10ms)
#task (rate=10ms, max=1ms)
void task_keybd(void);
#task (rate=20ms, max=3ms)
void task_aquire(void);
#task (rate=250ms, max=3ms)
void task_compute(void);
#task (rate=300ms, max=5ms)
void task_mainscreen(void); |
task_compute should be executed every 250 ms, but actually it is executed every 315 ms. task_mainscreen real execution rate is also larger. What could be the reason for this? I need that execution rate of exactly 250ms. I tried changing the timer, there was no result. My program has no active interrupts. I'm using PCWH 4.023. |
|
 |
Ttelmah
Guest
|
|
| Posted: Wed Feb 07, 2007 3:37 am |
|
|
The key is, that the RTOS, is not 'pre-emptive'. If a task takes longer than your specified time, the other tasks have to wait, till it is complete. It is up to you to ensure that the code in a task _will_ complete in the time you specify, otherwise delays will occur. Look at the third paragraph in the 'task' entry, in the manual. Notice the penultimate line.
Best Wishes |
|
|
VanHauser
Joined: 03 Oct 2005
Posts: 88
Location: Ploiesti, Romania
|
|
| Posted: Wed Feb 07, 2007 5:17 am |
|
|
I have read that manual page over and over. I measured the execution time for every task with the oscilloscope, I didn't just approximate them. Those times that I put there are actually a little bigger than real, so it is impossible that they could be exceeded.
All the task's execution rates are actually 25% larger in real life. The quartz is ok it seems, the delay() functions perform normally.
Please help me. |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Feb 07, 2007 6:12 am |
|
|
You will never get 'exactly' 250mSec. The granularity of the cycles involved, ensures this. However you should get a lot closer than you are seeing.
I'd try a couple of things then. First, try 3.249. Though the V4 compilers are at last starting to work, testing with this release, is always a god starting point.
Then remove the 'minor_cycle' specification. The RTOS, can calculate this itself, and will probably use a faster time than you are specifying, which may help.
Then try one other thing (guessing here!...). If CCS, treat the task allocation, as they do for some of their other stuff, it is probable that the 'check' order, is actually the order the tasks are declared. In which case, I'd suggest putting the timing critical tasks 'first' in the declaration order.
Also, consider trying another timer. Depending on how the prescaler is allocated, and the way that timer0 is programmed, they may be having trouble gtting the system 'tick' to your required value. In general, I have always used Timer2, which offers much better rate programming, for this sort of job.
Best Wishes |
|
|
VanHauser
Joined: 03 Oct 2005
Posts: 88
Location: Ploiesti, Romania
|
|
| Posted: Fri Feb 09, 2007 3:38 pm |
|
|
Ttelmah, thanks for your advice, but nothing seems to work! Tried with 3.249, tried without minor_cycle, tried changing the timer. By the way, when I used timer2 it gave me an error that it was not possible to use it, it said "Minor cycle too short for this timer", even when I did not specify the minor cycle.
I never wanted exactly 250ms but I need that rate as close as possible to this. The rate of the 'aquire' task is also important, I have a 1st order low pass filter running in it.
I'm still waiting for some ideas. |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Fri Feb 09, 2007 7:26 pm |
|
|
Simulate it on mplab and measure with the clock tool.
The RTOS's scheduler was pretty exact on my tests. |
|
|
VanHauser
Joined: 03 Oct 2005
Posts: 88
Location: Ploiesti, Romania
|
|
| Posted: Sat Feb 10, 2007 6:47 am |
|
|
| Can you guide me a little with this? I have loaded a simple test program into MPLAB, but how do I measure a pulse width from a pin? |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Sat Feb 10, 2007 9:09 am |
|
|
Go to Debugger>select tool>MPLAB SIM
Place a breakpoint at the first statement (double click it) in your task and open the stopwatch from the debugger menu.
Run your code and watch the stopwatch, it will tell you how long the code is taking to run. |
|
|
VanHauser
Joined: 03 Oct 2005
Posts: 88
Location: Ploiesti, Romania
|
|
| Posted: Sat Feb 10, 2007 10:16 am |
|
|
Thank you for the tip. The test program behaves badly in the simulator too. Here it is:
| Code: | #define CLKSPEED 32000000
#include <18F452.h>
#fuses H4,NOPROTECT,NOCPB,NOCPD,NOOSCSEN,BROWNOUT,BORV45,NOWDT,WDT128,PUT,NOSTVREN,NODEBUG,NOLVP,NOWRTB,NOWRT,NOWRTC,NOWRTD,NOEBTR,NOEBTRB
#use delay(clock=CLKSPEED)
#use fast_io(A)
#use fast_io(B)
#use fast_io(C)
#use fast_io(D)
#use fast_io(E)
#use rtos(timer=0, minor_cycle=10ms)
#task (rate=10ms, max=1ms)
void task_keybd(void);
#task (rate=20ms, max=3ms)
void task_aquire(void);
#task (rate=250ms, max=3ms)
void task_compute(void);
#task (rate=300ms, max=5ms)
void task_mainscreen(void);
#define LED1 PIN_A5
#define LED2 PIN_E0
#define LED3 PIN_E1
#define LED4 PIN_E2
#zero_ram
void task_keybd(void) {
output_toggle(LED4);
}
void task_mainscreen(void) {
output_toggle(LED3);
}
void task_compute(void) {
output_toggle(LED2);
}
void task_aquire(void) {
output_toggle(LED1);
}
void main() {
// Disable everything by default
setup_low_volt_detect(FALSE);
setup_oscillator(OSC_NORMAL);
setup_adc(ADC_OFF);
setup_adc_ports(NO_ANALOGS);
setup_timer_0(RTCC_OFF);
setup_timer_1(T1_DISABLED | T1_DIV_BY_1);
setup_timer_2(T2_DISABLED, 255, 1);
setup_timer_3(T3_DISABLED | T3_DIV_BY_1);
setup_ccp1(CCP_OFF);
setup_ccp2(CCP_OFF);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
// 7 6 5 4 3 2 1 0
set_tris_a(0b11010000); // x x LED1 DOUT DIN CLK CS_DAC CS_ADC
set_tris_b(0b11110000); // PGD PGC PGM x REL4 REL3 REL2 REL1
set_tris_c(0b10011111); // RX TX RE_DE x KEY4 KEY3 KEY2 KEY1
set_tris_d(0b11111111); // LCD_D7 LCD_D6 LCD_D5 LCD_D4 LCD_L LCD_EN LCD_RW LCD_RS
set_tris_e(0b11111000); // x x x x x LED4 LED3 LED2
rtos_run();
} |
I measured the aquire_task rate, it is 25 ms, instead of 20 ms.
The rate of task_compute is also wrong, I get 312.5 ms. |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Sat Feb 10, 2007 10:55 am |
|
|
Did you set the simulator to run at 32mhz also?
I didn't test your program, but mine has a 25mS task that is doing at 25.026300mS. Compiler version 3.249. It has low and hi priority interrupts. |
|
|
VanHauser
Joined: 03 Oct 2005
Posts: 88
Location: Ploiesti, Romania
|
|
| Posted: Sat Feb 10, 2007 11:04 am |
|
|
Of course I set 32 MHz.
Well, I am getting 25.0025 ms instead of 20 ms 
Does the same with version 3.249 too. |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Sat Feb 10, 2007 11:07 am |
|
|
I don't know what is going on, but you can find what is it pressing F7 and stepping through the code to see how long things are taking to complete.
Hope it helps. |
|
|
VanHauser
Joined: 03 Oct 2005
Posts: 88
Location: Ploiesti, Romania
|
|
| Posted: Sat Feb 10, 2007 11:09 am |
|
|
| Can you please post a test program that works fine for you? |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Sat Feb 10, 2007 11:25 am |
|
|
Your test.c does if it is set to run at 40mhz. The code I am writing also runs at this speed.
Probably it is another bug.
CCS Technical Support does not monitor this forum on a regular basis. Please do not post bug reports to this form. All bug reports should be emailed to support@ccsinfo.com. Thank you. |
|
|
VanHauser
Joined: 03 Oct 2005
Posts: 88
Location: Ploiesti, Romania
|
|
| Posted: Sat Feb 10, 2007 2:50 pm |
|
|
Seems like CCS messed this up too. I have made some tests and it
seems that RTOS treats any frequency above 20 MHz like it is 40
MHz. Also it treats 15 MHz like being 20 MHz. This is the first time I have
to change good hardware in order to make the code work 
I will install a 10 MHz crystal with PLL and report to CCS.
Thank you very much for your help, future. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
