過去の恥ずかしい記録をまとめました。

デジタル降魔録TOPページ




-過去ログは古い順に並んでいます-

2007年9月1日(土)

朝からやってまっせ・・・



 Flash PICの続報7だよ。

 間接アドレッシング、CALL命令、RETLW命令も動き出したし、入出力ポートもアクセス可能になったので、プログラム次第ではマイクロスイッチの検知もできる。

 たとえば〝ちきどん〟をマニュアルで動かして、マイクロスイッチの1番のON/OFFの回数を7セグメント表示器に出すとか、逆に基板上の押しボタンスイッチをマウスで押すと〝ちきどん〟が動き出すとかプログラムできるよ。
 もちろんCALL命令とRETLW命令を利用した7セグメント表示器の表示データのテーブル参照も可能なので、本格的なプログラムでも対応するはず。

 これで、ひと通りのシミュレーションができる。えへへへ。

 見てみたい方はコチラから。

 しかし!

 速度は遅いよ・・。2.5GHzのWindowsマシンでクロック60Hzぐらい。〝ちきどん〟を動かすと50Hzぐらいに落ちる。

 これは、笑ってごまかすしかない。

 それと、やはりプログラムの入力がやりにくい。1ラインずつ入力してエンターボタンを押す方法では、長いプログラムの入力が苦痛でしかない。

 たとえばマイクロチップス社で公表しているアプリケーションノートの算術演算処理プログラムを検証してみようと思っても、1ラインずつの入力では、やる気が出ないよな。
 やっぱり、ガバッとコピーして、Flash PICの上でドサッと貼り付けて、サッとアセンブルして即走らせる・・・。

 コレがいちばんですな。

 とりあえず、次の段階はテキスト入力したプログラムをFlash PICにドサッとコピーできるようにすることを目標にしよう。
 いまのとこは、ジャンプ先のラベルが使用できないのでアドレス直接入力なことと1ライン入力で辛抱です。
 あと、バグがあってプログラムのSaveもまだできない(恥)

 それでも1命令ずつのステップ処理ができるので、ウォッチウインドウでレジスタを見ながら処理の流れが良くわかる。
 これだけでもめっけモンです。





2007年9月2日(日)

今日もセッセとやってます・・・



 Flash PICの続報8だよ。

 今日は細かいバグの修整とFlash PICの配線図をこしらえた。HELPボタンを押すとイロイロな説明が出るようになっているのでぜひご覧ください。

 ついでにサンプルプログラムを二つほど読み込めるようにしてみたので、プログラムの参考にどうぞ。

 サンプルプログラム2は〝ちきどん〟のマイクロスイッチ3のONになった回数を7セグメント表示器に10進数で表示するという簡単なもの。

 処理の流れはこんな感じ・・・。

 サンプルプログラム2をロードしてRUNボタンを押すと、FLash PICは基板上の押しボタン(SW1)が押されるのを待つ。
 押さないといつまで経っても動かないのでご注意。

 押されると〝ちきどん〟が動き出し、後はマイクロスイッチ3がONになるたび、回数を数えるという動きをしている。

 本物らしいところは、マイクロスイッチがONになったあとOFFになるのを確認してから回数を加算しないと、正しく数えられない。
 1回のONを2回数えてしまうからだ。う~ん。本物らしいねぇ~。

 ちなみに、マイクロスイッチはチャタリングは起きないので安心して。そこまでシミュレートしていないよ。ぷぷっ。




2007年9月4日(火)

つぎ行ってみよう・・・


 Flash PICを次の段階にすすめる準備を始めた。

 次の段階というのは、ソースプログラムをテキストデータとして直接キーボードから打ち込んで、それをアセンブルしてFlash PICを動かすというもの。

 こうすると、別のエディタやWindows付属のメモ帳などでこしらえたものをコピー・貼り付けで移動ができるし、何より長文のプログラム作りに耐えれるようになる。サンプルプログラムもテキストデータになるのでダウンロードも可能になるし、他の人が作ったプログラムを読み込めるようにもなる。

 今の方式では苦痛なだけで、やる気が起きない。
 次の段階になって初めて完成と言えるだろうね。

 できたら・・・の話だけど・・・。(心配)





2007年9月6日(木)

