What I am trying to understand is what are events in an event-driven system. when it occurred, who or what caused it to occur ? I do not understand who generates the event system or program ?

The common example I see of the event is pressing a key on the keyboard. I think there are two key points to understand this whole concept are target system and program.

 

That is a very broad question.

Keyboards generate interrupts which invoke routines (functions) from an "interrupt service table" which is defined by the OS, for copying keyboard data to internal buffers and whatnot.

Event-driven paradigms are found in many other areas of software development as well. For example old-school WIN32 programming generally required that you set up a "message loop" which then received all kinds of events from the Windows subsystem. These days there are even API endpoints which provide a publisher-subscriber model which can then be used to set up event-driven frameworks.

 

That is a very broad question.

What are the types of events in context of system or program ?

I think button press is also a kind of event so i think it comes under system event.

 

I think button press is also a kind of event so i think it comes under system event.

You "think" it is a kind of event? Come on now!

Again, everything happening at the hardware level is generating events. The OS can generate events. You can design your own programs to generate and handle events. It's whatever you can imagine really. Anything that needs to be notified of "something" generally falls within that paradigm...

 

An event is anything that requires the system to perform an action.

Bob

 

I suspect that "almost all" computer system designs are event driven.
The system defines objects and accompanying methods that are executed when the object is activated.
I have programmed Mac, Android, Matlab, just as examples, and they are all event driven.

 

A good example is the current project I am working on. It uses a PIC32MX microcontroller to monitor and control the current in a solenoid via a PWM. The PWM generates an interrupt on every rising edge and on every falling edge of the PWM. At these two specific points, the current in the coil is measured via the interrupt to the PIC32. A free wheeling diode keeps the current flowing during the PWM off time. The rising edge interrupt measures the lowest current and the falling interrupt measures the highest current. The two are summed and the average taken. The PWM is the input stimulus signal of a PID control system. Where the current to the valve may be controlled from 0-1 normalized current. It is critical that the interrupts be serviced quickly because the PWM frequency is 150 HZ and the delta time must be less than 100 microseconds in order to capture both the high and low currents for averaging. Just one practical example.
There is no way this system could work right without the use of interrupts (events if you want to call them that) are basically generalized and may or may not be serviced by an interrupt handler. But an event does sort of imply a time constraint on when it must be serviced.
The resistance of the coil changes with temperature, so you do not want to close the loop around the actual PWM value but the feedback current. The PWM will automatically increase with increasing coil resistance to maintain constant current in the coil. Long winded example sorry.