JP2017528824A

JP2017528824A - オペレーティングシステムにおけるハードウェア・デバイス制御方法及びモジュール

Info

Publication number: JP2017528824A
Application number: JP2017510390A
Authority: JP
Inventors: ルォペンリウ; シュイドンワン
Original assignee: クワーンチーインテリジェントフォトニックテクノロジーリミテッド
Priority date: 2014-08-20
Filing date: 2015-08-20
Publication date: 2017-09-28
Anticipated expiration: 2035-08-20
Also published as: JP6462114B2; WO2016026449A1; KR101960443B1; US20170161125A1; EP3196759A1; US10599493B2; KR20170047284A; EP3196759A4

Abstract

本発明に記載のオペレーティングシステムにおけるハードウェア・デバイス制御方法及びモジュールによれば、ハードウェア・デバイス動作制御用ステータスデータを取得したあと、まず、ステータスデータをバッファユニットに送信して格納し、それから、ハードウェア・デバイスドライバを呼び出し、前記ハードウェア・デバイスドライバによって、バッファユニットに格納されているステータスデータを読み取り、ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御することができる。ハードウェア・デバイスドライバの呼び出し方法は、既存のハードウェア・デバイスドライバを呼び出し、ハードウェア・デバイスの動作を制御することか、或いは、リンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードする手順と、ハードウェア・デバイス動作制御用コマンドを取得し、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出す手順と、呼び出された機能実現関数を実行し、ハードウェア・デバイスに対応する動作を実行させる手順と、を含む。ハードウェア・デバイスが対応する動作を実行するように、ハードウェア・デバイスドライバによって、直接的に制御するため、ハードウェア・デバイスでの動作に入ったら、ハードウェア・デバイスドライバの動作を遅延したり、中断したりすることを防止でき、データ転送の正確性を向上され、高速なデータ転送を実現できる。

Description

本発明は、電気設備におけるオペレーティングシステムの開発に関して、より具体的には、オペレーティングシステムにおけるハードウェア・デバイス制御方法及びモジュール。

図1は、Androidのシステムアーキテクチャ図を示す。

第１層101は、Linuxカーネルドライバ層（Linux kernel）であり、C / C++により実現する。Androidはセキュリティー、メモリー管理、プロセス管理、ネットワークスタック、そしてドライバモデルなどのコアシステムサービスをLinuxカーネルに依存する。Linuxカーネルは、ハードウエアとソフトウェアスタック間の抽象層の役目も務める。標準のLinuxカーネルのほか、Androidはカーネルドライバ、例え、Binder（IPC）ドライバ、カメラドライバ、電源管理などを追加される。

第2層は、ライブラリ及びAndroidランタイム層である。102はライブラリ層（Libraries）、103はAndroidランタイム層（Android Runtime）である。ライブラリ層102は、様々なコンポーネントでC/C++ライブラリが利用されているため、AndroidにはC/C++ライブラリが含まれる。これらの機能はAndroidのアプリケーションフレームワークを通して、開発者に提供される。Androidランタイム層103は、Androidシステムの動作環境として、Java言語のコアライブラリの大部分の機能を提供するコアライブラリが含まれており、Dalvik Java仮想マシンとJavaコアパッケージから構成される。

第3層104はアプリケーションフレームワーク層（Application Framework）である。Androidシステムにおいて、開発者は、コアアプリケーションと同じようにフレームワークAPI（Application Programming Interface、アプリケーションプログラミングインターフェース）にフルアクセスが可能である。

第4層105は、アプリケーション層（Applications）である。すべてのAndroidアプリケーションは、Javaプログラミング言語を使用して書かれる。利用者が開発したAndroidアプリケーション及びAndroidのコアアプリケーションは同じレイヤーにあり、すべては、AndroidのシステムAPIによって構成される。

現在、多くの電気設備は、Androidシステムを採用されており、さらにハードウェア・デバイスであるLEDを搭載されておる。1般的には、ユーザーにとって、LED付きタイプが必要となる。Androidシステムを用いて、どのようにLEDを制御するかについては、この分野の技術者が検討している。

一方、光通信の発展につれて、LEDを用いて光通信を行う電気設備が多くなっている。Androidシステムにおいて、例えば、アプリケーション層では、，ユーザがLEDを光通信の形として用いてデータを発送する。当該データは、送信待ちのデータである。対応する符号化ルールに従い、当該データをLEDの点滅を制御する時間データに変換する。すなわち、アプリケーション層において、LEDの点灯・消灯を制御する時間データが生成される。但し、アプリケーション層において、LEDを制御するコマンドを取得した後、LEDドライバの呼び出しコマンドを1個ずつ発送する。LEDドライバによって、1つのコマンドで処理動作を終了してから、アプリケーション層から発送するもう1つのコマンドを待つ。それに加えて、アプリケーション層からコマンドをドライバ層に発送するには、アプリケーションフレームワーク層、ライブラリ層及びAndroidランタイム層など複数のレイヤーを通過する必要があるので、一定の遅延は避けることができなく、光通信におけるデータ転送の正確性に影響を与える可能性がある。

光通信では、可視光を使って通信する可視光通信がよく活用されている。当該可視光は、データの転送にも、照明にも用いられる。但し、前述の遅延によって、データを転送する際に、データ転送の正確性を保証するため、その転送速度（可視光の点滅頻度）適当に制限しないと、データ転送の正確性を保証できない場合がある。そのために、高速データ転送に適用されない。

一方、Androidにおいて、LEDのON/OFFを制御する必要がある場合には、通常、まず、camera driverを呼び出し、それから、カメラ自体のインターフェイスを通じてカメラのパラメータを設定し、LEDの点灯・消灯を制御する。これは、間接的制御に属する方法であるので、LEDを呼び出すときに、一定の遅延時間が生じる。

従来技術では、まず、camera driverを呼び出し、それから、カメラ自体のインターフェイスを通じてカメラのパラメータを設定し、LEDの点灯・消灯を制御する。これは、間接的制御に属する方法であるので、LEDを呼び出すときに、一定の遅延時間が生じる。

本発明の第１側面によれば、オペレーティングシステムにおけるハードウェア・デバイス制御方法を提供可能となる。当該方法は、ハードウェア・デバイスの動作を制御する機能実現関数を含むリンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードするステップと、ハードウェア・デバイス動作制御用コマンドを取得するステップと、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出すステップと、呼び出された機能実現関数を実行し、ハードウェア・デバイスに対応する動作を実行させるステップと、を備えるものである。

本発明の第２側面によれば、オペレーティングシステムにおけるハードウェア・デバイス制御モジュールを提供可能となる。当該モジュールは、ハードウェア・デバイスの動作を制御する機能実現関数を含むリンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードするロードユニットと、ハードウェア・デバイス動作制御用コマンドを取得する検出ユニットと、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出す呼び出しユニットと、呼び出された機能実現関数を実行し、ハードウェア・デバイスに対応する動作を実行させる第2実行ユニットと、を備えるものである。

本発明の第3側面によれば、オペレーティングシステムにおけるハードウェア・デバイス制御方法を提供可能となる。当該方法は、ハードウェア・デバイス動作制御用ステータスデータを取得するステップと、前記ステータスデータをバッファユニットに送信して格納するステップと、ハードウェア・デバイスドライバを呼び出し、また、バッファユニットに格納されている前記ステータスデータを発光素子ドライバによって読み取り、前記ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御するステップと、を備えるものである。