量産開始・・・


 本日、〝SH2〟(仮名)の量産基板が納品された。今回はデータ化けのトラブルがありヒヤヒヤもんだったが、一応ちゃんとできて来た。

 昔はアートワーク後のデータはフロッピーに入れて、完成時の基板の2倍寸のハードコピー(プリントアウト)を、面ごとに撮ったやつと一緒に基板屋さんに郵送していたのでデータ化けは無かった。
 ところが、最近はデータだけをネットで送信するようになっている。小心者の私にとってはこれが気になる。データ化けしたときのトラブルが怖くてしょうがなかった。そしたら案の定データ化けが起きて、2週間ほど前に先方から連絡が入ったのだ。

 担当者に聞くと「こんなことは稀にしかないのですが・・・」とのこと。稀にしかなくても、あったらあかんやんか。うちの会社は、試作抜きのいきなり量産方式なんやから、不具合のある基板が何百枚も出来たらど~すんの。

 今回のデータ化けは基板四隅の取り付け穴の1個が、基板の中央付近に現れたそうで、なんぼなんでもこんなところに基板の取り付け穴はこんやろ・・・ということでデータ化けが見つかったそうだ。

 取り付け穴でなくて、部品の小さな穴の1個が移動していたら、と想像すると冷や汗が出る。恐らくその部品は基板に挿入できないし、その間違った位置に移動した穴が他のパターンの邪魔をして回路はムチャクチャになっていたはず。

 恐ろしや~。なんまんだぶ。なんまんだぶ。

 みなさん。あんまり機械を信じたらだめですよ。

 で・・・。納品された〝SH2〟の基板だが、部品を入れて起動させるとすんなり動いた。

 あぁ~よかった。とりあえず神様に感謝。〝あ~めん〟





2007年9月8日(土)

仕事バカ人間誕生・・・


 変な夢で目が覚めた。

 おわん型の容器に入ったパチンコ球風の金属の球の数を数える機械を作る夢だ。
 夢なのでおわん型の容器には意味は無いだろうが、何か気になって起きてからしばらく布団の中で考えていた。

 個々の重さは同じようだから全体の重みを測って1個の重さで割るか?
 それともレールに流してカウントするか・・・。でもそうするとハードにコストが掛かるし、結構悩むなぁ・・・。って!夢ですから!

 頭抱える必要はないぞ!あほ!





2007年9月11日(火)

OEMが・・・


 今日、OEMをお願いしたいと、ある会社の社長さんとその担当者さんが数人やってきた。
 簡単にいうと、その会社の商品を開発してくれという依頼である。

 部屋に入るなり担当されている方が、鞄から企画書を持ち出して熱く説明されていたが、内容はセキュリティ関係の商品なのでここでは公表できない。ただ、この手の話はしょっちゅうやってくるが、ほとんど見積もりの段階で流れてしまう。みなさん安く考えているようだ。

 商品開発のほとんどは時間で、それが経費に入るということが頭から抜けているようだ。

 ハードウエアの方だけでも、回路設計・試作、そしてプリントパターンのデザイン、量産基板の作成、部品調達、実装作業などがある。
 ソフトウエアの方はアルゴリズムの組み立て・検証、プログラムのコーディング、バグ取り、ロケテストなど、こちらにもたくさんの工程がある。

 どうも、単純に作業をこなせば出来上がってくると思われているようだ。
 たしかにそういう工程も後半にはあるが、何も無い状態から目的のモノにカタチ創っていくという重要な工程があることに気が付いて欲しいな。

 特にソフトウエアなんてカタチすら無いんだよ。ハードがそのとおり動くからソフトウエアの存在が明らかになり、ソフトが正しく動くことでハードウエアが生きてくる・・・。この二人三脚が一番重要で時間が掛かるのに・・・。

 こっちは小さな脳みそを駆使してひねり出しているんだよ。ほんと・・・。

 この工程にも費用が掛かるということを察していただけないようで、いつも話は流れてしまう。

 たぶんこの話も尻切れトンボになるだろ~ね。


 話は変わって、Flash Picのプログラムをテキスト入力で行うという方式は順調に進んでいる。これで、プログラムの入力が一気に楽になるよ。

 PICのプログラムの検証がどこまで実用的にできるかが楽しみ・・・。うふふふ。




2007年9月13日(木)

