ST製気圧センサLPS25HB注意点

ST製気圧センサLPS25HBを使っていて、うまく気圧データを取得できないという問題に遭遇したため、その対処方法について紹介したいと思います。今回は秋月電子で販売されているLPS25HBの変換基板を使用しました。

現象としては一般的なI2Cデバイス同様にアドレス、レジスタを指定して、データをまとめて読み出すという流れでLPS25HBから気圧データを3byte分読み出すと同じ値のデータが3つ読み出され、意図した値が読み出せてないということが分かりました。データシートをよく見るとLPS25HBは一般的なI2Cデバイスと異なり、まとめてデータを読み出す際の自動アドレスインクリメントがデフォルトで無効化されているということが分かりました(データシートP.25)。自動アドレスインクリメントを有効化する場合はレジスタの最上位ビットに1をセットして読み出すと記載があります。自動アドレスインクリメントとは、2バイト以上のデータを読み出す際に先頭のレジスタのみ指定すると自動的にレジスタをインクリメントして一括で2バイト以上のデータを読み出せる機能です。

つまり、LPS25HBで気圧データ等を取得する場合、個々のレジスタを指定して1つずつ読み出すか、レジスタの最上位ビットに1をセットして読み出す必要があります。

例えば気圧データの場合、レジスタはPRESS_OUT_XL　0x28、PRESS_OUT_L　0x29、PRESS_OUT_H 0x2Aとなり、0x28を指定して3回読み出しするのでなく、レジスタの最上位ビットに1をセットした0xA8を指定して3回読み出しする必要があります。同様に温度の場合は0x2Bでなく、0xABを指定する必要があります。

他のST製気圧センサをざっと調べてみたところ、自動アドレスインクリメントがデフォルトで無効化されているのはLPS25HBのみということが分かりました。

製品名	アドレスインクリメント有無
ILPS22QS	〇
LPS22CH	〇
LPS22DF	〇
LPS22HB	〇
LPS22HH	〇
LPS25HB	×
LPS27HHTW	〇
LPS27HHW	〇
LPS28DFW	〇
LPS33K	〇

LPS25HBを使用する際は自動アドレスインクリメントがデフォルトで無効化されていることに注意してください。一般的な多くのI2Cデバイスはアドレスの自動インクリメントが有効化されていますが、ごく稀に自動アドレスインクリメントがデフォルトで無効化されているデバイスがあります。LPS25HBに限らず、I2Cデバイスの読み出しで同じ値が読み出されるという場合は自動アドレスインクリメントの設定がどうなっているか確認した方が良いと思いました。

USBカメラ変換基板

　今回は昨年から試行錯誤しながら取り組んでいるプロジェクト(USBカメラ変換基板プロジェクト)について紹介します。組込系でカメラ機能を利用する場合、昨今ではOpenMVやM5Camera、ESP32-Cam等を利用することが多いと思います。マイコンとカメラを接続する場合、一般的に下記の接続方法があります。

接続方法	メリット	デメリット	製品例
SPI	伝送が高速 ローエンドマイコン対応	機種によってコマンド互換なし 低解像度	Arducam等
UART	省配線 コマンド互換少し有 ローエンドマイコン対応	伝送が低速 低解像度	シリアルカメラ等
NTSC+SPI	伝送が高速 汎用NTSCカメラ対応	NTSCカメラ自体の入手性 バッファメモリ必須 解像度固定	TVP5150等でSPI変換
パラレル	伝送が高速 高解像度	配線が多い ハイエンドマイコンのみ対応	カメラモジュール等
MIPI	伝送が超高速 高解像度	専用IF必須 ハイエンドマイコンのみ対応	RaspberryPIカメラ等
HDMI	伝送が超高速 高解像度	変換IC必須 ハイエンドマイコンのみ対応	TFP401等で変換
カメラユニット	低コスト 筐体ケース付きがある	別途ファーム書き込み必要	OpenMV M5Camera ESP32-Cam HuskyLens
USBカメラ	USB汎用接続 ケーブル延長容易 入手性が良い	UVCホストの実装が複雑 USB1.1では動作しないカメラ有 解像度の制約が多い	Logicool C270、C920等

　SPI接続やUART接続の場合、予めバッファがカメラ側に内蔵されていることが多いため、マイコン側に大容量メモリがなくても最低限の処理が可能です。一方、パラレル接続やMIPI接続の場合はイメージセンサからほぼそのまま出力されるため、それに対応した高速なインタフェースと読み出しデータを保持するための大容量メモリが必須となります。ユニットとして販売されているものは公開されているファームを書き込むだけで簡単に動作確認や実装できるために便利ですが、生産終了やロットによる機能差等が生じる場合が多々あります。多くのカメラモジュールで使用されるイメージセンサは主にスマートフォン向けのため、カメラモジュールの生産終了や型式変更等が頻繁で継続した安定入手に難があります。

　上記の方法の中でUSBカメラやNTSCカメラを使用する場合、汎用的なIFで継続して安定入手が可能です。ただ、そのままでは容易に使うことが難しいのが課題です。そのため、単体や小規模のマイコンでも簡単に処理できるUSBカメラ変換基板を開発することにしました。

コンセプトは下記の通りです。

・汎用的なUSBカメラから画像取得(jpeg、bmp対応)

・単体でSDカード等に画像ファイルを保存

・簡易的なタイムラプス撮影ができる

・UARTやSPIを介した低解像度の画像取得

実際に開発したUSBカメラ変換基板です。

もともとはSTM32マイコンで実装予定でしたが、HALライブラリではIsochronous転送に失敗してうまく転送できない、昨今の半導体不足で入手困難であるため、断念。FTDIのVinculumではRTOSのオーバーヘッドが無視できず、SPIの転送速度が遅すぎて断念しました。最終的にPIC32MZマイコンを用いて実装しました。PIC32MZはUSB2.0 High Speedに対応しているため、多くのUSBカメラに対応できます。

SPIを介してLCDを接続してBMPデータを描画させてみました。

カメラや設定によって異なりますが、1秒間に10フレーム弱程度で比較的スムーズにLCDに表示させることができました。

また、10秒間隔でのタイムラプス撮影をして後からコマ送りで動画に編集してみました。今後はサンプルコードや利便性の向上、対応カメラの追加、機能追加等を検討したいと思います。随時こちらに更新情報を追加したいと思います。

MachXO3LF/L Starter Kit UART設定

MachXO3LF/L Starter KitはLattite社のFPGA、MachXO3シリーズの評価ボードです。FTDIのUSBシリアル変換ICが搭載されているため、Diamond Programmer等から書き込み治具なしでそのまま書き込んで動作確認できます。

特にMachXOシリーズは外部FlashなしでFPGA単体で動作可能なため、小規模な開発に便利です。MachXO3LFとMachXO3Lで2種類ありますが、何度も書き換えて使用する可能性がある場合はFlashベースのMachXO3LFとなります。MachXO3LF/L Starter KitはFTDIの2232Hを搭載しています。2232Hは1つのICにシリアル機能をデバイスAとデバイスBで2つ搭載しています。デバイスAはJTAG書き込み用(245FIFOモード)、デバイスBはUARTやI2C等のユーザ用途に設定可能になっています。一方でデフォルトではデバイスBが初期設定(245FIFOモード)となっており、UART等の用途で使用できません。今回はMachXO3LF/L Starter KitでFTDIのUARTを使用する設定について紹介します。

�@ハードウェア設定

MachXO3LF/L Starter KitのデフォルトではFTDIのデバイスBとMachXO3が接続されていません。FTDIチップ横のR14(FTDI:TX-FPGA:RX)、R15(FTDI:RX-FPGA:TX)に抵抗(0~100Ω程度)を取り付ける必要があります。写真ではハンダでジャンパさせました。

�AFTDI EEPROM設定

デバイスBが初期設定(245FIFOモード)となっており、UARTモードに切り替える必要があります。FTDIチップの横にEEPROMが接続されており、そこにFTDIチップの挙動を決定するパラメータが書き込まれています。パラメータを書き換えることでデバイスBをUARTとして動作させます。ここで注意点としてEEPROMのパラメータの書き換えに失敗した場合、Diamond Programmer等からJTAG治具として検出できなくなる可能性があるため、注意してください。

こちらのリンクからEEPROMのパラメータ書き換えのソフトウェアFT_Progをダウンロードします。ソフトウェアを起動し、F5キーを押して、ワーニングメッセージが表示されてOKを押すと、現在の情報が表示されます。

他にもFTDIデバイスが接続されている場合、誤って他のデバイスに書き込んでしまう可能性があるため、MachXO3LF/L Starter Kit以外のデバイスを外して、ツリー表示のデバイスが1つであることを確認してください。

Hardware Specificをクリックし、PortBのHardware設定をRS232 UARTに設定します。PortAはJTAG用の設定となっているため、間違えてPortAの設定を変更しないように注意します。

同様にDriverの項目をVirtual COM Portを選択します。

上記の設定で書き込みボタンを押します。USBを抜き差しするとCOMポートとして認識できるようになります。

なお、デバイスマネージャーから「表示をコンテナ別」に設定して、そこからVCP(Virtual COM Port)に設定変更できるチェックボックスがありましたが、こちらの設定だけではCOMポートが追加されるものの、UARTとして動作しませんでした。やはり、FT_Progを用いてパラメータの書き換えが必要なようです。

上記の手順後、C11にTX、A11にRXとしてユーザプログラムを書き込むことでMachXO3LF/L Starter Kit単体でPCとUART通信できるようになりました。R14、R15がデフォルトで未実装に気づかず、デバッグに時間を要してしまいました。Starter KitのPDF等にもUART通信を使用する手順について説明の記載がなく、ちょっと不親切だと思いましたが、なんとかPCとUART通信できるようになりました。

音方位センサ

　ー昨年から断続的に開発してきた音方位センサがやっと形になってきたため、紹介したいと思います。音方位センサは直径4cmの円形基板に4つのMEMSマイクを搭載したセンサで音源の方位を音の時間差から計算してLED及びI2C、UARTで結果を出力する基板です。主な用途として小型の首振りロボットの頭に搭載することで声で頭の向きを変えたり、声でカメラの向きを変更して撮影するといった用途を想定しています。

　基板自体の開発は20年12月に完了していたものの、ファームウェアのアルゴリズムが安定せず、リリースできずにいました。断続的にアルゴリズムの検討、処理の見直しを実施し、最終的にGCC-PHAT(Generalized Cross-Correlation. PHAse Transform)方式である程度、安定して方向検知できるようになりました。GCC-PHATの原理の詳細については多くの論文や資料があるため、こちらでは述べませんが、音の方位を検出する原理として、少し離れたマイクから同時に音をサンプリングすることで、マイク同士の距離の差によって音が到達する時間差から方位を検出します。180度片側の場合、2つのマイクで角度を検出できますが、前方か後方か分かりません。平面の場合、3つ以上あれば360度の方位を検出できます。本センサは1つ冗長ですが、マイクを4つ搭載しています。

　まず、ハードウェアの構成として、どのような種類のマイクを使用するかという問題があります。基板の実装密度を高め、より高感度、音の感度が周波数によらずフラットなMEMSマイクを採用しました。MEMSマイクの中でもアナログマイクとデジタルマイク(PDM)のどちらにするかについては、アナログの場合、外付けでアンプが必須で環境によって増幅率が変更な必要な場合があります。デジタルの場合は外付けのアンプが不要な代わりにソフトウェアで処理が必須となります。部品数を減らし、環境にロバストなデジタルMEMSマイクを選定しました。

　微小な音の遅延を測定するため、4つのデジタルMEMSマイクを同時にサンプリングする必要があります。STM32L4シリーズ等ではPDMデジタルMEMSマイクを容易に処理可能なDFSDMを搭載していますが、多くのマイコンはそのような機能を搭載していません。汎用性等を考慮し、今回はSPIを用いて実装しました。4つのMEMSマイクをSPIで同時サンプリングする場合、SPIのクロックを4つで共通にして、SPIの1つをマスタ、残りの3つをSPIスレーブとして実装し、DMA転送することで4つのMEMSマイクの同時サンプリングを実現しています。RAMが十分あり、SPIを5つ搭載しているSTM32F411を選定しました。

　実際にスマートフォンから水の音を出して方向検知するデモ動画を紹介します。

　GCC-PHATアルゴリズム単体に加えて、誤検知をより防止するため、周波数帯を数kHz前後にフィルタし、音の変化が大きい場合(音のアナログ値の標準偏差)にのみ角度出力することで比較的安定して方向検知できるようになりました。一方で手を叩く音やモノを叩く音のような瞬間的な音の場合、音の反射等の影響が大きくなり、誤検知が多くなります。UARTやI2C通信周りの実装を今後行い、コード、回路図含めて公開後、提供開始したいと思います。

PIC32MXとPIC32MZのUSB HOST

今回はPIC32MXとPIC32MZでUSB HOST機能の両者の仕様差について紹介します。PIC32MXで動いていたコードがPIC32MZで若干、仕様が異なるためにそのままでは動きませんでした。若干の仕様差について注意すべき点を紹介します。

■PIC32MZはUSB2.0 High Speed対応(480MHz)

　組込系のマイコンの多くはUSB 2.0 Host対応を謳っていても8割、9割はFull Speed対応(12MHz)です。PIC32MXもFull Speed対応(12MHz)です。一部のマイコン、例えばSTM32F7ではFull SpeedとHigh Speedに対応していますが、High Speedの場合、High Speedの信号を処理するためのUSB PHYを内蔵していません(一部内蔵したモデルもあるようです)。そのため、USB3300といったUSB PHYのICを外付けすることが必要です。High Speedの480MHz信号をそのままでは処理しきれないため、USB PHYでパラレル信号に変換してクロックを落としてマイコンに接続することが一般的です。

　一方、PIC32MZは驚くことにHigh Speed対応USB PHYをマイコンに内蔵しています。つまり、High Speedの480MHz信号をマイコンからUSBコネクタに直結可能です。ただし、480MHzの信号を扱うことになるため、基板の配線には特に注意が必要です。480MHzとなると普通のSPIやI2Cのような適当な信号配線では全く動きません。目安としてマイコンとUSBコネクタまでの配線長は最大75mm程度、30mm以下が理想でD＋とD-の配線差は最大2.5mm、直角でなく、45度に曲げるといったUSB2.0に準拠するため、細心の注意を払って配線する必要があります。kicadの等長配線、差動ペアの配線方法は以前に紹介した通りです。Full Speedと同じような感覚でいつものように適当に配線してしまい、まったくUSBを認識できませんでした。仕方なくパターンを切って外付けで差動ペアを配線したところ、正常に認識することができました。

即席で作った基板では当然ながらHigh Speedの480MHzに耐えられず、写真のように配線パターンを切ってからポリウレタン銅線のツイストペアケーブルでジャンパさせると正常に通信できました。

■PIC32MZはVBUS電圧レベルを厳密に監視

　PIC32MXのVBUSピンはONかOFFかを見ているだけだったため、適当に3.3Vを入れておけばUSB機能を利用することができました。一方、PIC32MZのVBUSピンは内部にコンパレータを内蔵しており、厳密にVBUS電圧レベルを監視しています。PIC32MXと同じ感覚で3.3Vを入れたところ、DRV_USBHS_Tasks内のDRV_USBHS_TASK_STATE_RUNNINGの途中で停止してしまいました。PLIB_USBHS_VBUSLevelGetで電圧レベルを取得しており、VBUSに5Vを入れると正常に状態遷移することができました。VBUSピンはPIC32MX、PIC32MZ含めて最大5.5Vまで印加可能なため、正しくはUSB電源に接続すべきピンです。マイコンのピンを外部電源系にそのまま接続するのは過電圧保護やESD対策等を考えると気が引けるため、3.3Vを接続していました。PIC32MZではそれが通用しないことが分かりました。

ポリウレタン銅線でVBUSピンの電源を3.3Vから5Vにジャンパさせると正常に状態遷移することが確認できた。

■その他

　High Speedの場合、Full Speedに比べてよりデバイスの消費電力が上がる傾向があります。電源配線幅、場合によってはコンデンサ等で安定したUSB電源をデバイスに供給できるように注意が必要です。USBデバイスを認識するものの、その後、デバイスの処理を開始するとUSBデバイスがリセットする現象に遭遇しました。オシロで確認するとデバイス処理開始直後に急激な電圧低下が生じていることが分かり、1つ目の写真にもある通り、電解コンデンサで電源を補強するとUSBデバイスがリセットされずに安定してデバイスの処理をすることが確認できました。

　PIC32MZは他のPIC32マイコンと比べると割高な印象がありますが、USB PHY内蔵と考えると、外付けよりもBOMコストを抑えて省配線でHigh Speedに対応できるため、むしろ他のマイコンよりも安いと言えます。今後、USBの他にPIC32MZのEthernet機能等も実験して紹介したいと思います。なお、Ethernet機能についてはPIC32MZでも残念ながら外付けでEthernet PHYのICが必須です。