本発明の第４側面によれば、オペレーティングシステムにおけるハードウェア・デバイス制御モジュールを提供可能となる。当該モジュールは、アプリケーション層における、ハードウェア・デバイス動作制御用ステータスデータを取得するステータスデータ取得ユニットと、アプリケーション層における、前記ステータスデータを発送する伝送ユニットと、アプリケーション層から発送されてくるステータスデータを格納するバッファユニットと、アプリケーション層において、カーネルドライバ層にあるハードウェア・デバイスドライバを呼び出し、また、バッファユニットに格納されている前記ステータスデータをハードウェア・デバイスドライバによって読み取り、前記ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御する実行ユニットと、を備えるものである。

本発明に記載のオペレーティングシステムにおけるハードウェア・デバイス制御方法及びモジュールによれば、ハードウェア・デバイス動作制御用ステータスデータを取得し、ステータスデータをバッファユニットに送信して格納し、それから、ハードウェア・デバイスドライバを呼び出し、前記ハードウェア・デバイスドライバによって、バッファユニットに格納されているステータスデータを読み取り、ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御することができる。ハードウェア・デバイスドライバの呼び出し方法は、既存のハードウェア・デバイスドライバを呼び出し、ハードウェア・デバイスの動作を制御することか、或いは、リンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードする手順と、ハードウェア・デバイス動作制御用コマンドを取得し、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出す手順と、呼び出された機能実現関数を実行し、ハードウェア・デバイスに対応する動作を実行させる手順と、を含む。本発明に記載のオペレーティングシステムにおけるハードウェア・デバイス制御方法及びモジュールによれば、ハードウェア・デバイスドライバによって、直接的に、ハードウェア・デバイスに対応する動作を実行させることができる。また、ステータスデータがバッファユニットに格納されているため、ハードウェア・デバイスドライバによって呼び出されると、バッファユニットに格納されているステータスデータを直接に読み取ることができる。当該読み取り処理が連続的動作なので、ハードウェア・デバイスでの動作に入ったら、ハードウェア・デバイスドライバの動作を遅延したり、中断したりすることを防止でき、データ転送の正確性を向上され、高速なデータ転送を実現できる。

図1は、Androidのシステムアーキテクチャ図を示す。図2は、本発明の実施例１に関するAndroidのシステムアーキテクチャ図を示す。図3は、本発明の実施例１に関するAndroidのシステムアーキテクチャ解析図を示す。図4は、本発明の実施例１に関するAndroidシステムにおけるハードウェア・デバイス制御方法のフローチャートを示す。図5は、本発明の実施例2に関するAndroidシステムにおけるハードウェア・デバイス制御モジュール構成図を示す。図6は、本発明の実施例3に関するAndroidシステムにおけるハードウェア・デバイス制御方法のフローチャートを示す。図7は、本発明の実施例4に関するAndroidシステムにおけるハードウェア・デバイス制御モジュール構成図を示す。図8は、本発明の実施例5に関するAndroidシステムにおけるハードウェア・デバイス制御方法のフローチャートを示す。図9は、本発明の実施例6に関するAndroidシステムにおけるハードウェア・デバイス制御モジュール構成図を示す。

本発明をよく理解するために、本発明に記載の実施例は、Androidシステムにおける発光素子（LED）の点灯・消灯を例として説明する。本発明に記載のオペレーティングシステムは、Blackberry OSシステム、windows phoneシステム、windows mobileシステム、IOSシステムまたはMac OSシステムなど他のオペレーティングシステムでもよいことを理解されたい。ハードウェア・デバイスは、電気設備におけるカメラ、振動器、Bluetooth、センサー、マイクなどでもよい。

以下、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。

実施例1
本発明の実施例において、Linuxカーネル空間（Linux Kernel層）に作成されたカーネルドライバ（LEDドライバ）及びユーザ空間に作成されたハードウェア抽象化層インタフェースを通して、上位の層にハードウエアアクセスインタフェースを提供する。すなわち、Androidシステムのアプリケーションフレームワーク層にハードウェアサービスを提供する。Androidシステムのアプリケーションは、Java言語で書かれるものであるが、ハードウエアドライバは、C/C++言語で作成されるものである。Javaは、JNI （Java Native Interface、Javaローカル呼び出し）の方法を使って呼び出す。そのために、Androidシステムにおいて、Javaアプリケーションは、JNIを使ってハードウェア抽象化層インタフェースを呼び出すことができる。

図2に示すように、本発明の実施例において、Androidシステムのアーキテクチャを五つの層に分けられる。第1層201は、Linuxカーネルドライバ層（Linux kernel）、第2層202は、ハードウェア抽象化層（HAL，Hardware Abstraction Layer）、第3層203及び204はライブラリ層203（Libraries）及びランタイム層204（Android Runtime）、第4層205は、アプリケーションフレームワーク層（Application Framework）、第5層206はアプリケーション層（Applications）である。

図2に基づき、図3は、他の角度からAndroidのシステムアーキテクチャ解析図を示す。Androidシステム全体をハードウェア、カーネル空間及びユーザ空間の三つに分けられるが、それぞれの構造は、図3に示す。

本発明の実施例において、JNI層を3番目の階層に移動する。JNI層は、アプリケーションフレームワーク層に一連のインタフェース関数を提供する。コールバック関数を使って、ハードウェア抽象化層と、やり取りを行い、これらのインタフェース関数を使用できるようになる。

本発明の実施例に記載のLED点灯・消灯制御方法も同様に、図1に示すAndroidシステムに適用することをご説明させて頂きたい。本実施例において、ハードウェア抽象化層を追加する。ハードウェア抽象化層を追加する目的としては、基準Linuxカーネルドライバ層インタフェースを持たないハードウェア・デバイスにアクセス経路を提供したり、上位のプログラムを呼び出すように可読性の低いインタフェースを可読性の高いインタフェースに変換したりするものである。すなわち、ハードウェア抽象化層は、Linuxカーネルドライバ層よりも上位に存在し、Linuxカーネルドライバ層からのサポートを受け、プリケーションフレームワーク層とJNI層にLED制御用インタフェースを提供できる。

図1及び図2に示す各階層の内部構造について、当業者であれば、よく知るべきであるが、説明は省略する。

図4は、本実施例に関するAndroidシステムにおけるLED点灯・消灯の直接制御方法を示す。図4に示すように、次のステップを含む。

ステップ301、アプリケーションフレームワーク層において、リンクライブラリをロードさせるコマンドを検出し、取得する。

具体的な実施例において、一方では、Androidシステムが起動した後に、自動的に、対応するリンクライブラリをロードするので、リンクライブラリをロードさせるコマンドは、Androidシステムが起動した後に発送してくる1コマンドでもよいが、もう一方では、リンクライブラリは、対応する機能実現関数を呼び出さないとロードされないので、リンクライブラリをロードさせるコマンドは、機能実現関数を呼び出する時、Androidシステムに検出されるコマンドでもよい。

ステップ302、アプリケーションフレームワーク層において、LED動作を制御する機能実現関数を含むリンクライブラリをロードする。
機能実現関数は、LED動作を制御する関数である。例えば、
led_on
led_off
……
或いは、LEDのドライバ信号が他のデバイス、例えば、CPUチップやカメラチップなどから発送されてくる場合、まず、当該デバイスの電源を入れ、それから、ドライバLEDを起動して発光させる。このやり方の有利な点としては、ランプ制御モードをさらに柔軟的に設定できることである。例えば、色別、輝度別などについて、下記の関数が書かれる。

led_device_open //LEDの電源ON（オプション、前述のデバイスの電源をONにするため）
led_device_close //LEDの電源OFF（オプション、前述のデバイスの電源をONにするため）
led_on
led_off
……
前述のLED動作制御用関数が定義された後、.cファイルに格納する。.cファイルは、すべての変数や関数の定義が書かれる。

ステップ303、アプリケーション層において、LED動作制御用コマンドを取得する。このコマンドは、ユーザがAndroidデバイスのヒューマンマシンインタフェース（つまり、アプリケーション層）から入力するLED動作制御用コマンドでもよいし、アプリケーション層における符号化後のコマンド文字列でもよい。例えば、「0」と「1」で表すデータ文字列ですが、「0」はLED電源OFF、「1」はLED電源ONを意味する。

ステップ301に基づき、ステップ303におけるLED動作制御用コマンドをリンクライブラリをロードさせるコマンドとして扱えるので、LED動作制御用的コマンドによって機能実現関数を呼び出される。本実施例に記載の方法についてステップバイステップという順番で説明したが、本発明に限定されるものではなく、これらの順番へのさまざまな変更は、本発明の精神から逸脱することなく、他の態様に適用されるのを理解されたい。

ステップ304、アプリケーション層において、リンクライブラリのロードが終了したかを確認し、終了していない場合、リンクライブラリのロード終了を待つが、終了した場合、ステップ305に移行する。

ステップ305、アプリケーション層において、リンクライブラリから、LED動作制御用コマンドに対応する機能実現関数を呼び出す。

アプリケーション層では、リンクライブラリのロードが全部終了したことを検出した後に機能実現関数を呼び出すか、或いは、確認しながら呼び出すか、あるいは、一定の時間を設定し、当該時間になったら、機能実現関数を呼び出す。

ステップ306、Linuxカーネルドライバ層において、呼び出された機能実現関数を実行し、LEDに対応する動作を実行させる。

本実施例において、Linuxカーネルドライバ層には、LEDドライバを設けており、LEDドライバによって、呼び出された機能実現関数を実行し、LEDに対応する動作を実行させる。

現在、一般、LEDをカメラの補助装置として使う。Cameraを使わないと、LEDを使いません。そのために、Androidシステムにおいて、LEDを使うには、まず、camera driverを呼び出し、cameraのパラメータを設定することで、LEDを制御する。すなわち、LEDへの制御は、間接な方法で行う。

camera driverを使ってLEDを制御する時には、時間の遅れが生じる場合がある。LEDの現在の応用範囲から考えると、この時間遅延が正常な使用に影響を与えないということである。但し、光通信（例えば、可視光通信）の発展につれて、光を使って情報転送することが求められている。光通信は、その伝送速度や情報転送正確性が要求される。そのために、上記の時間遅延問題が徐々に顕在化してきて、光通信の発展に差し障りをきたす。

本実施例において、AndroidシステムのLinuxカーネルドライバ層には、LEDドライバを設ける。LEDを制御する時、直接な制御方法となるので、LEDドライバを直接に呼び出す。それによって、camera driverでのLED制御に時間遅延が生じることを防止できる。

JNI層には、インタフェース関数が定義される。アプリケーション層において、JNI層のインタフェース関数に基づき、リンクライブラリからLED動作制御用コマンドに対応する機能実現関数を呼び出し、Linuxカーネルドライバ層のLEDドライバが対応する機能実現関数を実行する。

前記のオペレーティングシステムは、IOSシステムであり、syscallは、ローカルインタフェースであるので、AndroidシステムにおけるJNI層が定義されるインタフェース関数が使われるが、ここでは説明は省略する。

JNI層のインタフェース関数は、C/C++関数とJAVA関数の対応関係を定義されており、当該インタフェース関数は、JNIを使って、ハードウェア抽象化層のC/C++関数をアプリケーション層のJAVA関数にマッピングし、ハードウェア抽象化層（C/C++言語で）とアプリケーション層（JAVA言語で）とのやり取りを行う。led_onは、JAVA関数であり、JNIインタフェースからのマッピングがないと、最下層の機能関数を呼び出せない。JNI層において、この関数のマッピングは、java_完全なパッケージ名_クラス名_led_onというローカル関数に作成され、関数から最下層の機能関数を呼び出す。

Android運行環境におけるDalvik仮想マシンによって、メンバー関数を一つ呼び出すとき、当該メンバー関数は、JNIメソッドであることが分かったら、対応するアドレスに飛んで実行させる。すなわち、JNIメソッドは、Dalvik仮想マシンインタプリタではなく、直接にローカルオペレーティングシステムの上で実行されるものである。それによって、JNIメソッドは、Androidアプリケーションとローカルオペレーティングシステムが直接に通信する手段の一つであり、JNIメソッドによって、通信の効率性をさらに向上できる。

JNI層が機能実現関数を直接呼び出されるには、JNI層に機能実現関数をインスタンス化したアドレスが格納されていることが望ましい。インスタンス化とは、オブジェクト指向のプログラミングにおいて、クラスを基にした実際の値としてのデータを生成することである。例えば、LEDを制御する過程には、LED動作というクラスがあるとすれば、LED電源オン、LED電源オフなど具体的な機能実現関数をオブジェクトに作成する。このオブジェクトを作成するのは、インスタンス化である。当該オブジェクトを作成できたら、対応するアドレスが生成される。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構成体でなければならない。その一部のプログラミングコードについては、下記を参照してください。

struct led_module_t
{
struct hw_module_t common;
};
struct led_control_device_t
{
struct hw_device_t common;
int (*set_on)(struct led_control_device_t *dev, int32_t led);
int (*set_off)(struct led_control_device_t *dev, int32_t led);
};
struct led_control_context_t
{
struct led_control_device_t device;
};
構成体定義の役割：お互いに関連する変数や機能をまとめて、コードでパッケージングするものによって、勝手に変更することを避けることができる。構成体の利用が、望ましいが、これに限定しない。

構成体とは、幾つの同じ或いは異なる型のデータをまとめて一つの固まりにしたものである。構造体は一部のプロパティー、パラメータ等値（即ちデータメンバー）をパッケージングして新たな型になる。また、パッケージによって、これらのプロパティーやパラメータ等の値が繰り返し利用される。

LEDドライバに対して、LED輝度、LEDの電源オン・オフ時間などを構成体に定義されてもよい。輝度値、電源オン・電源オフの時間などはデータのメンバーにあたり、対応するクラスの構成体にパッケージングする。なお。C++で定義される構成体は、そのメンバーは、オブジェクトの状態または行為を表記する関数でもよい。例えば、LED点灯・消灯制御用関数であるLED_ON、LED_OFF、LED_DEVICE_OPEN、LED_DEVICE _CLOSEですが、それぞれに、前記のled_on、led_off、led_device_open、led_device_close関数に対応する。

実施例2
図5は、前述のAndroidシステムにおけるLED点灯・消灯の直接制御方法を示す。本実施例において、また、ロードユニット401と、検出ユニット402と、呼び出しユニット403と、実行ユニット404とを含むAndroidシステムにおけるLED点灯・消灯直接制御モジュール。

ロードユニット401は、ハードウェア・デバイスの動作を制御する機能実現関数を含むリンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードする。

検出ユニット402は、LED動作制御用コマンドを取得する。

呼び出しユニット403は、ロードユニット401によってダイナミックリンクライブラリをロードしたことを検出したら、前記リンクライブラリからLED動作制御用コマンドに対応する機能実現関数を呼び出すか、或いは、ロード終了かどうかを確認しながら呼び出するか、或いは、ロードする時間が事前に設定した時間に達したら、リンクライブラリを呼び出す。

実行ユニット404は、呼び出された機能実現関数を実行し、LEDに対応する動作を実行させる。具体的な実施例において、Androidシステムのアーキテクチャは、アプリケーション層、アプリケーションフレームワーク層、ライブラリ及びAndroidランタイム層、Linuxカーネルドライバ層からなる。Linuxカーネルドライバ層に、LEDドライバを設けている。実行ユニット404は、Linuxカーネルドライバ層において、呼び出された機能実現関数をLEDドライバによって実行し、LEDに対応する動作を実行させる。

Androidシステムのアーキテクチャは、さらに、JNI層を含む。JNI層は、インタフェース関数が定義されいる。ロードユニット401は、アプリケーションフレームワーク層において、リンクライブラリをロードさせるコマンドを検出したら、取得して、リンクライブラリをロードする。呼び出しユニット403は、アプリケーション層において、JNI層のインタフェース関数に従い、リンクライブラリから、LED動作制御用コマンドに対応する機能実現関数を呼び出し、Linuxカーネルドライバ層のLEDドライバに対応する機能実現関数を実行させる。

さらに、JNI層には、機能実現関数をインスタンス化したアドレスが格納されている。

Androidシステムのアーキテクチャは、さらにハードウェア抽象化層を含むことが望ましい。ハードウェア抽象化層は、Linuxカーネルドライバ層の上に実行されており、Linuxカーネルドライバ層からのサポートを受け、アプリケーションフレームワーク層とJNI層にLED制御用インタフェースを提供する。

オペレーティングシステムがIOSシステムである場合、 IOSシステムは、さらに、Libraryライブラリアダプティブを含み、Androidシステムのアーキテクチャにおけるハードウェア抽象化層と同様な働きを持つので、説明は省略する。

本発明の実施例に記載のAndroidシステムにおけるLED点灯・消灯の直接制御方法及びモジュールであって、リンクライブラリをロードさせるコマンドを検出したら、取得してリンクライブラリをロードするステップと、LED動作制御用コマンドを取得した後、リンクライブラリから前記コマンドに対応する機能実現関数を呼び出すステップと、呼び出された機能実現関数を実行し、LEDに対応する動作を実行させるステップとを含む。このように、前記の方法及びモジュールによれば、LED点灯・消灯を直接制御することができる。

本発明の実施例に記載のAndroidシステムにおけるLED点灯・消灯の直接制御方法及びモジュールは、WPオペレーティングシステムにも広く応用されており、具体的な実現方法も同じなので、説明は省略する。

実施例3
本実施例に関する技術的構想は、下記のとおりである。まず、ハードウェア・デバイス動作制御用ステータスデータをバッファユニットに格納する。前記バッファユニット内に格納されているデータはハードウェア・デバイスドライバによって、直接読み取り可能なものである。ステータスデータを格納した後、ハードウェア・デバイスドライバを呼び出し、バッファユニットに格納されているステータスデータをハードウェア・デバイスドライバによって、読み取る。ステータスデータに従い、ハードウェア・デバイスの動作状態を制御する。ハードウェア・デバイスドライバによって、バッファユニットからステータスデータを連続的に読み取るので、時間が遅延したり、中断したりすることがなく、データ転送の正確性を向上され、高速なデータ転送を実現できる。

本実施例に記載のハードウェア・デバイスは、発光素子、振動器、Bluetooth、カメラ、センサーまたはマイクでもよい。本実施例を容易に理解するために、本実施例は、ハードウェア・デバイスについて、発光素子を例に挙げて説明するが、ハードウェア・デバイスドライバは、発光素子ドライバ、ステータスデータは、時間データ、ハードウェア・デバイスの動作は、発光素子のオン・オフにあたる。

図2と図6に、本実施例に記載のオペレーティングシステムにおけるハードウェア・デバイス制御方法を示す。ハードウェア・デバイスは、発光素子である。次のステップを含む。

ステップ501、初期データを取得する。具体的には、初期データは、例えば、ユーザから入力する銀行系カードのアカウント、ユーザから入力するデータである。Androidシステムでは、アプリケーション層において、初期データを取得する。

ステップ502、初期データを符号化し、発光素子の点灯・消灯を制御する時間データを取得する。例えば、発光素子の点灯5s、消灯2s、点灯3s……。Androidシステムでは、アプリケーション層において初期データを符号化する。

ある実施例において、発光素子の点灯・消灯を制御する時間データをユーザによって直接入力する場合、初期データは、時間データに当たるので、符号化処理を行わない。

発光素子は、電気設備自体の光源、例えば、LEDランプでもよいし、携帯電話機に取り付けた他の光源、たとえば、レーザー送信機またはLEDでもよい。

通常は、取得した初期データは、N進数のデータである。初期データの符号化処理は、前記N進数のデータを電気信号ユニットに符号化することにあたる。具体的な処理方法は、下記のとおりである。

N進数のデータを順番に対応する電気信号ユニットに変換するステップであって、N進数のデータにおける異なる数値を異なる電気信号ユニットに符号化し、電気信号ユニット内のハイレベル・ローレベルの持続時間がそれぞれに、Ti1、Ti2…とTijとなり、i、j、Nは自然数であり、異なる電気信号ユニットを区切り記号にて区切ることを特徴とするもの。本例に記載の電気信号ユニット内のハイレベル・ローレベルについて、ハイレベルからローレベルへの順でもよいし、ローレベルからハイレベルへの順でもよい。ハイレベルとローレベルの間は、レベルのジャンプにて区切ってもよい。或いは、あるいは、持続時間の異なるハイレベル・ローレベルをフィーチャーレベル（Feature Level）とし、フィーチャーレベルと異なる基準レベルを区切りとして用いてもよい。

選択可能な一実施例において、少なくとも、エンコード待ちのN進数のデータの一部について、異なる状態のレベル信号に符号化でき、また、レベル信号の大きさに応じて複数のクループに分け、各グループがそれぞれのN進数のデータにおける各数値を表す。

このステップでは、初期データがN進数のデータに変換されていないデータであれば、まず、初期データをN進数のデータに変換する。

本実施例において、Ti2、Ti3…及びTijとTi1の計算値は、既定値又は既定範囲である。前記の計算とは、Ti2、Ti3…及びTijとTi1の商、積、差、和、逆数及び/または算余数を指す。

このステップにおいて、二進数のデータを例として説明する。N=2の場合、二進数の0を第1電気信号ユニットに符号化し、第1電気信号ユニット内のハイレベル・ローレベル持続時間がそれぞれに、T11とT12となる。二進数の1を第2電気信号ユニットに符号化し、第2電気信号ユニット内のハイレベル・ローレベル持続時間がそれぞれに、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、時間データを発送する。Androidシステムでは、アプリケーション層において、時間データをカーネルドライバ層に発送する。

ステップ504、発送されてくる時間データをバッファユニットに格納する。Androidシステムでは、カーネルドライバ層が、アプリケーション層から発送されきた時間データを取得した後、当該データをカーネルドライバ層におけるバッファユニットに格納する。バッファユニットに格納されているデータは、発光素子ドライバによって、直接に読み取り可能なものである。バッファユニットは、時間データを一時的に格納するもので、バッファレジスタでもよい。他の実施例において、前記バッファユニットは、既存システムの記憶ユニットでもよい。プログラミングによって、前記の記憶ユニットの領域の一部または全部を本実施例のバッファユニットとして扱う。

バッファレジスタは、バッファともいわれ、入力バッファと出力バッファの2つに分けられる。入力バッファは、外部から発送されてくるデータを一時的に記憶し、プロセッサへ送信する。出力バッファは、プロセッサから外部デバイスに送るデータを一時的に格納する。高速なCPUと低速な外部デバイスの間にバッファを設けて、両者の速度差を緩衝し、データ転送を同期できる。

ステップ505、送信待ちのデータに対応する時間データを発送して格納した後、発光素子ドライバを呼び出し、発光素子が使用可能な状態になる。Androidシステムでは、アプリケーション層において、カーネルドライバ層に存在している発光素子ドライバを呼び出す。

ステップ506、発光素子ドライバを呼び出した後、バッファユニットに格納されている時間データを読み取る。

ステップ507、発光素子ドライバより時間データを読み取った後、時間データに基づき、発光素子の点灯・消灯の時間を制御する。

ある実施例において、時間データは、配列である。発光素子ドライバは、時間データに基づき、発光素子の点灯・消灯の時間を制御する。換言すれば、発光素子ドライバは、配列の要素の順番に沿って発光素子の点灯・消灯の時間を制御する。もちろん、他の実施例において、時間データの構造は、従来技術によって実施可能な他の構造でもよい。

本実施例に記載のオペレーティングシステムにおける発光素子制御方法によれば、まず、発光素子の点灯・消灯の時間を制御する時間データをバッファユニットに格納する。時間データを格納した後、発光素子ドライバを呼び出す。バッファユニットに格納されている時間データを発光素子ドライバによって、読み取る。時間データに従い、発光素子の点灯・消灯の時間を制御する時間を制御する。発光素子ドライバによって、バッファユニットからステータスデータを連続的に読み取るので、時間が遅延したり、中断したりすることがなく、データ転送の正確性を向上され、高速なデータ転送を実現できる。

本実施例に記載のオペレーティングシステムは、Androidシステム、Blackberry OSシステム、windows phoneシステム、windows mobileシステム、IOSシステム、Mac OSシステムなどでもよいことを理解されたい。システムによって差があるものの、これらの態様への適当な変更などは、本発明の精神から逸脱することなく、本実施例に記載の発光素子制御方法に適用されるのは、当業者であれば、理解されるべきである。

ある実施例において、ステータスデータは、発光素子の発光強度を制御する強度データでもよい。他の実施例において、ハードウェア・デバイスは、振動器であれば、ステータスデータは、振動器の振動強度を制御する強度データでもよい。他のハードウェア・デバイスについて、その実現原理は、発光素子の実現原理と同様なので、説明は省略する。

実施例4
図7は、実施例3に基づき、提供するオペレーティングシステムにおけるハードウェア・デバイス制御方法を示す。本実施例は、また、オペレーティングシステムにおけるハードウェア・デバイス制御モジュールを提供可能となる。ハードウェア・デバイスは発光素子であり、時間データ取得ユニット601と、伝送ユニット602と、バッファユニット603と、実行ユニット604とを含む。

時間データ取得ユニット601は、アプリケーション層において、発光素子の点灯・消灯の時間を制御する時間データを取得する。

具体的な実施例において、時間データ取得ユニット601は、符号化サブユニット605をさらに備える。符号化サブユニット605は、アプリケーション層において、初期データを取得し、当該初期データを符号化して時間データが得られる。例えば、発光素子を点灯5s、消灯2s、点灯3s……ように制御する。

具体的には、初期データは、例えば、ユーザから入力する銀行系カードのアカウント、ユーザから入力するデータである。ある実施例において、発光素子の点灯・消灯を制御する時間データをユーザによって直接入力する場合、初期データは、時間データに当たるので、符号化サブユニット605での符号化処理を行わない。

伝送ユニット602は、アプリケーション層において、時間データをカーネルドライバ層に発送する。

バッファユニット603は、アプリケーション層から発送されきた時間データを格納する。カーネルドライバ層が、アプリケーション層から発送されきた時間データを取得した後、当該データをカーネルドライバ層におけるバッファユニット603に格納する。バッファユニット603に格納されているデータは、発光素子ドライバによって、直接に読み取り可能なものである。バッファユニットは、時間データを一時的に格納するもので、バッファレジスタでもよい。他の実施例において、前記バッファユニット603は、既存システムの記憶ユニットでもよい。プログラミングによって、前記の記憶ユニットの領域の一部または全部を本実施例のバッファユニット603として扱う。

実行ユニット604は、アプリケーション層において、カーネルドライバ層に存在している発光素子ドライバを呼び出し、バッファユニットに格納されている時間データを発光素子ドライバに読み取らせ、時間データに基づき、発光素子の点灯・消灯の時間を制御する。送信待ちのデータに対応する時間データを発送して格納した後、アプリケーション層において、カーネルドライバ層に存在している発光素子ドライバを呼び出し、発光素子が使用可能な状態になる。発光素子ドライバを呼び出し、バッファユニットに格納されている時間データを発光素子ドライバに読み取らせ、時間データに基づき、発光素子の点灯・消灯の時間を制御する。

本実施例に記載のオペレーティングシステムにおける発光素子制御モジュールによれば、まず、発光素子の点灯・消灯の時間を制御する時間データをバッファユニット303に格納する。時間データを格納した後、発光素子ドライバを呼び出す。バッファユニットに格納されている時間データを発光素子ドライバによって、読み取る。時間データに従い、発光素子の点灯・消灯の時間を制御する時間を制御する。発光素子ドライバによって、バッファユニットからステータスデータを連続的に読み取るので、時間が遅延したり、中断したりすることがなく、データ転送の正確性を向上され、高速なデータ転送を実現できる。

実施例5
本実施例によれば、まず、ハードウェア・デバイス動作制御用ステータスデータをバッファユニットに格納する。前記バッファユニット内に格納されているデータはハードウェア・デバイスドライバによって、直接読み取り可能なものである。ステータスデータを格納した後、ハードウェア・デバイスドライバを呼び出し、バッファユニットに格納されているステータスデータをハードウェア・デバイスドライバによって、読み取る。ステータスデータに従い、ハードウェア・デバイスの動作状態を制御する。ハードウェア・デバイスドライバによって、バッファユニットからステータスデータを連続的に読み取るので、時間が遅延したり、中断したりすることがなく、データ転送の正確性を向上され、高速なデータ転送を実現できる。

