今更かもしれないが伝助日記にて新世代 8051系マイコン入門ハンドブックのサポートサイトの存在を知る。そしてその流れで Silicon Laboratories の Web ページを訪れる。ああ Evaluation Kit を片っ端から発注したくなってしまった。今はホントにその気になればクリック一つで買えるんだよな。だからこそ理性が重要だよな。
いつもの BIGLOBE ストリームが様変わり。利用者登録、CM挿入、全画面表示無し。キビシイな。無料で見られるということは、そういうことなんだよな。いままでがアリエナイ展開だったんだよな。
明日から4月だ。自分の環境が変わらないのなら、自分自身が変わろう。真面目に。誠実に。等身大で。
思いがけないアルコール消毒。個人が出来ることとは、1人で悩みまくって考えることと、他人とのコミュニケーションとの掛け算なのかと思った。と言うことは「みーんな悩んで大きくなったぁー」の野坂昭如状態だけが成果を生み出す訳じゃないと言うことか。まあ両輪なんだろうな。ああ来月からは期待に応えられるだけの活動をしよう。自分に自信を持とう。
という訳で READ_BYTE の後、読み出した値を WRITE_BYTE で書き戻してみる。途中から 0xFF になることは無くちゃんとダンプ出来るようになった。テストは内蔵レジスタ領域で行っているので、もしかしたらどこかのレジスタへの書き込みがトリガなのかもしれないが、しかし気を許すと直ぐに 0xFF になってしまうので、やはり何かしらの時間経過が関係するようだ。ホントか?とりあえずイカサマ野郎としては、これで進めよう。確認すべきことは沢山あるのだ。
スゴイよ!新世代 8051系マイコン入門ハンドブックだよ!夢の C8051本だよ!しかも著者が中島千明氏だよ!イントロダクションの PDF を読んでいたら、あの 2001年 10月のコーフンがよみがえってきた。初心に帰ろう。マイコンは理屈ヌキで楽しいんだ。
BDM との格闘が生活の一部になってきた。TBDML のソースを見る。限られたリソースの中でアクロバティックな解決策を取っていることが分かった。少し気が楽になった。しかし違うな。同じイカサマでも真面目に、抜け漏れなくイカサマを貫いている。イカサマは言訳の道具ではない。如何に無駄を抑えるかマージンを有効に活用するかなんだろうな。その結果イカサマからホンモノが生み出される。所詮自分がやっているのはイカモノの生成か。
そして BDM との格闘はいよいよ現物を、正解を見てみるステージに。ご好意を有効に活用しよう。短い時間でキモを掴もう。
工学社の吉野のロボット製作日誌を見て衝撃を受ける。中味をパラパラと見て考える。何だろうこの衝撃は。他人のためという甘い誘惑から如何に逃げるかを考えているつもりではあるが、まだ隙があるということなのか。
BDM との格闘はまだまだ続く。TBDML 添付資料の References から S12X_BDM V2 Block Guide にたどり着く。早速見てみる。4.5 BDM Command Structure が非常に興味深い。ここでは READ の際にアドレスを MCU に送信してからデータを受信するまでの間 150 BDC clock cycle delay を入れるように書いてある。今まで 16cycle しか入れていなかったけど、この時間が短いのが原因なのか?そういえば ACK pulse もこの間の時間を制御しているよな。ちょっと伸ばしてみるか。
という訳で delay 時間を延ばす。しかしあまり状況は変わらない。、むしろ delay 時間が長すぎると全く値が読めなくなる。やっぱり付け焼刃だったか。難しいな。そろそろ現物を、正解を見てみたいな。
今日は自分が相当な PC 依存症になっていることを再認識。去年からライフスタイルの改善に努めたが、また新たなスタイルを構築するか。まあそれしか選択肢が無いんだけどな。オダジョーのようにはいかないな。やっぱり劇団ひとりなんだな。
BDM との格闘は今日も続く。ACK pulse の確認を行っているうちに BKGD pin の処理のイマイチさが良く見えてきた。1-wire ってロジアナで見てもどちらが Hi-Z にしてどちらがドライブしているのかイマイチ分からないから難しいよな。時間軸で電流値もプロットしてくれると参考になるんだけどな。まあ内蔵 RAM への書込みも時々は成功したし、方向性は間違っていないはずだ。ここで踏ん張れるかどうかだよな。ちょっと基本に返ってみるか。世の中の BDM 実装を色々と見てみよう。
という訳で情報を漁る。今更ではあるが TBDML を見つける。そうかこれが以前 CircuitCellar 誌に載っていたアレか。68HC908JB8 だしソースも公開されているし、今更何をやってもこれの焼き直しになりそうだな。まあアレだ。自分はツールを作るのが目的じゃ無いんだよな。I/F を自分のモノにしたい衝動に取り付かれているだけなんだよな。ハカーと書けば聞こえはいいが、正直オカシイなオレ。
もう一度 HCS08 Family Reference Manual Volume 1(PDF) Section 7 を読み返す。そういえば ACK の理解を後回しにしていたな。READ_BYTE がらみだと、この辺がアヤシイ。しかし 0x1807 の SDIDL レジスタ値を読んだロジアナ波形を見直しても ACK pulse のようなものは返されていない。これは自発的に ACK_ENABLE を発行してみるか?
まだまだやれることは一杯ありそうだ。HC12 や ColdFire の情報を漁れば、ヒントが沢山見つかるかもしれない。でも結局1週間ではメモリダンプすらママならなかったな。これが実力か。まあここでのチャレンジの過程が、将来やる気を失った時の自分を導いてくれることを信じよう。明日からはいつもの物欲モードも書いていこう。
これで受信処理を確認する術が整った。早速受信処理を仕込み受信した値を送信してみたところ、0x09 が送信されていることがロジアナ波形で確認できた。これで BDC command は OK だ。ちょっと時間がかかり過ぎたがようやくここまで来た。
という訳でいよいよメモリダンプに突入。0x1800〜0x184F のレジスタの値を READ_BYTE で読み UART で送信する処理を仕込み動かしてみた。すると途中まではそれらしい値が表示されるのだが、途中から値が全て 0xFF になってしまう。再度 0x1800 から値を読み直しても 0xFF のままだ。これは一体何だ?どうすればいいんだ?
シミュレータでの動作確認中に波形を見たくなる。シミュレータの出力結果を波形に変換するのにスプレッドシートを使ってみよう。という訳で前から目をつけていた Gnumeric をインストール。シミュレータの出力結果をとりあえず手作業で加工することで 0xE4 や 0xAA を送信する時の波形を見ることが出来た。
なかなか前に進まないが、ここでくじけずに出来る範囲で作業を続けよう。メモリダンプくらいまでは進めたいものだ。
ここでズルズル引っ張らずにズバっとアセンブラによる記述に切り替えてみよう。まずはベタベタに nop を並べて BDC command READ_STATUS 0xE4 の送信と、加えて受信用のパルス生成処理を仕込む。READ_STATUS command への応答をロジアナで見ると 0x00 が返って来ているように見える。試しに 0xE4 ではなく 0xE5 を送信してみると MCU 側から返される値に変化が見られた。8MHz 固定ではあるが、まずはこれで攻めてみよう。
段々いつもの通りイカサマっぽくなってきたな。所詮実力はこの程度なのか。ここで自分を慰めるのはいつもの悪い癖だ。SofTec の PK-HCS08GB60 は USB-BDM を 12MHz の 68HC908JB16 だけで実装している。今の自分は、自分の力ではなく ATmega168 16MHz をブン回しているに過ぎない。ボクはあの人に勝ちたい。
という訳で Timer1 の Fast PWM mode を使ってみる。しかしシミュレータの動きがおかしい。確かタイマは制約があるよなと思い AVR Studio のシミュレータヘルプファイル Simulator.chm を見る。Known Issues によると 16-bit Timer/Counters にはいくつか問題がありそうだ。更に ATmega168 だと Timer2 もアヤシイ。
という訳で実基板で動かしてロジアナで波形を見てデバッグする。タイミングは良い。しかし狙った回数の PWM が出ない。色々と格闘してみたが、どうも分からない。貴重な時間をかなり消費。
という訳で一旦立ち止まって考える。まず JTAGICE を持っていない自分にとっては、シミュレータで動作確認できるかどうかでデバッグの効率が大きく変わる。結線の変更は後回しとして、とりあえず Timer0 で PWM 信号を生成するように変更しよう。それでもダメなら USB の時と同じように命令サイクル数を数えながらアセンブラで書いてみよう。
なかなか思い通りにいかないな。おまけに予期せぬことが色々起きてしまう。しかしここが踏ん張りドコロだ。本業や家庭のモロモロと共存しながらマイコンと格闘することが、マイコンを生活の一部にすることに他ならない。リアルな世界との戦いを楽しもうぜ。
続いては AVR 用プログラムの準備だ。RESET と BKGD を両方 Low にして MC9S08QG8 を active background mode に移行させ、SYNC コマンドを送った後 BKGD を Hi-Z にするだけの簡単なプログラムを作成。シミュレータを使って PortB が意図どおりに動いていることを確認。そして ATmega168 に書き込みロジアナで動作を確認。Fuse bit を変更し忘れて暫く時間を消費してしまったが、シミュレータで動かした自信は確かに無駄な確認作業を減らしてくれた。
SYNC コマンドで BKGD を Low にする時間は 512us 程度でも良いのだろうが、とりあえず 1ms としてみた。そして SYNC コマンドの後 MC9S08QG8 が BKGD を Low にしていることをロジアナで確認。この時間は手持ちのチップでは 14.67us だったが、BDC clock 128cycle 分なので BDC clock は約 8.7MHz となる。やはり BDC clock となる Bus clock は 16MHz Internal clock の半分と考えてよいと言うことか。
まずはここまで来た。次は実際に BDC command を送ってみよう。集中している時は邪念が払拭される。これだこれなんだ。本業の時間制約もあるので活動は若干低迷するかもしれないが、この先もバリバリ進めよう。自分が1週間でどこまで行けるのか、チャレンジだ。世の中はやれば出来ることダラケなのだ。
BKGD によるデータ転送はどうやればいいんだ?大枠としては BDC clock 16clk で 1bit のデータをやりとりするのね。Host から MCU への通信では BKGD pin を Low にして 10clk 後の BKGD pin の状態が送信 bit 値になるのか。これは PWM の Duty 比を変えてやれば良さそうだな。問題は MCU から Host への送信だな。Host が 4clk 分 BKGD pin を Low にしてタイミングを決め、今度は Target が BKGD pin を High にしたり Low にしたりするのね。Host としては 4clk 分の Low とその後の BKGD pin のセンスを両方やる必要があるので、コンペアマッチを2個使わないといけないのか。
まずやることを考えてみよう。最初は RESET だな。しかし RESET と BKGD pin を Low にする時間が良く分からない。USBMULTILINKBDM の User Manual を見ると RESET を 5ms、BKGD を 10ms Low にしている。BKGD を High に戻してから 20ms 後から command を発行しているのね。これは簡単に実装できそうだ。
次に command のやりとりだ。しかし BDC clock が良く分からない。何回も PDF を読んでみたのだが、酸素が足りないのかオツムが足りないのかイマイチ分からない。分からないものは仕方が無い。実際に動かして SYNC コマンドを送った時の波形をロジアナで見て、内蔵クロックで動く MC9S08QG8 の BDC clock がどのくらいになるのかを見てみるか。
何はともあれ実験環境を作ってみよう。まず MCU を RESET して active background mode に移行させ、何かレジスタの中身を読む所まで仕込もう。MC9S08QG8 の SDIDH:SDIDL が 0x009 固定なので、これを読むのが良さそうだな。
コミュニケーションがドライブ感を生み出す。人と喋るって大事だな。