June 01, 2008

Super Sylphide 進捗状況(18) -- i2cでサーボインターフェイス

オートパイロットシステムSuperSylphideですが、最近はもっぱらI/O拡張基板用のVHDLを書いています。なかなかPC用のソフトウェアを書いている感覚と違うので、頭が混乱しています。特に並列に動作するものをイメージするのが難しく、タイミングチャートを図におこしてうんうんうなっていることがしばしばです。

とりあえずはラジコン用サーボのインターフェイスを作ろうと考えました。出来上がりは下図の予定です。

servo_IF-thumb.gif

注目ポイントとしては、i2cをインターフェイスにしていること、サーボ信号の読み込みができることです。多くのラジコン用サーボコントローラにはついていないサーボ信号の取り込み機能ですが、これをつけることによって人間の操縦履歴を取得したり、さらには人間の操縦をアシストする形でコントロールすることが可能となります。取得した履歴と飛行データをもとに模型飛行機の挙動を探ることができれば、様々な飛ばし方ができると思われます。

とりあえずi2cの部分は完成しました。i2.vhdが本体、i2c_test.vhdがテストベンチです。双方向なinout定義のsdaの処理に手惑いましたが、ハイインピーダンス('Z')にして、外部でpull-up('H'を繋ぐ)にすればよいようです。

現在はサーボ信号を処理する部分とi2cをいかにして繋ぐか悩んでいます。サーボ信号を扱う部分はi2cの処理単位である8bitsでは解像度が低すぎますので、もう少し大きめのレジスタを使用したいと考えていますが、それをいかに8bitsに整形するかが考えどころです。i2c側で8bitsよりも大きいレジスタを読み込めるように調整する機構をつけるか、サーボ信号を処理する側でアドレス指定などして8bitsに整形するか、どちらの方が良いか難しいところです。

※その後完成して、飛行試験でのデータ取得に成功しました。

23:47 fenrir が投稿 : 固定リンク | | このエントリーを含むはてなブックマーク | この記事をdel.icio.usでブックマーク | コメント (2) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/642

June 09, 2008

秋葉原でおきた痛ましい事件

[Timely]

恐ろしかったです。秋葉原で用を足そうと思ったのですが、幸い色々と立て込んでいてあの時間帯に秋葉原に立ち寄ることにはなりませんでした。渋谷、新宿、池袋あたりがターゲットにされそうなものですが、もはや秋葉原もそういう場所になってしまったということで、認識を新たにせざるを得ません。幼少より秋葉原に慣れ親しんできたのですが、最近あの一帯の人口、人種が急増したことと関係があるような気がしてなりません。

一アキハバラ人として、被害者の方のご冥福を節にお祈りたいと思います。

00:50 fenrir が投稿 : 固定リンク | | このエントリーを含むはてなブックマーク | この記事をdel.icio.usでブックマーク | コメント (0) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/643

June 13, 2008

秋月USBオーディオ

PCのサウンドカードが壊れてしまっていたので、秋月の新商品『USBオーディオモジュール』を組み立ててみました。ケースには同じく秋月の『ポリカーボネイトケース』を使っています。

akizuki_USB_audio.jpg

なかなかいい音でなっています。アンプ部分がPCから遠いことが効いているのでしょうか。ケーブルや電源等あわせて原価2000円程度、工作に1時間程度かかりました。サウンドカードをジャンクで数百円で購入するよりも、いい仕事をしたという満足感が得られたので、よしとします。

23:59 fenrir が投稿 : 固定リンク | | このエントリーを含むはてなブックマーク | この記事をdel.icio.usでブックマーク | コメント (0) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/644

June 18, 2008

VHDLの可視化ができないものかと

オートパイロットシステム SuperSylphideですが、FPGA基板のソフトがとりあえずひと段落しました。今では『進捗状況(18) -- i2cでサーボインターフェイス』に書いた、i2cによるサーボ信号の読み出し、書込みができます。この内容を記事にしようと考えたのですが、表題の問題が発生しました。

事の発端は、記事用にとVHDLを回路図にした絵が欲しくなったことに始まります。ターゲットFPGAはXilinxのspartan3なので、開発にも同じくXilinxのISE WebPACKを使用しているのですが、このソフトで表示されるRTL Schematicsは実に説明に都合がいい回路図なのです。

