WO2016043040A1 - デバイスドライバ登録装置とこれを用いたデバイスドライバの登録方法 - Google Patents

デバイスドライバ登録装置とこれを用いたデバイスドライバの登録方法 Download PDF

Info

Publication number
WO2016043040A1
WO2016043040A1 PCT/JP2015/074780 JP2015074780W WO2016043040A1 WO 2016043040 A1 WO2016043040 A1 WO 2016043040A1 JP 2015074780 W JP2015074780 W JP 2015074780W WO 2016043040 A1 WO2016043040 A1 WO 2016043040A1
Authority
WO
WIPO (PCT)
Prior art keywords
driver
interface
kernel
setting information
sequence file
Prior art date
Application number
PCT/JP2015/074780
Other languages
English (en)
French (fr)
Inventor
正之 荒木
高浜　元
Original Assignee
株式会社ａＬａｂ
株式会社コナミデジタルエンタテインメント
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社ａＬａｂ, 株式会社コナミデジタルエンタテインメント filed Critical 株式会社ａＬａｂ
Priority to JP2016514174A priority Critical patent/JP5997867B2/ja
Priority to CN201580050456.1A priority patent/CN107077435B/zh
Priority to US15/512,810 priority patent/US10372461B2/en
Publication of WO2016043040A1 publication Critical patent/WO2016043040A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading

Definitions

  • the present invention relates to a device driver registration apparatus and a device driver registration method using the device driver registration apparatus.
  • peripheral devices hereinafter referred to as “devices”
  • computers such as personal computers and smartphones
  • the device recognizes the device by the device driver and both A “logical connection” is required to enable communication.
  • the device driver is generally created as a dedicated program for each combination of a device and an operating system (OS) on the device manufacturer side and provided to the user side together with the device.
  • OS operating system
  • the main factor of such a provision form is that each device is manufactured based on a specific standard and specification, and more specifically, a device driver depends on not only the device but also the OS. It is.
  • a device driver is a program designed based on a standard or specification specific to each device.
  • information about hardware such as device configuration (configuration), parameters required for setting, and connection format.
  • the interface function between the OS and the device driver (this is referred to as “driver interface” in this specification) has a different method and form of calling the function for each OS.
  • installation of a device driver essentially requires OS administrator authority.
  • the device setting information that should be held by the device driver is extremely large depending on the device, and may require fine adjustments according to the characteristics of the device. However, even if you want to change the configuration a little to adjust it, the device manufacturer had to create (program) from scratch, and the computer user could not make any changes afterwards. .
  • the present invention has been made in view of the above, and a main technical problem is to provide a new mechanism for registering a device driver in the OS kernel by a simpler method than before.
  • a device driver registration method includes a notification driver having a driver interface for notifying device setting information to a kernel of an operating system; Using the scenario sequence file describing the device setting information, the scenario sequence file is read into the notification driver and registered in the kernel via the driver interface.
  • the notification driver in the above configuration has only a function as an interface for notifying the OS of device setting information. That is, no device-dependent information is included. Therefore, the notification driver alone does not function as a device driver at all.
  • the notification driver is a part of only the driver interface depending on the OS, and can be used in common for all devices.
  • the device setting information includes setting information related to device control, setting information to be set for the device (such as parameters to be given to the device), and an execution script for determining the operation of the device.
  • This mechanism improves device driver development efficiency on the device provider side, and greatly simplifies setting changes and setting value adjustment (tuning) operations.
  • the device driver corresponding to the device to be connected can be obtained on the computer side simply by reading the scenario sequence file at the time of initialization with the notification driver loaded in the kernel. Can be generated. Therefore, the device driver can be registered in the OS kernel by a simpler method than before.
  • FIG. 1 It is a conceptual diagram which shows the basic composition of a device driver.
  • a diagram showing a physical or logical connection mode between a kernel and a device and between a device and a device Flow chart showing device driver registration method
  • FIG. 1 is a conceptual diagram showing a basic configuration of a device driver.
  • the device driver 10 is a program located between the OS kernel 11 and the device 12, and the basic structure is as follows.
  • (C) Device interface 10C It consists of three structures.
  • the device driver of this embodiment has the function (a). Is separated into a program for realizing the above and a file describing device setting information necessary for the operations (b) and (c).
  • the driver interface is an interface located at the boundary between the OS and the device driver, and basically differs depending on the OS, but the function is the same regardless of the OS. Examples of the main functions (functions) of the driver interface are shown below. 1. Initialization (initializing the device) 2. Open (opens the device) 3. Close (close device) 4). Read (reads commands and data from the device) 5. Write (writes commands and data to the device) 6). I / O control (control of non-standardized devices)
  • a handler is a type of program that is expanded on a memory managed by the kernel. Although it is normally in a standby state, it is a subroutine program that is called when a specific processing request (event or interrupt) occurs, apart from a normal program.
  • the handler is used to notify the kernel of various device setting information held by the device driver main body 10B.
  • the driver interface 10A depends on the OS. Basically, once the driver driver 10A is created when a device driver for a certain OS is installed, the microprocessor unit (MPU) that runs the OS and the kernel does not change. It will not change afterwards.
  • the device driver main body 10B and the device interface 10C described below are both parts that depend on the configuration of the device. Therefore, if the device and its connection method (interface with the device) are the same, the OS is used as the OS. Regardless, it is common. From the perspective of the device driver 10 as a whole, the driver interface 10A is a very small part.
  • the device interface is an interface with the device as seen from the kernel side of the OS, and there are two types, a physical interface and a logical interface.
  • the device interface is a part that handles the physical connection format (problem in connection) with the hardware.
  • the registers of the registered device are expanded on the kernel memory map. It is a physical bus connection that mainly handles memory sharing and interrupt processing.
  • a memory mapped register PCI bus connection
  • I2C Inter-Integrated Circuit
  • SPI Serial Peripheral
  • the logical interface is an interface that expresses and controls the behavior of a device by a set of data (protocol packet data) according to a predetermined protocol such as a character string or a binary stream.
  • a predetermined protocol such as a character string or a binary stream.
  • a device interface it represents either or both of a physical interface and a logical interface depending on the context.
  • the device interface also has an interrupt line for transmitting and receiving interrupt signals.
  • Interrupt processing plays a role of controlling the state change on the device side by a registration type handler. For example, taking the case where the device is a camera module as an example, processing of an event “shutter is pressed” is performed by interrupt processing. When the shutter is pressed, the interrupt handler is read from the kernel, and as a result, the corresponding function (subroutine) is read.
  • (C) Device Driver Body The following setting information is mainly described in the device driver body 10B of the present embodiment. 1.
  • Setting information related to device control Setting information to be set on the device (parameters to be given to the device, etc.)
  • “Device setting information” in this specification refers to the above 1. (Setting information related to device control) and 2. (Setting information to be set in the device).
  • the setting information includes commands as well as data.
  • commands (instructions) that can be described in a script include, for example, waiting for an interrupt, register assignment, DMA transfer instruction, communication via the I2C / SPI bus, and writing to and reading from a memory-mapped register.
  • Device control is control related to the essential operation of the device, and includes control executed with administrator authority, such as device reset and setting change.
  • the parameter set in the device refers to a parameter for performing control according to the usage purpose or usage status of the device set by the user authority. For example, when viewing from the device, change the printer paper for the same printer with the same connection type, or set the camera mode (switch the panorama / video / still image mode depending on the scene even if the sensor and lens are the same). Contains device configuration information that cannot be detected electrically at all (except in special cases). Since the device driver body is inherently dependent on the device, it is determined based on information provided from the device manufacturer.
  • the device driver main body which is the core of the device driver, holds various setting information according to the device such as various parameters of the device and commands to the driver interface 10A and the device interface 10C.
  • This part is highly dependent on the device (hardware), but hardly depends on the OS.
  • the conventional device driver although most of the configuration is a common part determined depending on the device and the connection method, a part of the configuration depends on the OS, so the entire device driver depends on the OS. It was supposed to be.
  • the device driver prepares one “notification driver” for each OS, which is responsible for only the function of “(a) driver interface” depending on the OS, and registers this in the kernel.
  • the device setting information that does not depend on the OS (depends on the device) is loaded into the kernel via the “notification driver” when the device is initialized.
  • the device setting information can be freely rewritten later.
  • the device setting information is read at the time of initialization, and the function sequence (register sequence) is determined before the main thread. This is because it takes time to decide during runtime.
  • the behavior when writing to a register is often different depending on the manufacturer of the device, but the user's needs are determined, and even if the register arrangement is different, the functions realized are often the same. For example, taking a camera module as an example, ⁇ Camera A Register # 1. Zoom register # 2. Focus camera B Register # 1. Focus register # 2. zoom
  • both cameras A and B can be supported by simply changing the register order by changing the parameters specified in the device setting information.
  • the device driver of the present invention loads the “device setting information notification driver” that does not specify a device into the kernel, and loads the device setting information into the notification driver when the device is initialized.
  • the notification driver is created (programmed) in C language or the like, and once created, the same driver can be used repeatedly as long as the OS and the microprocessor unit do not change.
  • device setting information is described in a script format file called “scenario sequence file”.
  • scenario sequence file describing device setting information “This is a microphone device that communicates audio information via the I2C interface”, the OS From the user's point of view, it can be recognized as a microphone device.
  • This scenario sequence file depends on the device but not on the OS.
  • the scenario sequence file reading process is a process that is not possible with conventional device drivers.
  • a microprocessor unit with high processing capability and sufficient memory are available, such as a personal computer or smartphone in recent years. Since the processing (registration in the kernel) is completed within the time required by the device even if the number of dispatches increases slightly, there is no particular problem.
  • commands described in the scenario sequence file consist of the contents and order of the functions to be called. Since each function is divided into parts, a series of frequently used functions is defined as a macro program. It is convenient to use.
  • the speed of scenario sequence file reading processing is mainly related to the time required for dispatching functions called from the scenario sequence file. If too many commands are bundled, processing will be faster, but versatility will be impaired and it will be difficult to use. On the other hand, when frequently used commands such as “memory transfer” are handled, the number of dispatches increases, and when reading with a weak microprocessor unit, device recognition is not completed within the time required by the device and an error occurs. There is also a fear and attention is needed. Therefore, it should be designed appropriately in consideration of the number of dispatches permitted from the processing capacity of the microprocessor unit and the versatility of the scenario sequence file.
  • protocol packet processing is easy to create a macro sequence, but it is considered that it is somewhat inefficient to make a macro sequence for a bus connection and a lot of interrupt processing.
  • scenario sequence file becomes easier to use by creating macros in easy-to-use units.
  • FIG. 2 is a diagram showing a physical or logical connection mode between the kernel and the device and between the device and the device.
  • a solid line in the figure represents a bus interface connection, and a broken line represents a logical interface connection.
  • the kernel and the USB host controller are connected by a bus connection, but the USB device connected to the USB host controller is a logical interface that is communicated by a protocol packet.
  • the SD host device in the figure is connected to the kernel via an external bus such as a PCI bus.
  • a wireless communication device such as a WiFi (wireless LAN) module or a memory card is connected to the SD host (or the SD bus (or the other side). It is shown that it can be connected through an external bus called “SDIO bus that is upwardly compatible”.
  • the device registration method for the kernel is notified as device setting information when the device is initialized.
  • a device driver corresponding to any device can be realized.
  • FIG. 3 is a flowchart illustrating a device driver registration method according to the second embodiment.
  • step S1 the notification driver described in the first embodiment is loaded into the kernel.
  • the method of loading the device driver after the OS is started varies depending on the OS. For example, when the OS is Linux (registered trademark), a command such as “insmod” is used. If the OS is Windows (registered trademark), a driver definition file called “.sys” is created and the device driver is loaded into the registry by plug-and-play, and necessary device setting information is stored in the registry.
  • the registration method is simple. In other OSs, if there is a command for loading a device driver into the kernel, it is used. This step is usually performed with administrator authority, or is normally set so that the system is automatically executed with administrator authority at startup, but can be performed with user authority.
  • step S2 initialization of the device is started (step S2), and the scenario sequence file is read.
  • step S1 the notification driver has been loaded, and the device is in a standby state.
  • initialization is started and reading of the scenario sequence file is started.
  • this initialization step is, for example, setting device setting information (parameter) to an initial value, initializing an execution command described in an execution script for determining device operation, or As a preparation for generating a device driver based on a scenario sequence file, a work area is secured on a memory.
  • the operation of the initialization step when viewed from the device side and the kernel side is as follows, for example.
  • S2-1. Set register default values ⁇ OUT side (device side)> Registers on the sensor unit on the Out side (for example, if the device is a camera module, various devices such as the screen size, where to start focusing (usually infinity), white balance (image quality), exposure time, etc. Set the parameter to the initial value.
  • the camera module is an example, which means that the setting values of all devices are set to the initial values.
  • ⁇ Initialization is completed by reading the scenario sequence file.
  • step S3 a main thread for generating a handler based on the scenario sequence file is executed (step S3).
  • This step S3 is a step for generating functions and sequences for reading, writing, and I / O control, and can be performed with user authority. For example, the file write attribute can be changed using I / O control with user authority.
  • the device driver determines its own operation for the first time at this point.
  • step S4 the contents of the generated handlers are registered in the kernel as device drivers (step S4).
  • This device driver only needs to be registered in a state where it can be used on the OS, and may be incorporated in the kernel of the OS regardless of the method or usage form.
  • the notification driver when the notification driver is loaded into the kernel (step S1), the operation as a device driver has not been determined, the device is initialized from there, the scenario sequence file is read, and a handler is generated. Only when it is registered in the kernel (step S4), it functions as a device driver. Needless to say, the device driver of this embodiment operates in the same manner as a conventional device driver when viewed from the device side.
  • the device driver 10 independent of the OS can be generated by reading the device setting information (execution script for determining device parameters and device operation) described in the scenario sequence file.
  • the device connected to the interface 23 can be controlled and used.
  • the device driver 10 since the device driver 10 does not need to be compiled as in the prior art, the device driver 10 can be easily generated.
  • FIG. 4 is a conceptual diagram showing the basic configuration of the computer.
  • the computer 20 includes a microprocessor unit 21, a memory 22, and a device interface 23 (10C in FIG. 1).
  • the microprocessor unit 21 is mainly a CPU (Central Processing Unit), and various logic ICs such as an FPGA (field-programmable gate array) and a microcomputer may be used.
  • the memory 22 indicates a temporary storage device such as a RAM (Random Access Memory).
  • the device interface 23 may be any device for peripheral devices controlled by the microprocessor unit 21, and specifically, any device connected to various devices as shown in FIG. PCI (Peripheral Component Interconnect) card, network card, microphone, camera, USB, SD card, WiFi (Wireless Fidelity) built-in device, ADC (Analog Digital Converter), Bluetooth (registered trademark) built-in device, GPS built-in device, printer, FAX, scanner, etc.
  • the device interface 23 may be an interface for connecting a temporary storage device such as the memory 22 or a storage device such as a hard disk, and is connected to an input interface for connecting to a keyboard or a mouse, a display or other display device. The output interface may be used. Since the memory 22 is also a peripheral device, for example, the memory 22 is connected to a memory slot which is a device interface (not shown), and the microprocessor unit 21 manages the memory 22 with a device driver for the memory 22.
  • PCI Peripheral Component Interconnect
  • WiFi Wireless Fidel
  • An OS is installed in the computer 20, and the device driver 10 generated in steps S1 to S5 is registered in the OS kernel.
  • the device 12 is connected to the end of the device interface 23 of the computer 20.
  • the driver interface 10A shown in FIG. 1 is each handler of the OS.
  • the driver 10 plays a role of transmitting and receiving data between the driver interface 10A (each handler) and the device interface 10C determined for each device.
  • the driver 10 (10B) is a program for executing the processing of each handler determined in step S3.
  • the computer 20 can transmit / receive communication data to / from the device 12 with the device 12.
  • scenario sequence file describing device setting information.
  • the scenario sequence file is a file that describes the execution parameters for generating device parameters and handlers for the devices connected to the device interface. Since it is a script format file, it is very small enough to be edited with a text editor. It can also consist of text data of file size (for example, 2 kilobytes or less). Depending on the implementation, it may be described in the form of an intermediate language that does not depend on the OS or computer hardware (MPU), such as JavaScript (registered trademark) or XML.
  • MPU computer hardware
  • the information required to register a device with the kernel is (A) Information relating to device interface (b) Information relating to operation contents of device (c) Information relating to connection destination device. Such information may be described in a scenario sequence file and registered in the kernel via a notification driver.
  • a device such as a printer that can have a plurality of connection types even with the same device.
  • a printer that can be connected to a network is capable of USB connection or serial connection
  • the configurations of the driver interface and the device driver main body are not changed, and only the device interface is different.
  • the connection form is determined, it does not change thereafter, so it is only necessary to determine which device interface is to be mounted before mounting. If you want to change from USB connection to network connection (Ethernet (registered trademark) connection), initialize the device again with the OS running and without closing the device driver. It is only necessary to read the scenario sequence file in which the device interface part shown is read by the notification driver.
  • Processing instruction definition In the processing instruction definition, an execution command for describing the scenario itself is described. The interrupt number that is determined depending on the device (hardware) is treated as a reserved word such as “int1”.
  • the data set definition describes the definition of a data set in which one or a plurality of data is one set.
  • a data set can define a data string of any name.
  • the data string describes the register, definition contents, timing after writing, and the like. Register multiple patterns for the data set and use them according to the purpose and situation.
  • Definition of data set Definition contents b $ addr and mask n:
  • Data set b is defined as a data string that "writes 1-byte AND of mask to the contents of $ addr and waits for m milliseconds" w $ addr or mask n:
  • OS handlers [init], [term], [open], [close], [I / O-ctrl], [read], [write], [main_thread] ]
  • this device driver it is possible to control reading / writing to / from a memory-mapped register for a device that transmits and receives a packet of a predetermined size at an arbitrary timing, for example, an acceleration sensor.
  • "// comment" is added to the following part.
  • Instruction is a relatively simple program as described above.
  • the scenario sequence file is read by using functions such as open, read, write, and close. If there is an interrupt, it waits for an interrupt.
  • FIG. 5 is a block diagram illustrating a camera module according to the fourth embodiment.
  • the camera body 50 includes a calculator 20 and a camera module 30.
  • the camera module 30 includes a control unit 31, a device interface 33, a sensor 34, and optical system components such as an IR filter 35 and a lens 36.
  • the computer 20 and the camera module 30 are connected to each other with device interfaces 23 and 33 by, for example, a bus.
  • the camera module control unit 31 controls each unit of the camera module by a signal from the computer 20 or other external input.
  • the camera body 50 includes a display or touch panel (not shown).
  • the display or touch panel displays a setting screen for the camera module 30, a still image or a moving image captured by the camera body 50.
  • the camera body 50 may further include an interface for a memory and each device.
  • the control of the camera body 50 by the computer 20 needs to be changed according to the purpose.
  • still image capturing, moving image capturing, resolution setting, sensitivity setting, and the like there are a large number of setting values for the camera main body 50, and various adjustments such as image quality adjustment are necessary for each of them.
  • this type of optical device such as a camera module, the number of device parameters to be adjusted exceeds 1000, and the work requires specialized knowledge. In such a case, the ability to generate a device driver without compiling leads to a significant improvement in development efficiency.
  • the device driver can be set on the user's side later, for example, when selling a certain lens, such as white balance, exposure, focus, etc. that enables shooting with emphasis on perspective. If you distribute a scenario sequence file that includes parameters to set etc. to the user, the user can rewrite the new device setting information without compiling the device driver and use the camera with the lens attached, The user can also change the setting value.
  • a certain lens such as white balance, exposure, focus, etc. that enables shooting with emphasis on perspective.
  • a camera module that has many setting parameters and generally takes time to develop a device driver is exemplified as a device.
  • USB Universal Serial Bus
  • parallel ports and serial ports are included.
  • Registered in the kernel at the time of use such as a device connected via the SD bus, a device connected via the SD bus, or a bus type device via the PCI bus or IEEE1394 (both internal buses and external buses are included) Any device that can be made can be a “device”.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

【課題】従来よりも簡便な方法でデバイスドライバをオペレーティングシステムのカーネルに登録する。 【解決手段】　デバイス設定情報をオペレーティングシステムのカーネルに通知するドライバインターフェースを備えた通知用ドライバと、デバイスの構成情報を含むデバイスパラメータ及びデバイスの動作を決定する実行スクリプトを含む、デバイス設定情報を記述したシナリオ・シーケンス・ファイルとを用いて、前記通知用ドライバに前記シナリオ・シーケンス・ファイルを読み込むことにより前記ドライバインターフェースを介して前記カーネルに登録する。

Description

デバイスドライバ登録装置とこれを用いたデバイスドライバの登録方法
　本発明は、デバイスドライバ登録装置とこれを用いたデバイスドライバの登録方法に関する。
　パソコンやスマートフォンなどの計算機に周辺機器（以下、「デバイス」という。）を接続して使用するには計算機とデバイスとの物理的接続だけでなく、デバイスドライバによって計算機がデバイスを認識して双方で通信可能な状態にする、「論理的接続」が必要とされる。
　デバイスドライバは、デバイスメーカー側でデバイスとオペレーティングシステム（ＯＳ）の組合せ毎に専用プログラムとして作成されてデバイスと共にユーザ側に提供されることが一般的である。このような提供形態となる主な要因は、デバイスがそれぞれ固有の規格及び仕様に基づいて製造されているためであり、さらにいえば、デバイスドライバがデバイスだけでなくＯＳにも依存しているためである。
特開平１０－１１３８４号公報 特開２００４－７０９６４号公報
　デバイスドライバは、デバイスごとに固有の規格や仕様に基づいて設計されるプログラムであり、端的に言えば、デバイスの構成（コンフィギュレーション）や設定に必要なパラメータ及び接続形式などの、ハードウェアに関する情報をカーネルに登録するためのプログラムである。すなわち、大部分がハードウェアに関する情報であり、ＯＳへの依存がほとんどない部分から構成されている。しかし、同時に、ＯＳとデバイスドライバとのインターフェース機能（これを本明細書では「ドライバインターフェース」という。）は、ＯＳ毎にその機能を呼び出す方法や形式が異なっている。さらに、デバイスドライバのインストールは、本来的にＯＳの管理者権限が必要となる。
　デバイスドライバが保持すべきデバイス設定情報は、デバイスによっては非常に数が多く、デバイスの特性に合わせた微妙な調整が必要となる場合もある。しかし、その調整のためにコンフィギュレーションを少しだけ変えたい場合でも、デバイスメーカー側で一から作成（プログラミング）しなければならず、計算機のユーザー側で、事後的に変更を加えることもできなかった。
　そして、ひとたびデバイスドライバが作成されると、デバイスドライバの内部で規定されている各種のデバイス設定情報を事後的に変更することは不可能であった。例えば、ソースコードがＣ言語などでプログラミングされている場合は、ソースコードを書き直し、再度コンパイルして実行形式のプログラムファイルを生成し、これをユーザーに配布する必要があった。デバイスドライバを開発する立場から見ると、その作業は多大な労力を要するものであった。
　本発明は、上記に鑑みてなされたものであり、従来よりも簡便な方法でデバイスドライバをＯＳのカーネルに登録するあらたな仕組みを提供することを主たる技術的課題とする。
　本発明に係るデバイスドライバの登録方法は、デバイス設定情報をオペレーティングシステムのカーネルに通知するドライバインターフェースを備えた通知用ドライバと、
　デバイス設定情報を記述したシナリオ・シーケンス・ファイルとを用いて、前記通知用ドライバに前記シナリオ・シーケンス・ファイルを読み込むことにより前記ドライバインターフェースを介して前記カーネルに登録する。
　上記構成における通知用ドライバは、デバイス設定情報をＯＳに通知するインターフェースとしての機能だけを有する。すなわち、デバイスに依存する情報を一切含まない。そのため、通知用ドライバ単独ではデバイスドライバとして全く機能しない。通知用ドライバは、ＯＳに依存するドライバインターフェースのみの部分であり、全てのデバイスに共通して用いることができる。そして、デバイス側からデバイス設定情報を受け取ると直ちにオペレーティングシステムのカーネルに通知することができる。ここで、デバイス設定情報とは、デバイスの制御に関する設定情報、デバイスに設定する設定情報（デバイスに与えるパラメータ等）、及び、デバイスの動作を決定する実行スクリプトなどを含む。
　そのため、この通知用ドライバをカーネルに読み込ませた後、デバイスの初期化の際にシナリオ・シーケンス・ファイルをこの通知用ドライバに読み込ませることで、デバイスの動作に必要な全てのデバイス設定情報をいつでも自由にカーネルに登録することができるようになる。
　このような仕組みにより、デバイス提供者側においては、デバイスドライバの開発効率が向上し、設定変更や設定値の調整（チューニング）作業なども、大幅に簡素化することができる。
　本発明に係るデバイスドライバの登録方法によると、通知用ドライバをカーネルにロードした状態で、初期化の際にシナリオ・シーケンス・ファイルを読み込むだけで、接続するデバイスに応じたデバイスドライバを計算機側で生成できる。そのため、従来よりも簡便な方法でデバイスドライバをＯＳのカーネルに登録することができる。
デバイスドライバの基本構成を示す概念図である。 カーネル－デバイス間及びデバイス－デバイス間の物理的又は論理的な接続態様を示す図 デバイスドライバの登録方法を示すフローチャート 計算機の基本構成を示す概念図 カメラモジュールを示すブロック図
　以下、図面を参照して本発明の各実施形態について説明する。同一又は同類の部材には同一の符号を用いるか又は添字のみ異ならせて表示するものとし、重複した説明を省略しているが、各実施形態の記載は本発明の技術的思想を理解するために合目的的に解釈され、実施形態の記載に限定解釈されるべきものではない。
（第１の実施形態）－デバイスドライバの基本構成－
　図１は、デバイスドライバの基本構成を示す概念図である。デバイスドライバ１０は、ＯＳのカーネル１１とデバイス１２との間に位置するプログラムであり、基本構造は、
　（ａ）ドライバインターフェース１０Ａ
　（ｂ）デバイスドライバ本体１０Ｂ
　（ｃ）デバイスインターフェース１０Ｃ
という３つの構造からなっている。
　デバイスは実に数多くの種類が存在するが、どのようなデバイスであっても、基本的に、すべてのデバイスドライバがいずれも図１に示すような構造を有する。デバイス１２側からみて、ドライバインターフェース１０Ａよりも向こう側はユーザー権限で操作される領域（ユーザーエリア１３）、手前側は管理者権限で操作される領域（管理者エリア１４）である。
　しかし、従来のデバイスドライバは、（ａ）～（ｃ）のすべてが一つのプログラムとしてデバイスメーカー側で作成され、ユーザーに配布されていたが、本実施形態のデバイスドライバは、（ａ）の機能を実現するプログラムと、（ｂ）及び（ｃ）の動作に必要なデバイス設定情報を記述したファイルとに分離する構成を採用している。
（ａ）ドライバインターフェース
　ドライバインターフェースはＯＳとデバイスドライバの境界に位置するインターフェースであり、基本的にはＯＳごとに異なるが、その機能はＯＳによらず同じである。ドライバインターフェースの主な機能（ファンクション）の例を以下に示す。
　１．初期化（デバイスを初期化する）
　２．オープン（デバイスをオープンする）
　３．クローズ（デバイスをクローズする）
　４．リード（デバイスからコマンドやデータを読み出す）
　５．ライト（デバイスにコマンドやデータを書き込む）
　６．Ｉ／Ｏコントロール（標準化されていないデバイスの制御）
　デバイスとカーネルとのインターフェース機能は、デバイスハンドラ（以下「ハンドラ」という。）を用いて実現される。ハンドラとは、カーネルが管理するメモリ上に展開されるプログラムの一種である。普段は待機状態にあるが、通常のプログラムとは別に、特定の処理要求（イベントや割り込み）が発生したときに呼び出されるサブルーチンプログラムである。ドライバ設定情報をカーネルに登録する際には、このハンドラを用いてデバイスドライバの本体１０Ｂが保持している各種のデバイス設定情報をカーネルに通知する。
　ドライバインターフェース１０Ａは、ＯＳに依存する部分であるが、基本的には、あるＯＳに対するデバイスドライバを実装する際に一度作成すれば、ＯＳ及びカーネルを動かすマイクロプロセッサユニット（ＭＰＵ）が変わらない限り、以後変わることがない。これに対して、以下に説明するデバイスドライバ本体１０Ｂとデバイスインターフェース１０Ｃは、いずれもデバイスの構成に依存する部分であるため、デバイスやその接続方法（デバイスとのインターフェース）が同じであればＯＳに依らず、共通となる。デバイスドライバ１０の全体から見ると、ドライバインターフェース１０Ａはごくわずかな部分にすぎない。
（ｂ）デバイスインターフェース
　デバイスインターフェースは、ＯＳのカーネル側からみたデバイスとのインターフェースであり、物理的インターフェースと論理的インターフェースの２種類がある。デバイスインターフェースは、ハードウェアとの物理的な接続形式（結線上の問題）を扱う部分である。物理的インターフェースでは、登録されるデバイスのレジスタが、カーネルのメモリマップ上に展開される。それは主にメモリ共有と割り込み処理を扱う物理的なバス接続であり、デバイスの接続形式によって、例えば、メモリマップドレジスタ（ＰＣＩバス接続）、Ｉ２Ｃ（Inter-Integrated Circuit）バスインターフェースやＳＰＩ（Serial Peripheral Interface）などの通信型レジスタなどがある。
　一方、論理的インターフェースでは、例えば文字列やバイナリストリームなどの、決められたプロトコルに従った一まとまりのデータ（プロトコルパケットデータ)によってデバイスの挙動を表現し制御するインターフェースである。単にデバイスインターフェースといった場合には、文脈により物理的インターフェースと論理的インターフェースのいずれか又は両方を表す。
　また、デバイスインターフェースは、割り込み信号を送受信するための割り込みｌｉｎｅを有する。割り込み処理はデバイス側の状態変化を登録型のハンドラによって制御する役割を担う。例えば、デバイスがカメラモジュールである場合を例に取ると、「シャッターが押される」というイベントの処理は、割り込み処理で行っている。シャッターが押されると割り込みハンドラがカーネルから読み出され、その結果として、対応する関数（サブルーチン）が読み込まれる。
（ｃ）デバイスドライバ本体
　本実施形態のデバイスドライバ本体１０Ｂは、主に以下の設定情報が記述されている。
　１．デバイスの制御に関する設定情報
　２．デバイスに設定する設定情報（デバイスに与えるパラメータ等）
　本明細書における「デバイス設定情報」とは、上記の１．（デバイスの制御に関する設定情報）と２．（デバイスに設定する設定情報）の両方を含む。また、設定情報にはデータだけでなくコマンドを含む。例えば、スクリプトで記述できるコマンド（インストラクション）例えば割り込み待ち、レジスタへの代入、ＤＭＡ転送の指示、Ｉ２Ｃ／ＳＰＩバスを経由した通信、メモリマップドレジスタへの書き込みや読み出しなどを含む。
　デバイスの制御とは、デバイスの本質的な動作に関わる制御であり管理者権限で実行される制御、例えばデバイスのリセット、設定変更などを含む。一方、デバイスに設定するパラメータとは、ユーザー権限で設定されるデバイスの使用目的や使用状況等に応じた制御を行うためのパラメータをいう。例えば、同じ接続形式で同じプリンタでもプリンタの用紙を変更する、カメラのモード（センサとレンズは同じでもシーンによってパノラマ・動画・静止画モードを切り替える、など。）を設定するといった、デバイスから見ると（特別な場合を除いて）電気的には全く検知できないようなデバイスの設定情報を含む。デバイスドライバ本体は本来的にデバイスに依存する部分であるため、デバイスメーカー側から提供される情報に基づいて決まる。
　以上のように、デバイスドライバの中核をなすデバイスドライバ本体はデバイスの各種パラメータやドライバインターフェース１０Ａやデバイスインターフェース１０Ｃへのコマンドなど、デバイスに合わせた各種の設定情報を保持している。この部分はデバイス（ハードウェア）への依存性が高いがＯＳへの依存は殆ど無い。しかし、従来のデバイスドライバは、構成の大部分がデバイスや接続方法に依存して決まる共通部分であるにも関わらず、構成の一部がＯＳに依存するために、デバイスドライバ全体がＯＳに依存するものとなっていた。
　これに対して、本実施形態のデバイスドライバは、ＯＳに依存する「（ａ）ドライバインターフェース」の部分だけの機能を担う「通知用ドライバ」をＯＳごとに１つ準備し、これをカーネルに登録するところから開始し、デバイスの初期化の際にＯＳに依存しない（デバイスには依存する）デバイス設定情報を「通知用ドライバ」を介してカーネルに読み込ませることで、ユーザー権限で後からユーザーがデバイス設定情報を後から自由に書き換えることができるように構成されている。
　このように、初期化の際にデバイス設定情報を読み込んで機能の並び（レジスタの並び）をメインスレッドの前に決定する。これは、ランタイム中に決定しようとすると時間がかかるためである。レジスタに書き込んだ際の振る舞いはデバイスの製造メーカーによって異なる場合も多いがユーザーのニーズは決まっており、レジスタの並びは違っていても実現される機能は大体同じであることが多い。たとえば、カメラモジュールを例にとると、
・カメラＡ
　レジスタ＃１．ズーム
　レジスタ＃２．フォーカス
・カメラＢ
　レジスタ＃１．フォーカス
　レジスタ＃２．ズーム
　このようにレジスタの並びが違っている場合でも、デバイス設定情報で規定されるパラメータを変更してレジスタの並びを変えるだけでカメラＡ、Ｂの両方に対応できるようになる。
　このように、本発明のデバイスドライバは、デバイスを特定しない、「デバイス設定情報の通知用ドライバ」をカーネルにロードし、デバイスを初期化する際にデバイス設定情報を通知用ドライバに読み込んでデバイス設定情報をカーネルに通知することで、自身のデバイスの動作を確定させることができる。なお、通知用ドライバはＣ言語などで作成（プログラミング）し、一度作成すればＯＳ及びマイクロプロセッサユニットが変わらない限り、同じものを繰り返し用いることができる。
　本実施形態では、デバイス設定情報を「シナリオ・シーケンス・ファイル」と呼ばれるスクリプト形式のファイルに記述する。通知用ドライバをロードしてデバイスを初期化する際に、例えば、「Ｉ２Ｃインターフェース経由で音声情報を通信するマイクデバイスである」というデバイス設定情報を記述したシナリオ・シーケンス・ファイルを読み込むことで、ＯＳのユーザーからみるとそれがマイクデバイスとして認識されうる。このシナリオ・シーケンス・ファイルはデバイスに依存するがＯＳには依存しない。
　このように、初期化のたびごとに必要な機能をディスパッチしても、実際にカーネルに登録された際に占有するメモリ量は従来のデバイスドライバと変わらず、この点においては従来のデバイスドライバと比較して何らデメリットがない。
　シナリオ・シーケンス・ファイルの読込処理は、従来のデバイスドライバにはない処理といえるが、近年のパソコンやスマートフォンなどのように、処理能力が高いマイクロプロセッサユニットと十分なメモリを有している場合には、多少ディスパッチの回数が増えてもデバイスが要求する時間内に処理（カーネルへの登録）が終わるので、特に問題が起こることはない。
　さらに、シナリオ・シーケンス・ファイルに記述されるコマンドは、呼び出す機能の内容及び順序などからなるが、それぞれの機能は部品化されているため、頻繁に使用される一連の機能はマクロプログラムとして定義しておくと使い勝手がよい。
　シナリオ・シーケンス・ファイルの読み込み処理の速度については主にシナリオ・シーケンス・ファイルから呼び出す機能のディスパッチに要する時間と関係する。あまり多くのコマンドを束ねると処理は速くなるが汎用性が損なわれて使いにくくなる。逆に、例えば「メモリ転送」のような頻繁に用いられるコマンドを扱うとディスパッチ回数が増え、非力なマイクロプロセッサユニットで読み込む場合はデバイスが要求する時間内にデバイスの認識が完了せずエラーになるおそれもあり、注意が必要である。したがって、マイクロプロセッサユニットの処理能力等から許容されるディスパッチ回数とシナリオ・シーケンス・ファイルの汎用性を考慮して、適宜設計するべきである。
　一般に、プロトコルパケットの処理などはマクロシーケンス化しやすいが、バス接続で割り込み処理の多いものはマクロシーケンス化することはやや非効率であると考えられる。いずれにせよ使いやすい単位でマクロ化することでシナリオ・シーケンス・ファイルは更に使いやすくなっていく。
　図２は、カーネル－デバイス間及びデバイス－デバイス間の物理的又は論理的な接続態様を示す図である。図中の実線はバスインターフェース接続を表し、破線は論理的インターフェース接続を表す。例えば、カーネルとＵＳＢホストコントローラとはバス接続で接続されるが、ＵＳＢホストコントローラに接続されるＵＳＢデバイスはプロトコルパケットで通信される論理的インターフェースということになる。例えば、図中のＳＤホストデバイスは、カーネルとＰＣＩバスなどの外部バスで接続され、ＳＤホストデバイスの先にはＷｉＦｉ（無線ＬＡＮ）モジュールなどの無線通信デバイスやメモリカードなどが「ＳＤバス（或いはその上位互換であるＳＤＩＯバス）」と呼ばれる外部バスを通じて接続されうることを示している。
　このように、デバイスがどのようなデバイスインターフェースを持つものであっても、通知用ドライバをカーネルに読み込んだ後、デバイスの初期化の際に、カーネルに対するデバイスの登録方法をデバイス設定情報として通知することで、あらゆるデバイスに対応したデバイスドライバを実現することができる。
（第２の実施形態）－デバイスドライバの登録方法－
　図３は、第２の実施形態のデバイスドライバの登録方法を示すフローチャートである。
－ステップＳ１－
　ステップＳ１では、第１の実施形態で説明した通知用ドライバをカーネルにロードする。ＯＳ起動後にデバイスドライバをロードする方法はＯＳによって異なっている。例えば、ＯＳがＬｉｎｕｘ（登録商標）である場合は、”ｉｎｓｍｏｄ”などのコマンドを用いる。ＯＳがＷｉｎｄｏｗｓ（登録商標）である場合には、「．ｓｙｓ」というドライバ定義ファイルを作成してプラグ・アンド・プレイでＯＳにデバイスドライバの読み込みを行わせることで必要なデバイス設定情報をレジストリに登録する方法が簡便である。その他のＯＳでもデバイスドライバをカーネルにロードするコマンドがある場合にはそれを利用する。このステップは通常は管理者権限で行うか、起動時にシステムが管理者権限で自動実行するように設定することが通常であるが、ユーザー権限で行えるようにすることも可能である。
－ステップＳ２－
　次に、デバイスを初期化を開始して（ステップＳ２）、シナリオ・シーケンス・ファイルを読み込む。ステップＳ１で通知用ドライバのロードが終了し、デバイスは待機状態にある。ここで、初期化を開始して、シナリオ・シーケンス・ファイルの読込を開始する。
この初期化ステップは、具体的には、例えば、デバイスの設定情報（パラメータ）を初期値に設定することや、デバイスの動作を決定する実行スクリプトに記述された実行コマンドを初期化する、或いは、シナリオ・シーケンス・ファイルを基にデバイスドライバを生成するための準備としてメモリ上に作業領域を確保することなどを含む。
　この初期化ステップをデバイス側とカーネル側のそれぞれからみた動作は、具体的には、例えば以下の通りとなる。
　Ｓ２－１．レジスタのデフォルト値を設定　＜ＯＵＴ側（デバイス側）＞
　　Ｏｕｔ側のセンサ部のレジスタ（例えば、デバイスがカメラモジュールであるとした場合、画面サイズ、フォーカスをどこから開始するか（通常は無限大側）、ホワイトバランス（画調）、露出時間などの各種デバイスパレメータ）を初期値に設定する。なお、カメラモジュールは一例であり、あらゆるデバイスの設定値が初期値に設定されることを意味する。
　Ｓ２－２．ワークメモリのクリア（ワークメモリをゼロで埋める）　＜ＩＮ側＞
　以上のステップにより、デバイスドライバをカーネルに登録した際には、常に同じ動作が保証されることになる。
　シナリオ・シーケンス・ファイルを読み込むことで初期化が完了する。
－ステップＳ３－
　次に、シナリオ・シーケンス・ファイルを基にハンドラを生成するメインスレッドを実行する（ステップＳ３）。このステップＳ３は特にリードとライトとＩ／Ｏコントロールの機能とシーケンスを生成するステップであり、ユーザー権限で実施することができる。たとえば、ユーザー権限でＩ／Ｏコントロールを使ってファイルの書き込み属性を変えることもできる。デバイスドライバはこの時点ではじめて自身の動作が確定する。
－ステップＳ４－
　次に、生成された上記各ハンドラの内容をデバイスドライバとしてカーネルに登録する（ステップＳ４）。このデバイスドライバは、ＯＳ上で利用できるような状態で登録されていればよく、方式や利用形態などを問わず、ＯＳのカーネルに組み込まれていればよい。
　すなわち、通知用ドライバがカーネルに読み込まれた時点（ステップＳ１）では、デバイスドライバとしての動作は確定しておらず、そこからデバイスを初期化してシナリオ・シーケンス・ファイルを読み込んでハンドラを生成し、カーネルに登録された時点（ステップＳ４）で初めて、デバイスドライバとして機能するようになる。本実施形態のデバイスドライバは、デバイス側からみた場合には、従来のデバイスドライバと何ら変わりない動作をすることはいうまでもない。
　以上のステップＳ１～Ｓ４により、シナリオ・シーケンス・ファイルに記述されたデバイス設定情報（デバイスパラメータ及びデバイスの動作を決定する実行スクリプト）を読み込むことでＯＳに依存しないデバイスドライバ１０を生成することができ、そのデバイスドライバ１０を用いることでインターフェース２３に接続されたデバイスを制御して使用することができるようになる。また、デバイスドライバ１０は従来のようなコンパイルが不要であるため、デバイスドライバ１０を容易に生成することができる。
－ステップＳ５－
　デバイスを取り外すときは終了（Ｔｅｒｍｉｎａｔｅ）する。
（第３の実施形態）
　図４は、計算機の基本構成を示す概念図である。計算機２０はマイクロプロセッサユニット２１とメモリ２２とデバイスインターフェース２３（図１の１０Ｃ）を具備する。マイクロプロセッサユニット２１は、主にＣＰＵ（Central Processing Unit）であり、ＦＰＧＡ（field-programmable gate array）やマイコンなど、各種のロジックＩＣを用いてもよい。メモリ２２は、ＲＡＭ（Random Access Memory）などの一時記憶装置を指す。
　デバイスインターフェース２３は、マイクロプロセッサユニット２１が制御する周辺機器用のものであればよく、具体的には、例えば図２に示すような各種デバイスに接続するものであればよい。ＰＣＩ（Peripheral Component Interconnect）カード、ネットワークカード、マイク、カメラ、ＵＳＢ、ＳＤカード、ＷｉＦｉ（Wireless Fidelity）内蔵機器、ＡＤＣ（Analog to Digital Converter）、Ｂｌｕｅｔｏｏｔｈ（登録商標）内蔵機器、ＧＰＳ内蔵機器、プリンタ、ＦＡＸ、スキャナなどである。デバイスインターフェース２３は、メモリ２２のような一時記憶装置又はハードディスクなどの記憶装置を接続するためのインターフェースであってもよく、キーボードやマウスと接続するための入力インターフェース、ディスプレイその他表示装置と接続するための出力インターフェースであってもよい。なお、メモリ２２も周辺機器であるため、例えば、メモリ２２は図示しないデバイスインターフェースであるメモリスロットに接続され、マイクロプロセッサユニット２１がメモリ２２用のデバイスドライバでメモリ２２を管理する。
　計算機２０にはＯＳがインストールされており、さらに、そのＯＳのカーネルに上記ステップＳ１～Ｓ５により生成されたデバイスドライバ１０が登録されている。そして、計算機２０のデバイスインターフェース２３の先にデバイス１２が接続されている。
　図１に示すドライバインターフェース１０Ａは、ＯＳの上記各ハンドラである。ドライバ１０は、ドライバインターフェース１０Ａ（各ハンドラ）とデバイス毎に決まったデバイスインターフェース１０Ｃの間でデータを送受信する役割を果たす。具体的には、ドライバ１０（１０Ｂ）は、上記ステップＳ３により確定された各ハンドラの処理を実施するためのプログラムである。
　以上のようなデバイスドライバ１０をシナリオ・シーケンス・ファイルを基に生成することにより、計算機２０は、デバイス１２との間でデバイスとの通信データを送受信することができる。
（実施例）－シナリオ・シーケンス・ファイルの具体例－
　以下に、デバイス設定情報を記述したシナリオ・シーケンス・ファイルの一例を挙げる。
シナリオ・シーケンス・ファイルはデバイスインターフェースに接続されるデバイスのデバイスパラメータとハンドラを生成するための実行スクリプトを記述したファイルであり、スクリプト形式のファイルであるため、テキストエディタで編集できる程度の非常に小さな（例えば２キロバイト以下のような）ファイルサイズのテキストデータで構成することもできる。実装により、ＪａｖａＳｃｒｉｐｔ（登録商標）やＸＭＬなど、ＯＳや計算機のハードウェア（ＭＰＵ）に依存しない中間言語の形式で記述してもよい。
　デバイスをカーネルに登録するために必要な情報は、
　（ａ）デバイスインターフェースに関する情報
　（ｂ）デバイスの動作内容に関する情報
　（ｃ）接続先デバイスに関する情報
である。これらの情報をシナリオ・シーケンス・ファイルに記述し、通知用ドライバを介してカーネルに登録すればよい。
　構成情報のわずかな変更があっても従来のようにデバイスドライバをソースコードから書き換えて再度コンパイルする必要はなく、シナリオ・シーケンス・ファイルの一部を書き換えてデバイスを初期化しなおすだけでよい。
　例えば、プリンタのように、同じデバイスでも複数の接続形式が可能なデバイスが存在する。ネットワークに接続できるプリンタが、ＵＳＢ接続あるいはシリアル接続可能な場合、ドライバインターフェースとデバイスドライバ本体の構成は変わらず、デバイスインターフェースだけが異なっている。接続形態が決まれば以後変わることがないため、実装前にどのデバイスインターフェースを実装するかを決定すればよい。ＵＳＢ接続からネットワーク接続（Ｅｔｈｅｒｎｅｔ（登録商標）接続）に変更したい場合は、ＯＳを起動した状態でしかもデバイスドライバもクローズすることなく、再度デバイスを初期化して、単に経路情報が変更されたことを示すデバイスインターフェースの部分を修正したシナリオ・シーケンス・ファイルを通知用ドライバで読み込むだけでよい。
　以下、シナリオ・シーケンス・ファイルで定義するデバイス設定情報（コマンドとパラメータ等）の例について説明する。
[処理命令定義]
　処理命令定義は、シナリオそのものの記述を行う実行コマンドが記述される。なお、デバイス（ハードウェア）に依存して決まっている割り込み番号は「int1」などの予約語として扱う。
　処理命令　：　処理内容
　wait intr(n)　：　割り込みID n の割り込みを待つ
　write $addr　：　ＯＳから受け取ったデータを$addrに書き込む
　write $addr,size　：　ＯＳから受け取ったデータを$addrから書き込む
　write data,$addr　：　dataを$addrに書き込む
　read $addr,size　：　$addrからsizeだけのデータをＯＳに返す
　copy $add1,$add2,size　：　$add1から$add2にsizeバイト データを転送する
　copy $add1,$add2,size　：　$add1から$add2にsizeバイト データを転送する
　copy #dataset(n)　：　データセットID n を転送する
　res data　：　dataをＯＳに返す
　and mask,$addr　：　$addrのデータとmaskの論理積を取り、条件分岐式に反映する
　or mask,$addr　：　$addrのデータとmaskの論理和を取り、条件分岐式に反映する
　if else endif　：　シナリオの条件分岐
　while endwhile　：　while～endwhile間を条件ループする
　for n endfor　：　for～endfor間をn回ループする
　exit　：　インターフェースを終了する
　処理命令定義には、その他、ＤＭＡ転送やｍｕｔｅｘなどを含む同期の仕組みなどの処理命令が記述される。
[データセット定義]
　データセット定義は、１つ又は複数のデータを１セットとしたデータセットの定義が記述される。データセットは任意の名前のデータ列を定義することができる。データ列には、レジスタと定義内容、書き込み後のタイミングなどを記述する。データセットは複数パターンを登録しておき、目的や場合に合わせて使い分ける。
　データセットの定義　：　定義内容
　b $addr and mask n　：　データセットbを「$addrの内容にmaskの論理積を１バイト書き込み n ミリ秒待つ」データ列と定義する
　w $addr or mask n 　：　データセットwを「$addrの内容にmaskの論理和を２バイト書き込み n ミリ秒待つ」データ列と定義する
　l $addr data n　：　データセットlを「$addrの内容にdataを４バイト書き込み n ミリ秒待つ」データ列と定義する
　次に、シナリオ・シーケンス・ファイルを基にＯＳの各ハンドラ（[init]、[term]、[open]、[close]、[I/O-ctrl]、[read]、[write]、[main_thread]）にデバイスパラメータ並びに処理命令定義及びデータセット定義を含む実行スクリプトを割り当てて各ハンドラの処理を構成したデバイスドライバの一例を以下に挙げる。このデバイスドライバを用いることで、決まったサイズのパケットを任意タイミングで送受信するデバイス、例えば、加速度センサーに対してメモリマップドレジスタへの読み書きを制御することができる。なお、以下の一部には「// コメント」を追記している。
[init]
　allocate $buffer 16;
　allocate $flag 1;
　exit;
[term]
　free buffer;
　free $flag;
　exit;
[open]　// 何もしない
　exit;
[close] // 何もしない
　exit;
[I/O-ctrl] // 何もしない
　exit;
[read]
　or.w #0001,$flag;
　if　// バッファにデータが有れば
　read $recive_data,16;　// データを読み出す
　write.w 1,$flag
　endif
　exit;
[write]
　write $send_reg,16;　// デバイス読み込み開始
　wait int1;　// 完了割り込み待ち
　exit;
[main_thread]　// 受信割り込みを待ってバッファに読み出す
　while;
　wait int1;　// 完了割り込み待ち
　read $recive_data,buffer,16;　// デバイスからバッファにデータを読み出しておく
　write.w 1,$flag;
　endwhile;
　インストラクションは上記のとおり比較的簡単なプログラムである。デバイスドライバとしての機能を確定させるために、テキストエディタでシナリオ・シーケンス・ファイルにシナリオ（インストラクションの順序）を記述し、パーシングしたシナリオにより記述した処理内容（例えばルックアップテーブルを持ったもの）をそれぞれのインターフェース（６種)をコールバックハンドラとして割り当てる。シナリオ・シーケンス・ファイルを読み込む方法はオープン・リード・ライト・クローズなどの機能を用いる。また、割り込みがある場合は割り込み待ちを行う。
　なお、一連の作業をデバイスメーカーではないユーザー等の第三者がデバイスメーカーからデバイス設定に必要なパラメータを得てシナリオ・シーケンス・ファイルを作成する場合、シナリオのスクリプト内容自体を変更するとドライバの動作が狂うおそれがある。従って、このような場合はテキストファイルではなく、他のアプリケーションツールなどを介してシナリオ・シーケンス・ファイルを作成・修正できるようにして、不要な設定を変更しないようにするなどの工夫をしてもよい。
（第４の実施形態）
　図５は、第４の実施形態のカメラモジュールを示すブロック図である。図５に示すように、カメラ本体５０は、計算機２０とカメラモジュール３０とを有する。カメラモジュール３０は、制御部３１と、デバイスインターフェース３３とセンサー３４と、ＩＲフィルタ３５やレンズ３６等の光学系部品とを有する。計算機２０とカメラモジュール３０とは、デバイスインターフェース２３、３３同士が例えばバスにより接続されている。
　カメラモジュールの制御部３１は、計算機２０やその他外部入力からの信号によりカメラモジュールの各部を制御する。また、カメラ本体５０は図示しないディスプレイ又はタッチパネルを有し、ディスプレイ又はタッチパネルはカメラモジュール３０に対する設定画面、カメラ本体５０で撮影した静止画や動画などを表示する。なお、カメラ本体５０はメモリや各デバイスに対するインターフェースをさらに有していてもよい。
　計算機２０によるカメラ本体５０に対する制御は、目的に応じて変更する必要がある。静止画取り込み、動画取り込み、解像度設定、感度設定などではカメラ本体５０に対する大量の設定値が存在し、そのそれぞれについて、画質の調整など、様々な調整が必要になる。この種のカメラモジュールような光学デバイスにいたっては、調整すべきデバイスパラメータの数は１０００を超えるものもあり、その作業は専門知識を要するものであった。このような場合に、コンパイルすることなくデバイスドライバを生成できることは、開発効率の大幅な向上につながる。
　また、事後的にユーザーの側でデバイスドライバを設定できる点に着目し、例えばあるレンズを販売する際に、それに合わせて遠近感を強調した撮影が可能となるような例えばホワイトバランス、エクスポージャー、フォーカス等を設定するパラメータを含むシナリオ・シーケンス・ファイルをユーザーに配布すれば、デバイスドライバをコンパイルすることなくユーザーが新しいデバイス設定情報に書き換え、そのレンズを取り付けたカメラを使用できるようになり、また、ユーザーがさらにその設定値を変更することもできるようになる。
　なお、本実施形態では、設定パラメータが多く一般にデバイスドライバの開発に時間のかかるカメラモジュールをデバイスとして例示したが、ＵＳＢ（ユニバーサル・シリアル・バス）を経由する全てのデバイス、パラレルポートやシリアルポートを経由して接続されるデバイス、ＳＤバスを経由して接続されるデバイス、ＰＣＩバスやＩＥＥＥ１３９４などを経由するバス型デバイス（内部バス、外部バスのいずれもが含まれる）など、使用時にカーネルに登録されるあらゆるデバイスが「デバイス」となりうる。
１０　デバイスドライバ
　１０Ａ　ドライバインターフェース
　１０Ｂ　デバイスドライバ本体
　１０Ｃ　デバイスインターフェース
１１　カーネル
１２　デバイス
２０　計算機
２１　マイクロプロセッサユニット（ＭＰＵ）
２２　メモリ
２３　デバイスインターフェース
３０　カメラモジュール
３１　制御部
３３　デバイスインターフェース
３４　センサー
３５　ＩＲフィルタ
３６　レンズ
５０　カメラ本体

