－過去ログは古い順に並んでいます－
２００７年９月１日（土）
朝からやってまっせ・・・
Ｆｌａｓｈ ＰＩＣの続報７だよ。
間接アドレッシング、ＣＡＬＬ命令、ＲＥＴＬＷ命令も動き出したし、入出力ポートもアクセス可能になったので、プログラム次第ではマイクロスイッチの検知もできる。
たとえば〝ちきどん〟をマニュアルで動かして、マイクロスイッチの１番のＯＮ／ＯＦＦの回数を７セグメント表示器に出すとか、逆に基板上の押しボタンスイッチをマウスで押すと〝ちきどん〟が動き出すとかプログラムできるよ。
もちろんＣＡＬＬ命令とＲＥＴＬＷ命令を利用した７セグメント表示器の表示データのテーブル参照も可能なので、本格的なプログラムでも対応するはず。
これで、ひと通りのシミュレーションができる。えへへへ。
見てみたい方はコチラから。
しかし！
速度は遅いよ・・。２．５ＧＨｚのＷｉｎｄｏｗｓマシンでクロック６０Ｈｚぐらい。〝ちきどん〟を動かすと５０Ｈｚぐらいに落ちる。
これは、笑ってごまかすしかない。
それと、やはりプログラムの入力がやりにくい。１ラインずつ入力してエンターボタンを押す方法では、長いプログラムの入力が苦痛でしかない。
たとえばマイクロチップス社で公表しているアプリケーションノートの算術演算処理プログラムを検証してみようと思っても、１ラインずつの入力では、やる気が出ないよな。
やっぱり、ガバッとコピーして、Ｆｌａｓｈ ＰＩＣの上でドサッと貼り付けて、サッとアセンブルして即走らせる・・・。
コレがいちばんですな。
とりあえず、次の段階はテキスト入力したプログラムをＦｌａｓｈ ＰＩＣにドサッとコピーできるようにすることを目標にしよう。
いまのとこは、ジャンプ先のラベルが使用できないのでアドレス直接入力なことと１ライン入力で辛抱です。
あと、バグがあってプログラムのＳａｖｅもまだできない（恥）
それでも１命令ずつのステップ処理ができるので、ウォッチウインドウでレジスタを見ながら処理の流れが良くわかる。
これだけでもめっけモンです。
２００７年９月２日（日）
今日もセッセとやってます・・・
Ｆｌａｓｈ ＰＩＣの続報８だよ。
今日は細かいバグの修整とＦｌａｓｈ ＰＩＣの配線図をこしらえた。ＨＥＬＰボタンを押すとイロイロな説明が出るようになっているのでぜひご覧ください。
ついでにサンプルプログラムを二つほど読み込めるようにしてみたので、プログラムの参考にどうぞ。
サンプルプログラム２は〝ちきどん〟のマイクロスイッチ３のＯＮになった回数を７セグメント表示器に１０進数で表示するという簡単なもの。
処理の流れはこんな感じ・・・。
サンプルプログラム２をロードしてＲＵＮボタンを押すと、ＦＬａｓｈ ＰＩＣは基板上の押しボタン（ＳＷ１）が押されるのを待つ。
押さないといつまで経っても動かないのでご注意。
押されると〝ちきどん〟が動き出し、後はマイクロスイッチ３がＯＮになるたび、回数を数えるという動きをしている。
本物らしいところは、マイクロスイッチがＯＮになったあとＯＦＦになるのを確認してから回数を加算しないと、正しく数えられない。
１回のＯＮを２回数えてしまうからだ。う～ん。本物らしいねぇ～。
ちなみに、マイクロスイッチはチャタリングは起きないので安心して。そこまでシミュレートしていないよ。ぷぷっ。
２００７年９月４日（火）
つぎ行ってみよう・・・
Ｆｌａｓｈ ＰＩＣを次の段階にすすめる準備を始めた。
次の段階というのは、ソースプログラムをテキストデータとして直接キーボードから打ち込んで、それをアセンブルしてＦｌａｓｈ ＰＩＣを動かすというもの。
こうすると、別のエディタやＷｉｎｄｏｗｓ付属のメモ帳などでこしらえたものをコピー・貼り付けで移動ができるし、何より長文のプログラム作りに耐えれるようになる。サンプルプログラムもテキストデータになるのでダウンロードも可能になるし、他の人が作ったプログラムを読み込めるようにもなる。
今の方式では苦痛なだけで、やる気が起きない。
次の段階になって初めて完成と言えるだろうね。
できたら・・・の話だけど・・・。（心配）
２００７年９月８日（土）
仕事バカ人間誕生・・・
変な夢で目が覚めた。
おわん型の容器に入ったパチンコ球風の金属の球の数を数える機械を作る夢だ。
夢なのでおわん型の容器には意味は無いだろうが、何か気になって起きてからしばらく布団の中で考えていた。
個々の重さは同じようだから全体の重みを測って１個の重さで割るか？
それともレールに流してカウントするか・・・。でもそうするとハードにコストが掛かるし、結構悩むなぁ・・・。って！夢ですから！
頭抱える必要はないぞ！あほ！
２００７年９月１７日（月）
進化したよ・・・
テキスト入力を可能にしたＦｌａｓｈ ＰＩＣ（Ｒｅｖ２．２）のお披露目だ。
その前に初めてこのホームページを見た方のために説明します・・・。
Ｆｌａｓｈ ＰＩＣとは、仮想のＰＩＣデバイスを搭載したトレーニングボードをＦｌａｓｈプレーヤーを使ってインターネットのブラウザ上で実現しようというものなんだ。プログラムを入れてＲＵＮボタンを押すとそのプログラムに沿ってトレーニングボードに載っている部品がコントロールできるんだよ。これなら半田ごても電源の心配も要らない。ただし、手に持って触れることは出来ない。だって絵だもんね。・・・( ´艸｀)ムププ
で、前回のＲｅｖ１．０と比べてどう進化したか・・・。
まず、テキスト入力でプログラムが書けるようになった。
ソースプログラムウインドウにプログラムをキーボードから入力して〝Ｂｕｉｌｄ〟ボタンを押すとアセンブルされて隣の逆アセンブルウインドウに表示される。
もちろんエラーがあればエラー行の指摘が出るので修整することになる。
ＭＰＬＡＢを使用したことのある方ならすぐに使えると思う。
次に１４ビット幅の命令語を使用するＰＩＣに完全準拠させた。ミッドレンジＰＩＣなら大概のものはアセンブルできると思う。
そして、ブレークポイントの追加。
これで、任意の場所でプログラムを停止させてメモリー内を検証できる。
まず、テキスト入力になるとどう便利かというと、他の場所で作られたソースプログラムをＦｌａｓｈ ＰＩＣのソースウインドウへコピー、貼り付けが可能になるんだ。
これだけでもずいぶん楽しくなる。
入れてある４つのサンプルプログラムのうち４番目は、マイクロチップ社で公表されているアプリケーションノートの算術演算処理からＡＮ５２６、１６進⇒１０進変換処理をそのまま移植させている。
詳しく説明すると・・・。
アプリケーションノートの算術演算処理のページに行くと、〝AN526 Source Code - PIC16C5x/PIC16Cxx Utility Math Routines 〟という欄があるので、そこのソースコードをダウンロードする。するとたくさんのプログラムが展開されるので、その中の〝B16TOBCD.ASM〟というのを開いて、そっくりコピーしてＦｌａｓｈ ＰＩＣのソースウインドウへ貼り付ける。
あとは使用されているメモリー名をＦｌａｓｈ ＰＩＣ用のメモリ名に書き換えて〝Ｂｕｉｌｄ〟ボタンを押してアセンブルする。エラーが出たら修整。
文字列の検索・置換も可能なのでＦｌａｓｈ ＰＩＣ用のメモリー名に変更するのも簡単にできる。（まだ〝ＥＱＵ〟などの擬似命令は動かないのでこれでがまん。Ｒｅｖ３では可能にするつもり・・・）
このサンプルプログラムは、指定のメモリに書かれた４桁の１６進数を１０進数に変換して別のメモリ列に書き出すというものだが、Ｆｌａｓｈ ＰＩＣでもちゃんと動くことが実証された。
ただし、速度は遅いよ。とんでもなく遅い。本物のＰＩＣなら瞬時で計算終了になるが、Ｆｌａｓｈ ＰＩＣだと１１秒も掛かる。２．５ＧＨｚのＷｉｎｄｗｏｓマシンで確認している。Ｍａｃでは未確認。
でも、ワンステップ動作でメモリー内を見ながらプログラムの検証ができるのでこれは便利。
早速見てみたい方はコチラか、あるいは〝ＦＬＡＳＨ ＡＳ１〟のページに入って右上部のＦｌａｓｈ ＰＩＣのボタンを押して動かして欲しい。
詳しい取り説はＦｌａｓｈ ＰＩＣ内のＨｅｌｐを押せば出てくる。
２００７年９月２３日（日）
それっ、もういっちょう・・・
この連休で、Ｒｅｖ．３．０にグレードアップしたＦｌａｓｈ ＰＩＣの続報だ。
ちびちびアップしてないで、時間を掛けて一気にすればいいのに・・・と思われるかも知れないが、ブロックごとに作って行くという性格なんです。すみません。
Ｒｅｖ．３．０からはアセンブラの擬似命令、〝ｏｒｇ〟〝ｅｑｕ〟に対応するようになった。
擬似命令というのは、ＣＰＵに対しての命令語ではなく、アセンブル語をＣＰＵの命令に変換してくれているアセンブラというアプリケーションに対して行う指示のようなもので、ＣＰＵの命令語とは異なる。
ややこしいね～。
他にもイロイロ擬似命令はあるけど、この二つでほとんどまかなえる。
Ｒｅｖ．１．０の不便極まりない命令語選択式から進化して、テキストエディタ入力に加えて擬似命令の対応で、本格的なＰＩＣアセンブラになってきた。
¶ 別の場所で作られたＰＩＣのプログラムをＦｌａｓｈ ＰＩＣへ移す方法…
Ｆｌａｓｈ ＰＩＣのアセンブラがどこまで実用になるか、試験する意味も込めて、例のマイクロチップ社で公表されている算術演算処理の中から〝BCD2BIN.ASM〟を選んでみた。
これは、別の場所で作られたソースプログラムをＦｌａｓｈ ＰＩＣに移してちゃんと動くかの検証になる。成功すればシメシメだ。
〝BCD2BIN.ASM〟というプログラムは、５桁のＢＣＤコードされた１０進数を２バイトの１６進数に変換するもの。ちょうどサンプル４の逆になる。
では、早速やってみよう。
まずＦｌａｓｈ ＰＩＣのソース内を〝消去〟ボタンを押して、ヘッダ部分だけの初期状態に戻す。
ヘッダ部分というのはのＦｌａｓｈ ＰＩＣのコア内部にあるファイルレジスタのアドレス設定を予めしてある部分で、ＰＩＣでいうなら〝#INCLUDE "P16F877.INC"〟にあたる部分がソース上に展開してあると思ってもらっていい。ようは、INCLUDE擬似命令はまだ使えないのでソース上に書いてある。
初期状態のソースで 〝org 0x00〟から下は入出力ポートの初期設定なので今回は必要ないから削除する。
〝BCD2BIN.ASM〟をメモ帳で開き、全文をコピーしてＦｌａｓｈ ＰＩＣのソースウインドウの〝org 0x00〟から下に貼り付ける。
Ｆｌａｓｈ ＰＩＣでは、いまのところひとつの命令はウインドウの右端までで完結していないとだめ。２行に折り返すとエラー時の行番号が狂ってくるので注意が必要。
プログラムコードだけなら普通は１行以内に収まるが、コメントが長くなると２行にまたがって折り返しが起きる。そういうときは、いちど改行してあらためて〝；〟を付けて書くようにすればよい。
折り返しが起きたままにしておくと、エラーリストで示す行番号と実際にエラーが起きた行番号が異なってしまい混乱する。
はっきり言ってこれはバグだ。商品価値が出ないほどのバグで致命的だ。
現在対策案を検討中・・・。
それまでは、ひとつの命令はソースウインドウの右端までに収めるようにしなければいけない。エライすんまそん。
〝BCD2BIN.ASM〟のコメントもかなり長かったので１行内に収まるよう修整が必要だ。もっとも、長ったらしいコメントはプログラムに関係ないので、全部削除してもいいかもね。
英語だし・・・。ぷぷぷ。
今回はコメントは削除せずに修整だけを行って、とりあえずＢｕｉｌｄボタンを押してアセンブルさせてみる。
どしゃ～ん。エラーが２１個も出た。なんじゃ？
たぶん何かの命令が抜けていてＦｌａｓｈ ＰＩＣに合わなくて、そこから先が連続的にエラーになっていると思う。
気を取り直して、最初のエラーがあるLine-17（１７行目）を見てみると〝LIST P = 16C54, n = 66〟と書かれている。
これはＰＩＣデバイスを何にするか選択する擬似命令だ。
そりゃそうさな。Ｆｌａｓｈ ＰＩＣにはこんな擬似命令作ってないもんね。
この一行をコメントとしてプログラム的には削除する。（先頭に〝；〟を付けるとそれ以降をコメントとみなす）
他にも例の〝INCLUDE〟行があるのでこれもコメントにしてしまう。
別に完全に削除しても良いが、元のプログラムに戻す時に楽なのでそうした。
Ｆｌａｓｈ ＰＩＣは〝ｏｒｇ〟擬似命令から以降にプログラムが書かれていると判断するので、貼り付けた〝BCD2BIN.ASM〟内の〝equ〟文が、〝org 0x00〟以降に入っているのでこれはまずい。これでは〝equ〟というＣＰＵの命令になってしまう。当然ＣＰＵの命令ではないので〝Syntaxエラー（記序間違い）〟が出てしまう。
〝equ〟の行をすべて〝org 0x00〟より上に移動させる。
再びＢｕｉｌｄボタンを押してアセンブルさせてみる。
|
だいぶ減ったが、まだ大量にエラーが出る・・・。なんで？
いやいや、まだがっかりするのは早い。よ～く、ソースプログラムを見てみよう。
〝Line－58 ラベル名が見つかりません〟と出ているので、Line-58を見てみよう。
Line-58にはこんなことが書かれている。
|
〝mpy10b〟はこの行にラベルを定義しているので、このラベルが見つからないといっているのか？
いやちがう。"見つからない"といっているのだから、探しているということだ。
たしかに〝mpy10b〟はラベルだが、ここに定義しているので〝探している〟ではない。「定義できません」とかのエラーなら話はつながるが・・・。
じゃあ何を探している？
続く命令はこれだ⇒〝andlw 0F〟
定数（リテラル）で論理積を行う命令だが、〝0F〟が間違っている。
Ｆｌａｓｈ ＰＩＣでは１６進数を表す時は頭に〝0x〟をつけなくてはいけない。そうしないと数値ではなく文字と判断されてラベル名になっていまう。Ｆｌａｓｈ ＰＩＣは〝0F〟という文字列のラベルだと勘違いして、それを探しているのだ。
〝andlw 0x0F〟と書き直した。これで１６進の0x0Fということをアピールできる。
すぐにＢuildボタンを押してみた。
|
Line-58のエラーが消えた。よしよし。思ったとおり。
続いてLine-60を見てみる。
|
これはすぐにわかる。
〝STATUS,C〟の部分だ。〝STATUS〟は〝equ〟擬似命令で0x03と設定してあるので問題は無い。〝C〟の部分だ。
〝btfsc STATUS,C〟とくればこれはビットテストの命令で、STATUSレジスタの何番目かのビットが〝0〟の時、次の命令をスキップするというもの。本来は〝C〟の部分に０～７の数字が入る。
そうだった。Ｆｌａｓｈ ＰＩＣではビット位置の〝equ〟定義は出来なかった・・・。Ｆｌａｓｈ ＰＩＣから見れば〝C〟番目のビットなんて知ったこっちゃない。だからエラーになる。
STATUSレジスタの〝C〟ビットといえばＣarryフラグで０番目だ。だから〝C〟の部分を0に換えればよい。
なぜ０番目になるのかは、ＰＩＣの仕様書を見てみよう。
う～ん。しかしまだ細かい部分に不具合が目立つね。次のグレードアップを待ってもらおうかな。もう時間がない・・・。仕事もしなければいけないもんね。
〝STATUS,C〟を〝STATUS,0〟に変更するのは簡単。〝STATUS,C〟の文字をコピーして検索ボタンの横のテキスト入力欄に入れる。
続いて下の置換ボタン横のテキスト入力欄に〝STATUS,0〟といれて「もうありません」と出るまで〝連続置換〟ボタンを押すだけ。
それから、１６進表記の修整をすべてやってからもう一度Ｂｕｉｌｄボタンを押してみた。
|
おぉ。２個のエラーまで一気に減った。
Line-124は
|
となって、Line-125に〝goto main〟となっている。
１６進表記が間違っているので〝org 0x1FF〟と書き直せばエラーは消えるが・・・。
そっか、このソースはＰＩＣ１６Ｃ５４用なのだ。だからプログラムのスタートアドレスがプログラムエリアの一番最後になっている。Ｆｌａｓｈ ＰＩＣは１６Ｆ８４や８７７などと同じでアドレス０番、つまり先頭から動き出す。この部分を少し手直ししなければいけない
〝org 0x1FF〟の行を消して、〝goto main〟の１行を〝org 0x00〟のすぐ下に移動させる。これでプログラムスタートでラベル〝main〟へジャンプしてプログラムが動き出すはず。
Line-127の〝END〟はプログラムの終わりを意味するもので、Ｆｌａｓｈ ＰＩＣでは必要ない。なのでこの行も消す。
さぁ。もう一回Ｂｕｉｌｄボタンを押してみる。
|
やったじゃん！ エラーが無いってよ。
自分で作っておきながらなんだけど・・・。
他の人が作ったＰＩＣプログラムが、このＦｌａｓｈ ＰＩＣの上でエラーも無くアセンブルされる様は感激だね。
で、ちゃんと走るのか？
Ｂｕｉｌｄされてマシン語に変換されたプログラムが、左の逆アセンブラウインドウに表示されている。
このプログラムが正しく動けば、スタートさせるとすぐにラベル〝main〟の部分で〝R0〟〝R1〟〝R2〟と名前がつけられた汎用メモリに〝06〟〝55〟〝35〟とセットされて、１６進変換処理の〝BCDtoB〟を呼び出し〝H_byte〟と〝L_byte〟に変換された１６進が入って、そのあとの〝self〟をループするはず。
逆アセンブラウインドウで〝self〟の位置を選択して（アドレスは0x32となっている）〝Ｂｒｅａｋ Ｐｏｉｎｔ〟ボタンを押して、ブレークポイントを設定しておく。その行の先頭に赤い〝Ｂ〟マークが点く
こうすると〝self〟の位置にプログラムが来ると自動的にＦｌａｓｈ ＰＩＣは停止して知らせてくれるのでベンリ・・・。
ついでに〝Ｗａｔｃｈ〟ウインドウを出して、各汎用メモリの表示もさせておく。
〝Ｗａｔｃｈ〟ウインドウにはソースプログラムでつけられた名前のメモリが並んでいる・・・。えっ！〝H_byte〟が無いじゃん。
〝PORT_C〟の次にあるはずなのに・・・。
え～なんでや。バグか？
自信の無さがにじみ出てる。すぐにバグと疑ってしまう。
仕事柄しょっちゅうこんな目にあっているからね。
「なさけなや・・・」
源平討魔伝の婆さんに叱られた感じ・・・（知っている人は知ってるよね）
そんなナムコ社が作ったゲームの話はどうでもいい。
なぜ〝H_byte〟が出ていないかだ。
だね～。
とりあえずソースプログラムで〝H_byte〟を〝equ〟定義している場所を見てみるとすぐに分かった。
バグではない。
|
こうなっていた。
〝PORT_C EQU 0x0A〟でメモリアドレス１０番目（１６進で0x0A）としているのに、さらに〝H_byte equ 10〟でも同じアドレスを指定している。たぶんこれは１６進の0x10のことなんだろうな。
マイクロチップ社のプログラムは昔の書き方で、１０進数と１６進数をはっきり別けて記序していないのが良くない。
正直これは良くない見本です。（←えらそうに）
〝PORT_C EQU 0x0A〟まではＦｌａｓｈ ＰＩＣでは全共通なので固定されていて、0x0B番地から汎用メモリとして割り当てられている。なのでここは下記のようにすると間違いが少なくなる
|
上記のように修整してＢｕｉｌｄボタンを押す。
〝Ｗａｔｃｈ〟ウインドウに、ちゃんと〝H_byte〟の文字が〝PORT_C〟の次に出ている。アドレスもちゃんと0x0Bになっている。
よっしゃ。
心臓の高鳴りを感じながら、〝ＲＵＮ〟ボタンを押す。
しばらくして〝状態〟窓に「ブレークポイントで停止しました」と出た。
変換が終了してプログラムが停止したのだ。
〝Ｗａｔｃｈ〟ウインドウの答えが入る部分〝H_byte〟と〝L_byte〟を見てみると。
|
〝0xF8EB〟となっている。えぇ～。
〝065535〟は１６進で〝0xFFFF〟やろ。
なんでや。またバグか～。まだ、自分を信じられないバカ・・・。
〝R0 R1 R2〟に〝06 55 35〟と入れてるやろ・・・？
ありゃ？ Ｗａｔｃｈウインドウの〝R0 R1 R2〟は〝06 37 23〟となっていた。
確かに１０進数〝063723〟は１６進で〝0xF8EB〟で答えは合っている。でも納得いかない
もう一度ソースを見る。
ラベル〝main〟の部分を見ると、ここにも１０進表記で定数をセットしてある部分が出てきた。
|
例えば〝R1〟に55を入れようと〝movlw 55〟 として記序されているが、これではＦｌａｓｈ ＰＩＣは１０進数〝55〟と判断して、アセンブル時に１６進の〝0x37〟としてしまう。昔のＭＰＡＳＭ(マイクロチップのアセンブラ）では数値を１６進として扱うように設定されてるんだろうな。
こういう混乱を避けるためにもソース内の１６進は〝0x〟を付けた表記で記序する方がよい。Flash Action scriptでもそうなっている。
しかし他人のプログラムを触るということは、こんなところに違和感が出るんだな。少しため息混じりで１６進表記に変える。
|
Ｂｕｉｌｄボタンを押してＲＵＮさせた。
やっと正しく〝0xFFFF〟と〝H_byte L_byte〟に入って停止した。
ひぃ～。動いたね。やっとだけど。
苦労はしたが、結果はバグでもなんでもなくソースプログラムの記序の違いだけだった。
Ｆｌａｓｈ ＰＩＣでマイクロチップのＰＩＣ１６Ｃ５４のプログラムが動いた瞬間であった。
このときのソースプログラムをサンプル５にしてあるので、ぜひ覗いてみてほしい。
〝main〟の部分で〝R0,R1,R2〟に設定している数値をイロイロ変えてからＢｕｉｌｄしなおして走らせると、ちゃんと１６進に変換されているのがわかる。どうやって変換しているか、Ｓｔｅｐ動作でゆっくりと検証してみるのもイイ勉強になると思うよ。
連休はこれで終わり・・・。
明日からは会社でＰＩＣのアセンブラをするんでしょうな・・・。あほですな。
２００７年９月２９日（土）
いいこと思いついた・・・けど・・・
世に出ているＰＩＣ のシミュレーターはタダ単にレジスタの羅列だけ、よくてスイッチ入力の一覧表をマウスで押して変化を見るだけ。こんなシミュレーターは面白くない。実際に何かあるモノを動かしたり検知したりして、プログラムの勉強をしたい・・・という方のために製作を続けているのがＦｌａｓｈ ＰＩＣ だ。
なので・・・。
「外部機器までシミュレートできるのはＦｌａｓｈ ＰＩＣだけだぞぉ～」 なんて勝手に思い込んで調子にのっていたが、こういう余分なモノまで動かすと肝心のシミュレートがうまくいかないんだな～。だから世に存在しないだけなんっすね。
案の定〝ちきどん〟の動きがＣＰＵの速度を邪魔している。そうか、そういうことか・・・。くそぉ～。
Ｒｅｖ３．１まではフレームレートを最大の１２０にして１フレームレンダリングされるごとに、ＰＩＣの命令を１個ずつ処理していた。なので、平均速度が６３Ｈｚ（２ＧＨｚのＷｉｎｄｏｗｓマシンで）以上にならかった。
レンダリング以外にたくさんの仕事をしているのでフレームレート１２０だからといって１２０Ｈｚにならないのは理解できる。なので、いろいろＳｃｒｉｐｔの最適化をしていたが、どれもどんぐりの背比べ・・・。どうすっぺぇ。あきらめるか？
と、ここであきらめないで、さらに地獄の道を歩むのが好きな、わ・た・し。
ならば、Ｆｌａｓｈのレンダリング時間内にＰＩＣシミュレータ部の割り当てをもっと増やせばいいのでは？
そうです〝setInterval〟を使って最小値（１ｍＳ）で割り込みを掛けてＰＩＣシミュレータ部の割り当てを増やす作戦だ！
もちろん〝setInterval〟で呼ばれるＰＩＣシミュレータ部分には〝updateAfterEvent( )〟を入れてあるよ。これなら万全だ！
が・・・・・・・・・・・・・・。ダメでした・・・・。
がっくりクリクリ。
Ｆｌａｓｈ８のオーサリングでムービープレビューすると、速度が３６５Ｈｚまで上がったので大喜びしていたのだが、実際にｉＥ上で動かすと変化無しの６３Ｈｚに戻っていた。
なんでや～。
しかし、フラッシュプレーヤーのバージョン9,0,47,0より古いものでは、ちゃんと２７０Ｈｚほどに速度が上がっている。なんで、古いバージョンでは速く動いて、新しいバージョンでは動かんのや・・・。
くそ、やりやがったな Macromedia め～。
イロイロ調べたが理由はわからなかった。
結論は・・・フラッシュプレーヤーの最新版ではあまり速い〝setInterval〟は正しく機能しないようだ・・・。
しかし、ワテはまだあきらめないよ。
それなら、６３Ｈｚで動くＰＩＣシミュレータ部分を２回通せば１２０Ｈｚになるのでは・・・？
２個の〝setInterval〟を作り、同じ処理を定義するという方法だ。
これはうまくいった。最新版のフラッシュプレーヤーでも速度を上げることが出来た。
邪道だけど、まぁやったね。
それより最新版のフラッシュプレーヤーだと〝ちきどん〟を動かしても全体の速度がほとんど落ちないのがすごい。
古いバージョンだとガタ落ちになる。
やはり、恐るべし Macromedia ～。
Ｆｌａｓｈ ＰＩＣを試される時は最新版のプレーヤーにした方をお奨めする。
速度アップのテストがうまくいったので、フレームレートを３０に落とし、倍速ボタンの〝＋〟を押すと１ｍＳ設定の〝setInterval〟の関数が１個追加されるようにした。
最大２０個まで追加できるので、最高２０倍速でＰＩＣシミュレータが動くようになるわけだ。
あくまでもシミュレートの回数を増やしているだけなので、ＰＩＣの命令が一定速度で速くなっているわけではない。１倍速で５０Ｈｚだったからといって、４倍速にすれば２００Ｈｚにはならい。１９６～２０４Ｈｚあたりをフラフラしている。なので正式なシミュレーターとしては落第だ。
でも、ＰＩＣのプログラムは正しく動いているし〝ちきどん〟のスイッチもちゃんと認識しているので、面白いシミュレータには違いない・・・。
おかげでサンプル３の７セグの中をグルグル廻すというプログラムにバグがあることが発見された。１倍速では気がつかないが、１０倍速以上にして、そのままでは速すぎるので時間待ちのプログラムを追加すると見えてくる。すごい。ちゃんとＰＩＣのプログラムのシミュレーターが動いている証拠だ。
と、自画自賛。 ・・・( ´艸｀)ムププ
バグの部分は見つけてみてね・・・宿題。
調子にのってきたので〝ちきどん〟の付いていない別基板も作ろうかな。
１６進入力が出来るテンキーと８桁の７セグメント表示器を搭載したデラックスタイプの基板なんていいよな。
これだと１６進⇒１０進変換処理をボタンから入力できて、結果を表示器に出すという本格的なプログラムの勉強もできる。
う～。またイバラの道を歩むのか？ どうしよ。
２００７年９月３０日（日）
イバラの道は続く・・・
Ｒｅｖ．３．２のＦｌａｓｈ ＰＩＣで２０倍速にすると約１２００Ｈzのクロックで走るＰＩＣのシミュレーターになった。（２ＧＨｚのWindowsマシンで）
１２００Ｈｚ（＝１．２ＫＨｚ）というと１秒間に１２００命令走ることになる。Ｆｌａｓｈのフレームレートでいえば１２００ｆｐｓになる。Ｆｌａｓｈのオーサリングソフトでは１２０ｆｐｓが最大なのでその１０倍に匹敵する速度だ。
すごい速度だ・・・・・とは思えない。
実際のＰＩＣは４～２０ＭＨｚで走る。例えば１０ＭＨｚのクロックで走るとすると１命令２．５ＭＨｚで処理されるので、Ｆｌａｓｈ ＰＩＣとの差は２５００倍にもなる。とうてい足元にも及ばない・・・ガックリ。
次のＲｅｖ．４で計画しているＤｅｌｕｘｅ版では、８個の表示器と２０個の押しボタンを搭載したボードを計画しているが、１．２ＫＨｚの速度では８個の表示器をダイナミック点灯方式では駆動できない。
早速、イバラの道が広がっているなぁ～。
ダイナミック点灯方式というのは、たとえば８個の表示器に数字を表示する場合、瞬間的には１個の表示器しか表示させない。それをすごい速度で順に切り換えて８個の表示をしていく方式だ。
ややこしいそうだが理由は簡単。１個分の部品で済むからだ。
え～。ちゃんと表示されるの・・・？ と、思われるかもしれないが、これは一般的な方法。テレビの画面も瞬間的には１個の点しか点灯していない。でもちゃんと見えている。そのかわり切り換わる速度がメチャメチャ速い。
Ｆｌａｓｈ ＰＩＣに８個の表示器を搭載したとしたら、表示器を切り換える速度は１ｍＳ～１．５ｍＳ（１～１．５ＫＨｚ）になる。
最高速度１．２ＫＨｚのＣＰＵで１～１．５ＫＨｚで表示を切り換える仕事はできんやろ・・・。
無理やりやったら、切り換わっていく様子が丸見えだ。イリュージョンのステージで楽屋裏をみせているようだ。
どうするか・・・。
どうしよう。
イバラの道は続くのか・・・。
ＣＰＵの速度が遅い場合どうするかを考えればよい。こういうときは外付け回路で補う。
でも、そうするとコストがかかる・・・。
ぷぷぷ・・・。Ｆｌａｓｈ ＰＩＣに部品コストの問題はないのだ！
あははは。本気で悩んでいる自分が情けない。ほとんど病気ですな・・・。
所詮Ｆｌａｓｈ ＰＩＣは絵だ。どれだけコストの高い外付け回路を設けようが、高価なＩＣを追加しようが一銭もコストは掛からない。
じゃ。スタティック点灯方式だ。
ダイナミック方式と違い、スタティックは表示するデータを全桁（この場合８個分）常に出力しっぱなしの状態にするので、ＰＩＣ側から見れば表示内容を変更したい時だけ、その内容を更新すればＯＫというお手軽でお気楽な方式である。
ダイナミックの場合は器（うつわ）が１個しかないので高速に表示内容を入れ替えるが、スタティックの場合は表示桁分の器（うつわ）が準備されているので、セワしない動きをする必要が無い。
ただし、器（うつわ）になる部品が８個も必要になる。
会社でこんな回路を組んだら「バカもん！」って叱られる。
日ごろのウサ晴らしに、たまにはいいかも、大盤振る舞いの〝コスト高〟基板っていうのも。
２０個のキーボードの方はダイナミックスキャン（マトリックス回路）方式で試してみる。
これも、表示器と同じように瞬間的には数個のボタンしかスキャンしない代わりに部品が少なくてすむ方式。でも、ボタン入力は人間が行う動作なので、そこそこ遅くても多分反応すると思う。なんせ〝ちきどん〟のスイッチスキャンでも時間待ちをするぐらいなので・・・。
こうして・・・イバラの道に入っていく私であった・・・。
Copyright(C) 2004 D-Space Keyoss.
All rights reserved.