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.

How will a task execute without blocking other task in my situation

Status
Not open for further replies.

Kittu20

Member level 2
Joined
Oct 18, 2022
Messages
52
Helped
1
Reputation
2
Reaction score
0
Trophy points
6
Activity points
427
Suppose We have microcontroller which has 4 UART and 4 sender devices which support UART and 4 LEDs.

Initially all LEDs are turn ON

When the sender 1 is activated it sends 10 characters to microcontroller over UART. Then the microcontroller turns off LED 1, wait for 5 seconds and then turns on LED 1.

Same for other

When the sender 2 is activated it sends 10 characters to microcontroller over UART. Then the microcontroller turns off LED 2, wait for 5 seconds and then turns on LED 2.

When the sender 3 is activated it sends 10 characters to microcontroller over UART. Then the microcontroller turns off LED 3, wait for 5 seconds and then turns on LED 3.

When the sender 4 is activated it sends 10 characters to microcontroller over UART. Then the microcontroller turns off LED 4, wait for 5 seconds and then turns on LED 4

UART frame . 9600 baud, 8 data bits

The problem occurs when more than two devices are activated at the same time, it blocks the work.

I'm trying to figure out how these multiple tasks will execute without blocking each other
 

Typically each UART would generate an interrupt and set a bit in an interrupt register. When any interrupt bit is set, the ISR would process it and upon returning from the ISR it would immediately interrupt again because another bit was still set and that in turn would be processed. Remember that interrupts are a hardware feature so they can be requested simultaneously, the ISR program can then process them sequentially.

Brian.
 
Typically each UART would generate an interrupt and set a bit in an interrupt register. When any interrupt bit is set, the ISR would process it and upon returning from the ISR it would immediately interrupt again because another bit was still set and that in turn would be processed. Remember that interrupts are a hardware feature so they can be requested simultaneously, the ISR program can then process them sequentially.

Brian
Delay time is blocking a CPU for 5 seconds.

pseudo code maybe help to understand the logic

C:
void main()
{
 
 }

ISR ()
{
 
}
 

Hi,

the problem with your thinking is that the "delay 5 seconds" blocks the processing of other tasks.

As already explained in your other thread the OS will not waste the 5s of processing power but provide the 5s to other tasks.
In real time OS a "delay()" isn´t a busy wait as in standard microcontroller programming.

***
On the other hand:
I´d never do a "wait 5 seconds" in a real ime system.
Better run a task every 100ms. Then use a (static) counter variable to count up every time. So it counts up once per 100ms. If the counter counts up to 50 .. this means the delay is 50 x 100ms = 5000ms = 5s.
And you may have hundreds of counters for hundreds of LEDs in one task.

***

Your pseudo code makes no sense at all.

Klaus
 
Hi

pseudo code:
Code:
* setup:
define RED_LED = 0 as global integer variable
define RED_GREEN = 0 as global integer variable


*.. called every 100ms:
if (RED_LED > 0)
{
   if (--RED_LED == 0)
   {
      turn off red LED;
   }
   else
   {
      turn on red LED;
   }
}
if (GREEN_LED > 0)
{
   if (--GREEN_LED == 0)
   {
      turn off green LED;
   }
   else
   {
      turn on green LED;
   }
}
and so on.

* somewhere in code:
if (button green is pressed) GREEN_LED = 50 ; to make it ON for 5s

* somewhere else in code:
if (red LED on via UART is received ) RED_LED = 30 ; to make it ON for 3s

.. and so on.

Klaus
 
Of course there is always a HW approach. Using a low end SOC (single chip) :

1674153674617.png



Here a control reg or pin triggers associated one shot PWM to gen the 5 sec on pulse for respective LED.
At same trigger DMA for specific UART sends out message. Basically self controlling each event
independently of the others. Note I think 1 UART could have been muxed, just got lazy. Each onchip
resource has lib of f() calls to manipulate it, no need to write low level driver.....

Significant resources left (multipole copies of most) on chip for other uses, here is an overview
of what it has :

1674153859623.png


Tool (PSOC Creator) and compiler free, board I recommend for this (not knowing rest
of your requirments) $ 15, CY8CKIT-059.


Regards, Dana.
 
Last edited:
Hello!

Delay time is blocking a CPU for 5 seconds.

