Indigo Software Starter Kit : FUJITSU EMEA

Indigo Software Starter Kit

Multi-functional tool for development work with MB88F332 'Indigo'

Description

The Indigo Software Starter Kit helps users to develop applications for MB88F332 'Indigo' easily within a Windows XP based PC environment as well as on an embedded platform based on Fujitsu's ‘MB91F467x’ MCU family. It provides two APIs, related drivers and example code as reference software in order to simplify the start up of an application's development. An overview of the software architecture can be seen below.

GUI of Indigo Software Starter Kit

GdcCom Layer

The GdcCom API contains functions for reading and writing Indigo registers and register fields. It adds the following functionality to the underlying hardware communication (HwCom) layer:

symbolic register and field names
register shadowing in software
register field operations
command list support

The HwCom layer implements the basic low-level interface for reading and writing registers or memory blocks in the hardware. Currently, HwCom supports three communication channels: SPI on Windows (Aardvark), and SPI or APIX® on a 91467D/91467S MCU.

Software architecture

GI Layer

The graphics layer enables applications to easily make use of the hardware graphics functionality and supports the handling and management of ‘Sprites’ (Pixel Maps). The GI layer sits on top of the GDC Communication layer (GdcCom), making it independent of the communication channel. The application may also mix GI and GdcCom calls, as long as it does not use GdcCom for GI-related tasks.

The GI API contains functions for handling image patterns, color palettes, and sprites, as well as setting global SPE parameters. It also covers some related functionality such as watchdogs and signature checking.

The GI driver manages various resources such as sprite SRAM memory or Sprite Attribute Table (SAT) entries. The application may allocate (and free) these resources by means of abstract pattern objects, CLUT objects, and sprite objects and leave their administration to the GI layer.

In addition, the GI layer implements some mechanisms for avoiding artefacts on the display when modifying sprites: It supports a double-buffering concept for sprites as well as the use of command lists, to synchronize sprite updates with the display's VSync.