アナログ電子回路技術者同士の交流のためのアナログ・デバイセズ提供の掲示板サイトです。
日々の回路設計活動での課題や疑問とそれらの解決、あるいはご意見やご提案などの投稿を是非お寄せください!
  トップページに戻る
 現在の総記事数
 Translation
スタッフ
 

閲覧数の多い投稿

* ランキング情報は約24時間おきに更新されます。
ポイント数が高い投稿

* ランキング情報は約24時間おきに更新されます。

アナログ電子回路コミュニティサービス終了のお知らせ

平素はアナログ電子回路コミュニティをご愛顧いただき誠にありがとうございます。

この度、アナログ電子回路コミュニティは2018年3月末日をもってサービスを終了することとなりました。それに伴いまして、本サービスへの新規会員登録は2月末日をもって締切りといたします。約10年という大変長い間、たくさんの皆様にコミュニティをご利用いただきましたこと、深く感謝申し上げます。

なお、コミュニティに掲載しているコンテンツは編集の上、アナログ・デバイセズ社のウェブサイトに随時掲載していく予定です。詳細は追って会員の皆様にお知らせいたします。

今後ともEDN Japanをご愛顧くださいますようお願い申し上げます。


アナログ電子回路コミュニティ運営事務局
* LTC製品に関するご注意
申し訳ございませんが、現時点ではリニアテクノロジー社製品についてのお問い合わせは、リニアテクノロジー社の 技術サポートページ からお問い合わせください。

スレッド一覧に戻る

ホリエ
タイトル
BF592のTWIに関する質問
ポイント []
pt.
アクセス8864
カテゴリーDSP
キーワード REPEATED START   XMITSERV INTERRUPT   RCVSERV INTERRUPTハンドラ   Hardware Reference ver 1.0   割り込みスレシホールド   Powered by Yahoo
投稿日時12/07/18 22:52
ADSP-BF592のTWIについて教えてください。Hardware Reference ver 1.0 (以下HWR)を参照しています。

お聞きしたいのはTWI_MASTER_CTLレジスタのSTOPビットの使い方です。このビットはDCNTフィールドを使用せずにデータ転送を終了させたい場合に最後の転送において1を書き込むと考えていますが、実際にどのタイミングで書き込むのか判断しあぐねています。以下ではFIFOの割り込みスレシホールドが、送信の場合はバッファが空、受信の場合はバッファが空でないときに割り込みが発生するよう設定してあると仮定します。

実際にタイミング判断の参考になりそうな情報としては、たとえば図12-8があります。この図で送信を正しく終了するためにはどこでSTOPを1にすればいいでしょうか。直感的にはXMITSERV INTERRUPTのハンドラにおいて最後の送信データを書き込んだ後にSTOPを1にすればいいように思えますが、これであっていますでしょうか。逆に何もデータを書かずにこの割り込みハンドラの中でSTOPを1にすると直ちにSTOPビットが立ってシーケンスが終了するのでしょうか。

受信の停止の場合はもっと困難に感じています。おそらくは図12-7の中でRCVSERV INTERRUPTハンドラの中でSTOPを1にすればいいと考えていますが、正しいでしょうか。一見自明に思えますが、この割り込みが発生した段階でTWIペリフェラルの内部状態は「受信正常終了、ACK送信開始」というステートになっているのではないかと考えます。ここでSTOPを1にしてNACK送信に切り替えようとしても少々遅すぎないか気になります。仮に間に合うとしても、手遅れになるデッドラインは割り込み発生からどのくらいのSYSCLKサイクルなのでしょうか。

最後にXMIT->RCVのREPEATED START動作を行う場合ですが、TWI_MASTER_CTLのRSTARTは最初から1にしておけばSTOPビットを1にすることで自動的にREPEATED STARTに遷移すると仮定してよろしいでしょうか。

以上、お忙しいとは存じますが、よろしくお教えください。

なお、蛇足ではありますが図12-7の最後のACKはNACKの間違いかと思います。

コメントする     


BigBandBeat 回答番号 17
タイトル
STOPビットの書込みタイミングについて
ポイント
pt.
アクセス8290
投稿日時12/09/05 11:09
2. 受信
「ただちに」の最悪値ですが、SCKのクロックパルスがHIGHになるまでの区間で決まるのではないでしょうか。

NXPのI2C仕様書には以下のように書いてあります。

The data on the SDA line must be stable during the HIGH period of the clock. The HIGH or LOW state of the data line can only change when the clock signal on the SCL line is LOW.

