 |
General Operation
|
KwikPeg is written entirely in C++. It implements an event-driven
programming paradigm which has proven to be a superior method for creating
user interface software. KwikPeg brings structure and order to the otherwise
difficult task of responding to different external events arriving
asynchronously from many sources. This programming model has the
added benefit of being easily integrated into real-time multitasking
environments.
 |
Minimizing the Footprint
|
KwikPeg achieves its small footprint through several
means, including heavy reliance on C++ inheritance to encourage code
reuse. Each control type is built incrementally upon its predecessor,
allowing you to select and use only the objects which meet your
requirements without forcing you to carry along any unneeded baggage.
In addition, KwikPeg is written with the embedded market firmly in mind,
meaning that the value of every feature is weighed against the code size
and performance requirements of that feature.
The KwikPeg library is configured by compilation to
include only the features your application requires. The KwikPeg
Configuration Builder allows you to completely define the set of input
devices, drawing primitives and higher level features that your
target will require. This configuration capability allows you to remove
at compile time any library features that your application does not
require, in essence allowing you to customize the library to exactly
meet your needs. And it is all done without having to edit any
KwikPeg source files.
A minimum KwikPeg footprint requires approximately 50Kb of code space,
4Kb of stack and 2Kb of dynamically allocated memory. A typical full-featured
GUI may include 100Kb of code and require a 4Kb stack and 8Kb or more of
dynamically allocated memory.
|
Maximizing Performance
|
KwikPeg achieves maximum performance by minimizing
the system overhead required to maintain a graphical presentation.
Advanced window and viewport clipping techniques are used to
prevent unnecessary screen drawing. In addition, KwikPeg always
interacts directly with video and input hardware to achieve the greatest
possible throughput.
KwikPeg has been ported to the many target processors and
toolsets supported by KADAK. Most of the KwikPeg library is
completely hardware independent, relying on well defined hardware
interface objects to provide a consistent, simple and reliable
set of I/O methods.
KwikPeg applications are running today on all
of the most common embedded processors including
80x86, ARM, StrongARM, XScale,
PowerPC, 68xxx, ColdFire and MIPS32 microprocessors.
Several working examples supporting the most common display and
input types are provided with KwikPeg.
KwikPeg makes no assumptions about its software environment.
As you would expect, all RTOS specific dependencies have been
encapsulated so that KwikPeg is ready for use with
KADAK's AMX kernel and KwikNet network products.
KwikPeg also avoids the use of intrinsic data
types and floating point operations, thereby eliminating problems
often caused by different processor word lengths, endian-ness
or lack of floating point support
Finally, portability is enhanced by the general conformity to the
EC++ standard. KwikPeg does not require support for C++ exception
handling or runtime type identification. Your application
software can still make use of these features if they are
supported in the target environment by your particular compiler.
KwikPeg provides an intuitive and robust
object hierarchy. Objects may be used directly as provided or enhanced
through user derivation. KwikPeg imposes no artificial limits on how
objects are used; you are free to design screens with
a nesting of controls within windows within other windows, limited only
by the constraints of available memory.
You will find that KwikPeg lets you create your GUI quickly and easily,
incorporating features that often prove difficult and time consuming
in other desktop GUI programming environments.
The appearance of KwikPeg objects is almost identical to the appearance
of similar objects in common desktop graphical environments.
Of course, the appearance can be enhanced, simplified or altered
to meet the particular requirements of your application.
In fact, users often prefer to create their own GUI with a custom appearance
bearing no resemblance to any particular desktop graphical environment.
The KwikPeg API is defined entirely by the public functions provided
by the classes in the KwikPeg Library. This API provides robust and
intuitive methods for performing even the most complex graphical operations.
KwikPeg takes full advantage of the messaging,
memory management and synchronization services that the AMX
real-time operating system (RTOS) provides. KwikPeg input
devices are interrupt driven, using KwikPeg services to pass
user generated events to the graphical user interface.
KwikPeg supports two multitasking models to meet different needs
within an embedded system.
In one model, KwikPeg is configured as a single task executing at a
relatively low priority. User interface software interacts with
I/O devices and other system tasks using KwikPeg messaging services.
This model has the advantage of insulating the user interface
software from the real-time tasks executing on the target processor
and ensures that KwikPeg has a minimal effect on the real-time
performance of the target system.
KwikPeg can also be configured to support multiple GUI tasks.
These GUI tasks can be of different priorities and can each
directly create, display and control any number
of GUI windows or child controls. This advanced capability
is unique to the design of KwikPeg. When this model is used,
KwikPeg protects internal data structures from corruption through
judicious use of semaphores provided by the RTOS.
This tasking model has several advantages, the most significant
being that application programming is greatly simplified.
At any time, a GUI task can directly display a window or
any other type of GUI object and update the information displayed
for that object.
| 
