要約
マキシムの1-Wireデバイスは、デバイスとホストとの距離が1-Wireの仕様を超えるような遠隔地で使用されます。このアプリケーションノートでは、ホストと、1-Wire通信を実行するリモートコントローラとの間で使用することのできる簡単なプロトコルについて説明します。このアプリケーションノートはもともと、IEEE® 1451.4 A Smart Transducer Interface for Sensors and Actuators—Mixed-Mode Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats標準化委員会をサポートするために作成されたものです。
はじめに
マキシムの1-Wireデバイスは、デバイスとホストの距離が1-Wireの仕様を超えるような遠隔地で使用されることがあります。
このような場合、たとえば、LANやWANのネットワークを介して効率的かつトランスペアレントに1-Wireデバイスのデータを一貫した矛盾のない方法で転送することができるような通信機器が、センサとデータ処理コンピュータとの間にあると便利です。
このアプリケーションノートの目標は、一貫したフレームバッファフォーマットで動作するトランスポート層をドライバソフトウェアに挿入するという、比較的簡単に解決することができる方法を提案することです。この特別なトランスポート層によって、1-Wireプロトコルソフトウェアのさまざまなパーツを物理的に異なる場所に配置することができます。これによって、1-Wireのコンセプトである多様性が拡張されます(わかりやすくするために、特殊な用語、コマンド、またはコードはイタリック体で示しています)。このアプリケーションノートはもともとIEEE 1451.4 A Smart Transducer Interface for Sensors and Actuators—Mixed-Mode Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats標準化委員会をサポートするために作成されたものです。
シナリオ
リモートセンサに組み込まれたマキシムのデバイスは、1-Wireバスと複数の計測器を経由してホストアプリケーションに接続されています。計測器は異なる通信ラインを介して互いに接続されているため、異なるプロトコルを使用しています。この場合、計測器は通信リピータとして動作し、ホストアプリケーションと1-Wireバス上のデバイスとの間でデータをトランスペアレントに転送します。
図1. 複数プロトコルの場合のリピータ
本来の目標
たとえ新しい(なおかつ不明な)マキシムのデバイスが1-Wireバスに接続されているとしても、計測器(リピータ)のソフトウェアは、計測器の耐用寿命(10年以上)の間は安定している必要があります。
通信速度は最適化する必要があります。これは、他の通信バス(この例ではバス1とバス2)上の通信トランザクションの数を最小限に抑える必要があるということです。このようなバスは、1-Wireバスよりもかなり狭い帯域幅であったり、また1-Wire通信に関係しない他の通信タスクで使用されたりする可能性があるためです。
付随的な目標
特定タイプの1-Wireデバイスについての情報はすべて、ホストプログラムと分離される必要があります。リピータには、デバイスのいかなる特定情報も含めるべきではありません。
通信セッションは、仲介するバス(この例ではバス1とバス2)上の通信のオーバヘッドを最小限に抑えるため、(個々のバイトやビットの代わりに)バッファ全体を利用する必要があります。
リピータ用として、いくつかの基本とデバイストランスペアレントな1-Wireのトランザクションを該当するバッファフォーマットとともに定義する必要があります。これらのデバイストランスペアレントなトランザクションで、1-Wireデバイスのすべてのタイプと問題なく通信可能となる必要があります。
最小バッファサイズは、リピータが処理可能なサイズであるものとし、明確に定義する必要があります(リピータのバッファリング性能は非常に限られているものと想定されます)。
マキシムのデバイスとの通信において大きなバッファを必要とする場合は、複数の仲介バッファに対して1-Wireトランザクションを分割し、1-Wireで接続されたホストとリピータとの間で転送することを可能にできます。仲介通信プロトコルは、通常、プロトコル自身のフォーマットを用いた「エンベロープ」(たとえば、ヘッダや末尾の数バイトを追加)に1-Wireバッファフレームを詰めます。これは1-Wire通信にとってトランスペアレントであり、この仕様の一部とはなりません。
制限の受け入れ
リピータの1-Wireインタフェースは、EPROMのプログラミング電圧、より高速な「オーバドライブ」通信、あるいは強力なプルアップ電力供給を処理する必要はありませんが、その使用方法はこの仕様で定義されています。
リピータを介するすべての通信は、ホストアプリケーションから開始されるものと想定されます。
1-Wireバッファのトランスペアレントなトランザクション
1-Wireバス上のトランスペアレントなバッファトランザクションは、ビット単位で同時に送受信可能であるということを利用しています(1-Wireデバイスからビットフレームを受信すると、リピータによって1が送信されます)。
トランザクションの後、リピータのバッファには1-Wire (デバイス)から読み出した情報が格納されます。結果として1-Wireのトランザクションによって、リピータのバッファは、必要であればホストに返信することができます。すべてのバッファ通信はホストによって開始されます。
トランスペアレントな1-Wireバッファのプロトコル仕様
バッファフォーマット
トランスペアレントなバッファトランザクションのプロトコルでは、2つの通信バッファがリピータで定義されています。
ホストコンピュータからフレームを受信する1つの着信バッファと、戻りフレームが構成されている1つの発信バッファです。
一般的な着信フォーマット
長さバイト | シングルバイトコマンドおよびマルチバイトコマンドの配列 |
一般的な発信フォーマット
長さバイト | シングルバイトコマンドおよびマルチバイトコマンドの結果の配列 |
着信フレームと発信フレームの両方の最初のバイトは、フレーム(長さバイトを含まない)のバイト数を示す長さバイトです。
着信フレームには、一連の1-Wireコマンドを含めることができます。着信バッファ内のコマンドが解析され、解析結果が得られると、コマンドとその結果が発信バッファに置かれます。
着信バッファの長さが0の場合、バッファは無視されて処理は行われません。
リピータが処理することができる着信バッファと発信バッファの最小サイズは、長さバイトを含めて49バイトです。
一般的なコマンドフォーマット
1-Wireコマンドには、2つのタイプがあります。シングルバイトの1-Wireコマンドとマルチバイトの1-Wireコマンドです。ヘッダの最初のバイトのMSBビットによって、シングルバイトコマンドかマルチバイトコマンドかを特定しています。マルチバイトコマンドの場合、ヘッダは、コマンドバイトと、添付されたデータバイトブロックの長さを規定するバイトの2バイトで構成されます。
着信コマンドフォーマット | 発信応答フォーマット | ||||||
マルチバイトコマンド | マルチバイトコマンドの応答(指定のコマンド) | ||||||
|
| ||||||
シングルバイトコマンド | シングルバイトコマンドの応答(すべてのコマンド) | ||||||
|
|
コマンドは必ずシングルバイト値になります。1-Wire操作で結果が得られると、コマンドは必ず着信バッファから発信バッファにコピーされます。
マルチバイトコマンドで使用されるdata_lengthは必ずシングルバイトで、その値は、data_lengthバイトに続くバッファ内のバイト数です。DATA_xxxコマンドでは、data_lengthの値は、内部プロトコルレジスタに対する読出し操作と書込み操作を区別するためにも使用されます。レジスタ書込みの場合、data_lengthはゼロ以外の値になります。データは、着信バッファから、コマンドで指定されたデータレジスタにコピーされます。コマンドやデータは発信バッファにはコピーされません。レジスタ読出しの場合、data_lengthはゼロに等しくなります。コマンドは、発信バッファにコピーされます。コマンドで指定されたレジスタに対するdata_lengthが発信バッファにコピーされて、その後に続けてレジスタのデータがコピーされます。
return_codeは必ずシングルバイト値で、発信バッファ内のシングルバイトコマンドの後に続きます。
コマンドの概要
表1a. シングルバイトコマンド
コマンド名 | 説明 | コード |
CMD_ML_RESET | 1-Wire上のすべてのデバイスをリセットし、応答しているデバイスがあれば報告します。 | 80 (hex) |
CMD_ML_SEARCH | DATA_IDとDATA_SEARCH_STATEの各レジスタに指定したとおりの現在の検索状態を使用して1-Wire検索を実行します。 | 81 |
CMD_ML_ACCESS | 1-WireのMATCH_ROMコマンド55 hexを使用して、DATA_IDレジスタに指定したとおりの現在のデバイスを選択します。 | 82 |
CMD_ML_OVERDRIVE_ACCESS | 1-WireのMATCH_ROMコマンド69 hexを使用して、DATA_IDレジスタに指定したとおりの現在のデバイスを選択し、同時にデバイスをオーバドライブモードに設定します。リピータ端末がオーバドライブモードをサポートしていない場合、このコマンドはRET_CMD_UNKNOWNを返します。 | 83 |
CMD_RESET | リピータ端末をデフォルト状態にリセットします。以前に処理した発信バッファのデータはそのままで変わりません。 | 84 |
CMD_GETBUF | 発信バッファをそのまま返します。 このコマンドを正常に処理することができた場合、コマンドバイトは発信バッファにコピーされず、発信バッファの長さはそのままで変わりません。 このコマンドを処理することができない場合、CMD_GETBUFコマンドは、通常、RET_BUSYリターンコードとともに直ちに返されます。これは、発信バッファが返される唯一のコマンドです。 CMD_GETBUFコマンドが着信バッファ内に存在するとき、このコマンドは必ず、着信バッファ内の最後のコマンドになります。 CMD_GETBUFに続くコマンド(次の着信バッファ内)がCMD_GETBUFでない場合、このコマンドを処理する前に発信バッファがクリアされます。これによって、ホストは、発信バッファの再送信を複数回、要求することができるようになります。 |
85 |
CMD_ERROR | エラーコマンドです。このコマンドは、ホストにエラーを通知するためにリピータ端末の出力バッファでのみ使用されます。通常、エラーは、マルチバイトコマンドの処理またはリピータ端末内の内部エラーによって発生する可能性があります。着信バッファ内でエラーが発生した場合、戻りステータスは、RET_CMD_UNKNOWNでなければなりません。 | 86 |
(予備) | このプロトコルの今後の拡張に備えた予備のシングルバイトコマンドです。 リターンコードRET_CMD_UNKNOWNとともに返す必要があります。 | 87-CF |
(ベンダ固有) | リピータベンダが定義する予約済みのシングルバイトコマンド。使用しない場合、リターンコードRET_CMD_UNKNOWNとともにこれらのコマンドを返す必要があります。 | D0-FF |
表1b. マルチバイトコマンド、および必要なリピータのデータレジスタ
コマンド名 | 説明 | コマンド | レジスタサイズ |
DATA_ID | 64ビットの1-Wire ID番号レジスタへの書込みまたは読出しを行います。書込みコマンドのデータ長が8未満で1以上の場合、残りのレジスタバイトはクリアされます。 | 00 (hex) | 8 (bytes) |
DATA_SEARCH_STATE | 2バイトの1-Wire検索状態レジスタへの書込みまたは読出しを行います。レジスタへの書込みの間に、内部の検索アルゴリズム状態がクリアされます。最初のレジスタ書込みでは、LastDiscrepancyがプリセットされます(検索開始のためのDATA_IDビットのインデックス)。2番目のレジスタLastFamilyDiscrepancyは必ず書込みによってクリアされます。 | 01 | 2 |
DATA_SEARCH_CMD | 1-Wire検索コマンドレジスタへの書込みまたは読出しを行います。これは、CMD_ML_SEARCHコマンドの間に使用される1-Wire書込みコマンドです。 | 02 | 1 |
DATA_MODE | オプション(1-Wireバスの速度やレベル)を定義するレジスタへの書込みまたは読出しを行います。 | 03 | 1 |
DATA_CAPABILITY | リピータの1-Wire機能を読み出します(この操作はinbound data_lengthの値が0であるものと想定しています)。 | 04 | (1) 定数値 |
DATA_OUTBOUND_MAX | 発信バッファの最大長(バイト)を読み出します(この操作はinbound data_lengthの値が0であるものと想定しています)。 | 05 | (1) 定数値 |
DATA_INBOUND_MAX | 着信バッファの最大長(バイト)を読み出します(この操作はinbound data_lengthの値が0であるものと想定しています)。 | 06 | (1) 定数値 |
DATA_PROTOCOL | プロトコルのバージョン識別番号をヌル(/0)で終わるC文字列として読み出します。現バージョンの1.00プロトコルは「ML100」となります(この操作はinbound data_lengthの値が0であるものと想定しています)。 | 07 | (Max 20 incl. \0) 定数値 |
DATA_VENDOR | リピータベンダの識別データをヌル(/0)で終わるC文字列として読み出します(この操作はinbound data_lengthの値が0であるものと想定しています)。 | 08 | (Max 20 incl. \0) 定数値 |
CMD_ML_BIT | 用意された各データバイトのLSビットを使用してwrite_read 1-Wire通信ビットを開始します。 | 09 | (na) |
CMD_ML_DATA | 1-Wire通信ブロックを開始します。データの最初のバイトは、1-Wireバス上で処理される1-Wireデータバイトの総数(block_lengthと呼ばれる)を定義しています。1-Wire処理は、このバイトに続くデータバイトで開始されます。処理するdata_bytesの数が、ヘッダのblock_length - 1よりも大きい場合、残りのバイトは着信データ値(FF hex)に等しくなるように処理されます。 1-Wire処理の結果は発信レジスタに配置されます。 |
0A | (na) |
CMD_DELAY | 遅延を実行します。遅延の長さは、付属のデータバイトで定義されています。 data_lengthは1であるものとします。 |
0B | (n/a) |
(予備) | このプロトコル仕様の今後の拡張に備えた予備のマルチバイトコマンド このコマンドがリピータ端末にとって未知の場合、コマンドCMD_ERRORがリターンコードRET_CMD_UNKNOWNとともに発信バッファに配置されます。 |
0C-4F | |
(ベンダ固有) | 今後のベンダ固有の目的に備えた予備のマルチバイトコマンド このコマンドがリピータ端末にとって未知の場合、コマンドCMD_ERRORがリターンコードRET_CMD_UNKNOWNとともに発信バッファに配置されます。 |
50-7F |
合計:12のRAMレジスタバイト
表2. リターンコード(必ず発信バッファ内のシングルバイトコマンドの後に続きます)
リターンコード名 | 説明 | リターンコード |
RET_SUCCESS | コマンド操作が正常に行われました。 | 00 (hex) |
RET_END_SEARCH | デバイス検索の終了です。ID検索の最後のデバイスは、前回に検出したデバイスであり、検索状態はこれでリセットされます。 | 01 |
RET_BUSY | 前回のバッファがまだ処理されていません。 | 02 |
RET_ERROR | 詳細不明のエラーです(着信バッファの処理を停止します)。 | 03 |
RET_NO_DEVICE | 1-Wire上にデバイスが存在しません(着信バッファの処理を停止します)。 | 04 |
RET_ML_SHORTED | 1-Wireが短絡しているものと思われます(着信バッファの処理を停止します)。 | 05 |
RET_OUTBOUND_OVERRUN | 発信バッファのオーバランエラーです(着信バッファの処理を停止します)。 | 06 |
RET_INBOUND_OVERRUN | 着信バッファのオーバランエラーです(着信バッファの処理を停止します)。 | 07 |
RET_REG_OVERRUN | データレジスタのオーバランエラーです(着信バッファの処理を停止します)。 | 08 |
RET_END_OF_INBOUND | 着信バッファに予期しない結果が生じました(着信バッファの処理を停止します)。 | 09 |
RET_READ_ONLY | 読出し専用のデータレジスタに書き込もうとしています(data_lengthが0でありません。着信バッファの処理を停止します)。 | 0A |
RET_WRITE_ONLY | 書込み専用のデータレジスタを読み出そうとしています(data_lengthが0です。着信バッファの処理を停止します)。 | 0B |
RET_CMD_UNKNOWN | 未知のコマンドです(着信バッファの処理を停止します)。 | 0C |
(予備) | このプロトコル仕様の今後の拡張に備えた予備です。 | 0D to 7F |
(ベンダ固有) | ベンダ固有のリターンコードです。 | 80 to FF |
ベンダ固有のコマンドをホストで使用するには、DATA_VENDORコマンドを使用して、想定するリピータのタイプが存在することを確認する必要があります。この予防措置によって、各ベンダ間のコマンドの競合が防止されます。
コマンド処理の説明
コマンド処理のシーケンス
着信バッファと発信バッファは、複数のコマンドをシーケンスの中に含めることができます。
着信バッファは、順番に解析処理されます。処理されるコマンドのほとんどは、発信バッファに結果が追加されます。したがって、発信バッファ内のコマンドシーケンスは、着信バッファ内のコマンドシーケンスの順序と一致します。唯一の例外は、CMD_ERRORが発信バッファに挿入されたとき、およびビジー状態RET_BUSYがCMD_GETBUFコマンドの結果として直ちに返されたときです。
着信バッファを受信すると、着信バッファ内の最初のコマンドがCMD_GETBUFである場合を除いて、発信バッファはクリアされます。CMD_GETBUFの場合は、代わりに発信バッファが(再)送信されます。
着信バッファの受信によって着信バッファのオーバフローが発生した場合、RET_INBOUND_OVERRUNステータスとともにCMD_ERRORコマンドが発信バッファに挿入されます。着信バッファの残りの内容は無視されます。
着信バッファの処理によって発信バッファのオーバフローが発生した場合、現在のコマンド (シングルバイトコマンドの場合) か、あるいはCMD_ERRORコマンドがRET_OUTBOUND_OVERRUNステータスとともに発信バッファに挿入されます。現在のコマンドの処理は停止され、着信バッファのその他のコマンド処理も停止されます。
着信は、1-Wireがデバイスなしの状態(RET_NO_DEVICE)であっても、あるいは1-Wireバスが短絡状態(RET_ML_SHORTED)であっても中断される場合があります。不明または不適切なコマンドは、コード(RET_RET_OVERRUN、RET_END_OF_INBOUND、RET_READ_ONLY、RET_WRITE_ONLY、RET_CMD_UNKNOWN、RET_OUTBOUND_OVERRUN)を返して着信コマンド処理を停止します。着信コマンド処理を中断するエラー結果は、すべて最終エラーメッセージとみなされます。
リピータを用いるすることによって、1つの最終エラーメッセージ(CMD_ERROR + エラーステータス)のための場所が必ず発信バッファ内に存在させることができます。最終エラーメッセージが発信バッファに置かれた後、発信バッファが送信されるかリセットされるまで、上記のようにリピータ内のすべての処理の停止が可能となります。
リピータ端末によって連続してエラーイベントが検出された場合、最終エラーメッセージが発信バッファに置かれた後、後続のエラーイベントをすべて無視する必要があります。この状態は、発信バッファが送信後にリセットされるまで、あるいはCMD_ML_RESETコマンドによってリセットされるまで、事前に設定されています。これによって、スレーブでエラーが発生したシーケンスと同じシーケンスでホストにエラー情報が与えられ、またバッファ内の以前の情報が失われたり上書きされたりしないことを保証します。
エラー状況によって着信バッファの処理が中断されると、着信バッファを調べてCMD_GETBUFコマンドの有無を確認します。コマンドが見つかれば、発信バッファの現在の内容がホストに返送されます。CMD_GETBUFが見つからない場合、別の着信バッファを受信するまで他のコマンド処理は行われません。
バッファのフレーム同期
CMD_GETBUFコマンドを受信すると、リピータ端末によって発信バッファが送信されます。
CMD_GETBUFは「トークン」とみなすことができます。リピータ端末がホストからCMD_GETBUF「トークン」を受け取ると、発信バッファの送信が1回可能となります。発信バッファは、CMD_GETBUF「トークン」ごとに1回送信され、CMD_GETBUF「トークン」を受信(および処理)する前に、いずれの送信も開始されないものとします。
リピータ端末がビジーの場合、CMD_GETBUF「トークン」は直ちにホストに戻されます。ホスト端末は、その後、トークンの再送信を試行することもできれば(シングルバスポーリング)、あるいは他の場所で稼働中の低レベルの別の1-Wireプロトコルにトークンを送ることもできます(マルチバスポーリング)。
着信バッファのその後のコマンド解析が停止されるため、CMD_GETBUFは、必ず着信バッファの最後のコマンド(唯一のコマンドでない場合)でなければなりません。
図2a. 着信バッファの受信
図2b. 着信コマンドの処理
表3. フローチャートの変数の説明
フローの変数 | 説明 |
cmd | 処理中の現在のコマンドコード |
data_length | 現在のコマンドがマルチバイトコマンドの場合のデータバイト数 |
data_bytes | マルチバイトコマンドのデータバイトの開始へのポインタ |
return | 処理中コマンドの現在の結果バイト |
inbound | ホストからのコマンド着信リストを含むバッファ |
outbound | 着信コマンドからホストへ戻る応答を含むバッファ |
max | 着信バッファの最大サイズでDATA_INBOUND_MAXと同じ |
last_cmd | 評価済の最後のコマンド |
last_cmd_return | 評価済の最後のコマンドの結果 |

