以下、本発明の好適な実施の形態について詳細に説明する。なお以下に説明する本実施形態は特許請求の範囲に記載された本発明の内容を不当に限定するものではなく、本実施形態で説明される構成の全てが本発明の解決手段として必須であるとは限らない。
1.システム構成例
図1は、本実施形態のドライバー300(表示システム600)を含むシステムの構成例である。図1に示したように、システムはドライバー300(ソースドライバー)と、走査ドライバー400(ゲートドライバー)と、表示コントローラー200と、処理装置100と、表示パネル500(電気光学パネル)と、を含む。表示パネル500は、ドライバー300により駆動される。ドライバー300は、表示コントローラー200接続される。図2で後述するように、ドライバー300は処理装置100と接続されてもよい。表示コントローラー200は、処理装置100と接続される。なお、図1ではドライバー300が1つである例を示したが、本実施形態に係るシステム(表示システム600)が複数のドライバー300を含んでもよい。複数のドライバー300を含む例については、図5、図6を用いて後述する。
図1のシステムが自動車等に搭載される場合、処理装置100はECU(Electronic Control Unit)である。或いは、上記システムが情報通信端末等の電子機器に搭載される場合、処理装置100はCPU(Central Processing Unit)やマイクロプロセッサー等のプロセッサーである。
図2に、本実施形態のドライバー300(データ線駆動回路、ソースドライバー)の構成例を示す。ドライバー300は、インターフェース部(インターフェース)310、制御部(制御回路)330、駆動回路340、電源回路350、検出回路360を含む。ドライバー300は例えば集積回路装置(IC)等で実現される。
インターフェース部310は、コマンドインターフェース部311と、表示インターフェース部313と、エラー出力部315とを含んでもよい。インターフェース部310は、表示コントローラー200(例えばMPUやCPU、ASIC等。広義には外部の処理装置)との間の通信を行う。コマンドインターフェース部311は、コマンド(制御信号、表示設定データ)を受信する。表示インターフェース部313は、画像データ(表示データ)を受信する。エラー出力部315(エラー出力回路)は、エラー検出部333でのエラー検出結果に基づく出力を行う。
画像データの通信方式としては、例えばLVDS(Low Voltage Differential Signal)方式やRGBシリアル方式、ディスプレイポート規格の伝送方式等を採用できる。またコマンドや制御信号の通信方式としては、I2C方式、3線又は4線のシリアル伝送方式等を採用できる。インターフェース部310は、これらの通信方式を実現する入出力バッファー回路や制御回路(例えばLVDS方式ではPLL回路等)で構成される。
制御部330は、駆動制御部331と、エラー検出部333と、レジスター部335を含む。レジスター部335(レジスター。広義には記憶部、メモリー)は、インターフェース部310を介して入力されたコマンドや制御信号を記憶する。また、コマンドや制御信号の通信は、例えば端子設定(各端子にハイレベル又はローレベルを入力することにより制御信号を入力する手法)により実現されてもよい。レジスター部335は、エラー検出部333のエラー検出での期待値(狭義にはCRC値の期待値)を記憶する。ここでの期待値は、後述するように固定値であってもよい。
エラー検出部333は、インターフェース部310が受信したデータのエラー検出(第1のエラー検出)を行う。以下では、エラー検出部333がCRC(巡回冗長検査、Cyclic Redundancy Check)によるエラー検出処理を行う例について説明する。なお、エラー検出の手法はCRCに限定されるものではなく、例えばチェックサム等の手法を採用することが可能である。エラー検出処理の具体例については後述する。
また、制御部330(駆動制御部331)は、表示コントローラー200から入力された画像データやコマンド(制御信号)等に基づいて、画像データの処理やタイミング制御、ドライバー300の各部の制御等を行う。画像データの処理では、例えば表示コントローラー200から転送されたデータから各色成分チャンネルの表示データを抽出する処理や、階調補正等の画像処理等を行う。タイミング制御では、表示コントローラー200から入力されたクロック信号や画像データに基づいてタイミング制御信号を生成し、そのタイミング制御信号により、表示パネル500の走査線(ゲート線)の駆動タイミング(選択タイミング)やデータ線の駆動タイミングを制御する。制御部330は、例えばゲートアレイ等のロジック回路で構成される。
駆動回路340は、階調電圧生成回路と、複数のD/A変換回路と、複数のアンプ回路と、を含む。階調電圧生成回路は複数の電圧を出力し、その各電圧は複数の階調値のいずれかに対応している。D/A変換回路は、階調電圧生成回路からの複数の電圧の中から、画像データに対応する電圧を選択する。アンプ回路は、D/A変換部からのデータ電圧に基づいてデータ電圧を出力する。例えば、表示パネル500の1本のデータ線(ソース線)に対応してD/A変換回路とアンプ回路が設けられており、そのデータ線をアンプ回路が駆動する。或いは、表示パネル500の2本のデータ線に対応してD/A変換回路とアンプ回路が設けられてもよく、その2本のデータ線をアンプ回路が逆極性で駆動することによりドット反転駆動を行ってもよい。階調電圧生成回路は例えばラダー抵抗等で構成され、D/A変換回路は例えばスイッチ回路等で構成され、アンプ回路は例えば演算増幅器やキャパシター等で構成される。
電源回路350は、システム電源から供給される電源電圧(例えば第1の電源電圧VDDと、第2の電源電圧VSS)に基づいて種々の電圧を生成し、その電圧をドライバー300の各部の電源電圧として供給する。例えば、駆動回路340には、アンプ回路の正及び負の各電源電圧(ドット反転駆動の正極駆動、負極駆動に用いる電源電圧)、階調電圧生成回路の電源電圧が供給される。また、制御部330には、ロジック用の電源電圧が供給される。また、電源回路350は、表示パネル500のコモン電圧を表示パネル500のコモン電極に供給する。また電源回路350は、ドライバー300の半導体基板(P型基板)の基板電圧を供給する。
電源回路350は、例えば昇圧回路(例えばチャージポンプ型の昇圧回路)やリニアレギュレーター(例えばLDO(Low Drop-Out)レギュレーター)、ディスチャージ用のスイッチ素子等で構成される。
検出回路360は、表示コントローラー200から供給される画像データ転送用のクロック信号が停止しているか否かを検出し、停止を検出した場合には検出信号をアクティブにする。そして、検出信号がアクティブになったことを受けて、制御部330が表示パネル500を表示オフ状態(例えば全黒表示)にする。
図2に示したように、本実施形態に係るドライバー300は、画像データを受信するインターフェース部310と、受信された画像データのエラー検出を行うエラー検出部333と、画像データに基づいて電気光学パネル(表示パネル500)を駆動する駆動回路340と、を含む。そして、ドライバー300は、エラー検出の結果を外部デバイスに出力する。
本実施形態の手法によれば、ドライバー300が受信した画像データに対するエラー検出を行うこと、及びエラー検出の結果を外部デバイスに出力することが可能になる。画像データのエラー検出を行うことで、表示パネル500に不適切な画像を表示すること等を抑止できる。車載システムであれば、警告等の表示等、ユーザーの安全に関わる非常に重要な情報の表示が想定されるところ、当該情報が誤って表示されることを抑止できる。車両の電気システムについてISO26262等の規格が制定されている。ISO26262では自動車に特有のリスクの重要度をASIL(Automotive Safety Integrity Level)によって分類している。近年の車両では、高解像度の電気光学パネルを用いて、警告情報を含む多様な情報を出力する。そのため、表示システムの重要度が高くなっており、不適切な情報の表示を抑止することは、車両の安全機能の観点からも重要となる。
その際、ドライバー300内でエラー検出を行うだけでなく、エラー検出の結果を外部デバイスに出力できる。出力対象となる外部デバイスは、図2の破線に示したように、表示コントローラー200であってもよいし、処理装置100であってもよいし、その両方であってもよい。つまり、ドライバー300での画像データのエラー検出結果を、外部デバイスでも容易に共有でき、当該外部デバイスでエラーに応じた処理(画像データの再送や表示の停止等)を行うことが可能になる。
エラー検出結果の外部デバイスへの出力は、インターフェース部310により行ってもよい。例えば、インターフェース部310がコマンドインターフェース部311や表示インターフェース部313を含む場合に、コマンド、制御信号、画像データの送受信と同様のインターフェースにより、エラー検出結果を出力する。エラー検出結果の出力に、コマンド等のインターフェースを用いることで、エラー出力用の端子を設ける必要がなく、端子数を抑制できる。
或いは、図2に示したように、ドライバー300は、エラー検出の結果を出力するエラー出力端子TEを含んでもよい。そしてエラー出力部315は、エラー検出結果に応じてアクティブ/非アクティブ(Hレベル/Lレベル)が決定される信号を、エラー出力端子TEに出力する。
このようにすれば、外部デバイスではエラー出力端子TEの信号レベルにより、ドライバー300でのエラー検出結果を取得できる。そのため、ドライバー300のレジスター部335の所与の領域にエラー検出結果を記憶しておき、外部デバイス側からレジスター部335の当該領域を読み出すような制御が不要となる。即ち、外部デバイスは、ドライバー300でのエラー検出結果を容易に取得することが可能になる。
走査ドライバー400は、走査線駆動電圧を表示パネル500の各走査線に出力し、その各走査線を駆動(選択)する。例えば表示パネル500はデュアルゲートの表示パネルである。デュアルゲートの表示パネルでは、水平走査方向の1本の表示ラインに対応して2本の走査線が設けられ、その2本の走査線の一方で選択される画素と他方で選択される画素(これらは1本の表示ラインで隣り合う2つの画素)が1本のデータ線を共有している。走査ドライバー400は、1水平走査期間において2本の走査線を時分割に駆動し、それに対応してドライバー300がデータ線に2つの画素のデータ電圧を時分割に出力する。なお、本発明の手法は、デュアルゲートの表示パネル500に限らず種々の表示パネルを駆動する場合に適用できる。
走査ドライバー400の構成の詳細な説明は省略するが、例えばドライバー300と同様に、制御部や電源回路を含んでもよい。或いは、ドライバー300の制御部330や電源回路350により、走査ドライバー400(駆動回路)の動作が行われてもよい。例えば、ドライバー300の電源回路350から、走査ドライバー400の正の電源電圧、及び負の電源電圧が供給されてもよい。
図3に表示コントローラー200(回路装置)の構成例を示す。表示コントローラー200は、インターフェース部210、220(インターフェース回路)、制御部230(制御回路)を含む。表示コントローラー200は、例えば集積回路装置(IC)により実現される。
インターフェース部210は、処理装置100と表示コントローラー200の間の通信を行う。例えばインターフェース部210は、処理装置100から制御部230へ送信される画像データや、タイミング制御信号(例えばクロック信号、垂直同期信号、水平同期信号、データイネーブル信号等)を受信する。通信方式は、インターフェース部310と同様の方式を採用できる。
また、処理装置100から制御部230が有するレジスター部235への書き込みが行われてもよい。その場合、インターフェース部210は、処理装置100からレジスター部235へ書き込まれるレジスター値を受信する。或いはインターフェース部210は、エラー出力部215(エラー判定情報出力回路)を含み、エラー出力部215が出力するエラー判定情報(エラー信号、エラー検出信号)を処理装置100に送信してもよい。
制御部230は、表示コントローラー200の各部の制御を行う。特に制御部230は、タイミング制御を行ってもよく、処理装置100からのタイミング制御信号に基づいて、表示コントローラー200の各部の制御や、ドライバー300へ送信する制御信号(例えばクロック信号、垂直同期信号、水平同期信号、データイネーブル信号等)の生成を行う。
また制御部230は、画像処理部231(画像処理回路)、エラー検出部233(エラー検出回路)、レジスター部235(レジスター、記憶部)を含んでもよい。画像処理部231は、処理装置100からの画像データ(表示データ)に対して種々の画像処理(例えば階調補正等)やデータ整形処理(ドライバー300のデータ受信方式に適合した送信データを生成する処理)を行う。
エラー検出部233は、処理装置100からの画像データに対してエラー検出(第2のエラー検出)を行う。エラー検出処理の具体例については後述する。
エラー出力部215は、エラー検出部233の出力(CRC値や、CRC値と期待値の比較結果信号)に基づいて、エラー判定情報を出力する。エラー判定情報の出力とは、例えば、処理装置100へのエラー信号の出力である。ここでのエラー信号は例えば割り込み要求信号(IRQ:Interrupt ReQuest)であってもよい。或いは、エラー信号は、エラーと判定されたことを単に知らせる(エラーと判定された場合にアクティブとなる)信号であってもよい。
表示コントローラー200のインターフェース部220は、ドライバー300(狭義には上述したインターフェース部310)の間の通信を行う。例えばインターフェース部220は、画像処理部231が出力する画像データをドライバー300へ送信したり、制御部230が出力する制御信号(タイミング制御信号)をドライバー300へ送信する。また、インターフェース部220は、ドライバー300の動作を制御する表示設定データ(例えばモード設定信号)をドライバー300へ送信してもよい。
上記の制御部230の画像処理部231、エラー検出部233、レジスター部235やエラー出力部215は、ロジック回路(例えば、アンド回路やオア回路、インバーター回路等のゲート回路や、フリップフロップ回路等の機能回路を配置したゲートアレイ)で構成される。画像処理部231、エラー検出部233、レジスター部235、エラー出力部215の各部は機能ブロックを表しており、ハードウェアとしては一体のロジック回路として構成されてもよいし、個別のロジック回路として構成されてもよい。
或いは、上記の各部は、ソフトウェアにより実現してもよい。即ち、本実施形態の表示コントローラー200(回路装置)等は、その処理の一部または大部分をプログラムにより実現してもよい。この場合には、CPU等のプロセッサーがプログラムを実行することで、本実施形態の表示コントローラー200等が実現される。具体的には、非一時的な情報記憶媒体に記憶されたプログラムが読み出され、読み出されたプログラムをCPU等のプロセッサーが実行する。ここで、情報記憶媒体(コンピューターにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(DVD、CD等)、HDD(ハードディスクドライブ)、或いはメモリー(カード型メモリー、ROM等)などにより実現できる。そして、CPU等のプロセッサーは、情報記憶媒体に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。即ち、情報記憶媒体には、本実施形態の各部としてコンピューター(操作部、処理部、記憶部、出力部を備える装置)を機能させるためのプログラム(各部の処理をコンピューターに実行させるためのプログラム)が記憶される。また、各部の機能をソフトウェアにより実現してもよい点は、ドライバー300についても同様である。
本実施形態の手法は、処理装置100から第1の画像データを受信して、表示タイミング制御を行う表示コントローラー200と、表示コントローラー200によって制御され、表示コントローラーからの第2の画像データを受信して電気光学パネル(表示パネル500)を駆動するドライバー300と、を含む表示システム600に適用できる。そして図2及び図3を用いて上述したように、表示コントローラー200は、第1の画像データについての第1のエラー検出を行い、ドライバー300は、第2の画像データについての第2のエラー検出を行う。なお、表示コントローラー200では、第1の画像データに対して、データ形式を変換したり、種々の画像処理を行うことが可能である。よって、第2の画像データとは、表示コントローラー200(画像処理部231)において、第1の画像データに対する画像処理が行われた後に、ドライバー300へ送信されたデータを表す。
このようにすれば、図1のように表示コントローラー200と、ドライバー300とが別体(別IC)として設けられる場合において、それぞれで画像データのエラー検出を行うことが可能になる。上述したように、処理装置100と表示コントローラー200の間、表示コントローラー200とドライバー300の間ではインターフェースを介した画像データの通信が行われるため、各通信でエラーが発生するおそれがある。その点、第1のエラー検出と第2のエラー検出の両方を行うことで、一方のみを行う場合等に比べてエラーの検出精度を高くでき、不適切な画像データが表示パネル500に表示されることを抑止できる。
図2、図3に示したように、表示コントローラー200は、処理装置100から第1の画像データを受信する第1のインターフェース部(インターフェース部210)と、第1の画像データについての第1のエラー検出を行う第1のエラー検出部(エラー検出部233)を含む。また、ドライバー300は、表示コントローラー200から第2の画像データを受信する第2のインターフェース部(インターフェース部310)と、第2の画像データについての第2のエラー検出を行う第2のエラー検出部(エラー検出部333)を含む。これらの構成を有することで、表示コントローラー200及びドライバー300は、それぞれ画像データのエラー検出を行うことが可能である。
またこの場合も、エラー検出結果を外部デバイスに対して出力することは妨げられない。例えば、表示コントローラー200は、第1のエラー検出の結果を処理装置100に出力し、ドライバー300は、第2のエラー検出の結果を表示コントローラー200又は処理装置100に出力する。
このようにすれば、第1,第2のエラー検出の結果を他のデバイスに対して出力できるため、多様なエラー対応処理(例外処理)を行うこと等が可能になる。
2.エラー検出の具体例
本実施形態におけるエラー検出とは、具体的には第1のデバイスが第2のデバイスに送信する画像データと、第2のデバイスが実際に受信した画像データとが、一致しているか否かをチェックすること(通信エラーの検出)である。エラー検出にCRCを用いる場合、第2のデバイスは、第1のデバイスが第2のデバイスに送信しようとする画像データから演算されるCRC値を、期待値として取得しておく。第2のデバイスでのエラー検出は、第2のデバイスが実際に受信した画像データから演算されたCRC値(演算値)と、期待値とが一致するか否かを判定する処理となる。具体的な手法は種々考えられるが、例えば各画素に対してR,G,B各nビット(例えばn=8)のデータが割り当てられる場合、期待値としてR画素値に基づく期待値、B画素値に基づく期待値、B画素値に基づく期待値の3つを取得しておき、CRC値の演算、及び期待値との一致判定は、RGBの各色を対象として行ってもよい。
上記のエラー検出がドライバー300のエラー検出部333で行われるエラー検出(第2のエラー検出)であれば、上記第1のデバイスは表示コントローラー200(又は処理装置100)であり、上記第2のデバイスはドライバー300である。また上記のエラー検出が表示コントローラー200のエラー検出部233で行われるエラー検出(第1のエラー検出)であれば、上記第1のデバイスは処理装置100であり、上記第2のデバイスは表示コントローラー200である。
以下、第1のエラー検出及び第2のエラー検出の具体例について説明する。ただし、以下で説明する処理はエラー検出の一例であり、種々の変形実施が可能である。例えば、第1のエラー検出として説明した処理を第2のエラー検出で行ってもよいし、第2のエラー検出として説明した処理を第1のエラー検出で行ってもよい。また、複数のエラー検出を組み合わせてもよい。
2.1 ドライバーでのエラー検出の例
まずドライバー300で行われるエラー検出(第2のエラー検出)の具体例について説明する。なお、ドライバー300では、外部デバイスから取得した画像データに対して、何らかの画像処理(例えばガンマ補正等)を行い、処理後のデータに基づいて表示パネル500を駆動してもよい。この場合、エラー検出は画像処理前の画像データに対して行うとよい。エラー検出に用いる情報(期待値、或いは期待値を固定にするためのダミーデータ)は外部デバイスから送信されるものであり、当該情報は外部デバイスからの送信時の画像データのエラー検出を想定した値である。つまり、エラー検出の対象とするデータは、画像処理前のデータとすることが自然である。
<固定期待値>
上述したように、エラー検出ではエラー検出の期待値(CRC値の期待値)が必要となる。CRC値は画像データに応じて変化するため、期待値はフレーム毎に変化することが通常である。よって表示コントローラー200は、各フレームにおいて、画像データに基づき期待値を演算し、演算した期待値を画像データとともにドライバー300に送信してもよい。
しかし、エラー(通信エラー)は、画像データだけでなく期待値についても発生するおそれがある。そのため、各フレームでドライバー300が受信する期待値の信頼性は充分とは言えず、期待値にエラーが生じている場合、ドライバー300でのエラー検出を適切に行うことができない。
よって本実施形態では、表示コントローラー200は、エラー検出の演算値が固定値になるようなダミーデータが付加された画像データ(第2の画像データ)を、ドライバー300に出力する。
この場合、ドライバー300のインターフェース部310は、エラー検出の演算値が固定値になるようなダミーデータが付加された画像データを外部デバイス(表示コントローラー200)から受信し、エラー検出部333は、エラー検出の演算値が、上記固定値となるか否かを検出することで、エラー検出を行う。
このようにすれば、ドライバー300は、1回固定値を取得できれば、当該固定値を複数のフレームに渡って継続して利用できる。期待値を通信することによるエラーの発生を抑止できるため、精度の高いエラー検出が可能になる。この固定値は、例えばコマンドインターフェース部311を介して、処理装置100から受信してもよい。期待値をどの値に固定するかは設計段階で既知となるため、ドライバー300は、当該固定値を制御パラメーターとして処理装置100から取得することが可能である。ただし、固定値を表示インターフェース部313を介して表示コントローラー200から受信したり、ドライバー300の製造時にレジスター部325に記憶しておく等の変形実施も妨げられない。
ダミーデータを生成する手法は種々考えられる。一例としては以下の(1)~(3)の処理を行えばよい。なお、ここではCRCの演算値がqビットである(生成多項式がq+1ビットである)ことを想定している。
(1)エラー検出対象となるpビットの画像データの後にq個の‘0’からなるビット列を付加して、p+qビットのビット列Aを生成する
(2)上記のビット列Aを対象として、qビットのCRC値Bを求める
(3)qビットのCRC値Bをダミーデータとする(ビット列AにCRC値Bを加算したp+qビットのビット列Cを画像データ+ダミーデータとする)
CRCの一般的な演算では、エラー検出対象のビット列を、生成多項式を表すビット列を用いて除算(厳密には繰り上がり繰り下がりのない除算、modulo2の演算)した余りをCRC値とする。つまり、上記(2)で求められたCRC値(余り)を、元のビット列Aに加算することで、加算後のビット列Cの余りは必ず0になる。これにより、ダミーデータが付加された画像データ(ビット列C)を対象としたエラー検出の期待値を0に固定できる。
なお、ここでは固定値を0としたがこれには限定されず、qビットで表現可能な任意の数に拡張可能である。また、ここではダミーデータをCRC値の長さ(=生成多項式の長さ-1)と同じビット数とした。例えば、9ビットの生成多項式を用いるCRC-8であればダミーデータは8ビットであり、17ビットの生成多項式を用いるCRC-16であればダミーデータは16ビットである。ただし、エラー検出の演算値を固定するためのデータは少なくともCRC値と同じ長さであればよく、CRC値よりも長いビット列のデータをダミーデータとして用いることは妨げられない。例えば、ダミーデータの長さを、インターフェース部310における転送単位や、ドライバー300(制御部330)での処理単位に基づいて設定してもよい。
なお、本実施形態の手法は、画像データをドライバー300に送信するインターフェース部220と、制御部230と、を含み、制御部230は、ドライバー300での画像データのエラー検出において、演算値が固定値になるようなダミーデータを画像データに付加する制御を行い、インターフェース部220は、ダミーデータが付加された画像データを、ドライバー300に送信する表示コントローラー200に適用することが可能である。
<警告情報表示領域の画像データを対象>
本実施形態のエラー検出は、画像データ全体を対象とすることは妨げられない。言い換えれば、エラー検出部333は、電気光学パネル(表示パネル500)の表示領域全体の画像データについてエラー検出を行ってもよい。ただし電気光学パネルでは、所与の領域に表示される情報と、他の領域の表示される情報とで、重要度に差がある場合も多い。
例えば、システム(電子機器、移動体)に異常が発生した場合に、当該異常をユーザーに対して警告するための警告情報を、電気光学パネルの所与の領域(以下、警告情報表示領域)に表示してもよい。この場合、電気光学パネルの警告情報表示領域に表示される情報は、他の領域で表示される情報に比べて重要度が高い。即ち、警告情報表示領域の画像データは、他の領域の画像データに比べてエラー検出の必要性が高い。エラーを放置した場合、本来表示すべき警告情報とは異なる情報を表示してしまうためである。
よってエラー検出部333は、電気光学パネルの表示領域のうち、警告情報表示領域の画像データについてのエラー検出を行ってもよい。このようにすれば、重要な領域を優先してエラー検出を行うことが可能になる。さらに、警告情報表示領域以外の領域の画像データについては、エラー検出の頻度を下げたり、エラー検出を省略することが可能である。つまり、エラー検出の対象とする表示領域(画像データのデータ量)を抑えることで処理負荷を軽減することが可能になる。
なお、エラー検出を警告情報表示領域に限定した場合であっても、表示パネル500での画像の表示のためには、電気光学パネルの表示領域全体に対応する画像データが必要となる。つまり警告情報表示領域のエラー検出を行う場合、当該警告情報表示領域に対応する画像データを特定する情報が必要となる。よって、インターフェース部310は、外部デバイスから警告情報表示領域を特定する位置情報を取得する。この位置情報は、例えば矩形の警告情報表示領域の左上の座標値、及び右下の座標値により表される情報である。
また表示コントローラー200は、警告情報表示領域の画像データに対して、エラー検出の演算値が固定値となるようなダミーデータを付加する。このようにすれば、ドライバー300のエラー検出部333は、エラー検出の対象となる警告情報表示領域の画像データ、及び演算値の期待値を特定できるため、警告情報表示領域を対象としたエラー検出を適切に実行できる。
<上位nビット対象>
エラー検出の対象とする画像データのデータ量を抑えることを考えた場合、領域を限定する手法とは異なる手法を用いてもよい。例えば、エラー検出部333は、画像データのnビットのうち、上位のmビットについてのエラー検出を行い、下位のn-mビットについてのエラー検出を行わなくてもよい。
ここでの上位下位とは、所与の1画素に着目した場合の、RGBの各画素値のMSB側、LSB側を表す。例えば1つの画素に対して、各8ビットのR画素値、G画素値、B画素値が割り当てられる場合、n=8であり、上位のm(1以上7以下の整数)ビットとは、8ビットのR画素値のうちのMSB側のmビット(最上位ビットからmビット)、B画素値のうちのMSB側のmビット、G画素値のうちのMSB側のmビットを表す。
上位側(MSB側)のビットの値は、各画素値に対する寄与度が大きく、下位側(LSB側)のビットの値は寄与度が小さい。上記8ビットの例であれば、最上位ビットにエラーが発生すれば、画素値は128だけ変動してしまうが、最下位ビットにエラーが発生しても、画素値は1しか変動しない。そして、画素値がわずかにしか変動しない場合、対応する画素の色味の変動も小さい。つまり、下位側のビットにエラーが発生したとしても、ユーザーの認識に対する影響が小さい。
よって本実施形態では、エラー検出の対象を上位mビットに限定してもよい。エラー検出の対象となる領域(電気光学パネルの表示領域全体であってもよいし、上述したように警告情報表示領域であってもよい)が、縦r画素、横s画素の合計r×s画素である場合、全ビットを対象とすると、r×s×nビットに対するエラー検出を、RGBの各色について実行する必要がある。その点、上位mビットに限定することで、エラー検出はr×s×m(<r×s×n)ビットを対象とすればよい。即ち、エラー検出の対象となるデータ量を削減し、エラー検出の処理負荷を軽減することが可能になる。この際、上位側か下位側かを考慮するため、重要度が高いビットを適切にエラー検出対象としつつ、重要度が低いビットをエラー検出から除外することが可能である。
<表示設定データのエラー検出>
以上では、エラー検出の対象が表示インターフェース部313を介して取得される画像データである例について説明した。しかし、図2に示したように、インターフェース部310は、画像データを受信する表示インターフェース部313の他に、コマンドインターフェース部311を含んでもよい。そしてコマンドインターフェース部311は、外部デバイス(処理装置100、又は表示コントローラー200)から、表示設定データを受信する。ここでの表示設定データは、ドライバー300での表示設定に用いられるデータ(パラメーター)であり、例えば表示タイミングの設定を行うためのデータ等を含む。
この場合、表示設定データについてもインターフェース部310を介した通信により取得されるため、エラー(通信エラー)が発生する可能性がある。よってエラー検出部333は、コマンドインターフェース部311により受信した表示設定データのエラー検出を行ってもよい。
このようにすれば、エラー検出の対象を画像データ以外にも拡張することが可能になる。表示設定データのエラー検出を行うことで、不適切な設定データに基づいて表示制御が行われることを抑止できる。例えば、表示タイミングが本来のタイミングからずれてしまうことを抑止可能となる。
<エラー出力部によるカウント>
エラー出力部315は、エラー検出部333での検出結果に基づいてエラー検出結果を出力する。エラー検出部333での検出結果とは、狭義にはエラー検出の演算値(CRC値)が期待値と一致したか否かを表す情報である。ここでエラー出力部315は、エラー検出部333で演算値と期待値が不一致と判定された場合(以下、CRCエラーとも表記する)に、エラーを出力することは妨げられない。
しかし、通信規格上、ある程度の頻度でのビットエラーの発生は許容されている。そして、エラー検出の対象となる画像データは、例えば画素数×24ビットのビット列となるため、エラー検出領域を警告情報表示領域に限定したとしても、ある程度のデータ量となる。結果として、CRCエラー自体は数十フレームに1回程度の頻度で発生してしまい、1回のCRCエラーにより、エラー出力部315がエラーを出力すると、エラーに対する感度が過剰に高くなるおそれがある。
よってエラー出力部315において、エラー検出部333でCRCエラーが検出された回数をカウントし、カウント値が所定の閾値以上となった場合に、エラーを出力してもよい。言い換えれば、エラー出力部315は、CRCエラーが1回発生した場合に即座にエラーにするのではなく、所定回数発生した場合にエラーを出力する。ここでのカウント値は、エラーの累積発生回数であってもよいし、エラーの連続発生回数であってもよい。
2.2 表示コントローラーでのエラー検出の例
次に表示コントローラー200で行われるエラー検出(第1のエラー検出)の具体例について説明する。なお、表示コントローラー200でも、処理装置100から取得した画像データに対して、何らかの画像処理を行うことが可能であるが、エラー検出は、画像処理前の画像データを対象とするとよい。
<エラー検出領域の柔軟な設定>
エラー検出の対象とする領域は、表示パネル500の表示領域全体、又は警告情報表示領域のいずれかに限定されるものではなく、より柔軟に設定することが可能である。図4の例では、表示パネル500の表示領域に対応する画像(IMG)に対して、第1~第4のエラー検出領域AR1~AR4が設定される。エラー検出領域AR1~AR4の特定には位置情報が用いられる。ここでの位置情報は、例えば各エラー検出領域の始点SP1~SP4と終点EP1~EP4である。例えば画像IMGの左上の画素の座標を原点として、水平走査方向の座標xと垂直走査方向の座標yを定義する。座標x、yが共に最も小さい画素が始点であり、座標x、yが共に最も大きい画素が終点である。
なお、エラー検出領域の数は4つに限定されず、1又は複数の任意のエラー検出領域を設定できる。また図4では、エラー検出領域AR1~AR4が互いに重ならない領域となっているが、これに限定されず、一部が重なる領域となってもよい。またエラー検出領域を指定する位置情報は始点と終点に限定されず、領域を確定できる情報であればよい。例えば、エラー検出領域の始点の座標と横幅(水平走査方向の画素数)と縦幅(垂直走査方向の画素数)であってもよい。
エラー検出部233では、エラー検出領域を特定する位置情報を取得し、当該位置情報により特定されるエラー検出領域を対象としてエラー検出を行う。位置情報は、レジスター部235に記憶されていてもよい。この場合、エラー検出部233は、レジスター部235から位置情報を読み出し、画像データのうちの当該位置情報に対応する画素のデータを対象として、エラー検出を行う。位置情報は、インターフェース部210を介して処理装置100から取得される。図3には不図示であるが、表示コントローラー200のインターフェース部210は、表示インターフェース部と、コマンドインターフェース部とを含んでもよい。そして位置情報の取得は、表示インターフェース部を介して行われてもよいし、コマンドインターフェース部を介して行われてもよい。
レジスター部235に記憶される位置情報は、固定値であってもよい。この場合、エラー検出部233は、図4に示したエラー検出領域AR1~AR4を対象としたエラー検出を複数フレームに渡って継続してもよい。或いは、第1のフレームでは第1のエラー検出領域AR1を対象としたエラー検出を行い、第2のフレームでは第2のエラー検出領域AR2を対象としたエラー検出を行うといった変形実施も可能である。即ち、レジスター部235に複数の位置情報が記憶される場合、当該複数の位置情報を用いる順序や組み合わせについては種々の変形実施が可能である。
また、レジスター部235に記憶される位置情報は適宜更新されてもよい。例えば、フレーム毎に位置情報を更新することで、より柔軟なエラー検出領域の設定が可能になる。ただし、レジスター部235に記憶される位置情報を頻繁に更新する場合、レジスターの書き込み、読み出し処理が高頻度で行われるため処理負荷が大きくなってしまう。
この点を考慮して、画像データに位置情報を含めてもよい。インターフェース部210(表示インターフェース部)は、画像データと、エラー検出領域の位置情報と、を含むデータを受信し、エラー検出部233は、位置情報により特定されるエラー検出領域の画像データに基づいてエラー検出を行う。位置情報は、水平方向の1ラインの表示の後、次の1ラインの表示を開始するまでの期間である水平帰線期間、又は、1フレーム分の画像の表示が行われた後、次のフレームの画像の表示を開始するまでの期間である垂直帰線期間において送信されてもよい。或いは、画像データ(表示用画像データ)の前後、或いは途中に、位置情報を追加してもよい。このようにすれば、画像データを受信するインターフェース部210(表示インターフェース部)を用いて、フレームごとに位置情報を受信できるため、エラー検出領域の柔軟な設定が可能である。
なお、表示コントローラー200がエラー検出(第1のエラー検出)を行う画像データ(第1の画像データ)の電気光学パネルでの表示領域と、ドライバー300がエラー検出(第2のエラー検出)を行う画像データ(第2の画像データ)の電気光学パネルでの表示領域と、が異なってもよい。
このようにすれば、表示コントローラー200とドライバー300とでエラー検出の対象となる領域を柔軟に設定可能となる。例えば、上記のようにドライバー300では警告情報表示領域を対象としたエラー検出を行い、表示コントローラー200では第1~第4のエラー検出領域AR1~AR4を対象としたエラー検出を行ってもよい。ドライバー300でのエラー検出の対象となる領域数は、表示コントローラー200でのエラー検出領域の対象となる領域数よりも少ないことが好ましい。このようにすれば、ドライバー300でエラー検出の対象とするデータ量は、表示コントローラー200でエラー検出の対象とするデータ量よりも少なくなるため、ドライバー300での演算負荷を軽減することが可能になる。例えば、ドライバー300でのエラー検出は、表示コントローラー200でエラー検出の対象となる領域から選択された一部の領域を対象として実行される。具体的には、ドライバー300のエラー検出部333は、エラー検出領域AR1~AR4から選択された1つ~3つの領域を対象として、エラー検出を行う。
その他、エラー検出の対象となる領域は、表示コントローラー200とドライバー300とで種々の設定が可能である。もちろん、表示コントローラー200とドライバー300で同じ領域をエラー検出の対象とすることも妨げられない。
<期待値を外部デバイスから送信>
第1のエラー検出では、エラー検出の期待値を固定値とする例を説明した。しかし、期待値を固定せずに、画像データに合わせて毎フレーム変動する値としてもよい。この場合、処理装置100では、送信対象である画像データに基づいて、エラー検出の期待値(CRC値)を演算する。期待値の演算は、各エラー検出領域を対象として行われ、図4の例であればAR1~AR4に対応する期待値が演算される。1つのエラー検出領域について、R,G,Bの3つの期待値を用いる例であれば、AR1~AR4に対応する期待値として12個の期待値が演算されることになる。
表示コントローラー200は、処理装置100から、エラー検出の演算値の期待値を受信し、エラー検出の演算値が、期待値となるか否かを検出することで、エラー検出(第1のエラー検出)を行う。具体的には、期待値の受信はインターフェース部210を介して行われ、エラー検出はエラー検出部233で行われる。上記のようにエラー検出領域が設定される例であれば、エラー検出部233は、画像データと、位置情報と、期待値とに基づいてエラー検出を行えばよい。
期待値の取得が、表示インターフェース部を介して行われてもよいし、コマンドインターフェース部を介して行われてもよい点は、位置情報と同様である。また、期待値がレジスター部235に記憶されてもよいし、表示インターフェース部を介して取得した値を直接利用してもよい点についても、位置情報と同様である。
3.複数のドライバーを用いる例
図1では、ドライバー300(ソースドライバー)が1つである例を図示した。しかし、複数のドライバー300が設けられることも多い。例えば、ドライバー300のICサイズや許容端子ピッチの制限により、1つのドライバー300では、表示パネル500の全てのデータ線を駆動できない場合等が考えられる。特に、表示パネル500の高精細化が進むことでデータ線の数が増大した場合、複数のドライバー300が必要となる可能性が増す。
図5は、複数のドライバー300を用いる場合の、表示パネル500、ドライバー300(ソースドライバー)、走査ドライバー400の接続例である。図5の例では、表示パネルは4×N本のデータ線を有する。そしてN本のデータ線を駆動するドライバー300を4つ(ドライバー300-1~300-4)設け、当該4つのドライバー300により表示パネル500の4×N本のデータ線を駆動する。なお、図5ではドライバー300が4つの例を示したが、ドライバー300は2つ或いは3つであってもよいし、5つ以上であってもよい。
また、図5の例では表示パネル2×M本の走査線を有する。そしてM本の走査線の走査を行う走査ドライバー400を2つ(走査ドライバー400-1~400-2)設け、当該2つの走査ドライバー400により表示パネル500の2×M本の走査線の走査を行う。なお、走査ドライバー400の数についても、種々の変形実施が可能である。
複数のドライバー300の各ドライバー300-1~300-4は、表示コントローラー200(又は処理装置100)からのコマンド及び画像データに基づいて、データ線にデータ信号を供給する。ここでのデータ信号とは、画像データに基づいて生成される信号(狭義にはアナログ電圧)である。ただし、表示制御信号(表示タイミング信号、カスケード信号)は、ドライバー300-1で生成され、ドライバー300-1からドライバー300-2~300-4に供給される。また、走査ドライバー400-1、400-2で用いられる表示制御信号も、ドライバー300-1から供給される。
表示制御信号を生成するドライバー300(図5の例ではドライバー300-1)をマスターとよび、他のドライバー300で生成された表示制御信号の供給を受けるドライバー300(図5ではドライバー300-2~300-4)をスレーブと呼ぶ。また、ドライバー300が内蔵電源(電源回路350)を有する場合、当該内蔵電源がオンのドライバー300がマスターであり、オフのドライバー300がスレーブである。各ドライバー300は、例えば所与の端子に入力される信号に基づいてマスター/スレーブを設定可能である。走査ドライバー400についても、走査ドライバー400-1をマスターに設定し、走査ドライバー400-2をスレーブに設定すればよい。
複数のドライバー300が設けられる場合、各ドライバー300において上述したエラー検出(第2のエラー検出)を行うことが可能である。この場合、各ドライバーからそれぞれ外部デバイスに対してエラー検出結果を送信してもよい。しかし、上述したようにエラー出力端子TEを用いてエラー検出結果を出力する場合、エラー検出結果を受信する外部デバイス側でドライバー300の数に対応する数のエラー入力端子が必要となってしまう。
よって、ドライバー300がマスターに設定された場合、インターフェース部310は、スレーブに設定された他のドライバーのエラー検出の結果を、外部デバイスに出力してもよい。言い換えれば、表示システム600は、図1等に示したドライバー300と異なる第2のドライバーを含み、ドライバー300がマスターに設定され、第2のドライバーがスレーブに設定された場合に、マスターに設定されたドライバー300は、スレーブに設定された第2のドライバーのエラー検出(第2のエラー検出)の結果を出力する。
このようにすれば、エラー検出結果の出力元をマスターに設定されたドライバー300に統一することができ、外部デバイスでのエラー検出結果の取得が容易となる。上記エラー出力端子TEを用いる例であれば、ドライバー300の数によらず、外部デバイスには1つのエラー入力端子を設ければよいことになる。
図6は、マスターに設定されたドライバー300により、スレーブに設定されたドライバー300のエラー検出結果を出力する場合の接続例である。図6ではドライバー300-1がマスターに設定され、300-2~300-4がスレーブに設定されている。なお、ドライバー300の構成については図2を用いて上述したため、図6では各ドライバーの構成を簡略化している。また、ドライバー300の数は4つに限定されない。その他、複数のドライバー300を含む構成は図6に限定されず、これらの一部の構成要素を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。
図6に示すように、各ドライバー300(300-1~300-4)は、エラー検出部333(333-1~333-4)とエラー出力部315(315-1~315-4)を含む。ここでエラー出力部315は、入力信号の論理和を出力するOR回路であってもよい。エラー出力部315は、端子TI(TI-1~TI-4)に入力される信号と、自身のエラー検出部333の出力の論理和をエラー出力端子TE(TE-1~TE-4)に出力する。なお、以下ではエラー検出部333は、演算値と期待値が不一致の場合(CRCエラーが検出された場合)にHレベルの信号を出力し、一致した場合にLレベルの信号を出力する例について説明する。
スレーブに設定されたドライバー300-4の端子TI-4には、低電位側基準電圧(狭義にはグラウンド)が供給される。そのため、エラー出力部315-4は、エラー検出部333-4の出力がHレベルの場合にHレベルの信号を出力し、Lレベルの場合にLレベルの信号を出力する。即ち、エラー出力端子TE-4の出力は、ドライバー300-4でのエラー検出結果を表す信号となる。
スレーブに設定されたドライバー300-3の端子TI-3は、ドライバー300-4のエラー出力端子TE-4と接続される。そのため、エラー出力部315-3は、エラー検出部333-3、333-4のエラー検出の結果の論理和を出力する。即ち、エラー検出部333-3とエラー検出部333-4の少なくとも一方の出力がHレベルの場合にHレベルの信号を出力し、両方がLレベルの場合にLレベルの信号を出力する。
スレーブに設定されたドライバー300-2の端子TI-2は、ドライバー300-3のエラー出力端子TE-3と接続される。そのため、エラー出力部315-2は、エラー検出部333-2~333-4のエラー検出の結果の論理和を出力する。即ち、エラー検出部333-2~333-4の少なくとも1つの出力がHレベルの場合にHレベルの信号を出力し、全てがLレベルの場合にLレベルの信号を出力する。
マスターに設定されたドライバー300-1の端子TI-1は、ドライバー300-2のエラー出力端子TE-2と接続される。そのため、エラー出力部315-1は、エラー検出部333-1~333-4のエラー検出の結果の論理和を出力する。即ち、エラー検出部333-1~333-4の少なくとも1つの出力がHレベルの場合にHレベルの信号を出力し、全てがLレベルの場合にLレベルの信号を出力する。マスターに設定されたドライバー300-1のエラー出力端子TE-1は、外部デバイスに接続される。
このようにすれば、マスターに設定されたドライバー300(300-1)から、スレーブに設定されたドライバー300(300-2~300-4)のエラー検出結果を出力することが可能になる。
なお、図6ではエラー出力部315が単純なOR回路であるものとしたが、エラー出力部315は単純なOR回路には限定されない。例えば上述したように、エラー出力部315においてCRCエラーの回数をカウントしてもよい。その場合、エラー出力部315は、不図示のカウンター等を含み、カウント値に基づきHレベル/Lレベルが決定される信号と、端子TIから入力される信号の論理和を出力すればよい。
また、ドライバー300ごとにエラー検出の有効無効を設定してもよく、その場合、各ドライバー300は、エラー検出の有効無効の設定端子を含んでもよい。無効に設定されたドライバー300では、エラー検出部333が非アクティブとなり、エラー検出部333からの出力がLレベル(広義にはエラー無しを表す信号)に固定される。
また、図1や図5に示したように、表示システム600は走査ドライバー400(ゲートドライバー)を含む。走査ドライバー400では画像データを用いる必要がないため、画像データに対するエラー検出は不要である。ただし、走査ドライバー400でもエラー検出が行われる場合は考えられる。例えば、走査ドライバー400は、走査線を順次スキャンしていき、最後のスキャンが終わったら(1フレーム分の画像の表示制御が終了したら)信号を出力するものとしてもよい。そして走査ドライバー400は、当該信号がない場合にエラーを出力する。このようにすれば、表示制御が適切に行われているか否かのエラー検出が可能になる。
走査ドライバー400がエラー検出結果を出力可能である場合、当該走査ドライバー400から外部デバイスへの出力を行うものとすると、外部デバイスの端子数が増えてしまう。
よって、ドライバー300は、走査ドライバー400から、当該走査ドライバー400でのエラー検出結果を受信し、受信したエラー検出結果を出力してもよい。より具体的には、ドライバー300のインターフェース部310は、電気光学パネルの走査線を駆動する走査ドライバーのエラー検出結果を、外部デバイスに出力する。ドライバー300が複数ある場合、走査ドライバー400のエラー検出結果を出力するドライバーとは、マスターに設定されたドライバー300である。なお、図5に示したように走査ドライバー400が複数設けられる場合、例えばマスターである走査ドライバー400-1が、スレーブである走査ドライバー400-2でのエラー検出結果を受信し、受信したエラー検出結果と自身のエラー検出結果をドライバー300(マスターであるドライバー300-1)に出力する。
このようにすれば、走査ドライバー400のエラー検出結果についても、ドライバー300に集約して出力することが可能になる。
4.エラー検出等の感度(レート)設定
以上のように、ドライバー300でのエラー検出(第2のエラー検出)と、表示コントローラー200でのエラー検出(第1のエラー検出)を行ってもよい。本実施形態では、この2つのエラー検出の間に差異を設けてもよい。
具体的には、表示コントローラー200での第1のエラー検出の感度(エラーの検出のされやすさ)と、ドライバー300での第2のエラー検出の感度とが異なってもよい。エラー検出の感度は種々の手法により設定可能である。例えば、エラー検出を行うレート(頻度)を調整してもよい。第1のエラー検出をf1(f1は1以上の整数)フレームに1回行い、第2のエラー検出をf2(f2はf1と異なる正の整数)フレームに1回行う。f1<f2であれば、第1のエラー検出が第2のエラー検出に比べて高頻度で行われることになり、第1のエラー検出の感度が第2のエラー検出の感度より高くなる。
或いは、エラー出力部215及びエラー出力部315でCRCエラーの回数をカウントする場合、カウント値の閾値を変更してもよい。例えば、表示コントローラー200のエラー出力部215では、カウント値がC1以上になった場合にエラーを出力し、ドライバー300のエラー出力部315では、カウント値がC2(C2≠C1)以上になった場合にエラーを出力する。閾値が小さいほど、CRCエラーの検出回数が少なくてもエラーが出力されるため、エラー検出の感度が高くなる。C1<C2であれば、第1のエラー検出では、許容されるCRCエラーの回数が少なくなるため、第1のエラー検出の感度が第2のエラー検出の感度より高くなる。
このようにすれば、ドライバー300と表示コントローラー200とで、それぞれエラー検出の感度を柔軟に設定することが可能になる。特に本実施形態では、f1<f2及びC1<C2の少なくとも一方としてもよい。言い換えれば、第1のエラー検出の感度を第2のエラー検出の感度に比べて高くするとよい。処理装置100と表示コントローラー200の間の通信は、表示コントローラー200とドライバー300の間の通信に比べて高速であり、エラーが発生しやすい。つまり、エラーが発生しやすい表示コントローラー200の受信データについては感度を高くし、エラーが発生しにくいドライバー300の受信データについては感度を低くすることで、状況に合わせた適切なエラー検出が可能になる。
また、複数のドライバー300を用いる場合、各ドライバー300においてエラー検出(第2のエラー検出)を行ってもよい。本実施形態では、この各ドライバー300でのエラー検出の間に差異を設けてもよい。
例えば、ドライバー300のエラー検出部333は、電気光学パネルを駆動する他のドライバーのエラー検出の感度と異なる感度で、エラー検出を行う。このようにすれば、ドライバー300毎にエラー検出の感度を柔軟に設定することが可能になる。例えば、重要な情報が表示パネル500の表示領域の中央部に表示される場合、当該中央部のデータ線を駆動するドライバー300のエラー検出の感度を相対的に高くし、端部側のデータ線を駆動するドライバー300の感度を相対的に低くする。図5の例であれば、ドライバー300-2、300-3のエラー検出の感度を、ドライバー300-1、300-4に比べて高くする。より具体的には、警告情報表示領域に対応するデータ線を駆動するドライバー300のエラー検出感度を相対的に高くすればよい。なお、エラー検出の感度の調整は、上述したようにエラー検出部333でのエラー検出のレート(何フレームに1回エラー検出を行うか)を変更してもよいし、エラー出力部315でカウントを行う場合の閾値を変更してもよい。
或いは、一部のドライバー300でのエラー検出自体を非アクティブにしてもよい。例えば図6と合わせて上述したように、各ドライバーはエラー検出の有効無効を端子により設定可能であってもよい。そして、重要な情報が表示される領域(例えば警告情報表示領域)に対応するドライバー300をアクティブとし、その他のドライバー300を非アクティブとする。このような手法でも、複数のドライバー300の間で、エラー検出の感度に差を設けることが可能である。
或いは、エラー検出部333の出力を固定にするのではなく、ドライバー300(エラー出力部315)からのエラー出力の有効無効を設定してもよい。例えば、警告情報表示領域に対応するドライバー300のエラー出力のみを有効とし、他のドライバー300の出力を無視する構成としてもよい。このような手法でも、複数のドライバー300の間で、エラー検出の感度に差を設けることが可能である。
またドライバー300の制御部330は、エラー検出部333でのエラー検出とは異なる異常検出を行ってもよい。例えば制御部330は、クロック信号が供給されているか否かに基づいて、信号異常、或いは外部デバイスとの接続異常を判定してもよい。信号異常又は接続異常の判定は、例えば図2に示した検出回路360により行われる。
信号異常、接続異常が検出された場合、制御部330は表示パネル500での表示をオフにする制御を行ってもよい。例えば、制御部330は、表示領域全面を黒く表示する制御を行う。このようにすれば、不適切な情報の表示を行うことを抑止できる。不適切な情報の表示抑止という観点からすれば、制御部330は、エラー検出部333でエラーが検出された場合に、表示をオフにしてもよい。
ただし、信号異常や接続異常が発生した場合、正常な表示動作(表示パネル500の駆動)自体が難しい場合も考えられる。一方、CRCエラーについては上述したようにある程度の頻度で発生するものである。よって制御部330で表示をオフする場合に、信号異常や接続異常と、エラー検出部333でのエラー検出との間に差異を設けてもよい。
具体的には、ドライバー300は、駆動回路340の駆動制御を行う制御部330(駆動制御部331)を含み、制御部330は、信号異常又は接続異常がk回(kは正の整数)検出された場合に、表示をオフにする制御を行い、エラー検出部333によりエラーがj回(jはj>kの整数)検出された場合に、表示をオフにする制御を行う。
このようにすれば、信号異常又は接続異常と、エラーの検出との重要度(深刻度)の差異を考慮した上で、表示のオフ制御を行うことが可能になる。信号異常や接続異常では、上述したように正常な動作が難しいため、kは充分小さい値(例えばk=1)とする。それに対して、CRCエラーはある程度の回数の発生を許容可能である。また、ここではドライバー300の制御部330での制御を説明したが、表示コントローラー200の制御部230において同様の制御を行うことも妨げられない。
5.変形例
以上では、エラー出力端子TEとして、エラーの有無を出力する端子を用いる例を示した。ただしこれには限定されず、ドライバー300は、外部デバイスからエラーの種類を特定するためのデータ(以下、種類特定データ)の読み出すための端子を、エラー出力端子TEとして含んでもよい。外部デバイス(表示コントローラー200)は、当該端子を介してドライバー300に記憶された種類特定データを読み出すことで、エラーの種類を特定する。
ここで種類特定データの具体例は種々考えられる。例えば、複数のドライバー300が設けられる例であれば、いずれのドライバーでエラーが検出されたかを表すデータを種類特定データとしてもよい。或いは、走査ドライバー400でエラー検出が行われる場合、エラーがドライバー300で検出されたか走査ドライバー400で検出されたかを表す情報を種類特定データとしてもよい。また、ドライバー300において、CRCエラーに基づくエラー検出と、信号異常や接続異常等の異常検出を行う場合、いずれが検出されたかを表す情報を種類特定データとしてもよい。また、ドライバー300のエラー検出部333において、CRCエラーの累積発生回数と、連続発生回数の両方をカウント可能な場合、いずれのカウントが閾値を超えたかを表すデータを種類特定データとしてもよい。その他、本実施形態のドライバー300では種々のエラー、異常を検出可能であり、それらのうちのいずれが検出されたかを特定するデータを、種類特定データとして利用することが可能である。
6.電気光学装置、電子機器、移動体
本実施形態の手法は、上記のドライバー300(表示システム600)を含む種々の装置に適用できる。例えば、本実施形態の手法は、ドライバー300(表示システム600)と、電気光学パネル(表示パネル500)を含む電気光学装置に適用できる。また、本実施形態の手法は、ドライバー300(表示システム600)を含む電子機器や移動体に適用できる。
図7に、本実施形態の表示システム600を含む電気光学装置700(表示装置)の構成例を示す。電気光学装置700は、表示コントローラー200と、ドライバー300と、表示パネル500と、を含む。
表示パネル500は、例えばガラス基板と、ガラス基板上に形成される画素アレイ(液晶セルアレイ)とで構成される。画素アレイは、画素、データ線、走査線を含む。ドライバー300はガラス基板に実装され、ドライバー300と画素アレイとは透明電極(ITO:Indium Tin Oxide)で形成された配線群で接続される。表示コントローラー200はガラス基板とは別の回路基板に実装され、回路基板とガラス基板はフレキシブル基板等で接続される。なお、電気光学装置700はこの構成に限定されない。例えば、ドライバー300と表示コントローラー200が回路基板に実装され、その回路基板と表示パネル500がフレキシブル基板等で接続されてもよい。なお表示パネル500は、液晶ディスプレイ(LCD,liquid crystal display)であってもよいが、これには限定されない。例えば表示パネル500は、OLED(Organic Light Emitting Diode)を用いたディスプレイ(有機ELディスプレイ、OELD:Organic Electro-Luminescence Display)であってもよい。
図8に、本実施形態の表示システム600を含む電子機器800の構成例を示す。本実施形態の電子機器として、例えば車載表示装置(例えばメーターパネル等)や、ディスプレイ、プロジェクター、テレビション装置、情報処理装置(コンピューター)、携帯型情報端末、カーナビゲーションシステム、携帯型ゲーム端末、DLP(Digital Light Processing)装置等の、表示装置を搭載する種々の電子機器を想定できる。
電子機器800は、CPU810(処理装置100)、表示コントローラー200、ドライバー300、表示パネル500、記憶部820(メモリー)、操作部830(操作装置)、通信部840(通信回路、通信装置)を含む。
操作部830は、ユーザーからの種々の操作を受け付けるユーザーインターフェースである。例えば、ボタンやマウス、キーボード、表示パネル500に装着されたタッチパネル等で構成される。通信部840は、画像データや制御データの通信(送信、受信)を行うデータインターフェースである。例えばUSB等の有線通信インターフェースや、或いは無線LAN等の無線通信インターフェースである。記憶部820は、通信部840から入力された画像データを記憶する。或いは、記憶部820は、CPU810のワーキングメモリーとして機能する。CPU810は、電子機器800の各部の制御処理や種々のデータ処理を行う。表示コントローラー200はドライバー300の制御処理を行う。例えば、表示コントローラー200は、通信部840や記憶部820からCPU810を介して転送された画像データを、ドライバー300が受け付け可能な形式に変換し、その変換された画像データをドライバー300へ出力する。ドライバー300は、表示コントローラー200から転送された画像データに基づいて表示パネル500を駆動する。
図9に、本実施形態の表示システム600を含む移動体の構成例を示す。本実施形態の移動体として、例えば、車、飛行機、バイク、船舶、或いはロボット(走行ロボット、歩行ロボット)等の種々の移動体を想定できる。移動体は、例えばエンジンやモーター等の駆動機構、ハンドルや舵等の操舵機構、各種の電子機器を備えて、地上や空や海上を移動する機器・装置である。
図9は移動体の具体例としての自動車900を概略的に示している。自動車900には、表示システム600(表示コントローラー200,ドライバー300)を有する表示装置910(電気光学装置700)と、自動車900の各部を制御するECU920(処理装置100)が組み込まれている。ECU920は、例えば車速や燃料残量、走行距離、各種装置(例えばエアーコンディショナー)の設定等の情報をユーザーに提示する画像(画像データ)を生成し、その画像を表示装置910に送信して表示パネル500に表示させる。
なお、上記のように本実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本発明の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語と共に記載された用語は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。また本実施形態及び変形例の全ての組み合わせも、本発明の範囲に含まれる。また処理装置、表示コントローラー、ドライバー、電気光学装置、電子機器、移動体の構成・動作等も、本実施形態で説明したものに限定されず、種々の変形実施が可能である。