Pumpkin, Inc.

Pumpkin User Forums

Frequency of Task Execution

If you can't make Salvo do what you want it to do, post it here.

Frequency of Task Execution

Postby linton » Thu Oct 14, 2004 2:52 am

I am new to Salvo.
How can I create a task that executes exactly every 90ms (without using OS_Delay)?
Kindly give me some guidance how to do the same using timer. I wish to use PIC18F2620 in MPLAB IDE 6.62 and MC18 (2.30.01) Compiler.

Thanks in advance
Best Regards
Linton

------------------
Linton K John
Project Engineer – E&PE
*********************************************************
Wipro Technologies
Ph: +91-080-51103070. Ext 3386
E-Mail: linton.john@wipro.com
Location: WHS, Second Floor, E-City
**********************************************************

Linton K John
Project Engineer – E&PE
*********************************************************
Wipro Technologies
Ph: +91-080-51103070. Ext 3386
E-Mail: linton.john@wipro.com
Location: WHS, Second Floor, E-City
**********************************************************

linton
 
Posts: 4
Joined: Tue Oct 05, 2004 11:00 pm
Location: Bangalore, Karnataka, India

Re: Frequency of Task Execution

Postby aek » Thu Oct 14, 2004 7:10 am

Hi Linton.

How "exactly every 90ms" do you mean? This is a serious question -- I'm not trying to make light of anything.

Time-based service are handled in Salvo via OS_Delay() and OS_DelayTS(), with OS_DelayTS() essentially eliminating long-term timing jitter.

Cyclic timers are also available, but they don't support tasks, only functions.

The system timer is accurate to +/- 1 system tick.

Other issues (e.g. the number of eligible tasks at any time) will also affect timing to a certain degree.

90ms is a kind of in-between area. If you can tolerate a moderate amount of jitter (say, 10-20ms), then by all means use the system time functions.

If you need jitter less than, say, 200us, then you'll need to use an ISR instead to call your function (no task).

On the PIC18, the best thing is to use Salvo Pro to reconfigure Salvo so that it only disables low-priority interrupts. Then run all of your tasks, including any time-related ones that can tolerate some jitter, with Salvo and low-priority interrupts. For anything that's timing-critical, run it via a high-priority interrupt. Said high-priority interrupt will experience no interrupt latency from Salvo, and so therefore the jitter will be entirely up to your coding skills, and the PIC18's inherent interrupt response jitter.

We have a lot of Salvo customers who need exact timing for one critical process (e.g. sampling at a very accurate rate). They use this "split" approach with Salvo Pro to great effect.

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

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

Re: Frequency of Task Execution

Postby linton » Thu Oct 14, 2004 7:47 am

Thanks for the relevant information. Actually my requirement is :
I have two tasks - Task A and Task B. Task A is assumed to be having more priority. I want Task A is to be executed first (Assume its execution time is less than 90ms, say 50ms ). Then switch to Task B.
When the time reaches 90ms, Task A should be stared again (by preempting Task B).
This should be repeated. i. e Task A should be started in every 90ms (irrespective of the execution of Task B).

If this technic is not possible, how can I do the same usng functions and ISRs (instead of task). could you give me some Sample code fo the same ?

Thanks and regards
Linton

------------------
Linton K John
Project Engineer – E&PE
*********************************************************
Wipro Technologies
Ph: +91-080-51103070. Ext 3386
E-Mail: linton.john@wipro.com
Location: WHS, Second Floor, E-City
**********************************************************

Linton K John
Project Engineer – E&PE
*********************************************************
Wipro Technologies
Ph: +91-080-51103070. Ext 3386
E-Mail: linton.john@wipro.com
Location: WHS, Second Floor, E-City
**********************************************************

linton
 
Posts: 4
Joined: Tue Oct 05, 2004 11:00 pm
Location: Bangalore, Karnataka, India

Re: Frequency of Task Execution

Postby aek » Fri Oct 15, 2004 6:07 am

Hi Linton.

Two things:

1) You haven't given me any additional information on how accurate the 90ms needs to be.

2) Salvo is a cooperative event-driven RTOS, so you cannot simply "preempt" TaskB().

I suspect that you can simply code your application with calls to OS_Delay(5) and OS_Delay(9) assuming 10ms ticks, but without more detailed information, I can't comment further.

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

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

Re: Frequency of Task Execution

Postby aek » Fri Oct 15, 2004 6:31 am

Hi Linton.

Perhaps what you're looking for with your currently envisioned application is a time-sliced RTOS.

Salvo is an event-driven RTOS, which is quite different from a time-sliced RTOS.

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

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

Re: Frequency of Task Execution

Postby srikanth_cg » Mon Oct 18, 2004 5:21 am

Hi,

I am working with Linton on the same study. Here are few more details of what I am looking at a high level.

PIC18F2620 will be used and it would run at 16 MHz.

There would be 3 tasks as follows.

1. It is going to act as a I2C slave. It is going to receive I2C messages every now and then, say every 1 second or just about that time. One task would continuously poll for the I2C messages and keep track of the "State transitions" of the I2C communication based on the sequence it expects, process it and reply back when master initiates a read.

2. It would play an audio of frequency 11025 Hz and that's the 90ms task. Since we are implementing Software based SPI, the task is expected to take about 50ms to send 3 bytes to the DAC.

3. It also would act as a supervisor watchdog which resets the master if the master did not send an I2C message within the next 1 second from the time it received the last message.

As explained above, I am looking at both time-sliced as well as event-driver tasks (in a combination).

Can the Task2 wait upon Timer2 which gets trigerred every 90ms? Timer2 gets re-loaded with 0 when it matches PR2.

