実は数ヶ月前からTRX-305MB基板が手元にあります。
これはCQ出版社『トランジスタ技術』誌2014年11月号で取り上げられたSDR基板です。この基板はAnalog Devicesの高性能ADコンバーターを利用した基板で、RFでサンプリングされた信号をFPGAにより処理し、低周波IFに落としてDSPで復調を行うアーキテクチャになっています。
さて、この復調部分のDSPはADSP-BF533なのですが、ソースコードが公開されておらずバイナリが提供されているのみです。そこで、ここを何とかしてプログラムすれば、自分のSDRの実験に使えるじゃないかと目論んで、こそこそいじり回している次第です。
これから、時折このプロジェクトについてブログに書いていくことにします。
大まかな方向性
TRX-305MBは復調部のADSP-BF533の実行コードを主マイコンであるSH2 (SH7144) のFlash ROMに格納しており、これをリセット時にSPI経由でダウンロードすることでDSPをブートさせています。
幸い、TRX-305MB同梱CD-ROMにはこのSH2の全ソースコードが収録されており、DSPの実行コードも公開されています。先に書いたようにTRX-305のDSPのソースコードは非公開です。そこで、SH2に収録されているコードは、DSPのバイナリ(BlackfinのLDRファイル)をHex変換したものです。つまり、SH2のプログラムはこのHexデータをFlash ROMに格納することでADSP-BF533へのブートデータとして扱えるようになっています。
結論を言えば、このHexデータを置き換えることで、任意のプログラムをDSPで走らせることが出来るはず、と言うわけです。
現在考えている方向性は、この機能を使ってDSP上にSDR信号処理プラットホームを作ろうというものです。このプラットホームはFPGAから入力された低周波IF(Fsは35kHz程度)を復調して、FPGAにオーディオ信号を返すというものです。幸いFsが低いため、プラットホームとしては単純なオーディオ・フレームワークの延長に組み立てることが出来るだろうという目論見です。
ただ、いくつか困難な点があります。
まず、これは単純なオーディオ・フレームワークではありません。SPORTから入力されるのは低周波とはいえIQの複素信号であり、同時にFPGAからのコマンド・データもTDMで送られてきます。フレームワークはこれらを適切に捌いて、信号処理アルゴリズムに正しくわかりやすい形式で送る必要があります。このIQ信号はワイドFMとそれ以外の信号では速度が変りますので、フレームワークはそれを吸収して復調アルゴリズムを簡易にする手伝いをする必要があります。
同様に、復調された信号もFPGAに対してステータス情報とTDM化して送出しなければなりません。
最後に、コマンドの話があります。DSPのソースコードは公開されていませんので、コマンドについてはFPGAの公開されたソースを読みながら解釈していく必要があります。
こういったソフトウェア上のハードルがあるわけですが、加えて、ツールについてもハードルがあります。
TRX-305の設計者である西村さんはAnalog Devices社の開発ツールを使ってDSPファームウェアの開発を行っています。しかしながら、このツールは個人が買える値段ではありません（TRX-305MBの値段はどうなんだ、と言う話しは横に置いておきましょう）。必然的にツールはGCCとなり、だったら「TOPPERS/JSP for Blackfinが使えないか」というのが現状です。そもそも、TOPPERS/JSPは私がSDRで遊ぶためのプラットホームとしてメンテしているので、流れとしては自然ですが、ホスト側に私が手を出せないと言う点で、多少用心深くなっています。
まぁ、とにかく、年末休みの間にピーとかプーと音が出せればいいなぁ、という時間感覚で作業は進んでいます。
現状
さて、現状ですがTOPPERS/JSPをSH2からブートする過程の途中にいます。
これまでの実験で、TOPPERS/JSPのsample1アプリをICE経由でTRX-MB305MBのDSPにロードしてきちんと動作するところまでは移植が進んでいます。この辺りは簡単なもので、そもそもTOPPERS/JSP for Blackfinは新しいボードへの移植が非常に簡単です。たった4つのファイルを作って数個のパラメタをボードに合わせ込むだけで動き始めるのです。
問題はその次のステップで、TOPPERS/JSPをSH2のFlash ROMに格納して、SH2からブートさせるのが次のマイルストーンです。残念ながらここで躓いています。
メインのマイコンであるSH2(SH7144)は256kBのFlash ROMを持っていますが、調べた限りではDSP以外のコードが使用しているのはその3/4程度です。そのため、Blackfinのファームウェア格納用には64kB以上使うことが出来ます。これまでの経験からオーディオ・フレームワークの実装に必要なメモリ量は30kB以下ですので、アルゴリズムと合わせても、余裕を持って開発が出来ます。
一方で、SH2のプログラムに組み込むHexファイルを作るには、Analog DevicesがLDRと呼ぶファイル形式のファイルをBlackfinツールチェーン側で生成しなければなりません。これにはbfin-elf-ldrプログラムを使用します。
現在、手元ではbfin-elf-ldrで生成したLDRファイルをLinuxのフィルタを使ってHEXファイルに変換し、Windows上でSH2のプログラムとしてビルドしています。状況としては上に述べたとおり、ここからの実行に失敗しています。
TOPPERS/JSPを使わないベアメタルの小さなテストプログラムを作りましたが、これもTOPPERS/JSP同様ICEでロードすると動作しますがSHからブートすると動作しません、従って、TOPPERS/JSP for Blackfinの問題ではなさそうです。
どこに問題があるのか
問題が起きうるとしたら以下のような場所でしょう。
- bfin-elf-ldr自身
- LDRファイルをHEXに変換するスクリプト
- SH2からDSPへのロード方法
3に関しては、SH2からDSPへ、オリジナルの開発者によるダウンロードが出来ていますので、疑いとしてはそれほど濃厚なものではありません。ということで、1,2を疑うことになります。
当面、2のチェックをしつつも、1については実験が必要だと思っています。というのは、TRX-305はSPIブートなのです。私はADSP-BF592をUARTあるいはROMからブートさせたことはありますが、ADSP-BF533をSPI経由でホストからロードさせたことはありません。また、ネットで調べても、bfin-elf-ldrでADSP-BF533用のSPIブート用LDRを使ったという記録にもヒットしません。そのため、この点については多少の疑いをぬぐえないでいます。
現在使っているコマンドラインは以下のようなもので、これはマニュアルを読む限りは正しいはずですが、さて、ほんとかどうかは実験しなければわかりません。
bfin-elf-ldr -T BF533 -c -g 1 dsp.ldr a.out –bmode spi
ということで、次のステップは少し遠回りですがmbed辺りを使って手元のADSP-BF533基板をブートさせる事になります。
最後に
以上のように、多少身の丈に合わないことをやっていますが、追々成果は公表していきます。