WO2016026449A1 - 一种操作系统中控制硬件设备的方法和模块 - Google Patents

一种操作系统中控制硬件设备的方法和模块 Download PDF

Info

Publication number
WO2016026449A1
WO2016026449A1 PCT/CN2015/087608 CN2015087608W WO2016026449A1 WO 2016026449 A1 WO2016026449 A1 WO 2016026449A1 CN 2015087608 W CN2015087608 W CN 2015087608W WO 2016026449 A1 WO2016026449 A1 WO 2016026449A1
Authority
WO
WIPO (PCT)
Prior art keywords
hardware device
data
layer
function
action
Prior art date
Application number
PCT/CN2015/087608
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
Priority claimed from CN201410415227.2A external-priority patent/CN104216709B/zh
Priority claimed from CN201410456540.0A external-priority patent/CN104636128B/zh
Priority claimed from CN201410510111.7A external-priority patent/CN104267956B/zh
Application filed by 深圳光启智能光子技术有限公司 filed Critical 深圳光启智能光子技术有限公司
Priority to EP15833667.7A priority Critical patent/EP3196759A4/en
Priority to KR1020177007449A priority patent/KR101960443B1/ko
Priority to JP2017510390A priority patent/JP6462114B2/ja
Publication of WO2016026449A1 publication Critical patent/WO2016026449A1/zh
Priority to US15/437,047 priority patent/US10599493B2/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • G06F9/4411Configuring for operating with peripheral devices; Loading of device drivers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/545Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10Program control for peripheral devices
    • G06F13/105Program control for peripheral devices where the programme performs an input/output emulation function
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44521Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4494Execution paradigms, e.g. implementations of programming paradigms data driven