Claims (6)

  1. 　デバイス設定情報をオペレーティングシステムのカーネルに通知するドライバインターフェースを備えた通知用ドライバと、デバイス設定情報を記述したシナリオ・シーケンス・ファイルとを備え、
    　前記通知用ドライバに前記シナリオ・シーケンス・ファイルが読み込まれることにより前記ドライバインターフェースを介してデバイス設定情報が前記カーネルに登録されるデバイスドライバの登録装置。
  2. 　デバイス設定情報をオペレーティングシステムのカーネルに通知するドライバインターフェースを備えた通知用ドライバと、デバイス設定情報を記述したシナリオ・シーケンス・ファイルとを用いて、前記通知用ドライバに前記シナリオ・シーケンス・ファイルを読み込むことにより前記ドライバインターフェースを介して前記カーネルに登録するデバイスドライバの登録方法。
  3. 　前記通知用ドライバは、デバイス設定情報をオペレーティングシステムに通知するインターフェースとしての機能だけを有する請求項２記載のデバイスドライバの登録方法。
  4. 　デバイス設定情報をオペレーティングシステムのカーネルに通知するドライバインターフェースを備えた通知用ドライバをカーネルにロードするステップＳ１と、
    　デバイスを初期化を開始してデバイス設定情報を記述したシナリオ・シーケンス・ファイルを読み込むステップＳ２と、
    　前記シナリオ・シーケンス・ファイルを基にハンドラを生成するメインスレッドを実行するステップＳ３と、
    　生成された前記各ハンドラの内容をデバイスドライバとしてカーネルに登録するステップＳ４と、
    　を具備するデバイスドライバの登録方法。
  5. 　前記ステップＳ２は、
    　Ｓ２－１．レジスタのデフォルト値を設定するステップと、
    　Ｓ２－２．ワークメモリをクリアするステップと、
    を含む請求項４記載のデバイスドライバの登録方法。
  6. 　前記ステップＳ３は、テーブルを用いてハンドラ毎にデバイスパラメータ及びデバイスの動作を決定する実行スクリプトをそれぞれ関連付けるステップを含む請求項４記載のデバイスドライバの登録方法。
