STM32F4-DISCOVERYを使用してアナログビデオをキャプチャする

この記事では、STM32F4-DISCOVERYボードを使用してアナログ白黒ビデオ信号をキャプチャする方法と、USBを使用してコンピューターに転送する機能について説明します。

USB経由でコンピューターに画像を転送する

STM32F4-DISCOVERYボードを使用すると、さまざまなUSBデバイスを作成できます-使用されているマイクロコントローラーのUSB周辺モジュールには優れた機能があります。 しかし、ネットワーク上で使用する珍しいデザインの例はほとんどありません-ほとんどの場合、USBを使用してHID（キーボード、マウス、ジョイスティックのエミュレーション）およびCDC（COMポートエミュレーション）クラスを実装します。 通常、内蔵USBホストは、USBフラッシュドライブの接続に使用されます。



ウェブカメラなどの珍しいUSBデバイスを作りたかった。 それを2つの方法で実装できます-独自のクラスのUSBデバイスとそのドライバーを作成するか、はるかに簡単なUSBビデオデバイス用の標準USBクラスUSBビデオデバイスクラスを使用します。 そのようなデバイスのドライバーは、Windows XPに統合されています。 基本的なUVCの説明は、 このドキュメントにあります（新しい1.1がありますが、UVCバージョン1.0を使用しました）。

インターネット上のマイクロコントローラーにUVCを実装する例はほとんどありません。 デバイス記述子の正しいコンパイルは非常に複雑です（記述子はすべての機能を記述します）。 記述子にわずかなエラーがあっても、デバイスが検出されたように見えるという事実、またはBSODにさえつながる可能性があります。 既存のウェブカメラから記述子をコピーできますが、それらは不必要に複雑になる可能性があります-カメラには多くの場合マイクが含まれており、単一の画像をキャプチャできます（UVCの用語では静止画像キャプチャ）。また、多数のカメラ設定を変更できます。 これらすべてが混同しやすいので、プロジェクトをできるだけシンプルにしたかったのです。

長い検索の後、私は偶然そのような中国のプロジェクトにつまずいた。 これはSTM32F103のテトリスであり、コンピューターを使用して、コントローラーをUVCデバイスと見なす画像を表示します。 このプロジェクトはMJPEGエンコードも実装しています。 このプロジェクトは非常に興味深いものですが、そこにあるコードは非常に紛らわしく、コメントはほとんどありません。 それから記述子を取り出し、要件に合わせて少し調整しました。



記述子をコンパイルするときは、とりわけ、送信されたイメージのパラメーターを指定する必要があります。 320x240ピクセルの画像サイズとNV12画像フォーマットに決めました。 UVC標準では、NV12とYUY2の2つの形式の非圧縮画像のみを配信できます。

2番目の形式はより一般的ですが、NV12は白黒画像のエンコードにより適しており、占有スペースが少なくなります。 この形式では、データはYUV 4：2：0タイプに従ってエンコードされます（4バイトの色情報は4ピクセルに該当します）。 最初に画像全体の明るさに関する情報（私の場合は320 * 240バイト）、次に色に関する情報（バイトUとVが交互に移動します）があります。







合計で、イメージは（320 * 240 * 3/2）バイトを占有します。 この形式には欠点があります-すべてのプログラムがこの形式で動作できるわけではありません。 この形式のフリーウェアContaCamでの動作が保証されており、Skypeも正常に機能しました。

テスト画像をコントローラーにアップロードするために、エンコードされた画像データを含む.hファイルを生成する特別なコンバーターが作成されました。 NV12に加えて、コンバーターはYUY2形式で画像をエンコードできます。

非圧縮イメージの場合に記述子を適切に構成し、データを送信する方法の詳細な説明は、別の文書「 ビデオデバイスのユニバーサルシリアルバスデバイスクラス定義：非圧縮ペイロード 」に記載されています。



