• 本文
• 編集
• 差分

2008-05

2008-04

フィジカルコンピューティングについて†

http://gainer.cc/

http://funnel.cc/

• ＤＷＭ２００８.５付録の蛙のゲームはＦｌａｓｈ(ActionScript)で書かれている。
• どうやってＡＲＭ基板からＦｌａｓｈをコントロール出来るのだろうかという疑問が沸いてくる。（方向は逆かもしれない）

これには種があって、実はＧＡＩＮＥＲ(環境、ライブラリ)が使われている。

• ＧＡＩＮＥＲとは、最近流行り（？）のフィジカルコンピューティングなるものらしい。

• ＡＶＲでも同じようなものがある。Ａｒｄｕｉｎｏだ。
  • http://www.arduino.cc/
  • ホスト側の言語はＰｒｏｃｅｓｓｉｎｇというＪａｖａ由来の簡易言語だ。

• ＧＡＩＮＥＲは、ＣｙｐｒｅｓｓのＰＳｏＣマイコンをデバイスとして使用している。
  • 但し、接続はＵＳＢで、ＦＴ２３２を使用する。
• ＧＡＩＮＥＲのホスト側は３種類ある。
  • ＭＡＸ/Ｍｓｐ（製品）
  • Ｆｌａｓｈ(ActionScript)
  • Ｐｒｏｃｅｓｓｉｎｇ
• それ以外にＲｕｂｙやら.ＮＥＴやらＣ＋＋という実装もぼちぼち見られるようだ。

フィジカルコンピューティングなるものが流行っているなんてことは、ＤＷＭ２００８.５を入手するまで知らなかった。

• しかし、これはもっと汎用的であるべきだと思う。
  • たとえば、デバイスはＣｙｐｒｅｓｓ製である必要なんてない。
  • 実際のところ、ＤＷＭ誌のデバイスはＡＲＭだ。
  • 接続はシリアルまたはＵＳＢ経由のシリアル（Virtual COM Port)またはTCP/IPのいずれかを使うことになるだろう。しかし本質的にはＲＳ２３２ＣのRxD,TxDを使っているのと何ら変わりはない。ＵＳＢで仮想化されるだけだし、ＵＳＢも介したくない場合はＴＣＰ/ＩＰでも結局文字列渡しのコマンドストリームというところは変わらない。

文字列ベースのストリーム通信をやることに異論を挟むわけではないが・・・違和感を感じるのは何故だろう。

• 結局のところ、リモートセンシングとポートコントロールをやっているだけなのに
• ターゲットデバイスに文字列処理を強いるのはいかがなものか？

• 文字列ベースの処理はＰＣホスト側の仮想デバイス（シリアルプロクシーのレベルでも良い）に担当させて、ＵＳＢ/ＣＯＭはバイナリー化したほうが性能は良くなる。デバイス側のコードも簡略化出来る。

• ＡＶＲＵＳＢとの相性も良くなるわけだが。

• ＦｌａｓｈやらＰｒｏｃｅｓｓｉｎｇとの交信は文字列ストリームであることは賛成だ。

• そういうわけで、ｇｓｐ（ＧＡＩＮＥＲ　Ｓｅｒｉａｌ　Ｐｒｏｘｙ）を各種デバイス向けに用意してやれば、上位層は同じ（ような）デバイスと思ってアプリが作れるし、下位層はデバイスの差し替えが容易になるわけだ。

• 各種デバイスというのは
  • ＡＶＲ−ＵＳＢ
  • ＦＴ２３２を挟んだ（あるいはシリアル経由）ＡＶＲ
  • ＦＴ２３２を挟んだ（あるいはシリアル経由）Ｈ８などの汎用マイコンなど。

• というか、いまだに、簡易オシロの実装の方向性を考えているだけなのだが。

• サンプリングレート命になるので、８ｂｉｔもしくは１６ｂｉｔ整数のバイナリー列で受け取ってやるしかないと思っている。

• ＡＲＭのようにオンチップのＵＳＢ-仮想ＣＯＭデバイスを実装できれば、ボーレートは最速になる。

• ただし、ＵＳＢの弱点であるフレーム時間同期のことを考えると、コマンド送出→データ受け取りという同期の取り方では速度ネックになりやすい。
• 往復時間で数フレームを消費するので、せいぜい秒あたり２５０サンプルなんていう結果に陥るのだ。
• これはＲＳ２３２Ｃに換算すると１９２００ｂｐｓ程度だ。バイト数で言うと２４００バイト/秒なので、１サンプル１０バイトとしても達成出来るスループットだ。
• この程度のサンプリングレートで良いかどうかは、使い道次第だが・・・。