For Task3, I would create another timer, say Timer1 which would trigger off after 1 second, and in my task to process I2C message (Task1), I would restart the timer so that it starts counting again when it receives the next I2C message.

Please advise if Salvo could help us in this. We already have implemented this without an RTOS. We are looking at Salvo to see if it would help us in any way (in terms of improving reliability, ease of handling multiple tasks).

Thanks for your time.

Regards,
Srikanth

[This message has been edited by srikanth_cg (edited October 18, 2004).]

srikanth_cg
 
Posts: 3
Joined: Sun Oct 17, 2004 11:00 pm
Location: Bangalore, Karnataka, India

Re: Frequency of Task Execution

Postby aek » Mon Oct 18, 2004 7:38 am

Hi Srikanth.
quote:
It would play an audio of frequency 11025 Hz and that's the 90ms task.
No, that's 90us, which is an enormous difference!

On a 16MHz PIC18, 90us is 360 instructions. When planning the coding for an application, I find that it helps to keep things in perspective by considering how many cycles are required to do something ...

On to your individual points:

Task 2. Assuming that you need to send an updated 3 bytes every 50us via SPI to the DAC to generate your 11025Hz signal, then it's clear that this process (I won't call it a task) needs to be a high-priority ISR, and the rest of the ISRs should probably be low-priority interrupts to avoid jitter in the DAC-feeding ISR. I'm assuming you need this to happen repetitively, therefore it needs to be an ISR.

Task 1. I2C is also pretty fast (@110kHz, a bit every 9us, a packet every 90us). To reeceive it without error, you'll also need to run I2C receive via a high-priority ISR, regardless of how often you expect packets, because back-to-back I2C packets must be acted upon without more than a single packet's delay / latency. This would also have to be a high-priority ISR, coded to do the minimum (get I2C and put it into a global buffer).

At this point, if "Tasks" 1 & 2 are implemented as simple high-priority ISRs, you have on the order of 360 instructions to get everything done in these two ISRs. I think that this is eminently possible.

Task 1 (cont'd). I2C receives are handled by an ISR. I2C received data processing can be handled by a Salvo task, no problem. You could poll for received I2C messages via OS_Delay(1s), or you could implement a mechanism whereby you call OSSignalBinSem() indirectly (not from within the high-priority ISR, but from within your main loop that checks-and-clears your own high-priority semaphore) and the I2C Salvo task waits on the semaphore.

Task 3. Easily implemented as a Salvo task.

quote:
It would play an audio of frequency 11025 Hz and that's the 90ms task.
90us is too fast for event signaling. See above for a solution.
quote:
For Task3, I would create another timer, say Timer1 which would trigger off after 1 second, and in my task to process I2C message (Task1), I would restart the timer so that it starts counting again when it receives the next I2C message.
Much easier to have a Salvo task wait on a semphore with a 1s timeout -- then you automatically have a system which handles both situations nicely.

What your proposing would easily be implemented with Salvo Pro. The point is to focus on the time-critical issues (DAC feeding and I2C reception) and code the minimum as high-priority ISRs. Then, run Salvo and tie its timer to a low-priority ISR, and configure Salvo to only disable low-priority interrupts. You could end up with (in the extreme case) a system that spends 99% of its time in the high-priority ISRs, yet continues to function because Salvo and the low-priority ISRs run in the remaining 1% of available cycles. Realistically, you'll probably use up something like 40% of your cycles in the high-priority ISRs, and the rest of the time you'll be running Salvo tasks, etc.

The keys here, and the reasons why (to me) this is an application that's easily handled by Salvo are 1) Salvo's configurability, esp. w/regard to interrupts on the PIC18, and 2) the rather asynchronous nature of your application's timing requirements. You've got high-speed DAC/SPI and I2C processes running (and they're intolerant of interrupt latency), plus you have slower processes at 1Hz or so doing more system-level stuff.

If you like, we can build you a Salvo Lite library that only disables low-priority interrupts, and you can use that to test, etc.

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

[This message has been edited by aek (edited October 18, 2004).]

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

Re: Frequency of Task Execution

Postby aek » Mon Oct 18, 2004 7:52 am

A few more things.

1) When using Salvo, it's helpful to take advantage of the fact that Salvo's timer requires just a single "hook" to your application. I.e. call OSTimer() at 100Hz from a single ISR in order to have a single system timer tick of 10ms. While it's OK to do things like signal binSems from other timers, my suspeician is that it's usually an unnecessary complication.

2) When I mentioned that 90us is too fast for event signaling, what I mean by that is while the call to OSSignalXyz() will be faster than 90us, there are still other Salvo internals that need to occur for the task that was waiting on the signaled event to run. I.e. the entire "chain" will take longer than 90us, and so it's not a viable option.

3) An example of signaling indirectly (as I mentioned) with split high/low priority schemes can be seen here. Salvo user George C. uses the HI-TECH PICC-18 compiler, which has the additional requirement of using OSProtect() and OSUnprotect() ... the MPLAB-C18 compiler (because it is stack-based) doesn't require them.

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

[This message has been edited by aek (edited October 18, 2004).]

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

Re: Frequency of Task Execution

Postby srikanth_cg » Tue Oct 19, 2004 9:23 am

Thanks for the detailed reply! We will analyze few things based on the reply and get back if we have more questions.

Regards,
Srikanth

srikanth_cg
 
Posts: 3
Joined: Sun Oct 17, 2004 11:00 pm
Location: Bangalore, Karnataka, India


Return to Coding

Who is online

Users browsing this forum: No registered users and 2 guests