PCT/JP2015/074780 2014-09-19 2015-08-31 デバイスドライバ登録装置とこれを用いたデバイスドライバの登録方法 WO2016043040A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2016514174A JP5997867B2 (ja) 2014-09-19 2015-08-31 デバイスドライバ登録装置とこれを用いたデバイスドライバの登録方法
CN201580050456.1A CN107077435B (zh) 2014-09-19 2015-08-31 设备驱动器注册装置以及使用该设备驱动器注册装置的设备驱动器的注册方法
US15/512,810 US10372461B2 (en) 2014-09-19 2015-08-31 Device driver registration device and device driver registration method using same

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014-191562 2014-09-19
JP2014191562 2014-09-19

Publications (1)

Publication Number Publication Date
WO2016043040A1 true WO2016043040A1 (ja) 2016-03-24

Family

ID=55533080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/074780 WO2016043040A1 (ja) 2014-09-19 2015-08-31 デバイスドライバ登録装置とこれを用いたデバイスドライバの登録方法

Country Status (4)

Country Link
US (1) US10372461B2 (ja)
JP (1) JP5997867B2 (ja)
CN (1) CN107077435B (ja)
WO (1) WO2016043040A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018008145A1 (ja) * 2016-07-08 2018-01-11 三菱電機株式会社 制御装置及び制御方法
WO2018212083A1 (ja) * 2017-05-17 2018-11-22 三菱電機株式会社 制御装置及び制御方法
CN114661379A (zh) * 2022-04-02 2022-06-24 经纬恒润(天津)研究开发有限公司 车载摄像头系统的解串器驱动程序改造方法及相关装置

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107423075B (zh) * 2017-08-28 2021-06-08 深圳传音控股股份有限公司 驱动的注册方法以及用户终端
CN111221571B (zh) * 2018-11-26 2024-03-15 西安诺瓦星云科技股份有限公司 外设驱动制作方法、装置以及计算机可读介质
WO2021125393A1 (ko) * 2019-12-19 2021-06-24 (주)로보티즈 마이크로컨트롤러유닛 기반 드라이버 인식 장치 및 방법
CN116541084B (zh) * 2023-06-29 2023-12-15 深圳艾为电气技术有限公司 压缩机驱动器的驱动装载控制方法、装置、设备及介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0689253A (ja) * 1991-03-26 1994-03-29 Internatl Business Mach Corp <Ibm> 汎用のオペレーティング・システム・インターフェースを有するデバイス・ドライバを含むデータ処理システム
JP2007265064A (ja) * 2006-03-29 2007-10-11 Sharp Corp 記憶装置、デバイス制御装置、デバイス制御プログラム、放送受像機及びデバイス制御方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1011384A (ja) 1996-06-24 1998-01-16 Sumitomo Metal Ind Ltd 入出力標準化装置
KR100464349B1 (ko) 2002-08-08 2005-01-03 삼성전자주식회사 디바이스 드라이버 제어 공통화 방법
US7203774B1 (en) * 2003-05-29 2007-04-10 Sun Microsystems, Inc. Bus specific device enumeration system and method
JP2009252194A (ja) * 2008-04-11 2009-10-29 Nec Electronics Corp データ処理装置、ハードウェアアクセス方法、及びハードウェアアクセスプログラム
JP5294892B2 (ja) * 2009-01-14 2013-09-18 キヤノン株式会社 画像形成装置、装置、制御方法、及びプログラム
JP4814407B1 (ja) * 2010-06-10 2011-11-16 パナソニック株式会社 再生装置、記録媒体、再生方法、プログラム
JP2012155515A (ja) * 2011-01-26 2012-08-16 Renesas Electronics Corp ソースデバイスドライバ及び実行モジュールの作成方法
JP5846016B2 (ja) * 2012-03-30 2016-01-20 富士通株式会社 情報処理装置、情報処理方法、及び情報処理プログラム
CN103853383B (zh) * 2014-03-05 2016-08-31 中南大学 一种在Uboot中实现触摸屏驱动的方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0689253A (ja) * 1991-03-26 1994-03-29 Internatl Business Mach Corp <Ibm> 汎用のオペレーティング・システム・インターフェースを有するデバイス・ドライバを含むデータ処理システム
JP2007265064A (ja) * 2006-03-29 2007-10-11 Sharp Corp 記憶装置、デバイス制御装置、デバイス制御プログラム、放送受像機及びデバイス制御方法

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018008145A1 (ja) * 2016-07-08 2018-01-11 三菱電機株式会社 制御装置及び制御方法
JPWO2018008145A1 (ja) * 2016-07-08 2019-03-07 三菱電機株式会社 制御装置及び制御方法
WO2018212083A1 (ja) * 2017-05-17 2018-11-22 三菱電機株式会社 制御装置及び制御方法
JPWO2018212083A1 (ja) * 2017-05-17 2019-11-07 三菱電機株式会社 制御装置及び制御方法
CN114661379A (zh) * 2022-04-02 2022-06-24 经纬恒润(天津)研究开发有限公司 车载摄像头系统的解串器驱动程序改造方法及相关装置
CN114661379B (zh) * 2022-04-02 2024-01-05 经纬恒润(天津)研究开发有限公司 车载摄像头系统的解串器驱动程序改造方法及相关装置