うれしいような、迷惑のような・・・


 机の上に大きな段ボール箱が置いてあった。聞くと新しいパソコンが支給されたそうだ。

 えっ?今のパソコンまだ2年も使ってないよ・・・。別に処理速度も遅くないけど・・・。

 箱を開けるとデュアルコアのペンティアムマシンが出てきた。
 おぉ。デュアルコアだ! ちょっと欲しかったかな・・・。

 マシンを箱からゴソゴソ出していると社長がニコニコして横に現れた。本人は機嫌よさそうにしているがコチラはたまらん。
 この忙しいのに今までのアプリケーションを全部この新機種にインストールし直さなければいけないんだよ。わかる?社長。

 なんてことは口が裂けても言えない。機嫌を損ねて取り上げられるのもやだし・・・。

 「うれいしいなぁ」なんて言葉を連発して子供がクリスマスプレゼントを開ける仕草にも似た感じで社長の前でアピールする。

 なんかなさけない・・・。

 立ち上げて軽く動かしてみた。少しは速くなったように感じられるが、まだデュアルコアの感激は無い。
 50MBを超える画像データの編集か、部品点数の多い基板のアートワークでもしてみないとわからないだろうな。

 しかしそれを動かすにも、ハードディスクの中は空っぽ状態。

 冗談じゃないぜ。MPLABもエディタもICE も・・・それからアートワーク用のアプリケーションソフト、フォトショップ、イラストレーター、ワードも何もかも全部インストールからやり直しやんか。
 おっと、いままで作ったソースプログラムや開発ドキュメントの引越しはだれがやると思ってるねん。パッケージのデザイン関係や取り説のデータなんてどれだけあると思ってんの。
 こんなんやったら、はやくネットワーク化してくれ~。いつも言ってんじゃんかぁ。
 それか、せめて外付けのハードディスクを買ってくれ~。

 でも、正直うれしいかな・・・。

 うれし、悲しい一日でした。





2007年9月14日(金)

えっ?・・・



 昼過ぎ、外付けハードディスクが届いた・・・。

 えっ・・・? 

 このホームページ誰かが見ていて社長にチクったのかな?

 タイミングが良すぎやしないかい?
 もしかしたら、もしかする。

 ま、データの引越しは楽になるけどね・・・。





2007年9月17日(月)

