IICA　NACK　につきまして

わわいです
NACKの送信方法ではなく、NACKの送信条件であれば、それはあなたが決めるものです。
一般的には、エラーが出た場合や、想定書き込みデータの最終バイトの送信時など、通信を中断／終了させる場合にNACKを送信しますな

チョコです。
そうですね，方法でなく，条件ですね。

>エラーが出た場合や、想定書き込みデータの最終バイトの送信時など、
エラー云々は間違いです。I2Cの仕様では「3.1.6 アクノリッジ（ACK） とノット・アクノリッジ（NACK）」に以下のように規定されています。

1. 転送されたアドレスのレシーバがバスに存在しない．つまりアクノリッジで応答する
デバイスがない場合。
2. レシーバが何らかのリアルタイム機能を実行中でマスタとの通信を行える状態では
なく、送信も受信もできない場合。
3. 転送の間、受信したデータやコマンドをレシーバが理解できない場合。
4. 転送の間、レシーバがそれ以上データバイトを受信できない場合。
5. マスタレシーバがスレーブトランスミッタに対し転送の終了を伝える場合。

ここは，スレーブなので，通信を行えない状態でNACK応答することになります。

チョコ様、わわい様
ご指導ありがとうございます。
コード生成プラグインで生成されたドライバ部分の「iica0_slave_handler」の内容を見ていると、
明示的に「ACKE0 = 0」としているところがなかったので、勝手な思い込みがありました。
ご指摘のとうり、条件の内容を確定するのが、先であることが理解できました。
まったく、思慮がたりませんでした。

ただ、「iica0_slave_handler」内では、「ACKE0 = 0」が無いということは、「iica0_slave_handler」に入るタイミングでは、「ACKE0 = 0」になっていて、ACKが出したい場合に「ACKE0 = 1」にすると理解してよいのでしょうか？
つたない、再質問で申し訳ありません。
よろしくお願いします。

チョコです。
>ただ、「iica0_slave_handler」内では、「ACKE0 = 0」が無いということは、「iica0_slave_handler」に入るタイミングでは、「ACKE0 = 0」になっていて、ACKを出したい場合に「ACKE0 = 1」にすると理解してよいのでしょうか？

いいえ，違います。
通常，スレーブではNACK応答することはない（ACK応答しかしない）ので，コード生成では初期設定（R_IICA0_Create）でACKE0 = 1;と設定されています。
前回のPOSTで示したように，スレーブは通信できないときだけNACK応答します。つまり，通常は常にACK応答するようなプログラムになっています。

追伸

RL78に搭載のIICAはスレーブアドレスはハードウェアで検出して自動でACK応答するようになっています。

ACKE0が有効になるのは，データ受信時のみで，そのときにACKE0の設定に応じて9クロック目でACK/NACK応答になります。

チョコ様
レスありがとうございます。
「R_IICA0_Create」内でACKE0 = 1;　となっている部分確認できました。
なるほど、IICAのスレーブでは、常にACK応答になること、理解しました。

ただ、RL78/G13のマニュアルにおける、図１３－３２を見ている限りでは、関連の割り込み（INTIICAn ）は、ACK応答時のCLKの立下りで起こると記載されています。

＞ACKE0が有効になるのは，データ受信時のみで，そのときにACKE0の設定に応じて9クロック目でACK/NACK応答になります。
ご指摘内容の処理を行うには、ACK送出前に関連割り込みが入らないと処理ができない気がします。

図１３－３２の内容より、関連割り込みは、ACKタイミングのCLKの立下りで入るとすると、NACKにしているのは、IICA内部にて、エラーを判定し、ACKを出力している様に思われます。
ご指摘のデータ受信時にも同様のタイミングチャートになっているように思われます。

IICAの動作特有のもののような気がします。

それとも、マニュアルの見方がたらんのでしょうか？

チョコです。
>ご指摘内容の処理を行うには、ACK送出前に関連割り込みが入らないと処理ができない気がします。

ACK/NACK応答を切り替える場合（マスタ受信の場合）には，WTIM0の設定でINTIICAとウェイトを8クロック
目にします（コード生成ではスレーブも同じ設定にしていますが，それは不要です）。
これで，マスタは8ビットのデータ転送が終わった段階でINTIICAが発生し，受信したデータが最後のデータ
かどうかを判断して，ACK応答かNACK応答かでACKE0を設定して，WREL0でウェイトを解除して送信側
（スレーブ）にACK/NACK応答します（NACK応答の場合には，マスタは9クロック目でのINTIICAに切り替えて
からウェイト解除します）。この動作は図13-33に該当します。

図13-32を見ると，スレーブはACK応答だけなので8クロック目でINTIICAを発生させる必要がなく，9クロック・
ウェイト（WTIM0 ＝ H）に固定され，ACKE0もHに固定されています。
ACKの受信側（＝データの送信側）は必ず9クロック目でのウェイトにしておく必要があります（そうしないと
ACK応答の確認ができません。

>NACKにしているのは、IICA内部にて、エラーを判定し、ACKを出力している様に思われます。

そのような動作はありません。IICAでチェックできるのはACK応答があったかどうかです。どうもI2Cバスで
ACK/NACKはデータのエラー・チェックと誤解している人が多いようですが，I2Cのプロトコルにはデータの
エラー・チェックはありません。必要なら，上位のプロトコルでやる必要があります。

>マニュアルの見方がたらんのでしょうか？

