C言語FFTライブラリ

今回はC言語ベースのFFTライブラリについて紹介します。音や画像などを処理する場合に欠かせない処理としてFFTがあります。1次元の場合はFFT処理で時間毎の信号を周波数ごとの信号に変換できます。1からFFT処理を実装するよりも多くの場合はライブラリを活用すると思います。今回は代表的なFFTライブラリを紹介したいと思います。

■FFTW3

・ライセンス

　GPL、商用ライセンス

・メリット

　多次元対応

　CPUの拡張命令によってより高速な処理が可能

　マルチスレッド対応

・デメリット

　GPLライセンス

　専用ライブラリを組み込む必要がある

　fotranコンパイラが必要

　malloc使用

　→組み込み系には向かない

■FFTSS

・ライセンス

　修正 BSD

・メリット

　BSDライセンス

　FFTWと互換インタフェース

　多次元対応

　fotranコンパイラ不要

・デメリット

　全てのFFTW関数と互換があるわけではない

　コード構成が複雑

　malloc使用

　→組み込み系には向かない

■FFTSG

・ラインセンス

　フリーソフトウェア

・メリット

　コード構成がシンプルで移植が容易

　CPUの拡張命令未使用で移植性が高い

　マルチスレッド対応

　malloc使用/未使用選択可能

　組み込み系にも移植可能

・デメリット

　CPUの拡張命令未使用で速度は期待できない

■CMSIS-DSP Library

・ライセンス

　 Apache2.0

・メリット

　ARM DSPを活用した高速処理

・デメリット

　ARMDSP搭載マイコンのみ使用可能

　ARMDSP専用で移植性が低い

　サイズ最大4096点

PCアプリケーションで使用する場合はFFTSSやFFTSGがお勧めです。組み込み系の場合はFFTSGがお勧めです。

STM32マイコンでFPU搭載の場合、FFTSGとCMSIS-DSPライブラリで同じ処理点数で速度差はほとんどありませんでした。DSPを使用するCMSIS-DSPライブラリの方がハードウェア演算を利用するため、若干速くなります。

ただ、最適化されたFFTとFPUによってFFTSGも高速に処理できるため、あまり差がなくなっています。一方、CMSIS-DSPライブラリは最大4096点と用意されている関数の点数に制約があります。また、事前にVisualStudio等のコンソールアプリケーションとして単体テストしてからマイコンに移植するといった用途も考えるとFFTSGの一択となります。FFTSGのソースコードはdoubleとなっているため、STM32マイコン等に移植する際にはソースコード内のdoubleを丸ごとfloatに置換させるとFPUで高速に処理できるようになります。なお、FFTSGはサイズ最大4096点の制約がないものの、4096点以上の場合に膨大なRAMメモリが必要となります。高性能マイコンや外部RAM搭載マイコンが必要となります。

mbedからSW4STM32インポート時のエラー対策

あけましておめでとうございます。2021年も組み込み系を中心として情報発信や開発を行っていきたいと思います。

今回は今回はよくあるmbedからのインポート時に生じるエラーの対処方法について紹介します。mbedの機能としてオフライン開発環境のプロジェクトファイルとしてエクスポートできる機能があります。ただ、プロジェクトによってはmbedからエクスポートしたプロジェクトをSW4STM32等にインポートするとエラーでビルドできない場合があります。エラー内容に応じて下記の対策を行います。

■mbed namespace undefined mbedエラー

プロジェクト内にC言語のcファイルがある場合に発生します。mbedはC++言語のため、ファイルを強制的にcppファイルに拡張子を書き換えることで対処することができます。多くの場合、コード自体を書き換える必要はありません。

■nano.specs: attempt to rename spec 'link' to already defined spec 'nano_link' エラー

プロジェクトのプロパティからC/C++Build設定のSettings、Tool Settings、MCU GCC Linkerの設定で、-specs=nosys.specs -specs=nano.specを削除します。

また、プロジェクトフォルダ直下にmakefile.targetファイル内に2か所(debugとrelease)ある

-specs=nosys.specs -specs=nano.specを同様に削除します。

■Undefined reference to `_getpid', to `_kill', and others エラー

暫定対策ではありますが、main.cppファイル内に下記の2行を追加することでエラーを回避させます。

extern "C" int _getpid(void){return 1;}

extern "C" void _kill(int pid){while(1);}

以上のような対策でよくあるmbedからのインポート時のエラーに対処できます。他のエラーに遭遇した場合にはまた追記していきたいと思います。

STM32 UARTパリティ設定 注意点

STM32マイコンのUARTでパリティを使用する際の注意点について紹介します。通信相手によってはパリティビットを使用する場合があります。STM32マイコンのUARTにもパリティ設定項目があり、パリティなし、偶数パリティ、奇数パリティに対応しています。ただ、パリティを使用する際に注意点があり、注意点に気づかずに設定すると意図したデータが送受信されません。

パリティを使用する際の注意点として、パリティビットを含めたデータ長を設定する点です。具体的には8bitの送受信データでパリティビット有効にした場合はデータ長は9bitとして設定します。8bitのままの場合、パリティビットを含めて8bitとなり、送受信のデータ長は7bitとして扱われ、0x00~0x7Fまでのデータしか送受信されません。

