🧑🏻‍🤝‍🧑🏻 🚨 👩‍👧‍👦 マイクロコントローラーで複雑なC ++アプリケーションを実行する 🛌🏿 🏎️ 🐰

今日、マイクロコントローラー用のC ++で開発できることに誰も驚いていません。mbedプロジェクトは、この言語に完全に焦点を合わせています。他の多くのRTOSは、C ++開発機能を提供します。プログラマーはオブジェクト指向プログラミングツールにアクセスできるため、これは便利です。ただし、多くのRTOSは、C ++の使用にさまざまな制限を課しています。この記事では、C ++の内部を調べ、これらの制限の理由を見つけます。

ほとんどの例はRTOSEmboxで検討されることにすぐに注意したいと思います。実際、Qtや OpenCVなどの複雑なC ++プロジェクトは、マイクロコントローラー上で機能します。OpenCVには完全なC ++サポートが必要ですが、これは通常マイクロコントローラーにはありません。

基本構文

C ++言語の構文は、コンパイラーによって実装されます。ただし、実行時に、いくつかの基本的なエンティティを実装する必要があります。コンパイラーでは、それらはlibsupc ++言語サポートライブラリーに含まれています。最も基本的なのは、コンストラクタとデストラクタのサポートです。オブジェクトには、グローバルオブジェクトと新しいオブジェクトの2種類があります。

グローバルコンストラクタとデストラクタ

C ++アプリケーションがどのように機能するかを見てみましょう。 main（）を入力する前に、すべてのグローバルC ++オブジェクトがコードに存在する場合、それらが作成されます。これには、特別なセクション.init_arrayが使用されます。セクション.init、.preinit_array、.ctorsもあります。最新のARMコンパイラの場合、セクションの最も一般的な使用法は.preinit_array、.init、および.init_arrayです。 LIBCの観点からは、これは関数へのポインターの通常の配列であり、配列の対応する要素を呼び出すことによって最初から最後まで渡す必要があります。この手順の後、制御はメイン（）に移されます。

Emboxからグローバルオブジェクトのコンストラクターを呼び出すためのコード：

void cxx_invoke_constructors(void) {
    extern const char _ctors_start, _ctors_end;
    typedef void (*ctor_func_t)(void);
    ctor_func_t *func = (ctor_func_t *) &_ctors_start;

    ....

    for ( ; func != (ctor_func_t *) &_ctors_end; func++) {
        (*func)();
    }
}

ここで、C ++アプリケーションの終了がどのように機能するか、つまり、グローバルオブジェクトのデストラクタの呼び出しを見てみましょう。 2つの方法があります。

コンパイラで最も一般的に使用されているものから始めます-__ cxa_atexit（）（C ++ ABIから）を介して。これはPOSIXatexit関数の類似物です。つまり、プログラムの終了時に呼び出される特別なハンドラーを登録できます。上記のように、アプリケーションの開始時にグローバルコンストラクターが呼び出されると、__ cxa_atexitの呼び出しを通じてハンドラーを登録するコンパイラー生成コードもあります。ここでのLIBCの仕事は、必要なハンドラーとその引数を格納し、アプリケーションの終了時にそれらを呼び出すことです。

別の方法は、デストラクタへのポインタを特別なセクション.fini_arrayおよび.finiに格納することです。 GCCコンパイラでは、これは-fno-use-cxa-atexitフラグを使用して実現できます。この場合、デストラクタは、アプリケーションの終了時に逆の順序（上位アドレスから下位アドレスへ）で呼び出す必要があります。この方法はあまり一般的ではありませんが、マイクロコントローラーで役立つ場合があります。実際、この場合、アプリケーションのビルド時に、必要なハンドラーの数を確認できます。

Emboxからグローバルオブジェクトのデストラクタを呼び出すためのコード：

int __cxa_atexit(void (*f)(void *), void *objptr, void *dso) {
    if (atexit_func_count >= TABLE_SIZE) {
        printf("__cxa_atexit: static destruction table overflow.\n");
        return -1;
    }

    atexit_funcs[atexit_func_count].destructor_func = f;
    atexit_funcs[atexit_func_count].obj_ptr = objptr;
    atexit_funcs[atexit_func_count].dso_handle = dso;
    atexit_func_count++;

    return 0;
};

void __cxa_finalize(void *f) {
    int i = atexit_func_count;

    if (!f) {
        while (i--) {
            if (atexit_funcs[i].destructor_func) {
                (*atexit_funcs[i].destructor_func)(atexit_funcs[i].obj_ptr);
                atexit_funcs[i].destructor_func = 0;
            }
        }
        atexit_func_count = 0;
    } else {
        for ( ; i >= 0; --i) {
            if (atexit_funcs[i].destructor_func == f) {
                (*atexit_funcs[i].destructor_func)(atexit_funcs[i].obj_ptr);
                atexit_funcs[i].destructor_func = 0;
            }
        }
    }
}