図13-33（マスタ受信）のマスタ側と図13-32のマスタ側を比較すると，WTIM0やACKE0が変化しているのが
分かるかと思います（一つのタイミング図だけではなく，複数のタイミング図を比較してください）。

チョコ様
レスが遅れてしまい。申し訳ありません。
少し出張で出かけておりました。
大変ご丁寧な説明ありがとうございます。
出張の移動中、何回も読み直して、理解で出来ました。

>図13-33（マスタ受信）のマスタ側と図13-32のマスタ側を比較すると，WTIM0やACKE0が変化しているのが
>分かるかと思います（一つのタイミング図だけではなく，複数のタイミング図を比較してください）。
この一文で、マスタ側を全く見ていなかったので、理解できていなかったことが判りました。
ありがとうございます。
この事例は、マスタ側受信ですが、マスタ側送信の場合もこれまでのご説明内容よりマニュアルを良く見直すと、
13. 5. 17 I2C割り込み要求（INTIICAn）の発生タイミング
（2）スレーブ動作（スレーブ・アドレス受信時）
（3）スレーブ動作（拡張コード受信時）
の内容がすっきりしてきました。
ありがとうございました。

>>NACKにしているのは、IICA内部にて、エラーを判定し、ACKを出力している様に思われます。
>そのような動作はありません。IICAでチェックできるのはACK応答があったかどうかです。どうもI2Cバスで
>ACK/NACKはデータのエラー・チェックと誤解している人が多いようですが，I2Cのプロトコルにはデータの
>エラー・チェックはありません。必要なら，上位のプロトコルでやる必要があります。
ここも、問題を探るうちにそうなんだと、理解させられました。
ACK/NACKで整合性返信をイメージしていたので、過剰な考えがうまれてしまいました。

すっきりしました。
ここ最近の悩みでしたので、助かりました。

ありがとうございました。
また、レスをいただきました皆様にもお礼を申し上げます。

わわいです
IICの動作を理解するには、CPUのマニュアルよりも、IICのEEPROMなどのデータシートを見ると、信号の解説が載っています。
その他、IICを使っているデバイスのデータシートを集めていろいろ見てみるといいんじゃないかと。
まあ、いろいろみてみればNACKをどういう用途で使ってるか、もわかってくるかとおもいます

チョコです。
I2Cについては昨年5月にかふぇルネのサンプルプログラム等に「I2C通信のまとめ」に投稿しています。
その「2.1.3 I2Cバスのプロトコルのとらえ方」に記載しているのですが，I2Cバスの基本的なプロトコルは
マスタが制御するが，その上でスレーブを制御するためにはスレーブの仕様に合わた制御が必要です。
つまり，大きな動きはスレーブの仕様を参照すべきです。わわいさんが言っているようにスレーブの仕様
をみるのが一番です（マスタはスレーブに合わせた制御を行う）。

こちらの方も参照してみてください（これ以外にもサンプルプログラム等にI2Cの情報があります）。

japan.renesasrulz.com/.../291

わわい様、チョコ様
最後まで、レスを入れていただき、ありがとうございます。

>IICの動作を理解するには、CPUのマニュアルよりも、IICのEEPROMなどのデータシートを見ると、信号の解説が載っています。
過去に、EEPROMとか、RTCなどでI2CをIICで使ったりしてるのですが、ばたばたとマニュアルのサンプル見ながら作っている状態で、いざ問題にぶつかると、迷路に入ってしまいました。
I2C、IICは、昔できたら・・・とおごりがあったように思います。
ここにポストしてよかったです。

>I2Cについては昨年5月にかふぇルネのサンプルプログラム等に「I2C通信のまとめ」に投稿しています。
ご紹介いただきました、資料は、こちらにポストするきっかけとなる、ものでした。
もしかすると何かあるかも・・・と思い、ポストさせていただきました。

先ほども書きましたが、I2CとかIICてよく使うので、できたからとほんと、たかをくくってたところがありました。まだまだ、やることはありそうです。ｗ

I2Cにつきましては、現在も他に少し変わったことをしてまして、本件とは別にポストしようか考えています。
もう少し、いろいろ考えてから、最後にポストさせていただきたいと思います。
自分でも少し考えないと思いますので。

ありがとうございました。

わわい様、チョコ様
最後まで、レスを入れていただき、ありがとうございます。

>IICの動作を理解するには、CPUのマニュアルよりも、IICのEEPROMなどのデータシートを見ると、信号の解説が載っています。
過去に、EEPROMとか、RTCなどでI2CをIICで使ったりしてるのですが、ばたばたとマニュアルのサンプル見ながら作っている状態で、いざ問題にぶつかると、迷路に入ってしまいました。
I2C、IICは、昔できたら・・・とおごりがあったように思います。
ここにポストしてよかったです。

>I2Cについては昨年5月にかふぇルネのサンプルプログラム等に「I2C通信のまとめ」に投稿しています。
ご紹介いただきました、資料は、こちらにポストするきっかけとなる、ものでした。
もしかすると何かあるかも・・・と思い、ポストさせていただきました。

先ほども書きましたが、I2CとかIICてよく使うので、できたからとほんと、たかをくくってたところがありました。まだまだ、やることはありそうです。ｗ

I2Cにつきましては、現在も他に少し変わったことをしてまして、本件とは別にポストしようか考えています。
もう少し、いろいろ考えてから、最後にポストさせていただきたいと思います。
自分でも少し考えないと思いますので。

ありがとうございました。