Definitions

  • the present application relates to the development of an operating system of an electronic device, and in particular to a method and a module for controlling a hardware device in an operating system.
  • the first layer 101 is the Linux kernel driver layer (Linux kernel), which is implemented by C/C++.
  • the Android core system service relies on the Linux kernel, including security, memory management, process management, network protocols, driver models, and more.
  • the Linux kernel also acts as an abstraction layer between the hardware and the software stack.
  • Android also adds kernel drivers such as Binder (IPC) drivers, camera drivers, power management, and more.
  • IPC Binder
  • the second layer is the component library and the virtual machine layer, wherein 102 is a component library layer (Libraries), 103 is a virtual machine layer (Android Runtime), and the component library layer 102 is implemented by C/C++, and includes a C/C++ library for Used by different components in Android, they serve developers through the Android application framework.
  • the virtual machine layer 103 acts as a motion environment for the Android system, which provides most of the functions of the Java programming language core library, consisting of the Dalvik Java virtual machine and the underlying Java class library.
  • the third layer 104 is an Application Framework.
  • the developer can also fully access the API (Application Programming Interface) framework used by the core application.
  • API Application Programming Interface
  • the fourth layer 105 is the application layer (Applications), the Android application is written in the Java language, the user-developed Android application and the Android core application are at the same level, and they are all built based on the Android system API. .
  • visible light communication is usually used, and the visible light can be used for data transmission or for illumination.
  • the transmission speed the blinking frequency of visible light
  • the Android system when it is necessary to control the flash switch, it is usually first to call the camera driver, and use the camera's own interface to set the camera's parameters to achieve the flash switch.
  • This way of controlling the flash is an indirect control, and its call to the flash has a certain time delay.
  • the prior art realizes the control mode of the flash switch by first calling the camera driver, using the interface provided by the camera, and setting the parameters of the camera, which belongs to the indirect control, and has a certain time delay for the flash call.
  • the present application provides a method for controlling a hardware device in an operating system, including: acquiring a link library load instruction, loading a link library, and the link library includes a function for controlling a hardware device action a function; acquiring an instruction for controlling an action of the hardware device; calling a function implementation function corresponding to the instruction of the control hardware device in the link library; executing a function implementation function called to control the hardware device to perform a corresponding action.
  • the present application provides a module for controlling a hardware device in an operating system, including: a loading unit, configured to acquire a link library loading instruction, and load a link library, where the link library includes a function implementation function of the hardware device action; a detection unit, configured to acquire an instruction for controlling an action of the hardware device; and a calling unit, configured to invoke a function implementation function corresponding to the instruction of the control hardware device in the link library; The unit is configured to control the hardware device driver to execute the called function implementation function to control the hardware device to perform the corresponding action.
  • the present application provides a method for controlling a hardware device in an operating system, including: acquiring state data for controlling an action of a hardware device; and transmitting and storing the state data to In the buffer unit, the hardware device driver is invoked, and the light emitting device drives the reading of the state data stored in the buffer unit, and controls the state of the hardware device action according to the state data.
  • the present application provides a module for controlling a hardware device in an operating system, including: a state data acquiring unit, configured to control an application layer to acquire state data for controlling an action of a hardware device. a transmission unit for controlling the application layer to deliver the status data, a buffer unit for storing state data delivered by the application layer, and an execution unit for controlling the application layer to call hardware located in the kernel driver layer
  • the device drives and controls the hardware device driver to read the state data stored in the buffer unit, and controls the state of the hardware device action according to the state data.
  • the method and the module for controlling the hardware device in the operating system provided by the present application, after obtaining the state data for controlling the action of the hardware device, first sending and storing the state data to the buffer unit, and then calling the hardware device driver, the hardware
  • the device driver reads the state data stored in the buffer unit and controls the state of the hardware device action based on the state data.
  • the calling hardware device driver specifically includes: calling an existing hardware device driver to control the hardware device action; or, acquiring a link library loading instruction, loading the link library; and acquiring an instruction for controlling the action of the hardware device, calling the link library and The function implementation function corresponding to the hardware device action instruction; then executing the called function implementation function to control the hardware device to perform the corresponding action.
  • the hardware device driver controls the hardware device to perform a corresponding action as a direct control mode.
  • the state data is stored in the buffer unit, after the hardware device driver is invoked, The status data stored in the buffer unit is directly read, and the reading process is continuous, which avoids the interruption, delay, and the like of the hardware device driver in the process of driving the hardware device, thereby improving the accuracy of data transmission, and Provides guarantee for high speed data transmission.
  • 1 is a schematic diagram of an architecture of an Android system
  • FIG. 2 is a schematic structural diagram of an Android system according to Embodiment 1 of the present application.
  • FIG. 3 is a schematic structural diagram of an Android system according to Embodiment 1 of the present application.
  • FIG. 4 is a schematic flowchart of a method for controlling a hardware device in an Android system according to Embodiment 1 of the present application;
  • FIG. 5 is a schematic structural diagram of a module for controlling a hardware device in an Android system according to Embodiment 2 of the present application;
  • FIG. 6 is a schematic flowchart of a method for controlling a hardware device in an Android system according to Embodiment 3 of the present application;
  • FIG. 7 is a schematic structural diagram of a module for controlling a hardware device in an Android system according to Embodiment 4 of the present application;
  • FIG. 8 is a schematic flowchart of a method for controlling a hardware device in an Android system according to Embodiment 5 of the present application;
  • FIG. 9 is a schematic structural diagram of a module for controlling a hardware device in an Android system according to Embodiment 6 of the present application.
  • the embodiment of the present application is described by taking an example of controlling a light-emitting device (flash) switch in an Android system.
  • the operating system referred to in the present application may also be a Blackberry OS system, a windows phone system, Other operating systems such as windows mobile systems, IOS systems, or Mac OS systems.
  • the hardware device can also be a camera, a vibrator, a Bluetooth, a sensor, a microphone, etc. in the electronic device.
  • the kernel driver is implemented in the Linux kernel space (Linux Kernel layer).
  • the program flash drive
  • hardware abstraction layer interface in user space to provide hardware access to the upper layer, which provides hardware services for the application framework layer of Android. Since the Android application is written in the Java language, the hardware driver is implemented in the C/C++ language, and Java provides the JNI (Java Native Interface) method call, so in the Android system, Java applications can call the hardware abstraction layer interface through JNI.
  • JNI Java Native Interface
  • the architecture of the Android system is divided into five layers.
  • the first layer 201 is a Linux kernel driver layer (Linux kernel)
  • the second layer 202 is a hardware abstraction layer (HAL)
  • the third layer 203, 204 is a component library layer 203 (Libraries) and a virtual machine layer 204 ( Android Runtime)
  • the fourth layer 205 is the application framework layer (Application Framework)
  • the fifth layer 206 is the application layer (Applications).
  • Figure 3 shows an analysis of the architecture of the Android system from another perspective.
  • the entire Android system can be divided into three parts: hardware, kernel space and user space, and the content of each of them is shown in Figure 3.
  • the JNI layer is divided into the third layer, and the JNI layer designs a series of interface functions for the application framework layer, and in the specific implementation of the interface functions, the callback function is used to interact with the hardware abstraction layer.
  • the method for controlling the flash switch provided by the embodiment of the present application is also applicable to the Android system of the architecture shown in FIG. 1.
  • the function of adding the hardware abstraction layer in this embodiment is that the interface does not have a standard Linux kernel driver layer.
  • the hardware device provides an access path, and converts the originally poorly readable interface into a readable interface for the upper layer program call. That is, the hardware abstraction layer runs on the Linux kernel driver layer for providing the interface implementation of the flash control for the application framework layer and the JNI layer with the support of the Linux kernel driver layer.
  • the embodiment provides a method for directly controlling a flash switch in an Android system, including the following steps:
  • Step 301 The application framework layer detects the link library loading instruction.
  • the link library load instruction may be an instruction issued by the Android system after startup; on the other hand, the link library only needs to be called.
  • the corresponding function needs to be loaded when the function is implemented. Therefore, the link library load instruction may be an instruction issued by the Android system when the function implementation function is called.
  • Step 302 The application framework layer loads the link library, and the link library includes a function implementation function for controlling the flash action.
  • the function implementation function is a function for controlling the action of the flash, for example:
  • the driving signal of the LED needs to be given by another device, such as a CPU chip or a camera chip, the device needs to be turned on first, and then the LED is driven to emit light.
  • the mode of the control lamp is more flexible, such as different colors, different brightness, etc., you can write the following function:
  • the above functions for controlling the flash action can be saved in the .c file after the definition.
  • the .c file is the definition of all variables and functions.
  • Step 303 The application layer acquires an instruction for controlling the flash action.
  • the instruction may be an instruction input by the user through the human-machine interaction interface (ie, application layer) of the Android device for controlling the flash action; or may be an encoded instruction string in the application layer, for example, “0” and “ A data string represented by 1", where "0" indicates that the flash is off and "1" indicates that the flash is turned on.
  • the instruction for controlling the flash action in step 303 can also be used as a link library load instruction, and the instruction for controlling the flash action can be understood as a call to the function realization function. Therefore, it should be noted that the implementation The order of the steps of the method provided in the examples should not be construed as limiting the present application. In other embodiments, the order of the steps may be appropriately changed according to actual conditions.
  • Step 304 The application layer detects whether the link library is loaded, and if not, continues to load the to-be-linked library, and if yes, proceeds to step 305.
  • Step 305 The application layer invokes a function implementation function in the link library corresponding to the instruction for controlling the flash action.
  • the application layer can call the function implementation function when it detects that the link library is fully loaded, or call it at the same time as the detection, or can set a predetermined time. When a certain predetermined time is met, the function realization function is called.
  • Step 306 The Linux kernel driver layer executes the called function implementation function to control the flash to perform the corresponding action.
  • a flash driver is provided in the Linux kernel driver layer, and the flash driver executes the called function implementation function to control the flash to perform the corresponding action.
  • the flash is usually only used as the auxiliary hardware of the camera. It is only possible to use the flash when using the camera. Therefore, when using the flash in the Android system, the camera driver must be called first, and the flash is set by setting the camera parameter. control. That is, the control of the flash is an indirect control.
  • the flash driver is independently set in the Linux kernel driver layer of the Android system.
  • the flash driver can be directly invoked, and the control mode of the flash is direct control.
  • the time delay that occurs when the flash is controlled by the camera driver can be avoided.
  • the JNI layer defines interface functions.
  • the application layer calls the function implementation function corresponding to the instruction for controlling the flash action in the link library according to the interface function of the JNI layer, so that the flash driver of the Linux kernel driver layer executes the corresponding function realization function.
  • the syscall is a localized interface, and the interface function of the JNI layer defined in the Android system can be implemented, and details are not described herein.
  • the interface function of the JNI layer defines the correspondence between the C/C++ function and the JAVA function.
  • the interface function uses the JNI method to map the C/C++ function of the hardware abstraction layer to the JAVA function of the application layer to implement the hardware abstraction layer.
  • C/C++ language interaction with the application layer (using the JAVA language).
  • Led_on is a JAVA function. Only the mapping of the JNI interface can call the underlying function. It will be mapped to a local function named java_full package name_class_name_led_on in the JNI layer, and then the underlying function will be called in the function.
  • the Dalvik virtual machine in the Android runtime environment calls a member function, if it finds that the member function is a JNI method, it will jump directly to its address to execute. That is, the JNI method is executed directly on the local operating system, not by the Dalvik virtual machine interpreter. Therefore, the JNI method is a means for Android applications to communicate directly with the local operating system, making communication more efficient through the JNI approach.
  • the JNI layer stores the address after the function implementation function is instantiated, so that the JNI layer directly calls the function implementation function.
  • Instantiation refers to the process of creating objects with classes in object-oriented programming. For example, during the control of the flash, the flash action is taken as a class, and the specific function realization functions such as turning on the flash and turning off the flash are created as objects. The creation process of this object is instantiated. After the object is created, there will be a corresponding address. After the JNI layer saves the address, when the function implementation function is subsequently called, the corresponding object can be quickly queried according to the address, without first retrieving the corresponding function of the function implementation function. class.
  • hw_module_methods_t This structure only provides an interface to open the open function of the special device.
  • the input parameters are "hw_module_t, id" and "w_device_t”. This function is used to initialize each member of hw_device_t.
  • Strcut hw_device_t.//Device type For each device data structure, it must start with the structure, which is the guide line of all devices, after which the device itself is the data of each device.
  • the hardware abstraction layer stipulates that the hw_module_t structure cannot be directly used, and an inheritance is required, that is, a layer of structure is set outside the structure, but the hw_module_t structure must be the structure.
  • a structure is a collection of data consisting of a series of data of the same type or different types.
  • the structure is used to encapsulate some attributes, parameter values (ie, data members) to form a new type. After encapsulation, the attributes and parameter values can be used multiple times.
  • the defined structure may include flash brightness, flash on/off time, etc., while the brightness value, on/off time is encapsulated as a data member in the structure of the corresponding category.
  • the data members can also be functions, which can be used not only to describe the state of the object, but also to describe the behavior of the object, such as the function LED_ON, LED_OFF, LED_DEVICE_OPEN, which controls the flash on/off.
  • LED_DEVICE_CLOSE which respectively correspond to the aforementioned led_on, led_off, led_device_open, led_device_close functions.
  • the embodiment further provides a module for directly controlling the flash switch in the Android system, including the loading unit 401 and the detecting unit. 402. Calling unit 403 and executing unit 404.
  • the loading unit 401 is configured to acquire a link library load instruction and load a link library, and the link library includes a function implementation function for controlling a flash action.
  • the detecting unit 402 is configured to acquire an instruction to control the action of the flash.
  • the loading unit 401 After the loading unit 401 detects that the loading unit 401 loads the dynamic link library, it calls a function implementation function corresponding to the instruction for controlling the flash action in the link library, or invokes it at the same time of detection, or can set a predetermined time.
  • the link library is called when a certain predetermined time is met.
  • the execution unit 404 is configured to execute the called function implementation function to control the flash to perform the corresponding action.
  • the architecture of the Android system includes an application layer, an application framework layer, a component library and a virtual machine layer, and a Linux kernel driver layer.
  • a flash driver is provided in the Linux kernel driver layer, and the execution unit 404 is configured to control the flash driver in the Linux kernel driver layer to execute the called function implementation function to control the flash to perform the corresponding action.
  • the architecture of the Android system also includes the JNI layer, which is defined by the JNI layer.
  • the loading unit 401 is configured to control the application framework layer to detect that the link library loading instruction is obtained, and then load the link library.
  • the calling unit 403 is configured to control the application layer to call a function implementation function corresponding to the instruction for controlling the flash action in the link library according to the interface function of the JNI layer, so that the flash driver of the Linux kernel driver layer executes the corresponding function implementation function.
  • JNI layer holds the address after the function implementation function is instantiated.
  • the architecture of the Android system further comprises a hardware abstraction layer running on the Linux kernel driver layer for providing an interface for the flash control interface for the application framework layer and the JNI layer supported by the Linux kernel driver layer. .
  • the IOS system also includes a library library adaptation, which can implement the hardware abstraction layer in the architecture similar to the Android system, and will not be described here.
  • the link library is loaded; after obtaining the instruction for controlling the flash action, calling the link library and The function corresponding to the instruction implements the function; then executes the called function implementation function to control the flash to perform the corresponding action, thereby achieving direct control of the flash switch.
  • the method and the module for directly controlling the flash switch in the Android system provided by the embodiment of the present application can also be extended to the WP operating system, and the specific implementations are similar and will not be described again.
  • the inventive concept of the embodiment is that the state data for controlling the action of the hardware device is first stored by using the buffer unit, and the data stored in the buffer unit is directly readable by the hardware device driver, and after the state data is stored, the hardware is called again.
  • the device driver, the hardware device driver reads the state data stored in the cache unit, and controls the state of the hardware device action according to the state data.
  • the status data in the hardware device driver read buffer unit is continuous, and there is no time delay, interruption, etc., thereby ensuring the accuracy of data transmission, and also Provides guarantee for high speed data transmission.
  • the hardware device in this embodiment may be a light emitting device, a vibrator, a Bluetooth, a camera, a sensor, or a microphone.
  • the embodiment mainly describes the hardware device as a light-emitting device.
  • the hardware device is driven by the light-emitting device, the state data is time data, and the hardware device acts as the light-emitting device is turned on or off.
  • the embodiment provides a method for controlling a hardware device in an operating system.
  • the hardware device is a light emitting device, and includes the following steps:
  • Step 501 Acquire original data.
  • the original data may be data input by the user, such as a bank card account input by the user.
  • raw data can be obtained by the application layer.
  • Step 502 Encoding the original data to obtain time data for controlling whether the light emitting device is turned on or off. For example, controlling the light emitting device to turn on 5s, off 2s, open 3s...
  • the original layer can be applied by the application layer.
  • the data is encoded.
  • the user directly inputs time data for controlling the turning on or off of the light emitting device, that is, the original data is time data, then no encoding operation is required.
  • the light emitting device may specifically be its own light source in the electronic device, such as an LED flash; or other light source, such as a light source plugged into the mobile phone, which may be a laser emitter or an LED.
  • the acquired raw data is usually N-carrying data, and encoding the original data is equivalent to encoding the N-carrying data into an electrical signal unit, as follows:
  • the step includes: encoding each different digital data in the N-carrying data into different electrical signal units, and the high and low level durations in the electrical signal unit
  • the segments are Ti 1, Ti2, ... and Tij, respectively, i, j, and N are natural numbers, and different electrical signal units are separated by a separation mark.
  • the high and low levels in the electrical signal unit of this example are not defaulted to high first. After the low level, it can also be low level first and then high level.
  • the separation flag between high and low level can be level jump, or the high level and low level with different durations are characteristic levels.
  • the flag is a reference level that is different from the feature level.
  • At least part of the N-carrying data to be encoded may be encoded into level signals having different states, and divided into multiple files according to the level signal size, and different files represent different numbers in the N-carrying data.
  • the original data is data that has not been converted into N-carry data
  • the original data needs to be converted into N-carry data first.
  • the operation values of Ti2, Ti3, ... and Tij and Ti1 are predetermined values or predetermined ranges, and the operations herein refer to: Ti2, Ti3, ... and the ratio of Tij to Ti1, product, difference, sum, reciprocal, and/or Calculate the remainder.
  • the binary data 0 is encoded into the first electrical signal unit, and the high and low level durations in the first electrical signal unit are respectively T11 and T12;
  • the level transition is a transition from a high level to a low level.
  • a level transition occurs in an electrical signal unit, wherein the high level controls the LED flash, and the low level control
  • the LED flash does not emit light; in other embodiments, the opposite control mode may be employed, such as a level transition from a low level to a high level, wherein the low level controls the LED flash, and the high level controls the LED.
  • the flash does not glow.
  • Step 503 The time data is delivered.
  • the application layer can send the time data to the kernel driver layer.
  • Step 504 Store the delivered time data into the buffer unit.
  • the Android system specifically: after the kernel driver layer obtains the time data sent by the application layer, it stores it in the buffer unit set in the kernel driver layer.
  • the data stored in the buffer unit is directly readable by the driving of the light emitting device, and the buffer unit functions to temporarily store the time data, which may be a buffer register.
  • the buffer unit may also use a conventional system storage unit to separate a part or all of the storage unit by a program method as a buffer unit in this embodiment.
  • Buffer registers also known as buffers, can be divided into input buffers and output buffers.
  • the former's role is to temporarily store the data sent by the peripherals, so that the processor can take it away; the latter is used to temporarily store the data sent by the processor to the peripherals.
  • the buffer can coordinate and buffer the high-speed working CPU with the slow working peripheral to achieve data transfer synchronization.
  • Step 505 After the time data corresponding to the data to be sent is sent and stored, the light emitting device is driven to ensure that the light emitting device is in an available state.
  • the program layer should call the light emitting device driver located in the kernel driver layer.
  • Step 506 After the illumination device driver is called, the time data stored in the buffer unit is read.
  • Step 507 After the driving device drives the reading time data, the time when the light emitting device is turned on or off is controlled according to the time data.
  • the time data is an array.
  • the light emitting device drives the time when the light emitting device is turned on or off according to the time data, specifically: the light emitting device drives the time when the light emitting device is turned on or off according to the order of the data elements in the array.
  • the format of the time data may also be in other feasible manners in the prior art.
  • the time data for controlling the turning on or off of the light-emitting device is first stored by using the buffer unit, and after the time data is stored, the light-emitting device is driven to be driven, and the light-emitting device is driven to read and save.
  • the time data in the buffer controls the time when the light-emitting device is turned on or off according to the time data.
  • the time data in the driving device of the light-emitting device is continuous, and there is no time delay phenomenon, thereby ensuring the accuracy of data transmission and ensuring high-speed data transmission of optical communication.
  • the operating system in this embodiment may be an Android system, a Blackberry OS system, a windows phone system, a windows mobile system, an IOS system, a Mac OS system, etc., although there are differences in each system, in order to implement the embodiment.
  • a method of controlling a light emitting device under the concept of the present invention, Those skilled in the art can achieve the object by appropriate changes.
  • the status data may also be intensity data for controlling the illumination intensity of the illumination device.
  • corresponding state data may also be intensity data for controlling the vibration intensity of the vibrator.
  • the implementation principle is the same as that of the illuminating device, and is not described in this embodiment.
  • the embodiment provides a module for controlling a hardware device in an operating system, where the hardware device is a light emitting device, and includes a time data acquiring unit 601. Transmission unit 602, buffer unit 603, and execution unit 604.
  • the time data acquisition unit 601 is configured to control the application layer to acquire time data for controlling whether the light emitting device is turned on or off.
  • the original data may be data input by the user, such as a bank card account input by the user.
  • the encoding subunit 605 is not required to perform the encoding operation.
  • the light emitting device may specifically be its own light source in the electronic device, such as an LED flash; or other light source, such as a light source plugged into the mobile phone, which may be a laser emitter or an LED.
  • the transmission unit 602 is configured to control the application layer to deliver time data to the kernel driver layer.
  • the buffer unit 603 is configured to store time data delivered by the application layer. After the kernel driver layer obtains the time data sent by the application layer, it stores it in the buffer unit 603 disposed in the kernel driver layer.
  • the buffer unit 603 is directly readable by the light emitting device drive, and the buffer unit 603 functions to temporarily store time data, which may be a buffer register. In other embodiments, the buffer unit 603 may also use a conventional system storage unit to separate a part or all of the storage unit by a program method as the buffer unit 603 in this embodiment.
  • Buffer registers also known as buffers, can be divided into input buffers and output buffers.
  • the former's role is to temporarily store the data sent by the peripherals, so that the processor can take it away; the latter is used to temporarily store the data sent by the processor to the peripherals.
  • the buffer can coordinate and buffer the high-speed working CPU with the slow working peripheral to achieve data transfer synchronization.
  • the execution unit 604 is configured to control the application layer to invoke the light emitting device driving in the kernel driving layer, and control the light emitting device to drive the reading of the time data stored in the buffer unit, and control the time when the light emitting device is turned on or off according to the time data.
  • the program layer should call the light-emitting device driver located in the kernel driver layer to ensure that the light-emitting device is in an available state.
  • the driving of the light emitting device is called, the time data stored in the buffer unit is read, and the light emitting device is controlled to be turned on according to the time data. The time of opening or closing.
  • the time data is an array.
  • the light emitting device drives the time when the light emitting device is turned on or off according to the time data: the light emitting device drives the time when the light emitting device is turned on or off according to the order of the data elements in the array.
  • the format of the time data may also be in other feasible manners in the prior art.
  • the time data for controlling the light-emitting device to be turned on or off is first stored by the buffer unit 303, and after the time data is stored, the light-emitting device is driven to be driven, and the light-emitting device is driven to read.
  • the time data stored in the buffer controls the time when the light-emitting device is turned on or off based on the time data.
  • the time data in the driving device of the light-emitting device is continuous, and there is no time delay phenomenon, thereby ensuring the accuracy of data transmission and ensuring high-speed data transmission of optical communication.
  • the operating system in this embodiment may be an Android system, a Blackberry OS system, a windows phone system, a windows mobile system, an IOS system, a Mac OS system, etc., although there are differences in each system, in order to implement the embodiment.
  • a module for controlling a light-emitting device can be achieved by a person skilled in the art with appropriate modifications under the concept of the present invention.
  • the status data may also be intensity data for controlling the illumination intensity of the illumination device.
  • corresponding state data may also be intensity data for controlling the vibration intensity of the vibrator.
  • the implementation principle is the same as that of the illuminating device, and is not described in this embodiment.
  • the state data for controlling the operation of the hardware device is first stored by using the buffer unit, and the data stored in the buffer unit is directly read by the hardware device driver, and after the state data is stored, the hardware device driver is called.
  • the hardware device driver reads the state data stored in the cache unit, and controls the state of the hardware device action according to the state data.
  • the status data in the hardware device driver read buffer unit is continuous, and there is no time delay, interruption, etc., thereby ensuring the accuracy of data transmission and ensuring high-speed data transmission.
  • the hardware device in this embodiment may be a light emitting device, a vibrator, a Bluetooth, a camera, a sensor, or a microphone.
  • the present embodiment mainly describes a hardware device as a light-emitting device (flash).
  • the hardware device is driven by a flash, the state data is time data, and the hardware device acts as a flash on or off.
  • the embodiment provides a method for controlling a hardware device in an operating system, including the following steps:
  • Steps 701-704 are the same as steps 501-504 in the third embodiment.
  • Steps 705-710 are the same as steps 301-306 in the first embodiment.
  • Step 711 The flash driver reads the time data stored in the buffer unit.
  • Step 712 After the flash drive reads the time data, the time when the light emitting device is turned on or off is controlled according to the time data.
  • the flash is usually only used as the auxiliary hardware of the camera. It is only possible to use the flash when using the camera. Therefore, when using the flash in the Android system, the camera driver must be called first, and the flash is set by setting the camera parameter. control. That is, the control of the flash is an indirect control.
  • the flash driver is independently set in the Linux kernel driver layer of the Android system.
  • the flash driver can be directly invoked, and the control mode of the flash is direct control.
  • the time delay that occurs when the flash is controlled by the camera driver can be avoided.
  • step 705-step 709 is a hardware device driver (flash drive) calling mode provided by this embodiment, and belongs to a direct control mode.
  • the existing hardware device driver can be invoked in any of the prior art manners to control hardware device actions, such as in the manner of indirect control described above.
  • the JNI layer defines interface functions.
  • the application layer calls the function implementation function corresponding to the instruction for controlling the flash action in the link library according to the interface function of the JNI layer, so that the flash driver of the Linux kernel driver layer executes the corresponding function realization function.
  • the syscall is a localized interface, and the interface function of the JNI layer defined in the Android system can be implemented, and details are not described herein.
  • the interface function of the JNI layer defines the correspondence between the C/C++ function and the JAVA function.
  • the interface function uses the JNI method to map the C/C++ function of the hardware abstraction layer to the JAVA function of the application layer to implement the hardware abstraction layer.
  • C/C++ language interaction with the application layer (using the JAVA language).
  • Led_on is a JAVA function. Only the mapping of the JNI interface can call the underlying function. It will be mapped to a local function named java_full package name_class_name_led_on in the JNI layer, and then the underlying function will be called in the function.
  • the Dalvik virtual machine in the Android runtime environment calls a member function, if it finds that the member function is a JNI method, it will jump directly to its address to execute. That is, the JNI method is executed directly on the local operating system, not by the Dalvik virtual machine interpreter. Therefore, the JNI method is a means for Android applications to communicate directly with the local operating system, making communication more efficient through the JNI approach.
  • the JNI layer stores the address after the function implementation function is instantiated, so that the JNI layer directly calls the function.
  • Instantiation refers to the process of creating objects with classes in object-oriented programming. For example, during the control of the flash, the flash action is taken as a class, and the specific function realization functions such as turning on the flash and turning off the flash are created as objects. The creation process of this object is instantiated. After the object is created, there will be a corresponding address. After the JNI layer saves the address, when the function implementation function is subsequently called, the corresponding object can be quickly queried according to the address, without first retrieving the corresponding function of the function implementation function. class.
  • the following three structures are defined in the hardware abstraction layer.
  • the three structures in the hardware abstraction layer in this embodiment are the same as those in the first embodiment, and are not described here.
  • the time data is an array.
  • the flash driver controls the time when the flash is turned on or off based on the time data.
  • the light-emitting device driver controls the time when the flash is turned on or off according to the order of the data elements in the array.
  • the format of the time data may also be in other feasible manners in the prior art.
  • the time data for controlling the flash to be turned on or off is first stored by using the buffer unit, and after the time data is stored, the light emitting device is called to be driven, and the flash driver is saved and stored in the buffer.
  • the time data in the time according to the time data to control the time when the flash is turned on or off.
  • the time data in the flash drive read buffer is continuous, and there is no time delay, which ensures the accuracy of data transmission and also guarantees high-speed data transmission of optical communication.
  • the operating system in this embodiment may be an Android system, a Blackberry OS system, a windows phone system, a windows mobile system, an IOS system, a Mac OS system, etc., although there are differences in each system, in order to implement the embodiment.
  • a method of controlling a light-emitting device can be achieved by a person skilled in the art with appropriate modifications under the concept of the present invention.
  • the status data can also be intensity data for controlling the intensity of the flash light.
  • corresponding state data may also be intensity data for controlling the vibration intensity of the vibrator.
  • the implementation principle is the same as that of the flash, which is not described in this embodiment.
  • the embodiment further provides a module for controlling a hardware device in an operating system, including a state data acquiring unit 801, a transmitting unit 802, and a buffer.
  • the status data acquisition unit 801 is configured to acquire status data for controlling the action of the hardware device.
  • the transmission unit 802 is configured to deliver the status data.
  • the buffer unit 803 is configured to store status data delivered by the transmission unit 802.
  • the first execution unit 808 is configured to invoke the hardware device driver, and controls the hardware device driver to read the state data stored in the buffer unit 803, and controls the state of the hardware device action according to the state data.
  • the loading unit 804 is configured to acquire a link library loading instruction, and load a link library, where the link library is included for controlling A function implementation function that makes hardware device actions.
  • the detecting unit 805 is configured to acquire an instruction to control the action of the hardware device.
  • the calling unit 806 is configured to call a function implementation function in the link library corresponding to the instruction that controls the action of the hardware device.
  • the second execution unit 807 is configured to control the hardware device driver to execute the called function implementation function to control the hardware device to perform the corresponding action.
  • the state data obtaining unit 801 further includes an encoding sub-unit 810 for acquiring original data, and encoding the original data to obtain state data.
  • the hardware device is a light emitting device, a vibrator, a Bluetooth, a camera, a sensor, or a microphone.
  • the hardware device driver when the hardware device is a light emitting device, the hardware device driver is driven by the light emitting device, and the state data is an array representing time data; the first execution unit 808 controls the hardware device driver to control the state of the hardware device according to the state data: An execution unit 808 controls the illumination device to drive the time during which the illumination device is turned on or off in the order of the data elements in the array.
  • the status data is an array representing time data, luminance data, or intensity data.
  • the operating system is an Android system, a Blackberry OS system, a windows phone system, a windows mobile system, an IOS system, or a Mac OS system.
  • the kernel driver layer of the Android system is provided with a driver of the hardware device, and the second execution unit 807 is configured to control the driver of the hardware device to execute the called function implementation function to control
  • the hardware device performs a corresponding action; or, when the operating system is an IOS system, the driver of the hardware device is set in the core system layer of the IOS system, and the second execution unit 807 is configured to control the function implementation function of the driver of the hardware device to be called. To control the hardware device to perform the corresponding action.
  • the architecture of the Android system further includes a JNI layer, and the JNI layer defines a corresponding JNI interface function; the calling unit 806 is configured to invoke the link library and control hardware device actions according to the interface function.
  • the function implementation function corresponding to the instruction is provided for the hardware device driver of the kernel driver layer to execute the corresponding function implementation function; or, when the operating system is the IOS system, the interface function provided by the core system layer is accessed by using the LibSystem library;
  • the function implementation function corresponding to the instruction for controlling the action of the hardware device in the link library is called according to the interface function, so that the hardware device driver of the kernel driver layer executes the corresponding function implementation function.
  • the JNI layer holds the address after the function implementation function is instantiated.
  • the architecture of the Android system further includes a hardware abstraction layer, and the hardware abstraction layer runs on the kernel driver layer for the application of the Android system under the support of the kernel driver layer.
  • the framework layer and the JNI layer provide an interface implementation for hardware device control; or, when the operating system is an IOS system, the IOS system also includes a core service layer.
  • the loading unit 804, the detecting unit 805, the calling unit 806, and the The second execution unit 807 is a direct control mode for the hardware device drive (flash drive) call mode.
  • the first execution unit 808 can invoke an existing hardware device driver in any manner in the prior art to control hardware device actions, such as indirect control.
  • the module for controlling the hardware device in the operating system provided in this embodiment corresponds to the method for controlling the hardware device, and the working principle is not described herein again.
  • the method and the module for controlling the hardware device in the operating system provided by the embodiment of the present application, after obtaining the state data for controlling the action of the hardware device, first sending and storing the state data to the buffer unit, and then calling the hardware device driver.
  • the hardware device driver reads the state data stored in the buffer unit, and controls the state of the hardware device action according to the state data.
  • the calling hardware device driver specifically includes: calling an existing hardware device driver to control the hardware device action; or, acquiring a link library loading instruction, loading the link library; and acquiring an instruction for controlling the action of the hardware device, calling the link library and The function implementation function corresponding to the hardware device action instruction; then executing the called function implementation function to control the hardware device to perform the corresponding action.
  • the hardware device driver controls the hardware device to perform a corresponding action as a direct control mode.
  • the state data is stored in the buffer unit, after the hardware device driver is invoked, The status data stored in the buffer unit is directly read, and the reading process is continuous, which avoids the interruption, delay, and the like of the hardware device driver in the process of driving the hardware device, thereby improving the accuracy of data transmission, and Provides guarantee for high speed data transmission.

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)
  • Telephone Function (AREA)
  • Stored Programmes (AREA)

Abstract

一种操作系统中控制硬件设备的方法和模块,获取到用于控制硬件设备动作的状态数据,将其下发并存储到缓冲单元;调用硬件设备驱动,硬件设备驱动读取缓冲单元中的状态数据,根据状态数据控制硬件设备动作的状态。调用硬件设备驱动包括:调用已有的硬件设备驱动,以控制硬件设备动作;或者获取链接库加载指令,加载链接库;获取用于控制硬件设备动作的指令,调用链接库中与该指令对应的功能实现函数;执行被调用的功能实现函数,以控制硬件设备执行相应的动作。硬件设备驱动控制硬件设备执行动作为直接控制方式,能够有效避免在驱动硬件设备动作时出现中断、延迟等现象,从而提高数据传输的准确性,为高速数据传输提供了保证。

Description

一种操作系统中控制硬件设备的方法和模块 技术领域
本申请涉及电子设备操作系统的开发,具体涉及一种操作系统中控制硬件设备的方法和模块。
背景技术
请参考图1,为安卓系统的架构示意图。
第一层101为Linux内核驱动层(Linux kernel),其由C/C++实现。安卓核心系统服务依赖于Linux内核,包括安全性、内存管理、进程管理、网络协议、驱动模型等。Linux内核也作为硬件和软件栈之间的抽象层,除了标准的Linux内核外,安卓还增加了内核的驱动程序,例如:Binder(IPC)驱动、camera驱动、电源管理等。
第二层为组件库和虚拟机层,其中,102为组件库层(Libraries),103为虚拟机层(Android Runtime),组件库层102通过C/C++实现,包含C/C++库,用于安卓系统中不同的组件使用,它们通过安卓应用程序框架为开发者进行服务。虚拟机层103作为安卓系统的运动环境,其提供了Java编程语言核心库的大多数功能,由Dalvik Java虚拟机和基础的Java类库组成。
第三层104为应用框架层(Application Framework),在安卓系统中,开发人员也可以完全访问核心应用程序所使用的API(Application Programming Interface,应用程序编程接口)框架。
第四层105为应用程序层(Applications),安卓应用程序都是采用Java语言编写的,用户开发的安卓应用程序和安卓的核心应用程序是同一层次的,它们都是基于安卓的系统API构建的。
目前,众多的电子设备采用安卓系统,且设备硬件上都安装有闪光灯,在很多情况下,用户具有使用闪光灯的需求,因此,如何在安卓系统上实现闪光灯的控制,是本领域技术人员正在研究的问题。
一方面,随着光通信的发展,越来越多的电子设备通过使用闪光灯来进行光通信。在安卓系统中,例如,用户在应用程序层控制将某一数据通过闪光灯以光通信的方式发送出去,则该数据作为待发送数据,根据相应的编码规则将该数据转换成控制闪光灯亮灭的时间数据,即在应用程序层产生了控制闪光灯开关的时间数据。然而应用程序层在获取到控制闪光灯的指令后,对闪光灯驱动的调用指令是一条一条发送的,闪光灯驱动执行完一条指令后,等待应用程序层发送的下一条指令,加上应用程序层将指令传达到驱动层需要经过应用框架层、组件库层和虚拟机层等层级,其间,必然会出现一定的时间延迟,从而影响光通信过程中数据传输的准确性。
在光通信中,通常采用的是可见光通信,该可见光即可用于进行数据传输,又可以作为照明用。然而,由于上述时间延迟问题,使得数据传输过程中,为了保证数据的准确性,需要适当限制其传输速度(可见光的闪烁频率)。因此,对于需要对数据进行高速传输时,无法很好地适用。
另一方面,在安卓系统中,当需要控制闪光灯的开关时,通常是先调用camera driver,利用camera自带的接口,通过设置camera的参数,来实现闪光灯的开关。而这种对闪光灯的控制方式,属于间接控制,其对闪光灯的调用具有一定的时间延迟。
技术问题:
现有技术通过先调用camera driver,利用camera自带的接口,通过设置camera的参数,来实现闪光灯的开关的控制方式,属于间接控制,其对闪光灯的调用具有一定的时间延迟。
技术解决方案:
根据本申请的第一方面,本申请提供了一种操作系统中控制硬件设备的方法,包括:获取链接库加载指令,加载链接库,所述链接库中包括用于控制硬件设备动作的功能实现函数;获取用于控制硬件设备动作的指令;调用所述链接库中与所述控制硬件设备动作的指令对应的功能实现函数;执行被调用的功能实现函数,以控制硬件设备执行相应的动作。
根据本申请的第二方面,本申请提供了一种操作系统中控制硬件设备的模块,包括:加载单元,用于获取链接库加载指令,并加载链接库,所述链接库中包括用于控制硬件设备动作的功能实现函数;检测单元,用于获取控制硬件设备动作的指令;调用单元,用于调用所述链接库中与所述控制硬件设备动作的指令对应的功能实现函数;第二执行单元,用于控制硬件设备驱动执行被调用的功能实现函数,以控制硬件设备执行相应的动作。
根据本申请的第三方面,本申请提供了一种操作系统中控制硬件设备的方法,其特征在于,包括:获取用于控制硬件设备动作的状态数据;将所述状态数据下发并存储到缓冲单元中;调用硬件设备驱动,所述发光器件驱动读取保存在缓冲单元中的状态数据,根据所述状态数据控制硬件设备动作的状态。
根据本申请的第四方面,本申请提供了一种操作系统中控制硬件设备的模块,其特征在于,包括:状态数据获取单元,用于控制应用程序层获取用于控制硬件设备动作的状态数据;传输单元,用于控制应用程序层将所述状态数据下发;缓冲单元,用于存储应用程序层下发的状态数据;执行单元,用于控制应用程序层调用位于内核驱动层中的硬件设备驱动,并控制硬件设备驱动读取保存在缓冲单元中的状态数据,根据所述状态数据控制硬件设备动作的状态。
有益效果:
本申请提供的操作系统中控制硬件设备的方法和模块,在获取到用于控制硬件设备动作的状态数据后,先将状态数据下发并存储到缓冲单元中,之后调用硬件设备驱动,该硬件设备驱动读取保存在缓冲单元中的状态数据,根据状态数据控制硬件设备动作的状态。调用硬件设备驱动具体包括:调用已有的硬件设备驱动,以控制硬件设备动作;或者,获取链接库加载指令,加载链接库;在获取用于控制硬件设备动作的指令后,调用链接库中与硬件设备动作指令对应的功能实现函数;之后执行被调用的功能实现函数,以控制硬件设备执行相应的动作。本申请提供的操作系统中控制硬件设备的方法和模块中,硬件设备驱动控制硬件设备执行相应的动作为直接控制方式,另外,由于状态数据存储在缓冲单元中,硬件设备驱动被调用后,便直接读取存储在缓冲单元中的状态数据,该读取过程是连续的,避免了硬件设备驱动在驱动硬件设备动作的过程中出现中断、延迟等现象,从而提高了数据传输的准确性,并为高速数据传输提供了保证。
附图说明
图1为安卓系统的架构示意图;
图2为本申请实施例一提供的安卓系统的架构示意图;
图3为本申请实施例一提供的安卓系统的架构分析示意图;
图4为本申请实施例一安卓系统中控制硬件设备的方法流程示意图;
图5为本申请实施例二安卓系统中控制硬件设备的模块的结构示意图;
图6本申请实施例三安卓系统中控制硬件设备的方法流程示意图;
图7本申请实施例四安卓系统中控制硬件设备的模块的结构示意图;
图8本申请实施例五安卓系统中控制硬件设备的方法流程示意图;
图9本申请实施例六安卓系统中控制硬件设备的模块的结构示意图。
具体实施方式
为了更好地理解本申请,本申请实施例以安卓系统中控制发光器件(闪光灯)开关为例进行说明,应当理解,本申请中所指的操作系统还可以是Blackberry OS系统、windows phone系统、windows mobile系统、IOS系统或Mac OS系统等其他操作系统。硬件设备还可以是电子设备中摄像头、震动器、蓝牙、传感器、麦克风等。
下面通过具体实施例对本申请做进一步说明。
实施例一
在本申请实施例中,通过在Linux内核空间(Linux Kernel层)实现内核驱动 程序(闪光灯驱动)和在用户空间实现硬件抽象层接口,以向更上一层提供硬件访问接口,即为安卓系统的应用框架层提供硬件服务。由于安卓系统的应用程序是用Java语言编写的,硬件驱动程序是用C/C++语言来实现的,而Java提供了JNI(Java Native Interface,Java本地调用)方法调用,因此,在安卓系统中,Java应用程序可以通过JNI来调用硬件抽象层接口。
请参考图2,本申请实施例中,将安卓系统的架构分为五层。第一层201为Linux内核驱动层(Linux kernel),第二层202为硬件抽象层(HAL,Hardware Abstraction Layer),第三层203、204为组件库层203(Libraries)和虚拟机层204(Android Runtime),第四层205为应用框架层(Application Framework),第五层206为应用程序层(Applications)。
基于图2,请参考图3,其示出了从另一角度对安卓系统的架构的分析。可将整个安卓系统分为硬件、内核空间和用户空间三个部分,其各自包括的构架内容如图3所示。
在本申请实施例中,将JNI层划分到第三层中,JNI层为应用框架层设计了一系列接口函数,而在这些接口函数的具体实现中,利用回调函数与硬件抽象层进行交互。
需要说明的是,本申请实施例提供的控制闪光灯开关的方法也同样适用于图1所示架构的安卓系统,本实施例中增加硬件抽象层的作用在于,为不具有标准Linux内核驱动层接口的硬件设备提供接入的路径,将原本可读性差的接口转化成可读性好的接口,提供给上层程序调用。即硬件抽象层运行于Linux内核驱动层之上,用于在Linux内核驱动层的支持下,为应用框架层和JNI层提供对闪光灯控制的接口实现。
图1和图2中各层的内部框架为本领域技术人员熟知的,因此,本申请不对其进行一一翻译和说明。
请参阅图4,本实施例提供了一种安卓系统中直接控制闪光灯开关的方法,包括下面步骤:
步骤301:应用框架层检测获取链接库加载指令。
在具体实施例中,一方面,安卓系统在启动后会自动加载相应的链接库,因此,链接库加载指令可以是安卓系统在启动后发出的一个指令;另一方面,链接库只有在需要调用相应的功能实现函数时才需要进行加载,因此,链接库加载指令可以是安卓系统检测到要进行功能实现函数的调用时发出的一个指令。
步骤302:应用框架层加载链接库,链接库中包括用于控制闪光灯动作的功能实现函数。
功能实现函数为用于控制闪光灯动作的函数,例如:
led_on
led_off
……
或者当led的驱动信号需要由另外一个设备给出时,例如CPU芯片或摄像头芯片等,则需要先打开该设备,然后再驱动LED发光。这样的优势是控制灯的模式更加灵活,例如不同颜色、不同亮度等,则可以写如下函数:
led_device_open//打开闪光灯(可选,其功能是打开上述设备)
led_device_close//关闭闪光灯(可选,其功能是打开上述设备)
led_on
led_off
……
上述用于控制闪光灯动作的函数在定义完毕后,可以保存在.c文件里,.c文件中是所有变量和函数的定义。
步骤303:应用程序层获取用于控制闪光灯动作的指令。该指令可以是用户通过安卓设备的人机交互界面(即应用程序层)输入的用于控制闪光灯动作的指令;也可以是应用程序层中已编码好的指令串,例如用“0”和“1”表示的数据串,其中,“0”表示闪光灯关闭,“1”表示闪光灯打开。
基于步骤301,步骤303中用于控制闪光灯动作的指令也可以作为链接库加载指令,用于控制闪光灯动作的指令即可理解为要进行功能实现函数的调用,因此,需要说明的是,本实施例中提供的方法的步骤顺序不应该理解为对本申请的限定,在其他实施例中,其步骤顺序可以根据实际情况进行适当的变换。
步骤304:应用程序层检测链接库是否加载完毕,如果否,则继续待链接库加载完毕,如果是,则继续步骤305。
步骤305:应用程序层调用链接库中与用于控制闪光灯动作的指令对应的功能实现函数。
应用程序层可以在检测到链接库全部加载完毕时调用功能实现函数,或者在检测的同时即进行调用,或者可以设定预定的时间,当满足一定的预定时间时,便调用功能实现函数。
步骤306:Linux内核驱动层执行被调用的功能实现函数,以控制闪光灯执行相应的动作。
本实施例中,Linux内核驱动层中设置有闪光灯驱动,闪光灯驱动执行被调用的功能实现函数,以控制闪光灯执行相应的动作。
目前,闪光灯通常只用于作为camera的辅助硬件,只有在使用camera时,才有可能会使用到闪光灯,因此,安卓系统中在使用闪光灯时,必须先调用camera driver,通过设置camera参数来实现闪光灯的控制。即,对闪光灯的控制为间接控制的方式。
在通过camera driver控制闪光灯时会出现时间延迟的问题,但对于目前闪光灯的应用范围,该时间延迟不会影响正常的使用。然而,随着光通信(例如可见光通信)的发展,当需要通过光进行信息传输时,由于光通信对传输速度及信息传输准确性的要求,上述时间延迟的问题便逐渐突显出来,并成为光通信发展的障碍之一。
本实施例中,在安卓系统的Linux内核驱动层中独立设置有闪光灯驱动,在控制闪光灯时,可以直接调用闪光灯驱动,其对闪光灯的控制方式为直接控制。可以避免在通过camera driver控制闪光灯时出现的时间延迟。
JNI层定义有接口函数。应用程序层根据JNI层的接口函数调用链接库中与控制闪光灯动作的指令对应的功能实现函数,以供Linux内核驱动层的闪光灯驱动执行相应的功能实现函数。
当所述操作系统为IOS系统,则syscall为本地化接口处,可实现安卓系统中JNI层定义有接口函数的作用,此处不再赘述。
JNI层的接口函数定义了C/C++函数与JAVA函数的对应关系,该接口函数采用JNI方法将硬件抽象层的C/C++函数映射到应用程序层的JAVA函数上,以实现硬件抽象层(采用C/C++语言)与应用程序层(采用JAVA语言)的交互。led_on为JAVA函数,只有通过JNI接口的映射才能调用底层的功能函数,它会在JNI层中映射成名为java_全包名_类名_led_on的本地函数,再在函数里调用底层功能函数。
安卓运行环境中的Dalvik虚拟机在调用一个成员函数时,如果发现该成员函数是一个JNI方法,那么就会直接跳到它的地址去执行。即,JNI方法是直接在本地操作系统上执行的,而不是由Dalvik虚拟机解释器执行。因此,JNI方法是安卓应用程序与本地操作系统直接进行通信的一个手段,通过JNI方法使得通信更加高效。
优选的,JNI层保存有功能实现函数实例化后的地址,以便于JNI层直接调用功能实现函数。实例化是指在面向对象的编程中,用类(Class)创建对象的过程。例如:在闪光灯的控制过程中,将闪光灯动作作为类,将开启闪光灯、关闭闪光灯等具体的功能实现函数创建为对象。该对象的创建过程,即为实例化。该对象创建完后会有一对应的地址,JNI层保存该地址后,在后续调用该功能实现函数时,即可以根据该地址快速查询到相应的对象,而不需要先检索该功能实现函数对应的类。
本实施例中,在硬件抽象层定义有下面三个结构体:
struct hw_module_t;//模块类型:每一个硬件模块的必须申明一个hal_module_info_sym的数据结构体,该结构体的第一个成员必须是以hw_module_t为数据的结构体。
struct hw_module_methods_t;//模块方法:该结构体仅提供一个打开特殊设备的open函数的接口,其传入参数为“hw_module_t,id”和“w_device_t”,该函数用于初始化hw_device_t的各个成员。
strcut hw_device_t.//设备类型:对于每一个设备数据结构体都必须以该结构体开头,该结构体是所有设备的引导线,在该结构体之后才是每一个设备自己的数据。
本实施例中,在定义硬件模块类型结构体时,硬件抽象层规定不能直接使用hw_module_t结构体,需要做一个继承,即在该结构体外再套一层结构体,但hw_module_t结构体必须是该结构体的第一个成员变量数据类型,以方便两者之间的强制转换。其部分程序代码可参考如下:
Figure PCTCN2015087608-appb-000001
定义结构体的作用:把相关的变量与功能打包在一起,代码进行封装,以避免随意被更改。结构体是一种优选的方式,并不是必须的。
结构体是由一系列具有相同类型或不同类型的数据构成的数据集合。结构体用来封装一些属性、参数等值(即数据成员),以组成新的类型,封装后使得该属性、参数等值可以被多次利用。
对于闪光灯驱动,其定义的结构体可以包括闪光灯亮度、闪光灯开/关时间等,而亮度值、开/关时间则作为数据成员被封装在相应类别的结构体中。另外,对于采用C++定义的结构体,其数据成员还可以为函数,不仅可以用于描述对象的状态,还可以用于描述对象的行为,例如控制闪光灯开/关的函数LED_ON,LED_OFF,LED_DEVICE_OPEN,LED_DEVICE_CLOSE,它们分别对应前述的led_on,led_off,led_device_open,led_device_close函数。
实施例二
请参考图5,对应于上述安卓系统中直接控制闪光灯开关的方法,本实施例还相应提供了一种安卓系统中直接控制闪光灯开关的模块,包括加载单元401、检测单元 402、调用单元403和执行单元404。
加载单元401用于获取链接库加载指令,并加载链接库,链接库中包括用于控制闪光灯动作的功能实现函数。
检测单元402用于获取控制闪光灯动作的指令。
调用单元403检测到加载单元401加载完动态链接库后,调用所述链接库中与控制闪光灯动作的指令对应的功能实现函数,或者在检测的同时即进行调用,或者可以设定预定的时间,当满足一定的预定时间时,便调用链接库。
执行单元404用于执行被调用的功能实现函数,以控制闪光灯执行相应的动作。在具体实施例中,安卓系统的架构包括应用程序层、应用框架层、组件库和虚拟机层、Linux内核驱动层。Linux内核驱动层中设置有闪光灯驱动,执行单元404用于控制Linux内核驱动层中的闪光灯驱动执行被调用的功能实现函数,以控制闪光灯执行相应的动作。
安卓系统的架构还包括JNI层,JNI层定义有接口函数。加载单元401用于控制应用框架层检测获取到链接库加载指令后,加载链接库。调用单元403用于控制应用程序层根据JNI层的接口函数调用链接库中与控制闪光灯动作的指令对应的功能实现函数,以供Linux内核驱动层的闪光灯驱动执行相应的功能实现函数。
进一步,JNI层保存有功能实现函数实例化后的地址。
优选的,安卓系统的架构还包括硬件抽象层,硬件抽象层运行于Linux内核驱动层之上,用于在Linux内核驱动层的支持下,为应用框架层和JNI层提供对闪光灯控制的接口实现。
当操作系统为IOS系统时,IOS系统还包括Library库适配,可以实现类同安卓系统的架构中硬件抽象层的作用,此处不再赘述。
本申请实施例提供的安卓系统中直接控制闪光灯开关的方法和模块中,先在检测获取到链接库加载指令后,加载链接库;在获取用于控制闪光灯动作的指令后,调用链接库中与该指令对应的功能实现函数;之后执行被调用的功能实现函数,以控制闪光灯执行相应的动作,从而实现对闪光灯开关的直接控制。
本申请实施例提供的安卓系统中直接控制闪光灯开关的方法和模块还可以扩展应用至WP操作系统,具体的实现类同,不再赘述。
实施例三
本实施例的发明构思在于:利用缓冲单元将用于控制硬件设备动作的状态数据先存储,该缓冲单元内存储的数据为硬件设备驱动可直接读取的,状态数据存储完毕后,再调用硬件设备驱动,硬件设备驱动读取保存在缓存单元中的状态数据,根据状态数据控制硬件设备动作的状态。硬件设备驱动读取缓存单元中的状态数据是连续的,不会出现时间延迟、中断等现象,从而保证了数据传输的准确性,同时也 为高速数据传输提供了保证。
本实施例中硬件设备可以为发光器件、震动器、蓝牙、摄像头、传感器或麦克风。为了便于对本实施例进行说明,本实施例主要以硬件设备为发光器件进行说明,相应的,硬件设备驱动为发光器件驱动,状态数据为时间数据,硬件设备动作为发光器件的开启或关闭。
请参见图2和图6,本实施例提供了一种操作系统中控制硬件设备的方法,硬件设备为发光器件,包括下面步骤:
步骤501:获取原始数据。具体的,原始数据可以是用户输入的数据,例如用户输入的银行卡账号。在安卓系统中,可以由应用程序层获取原始数据。
步骤502:对原始数据进行编码,以得到用于控制发光器件开启或关闭的时间数据,例如,控制发光器件开5s、关2s、开3s……在安卓系统中,可以由应用程序层对原始数据进行编码。
在某些实施例中,如果用户直接输入用于控制发光器件开启或关闭的时间数据,即原始数据便是时间数据,此时则不需要进行编码操作。
发光器件具体可以是电子设备中自身的光源,例如LED闪光灯;或者其他光源,例如插接在手机上的光源,可以为激光发射器或者LED。
获取的原始数据通常为N进位制数据,对原始数据进行编码相当于将该N进位制数据编码为电信号单元,具体如下:
将N进位制数据按位依次转换为与其对应的电信号单元,该步骤包括:将N进位制数据中每个不同的数字编码为不同的电信号单元,电信号单元内的高低电平持续时间段分别为Ti 1、Ti2…和Tij,i、j、N为自然数,不同的电信号单元以分隔标志隔开,其中,本例的电信号单元内的高低电平并不默认为先高电平后低电平,也可以先低电平后高电平,高低电平之间其分隔标志可以为电平的跳变,或者以持续时间段不同的高低电平为特征电平,其分隔标志为不同于特征电平的基准电平。
在一可选实施例中,可以对至少部分待编码的N进位制数据编码为状态不同的电平信号,按照电平信号大小分为多档,不同档表示N进位制数据中的不同数字。
本步骤中,如果原始数据是未转换为N进位制数据的数据时,需要先将原始数据转换为N进位制数据。
本例中,Ti2、Ti3…和Tij与Ti1的运算值为预定值或预定范围,这里的运算是指:Ti2、Ti3…和Tij与Ti1的比值、乘积、差、和、倒数、和/或算余数。
本步骤中,以二进制数据为例,即当N=2时,将二进制数据0编码为第一电信号单元,第一电信号单元内的高低电平持续时间段分别为T11和T12;将二进制数据1编码为第二电信号单元,第二电信号单元内的高低电平持续时间段分别为T21和T22,其中,T11时间段为预设时间,T12=T11,T21=T11,T22=m*T21,m为设定的系数;或者,T11时间段为预设时间范围,T12、T11、T21在同一时间范围内, T122=m*21,m为设定的系数,最终使得T22与T21运算值不等于T12与T11运算值。
电平的跳变是从高电平到低电平的跳变,在二进制数据中,一个电信号单元内的电平发生一次跳变,其中,高电平控制LED闪光灯发光,低电平控制LED闪光灯不发光;在其他实施例中,可以采用相反的控制方式,如:电平发生为低电平到高电平的跳变,其中,低电平控制LED闪光灯发光,高电平控制LED闪光灯不发光。
步骤503:将时间数据下发。在安卓系统中,具体可以为:应用程序层将时间数据下发到内核驱动层。
步骤504:将下发的时间数据存储到缓冲单元中。在安卓系统中,具体为:内核驱动层获取到应用程序层下发的时间数据后,将其存储到设置在内核驱动层的缓冲单元中。缓冲单元内存储的数据为发光器件驱动可直接读取的,缓冲单元起到暂时保存时间数据的作用,其可以是缓冲寄存器。在其它实施例中,该缓冲单元也可以是利用现有的系统存储单元,通过程序的方法将该存储单元分离出一部分或全部空间作为本实施例中的缓冲单元。
缓冲寄存器又称缓冲器,可分为输入缓冲器和输出缓冲器两种。前者的作用是将外设送来的数据暂时存放,以便处理器将它取走;后者的作用是用来暂时存放处理器送往外设的数据。缓冲器可以使高速工作的CPU与慢速工作的外设起协调和缓冲作用,实现数据传送的同步。
步骤505:待发送数据对应的时间数据下发并存储完毕后,调用发光器件驱动,以保证发光器件处于可用状态。在安卓系统中,具体可以为:应该程序层调用位于内核驱动层中的发光器件驱动。
步骤506:发光器件驱动被调用后,读取保存在缓冲单元中的时间数据。
步骤507:发光器件驱动读取时间数据后,根据时间数据控制发光器件开启或关闭的时间。
在某些实施例中,时间数据为一数组。发光器件驱动根据时间数据控制发光器件开启或关闭的时间,具体为:发光器件驱动按照数组中数据元素的顺序控制发光器件开启或关闭的时间。当然,在其他实施例中,时间数据的格式也可以采用现有技术中其他可行的方式。
本实施例提供操作系统中控制发光器件的方法中,利用缓冲单元将用于控制发光器件开启或关闭的时间数据先存储,时间数据存储完毕后,再调用发光器件驱动,发光器件驱动读取保存在缓存器中的时间数据,根据时间数据控制发光器件开启或关闭的时间。发光器件驱动读取缓存器中的时间数据是连续的,不会出现时间延迟现象,从而保证了数据传输的准确性,同时也为光通信的高速数据传输提供了保证。
需要说明的是,本实施例中的操作系统可以是安卓系统、Blackberry OS系统、windows phone系统、windows mobile系统、IOS系统、Mac OS系统等,虽然各个系统存在着差异,但为了实现本实施例控制发光器件的方法,在本发明的构思下, 本领域技术人员可以通过适当的改变以达到目的。
在某些实施例中,状态数据还可以是用于控制发光器件发光强度的强度数据。在其他实施例中,如果硬件设备为震动器,相应的,状态数据也可以是用于控制震动器震动强度的强度数据。对于其他硬件设备,其实现原理与发光器件的实现原理一致,本实施例不再赘述。
实施例四
请参考图7,基于实施例三提供的操作系统中控制硬件设备的方法,本实施例相应提供了一种操作系统中控制硬件设备的模块,硬件设备为发光器件,包括时间数据获取单元601、传输单元602、缓冲单元603和执行单元604。
时间数据获取单元601用于控制应用程序层获取用于控制发光器件开启或关闭的时间数据。
在具体实施例中,时间数据获取单元601还包括编码子单元605,用于控制应用程序层获取原始数据,对原始数据编码后得到时间数据,例如,控制发光器件开5s、关2s、开3s……
具体的,原始数据可以是用户输入的数据,例如用户输入的银行卡账号。在某些实施例中,如果用户直接输入用于控制发光器件开启或关闭的时间数据,即原始数据便是时间数据,此时则不需要编码子单元605进行编码操作。
发光器件具体可以是电子设备中自身的光源,例如LED闪光灯;或者其他光源,例如插接在手机上的光源,可以为激光发射器或者LED。
传输单元602用于控制应用程序层将时间数据下发到内核驱动层。
缓冲单元603用于存储应用程序层下发的时间数据。内核驱动层获取到应用程序层下发的时间数据后,将其存储到设置在内核驱动层的缓冲单元603中。缓冲单元603为发光器件驱动可直接读取的,缓冲单元603起到暂时保存时间数据的作用,其可以是缓冲寄存器。在其它实施例中,该缓冲单元603也可以是利用现有的系统存储单元,通过程序的方法将该存储单元分离出一部分或全部空间作为本实施例中的缓冲单元603。
缓冲寄存器又称缓冲器,可分为输入缓冲器和输出缓冲器两种。前者的作用是将外设送来的数据暂时存放,以便处理器将它取走;后者的作用是用来暂时存放处理器送往外设的数据。缓冲器可以使高速工作的CPU与慢速工作的外设起协调和缓冲作用,实现数据传送的同步。
执行单元604用于控制应用程序层调用位于内核驱动层中的发光器件驱动,并控制发光器件驱动读取保存在缓冲单元中的时间数据,根据时间数据控制发光器件开启或关闭的时间。待发送数据对应的时间数据下发并存储完毕后,应该程序层调用位于内核驱动层中的发光器件驱动,以保证发光器件处于可用状态。发光器件驱动被调用后,读取保存在缓冲单元中的时间数据,并根据时间数据控制发光器件开 启或关闭的时间。
在某些实施例中,时间数据为一数组。发光器件驱动根据时间数据控制发光器件开启或关闭的时间时:发光器件驱动按照数组中数据元素的顺序控制发光器件开启或关闭的时间。当然,在其他实施例中,时间数据的格式也可以采用现有技术中其他可行的方式。
本实施例提供操作系统中控制发光器件的模块中,利用缓冲单元303将用于控制发光器件开启或关闭的时间数据先存储,时间数据存储完毕后,再调用发光器件驱动,发光器件驱动读取保存在缓存器中的时间数据,根据时间数据控制发光器件开启或关闭的时间。发光器件驱动读取缓存器中的时间数据是连续的,不会出现时间延迟现象,从而保证了数据传输的准确性,同时也为光通信的高速数据传输提供了保证。
需要说明的是,本实施例中的操作系统可以是安卓系统、Blackberry OS系统、windows phone系统、windows mobile系统、IOS系统、Mac OS系统等,虽然各个系统存在着差异,但为了实现本实施例控制发光器件的模块,在本发明的构思下,本领域技术人员可以通过适当的改变以达到目的。
在某些实施例中,状态数据还可以是用于控制发光器件发光强度的强度数据。在其他实施例中,如果硬件设备为震动器,相应的,状态数据也可以是用于控制震动器震动强度的强度数据。对于其他硬件设备,其实现原理与发光器件的实现原理一致,本实施例不再赘述。
实施例五
本实施例中,利用缓冲单元将用于控制硬件设备动作的状态数据先存储,该缓冲单元内存储的数据为硬件设备驱动可直接读取的,状态数据存储完毕后,再调用硬件设备驱动,硬件设备驱动读取保存在缓存单元中的状态数据,根据状态数据控制硬件设备动作的状态。硬件设备驱动读取缓存单元中的状态数据是连续的,不会出现时间延迟、中断等现象,从而保证了数据传输的准确性,同时也为高速数据传输提供了保证。
本实施例中硬件设备可以为发光器件、震动器、蓝牙、摄像头、传感器或麦克风。为了便于对本申请进行说明,本实施例主要以硬件设备为发光器件(闪光灯)进行说明,相应的,硬件设备驱动为闪光灯驱动,状态数据为时间数据,硬件设备动作为闪光灯的开启或关闭。
下面通过具体实施方式结合附图对本申请作进一步详细说明。
请参考图8,本实施例提供了一种操作系统中控制硬件设备的方法,包括下面步骤:
步骤701-704与实施例三中的步骤501-504相同。
步骤705-710与实施例一中的步骤301-306相同。
步骤711:闪光灯驱动读取保存在缓冲单元中的时间数据。
步骤712:闪光灯驱动读取时间数据后,根据时间数据控制发光器件开启或关闭的时间。
目前,闪光灯通常只用于作为camera的辅助硬件,只有在使用camera时,才有可能会使用到闪光灯,因此,安卓系统中在使用闪光灯时,必须先调用camera driver,通过设置camera参数来实现闪光灯的控制。即,对闪光灯的控制为间接控制的方式。
在通过camera driver控制闪光灯时会出现时间延迟的问题,但对于目前闪光灯的应用范围,该时间延迟不会影响正常的使用。然而,随着光通信(例如可见光通信)的发展,当需要通过光进行信息传输时,由于光通信对传输速度及信息传输准确性的要求,上述时间延迟的问题便逐渐突显出来,并成为光通信发展的障碍之一。
本实施例中,在安卓系统的Linux内核驱动层中独立设置有闪光灯驱动,在控制闪光灯时,可以直接调用闪光灯驱动,其对闪光灯的控制方式为直接控制。可以避免在通过camera driver控制闪光灯时出现的时间延迟。
需要说明的是,步骤705-步骤709为本实施例提供的一种硬件设备驱动(闪光灯驱动)调用方式,属于直接控制的方式。在其他实施例中,可以采用现有技术中的任一种方式调用已有的硬件设备驱动,以控制硬件设备动作,例如采用上述间接控制的方式。
JNI层定义有接口函数。应用程序层根据JNI层的接口函数调用链接库中与控制闪光灯动作的指令对应的功能实现函数,以供Linux内核驱动层的闪光灯驱动执行相应的功能实现函数。
当操作系统为IOS系统,则syscall为本地化接口处,可实现安卓系统中JNI层定义有接口函数的作用,此处不再赘述。
JNI层的接口函数定义了C/C++函数与JAVA函数的对应关系,该接口函数采用JNI方法将硬件抽象层的C/C++函数映射到应用程序层的JAVA函数上,以实现硬件抽象层(采用C/C++语言)与应用程序层(采用JAVA语言)的交互。led_on为JAVA函数,只有通过JNI接口的映射才能调用底层的功能函数,它会在JNI层中映射成名为java_全包名_类名_led_on的本地函数,再在函数里调用底层功能函数。
安卓运行环境中的Dalvik虚拟机在调用一个成员函数时,如果发现该成员函数是一个JNI方法,那么就会直接跳到它的地址去执行。即,JNI方法是直接在本地操作系统上执行的,而不是由Dalvik虚拟机解释器执行。因此,JNI方法是安卓应用程序与本地操作系统直接进行通信的一个手段,通过JNI方法使得通信更加高效。
优选的,JNI层保存有功能实现函数实例化后的地址,以便于JNI层直接调用功 能实现函数。实例化是指在面向对象的编程中,用类(Class)创建对象的过程。例如:在闪光灯的控制过程中,将闪光灯动作作为类,将开启闪光灯、关闭闪光灯等具体的功能实现函数创建为对象。该对象的创建过程,即为实例化。该对象创建完后会有一对应的地址,JNI层保存该地址后,在后续调用该功能实现函数时,即可以根据该地址快速查询到相应的对象,而不需要先检索该功能实现函数对应的类。
本实施例中,在硬件抽象层定义有下面三个结构体,本实施例中的硬件抽象层的三个结构体与实施例一中的对应相同,此处不再赘述。
在某些实施例中,时间数据为一数组。闪光灯驱动根据时间数据控制闪光灯开启或关闭的时间,具体为:发光器件驱动按照数组中数据元素的顺序控制闪光灯开启或关闭的时间。当然,在其他实施例中,时间数据的格式也可以采用现有技术中其他可行的方式。
本实施例提供操作系统中控制闪光灯的方法中,利用缓冲单元将用于控制闪光灯开启或关闭的时间数据先存储,时间数据存储完毕后,再调用发光器件驱动,闪光灯驱动读取保存在缓存器中的时间数据,根据时间数据控制闪光灯开启或关闭的时间。闪光灯驱动读取缓存器中的时间数据是连续的,不会出现时间延迟现象,从而保证了数据传输的准确性,同时也为光通信的高速数据传输提供了保证。
需要说明的是,本实施例中的操作系统可以是安卓系统、Blackberry OS系统、windows phone系统、windows mobile系统、IOS系统、Mac OS系统等,虽然各个系统存在着差异,但为了实现本实施例控制发光器件的方法,在本发明的构思下,本领域技术人员可以通过适当的改变以达到目的。
在某些实施例中,状态数据还可以是用于控制闪光灯发光强度的强度数据。在其他实施例中,如果硬件设备为震动器,相应的,状态数据也可以是用于控制震动器震动强度的强度数据。对于其他硬件设备,其实现原理与闪光灯的实现原理一致,本实施例不再赘述。
实施例六
请参考图9,对应于实施例五提供的操作系统中控制硬件设备的方法,本实施例还提供了一种操作系统中控制硬件设备的模块,包括状态数据获取单元801、传输单元802、缓冲单元803、加载单元804、检测单元805、调用单元806、第一执行单元808和第二执行单元807。
状态数据获取单元801用于获取用于控制硬件设备动作的状态数据。
传输单元802用于将状态数据下发。
缓冲单元803用于存储传输单元802下发的状态数据。
第一执行单元808用于调用硬件设备驱动,并控制硬件设备驱动读取保存在缓冲单元803中的状态数据,根据该状态数据控制硬件设备动作的状态。
加载单元804用于获取链接库加载指令,并加载链接库,链接库中包括用于控 制硬件设备动作的功能实现函数。
检测单元805用于获取控制硬件设备动作的指令。
调用单元806用于调用链接库中与控制硬件设备动作的指令对应的功能实现函数。
第二执行单元807用于控制硬件设备驱动执行被调用的功能实现函数,以控制硬件设备执行相应的动作。
在具体实施例中,状态数据获取单元801还包括编码子单元810,用于获取原始数据,对原始数据编码后得到状态数据。
在具体实施例中,硬件设备为发光器件、震动器、蓝牙、摄像头、传感器或麦克风。
在具体实施例中,硬件设备为发光器件时,硬件设备驱动为发光器件驱动,状态数据为表示时间数据的数组;第一执行单元808控制硬件设备驱动根据状态数据控制硬件设备的状态时:第一执行单元808控制发光器件驱动按照数组中数据元素的顺序控制发光器件开启或关闭的时间。
在具体实施例中,状态数据为表示时间数据、亮度数据或强度数据的数组。
在具体实施例中,操作系统为安卓系统、Blackberry OS系统、windows phone系统、windows mobile系统、IOS系统或Mac OS系统。
在具体实施例中,当操作系统为安卓系统时,安卓系统的内核驱动层中设置有硬件设备的驱动,第二执行单元807用于控制硬件设备的驱动执行被调用的功能实现函数,以控制硬件设备执行相应的动作;或者,当操作系统为IOS系统时,IOS系统的核心系统层中设置有硬件设备的驱动,第二执行单元807用于控制硬件设备的驱动执行被调用的功能实现函数,以控制硬件设备执行相应的动作。
在具体实施例中,当操作系统为安卓系统时,安卓系统的架构还包括JNI层,JNI层定义有相应的JNI接口函数;调用单元806用于根据接口函数调用链接库中与控制硬件设备动作的指令对应的功能实现函数,以供内核驱动层的硬件设备驱动执行相应的功能实现函数;或者,操作系统为IOS系统时,则利用LibSystem库访问核心系统层提供的接口函数;调用单元806用于根据接口函数调用链接库中与控制硬件设备动作的指令对应的功能实现函数,以供内核驱动层的硬件设备驱动执行相应的功能实现函数。
在具体实施例中,JNI层保存有功能实现函数实例化后的地址。
在具体实施例中,当操作系统为安卓系统时,安卓系统的架构还包括硬件抽象层,硬件抽象层运行于内核驱动层之上,用于在内核驱动层的支持下,为安卓系统的应用框架层和JNI层提供对硬件设备控制的接口实现;或者,当操作系统为IOS系统时,IOS系统还包括核心服务层。
需要说明的是,本实施例中,加载单元804、检测单元805、调用单元806、第 二执行单元807对硬件设备驱动(闪光灯驱动)调用方式属于直接控制的方式。在其他实施例中,第一执行单元808可以采用现有技术中的任一种方式调用已有的硬件设备驱动,以控制硬件设备动作,例如采用间接控制的方式。
本实施例提供的操作系统中控制硬件设备的模块与上述控制硬件设备的方法对应,此处不再对其工作原理进行赘述。
本申请实施例提供的操作系统中控制硬件设备的方法和模块,在获取到用于控制硬件设备动作的状态数据后,先将状态数据下发并存储到缓冲单元中,之后调用硬件设备驱动,该硬件设备驱动读取保存在缓冲单元中的状态数据,根据状态数据控制硬件设备动作的状态。调用硬件设备驱动具体包括:调用已有的硬件设备驱动,以控制硬件设备动作;或者,获取链接库加载指令,加载链接库;在获取用于控制硬件设备动作的指令后,调用链接库中与硬件设备动作指令对应的功能实现函数;之后执行被调用的功能实现函数,以控制硬件设备执行相应的动作。本申请提供的操作系统中控制硬件设备的方法和模块中,硬件设备驱动控制硬件设备执行相应的动作为直接控制方式,另外,由于状态数据存储在缓冲单元中,硬件设备驱动被调用后,便直接读取存储在缓冲单元中的状态数据,该读取过程是连续的,避免了硬件设备驱动在驱动硬件设备动作的过程中出现中断、延迟等现象,从而提高了数据传输的准确性,并为高速数据传输提供了保证。
本领域技术人员可以理解,上述实施方式中各种方法的全部或部分步骤可以通过程序来指令相关硬件完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:只读存储器、随机存取存储器、磁盘或光盘等。
以上内容是结合具体的实施方式对本申请所作的进一步详细说明,不能认定本申请的具体实施只局限于这些说明。对于本申请所属技术领域的普通技术人员来说,在不脱离本申请发明构思的前提下,还可以做出若干简单推演或替换。

Claims (30)

  1. 一种操作系统中控制硬件设备的方法,其特征在于,包括:
    获取链接库加载指令,加载链接库,所述链接库中包括用于控制硬件设备动作的功能实现函数;
    获取用于控制硬件设备动作的指令;
    调用所述链接库中与所述控制硬件设备动作的指令对应的功能实现函数;
    执行被调用的功能实现函数,以控制硬件设备执行相应的动作。
  2. 如权利要求1所述的方法,其特征在于,在获取链接库加载指令之前,还包括步骤:
    获取用于控制硬件设备动作的状态数据;
    将所述状态数据下发并存储到缓冲单元中;
    在执行被调用的功能实现函数之后,还包括步骤:
    调用硬件设备驱动,所述硬件设备驱动读取保存在缓冲单元中的状态数据,根据所述状态数据控制硬件设备动作的状态。
  3. 如权利要求2所述的方法,其特征在于,获取用于控制硬件设备动作的状态数据,具体为:获取原始数据,对原始数据编码后得到所述状态数据。
  4. 如权利要求2所述的方法,其特征在于,所述硬件设备为发光器件、震动器、蓝牙、摄像头、传感器或麦克风。
  5. 如权利要求4所述的方法,其特征在于,所述硬件设备为发光器件时,所述硬件设备驱动为发光器件驱动,所述状态数据为表示时间数据的数组;所述硬件设备驱动根据所述状态数据控制硬件设备动作的状态,具体为:发光器件驱动按照所述数组中数据元素的顺序控制发光器件开启或关闭的时间。
  6. 如权利要求2所述的方法,其特征在于,所述状态数据为表示时间数据、亮度数据或强度数据的数组。
  7. 如权利要求2所述的方法,其特征在于,当所述操作系统为安卓系统时,所述安卓系统的内核驱动层中设置有所述硬件设备的驱动,所述硬件设备的驱动执行被调用的功能实现函数,以控制硬件设备执行相应的动作;或者,
    当所述操作系统为IOS系统,所述IOS系统的核心系统层中设置有所述硬件设备的驱动,所述硬件设备的驱动执行被调用的功能实现函数,以控制硬件设备执行相应的动作。
  8. 如权利要求7所述的方法,其特征在于,当所述操作系统为安卓系统时,所述安卓系统的JNI层定义有相应的JNI接口函数;
    获取链接库加载指令,加载链接库后,根据所述接口函数调用所述链接库中与控制硬件设备动作的指令对应的功能实现函数,以供内核驱动层的硬件设备驱动执行相应的功能实现函数;或者,
    当所述操作系统为IOS系统时,则利用LibSystem库访问核心系统层提供的接口函数;
    获取链接库加载指令,加载链接库后,根据所述接口函数调用所述链接库中与控制硬件设备动作的指令对应的功能实现函数,以供核心系统层的硬件设备驱动执行相应的功能实现函数。
  9. 如权利要求8所述的方法,其特征在于,JNI层保存有功能实现函数实例化后的地址。
  10. 如权利要求8所述的方法,其特征在于,当所述操作系统为安卓系统时,所述安卓系统还包括硬件抽象层,所述安卓系统的硬件抽象层运行于内核驱动层之上,用于在内核驱动层的支持下,为安卓系统的应用框架层和JNI层提供对硬件设备控制的接口实现;或者
    当所述操作系统为IOS系统,所述IOS系统还包括核心服务层。
  11. 一种操作系统中控制硬件设备的模块,其特征在于,包括:
    加载单元,用于获取链接库加载指令,并加载链接库,所述链接库中包括用于控制硬件设备动作的功能实现函数;
    检测单元,用于获取控制硬件设备动作的指令;
    调用单元,用于调用所述链接库中与所述控制硬件设备动作的指令对应的功能实现函数;
    第二执行单元,用于控制硬件设备驱动执行被调用的功能实现函数,以控制硬件设备执行相应的动作。
  12. 如权利要求11所述的模块,其特征在于,所述操作系统中控制硬件设备的模块还包括:
    状态数据获取单元,用于获取用于控制硬件设备动作的状态数据;
    传输单元,用于将所述状态数据下发;
    缓冲单元,用于存储传输单元下发的状态数据;
    第一执行单元,用于调用硬件设备驱动,并控制所述硬件设备驱动读取保存在缓冲单元中的状态数据,根据所述状态数据控制硬件设备动作的状态;
    第一执行单元调用硬件设备驱动时,调用已有的硬件设备驱动,以控制硬件设备动作。
  13. 如权利要求12所述的模块,其特征在于,所述状态数据获取单元还包括编码子单元,用于获取原始数据,对原始数据编码后得到所述状态数据。
  14. 如权利要求12所述的模块,其特征在于,所述硬件设备为发光器件、震动器、蓝牙、摄像头、传感器或麦克风。
  15. 如权利要求14所述的模块,其特征在于,所述硬件设备为发光器件时,所述硬件设备驱动为发光器件驱动,所述状态数据为表示时间数据的数组;所述第一 执行单元控制硬件设备驱动根据所述状态数据控制硬件设备的状态时:第一执行单元控制发光器件驱动按照所述数组中数据元素的顺序控制发光器件开启或关闭的时间。
  16. 如权利要求12所述的模块,其特征在于,所述状态数据为表示时间数据、亮度数据或强度数据的数组。
  17. 如权利要求12所述的模块,其特征在于,当所述操作系统为安卓系统时,所述安卓系统的内核驱动层中设置有所述硬件设备的驱动,所述第二执行单元用于控制硬件设备的驱动执行被调用的功能实现函数,以控制硬件设备执行相应的动作;或者
    当所述操作系统为IOS系统时,所述IOS系统的核心系统层中设置有所述硬件设备的驱动,所述第二执行单元用于控制硬件设备的驱动执行被调用的功能实现函数,以控制硬件设备执行相应的动作。
  18. 如权利要求17所述的模块,其特征在于,当所述操作系统为安卓系统时,所述安卓系统的架构还包括JNI层,所述JNI层定义有相应的JNI接口函数;
    调用单元用于根据所述接口函数调用所述链接库中与控制硬件设备动作的指令对应的功能实现函数,以供内核驱动层的硬件设备驱动执行相应的功能实现函数;或者
    所述操作系统为IOS系统时,则利用LibSystem库访问核心系统层提供的接口函数;调用单元用于根据所述接口函数调用所述链接库中与控制硬件设备动作的指令对应的功能实现函数,以供内核驱动层的硬件设备驱动执行相应的功能实现函数。
  19. 如权利要求18所述的模块,其特征在于,所述JNI层保存有功能实现函数实例化后的地址。
  20. 如权利要求18所述的模块,其特征在于,当所述操作系统为安卓系统时,所述安卓系统的架构还包括硬件抽象层,所述硬件抽象层运行于内核驱动层之上,用于在内核驱动层的支持下,为安卓系统的应用框架层和JNI层提供对硬件设备控制的接口实现;或者当所述操作系统为IOS系统时,所述IOS系统还包括核心服务层。
  21. 一种操作系统中控制硬件设备的方法,其特征在于,包括:
    获取用于控制硬件设备动作的状态数据;
    将所述状态数据下发并存储到缓冲单元中;
    调用硬件设备驱动,所述发光器件驱动读取保存在缓冲单元中的状态数据,根据所述状态数据控制硬件设备动作的状态。
  22. 如权利要求21所述的方法,其特征在于,获取用于控制硬件设备动作的状态数据,具体为:获取原始数据,对原始数据编码后得到所述状态数据。
  23. 如权利要求21所述的方法,其特征在于,所述硬件设备为发光器件、震动器、蓝牙、摄像头、传感器或麦克风。
  24. 如权利要求21所述的方法,其特征在于,所述状态数据为表示时间数据、亮度数据或强度数据的数组。
  25. 如权利要求23所述的方法,其特征在于,所述硬件设备为发光器件时,所述硬件设备驱动为发光器件驱动,所述状态数据为表示时间数据的数组;所述硬件设备驱动根据所述状态数据控制硬件设备动作的状态,具体为:发光器件驱动按照所述数组中数据元素的顺序控制发光器件开启或关闭的时间。
  26. 一种操作系统中控制硬件设备的模块,其特征在于,包括:
    状态数据获取单元,用于控制应用程序层获取用于控制硬件设备动作的状态数据;
    传输单元,用于控制应用程序层将所述状态数据下发;
    缓冲单元,用于存储应用程序层下发的状态数据;
    执行单元,用于控制应用程序层调用位于内核驱动层中的硬件设备驱动,并控制硬件设备驱动读取保存在缓冲单元中的状态数据,根据所述状态数据控制硬件设备动作的状态。
  27. 如权利要求26所述的模块,其特征在于,所述状态数据获取单元还包括编码子单元,用于控制应用程序层获取原始数据,对原始数据编码后得到所述状态数据。
  28. 如权利要求26所述的模块,其特征在于,所述硬件设备为发光器件、震动器、摄像头、传感器或麦克风。
  29. 如权利要求26所述的模块,其特征在于,所述状态数据为表示时间数据、亮度数据或强度数据的数组。
  30. 如权利要求28所述的模块,其特征在于,所述硬件设备为发光器件时,所述硬件设备驱动为发光器件驱动,所述状态数据为表示时间数据的数组;所述执行单元控制硬件设备驱动根据所述状态数据控制硬件设备的状态时:执行单元控制发光器件驱动按照所述数组中数据元素的顺序控制发光器件开启或关闭的时间。
