私は数年にわたって組み込みシステムに取り組んできました。当社は、自動車、充電器などのオンボードコンピューターを開発および製造しています。



当社の製品で使用されるプロセッサは、主に16ビットおよび32ビットのMicrochipマイクロコントローラーで、8〜32 kBのRAM、128〜512 kBのROM、MMUなしです。 時には、最も単純なデバイスの場合、さらに控えめな8ビットチップが使用されます。

明らかに、Linuxカーネルを使用する（合理的な）機会はありません。 したがって、何らかのRTOS（リアルタイムオペレーティングシステム）が必要です。 マイクロコントローラでOSを使用しない人もいますが、これは良い習慣ではありません。ハードウェアがOSの使用を許可している場合、それを使用します。

数年前、8ビットからより強力な16ビットマイクロコントローラーに切り替えたとき、私よりも経験豊富な同僚がTNKernelプリエンプティブRTOSを推奨しました 。 これが、私が数年間さまざまなプロジェクトで使用したOSです。

彼女にとても満足しているわけではありません。たとえば、タイマーはありません。 また、スレッドが一度に複数のキューからのメッセージを待機することはできません。 また、スタックのソフトウェア制御オーバーフローはありません（実際に気になります）。 しかし、うまくいったので、私はそれを使い続けました。

押し出しOSの仕組み

あなたと私がお互いを理解していることを確認するために、プリエンプティブOSが原理的にどのように機能するかを簡単に説明します。 ここで設定していることが読者にとってささいなことである場合は、申し訳ありません。

複数のスレッドを開始する

マイクロコントローラーは「シングルスレッド」です。一度に実行できる命令は1つだけです（もちろん、マルチコアプロセッサーもありますが、現在ではそうではありません）。 シングルコアプロセッサで複数のスレッドを実行するには、スレッドを切り替える必要があるため、ユーザーはスレッドを並列に実行しているように見えます。



これは、OSが最初に必要なものです。つまり、スレッド間で制御を切り替えます。 彼女はどのようにそれをしますか？

マイクロコントローラにはレジスタのセットがあります。 なぜなら マイクロコントローラはシングルスレッドであり、このレジスタセットは1つのスレッドにのみ属します。 たとえば、2つの数値の合計を見つけた場合：

//-- assume we have two ints: a and b int c = a + b; 

実際、次のようなことが起こります（もちろん、アクションの特定のシーケンスはアーキテクチャによって異なりますが、一般的には考え方は変わりません）。

 # the MIPS disassembly: LW V0, -32744(GP) #    a  RAM   V0 LW V1, -32740(GP) #    b  RAM   V1 ADDU V0, V1, V0 #   V1  V0 ,    V0 SW V0, -32496(GP) #    V0  RAM (   c) 

4つのアクションがあります。 なぜなら プリエンプティブOSでは、1つのスレッドがいつでも別のスレッドに取って代わることができます。もちろん、これはこのシーケンスの途中で発生する可能性があります。 合計の値がレジスタV0およびV1にロードされた後、別のスレッドが現在のスレッドを混雑させていると想像してください。 新しいスレッドには独自の機能があるため、必要に応じてこれらのレジスタを使用します。 もちろん、2つのスレッドが互いに干渉しないようにする必要があります。したがって、最初のスレッドが再び制御を取得するとき、レジスタV0およびV1（およびその他）の値は、混雑する前と同じである必要があります。

そのため、ストリームAからストリームBに切り替える場合、まず、ストリームAのすべてのレジスタの値をどこかに保存してから、ストリームBのすべてのレジスタの値を復元する必要があります。その後、ストリームBが制御を取得し、動作を継続します。

したがって、より正確なフロースイッチング図は次のようになります。



あるスレッドから別のスレッドに切り替える必要がある場合、カーネルが制御を取得し、必要なサービスアクション（少なくとも、レジスタの値を保存および復元）を実行してから、制御が次のスレッドに転送されます。

各ストリームのレジスタ値は正確にどこに保存されますか？ 多くの場合、これはスレッドスタックです。

ストリームスタック

最新のオペレーティングシステムでは、MMUのおかげで（ユーザー）スタックが動的に成長します。スレッドが必要になるほど、スレッドが増えます（カーネルが許可する場合）。 しかし、私が使用しているマイクロコントローラーにはこの贅沢はありません。すべてのRAMはアドレス空間に静的にマップされます。 したがって、各スレッドは、スタックに使用される独自のRAMを取得します。 また、スレッドが割り当てられたよりも多くのスタックを使用すると、メモリが破損し、その結果、不正な操作が発生します。 実際、各スレッドのスタックスペースは単なるバイトの配列です。

特定の各スレッドが必要とするスタックの量を決定する場合、最初に必要なスタックの量を把握し、ある程度余裕を持って取得します。 たとえば、深く埋め込まれたGUIストリームの場合、数キロバイトが必要になる場合がありますが、ユーザー入力を処理する小さなストリームの場合は、数百バイトで十分です。

3つのスレッドがあり、それらのスタック消費量が次のとおりであると仮定しましょう。



既に示したように、各スレッドのレジスタ値のセットは、このスレッドのスタックに保存されます。 このレジスタ値のセットは、ストリームコンテキストと呼ばれます 。 次の図はこれを反映しています（アクティブなフローはアスタリスクで示されています）：



アクティブなスレッド（スレッドA）のコンテキストはスタックに保存されないことに注意してください。 マイクロコントローラーのスタックポインターは、ストリームAのユーザーデータの先頭を指し、マイクロコントローラーのレジスタセット全体がストリームAに属します（実際、ストリームに関連しない特別なレジスタがまだ存在する可能性がありますが、これは今では興味の対象ではありません）。

カーネルは、制御をスレッドAからスレッドBに切り替えることを決定すると、次のことを行います。

• すべてのレジスタの値をスタック（つまり、スレッドAのスタック）に保存します。
• スタックポインターをストリームBスタックの先頭に切り替えます。
• スタックから（つまり、スレッドBのスタックから）すべてのレジスタの値を復元します。

その後、次のものがあります。



ストリームBは引き続き事業に取り掛かります。

中断

中断という非常に重要なトピックについてはまだ触れていません。

割り込みとは、現在実行中のスレッドが（ほとんどの場合、外部イベントが原因で）中断され、プロセッサが（割り込みを処理するために）しばらく他の何かに切り替えてから、割り込みを受けたスレッドに戻ることです。 割り込みはいつでも生成される可能性があるため、これに備える必要があります。

通常、組み込みシステムに使用されるマイクロコントローラーには、タイマー、トランシーバー（UART、SPI、CANなど）、ADCなどの多くの周辺機器があります。 この周辺機器は、特定のイベントが発生したときに割り込みを生成できます。たとえば、UART周辺機器は、新しいバイトを受信すると割り込みを生成できるため、プログラムはどこかに保存できます。 タイマーはオーバーフロー割り込みを生成するため、プログラムはこれをいくつかの定期的なタスクなどに使用できます。

割り込みハンドラーはISR（割り込みサービスルーチン）と呼ばれます。

割り込みにはさまざまな優先順位があります。たとえば、ある種の低優先順位の割り込みが生成されると、実行中のスレッドが中断され、ISRが制御を引き継ぎます。 ここで、高優先度の割り込みが生成されると、現在のISRが再び一時停止され、新しい割り込みのISRが制御を引き継ぎます。 明らかに、それが終了すると、最初のISRは作業を続行し、それも終了すると、最終的に制御は中断されたストリームに戻されます。

割り込みが受け入れられない短い期間があります。たとえば、ISRで変更される可能性のあるデータを処理する場合です。 このデータを複数のステップで処理すると、処理の途中で割り込みが発生し、データが変更される可能性があります。 その結果、ストリームは非整数データを処理し、プログラムの誤動作につながります。

これらの短い期間は「クリティカルセクション」と呼ばれます。クリティカルセクションに入ると割り込みが禁止され、終了すると割り込みが有効になります。 つまり、クリティカルセクション内で何らかの種類の割り込みが生成された場合、ISRは（割り込みが許可されるとき）出口からのみ呼び出されます。

非常に興味深い質問：ISRスタックをどこに保存しますか？

割り込みスタック

一般に、2つのオプションがあります。

• 中断されたスレッドスタックを使用します。
• 割り込み用に別のスタックを使用します。

中断されたスレッドのスタックを使用すると、次のようになります（次の図では、スレッドBが中断されます）。



割り込みが生成されるとき：

• 現在のスレッドのコンテキストは、スレッドのスタックに保存されます（ISRが完了すると、すぐに別のスレッドに切り替えることができます）。
• ISRはその仕事を行います（中断を処理します）。
• 別のスレッドに切り替える必要がある場合は、切り替えます（少なくとも、スタックポインターを変更します）。
• スレッドコンテキストはスタックから復元されます。
• ストリームは作業を続けます。

