私はオペレーティング システムの開発者の XNUMX 人です エンボックスこの記事では、STM32746G ボードで OpenCV を実行する方法について説明します。

検索エンジンに「STM32 ボードの OpenCV」などと入力すると、このライブラリを STM32 ボードや他のマイクロコントローラで使用することに興味がある人がかなり多く見つかります。
名前から判断すると、必要なものを説明するビデオがいくつかありますが、通常 (私が見たすべてのビデオで) STM32 ボードでは、カメラから画像のみを受信し、その結果が画面に表示されていました。画像処理自体は、通常のコンピューターまたはより強力なボード (Raspberry Pi など) で実行されました。

なぜ難しいのですか？

検索クエリの人気は、OpenCV が最も人気のあるコンピュータ ビジョン ライブラリであるという事実によって説明されます。つまり、より多くの開発者が OpenCV に精通しており、マイクロコントローラ上でデスクトップ対応のコードを実行できるため、開発プロセスが大幅に簡素化されます。 しかし、なぜこの問題を解決するための人気のある既製レシピがまだ存在しないのでしょうか?

小さなショールで OpenCV を使用する場合の問題は、次の XNUMX つの機能に関連しています。

• 最小限のモジュール セットでライブラリをコンパイルした場合でも、非常に大きなコード (数メガバイトの命令) が発生するため、(OS を考慮しなくても) 同じ STM32F7Discovery のフラッシュ メモリに収まりません。
• ライブラリ自体は C++ で書かれています。つまり、
  • ポジティブなランタイム（例外など）のサポートが必要
  • 組み込みシステム用の OS に通常見られる LibC/Posix はほとんどサポートされていません。標準 Plus ライブラリと標準 STL テンプレート ライブラリ (ベクトルなど) が必要です。

Embox への移植

いつものように、プログラムをオペレーティング システムに移植する前に、開発者が意図した形式でプログラムをビルドしてみることをお勧めします。 私たちの場合、これに問題はありません。ソース コードは次の場所にあります。 ギタベ、ライブラリは通常の cmake を使用して GNU/Linux でビルドされます。

幸いなことに、OpenCV はすぐに使用できる静的ライブラリとして構築できるため、移植が容易になります。 標準構成のライブラリを収集し、それらがどれだけのスペースを占めるかを確認します。 各モジュールは個別のライブラリに収集されます。

> size lib/*so --totals
   text    data     bss     dec     hex filename
1945822   15431     960 1962213  1df0e5 lib/libopencv_calib3d.so
17081885     170312   25640 17277837    107a38d lib/libopencv_core.so
10928229     137640   20192 11086061     a928ed lib/libopencv_dnn.so
 842311   25680    1968  869959   d4647 lib/libopencv_features2d.so
 423660    8552     184  432396   6990c lib/libopencv_flann.so
8034733   54872    1416 8091021  7b758d lib/libopencv_gapi.so
  90741    3452     304   94497   17121 lib/libopencv_highgui.so
6338414   53152     968 6392534  618ad6 lib/libopencv_imgcodecs.so
21323564     155912  652056 22131532    151b34c lib/libopencv_imgproc.so
 724323   12176     376  736875   b3e6b lib/libopencv_ml.so
 429036    6864     464  436364   6a88c lib/libopencv_objdetect.so
6866973   50176    1064 6918213  699045 lib/libopencv_photo.so
 698531   13640     160  712331   ade8b lib/libopencv_stitching.so
 466295    6688     168  473151   7383f lib/libopencv_video.so
 315858    6972   11576  334406   51a46 lib/libopencv_videoio.so
76510375     721519  717496 77949390    4a569ce (TOTALS)

最後の行からわかるように、.bss と .data はそれほどスペースを占有しませんが、コードは 70 MiB を超えています。 これを特定のアプリケーションに静的にリンクすると、コードが少なくなるのは明らかです。

最小限のサンプルがアセンブルされるように、できるだけ多くのモジュールを破棄してみましょう (たとえば、単純に OpenCV バージョンを出力します)。 cmake .. -LA そしてオプションでオフになるものをすべてオフにします。

        -DBUILD_opencv_java_bindings_generator=OFF 
        -DBUILD_opencv_stitching=OFF 
        -DWITH_PROTOBUF=OFF 
        -DWITH_PTHREADS_PF=OFF 
        -DWITH_QUIRC=OFF 
        -DWITH_TIFF=OFF 
        -DWITH_V4L=OFF 
        -DWITH_VTK=OFF 
        -DWITH_WEBP=OFF 
        <...>

> size lib/libopencv_core.a --totals
   text    data     bss     dec     hex filename
3317069   36425   17987 3371481  3371d9 (TOTALS)

一方では、これはライブラリの XNUMX つのモジュールにすぎませんが、他方では、これはコード サイズのコンパイラ最適化が行われていないものです (-Os）。 約 3 MiB のコードはまだかなりの量ですが、すでに成功の期待が持てます。

エミュレータで実行する

エミュレータでデバッグする方がはるかに簡単なので、まずライブラリが qemu で動作することを確認します。 エミュレートされたプラットフォームとして、Integrator / CP を選択しました。 第一に、これは ARM でもあり、第二に、EMbox はこのプラットフォームのグラフィック出力をサポートしています。

Embox には外部ライブラリを構築するためのメカニズムがあり、これを使用して OpenCV をモジュールとして追加し (静的ライブラリの形式で「最小限の」ビルドに同じオプションをすべて渡します)、その後、次のような単純なアプリケーションを追加します。

version.cpp:

#include <stdio.h>
#include <opencv2/core/utility.hpp>

int main() {
    printf("OpenCV: %s", cv::getBuildInformation().c_str());

    return 0;
}

システムを組み立てて実行すると、期待どおりの出力が得られます。

root@embox:/#opencv_version                                                     
OpenCV: 
General configuration for OpenCV 4.0.1 =====================================
  Version control:               bd6927bdf-dirty

  Platform:
    Timestamp:                   2019-06-21T10:02:18Z
    Host:                        Linux 5.1.7-arch1-1-ARCH x86_64
    Target:                      Generic arm-unknown-none
    CMake:                       3.14.5
    CMake generator:             Unix Makefiles
    CMake build tool:            /usr/bin/make
    Configuration:               Debug

  CPU/HW features:
    Baseline:
      requested:                 DETECT
      disabled:                  VFPV3 NEON

  C/C++:
    Built as dynamic libs?:      NO
< Дальше идут прочие параметры сборки -- с какими флагами компилировалось,
  какие модули OpenCV включены в сборку и т.п.>

次のステップは、いくつかの例、できれば開発者自身が提供する標準的な例の XNUMX つを実行することです。 あなたのサイトで。 私が選んだ 国境探知機キャニー.

結果をフレーム バッファに直接表示するために、この例を少し書き直す必要がありました。 そうする必要があったからです。 関数 imshow() QT、GTK、および Windows インターフェイスを通じてイメージを描画できますが、もちろん、これらは STM32 の構成には含まれません。 実際、QT は STM32F7Discovery 上でも実行できますが、これについては別の記事で説明します 🙂

エッジ検出の結果がどの形式で保存されるかを簡単に説明した後、画像を取得します。

原画

結果

STM32F7Discovery で実行

32F746GDISCOVERY には、何らかの方法で使用できるハードウェア メモリ セクションがいくつかあります。

1. 320KiB RAM
2. 画像用の 1MiB フラッシュ
3. 8MiB SDRAM
4. 16MiB QSPI NAND フラッシュ
5. microSDカードスロット

SD カードはイメージの保存に使用できますが、最小限のサンプルを実行するという観点では、あまり役に立ちません。
ディスプレイの解像度は 480×272 です。これは、フレームバッファ メモリが 522 ビットの深さで 240 バイトになることを意味します。 これは RAM のサイズを超えるため、フレームバッファとヒープ (画像や補助構造のデータを保存するために OpenCV を含む) は SDRAM に配置され、その他すべて (スタック用のメモリやその他のシステム ニーズ) ) は RAM に移動します。

STM32F7Discovery の最小構成 (ネットワーク全体、すべてのコマンドを破棄、スタックをできるだけ小さくするなど) を使用し、そこにサンプルを含む OpenCV を追加すると、必要なメモリは次のようになります。

   text    data     bss     dec     hex filename
2876890  459208  312736 3648834  37ad42 build/base/bin/embox

どのセクションがどこにあるのかよくわからない人のために、次のように説明します。 .text и .rodata 命令と定数 (大まかに言えば、読み取り専用データ) は次の場所にあります。 .data データは変更可能です。 .bss 「null」変数もありますが、それでも場所が必要です (このセクションは RAM に「移動」します)。

良いニュースは .data/.bss 適合するはずですが、 .text 問題は、画像用のメモリが 1MiB しかないことです。 捨てられる .text 例の画像を取得して、たとえば起動時に SD カードからメモリに読み込みますが、fruits.png の重さは約 330KiB なので、これでは問題は解決されません。 .text OpenCVコードで構成されています。

概して、残っていることは XNUMX つだけです。コードの一部を QSPI フラッシュにロードすることです (プロセッサがこのデータに直接アクセスできるように、メモリをシステム バスにマッピングする特別な動作モードがあります)。 この場合、問題が発生します。まず、デバイスを再起動した直後には QSPI フラッシュ ドライブのメモリが使用できなくなります (メモリ マップド モードを個別に初期化する必要があります)。次に、このメモリをこのメモリで「フラッシュ」することはできません。おなじみのブートローダー。

その結果、QSPI 内のすべてのコードをリンクし、TFTP 経由で必要なバイナリを受け取る自作のローダーでフラッシュすることが決定されました。

結果

このライブラリを Embox に移植するというアイデアは約 XNUMX 年前に現れましたが、さまざまな理由により何度も延期されました。 その XNUMX つは、libstdc++ と標準テンプレート ライブラリのサポートです。 Embox での C++ サポートの問題はこの記事の範囲を超えているため、ここでは、このライブラリが動作するために適切な量のサポートを達成できたことだけを述べておきます 🙂

最終的に、これらの問題は克服され (少なくとも OpenCV サンプルが動作するには十分)、サンプルは実行されました。 ボードが Canny フィルターを使用して境界を検索するには、40 秒ほどかかります。 もちろん、これは長すぎます (この問題を最適化する方法については考慮事項があり、成功した場合にはこれについて別の記事を書くことが可能です)。

ただし、中間目標は、STM32 上で OpenCV を実行する基本的な可能性を示すプロトタイプを作成することであり、この目標は達成されました。万歳です。

tl;dr: ステップバイステップの説明

0: 次のように Embox ソースをダウンロードします。

    git clone https://github.com/embox/embox && cd ./embox

1: QSPI フラッシュ ドライブを「フラッシュ」するブートローダーを組み立てることから始めましょう。

    make confload-arm/stm32f7cube

次に、ネットワークを構成する必要があります。 TFTP経由で画像をアップロードします。 ボードとホストの IP アドレスを設定するには、conf/rootfs/network を編集する必要があります。

設定例：

iface eth0 inet static
    address 192.168.2.2
    netmask 255.255.255.0
    gateway 192.168.2.1
    hwaddress aa:bb:cc:dd:ee:02

gateway - イメージのロード元のホスト アドレス、 address - ボードのアドレス。

その後、ブートローダーを収集します。

    make

2: ボード上のブートローダーの通常のロード (駄洒落でごめんなさい) - ここには特に何もありません。STM32F7Discovery の他のアプリケーションと同様に行う必要があります。 やり方がわからない場合は、それについて読むことができます ここで.
3: OpenCV の構成を使用してイメージをコンパイルします。

    make confload-platform/opencv/stm32f7discovery
    make

4: QSPI に書き込む ELF セクションを qspi.bin に抽出します。

    arm-none-eabi-objcopy -O binary build/base/bin/embox build/base/bin/qspi.bin 
        --only-section=.text --only-section=.rodata 
        --only-section='.ARM.ex*' 
        --only-section=.data

これを行うスクリプトが conf ディレクトリにあるので、それを実行できます。

    ./conf/qspi_objcopy.sh # Нужный бинарник -- build/base/bin/qspi.bin

5: tftp を使用して、qspi.bin.bin を QSPI フラッシュ ドライブにダウンロードします。 ホスト上でこれを行うには、qspi.bin を tftp サーバーのルート フォルダー (通常は /srv/tftp/ または /var/lib/tftpboot/) にコピーします。対応するサーバーのパッケージは、通常 と呼ばれる最も一般的なディストリビューションで入手できます。 tftpd または tftp-hpa、場合によってはそうする必要があります systemctl start tftpd.service 始めること）。

    # вариант для tftpd
    sudo cp build/base/bin/qspi.bin /srv/tftp
    # вариант для tftp-hpa
    sudo cp build/base/bin/qspi.bin /var/lib/tftpboot

Embox (つまり、ブートローダー内) で、次のコマンドを実行する必要があります (サーバーのアドレスは 192.168.2.1 であると仮定します)。

    embox> qspi_loader qspi.bin 192.168.2.1

6: コマンドあり goto QSPI メモリに「ジャンプ」する必要があります。 具体的な場所は画像のリンク方法によって異なります。このアドレスは次のコマンドで確認できます。 mem 0x90000000 (開始アドレスはイメージの 32 番目の XNUMX ビット ワードに収まります); スタックにフラグを立てる必要もあります -s、スタック アドレスは 0x90000000 です。例:

    embox>mem 0x90000000
    0x90000000:     0x20023200  0x9000c27f  0x9000c275  0x9000c275
                      ↑           ↑
              это адрес    это  адрес 
                стэка        первой
                           инструкции

    embox>goto -i 0x9000c27f -s 0x20023200 # Флаг -i нужен чтобы запретить прерывания во время инициализации системы

    < Начиная отсюда будет вывод не загрузчика, а образа с OpenCV >

7: 打ち上げ

    embox> edges 20

40 秒間の国境探索をお楽しみください 🙂

何か問題が発生した場合は、問題を書き込んでください 私たちのリポジトリ、またはメーリングリストへ [メール保護]、またはここのコメントで。

出所： habr.com