この記述より、ACKを返すにしてもNACKを返すにしても受信側はSCKパルスがLOWの間に状態を安定させればよいことになります。
先にご指摘がありました通り、最後のバイトを受信して割り込みが発生した時点ではSTOPビットを立てていませんから、「受信可能・非STOP条件」ということで、TWIペリフェラルの内部ステートマシンはACK送出に遷移すると思います。
しかし、SCKがLOWまでの間にSTOPビットを書き込めれば、ACK送出の状態をNACK→STOPへの状態遷移に切り替えることができるのではないかと思います。
では、SCKの立ち上がりからどれくらい前までにSTOPビットを書き込めば間に合うかについてですが、残念ながらデータシート等にこのあたりの時間的タイミングの仕様が書かれていませんので不明です。
ただ、考え方はこれで良いと思うのですがいかがでしょうか。

また、ここからは私の予想なのですが、最後の受信バイトのRCVSERV割り込みの発生タイミングは、おそらく最終ビットをサンプリングしたタイミングがトリガになると思います。
サンプリングのタイミングはSCKの立ち下りではなく立ち上がりでしょうから、最終ビットのSCKの立ち上がりでRCVSERV割り込みが入り、SCKが立ち下がってACK/NACKクロック期間に入り、SCKが再び立ち上がるまで、の期間がSTOPビットを書き込むタイミングではないかと思います。

このように考えると400kHzクロックの場合1サイクル分2.5uSがほぼSTOPビットを書き込める期間として使えます。ご指摘のように不感時間が1uS程度としても、無視はできませんがソフトの設計次第で対処できない期間ではないと思います。

また、Epocheさんのコメントにありましたが、HRMの「Clock Stretching During FIFO Overflow」に記載の通り、FIFOがFULLであればクロックがストレッチされますので、さらに余裕は増えます。

1. 送信
こちらは確認が必要ですね。
動作を実際に確かめていないのであくまで予想ですが、最後のデータがFIFOから送信レジスタに転送されてFIFOが空になったときではないかと思います。この時にXMTSERV割り込みが入るでしょうから、そのタイミングかなと。。。
この割り込みが入った時点では、FIFOから送信レジスタに転送された最後のデータが送信中だと思いますので、ホリエさんが仰るように、「ただちに」については送信時には問題にならないだろうと思います。

ホリエ 回答番号 16
タイトル
もうすこしお願いします
ポイント
pt.
アクセス8234
投稿日時12/09/01 14:45
回答お願いします。

やはり最後のデータで「すぐに」STOPビットを立てるということですが、もうすこし詰めさせてください。

1. 送信時
STOPビットを立てるのは、最後のデータをFIFOに書いたときでしょうか、それとも、最後のデータがFIFOから送信レジスタに転送されてFIFOが空になったときでしょうか。ご存じのとおり、TWI
はNバイトの送信にN+2回の送信割り込みが発生します(1回はMCOMP)。
「ただちに」については送信時には問題にならないだろうと考えています。


2. 受信
最後のデータを受信したら「ただちに」STOPビットを立てるわけですが、「ただちに」の最悪値はどのように決まるのでしょうか。
割り込みレイテンシはBFコアの割り込み応答速度だけではなく、RTOSやアプリの割り込み禁止区間の長さで決まります。つまり、個々の最悪地が直接システム設計に影響してきます。RTOSの場合APIや割り込みエントリ/エクジットの割り込み不感時間はBlackfinの場合1uS程度だと考えられますが、400kHzクロックの場合1サイクル2.5uSですので、決して無視できない値です。

しつこいようで心苦しい限りですが、よろしくお願いします。


Epoché 回答番号 15
タイトル
DCNT=0xFFの場合のSTOPビット操作
ポイント
pt.
アクセス7983
投稿日時12/08/29 23:48
長らくお待たせしておりまして申し訳ございません。
回答としましては、、
割り込みハンドラの中で、意図するデータ量に達したかどうかチェックして、達していたら、「ただちに」STOPを1にするという処理で、間に合うというホリエ様の当初のご推察の通りの回答ございます。
ご査収のほど何卒よろしくお願い申しあげます。

Epoché 回答番号 14
タイトル
ご指摘の通りです。
ポイント
pt.
アクセス7987
投稿日時12/08/24 00:05
まったくご指摘の通りです。
お時間がかかってしまっており申し訳ございません。
担当への私の初動が悪かったかもしれません。。。

(According to HRM 12-30)
>Setting DCNT to 0xFF disables the counter. In this transfer mode, data
continues to be transferred until it is concluded by setting the STOP bit.

The customer try to follow this description, but it not clear when should the
customer set STOP bit.

ということで、この点に絞って確認中でございます。
お時間がかかってしまって申し訳ございません。
回答を得次第ご報告申し上げます。


ホリエ 回答番号 13
タイトル
STOP bit
ポイント
pt.
アクセス8320
投稿日時12/08/23 23:54
こんにちは。

どうも担当の方が私の質問を理解していないように思えるのですが、それとも、答えるのを避けているのでしょうか。

