組み込みソフトウェアの場合、OSSといえどもターゲット基板は必要です。
作業効率を考えれば、基板は作業机に置いてあって電源さえ入れればいつでもデバッグ出来るという環境が理想です。しかしながら、自宅で趣味でソフトウェアを開発するとなると、そのような環境は、なかなか難しいものです。
そこで、今回は私の開発環境をご紹介します。
SPORT受信DMAバッファ上のデータの並びを探る予備実験を行いました。
非ワイドFMモードでは、SPORT各チャンネルにサンプルあたり2ワードのデータが転送されます。そのため、タイミングによってはこれらがABABと受信されたりBABAと受信されたりします。これは想定できることであり、当然ですがプログラムはそれに左右されないように作らなければなりません。
一方で、口伝えで「ADSP-BF533ではSPORTのプライマリ・チャンネルとセカンダリ・チャンネルのデータがバッファ上で反転する」という話を聞いたことがあります。実際、TRX-305のデータは、データの位置に依らずデータを見るだけでプライマリ・チャンネルのデータかセカンダリ・チャンネルのデータなのかを見分けることが出来ます。つまり、両チャンネルのデータがバッファ上で入れ替わるであろうと想定しているわけです。
そこで、SPORT受信開始時のデータを観測して、データの並びを調べてみました。結果として「プライマリ・チャンネルとセカンダリ・チャンネルが判定することはない」という結論に達しました。
前回大まかに説明したように、RX IFのデータはなかなか複雑です。
こういったデータをリアルタイムに扱いながら一台の受信機として成立させるために、いくつかあらかじめ考えておくべき事があります。
TRX-305のDSPファームウェアに関しては、ブート問題が私の手を離れたため、しばらくはDSP用フレームワークの事だけを考えればよくなりました。これでようやく落ち着いて設計出来ます。
これからしばらく私自身の考察をかねて、FPGAとDSPがやりとりするデータについて書いていきます。おおむね書き終わる頃には解決しなければいけない問題と、ソフトウェアの構造もはっきりするでしょう。プログラムもデータも、その構造は解決すべき問題の構造に従ったものになるからです。
TRX-305上でBlackfinのオブジェクトが起動しない問題が続いています。とうとう、別基板で調査することになりました。
冬休みの間、ELFLOADERやbfin-elf-ldrが生成するLDRファイルを精査したり、LDRフォーマットのドキュメントを精読したりしました。が、両者の間に差はあるものの、ドキュメントに記述されている範囲内で問題だと思えないこと、それ以前に、明らかにドキュメントに記されていない形でLDRフォーマットが使われていることから、フォーマット面について理責めしていくのは、ほぼ絶望的になりました。
一方でTRX-305は基板が高密度で、プローブをBF533の足に押しつけながら測定などとうてい出来そうに無いため、ここに来てあきらめてさらに違う基板で動作を検証することにしました。