[General] Problem with multithreading

[kunal5959]

I wanted to implement a simple multithreading code on my ATMEGA128A prtototype board where 4 different tasks would be regulated in a time window such that each thread/ task occors only for a defined period. The task is to set the PORTB6 in one thread and then clear in second and the set and clear again in next threads. Now i am using AVR studio and C language..

I actually used two different programs one introducing delay(_delay_ms(2)) in thread/TASK 1 and other without delay in THread/TASK 1.

i do not understand why the setting of the LED to On or off differs when I use delay_ms(2) as shown in the code.i expected that the 2 ms delay_ms in the code would be ignored while the timer has to run the thread 1 only for 1.4 ms.

Since OCR is set to 1 TIMER0 interrupt is called every 139 us~140us.. I am using a timer counter in my code such that each thread is called at 10x140us,,20X140us,,30X140us,,40X140us...

The (1) Oscilloscope Pic shows the toggling without delay and
The (2) Oscill pic shows toggling without a delay.. pic with (1.4,2.8,4.2,5.6)as measured time diff

(1) is the ideal case as it satisfies Toggle duration of (Thread 1->1.4 ms,Thread 2->2.8ms,Thread 3->4.2ms&Thread 4->5.6ms) accordin to my calculation..
(2) (Thread 1->2.8 ms,Thread 2->1.4ms,Thread 3->4.2ms&Thread 4->5.6ms) this is absurd bcos i expected that the 2 ms delay_ms in the code would be ignored while the timer has to run the thread 1 only for 1.4 ms..??

can anyone help me in understand how the interrupt handles the threads in the second case????

---

Code C - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <stdio.h>
#include <util/delaynew.h>
 
/* function declaration */
unsigned long int frequencygenerator(unsigned long int a);
# define F_CPU 1830000UL
 
volatile int thread=4,s,t=10;
int main (void)
{   
  s=0;
   DDRA=0xFF;
   DDRE=0xFF;
   DDRB =0xFF; // Set LED as output
 
   
 /**** this timer initialisation of TIMER0 is uused to activate the Timer counters that will be used for TIMING SYNC in main programm**/         
   TIMSK|=(1<<OCIE0);//
   OCR0   = 1;
   TCCR0|=(1<<CS00)|(1<<CS02)|(1<<WGM01)|(1<<COM00);//////CTC mode Prescaler set to 128 so that  every 139 us timer0 interrupt is called.
 
   
 
sei();
   while(1){  
       
       
       // THREAD 1 ===========================================
    if(thread == 1){
  PORTB|=(1<<PORTB6);
   _delay_ms(2);  // this delay is used in only 2nd case...1st case is without delay instruction.
          }
     // THREAD 2 ===========================================
    if (thread == 2){
  PORTB&=~(1<<PORTB6);
  
   
             }
      if (thread == 3){
  PORTB|=(1<<PORTB6);
             }
        if (thread == 4){
  PORTB&=~(1<<PORTB6);
             }
             
   }
}
ISR(TIMER0_COMP_vect)
{
            s=s+1;//// each +1 counter adds 139 us to the OCR counter
 
    if(s==t)  {
      
      if (thread==4){
            thread=1;
            t=10; ////// t=10 implies 10 * 139 us is waiting time 
      }else if (thread==1){
          
          thread=2;
          t=20;       ////// t=20 implies 20 * 139 us is waiting time 
      }else if(thread==2) {  
             thread =3;
             t=30;}  ////// t=30 implies 30 * 139 us is waiting time 
       else {thread=4;
             t=40;}    ////// t=40 implies 40 * 139 us is waiting time 
       
      s=0;
      }
}

---

 

[FvM]

i expected that the 2 ms delay_ms in the code would be ignored while the timer has to run the thread 1 only for 1.4 ms.

The opposite is true. Your interrupt controlled "thread" semaphore is ignored as long as delay_ms() is executed.

The lessest you must do is to return to the scheduler when executing a delay. Means you need a multitasking-aware delay function and a different scheme to switch between threads.

 

[kunal5959]

Actually my main aim was to write a code where i can control 4 threads such that each thread has a timeout.. After a defined amount of time the a TIMING handler skips to another thread even if the thread takes more time than the defined one.

I thought timer interrupt are the only solution....Can you suggest how to TIMEOUT different threads in the main loop??

 

[FvM]

I presume you won't implement true context switching, so you need to give execution periodically back to the scheduler.

 

[kunal5959]

Thanks for the information FvM. i will read more articles on Task scheduling. It seems a major use of Task scheduling in implementing RTOS.. I hope i get some idea how to implement my idea there...Thanks again.

 

[doraemon]

Hello!

I'm not familiar with the avr environment and therefore I don't know what _delay_ms does.
I mean, I know it's a delay, but how does it delay? Does it simply eat CPU cycles?

I'm doing all my programs multithreaded, and in the latest I have in the pipeline, there are
20+ possible threads.

The embedded world is really a world of clock saving. So in case your delay function simply
eats cycles, rewrite it. Here is how to do with a simple example. Suppose you have some 1 ms
"tick" that calls a periodical process. If your 2ms cycles eater is in this time slot, you will loose
the next tick, and possibly a third one. What you should do is as follows. We will suppose that
you have a timeout variable:

---

Code C - [expand]
1
2
3
4
5
6
7
8
9
last_function_before_timeout();
    if(timeout > 0) {
        timeout--;
        return;
    }
    else {
        timeout = 2; // Will delay the next function of 2 ms
    }
    first_function after timeout();

---

As you can see, when your timeout is needed, you simply set a variable, which takes a few
clock cycles only instead of 40 000 cycles in case your processor works at 20 MHz.

FvM mentioned context switching. Indeed, saving the context and restoring the next takes a lot
of clock cycles. So the best is just to avoid context saving.
If you have a thread that needs to be in real-time (e.g. audio sampling) then promote it to master
thread. All the process will run around and you should ensure that any function you write
fits into a single time slot or at least can be split.
If you follow these 2 rules (never eat cycles idling, fit all functions in a single time slot):
- Your code will be simpler, cleaner with less "what if"s
- Your real-time characteristics will be guaranteed whatever happens.
- As your data thread is master, you will never loose a single sample.

Dora.

 

[FvM]

These days, freeRTOS is becoming a quasi standard for multi-tasking on small embedded systems below the full featured OS (e.g. linux) level. Ports for AVR are included in the recent version. https://www.freertos.org/index.html

Reviewing the task concept of freeRTOS should be at least instructive for your own work.