JAVA-BASED REAL-TIME PROGRAMMING

2. Fundamentals
1. Remove the loop statement around the control algorithm and the waiting
for next sample to simply get a function computing one new control
output based on one single input event.
2. Connect some external timer hardware generating periodic time events
to the program. This is built into so called micro-controller chips, and
available on (almost) any computer board. The timer should be set up
to expire often enough to obtain good control, but seldom enough not to
waste CPU time. (To find an appropriate value is a control engineering
task which is not covered.)
However, such an interrupt/event-driven technique does not scale up very
well. Imagine a control computer handling many control loops with different
sampling periods, that would require non-standard timer hardware, and the
dispatching of timer events would be troublesome. Further disadvantages will
be mentioned below. Thus, event processing as a general mechanism is mainly
useful when developing user interfaces or computing functions that can run to
completion and return whenever triggered (by time, mouse clicks, etc.). Here
we also need other more powerful concepts.
2.4.2 Time and encapsulation
The main limitation with purely event-driven software is that the processing
must be completed immediately not to delay processing of the subsequent
events. When the required computing takes to long time to complete, we need
some means to schedule to work to be done. For instance, the user pushing
a button in a web-based application may results in a request for information
to be downloaded via Internet. Clearly, we need some means to let the event
handler start (or give data to) an ongoing activity taking care of the loading.
That activity then needs to be interruptible by other events, and possibly by
more important ongoing activities issued by those events.
Another reason that we need ongoing, and interruptible, activities is software
quality. It is fundamental both within OOP and programming in general
to keep information locally whenever possible, and to let the program clearly
express the task to be performed. Consider a control loop such as the temperature
control of the LEGO-brick machine. Putting the control statements
(including timing requirements) in a loop within a method of the control object
is clearly better than having the timing requirements registered in one
part of the program and the control actions coded in another part. So again,
we want to be able to express our computations and control algorithms in an
object-oriented manner as we are used to, and have a run-time system that
takes care of scheduling the different activities.
In Java applets the event handling is performed in functions like action
and handleEvent, whereas ongoing activities are (or at least should be) done
24 2012-08-29 16:05