本実施例に記載のハードウェア・デバイスは、発光素子、振動器、Bluetooth、カメラ、センサーまたはマイクでもよい。本実施例を容易二節目するために、本実施例は、ハードウェア・デバイスについて、発光素子（LED）を例に挙げて説明するが、ハードウェア・デバイスドライバは、LEDドライバ、ステータスデータは、時間データ、ハードウェア・デバイスの動作は、発光素子の点灯・消灯にあたる。

図8は、本実施例に関するオペレーティングシステムにおけるハードウェア・デバイス制御方法を示す。当該方法は、次のステップを含む。

ステップ701-704は、実施例3に記載のステップ501-504と同じである。

ステップ705-710は、実施例1に記載のステップ301-306と同じである。

ステップ711、バッファユニットに格納されている時間データをLEDドライバによって、読み取る。

ステップ712、LEDドライバより時間データを読み取った後、時間データに基づき、発光素子の点灯・消灯の時間を制御する。

本実施例において、AndroidシステムのLinuxカーネルドライバ層には、LEDドライバを設ける。LEDを制御する時、LEDへの直接名制御方法で、LEDドライバを直接に呼び出す。それによって、camera driverでのLED制御に時間遅延が生じることを防止できる。

ステップ705-ステップ709は、本実施例に記載のハードウェア・デバイスドライバ（LEDドライバ）呼び出し方法であり、直接制御する方法に当たることを理解されたい。他の実施例において、その他の従来技術を利用する方法、例えば、前述の間接制御の方法によって、既存のハードウェア・デバイスドライバを呼び出し、ハードウェア・デバイスの動作を制御する。

JNI層が機能実現関数を直接呼び出されるには、JNI層に機能実現関数をインスタンス化したアドレスが格納されていることが望ましい。インスタンス化とは、オブジェクト指向のプログラミングにおいて、クラス（Class）を基にした実際の値としてのデータを生成することである。例えば、LEDを制御する過程には、LED動作というクラスがあるとすれば、LED電源オン、LED電源オフなど具体的な機能実現関数をオブジェクトに作成する。このオブジェクトを作成するのは、インスタンス化である。当該オブジェクトを作成できたら、対応するアドレスが生成される。JNI層に当該アドレスを格納し、その後、当該機能実現関数を呼び出したい場合には、前記機能実現関数に対応するクラスを検索しなくても、前記アドレスに従い、対応するオブジェクトを早速に特定できる。

本実施例において、ハードウェア抽象化層には、次の三つの構成体が定義される。本実施例におけるハードウェア抽象化層の3構成体は、実施例1と同様なので、説明は省略する。

本実施例に記載のオペレーティングシステムにおけるLED制御方法によれば、まず、LEDの点灯・消灯の時間を制御する時間データをバッファユニットに格納する。時間データを格納した後、発光素子ドライバを呼び出す。バッファユニットに格納されている時間データをLEDドライバによって、読み取る。時間データに従い、LEDの点灯・消灯の時間を制御する時間を制御する。LEDドライバによって、バッファユニットからステータスデータを連続的に読み取るので、時間が遅延したり、中断したりすることがなく、データ転送の正確性を向上され、高速なデータ転送を実現できる
本実施例に記載のオペレーティングシステムは、Androidシステム、Blackberry OSシステム、windows phoneシステム、windows mobileシステム、IOSシステム、Mac OSシステムなどでもよいことを理解されたい。システムによって差があるものの、これらの態様への適当な変更などは、本発明の精神から逸脱することなく、本実施例に記載の発光素子制御方法に適用されるのは、当業者であれば、理解されるべきである。

実施例6
図9は、実施例5に基づき、提供するオペレーティングシステムにおけるハードウェア・デバイス制御方法を示す。本実施例において、また、ステータスデータ取得ユニット801と、伝送ユニット802と、バッファユニット803と、ロードユニット804と、検出ユニット805と、呼び出しユニット806と、第1実行ユニット808と、第2実行ユニット807とを含むオペレーティングシステムにおけるハードウェア・デバイス制御モジュールを提供可能となる。

ステータスデータ取得ユニット801は、ハードウェア・デバイス動作制御用ステータスデータを取得する。

伝送ユニット802は、ステータスデータを発送する。

バッファユニット803は、伝送ユニット802から発送されてくるステータスデータを格納する。

第1実行ユニット808は、ハードウェア・デバイスドライバを呼び出し、バッファユニット803に格納されているステータスデータをハードウェア・デバイスドライバによって読み取り、当該ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御する。

ロードユニット804は、ハードウェア・デバイスの動作を制御する機能実現関数を含むリンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードする。

検出ユニット805は、LED動作制御用コマンドを取得する。

呼び出しユニット806は、リンクライブラリから、ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出す。

第2実行ユニット807は、呼び出された機能実現関数をハードウェア・デバイスドライバに実行させ、ハードウェア・デバイスが対応する動作を実行する。

具体的な実施例において、ステータスデータ取得ユニット801、符号化サブユニット801をさらに備える。符号化サブユニット801は、初期データを取得し、当該初期データを符号化して時間データが得られる。

具体的な実施例において、ハードウェア・デバイスは、発光素子、振動器、Bluetooth、カメラ、センサーまたはマイクでもよい。

具体的な実施例において、ハードウェア・デバイスは、発光素子である場合、ハードウェア・デバイスドライバは、発光素子ドライバ、ステータスデータは時間データを表す配列である。ハードウェア・デバイスドライバがステータスデータに基づき、ハードウェア・デバイスの状態を制御することを第1実行ユニット808によって、制御する。つまり、発光素子ドライバが、配列の要素の順番に沿って発光素子の点灯・消灯の時間を制御するすることを第1実行ユニット808によって、制御する。

具体的な実施例において、ステータスデータは、時間データ、輝度データ或いは強度データを表す配列である。

具体的な実施例において、オペレーティングシステムはAndroidシステム、Blackberry OSシステム、windows phoneシステム、windows mobileシステム、IOSシステムまたはMac OSシステムである。

具体的な実施例において、オペレーティングシステムはAndroidシステムである場合、Androidシステムのカーネルドライバ層には、ハードウェア・デバイスのドライバを設ける。第2実行ユニット807は、ハードウェア・デバイスが対応する動作を実行するために、ハードウェア・デバイスのドライバによって呼び出される機能実現関数を制御する。或いは、オペレーティングシステムはIOSシステムである場合、IOSシステムのコア心システム層には、ハードウェア・デバイスのドライバを設ける。第2実行ユニット807ハードウェア・デバイスが対応する動作を実行するために、ハードウェア・デバイスのドライバによって呼び出される機能実現関数を制御する。

具体的な実施例において、オペレーティングシステムはAndroidシステムである場合、Androidシステムのアーキテクチャは、JNI層をさらに有する。JNI層は、対応するJNIインタフェース関数が定義されている。呼び出しユニット806は、インタフェース関数に従い、リンクライブラリから、ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出し、カーネルドライバ層のハードウェア・デバイスドライバが対応する機能実現関数を実行する。或いは、オペレーティングシステムは、IOSシステムである場合、LibSystemライブラリを使ってコアシステム層から提供されるインタフェース関数をアクセスする。呼び出しユニット806は、インタフェース関数に従い、リンクライブラリから、ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出し、カーネルドライバ層のハードウェア・デバイスドライバが対応する機能実現関数を実行する。

