僕は今でも、ある晩、僕のTM4C123GH6PMのLEDを眺めながら、決して来なかった単純な「ハートバット」の瞬間を待っていたことを覚えています。僕は、SysTickをセットアップし、PendSVを待機し、トレードコントロールブロック(TCB)を初期化しました。しかし、静かな瞬間の代わりに、LEDは一度振動し、そして凍りついた――私を嘲笑しました。あの瞬間は、小さなRTOSの構築が本当に意味するものを結晶させた:ハードウェアクルクと戦い、困難なバグを追いかけ、すべてをスムーズに走らせるのに十分なコードをパッチしました。この記事では、ARM Cortex-M4に最小限 ちょっとしたバックストーリー 約1年前、私の組み込まれたシステムクラスは、TM4C123GH6PM(ARM Cortex-M4)で単純なRTOSをゼロから構築することを任命しました。以前はFreeRTOSを使用していましたが、舞台の裏で何が起きているかを完全に理解したことはありませんでした。 Why? 
 
 
 
 CPUがどのように一つのトレードから別のトレードに切り替わるかを正確に見たかった。 私は、なぜ低優先度のタスクが、より高い優先度のタスクを意外に飢えさせることができるのかを学ぶ必要がありました(こんにちは、優先度の逆転)。 私は真のデバッグストーリーを欲しがっていた - 例えば、私はPendSVがなぜ実行されなかったのか疑問に半日を費やした(SysTickと同じ優先順位を与えていたことが判明しました)。 スパイラー:私のRTOSは完璧ではなかったが、その欠点を追いかけながら、私はどの教科書よりもARMインターナルのことをもっと学んだ。 「Cortex-M4 World」 コードの一行を書く前に、私はCortex-M4が中断とコンテキストの切り替えをどのように処理するかを頭に巻き込む必要がありました。 
 
 
 
 
 
 PendSV’s “Gentle” Role 
 
 
 PendSV is designed to be the lowest-priority exception—meaning it only runs after all other interrupts finish. My first mistake was setting PendSV’s priority to 0 (highest). Of course, it never ran because every other interrupt always preempted it. Once I moved it to 0xFF, scheduling finally kicked in. Note to self (and you): write down your NVIC priorities on a Post-it. It’s easy to confuse “0 is highest” with “0 is lowest.” 
 
 SysTick as the Heartbeat 
 
 
 I aimed for a 1 ms tick. On a 16 MHz clock, that meant  . LOAD = 16 000 – 1 I initially tried to do all scheduling decisions inside the SysTick ISR, but that got messy. Instead, I now just decrement sleep counters there and set the PendSV pending bit. Let the “real” context switch happen in PendSV. 
 
 Exception Stack Frame 
 
 
 When any exception fires, hardware auto-pushes R0–R3, R12, LR, PC, and xPSR. That means my “fake” initial stack for each thread must match this exact layout—else, on the very first run, the CPU will attempt to pop garbage and crash. I once forgot to set the Thumb bit ( ) in xPSR. The result was an immediate hard fault. Lesson: that Thumb flag is non-negotiable. 0x01000000 トレードコントロールブロック(TCB) 私のRTOSの各トレードには、以下が含まれています。 typedef enum { READY, RUNNING, BLOCKED, SLEEPING } state_t;

typedef struct {
    uint32_t *stack_ptr;   // Saved PSP for context switches
    uint8_t   priority;    // 0 = highest, larger = lower priority
    state_t   state;       // READY, RUNNING, BLOCKED, or SLEEPING
    uint32_t  sleep_ticks; // How many SysTick ticks remain, if sleeping
} tcb_t;
 実践では、私は宣言しました: #define MAX_THREADS 9
#define STACK_WORDS 256

