スタックの取り扱い

ＲＯＭの状況は次の通りです。 ＬＰＣ１７６９のメモリマップは、ＲＡＭが０ｘ１０００００００～０ｘ１０００８０００、ＲＯＭが０ｘ００００００００～０ｘ０００８００００。 リンカスクリプトが＿ｖＳｔａｃｋＴｏｐをＲＡＭの最終アドレス（０ｘ１０００８０００）で定義。 Ｃソース上でベクタテーブルの第１エントリに＿ｖＳｔａｃｋＴｏｐを設定。 リンカがベクタテーブルを０ｘ００００００００に配置。 そしてリセットされるとＬＰＣ１７６９はメインスタックポインタにＲＯＭ先頭の４バイトを入れ、メインスタックポインタが０ｘ１０００８０００になります。

アイドルタスクを生成します。 ＳＶＣ　０を実行、ＳＶＣ例外が発生、ハンドラモードで処理を開始します。 2014.08.20 タスクスケジューラーを起動した所には制御が戻りません。 起動時点のメインスタックに積んだ内容は不要なので、メインスタックポインタをＲＡＭの最終アドレスに戻します。 この補足を書いて気付いたけど、スタックのデータをタスクが参照するような処理があれば、 例外がメインスタックを使うので最初に積んだ内容が破壊されてしまいます。

ｖＴａｓｋＣｒｅａｔｅで指定したスタック確保量（４バイトを１とする単位）をヒープから確保してタスクに割り当てます。 ヒープの確保処理はＦｒｅｅＲＴＯＳに添付のｈｅａｐ１／ｈｅａｐ２／ｈｅａｐ３から１つ選択してビルドに追加します。 私のプロジェクトではｈｅａｐ２を使っています。

例外はハンドラモードでメインスタックを使います。 ＬＰＣ１７６９は例外処理の前に、タスク走行中であればプロセススタックに、例外走行中であればメインスタックに、ｒ０～ｒ３、ｒ１２、ｒ１４、ｒ１５、ｘＰＳＲの８レジスタをプッシュします。 私のプロジェクトではＦｒｅｅＲＴＯＳが使うＳｙｓＴｉｃｋとＰｅｎｄＳＶは優先度３１、アプリケーションの例外は優先度３０です。 ＳｙｓＴｉｃｋとＰｅｎｄＳＶに対してアプリケーションが横取り（例外処理中に別の例外を処理）します。 でもアプリケーション側同士は優先度が３０で統一されていて横取りしません。 例外処理は普通のＣ関数です。 ｒ４～ｒ１１を破壊する予定があれば入口でメインスタックにプッシュして走行します。

契機はＳｙｓＴｉｃｋ例外、またはｖＴａｓｋＤｅｌａｙといったＡＰＩ呼び出しです。 ＳｙｓＴｉｃｋ例外の場合、確かデフォルトは１０ｍｓ間隔でヘッダファイルで変更できたハズです。 ＡＰＩ呼び出しで固有の操作はありません。 両者とも最後はプログラムからＰｅｎｄＳＶ例外を発行し保留されます。ＰｅｎｄＳＶの優先度はＳｙｓＴｉｃｋと同じ３１なので横取りしません。 ＳｙｓＴｉｃｋ例外終了後、テールチェインでＰｅｎｄＳＶ例外が始まります。 テールチェインは、例外終了処理後に例外開始処理をするのが事前に判明した際は両者を相殺して省略する動作です。 ここではＳｙｓＴｉｃｋ例外の終了処理～ＰｅｎｄＳＶ例外開始処理が相殺されるテールチェインが発生します。 そしてＰｅｎｄＳＶ例外処理が始まります。 ＦｒｅｅＲＴＯＳは、直前まで走行中だったタスクのプロセススタックにｒ４～ｒ１１の８レジスタをプッシュ、走行中のＴＣＢにｐｓｐ（プロセススタックポインタ）を保存します。 メインスタックにｒ３、ｒ１４をプッシュ、ｂａｓｅｐｒｉをｃｏｎｆｉｇＭＡＸ＿ＳＹＳＣＡＬＬ＿ＩＮＴＥＲＲＵＰＴ＿ＰＲＩＯＲＩＴＹに設定します。 これはヘッダファイルで５と定義してあります。 この設定により例外優先度が５以上の低優先度な例外は禁止されます。 私のプロジェクトは自分用の例外は３０、ＦｒｅｅＲＴＯＳが使うＰｅｎｄＳＶとＳｙｓＴｉｅｃｋは３１で、例外全面禁止になります。 ｖＴａｓｋＳｗｉｔｃｈＣｏｎｔｅｘｔが次に走行するタスクを選択して切り替えます。 この後は、これまでやって来た事を復旧するように処理が進みます。 でもタスクに関しては、切替後のタスクを復旧しますから別のタスクが走行する訳です。

文章ではサッパリ分からないと思い、図解してみましたがやっぱり分かりません（泣）。

いやあ、ＬＰＣＸＰｒｅｓｓｏ（ＬＰＣ１７６９版）を始めてから、スタックを調べようと思い、幾年月、ようやくその全貌を把握できました、多分（汗）。
ＬＰＣ１７６９、ＦｒｅｅＲＴＯＳ含めて、全部鉄ゲタですよ、もう。＜本人の理解力不足とも言う。