次は、HALを使わず素でI2Cを制御しようと思って、いろいろ試作しているけど、うまくいかない。I2Cの9DoFセンサ(LSM9DS1)と接続して、STM32からI2Cアドレスを出すタイミングでなぜかI2CバスがHi-Zになってしまうようで、STM32からクロックを出せないでいる。STM32のステータスレジスタもNACK等のフラグではなくBUSYのまま。だから、何か待ちに入ってしまっているようだ。なぜ待ちに入るのか？ センサからDELAY要求が来ているから？？？ TIMINGRのタイミング制御レジスタも4HMz版がないからちょっと設定が怪しい。。
上記がオシロの画面なのだが、、スタートコンディションを送り出した次のクロック操作の時点でバスを渡しているような印象だ。だから、、アドレスを渡すつもりがないのか、あるいは、スレーブモードに切り替わったのか？？
この時のレジスタの値は以下。これらのビットを読み解けば、I2Cのブロックがどういうつもりでウエイト？しているのかが分かるかも。。
(gdb) p/x *(0x40005400) $2 = 0x1 (gdb) p/x *(0x40005404) $3 = 0x120d4 (gdb) p/x *(0x40005408) $4 = 0x0 (gdb) p/x *(0x4000540C) $5 = 0x0 (gdb) p/x *(0x40005410) $6 = 0x42c3c7 (gdb) p/x *(0x40005414) $7 = 0x0 (gdb) p/x *(0x40005418) $8 = 0x8001 (gdb) p/x *(0x4000541C) $9 = 0x0 (gdb) p/x *(0x40005420) $10 = 0x0 (gdb) p/x *(0x40005424) $11 = 0x0 (gdb) p/x *(0x40005428) $12 = 0x0
何度かテストしていると、ステータスとして、ARLOが立ってる場合がある。これはアービトレーション喪失なのだが、
なぜアービトレーション喪失するか？？多分、センサがバスを使おうとするから（推測）。一発目のクロックで
センサーが何か応答して、バスをBUSYにしてしまい、STM32側からは送り出せず、アービトレーション喪失と判断して
バスをHiZにするのだろう。なぜBUSYにするのか？？センサ側にデバッグ手段がないと分からん。あるいは、、
I2Cバスアナライザとか。。
仕様書より
アービトレーション喪失の場合、マスタはスレーブモードに自動的に切り替えて、スレーブとしてアドレス指定された
場合は専用アドレスを確認応答できます。
スタートコンディションのホールドタイムは4.0usecらしいのだが、この波形を見ているとそれぐらいは時間猶予を持たせていそうだ。だったらセンサーにとって、バス仕様の何に文句あるのだろうか。。
