組み込みソフトウェアの場合、OSSといえどもターゲット基板は必要です。
作業効率を考えれば、基板は作業机に置いてあって電源さえ入れればいつでもデバッグ出来るという環境が理想です。しかしながら、自宅で趣味でソフトウェアを開発するとなると、そのような環境は、なかなか難しいものです。
そこで、今回は私の開発環境をご紹介します。
間が空いてしまいました。いいわけでしかありませんが、仕事のトラブルがおきると長距離通勤者はもうダメですね。仕事と通勤でごっそり体力を持って行かれます。若い頃はそれでも何とかなったものですが。というか、トラブルが無くても平 … 続きを読む
SPORT受信DMAバッファ上のデータの並びを探る予備実験を行いました。
非ワイドFMモードでは、SPORT各チャンネルにサンプルあたり2ワードのデータが転送されます。そのため、タイミングによってはこれらがABABと受信されたりBABAと受信されたりします。これは想定できることであり、当然ですがプログラムはそれに左右されないように作らなければなりません。
一方で、口伝えで「ADSP-BF533ではSPORTのプライマリ・チャンネルとセカンダリ・チャンネルのデータがバッファ上で反転する」という話を聞いたことがあります。実際、TRX-305のデータは、データの位置に依らずデータを見るだけでプライマリ・チャンネルのデータかセカンダリ・チャンネルのデータなのかを見分けることが出来ます。つまり、両チャンネルのデータがバッファ上で入れ替わるであろうと想定しているわけです。
そこで、SPORT受信開始時のデータを観測して、データの並びを調べてみました。結果として「プライマリ・チャンネルとセカンダリ・チャンネルが判定することはない」という結論に達しました。
前回大まかに説明したように、RX IFのデータはなかなか複雑です。
こういったデータをリアルタイムに扱いながら一台の受信機として成立させるために、いくつかあらかじめ考えておくべき事があります。
TRX-305のDSPファームウェアに関しては、ブート問題が私の手を離れたため、しばらくはDSP用フレームワークの事だけを考えればよくなりました。これでようやく落ち着いて設計出来ます。
これからしばらく私自身の考察をかねて、FPGAとDSPがやりとりするデータについて書いていきます。おおむね書き終わる頃には解決しなければいけない問題と、ソフトウェアの構造もはっきりするでしょう。プログラムもデータも、その構造は解決すべき問題の構造に従ったものになるからです。