STM32およびFreeRTOS。 1.ストリームを使用したエンターテイメント

この一連の5つの記事は、通常の「tinek」とarduinokの機会が少ない人向けに設計されていますが、より強力なコントローラーに切り替える試みはすべて失敗したか、可能な限り喜びをもたらさなかった。 私たちのスタジオプログラマーの「教育プログラム」で次のすべてが何度も話されています（「tinek」から「stmki」に切り替えると、何をつかむのか分からず、st迷に陥る可能性が非常に多くなることをしばしば認めています）。すべてになります。 読んでいるとき、読者は好奇心が強い人であり、Keil、STM32Cubeを見つけて配置し、OKボタンを押すことができたことがわかります。 練習には、STM32F3DISCOVERY評価ボードを使用します。これは安価で、強力なプロセッサと多数のLEDを備えているためです。



各記事は、自宅、家族、またはリラクゼーションのために、1時間近くのどこかで「繰り返し」と「反省」のために設計されています...











多くの場合（ほとんどの場合、ほとんどの場合）、マイクロコントローラーは一度に複数のパラメーターをモニターする必要がある状況で使用されます。 またはその逆に、複数のデバイスを同時に管理します。



例のための問題はここにあります：異なる休止の異なる期間のパルスを出力する必要がある4つの出力があります。 持っているのは、ミリ秒単位でカウントするシステムタイマーです。



「arduinoで自分自身を拷問する」という精神でタスクを複雑にします。 タイマーは別のタイマーでビジーであり、PWMはすべてのレッグで機能しないため、適切ではありません。通常、希望のモードに駆動することはできません。 少し考えた後、座ってこのコードのようなものを書きます

//  int time1on=500; // ,   1    int time1off=250; // ,   1    unsigned int now=millis(); .... // -   if(millis()<now+time1on) { port1=ON; } else { port1=OFF; if(millis()>now+time1on+time1off) { now=millis(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、4つすべてのポートでそのようなことをします。 いくつかの画面で適切なフットクロスが表示されますが、このフットクロスは非常に迅速に機能し、動作します。これはマイクロコントローラーにとって重要です。



その後、プログラマーは、ポートの状態が変化しなくても、各サイクル中にポートがぴくぴく動くことに突然気付きます。 フットクロス全体が支配します。 次に、同じニーズを持つポートの数が2倍になります。 プログラマーは、すべてを吐き出し、タイプをPortBlink（int port num）の単一の関数に書き換えます。



幸福はほとんど来ましたが、突然、いくつかのポートで、「終了」コントロールと一緒に何かを事前に読み取り、この読み取りに基づいてポートを制御する必要がありました。 プログラマーは再び誓い、特にポートに対して別の機能を実行します。



幸せ？ しかし、気にしないで。 顧客が何かを接続すると、数秒でプロセスが簡単に遅くなる可能性があります...うめき声が始まり、プログラマーが再びコードを修正し、最終的に読み取り不可能なゴミに変え、マネージャーが機能を追加するために顧客にワイルド価格をロールアウトし、顧客は二度と混乱しないことを誓います統合ソリューション。



（広告や賞賛など）そしてなぜですか？ 当初、プラットフォームに関して間違った決定が行われたためです。 可能であれば、原始的なタスクでも洗練されたプラットフォームを提供します。 経験から、開発とサポートのコストははるかに低くなります。 次に、8番目の出力を制御するために、72MHzで動作可能なSTM32F3を使用します。 （ささやき声）実際、私は彼とのデモ支払いを手元に置いています（メール）。 L1はまだ使用されていましたが、プロジェクトの1つで誤って使用していました。



STM32Cubeを開き、ボードを選択し、FreeRTOSの横のチェックボックスをオンにして、通常どおりプロジェクトを組み立てます。 そのようなものは必要ないので、デフォルトですべてを残します。



FreeRTOSとは何ですか？ これは、マイクロコントローラー用のほぼリアルタイムのオペレーティングシステムです。 つまり、マルチタスク、セマフォ、その他のミューテックスなどのオペレーティングシステムについて聞いたことがあるすべてです。 FreeRTOSを選ぶ理由 STM32Cubeをサポートしているだけです;-)。 他の同様のシステムがたくさんあります-同じChibiOSです。 本質的に、それらはすべて同じであり、チームとその形式が異なるだけです。 ここでは、オペレーティングシステムの操作に関する本や指示の山を書き直すつもりはありません。プログラマーの大変な仕事に非常に役立つ最も興味深いことの広いストロークを実行するだけです。