uint32_t    thread_stacks[MAX_THREADS][STACK_WORDS];
tcb_t       tcbs[MAX_THREADS];
uint8_t     thread_count = 0;
int         current_thread = -1;
 Stack-Overflow ホラーストーリー 最初に割り当てたとき , すべてがうまく見えた - いくつかの組み込まれた機能の呼び出しをした私の「労働者」の糸が、メモリを腐敗させ始めるまで。 スタートアップして、どれだけ書かれたかを調べてみると、最適化されたビルドフラッグでは128語が足りないことがわかりました。 STACK_WORDS = 128 0xDEADBEEF 新しい糸を引く トレードを作成するということは、そのスタックをカットし、例外入力時に起こるハードウェアのスタッキングをシミュレートすることを意味しました。 void rtos_create_thread(void (*fn)(void), uint8_t prio) {
    int id = thread_count++;
    tcb_t *t = &tcbs[id];
    uint32_t *stk = &thread_stacks[id][STACK_WORDS - 1];

    // Simulate hardware stacking (xPSR, PC, LR, R12, R3, R2, R1, R0)
    *(--stk) = 0x01000000;            // xPSR: Thumb bit set
    *(--stk) = (uint32_t)fn;          // PC → thread entry point
    *(--stk) = 0xFFFFFFFD;            // LR → return with PSP in Thread mode
    *(--stk) = 0x12121212;            // R12 (just a marker)
    *(--stk) = 0x03030303;            // R3
    *(--stk) = 0x02020202;            // R2
    *(--stk) = 0x01010101;            // R1
    *(--stk) = 0x00000000;            // R0

    // Save space for R4–R11 (popped by the context switch)
    for (int r = 4; r <= 11; r++) {
        *(--stk) = 0x0; // or use a pattern if you want to measure usage
    }

    t->stack_ptr   = stk;
    t->priority    = prio;
    t->state       = READY;
    t->sleep_ticks = 0;
}
 Pitfalls To Watch For トップページ 
 
 
 
 xPSR で thumb bit. 欠けると、CPU がコードを ARM 指示として解釈しようとします。 Magic 0xFFFFFFFD. This tells the CPU, “On exception return, use PSP and go to Thread mode.” I recall looking up the ARM ARM (Architecture Reference Manual) at least three times to get this right. これがCPUに「例外に戻って、PSPを使用してトレードモードに移行する」と言います。 Stack Order. Pushing R4–R11 manually must follow the exact order the handler expects. A simple typpo (e.g., pushing R11 first instead of R4) throws off the entire frame. R4–R11を手動で押すと、トレーダーが期待する正確な順序に従う必要があります。 タイム・パス:SysTick Handler 以下は私の最後のSysTick ISR、基本的なものに切り替えました: void SysTick_Handler(void) {
    for (int i = 0; i < thread_count; i++) {
        if (tcbs[i].state == SLEEPING) {
            if (--tcbs[i].sleep_ticks == 0) {
                tcbs[i].state = READY;
            }
        }
    }
    SCB->ICSR |= SCB_ICSR_PENDSVSET_Msk; // Pend PendSV for scheduling
}
 いくつかのノート: 
 
 
 初期のバージョンでは、SysTickの内側にrtos_schedule()を呼び出そうとしました. それは間違えと混乱を招いた。 I found that if SysTick_IRQn and PendSV_IRQn share the same priority, PendSV sometimes never runs. Always give PendSV the absolute lowest numeric priority (i.e., NVIC_SetPriority(PendSV_IRQn, 0xFF)), and keep SysTick slightly higher (e.g., 2 or 3). ビッグスイッチ:PendSV Handler PendSV がようやく起動すると、実際のコンテキスト スイッチを実行します. My implementation in GCC inline assembly (ARM syntax) looks like this: __attribute__((naked)) void PendSV_Handler(void) {
    __asm volatile(
        "MRS   R0, PSP                \n" // Get current PSP
        "STMDB R0!, {R4-R11}          \n" // Push R4–R11 onto stack
        "LDR   R1, =current_thread    \n"
        "LDR   R2, [R1]               \n"
        "STR   R0, [R2, #0]           \n" // Save updated PSP into TCB

        "BL    rtos_schedule          \n" // Decide next thread

        "LDR   R1, =current_thread    \n"
        "LDR   R2, [R1]               \n"
        "LDR   R0, [R2, #0]           \n" // Load next thread’s PSP
        "LDMIA R0!, {R4-R11}          \n" // Pop R4–R11 from its stack
        "MSR   PSP, R0                \n" // Update PSP to new thread
        "BX    LR                     \n" // Exit exception, restore R0–R3, R12, LR, PC, xPSR
    );
}
 How I Tracked Down That Pesky 32-Byte オフセット 最初は、私の「保存 / 復元」コードが 32 バイトでオフでした 症状? トレードが実行され、間違った場所で生活に戻る - ガルブレードされた指示、ランダムなジャンプ。 ) 正確に何バイトが押されたかを測定するために 私のデバッガーでは、私は次に数値のPSP値と比較しました 確かに、偶然使いましたが、 代わりに 追加記録を1つ押すと、追加押した記録を削除して修正しました。 STMDB tcbs[].stack_ptr STMDB R0!, {R4-R11, R12} {R4-R11} 次ページへ 次の投稿: Scheduler Logic 私のスケジュールは意図的に単純です. It scans all TCBs to find the highest-priority READY thread, with a tiny round-robin tweak for threads of equal priority: すべてのTCBsをスキャンして、最優先順位のREADY threadを見つけることができます。 void rtos_schedule(void) {
    int next = -1;
    uint8_t best_prio = 0xFF;

    for (int i = 0; i < thread_count; i++) {
        if (tcbs[i].state == READY) {
            if (tcbs[i].priority < best_prio) {
                best_prio = tcbs[i].priority;
                next = i;
            } else if (tcbs[i].priority == best_prio) {
                // Simple round-robin: if i is after current, pick it
                if (i > current_thread) {
                    next = i;
                    break;
                }
            }
        }
    }
    if (next < 0) {
        // No READY threads—fall back to idle thread (ID 0)
        next = 0;
    }
    current_thread = next;
}
 What I Learned Here: 
 
 
 二つのトレードが優先順位1を共有するが、私は常に下のIDを選択する場合、もう一つはCPU時間を決して得ることはありません。 idle thread (ID 0) は特別なケースで、常にREADY、常に最下位優先度(priority = 255)なので、他の何も実行できない場合は、単にスピンします(または __WFI() を呼び出して電力を節約します)。 Kernel Primitives: Yield, Sleep, and Semaphores シングル 基本をトレードした後、次のステップはトレードを適切に相互作用させることでした。 出稼ぎ void rtos_yield(void) {
    SCB->ICSR |= SCB_ICSR_PENDSVSET_Msk;
}
 スプリング好き 長いループの終わりに、他のトレードが公平なショットを得るように。 いくつかのタスクがCPUを特定の優先設定下でハグしたことを意味した。 rtos_yield() yield() 眠り void rtos_sleep(uint32_t ticks) {
    tcb_t *self = &tcbs[current_thread];
    self->sleep_ticks = ticks;
    self->state       = SLEEPING;
    rtos_yield();
}
 「LED blinking thread calls」 半秒ごとに瞬くのを見ていると、SysTickとPendSVが正しい仕事をしていることがわかります。 rtos_sleep(500) セマフィア 最初は、無邪気なアプローチを試してみました。 typedef struct {
    volatile int count;
    int waiting_queue[MAX_THREADS];
    int head, tail;
} semaphore_t;