PCT/CN2015/087608 2014-08-20 2015-08-20 一种操作系统中控制硬件设备的方法和模块 WO2016026449A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP15833667.7A EP3196759A4 (en) 2014-08-20 2015-08-20 Method and module in operating system for controlling hardware device
KR1020177007449A KR101960443B1 (ko) 2014-08-20 2015-08-20 조작 시스템중에서 하드웨어 설비를 제어하는 방법과 모듈
JP2017510390A JP6462114B2 (ja) 2014-08-20 2015-08-20 オペレーティングシステムにおけるハードウェア・デバイス制御方法及びモジュール
US15/437,047 US10599493B2 (en) 2014-08-20 2017-02-20 Method and module in operating system for controlling hardware device

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
CN201410415227.2A CN104216709B (zh) 2014-08-20 2014-08-20 操作系统中直接控制硬件设备的方法和装置
CN201410415227.2 2014-08-20
CN201410456540.0A CN104636128B (zh) 2014-09-10 2014-09-10 操作系统中控制硬件设备的方法和模块
CN201410456540.0 2014-09-10
CN201410510111.7 2014-09-28
CN201410510111.7A CN104267956B (zh) 2014-09-28 2014-09-28 一种操作系统中控制硬件设备的方法和装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/437,047 Continuation US10599493B2 (en) 2014-08-20 2017-02-20 Method and module in operating system for controlling hardware device