図2c. 発信スペースの検証
コマンドの詳細説明
CMD_ML_RESET
CMD_ML_RESETコマンドは、すべての1-Wireデバイスをリセットして、少なくとも1つのデバイスが存在するかどうかを検出します。デバイスが存在しない場合、リターンコードRET_NO_DEVICEが発信バッファに置かれ、着信バッファの処理が停止します。このコマンドは、リセット信号が1-Wireに送出されるときの通信速度に対応したDATA_MODEデータレジスタを使用します。
例:1-Wire上のデバイスをリセットします。
inbound CMD_ML_RESET outbound CMD_ML_RESET <return byte>

図3a. コマンドCMD_ML_RESETの処理
CMD_ML_SEARCH
CMD_ML_SEARCHコマンドは、リピータ内の現在の検索状態を使用して検索を実行し、1-Wire上の「次の」デバイスを見つけます。コマンドは検索前に1-Wireのリセットを行いません。CMD_ML_RESETコマンドは、ほとんどの場合、CMD_ML_SEARCHの前に使用する必要があります。このコマンドは、リピータのデータレジスタDATA_SEARCH_STATEおよびDATA_IDにある検索状態の情報を使用します。検索をリセットして1-Wire上の「最初の」デバイスを見つけるには、DATA_SEARCH_STATEデータレジスタの2バイトを0に設定します。使用方法の詳細な説明については、DATA_SEARCH_STATEコマンドの説明を参照してください。このコマンドは、1-Wire上で検索を実行するときの通信速度に対応したDATA_MODEデータレジスタを使用します。1-Wire検索アルゴリズムの詳細な説明については、付録を参照してください。
例:1-Wire上の最初のデバイスを検索します。検索状態をリセットしてから検索を行います。見つけたデバイスのIDを読み出します。
inbound DATA_SEARCH_STATE <2><0,0> CMD_ML_RESET CMD_ML_SEARCH DATA_ID <0> outbound CMD_ML_RESET <return byte> CMD_ML_SEARCH <return byte> DATA_ID <8><8 bytes of ROM>例:1-Wire上の次の2つのデバイスを検索して、これらのデバイスのIDを返します。
inbound CMD_ML_RESET CMD_ML_SEARCH DATA_ID <0> CMD_ML_RESET CMD_ML_SEARCH DATA_ID <0> outbound CMD_ML_RESET <return byte> CMD_ML_SEARCH <return byte> DATA_ID <8><8 bytes of ROM> CMD_ML_RESET <return byte> CMD_ML_SEARCH <return byte> DATA_ID <8><8 bytes of ROM>

