デシベル計算の高速化
前回記事でべき乗(pow)や対数(log)の演算は遅いということが分かりました。デジタルエフェクターではデシベル計算をよく使うため、これらの演算を高速化することを考えます。(以下、C言語を前提とした記述となっています。)
< dB x → 電圧比(倍率) y >
通常の計算は y = powf( 10.0f, x / 20.0f ) ですが、500サイクル程度かかります。そこでテーブル引きという方法を使います。あらかじめ表(ルックアップテーブル)を用意しておき、そこから値を取り出して計算する方法です。
今回テーブルは-128dB~+128dBの範囲で1dBステップとしました。小数点以下の部分については線形補間(2点間を一次関数に当てはめる)で近似します。コードは下記の通りです。dbtovolTable.hファイルはGitHubに置いています。
xiにはuint8_tの0~255が入るので、テーブル配列のサイズは257にすればよいです。もちろん入力値が範囲外の場合は正しい値が出力されません。誤差は最大0.015dBで、実用には充分だと思います。サイクル数は約30となり大幅に高速化できました。
< 電圧比(倍率) x → dB y >
通常の計算は y = 20.0f * log10f( x ) ですが、230サイクル程度かかります。こちらもテーブル引きを利用したいところですが、等比級数的なテーブルを準備する方法がわかりませんでした。膨大な量の配列を準備している例もありますが、メモリが少ない場合には無理があります。
今回はsqrtf演算(=1/2乗)が高速なことを利用することにしました。以下のように式を変形します。
log x
= log ( x1/2 )2
= 2 log x1/2
・・・
= 32 log x1/32
あとは x1/32 とdBの関係を三次関数で近似します。コードは以下の通りです。
使用範囲は0.00001(-100dB)~1(0dB) 推奨、最大誤差0.016dBです。電圧比というより音量変換を見据えた範囲としています。範囲を超えると誤差が増えますが、極端に外れた値にはなりません。サイクル数は約90で、効果はそれなりでした。
他にもいろいろな方法を試したのですが、条件分岐を入れると意外とサイクル数が増えてしまう等、なかなかこれといった方法が見つかりませんでした。場合によっては通常のlog10fを使うことになりそうです。
< dB x → 電圧比(倍率) y >
通常の計算は y = powf( 10.0f, x / 20.0f ) ですが、500サイクル程度かかります。そこでテーブル引きという方法を使います。あらかじめ表(ルックアップテーブル)を用意しておき、そこから値を取り出して計算する方法です。
今回テーブルは-128dB~+128dBの範囲で1dBステップとしました。小数点以下の部分については線形補間(2点間を一次関数に当てはめる)で近似します。コードは下記の通りです。dbtovolTable.hファイルはGitHubに置いています。
#include "dbtovolTable.h"
float dbtovol(float x)
{
x += 128.0f;
uint8_t xi = (uint8_t) x;
return dbtormsTable[xi] + (dbtormsTable[xi+1] - dbtormsTable[xi]) * (x - xi);
}
xiにはuint8_tの0~255が入るので、テーブル配列のサイズは257にすればよいです。もちろん入力値が範囲外の場合は正しい値が出力されません。誤差は最大0.015dBで、実用には充分だと思います。サイクル数は約30となり大幅に高速化できました。
< 電圧比(倍率) x → dB y >
通常の計算は y = 20.0f * log10f( x ) ですが、230サイクル程度かかります。こちらもテーブル引きを利用したいところですが、等比級数的なテーブルを準備する方法がわかりませんでした。膨大な量の配列を準備している例もありますが、メモリが少ない場合には無理があります。
今回はsqrtf演算(=1/2乗)が高速なことを利用することにしました。以下のように式を変形します。
log x
= log ( x1/2 )2
= 2 log x1/2
・・・
= 32 log x1/32
あとは x1/32 とdBの関係を三次関数で近似します。コードは以下の通りです。
#include <math.h>
float voltodb(float x)
{
x = sqrtf(sqrtf(sqrtf(sqrtf(sqrtf(x)))));
return - 559.57399f + 995.83468f * x
- 591.85129f * x * x + 155.60596f * x * x * x;
}
使用範囲は0.00001(-100dB)~1(0dB) 推奨、最大誤差0.016dBです。電圧比というより音量変換を見据えた範囲としています。範囲を超えると誤差が増えますが、極端に外れた値にはなりません。サイクル数は約90で、効果はそれなりでした。
他にもいろいろな方法を試したのですが、条件分岐を入れると意外とサイクル数が増えてしまう等、なかなかこれといった方法が見つかりませんでした。場合によっては通常のlog10fを使うことになりそうです。
STM32 計算速度データ
デジタルエフェクターでリアルタイムにデジタル信号処理をする場合、計算が間に合わずまともな音が出なくなるという可能性があります。そこで、様々な計算方法についてどの程度処理時間がかかるのか確認しておくことにしました。使ったのはNUCLEO-F401REで、FPU(浮動小数点演算処理装置)を備えています。開発環境はSTM32CubeIDE(1.0.2)です。
経過時間を確認するには、CPUのクロックサイクルのカウント数(以下サイクル数)を利用すると便利です。下記の記載をしておくと、サイクル数を確認できるようになります。(参考ページ→ARMのData Watchpoint and Trace Unitを使って処理時間計測をしてみよう)
そして下記のようにコードを書きます。「DWT->CYCCNT」に現在のサイクル数が入ります。コンパイル時に最適化されないように、volatileを入れ、サイクル数を変数として使うことにします。
上記「変数の代入」を基準として、処理を追加した場合にどのぐらいサイクル数が増えるかを確認しました。例えば乗算の場合、「ivar[1] = start * stop;」のようにして、変数の乗算を1つ追加するといった具合です。定数を使うと事前に計算されてしまう場合があるため、全て変数を使います。
コンパイル時の最適化オプション「O0(最適化なし)」と「Ofast(最速最適化)」での違いも確認します。1000回平均値ですが結果が結構変わるときがあり、あまり正確ではなさそうです。
<32ビット整数(uint32_t)>
変数の呼び出しに数サイクル必要なのか、代入だけで結構時間がかかるようです。剰余演算がそんなに遅くないというのが意外でした。
<32ビット浮動小数点数(float)>
定数での除算の場合は最適化で乗算と同じ速さになりますが、変数だと遅いままとなってしまいます。
C言語標準ライブラリmath.hにある数学の関数については以下の通りです。
デシベル計算に使うpowfがかなり遅いので、ルックアップテーブルの利用を考える必要がありそうです。
CMSIS-DSPライブラリを導入し、とりあえず2つの関数を使ってみました。(参考ページ→STM32 CubeIDE環境で、CMSIS-DSPを使う方法)
今後、BiQuadフィルタやフーリエ変換等の活用について検討したいと思います。
経過時間を確認するには、CPUのクロックサイクルのカウント数(以下サイクル数)を利用すると便利です。下記の記載をしておくと、サイクル数を確認できるようになります。(参考ページ→ARMのData Watchpoint and Trace Unitを使って処理時間計測をしてみよう)
CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
そして下記のようにコードを書きます。「DWT->CYCCNT」に現在のサイクル数が入ります。コンパイル時に最適化されないように、volatileを入れ、サイクル数を変数として使うことにします。
volatile uint32_t start = 0;
volatile uint32_t stop = 0;
volatile uint32_t ivar[50] = {};
volatile uint32_t cnt[50] = {};
start = DWT->CYCCNT; // 開始時サイクル数
ivar[0] = start; // 計測したい処理
stop = DWT->CYCCNT; // 終了時サイクル数
cnt[0] = stop - start; // 処理にかかったサイクル数
上記「変数の代入」を基準として、処理を追加した場合にどのぐらいサイクル数が増えるかを確認しました。例えば乗算の場合、「ivar[1] = start * stop;」のようにして、変数の乗算を1つ追加するといった具合です。定数を使うと事前に計算されてしまう場合があるため、全て変数を使います。
コンパイル時の最適化オプション「O0(最適化なし)」と「Ofast(最速最適化)」での違いも確認します。1000回平均値ですが結果が結構変わるときがあり、あまり正確ではなさそうです。
<32ビット整数(uint32_t)>
| サイクル数(O0) | サイクル数(Ofast) | |
| 何もしない | 8 | 4 |
| 代入(=)※基準 | 16 | 7 |
| 加算(+) 減算(-) 乗算(*) | 5 | 3 |
| 除算(/) | 9 | 7 |
| 剰余演算(%) | 11 | 8 |
| 各ビット演算(& | ! ^ >> <<) | 5 | 3 |
<32ビット浮動小数点数(float)>
| サイクル数(O0) | サイクル数(Ofast) | |
| 代入(=)※基準 | 16 | 7 |
| 加算(+) 減算(-) 乗算(*) | 5 | 4 |
| 除算(/) | 17 | 17 |
C言語標準ライブラリmath.hにある数学の関数については以下の通りです。
| サイクル数(O0) | サイクル数(Ofast) | |
| sqrtf | 51 | 16 |
| logf | 189 | 189 |
| expf | 216 | 207 |
| powf | 565 | 571 |
| sinf | 82 | 79 |
| sinhf | 286 | 283 |
| atanf | 189 | 178 |
CMSIS-DSPライブラリを導入し、とりあえず2つの関数を使ってみました。(参考ページ→STM32 CubeIDE環境で、CMSIS-DSPを使う方法)
| サイクル数(O0) | サイクル数(Ofast) | |
| arm_sqrt_f32 | 91 | 13 |
| arm_sin_f32 | 56 | 52 |
タグ : マイコン
STM32 SPI接続タッチパネル付ディスプレイを使う

