Datasheet

PDF: 09005aef8202ec2e/Source: 09005aef8202ebf7 Micron Technology, Inc., reserves the right to change products or specifications without notice.
MT9D111__6_REV5.fm - Rev. B 2/06 EN
136 ©2004 Micron Technology, Inc. All rights reserved.
MT9D111 - 1/3.2-Inch 2-Megapixel SOC Digital Image Sensor
Firmware
Micron Confidential and Proprietary
Firmware
Firmware implements all automatic functionality of the camera, including auto expo-
sure, white balance, auto focus, flicker detection and so on. The firmware consists of
drivers, generally one driver per each major control function. The firmware runs on a
6811-compatible microcontroller with a mathematical co-processor. 32K of metal mask-
programmable PROM is available for non-volatile code. 2K of volatile SRAM is available,
where typically the first 1K of SRAM is used by the PROM drivers for data and stack,
while to the second 1K is reserved for loadable custom code.
The firmware and MCU subsystem targets to achieve the following high-level goals and
features:
• execute applications from ROM and RAM
• execute applications in real-time, synchronized to IFP
• allow loading custom executable programs
• firmware controls IFP by reading and writing ring bus registers
• firmware consists from drivers and bootstrap code
• user can extend or override functionality of ROM drivers
• user can add all new drivers
• drivers have variables; user configures drivers by setting variables via two-wire serial
interface
• when idle, puts MCU into low-power sleep mode
• a minimal code overhead due to flexibility
• transparency from firmware build version
• stability, diagnostics and recovery from software crashes
• framework for application and driver development
The firmware is written in C with some inline assembler where extra performance is
required. It runs on 6811-compatible microcontroller with a mathematical co-processor.
Overview of Architecture
Bootstrap Routine
The firmware consists of a bootstrap code, drivers and a test module. The bootstrap
code initializes internal low-level MCU registers, performs a mini-self-test, and sets up a
128-bytes deep stack. The main routine is then invoked.
Drivers
Firmware applications are organized into drivers. Each driver performs a specific func-
tion. Each driver has its own data structure with various variables. The user can access
the data structure via R198:1 and R200:1 to read or write variables. The access is imple-
mented using hardware direct memory access (DMA).
Drivers are static objects with virtual methods. Each driver has an associated data struc-
ture and a driver ID. To access a driver variable, the user must know driver ID and vari-
able offset in the data structure. Driver methods are implemented using a virtual
method table (VMT). VMT is a table of pointers to driver methods. The object data struc-
ture has a pointer to VMT. Software routines must call methods indirectly, via VMT
pointer. This allows overriding of methods.
Extending and Overriding Drivers
VMTs are necessary to be able to override a driver. To override a driver, the software
developer has to perform the following steps:
1. Load executable code