基本的なプロジェクトとして、 USBマイクプロジェクトを取り上げました。 また、アイソクロナスエンドポイントを介したコンピューターへのデータ転送も実装しました。 USBでの作業は、コントローラー製造元のライブラリ（STSW-STM32046）を使用して実装されます。 記述子、VID / PID（私が理解するように、任意のものをインストールできます）を置き換えた後、コントローラーは画像処理デバイスとして検出されました。 次の段階は、ビデオ情報ストリームのコンピューターへの転送です（スターターの場合、コントローラーのメモリに保存されたテスト画像）。



事前に、処理する必要があるさまざまなUSB要求（要求）に言及する価値があります。 コントローラーがコンピューター（ホスト）から特定の種類の要求に対する要求を受信すると、USBライブラリはusbd_video_Setup関数を呼び出し、要求を処理する必要があります。

この機能のほとんどは、マイクコードから取得されます。これは、標準デバイスリクエストの処理です。 ここでは、SET_INTERFACE要求を受信したときに発生する代替インターフェイス間の切り替えに注意を払うことができます。 UVCデバイスは、少なくとも2つの代替インターフェースを提供する必要があります。そのうちの1つ（ゼロ帯域幅、0未満の数値）は、コンピューターが不要なときにUSBデバイスを切り替え、バス上のデータフローを制限します。 コンピューター上のプログラムがデバイスからデータを受信する準備ができると、デバイスにリクエストを送信して別の代替インターフェイスに切り替えます。その後、デバイスはホストからのINトークンパケットの受信を開始し、ホストがデータの送信を待機していることを通知します。

別のタイプの要求があります-このクラスに固有のクラスデバイス要求-UVC。 それらは、カメラからステータスに関するデータを取得し、その動作を制御するために使用されます。 しかし、最も単純な実装でも、カメラのパラメーターを変更できない場合、プログラムはリクエストを処理する必要があります：GET_CUR、GET_DEF、GET_MIN、GET_MAX、SET_CUR。 それらはすべて、コンピューターからカメラの電源を入れる前に送信されます。 UVC仕様に従って、コンピューターはカメラに動作可能なモードを要求し、カメラが動作するモードの指示を送信します。 そして、そのようなリクエストには、プローブとコミットの2種類があります。 私の場合、このデータは一切使用されませんが、リクエストが処理されない場合（送信されたデータを取得しない、または応答しない）、コンピューター上のプログラムは「フリーズ」し、コントローラーを再起動する必要があります。



プロジェクトを作成する過程で、USBライブラリがホストへのデータ転送要求を誤って処理することがあることがわかりました-少量のデータを転送した後、データ転送が停止し、コンピューターを再起動することによってのみ再起動できます。 これは、ビデオ情報（1エンドポイントを介して）と制御情報（0エンドポイントを介して）の伝送に適用されます。 これは、書き込みを開始する前に、目的のエンドポイントのFIFOを事前にクリアすることで修正されます。



すべての必要な要求が転送され、コンピューターが代替インターフェイスをメインモードに切り替える要求を送信した後、ビデオデータの送信を開始できます。 コンピューターは、ミリ秒ごとにINトークンパケットバスに発行を開始します。これを受信すると、コントローラーはusbd_video_DataIn関数を呼び出し、そこからライブラリデータ転送関数DCD_EP_Txを呼び出す必要があります。

ビデオデータはパケットで送信されます。各パケットの先頭には、2バイトの長さのヘッダーが必要です（UVC仕様では、追加情報を含む長いヘッダーの使用がサポートされています）。 ヘッダーの最初のバイトは常に2です-これはヘッダーの全長です。 2番目のバイトにより、ホストはフレームの開始とその変更を検出できます。このバイトの最初のビットは、新しいフレームの最初のパケットで交換する必要があります。 このフレームの後続のパケットでは、このビットの値は同じままです。 残りのビットはゼロのままにしておくことができます。 パッケージの残りはビデオデータです。 パッケージ内の長さは任意です（ただし、特定のサイズを超えないようにしてください）。