図3b. コマンドCMD_ML_SEARCHの処理
CMD_ML_ACCESS
CMD_ML_ACCESSコマンドは、データレジスタDATA_IDにID番号が含まれたデバイスを選択します。1-Wireデバイスは「Match ROM」コマンドを使用することによって選択されます。このコマンドは、最初にCMD_ML_RESETコマンドで回線をリセットして、「Match ROM」コマンド(55 hex)を送出し、さらにDATA_IDから8バイトのIDを送信することによって使用します。
この時点で1-Wireデバイスは「アクセス」されたことになります。次にデバイスは、デバイス固有のコマンドに対応する準備が完了します。このコマンドは、CMD_ML_RESETが失敗した場合にリターンコードRET_NO_DEVICEを返し、その他の問題が検出された場合はRET_ML_SHORTEDを返します。成功時のリターンコードは、RET_SUCCESSです。
このコマンドは、DATA_MODEデータレジスタの速度ビットを使用して、1-Wire上でアクセスするときの通信速度を選択します。
例:現在のデバイスIDを設定して、そのデバイスを選択します。
inbound DATA_ID <8><8 bytes of ID> CMD_ML_ACCESS outbound CMD_ML_ACCESS <return byte>

図3c. コマンドCMD_ML_ACCESSの処理
CMD_ML_OVERDRIVE_ACCESS
CMD_ML_OVERDRIVE_ACCESSコマンドは、データレジスタDATA_IDにID番号が含まれたデバイスを選択すると同時にそのデバイスとリピータをオーバドライブの通信速度に設定します。これは、DATA_MODEレジスタの速度ビットをクリアすることによって最初にリピータを強制的に標準速度にします。次に、CMD_ML_RESETコマンドを用いて1-Wireを標準速度にリセットします。
CMD_ML_RESETがデバイスの存在を検出した場合、「Overdrive Match ROM」コマンド(69 hex)も標準速度で送信されます。この時点で、DATA_MODEレジスタの速度ビットが設定され、リピータは強制的にオーバドライブの通信速度になります。次に、DATA_IDの8バイトIDがオーバドライブ速度で送信されます。このコマンドが終了した後も、速度ビットはオーバドライブに設定されたままとなります。このコマンドは、CMD_ML_RESETが失敗した場合にリターンコードRET_NO_DEVICEを返し、その他の問題が検出された場合はRET_ML_SHORTEDを返します。成功時のリターンコードは、RET_SUCCESSです。
このコマンドを運用する場合には、リピータにオーバドライブ速度の性能があり(DATA_CAPABILITYコマンドを参照)、またDATA_IDにIDが含まれた現在のデバイスにオーバドライブの性能がある必要があります。リピータがオーバドライブモードをサポートしていない場合にこのコマンドを使用すると、RET_CMD_UNKNOWNが発生します。
例:現在のデバイスIDを設定してから、そのデバイスを選択し、デバイスとリピータをオーバドライブに設定します。
inbound DATA_ID <8><8 bytes of ID> CMD_ML_OVERDRIVE_ACCESS DATA_MODE <00> outbound CMD_ML_OVERDRIVE_ACCESS <return byte> DATA_MODE <01><01 (Overdrive)>

