Microchip Technology AC164127-9 Data Sheet

DS01368A-page 22

 2011 Microchip Technology Inc.

Every hardware display controller has its own set of
commands and status information. Therefore, separate
software drivers are needed for each supported display
controller, which fulfills the requirements of the display
driver and the standard APIs defined by the Graphics
Library. The list of supported drivers can be found in the
Graphics Library Help file. To know if a display module is
supported, check if the display driver inside the display
module is available in the above mentioned folder.
The main function provided by this layer is the
initialization of the driver using the API
ResetDevice()

, painting a pixel using APIs,

SetColor(color)

 and PitPixel(x, y), and

knowing the color of a pixel using the API
GetPixel(x, y

). The other functionalities provided

are, for example, setting up of clipping area, getting the
maximum x and y values for a display screen, etc. An
application can be written using only this layer without
using any higher layers. In that case, all the shapes
must be drawn by the user. To include this layer, the
following files must be added to the project:

HEADER FILES

Graphics.h

DisplayDriver.h or specific <Driver.h>

(like SSD1926.h)

CONFIGURATION FILES

HardwareProfile.h

GraphicsConfig.h

These files are project-specific and must be inside the
project folder.

SOURCE FILES

Specific <Driver.c> (like SSD1926.c)

This is a layer above the Display Driver layer and
provides most common services through APIs, which
are used to draw basic shapes, for instance, line
(normal, thick, dashed), bar, rectangle, circle, polygon,
bevel and arc. It also provides APIs for drawing text
and images. These are generic APIs which work with
any given display driver. However, some of these APIs
may be implemented by the Driver layer for optimized
performance, especially if the driver supports 2D-
Accelerations (For example, the Microchip Graphics
module and SSD1926). It is possible to write simple
applications by using Primitive and Driver layers only
and without using higher layers. To include this layer,
the following files must be added to the project:

HEADER FILES

Primitive.h

SOURCE FILES

Primitive.c

The GOL consists of many selectable objects, called
‘widgets’, such as Button, TextBox, Check Box,
ScrollBar, ProgressBar, Picture, ListBox, GroupBox,
Meter, DigitalMeter, Dial, Chart and Grid, which form
the basic elements of a complex graphics application.
Each of these widgets is implemented in ‘C’, but with
basic object-oriented principles, and can be used as
modules. Use of this layer must be enabled at compile
time in the ‘GraphicsConfig.h’ file. The use of
individual widgets can be enabled or disabled during
compile time in the ‘GraphicsConfig.h’ file, thereby
saving RAM and ROM. For more information, see the

 section.

Each kind of widget has a default style scheme which
defines the font and the colors used for various parts
and states of the widget. For example, a button in a
pressed state has a different color than the released
button. The style scheme for each widget is explained
in detail in the Help file of the Microchip Graphics
Library. For each style scheme, some heap memory
(dynamically allocated memory) is required to store the
style scheme values. Heap is required to store the state
information for each enabled widget. The total heap
must be greater than the sum of heaps for all the
instances of used widgets. Aside from the heap
requirement, each widget type also needs to use RAM
space for variables when rendering and managing the
widgets. This additional RAM requirement is a constant
overhead for each type of widget. The difference
between the two is that the heap requirement is needed
for each instance of a widget, while the RAM
requirement is needed for each type of widget. The
RAM requirement is constant and not dependent on the
number of instances of one type of widget.