進化したよ・・・


 テキスト入力を可能にしたFlash PIC(Rev2.2)のお披露目だ。

 その前に初めてこのホームページを見た方のために説明します・・・。

 Flash PICとは、仮想のPICデバイスを搭載したトレーニングボードをFlashプレーヤーを使ってインターネットのブラウザ上で実現しようというものなんだ。プログラムを入れてRUNボタンを押すとそのプログラムに沿ってトレーニングボードに載っている部品がコントロールできるんだよ。これなら半田ごても電源の心配も要らない。ただし、手に持って触れることは出来ない。だって絵だもんね。・・・( ´艸`)ムププ

 で、前回のRev1.0と比べてどう進化したか・・・。

 まず、テキスト入力でプログラムが書けるようになった。
 ソースプログラムウインドウにプログラムをキーボードから入力して〝Build〟ボタンを押すとアセンブルされて隣の逆アセンブルウインドウに表示される。

 もちろんエラーがあればエラー行の指摘が出るので修整することになる。
 MPLABを使用したことのある方ならすぐに使えると思う。

 次に14ビット幅の命令語を使用するPICに完全準拠させた。ミッドレンジPICなら大概のものはアセンブルできると思う。

 そして、ブレークポイントの追加。
 これで、任意の場所でプログラムを停止させてメモリー内を検証できる。


 まず、テキスト入力になるとどう便利かというと、他の場所で作られたソースプログラムをFlash PICのソースウインドウへコピー、貼り付けが可能になるんだ。
 これだけでもずいぶん楽しくなる。

 入れてある4つのサンプルプログラムのうち4番目は、マイクロチップ社で公表されているアプリケーションノートの算術演算処理からAN526、16進⇒10進変換処理をそのまま移植させている。

 詳しく説明すると・・・。
アプリケーションノートの算術演算処理のページに行くと、〝AN526 Source Code - PIC16C5x/PIC16Cxx Utility Math Routines 〟という欄があるので、そこのソースコードをダウンロードする。するとたくさんのプログラムが展開されるので、その中の〝B16TOBCD.ASM〟というのを開いて、そっくりコピーしてFlash PICのソースウインドウへ貼り付ける。

 あとは使用されているメモリー名をFlash PIC用のメモリ名に書き換えて〝Build〟ボタンを押してアセンブルする。エラーが出たら修整。
 文字列の検索・置換も可能なのでFlash PIC用のメモリー名に変更するのも簡単にできる。(まだ〝EQU〟などの擬似命令は動かないのでこれでがまん。Rev3では可能にするつもり・・・)

 このサンプルプログラムは、指定のメモリに書かれた4桁の16進数を10進数に変換して別のメモリ列に書き出すというものだが、Flash PICでもちゃんと動くことが実証された。

 ただし、速度は遅いよ。とんでもなく遅い。本物のPICなら瞬時で計算終了になるが、Flash PICだと11秒も掛かる。2.5GHzのWindwosマシンで確認している。Macでは未確認。
 でも、ワンステップ動作でメモリー内を見ながらプログラムの検証ができるのでこれは便利。

 早速見てみたい方はコチラか、あるいは〝FLASH AS1〟のページに入って右上部のFlash PICのボタンを押して動かして欲しい。

 詳しい取り説はFlash PIC内のHelpを押せば出てくる。





2007年9月23日(日)

それっ、もういっちょう・・・


 この連休で、Rev.3.0にグレードアップしたFlash PICの続報だ。

 ちびちびアップしてないで、時間を掛けて一気にすればいいのに・・・と思われるかも知れないが、ブロックごとに作って行くという性格なんです。すみません。

 Rev.3.0からはアセンブラの擬似命令、〝org〟〝equ〟に対応するようになった。
 擬似命令というのは、CPUに対しての命令語ではなく、アセンブル語をCPUの命令に変換してくれているアセンブラというアプリケーションに対して行う指示のようなもので、CPUの命令語とは異なる。

 ややこしいね~。

 他にもイロイロ擬似命令はあるけど、この二つでほとんどまかなえる。
 Rev.1.0の不便極まりない命令語選択式から進化して、テキストエディタ入力に加えて擬似命令の対応で、本格的なPICアセンブラになってきた。

¶ 別の場所で作られたPICのプログラムをFlash PICへ移す方法…

 Flash PICのアセンブラがどこまで実用になるか、試験する意味も込めて、例のマイクロチップ社で公表されている算術演算処理の中から〝BCD2BIN.ASM〟を選んでみた。

 これは、別の場所で作られたソースプログラムをFlash PICに移してちゃんと動くかの検証になる。成功すればシメシメだ。

 〝BCD2BIN.ASM〟というプログラムは、5桁のBCDコードされた10進数を2バイトの16進数に変換するもの。ちょうどサンプル4の逆になる。

 では、早速やってみよう。
 まずFlash PICのソース内を〝消去〟ボタンを押して、ヘッダ部分だけの初期状態に戻す。
 ヘッダ部分というのはのFlash PICのコア内部にあるファイルレジスタのアドレス設定を予めしてある部分で、PICでいうなら〝#INCLUDE "P16F877.INC"〟にあたる部分がソース上に展開してあると思ってもらっていい。ようは、INCLUDE擬似命令はまだ使えないのでソース上に書いてある。

 初期状態のソースで 〝org 0x00〟から下は入出力ポートの初期設定なので今回は必要ないから削除する。

 〝BCD2BIN.ASM〟をメモ帳で開き、全文をコピーしてFlash PICのソースウインドウの〝org 0x00〟から下に貼り付ける。

 Flash PICでは、いまのところひとつの命令はウインドウの右端までで完結していないとだめ。2行に折り返すとエラー時の行番号が狂ってくるので注意が必要。
 プログラムコードだけなら普通は1行以内に収まるが、コメントが長くなると2行にまたがって折り返しが起きる。そういうときは、いちど改行してあらためて〝;〟を付けて書くようにすればよい。
 折り返しが起きたままにしておくと、エラーリストで示す行番号と実際にエラーが起きた行番号が異なってしまい混乱する。

 はっきり言ってこれはバグだ。商品価値が出ないほどのバグで致命的だ。
 現在対策案を検討中・・・。
 それまでは、ひとつの命令はソースウインドウの右端までに収めるようにしなければいけない。エライすんまそん。

 〝BCD2BIN.ASM〟のコメントもかなり長かったので1行内に収まるよう修整が必要だ。もっとも、長ったらしいコメントはプログラムに関係ないので、全部削除してもいいかもね。
 英語だし・・・。ぷぷぷ。


 今回はコメントは削除せずに修整だけを行って、とりあえずBuildボタンを押してアセンブルさせてみる。


 どしゃ~ん。エラーが21個も出た。なんじゃ?
 たぶん何かの命令が抜けていてFlash PICに合わなくて、そこから先が連続的にエラーになっていると思う。

 気を取り直して、最初のエラーがあるLine-17(17行目)を見てみると〝LIST P = 16C54, n = 66〟と書かれている。
 これはPICデバイスを何にするか選択する擬似命令だ。

 そりゃそうさな。Flash PICにはこんな擬似命令作ってないもんね。

 この一行をコメントとしてプログラム的には削除する。(先頭に〝;〟を付けるとそれ以降をコメントとみなす)
 他にも例の〝INCLUDE〟行があるのでこれもコメントにしてしまう。
 別に完全に削除しても良いが、元のプログラムに戻す時に楽なのでそうした。

 Flash PICは〝org〟擬似命令から以降にプログラムが書かれていると判断するので、貼り付けた〝BCD2BIN.ASM〟内の〝equ〟文が、〝org 0x00〟以降に入っているのでこれはまずい。これでは〝equ〟というCPUの命令になってしまう。当然CPUの命令ではないので〝Syntaxエラー(記序間違い)〟が出てしまう。

 〝equ〟の行をすべて〝org 0x00〟より上に移動させる。

再びBuildボタンを押してアセンブルさせてみる。


 だいぶ減ったが、まだ大量にエラーが出る・・・。なんで?
 いやいや、まだがっかりするのは早い。よ~く、ソースプログラムを見てみよう。

〝Line-58 ラベル名が見つかりません〟と出ているので、Line-58を見てみよう。

 Line-58にはこんなことが書かれている。

〝mpy10b〟はこの行にラベルを定義しているので、このラベルが見つからないといっているのか?
 いやちがう。"見つからない"といっているのだから、探しているということだ。
 たしかに〝mpy10b〟はラベルだが、ここに定義しているので〝探している〟ではない。「定義できません」とかのエラーなら話はつながるが・・・。

 じゃあ何を探している?

 続く命令はこれだ⇒〝andlw 0F〟
 定数(リテラル)で論理積を行う命令だが、〝0F〟が間違っている。
 Flash PICでは16進数を表す時は頭に〝0x〟をつけなくてはいけない。そうしないと数値ではなく文字と判断されてラベル名になっていまう。Flash PICは〝0F〟という文字列のラベルだと勘違いして、それを探しているのだ。
〝andlw 0x0F〟と書き直した。これで16進の0x0Fということをアピールできる。
 すぐにBuildボタンを押してみた。

 Line-58のエラーが消えた。よしよし。思ったとおり。

 続いてLine-60を見てみる。

 これはすぐにわかる。
〝STATUS,C〟の部分だ。〝STATUS〟は〝equ〟擬似命令で0x03と設定してあるので問題は無い。〝C〟の部分だ。
 〝btfsc STATUS,C〟とくればこれはビットテストの命令で、STATUSレジスタの何番目かのビットが〝0〟の時、次の命令をスキップするというもの。本来は〝C〟の部分に0~7の数字が入る。

 そうだった。Flash PICではビット位置の〝equ〟定義は出来なかった・・・。Flash PICから見れば〝C〟番目のビットなんて知ったこっちゃない。だからエラーになる。
 STATUSレジスタの〝C〟ビットといえばCarryフラグで0番目だ。だから〝C〟の部分を0に換えればよい。
 なぜ0番目になるのかは、PICの仕様書を見てみよう。

 う~ん。しかしまだ細かい部分に不具合が目立つね。次のグレードアップを待ってもらおうかな。もう時間がない・・・。仕事もしなければいけないもんね。

〝STATUS,C〟を〝STATUS,0〟に変更するのは簡単。〝STATUS,C〟の文字をコピーして検索ボタンの横のテキスト入力欄に入れる。
続いて下の置換ボタン横のテキスト入力欄に〝STATUS,0〟といれて「もうありません」と出るまで〝連続置換〟ボタンを押すだけ。
それから、16進表記の修整をすべてやってからもう一度Buildボタンを押してみた。


 おぉ。2個のエラーまで一気に減った。

Line-124は

 となって、Line-125に〝goto main〟となっている。
 16進表記が間違っているので〝org 0x1FF〟と書き直せばエラーは消えるが・・・。
 そっか、このソースはPIC16C54用なのだ。だからプログラムのスタートアドレスがプログラムエリアの一番最後になっている。Flash PICは16F84や877などと同じでアドレス0番、つまり先頭から動き出す。この部分を少し手直ししなければいけない

〝org 0x1FF〟の行を消して、〝goto main〟の1行を〝org 0x00〟のすぐ下に移動させる。これでプログラムスタートでラベル〝main〟へジャンプしてプログラムが動き出すはず。
 Line-127の〝END〟はプログラムの終わりを意味するもので、Flash PICでは必要ない。なのでこの行も消す。

 さぁ。もう一回Buildボタンを押してみる。


 やったじゃん! エラーが無いってよ。

 自分で作っておきながらなんだけど・・・。
 他の人が作ったPICプログラムが、このFlash PICの上でエラーも無くアセンブルされる様は感激だね。

 で、ちゃんと走るのか?

 Buildされてマシン語に変換されたプログラムが、左の逆アセンブラウインドウに表示されている。

 このプログラムが正しく動けば、スタートさせるとすぐにラベル〝main〟の部分で〝R0〟〝R1〟〝R2〟と名前がつけられた汎用メモリに〝06〟〝55〟〝35〟とセットされて、16進変換処理の〝BCDtoB〟を呼び出し〝H_byte〟と〝L_byte〟に変換された16進が入って、そのあとの〝self〟をループするはず。

 逆アセンブラウインドウで〝self〟の位置を選択して(アドレスは0x32となっている)〝Break Point〟ボタンを押して、ブレークポイントを設定しておく。その行の先頭に赤い〝B〟マークが点く
 こうすると〝self〟の位置にプログラムが来ると自動的にFlash PICは停止して知らせてくれるのでベンリ・・・。

 ついでに〝Watch〟ウインドウを出して、各汎用メモリの表示もさせておく。

 〝Watch〟ウインドウにはソースプログラムでつけられた名前のメモリが並んでいる・・・。
 えっ!〝H_byte〟が無いじゃん。
 〝PORT_C〟の次にあるはずなのに・・・。

 え~なんでや。バグか?
 自信の無さがにじみ出てる。すぐにバグと疑ってしまう。
 仕事柄しょっちゅうこんな目にあっているからね。

 「なさけなや・・・」
 源平討魔伝の婆さんに叱られた感じ・・・(知っている人は知ってるよね)

 そんなナムコ社が作ったゲームの話はどうでもいい。
 なぜ〝H_byte〟が出ていないかだ。

 だね~。

 とりあえずソースプログラムで〝H_byte〟を〝equ〟定義している場所を見てみるとすぐに分かった。

 バグではない。

 こうなっていた。

 〝PORT_C EQU 0x0A〟でメモリアドレス10番目(16進で0x0A)としているのに、さらに〝H_byte equ 10〟でも同じアドレスを指定している。たぶんこれは16進の0x10のことなんだろうな。
 マイクロチップ社のプログラムは昔の書き方で、10進数と16進数をはっきり別けて記序していないのが良くない。
 正直これは良くない見本です。(←えらそうに)

 〝PORT_C EQU 0x0A〟まではFlash PICでは全共通なので固定されていて、0x0B番地から汎用メモリとして割り当てられている。なのでここは下記のようにすると間違いが少なくなる

 上記のように修整してBuildボタンを押す。
 〝Watch〟ウインドウに、ちゃんと〝H_byte〟の文字が〝PORT_C〟の次に出ている。アドレスもちゃんと0x0Bになっている。
 よっしゃ。
 
 心臓の高鳴りを感じながら、〝RUN〟ボタンを押す。

 しばらくして〝状態〟窓に「ブレークポイントで停止しました」と出た。
 変換が終了してプログラムが停止したのだ。

 〝Watch〟ウインドウの答えが入る部分〝H_byte〟と〝L_byte〟を見てみると。

 〝0xF8EB〟となっている。えぇ~。
 〝065535〟は16進で〝0xFFFF〟やろ。

 なんでや。またバグか~。まだ、自分を信じられないバカ・・・。
 〝R0 R1 R2〟に〝06 55 35〟と入れてるやろ・・・?

 ありゃ? Watchウインドウの〝R0 R1 R2〟は〝06 37 23〟となっていた。
 確かに10進数〝063723〟は16進で〝0xF8EB〟で答えは合っている。でも納得いかない

 もう一度ソースを見る。
 ラベル〝main〟の部分を見ると、ここにも10進表記で定数をセットしてある部分が出てきた。


 main   movlw   06
	movwf   R0      ; Set R0 = 06
	movlw   55
	movwf   R1      ; Set R1 = 55
	movlw   35
	movwf   R2      ; Set R2 = 35      ( R0, R1, R2 = 6,55,35 )
 ;
	call    BCDtoB  ; After conversion H_Byte = FF & L_Byte = FF
 ;
 self    goto    self
	

 例えば〝R1〟に55を入れようと〝movlw 55〟 として記序されているが、これではFlash PICは10進数〝55〟と判断して、アセンブル時に16進の〝0x37〟としてしまう。昔のMPASM(マイクロチップのアセンブラ)では数値を16進として扱うように設定されてるんだろうな。

 こういう混乱を避けるためにもソース内の16進は〝0x〟を付けた表記で記序する方がよい。Flash Action scriptでもそうなっている。

 しかし他人のプログラムを触るということは、こんなところに違和感が出るんだな。少しため息混じりで16進表記に変える。

 Buildボタンを押してRUNさせた。


 やっと正しく〝0xFFFF〟と〝H_byte L_byte〟に入って停止した。

 ひぃ~。動いたね。やっとだけど。

 苦労はしたが、結果はバグでもなんでもなくソースプログラムの記序の違いだけだった。

 Flash PICでマイクロチップのPIC16C54のプログラムが動いた瞬間であった。


 このときのソースプログラムをサンプル5にしてあるので、ぜひ覗いてみてほしい。
〝main〟の部分で〝R0,R1,R2〟に設定している数値をイロイロ変えてからBuildしなおして走らせると、ちゃんと16進に変換されているのがわかる。どうやって変換しているか、Step動作でゆっくりと検証してみるのもイイ勉強になると思うよ。


 連休はこれで終わり・・・。
 明日からは会社でPICのアセンブラをするんでしょうな・・・。あほですな。





2007年9月25日(火)

そらそ~だ・・・


 連日のプログラム作業でいささか疲れてきた。
 仕事も休日もやっていることが一緒というのはやっぱあかんね。
 終日〝ぼぉ~~~〟っとしていた。

 今日は早く切り上げて、さっさと寝てしまおう。





2007年9月29日(土)

いいこと思いついた・・・けど・・・


 世に出ているPIC のシミュレーターはタダ単にレジスタの羅列だけ、よくてスイッチ入力の一覧表をマウスで押して変化を見るだけ。こんなシミュレーターは面白くない。実際に何かあるモノを動かしたり検知したりして、プログラムの勉強をしたい・・・という方のために製作を続けているのがFlash PIC だ。

 なので・・・。

 「外部機器までシミュレートできるのはFlash PICだけだぞぉ~」 なんて勝手に思い込んで調子にのっていたが、こういう余分なモノまで動かすと肝心のシミュレートがうまくいかないんだな~。だから世に存在しないだけなんっすね。
 案の定〝ちきどん〟の動きがCPUの速度を邪魔している。そうか、そういうことか・・・。くそぉ~。

 Rev3.1まではフレームレートを最大の120にして1フレームレンダリングされるごとに、PICの命令を1個ずつ処理していた。なので、平均速度が63Hz(2GHzのWindowsマシンで)以上にならかった。
 レンダリング以外にたくさんの仕事をしているのでフレームレート120だからといって120Hzにならないのは理解できる。なので、いろいろScriptの最適化をしていたが、どれもどんぐりの背比べ・・・。どうすっぺぇ。あきらめるか?

 と、ここであきらめないで、さらに地獄の道を歩むのが好きな、わ・た・し。

 ならば、Flashのレンダリング時間内にPICシミュレータ部の割り当てをもっと増やせばいいのでは?
 そうです〝setInterval〟を使って最小値(1mS)で割り込みを掛けてPICシミュレータ部の割り当てを増やす作戦だ!
 もちろん〝setInterval〟で呼ばれるPICシミュレータ部分には〝updateAfterEvent( )〟を入れてあるよ。これなら万全だ!

 が・・・・・・・・・・・・・・。ダメでした・・・・。

 がっくりクリクリ。

 Flash8のオーサリングでムービープレビューすると、速度が365Hzまで上がったので大喜びしていたのだが、実際にiE上で動かすと変化無しの63Hzに戻っていた。
 なんでや~。

 しかし、フラッシュプレーヤーのバージョン9,0,47,0より古いものでは、ちゃんと270Hzほどに速度が上がっている。なんで、古いバージョンでは速く動いて、新しいバージョンでは動かんのや・・・。

 くそ、やりやがったな Macromedia め~。

 イロイロ調べたが理由はわからなかった。
 結論は・・・フラッシュプレーヤーの最新版ではあまり速い〝setInterval〟は正しく機能しないようだ・・・。

 しかし、ワテはまだあきらめないよ。

 それなら、63Hzで動くPICシミュレータ部分を2回通せば120Hzになるのでは・・・?
2個の〝setInterval〟を作り、同じ処理を定義するという方法だ。
 これはうまくいった。最新版のフラッシュプレーヤーでも速度を上げることが出来た。
 邪道だけど、まぁやったね。

 それより最新版のフラッシュプレーヤーだと〝ちきどん〟を動かしても全体の速度がほとんど落ちないのがすごい。
 古いバージョンだとガタ落ちになる。
 
 やはり、恐るべし Macromedia ~。
 Flash PICを試される時は最新版のプレーヤーにした方をお奨めする。

 速度アップのテストがうまくいったので、フレームレートを30に落とし、倍速ボタンの〝+〟を押すと1mS設定の〝setInterval〟の関数が1個追加されるようにした。
 最大20個まで追加できるので、最高20倍速でPICシミュレータが動くようになるわけだ。

 あくまでもシミュレートの回数を増やしているだけなので、PICの命令が一定速度で速くなっているわけではない。1倍速で50Hzだったからといって、4倍速にすれば200Hzにはならい。196~204Hzあたりをフラフラしている。なので正式なシミュレーターとしては落第だ。
 でも、PICのプログラムは正しく動いているし〝ちきどん〟のスイッチもちゃんと認識しているので、面白いシミュレータには違いない・・・。
 おかげでサンプル3の7セグの中をグルグル廻すというプログラムにバグがあることが発見された。1倍速では気がつかないが、10倍速以上にして、そのままでは速すぎるので時間待ちのプログラムを追加すると見えてくる。すごい。ちゃんとPICのプログラムのシミュレーターが動いている証拠だ。

 と、自画自賛。 ・・・( ´艸`)ムププ

 バグの部分は見つけてみてね・・・宿題。

 調子にのってきたので〝ちきどん〟の付いていない別基板も作ろうかな。
 16進入力が出来るテンキーと8桁の7セグメント表示器を搭載したデラックスタイプの基板なんていいよな。
 これだと16進⇒10進変換処理をボタンから入力できて、結果を表示器に出すという本格的なプログラムの勉強もできる。

 う~。またイバラの道を歩むのか? どうしよ。




