学研のGMC-4改造記を振り返る ― 2009/08/19 18:35:30
所で、学研のGMC-4ネタを周りを見ないで突っ走ってここまで来てしまったが、色々と改めて一呼吸置いてみた。改めて見渡すと既に色々な方々が似たようなプロジェクトでやられている。ここは一つ小休止
まず、打ち込みの仕様なのだが、構想100年のサイトで既に仕様を提唱している。まずこのフォーマットに修正する予定。データの次の0x0d受信時のInc処理もフラグを用意すれば殆ど修正は手間が掛からないはずだ。
次に、通信の取りこぼし対策。構想100年のサイトでは、CTS-RTSのフロー制御で行っている。私も真似ようと思ったのだが、私のシステムではバッファがあと50バイト程あれば300ボーという条件付で80ステップ全て使ったプログラムのデータ転送を無手順で行えると見ている。
しかし、通信のバッファの問題。PIC16F648はRAMエリアが256バイト(16F628は224バイト)使えるわけなのだが、unsigned charでバッファを確保するにしても
unsigned char Buffer_FIFO[160];←これはだめで
バンクというPICの変態アーキテクチャーのおかげで、連続した領域を確保できないわけである。(その変態に付き合っている自分もどうかと思うが・・・・・)
それなので、これを2つに分けて確保すると、
unsigned char Buffer_FIFO[80];
unsigned char Buffer_FIFO2[80];←こうすれば良い
これなら領域を取れるわけである。但し、それなりのアルゴリズムにも工夫が必要となる。「電子ブロック工房」のサイトでも同じような事に遭遇した様だ。
あと、某巨大掲示板でUSB付きのPICでやらないかという事だが、あいにくそこまでのスキルがないorz むしろ課題とさせてくれ orz
というわけで、まずは出来るところから修正して、ダブルリングバッファについては頭を加熱させてみようと思っている。これが出来れば他のPICのプログラムでも応用が利きそうだ。それにしても、今回はGMC-4から色々収穫が多いな。
コメント
_ まりす ― 2009/08/20 00:37:53
_ air_variable ― 2009/08/20 04:59:47
さて、バッファについては実験した所、140文字(データ+インクリメント処理では約70電文)までは80バイトのバッファでも転送が問題ありませんでしたので、本当にあと少しの通信バッファがあれば300ボー限定ではありますが、うまくいきそうな気配です。
オルガンモードについても、仰った通り、今は40msのキーオン/オフなので、パソコンからの演奏は断片的になっています。
ここの部分は通信の構成上、キーのストローク処理(押す/離す)が課題になりそうです。
フロー制御については、残るピンはPICKIT2に入れている2本のリソースが出力に使用できるのですが、X制御の方が確かに楽ですね。
助言を頂き大変参考になります。
まずは、まりすさんの方で決められた通信のフォーマットの実装を今週中には行い、通信手順は試行錯誤してみたいと思います。そうする事で、使い手にとって共通の仕様方になりますので、大変便利と思います。少しでも多くの人が簡単にGMC-4を使える事が私の所存です。
貴重なご意見を頂きありがとうございます。ブログがインタラクティブなものであると言う事を改めて実感致しました。これからも宜しくお願い致します。
※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。
※投稿には管理者が設定した質問に答える必要があります。
プログラムローダー開発成功おめでとうございます。
トランジスタの使い方など、とても勉強になります。
また、当方サイトの紹介ありがとうございました。
ところで、バッファとフロー制御の件ですが、回路図を拝見させていただいたところ、PINにも余裕が無さそうですね。
そこでソフトウェアフロー制御のXON/XOFFコントロールを使われてはどうでしょう?
バッファの8割程度たまったら、XOFF(0x13)を発行、バッファが2割程度をきったらXON(0x11)を発行で、送り出し側の制御をします。
プログラムを送るだけなら必要量+αのバッファでもよいですが、オルガンモードで使うなど、プログラム以上のデータを送る利用方法も有りえますので、フロー制御をされた方が後々使い道が広がると思いますよ。