Darkside(リンクエラー修正しました)

2018年7月14日(土) 21:20

あくまで手段

 I2Cでは、常時Lという問題は解消された。だが、途中で止まってしまう。
 LCDに対して送るコマンドは、3バイト1組である。

1)スレイブアドレスを送信
2)0を送信
3)コマンドを送信

 ここで、2)までは終了するが、3)が終了しない。送信の内部にLチカを仕込んで調べると、送信できているがスレイブがACKを返して来ない。1)と2)ではACKが返って来ているのに、3)だけ返って来ないのは意味不明。
 そこで、オシロの出番。

 なぜか、1)が捉えられない。2)と3)だけ捉えられている。そして、2)だけでなく3)も、ACKは返って来ているように見える。となると、問題はソフト側だ。ソフトのちょっとした命令入れ替えで動作したりしなくなったりするのがI2Cである。動作例はネットにいろいろ転がっているが、コピペしてもどこかに障害が出てなぜか動かない、というのがI2Cあるあるだ。

 ACK受信までの手順を試行錯誤していると、遂に液晶表示に成功!
・・・なのだが、異様に薄い。かろうじて文字が読めるぐらいで、コントラストを最大限に調整しても写真を撮れないぐらい薄い表示にしかならない。
 オシロでは、

 一部の波形が妙にクリッピングされている。しかも、ソフトを元に戻してもクリッピングは直らない。それでも極薄表示なりに液晶が使えるのだから、とオシロを外したら表示されなくなった。
 オシロのプローブを付けると、液晶に極薄表示される。プローブを外すと、何も表示されない。プローブを外したときのI2C波形は、当たり前だが不明である。どこの量子力学だよ!

 今日も繰り返すが、液晶表示とかI2C使用とか、あくまでも手段である。目的ではない。だからもう開き直って、液晶表示させたい時はオシロを付けることにした。ハード周りに何か実装上の問題があるのだろうが、究明している暇など無い。
 必要ならオシロを付けて表示させデバッグする。

 1系統だけになったので12ビットに戻したADCが、ちゃんと読めていることを液晶表示して確認。
 しかし別の問題として、sprintf が猛烈にメモリーを消費する。この命令1つ増えただけで、プログラムエリアの37%ぐらいを食ってしまうのだ。確かにコード量が多い関数だというのは想像が付くが、逆に言うと dsPIC33 のプログラムエリアが小さ過ぎる。
 やはり、dsPIC33 にはブラシレスモーター制御のみを任せ、ドリル戦車のメインCPUは STM32F4 にするのが無難だ。

written by higashino [ドリル戦車] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

Comments

TrackBacks

Darkside(リンクエラー修正しました)

Generated by MySketch GE 1.4.1

Remodelling origin is MySketch 2.7.4