パケット内のビデオデータの長さを特別に選択して、バイト単位の画像のサイズを余りなく分割しました。つまり、すべてのパケットは同じ長さです。



これが結果です：







パフォーマンスはどうですか？

このコントローラーは、USBフルスピード標準をサポートしています。これにより、理論上の速度は12 Mbpsになります。 したがって、信頼できる最大値は、フレーム送信時間が（320 * 240 * 3/2）/（12 * 10 ^ 6/8）= 76 msであり、13 FPSになります。 ただし、USBは半二重プロトコルであり、マイクロコントローラーには制限があります。 コントローラは、FIFOを使用してUSB経由でデータを送信します。さらに、このコントローラには1250バイトのメモリがあり、すべてのコントロールポイント間で分割する必要があります。 メモリ割り当ては「usb_conf.h」ファイルに示され、サイズは32ビットワードで示されます。

#define RX_FIFO_FS_SIZE 64 #define TX0_FIFO_FS_SIZE 16 #define TX1_FIFO_FS_SIZE 232 #define TX2_FIFO_FS_SIZE 0 #define TX3_FIFO_FS_SIZE 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

FIFOコマンドをコンピューターから受信するには、少なくとも64ワードを割り当てる必要があります; FIFOの場合、0エンドポイントを介したコンピューターへの制御情報の転送には、さらに16ワードが必要です。 他のすべては、ビデオ伝送の最初のエンドポイントに割り当てることができます。 合計は（64 + 16 + 232）* 4 = 1248バイトです。 232ワード（928バイト）の制限があるため、パケットサイズ（VIDEO_PACKET_SIZE）は（768 + 2）バイトに設定されました。 したがって、1フレームは、（320 * 240 * 3/2）/（768）= 150パケットで構成され、150 * 1msで送信され、6.6 FPSになります。

実際の結果は、計算されたものと一致します。







それほど多くはありませんが、同じサイズの非圧縮画像を転送する場合、それ以上は取得できません。 そのため、マイクロコントローラーで画像を圧縮することにしました。

MJPEGへの移行

UVC標準は、さまざまなタイプの圧縮をサポートしています。そのうちの1つがMJPEGです。 このタイプの圧縮では、各ソース画像フレームはJPEG標準に従って圧縮されます。 結果の圧縮フレームは、上記のようにコンピューターに送信できます。 MJPEGの記述子とデータ転送機能については、「 ビデオデバイスのユニバーサルシリアルバスデバイスクラス定義：Motion-JPEGペイロード 」のドキュメントで説明しています。



コンピューターで準備された静的イメージの転送は非常に簡単であることが判明しました。以前のように、通常のJPEGファイルを.hファイルに変換し、プロジェクトに追加して、バッチで転送します。 圧縮イメージのサイズは任意であるため、最後のデータパケットの長さも可変であるため、計算する必要があります。

30000バイトの圧縮イメージサイズでは、（30000/768）=> 40パケットで構成され、40パケットが送信されます。これは25 FPSに相当します。

JPEGでの圧縮には、 ここで取得したエンコーダーを使用することにしました 。 これはARMに適合しており、白黒画像用にのみ設計されており、私に適しています。そのため、白黒カメラからデータを取得します。

このエンコーダーはSTM32F4ですぐに動作を開始しましたが、Cortrx-M4には適応しませんでした。 テストbmpファイルは25ミリ秒で圧縮され、これは40 FPSに相当します。 コントローラーから圧縮イメージを読み取るために、STM32 ST-LINK Utilityプログラムを使用しました。 まず、プログラムのデバッグ中に、圧縮イメージが配置される配列の開始アドレスを見つけてから、このプログラムで指定する必要があります。 読み取りダンプは、すぐに.jpgとして保存できます。

次に、ダブルバッファリングのためにエンコーダに2つの出力配列を操作する機能を追加し、USBデータ出力プロジェクトと組み合わせました。