Amazon等で取り扱いがある、320×240ドットのSPI接続タッチパネル付2.8インチディスプレイモジュールを使ってみます。前回とは違うILI9341という制御ICです。
Nucleoボードとディスプレイモジュールとの接続は下図の通りです。消費電流は実測50mA程度でした。

※電源に5Vではなく3.3Vを供給する場合は、モジュール裏面のジャンパー(J1)を繋ぎます。最初気づいていませんでしたが、一応動作していました。
<STM32CubeIDE(1.0.2) iocファイル Pinout & Configurationタブ>
・右側列 IC画像
設定済ピンを変更しておく
(21)-PA5 : SPI1_SCK
ピン設定
(38)-PC7 : GPIO_Output
(42)-PA9 : GPIO_Output
(43)-PA10 : GPIO_Output
(56)-PB4 : GPIO_Input
(58)-PB6 : GPIO_Output
左側列のConnectivity→SPI1を開く
・中央列上側 Mode
Mode : Full-Duplex Master
・中央列下側 Configuration→Parameter Settingsタブ
Data Size : 8 bits
Prescaler (for Baud Rate) : 64 ※通信がうまくいかない場合は値を大きくして速度を落とします。
<STM32CubeIDE(1.0.2) main.cファイル他>
下記ページのライブラリを利用します。
github.com/afiskon/stm32-ili9341(右側の[Clone or download]ボタンから全ファイルをダウンロードできます。)
Lib/ili9341フォルダ内の7ファイルを自分のプロジェクトの各フォルダへコピーします。
Incフォルダ→fonts.h ili9341.h ili9341_touch.h testimg.h
Srcフォルダ→fonts.c ili9341.c ili9341_touch.c
STM32F3シリーズのNucleoボードを使う場合、ili9341.cとili9341_touch.c最上部に記載されている"stm32f4xx_hal.h"を"stm32f3xx_hal.h"へ変更します。STM32F4シリーズの場合は、そのままでOKです。使用するGPIOピンはili9341.hとili9341_touch.hに#defineで定義されています。
ライブラリのmain.cから以下の3箇所のコードを自分のプロジェクトのmain.cへコピーします。
/* USER CODE BEGIN Includes */〜/* USER CODE END Includes */
/* USER CODE BEGIN 0 */〜/* USER CODE END 0 */
/* USER CODE BEGIN WHILE */~/* USER CODE END WHILE */
実行しディスプレイに画像等が表示されれば成功です。最後の黒い画面ではタッチパネルのテストができます。前回のディスプレイは描画した後毎回画面を更新していましたが、今回はその必要はありません。
タグ : マイコン
Nuzz