There are several ways to make a delay.
- The cycle-eater. A plain while or for loop that just consumes cycles.
- Using a timer and an interrupt.
- Using an external RTC with a wakeup bit.
- Other methods.

From what you say, you are probably using the first method.
As for the second method, you setup a timer, you fire it, and when you get a timer interrupt,
you do what you planned to do after the timeout (in your case 5s).
In this case, you can do other tasks while the timer counts.
And you don't need any operating system to do that.

Example: you press on one button. It sets up a LED, and the LED is cleared 5 seconds later.
The button is on port A, bit 1 and the button is on port A, bit 0. Change this to fit your hardware.
Note that you don't need a loop. The timer will count the time for you and call you when
finished, so you don't have to increment / decrement any variable, which greatly simplifies the
code. Of course, depending how you implement your timer setup, it can be in seconds, ms,
µs, clocks, etc... In this case, I will assume it's in seconds.
How it works:
- When you press the button, an interrupt service routine (ISR) is called (ButtonInterrupt below).
- The ISR sets the LED on and immediately fires a timer.
- When the timer finishes, another ISR is called (TimerInterrupt below).
- This timer interrupt sets the LED off.

Advantage: your program does nothing when there is no event.

Code:
void Setup(void) {
    SetLEDPort(PortA.1); // Configures the LED
    SetButtonInterrupt(PortA.0);  // Configure the button
    SetTimerInterrupt(5); // Configure your timeout.
}

void main() {
    Setup();
    EnableInterrupts();
}

void ButtonInterrupt(void) {
    PortA.1 = 1;      // LED on
    StartTimer();
}

void TimerInterrupt(void) {
    PortA.1 = 0;     // LED off
}


Dora.
 
Hi,
Advantage: your program does nothing when there is no event.
The program does nothing... but usually still the processor is running (doing a loop).
But especially for low power applications (battery powered) ... you may indeed use power saving modes (depends on microcontroller) that switch off the core clock. No code is executed then, just the counter for the interrupt is running, and wakes up the processor after the desired time.

Klaus
 
There are still processors available with fully static cores, where clock can
be shut off internally of processor. Freescale, now NXP, these folks -


offer them. Basically just draw leakage currents when off.

And some processors that get into nA area sleep currents -

https://www.analog.com/en/parametricsearch/11339#/ Some arm core....


Regards,. Dana.
 
Last edited:

Hi,

The program does nothing... but usually still the processor is running (doing a loop).
But especially for low power applications (battery powered) ... you may indeed use power saving modes (depends on microcontroller) that switch off the core clock. No code is executed then, just the counter for the interrupt is running, and wakes up the processor after the desired time.

Klaus

Well, I'm aware there is a kind of internal loop, usually low frequency, that allows to wait for events. But I mean that you can do other
work while waiting for the events. In MSP430 case, there is a low frequency clock called VLF something. (Very Low Frequency) xxx.
which even saves the power that the crystal usually needs.
Not sure how this fits with Dana's reply, whether it's possible to completely shutdown all clocks.

Dora.
 

Hi,

On the other hand:
I´d never do a "wait 5 seconds" in a real ime system.
Better run a task every 100ms.
Klaus
why did you choose only 100 milliseconds why can't it be 50 milliseconds, 200 milliseconds or any other value. Is there any specific reason for 100 millisecond ?
 

Hi,

What timing to choose depends on your task(s) ... and and what timing granularity it needs.

For example:
Doing keyboard poll should be done (my personal taste) every 50 ms.
So it´s fast enough to capture every keypress, even if fast.

Updating display content for a measurement device: up to every 300ms.
If you do it every 100ms then your mind can´t compute it and looks a bit hectic.
If you do it once a second it your brain is waiting from one update to the next.

If you run a task every 1ms, then the processing power overhead may be too high. So you lose processing power for other tasks.
I´ve done tasks every 100us on a 8MHz 8 bit microcontroller with heavy signal filtering ... but this part was written in assembler to reduce overhead. Nowadays I´d use a more suitable/faster microcontroller and C.

Gernerally: it all depends on your application requirements, your microcontrolelr, your compiler... There is no general rule.

I often do my timing diagrams with paper and pencil. You may use Excel, any drawing program or any other software.
If you are experienced you may do yor timing diagrams in your brain ... but sooner or later you need to do it.
I´d say you can´t do a real time software without deciding your applicationn timing requirements first.

Klaus
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top