Aš vis dar prisimenu žiūrėdamas į mano TM4C123GH6PM LED vieną vakarą, laukdamas paprasto „širdies plakimo“ mirksėjimo, kuris niekada neatėjo. Aš maniau, kad padariau viską teisingai: įdiegiau „SysTick“, pakabinau „PendSV“ ir inicijuodavau savo „Thread Control Blocks“ (TCBs). Bet vietoj nuolatinio mirksėjimo, „LED“ sukrėtė vieną kartą, tada užšaldė – šaipydamas mane. Tą akimirką kristalizavo tai, ką iš tikrųjų reiškia sukurti mažą RTOS: kovoti su aparatūros trikdžiais, persekioti neįtikėtinus klaidas ir sujungti pakankamai kodo, kad viskas vyktų sklandžiai. Šiame straipsnyje aš Šiek tiek backstory Maždaug prieš metus mano įterptųjų sistemų klasė paskyrė mums sukurti paprastą RTOS nuo nulio ant TM4C123GH6PM (ARM Cortex-M4). Aš anksčiau naudojau FreeRTOS, bet niekada visiškai nesupratau, kas vyksta už scenų. Why? 
 
 
 
 Aš norėjau pamatyti, kaip tiksliai CPU pereina iš vieno laido į kitą. Man reikėjo sužinoti, kodėl mažo prioriteto užduotys gali netyčia nugalėti aukštesnio prioriteto užduotis (sveiki, prioriteto invertavimas). Aš troško tikrų debugging istorijų - pavyzdžiui, tą laiką, kurį praleidau pusę dienos, įdomu, kodėl PendSV niekada neveikė (atrodo, kad aš suteikiau jam tą patį prioritetą kaip ir SysTick). Spoiler: Mano RTOS nebuvo tobulas, bet, persekiojęs savo trūkumus, sužinojau daugiau apie ARM internals nei iš bet kurios vadovėlio. Nardymas į Cortex-M4 pasaulį Prieš rašydamas vieną kodo eilutę, turėjau apvynioti galvą apie tai, kaip Cortex-M4 tvarko pertraukas ir konteksto perjungimą. 
 
 
 
 
 
 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 Triukšmo kontrolės blokas (TCB) Kiekvienas mano RTOS laidas turi: 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;
 Praktiškai aš pareiškiau: #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 siaubo istorija Kai pirmą kartą paskyriau , viskas atrodė gerai - kol mano "darbuotojo" siūlas, kuris padarė keletą įterptų funkcijų skambučių, pradėjo sugadinti atmintį. pradedant ir tikrinant, kaip toli jis buvo perrašytas, radau, kad 128 žodžių nepakanka optimizuotų statybos vėliavų. STACK_WORDS = 128 0xDEADBEEF Sukurti naują virvę Sukurti siūlą reiškė iškirpti jo krūvą ir imituoti aparatūros kaupimąsi, kuris vyksta išimties įraše. 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;
}
 Pėdsakai, kuriuos reikia stebėti 
 
 
 
 Tai reiškia, kad jūsų procesorius bandys interpretuoti kodą kaip ARM instrukcijas - tiesioginę klaidą. Magic 0xFFFFFFFD. Tai pasakoja procesoriui: „Atgal į išimtį, naudokite PSP ir eikite į siūlo režimą.“ Prisimenu, kad mažiausiai tris kartus ieškojau ARM ARM (Architecture Reference Manual), kad tai padarytumėte teisingai. Rankiniu būdu stumiant R4–R11 turi būti laikomasi tikslios tvarkos, kurią tikisi tvarkytojas. Paprastas spausdinimas (pvz., pirmiausia stumiant R11 vietoj R4) išmeta visą rėmą. Leiskite laiko praeiti: SysTick Handler Štai mano galutinis SysTick ISR, supjaustytas iki esminių dalykų: 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
}
 Keletas pastabų: 
 
 
 Ankstyvosiose versijose aš bandžiau skambinti rtos_schedule() tiesiai SysTick viduje. Tai lėmė įsišaknijusius pertraukas ir maišą. Aš sužinojau, kad jei SysTick_IRQn ir PendSV_IRQn turi tą patį prioritetą, PendSV kartais niekada neveikia. Didysis jungiklis: „PendSV Handler“ Kai „PendSV“ pagaliau paleidžiamas, jis pakeičia faktinį kontekstą. Mano įgyvendinimas GCC inline assembly (ARM sintaksė) atrodo taip: __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
    );
}
 Kaip aš atsekti, kad pesky 32-byte kompensacija Iš pradžių mano "išsaugoti / atkurti" kodas buvo išjungtas 32 bajtais. Simptomas? Laidai būtų paleisti, tada kažkaip grįžta į gyvenimą netinkamoje vietoje - išgręžtos instrukcijos, atsitiktiniai šuoliukai. ) tiksliai išmatuoti, kiek baitų buvo stumti. mano debugger, aš tada palygino skaitmeninę PSP vertę su Aš tikėjausi. pakankamai tikras, aš netyčia naudojau Vietoj —paspaudus vieną papildomą registrą. Pašalinus papildomą paspaudusį registrą jis buvo išspręstas. STMDB tcbs[].stack_ptr STMDB R0!, {R4-R11, R12} {R4-R11} Kitas Kitas įrašas: Planavimo logika Jis nuskaito visus TCB, kad surastų aukščiausio prioriteto READY vielą, su mažu apvaliu robin tweaku vienodo prioriteto vieloms: 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: 
 
 
 Jei dvi vielos turi prioritetą 1, bet aš visada pasirenku žemesnį ID, kitas niekada negaus CPU laiko. Tuščias siūlas (ID 0) yra specialus atvejis: visada pasiruošęs, visada mažiausias prioritetas (prioritetas = 255), todėl, jei nieko kito neįmanoma paleisti, jis tiesiog sukasi (arba skambina __WFI() energijos taupymui). Branduoliniai primityvai: pelnas, miegas ir semaforos Po pagrindinių dalykų, kitas žingsnis buvo padaryti siūlai sąveikauti tinkamai. pelnas void rtos_yield(void) {
    SCB->ICSR |= SCB_ICSR_PENDSVSET_Msk;
}
 Man patinka sprinkliai ilgų posūkių pabaigoje, kad kitos vielos gautų teisingą šūvį. ankstyvuose bandymuose, praleidžiant Tai reiškė, kad kai kurios užduotys sukrėtė procesorių pagal tam tikras prioritetines konfigūracijas. rtos_yield() yield() miegoti void rtos_sleep(uint32_t ticks) {
    tcb_t *self = &tcbs[current_thread];
    self->sleep_ticks = ticks;
    self->state       = SLEEPING;
    rtos_yield();
}
 „Led Blinking“ skambučiai Kai žiūriu, kaip jis mirksi kas pusę sekundės, žinau, kad "SysTick" ir "PendSV" daro savo darbą teisingai. rtos_sleep(500) Semifinalių Iš pradžių aš bandžiau naivų požiūrį: 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();
}
 Prioritetas Inversijos košmaras Vieną dieną turėjau tris virves: 
 
 
 
 T0 (prioritetas 2): laikosi šviesos pertekliaus. T1 (prioritetas 1): laukiant to semaforo. T2 (prioritetas 3): pasiruošęs paleisti ir didesnis nei T0, bet mažesnis nei T1. Kadangi T1 buvo užblokuotas, T2 tęsė darbą – niekada neduodamas T0 galimybės išleisti T1 žibintuvėlį. T1 alkanas. Mano greitas įsilaužimas buvo laikinai padidinti T0 prioritetą, kai T1 buvo užblokuotas – tai primityvus prioriteto paveldėjimas. Pilnas sprendimas būtų sekti, kuris vielos laikosi žibintuvėlį ir automatiškai pakelia jo prioritetą. Išjungti viską išjungti: Pradžia / Pradžia Pradžia / Pradžia į , po pagrindinės aparatūros init (laikrodžiai, GPIO LED, UART apvalkalui), aš padariau: 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
}
 Pora galutinių pastabų: 
 
 
 Idle Thread (ID 0): jis tiesiog perjungia šviesos diodą su mažu prioritetu. Jei kažkas negerai, žinau, kad bent jau pasiekiau tuščią vielą. UART pertraukos prioritetas: UART TX pertrauka reikėjo didesnio prioriteto nei PendSV; kitaip ilgai spausdinti skambučiai būtų nutraukti viduryje perdavimo, sutrikdydami išvestį. Žymės: Peeking Under the Hood Aš sukūriau mažą apvalkalą, kad galėčiau įvesti komandas per UART ir patikrinti siūlių būsenas: 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");
        }
    }
}
 Ši apvalkalas buvo mano saugos tinklas: jei šviesos diodai elgėsi keistai, aš šokinėčiau į savo serijinį terminalą, , ir iš karto pamatyti, kurie siūlai buvo paruošti, užblokuoti ar miega. ps Pamokos, išmokstamos kelyje 
 
 
 
 
 
 „Interrupt Priorities“ yra viskas, ką praleidau visą popietę, įsitikinęs, kad mano „PendSV“ kodas buvo neteisingas, kol supratau, kad nustatiau „SysTick“ ir „PendSV“ į tą patį prioritetą. Išmatuokite savo krūvos naudojimą Iš anksto užpildykite kiekvieno laido krūvą su žinomu modeliu (0xDEADBEEF) paleidimo metu. Po paleidimo patikrinkite atmintį, kad pamatytumėte, kaip giliai modelis buvo užrašytas. Jei jūsų krūvos rodyklė kada nors patenka į tą modelį, jūs žinote, kad jums reikia didesnės krūvos. Aš sužinojau tai sunkiai, kai gilesnė skambučių grandinė mano darbuotojo lauke sukėlė tylų perrašymą. Naudokite šviesos diodų ir GPIO debugging Jei neturite fancy debugger, tiesiog perjungti GPIO pin (įklijuoti jį į šviesos diodą). Aš įdėti vieną LED perjungimo pačioje pradžioje PendSV_Handler ir kitą jo pabaigoje. žiūrėti tuos mirksėjimą logikos analizatorius padėjo man patikrinti, kad tvarkytuvas veikia tikėtiną skaičių kartų - ir maždaug teisingus intervalus. Iš pradžių mano pirmoji RTOS versija bandė palaikyti dinamišką užduočių kūrimą paleidimo metu – didžiulė klaida. galų gale patyriau atminties suskaidymą ir keistus gedimus. Dokumentas Kiekvienas stebuklingas skaičius, kad 0xFFFFFFFD reikšmė "netikros" rėmo rėmo? parašiau trumpą užrašą: "Link registro reikšmė, rodanti grįžimą į siūlo režimą naudojant PSP."Be šio komentaro, aš Google "ARM išimties grąžinimo reikšmės" kiekvieną kartą, kai perskaičiau kodą. Kiti žingsniai: kur eiti iš čia Jei nuspręsite statyti ant šio pagrindo, čia yra keletas idėjų: 
 
 
 
 
 
 Viso prioriteto paveldėjimas "Semaphores", o ne mano greitas "boost-and-forget" įsilaužimas, įgyvendinkite tinkamą protokolą, kuriame aukščiausio prioriteto užblokuotos vielos prioritetas yra paveldėtas, kol bus išleistas semaphore. Inter-Thread pranešimų eilutės Leiskite siūlai saugiai siųsti mažus pranešimus ar rodykles vienas kitam. pagalvokite apie tai kaip mažą pašto dėžutę, skirtą duomenų perdavimui tarp užduočių. Dinaminis užduočių kūrimas / ištrynimas Dėmesys mažame kaupiamojo valdytojo ar atminties baseine, kad galėtumėte sukurti ir nužudyti siūlus - nepamirškite papildomo sudėtingumo! Profiliavimo kilpos Išplėskite savo SysTick tvarkyklę (arba naudokite kitą laikmatį), kad užregistruotumėte, kiek kilpų veikia kiekvienas laidas. Realaus laiko saugos patikrinimai Įveskite kamino naudojimo apribojimus ir aptinkate, kada laido kamino rodyklė kerta į 0xDEADBEEF regioną - sukelia saugų išjungimą arba atkūrimą vietoj atsitiktinių avarijų. Galutinės mintys Pastatyti minimalų RTOS yra neramus, dažnai varginantis ir visiškai apšviečiantis. Nuo persekiojimo netinkamai išdėstytą PendSV prioritetą kovoti su krūva perteklių, kiekviena klaida privertė mane giliau suprasti Cortex-M4 vidaus. Jei duosite tai šūvį, prašau, leiskite man žinoti, kuri dalis paskatino jus į sieną.Aš norėčiau išgirsti savo "LED mirksi" istorijas ar bet kokius kitus triukus, kuriuos atradote, kai persekiojote vaiduoklius savo tvarkaraštyje.

Read My Stories

Šis garso įrašas sukurtas originalia istorijos kalba!

Per ilgai; Skaityti

Make resilience your competitive advantage

Pradėti su RTOS: Praktiškas vadovas pradedantiesiems, naudojantiems Cortex-M4

About Author

KOMENTARAI

PABAIGTI ŽYMES

ŠIS STRAIPSNIS BUVO PRISTATYMAS

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps