STM32およびFreeRTOS。 2.黒のセマフォ

パート1、ストリームについて



実際には、いくつかのイベントが異なる周期で発生することがよくあります（またはまったく発生しないこともあります）。 たとえば、マクドナルドでジュースを注文する、ユーザーがボタンを押す、またはチケット売り場でスキーを注文する、などです。 そして、当社の強力なマイクロコントローラーは、これらすべてを処理する必要があります。 しかし、最も便利な方法は？







MacDuckでジュースを注文するプロセスを観察しましょう。 買い手は「ジュースが欲しい」と言い、1人の売り手は小切手の価値を破り、もう1人は画面を見てジュースを注ぎに行きます。 彼はそれを注ぎ、持ってきて、再びスクリーンを見て、持っていく必要があるものを探しました。 そして、それは無限に続くか、シフトの終わりまで続きます。 人間の労働を機械労働に置き換えているので、これを自動化します！



前の記事を読んだ後、普通のプログラマーは喜んで座って、このコードのようなものを書きます。

bool sok=false; void thread1(void) { for(;;) if(user_want_juice()) sok=true; } void thread2(void) { for(;;) if(sok) {prinesi_sok(); sok=false; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ロジックは明確だと思います。1つのスレッドが状況を制御し、ジュースを持ち込む必要があるときにフラグを設定します。 そして、他はこのフラグを制御し、必要に応じてジュースをもたらします。 問題はどこにありますか？



最初の問題は、ジュースの持ち主が常に「ジュースを持参する必要がありますか」と尋ねることです。 これは売り手を悩ませ、組み込みデバイスのプログラマーの最初のルールに違反します。「機能に何の関係もない場合は、スケジューラに制御を渡します」。 osDelay（1）を貼り付けて、他のタスクが機能するようにするか、優先度を下げてスピンさせるようにします。鉄片が耐えられるからです。 過熱、リソース不足などなど...これらは大きなコンピューターではありません-場合によっては、ボード全体が最小のコンピュータークーラーよりも小さいことがあります。



そして、2番目の問題はさらに深く埋もれています。 コンパイラ、最適化、およびマルチスレッドについてです。 次に例を示します。ジューストレイは非常に高速であるため、一度に3人の売り手にサービスを提供できます。 その結果、プロセスが相互にシフトされると、古典的な「人種」が簡単に判明する可能性があります。



Seller1（以降P1）「ジュースが必要です！」Sok = true;

Sokonosets（さらにC）（目を覚ます）「ああ！ ジュースが必要です」

P2「ジュースも必要」sok = true;

P3「私も！」Sok = true;

C（絞り汁）、P1-あなたのジュース。 sok = false;



悲しみのP2とP3。





プログラマーは、論理フラグの代わりにカウンターを考え、考え、思いつきます。 何が起こったように見えます。



P1 "Soku！" Sok ++;

C「待機」

P2「ソク！」ソク++

P3「ジュースも2つあります！」Sok ++; sok ++;

C-P1「ジュース用！」Sok--;

C（sok> 0？）「ああ、まだ必要です！」

-2を「ホールド」します-;

C「その他」

S-P3「ようこそ」ソック-;

C-そしてもう一度降ります

C-P3 "pzhlsta" sok--;

C「ああ、誰もジュースをもう必要としません。私は寝ます」





コードは美しく機能し、理解可能であり、原則としてエラーはないはずです。 プログラマーはタスクを閉じて、次へ進みます。 最終的に、プロジェクトの次のビルドの前に、リソースの不足が始まり、誰かがunningな（または賢い）最適化をオンにするか、コントローラーをマルチコアに変更します。 そして、すべて：上記のタスクは期待どおりに動作しなくなります。 さらに、最もうんざりすることもありますが、期待どおりに動作することもあり、99％の場合、デバッガーでは一般に完全に動作します。 プログラマーは泣き、泣き、「変数を静的または揮発性として宣言する」などのシャーマニズムのアドバイスに従うようになります。



そして、実際には何が起こるのでしょうか？ お金を持たせてください。



苗木がsok--操作を実行するとき。 実際には、次のことが起こります。



1. sok値を一時変数に入れます

2.一時変数の値を1減らす

3.一時変数の値をsokに書き込みます



そして今、私たちはマルチスレッド（そしておそらくマルチコア）システムを持っていることを思い出します。 スレッドは実際に並行して実行できます。 したがって、実際には、デバッガーの下ではなく、次のことが起こります（または売り手と果汁持ち手が同時に同じ変数に変わりました）



C.値sokを一時変数に入れます

P. sokの値を一時変数2に取り込みます。

C.一時変数の値を1減らす

P.一時変数2の値を1増やします。

P.一時変数2の値をsokに書き込みます

C.一時変数の値をsokに書き込む





その結果、sokには期待とまったく同じ値がありません。 この事実を発見したプログラマーは、自分で鹿をかぶったセーターを引き裂き、「私はそれについて読んだ、どうすれば忘れられます！」などと叫び、この変数へのマルチスレッドアクセスを禁止するラッパーで変数を操作するためのコードをラップします。 通常、人々はタスクの切り替えやミューテックスのような他の同様のものを禁止します。 最適化を開始します-すべて正常に動作します。 しかし、ここにプロジェクトアーキテクト（またはstudiovsemoeのチーフテクニー、つまり私）が来て、プログラマーに有利なスタートを与えます。なぜなら、そのような禁止事項などはすべて、パフォーマンスに大きく影響し、期間に関連するほとんどすべてを狂わせるからです。



あなたはたくさんのコードを書き直さなければならず、プログラマーの最初のルールに違反しないようにさえするので、状況はほとんど絶望的であるように思えます...しかし、私は通常、突然親切になり、あなたが今読んでいるものを伝えます。



適切なOSにはセマフォがあります。 FreeRTOSには、「バイナリ」と「カウント可能」の2つのタイプのセマフォがあります。 すべての違いは、カウンタが1の場合、バイナリはカウントの特殊なケースであるということです。さらに、バイナリは高速システムで使用するのは非常に危険です。



通常の変数に対するセマフォの利点は何ですか？



まず、このセマフォの状態が変わるまで、タスクスケジューラにスレッドにリソースを割り当てないように依頼できます。 つまり、ジュースの持ち主は「ジュースが必要ですか？」と売り手を脅かすことはなくなりますが、誰かがジュースを必要とするまで奥の部屋のどこかで眠ります。



次に、タスクスケジューラは必要なすべてのチェックを実行して、セマフォとその値の整合性を維持します。 つまり、異なる速度でジュースを運ぶ1人の売り手に複数のサポナーを立ち上げることが可能であり、互いに絡み合い、必要以上のジュースを持ち込むことはありません。



高速システムとバイナリセマフォの問題は何ですか？ 原則として、状況は逆さまになったジュース生産者に関する最初の例に完全に類似しています。



McDuckのコントローラーがブレーキをかけられた男（以降K）を奪ったと想像してください。 そのタスクは簡単です-注文されたジュースの量を計算します。



P1-S「ジュース！」

K-「ああ、彼らはジュースを注文しました、私たちは小さなものを描く必要があります！」

P2-S「ジュース！」

P3-S「ソク！」

（この間、Kは舌を突き出して団結します）

K-それで、私たちは小さなものを描きました。次の注文を待っています。





ご存知のように、一日の終わりのデータはまったく収束しません。 それが、スタジオでクラスとしてバイナリセマフォを使用することを禁じられている理由です-コントローラーの速度は常に異なります（速度の違いは、最低周波数でSTM32L1 / MSP430であり、最大でSTM32F4は2桁以上であり、コードは同じように動作します）。そのようなエラーをキャッチすることは非常に困難です。



セマフォのカウントはどのように機能しますか？ たとえば、同じマクダック、サンドイッチを作る部門（または、一言で言えば大きなマックを持つハンバーガーの名前は何ですか？）を考えてみましょう。 一方で、ビッグマックを販売する売り手がたくさんいます。 ビッグマックは、一度に1つずつ、2つまたは10つずつ販売されます。 一般的に、あなたは推測しません。 一方、ビッグメーカーがいます。 彼は一人、若くて経験の浅い人、または熟達した素早い人かもしれません。 または一度に。 売り手はそれを気にしません-ビッグマックが必要で、とにかく誰がそれをします。 その結果：



P1「1 bigmakが必要」（セマフォを1kuに置く）

D1「わかりました、私は1つのbimakをできます。 （若い、近くになって、0でセマフォを削除します）

P2「3つのbigmakが必要です」（セマフォを3つ増やします）

D2「OK、もう1つビッグマックをすることができます」（待機の次の行。セマフォの2）

（ここにD1があります）

D1「bigmacを使いました。もう1つできます」（セマフォ1）

D2「わかりました。私はやったことがあります。もう1つやります。」 セマフォ0

（戻ってくる、彼は速い）

D2「もっとビッグマキが必要ですか？」 10ティック待ちます。そうでない場合は、立ち去ります」

D1「すべて完了。 目を覚ます、他にどのようにそれが必要になるのか」（スケジューラはスレッドを遅くします）

D2「何をしない？ よく私は去った。 Ntsikの目盛りを確認します ''





その結果、1人でビッグマクを作成できるか、10人で作成できます。違いは、単位時間あたりに生成されるビッグマクの数のみです。 さて、bigmakiとmcdonaldsについては十分です。これらすべてをコードで実装する必要があります。 この場合も、前の例のボードとコードを使用します。 異なる速度で異なる点滅をする8つのLEDがあります。 そこで、「myrg」を「sandwich」と同じものにします。 ボードにはカスタムボタンがあるため、1回のクリックで1つの「サンドイッチ」が必要になるように作成します。 また、ボタンを押したままにすると、1秒あたり5つの「サンドイッチ」が必要になります。



「グローバル」コードのどこかにセマフォを作成します。

 xSemaphoreHandle BigMac;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

StartThreadスレッドのコードで、セマフォを初期化します

 BigMac = xSemaphoreCreateCounting( 100, 0 );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、最大100個のbigmakを注文できます。



そして、無限ループのコードを次のコードに変更します

 if(HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_0)==GPIO_PIN_SET) { xSemaphoreGive(BigMac); } osDelay(200);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、ボタン（およびボード上のPA0を対象とする）が押された場合、200ミリ秒ごとに1つのセマフォを発行し、bigmaxを要求します。



そして、各コードの点滅LEDに追加

 xSemaphoreTake( BigMac, portMAX_DELAY); HAL_GPIO_WritePin(GPIOE,GPIO_PIN_15,GPIO_PIN_RESET); ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、BigMacセマフォが理解できるまで待機しています（portMAX_DELAY）。 任意の数のティックを設定するか、portTICK_PERIOD_MSマクロを使用して待機するミリ秒数を設定できます。



注意！ コードでは、可読性を高めるためのチェックを導入していません。



コンパイルして実行します。 ボタンを長く押すほど、LEDが点滅します。 手放す-停止します。 しかし、1つは、最速（およびキュー内で最長）が点滅しないことです。彼は単に「注文」を受け取りません。 OK、各サンドイッチの速度を50msに上げます。 これで、全員に十分な注文があり、全員が点滅しています。 ボタンを放します-しばらくの間、彼らはフラッシュを続け、収集された注文を行います。 それは非常に良いことです。私は最大6万個のbigmakを注文することができ（符号なしの長さまで可能）、注文期間は10ミリ秒に設定されました。



これですべてが非常に美しくなりました-クリックするとLEDが点滅します。 ボタンを長押しするほど、リリース後のLEDの点滅が長くなります。 実生活との完全な類推。



実生活との類推を続けるために、我々は常にマクダックにサンドイッチのコレクターがいることを思い出します。 つまり、売り手は向きを変えずに「サンドイッチが必要」と振ると、誰かが作ることができます。 しかし、正午の普通の食堂の場合はどうでしょうか？ レジ係は少なくとも自分自身をファンにすることができます-彼女以外の誰もが次のシリーズを見ているので、誰も見ることができません。 レジ係は、営業時間外にさまよい、「タティアナ・ヴァシリエヴナ、出て行ってください、ここにスープを注いでください」のようなことを叫びたいと思っている訪問者を理解する必要があります。



このような対象の場合、セマフォは意味をなしません。 FreeRTOSの古いバージョンでは、APIを介してタスクを起動するだけで（「そこにスープが必要」）、新しいバージョンではvTaskNotifyが呼び出されました（違いは渡されたパラメーター「borschクラスのスープが必要です」にあります）。 通常のものと比較して、生産性の大幅な向上を約束しますが、現時点では大規模なテストを実施していません。



セマフォには別のサブタイプ-ミューテックスがありますが、これらは同じバイナリセマフォです。 そして、再帰ミューテックスはセマフォをカウントしています。 それらはまったく同じ方法で作成され、まったく同じ方法で動作します。それらの「作成可能」状態は、通常のもののように「ゼロより大きく」なく、「ゼロのみ」です。 リソースと変数の共有に使用されます。 私たち自身でアプリケーションの例を考え出すことを提案します（ここでは、何らかの理由で、誰もがトイレと鍵についての話を思いつきます。「社説の旗」や「会社の印章」はありませんでした。



コードの結果は、言葉で説明するよりもビデオに表示する方が簡単です







この段階で、人々はすでに記述されたコードでのセマフォの適用可能性について議論し始め、通常、FreeRTOSがイベントフラグ/ビット/グループを呼び出すようになります。 このテーマに関する簡単なグーグルズの後、プログラマーは満足して落ち着いて発散します:)



いつものように、投稿からの更新を含む完全なコードはここkaloshin.ru/stm32/freertos/stage2.rarにあります。



次の部分、キューについて