void cxx_invoke_destructors(void) {
    extern const char _dtors_start, _dtors_end;
    typedef void (*dtor_func_t)(void);
    dtor_func_t *func = ((dtor_func_t *) &_dtors_end) - 1;

    /* There are two possible ways for destructors to be calls:
     * 1. Through callbacks registered with __cxa_atexit.
     * 2. From .fini_array section.  */

    /* Handle callbacks registered with __cxa_atexit first, if any.*/
    __cxa_finalize(0);

    /* Handle .fini_array, if any. Functions are executed in teh reverse order. */
    for ( ; func >= (dtor_func_t *) &_dtors_start; func--) {
        (*func)();
    }
}

グローバルデストラクタは、C ++アプリケーションを再起動できるようにする必要があります。マイクロコントローラ用のほとんどのRTOSは、再起動しない単一のアプリケーションを実行します。開始は、システム内で唯一のカスタム関数mainから始まります。したがって、小さなRTOSでは、グローバルデストラクタは使用を目的としていないため、空であることがよくあります。

Zephyr RTOSのグローバルデストラクタコード：

/**
 * @brief Register destructor for a global object
 *
 * @param destructor the global object destructor function
 * @param objptr global object pointer
 * @param dso Dynamic Shared Object handle for shared libraries
 *
 * Function does nothing at the moment, assuming the global objects
 * do not need to be deleted
 *
 * @return N/A
 */
int __cxa_atexit(void (*destructor)(void *), void *objptr, void *dso)
{
    ARG_UNUSED(destructor);
    ARG_UNUSED(objptr);
    ARG_UNUSED(dso);
    return 0;
}

新規/削除演算子

GCCコンパイラでは、new / delete演算子の実装はlibsupc ++ライブラリにあり、それらの宣言はヘッダーファイルにあります。

libsupc ++からのnew / delete実装を使用できます。Aですが、それらは非常に単純であり、たとえば、標準のmalloc / freeまたはアナログを介して実装できます。

単純なEmboxオブジェクトの新規/削除実装コード：


void* operator new(std::size_t size)  throw() {
    void *ptr = NULL;

    if ((ptr = std::malloc(size)) == 0) {
        if (alloc_failure_handler) {
            alloc_failure_handler();
        }
    }

    return ptr;
}
void operator delete(void* ptr) throw() {
    std::free(ptr);
}

RTTIと例外

アプリケーションが単純な場合は、例外サポートと動的データ型識別（RTTI）は必要ない場合があります。この場合、コンパイラフラグ-no-exception-no-rttiを使用して無効にすることができます。

ただし、このC ++機能が必要な場合は、実装する必要があります。これは、new / deleteよりもはるかに困難です。

幸いなことに、これらはOSに依存せず、libsupc ++ライブラリですでにクロスコンパイルされています。したがって、サポートを追加する最も簡単な方法は、libsupc ++を使用することです。クロスコンパイラのライブラリ。プロトタイプ自体はヘッダーファイルとにあります。

クロスコンパイラの例外を使用するには、独自のC ++ランタイムロードメソッドを追加するときに満たす必要のある小さな要件があります。リンカスクリプトには、特別な.eh_frameセクションが必要です。また、ランタイムを使用する前に、このセクションをセクションの先頭のアドレスで初期化する必要があります。 Emboxは次のコードを使用します。

void register_eh_frame(void) {
    extern const char _eh_frame_begin;
    __register_frame((void *)&_eh_frame_begin);
}

ARMアーキテクチャの場合、独自の情報構造を持つ他のセクション（.ARM.exidxおよび.ARM.extab）が使用されます。これらのセクションの形式は、「ARMアーキテクチャの例外処理ABI」（EHABI標準）で定義されています。.ARM.exidxはインデックステーブルであり、.ARM.extabは例外を処理するために必要な要素自体のテーブルです。これらのセクションを使用して例外を処理するには、リンカースクリプトにそれらを含める必要があります。

    .ARM.exidx : {
        __exidx_start = .;
        KEEP(*(.ARM.exidx*));
        __exidx_end = .;
    } SECTION_REGION(text)

    .ARM.extab : {
        KEEP(*(.ARM.extab*));
    } SECTION_REGION(text)

GCCがこれらのセクションを使用して例外を処理できるようにするには、.ARM.exidxセクションの開始と終了（__exidx_startと__exidx_end）を指定します。これらのシンボルは、libgcc /unwind-arm-common.incファイルのlibgccにインポートされます。

extern __EIT_entry __exidx_start;
extern __EIT_entry __exidx_end;

ARMでのスタックアンワインドの詳細については、記事を参照してください。

言語標準ライブラリ（libstdc ++）

標準ライブラリのネイティブ実装

C ++のサポートには、基本的な構文だけでなく、libstdc ++標準ライブラリも含まれています。その機能と構文は、さまざまなレベルに分けることができます。文字列やC ++ setjmpラッパーの操作などの基本的なことがあります。これらは、標準Cライブラリを介して簡単に実装できます。また、標準テンプレートライブラリ（STL）など、より高度なものもあります。

クロスコンパイラの標準ライブラリ

基本的なものはEmboxに実装されています。これらで十分な場合は、外部C ++標準ライブラリを含めることはできません。ただし、たとえば、コンテナーのサポートが必要な場合、最も簡単な方法は、クロスコンパイラーからのライブラリーとヘッダー・ファイルを使用することです。

クロスコンパイラからC ++標準ライブラリを使用する場合はひねりがあります。標準のarm-none-eabi-gccを見てみましょう。

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/alexander/apt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: ***     --with-gnu-as --with-gnu-ld --with-newlib   ***
Thread model: single
gcc version 9.3.1 20200408 (release) (GNU Arm Embedded Toolchain 9-2020-q2-update)

これは、C標準ライブラリの--with-newlib.Newlib実装をサポートして構築されています。Emboxは、標準ライブラリの独自の実装を使用します。これには理由があり、オーバーヘッドを最小限に抑えます。したがって、必要なパラメータは、標準Cライブラリだけでなく、システムの他の部分にも設定できます。

標準Cライブラリは異なるため、ランタイムを維持するために互換性レイヤーを実装する必要があります。クロスコンパイラから標準ライブラリをサポートするために必要であるが明白ではないものの1つのEmboxからの実装の例を示します

struct _reent {
    int _errno;           /* local copy of errno */

  /* FILE is a big struct and may change over time.  To try to achieve binary
     compatibility with future versions, put stdin,stdout,stderr here.
     These are pointers into member __sf defined below.  */
    FILE *_stdin, *_stdout, *_stderr;
};

struct _reent global_newlib_reent;

void *_impure_ptr = &global_newlib_reent;

static int reent_init(void) {
    global_newlib_reent._stdin = stdin;
    global_newlib_reent._stdout = stdout;
    global_newlib_reent._stderr = stderr;

    return 0;
}

libstdc ++クロスコンパイラーを使用するために必要なすべての部分とその実装は、Emboxのフォルダー 'third-party / lib / toolchain / newlib_compat /'で表示できます。

標準ライブラリstd :: threadおよびstd :: mutexの拡張サポート

コンパイラのC ++標準ライブラリは、さまざまなレベルのサポートを持つことができます。出力をもう一度見てみましょう。

$ arm-none-eabi-gcc -v
***
Thread model: single
gcc version 9.3.1 20200408 (release) (GNU Arm Embedded Toolchain 9-2020-q2-update)

スレッドモデル：シングル。GCCがこのオプションでビルドされると、STLからのすべてのスレッドサポートが削除されます（たとえば、 std :: threadおよび std :: mutex）。また、たとえば、OpenCVなどの複雑なC ++アプリケーションのアセンブリには問題があります。つまり、このバージョンのライブラリは、この機能を必要とするアプリケーションを構築するには不十分です。

Emboxで使用するソリューションは、マルチスレッドモデルを備えた標準ライブラリのために独自のコンパイラを構築することです。Emboxの場合、posix「スレッドモデル：posix」が使用されます。この場合、std :: threadおよびstd :: mutexは、標準のpthread_ *およびpthread_mutex_ *を介して実装されます。これにより、newlib互換性レイヤーを含める必要もなくなります。

エンボックス構成

コンパイラの再構築は最も信頼性が高く、最も完全で互換性のあるソリューションを提供しますが、同時に、多くの時間がかかり、マイクロコントローラではそれほど多くない追加のリソースが必要になる場合があります。したがって、この方法をどこでも使用することはお勧めできません。

サポートコストを最適化するために、Emboxは、さまざまな実装を指定できるいくつかの抽象クラス（インターフェイス）を導入しました。

embox.lib.libsupcxx-言語の基本構文をサポートするために使用するメソッドを定義します。
embox.lib.libstdcxx-使用する標準ライブラリの実装を定義します

libsupcxxには3つのオプションがあります。

embox.lib.cxx.libsupcxx_standalone-Emboxに含まれる基本的な実装。
third_party.lib.libsupcxx_toolchain-クロスコンパイラの言語サポートライブラリを使用します
third_party.gcc.tlibsupcxx-ソースからのライブラリの完全なアセンブリ

最小限のオプションは、C ++標準ライブラリがなくても機能します。Emboxには、標準Cライブラリの最も単純な関数に基づく実装があります。この機能では不十分な場合は、3つのlibstdcxxオプションを指定できます。

third_party.STLport.libstlportgは、STLportプロジェクトに基づくSTL標準ライブラリです。gccを再構築する必要はありません。しかし、プロジェクトは長い間サポートされていません
third_party.lib.libstdcxx_toolchain-クロスコンパイラの標準ライブラリ
third_party.gcc.libstdcxx-ソースからのライブラリの完全なアセンブリ

必要に応じて、ウィキでSTM32F7でQtまたは OpenCVをビルドして実行する方法について説明しています。すべてのコードは当然無料です。

マイクロコントローラーで複雑なC ++アプリケーションを実行する