void rtos_sem_wait(semaphore_t *sem) {
    __disable_irq();
    sem->count--;
    if (sem->count < 0) {
        sem->waiting_queue[sem->tail++] = current_thread;
        tcbs[current_thread].state = BLOCKED;
        __enable_irq();
        rtos_yield();
    } else {
        __enable_irq();
    }
}

void rtos_sem_post(semaphore_t *sem) {
    __disable_irq();
    sem->count++;
    if (sem->count <= 0) {
        int tid = sem->waiting_queue[sem->head++];
        tcbs[tid].state = READY;
    }
    __enable_irq();
}
 オリジナルタイトル: Priority Inversion Nightmare ある日、私は3つのトレードを持っていました: 
 
 
 
 T0(優先順位2):セマフォールを保持する。 T1(優先順位1):そのセマフォーを待つ。 T2(優先順位3):走る準備ができ、T0より高いがT1より低い。 T1がブロックされていたため、T2は走り続けた - T1のためのセマフォーを解放するチャンスをT0に与えたことはありません。T1は飢えた。T1がブロックされたときにT0の優先順位を一時的に増やすことにしました - これは初期の優先順位の継承です。完全なソリューションは、どの糸がセマフォーを保持し、その優先順位を自動的に引き上げます。 「Kicking Everything Off」 rtos_start() スタート(スタート) イン , 基本的なハードウェア init (clocks, GPIO for LEDs, UART for the shell) 後、私は: main() // 1. Initialize SysTick and PendSV priorities
systick_init(16000);        // 1 ms tick on a 16 MHz system
NVIC_SetPriority(PendSV_IRQn, 0xFF);

// 2. Create threads (ID 0 = idle thread)
rtos_create_thread(idle_thread, 255);
rtos_create_thread(shell_thread, 3);
rtos_create_thread(worker1, 1);
rtos_create_thread(worker2, 2);

// 3. Switch to PSP and unprivileged Thread mode
current_thread = 0;
__set_PSP((uint32_t)tcbs[0].stack_ptr);
__set_CONTROL(0x02); // Use PSP, unprivileged
__ISB();

// 4. Pend PendSV to start first context switch
SCB->ICSR |= SCB_ICSR_PENDSVSET_Msk;