これは非常に迅速に機能しますが、リソースが非常に限られている組み込みシステムのコンテキストでは、このアプローチには重大な欠点があります。 どっち？

割り込みはいつでも発生する可能性があるため、割り込みが発生したときにどのスレッドがアクティブになるかを事前に知ることはできません。 そのため、各スレッドのスタックサイズを見積もるときは、最悪のネストを考慮して、既存のすべての割り込みがこのスレッドで発生する可能性があると想定する必要があります。 これにより、すべてのストリームのスタックサイズが大幅に増加する可能性があります。1KBで簡単ですが、それ以上になる場合もあります（もちろん、アプリケーションによって異なります）。 たとえば、アプリケーションに7つのスレッドがある場合、割り込みに必要なRAMサイズは1 * 7 = 7 kBです。 マイクロコントローラーのRAMが32 kBのみの場合（これは既に豊富なマイクロコントローラーです）、7 kBは20％です！ あ〜

合計で、各スレッドのスタックには次のものが含まれている必要があります。

• 独自のストリームデータ。
• ストリームコンテキスト（すべてのレジスタの値）;
• 最悪の場合のネストに基づくすべてのISRのデータ。

割り込みに別のスタックを使用する場合は、次のオプションに進みます。



これで、前の例のISRに1 kBを1回だけ割り当てる必要があります。 これははるかに有能なアプローチだと思います。組み込みシステムでは、RAMは非常に高価なリソースです。

このようなRTOSの原則の表面的なレビューの後、次に進みます。

TNKernel

記事の冒頭で示したように、16ビットおよび32ビットのマイクロコントローラーの開発にはTNKernelを使用しました。

残念ながら、 PIC32のTNKernelポートの作成者であるAlex Borisovは、割り込みが割り込みスレッドのスタックを使用する場合にこのアプローチを使用していました。 大量のRAMを無駄にし、私をとても幸せにしませんが、それ以外の場合TNKernelは見栄えがよく、コンパクトで高速なので、使い続けました。 X日まで、実際、すべてが非常に悪いことを知って非常に驚きました。

PIC32の下のファイルTNKernel

私は別のプロジェクトに取り組みました：車のキャンドルからのアナログ信号を分析し、ユーザーがこの信号のいくつかのパラメーターを見ることができるデバイス：持続時間、振幅など。 信号は急速に変化するため、十分に頻繁に測定する必要があります。1または2マイクロ秒ごとに1回です。

このタスクでは、PIC32ファミリのMicrochipプロセッサ（MIPSコア付き）が選択されました。

タスクはそれほど難しくないはずですが、ある日問題が発生しました。デバイスが測定を開始したときに、プログラムがまったく予期しない場所でクラッシュすることがありました。 「それは汚染された記憶であるに違いない」と私は思い、非常に怒っていた。 メモリ破損に関連するエラーを見つけるプロセスは長く、完全に非自明である可能性があります：前述したように、MMUがなく、システム内のすべてのスレッドがすべてのRAMを使用できるため、スレッドの1つが制御不能になり、他のスレッドのメモリを台無しにした場合、その後、問題は実際の場所から非常に遠く離れた場所に現れ、エラーが発生します。

TNKernelにはソフトウェアスタックオーバーフロー制御がないことは既に述べたので、メモリ破損の疑いがある場合は、まず、スレッドがスタックでオーバーフローしているかどうかを確認する価値があります。 スレッドが作成されると、そのスタックは特定の値（PIC32の下のTNKernelでは0xffffffff ）で初期化されるため、スタックの終わりが汚れているかどうかを簡単に確認できます。 確認したところ、実際、アイドル状態のスレッドスタックは明らかにいっぱいです。



MIPSでは、スタックが大きくなるため、 task_idle_stack[0]はアイドルスレッドスタックで最後に使用可能なワードです。

まあ、これはすでに何かです。 しかし、実際には、このスレッドのスタックには大きなマージンが割り当てられています。デバイスが正常に動作している場合、880のうち約300バイトしか使用されていません。 スタックをオーバーフローさせるある種の野生のバグが存在するはずです。

その後、私は記憶をより注意深く研究し始め、スタックが繰り返しパターンで満たされていることが明らかになりました。 参照：シーケンス0xFFFFFFFF, 0xFFFFFFFA, 0xA0006280, 0xA0005454 ：



そして再び同じシーケンス：



アドレス0xA000051Cおよび0xA00005A4 違いは136バイトです。 4（ワードサイズ）で割ります。これらは34ワードです。

うーん、34ワード...これはMIPSのコンテキストのサイズです！ そして、同じパターンが何度も繰り返されます。 そのため、コンテキストは数回連続して保存されているようです。 しかし...これはどのようにできますか？！

残念ながら、すべてを理解するために多くの時間がかかりました。 まず、保存されたコンテキストをより詳細に調査しようとしました。特に、中断されたストリームが後で作業を再開する必要があるアドレスがプログラムメモリにある必要があります。 PIC32では、プログラムメモリは0x9D000000から0x9D007FFF領域にマッピングされるため、これらのアドレスは残りのデータと簡単に区別できます。 これらのアドレスは保存されたコンテキストから0x9D012C28 。そのうちの1つは0x9D012C28です。 逆アセンブラを確認します。

 9D012C04 AD090000 SW T1, 0(T0) 9D012C08 8FA80008 LW T0, 8(SP) 9D012C0C 8FA9000C LW T1, 12(SP) 9D012C10 01000013 MTLO T0, 0 9D012C14 01200011 MTHI T1, 0 9D012C18 8FA10010 LW AT, 16(SP) 9D012C1C 8FA20014 LW V0, 20(SP) 9D012C20 8FA30018 LW V1, 24(SP) 9D012C24 8FA4001C LW A0, 28(SP) 9D012C28 8FA50020 LW A1, 32(SP) # <-   9D012C2C 8FA60024 LW A2, 36(SP) 9D012C30 8FA70028 LW A3, 40(SP) 9D012C34 8FA8002C LW T0, 44(SP) 9D012C38 8FA90030 LW T1, 48(SP) 9D012C3C 8FAA0034 LW T2, 52(SP) 9D012C40 8FAB0038 LW T3, 56(SP) 9D012C44 8FAC003C LW T4, 60(SP) 9D012C48 8FAD0040 LW T5, 64(SP) 9D012C4C 8FAE0044 LW T6, 68(SP) 9D012C50 8FAF0048 LW T7, 72(SP) 9D012C54 8FB0004C LW S0, 76(SP) 9D012C58 8FB10050 LW S1, 80(SP) 9D012C5C 8FB20054 LW S2, 84(SP) 9D012C60 8FB30058 LW S3, 88(SP) 9D012C64 8FB4005C LW S4, 92(SP) 9D012C68 8FB50060 LW S5, 96(SP) 9D012C6C 8FB60064 LW S6, 100(SP) 9D012C70 8FB70068 LW S7, 104(SP) 9D012C74 8FB8006C LW T8, 108(SP) 9D012C78 8FB90070 LW T9, 112(SP) 9D012C7C 8FBA0074 LW K0, 116(SP) 9D012C80 8FBB0078 LW K1, 120(SP) 9D012C84 8FBC007C LW GP, 124(SP) 9D012C88 8FBE0080 LW S8, 128(SP) 9D012C8C 8FBF0084 LW RA, 132(SP) 9D012C90 41606000 DI ZERO 9D012C94 000000C0 EHB 9D012C98 8FBA0000 LW K0, 0(SP) 9D012C9C 8FBB0004 LW K1, 4(SP) 9D012CA0 409B7000 MTC0 K1, EPC 

SP（スタックポインター）に関連するアドレスからのLW（ロードワード）からのこの特徴的なシーケンスは、コンテキスト回復手順です。 これで、コンテキストがスタックから復元されたときにスレッドがプッシュされたことは明らかです。 さて、これは中断が原因である可能性がありますが、なぜこれほど頻繁に連続するのでしょうか？ システムにはそれほど多くの割り込みさえありません。

それ以前は、TNKernelを使用したのは、それがどのように機能するか明確に理解せずに使用しただけでした。 だから、私はコアに深く入るのが少し怖かったです。 しかし、今回はそうしなければなりませんでした。

PIC32でのTNKernelのコンテキストの切り替え

コンテキストスイッチングのプロセス全般については既に説明しましたが、ここでは、このトピックを更新し、特定の実装（TNKernel）の詳細を追加しましょう。

