Event driven system in a software development

Hi,

Pressing on a keyboard key is an event.... for example.

Now there are two (or more) ways for the software to get this information.

Polled: (not even driven)
* ask the keyboard (as a software function) in short distance of time (let's say 20ms) whether a key is pressed or not
* the keyboard may respond: no_key, no_key, no_key, key_A, no_key, no_key ... on the according requests
* the function may immediately return on _no_key
* the function may process the key_A

Event driven example: (OS)
* no function asks the keyboard (no processing power)
* when you press a key (event) the keyboard itself starts the (serial) communication
* the communication interface in the processor receives the information (hardware, no processing power)
* when received the comm interface raises an interrupt
* the interrupt causes an ISR to be called (processed)
* within the ISR the key information is processed (maybe just stored into a buffer)

Similar event driven / polled processing you may do with "OS to application" information.

Indeed many things can be treated as an event.
* paper_out on a printer
* mouse movements
* connect an USB stick to the PC
* 1 second timer (if you told the processor internal timer to raise an even every 1s)
* and so on

Klaus

KlausST said:

Event driven example: (OS)
* no function asks the keyboard (no processing power)
* when you press a key (event) the keyboard itself starts the (serial) communication
* the communication interface in the processor receives the information (hardware, no processing power)
* when received the comm interface raises an interrupt
* the interrupt causes an ISR to be called (processed)
* within the ISR the key information is processed (maybe just stored into a buffer)

Similar event driven / polled processing you may do with "OS to application" information.

Klaus

Click to expand...

Hi Klaus

I am trying to understand some basic concept of operating system programming. I have some doubts in my mind which I want to clear.

1) Can two events be generated simultaneously?

I think yes more than one event can occur simultaneously

2) If multiple events occur at the same time, how does the system handle them?

Single core processor can handle one event at a time

Hi,

Kittu20 said:

1) Can two events be generated simultaneously?

Click to expand...

Usual answer: yes
A physicians answer: no.
What the definition of simultaneously? Within a millisecond, a microsecond, a nonsecond, a picosecond..

A mechanical event like pressing a keyboard button and a mouse button at the same time?
An electrical event like two electrical signals arrive at the processor at the same time?
Or software events, like the OS tells the applicaton that the user connected a USB stick?

Two independent events? like a key press and an ethernet packet arrived?
Two signals that depend on each other like hearing the same voice with two ears (microphones)?

Kittu20 said:

2) If multiple events occur at the same time, how does the system handle them?

Click to expand...

A processor is a clocked system, thus it has a dedicated stepsize for time (measurement).
Now if one event after the other arrived, then usually the first one is processed first.
If two events arrive in the same "clock period", then usually there is a prority system. Either hardware or software.
Hardware: like interrupt proirity, or software, like a switch_case instruction: the uper is processed first.
(indeed there is a chance that one higher priority event stops the processing of a lower priority event, processes the higher priority event, and after that resumes to process the lower priority event.)

Hardware can process events in parallel. Software will process one after the other.

But: in most cases it does not matter whether the one event is processed a microsecond ofter the other.
And in case it really matters then there should be a datasheet or description that tells you how to treat things.
In the keyboard it surely matters whether an "A" is processed before an "B". But it should be common sense that you should not press both buttons at exactly the same time.
***

You see it depends on a lot of things.
I recommend you to be more specific.

Klaus

KlausST said:

You see it depends on a lot of things.
I recommend you to be more specific.

Click to expand...

Sorry I don't have any specific question right now I am asking the doubts which are coming in my mind

suppose we have to Task's

Task 1 takes 2 milliseconds of CPU time to complete its work

Task 2 takes 40 milliseconds of CPU time to complete its work.

Suppose the system has given CPU control to Task 2. It has completed 50% of its work and then Task 1 needs to control the CPU, so the system gives the CPU control to Task 1. After Task 1 is finished, the system returns control of the CPU to Task 2.

Will Task 2 complete the remaining 50% work or start from beginning?

I believe you can answer the question yourself. If a task won't be exactly continued at the point where it has been interrupted, no multitasking system could work at all. Double execution of instructions would cortupt results.

FvM said:

I believe you can answer the question yourself. If a task won't be exactly continued at the point where it has been interrupted, no multitasking system could work at all. Double execution of instructions would cortupt results.

Click to expand...

In a normal process, we write c code inside the main function to execute a tasks, if an interrupt occurs in between, the processor handles the interrupt first. The processor then goes back to the main task and start from where it left off.

That's why I was thinking Task 2 should start from where it left off

There are events which are handled by the OS, whose execution is outside our control. Much of it is invisible to us.

OTOH when software is developed by you, while your application is running under your own code...
The system places an event in a flag notification of some kind (a unique variable or command expression). Events may line up in a queue (example, several characters may be typed).

Within your application you write code to handle events however you prefer. Perform tasks in any order you wish, or cancel a task if you wish. You can wait until the right moment before giving attention to an event.

Your program must cooperate with the OS in regard to handling events. This requires some knowledge. The system has its tasks which it usually performs independently of your tasks.

An important aspect of software development is to try to 'break' your program. If your program crashes (or it crashes the OS) then you may need to re-write routines in order to eliminate the problem.

I am still confused, suppose we have two Tasks. Task 1 has control of the CPU. Events are then generated and Task 2 seeks control of the CPU.

What will the system do in these situations?

Can a Task1 be preempted, or it is allowed to run to "completion"?

If you yourself code task 1 & 2, then you probably want to follow recommendations as to what makes a programmer's life easier. Subroutines (or Functions) are a customary method for performing a self-contained task, or a task you wish to complete. At its finish you're supposed to 'END SUB' or "EXIT Function'. Good programming practice avoids jumping out of a subroutine willy-nilly.

Usually the programming environment performs a debugging step (while compiling your code). As you compose your program, expect to see the compiler report errors. Don't be alarmed; the purpose is to oblige a programmer to develop good coding style.

The OS might 'time-share' your program among other operations. As it does so it's designed to 'be polite about it'. The OS lets each program run its own code. Likewise it expects your program to be polite, and not to 'take control' of the cpu.

Politely the OS conveys notifications that an event happened. Any time you wish, your program can check the event queue for various events. It's convenient to check after a routine is finished. If an event occurred then you can branch to a routine you wrote to handle that event.

Hi,

In short:
Every task is expected to run to it's end. But it may be unterrupted by other tasks.
================================

I can only imagine a "shutdown" to stop tasks without being resumed.

Just think by yourself: when you write a task, do you like it to be stopped without finishing?

Not finishing to the end will most probably end in a catastrophe. Since usually at the beginning memry will be allocated ... and at tze end the memory will be released. Allocating, but not releasing memory will sooner or later cause a memory underrun.
In microcontrollers you may transfer data via stack .. if there is a "call" without "return" it will cause a stack overflow.

Klaus