STM32CubeMXの設定項目をよく見ると「including Parity」と記載があり、パリティビットを含めたデータ長を設定することが分かりますが、あまり考えずに設定すると見落としがちです。特にCubeMXから生成した後にコード上で変更すると設定項目の注意書きにも気づかないため、特に注意が必要です。

STM32 USB CDC応用

以前、STM32 USB CDC注意点について紹介しました。今回はUSBの接続有無確認やCOMポートのオープンといった確認する方法を応用編として紹介します。

■USB接続有無確認方法

ステートを確認することでPC等のホスト側とのUSB接続有無を確認することができます。STM32 HALライブラリのUSB CDC以外でも利用できます。USBデバイスのハンドルのdev_stateから確認できます。dev_state が USBD_STATE_CONFIGURED の場合はUSBがPCと接続されている状態です。例えば下記のような使い方ができます。

if(hUsbDeviceFS.dev_state == USBD_STATE_CONFIGURED)

{

   //USBが接続されている場合

}

else

{

  //USBが接続されていない場合

}

■COMポートオープン有無

CDCの場合、USB接続の有無だけでなく、COMポートのオープン有無を確認したい場合が多々あると思います。通信で確認する他に間接的ではありますが、CDC_GET_LINE_CODINGの呼び出しイベントから確認できます。電源ON後のUSB認識時とCOMポートオープン時にそれぞれ2回から3回、CDC_GET_LINE_CODINGのイベントが発生します。このイベント発生をカウントすることでCOMポートのオープンを確認することが可能です。

usbd_cdc_if.cファイル内のCDC_Control_FS関数のCDC_GET_LINE_CODING条件を下記の様に書き換えます。必要に応じて下記の様にカウンタとフラグを設定して確認できるようにします。

case CDC_GET_LINE_CODING:

{

  USBD_SetupReqTypedef * req = (USBD_SetupReqTypedef *)pbuf;

  if((req->wValue & 0x0001) != 0) //ドライバによっては不要

  {

    comOpenCount++;

    if(comOpenCount>3)IsComPortOpen=true;

  }

}

STM32マイコンのUSB関連のHALライブラリについても、最低限の機能は実装されているため、少しコードを追加することで応用することが可能です。他にも便利な機能等あれば、また紹介したいと思います。

コード移植時のチェック項目

STM32マイコンのHALライブラリは移植性が高く、STM32FxxやSTM32Lxxといったシリーズを超えた場合でもほぼそのままのコードで動かすことができます。シリーズによっては一部の関数で引数が増えていたり、設定が異なっているものもありますが、多くはそのまま移植することができます。ただ、時々、移植してもうまく動かない、同じシリーズでも動作しないといった場合があります。そのような場合はコードの分かりずらい箇所で設定が違っていたり、コード以外の設定が違って動かないということがあります。

今回はコード移植時にうまく動かない場合のチェック項目について紹介します。これまでの経験でよくあるコード移植時の設定漏れをリストにしてみました。

�@リンカスクリプト

プロジェクトフォルダ直下にSTM32Fxxxxx_FLASH.ldファイルがあります。メモリ配置を設定するスクリプトでSDRAMやSRAM、密結合メモリ等の設定をしています。また、HeapサイズやStackサイズを定義しています。サイズが異なる場合にメモリを確保できず、エラーとなっている場合があります。

�Aスタートアップファイル

プロジェクトフォルダ直下のstartupフォルダにstartup_stm32fxxxxx.sファイルがあります。起動直後に呼び出される処理が記載されています。稀に初期化処理や割込み処理を意図的に変更している場合があります。

�Bプリプロセッサ

SW4STM32の場合、プロジェクトのプロパティから[C/C++ Build]→ [Settings]→ [Tool Settings]→ [MCU GCC Compiler]→ [Preprocessor] の定義を確認します。うまく動くプロジェクトと比較して抜けがないか、確認します。コード上で定義(#define)せずにここで定義している場合があります。定義項目が抜けているとコードが部分的に除外され、挙動や動作が異なる場合があります。必要に応じて追加します。

�C割込み

プロジェクト直下のsrcフォルダ内のstm32fxxx_it.cファイルに割込み処理の設定がされています。よくある移植時の設定ミスとして、タイマの割込み関数内に直接、割込み関数が定義されている場合があります。また、割込み設定がされておらず、関数自体がない場合もあります。特にHAL_Delayが動作しない、HAL_Delayで停止してしまう場合はstm32fxxx_it.cファイル内にSysTick_Handler関数が定義されているか確認します。合わせて、SysTick_Handler関数内にHAL_IncTick関数が呼び出されているか確認します。

WinMerge等でプロジェクトフォルダを丸ごと比較できる場合は移植時のミスに気づきやすいですが、フォルダ内の構造が違っていたり、異なるシリーズに移植した際はファイル名が異なるため、単純比較できないということも多々あります。このような場合に上記の項目について確認すると漏れに気づくことが多いです。他にもよくある漏れがあれば追記したいと思います。