ただし、結果のデザインはContaCamプログラムとブラウザーでのみ機能しました（ こちらで確認してください ）。 静止画像では、35 FPSを取得できました。

圧縮画像の例（画像サイズ17 Kバイト）：







bmpファイルの情報はそのように保存されるため、イメージは上下逆になっています。



しかし、他のプログラムはまったく機能しないか、そのようなイメージを与えました。







これは、UVC標準がMJPEGを使用した白黒画像の転送をサポートしていないという事実によるものです。

JPEG画像の要件は次のとおりです。

•カラーエンコーディング-YCbCr

•ピクセルあたりのビット数-カラーコンポーネントごとに8つ（フィルタリング/サブサンプリング前）

•サブサンプリング-422

したがって、既存のエンコーダを再作成して擬似カラー画像を形成する必要がありました。実際、このような画像では輝度データ（Y）のみがエンコードされ、カラーデータ（CbおよびCr）の代わりにゼロが送信されます。 JPEG形式の構造をより深く知る必要がありました。

白黒から擬似カラーへの移行

以前のエンコーダーの仕組み：

1. JPEGファイルのヘッダーが形成されます。

2.元の画像のブロック（8x8ピクセル）処理。

2.1各ブロックはメモリから読み取られ、その離散コサイン変換（DCT）

2.2結果の64個の値は量子化され、結果はハフマンコードを使用してパックされます。

3.データ終了マーカーが生成され、圧縮画像のサイズが計算されます。

JPEGの詳細については、 こちらとこちらをご覧ください 。

圧縮された画像の色情報はJPEGヘッダーに保存されるため、変更する必要があります。 色11の輝度成分間引き22で、SOF0およびSOSセクションを変更し、それらの3つの成分の使用を示す必要があります。どこでも、量子化テーブルの識別子として0を指定しました。

これで、情報のコーディング方法を変更できます。 色情報は間引きされるため、4つの色情報ブロックは2つの色情報ブロックに対応する必要があります。 したがって、輝度情報の4つのブロックが最初に順番にコーディングされます。その後、さらに2つの色情報のブロックをエンコードする必要があります（上記の記事の例）。







使用されるライブラリでは、量子化、処理されたデータの最終圧縮、およびメモリへの書き込みは別の関数によって実行されるため、色情報の形成には、DCT係数の配列を無効にしてこの関数を2回呼び出すだけで十分です。

ただし、JPEGコーディングには重要な機能があります。エンコードされるのは各ブロックの先頭のDC係数ではなく、現在のDC係数と対応するコンポーネントの前のブロックのDC係数の差です 。 ライブラリでは、この差異は量子化の前に最初に計算されたため、CrおよびCbチャネルの処理中に差異が計算されないように上記の関数を変更する必要がありました-これらのコンポーネントではゼロが続きます。

その結果、使用されているすべてのビデオキャプチャプログラムで画像が正しく表示されるようになりました。 この疑似カラーコーディングの欠点は、速度が多少低下することです。 テストイメージの圧縮には35ミリ秒かかり、28 FPSになりました。

アナログビデオキャプチャ

ビデオデータを許容可能な速度でコンピューターに転送する方法ができたので、ビデオ信号に取り組むこともできます。 USBを使用した実験の最初から、デバッグボード自体を使用してアナログビデオカメラからのビデオ信号のキャプチャを実装するつもりでした。

すでにマイクロコントローラで自家製のテレビを作ったので、白黒のビデオ信号をキャプチャする技術は私にとって新しいものではありませんでした。 もちろん、STM32F4コントローラーはATxmegaとは大きく異なるため、ビデオキャプチャへのアプローチを変更する必要がありました。



PAL形式自体はすでにさまざまなリソースで繰り返し説明されているので、主な規定に焦点を当てますが、これは白黒バージョンのみです。