ＧＡＩＮＥＲコマンドリスト†

付録ＡＲＭは、厳密に言うとＧＡＩＮＥＲではないのかもしれない。†

• main.c

  void checkCommand()
  {
   // *  -- Accelerator mode
   if(memcmp(buffer_out, "*", 1) == 0) ＜＝＝こんなコマンドは存在しない。
   {
     sendFlg = 0;
     mode = 'A';
   }
   ・・・
  void main(void)
  {
   ・・・
       case 'A':    ＜＝＝アクセラモードというのはＧＡＩＮＥＲにはない。
         delay(CNT_DELAY);
         ACC_To_USB_Send_Data();
         break;

• hw_config.c

  void ACC_To_USB_Send_Data(void) ＜＝＝アクセラモードの挙動。
  {
   u16 x, y, z;
   x = ADC_RegularConvertedValueTab[0];
   y = ADC_RegularConvertedValueTab[1];
   z = ADC_RegularConvertedValueTab[2];
   sprintf((char*)buffer_in, "%d,%d,%d\r", x, y, z);
   ・・・

• たしかに、３軸の１０進値を "x,y,z\n" 形式で吐いている。
• ＧＡＩＮＥＲに則れば、"i00＊" とか "iFF＊" みたいにアナログインプットコマンド（連続送信モード）の"i"を受け取ると、１バイトのアナログ値をＨＥＸ２桁で返す流儀がオリジナルなようだ。
  • ＧＡＩＮＥＲのままでは、１６ビット（あるいは１２ビット）アナログ値は受け渡すことが出来ないので、困るはず。
• 実際に "i＊"を送ると、 "iXXYYZZWW＊" (XX,YY,ZZ,WWは４つのアナログ入力値（00〜0xFF）ただしWWは00固定、他の軸は256/4096した値）を連続送信するモードに突入する。
• さらに、アナログ入力系のコマンドと、上記のアクセラ入力モード以外はいっさい実装されていないことがわかった。

Ｃｙｐｒｅｓｓ用のＧＡＩＮＥＲファームの実装はあまり良くないのでは？†

• gainer_psoc(1.1.0b00)よりもgainer_v1.5(1.5.0b01)のほうが、まだまともだが。
• なまじ文字列コマンドで柔軟性を持たせているので、処理が重い。
• コード量もけっこうある。
  • v1.5のhexで内容的に１６ｋＢくらい（？）

• ＡＴｔｉｎｙ２３１３の２ｋＢには、逆立ちしても入らない容量

• そのまえに、前提条件として、文字列ストリームで汎用性を持たせてあるわりには、Ｃｙｐｒｅｓｓ以外への実装に向かないようなコマンド体系、リファレンス実装とはいかがなものかい？（或いは、他のマイコンへの挑戦なのカー？）

とはいえ、ＧＡＩＮＥＲは大きな可能性を持っていると思う。†

• ＰＳｏＣ、ＡＶＲ、ＡＲＭ、Ｈ８、ＳＨ、Ｒ８などどのマイコンもＵＡＲＴ（つまりシリアル通信）くらいは持っている。
• つまり、シリアル通信はマイコンの共通言語なんだ。（ＰＣから見て）
• ＵＳＢ化されていても仮想ＣＯＭポートであればシリアル通信とほぼ同じだ。

ということは

• ＧＡＩＮＥＲのデバイス層が共通なコマンド体系で実装されれば、事実上どのマイコンもＰＣと繋がり、ほぼ同じように操作出来るアプリケーション群が書けるはず。
• ついでに言うと、内部メモリーを読み書きするモニターとＳローダーとＧＤＢスタブ（or ＯｐｅｎＯＣＤのようなもの）まで、このシリアル通信に含めてしまえば、ＰＣと接続して処理を行う用途についてはほぼ需要を満たせるはずなんだ。
  • デバッグスタブは機種固有なのでとりあえずおいといても構わない。
• これは迅速なプロトタイピングの実現という意味で非常に便利なものだ。
• ＰＣ部のメインルーチンをターゲットに移植すれば、プロトタイプからスタンドアローン化も出来ることになる。（但しＰＣ側のリソースは使えない）

• それにしても、現在のＣｙｐｒｒｅｓｓ（ＰＳｏＣ）の実装はとても褒められたものではない。
• ＧＡＩＮＥＲ　ｖ２.０に期待するか。

勝手にＧＡＩＮＥＲ補完計画†

• 実は俺にとっては上位層なんてどうでもよい。
  • 極端なことを言えば、ＣＯＭポートをReadFile/WriteFile出来る言語があればそっから上はなんでもＯＫ。
  • それが出来ない言語ではｇｓｐのようなものを仲介させてＴＣＰのストリームをＯｐｅｎさせる。

• シリアルポートを流れるコマンドこそ全て。（モデムで言うならさしずめＡＴコマンド体系がしっかりしているかどうかだ）
• マイコンの機種に依存しない柔軟なコンフィギュレーションが必要。
  • たとえばＡＶＲならport directionを制御したり、PWMの周期やモードを制御できたほうがよいが、それらは機種固有なのでオプショナルだ。
  • 論理ポートＮｏと物理ポートＮｏの割り付けのようなものは必要だろう。ＰＳｏＣのように固定化したものでなく。
• データの種類は　analog in/out , digital in/out 。
  • ＡＶＲでは双方向とかＰｕｌｌＵｐがあるが・・・それらはオプショナル。
• 受け渡すデータ列は８ビット、１６ビット、３２ビットの３種類。３２ビットは将来のオプション
• 基本的には数値表現は１６進整数値。（固定桁ゼロパディング）
• オプショナルでバイナリ８ビット、１６ビット、３２ビットのストリームあり。
• continuousモード（連続送信モード）はサンプリングレートの指定が必要だと思う。

いっそのこと、ＭＩＤＩのノートＯＮ、ノートＯＦＦイベントをそのまま流用するか？ （ain/aout代わりに）

• そうすると、ベンダーリクエストのコマンドが来たら、Ｓレコードを埋め込んでプログラムを送りつけて実行させたり、やりたい放題のことも出来る。

秋月のＳＨ２ｔｉｎｙ†

• Ｃｏｍｍｉｎｇ　Ｓｏｏｎだった基板が新製品に出ていた。
  • http://akizukidenshi.com/catalog/items2.php?c=new&s=date&p=1&r=1&page=#K-02312

１８００円。すこし安いな。完成品のようだ。

• これに外部メモリーが付けられるなら鬼に金棒なんだが。
• ＦＲ６０の汎用ポートにバスぶら下げるのって・・・（ＩＦ記事見たけど・・・）どうなんでしょ？
  • http://www.cqpub.co.jp/interface/sample/200806/I0806100.pdf
• まわりくどいＩ／Ｏポートとしては使えるだろうけど、外部ＲＡＭ上のコードを実行できるわけじゃないしねぇ。

まだＨ８のモニターを弄っているのだが・・・†

• こんどは３０４８Ｆの秋月ボードにmonitorを書き込もうとしている
• flashの書き込みは１回目はうまくいったのだが、２回目以降ちっとも書き込めない。
• やっぱり１００回のチケットを使い果たしたのか？
• と思ったが、昇圧の１２Ｖがやや低いような気がする。

現在、秋月３０４８マザボを改造して、ＡＶＲＵＳＢによるＵＳＢポートを繋いでいる。

• ＡＴｔｉｎｙの空きポートにＰＷＭ生成をプログラムして、そこから取り出した矩形波 で２ＳＣ１８１５みたいなＴｒをＯｎ、Ｏｆｆしている。
• 適当なトロイダルコイルをチョッパして、なんちゃって１２Ｖを生成しているのだが、
• ちょっと電圧が足りてないようだ。
• それと、５Ｖ、１２Ｖを与えるタイミングが、秋月の意図したタイミングと逆転してしまう（１２Ｖが後で印加される）ので、どうも具合が悪い。
• 対策として、手動リセットをかましているのだが、今日に限ってうまく書き込めない状態のようだ・・・。困ったな。
• 三端子レギュレータをとっぱずしてみるか・・・。

なんか適当すぎるなぁ＞俺

３０４８Ｆ用のモニタがとりあえず動作した。†

• 電源１２Ｖ問題は、ハンダ不良だった。（つまんねー）
• でも、チョッパーのＯＵＴは１２Ｖしか出ていないので三端子レギュレータをスルーするように配線を変えてみた。
• 一応書き込み成功。sciのコントロールが３６９４Ｆと微妙に違うのが気に入らないがまあいいや。
• そのうちソースを整理してＵＰ予定。
• 結局のところＧＤＢなんか使う気ないのでＳｔｕｂ統合はナシ。
• ３０４８ＦはフラッシュＲＯＭが多めなので、逆アセンブラくらい欲しいなあ・・・
• 相変わらず１９２００ｂｐｓ。
• ３８４００ｂｐｓにするとやはり文字欠けする。ＡＶＲＵＳＢ側の（スループット不足）問題。
• でも速いほうが気持ちいい。
• いっそのこと、ＡＶＲｍｏｎｉｔのように、バイナリーでメモリーＲ/Ｗするだけの単機能 モニターにしてしまって、パソコン側に逆アセンブラを入れようかとも思った。
• そうしたら現在の３倍は速く表示出来るし、スループット不足による文字欠けは（１６バイト単位のリードをリクエストする限りは）発生しない。
• ３０４８Ｆ側のコードも、現在の４ｋ強サイズから、１ｋバイト程度にまで縮むに違いない。

トラ技８、９月号はＮＥＣの７８ＫＵＳＢマイコンが付録†

http://www.cqpub.co.jp/toragi/Images/tr200808,9.pdf

• ８月号（７/１０発売）ＵＳＢスティック型風の７８Ｋマイコン基板付録
• ９月号（８/９発売）ベースボード（基板のみ。部品なし）付録

今年は基板が豊作だ。・・・しかもＵＳＢ接続種が多い！

http://www.necel.com/micro/ja/product/all_8_usb.html

• ７８Ｋは８ビットマイコンらしい。ＲＯＭ１６Ｋ、ＲＡＭ３Ｋ。なのにＵＳＢ
  • 何故にＵＳＢ？といった感じだな。
  • クロックは１６ＭＨｚ。
  • ユーザーズマニュアルをＤＬしようとしたら、500 Errorって何だい。

• ああ、もうこれ以上、マイコンの機種を増やしたくない。
  • ＡＶＲを主軸にして、ＡＲＭとＳＨ２ｔｉｎｙくらいにとどめておこう。
  • ７８Ｋはチップ価格が安いらしい（３００円とか） --- http://www.necel.com/news/ja/archive/0609/1901.html
  • データ記録用フラッシュ２５６ＫＢ内蔵品種もある。（コードは１６ｋＢのままで）
  • そもそも８ビットマイコンなのに、何故に２５６ｋＢ？
  • この７８Ｋ＋ＵＳＢは、鍵用途だな（ＵＳＢドングルっぽいやつ）

http://elm-chan.org/works/sp78k/report.html

• 上記ＣｈａＮさんの解説によると、

  78Kアーキテクチャは、8085に独自のビット操作命令を追加したような感じのレジスタと命令セットを持ち

• ということらしいので、Ｃで書こうとは思わないほうがよいのかな。
• ＰＩＣよりはまし、とか。
• 某社の８０５１よりはまし、とか。
• ＊＊よりはまし、というのは何ともネガティブだなぁ・・・。
• ＰＩＣを含めフルアセンブラで書かないと使えないようなＣＰＵは全力でスルーの方向で。
  • とか、いいながら、上記トラ技の広告ＰＤＦによるとＣ言語でプログラミング出来るらしい。
  • ８０８５をか？
  • とりあえず怖いものみたさで入手予定だ。
  • ダメアーキだったとしても、（一応シリアルを含むので）ＦＴ２３２の代用品として使えるかも

７８Ｋのユーザーズマニュアルを流し読み。†

• ほんとに８０８５だ。ＩＸ，ＩＹは無い。
• ８０８０に欠けているＡレジスタの片割れとしてＸを追加しており、
• ＡＸ、ＢＣ、ＤＥ、ＨＬという１６ビットレジスタペアが構成できる（って８０８６かよ）
• ［ＨＬ＋Ｂ］とか［ＨＬ＋Ｃ］あるいは［ＨＬ＋＃imm8］というアドレスモードがある。
  • それ以外のパターンはあるかというと、ない。
  • ［ＢＣ］［ＤＥ］［ＨＬ］はあるが、［ＡＸ］というアドレスモードはない。
  • にもかかわらず、ＡＸに対してのみ１６ビット即値加算、減算、即値比較が用意されている。
  • ＢＣ、ＤＥ、ＨＬに即値代入するのは普通にあるが、レジスタペアにメモリーからロード、ストアはない。ＡＸのみ可能。
  • ＡＸとｒｐ（ＢＣ、ＤＥ、ＨＬのうちどれか）の交換はある。代入は無い。
  • ＡＸ＝Ａ＊Ｘ、ＡＸ＝ＡＸ／Ｃという符号なし乗除算命令を持っている（それぞれ１６、２５クロック）
  • そのほかはおおよそ８０８５相当なので、Ｃ言語で使うにはきつい
• バスは８ビットらしく、平均命令サイクル数は６くらい？
  • ＡＶＲ換算で３ＭＨｚくらいかな。だけどレジスタが少ないのでＣ言語で使うには効率が悪い。
• そうそう、ＵＳＢは一応１２ＭＨｚ（フルスピード）でパケット長６４バイト。
  • それからバルク用エンドポイントが２つ用意できる。６４バイトのバッファをエンドポイントごとに２組持てる。

中国四川省地震†

• 本題(AVR)から脱線して申し訳ない。
• この地震に関して、日本国内での反応は「他人事」もしくは「対岸の火事」のように見ているが、
• 実のところ、被災者１０００万人、死者数万人（もしかしたら１０万人を越える、ダムが決壊すればそれどころではない）というリアル数字は地震の第一報からは全く想像も出来なかったことだ。
• これは対岸の火事ではない。近い将来間違いなく日本で起こる。
• 不気味な予行演習だ

Ａｔｏｍベンチマーク来たー†

ＰＣウォッチ：MSIのAtom搭載ミニPC「WIND PC」速報レビュー

• http://pc.watch.impress.co.jp/docs/2008/0519/msi2.htm
• Ａｔｏｍ以外は汎用品という割り切り方が好いねぇ・・・。
• Ｅ７２００と比べると１/５以下の性能だ。負けっぷりが好いねぇ。
• Cele-M 900MHzと比べるとやや劣るくらいだな（Atomは1.33GHz）
• システムトータルでの消費電力は実測３０〜３５Ｗらしい。排気ファンが１つ付いている。惜しい
• 完全ファンレスだったら良かったのに・・・

ＯｐｅｎＣＶ：†

openframeworksとか入れなくちゃいかんのかなーと思っていたら、別なのを見つけたので貼っとく

• http://opencv.jp/
• インテルが開発・公開しているオープンソースのコンピュータビジョン向けライブラリ。
• WindowsならびにLinux、FreeBSD,Mac OS X等。
• C/C++で記述する。

初めて知った。

• 名前だけはなんとなく聞いていたが、ＣＶってあーたなんですか？って感じで通り過ぎていた（引っかからなかった）わけで・・・。（Control Voltage?え？）
• コンピュータビジョンのことらしい。
• Wikipediaによると、

  コンピュータビジョン（computer vision）は大雑把に言って、
  「ロボットの目」を作る研究分野である。

  だそうだ。

フィジカルコンピューティングと何か関係あるのかな？†

とりあえずやりたいことは

• Ｗｉｎ上でも動くＧＵＩっぽいプログラムを簡単に書きたい。
• もちろん、画像を表示するのが主だ。

• で、この手の簡易言語の候補としてあがってきたのは

  MAX/Msp	商用ソフト,元はMac用のサウンド系ツール	商用はフリーじゃない不利
  Action Script	Adobe Flashで使われている。JavaScriptにすこし似ている	Webブラウザ上の動作なので嫌
  Processing	Java由来の簡易言語。Java仮想マシン上で動く。Proce55ingとも書かれる	Javaかぁ・・・
  openframeworks	ＯｐｅｎＧＬの薄いラッパーとして実装されたＣ＋＋ベースの簡易言語(?)	まだまだ過渡期

• どれも触手が動かないんだよう・・・。
• このほかに、Ｔｃｌ/ＴｋとかＨＳＰ（ほっとすーぷ）とかＣ＃とかもいちおう考えはした。

• やっぱりアルゴリズムを書くのはバニラなＣ言語がいい。
• だけどＧＵＩ構築の為にＷｉｎ３２ＡＰＩを叩くとかＶｉｓｕａｌなんとかを使うのは嫌だ（面倒すぎるし、Ｗｉｎｄｏｗｓと心中したくない心理）
• ＳＤＬとかＯｐｅｎＧＬベースも考えてみたが、こつこつやるのはやっぱ面倒臭いんだよ〜。

というわけで、暫くの間ＯｐｅｎＣＶを試してみることにする。