図3d. コマンドCMD_ML_OVERDRIVE_ACCESSの処理
CMD_RESET
リピータのリセットは、リピータをリセットしてデフォルト状態にします。ホストによってまだ読み出されていない発信バッファ内のデータ内容はいずれも、CMD_RESETの後に失われます。CMD_RESETで設定されるデフォルト値については、表4を参照してください。
例:リピータの状態をデフォルト値にリセットします。
inbound CMD_RESET outbound CMD_RESET <return byte>表4. デフォルト値
リピータの状態 | デフォルト値 |
DATA_ID | 0,0,0,0,0,0,0,0 |
DATA_SEARCH_STATE | 0,0 |
DATA_SEARCH_CMD | F0 hex |
DATA_MODE | 0 (標準速度) |
DATA_CAPABILITY | リピータ固有 |
DATA_OUTBOUND_MAX | リピータ固有、最低49バイト |
DATA_INBOUND_MAX | リピータ固有、最低49バイト |
DATA_PROTOCOL | 仕様向けの「ML100」 |
DATA_VENDOR | リピータ固有 |
outbound length | 0 |
last_cmd | CMD_ML_RESET (80 hex) |
last_cmd_return | RET_SUCCESS (00 hex) |
LastDeviceFlag | 0 |

図3e. コマンドCMD_RESETの処理
CMD_GETBUF
CMD_GETBUFコマンドは、現在の発信バッファの内容をホストに返送します。着信バッファ内の以降のコマンドはいずれも無視されます。このため、CMD_GETBUFコマンドは必ず着信バッファ内の最後のコマンドになるようにしてください。
発信バッファは、CMD_GETBUFの処理の後も変更されずにそのままです。このためホストは、新しいCMD_GETBUFコマンドを送信することによって(前回の送信中に何らかの問題が生じた場合)、発信バッファの再送信を常に要求することができます。
CMD_GETBUFコマンドの処理に続く着信バッファ内のコマンドは、新しいコマンドが処理される前に発信バッファをリセットします。CMD_GETBUFの詳細については、「コマンド処理の説明」を参照してください。
図3f. コマンドCMD_GETBUFの処理
CMD_ERROR
エラーコマンドは、ホストにエラーを伝える手段として、発信バッファでのみ使用されます。通常、マルチバイトコマンドの処理によってエラーが生じる可能性があります。このコマンドが着信バッファで発生した場合、戻りステータスRET_CMD_UNKNOWNとともに発信バッファにコピーされます
DATA_TD
DATA_IDコマンドによって、リピータ内の8バイトのデバイスIDレジスタの読出しと書込みが可能になります。このレジスタには、1-Wire上で見つかった最後のデバイスのIDが格納されます。このレジスタは、1-Wire上で「次の」デバイスを見つけるために現在の検索で使用され、また検索の結果を記憶する場所でもあります。長さは8バイトで、デフォルト値はすべて0です。
図3gのフロー図は、リピータのレジスタの読出しまたは書込みを行うコマンドの一般的な流れを示します。リピータのレジスタには、読出しのみ可能なレジスタ(読出し専用、長さバイトはゼロ)や、書込みのみ可能なレジスタ(書込み専用、長さバイトはゼロ以外の値)があることに留意してください。
図3g. データレジスタコマンドの処理
DATA_SEARCH_STATE
DATA_SEARCH_STATEコマンドによって、最後の検索のカウントを保持するため、また「次の」デバイスを現在の検索で見つけるために使用する2バイトのレジスタに対する読出しや書込みが可能になります。これら2バイトをDATA_IDと組み合わせることによって、特定のファミリコードを対象にした検索を実現することができます。デフォルト値はすべて0です。この検索状態の最初のバイトは、LastDiscrepancy番号です。これは、最後の検索で取得した検索パスを示します。この番号は、前回の検索で中止された検索を続けるために必要となります。2番目のバイトはLastFamilyDiscrepancyです。これは、前回、DATA_IDのキーファミリコードバイトで使われた検索方向を示します。検索状態の3番目のバイトはLastDeviceFlagで、1-Wire上の最後の検索が最後のデバイスであったことを示すフラグです。LastDeviceFlagはリピータの内部にあり、DATA_SEARCH_STATEに書き込むときに自動的にクリアされます。図3gのフロー図は、リピータのレジスタの読出しまたは書込みを行うコマンドの一般的な流れを示します。1-Wire検索アルゴリズムの詳細な説明については、付録を参照してください。
表5. 1-Wire検索状態の説明
バイトの変数 | 説明 | バイトナンバー |
LastDiscrepancy | DATA_IDレジスタのビットインデックス。(次の)検索不一致がどのビットから開始する必要があるのかを特定します。例えば、9の値は次の検索不一致にDATA_IDレジスタの9番目のビットから開始させるのか、など。よって、検索はDATA_ID (デバイスのファミリコード)の最初の8ビットで特定されたデバイスに限定されます。デフォルト値は0 (全デバイスを検索)です。 | 0 |
LastFamilyDiscrepancy | DATA_IDレジスタのビットインデックス。検索中に更新され、2つの1-Wireデバイス間で選択が実行されるDATA_IDの最初のビットを特定します。DATA_ID (デバイスのファミリビット)の最初の8ビット内でのみ更新されます。次の検索がこのビットインデックス内で開始する場合は、検索は次のデバイスファミリのデバイスのために実行されます。この値がどのように検索アルゴリズムによって更新されるかの説明は付録を参照してください。 | 1 |
CMD_ML_SEARCHコマンドを使用し、またDATA_SEARCH_STATEとDATA_IDのレジスタ値を操作することによって5つの操作タイプを実行することができます。これらの操作は、1-WireデバイスのIDの検出と検証に関するものです。1-Wire検索アルゴリズムについての説明は、アプリケーションノート187 「1-Wire検索アルゴリズム」を参照してください。
FIRST
「FIRST」操作は、1-Wire上の最初のデバイスを検索します。この操作は、DATA_SEARCH_STATEの3バイトをすべてゼロにし、CMD_ML_SEARCHを呼び出すことによって行なわれます。得られたID番号は、DATA_IDレジスタから読み出すことができます。1-Wire上にデバイスが存在しない場合、CMD_ML_RESETは、RET_NO_DEVICEを返します。検索そのものでエラーが発生した場合は、CMD_ML_SEARCHは、RET_END_SEARCHを返します。
例:1-Wire上の最初のデバイスを検出してIDを読み出します。
inbound DATA_SEARCH_STATE <2><0,0> CMD_ML_RESET CMD_ML_SEARCH DATA_ID <0> outbound CMD_ML_RESET <return byte> CMD_ML_SEARCH <return byte> DATA_ID <8><8 bytes of ID>
NEXT
「NEXT」操作は、1-Wire上の次のデバイスを検索します。この検索は通常、「FIRST」操作または別の「NEXT」操作の後に実行されます。この操作は、前回の検索からDATA_SEARCH_STATEの2バイトを変更しないまま、CMD_ML_SEARCHを呼び出すことによって行われます。得られたID番号は、その後、DATA_IDレジスタから読み出すことができます。最後の検索が1-Wire上の最後のデバイスであった場合、あるいは検索そのものでエラーが発生した場合、CMD_ML_SEARCHコマンドは、RET_END_SEARCHを返します。
例:1-Wire上の次のデバイスを検出してIDを読み出します。
inbound CMD_ML_RESET CMD_ML_SEARCH DATA_ID <0> outbound CMD_ML_RESET <return byte> CMD_ML_SEARCH <return byte> DATA_ID <8><8 byts of ROM>
TARGET
「TARGET」操作は、検索状態を事前に設定して特定のファミリタイプを最初に検出する方法です。各1-Wireデバイスは、ID番号内に1バイトの「ファミリコード」が埋め込まれています。この「ファミリコード」によって、1-Wireマスタはこのデバイスの性能を知ることができます。1-Wire上に複数のデバイスが存在する場合、関心のあるデバイスファミリのみを検索の対象にすることが一般的な方法です。あるファミリを対象にするには、DATA_SEARCH_STATEを09, 00 (hex)に設定します。これによって、LastDiscrepancyはファミリコードを超える値に設定されます。次に、DATA_IDレジスタの最初のバイトに希望のファミリコードバイトを設定します。
ここで、CMD_ML_SEARCH関数を呼び出して、得られたIDをDATA_IDレジスタから読み出します。現時点で、希望するファミリのデバイスが1-Wire上に存在しない場合、別のタイプが検出されることになるため、DATA_ID内のファミリコードを確認する必要があることに留意してください。
例:あるファミリタイプを対象にし、1-Wire上でそのタイプの最初のデバイスを検索して、そのIDを読み出します。
inbound DATA_SEARCH_STATE <2><09,00> DATA_ID <1><family code> CMD_ML_RESET CMD_ML_SEARCH DATA_ID <0> outbound CMD_ML_RESET <return byte> CMD_ML_SEARCH <return byte> DATA_ID <8><8 bytes of ROM> DATA_SEARCH_STATE <2><2 bytes of search state>
SKIP
「SKIP」操作は、1-Wire上での前回の検索で検出されたファミリタイプを備えたデバイスをすべて無視するものです。この操作は、検索の後でのみ実行することができます。この操作は、LastFamilyDiscrepancy (バイト1)をDATA_SEARCH_STATEのLastDiscrepancy (バイト0)にコピーしてから、CMD_ML_SEARCHで別の検索を行うことによって達成されます。以下の例では、すでに検索を実行してDATA_SEARCH_STATEの内容がわかっているものと想定しています。
例:最後の検索で検出されたファミリタイプを備えたすべての1-Wireデバイスを無視し、別のタイプの次のデバイスを検出して、そのIDを読み出します。
inbound DATA_SEARCH_STATE <2><LastFamilyDescrepancy, 00> CMD_ML_RESET CMD_ML_SEARCH DATA_ID <0> outbound CMD_ML_RESET <return byte> CMD_ML_SEARCH <return byte> DATA_ID <8><8 bytes of ROM>
VERIFY
「VERIFY」操作は、既知のIDを備えたデバイスが現在1-Wireに接続されているかどうかを確認するものです。この操作は、IDを提供して、そのIDを対象にした検索を行い、IDが存在するかどうかを確認することによって達成されます。最初にDATA_IDレジスタに既知のIDを設定します。次に、DATA_SEARCH_STATEのLastDiscrepancy (バイト0)を64 (40 hex)に設定します。CMD_ML_SEARCHで検索操作を実行し、DATA_IDの結果を読み出します。検索が成功して、DATA_IDが検索対象のIDのままである場合、そのデバイスは現在1-Wire上に存在します。
例:IDを設定して、1-Wireデバイスが現在接続されているかどうかを確認します。
inbound DATA_SEARCH_STATE <2><40, 00> DATA_ID <8><ID of device to verify> CMD_ML_RESET CMD_ML_SEARCH DATA_ID <0> outbound CMD_ML_RESET <return byte> CMD_ML_SEARCH <return byte> DATA_ID <8><8 bytes of ROM>
DATA_SEARCH_CMD
DATA_SEARCH_CMDコマンドによって、検索操作中に使用したコマンドが格納された、1バイトレジスタへの読出しと書込みが可能になります。現在2つの有効なコマンドとして、標準検索用のF0 (hex)および警報デバイスのみを見つけるEC (hex)があります。長さは1バイトでデフォルト値はF0 (hex)です。図3gのフロー図は、リピータのレジスタの読出しまたは書込みを行うコマンドの一般的な流れを示します。
DATA_MODE
DATA_MODEコマンドによって、リピータ上での1-Wireの現在の速度とレベルモードが格納された、1バイトレジスタへの読出しと書込みが可能とします。表6は、事前に定義されたモードビットフラグを示します。このレジスタに書き込むと、即座に1-Wireの状態が変更され、コマンドブロックの途中でモードを操作することができるようになります。ビットフラグで指定された操作を実行する性能がリピータにない場合、このコマンドは無効になります。DATA_CAPABILITYデータレジスタを調べてください。図3gのフロー図は、リピータのレジスタの読出しまたは書込みを行うコマンドの一般的な流れを示します。
表6. DATA_MODEレジスタにある1-Wireモードフラグのビット説明
モードビット名 | 説明 | ビットナンバー |
Speed | 0なら標準速度、1ならオーバドライブ | 0 |
PowerDelivery | 0なら通常の5ボルトのプルアップ、1なら強力なプルアップ | 1 |
ProgramVoltage | 0なら12ボルトのプログラミング電圧をディセーブル、1ならイネーブル(PowerDeliveryおよびPowerDownはディセーブルされます) | 2 |
PowerDown | 1-Wireバスの電源をオフにするために使用する低インピーダンスゼロ電圧(PowerDeliveryおよびProgramVoltageはディセーブルされます) | 3 |
(予備) | 今後のこのプロトコル仕様の拡張に確保。デフォルトでは0,0を使用します。 | 4,5 |
(ベンダ固有) | ベンダ固有モードのフラグです。これらのビットを設定する前に、ホストはDATA_VENDORコマンドを使用して、期待されるリピータタイプが存在することを確認する必要がある。これらに留意することによって、異なるリピータベンダ間の機能相性の問題を防止します。デフォルトでは0,0を使用します。 | 6,7 |
DATA_CAPABILITY
DATA_CAPABILITYコマンドによって、1-Wire通信の電力供給と速度についてのリピータの性能が格納された、1バイトレジスタの読出しを可能にします。表7は、事前に定義された機能ビットフラグを示します。図3gのフロー図は、リピータのレジスタの読出しまたは書込みを行うコマンドの一般的な流れを示します。DATA_CAPABILITYは読出し専用であることに留意してください。
表7. DATA_CAPABILITYレジスタの1-Wire性能フラグのビット説明
性能ビット名 | 説明 | ビットナンバー |
Overdrive_C | 1ならオーバドライブ速度使用可能、0なら標準速度のみ使用可能です。 | 0 |
PowerDelivery_C | 1なら強力な5ボルトプルアップ電力供給が使用可能、0なら通常の通信プルアップのみ使用可能です。 | 1 |
ProgramVoltage_C | 1なら12ボルトのプログラミング電圧が使用可能、0なら使用不可です。 | 2 |
PowerDown_C | 1 なら低インピーダンスのゼロ電圧が使用可能、0なら使用不可です。 | 3 |
(予備) | 今後のこのプロトコル仕様の拡張のために確保します。 | 4,5 |
(ベンダ固有) | ベンダ固有モードのフラグ | 6,7 |
DATA_OUTBOUND_MAX
DATA_OUTBOUND_MAXコマンドによって、事前に定義された発信バッファの最大データ長(バイト)が格納された、1バイトレジスタの読出しを可能にします。発信バッファの最小サイズは、長さバイトを含めずに48バイトです。図3gのフロー図は、リピータのレジスタの読出しまたは書込みを行うコマンドの一般的な流れを示します。DATA_OUTBOUND_MAXは読出し専用であることに留意してください。
発信バッファには、必ず最終エラーメッセージ用のスペース(2バイト)が必要であるため、1-Wire通信中に変更可能な実効サイズは、DATA_OUTBOUND_MAXよりも2バイト小さくなることに留意してください。
DATA_INBOUND_MAX
DATA_INBOUND_MAXコマンドによって、事前に定義された着信バッファの最大データ長(バイト)が格納された、1バイトレジスタの読出しが可能になります。着信バッファの最小サイズは、長さバイトを含めずに48バイトです。図3gのフロー図は、リピータのレジスタの読出しまたは書込みを行うコマンドの一般的な流れを示します。DATA_INBOUND_MAXレジスタは読出し専用であることに留意してください。
DATA_PROTOCOL
DATA_PROTOCOLコマンドによって、プロトコル名とバージョンを表すゼロ終端文字列の読出しが可能になります。このアプリケーションノートの仕様はバージョン1.00であるため、DATA_PROTOCOLの文字列「ML100」で表されます。図3gのフロー図は、リピータのレジスタの読出しまたは書込みを行うコマンドの一般的な流れを示します。DATA_PROTOCOLレジスタは読出し専用であることに留意してください。C文字列の最大長は、0終端を含めて20バイトです。
DATA_VENDOR
DATA_VENDORコマンドによって、ベンダ名を表すゼロ終端文字列の読出しを可能にします。これを使用して、ベンダ固有のコマンドとモードを特定します。図3gのフロー図は、リピータのレジスタの読出しまたは書込みを行うコマンドの一般的な流れを示します。DATA_VENDORレジスタは読出し専用であることに留意してください。C文字列の最大長は、0終端を含めて20バイトです。
CMD_ML_BIT
CMD_ML_BITは、1-Wireとのビットレベルの通信を提供します。CMD_ML_BITはマルチバイトコマンドで、0よりも大きい長さバイトと、1つ以上のデータバイトを提供します。各データバイトは1ビットの通信を表します。各データバイトの最下位ビットは1-Wireに送信され、そのビット通信の結果は発信バッファ内の1バイトにマルチバイト読出しフォーマットで置かれます。このコマンドは、1-Wire上でビット操作を実行するときの通信速度に対応したDATA_MODEデータレジスタを使用します。
例:検索アルゴリズムの最初の2ビットを手動で実行します。
inbound CMD_ML_RESET CMD_ML_DATA <2><length=1><0F> CMD_ML_BIT <2><01,01> outbound CMD_ML_RESET <return byte> CMD_ML_DATA <1><0F> CMD_ML_BIT <2><result1, result2>