「Nutube自作エフェクターコンテスト」第二弾に向けて製作したエフェクターです。読み方は「ニャズ」で、一応肉球のような筐体デザインとなっています。
第一回コンテストでアイデアが出尽くしているのでどのような回路にするか悩みましたが、誰もやっていなさそうなグリッド接地回路を採用することにしました。Nutubeでのグリッド接地回路では、入力をフィラメントに加えるしかありません。フィラメントは過大入力により焼き切れてしまうため、必ずクリッピングが必要です。そういうわけでハードクリップした音を使うファズを作ろうと考えました。
▽回路図

<Nutube周辺>
フィラメントへの入力はなぜか片方だけでは出力が低くなったので両方にしています。R9~R11は最も増幅率が高くなるように調節しました(R9は通常トリマーにする必要があると思います)。それでもNutube部分では5倍程度の増幅率なので歪ませるのは無理で、ただ通すだけという形になってしまいました。フィラメントの電圧は実測0.9V~1.2V程度と低いですが問題ないようです。いろいろと実験していたので、寿命が縮んだり動作がおかしくなっている部分があったりするかもしれません。オペアンプは念のため出力電流に余裕があるNJM4556Aを使用しました。
<クリッピング>
ファズはあまり作ったことがなく、ファズっぽい音というのは何なのかイマイチわかりません。Fuzz Face Analysisというページを見てみると、Fuzz Faceはかなり非対称に偏った歪みで、デューティ比が極端な矩形波となっています。おそらく偶数次倍音が多く出ているでしょう。これを踏まえ、クリッピングは片側をショットキーダイオード1個にするという極端なものとしました。半波整流にすることも検討しましたが、あまり使いやすいといえる音ではないと思います。デューティ比が極端な矩形波については、オペアンプを使って実現させるのは難しく、再現に至りませんでした。
▽レイアウト