Epocheさんはご存じのことですが、STOP直前のアクノリッジがACKかNAKかというのは、私にとっては質問ではなく指摘です。担当の方はこだわっているようですが、これはどうもBlackfinのTWI実装がI2C準拠か否かになりつつあるようです。

受信および送信終了時のSTOPビットについては、これもEpocheさんは理解してくださっているように、私の質問はDCNTを使わない場合についてです。DCNTを使えばできることはわかっていますが、これでは比較的小さなバイト数の転送しか取り扱えないため、DCNTを使わない転送が必要になります。

BF592のマニュアルにはDCNTを使わない場合にはSTOP bitによって止めるまで送信が続くと明示してありますので、そのタイミングを知りたいというのが最初からお聞きしている点です。

よろしくお願いします。

Epoché 回答番号 12
タイトル
TWIとI2Cのはざまで
ポイント
pt.
アクセス8132
投稿日時12/08/19 16:31
中間報告ですが、、
担当者からは以下の回答を得ておりますが、2つの点が明確になっていません。

STOPビットはユーザーがコントロールできるものではなく、スレーブから最後のデータ(DCNTがゼロ)を受け取ったら、BF592はACKに続いて、STOPコンディションを自動的に、すぐに送ります。このACK→STOP信号の送出でスレーブは、これ以上データを送らなくても良いことを知る。
■疑問点1)つまりNACKでなくてもACK→STOP送出で、メモリがデータ送信止めるので良いというTWIの実装?

リピートスタートでは、
ACK→Start(DCNTがゼロでない場合)、
ACK→Stop(DCNTがゼロの場合)、
いずれの場合でも、ユーザーはRSTARTとDCNTをプログラムすることで転送を開始することができます。
したがってBF592はSTOPコンディションの送出タイミングをすればよいか、DCNTがゼロになることにより知ることができます。したがって、割り込み野中でSTOPコンディションをユーザーが操作する必要はありません。
■疑問点2)DCNT未使用(DCNT=0xFF)の時は?

以上です。
引き続き確認を続けます。

Epoché 回答番号 11
タイトル
age
ポイント
pt.
アクセス7814
投稿日時12/08/14 11:36
まだ確認中でございます。夏休みかな。。Pushいたします。m(_ _)m

Epoché 回答番号 10
タイトル
ご指摘の通りです
ポイント
pt.
アクセス7957
投稿日時12/08/06 18:27
失礼いたしました。ご指摘の通りI2Cの仕様では、マスタが受信の時には、もういらないというのをNAKとしてスレーブに伝える必要がございます。
BF592はNACをSTOPビットを出さなくてはいけないはずですね。。。さらに確認いたします。申し訳ございません。少々お待ちください。

ホリエ 回答番号 9
タイトル
正しく指摘が伝わっていないのかもしれません
ポイント
pt.
アクセス8158
投稿日時12/08/05 20:37
I2CのACK/NACKはマスターかスレーブであるかにかかわらず、受信側が「もう受信しません(できません)」という状態のときにNACKを返すはずです。

言い換えると、最後の受信バイトの受信が終わるとACKではなくNACKを返さなければなりません。

NXPのI2C仕様書には以下のように書いてあります。

If a master-receiver is involved in a transfer, it must signal the end of data to the slave- transmitter by not generating an acknowledge on the last byte that was clocked out of the slave. The slave-transmitter must release the data line
to allow the master to generate a STOP or repeated
START condition.

http://www.nxp.com/documents/other/39340011.pdf

この件質問ではなくドキュメントの不具合の指摘のつもりでしたが、本当にACKが返るとしたら、まずいのではないでしょうか。

Epoché 回答番号 8
タイトル
英文ママで失礼します。
ポイント
pt.
アクセス8039
投稿日時12/08/04 14:15
【ご質問】
なお、蛇足ではありますが図12-7の最後のACKはNACKの間違いかと思います。
【回答】
No, the information in the figure is correct. It is the ACK asserted by the Blackfin master. Since it is a Transmit followed by receive operation, the master has to acknowledge the reception of data from the slave.

ということで、ご指摘のNAKの送出というのは不要なのではないかと。
取り急ぎまして。。

ホリエ 回答番号 7
タイトル
次ページに流れたのであげておきます。
ポイント
pt.
アクセス7811
投稿日時12/08/03 21:35
回答お待ちしております

ホリエ 回答番号 6
タイトル
Receive時のSTOPビットタイミングについて
ポイント
pt.
アクセス8011
投稿日時12/07/25 22:11
Epoché様

ご回答ありがとうございます。

さて、いただいたご回答にもう少し質問させてください。

> ご懸念されている受信時は、クロックがストレッチ
> され、STOPビットが書かれる前にステートが遷移
> することはございません

