CROSS-REFERENCE TO RELATED APPLICATIONSThis application relates to co-pending U.S. patent application Ser. No. 08/631,173, entitled “System and Method for Using a Unified Memory Architecture to Implement a Digital Camera Device,” which is hereby incorporated by reference.
BACKGROUND OF THE INVENTION1. Field of the Invention
This invention relates generally to digital cameras and more particularly to a system and method for using a scripting language to set digital camera device features.
2. Description of the Background Art
A modern digital camera typically includes an imaging device and a built-in computer. The imaging device captures raw image information representing a scene and is controlled by the built-in computer system. The built-in computer system receives, processes and compresses the raw image information before storing the compressed digital information in an internal memory.
A typical digital camera enables a user to manipulate mechanical buttons, rotatable and toggle switches, etc. to select a few of the camera feature settings. However, the remainder of the digital camera features are typically based on built-in computer system programming. Original Equipment Manufacturers (OEMs) set the software-based features and software-based feature settings for each digital camera. Accordingly, consumers examine both the camera hardware and the camera programming to determine whether or not to purchase the camera.
Except for a few OEM selected features, the camera feature programming is stored in Read-Only Memory (ROM). Thus, the majority of the camera feature programming is not user accessible and thus not modifiable. Further, new features cannot be added. A system and method are needed for enabling an ordinary user to set digital camera device features easily. Further, a system and method are needed for enabling a programmer to add digital camera device features which are also settable by the ordinary user.
SUMMARY OF THE INVENTIONIn accordance with the present invention, a system and method are disclosed for using scripts to implement digital camera features. The digital camera includes memory storing scripts for providing digital camera device features, an interface for receiving user selected feature settings, a script manager for interpreting the scripts and the feature settings to generate data structures, and a command handler for configuring the camera to provide the camera features. The digital camera further includes an imaging device for generating a digitized image and image processors for enhancing the digitized image. Since the user need only select the camera feature script and then run and optionally interact with the camera-configuring script, the ordinary user can modify the camera features.
The digital camera includes a port connectable to host computer for adding or modifying scripts to add or modify available camera features. The host computer uses a text editor application program to generate or modify scripts, and optionally uses any error detection application program for error testing the script. The camera may be connected to the host computer for downloading the newly-generated camera-configuring script into camera memory. Alternately, the script can be loaded onto a removable memory card and inserted into the camera. The added or modified script can be run to configure the camera according to a selected feature and setting.
The invention further provides a method for generating data structures from a script. The method begins by receiving a feature setting command which includes a command name, a feature name and a feature setting by an interface from a user. Using a command table which includes a set of command names and corresponding command codes, command codes are extracted based on the command names. Using a command parameter table which includes corresponding parameter formats, the parameters are extracted based on the parameter format list. Parameters may include feature names and settings. Accordingly, a data structure which includes the command code and parameters, including any feature settings in the specified format is then generated by the script manager. The data structure is sent to a command handler for execution and generation of responsive data, which is sent back to the script manager for processing.
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a block diagram illustrating a digital camera in accordance with the present invention;
FIG. 2 is a block diagram illustrating the imaging device ofFIG. 1;
FIG. 3 is a block diagram illustrating the computer ofFIG. 1;
FIG. 4 is a memory map illustrating the ROM ofFIG. 3;
FIG. 5 is a memory map illustrating the DRAM ofFIG. 3;
FIG. 6A is a block diagram illustrating theFIG. 4 script manager;
FIG. 6B is a block diagram illustrating operations of theFIG. 1 camera;
FIG. 7A is a flowchart illustrating the preferred method for generating a data structure from a script statement;
FIG. 7B is a flowchart illustrating the preferred method for executing a command;
FIG. 8 is a flowchart further illustrating the step of building a data structure ofFIG. 7A;
FIG. 9 is a block diagram illustrating an external command send data structure; and
FIG. 10 is a block diagram illustrating an external command receive data structure.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTFIG. 1 is a block diagram of adigital camera110 having modifiable camera features such as exposure, focus, date/time stamp, etc., and coupled to ahost computer120.Camera110 comprises animaging device114 coupled via asystem bus116 to acomputer118. When a photographer depresses an action button (not shown),computer118 instructsimaging device114 to take a picture of anobject112.Imaging device114 optically captures and forwards light-based imageinformation representing object112 viasystem bus116 tocomputer118. Based on thecamera110 features,computer118 performs various image processing functions on the image information before storing the processed data in internal memory (not shown). Camera110 uses scripts, which may be authored and error tested onhost computer120, to configure its features. A conventional text editor application program (not shown) may be used onhost computer120 for generating a script and an error reporter application program (not shown) may be used onhost computer120 for error testing the script. If the error reporter locates an error, then the script may be edited until the error reporter determines that the script will provide the intendedcamera110 feature.Camera110 may be connected tohost computer120, and the script may be downloaded fromhost computer120 intocamera110 by moving the script to a system folder (not shown) incamera110 memory or to a flash disk.
FIG. 2 is a block diagram illustratingimaging device114, which comprises a lens220, a filter222, an image sensor224, a timing generator226, an analog signal processor228, an analog-to-digital (A/D) converter230, an interface232 and a motor234. A detailed discussion of the preferred elements ofimaging device114 is provided in U.S. patent application Ser. No. 08/355,031, entitled “A System and Method For Generating a Contrast Overlay as a Focus Assist for an Imaging Device,” filed on Dec. 13, 1994, which is hereby incorporated by reference.
Briefly, light-basedinformation identifying object112 passes alongoptical path236 through lens220 and filter222 to image sensor224. Image sensor224 captures the light data, generates light-based image information from the light data, and routes the light-based image information through analog signal processor228, AID converter230 and interface232. Interface232 controls analog signal processor228, motor234 and timing generator226, and passes the light-based image information viasystem bus116 tocomputer118.
FIG. 3 is a blockdiagram illustrating computer118, which comprises a central processing unit (CPU)344, Dynamic Random-Access Memory (DRAM)346, an Input/Output (I/O)interface348 and Read-Only Memory (ROM)350, each connected tosystem bus116.Computer118 optionally further includes a buffers/connector352 coupled tosystem bus116, and aremovable memory354 coupled via apath356 to buffers/connector352.
CPU344controls camera110 operations and may include a microprocessor device such as Motorola MPC821 manufactured by Motorola, Inc. of Schaumburg, Ill. or a Hitachi SH3 manufactured by Hitachi America, Ltd. of Terrytown, N.Y.CPU344 optionally uses a multithreaded environment for concurrent activation ofmultiple camera110 control functions.DRAM346 is conventional DRAM selectively allocated to various storage functions including image data storage. I/O interface348permits host computer120 or a user via externally-mounted user controls and an external LCD display panel to communicate withcomputer118.
ROM350 stores computer-readable program instructions for controllingcamera110 operations. Buffers/connector352 provides an interface, such as a Personal Computer Memory Card International Standard (PCMCIA) slot, for connecting a removable memory.Removable memory354 is preferably a readily removable and replaceable non-volatile data storage device such as a flash disk, and serves as an additional image data storage area. A user who possesses severalremovable memories354 may replace a fullremovable memory354 with an emptyremovable memory354 to effectively expand the picture-taking capacity ofcamera110.
FIG. 4 is a memorymap illustrating ROM350, which stores programs including acontrol application400, atoolbox402,drivers404, akernel406 and asystem configuration408.Control application400 comprises program instructions for managing thevarious camera110 functions and executing script commands.Toolbox402 comprises selected function modules including ascript manager410,external command handlers420,image processors430 andcamera control system440.Script manager410 operates as a script interpreter by generating data structures from script statements which are used to provide thecamera110 features.External command handlers420 manage the data structures generated byscript manager410 and may store parameter values in a programmable RAM (PRAM) such as an EEPROM.Image processors430 are programs for enhancing (e.g., adjusting the contrast, sharpening, converting the image to gray-scale, etc.) the digital image received fromimaging device114.Camera control system440 receives and processes the data structures from theexternal command handlers420 for controlling camera functions. System functions, I/O functions, camera hardware functions, image processor functions are controlled by the control application and toolbox routines receiving data structures from external command handlers.Script manager410 operations are described in greater detail with reference to FIG.6.
Drivers404 comprise program instructions for controllingvarious camera110 hardware components, such as motor234 (FIG. 2) and a flash (not shown).Kernel406 comprises program instructions providing basicunderlying camera110 services including synchronization routines, task creation, activation and deactivation routines, resource management routines, etc.System configuration408 comprises program instructions for providinginitial camera110 start-up routines such as the system boot routine and system diagnostics.
FIG. 5 is a memorymap illustrating DRAM346, which includes a workingmemory530, aRAM disk532 and asystem area534. Workingmemory530 stores camera-configuringscripts536.Scripts536 comprise program statements which may include commands, which are loaded at start-up by the configuration software from the RAM disk or flash disk. A command is a function routine call comprising a command name, optionally a send list and optionally a receive list. An example of a command is “GetCameraStates (1,‘hint’:3?,hint)” where “GetCameraStates” is the command name, “1,‘hint’” is the send list, “:” separates the send list from the receive list, and “3?,hint” is the receive list. The command name GetCameraStates calls the function routine for retrieving the status value of a particular feature. The “1” in the send list indicates that only one request is being made. The “‘hint’” indicates that the value requested is for the hint feature. The “3?” in the receive list indicates that upon receipt of responsive data three values should be skipped, and the “hint” in the receive list specifics the variable in which to store the fourth value. Combining both the send list and the receive list in the command provides a simple command structure.
A script for configuring the camera hint mode, which enables the camera to select exposure type automatically (AUTO), to set exposure such that the background is out of focus (PORT), to set the exposure to capture as much depth of field as possible (LAND), to shift exposure to provide a fast shutter speed for moving objects (SPRT) or to maximize depth of field for objects in very close proximity (CLOS), is as follows:
|  |  | 
|  | #HINT_01 CSM | (1) | 
|  | name “Set Exposure Hint Mode” | (2) | 
|  | declare u:hint | (3) | 
|  | GetCameraStates(1,“hint” 3?,hint) | (4) | 
|  | get hint | (5) | 
|  | 1: “AUTO” | 
|  | 2: “PORT” | 
|  | 3: “LAND” | 
|  | 4: “SPRT” | 
|  | 5: “CLOS” | 
|  | end | (6) | 
|  | SetCameraStates(false,1,“hint”,hint) | (7) | 
|  | SetScriptStatus(1,“hint”) | (8) | 
|  |  | 
Script manager410 enables execution and re-execution of the script for modifying and re-modifying the hint mode setting. At any time, a user can instruct
script manager410 to execute the exposure hint feature script for setting or resetting the hint feature.
Statement (1) is a comment identifying the DOS name of the script. Statement (2) specifics the script description to be provided upon user request. Statement (3) defines a variable “hint” as an unsigned integer u. A variable type table is shown below in table 1.
| Specifier | Description | 
|  | 
| u | 32 bits unsigned integer. | 
| i | 32 bits signed integer. | 
| f | 32 bits signed fractional port in signed 15 bits signed integer | 
|  | and 16 bits fraction | 
| s | 32 bytes characters containing a string up to 31 significant | 
|  | characters terminated by a null character. | 
| n | 16 bytes string contains DOS filename, format as (8 | 
|  | characters). (3 characters) or (8 characters). | 
| p | 4 characters string. | 
| b | 32 bits of Boolean flags, each bit can be either true(1) or | 
|  | false(0) | 
| l | identifier used to indicate a label name | 
|  | 
Statement (4) is a command for retrieving the previously set value of hint. Statement (5) is a user interaction statement which comprises a command requesting that the user accept or modify the hint mode setting. The list of values and strings separated by colons is the feature value related to the string name for that feature. The user selects a feature by name, and the selected name's value is returned in the variable. Statement (6) ends the list in statement (5). Statement (7) instructs
control application400 to reconfigure the hint mode as the user selects. Lastly, statement (8) communicates modifications to the user via the optional LCD status display.
RAM disk532 is a RAM-based data storage area for storing the compressed light-based image information and is typically organized in a sectored format similar to that of conventional hard disk drives.RAM disk532 may use a standardized file system enabling the external host computer system (not shown) to readily access stored data. Because the information is actually stored in RAM, the data can be easily and quickly retrieved.System area534 typically stores system error information forCPU344 to report upon restartingcomputer118 after a system error occurs.
FIG. 6A is a block diagram illustratingscript manager410 which includes afunction decoder605,function handlers610, atokenizer620, acommand interpreter625,internal command handlers630, aprogramming statement interpreter635, a command table640 and a variable table645.
Function decoder605 is a program routine for managing and decoding script messages received fromcontrol application400.Function decoder605 forwards the decoded script messages to functionhandlers610, which are program routines for managing these messages. If the script message only includes simple instructions (i.e., instruction such as initialize, abort, search for, GetName and Reset which do not require script execution), then functionhandlers610 perform the required functions and return the appropriate responses viafunction decoder605 back tocontrol application400. If the script message includes a complex instruction, (i.e., an instruction such as GetCameraStates or SetCameraStates which requires script execution and interpretation), then functionhandlers610 forward the message to tokenizer620 for complex instruction handling.
Tokenizer620 examines the syntax of the statements in the script message to convert the statement's ASCII codes into tokens.Tokenizer620 passes tokens corresponding to script commands to commandinterpreters625 and tokens corresponding to Arithmetic Logic Unit (ALU) statements, Input/Output (I/O) statements, control statements and documentation statements toprogramming statement interpreter635.
Command interpreters625 generate data structures representing the tokens.Command interpreters625 forward the data structures for external commands (i.e., commands which are used system-wide such as GetCameraStates or SetCameraStates and which require computations or information exchange with external components) toexternal command handlers420, by passing them back as a response via thefunction decoder605. The control application then passes the response to the appropriateexternal command handler420 for processing based on the command code.Command interpreters625 pass data structures for internal script commands (i.e., commands which are dedicated toscript manager410 such as Wait, Write, GetTimeString or GetDateString) are passed tointernal command handler630.
To indicate whether a command is an internal command or an external command, each command entry in the command table may include an external/internal flag,command interpreter625 may include an external/internal command table, or the command values may indicate accordingly. To create a data structure from a script command,command interpreters625 use command table640 and variable table645. An example command table640 is shown in table 2.
| Command | Command | Parameter | Parameter | 
| Name | Code | Count | Type List | 
|  | 
| “GetCameraStates” | 0 ± 0005 | 2 | 1, 16, 0, 0, 0, 0 | 
| “GetCameraCapabilities” | 0 ± 0006 | 2 | 1, 16, 0, 0, 0, 0 | 
| “SetCameraStates” | 0 ± 0007 | 3 | 4, 1, 17, 0, 0, 0 | 
| “GetCameraStatus” | 0 ± 0008 | 0 | 0, 0, 0, 0, 0, 0 | 
|  | 
The first column indicates command names, the second column indicates command codes, third column indicates the number of parameters in the parameter type send lists, and the fourth column indicates parameter type send list formats. It will be appreciated that other commands and other parameter type lists may be included in command table 2.
In conjunction with the parameter type list of command table 2,command interpreters625 use a parameter type table 3 as follows:
| TABLE 3 | 
|  | 
| Parameter Type Table | 
| Parameter | Value | Description | 
|  | 
| cuInteger | (1) | integer between 0 and 4G, 32 bit unsigned integer, a | 
|  |  | preceding 0x or 0x means hex value, otherwise | 
|  |  | decimal value. | 
| cInteger | (2) | integer between −2G and +2G, 32 bit signed integer, | 
|  |  | a preceding 0x or 0x means hex value, otherwise | 
|  |  | decimal value. | 
| cFixed | (3) | fixed integer between −32767.99999 . . . and | 
|  |  | +32767.99999 . . . , 32 bit signed fractional part in | 
|  |  | signed 15-bit signed integer and 16-bit fraction. | 
| cBitFlags | (4) | Boolean and bitflags; 32 bits of Boolean flags, each | 
|  |  | bit can be either true(1) or false(0), “0b” means | 
|  |  | Boolean, “0x” or “0x” means hex, otherwise decimal | 
|  |  | value | 
| cPName | (6) | parameter name. | 
| cName | (7) | DOS filename: 16 byte string surrounded by double | 
|  |  | quotes. The format is an up to 8 character filename, | 
|  |  | followed by a period, and a up to three character | 
|  |  | extension or up to 8 character filename; example | 
|  |  | “myscript.csm.” | 
| cString | (8) | a sequence of characters surrounded by double quotes, | 
|  |  | max. length is 31, no double quotes inside the | 
|  |  | character string. | 
| cPList | (16) | parameter list. | 
| cPVList | (17) | parameter/value list. | 
| cNameList | (18) | DOS filename list. | 
| cUList | (19) | unsigned integer list | 
|  | 
For example, the command “GetCameraCapabilities” parameter list “1,16” specifies that the send list must contain a cUInteger, which is defined as a 32 bit unsigned integer between 0 and 4 G, followed by a cPList which is defined as a parameter list. A cPList is simply a list of any length of pName type values.
Command interpreters625 use tables 2 and 3 to compare predefined script formats with actual scripts for performing script command error checking. Error checking is defined in greater detail with reference to
FIGS. 7 and 8. Generation of a data structure by
command interpreters625 is described in detail with reference to
FIGS. 7-10.
An example variable (or parameter) table is illustrated in table 4 as follows:
External andinternal command handlers420 and650 accordingly send image processor parameters to imageprocessors430 for settingcamera110 software-based features, or camera parameters to thecamera control system440 for setting capture-related features. Although not shown,command handlers420/650 may send I/O parameters to I/O interface348 for setting I/O features or other system or control parameters to other managers for settingother camera110 features. The operations ofexternal command handlers420 andinternal command handlers630 are described below in greater detail with reference to FIG.7B.
Programming statement interpreter635 uses variable table645 to process a programming statement such as control, I/O, ALU or documentation statements. For example, a programming statement may be a definition, a mathematical expression, a logical expression, etc.
If one of thescript manager410 components including thetokenizer620, thecommand interpreters625, theprogramming statement interpreter635, theinternal command handler630 locates an error in the script message, then thescript manager410 component sends an error message to anerror handler615 offunction handlers610. Theerror handler615 recognizes error codes in the error message, stops script execution and passes an appropriate error message responsively back viafunction decoder605 to I/O interface348.
FIG. 6B is a block diagram illustrating the operations ofcamera100.Imaging device114 captures and converts an image to a digitized image, and stores the digitized image inmemory354.Image processor430 takes the raw digitized image and adds image enhancements such as contrast adjustment, sharpening, etc.Image processor430 stores the enhanced image again inmemory354.
The operations ofimaging device114 and ofimage processors430 can be controlled by active scripts and script feature settings. While executing a script, thescript manager410 retrieves and displays the script feature setting currently-stored in thescript data base536 for the selected script. Thescript manager410 can interact with a user via I/O interface348 to enable modification or the currently-stored script feature setting in order to modify the camera device feature.Script manager410 generates data structures representing commands within the script, as described below with reference to FIGS.7A and8-10.
Script manager410 sends the data structures to external/internal command handlers420/650, which accordingly send image processor parameters to imageprocessors430 for settingcamera110 software-based features, camera parameters to camera control software for setting capture features, or other system or control parameters to other appropriate managers. It will be appreciated that a programmer may usehost computer120 to add additional scripts to scriptdata base536, for adding additional functions and features tocamera110.
FIG. 7A is a flowchart illustrating amethod700 for managingscript536 statements.Method700 begins instep702 bytokenizer620 receiving and parsing a statement. Iftokenizer620 instep704 determines that the program statement is not a script command, then tokenizer620 sends the tokens toprogramming statement interpreters635, which instep706 analyze the statement.Programming statement interpreter635 instep708 executes the program statement conventionally. Examples of these statements include control, I/O, ALU and documentation statements.Tokenizer620 instep710 determines whether there is another statement inscript536. If so, then tokenizer620 returns to step702. Otherwise,method700 ends.
Iftokenizer620 instep704 determines that the program statement is a script command, then tokenizer620 sends the token to commandinterpreters625 which instep712 retrieve the command code and the parameter list from the command table640 illustrated above in Table 2 described with reference to FIG.6. Using the command code and the parameter list,command interpreters625 instep714 scan the parameters and build a data structure. The step of building a data structure from a command is described in detail with reference to FIG.8.
Command interpreters625 instep716 forward data structures representing external commands via a response through thefunction decoder605 back to thecontrol application400 toexternal command handler420 or data structures representing internal commands tointernal command handlers630 for command execution. Command execution is described below with reference to FIG.7B.
Command interpreters625 instep718 receive responsive data returned fromcommand handlers420 or650.Command interpreters625 instep719 examine the data returned to determine if the data indicates an error. If so, then commandinterpreters726 jump to step726 to report the error. Otherwise,command interpreters625 continue withstep720 to determine whether the current command includes a receive list. If not, thenmethod700 returns to step710. If so, then commandinterpreters625 instep722 examine the expected parameter type in the receive list.
If the expected parameter type is a constant, then commandinterpreters625 determine whether the responsive data matches the expected parameter type. If not, then commandinterpreters625 inform theerror handler615, which instep726 reports the error andmethod700 then ends. Otherwise,command interpreters625 instep728 advance four bytes for an integer value, sixteen bytes for a DOS name or thirty-two bytes for a character string to index to the next parameter.Command interpreters625 instep730 determine whether another parameter remains in the receive list. If so, then commandinterpreters625 return to step722. Otherwise,command interpreters625 return to step710.
Ifcommand interpreters625 instep722 determine that the parameter type is a variable, then commandinterpreters625 in step731 determine if the variable has been defined. If not, thenmethod700 jumps to step726 to report the error. Otherwise,command interpreters625 in step732 stuff the received data value into the variable and proceed to step728 to index to the next parameter.
Ifcommand interpreters625 instep728 determine that the parameter type is a number N followed by the symbol “?”, then commandinterpreters625 instep734 extract the valueN. Command interpreters625 instep736 index past N×4 bytes of responsive data, i.e. N parameters. The type “N?” is used to index past parameters which are known to be unnecessary for performing the current instruction. For example, the command “GetCameraStates(1, ‘fmod’:3?, abc)” requests the current state ofcamera110 focus mode. The responsive data may be “1,‘fmod’,1,25” where “25 represents the current focus mode state. Parameter “3?” causes commandinterpreters625 to jump over the first three parameters “1,‘fmod’,1”, and on the next loop stuff the value “25” into the variable “abc.” Thus, the function “N?” eliminates examination of parameters known to be unnecessary.Command interpreters625 then proceed to step734.
FIG. 7B is a flowchart illustrating details of themethod716 for executing a command.Method716 begins withstep740 bycommand interpreters625 determining whether the command is an external command or an internal command. If the command is an external command, then commandinterpreters625 instep742 sends the data structure (which represents the command and the send list) and the response code to functiondecoder605, which decodes and forwards the data structure and response code to controlapplication400.Control application400 instep744 sends the data structures to the appropriateexternal command handler420. The appropriateexternal command handler420 instep746 executes the command data structure and instep748 forwards the appropriate response data back to the control application, which in turn calls thescript manager410 with the result. Thefunction decoder605 sends the response data back to commandinterpreters625.Method716 then ends.
If instep740command interpreters625 determine that the command is an internal command, then commandinterpreters625 instep750 sends the data structure (which represents the command and the send list) to the appropriateinternal command handler630.Method716 then jumps to step746.
FIG. 8 further illustrates step714 of building a data structure. Step714 begins instep805 bycommand interpreters625 creating a command data structure header.Command interpreters625 instep810 get the next parameter and instep815 determine the parameter type.Command interpreters625 instep820 determine if the parameter matches the expected parameter type. For example, by examining table 2 and table 3,command interpreters625 expect the command “GetCameraStates” to be followed by a send list comprising a cUInteger (1) in turn followed by a cPList (16). If the selected parameter is not a member of the expected parameter type, then commandinterpreters625 forward a message to errorhandler615, which in step825 reports the error via a response through thefunction decoder605 to thecontrol application400. The control application reports the error to the user. As illustrated by jump symbol “A,”method700 then ends.
If the selected parameter is a member of the expected parameter type, then commandinterpreters625 instep830 determine whether the parameter is a constant or a variable. If the parameter is a variable, then commandinterpreters625 instep833 determine if the variable is defined. If not, thenmethod714 jumps to step726 (FIG. 7A) to report the error. Otherwise,command interpreters625 instep835 retrieve the value of the variable. If the parameter is a constant, then commandinterpreters625 convert the ASCII constant to a value. In either case,command interpreters625 instep845 append the value to the send data structure.Command interpreters625 instep850 increment the data structure size in the header by 4, 8 or 16 bytes depending on the data type.Command interpreters625 instep855 determine if the retrieved parameter is the last parameter. If so, thenmethod714 ends. If not, thenmethod714 returns to step810.
FIG. 9 is a block diagram illustrating a command senddata structure900, which comprises aheader905 and appendedparameters930, generated bycommand interpreters625.Header905 comprises acommand code910, acommand data length915, acommand data pointer920 and adeallocation routine pointer925.Parameters930 may include a plurality of appended parameters935-945.
For the example command “GetCameraStates(1, ‘fmod’:3?,fmod)”,command interpreters625 retrieve the command code “0×0005” for “GetCameraStates” ascommand code910, setcommand data length915 to zero and place the value nil intocommand data pointer920.Command interpreters625 append an address of the subroutine which will dispose of the data structure as adeallocation routine pointer925.Command interpreters625 retrieve the parameter “1” and determine that it matches the expected parameter type cUInteger. Since the parameter is a constant,command interpreters625 append the 32-bit parameter value representing “1” to the data structure asparameter #1data935.Command interpreters625 modifycommand data pointer920 to point toparameter #1data935, and incrementcommand data length915 by four bytes.Command interpreters625 retrieve the parameter “fmod” and determine that it matches the expected parameter type cPList. Since the parameter type is a parameter name constant,external command interpreters625 append the constant “fmod” to senddata structure900 asparameter #2data940.Command interpreters625 incrementcommand data length915 by another four bytes. In this example, there are only two parameters and command data length is eight bytes.
FIG. 10 is a block diagram illustrating a command retrievedata structure1000, which comprises a header1005 and return parameters1030. Header1005 comprises acommand error code1010, acommand data length1015, acommand data pointer1020 and adeallocation routine pointer1025. Return parameters1030 may includeparameter #1data1035 andparameter #2data1040. Any number of parameters may be included.
As described inFIG. 7A,command interpreters625 receive the command receivedata structure1000 as responsive data returned from eitherexternal command handlers420 orinternal command handlers630.Command interpreters625 process the receive list “3?,fmod” with the data structure1030 values.
The foregoing description of the preferred embodiments of the invention is by way of example only, and other variations of the above-described embodiments and methods are provided by the present invention. Components of this invention may be implemented using a programmed general purpose digital computer, using application specific integrated circuits, or using a network of interconnected conventional components and circuits. The embodiments described herein have been presented for purposes of illustration and are not intended to be exhaustive or limiting. Many variations and modifications are possible in light of the foregoing teaching. The system is limited only by the following claims: