掃除機 吸引圧

今回は掃除機の吸引圧について事前検討した内容を少し紹介します。なぜ、掃除機の吸引圧を検討したかというと紙パックの容量を可視化できたら便利だと思ったからです。市販品の掃除機では紙パック詰まりを表示して交換を促す製品もありますが、定量的に紙パック容量を可視化しているものはあまりありません。

今回はマキタの掃除機CL107FDに新品の紙パックを使用した状態でダストボックス内の紙パックとファンの間に圧力センサを入れ込んで吸引圧を調べてみました。

圧力センサはST製 LPS22HHの評価基板を使用して、USBシリアルI2C変換基板でPCに接続して1秒周期でNode-Redからリアルタイムに可視化してみました。

今回の掃除機は吸引パワーを3段階切り替え可能で標準→強→弱の順に切り替えてみました。

標準で1012hPaから996hPaまで低下、強で993hPa、弱で1004hPaとなりました。まとめると標準で-16hPa、強で-19hPa、弱で-8hPaという感じです。

続いて標準状態で紙パックにごみが堆積して詰まったと仮定してノズル先端を手で押さえて検討してみました。標準の996hPaから987hPaまで低下し、-9hPa程度内部の気圧が低下することが分かりました。

実際の掃除では掃除機のモードによる気圧変化だけでなく、更に掃除機のノズル形状、絨毯かフローリングかで若干基準が変わります。圧力センサを入れるだけで容易に紙パック容量を可視化というのは難しいかもしれませんが、見込みはあることが分かりました。定常的な圧力だけでなく、圧力変化の勾配等、圧力センサを活用して面白いセンサを検討してみたいと思います。

nanoDLA ロジックアナライザ

今回はロジックアナライザnanoDLAを紹介します。aitendoでも扱いがありますが、aliexpressで購入しました。8ch、24Mサンプリング、日本円で900円前後の簡易ロジックアナライザです。実際にインストールしてUSB信号(USB1.1)を解析してみました。

ソフトウェアはnanoDLA互換機となっており、こちらのサイトからPulseViewというソフトをダウンロード、インストールします。Windowsの他、Mac、Linuxにも対応しています。ドライバはZadigを用いて別途インストールします。

ZadigのインストールではOptionsからList All Devicesを選択することがポイントです。

リスト内のfx2lafwを選択してinstallドライバをクリックしてインストールします。

ドライバのインストールが完了した後、PulseViewを起動させます。

nanoDLAと接続するために赤枠のデバイスリストをクリックします。

fx2lafwを選択し、usbにチェック、scanをクリックするとデバイスが表示され、選択します。

デフォルトは1Mサンプル、20kHzのため、必要に応じて変更して、左上のRunボタンをクリックすると自動的に指定のサンプルを読み込みます。また、Configure Channelをクリックして必要な信号のみに選択することも可能です。

実際にUSB信号(USB1.1)を解析してみました。

拡大するとこんな感じです。

ロジックアナライザなので様々なプロトコルに対応しています。CAN、I2C、I2S、JTAG、SPI、UART等はもちろんのこと、この価格でSDやUSB(USB1.1のみ)、IR(赤外線通信)に対応しているのは驚きです。サンプリング周波数設定横の黄色と緑のアイコンをクリックすると対応プロトコルを選択できます。

プロトコル選択後にビュー側のプロトコルをクリックすると何の信号にプロトコルのどの信号が対応するか詳細を選択できます。

信号値だけでなく、Stack Decoderをクリックするとプロトコルに応じて処理内容を解析して補助情報を表示する機能もあります。

簡易的なロジックアナライザのため、電圧レベルが低レベル -0.5V~0.8V、高レベルは2V~5.25vで固定で絶縁等もされていませんが、非常に安価で容易に使用できるので1つあると非常に便利です。PCオシロスコープではチャンネル数が2chや4chと限定され、後から信号レベルを読み取る必要があります。一方、ロジックアナライザは最大8chでプロトコル解析して値が表示されるため、解析をより早くできます。Windowsの他、Mac、Linuxにも対応しているため、ロジックアナライザの入門としてnanoDLAはお勧めです。

QSPI通信を用いたSRAM読み書き

STM32マイコンのペリフェラル機能の1つ、QSPIがあります。今回はQSPIでNOR Flashではなく、SRAM(IS62WVS5128FB)を読み書きする方法を紹介します。データ削除等が必要なNOR FlashよりもSRAMは処理がシンプルで、読み書きのみです。

SPIは4つの信号線 (CS:Cable Select、SCK:Serial Clock、MISO:Master In Slave Out、MOSI:Master Out Slave In) で構成されています。一方、QSPIは6つの信号線(CS、SIO0、SIO1、SIO2、SIO3、SCK)で構成されています。SPIはMISO、MOSIの2本の通信バスに対して、QSPIはSIO0、SIO1、SIO2、SIO3の4本の通信バスに拡張されています。そのため、1クロックで送受信できるデータが2倍となり、より高速に通信できるようになっています。QSPIは主にNOR Flash、SRAM等のメモリ向けのインタフェースとして多く採用されています。

QSPI通信はSPI通信と互換があり、多くのQSPI対応デバイスは起動直後はSPIデバイスとして動作します。初期化や設定が完了してからQSPIモードに切り替えて高速に通信します。また、SPIのMISO、MOSIの2本のバスは通信方向が固定されていますが、QSPIは通信状態に応じて通信方向が変化します。通信状態をやり取りするためにSPIと異なり、インストラクションを送ってからアドレスやデータのやり取りを行います。多くの場合はインストラクション＋アドレス＋データの3つで構成されています。

STM32マイコンのHALライブラリでは、HAL_QSPI_Commandでインストラクション＋アドレス+データ設定を行い、送信の場合のデータはHAL_QSPI_Transmitで送信し、受信の場合はHAL_QSPI_Receiveで受信します。

具体的にデータをメモリから読み込む場合は下記のような流れで設定します。

QSPI_CommandTypeDef sCommand;
HAL_StatusTypeDef res=0;
sCommand.InstructionMode = QSPI_INSTRUCTION_1_LINE;//インストラクションのバス数 1~4
sCommand.Instruction = READ_CMD;//インストラクション
sCommand.AddressMode = QSPI_ADDRESS_1_LINE;//アドレスのバス数 1~4
sCommand.Address = address;//アドレス
sCommand.AddressSize = QSPI_ADDRESS_24_BITS;//アドレス長
sCommand.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;//オルタネイトバイト(拡張用、通常は未使用)
sCommand.DataMode = QSPI_DATA_1_LINE;//データのバス数 1~4
sCommand.DummyCycles = 0;//アドレスを設定してからデータの送受信までに待機が必要な場合に設定
sCommand.DdrMode = QSPI_DDR_MODE_DISABLE;//DDRモード設定
sCommand.DdrHoldHalfCycle = QSPI_DDR_HHC_ANALOG_DELAY;//DDRモード時遅延設定
sCommand.SIOOMode = QSPI_SIOO_INST_EVERY_CMD;//コマンドモード
sCommand.NbData = read_length;//データ長さ

res+=HAL_QSPI_Command(&QSPIHandle, &sCommand, 0xFFF);//インストラクション＋アドレス+データ設定
res+=HAL_QSPI_Receive(&QSPIHandle, read_data, 0xFFF);//受信処理

上記の例では一般的なインダイレクトモードの例を紹介しました。STM32マイコンのQSPIではインダイレクトモード、ステータスポーリングモード、メモリマップモードの3種類あります。

インダイレクトモード：インストラクション＋アドレス+データで送受信する一般的処理モードです。

ステータスポーリングモード：メモリのフォーマット等、時間を要する処理の場合に処理の完了有無を定期的に自動で確認することができます。

メモリマップモード：アドレスで直接、データを読み込み可能なモードです。ポイントは読み込み専用で書き込み不可。フォントや画像といった固定のデータを読み出す場合に向いています。

SRAM(IS62WVS5128FB)はDDRモードに対応していませんが、DDRモードに対応しているメモリの場合、クロックの立上がりと立下りの両方でデータのやり取りができるため、さらに倍のデータをやり取りできます。今回は読み込みのみ紹介しましたが、SRAM(IS62WVS5128FB)とQSPIで読み書きする全体コードはこちらにアップしました。

最近のSTM32L5等ではQSPIの代わりにOctalSPIが搭載されています。OctalSPIはバスが8本となりさらに高速に通信することが可能です。残念ながらQSPIのメモリマップモードは読み込み専用ですが、OctalSPIのメモリマップモードはFMCやFSMCのメモリマップモード同様に読み書き可能です。OctalSPIも今後紹介したいと思います。

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からのインポート時のエラーに対処できます。他のエラーに遭遇した場合にはまた追記していきたいと思います。