Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Task state in scheduling

Status
Not open for further replies.

Daljeet12

Member level 4
Joined
Jun 16, 2018
Messages
78
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Activity points
648
I have come across the Wikipedia page which explains the theoretical terms but I am having trouble understanding its real example.


I just assume some task are (e.g. LED ON, LED OFF, read a button, display a message on an LCD screen, Motor ON, Motor OFF, read temperature data, send serial data to PC, receive data from PC )

I am showing some example of running task

CPU sending instructions to turn on the LED.
‌CPU sending instructions to turn off the LED
‌CPU sending instructions to turn on the Motor.
‌CPU sending instructions to turn off the Motor.

Explaining ready to run, running, and suspend state of task

If ADC data arrives in every 100us. CPU only takes 10us to receive ADC data. Now CPU has 90us of free time and we can use it to do any other task. We can use 90us CPU time to complete other tasks.

Does it mean that the ADC task will run on the CPU for 10us and it will be suspended for 90us? It means It should be ready to run every 100us. Because if the CPU is not assigned after 100us then the incoming data will be lost.

I can explain more but i want to confirm that what i explained in scheduling is correct.
 

Hello!

Does it mean that the ADC task will run on the CPU for 10us and it will be suspended for 90us?

Basically yes, but usually you set the parameters of ADC to work by itself, so the
ADC engine works continuously in parallel with the CPU, and it tells the CPU when it
has new data available. Therefore, it doesn't take 10µs to read it. Well, it depends
on which processor you are using, but recent chips work at several MHz, so reading the
data when it's ready just takes a few 100s ns or possibly 1µs if you run on an extreme
low power system, not more.

Because if the CPU is not assigned after 100us then the incoming data will be lost.

What do you mean by "CPU not assigned"?

In your example, I don't see any relation between your ADC and leds, motors.
Is your ADC used to measure temperature? In this case I don't see any need of
not losing a single data. Temperature evolution is usually slow, reading it at 100µs
intervals is a lot too fast.

But OK, if you have some real time data you don't want to skip, you have to make sure
that your tasks are faster than the ADC.

That said, considering what you are describing, reading temperature, switching on / off
motors and LEDs, all this is not a big deal and there will be no problem to process it
that fast.

I can explain more but i want to confirm that what i explained in scheduling is correct.

Indeed, it would be useful to explain more. I have a fuzzy image about what you want
to do, reading a temperature, report it to a PC and then power LED / motors on and off,
possibly from the PC via a CPU. Based on that I can only make assumptions.

Dora
 
Hi,

The key is: interrupt.

There is a MAIN loop.
And there are interrupt tasks, called ISRs. They are no loops. They have a beginning and an end.

So you run your standard program in MAIN, as a loop.
And every time when the ADC data is available,
* the MAIN loop is suspended
* the ISR is started, fetching data from ADC
* doing something "fast" with the data, like storing to SRAM
* the ISR is finished
* and processing the MAIN resumes

Klaus
 
In your example, I don't see any relation between your ADC and leds, motors.
That said, considering what you are describing, reading temperature, switching on / off
motors and LEDs, all this is not a big deal and there will be no problem to process it
that fast.
My intent is to understand the description given in the Wikipedia page, that's why I showed of my tasks.

The Task in the system can be anything. I have taken some examples of Tasks in my list just to understand the description of page, they all are not related to the actual application, it is purely taken to understand the information given on wiki page.

What do you mean by "CPU not assigned"?
To complete any task, the task requires CPU service. CPU sends necessary instructions to the device to perform that task.

We need to decide which one task needs to control the CPU and when it needs to take back control from the task to serve another task.

Is your ADC used to measure temperature? In this case I don't see any need of
not losing a single data. Temperature evolution is usually slow, reading it at 100µs
intervals is a lot too fast.
In this case I will assume that I have any analog input that I need to read within 100us, if I am not reading within the time limit the I will be lost data.

Now you must have got the idea that I am just trying to understand the many Task state from real example.
--- Updated ---