さて、私は彼らがインターネットでそれを読み、インスピレーションを得たと考えます。 何が変わったかを見る



main.cの先頭のどこかに

 static void StartThread(void const * argument);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべての初期化の後

 /* Create Start thread */ osThreadDef(USER_Thread, StartThread, osPriorityNormal, 0, configMINIMAL_STACK_SIZE); osThreadCreate (osThread(USER_Thread), NULL); /* Start scheduler */ osKernelStart(NULL, NULL);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、1つの無限ループとosDelay（1）を持つ空のStartThread。



びっくりした？ 一方、あなたが使用する機能のほぼ90％になる前に。 最初の2行は通常の優先度でスレッドを作成し、最後の行はタスクスケジューラを起動します。 そして、このすべての素晴らしさは6キロバイトのフラッシュに収まります。



しかし、作業を確認する必要があります。 osDelayを次のコードに変更します

 HAL_GPIO_WritePin(GPIOE,GPIO_PIN_8,GPIO_PIN_RESET); osDelay(500); HAL_GPIO_WritePin(GPIOE,GPIO_PIN_8,GPIO_PIN_SET); osDelay(500);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイルして塗りつぶします。 すべてが正しく完了すると、青色のLEDが点滅します（PE8-PE15のSTM32F3Discoveryに多数のLEDがはんだ付けされているため、別のボードがある場合はコードを変更します）



次に、各LEDの機能を取得して複製します。

 static void PE8Thread(void const * argument); static void PE9Thread(void const * argument); static void PE10Thread(void const * argument); static void PE11Thread(void const * argument); static void PE12Thread(void const * argument); static void PE13Thread(void const * argument); static void PE14Thread(void const * argument); static void PE15Thread(void const * argument);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各LEDにストリームを追加します

 osThreadDef(PE8_Thread, PE8Thread, osPriorityNormal, 0, configMINIMAL_STACK_SIZE); osThreadCreate (osThread(PE8_Thread), NULL);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてコードを動かしてLEDを点灯させます

 static void PE8Thread(void const * argument) { for(;;) { HAL_GPIO_WritePin(GPIOE,GPIO_PIN_8,GPIO_PIN_RESET); osDelay(500); HAL_GPIO_WritePin(GPIOE,GPIO_PIN_8,GPIO_PIN_SET); osDelay(500); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般的に、すべてが同じです。



コンパイルし、記入し、図を取得します。 完了。 LEDは点滅しません。



commentメソッドによるひどいデバッグにより、3つのスレッドが動作しており、4つのスレッドはもう動作していないことがわかります。 問題は何ですか？ 問題は、シェルダとスタックに割り当てられたメモリにあります。



FreeRTOSConfig.hを確認します

 #define configMINIMAL_STACK_SIZE ((unsigned short)128) #define configTOTAL_HEAP_SIZE ((size_t)3000)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてに3000バイト、各タスクには128バイトがあります。 さらに、他のどこかに、タスクに関する情報やその他の有用な情報を保存する必要があります。 そのため、何もしないと、十分なメモリがない場合でもスケジューラは起動しません。



事実から判断すると、完全な最適化を有効にすると、FreeRTOS自体は250バイトかかります。 さらに、タスクごとに、スタック用に128バイト、内部リスト用に64バイト、タスク名用に16バイト。 250 + 3 *（128 + 64 + 16）= 874を考慮します。 キロバイトでも届かない。 そして、我々は3を持っています...



問題は何ですか？ STM32Cubeで提供されるFreeRTOSのバージョンは古すぎて（7.6.0）vTaskInfoを取得できないため、私は脇に行きます：



ストリームを作成する前後に、以下を設定します（freは通常のsize_tです）

 fre=xPortGetFreeHeapSize();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブレークポイントに固定して、次の数字を取得します。タスクを作成する前に2376バイト、1768後に空きバイトがありました。つまり、1つのタスクに608バイトが費やされています。 もう一度確認してください。 番号2992-2376-1768-1160を取得します。 番号は同じです。 単純な論理的結論により、ファックスからのこれらの番号は、最適化がオンになり、すべての種類のモジュールがオフになった、一部のデッドプロセッサに対して取得されることがわかります。 さらに調べて、シェドラーの開始が約580バイトを消費することを理解します。



一般に、最小スタックを使用してタスクごとに610バイト、OS自体にさらに580バイトを計算します。 TOTAL_HEAP_SIZEの合計は、610 * 9 + 580 = 6070と記述する必要があります。 丸めて6100バイトを与えます-食べさせます。



すべてのLEDが一度に点滅する様子を編集、記入、観察します。 スタックを6050に削減しようとしていますが、やはり何も機能しません。 だから私たちは正しく計算しました:)



これで、各LEDに「インパルス」と「一時停止」の独自の間隔を設定できます。 原則として、FreeRTOSを更新するか、コードを想起させる場合、0.01msの精度を与えるのは簡単です（デフォルトでは、1ティックは1msです）。



同意して、8つのタスクを単独で処理することは、同時に8つのタスクを処理するよりもはるかに快適ですか？ 実際には、プロジェクトでは通常30〜40スレッドでスピンします。 プログラマーが何人死ぬか、すべての処理を1つの関数にプッシュすると、計算するのが怖くなります:)



次のステップは、優先順位に対処する必要があります。 実際の場合と同様に、一部のタスクは他のタスクよりも「同等」であり、より多くのリソースが必要です。 まず、1つのフラッシャーをフラッシャーに交換しますが、OSの手段ではなく単純なサイクルで一時停止が行われると、間違って行われます。



つまり、osDelay（）の代わりに、このような恐怖がここに挿入されます。

 unsigned long c; for(int i=0;i<1000000;i++) { c++; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常、サイクル数は実験的に選択されます（そのような遅延が複数ある場合は、計算に多くの頭痛が伴うため）。 麻酔は、コマンドの実行時間を計算できます。



置換、コンパイル、実行。 LEDは以前と同様に点滅しますが、どういうわけか動きが遅くなります。 オシロスコープで見ると、滑らかな境界（燃やす50ミリ秒と燃やさない50ミリ秒）の代わりに、境界が1〜2ミリ秒浮かび始めたことがわかります（奇妙なことに、目には見えます）。 なんで？ FreeRTOSはリアルタイムシステムではないため、このような自由を確保できます。



ここで、このタスクの優先度をosPriorityAboveNormalに1ステップ上げます。 実行して、孤独に点滅するLEDを確認します。 なんで？



スケジューラがタスクに優先順位を付けるためです。 彼は何を見ていますか？ その優先度の高いタスクには、常にプロセッサが必要です。 結果は何ですか？ 他のタスクには作業時間がありません。



そして、優先度を通常からosPriorityBelowNormalに1ステップ下げます。 その結果、通常のタスクに作業を割り当てたスケジューラーは、残りのリソースを「不良」にします。



ここから、プログラマの最初のルールを簡単に推測できます。関数に何の関係もない場合は、スケジューラに制御を渡します。



FreeRTOSには2つの「待機」オプションがあります



最初のオプションは「Nティックだけ待つ」です。 フリルのない通常のポーズ：彼らがどれだけ待っているか、どれだけ待っているか。 これはvTaskDelayです（osDelayは単なる同義語です）。 実行時を見ると、次のようなものがあります（便利なタスクが完了するまでに24ミリ秒かかると仮定します）。



... [0ms]-コントロール転送-操作[24ms] 100msで一時停止[124ms]-コントロール転送-操作[148ms] 100ms [248ms]で一時停止...



動作に必要な時間のため、最初に想定したように、100msごとにコントロール転送が発生しないことは簡単にわかります。 そのような場合には、vTaskDelayUntilがあります。 これにより、タイムラインは次のようになります



... [0ms]-コントロール転送-操作[24ms] 76ms [100ms]で一時停止-コントロール転送-操作[124ms] 76ms [200ms]で一時停止...



ご覧のとおり、タスクは明確に定義された時間間隔で制御を受け取ります。 スレッドの1つでスケジューラの精度を確認するために、1ミリ秒間停止するように要求しました。 図では、9つのスレッドでの作業の精度を評価できます（StartThreadを忘れないでください）







人々は優先順位を付けてゲームに没頭し、「いつ壊れるのか」を把握しているので、私は通常ここで終わります。



すべてのソースコードを含む完全に組み立てられたプロジェクトは、 kaloshin.ru / stm32 / freertos / stage1.rarで取得できます。



続き2.セマフォについて