ISE_RTL.png
WebPACKにてRTL Schematicsのスクリーンショット

ところが残念ながら、この回路図を画像ファイルとして保存することができません。贅沢はいわないので、epsファイルぐらい(笑)吐いて欲しいものです。描画できるのだからファイルに落とし込むことなど容易いとは思うのですが、ないものはないのです。そこで解決方法をいくつか探ってみました。

  1. RTL Schematicsの印刷はできるので、そこでPrimo PDFなどを使ってPDF化。その後pdftopsなどを使ってepsに変換して、最後はイラストレータで加工。でも文字化け…
  2. 元のファイルはVHDLなので、その可視化を直接行ってくれるものがないか探す。signsというeclipseのプラグインとしても動作するツールがなかなか良さそうだが…
  3. 回路図を別のフォーマットで書き出した上で、他の可視化ツールで読み込んで画像に出力。EDIFというフォーマットがデファクトらしいが…

上記の選択肢の末尾からご察しいただけるかと思いますが、どれも満足がいく結果が得られませんでした。

1.については、WebPACKが吐き出すPDFファイルは怪しげなフォントが埋め込まれてしまっているので、イラストレータで開くのに適したepsが最終的に得られませんでした。埋め込まれたフォントを置換するスクリプトが用意できればよいのですが、そこまではチャレンジしませんでした。

2.についてはsignsがeclipse上でうまく動作してくれませんでした。signs-0.6.3を使ってみたのですが、『(signsがコンパイルした)ライブラリのトップモジュールがおかしいよ』的なエラーがでて、描画をしてくれません。今後のバージョンに期待したいと思います。

3.ですがEDIFのviewerで無償のものを発見できず断念しました。デファクトならば標準的なソフトが無償で提供されてもいいものだとは思うのですが…。Wikipedia『EDIF』をみると事情が多少垣間見られます。ところでこのEDIFは実は内部的にはS式なので、パースが非常に簡単です。ということは、ごにょごにょしてEagleの回路図に変換ということもできるかもしれません、検討してみようと思います。

もしよい方法をご存知でしたら、是非ともお教えください m(_ _)m

00:06 fenrir が投稿 : 固定リンク | | このエントリーを含むはてなブックマーク | この記事をdel.icio.usでブックマーク | コメント (7) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/645

June 22, 2008

EBNFをRacc形式に変換

前回の記事『VHDLの可視化ができないものかと』のコメント欄に少し書きましたが、VHDLを可視化できないものかと思案中です。とりあえずプログラミング系のスキル向上も兼ねて、VHDLのパーサくらいこさえてみようと一念発起してみました。パーサジェネレータとしてはRubyベースのRaccを使うことにします。

VHDLはその定義が、定義記法の1つであるBNFを拡張したEBNFによって行われています。例えばVHDL-93のEBNF定義は『Hyperlinked VHDL-93 BNF Syntax』にあります。この定義をパーサジェネレータにうまいこと食わせられれば、パーサ生成に向けた第一歩をクリアすることができるという寸法です。

しかしながらRaccはBNFに近い形式のみでEBNFをそのまま受け付けてくれるわけではありません。特に問題となるのが、EBNFのみで可能なブレース('[', ']')やブラケット('{', '}')を使った省略可能及び繰り返しの表記で、これをBNFでも表記可能な再帰定義で書き換えなければなりません。

書き換えの例をあげると以下のようになります。EBNF、それを変換したBNFの順に示します。

hoge_def ::= { ada_def [ basha_def ] }

hoge_def ::= hoge_def_loop
hoge_def_loop ::= ada_def basha_def hoge_def_loop
    | ada_def hoge_def_loop
    |

VHDLクラスのまじめな言語になると、これを手動で変換というのはかなり大変です。そこでRubyでVHDLのEBNF用変換スクリプトebnf2raccy.rbを書いてみました。これで記法の問題、並びにキーワードの終端記号化を行っています。VHDLのEBNF定義ebnf.txtから、このスクリプトによって生成したRacc用入力ファイルをRaccで処理したところ、shift/reduce、reduce/reduce conflictsがいくつか出ていますが、EBNFからBNFへの記法変換についてはうまくいっているようです。