カーネルは、コンテキストをスレッドAからスレッドBに切り替えることを決定すると、次のことを行います。

• すべてのレジスタの値をスタック（つまり、スレッドAのスタック）に保存します。
• 中断を禁止します。
• スタックポインターをストリームBスタックの先頭に切り替えます。
• ポインターをアクティブなスレッドのハンドル（スレッドBのハンドル）に切り替えます。
• 割り込みを許可します。
• スタックから（つまり、スレッドBのスタックから）すべてのレジスタの値を復元します。

ご覧のように、カーネルがストリーム記述子とスタックの最上部へのポインターで動作している間、短いクリティカルセクションがあります：そうでない場合、これらのアクションの間に割り込みが生成されると状況が発生する可能性があり、もちろんデータの不完全性は誤った動作につながります。

PIC32でのTNKernel割り込み

TNKernelにはPIC32の下に2種類の割り込みがあります。

• システム割り込み：カーネルサービスを引き起こす可能性があり、ISRの直後にコンテキストスイッチが発生する可能性があります。 このような割り込みが呼び出されると、カーネルは現在のスレッドのスタックに完全なコンテキストを保存します
• ユーザー割り込み：カーネルサービスを呼び出すことができません。 このような割り込みが生成されると、カーネルは何のアクションも実行しません。

現在、システム割り込みにのみ関心があります。 また、TNKernelにはこのタイプの割り込みに対する制限があります。アプリケーション内のすべてのシステム割り込みは同じ優先度を持つ必要があるため、これらの割り込みはネストできません。

小さなリマインダーとして、割り込みが生成されたときに何が起こるかを次に示します。

• 現在のスレッドのコンテキストは、ストリームスタックに格納されます。
• ISRが制御します。

これでISRがアクティブになり、スタックの使用は次のとおりです。



すでに述べたように、このアプローチではスレッドに必要なスタックサイズが大幅に増加します。各スレッドは、次の要素を収容できる大きさでなければなりません。

• 独自のストリームデータ。
• ストリームコンテキスト（すべてのレジスタの値）;
• 最悪の場合のネストに基づくすべてのISRのデータ。

ISRスタックにスレッドの数を掛ける必要はありませんが、一般的に言って、私はISRスタックに対応する準備ができていました。

コンテキスト切り替え時の中断

そして、コンテキストの切り替え中に割り込みが生成された場合、つまり 現在のスレッドのコンテキストはスタックに保存されるか、スタックから復元されますか？

あなたが推測したと思う：なぜなら コンテキストの保存/復元プロセス中の中断は禁止されていません。コンテキストは2回保存されます。 ここに：



そのため、カーネルがスレッドBからスレッドAに切り替えることを決定すると、次のようになります。

• コンテキストはスレッドBのスタックに保存されます。
• このプロセスの途中で、中断が発生します。
• スレッドBのスタックでは、スペースが別のコンテキストに割り当てられ、コンテキストがそこに保存されます
• ISRが制御を取り、その仕事をして終了します
• ISRが完了すると、カーネルはどのスレッドが制御を渡す必要があるかを確認します（これはスレッドAです。割り込みが発生する前にスレッドAに切り替えたかったことを思い出してください）
• 中断の禁止
• スタックポインターとポインターを現在のスレッドのハンドルに切り替えます
• 割り込みを許可
• コンテキストはスタックから復元されます（つまり、タスクAのスタックの最上部から）

次の図が表示されます。



参照：コンテキストはストリームBのスタックに2回保存されます。実際、スタックがいっぱいでない場合、これは災害ではありません。 この二重保存されたコンテキストは、スレッドBが制御を取得するとすぐに2回復元されます。 たとえば、スレッドAが何かを待ち、カーネルが制御をスレッドBに戻すと仮定します。

• コンテキストはストリームAスタックに保存されます。
• 割り込みの無効化、スタックポインターの切り替えなど、割り込みの有効化。
• コンテキストは、スレッドBのスタックから復元されます。

実際、スレッドAに切り替える前にスレッドBのスタックにコンテキストが保存された時点に戻っています。したがって、コンテキストの保存を続けます。

• ストリームBスタックへのコンテキストの保存を終了します。
• アクティブ化する必要があるストリームを取得します（実際、既にアクティブ化されています：ストリームB）。
• コンテキストを元に戻します。

その後、スレッドBは、何も起こらなかったかのように機能し続けます。



ご覧のとおり、実際には何も破ることはありませんでしたが、この調査から重要な結論を下す必要があります。各ストリームのコンテキストに含まれるべきであるという仮定は正しくありませんでした。 少なくとも、1つではなく2つのコンテキストに対応する必要があります。

覚えているように、TNKernelのすべてのシステム割り込みは同じ優先度を持つ必要があるため、ネストすることはできません。つまり、コンテキストを2回以上保存できないことを意味します。

その場合、最終的な結論は次のとおりです。各スレッドのスタックには次のものが含まれている必要があります。

• 独自のストリームデータ。
• ストリームコンテキスト（すべてのレジスタの値）;
• コンテキストが保存されたときに中断が発生した場合の2番目のコンテキスト。
• 最悪の場合のネストに基づくすべてのISRのデータ。

ああ...各ストリームにさらに136バイト。繰り返しますが、スレッド数で乗算します。7スレッドの場合、これはほぼ1キロバイトで、32 kBのさらに3％です。

わかった いいね私は、おそらく、このような状況に同意するだろうが、私たちの最終的な結論は、実際には、それは最終的ではありません。すべてのより悪化し。

より深く掘る

二重コンテキストをより深く保存するプロセスを詳しく調べてみましょう：前回の調査の後でも、スレッドスタックにコンテキストが何回保存されたのかを説明することはできません。 ）、および別のシステム割り込みが発生した場合、現在のISRが制御を返した後に処理されます。

もう一度この図を見てみましょう。ISRはすでに制御を返しているので、ストリームAに切り替えました。



この時点で、プロセッサの割り込みレベルが再び下げられ、コンテキストがスレッドBスタックに2回保存されます。

次は何だと思いますか？

そうです。ストリームBに切り替えて、コンテキストを復元しているときに、別の割り込みが発生する可能性があります。考慮してください：



はい、コンテキストはすでに3回スレッドスタックに保存されています。さらに悪いことに、同じ割り込みである可能性もあります。同じ割り込みでスレッドスタックのコンテキストを数回保存できます。

したがって、割り込みが定期的に発生し、スレッドが前後に切り替わるのとまったく同じ速度で運が悪ければ、コンテキストはストリームスタックに何度も保存され、最終的にはスタックオーバーフロー。

これは、PIC32でのTNKernelポートの作成者によって明らかに考慮されていませんでした。

そしてこれがまさにアナログ信号を測定したデバイスで起こったことです。ADC割り込みはそのような「成功した」周波数で正確に生成されました。起こったことは次のとおりです。

• ADC周辺機器は次の測定を完了し、割り込みを生成します。
• ISR , , , - ;
• ISR , (.. , );
• ;
• , - . , .
• 2.

もちろん、これはADC割り込みが非常に頻繁に生成されることですが、システムの動作はまったく受け入れられません。正しい動作：このような頻繁な割り込みの生成が停止されるまで、スレッドは（一度に）制御を受信しなくなります。スタックは保存されたコンテキストの束で満たされるべきではなく、割り込みが頻繁に生成されなくなると、システムは静かに動作し続けます。

そしてもう1つの結果：そのような定期的な割り込みがない場合でも、アプリケーションに存在するさまざまな割り込みが不幸な瞬間に発生して、コンテキストが何度も保存される可能性がゼロではないままです。組み込みシステムは、多くの場合、時間（数年および数年）にわたる連続動作用に設計されています。たとえば、車のアラーム、オンボードコンピューターなどです。そして、デバイスの動作時間が無限になる傾向がある場合、そのようなイベントの発生の可能性は一致する傾向があります。遅かれ早かれ、これは起こっています。もちろん、これは受け入れられないので、物事の現在の状態を離れることはできません。

良い：少なくとも今は問題の原因を知っています。次の質問：この理由を排除する方法？

おそらく、最速かつ最もダーティなハックは、コンテキストの保存/復元中の割り込みを単に禁止することです。はい、これは問題を解決しますが、それは非常に非常に悪い解決策です：クリティカルセクションはできるだけ短くする必要があり、そのような長時間の割り込みを禁止することはほとんど良い考えではありません。

はるかに優れたソリューションは、割り込み用に別のスタックを使用することです。

TNKernelを改善しようとしています

Anders MontonenによるPIC32の下には別のTNKernelポートがあり、割り込み用に別のスタックを使用します。しかし、このポートには、Alex Borisovのポートにある便利な機能はありません。システム割り込みを宣言するための便利なSyshnyマクロ、システムティックを操作するためのサービスなどです。

そこで、私はそれをフォークし、必要なものを実装することにしました。もちろん、カーネルでこのような変更を行うためには、その仕組みを十分に理解する必要がありました。そして、TNKernelコードを勉強すればするほど、それが好きではなくなりました。TNKernelは、ひざまずいて書かれたプロジェクトの印象を与えます。重複したコードが多く、整合性がありません。

悪い実装例

ルール「1つの入口点、1つの出口点」の違反

カーネルのどこにでも見られる最も一般的な例は、次のようなコードです。

 int my_function(void) { tn_disable_interrupt(); //-- do something if (error()){ //-- do something tn_enable_interrupt(); return ERROR; } //-- do something tn_enable_interrupt(); return SUCCESS; } 

複数の演算子returnがあり、さらに戻る前に特定のアクションを実行する必要がある場合は、そのようなコードが問題の鍵になります。次のように書き換えることをお勧めします。

 int my_function(void) { int rc = SUCCESS; tn_disable_interrupt(); if (error()){ rc = ERROR; } else { //-- so something } tn_enable_interrupt(); return rc; } 

さて、戻る前に割り込みを許可する必要があることを覚えておく必要はありません。コンパイラに作業を任せてください。

あなたは結果のために遠くに行く必要はありません：現時点で最新のTNKernel 2.7からの機能はここにあります：

 int tn_sys_tslice_ticks(int priority,int value) { TN_INTSAVE_DATA TN_CHECK_NON_INT_CONTEXT tn_disable_interrupt(); if(priority <= 0 || priority >= TN_NUM_PRIORITY-1 || value < 0 || value > MAX_TIME_SLICE) return TERR_WRONG_PARAM; tn_tslice_ticks[priority] = value; tn_enable_interrupt(); return TERR_NO_ERR; } 

参照：間違ったパラメーターが関数に渡されると、関数は戻りTERR_WRONG_PARAM、割り込みは禁止されたままになります。1つのエントリポイント、1つの出口ポイントのルールに従えば、このエラーは発生しなかった可能性が高くなります。

DRY原則の違反

（繰り返してはいけません）
オリジナルのTNKernel 2.7コードには、大量のコードの重複が含まれています。多くの類似したことは、単純なコピーを通じて異なる場所で行われます。

いくつかの類似したサービス（たとえば、メッセージを送信するサービス：ストリームから、待機せずにストリームから、または割り込みから）がある場合、これらは3つの非常に類似した関数であり、1-2行が異なり、物事を一般化する試みはありません。

ストリーム状態の切り替えは非常に全体的に実装されています。たとえば、スレッドをRunnableからWaitに移動する必要がある場合、1つのフラグをクリアして別のフラグを設定するだけでは十分ではありません。スレッドが存在する開始キューからも削除する必要があります。待機、待機キューへのスレッドの追加（必要な場合）、タイムアウトの設定（必要な場合）など TNKernel 2.7には、このための一般的なメカニズムはありません。それぞれの場合に、コードはここに記述されています。

それまでの間、これらのことを実装する正しい方法は、状態ごとに3つの関数を記述することです。

• 指定された状態でストリームを入力します。
• セット状態からストリームを推定するには;
• ストリームが指定された状態にあるかどうかを確認します。

現在、ある状態から別の状態にストリームを転送する必要がある場合、通常は2つの関数を呼び出す必要があります。1つは古い状態からストリームを取り出し、もう1つは新しい状態に入る関数です。シンプルで信頼性の高い。

DRYルールの定期的な違反の結果として、何かを変更する必要がある場合、いくつかの場所でコードを編集する必要があります。言うまでもなく、これは悪質な行為です。

要するに、TNKernelにはさまざまな実装が必要なものが山ほどあります。

徹底的にリファクタリングすることにしました。何も壊さないようにするために、カーネルの単体テストの実装を開始しました。そしてすぐに、TNKernelがまったくテストされていないことが明らかになりました。カーネル自体に不快なバグがあります！

発見され修正されたバグに関する特定の情報については、TNKernelを再実装する理由。

会う：TNeo

ある時点で、私がやっていることが「リファクタリング」の範囲をはるかに超えていることが明らかになりました。実際、私はほとんどすべてを完全に書き直しました。さらに、TNKernel APIには長い間気になっていたことがいくつかあったので、APIを少し変更しました。また、見逃したことがあるので、それらを実装しました。タイマー、スタックのソフトウェア制御オーバーフロー、複数のキューからのメッセージを待機する機能などです。

名前についてはかなり前から考えていました。TNKernelとの直接接続を示したいが、新鮮でクールなものを追加したかったのです。したがって、最初の名前はTNeoKernelでした。

しかし、しばらくして、それ自体は簡潔なTNeoに縮小されました。

TNeoには、RTOS用の標準機能セットに加えて、どこにもない便利な機能があります。ほとんどの機能はオプションであるため、それらを無効にしてメモリを節約し、パフォーマンスをわずかに向上させることができます。

• タスク、またはスレッド：カーネルが一般的に書かれた最も基本的な機能。
• ミューテックス：共有リソースを保護するオブジェクト：
  
  • 再帰的ミューテックス：オプション、ミューテックスはネストされたロックを許可します
  • デッドロックの定義：デッドロックが発生した場合、カーネルは任意のコールバック関数を呼び出すことでこれを通知できます
  
  
• セマフォ：タスクを同期するためのオブジェクト
• 固定サイズのメモリブロック：シンプルで確定的なメモリマネージャ
• : , , , ;
  
  • : - : ,
  
  
• : FIFO ,
• : .
• : RAM
• : ,
• 動的ティック：システムに何の関係もない場合、システムティックの定期的な処理に気を取られない
• プロファイラー：各スレッドが実行されていた時間、最大実行時間、およびその他の情報を確認できます

プロジェクトはGitHub：TNeoでホストされています。

現在、カーネルは次のアーキテクチャに移植されています。

• ARM Cortex-Mコア：Cortex-M0 / M0 + / M1 / M3 / M4 / M4F（サポートされるツールチェーン：GCC、Keil RealView、clang、IAR）
• マイクロチップ：PIC32MX / PIC24 / dsPIC

完全なドキュメントは、htmlとpdfの2つのバージョンで入手できます。

• 最後の安定したTNeo：html、pdf
• 現在の開発TNeoベータ版：html、pdf
• 変更履歴

TNeoの実装

もちろん、1つの記事でカーネル全体の実装をカバーすることは非常に困難です。代わりに、自分にははっきりしていなかったことを思い出して、これらのことに集中しようとします。

しかし、まず第一に、1つの内部構造、リンクリストを考慮する必要があります。

関連リスト

リンクリストはよく知られたデータ構造であり、読者はおそらくそれをすでに知っているでしょう。ただし、完全を期すために、TNeoでのリンクリストの実装を見てみましょう。

リンクリストは、TNeoのあらゆる場所で使用されます。より具体的には、循環双方向リンクリストが使用されます。Cの構造は次のとおりです。

 /** * Circular doubly linked list item, for internal kernel usage. */ struct TN_ListItem { /// /// pointer to previous item struct TN_ListItem *prev; /// /// pointer to next item struct TN_ListItem *next; }; 

src / core / tn_list.cで宣言されています。

ご覧のとおり、構造には同じ構造のインスタンスへのポインタが含まれています。つまり、前の要素と次の要素です。このような構造のチェーンを編成して、次のように接続できます。



これはすばらしいことですが、あまり使い道がありません。各オブジェクトにいくつかの有用なデータが必要ですよね？

解決策はstruct TN_ListItem、インスタンスをバインドしたい別の構造に埋め込むことです。たとえば、次のような構造があるとしますMyBlock：

 struct MyBlock { int field1; int field2; int field3; }; 

そして、この構造のインスタンスのシーケンスを構築できるようにしたいと思います。まず第一に、私たちはstruct TN_ListItemそれをそれに組み込みます。

この例struct TN_ListItemでは、先頭に配置するのが論理的ですが、先頭だけでなく、どこにでも配置できるstruct MyBlockものを強調するstruct TN_ListItemために、中央に配置しましょう。

 struct MyBlock { int field1; int field2; //-- say, embed it here. struct TN_ListItem list_item; int field3; }; 

OK、そして今いくつかのインスタンスを作成します：

 //-- blocks to put in the list struct MyBlock block_first = { /* ... */ }; struct MyBlock block_second = { /* ... */ }; struct MyBlock block_third = { /* ... */ }; 

そして今、もう一つの重要なポイント：リスト自体を作成します。これは空でも空でもありません。これは同じ構造の単なるインスタンスですが、struct TN_ListItemどこにも埋め込まれていません。

 //-- list head struct TN_ListItem my_blocks; 

リストが空の場合、前の要素と次の要素へのポインタの両方が自分自身を指しますmy_blocks。

これで、リストを次のように整理できます。



次のようなコードを使用して作成できます。

 //-- ,         , // .     . my_blocks.next = &block_first.list_item; my_blocks.prev = &block_third.list_item; block_first.list_item.next = &block_second.list_item; block_first.list_item.prev = &my_blocks; block_second.list_item.next = &block_third.list_item; block_second.list_item.prev = &block_first.list_item; block_third.list_item.next = &my_blocks; block_third.list_item.prev = &block_second.list_item; 

これは素晴らしいことですが、上記のことから、まだでTN_ListItemはなく、のリストがあることがわかりMyBlockます。しかし、アイデアは、開始MyBlockから開始までのオフセットlist_itemがすべてのインスタンスで同じであるということですMyBlock。ですから、へのポインタがありTN_ListItem、このインスタンスが組み込まれていることがわかっている場合MyBlock、ポインタから特定のオフセットを減算し、へのポインタを取得できますMyBlock。

これには特別なマクロがあります：container_of()（src / core / internal / _tn_sys.hで定義されています）：

 #if !defined(container_of) /* given a pointer @ptr to the field @member embedded into type (usually * struct) @type, return pointer to the embedding instance of @type. */ #define container_of(ptr, type, member) \ ((type *)((char *)(ptr)-(char *)(&((type *)0)->member))) #endif 

のようにポインタを持っているためTN_ListItem、MyBlock次のように外部へのポインタを取得します。

 struct TN_ListItem *p_list_item = /* ... */; struct MyBlock *p_my_block = container_of(p_list_item, struct MyBlock, list_item); 

これで、たとえば、リスト内のすべての要素を走査できますmy_blocks。

 //-- loop cursor struct TN_ListItem *p_cur; //--      my_blocks for (p_cur = my_blocks.next; p_cur != &my_blocks; p_cur = p_cur->next) { struct MyBlock *p_cur_block = container_of(p_cur, struct MyBlock, list_item); //-- , p_cur_block     MyBlock } 

このコードは機能しますが、やや混乱し、リストの実装の詳細でオーバーロードされます。リストをクロールするための特別なマクロを用意することをお勧めします：src / core / internal / _tn_list.hファイルで_tn_list_for_each_entry()定義されます。

次に、すべての詳細を非表示にして、インスタンスのリストを次のMyBlockように移動できます。

 struct MyBlock *p_cur_block; _tn_list_for_each_entry( p_cur_block, struct MyBlock, &my_blocks, list_item ) { //-- , p_cur_block     MyBlock } 

結果として、これはオブジェクトのリストを作成する非常に便利な方法です。そして、もちろん、同じオブジェクトを複数のリストに含めることができます。このため、構造には複数の組み込みインスタンスが必要struct TN_ListItemです。このオブジェクトを含める予定のリストごとに。

---

Hacker Newsの元の記事（英語）へのリンクを公開した後、読者の1人が質問しました。リンクリストstruct TN_ListItemは他の構造に埋め込むことで実装されるのはなぜですか。

 struct TN_ListItem { TN_ListItem *prev; TN_ListItem *next; void *data; //--      } 

この質問は興味深いので、記事自体に回答を含めることにしました

。TNeoはヒープからメモリを割り当てません。ポインタが特定のカーネルサービスにパラメータとして渡されるオブジェクトでのみ機能します。実際、これは非常に優れています。多くの場合、組み込みシステムは束をまったく使用しません。彼女の行動は十分に決定されていません。

したがって、たとえば、タスクがミューテックスを予期するようになると、このタスクはこの特定のミューテックスを待機しているタスクのリストに追加され、この操作の複雑さはO（1）です。常に一定の（そして、ちなみに小さな）時間で実行されます。

アプローチcを使用する場合void *data;、2つのオプションがあります。

• - , - struct TN_ListItem ( , , - );
• struct TN_ListItem ( ) , .

. , , Linux (. «Linux Kernel Development» by Robert Love). helper- ( ) Linux, : , GCC- , typeof() , .. TNeo GCC.

, TNeo :

• : (, )
• , ( )
• , ,
• 等

()

タスク、またはスレッドはシステムの最も重要な部分です。結局のところ、これはまさにRTOSが一般的に存在するものです。比較的単純なマイクロコントローラー向けのTNeoおよびその他のRTOSのコンテキストでは、タスクは、（あたかも）他のタスクと並行して実行されるサブルーチンです。

一般的に、スレッドという用語を好みますが、TNKernelではタスクという用語を使用しているため、TNeoではタスクという用語も使用して互換性を維持しています。この記事では、両方の用語を同じ意味で使用します。

システム内の既存の各タスクにはstruct TN_Task、src / core / tn_tasks.hファイルで宣言された独自の記述子があります。これはかなり大きな構造です。

タスク記述子の最初の要素は、タスクスタックの最上部へのポインターです。stack_cur_pt。この事実は、アセンブラコンテキストスイッチングルーチンで積極的に使用されています。タスクハンドルへのポインタがあれば、単純にリダイレクトすることができ、結果の値はタスクスタックの最上部を指します。かなり快適です。

現在および次のタスク

カーネルには2つのポインターがあります。現在実行中のタスクと、次に開始されるタスクです。

中のsrc /コア/内部/ _tn_sys.h：

 /// task that is running now extern struct TN_Task *_tn_curr_run_task; /// task that should run as soon as possible (if it isn't equal to /// _tn_curr_run_task, context switch is needed) extern struct TN_Task *_tn_next_task_to_run; 

コメントからわかるように、それらが異なる記述子を指している場合は、コンテキストをできるだけ早く切り替える必要があります。

タスクの優先順位と起動キュー

タスクには異なる優先順位があります。使用可能な優先順位の最大数は、プロセッサワードの次元によって決まります。16ビットマイクロコントローラーでは16の優先順位があり、32ビットの優先順位では32です。これが理由で明らかになるので、一般的に言えば、私はアプリケーションにこれ以上必要としません。 5つまたは6つの優先順位よりも。

優先度ごとに、この優先度を持つ実行可能タスクのリンクリストがあります。

中のsrc /コア/内部/ _tn_sys.h：

 /// list of all ready to run (TN_TASK_STATE_RUNNABLE) tasks extern struct TN_ListItem _tn_tasks_ready_list[TN_PRIORITIES_CNT]; 

TN_PRIORITIES_CNTユーザー設定可能な値はどこにありますか（もちろん、最大値を超えることはできません）。

タスク記述子には、struct TN_ListItem次のタスクリストのいずれかに追加されるインスタンスがあります。

 /** * Task */ struct TN_Task { /* ... */ /// queue is used to include task in ready/wait lists struct TN_ListItem task_queue; /* ... */ } 

カーネルには、各ビットが1つの優先度に対応するビットマスク（1ワードサイズ）もあります。ビットが設定されている場合、これは、対応する優先度を持つタスクを開始する準備がシステムにあることを意味します。

 /// bitmask of priorities with runnable tasks. /// lowest priority bit (1 << (TN_PRIORITIES_CNT - 1)) should always be set, /// since this priority is used by idle task which should be always runnable, /// by design. extern volatile unsigned int _tn_ready_to_run_bmp; 

そのため、カーネルはどのタスクを転送する必要があるかを判断する必要がある場合、アーキテクチャを実行します-の特定のfind-first-set命令を実行し_tn_ready_to_run_bmp、すぐに開始する準備ができたすべてのタスクから最高の優先度を取得します 次に、対応する優先度のタスクリストから最初のタスクを取得し、それに制御を移します。

もちろん、タスクがRunnable状態（実行準備完了）に出入りする場合、対応するビットを提供しますが_tn_ready_to_run_bmp、これは非常に簡単です。一般的に、すべてが高速です。

タスクコンテキスト

タスクが現在実行されていない場合、そのコンテキスト（すべてのレジスタの値と、タスクを続行するプログラムメモリ内のアドレス）がスタックに格納されることを思い出してください。またstack_cur_ptr、タスク記述子では、この保存されたコンテキストの最上部を正確に指します。

カーネルがサポートする各アーキテクチャ（MIPS、ARM Cortex-Mなど）には、特定のコンテスト構造があります。これらのすべてのレジスタがスタック上にどのように配置されているか。タスクが作成され、開始の準備が完了すると、スタックの先頭に「初期化」コンテキストが入力されるため、タスクが最終的に制御を取得すると、この初期化コンテキストが復元されます。したがって、各タスクは分離されたクリーンな環境で実行されます。

タスク状態

タスクは、次のいずれかの状態になります。

• 実行可能：タスクを実行する準備ができています（これは、タスクが現在実際に実行されていることを意味するものではありません）
• 待機：タスクは何か（キュー、ミューテックス、セマフォなどからのメッセージ）を待っています
• 一時停止：タスクは別のタスクによって一時停止されました
• 待機+中断：タスクは待機状態にあり、その後、別のタスクによって中断されました
• 休止状態：タスクは作成後にまだアクティブになっていないか、呼び出しによって破棄されていますtn_task_terminate。次回タスクがアクティブ化されると、以前の状態はゼロにリセットされ、クリーンな環境で起動されます。

タスクが状態を離れるか、逆にその状態に入ると、実行する必要がある特定のアクションセットがあります。 例：

• Dormant, , ,
• Runnable, _tn_ready_to_run_bmp ,
• Runnable, , - _tn_ready_to_run_bmp , ,
• Wait, ( ), ,
• タスクが待機状態を終了すると、待機キューからタスクを削除し（そのようなキューにある場合）、タイマーをリセットします（設定されている場合）
• 等

実際、たとえば、タスクがRunnable状態を離れるとき、タスクが新しい状態になるのを心配する必要はありません。一時停止？休眠？問題ではありません。どの場合でも、常に起動キューから削除して、残りの必要なアクションを実行する必要があります。

これを実装する簡単で信頼性の高い方法は、状態ごとに3つの関数を記述することです。

• 特定の状態でタスクを入力します。
• 指定された状態からタスクを取り出します。
• タスクが指定された状態にあるかどうかを確認します。

したがって、src / core / tn_tasks.cファイルには次の関数があります。

 void _tn_task_set_runnable(struct TN_Task * task) { /* ... */ } void _tn_task_clear_runnable(struct TN_Task * task) { /* ... */ } void _tn_task_set_waiting( struct TN_Task *task, struct TN_ListItem *wait_que, enum TN_WaitReason wait_reason, TN_TickCnt timeout ) { /* ... */ } void _tn_task_clear_waiting(struct TN_Task *task, enum TN_RCode wait_rc) { /* ... */ } //-- etc. 

また、ある状態から別の状態にタスクを転送する必要がある場合、通常は次のように要約されます。

  _tn_task_clear_dormant(task); _tn_task_set_runnable(task); 

そして、すべての内政が解決されることを確信できます。かっこいい？

タスク作成

タスクが完了する必要があるものが1つあります。スタック用のスペースです。そのため、タスクを作成する前に、このタスクのスタックとして使用される配列を割り当て、この配列を残りのものとともにに渡す必要がありtn_task_create()ます。

カーネルは、タスクスタックの先頭をこの配列の先頭（またはアーキテクチャに応じて末尾）に設定し、タスクを休眠状態にします。現時点では、彼女はまだ打ち上げの準備ができていません。ユーザーが呼び出すとtn_task_activate()（またはフラグTN_TASK_CREATE_OPT_STARTが渡された場合tn_task_create()）、カーネルは次のように動作します。

• 休止状態からタスクを削除します。すでにご存じのとおり、この時点でタスクスタックはクリーンコンテキストで初期化されます。
• タスクを実行可能状態にします。すでにご存じのとおり、この時点で、タスクは対応する実行キューの最後に配置されます。

これで、スケジューラがこのタスクを処理し、必要に応じて実行します。

タスクの開始方法を見てみましょう。

タスク起動

もちろん、タスクを実行するために必要な手順の正確なシーケンスは、アーキテクチャによって異なります。ただし、一般的な考え方として、カーネルは次のように機能します。

• 指し示すタスクハンドルからスタックポインターを取得_tn_next_task_to_runし、現在のスタックポインターとして設定します。
• 実行する _tn_curr_run_task = _tn_next_task_to_run; ;
• スタックからすべてのレジスタの値を次々にロードします（スタックポインタがタスクスタックの最上部に設定されたことを思い出してください）。とりわけ、アドレスはプログラムメモリにもロードされ、タスクを再開する必要があります。
• 制御をタスクに転送します。

カーネルがタスクに制御をどのように正確に転送するかは、すでにアーキテクチャに完全に依存しています。たとえば、MIPSでは、プログラムカウンタータスクをEPCレジスタ（例外プログラムカウンター）に保存し、命令を実行するeret（例外から戻る）必要があります。つまり、コアはプロセッサを「だまし」、「通常の」割り込みから戻ってきたかのように動作します。実行後eret、現在のPC（プログラムカウンター）はEPCに保存されている値に設定され、実際、タスクは実行を継続します。

コンテキストスイッチ

カーネルが現在のタスクの実行を一時停止し、次のタスクに制御を移すプロセスは、「コンテキストスイッチング」と呼ばれます。この手順は、常に最低の優先度を持つ特別なISRで実行されます。そのため、コンテキストを切り替える必要がある場合、カーネルは対応する割り込みビットを設定します。ユーザータスクが現在実行されている場合、コンテキストを切り替えるISRは、そこでプロセッサによって呼び出されます。このビットが（割り込みの優先順位に関係なく）他のISRから設定されている場合、コンテキスト切り替えは後で開始されます：現在実行中のすべてのISRが制御を返します。

もちろん、コンテキストの切り替えに使用される特定の割り込みは、アーキテクチャによって異なります。例えば、ARM上のCortex-M上のOSのコンテキストスイッチのために提供される特別な例外があるPIC32コアソフトウェア割り込み0を使用しますPendSV。

カーネルISRスイッチングコンテキストが呼び出されると、次のことを行います。

• すべてのレジスタの値を現在のタスクのスタックに1つずつ保存します。とりわけ、アドレスはタスクが中断されたプログラムメモリに保存されます。
• すべてのレジスタがスタックに保存されると、カーネルは現在のスタックポインターを現在のタスクのハンドルに保存します。
• おそらく、オンコンテキストスイッチハンドラーを実行します（これらの機能のいずれかが有効になっている場合、プロファイラーおよびスタックオーバーフローをプログラムで制御するために必要です）。
• 次に、前のセクション「タスクの起動」で示したシーケンスに進みます。

コンテキストの切り替えは、現在のタスクよりも優先度の高いタスクが実行可能になると発生します。または、現在のタスクが待機状態になったとき。

たとえば、優先度の低い送信機と優先度の高い受信機の2つのタスクがあるとします。受信者はキューからメッセージを取得しようとするため、キューが空の場合、タスクは待機状態になります。実行できなくなったため、カーネルは優先度の低いTransmitterタスクに移行します。



図からわかるように、低優先度のTransmitterタスクがserviceを呼び出してメッセージを送信するとtn_queue_send()、このタスクは高優先度のReceiverを優先してカーネルによってプッシュされます。そのため、tn_queue_send()送信機に戻るまでに、多くのことが起こりました。

• コンテキストはReceiverに切り替わります。
• 受信者はメッセージを受信して​​処理します。
• 受信者は次のメッセージの受信を試み、待機状態に入ります。
• コンテキストは送信機に戻ります。

したがって、システムの応答性は非常に高くなります。タスクに適切な優先度を設定すると、イベントは非常に迅速に処理されます。

タスクアイドル

TNeoには1つの特別なタスクがあります：アイドル。最も低い優先度を持ち（ユーザータスクにそれほど低い優先度を設定することはできません）、常に実行する準備ができている必要があります。したがって、_tn_ready_to_run_bmp常に少なくとも1つのビットが設定されます。明らかに、実行する準備ができている他のタスクがない場合、カーネルはこのタスクに制御を渡します。

アプリケーションは、アイドルタスクから継続的に呼び出されるコールバック関数を実装できます。これは、さまざまな便利な目的に使用できます。

• MCUスリープ。システムに何の関係もない場合、消費電力を削減するために、プロセッサをスリープに切り替えるのが理にかなっています。もちろん、アプリケーションはプロセッサがスリープを終了するための条件を設定する必要があります。ほとんどの場合、これは何らかの割り込みです。
• システム負荷の計算。最も単純な実装：無限ループで変数の値をインクリメントするだけです。値の変化が速いほど、システムの負荷は小さくなります。

なぜなら アイドルタスクは常に開始する準備ができている必要があります。タスクを待機状態にすることができるこのコールバックからカーネルサービスを呼び出すことは禁止されています。

タイマー

カーネルには時間の概念が必要です。静的ティックと動的ティックの 2つのスキームを使用できます。

静的ティック

静的ティックは、タイムアウトを実装する最も簡単な方法です。定期的な間隔で割り込みを生成するハードウェアタイマーが必要です。この記事では、このようなタイマーをシステムタイマーと呼びます。このタイマーの期間はユーザー定義です（私は常に1 msを使用しましたが、もちろん、任意の期間を設定できます）。このタイマーのISRでは、特別なカーネルサービスを呼び出すだけです。

 //-- example for PIC32, hardware timer 5 interrupt: tn_p32_soft_isr(_TIMER_5_VECTOR) { INTClearFlag(INT_T5); tn_tick_int_processing(); } 

tn_tick_int_processing()呼び出されるたびに、システムティックが発生したと言います。この関数内で、カーネルは、何らかのタイマーのコールバックを呼び出す時間であるかどうかを確認し、そうである場合は呼び出します。

タイマーの最も単純な実装は次のようになります。すべてのアクティブタイマーのリンクリストがあり、システムティックごとにタイマーのリスト全体を調べ、各タイマーに対して次のアクションを実行します。

• タイムアウト値を1減らします。
• 新しい値がゼロの場合、このタイマーをリストから削除し（つまり、タイマーを非アクティブにし）、タイマーコールバックを開始します。

このアプローチには重大な欠点があります。

• コールバックからタイマーを管理することはできません。たとえば、新しいタイマーを追加すると、タイマーのリストが変更されます。 しかし、以来 , ;
• : .

おそらく、最後のポイントは組み込みシステムではそれほど重要ではありません。誰もがこのような多数のタイマーを必要とすることはまずありません。ただし、最初のポイントは非常に重要です。タイマーコールバックからタイマーを追加（または再構成）できるようにしたいのです。

したがって、TNeoはより巧妙なアプローチを取ります。基本的な考え方はLinuxカーネルから取られていますが、（1）組み込みシステムはLinuxが記述されているマシンよりもリソースが大幅に少ないため、（2）TNeoはLinuxのスケーリングと同様にスケーリングする必要がありません。Linuxデバイスドライバー、第3版のLinuxタイマーについて読むことができます。

• 時間、遅延、および遅延作業
  
  • カーネルタイマー
    
    • カーネルタイマーの実装
      

この本は、リンクhttp://lwn.net/Kernel/LDD3/ で誰でも利用できます

。そのため、TNeoでのタイマーの実装に目を向けます。

Nのカスタム値があり、これは2のべき乗でなければなりません。通常の値は4、8、または16です。リストの配列（いわゆるティックリスト）があり、この配列はN個の要素で構成されています。つまり、N個のティックリストがあります。

システムの数が1から（N-1）になった後にタイマーが切れると、このタイマーはこれらのティックリストの1つに追加されます。ティックリスト番号は、適切なマスクをタイムアウトにオーバーレイするだけで計算されます（これが、Nが2のべき乗でなければならない理由です）。タイマーが後で期限切れになると、「ジェネリック」リストに追加されます。

もちろん、マスクはNに対応します。たとえば、N = 4の場合、マスクが使用されます0b0011; N = 8の場合、マスクが使用されます0b0111。

N番目のシステムティックごとに、カーネルは「共通」リストのすべてのタイマーを通過し、各タイマーに対して次のアクションを実行します。

• タイムアウトはN減少します。
• 結果のタイムアウトがNより小さい場合、タイマーは対応するティックリストに移動します。

そして、システムティックごとに、対応する1つのティックリストを調べ、このリストからすべてのタイマーを無条件にコールバックします。このソリューションは、上記で説明した最も単純なものよりも効率的です。タイマーのリスト全体をNティックで1回だけ通過する必要があり、残りの場合は、リストが既に準備されているすべてのタイマーを無条件で「シュート」します。

気配りのある読者は疑問に思うかもしれません。実際にN個のリストがあるのに、なぜ（N-1）ティックリストのみを使用するのでしょうか。これは、タイマーコールバックからタイマーを変更できるようにしたいだけだからです。 N個のリストを使用し、タイムアウトがNに等しいタイマーをユーザーが追加すると、現在実行中のリストに新しいタイマーが追加されます。これはできません。

（N-1）リストを使用する場合、現在渡されているティックリストに新しいタイマーを追加できないことを保証します（ちなみに、このリストからタイマーを削除できますが、これにより問題は発生しません） 。

このタイマーの実装は多くのアプリケーションで十分に受け入れられますが、時には理想的ではありません：デバイスがほとんど何もしないでほとんどの時間を費やしている場合、MCUは定期的に起動してシステムティックを処理する必要がありますそして、眠りに戻ります。このために、動的ティックが実装されました。

動的ティック

基本的な考え方は、無駄な呼び出しを取り除くことですtn_tick_int_processing()。カーネルが100システムティックを介してタスクを起動する必要がある場合、システムティックのtn_tick_int_processing()100周期後に正確に呼び出す必要があります（もちろん、外部非同期イベントが発生してこれを変更する可能性があります）。

これを行うには、カーネルがアプリケーションとチャットできる必要があります。

• tn_tick_int_processing()Nティックを介して次の呼び出しをスケジュールするには、
• 時間を尋ねる（つまり、現在のシステムのティック数を取得する）。

したがって、動的ティックモードがアクティブ（TN_DYNAMIC_TICK1に設定）の場合、アプリケーションはシステム起動時にこれらのコールバックへのポインターを提供する必要があります。もちろん、これらのコールバックの実際の実装は、MCUのタイプに完全に依存します（同じアーキテクチャでも、異なる周辺機器などを持つ膨大な数のMCUがあります）。したがって、これらのコールバックの正しい実装はアプリケーションにあります。

システムを起動

正常に機能するには、カーネルに次のものが必要です。

• アイドルタスクスタック用のスペース。
• 割り込みスタック用のスペース。
• アイドルタスクのコールバック。
• ある種のユーザータスク。

そのため、システムを起動する前に、アプリケーションはIdleタスクスタックと割り込みに配列を割り当て、Idleタスクコールバック（空の場合もある）を提供し、少なくとも1つ（通常は1つ）のユーザータスクを作成する必要がある特別なコールバックを提供する必要があります。これは起動される最初のタスクであり、私のアプリケーションでは通常、task_initまたはを呼び出しますtask_conf。明らかに、アプリケーションを初期化しています。アプリケーションする必要があります。

main()

• を呼び出してシステム割り込みを無効にしますtn_arch_int_dis()。
• マイクロコントローラーの主要な初期化を実行します。少なくとも、発振器の設定。
• システムタイマーの割り込みを構成します（ISRの呼び出し元tn_tick_int_processing()）。
• を呼び出してtn_sys_start()、すべての必要な情報を提供します：スタックの配列へのポインター、そのサイズ、およびコールバック関数。

カーネルは次のことを行います。

• 起動キュー（リストの配列_tn_tasks_ready_list）およびカーネルの内部状態の他の側面を初期化します。
• アイドルタスクを作成してアクティブにします（その後_tn_next_task_to_run、アイドルタスクハンドルをポイントします）。
• 最初のユーザー定義タスクが作成およびアクティブ化されるユーザー定義関数を呼び出します（その後_tn_next_task_to_run、最高優先度のユーザー定義タスクへのハンドルを指します）。
• _tn_arch_sys_start()コンテキストを切り替えるための割り込みを開始し、記述子が指すタスクへの最初のコンテキスト切り替えを実行するアーキテクチャ依存の関数を呼び出し_tn_next_task_to_runます。

その後、システムは通常どおり動作します。ユーザータスクが制御を取り、ユーザータスクが実行できるすべての操作を実行できます。通常、彼女は次のことを行います。

• ボード上のさまざまな周辺機器（LCDディスプレイ、フラッシュドライブなど）を初期化します。
• アプリケーションで使用されるソフトウェアモジュールを初期化します。
• 他のすべてのユーザータスクを作成します（すべてが既に初期化されているため、作業を開始できます）。

実装の詳細

さて、私はある時点でやめるべきだと思います。率直に言って、この記事では実装のすべての詳細を説明することはできません。

全体像を理解するために必要な最も興味深いトピックに触れようとしました。他のトピックについては、読者はソースコードを簡単に調べることができます。私はそれを本当に良く理解できるようにしようとしました。ソースが利用可能です：それらを使用してください！

ご質問がある場合は、コメントでお尋ねください。

単体テスト

通常、ユニットテストについて話すときは、ホストマシンで実行されるテストを意味します。しかし、残念ながら、組み込みシステムに使用されるコンパイラには多くの場合エラーが含まれているため、ハードウェアで直接カーネルをテストすることにしました。したがって、カーネルがデバイス上で100％動作していることを確認できます。

テストの実装の簡単な概要：

優先度の高いタスク「テストディレクター」があり、「作業」タスクとさまざまなRTOSオブジェクト（メッセージキュー、ミューテックスなど）を作成し、作業タスクに何をするかを指示します。例：

• タスクA、ミューテックスM1をブロックします
• タスクB、ミューテックスM1をブロックします
• タスクC、ミューテックスM1をブロックします
• タスクA、ミューテックスM1を削除します

各ステップの後、テストディレクターはワーカーが作業を行うのを待ち、すべてが計画どおりに進行していることを確認します。タスクのステータス、優先度、カーネルサービスから最後に返された値、オブジェクトのさまざまなプロパティなどを確認します。

詳細ログがUARTに表示されます。通常、各ステップの後に、次が表示されます。

• リテラルコメント。
• テストディレクターは、彼がしていることを書きます。
• 各作業タスクは、実行内容を書き込みます。
• テストディレクターはすべてをチェックし、レポートを作成します。

表示されるログの例を次に示します。

 //-- A locks M1 (line 404 in ../source/appl/appl_tntest/appl_tntest_mutex.c) [I]: tnt_item_proceed():2101: ----- Command to task A: lock mutex M1 (0xa0004c40) [I]: tnt_item_proceed():2160: Wait 80 ticks [I]: [Task A]: locking mutex (0xa0004c40).. [I]: [Task A]: mutex (0xa0004c40) locked [I]: [Task A]: waiting for command.. [I]: tnt_item_proceed():2178: Checking: [I]: * Task A: priority=6 (as expected), wait_reason=DQUE_WRECEIVE (as expected), last_retval=TN_RC_OK (as expected) [I]: * Task B: priority=5 (as expected), wait_reason=DQUE_WRECEIVE (as expected), last_retval=NOT-YET-RECEIVED (as expected) [I]: * Task C: priority=4 (as expected), wait_reason=DQUE_WRECEIVE (as expected), last_retval=NOT-YET-RECEIVED (as expected) [I]: * Mutex M1: holder=A (as expected), lock_cnt=1 (as expected), exists=yes (as expected) //-- B tries to lock M1 -> B blocks, A has priority of B (line 413 in ../source/appl/appl_tntest/appl_tntest_mutex.c) [I]: tnt_item_proceed():2101: ----- Command to task B: lock mutex M1 (0xa0004c40) [I]: tnt_item_proceed():2160: Wait 80 ticks [I]: [Task B]: locking mutex (0xa0004c40).. [I]: tnt_item_proceed():2178: Checking: [I]: * Task A: priority=5 (as expected), wait_reason=DQUE_WRECEIVE (as expected), last_retval=TN_RC_OK (as expected) [I]: * Task B: priority=5 (as expected), wait_reason=MUTEX_I (as expected), last_retval=NOT-YET-RECEIVED (as expected) [I]: * Task C: priority=4 (as expected), wait_reason=DQUE_WRECEIVE (as expected), last_retval=NOT-YET-RECEIVED (as expected) [I]: * Mutex M1: holder=A (as expected), lock_cnt=1 (as expected), exists=yes (as expected) //-- C tries to lock M1 -> B blocks, A has priority of C (line 422 in ../source/appl/appl_tntest/appl_tntest_mutex.c) [I]: tnt_item_proceed():2101: ----- Command to task C: lock mutex M1 (0xa0004c40) [I]: tnt_item_proceed():2160: Wait 80 ticks [I]: [Task C]: locking mutex (0xa0004c40).. [I]: tnt_item_proceed():2178: Checking: [I]: * Task A: priority=4 (as expected), wait_reason=DQUE_WRECEIVE (as expected), last_retval=TN_RC_OK (as expected) [I]: * Task B: priority=5 (as expected), wait_reason=MUTEX_I (as expected), last_retval=NOT-YET-RECEIVED (as expected) [I]: * Task C: priority=4 (as expected), wait_reason=MUTEX_I (as expected), last_retval=NOT-YET-RECEIVED (as expected) [I]: * Mutex M1: holder=A (as expected), lock_cnt=1 (as expected), exists=yes (as expected) //-- A deleted M1 -> B and C become runnable and have retval TN_RC_DELETED, A has its base priority (line 431 in ../source/appl/appl_tntest/appl_tntest_mutex.c) [I]: tnt_item_proceed():2101: ----- Command to task A: delete mutex M1 (0xa0004c40) [I]: tnt_item_proceed():2160: Wait 80 ticks [I]: [Task A]: deleting mutex (0xa0004c40).. [I]: [Task C]: mutex (0xa0004c40) locking failed with err=-8 [I]: [Task C]: waiting for command.. [I]: [Task B]: mutex (0xa0004c40) locking failed with err=-8 [I]: [Task B]: waiting for command.. [I]: [Task A]: mutex (0xa0004c40) deleted [I]: [Task A]: waiting for command.. [I]: tnt_item_proceed():2178: Checking: [I]: * Task A: priority=6 (as expected), wait_reason=DQUE_WRECEIVE (as expected), last_retval=TN_RC_OK (as expected) [I]: * Task B: priority=5 (as expected), wait_reason=DQUE_WRECEIVE (as expected), last_retval=TN_RC_DELETED (as expected) [I]: * Task C: priority=4 (as expected), wait_reason=DQUE_WRECEIVE (as expected), last_retval=TN_RC_DELETED (as expected) [I]: * Mutex M1: holder=NONE (as expected), lock_cnt=0 (as expected), exists=no (as expected) 

何かがうまくいかない場合、それは「期待どおり」ではなく、エラーと詳細です。

一時停止したタスク、リモートタスク、削除されたオブジェクトなどの状況を含む、1つのサブシステム（ミューテックス、キューなど）のフレームワーク内で起こりうるすべての状況をシミュレートしようとしました。これはカーネルを本当に安定に保つのに大いに役立ちます。

最後の言葉

FreeRTOSを使用しないのはなぜですか？

さて、いくつかの理由があります。

まず、私は彼らのライセンスが好きではありません。ライセンスの下では、FreeRTOSは他の製品と比較することを禁じられています！FreeRTOSライセンスの最後の段落をご覧ください。

FreeRTOS may not be used for any competitive or comparative purpose, including the publication of any form of run time or compile time metric, without the express permission of Real Time Engineers Ltd. (this is the norm within the industry and is intended to ensure information accuracy).

私が知る限り、彼らはMicrochipフォーラムでの非常に古い議論の後にこの条件を追加しました。人々はいくつかのコアを比較するグラフを投稿し、これらのグラフはFreeRTOSを支持しませんでした。 FreeRTOSの著者は、測定値が間違っていたと述べましたが、奇妙なことに、「正しい」測定値を提供できませんでした。

だから、何らかの形でFreeRTOSを残すカーネルを書いたとしても、それについて書くことはできません。私は何かを理解していないかもしれませんが、私の意見では、ある種のナンセンスです。私はこれらのものが好きではありません。

ところで、数年前、同僚がTNKernelを推奨したとき、彼らはTNKernelがFreeRTOSよりもずっと速いと言っていました。好奇心からTNeoを実装した後、もちろんいくつかの比較を行いましたが、残念ながら、FreeRTOSライセンスのためにそれらを公開することはできません。

第二に、ソースコードも好きではありません。たぶん私は理想主義的すぎるかもしれませんが、私にとってリアルタイムの核心はある程度特別なプロジェクトであり、可能な限り理想に近いものにしたいのです。

はい、GitHubでTNeoコードをチェックして、なぜそれが悪いのかを説明するときです。おそらくこれは、カーネルをさらに改善するのに役立つでしょう！

第三に、多かれ少なかれ既成のTNKernelの代替品が欲しかった既存のアプリケーションを新しいカーネルに簡単に移植できるようにします。記事の最初の部分で説明したマイクロチップマイクロコントローラー用のTNKernelの問題を考慮すると、デバイスには常に未定義の動作の可能性がありました。

そして最後になりましたが、コアでの作業は非常にエキサイティングな体験です！

それにもかかわらず、FreeRTOSには（おそらく）他のすべての類似製品に勝る否定できない利点があります：それは膨大な数のアーキテクチャに移植されています。幸いなことに、私はそれほど必要ありません。

TNeoはどこで使用されますか？

, TNeo , TNKernel: , , .. .

Microchip MASTERS 2014, StarLine Cortex-M. , .

TNeo — 16- 32- .

GitHub: TNeo .

, :

• ARM Cortex-M cores: Cortex-M0/M0+/M1/M3/M4/M4F (supported toolchains: GCC, Keil RealView, clang, IAR)
• Microchip: PIC32MX/PIC24/dsPIC

: html pdf.

• TNeo: html , pdf
• development TNeo BETA: html , pdf
• Changelog

---

: How I ended up writing new real-time kernel . .. — , , , «» .