HAMMOND1590Aサイズに詰め込みました。Nutubeはスカスカのスポンジで挟み込んでいます。スイッチング時のマイクロフォニックノイズはNuverdrive+より少なめでした。
周波数特性については、低域はカットせず高域をかなりカットするような形です。ZOOM MS-50Gに入っているTB MK1.5(おそらくトーンベンダー)と比較すると似たニュアンスの音でしたので、それなりにファズっぽさというものを出すことができていると思います。
True Bypass Relay Module

秋月電子にある特価ラッチリレーEA2-5TNAGを利用したトゥルーバイパスモジュールです。以前解析したmonomonster Relay Bypass Moduleの代わりとして考えました。マイコンを使った方が小型で長押し等に応用が効くという利点があるのですが、プログラミングが必要なのはややハードルが高いかと思います。別な方法を検索してみるとロジックIC(4069)を使ったものを見つけたので、そのまま利用することにしました。
参考ページ→Using a latching relay driver for true bypass
▽回路図

秋月電子では在庫限りの部品が多いのでご注意ください。おそらくC8(10μF)はなしでも大丈夫だと思います。
基板データはGitHubに公開しています。当初ラッチリレーのピン配置の表裏が逆というミスがあったので、公開しているデータはエラー修正済のRev.B基板です。エラー修正前のRev.A基板をお持ちの方は必ずREADME.txtの内容をご確認下さい。HAMMOND1590Bの場合は基板を立てて入れられないので、次に基板発注することがあればもう少し横長に修正するかもしれません。
スイッチングノイズをオシロスコープで確認しました。

一般的な黒い3PDTスイッチと比較すると高い音のノイズですが、音量は同程度のようです。スイッチ交換がしやすい以外の利点がないように思われますが、BOSS筐体に使うような場合には最適ではないかと思います。