これらをもとにパーサをこさえようとしていますが、現在のところ入力文字列を意味単位(トークン)に区切ってくれるスキャナとの関係をどうしようかと思案中です。VHDLの定義自体は文字指向、つまり一文字ずつ処理するように作ってあるようですが、パーサとしては字句指向、つまりは単語単位でリテラルとしてスキャナからトークンが生成されたほうが都合がよいと思います。そこでVHDLの定義の中で、文字を結合して意味を形作っている下位部分をいくつか書き換えようと考えています。
またVHDLの定義をみたところ、いくつか不足している規則があるようです。例えばsignal_nameなどのアンダーバーがついてる規則について定義がありません。nameという規則はあるのでaliasであると考えられます。パーサとして機能させるためには、これらについても正しく関係付けを行わないといけないので少々厄介です。

※(2008/6/24)正規表現を使ってリテラル単位でスキャナからトークンが生成されるように変更してみました。リンク先のファイルも更新してあります。

※※(2008/6/25)キーワードと規則名が一部被っていたことに愕然としました。literal、range等です。BNF側を修正することで対応しました。また今後の方針ですが、VHDLの文法がなかなかお茶目のよう(定義済みの名前と定義がない名前で文法上の動作をかえる必要があるらしい、トークンの1つ先読みだけでは完全に文法が定まらない?)で、これをどうやってRaccが採用しているLALR(1)で実現するか難しいところです。おそらくアクションと組合わせて、next_tokenでスキャナからトークンを返す直前にちょっとした細工をかます必要があるのではないかと考えています。

16:52 fenrir が投稿 : 固定リンク | | このエントリーを含むはてなブックマーク | この記事をdel.icio.usでブックマーク | コメント (2) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/646

June 27, 2008

秋月GPSモジュールから生データ抽出

秋月で販売されているGPSモジュールを購入、分解したことは以前の記事『秋月GPSモジュール@4800円』で書きましたが、その後こんな形になりました。

gps_packet_sniffer_RevA_view.jpg
インターフェイスはPC接続用USBとアンテナ接続用SMA

中身はこんな感じになっています。

gps_packet_sniffer_RevA.jpg
中身はごちゃごちゃ

秋月のGPSモジュールから怪しい線が何本かでているのが確認できるかと思いますが、これは以前計画した通り、GPSの生データ、もう少し具体的にいうと、中間周波数に落とされたGPS電波をAD変換した後のデジタルデータ、を抽出するためのものです。色々オシロを当てて調べてみた結果、目的とする信号がでているのはSiRF GPS2e/LP-7456の82(ACQCLK),84(MAG),86(SIGN)ピンのようでした。これらの信号をPCに転送するために、74HCT4015(4bits dual serial-in/parallel-out shift register、1clockあたり必要な信号は2bitsなのでそれをまとめる)とCypress FX2LP(データ転送用)を使ってみました。74HCT4015は多くのセミコンダクタでディスコンになりつつあるようですが、運良く鈴商で入手できました。

とりあえず組み立ててみた結果なのですが、残念ながら動作しませんでした。SiRFチップからの信号の取得に失敗しているようです。さらに調査してみた結果、以前Novatell SuperStar2から信号を取得しようとしたときと違い、どうやら信号が83ピンを基準電圧とした差動出力されているようでした。特にACQCLKについては実測してみたところ差動で150mVp-pしかないので、コンパレータでレベル変換するしかなさそうです。他の2つの信号MAGとSIGNについてはある程度強度が確保されていたので、AM26LV32TB3R1(後述)等で差動からシングルエンドに変換できると思います。

実はsparkfunで扱っているSiGe GN3S Samplerとほぼ同じ機能のものを実現しようとしているので、買い物で済むことは済むのですが、いつも売り切れ & 楽しくないのでこういうことをしている次第です。

※その後、差動信号はPECLという規格のようだ、ということがわかりました。

10:47 fenrir が投稿 : 固定リンク | | このエントリーを含むはてなブックマーク | この記事をdel.icio.usでブックマーク | コメント (2) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/647