Professional Documents
Culture Documents
WinMobile Camera Driver SRD Sample
WinMobile Camera Driver SRD Sample
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
Document History
S . N 0 1 1.0 Vers ion Issue Date Change Comments Description / Issued By Approved By
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
Table of Content
1
1.1
INTRODUCTION
Purpose
The purpose of this document is to clearly and unambiguously specify the software services and support needed for the design and development of camera driver for a device using Omni Vision OV5640 image sensor in WinMobile.
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
1.2
Purpose
The objective of this project is to develop a fully functional Camera Driver for Rugged Industrial PDA using Omni Vision OV5640 color CMOS 5 megapixel image sensor. The primary consumer of the camera device driver interface is the DirectShow video capture filter.
1.3
References
OmniVision Serial Camera Control Bus Functional Specification OV5640 Preliminary Specification Microsoft windows mobile 6.5 DTK TIs Technical Reference Manual SPRUGN4MMay 2010Revised July 2011
1.4
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
OVERALL DESCRIPTION
The OV5640 (color) image sensor is a low voltage, high-performance, 1/4-inch 5 megapixel CMOS image sensor that provides the full functionality of a single chip 5 megapixel (2592x1944) camera using OmniBSI technology in a small footprint package. It provides full-frame, sub-sampled, windowed or arbitrarily scaled 8-bit/10-bit images in various formats via the control of the Serial Camera Control Bus (SCCB) interface
2.1 2.1.1
Complexity
Business Complexity Medium Business Values High Technical Complexity Medium
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
2.1.2
Camera Driver should be detected and initialized for every start up, as long as the camera device is present in the board At initialization time, the camera driver detects and initializes the hardware, allocates and initializes its data structures, and returns a device instance identifier that will be passed to the other entry points.
2.1.3
The camera driver architecture uses the concept of a pin as defined by the DirectShow middleware. Pins are used to transmit data in and out of a device and are always in one of three states: stopped, paused, and playing. A camera driver can support up to three types of pins: preview, capture, still. Each pin can support a number of media formats. The DirectShow middleware manages the process matching media formats from camera output pins with pins on downstream filters.
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
Driver should be able to handle various video controlling ioctls from camera application Business Complexity Medium Business Values High Technical Complexity Medium
2.1.4
Driver would be able to support following image settings, Picture brightness or black level Picture contrast or luma gain Satuaration Sharpness White Balance Gamma adjust
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
Inputs <Detail the inputs for this specific functionality> Business Rule <Describe the business events, which account for this functionality> Events Flow <The details of the events, which triggers the start and end of this functionality> Output <The desired output at the end of such an event>
2.2
Functionality 2
<Describe the functionality> Complexity <Fill this as mentioned below>
Business Complexity High - Business systems are not in place or are in place, but require significant changes Medium - Current business
Business Values High Critical functionality, must be in the beta release of the application Medium 9Important
Technical Complexity High Heavy development effort, many functional significant issues, requirements, performance complex complex business rules,
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
Business Complexity system in place requires moderate support changes the to new
Business Values but not immediately necessary Low - Nice to have functionality, but not extremely critical in
Technical Complexity integration with other applications Medium - Solution exists, yet requires customization, simple or no integration with other applications Low - Easily implemented, out-of-the-box functionality
particular
functionality
the short-term
Inputs <Detail the inputs for this specific functionality> Business Rule <Describe the business events, which account for this functionality> Events Flow <The details of the events, which triggers the start and end of this functionality> Output <The desired output at the end of such an event>
2.3
Functionality 3
<Describe the functionality> Complexity
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
<Fill
this
as
mentioned
below>
Business Complexity High - Business systems are not in place or are in place, but require significant changes Medium - Current business system in place requires moderate support changes the to new
Business Values High Critical functionality, must be in the beta release of the application Medium but not Important
Technical Complexity High Heavy development effort, many functional significant issues, integration applications Medium - Solution exists, yet requires customization, simple or no integration with other applications Low - Easily implemented, out-of-the-box functionality with requirements, performance complex other complex business rules,
immediately
particular
functionality
the short-term
Inputs <Detail the inputs for this specific functionality> Business Rule <Describe the business events, which account for this functionality>
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
Events Flow <The details of the events, which triggers the start and end of this functionality> Output <The desired output at the end of such an event>
NON-FUNCTIONAL REQUIREMENTS
<Including but not limited to following>
3.1
Localization / Globalization
< Localization / globalization requirements for the set of functionality be mentioned here>
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
3.2
Usability
<This section should include all of those requirements that affect usability. They may include: Required training time for users Measurable task times for typical talks; alternatively, base usability requirements of the new system on other systems that the users know and like Requirements that conform to common usability standards, such as GUI standards etc>
3.3
Reliability
<Requirements for system reliability should be specified here. They may include Availability: specify percent of time available, hours of use, maintenance access, degraded-mode operations, and so on Mean time between failures (MTBF): this is usually specified in hours but could also be specified in terms of days, months or years Mean time to repair (MTTR): How long is the system allowed to be out of operation after it has failed? Accuracy: Specify precision (resolution) and accuracy (by some known standard) that is required in the systems output Maximum bugs or defect rate: Usually expressed in terms of bugs/KLOC or bugs per function-point Bugs or defect rate: categorized in terms of minor, significant and critical bugs. The requirements(s) must define what is meant by a critical bug>
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
3.4
Performance
<The performance characteristics of the system should be outlined in this section, Include specific response times, where applicable, reference related features by name Response time for a transaction (average, maximum) Throughput (transactions per second) Capacity (the number of customers or transactions the system can accommodate) Degradation modes (the acceptable mode of operation when the system has been degraded) Resource utilization (memory, disk, communications)>
3.5
Integration
<Detail the integration requirements>
3.6
Scalability
< Detail any specific scalability requirements for the overall system (if desired)>
3.7
Security
<Specify any requirements regarding security or privacy issues surrounding use of the product>
3.8
Exception Handling
< Detail the exceptions handling requirements, the messages during these exceptions etc>
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
3.9
Infrastructure Requirements
< Infrastructure requirements to roll out this entire set of functionalities or the whole product>
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
developmental tools, architectural and design constraints, purchased components, and class libraries.>
3.16 Interfaces
<This section defines the interfaces that must be supported by the application, this section should contain adequate specificity, protocols, ports, and logical addresses, and so on, so that the software can be developed and verified against the interface requirements. >
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
3.20 Assumptions
<List the assumptions here>
GRACE System Technology Labs (India ) Private Limited SRD Structured approach
<LOGO>
3.21 Dependencies
<List the dependencies here>
3.22 Constraints
<List the identified constraints here>