Publications (1)

Publication Number Publication Date
WO2016026449A1 true WO2016026449A1 (zh) 2016-02-25

Family

ID=55350210

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/087608 WO2016026449A1 (zh) 2014-08-20 2015-08-20 一种操作系统中控制硬件设备的方法和模块

Country Status (5)

Country Link
US (1) US10599493B2 (zh)
EP (1) EP3196759A4 (zh)
JP (1) JP6462114B2 (zh)
KR (1) KR101960443B1 (zh)
WO (1) WO2016026449A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109032813B (zh) * 2018-06-29 2021-01-26 Oppo(重庆)智能科技有限公司 一种移动终端及其进程间通信的限制方法、存储介质
CN113824888B (zh) * 2021-11-23 2022-06-17 北京鲸鲮信息系统技术有限公司 Linux兼容Android的相机控制方法、系统、装置及介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN2759098Y (zh) * 2004-10-10 2006-02-15 矽诚科技股份有限公司 随音乐节拍变色的发光装置及其所使用的发光模块
WO2012173638A1 (en) * 2011-06-13 2012-12-20 American Megatrends, Inc. Methods, devices and computer program products for confluence of multiple operating systems
CN103488478A (zh) * 2013-09-03 2014-01-01 厦门雅迅网络股份有限公司 基于android平台的设备管理框架
CN103970559A (zh) * 2013-02-05 2014-08-06 北京壹人壹本信息科技有限公司 一种基于Android系统的设备加载方法及装置
CN104216709A (zh) * 2014-08-20 2014-12-17 深圳光启创新技术有限公司 操作系统中直接控制硬件设备的方法和模块
CN104267956A (zh) * 2014-09-28 2015-01-07 深圳光启创新技术有限公司 一种操作系统中控制硬件设备的方法和模块
CN104636128A (zh) * 2014-09-10 2015-05-20 深圳光启创新技术有限公司 操作系统中控制硬件设备的方法和模块

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5964843A (en) * 1996-04-25 1999-10-12 Microsoft Corporation System for enhancing device drivers
JP4444500B2 (ja) * 1998-01-07 2010-03-31 インテル・コーポレーション イメージング・デバイスとホスト・システムの間のイメージ情報の自動転送
FR2811783B1 (fr) 2000-07-13 2002-10-04 Thomson Multimedia Sa Systeme et procede d'adressage d'une unite centrale d'un appareillage multi-dispositifs et appareillage correspondant
KR101224184B1 (ko) * 2011-03-30 2013-01-21 주식회사 케이디티 시스템즈 모바일 환경으로 확장 가능한 통합형 원방감시제어시스템
KR101249735B1 (ko) * 2011-04-04 2013-04-03 주식회사 인프라웨어테크놀러지 범용 운영체제 상에서 안드로이드 어플리케이션을 실행하기 위한 단말장치 및 방법, 그리고 이를 위한 컴퓨터로 판독가능한 기록매체
FR2981174B1 (fr) * 2011-10-06 2013-12-20 Thales Sa Procede de creation dynamique d'un environnement d'execution d'une application pour securiser ladite application, produit programme d'ordinateur et appareil informatique associes
CN102629202A (zh) 2012-03-07 2012-08-08 维图通讯有限公司 一种处理内嵌多模块物联网移动终端设备数据系统的方法
CN103353839A (zh) 2013-06-07 2013-10-16 杭州竞天数码科技有限公司 一种基于Android系统的通用串行设备通信模块

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN2759098Y (zh) * 2004-10-10 2006-02-15 矽诚科技股份有限公司 随音乐节拍变色的发光装置及其所使用的发光模块
WO2012173638A1 (en) * 2011-06-13 2012-12-20 American Megatrends, Inc. Methods, devices and computer program products for confluence of multiple operating systems
CN103970559A (zh) * 2013-02-05 2014-08-06 北京壹人壹本信息科技有限公司 一种基于Android系统的设备加载方法及装置
CN103488478A (zh) * 2013-09-03 2014-01-01 厦门雅迅网络股份有限公司 基于android平台的设备管理框架
CN104216709A (zh) * 2014-08-20 2014-12-17 深圳光启创新技术有限公司 操作系统中直接控制硬件设备的方法和模块
CN104636128A (zh) * 2014-09-10 2015-05-20 深圳光启创新技术有限公司 操作系统中控制硬件设备的方法和模块
CN104267956A (zh) * 2014-09-28 2015-01-07 深圳光启创新技术有限公司 一种操作系统中控制硬件设备的方法和模块

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3196759A4 *