この形式のフレーム周波数は25 Hzですが、インターレーススキャンが使用されます。つまり、フレームを送信するときに、偶数ラインと奇数ラインが最初に送信されます。 そのような行の各セットは、フィールドと呼ばれます。 この形式のフィールドには、50 Hz（20 ms）の周波数があります。 1つのフィールドでは、312.5行が送信されます（そのうち288.5行のみがビデオ情報を含みます）。 すべてのラインは、64μsの周期で続くクロックパルスによって分離されます。 ライン自体のビデオ信号は52μsかかります。

フィールドはフレームとイコライジングクロックパルスで区切られます。 クロックパルスをイコライズする重要な機能は、周期が行周期の2倍（32μs）であるため、クロックパルスと簡単に区別できることです。







したがって、コントローラーのメモリに画像をキャプチャするには、クロック信号を検出し、それらからイコライズパルスを抽出し、各ラインのビデオ送信を開始する前にADCの変換を開始できるプログラムを作成する必要があります。



次に、ビデオ信号をデジタル化する方法について詳しく説明します。

STM32F4コントローラーには3つの個別のADCがあり、それぞれが12ビットの分解能で2.4 MSPSの速度で動作できます。 ビット容量が減少すると速度は向上しますが、320 * 240の解像度を得るには十分ではありません。 ただし、コントローラーを使用すると、複数のADCを組み合わせることができます。すべてのADCによるキャプチャを同時に構成することも、ADC間のキャプチャ遅延を設定することもできます。その結果、全体的なキャプチャ速度が向上します。



2つのADCを同時に使用する場合のキャプチャ速度はどのくらいですか（インターリーブデュアルモード）？

ADCのクロッキングには、APB2バスが使用され、そのクロック周波数は、コントローラーが初期化されるときにシステム周波数の半分（168 MHz / 2）= 84 MHzに設定されます。 ADCの場合、これは多すぎるため、ADCをセットアップするときは、分周器を2に設定する必要があります。結果の42 MHzの周波数は、データシートで許容される最大値（36 MHz）よりも高いですが、この周波数でもADCはうまく機能します。

ビット深度が8ビットに設定された各ADCが個別に動作する場合、最大変換速度は（42 MHz /（3 + 8））= 3.81 MSPSになります。 6サイクルのデータキャプチャ時間の間に遅延を設定することにより、7 MSPSの速度と、7サイクル-6 MSPSを得ることができます。

最後のオプションを選択しました。 ライン全体（64μs）には384バイト、ビデオ信号のあるラインのアクティブ部分（52μs）には312バイト（ピクセル）が必要です。

ADCは、DMAを使用して変換結果をメモリに送信します。 2つの8ビットADCを使用する場合、2番目のADCの変換時にデータが16ビットワードの形式でメモリに転送されます。 原則として、フレーム全体の内容をメモリにキャプチャすることが可能です。これには、（384 * 240）= 92.16 KBが必要です。 しかし、私は別の方法を取りました。データキャプチャは、コントローラが同期パルスを検出した後に始まり、366バイト（183 DMA転送）をキャプチャした後に停止します。 なぜそのような数が選ばれるのか-私はさらに伝えます。 その結果、ビデオデータは（366 * 240）= 87.84 KBのRAMを占有します。



クロック信号を検出する方法を検討してください。 理想的には、特別なチップ、または少なくともコンパレータで検出する方が良いのですが、これは設計を複雑にします。 未使用のADCはまだ1つあるため、それを使用してクロック信号を検出することにしました。 各ADCには、特別なモジュール「アナログウォッチドッグ」が含まれています。 デジタル化された値が指定された制限を超えている場合、割り込みを生成できます。 ただし、このモジュールはデジタル化された信号のエッジの変化に応答することはできません。入力信号またはモジュール設定が変更されるまで割り込みを生成します。 信号の前線を検出する必要があるため、中断されるたびにこのモジュールを再構成する必要がありました。 アナログウォッチドッグのしきい値の自動検出をプログラムに実装しなかったため、使用中のカメラに対して手動で指定されます。



イコライジングパルスを検出するために、1 MHzの周波数で動作するコントローラータイマーの1つが使用されます。 タイマーは継続的に実行され、アナログウォッチドッグ割り込みハンドラー（クロックの立ち上がりエッジが検出されたとき）で、現在の値が読み取られ、前の値と比較されます。 したがって、水平同期パルスを等化パルスと区別することが可能です。 イコライジングクロックパルスが終了すると、コントローラーは17個の水平クロックパルスをスキップし、クロックパルスの立ち上がりエッジが検出されると、現在のラインのビデオデータのキャプチャを開始します。 このコントローラーの割り込みハンドラーへの入力は可変時間で発生する可能性があり、ADC 3が最初の2つよりも低速で実行されるため、クロックフロントとキャプチャ開始間の時間が異なる場合があり、震える「ライン。 これが、ビデオデータのキャプチャがクロックのリーディングエッジから始まり、ラインが366バイトかかる理由です。したがって、クロックの一部がフレームに落ち、ラインごとにプログラムで削除できます。

波形は、ビデオ信号がどのようにキャプチャされているかを示します（DMA動作中、「黄色」チャンネルは1に設定されます）。







キャプチャは、ビデオデータの出現後にのみ開始されます。







240行の制限が設定されているため、1つのフィールドのすべての行がキャプチャされるわけではありません。







結果は次の生画像です（ST-Linkユーティリティを使用して取得）：







コントローラのメモリに画像をキャプチャしたら、処理する必要があります。各ラインで、クロック信号のキャプチャに関連するオフセットを削除し、ピクセル輝度値から黒レベルを減算します。 このコードを最適化しようとしなかったので、完了するまでに5ミリ秒かかります。



画像が処理された後、JPEGでのエンコードを開始できます。同時に、USBを介して前の画像の既にエンコードされたデータの転送が開始されます。

したがって、フレームは20ミリ秒キャプチャされ、処理には5ミリ秒かかり、データ転送でのエンコードは35ミリ秒であり、合計60ミリ秒、つまり16.6 FPSのフレームレートになります。 その結果、1つのフレーム（実際にはフィールド）がキャプチャされ、2つのフレームがスキップされることがわかりました。 PALスキャンはインターレースであるため、偶数または奇数フィールドが交互にキャプチャされ、1ピクセルずつ画像にジッターが生じることがわかります。 これを取り除くには、フレームのキャプチャ間に追加の遅延を追加します。その後、別のフィールドがスキップされ、出力のフレームレートが（50/4）= 12.5 FPSに低下します。

ビデオソースについて少し

最初は、KPC-190Sビデオ監視カメラを信号源として使用する予定でした（このカメラはほぼ15年前です）。 これは、良好な画像品質を提供するということではありません-非常にノイズが多く、コントラストがあまり高くなく、振幅が小さい（オシログラムから1 Vに近いことがわかります）。 出力信号をわずかに調整するために、カメラは可変抵抗器の抵抗分割器を介してコントローラーに接続されます。 カメラが接続されているボードの唯一の信号出力はPC2です（すべてのADCが接続されています）。

デザインの外観：







このカメラは良好な画質を提供しなかったため、Canon A710カメラからの信号を取得することにしました。 テレビに接続するためのアナログ出力があり、カメラ画面に表示されるすべてのものが表示されます。 カメラの信号品質は優れていますが、ビデオ信号はカラーです。 信号から色成分を除去するために、このフィルターを使用しました：







さらに、カメラ出力のクロックパルスの極性は負であるため、コントローラーのADCで検出するには、調整可能な電源を使用して信号にバイアス電圧を追加する必要がありました。 また、アナログウォッチドッグの応答しきい値をわずかに変更する必要がありました。

カメラが接続されたデザインの外観：







カメラから受け取った画像の例：







ビデオデバイスの操作：







プロジェクトのソースコード： github.com/iliasam/STM32F4_UVC_Camera