Colour Section

What the screen can do

The display screen is made up of 240x320 pixels — that's 76,800 pixels — each of which can display an individual 18-bit colour i.e. each pixel can be any one of 262,144 colours. That's marvellous, but it adds up to 172,800 bytes of memory. Presents a bit of a problem when the dashboard's microcontroller has only 512 bytes of RAM and 16,384 bytes of flash.

The screen has a more frugal 16 bits per pixel mode, which reduces the memory need somewhat, but is still way out of reach of the microcontroller.

Fortunately, dashboards don't really need a lot of different colours. so rather than assigning colours pixel by pixel, we can say that whole regions of pixels share the one colour. In the dashboard firmware, these regions are defined in two ways:

1. widgets configurable dashboard components with particular appearances and behaviors
2. display lists user-defined drawing operations built up from a small set of primitives.

Once regions have been defined, it's just a matter of choosing colours to fill them.

Colour structure

The colour section can be introduced in two ways:

• [COLOUR] — remove default colours leaving them all free to be redefined.
• [+COLOUR] — keep default colours, adding new entries at the end.

The colour table is made up of two kinds of entry: colour maps and named colours.

• cmap_name { colour_list }
• cname = colour

where:

• cmap_name and cname are unique names for the entries
• colour_list is one or more colour values
• colour is a colour specified by one of the 147 standard names or by a hexadecimal RGB value of the form #rrggbb where r, g and b are hexadecimal digits. The abbreviated form #rgb is also supported with each digit duplicated (e.g. #2CE is shorthand for #22CCEE).

The default colour table

Configuring your own colours is optional. The dashboard comes with a standard set of colours which is adequate for many purposes. Here is how the default colour table is defined:

[COLOUR]
base {
	black white #FF4040 #FFFF30 #50FFFF
}
bgr {
	black DodgerBlue Lime Red
}
ogo {
	black DarkOrange Lime DarkOrange
}
gor {
	black Lime Orange Red
}
bluebg = #014A94
redbg = firebrick
greenbg = darkolivegreen
brownbg = saddlebrown

As you can see, the table is made up of a number of colour maps followed by several named colours intended for default backgrounds.

Colour maps give a way of referring to a group of colours by name. Many of the widgets include a cmap option. If you read the widget description you'll find it saying that certain things are drawn in colour 0 or colour 1 or whatever.

This is how the widget defines different colour regions and how you, by creating a suitable colour map, can control the colours for each region. The first colour in the map is colour 0, the next is colour 1 and so on.

Named colours are intended for use in display lists, though colour map entries are also accessible, using an index to refer to a particular entry. For example you can refer to the last colour in the base colour map (a light blue) as base[4]. Colour 0 doesn't require an index, i.e. bgr[0] and bgr mean exactly the same thing.

The base colour map

The base colour map is defined as the first five colours in the table (regardless of names). All widgets default to this colour map, but BOOLEAN and TEXT widgets lack a cmap option to change it. The BOOLEAN widget can choose any colours it wants, using display lists, though it still uses the base colour map in some circumstances. The TEXT widget (and the TEXT part of the TRILED widget) can only use the base colour map.

The truth

Sampler

Here are samples of the colours in the default table