図3h. コマンドCMD_ML_BITの処理
CMD_ML_DATA
CMD_ML_DATAは、1-Wireとのブロックレベル通信を提供します。CMD_ML_BLOCKはマルチバイトコマンドで、0よりも大きい長さバイトおよび1つ以上のデータバイトを提供します。最初のデータバイトは、1-Wireの合計ブロック長(バイト)を定義します。ブロック長の後に続くデータバイトは1-Wireに送信され、そのバイト通信の結果は、発信バッファ内の1バイトにマルチバイト読出しフォーマットで置かれます。ブロック長が、提供されたデータバイト数よりも大きい場合、ブロック長の残りの部分はFF (hex)バイトとして処理されます。これは通常、1-Wireデバイスからの読出し操作です。このコマンドは、1-Wire上でブロック操作を実行するときの通信速度に対応したDATA_MODEデータレジスタを使用します。
例:DATA_IDにID番号が含まれた1-Wireメモリデバイスから、最初の32バイトのメモリを読み出します。
inbound CMD_ML_ACCESS CMD_ML_DATA <3><length=34><F0, 00> outbound CMD_ML_ACCESS <return byte> CMD_ML_DATA <34><2 bytes of write data echo and 32 bytes of read data>

図3i. コマンドCMD_ML_DATAの処理
CMD_DELAY
CMD_DELAYコマンドは、与えられた1データバイトで指定される時間だけ、着信バッファの解析の実行を一時停止します。遅延コマンドは、少なくとも所定の量の遅延を行うものとします。ただし、長くすることもできます。このコマンドは、プログラミングおよび電力供給タイプの1-Wire機能とのタイミングを合わせるために、通常、DATA_MODEコマンドとともに使用されます。ビット値に以下の意味を与えることで、この1バイトの値で広範囲の遅延時間を設けることができます。すなわち、最上位ビットをフラグとし、このフラグをセットすると値はミリ秒となり、セットしないときはマイクロ秒となります。Xで表される下位3ビットは、式2^(5 + X)で使用することで、表8に示した値が得られます。
例:1-Wire上にEPROMプログラミングパルスを送出します。
inbound DATA_MODE <04 (hex) (12 volt pulse on)> CMD_DELAY <1><04 (hex) 512 microseconds)> DATA_MODE <00 (hex) (12 colt pulse off)> outbound表8. 遅延バイトの時間値
DELAY BYTE | TIME |
00 (hex) | 32 microseconds |
01 | 64 |
02 | 128 |
03 | 256 |
04 | 512 |
05 | 1024 |
06 | 2048 |
07 | 4096 |
80 | 32 milliseconds |
81 | 64 |
82 | 128 |
83 | 256 |
84 | 512 |
85 | 1024 |
86 | 2048 |
87 | 4096 |

図3j. コマンドCMD_DELAYの処理
参考文献
「Communication with Dallas Semiconductor MicroLAN devices in sensors on remote locations」 Smiczek、David、および、Jan Kristoffersen、Jørgen Bøkke、1998年8月、IEEE 1451.4
このプロトコルの「C」の実装例:http://files.maximintegrated.com/sia_bu/public/mlpkt100.zip
DS2430Aは、新規設計用には推奨されません。
{{modalTitle}}
{{modalDescription}}
{{dropdownTitle}}
- {{defaultSelectedText}} {{#each projectNames}}
- {{name}} {{/each}} {{#if newProjectText}}
-
{{newProjectText}}
{{/if}}
{{newProjectTitle}}
{{projectNameErrorText}}