具体的な実施例において、JNI層には、機能実現関数をインスタンス化したアドレスが格納されている。

具体的な実施例において、オペレーティングシステムは、Androidシステムである場合、Androidシステムのアーキテクチャは、ハードウェア抽象化層をさらに含む。ハードウェア抽象化層は、Linuxカーネルドライバ層の上に実行されており、Linuxカーネルドライバ層からのサポートを受け、アプリケーションフレームワーク層とJNI層にLED制御用インタフェースを提供する。或いは、オペレーティングシステムは、IOSシステムである場合、IOSシステムは、コアサービス層をさらに含む。

本実施例におけるロードユニット804、検出ユニット805、呼び出しユニット806、第2実行ユニット807からハードウェア・デバイスドライバ（LEDドライバ）を呼び出す方法は、直接制御する方法にあたることを理解されたい。他の実施例において、第1実行ユニット808は、その他の従来技術を利用する方法、例えば、前述の間接制御の方法によって、既存のハードウェア・デバイスドライバを呼び出し、ハードウェア・デバイスの動作を制御する
本実施例に記載のオペレーティングシステムにおけるハードウェア・デバイス制御モジュールは、前述のハードウェア・デバイス制御方法に対応するので、その技術原理の説明は、省略する。

本発明の実施例に記載のオペレーティングシステムにおけるハードウェア・デバイス制御方法及びモジュールによれば、ハードウェア・デバイス動作制御用ステータスデータを取得し、ステータスデータをバッファユニットに送信して格納し、それから、ハードウェア・デバイスドライバを呼び出し、前記ハードウェア・デバイスドライバによって、バッファユニットに格納されているステータスデータを読み取り、ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御することができる。ハードウェア・デバイスドライバの呼び出し方法は、既存のハードウェア・デバイスドライバを呼び出し、ハードウェア・デバイスの動作を制御することか、或いは、リンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードする手順と、ハードウェア・デバイス動作制御用コマンドを取得し、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出す手順と、呼び出された機能実現関数を実行し、ハードウェア・デバイスに対応する動作を実行させる手順と、を含む。本発明の実施例に記載のオペレーティングシステムにおけるハードウェア・デバイス制御方法及びモジュールによれば、ハードウェア・デバイスが対応する動作を実行するように、ハードウェア・デバイスドライバによって、直接制御でき、また、バッファユニットに格納されているステータスデータをハードウェア・デバイスドライバによって、呼び出し、連続的にバッファユニットに格納されているステータスデータを直接読み取ることができるため、ハードウェア・デバイスでの動作に入ったら、ハードウェア・デバイスドライバの動作を遅延したり、中断したりすることを防止でき、データ転送の正確性を向上され、高速なデータ転送を実現できる。

前述の実施形態に記載のさまざまな方法の一部又は全部のステップについて、対応するハードウェアに機能させるためのプログラムによって実施され、また、当該プログラムはコンピュータの読み取り可能な記録媒体に格納されるものであり、当該記録媒体は、読み出し専用メモリ、ランダムアクセスメモリ、磁気ディスクや光学ディスクなどを含むことは、当業者であれば、理解されるべきである。

本発明について具体的な実施形態を参照して説明したが、開示された実施の形態に限定されるものではなく、本発明へのさまざまな変更、入れ替えは、本発明の精神または範囲から逸脱することなく、他の態様に適用されることは、当業者であれば、理解されるべきである。

Claims

