TRX-305上のDSPをいじるプロジェクトですが、ようやく問題の切り分けに成功しました。理由はDSPのファームウェア・イメージではなくマイコン側でした。現在問題は私の手を離れていますが、そのうち解決されるものと思われます。
当面、プロジェクトとしてはROMからのブートを必要としないため、問題の解決が数ヶ月に及んだとしてもわたしの方は先に進むことができるようになりました。
ということで、ようやく、本当にようやくですがプロジェクトを先に進めることが出来ます。
目標とする成果物
このプロジェクトが作ろうとしている開発成果物はTRX-305上で動作するソフトウエアラジオのフレームワーク（あるいはスケルトン）です。このフレームワークはTRX-305のFPGAからIFディジタル信号を受け取り、DSP上で必要な信号処理を施して復調し、FPGAに対してオーディオ信号を送り返します。現在の予定では、FPGAに対するプログラムの修正は必要ありません。
なお、成果物はフレームワークなので、実際の信号処理自体はフレームワークのユーザー（TRX-305に独自信号処理を搭載したいと考えているプログラマ)がプログラムを書くことになります。
フレームワークはTOPPERS/JSP for Blackfin上に構築します。そのため、DSPプログラムではありますが、極端に難しいものにはならないはずです。追々解説しますがTRX-305のマイコン-DSP間通信はかなり扱いが面倒なため、C言語/RTOS環境を利用できるというのは心強いことです。
開発するフレームワークのライセンスはBSD 2条項ライセンスです。詳しくはBSD 2条項ライセンスを検索する等してください。
開発環境
開発環境は以下の通りです。
- OS : Ubuntu 14.04 LTS 32bit版
- Toolchain : GCC Blackfin Toolchain ADI-2014R1RC2
- IDE : Eclipse
- ICE：gnICE
- Runtime : TOPPERS/JSP for Blackfin
以上の開発環境はフレームワークの開発環境であり、フレームワークを利用してプログラム開発をする場合には、IDEは無くても良いでしょう。また、ICEにはリアルタイム性がないため、フレームワーク利用者にはデバッグ用としても不要かと思います。
OS / Toolchainともフリーですので気軽にプログラムを開発できます。私はOSをVMware Workstationで走らせており、ホスト環境はWindows 8.1です。TRX-305のビルド環境はWindowsですので、何らかの仮想マシンをWindowsで走らせ、その中でUbuntuを走らせるといいでしょう。
リソース
開発用のバグトラッキングやソースコード管理にはSourceforgeを利用しています。Sourceforgeのtrx305-dspプロジェクトには今日現在ソースツリーとinstallerスクリプトのベータ版をアップロードしています。
ソースの状況ですが、TRX-305上のBlackfin DSPにICEでダウンロードすることでTOPPERS/JSPが動作しています。上に述べたようにBootの問題はまだ存在しているため、当面の作業はICEベースとなります。
ソースツリーはTOPPERS/JSP for Blackfinプロジェクトから持ってきたものですが、一部手を入れています。
改造点の一つ目はconfigureスクリプトです。ubuntu 14.04ではPerlのGetOpts()関数の古い形式がサポートから外れているため、TOPPERS/JSPのconfigureスクリプトが動作しなくなりました。これを修正して動作するようにしています。TOPPERS/JSP for Blackfinプロジェクトへのバックポートはまだ行っていません。また、TOPPERSプロジェクトへも追々報告する必要があります。
改造点の二つ目はTarget依存部です。TOPPERSカーネルではターゲットに依存する部分（初期設定など）はターゲット依存部に追い出すことになっています。TOPPERS/JSP for Blackfinはこのターゲット依存部を非常に作りやすくなっており、TRX-305のDSPへのターゲット依存部移植はものの一、二時間で終わりました（たいてい、「あれ、ubutunの更新が始まった」「ICEのコマンドどうするんだっっけ」といった事で時間を多く取られる）。
改造点の三つ目はTRX-305用のソースの生成です。TOPPERS/JSPカーネルはビルドしても実行形式ファイルしか生成しません。しかし、Blackfin組み込み環境ではLDRファイルと呼ばれるブートローダー用のファイル形式に変換する必要があります。また、TRX-305の開発環境で受け付けるのはSH用のソースだけであり、LDRファイルはさらにTRX-305の開発環境で解釈できるソースファイルに変換する必要があります。TRX-305にはLDR->SH変換ユーティリティが存在するのですが、（制作者情報のとおり）Windows 8.1では動作しなかったため、Ubuntu上でLDRの生成とLDR->SH変換を行うスクリプトを書いてMakefileに埋め込んでいます。
現在sourceforgeのgitに格納してあるソースツリーの最新版は上記改造を全て施しています。
コンソール
TRX-305はSDR実験基板であり、操作はフロントパネルではなくUARTコンソールから行います。一時期フロントパネルがほしかったのですが、全機能を使えるわけではありませんので今ではそれほどでもなく、必要になったら作る方が楽しいかなと考えています。とにかく、実験にコンソールは必要です。また、TOPPERS/JSPの内部モニタもUARTを使用しています。
私はいつもコンソールにはUbuntu上のkermitを使っています。UARTからの信号はUSB-シリアル変換しています。TRX-305はUSB-シリアル変換チップを搭載しておりはじめからコンソールはUSBなのでよいのですが、DSPのシリアルポートはロジックレベルでやりとりするむき出しの信号ポートがテストポイントとして提供されているだけです。
これを利用するためにスイッチサイエンスのPL2303HX内蔵USBシリアル変換ケーブルを購入して使用しています。同製品はすでに在庫がないようですが、Raspberry Pi用に同様の製品はたくさん販売されているようなので困らないでしょう。
USB-シリアル変換ケーブルを使うと、シリアル・ポートのデバイス名は /dev/ttyUSB0, /dev/ttyUSB1…と、USBハブに差し込んだ順で名前が振られていくため、作業するときには煩わしいです。そこで、以下のようなudevルール・ファイルを書きました。これで/dev/ttyTRX305-console, /dev/ttyTRX305-dsp と分かりやすい名前でデバイスを扱うことが出来ます。
## set USB Seiral port name to avoid the interface of other usbserialconverter
# for TRX-305 Console USBSeiral conversion module.
ATTRS{manufacturer}=="FTDI", ATTRS{serial}=="AH016Q7S", SYMLINK+="ttyTRX305-console"
# for TRX-305 DSP USBSerial conversion module
ATTRS{manufacturer}=="Prolific Technology Inc.", ATTRS{product}=="USB-Serial Controller", SYMLINK+="ttyTRX305-dsp"
今後の展開
ようやくスタート地点に立てたので、これからフレームワークの実装に必要な情報やフレームワークを作る過程で考えたことをこちらのBlogに書いていきます。しばらくは「どういう構成にするべきか」といった話が続くことになります。
なお、こちらはあくまで作業内容を書き込んでいるBlogです。Blog自身に関するコメントは歓迎しますが、trx305-dspプロジェクト自身へのコメントや、先の話ですがバグ情報などはプロジェクトの掲示板までお願いします。