Home

DISPLAY MODELS

This file documents the following VSM Peripheral Models:

  • Multiplexed LED Display Model

  • Alphanumeric LCD Display Model (HD44780 Controller)

  • Graphical LCD Display Model (T6963C Controller)

This file last modified 30th November 2012.


HD44780

ALPHANUMERIC LCD (HD44780)

Introduction

LCDALPHA.DLL can be used to simulate most commonly available alphanumeric LCD modules based around the HD44780 controller chip. The model is set up to allow for an arbitrary mapping of LCD character positions to controller chip addresses, and displays with one or two controller chips are catered for.

A number of common display types from Densitron are pre-defined in DISPLAYS.LIB.

Details on how to program the controller chip can be found in the HD44780 Datasheet.

Symbol Naming

The ISIS library part should be created with two active symbols representing the on and off states of the display backlight. The origin should be in the centre of the symbols; their area defines where the display output will appear.

Pin Naming

The model should have pin names corresponding to the pins of the HD44780 controller - the easiest thing to do when making a new display is to decompose one of the existing ones.

If the display has two controller chips, label the enable pins E1 and E2 as opposed to E.

Properties

The LCDALPHA model supports the following properties

Property | Default | Description
NUMCOLS | - | Specifies the display width in characters.
NUMROWS | - | Specifies the display height in characters.
CLOCK | 250kHz | Specifies the clock frequency of the controller chip. This determines the time taken to process the various commands, and also the blink rate of the cursor.
ROWn | - | Specifies the address map for the n'th row.

Address Mapping

The mapping between address locations within the controller chip memory and physical locations on the display itself varies between different LCD modules. To cater for this, LCDALPHA.DLL allows you to specify the mapping for each row of the display.

For example, the mapping for a typical 4x16 display is shown below:

To correctly model this with LCDALPHA.DLL, you would need to add the following properties to the ISIS library part:

ROW1=80-8F

ROW2=C0-CF

ROW3=90-9F

ROW4=D0-DF

If a row contains a non-contiguous run of address, you can add multiple address ranges on one line, as in

ROW1=80-8F C0-CF

Debug Support

The controller model contains internal debug or trace information which can be enabled manually from the Debug menu in ISIS. When enabled internal trace data for the model will be dumped in the simulation log during a simulation run.

Bear in mind that enabling trace mode may send a great deal of data to the simulation log, and seriously degrade the performance of the simulator.


LED_Display

MULTIPLEXED LED DISPLAY

Introduction

LEDMPX.DLL can be used to simulate an arbitrary array of LED display segments which are driven by a matrix of common digit and segment wires. Typical applications included blocks of two or two or more 7 segment displays in which the segment lines are commoned but it could also be used to model rectangular dot matrix type LED modules.

The LEDs are modelled at the digital level only; there is no attempt to simulate their analogue behaviour (i.e. diode characteristics). However, provision is made to model a persistence of vision delay, so that a steady display can be achieved, not withstanding the multiplexed nature of the drive signals.

LEDMPX is a combined active component and digital simulator model. Logic levels detected at the row and column pins are used to select and display the corresponding active symbols for each segment of each digit. The best way to understand how to use the model is to decompose one of the existing devices that is based on it such as 7SEG-MPX4-CA.

Symbol Naming

The ISIS library part should be created as a bitwise active symbol, with one bit (thus two symbols) per segment. For a typical example see BITWISE INDICATORS in the Proteus VSM SDK.

You may be required to sign an NDA in order to gain access to the SDK.

A common symbol must also be defined, as this is used by LEDMPX.DLL to determine the width of a digit (or column).

This scheme avoids the need to define a separate active symbol for each and every segment in the display; only two symbols (on and off) for each segment of the left most digit need be drawn.

Pin Naming

The LEDMPX model will automatically detect the number of segments (rows) and digits (columns) on the parent device. Segment pins should be named 'A' - 'H' whilst digit pins should be named '1', '2', '3', '4'.

If you are attaching the device to a physical PCB footprint in ARES, you should use pin names as above, and pin numbers to match the footprint. Do not confuse digit numbers with pin numbers!

The Maximum number of rows and/or columns is set at 8.

Polarity

By default, a segment is drawn as lit if the corresponding row and column pins are both high for more than 1us during a given animation frame (typically 50ms). This gives a crude but effective representation of persistence of vision; in the real world, the segments are driven with a heavy current for short period of time, and the eye averages out the brightness.

To model common anode or common cathode displays, you can use the INVERT property to list the pins that are active low. For example, a display with four common cathode digits would need the property:

INVERT=1,2,3,4


T6963

GRAPHICAL LCD (T6963)

Introduction

LCDPIXEL.DLL can be used to simulate commonly available pixel addressable LCD display modules based around the Toshiba T6963C controller chip. Support for other controller chips may be added in the future - please tell us what you are using.

A number of common display types from Densitron and Powertip are pre-defined in DISPLAYS.LIB.

The T6963C Datasheet contains details of how to program the controller chip.

Symbol Naming

The ISIS library part should be created with two active symbols representing the on and off states of the display backlight. The origin should be at the top left corner of the symbols; their area defines where the display output will appear.

Pin Naming

The model should have pin names corresponding to the pins of the T6963C controller - the easiest thing to do when making a new display is to decompose one of the existing ones.

Special provision is made for dealing with the FS (font-select) and MD (mode select) pins which may, or may not, be presented on the display module connector. See below.

Properties

The LCDPIXEL model supports the following properties:

Property | Default | Description
WIDTH | - | Specifies the display width in characters.
HEIGHT | - | Specifies the display height in characters.
CLOCK | 250kHz | Specifies the clock frequency of the controller chip. This determines the time taken to process the various commands.
FS0,FS1 | - | Specifies a hard wired logic state for the font select pins of the controller chip. Use these properties if either of the font select pins is not present on the LCD module connector
MD2,MD3 | - | Specifies a hard wired logic state for the column width select pins of the controller chip. Use these properties if either of the width select pins is not present on the LCD module connector.
RAMSIZE | 65536 | Specifies the amount of RAM present on the LCD module. Address outside the RAM size are assumed to 'wrap round' into the physically memory space.

Debug Support

The controller model supports a trace mode which logs all commands sent to the display. This enables you to verify what commands are being received by the controller as program execution proceeds.

Debug messaging can be enabled manually from the Debug menu in ISIS. When enabled internal trace data for the model will be dumped in the simulation log during a simulation run.

Bear in mind that enabling trace mode may send a great deal of data to the simulation log, and seriously degrade the performance of the simulator.

Limitations

The T6963C model has the following limitations:

  • The timing for many commands is not specified in the data sheet; we have assumed that all command and argument loads take 16 clock cycles. If you your code does not check the status register as specified in the data sheet, it may not work properly on a physical display module.

  • The operation of the screen peek and screen copy commands is very badly documented; we have tested some 3rd party code that uses screen peek, but we cannot be certain about the exact behaviour of these commands in more obscure situations (e.g. text attribute mode).

  • The clock frequencies used on the specific display modules in DISPLAYS.LIB are not given in the data sheets, so we have estimated clock frequencies assuming a 60Hz refresh rate.

  • Dual scan mode is not supported.

  • The action of the HALT pin is not modelled.