Also Published As

Publication number Publication date
JP6462114B2 (ja) 2019-01-30
KR101960443B1 (ko) 2019-03-20
US20170161125A1 (en) 2017-06-08
EP3196759A1 (en) 2017-07-26
US10599493B2 (en) 2020-03-24
JP2017528824A (ja) 2017-09-28
KR20170047284A (ko) 2017-05-04
EP3196759A4 (en) 2018-07-25

Similar Documents

Publication Publication Date Title
CN104267956B (zh) 一种操作系统中控制硬件设备的方法和装置
US20180074843A1 (en) System, method, and computer program product for linking devices for coordinated operation
CN104216709B (zh) 操作系统中直接控制硬件设备的方法和装置
JP6458959B2 (ja) 協調設計されたプロセッサ用動的言語アクセラレータ
US10019298B2 (en) Middleware interface and middleware interface generator
EP3008604A1 (en) Unified extensible firmware interface (uefi) driver and protocol
WO2020259163A1 (zh) 设备部署方法及装置、设备运行方法及电子设备
WO2021052167A1 (zh) 一种实现应用插件化的方法及电子设备
US8464226B2 (en) System and method for interoperating with foreign objects from a host computing environment
WO2016026449A1 (zh) 一种操作系统中控制硬件设备的方法和模块
CN106919391B (zh) 面向智能手机的可定制操作系统组件的嵌入式系统
US20230325209A1 (en) User Interface Implementation Method and Apparatus
US7350193B2 (en) Procedure invocation in an integrated computing environment having both compiled and interpreted code segments
US7886304B1 (en) Method and system implementing efficient remote procedure call and emulation system therefor
KR20130012603A (ko) 복수의 운영체제와 호환 가능한 가상머신 생성 방법 및 가상머신 프로그램을 저장한 기록매체
CN106922189B (zh) 设备代理装置及其控制方法
CN114265573B (zh) 一种音效控制方法、系统及中控车机
KR101019688B1 (ko) 고레벨 언어 기반 임베디드 시스템
JP2003177882A (ja) 無線印刷インターフェース・キットおよび方法
WO2024140891A1 (zh) 一种编译方法、电子设备及系统
CN115220936B (zh) 一种多类传感器数据在控制器中零拷贝的方法和装置
WO2024131486A1 (zh) 性能分析方法、可读存储介质、程序产品及电子设备
WO2023169212A1 (zh) 一种识别应用程序中sdk的方法、终端及服务器
WO2023246604A1 (zh) 手写输入方法及终端
CN117369987A (zh) 一种计算装置及相关任务执行调度方法

Legal Events

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

Ref document number: 15833667

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017510390

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2015833667

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015833667

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20177007449

Country of ref document: KR

Kind code of ref document: A