この点ですが、まだ少しイメージがつかめません。最初の質問で仮定したとおり、受信割り込みはFIFO内のデータが1あるいは2バイトの時に発生するよう設定する予定です。これはTWI_FIFO_CTLレジスタのRCVINTLENビットを0にするということです。

HWR 1.0 の12-36ページによれば

[0] An interrupt (RCVSERV) is set when RCVSTAT indicates one ortwo bytes in the FIFO are full (01 or 11).

ということであり、FIFOの長さが短くなると言うことではありません。つまり、最後のデータの受信割り込みが発生した時点でもFIFOには余裕があります。割り込みが発生した時点ではSTOPビットを立てていませんから、「受信可能・非STOP条件」ということで、TWIペリフェラルの内部ステートマシンはクロック・ストレッチせずACK送出に遷移しているのではないでしょうか。

細かい事で申し訳ありませんが、この点を把握しておかないと割り込みハンドラを設計できません。よろしくお願いします。

ホリエ 回答番号 5
タイトル
Repeated Startについて
ポイント
pt.
アクセス8093
投稿日時12/07/25 22:01
Epoché様

ご回答ありがとうございます。RSTARTの件、クリアになりました。HWRには最後の送信割り込みでRSTARTを1にするよう記述してありますが、あまりにも厳しいタイミングである気がしたので質問した次第です。

Epoché 回答番号 4
タイトル
repeated Startについて
ポイント
pt.
アクセス8141
投稿日時12/07/25 19:39
【ご質問】
TWI_MASTER_CTLのRSTARTは最初から1にしておけばSTOPビットを1にすることで自動的にREPEATED STARTに遷移すると仮定してよろしいでしょうか。
【回答】
RSTARTビットはDCNTやTWI_ENABLEの設定と同じシーケンスで設定していただければ良いようです。


すでにご覧頂いている場合はご容赦ください。
下記URLはEngineerZoneでのBF592とEEPROを接続するトピックです。
http://ez.analog.com/message/26686#26686

誤植のご指摘もありがとうございます。報告し次回改訂時に修正させるようにいたします。


Epoché 回答番号 3
タイトル
確認いたしました!
ポイント
pt.
アクセス8157
投稿日時12/07/24 16:33
ご推察の通り、送信時はXMITSERV INTERRUPTのハンドラ、受信時はRCVSERV INTERRUPTハンドラにてSTOPビットの操作を行なってください。ご懸念されている受信時は、クロックがストレッチされ、STOPビットが書かれる前にステートが遷移することはございません。

取り急ぎましてご質問の一部ですがご査収のほどよろしくお願い申し上げます。

ホリエ 回答番号 2
タイトル
よろしくお願いします
ポイント
pt.
アクセス8177
投稿日時12/07/20 12:22
Epoche様

お返事ありがとうございます。確認してくださるとの事で、お待ちしております。

ちなみにTWIのカウンターを用いれば問題なく状態遷移できそうだということは確認しています。しかし、この方法は254Byteまでしか伝送できません。ADCやDAC程度ならそれでいいのですが、EEPROMに大きな設定データを格納するときなどは心もとないので、質問した方法で設計しているしだいです。

Epoché 回答番号 1
タイトル
お問い合せありがとうございます!
ポイント
pt.
アクセス8177
投稿日時12/07/19 23:30
ご指摘の件、ムムムと考えこんでしまいました。確認いたします。他社の同じペリフェラルはどうなんだろうと調べてみると、Blackfinのようにシーケンスの中でセットするものではなくて、他のビットと組み合わせて、モードとして最初に設定するような使われ方でした。(つまり参考になりませんでした)
少々お時間をいただければ幸いです。

スレッド一覧に戻る



コメント投稿

* コメントの投稿にはログイン(ユーザー登録)が必要です。


タイトル

* 50文字以内
『初心者でも大丈夫!』
(記事の内容が初心者向けの場合はここにチェックをしてください。)
本文

* あと6000文字

ファイル1
ファイル2
ファイル3

* 5MBまでのGIF, JPEG, PDF ファイルが投稿できます。

* 入力に時間がかかると、セキュリティのためにログイン情報が破棄されて書き込みが処理されないことがあります。投稿内容確認ボタンを押す前に、一旦文章をクリップボードにコピー(本文入力欄をクリック後Ctrlキー+A、Ctrlキー+Cと連続で押す)して、再貼り付けできるようにしておいて下さい。

ゲスト 様
投稿する場合はログインして下さい。 初めての方はこちらからご登録ください。

お知らせ
ユーザーランキング

* ランキング情報は約24時間おきに更新されます。


  個人情報保護方針会社情報お問い合わせ

copyright(c) 2010 - 2017 ITmedia Inc.