Pumpkin, Inc.

Pumpkin User Forums

Sub OSTimer() delays

Have an idea on how to make Salvo better? Post it here!

Sub OSTimer() delays

Postby luben » Thu Feb 13, 2003 2:15 am

SUBTIMER delays

In one RTOS is really unaccepable to make delays with <for(...)> loops. For delays that are equal or bigger then the main OSTimer() pace rate there is really no problems - OS_Delays, timeout services.

About delays in the range 10-100uS is acceptable to use <FOR(...)> loop - the OS_Yield() and the return from the kernel could be bigger from this time, so it's better to make delay within the task.

But for delays in the range 100uS - 2000uS - there are really no available services for delays.

I had such problem:
When sending data to RS232 (no handshaking control) from my module to computer, the PIC uP sent so quickly the bytes (it has internal FIFO that allows unbreakable send), that some bytes were skipped from the receiving computer. I put 2 OS_Yield() like delays between sending the bytes and everything was OK. Unfortunately the OS_Yield() will return the control within unpredictable amount of time - I mean, OS_Yield is not time related service. It could happen that the control will come back the next execution of OSSched() or it could happen the control to be returned after 20-30 and more calls of OSShed().

My old idea about OS_Skip() could help a lot for this delays. If you have service like OS_Skip(how_many_times, Label) that:
- return the control to the kernel
- after <how_many_times> calling of the OSSched will return the control to the task - guaranteed, without carrying about priorities. It's case when the task needs to execute some delay to complete the already started function. It could make the delay within the task, thuse robbing of other task from processor's time. With OS_Skip() the task will allow to other tasks to do some useful job and after some calls of OSSched it will take back the control.

In my opinion the OS_Skip should overrun the priorities, because:
- it should be used in cases when one even low priority task wants to make sub OSTimer() delay to complite the job. Using OS_Yield could result that the low priority task could not receive the control long time. In current SALVO the low priority task have to increase the priority, to wait some event (connected with some timer). That means OS_Skip should be used very carefully.

In short - Such service could be used for sub OSTimer() delays. In my previous posts I explained the other very usefull features of this service - like how highest priority task could bring the control to lower priority tasks, without decreasing the priority (that could be dangerous).

Regards
Luben

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: Sub OSTimer() delays

Postby aek » Thu Feb 13, 2003 9:30 am

Hi Luben.

I'll think about this some more, but it is decidedly non-trivial to "bridge this gap" between where for()-loop delays and OS_Delay() delays live.

And of course I'll point out that one can always do things in the foreground (ISR level) while a 100us-2ms delay is in progress at the task level.

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

[This message has been edited by aek (edited February 13, 2003).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm


Return to Feature Requests

Who is online

Users browsing this forum: No registered users and 1 guest

cron