// 5. Idle loop
while (1) {
    __WFI();  // Save power until next interrupt
}
 最後の2枚のノート: 
 
 
 Idle Thread (ID 0):それは単に低優先度のLEDを切り替えます. 何かが間違っている場合、私は少なくとも私は無駄な糸に到達したことを知っています。 UART Interrupt Priority: UARTのTX中断はPendSVよりも優先順位が高い必要があり、そうでないと、長いプリントF通話は中間送信を中断し、出力が不足します。 タイトル:The UART Shell: Peeking Under the Hood 私は小さなシェルを作り、UARTでコマンドを入力し、トレードステータスを確認することができます。 void shell_thread(void) {
    char buf[64];
    while (1) {
        uart_print("> ");
        uart_read_line(buf, sizeof(buf));

        if (strncmp(buf, "ps", 2) == 0) {
            for (int i = 0; i < thread_count; i++) {
                uart_printf("TID %d: state=%d prio=%d\n",
                    i, tcbs[i].state, tcbs[i].priority);
            }
        } else if (strncmp(buf, "sleep ", 6) == 0) {
            uint32_t msec = atoi(&buf[6]);
            rtos_sleep(msec);
        } else if (strncmp(buf, "kill ", 5) == 0) {
            int tid = atoi(&buf[5]);
            if (tid >= 1 && tid < thread_count) { // don’t kill idle
                tcbs[tid].state = BLOCKED; // crude kill
                uart_printf("Killed thread %d\n", tid);
            }
        } else {
            uart_print("Unknown command\n");
        }
    }
}
 このシェルは私のセキュリティネットだった:LEDが奇妙に振る舞っていたら、私はシリアルターミナルに飛び込む。 , and immediately see which threads were READY, BLOCKED, or SLEEPING. It saved me hours of guesswork. それは私に数時間の推測を節約しました。 ps 途中で学んだ教訓 
 
 
 
 
 
 Interrupt Priorities Are Everything I spent an entire afternoon convincing my PendSV code was wrong—until I realized I’d set SysTick and PendSV to the same priority. 一度SysTick a higher priority gave, PendSV started firing reliably. レッスン: あなたのNVIC_SetPriority()呼び出しを2倍と3倍チェックしてください。 スタート時に知られているパターン(0xDEADBEEF)で各スレッドのスタックをプレフィンします。起動後、メモリをチェックして、パターンがどれほど深く書かれたかを確認してください。スタックポインタがそのパターンに入った場合、あなたはより大きなスタックを必要としていることを知っています。私は労働者のスレッド内のより深い呼び連鎖が沈黙のスレッドを引き起こしたときにこのことを学びました。 LEDs & GPIO を使用してデバッグする あなたがファンシアなデバッグを持っていない場合は、ただ GPIO ピンを切り替えましょう (LED にハックしてください) 私は、PendSV_Handler の最初に 1 つの LED トグルを置き、その終わりに 1 つを置きました。 Keep It Simple at First My very first RTOS version tried to support dynamic task creation at runtime—massive error. I ended up with memory fragmentation and weird crashes. By freezing the number of threads at startup (only nine slots in my case), I avoided a world of pain. 私の最初のRTOSバージョンは、ランタイムでダイナミックなタスク作成をサポートしようとしました。 ドキュメント すべてのマジック番号 0xFFFFFFFD 値が「偽の」スタックフレームにありますか? 私は「PSP を使用して Thread モードに戻ることを示すリンク レジストリ 値」という短いメモを書きました。 次 次の投稿: Where to Go From Here この基盤に基づくことを決めたら、以下にいくつかのアイデアがあります。 
 
 
 
 
 
 私の速い「boost-and-forget」ハックの代わりに、最も優先順位のブロックされたトレードの優先順位がリリースされるまで継承される適切なプロトコルを実装します。 Inter-Thread Message Queues トレードは、小さなメッセージやポインタを安全に互いに送信できます。 タスク間でデータを送信するための小さなメールボックスのように考えてください。 Dynamic Task Creation/Deletion Tack on a small heap manager or memory pool so you can create and kill threads on the fly - mind the extra complexity! ダイナミックタスク作成/削除 タックを小さなヒップマネージャーまたはメモリプールでタックして、フライトでトレードを作成して殺すことができます! Profiling Hooks あなたの SysTick トレーダーを拡張する (または別のタイマーを使用して) 各トレードがいくつトリックを実行しているかをログする. You could output a simple report over UART showing CPU usage by task. リアルタイムのセキュリティチェック ステック使用制限を導入し、トレードのステックポインターが 0xDEADBEEF リージョンに入るときを検出し、ランダムな衝突の代わりに安全なシャットダウンまたはリセットを引き起こします。 最終思考 最小限のRTOSを構築することは混乱し、しばしば挫折し、完全に啓蒙します。間違ったPendSVの優先順位を追いかけることから、ストックオーバーフローと戦うことまで、すべてのバグは私にCortex-M4の内部をより深く理解することを強要しました。あなたが自分自身のTM4Cまたは他のCortex-Mの部品でこれを試してみるなら、いくつかのデバッグの夜を期待してください - しかし、最初の信頼性の高いLEDのブリックがようやく現れたときの深い満足も期待してください。 あなたがこのショットを与えるならば、あなたが壁を駆り立てた部分を教えてください. 私はあなたの自分の「LEDのブリッキング」ストーリーやあなたのスケジュールのゴーストを追いかけながら発見した他のトリックを聞きたいです. ハッピーハッキング!

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

RTOS を開始する: Cortex-M4 を使用する初心者向けの手作業ガイド

About Author

コメント

ラベル

この記事は

Related Stories

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps