ベンチ検討中

By 酔漢 - Last updated: 金曜日, 1月 13, 2017

作業用のベンチを作ろうと画策しています。

昨年の頭頃に、

「いい加減、ちゃぶ台で半田づけするのは嫌だ」

と思い始めてベンチを作ろうとあれこれ調べていました。結局昨年は公私共々に多忙になってそういったことを考える余裕が無かったのですが、年も明けて、だいぶ前向きな考え方ができるようになってきました。

当初は3メートルくらいの台を作って、左でPC、右で作業と考えていました。広く作業できるのが利点ですが、部屋の窓へアクセスできなくなるため、家族が難色を示していました。夏熱いですしね。ところが、Twitterの「電子工作愛好家の作業環境が見たい」タグを見て、だいぶ考えが変りました。

今考えているのはPCのモニタ+ステレオスピーカーの幅に抑えて、横にメタルラックを立てると言うものです。奥行きは少し深め。こうすると机の横から余裕を持って部屋の窓へアクセスできます。また、奥行きを深く持つことでモニタの後ろにラジオやオーディオインターフェースを置き、マウント・アームでモニタを跳ね上げて使うことで、スペースを効果的に活用できます。モニターのハネ上げは、半田付けで汚れることの回避にもなりますね(ラジオが汚れる…)

毎回引っ張り出すのに難儀しているオシロスコープや顕微鏡はラックに収納しておけば手軽です。机が今より広いため、アームと照明のついたルーペをマウントすることもできます。

なかなか夢が広がります。

Filed in 日記

STM32F746の信号処理性能

By 酔漢 - Last updated: 日曜日, 1月 8, 2017

いろいろ問題がありましたが、Nucleo F746ZG用のUI基板『浮舟』が完成しました。浮舟には性能測定用のテストポイントを付けましたのでオシロスコープの接続が容易です。ということで、ようやく肝心の性能評価にかかりました。

結論から書くと、十分な性能がでています。

三角関数

stdlibのsin()関数の実行です。

sin()関数の1回の実行が1.16uSです。これは割り込み処理等のフレームワーク・オーバーヘッドを含みます。一方、ブロックサイズ=11とした11回の実行は同じくオーバーヘッド込みで8.81uSです。ですので、1回の実行時間は0.76uSです。

サンプル周期は20uSです。もくろんでいるアルゴリズムは、この間に4回程度sin/cosを実行することになると思われます。その時間が3uSなら、許容範囲です。archtan()についても調べましたが、同程度の計算時間です。

Office Lens 20170108-160953

Office Lens 20170108-161140

FIRフィルタ

CMSISのarm_fir_f32()を使って100タップの浮動小数点FIR関数を実行しました。ブロックサイズ=1のときは割り込みオーバーヘッド込みで4.2uS。ブロックサイズ=11の時は同じく17.9uSです。このことから1000タップの実行時間は13.7uS、1タップの平均は13.7nSとなります。

処理速度としては申し分ありません。おおよそ200MHzでこの性能と言うことは、タップあたり3サイクルを切っており、汎用CPUによる信号処理としては文句の付けようがない性能です。

Office Lens 20170108-164116

Office Lens 20170108-164414

まとめ

「Fs=48kHzで1サンプルの間にsinとcosを計4回、128タップのフィルタを4本回せると良いな」と、考えていましたが、充分以上の性能でした。この処理ならSTM32F746を200MHzで動作させて、だいたい50%くらいの処理負荷になりそうです。

Filed in 日記

Nucleo F746ZG用UI基板

By 酔漢 - Last updated: 火曜日, 1月 3, 2017

明けましておめでとうございます。

この正月は、昨年12月にはいってから作業していたNucleo F746ZG用UI基板『浮舟』のテストをしていました。

このボードはNucleo F746ZG用コーデック・アダプタ『桐壺』とペアで使うことを想定した基板で、組み合わせて使うことで、Nucleo F746ZGの浮動小数点演算能力をどの程度オーディオ信号処理に使えるか実験したいという目録見です。

昨年末は忙しかったため、ようやく年末になって組み立てに着手出来たのですが、さて結果はと言うとぼろぼろです。問題点を列挙すると以下のようになります。

特にUSBシリアル・ポートとのかぶりは問題です。低価格評価基板と言うことで甘く見ていましたが、Nucleo F746ZGには多数のショート・ブリッジが実装されており、ピンをGPIOに振るか、EthernetやUSBのような高機能IFに振るかを選択できます。今回、EthernetやUSBは使いませんが、USBシリアル・ポートはmbedの重要なデバッグ手段ですので看過できません。

結局、部品の変更やシルクの不満点などの修正点と併せてレイアウトを変更し、ver2として新年のうちに作り上げました。今日、ガーバーをスイッチサイエンスに送りました。早くすれば1月中旬のうちに新しい基板がくるでしょう。中国の正月とぶつかることは避けたいものです。

Filed in 日記

InterpolatorとDecimatorの制約

By 酔漢 - Last updated: 日曜日, 12月 18, 2016

オーディオ用のInterpolatorとDecimatorはFIRフィルタの変形として実装することが多いですが、一般には係数長やブロックサイズ長に制約があることは知られていません。

何故知られていないかというと、あはは使われないからです。あはは。サンプル周波数を変える等というのは、なかなかアマチュアのフィールドには降りてきません。そんなものを使う場合にはエキスパートなわけで、エキスパートはエキスパートのコミュニティを持っているから一般には知る必要も無いと言うことでしょう。

実際にどんな制約があるか、CMSISのDSPライブラリを見てみましょう。たとえば、arm_fir_decimate_init_f32()の返り値に関する記述を読んでみると以下の記述があります。

The function returns ARM_MATH_SUCCESS if initialization was successful or ARM_MATH_LENGTH_ERROR if blockSize is not a multiple of M.

多少記述が曖昧ですが、blockSizeはダウンサンプル比Mの整数倍でなければなりません。明示されてはいませんが、同じ制約がarm_fir_decimate_f32()にもあるはずです。

また、arm_fir_interpolate_init_f32()には以下の記述があります。

The function returns ARM_MATH_SUCCESS if initialization was successful or ARM_MATH_LENGTH_ERROR if the filter length numTaps is not a multiple of the interpolation factor L.

係数長はアップサンプル比Lの整数倍でなければなりません。

自分で実装するとこれらの制約は自明なものとして頭に入るのですが、使うときにはちょっとした罠になるため注意が必要です。

Filed in 日記

OneDriveとOneDrive for Businessはembedの方式が違う

By 酔漢 - Last updated: 月曜日, 12月 12, 2016

昨日、signalbottom関連のデータアップロードに手間取ってしまいました。原因はOneDriveとOneDrive for Businessの違いです。

WordPressには外部サイトからのembedデータを埋め込む機能があり、スライド埋め込み用としてずっと利用しています。ところが、今回急に使えなくなりました。理由は私がデータをOneDriveからOneDrive for businessに動かしたことです。両者はembedデータのexport形式が異なり、OneDrive for businessのデータをwordpressに埋め込むことはできないのでした。

いろいろとあしを取られる事が多いです。

Filed in 日記

C言語のfloatとdouble

By 酔漢 - Last updated: 月曜日, 11月 28, 2016

昨日書いたエントリは、少し混乱気味でした。

話の内容としては「バグを取り除いた」「しかしまだ比較的大きめな雑音が残っている」と言う二つの話なのですが、書き方が悪くて「バグを取った、それが雑音の元だった」と言う文章に読めてしまいます。ちょっと書き直していますので、昨日読んだ方は読み直していただければと思います。

さて、バグ取りの内容ですが、「評価プログラムの浮動小数点型がfloatだったのでdoubleに直した」というものです。

実装したCORDICは32bit固定小数点数です(精密に言えばQ2.30フォーマット)。したがって、制度調査をする場合、基準となる浮動小数点sine関数は、倍精度浮動小数点にする必要があります。単精度浮動小数点数は、隠しビットを含めても仮数部が24ビットしかないからです。

ということで当然倍精度浮動小数点型を使わなければならないのですが、それがわかっていてfloatを使っていたというのがバグです。つまり、私のC++言語に対する理解の誤りが根本原因でした。

私はC言語の知識が古いので、K&Rの「float型はコンパイル時にdoubleに昇格される」という知識が頭にこびりついています。C言語のANSI標準制定時にこのルールは改正され、floatはfloatとして扱われる事になっています。それは頭にたたき込んだ覚えがあるのですが、いつの間にやら溶けて消えたようです。

私の場合、経歴の長い部分をDSP屋として過ごしています。「このプロセッサではfloatは32bit。しかしそれはDSPだから」という誤った先入観念が邪魔をして「x86ではfloatは32bit、あくまで32bit」という事が頭に定着するのを阻害していたのだと思います。

言い訳でしか有りません。正しい知識無くしては、プログラムは正しく動作しないと言う当たり前のことです。

Filed in 日記

精度評価進行中

By 酔漢 - Last updated: 日曜日, 11月 27, 2016

土曜日にSignalbottomの呑み会がありました。今回も大変刺激的なプレゼンを聞くことができ、励みになりました。みなさん、ありがとうございます。

さて、VHDLで書いたSinCosのCORDICですが、再度評価プログラムのバグが見つかり、かなり大きいとため息をついていた誤差がぐっと小さくなりました。

一方で、まだ結構大きめな雑音があります。CORDICは1ステージ増やす度に1bit誤差が小さくなるアルゴリズムなのですが、一方でLSBから累積されていく丸め誤差の総和は増えていきます。ここは理屈の上では1ステージあたり0.5LSBの誤差なのですが、実際にはシフト部での丸めとあらかじめ計算している進角の持つ0.5LSBの誤差が両方効いてきます。N回誤差の蓄積は一般に√N倍になるわけですが、統計的に見てみれば、N倍のピークがあっても不思議ではありません。

あらかじめ必要なビット精度を定めた後、丸めで汚染されるビットを切り捨てるために事前シミュレーションが必要なようです。

精度はもう少し評価してみます。

Filed in 日記

SinCos CORDIC精度評価開始

By 酔漢 - Last updated: 金曜日, 11月 25, 2016

VHDLで設計したSinCos CORDICの精度評価を開始しました。

実際には、精度評価をするのはVHDLによる設計ではなくC++によるモデルの方です。両者はビット単位で合致するようチェックをかけていますので、それを担保にC++でテストをします。C++の方が親しんでいる分、テストプログラムを書きやすいです。

で、昨日は初っぱなから躓きました。妙な誤差があります。0と±πではほとんど誤差がないのに、その間では盛り上がるように誤差が増えていきます。誤差の絶対値としては126dBくらいです。一見、十分低いようですが32bit精度でこれでは困ります。熟考後、当たりを付けたのがπ精度。テストプログラムではエイヤ!と3.141592を使っていたのですが、これが原因でした。精度を倍精度浮動小数点数に合わせると、平均で30dBくらい改善したようです。ちょっと盛りすぎか。

ピークにはまだ不満があるので、腰を据えて追いかけていきます。

Filed in 日記

int32_t

By 酔漢 - Last updated: 木曜日, 11月 17, 2016

32bit幅を仮定する整数をint32_tに変更しました。

「ポータブルにしよう」としたのはいいのですが、標準でビット幅保証の型が存在しているとは知りませんでした。不勉強です。

Filed in 日記

32bit整数

By 酔漢 - Last updated: 水曜日, 11月 16, 2016

C++のint型を32bitと仮定することに漠然と不安を感じます。

用途がVHDLのモデル記述である以上、プラットホームはx86/AMD64上のUbuntuになります。大きく見積もってWindowsが加わるくらいですが、この範疇だとgccのintのサイズは32bitです。ですからそれほど心配する必要はありません。

が、やはり不安を感じます。vhdlint32みたいな型をtypedefで作った方がいいんでしょうね。

Filed in 日記