2007年9月30日(日)

イバラの道は続く・・・


 Rev.3.2のFlash PICで20倍速にすると約1200Hzのクロックで走るPICのシミュレーターになった。(2GHzのWindowsマシンで)
 1200Hz(=1.2KHz)というと1秒間に1200命令走ることになる。Flashのフレームレートでいえば1200fpsになる。Flashのオーサリングソフトでは120fpsが最大なのでその10倍に匹敵する速度だ。

 すごい速度だ・・・・・とは思えない。

 実際のPICは4~20MHzで走る。例えば10MHzのクロックで走るとすると1命令2.5MHzで処理されるので、Flash PICとの差は2500倍にもなる。とうてい足元にも及ばない・・・ガックリ。

 次のRev.4で計画しているDeluxe版では、8個の表示器と20個の押しボタンを搭載したボードを計画しているが、1.2KHzの速度では8個の表示器をダイナミック点灯方式では駆動できない。

 早速、イバラの道が広がっているなぁ~。

 ダイナミック点灯方式というのは、たとえば8個の表示器に数字を表示する場合、瞬間的には1個の表示器しか表示させない。それをすごい速度で順に切り換えて8個の表示をしていく方式だ。

 ややこしいそうだが理由は簡単。1個分の部品で済むからだ。

 え~。ちゃんと表示されるの・・・? と、思われるかもしれないが、これは一般的な方法。テレビの画面も瞬間的には1個の点しか点灯していない。でもちゃんと見えている。そのかわり切り換わる速度がメチャメチャ速い。
 Flash PICに8個の表示器を搭載したとしたら、表示器を切り換える速度は1mS~1.5mS(1~1.5KHz)になる。
 最高速度1.2KHzのCPUで1~1.5KHzで表示を切り換える仕事はできんやろ・・・。
 無理やりやったら、切り換わっていく様子が丸見えだ。イリュージョンのステージで楽屋裏をみせているようだ。

 どうするか・・・。

 どうしよう。

 イバラの道は続くのか・・・。

 CPUの速度が遅い場合どうするかを考えればよい。こういうときは外付け回路で補う。
 でも、そうするとコストがかかる・・・。

 ぷぷぷ・・・。Flash PICに部品コストの問題はないのだ!
 あははは。本気で悩んでいる自分が情けない。ほとんど病気ですな・・・。

 所詮Flash PICは絵だ。どれだけコストの高い外付け回路を設けようが、高価なICを追加しようが一銭もコストは掛からない。

 じゃ。スタティック点灯方式だ。

 ダイナミック方式と違い、スタティックは表示するデータを全桁(この場合8個分)常に出力しっぱなしの状態にするので、PIC側から見れば表示内容を変更したい時だけ、その内容を更新すればOKというお手軽でお気楽な方式である。
 ダイナミックの場合は器(うつわ)が1個しかないので高速に表示内容を入れ替えるが、スタティックの場合は表示桁分の器(うつわ)が準備されているので、セワしない動きをする必要が無い。
 ただし、器(うつわ)になる部品が8個も必要になる。

 会社でこんな回路を組んだら「バカもん!」って叱られる。
 日ごろのウサ晴らしに、たまにはいいかも、大盤振る舞いの〝コスト高〟基板っていうのも。


 20個のキーボードの方はダイナミックスキャン(マトリックス回路)方式で試してみる。
 これも、表示器と同じように瞬間的には数個のボタンしかスキャンしない代わりに部品が少なくてすむ方式。でも、ボタン入力は人間が行う動作なので、そこそこ遅くても多分反応すると思う。なんせ〝ちきどん〟のスイッチスキャンでも時間待ちをするぐらいなので・・・。

 こうして・・・イバラの道に入っていく私であった・・・。