Hi,
The key is: interrupt.

There is a MAIN loop.
And there are interrupt tasks, called ISRs. They are no loops. They have a beginning and an end.
You mean something like this

MAIN loop.

Does Task 1 need run (if yes, call)... Does Task 2 need run (if yes, call)... Does Task 3 need run (if yes, call)... Does Task 1 need run (if yes, call)... Does Task 2 need run (if yes, call)... Does Task 3 need run (if yes, call)
 
Last edited:

Hello!

My intent is to understand the description given in the Wikipedia page, that's why I showed of my tasks.

At the end of the day, you have to begin programming. And I would even say at the
beginning of the day. You cannot learn how to ride a bicycle from a book. You have
to get some kind of feeling on how this works and what you can do with it. So you should
start about tasks, intertupts by actually coding.

In this case I will assume that I have any analog input that I need to read within 100us,
if I am not reading within the time limit the I will be lost data.

As said earlier, on recent processors there is a way to setup the ADC to have data
at the rate you want (within the CPU capability). Everytime data is ready, the ADC
rings the CPU, that's the interrupts Klaus was talking about.

You can even have a program without any loop, it works fine.

Back to the ADC / interrupt. In your example you can program ADC to call interrupts
every 100µs. From there, it's simple. You do what you have to do with the result, and
then you put the CPU in sleep mode until the next interrupt. This assumes that the
whole processing takes less than 100µs. As soon as you cross this time limit, you will
have one interrupt every 200µs, although this depends on the processor and the way
you program it.

You mean something like this

MAIN loop.

Etc..

Not exactly. If you setup an interrupt, then an interrupt service routine (ISR) will
be called automatically. In this routine, you set up a state variable that will be
used in your main loop.

It would look like this (in pseudo code), with an ADC and a timer, both with interrupts:

Code:
volatile int event = NO_EVENT;
enum {NO_EVENT, ADC_EVENT, TIMER_EVENT};

void main(void) {
    setup();
    while(1) {
        switch(event) {
        case ADC_EVENT :
            process_adc();
            break;
        case TIMER_EVENT:
            process_timer();
            break;
        }
        event = NO_EVENT;
    }
}

[some ISR definitions, pragmas, etc...]
void my_ADC_isr(void) {
    event = ADC_EVENT;
}

[some other ISR definitions, pragmas, etc...]
void my_TIMER_isr(void) {
    event = TIMER_EVENT;
}

Another way to do this:

Code:
void main() {    //    NB: Usually it's int main, but it doesn't make sense if you don't use an OS.
    setup();
    __enable_interrupts();
};

So The only task of the main function is to start your program, and then do nothing.

Then, for example if you want to do something with ADC every 100 µs:

Code:
[some ISR definitions, pragmas, etc...]
void my_ADC_isr(void) {
    __disable_interrupts();
    process_adc();
    __enable_interrupts();
}
As long as process_adc() takes less than 100µs, it will just run fine.

So again, my advice would be to start programming. Academic concepts certainly don't hurt, but there is
a great deal of practice needed to really understand what you want to do and how you can achieve
your target.

Dora
 

Hi,

You mean something like this
It is
Code:
Main_loop:
{
* main_task1
* main_task2
* main_task3
}
Mind: there is no task for the ADC.
The task is an ISR. It is called independently of the main loop.
You may have main tasks that take 10ms each, and still the ADC_ISR can be called every 100us.

Let's say your main job is baking a cake.
It maybe takes an hour
But whenever your mobile phone rings you stop the the bakery job, talk for a short time, then resume the bakery job.

The mobile phone is not part of the bakery job, it is completely independent. You may get no phone call, you may get 10 phone calls, you don't know before.
There are ISRs that are called very regularily, like ADC sampling. It may be very accurate every 100us.
There are other ISRs that are called rather unregularily, like an USB communication, or a keypress.

During bakery.. the timing of the telephone calls may be random.
But you could also use a "reminder" that tells very regularily you every 5 minutes to look for the children.

Klaus
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top