Also Published As

Publication number Publication date
CN107077435B (zh) 2020-03-31
US20170286124A1 (en) 2017-10-05
JPWO2016043040A1 (ja) 2017-04-27
JP5997867B2 (ja) 2016-09-28
US10372461B2 (en) 2019-08-06
CN107077435A (zh) 2017-08-18

Similar Documents

Publication Publication Date Title
JP5997867B2 (ja) デバイスドライバ登録装置とこれを用いたデバイスドライバの登録方法
JP6259122B2 (ja) ファームウェアアップグレード方法、装置、プログラム及び記録媒体
US8352577B2 (en) Method and apparatus for updating information on an embedded system
WO2014105120A2 (en) Camera command set host command translation
JP7093979B2 (ja) デバイスプロキシ装置及びそれを含む計算機システム
EP3086224A1 (en) Enabling a metadata storage subsystem
WO2019182335A1 (ko) 전자 장치 및 전자 장치의 업데이트 제어 방법
US20190236035A1 (en) Standardized device driver having a common interface
US9141321B1 (en) Configurable printer server device
US20190191079A1 (en) Camera initialization for a multiple camera module
US10592644B2 (en) Information protection method and device based on a plurality of sub-areas for MCU chip
EP3096233A1 (en) Executing a command within a transport mechanism based on a get and set architecture
WO2023155363A1 (zh) 服务器动态热备份的方法、装置、设备及存储介质
JP2009064303A (ja) 撮像装置、共用リソース管理方法、およびプログラム
KR102276696B1 (ko) 집적 회로 무선장치
CN109982136B (zh) 音量调节的方法及装置
KR100310307B1 (ko) 내장형시스템의운영체제개발을위한쉘기능제공방법
JP2024044011A (ja) 情報処理装置及び情報処理方法
JP2006048417A (ja) Ｐｃカードアダプタ
Zhang et al. Realization of Automatic Keystone Correction for Smart mini Projector Projection Screen
US20170097836A1 (en) Information processing apparatus
CN117492581A (zh) 触摸框设备的注册方法、数据处理方法、介质以及设备
CN113835757A (zh) 多主机共享寄存器模型的方法、装置及电子设备
CN110879727A (zh) 一种调节显示屏亮度的方法
JP2014026454A (ja) ブリッジ回路

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2016514174

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15841708

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 15512810

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 15841708

Country of ref document: EP

Kind code of ref document: A1