ハードウェア・デバイスの動作を制御する機能実現関数を含むリンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードするステップと、ハードウェア・デバイス動作制御用コマンドを取得するステップと、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出すステップと、呼び出された機能実現関数を実行して、ハードウェア・デバイスが対応する動作を実行するように制御するステップと、を含むことを特徴とするオペレーティングシステムにおけるハードウェア・デバイス制御方法。
リンクライブラリをロードさせるコマンドを取得するステップは、さらに、
ハードウェア・デバイス動作制御用ステータスデータを取得するステップと、前記ステータスデータをバッファユニットに送信して格納するステップと、を含み、
また、呼び出された機能実現関数を実行した後、ハードウェア・デバイスドライバを呼び出し、バッファユニットに格納されている前記ステータスデータを前記ハードウェア・デバイスドライバによって読み取り、前記ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御するステップを含むこと、を特徴とする請求項1に記載の方法。
取得するハードウェア・デバイス動作制御用ステータスデータは、初期データを取得し初期データを符号化処理して得られる前記ステータスデータであることを特徴とする請求項２に記載の方法。
前記ハードウェア・デバイスは、発光素子、振動器、Bluetooth、カメラ、センサーまたはマイクであることを特徴とする請求項２に記載の方法。
前記ハードウェア・デバイスが発光素子である場合、前記ハードウェア・デバイスドライバは発光素子ドライバ、前記ステータスデータが時間データを表す配列である、前記ハードウェア・デバイスドライバは、前記ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御し、具体的には、発光素子ドライバは、前記配列におけるデータ要素の順に従い、発光素子のON/OFF時間を制御すること、を特徴とする請求項4に記載の方法。
前記ステータスデータは、時間データ、輝度データ又は強度データを表す配列であること、を特徴とする請求項２に記載の方法。
前記オペレーティングシステムはAndroidシステムである場合、前記Androidシステムのカーネルドライバ層に前記ハードウェア・デバイスのドライバを設置されており、前記ハードウェア・デバイスのドライバによって、呼び出される機能実現関数を実行して、ハードウェア・デバイスが対応する動作を実行することか、或いは、
前記オペレーティングシステムはIOSシステムである場合、前記IOSシステムのコアシステム層には、前記ハードウェア・デバイスのドライバを設置されており、前記ハードウェア・デバイスのドライバによって、呼び出される機能実現関数を実行させ、ハードウェア・デバイスが対応する動作を実行すること、を特徴とする請求項２に記載の方法。
前記オペレーティングシステムはAndroidシステムである場合、前記AndroidシステムのJNI層に対応するJNIインタフェース関数が定義されており、リンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードし、そして、前記インタフェース関数に従い、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出し、カーネルドライバ層におけるハードウェア・デバイスドライバが相当する機能実現関数を実行させることか、或いは、
前記オペレーティングシステムがIOSシステムである場合、LibSystemライブラリを使ってコアシステム層から提供されるインタフェース関数へアクセスし、リンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードし、そして、前記インタフェース関数に従い、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出し、コアシステムにおけるハードウェア・デバイスドライバが対応する機能実現関数を実行させること、を特徴とする請求項７に記載の方法。
JNI層には、機能実現関数をインスタンス化したアドレスが格納されていることを特徴とする請求項8に記載の方法。
前記オペレーティングシステムはAndroidシステムである場合、前記Androidシステムは、さらにハードウェア抽象化層を含み、前記Androidシステムのハードウェア抽象化層はカーネルドライバ層の上に実行されており、カーネルドライバ層のサポートを受け、Androidシステムのアプリケーションフレームワーク層及びJNI層にハードウェア・デバイス制御用インタフェースを提供し、或いは、
前記オペレーティングシステムはIOSシステムである場合、前記IOSシステムは、さらにコアサービス層を含むこと、を特徴とする請求項8に記載の方法。
ハードウェア・デバイスの動作を制御する機能実現関数を含むリンクライブラリをロードさせるコマンドを取得し、リンクライブラリをロードするロードユニットと、ハードウェア・デバイス動作制御用コマンドを取得する検出ユニットと、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出す呼び出しユニットと、呼び出された機能実現関数を実行し、ハードウェア・デバイスが対応する動作を実行するように制御する第2実行ユニットと、を含むことを特徴とするオペレーティングシステムにおけるハードウェア・デバイス制御モジュール。
ハードウェア・デバイス動作制御用ステータスデータを取得するステータスデータ取得ユニットと、前記ステータスデータを発送する伝送ユニットと、伝送ユニットから発送されるステータスデータを格納するバッファユニットと、
ハードウェア・デバイスドライバを呼び出し、バッファユニットに格納されているステータスデータを前記ハードウェア・デバイスドライバによって読み取り、前記ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御する第1実行ユニットとを含むオペレーティングシステムにおけるハードウェア・デバイス制御モジュールであって、第1実行ユニットによって、ハードウェア・デバイスドライバを呼び出す時、既存のハードウェア・デバイスドライバを呼び出して、ハードウェア・デバイスの動作を制御すること、を特徴とする請求項11に記載のモジュール。
前記ステータスデータ取得ユニットは、さらに、初期データを取得し初期データを符号化処理して前記ステータスデータを取得する符号化サブユニットを含むこと、を特徴とする請求項12に記載のモジュール。
前記ハードウェア・デバイスは、発光素子、振動器、Bluetooth、カメラ、センサーまたはマイクであることを特徴とする請求項12に記載のモジュール。
前記ハードウェア・デバイスが発光素子である場合、前記ハードウェア・デバイスドライバは発光素子ドライバである、配列である、前記第1実行ユニットはハードウェア・デバイスドライバを制御して、前記ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御場合、前記第1実行ユニットは発光素子ドライバを制御して、前記配列におけるデータ要素の順に従い、発光素子のON/OFF時間を制御すること、を特徴とする請求項14に記載のモジュール。
前記ステータスデータは、時間データ、輝度データ又は強度データを表す配列であることを特徴とする請求項12に記載のモジュール。
前記オペレーティングシステムはAndroidシステムである場合、前記Androidシステムのカーネルドライバ層に前記ハードウェア・デバイスのドライバを設置されており、前記第2実行ユニットは、前記ハードウェア・デバイスのドライバによって、呼び出される機能実現関数を実行するように制御し、ハードウェア・デバイスが対応する動作を実行するように制御し、或いは、
前記オペレーティングシステムはIOSシステムである場合、前記IOSシステムのコアシステム層には、前記ハードウェア・デバイスのドライバを設置されており、前記第2実行ユニットは、前記ハードウェア・デバイスのドライバによって、呼び出される機能実現関数を実行して、ハードウェア・デバイスが対応する動作を実行するように制御すること、を特徴とする請求項12に記載のモジュール。
前記オペレーティングシステムはAndroidシステムである場合、前記Androidシステムは、さらにJNI層を有し、前記JNI層に対応するJNIインタフェース関数が定義されており、呼び出しユニットは、前記インタフェース関数に従い、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出し、カーネルドライバ層におけるハードウェア・デバイスドライバが相当する機能実現関数を実行させることか、或いは、
前記オペレーティングシステムがIOSシステムである場合、LibSystemライブラリを使ってコアシステム層から提供されるインタフェース関数へアクセスし、呼び出しユニットは、前記インタフェース関数に従い、前記リンクライブラリから前記ハードウェア・デバイス動作制御用コマンドに対応する機能実現関数を呼び出し、カーネルドライバ層におけるハードウェア・デバイスドライバが対応する機能実現関数を実行させること、を特徴とする請求項17に記載のモジュール。
前記JNI層には、機能実現関数をインスタンス化したアドレスが格納されていることを特徴とする請求項18に記載のモジュール。
前記オペレーティングシステムはAndroidシステムである場合、前記Androidシステムは、さらにハードウェア抽象化層を含み、前記Androidシステムのハードウェア抽象化層はカーネルドライバ層の上に実行されており、カーネルドライバ層のサポートを受け、Androidシステムのアプリケーションフレームワーク層及びJNI層にハードウェア・デバイス制御用インタフェースを提供し、或いは、
前記オペレーティングシステムはIOSシステムである場合、前記IOSシステムは、さらにコアサービス層を含むこと、を特徴とする請求項18に記載のモジュール。
ハードウェア・デバイス動作制御用ステータスデータを取得するステップと、前記ステータスデータをバッファユニットに送信して格納するステップと、ハードウェア・デバイスドライバを呼び出し、また、バッファユニットに格納されているステータスデータを前記発光素子ドライバによって読み取り、前記ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御するステップと、を特徴とするオペレーティングシステムにおけるハードウェア・デバイス制御方法。
取得するハードウェア・デバイス動作制御用ステータスデータは、初期データを取得し初期データを符号化処理して得られる前記ステータスデータであることを特徴とする請求項21に記載の方法。
前記ハードウェア・デバイスは、発光素子、振動器、Bluetooth、カメラ、センサーまたはマイクであることを特徴とする請求項21に記載の方法。
前記ステータスデータは、時間データ、輝度データ又は強度データを表す配列であること、を特徴とする請求項21に記載の方法。
前記ハードウェア・デバイスが発光素子である場合、前記ハードウェア・デバイスドライバは発光素子ドライバ、前記ステータスデータが時間データを表す配列であるが、前記ハードウェア・デバイスドライバは、前記ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御し、具体的には、発光素子ドライバは、前記配列におけるデータ素子の並びの順に従い、発光素子のON/OFF時間を制御すること、を特徴とする請求項23に記載の方法。
アプリケーション層における、ハードウェア・デバイス動作制御用ステータスデータを取得するステータスデータ取得ユニットと、アプリケーション層における、前記ステータスデータを発送する伝送ユニットと、アプリケーション層から発送されてくるステータスデータを格納するバッファユニットと、アプリケーション層において、カーネルドライバ層にあるハードウェア・デバイスドライバを呼び出し、また、バッファユニットに格納されている前記ステータスデータをハードウェア・デバイスドライバによって読み取り、前記ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御する実行ユニットと、を含むことを特徴とするオペレーティングシステムにおけるハードウェア・デバイス制御モジュール。
前記ステータスデータ取得ユニットは、さらに、初期データを取得し初期データを符号化処理して前記ステータスデータを取得する符号化サブユニットを含むこと、を特徴とする請求項26に記載のモジュール。
前記ハードウェア・デバイスは、発光素子、振動器、Bluetooth、カメラ、センサーまたはマイクであることを特徴とする請求項26に記載の方法。
前記ステータスデータは、時間データ、輝度データ又は強度データを表す配列であること、を特徴とする請求項26に記載の方法。
前記ハードウェア・デバイスが発光素子である場合、前記ハードウェア・デバイスドライバは発光素子ドライバ、前記ステータスデータが時間データを表す配列であるが、前記ハードウェア・デバイスドライバは、前記ステータスデータに基づき、ハードウェア・デバイスの動作状態を制御し、つまり、発光素子ドライバは、前記配列におけるデータ素子の並びの順に従い、発光素子のON/OFF時間を制御すること、を特徴とする請求項28に記載の方法。