Prekidi i posebni slučajevi. Primjeri prekida

Mehanizam prioriteta (PM) pokazuje koje uređaje je potrebno prvo servisirati. MP rješava sljedeće zadatke:

Popravlja prioritet bilo kojeg programa koji izvršava procesor.

Identificira RFP iz VU s najvišim prioritetom.

Omogućuje prekid programa kada se pojavi zahtjev visokog prioriteta.

Prekidanje rutine usluge prekida naziva se ugniježđenim prekidom.

Riža. 6.4 Primjer CPU-a u načinu rada ugniježđenog prekida.

Slika 6.4 prikazuje primjer ugniježđenog prekida:

Prije t 1 nema plaće

t 1 → RFP iz VU4

t 2 → RFP od VU3

t 3 → RFP od VU2

t 4 → održavanje VU2 je završeno

t 5 → RFP od VU1

t 6 → održavanje VU1 je završeno

t 7 → završeno održavanje VU3

t 8 → održavanje VU4 je završeno

Nedostatak: Uz veliku učestalost primanja plaće, CPU ne radi učinkovito, jer puno se CPU vremena troši na ZP, vraćanje registara procesora, prelazak s jednog programa na drugi.

Učestalost ZP-a možete smanjiti uključivanjem međuspremnika.

Prilikom dodjele prioriteta VU uzimaju se u obzir sljedeći uvjeti:

Što je uređaj brži, to mu je veći prioritet.

Najveći prioritet dodjeljuje se uređaju s kojeg se podaci ne mogu oporaviti (obično timer).

U obitelji računala Macintosh prioritet programa naznačen je u drugoj riječi VI.

U obitelji računala IBMPC prioritet programa se postavlja pomoću posebnog LSI (veliki integrirani krug) - programabilnog kontrolera prekida.

Tehnička implementacija višerazinskih ugniježđenih prioritetnih vektorskih prekida u računalu koje se temelji na jednom kanalu za razmjenu podataka okosnice.

Implementacija višerazinskih VI-ova u računala obiteljiIBM .

Za implementaciju višerazinskog VI u računalu obitelji IBM primijenjen LSI Intel 8259A.

Specifikacije za Intel 8259a.

Broj razina RFP-a = 8.

Broj razina može se proširiti na 64 kaskadnim mikro krugovima

Način rada plaće, razine prioriteta, WUA se postavlja programski.

Tehnička implementacija prioritetnih vektorskih prekida u računalu s izoliranim glavnim kanalima za razmjenu podataka (obitelj IBMNA): načini rada programabilnog kontrolera prekida (SCP),

dijagram povezivanja kontrolne ploče sa sistemskom sabirnicom,

Shema spajanja upravljačke ploče na VU sistemsku sabirnicu.

Riža. 6.7 Shema spajanja upravljačke ploče na sistemsku sabirnicu i upravljačku ploču.

LSI dodjela pinova:

D7- D0 - izlazi koračnog motora, koriste se za primanje upravljačkih informacija od CPU-a i prijenos informacija o statusu na CPU.

A0 - unos adrese, adresiranje internih registara kontrolera (2 adrese).

~ Cs (čip Izaberi) - odabir kristala, omogućuje ili onemogućuje komunikaciju regulatora sa sistemskom sabirnicom.

• ~Cs= 0 - postoji veza, ~ Cs= 1 - nema veze.

Prva upravljačka ploča koristi adrese - 20 h, 21 h.

Druga upravljačka ploča koristi adrese - A0 h, A1 h.

~ RD, ~ WR- ulaz, izlaz (ShU signali), spojeni su na glavne vodove ~ IORi ~IOW.

INT(izlaz) - ZP signal za CPU.

~ INTA (potvrda prekida)- RP signal iz CPU-a.

CAS2, CAS1, CAS0 - kaskadni autobus. Za glavni kontroler prekida ove linije su izlazi, a za slave su ulazi.

~ SP/~ RU- označava glavnog (1) ili slave (0) upravljačke ploče.

IR0... IR7 - unos zahtjeva za prekidom od VU.

funkcionalni sastav i programski model upravljačke ploče.

Prekinuti- riječ je o promjeni prirodnog redoslijeda izvršavanja programa, koja je povezana s potrebom da sustav odgovori na rad vanjskih uređaja, kao i na pogreške i posebne situacije koje su nastale tijekom izvršavanja programa. To zove poseban program - rukovalac prekida, specifična za svaku nastalu situaciju, nakon čijeg se izvršenja nastavlja rad prekinutog programa.

Mehanizam prekida osigurava odgovarajući hardver i softver računala.

Klasifikacija prekida prikazana je na Sl. 7.1.

Riža. 7.1.

Zahtjevi hardverskog prekida nastaju asinkrono s obzirom na rad mikroprocesora i povezani su s radom vanjskih uređaja.

Zahtjev od nemaskirabilne prekide dolazi na ulaz NMI mikroprocesor i ne može se softverski zaključati. Obično se ovaj ulaz koristi za traženje prekida od strujnih krugova ili fatalnih I/O pogrešaka.

Za upite maskirani prekidi koristi se INT ulaz mikroprocesora. Liječenje zahtjev za prekidom na ovom ulazu može se blokirati brisanjem bita IF registar zastave mikroprocesor.

Softver prekida se, strogo govoreći, nazivaju iznimkama ili posebnim slučajevima. Povezuju se s posebnim situacijama koje nastaju tijekom izvođenja programa (nedostatak stranice u RAM-u, kršenje zaštite, prelijevanje), odnosno s onim situacijama koje programer ne može predvidjeti ili s prisutnošću posebne naredbe INT n u program, koji programer koristi za pozivanje funkcija operacijskog sustava ili BIOS-a koji podržavaju rad s vanjskim uređajima. U nastavku, kada ćemo raspravljati o radu sustava za prekide, koristit ćemo jedan izraz "prekid" za hardverske prekide i iznimke, osim ako nije drugačije navedeno.

Softverski prekidi su sljedećih vrsta.

Kršenje (odbijanje)- poseban slučaj koji mikroprocesor može otkriti prije nego što dođe do stvarne pogreške (na primjer, odsutnost stranice u RAM-u); nakon obrade kršenja, program se izvršava s ponovnim pokretanjem naredbe koja je uzrokovala kršenje.

Zamka- poseban slučaj koji je otkriven nakon završetka izvršenja naredbe (na primjer, prisutnost naredbe INT n u programu ili postavljena TF zastava u registar zastave). Nakon što je ovaj prekid obrađen, izvršavanje programa se nastavlja sljedećom instrukcijom.

Sudar(izlazak iz procesa) je toliko ozbiljna pogreška da se neki kontekst programa gubi i njegov nastavak je nemoguć. Nemoguće je utvrditi uzrok nesreće, pa se program uklanja iz obrade. Alarmi uključuju hardverske pogreške i nekompatibilne ili nevažeće vrijednosti u tablicama sustava.

Nalog za rukovanje prekidom

Prekidi i iznimke prepoznaju se na granicama instrukcija, a programer možda ne mari za stanje internih radnih registara i cjevovodnih uređaja.

Odgovarajući na zahtjeve za prekide, mikroprocesor mora identificirati svoj izvor, zadržati minimalni kontekst trenutnog programa i prebaciti se na poseban program - rukovatelj prekida. Nakon servisiranja prekida, MP se vraća na prekinuti program, a on bi trebao nastaviti kao da nije bilo prekida.

Obrada zahtjeva za prekidom sastoji se od:

• "refleksne" radnje procesora, koje su iste za sve prekide i posebne slučajeve i koje programer ne može kontrolirati;
• izvršavanje rukovatelja koji je kreirao programer.

Kako bi mikroprocesor identificirao izvor prekida i pronašao rukovatelja koji odgovara zaprimljenom zahtjevu, svakom zahtjevu za prekidom se dodjeljuje svoj broj ( tip prekida).

Vrsta prekida za softverski prekidi uveden iz unutrašnjosti mikroprocesora; na primjer, prekid stranice bez memorije je tipa 14. Za prekide koje poziva INT n instrukcija, tip je sadržan u samoj instrukciji. Za maskirane hardverske prekide, tip se unosi iz prioritetni kontroler prekida na sabirnici podataka. Prekid koji se ne može maskirati tip 2 dodijeljen.

Ukupno, mikroprocesor razlikuje 256 vrste prekida... Dakle, svi se mogu kodirati u 1 bajt.

"Refleksne" akcije mikroprocesora na obradu zahtjev za prekidom izvode se MP hardverom i uključuju:

• definicija tip prekida ;
• spremanje konteksta prekinutog programa (neke informacije koje će vam omogućiti da se vratite na prekinuti program i nastavite njegovo izvršavanje). Najmanje registri se uvijek automatski spremaju EIP i CS, definirajući točku povratka na prekinuti program, te registar zastavica EFLAGS. Ako se rukovatelj prekida poziva pomoću vrata zadatka, tada je segment TSS stanja prekinutog zadatka u potpunosti pohranjen u memoriju;
• definicija adrese rukovalac prekida i prijenos kontrole na prvu naredbu ovog rukovatelja.

Nakon toga, program se izvršava - rukovalac prekida odgovara primljenom zahtjevu. Ovaj program piše i stavlja u memoriju programer aplikacije ili sustava. Rukovalac prekida mora završiti naredbom I RET, uz koje se automatski događa prijelaz na nastavak prekinutog programa s vraćanjem njegovog konteksta.

Za pozivanje rukovatelja prekida, mikroprocesora pri radu pravi način rada koristi tablica vektora prekida i u zaštićeni način rada - tablica deskriptora prekida.

Sadržaj IDTr registra nije pohranjen u TSS segmentima i ne mijenja se kada se zadatak prebaci. Programi ne mogu pristupiti IDT budući da je jedini dio TI tablični indikator v selektor segment pruža izbor samo između tablica Gdt i LDT.

Maksimalno ograničenje za tablicu deskriptora prekida je 256 * 8 - 1 = 2047.

Moguće je postaviti nižu granicu, ali se to ne preporučuje. Ako se ručki pristupa izvan granica IDT, procesor ulazi u režim isključivanja sve dok ne primi signal na ulazu NMI ili resetirajte.

V IDT mogu se pohraniti samo deskriptori sljedećih tipova:

• trap gateway,
• interrupt gateway, pristupnik zadatka.

Watchdog timeri.

Često, električni šum koji stvara okolna oprema uzrokuje da mikrokontroler adresira pogrešnu adresu, nakon čega njegovo ponašanje postaje nepredvidivo (mikrokontroler je "van kontrole"). Za praćenje takvih situacija, u mikrokontroler su često uključeni watchdog timeri.

Ovaj uređaj uzrokuje resetiranje mikrokontrolera ako se njegov sadržaj ne ažurira unutar određenog vremenskog razdoblja (obično od nekoliko desetaka milisekundi do nekoliko sekundi). Ako promjena sadržaja programskog brojača ne odgovara navedenom programu, naredba za modificiranje watchdog timera neće se izvršiti. U tom slučaju, watchdog timer resetira mikrokontroler, postavljajući ga u izvorno stanje.

Mnogi programeri ne koriste watchdog timere u svojim aplikacijama, jer ne vide potrebu da ih koriste za borbu protiv učinaka električne buke, na primjer, kada postavljaju mikrokontroler u zaslon katodnih zraka u blizini transformatora koji osigurava prigušenje povratni put zraka, ili pored indukcijskih svitaka u automobilu. U modernoj elektronici je malo vjerojatno da će doći do električnih smetnji, iako se ponekad javljaju u situacijama poput gore navedenih.

Ne preporučuje se korištenje watchdog timera za maskiranje softverskih problema. Iako ovaj mjerač vremena može smanjiti vjerojatnost softverskih pogrešaka, malo je vjerojatno da će eliminirati sve moguće uzroke pogrešaka. Umjesto da se oslanjate na hardver kako biste spriječili softverske greške, bolje je temeljitije testirati softver u različitim situacijama.

Mnogi korisnici vjeruju da su prekidi dio hardvera koji je najbolje ostaviti na miru, jer njihovo korištenje zahtijeva izvrsno poznavanje procesora za razvoj rukovatelja prekidima. Inače, kada dođe do prekida, sustav "zaspi" ili "pedali". Ovaj osjećaj obično dolazi do programera nakon iskustva s prekidima za osobno računalo, koje ima niz značajki koje otežavaju stvaranje rukovatelja prekida. Mnogi od ovih problema se ne pojavljuju u hardveru koji se temelji na mikrokontroleru. Korištenje prekida u ovoj opremi može uvelike pojednostaviti njezin dizajn i primjenu.

Ako se nikada niste bavili prekidima, onda se postavlja pitanje - što je to? U računalnom sustavu, prekid je pokretanje posebnog potprograma (koji se naziva "upravljač prekidom" ili "rutina usluge prekida") koji se pokreće hardverskim signalom. Tijekom izvršavanja ovog potprograma, implementacija trenutnog programa se zaustavlja. Pojam zahtjev za prekidom koristi se jer ponekad program odbija potvrditi prekid i odmah izvršiti rukovalac prekida (slika 2.19).

Prekidi u računalnom sustavu slični su prekidima u svakodnevnom životu. Klasičan primjer takvog prekida je telefonski razgovor tijekom gledanja TV programa. Kada telefon zazvoni, imate tri opcije. Prvi je ignoriranje poziva. Drugi je da odgovorite na poziv, ali recite da ćete nazvati kasnije. Treće je odgovoriti na poziv, odgađajući sve tekuće poslove. Računalni sustav također ima tri takva odgovora koji se mogu koristiti kao odgovor na vanjski hardverski zahtjev.

Prvi mogući odgovor - "ne odgovarati na prekid dok se trenutni zadatak ne završi" - implementira se onemogućavanjem (maskiranjem) usluge zahtjeva za prekidom. Nakon dovršenog zadatka moguća je jedna od dvije opcije: resetiranje maske i omogućavanje usluge, što će dovesti do poziva rukovatelja prekida, ili analiza vrijednosti bitova ("polling"). što ukazuje na dolazak zahtjeva za prekidom i izravno izvršenje uslužnog programa bez pozivanja rukovatelja prekida. Ova metoda rukovanja prekidom koristi se kada je potrebno osigurati određeno vrijeme izvršavanja glavnog programa, budući da svaki prekid može narušiti implementaciju potrebnog sučelja.

Riža. 2.18 - Izvršavanje prekida.

Dugotrajno maskiranje prekida se ne preporučuje, jer se tijekom tog vremena može preklapati nekoliko događaja koji uzrokuju prekide, a samo će jedan biti prepoznat. Dopušteno trajanje maskiranja ovisi o specifičnoj primjeni mikrokontrolera, te vrsti i učestalosti takvih događaja. Ne preporučuje se onemogućavanje prekida na vrijeme duže od polovice minimalnog očekivanog razdoblja slijeda događaja koji zahtijevaju prekide.

Rukovalac prekida uvijek pruža sljedeći slijed radnji:

2. Resetirajte kontroler prekida i hardver koji je uzrokovao zahtjev.

3. Obradite podatke.

4. Vratite sadržaj registara konteksta.

5. Vratite se na prekinuti program.

Kontekstni registri su registri koji određuju trenutno stanje izvršenja glavnog programa. To obično uključuje programski brojač, statusne registre i akumulatore. Drugi registri procesora, kao što su indeksni registri, mogu se koristiti tijekom obrade prekida, pa se njihov sadržaj također mora spremiti. Svi ostali registri su specifični za pojedini mikrokontroler i njegovu primjenu.

Nakon resetiranja, kontroler prekida spreman je prihvatiti sljedeći zahtjev, a oprema koja uzrokuje prekid spremna je poslati zahtjev kada je to prikladno. Ako stigne novi zahtjev za prekidom, procesorov registar za maskiranje prekida spriječit će obradu prekida, ali će registar statusa prekida uhvatiti ovaj zahtjev, koji će čekati svoju uslugu. Nakon što je obrada trenutnog prekida završena, maska ​​prekida se briše, a novoprimljeni zahtjev se šalje na obradu.

Ugniježđene prekide je teško implementirati s nekim vrstama mikrokontrolera koji nemaju stog. Ovi prekidi također mogu uzrokovati probleme s preljevom steka. Problem preljeva je relevantan za mikrokontrolere zbog ograničene količine njihove podatkovne memorije i stoga: slijed ugniježđenih prekida može dovesti do činjenice da će više podataka biti gurnuto u stog nego što je dopušteno.

Konačno, prekid se obrađuje. Drugi TV primjer pokazuje da možete brzo odgovoriti na zahtjev za prekid prihvaćanjem potrebnih podataka, koji će se potom koristiti nakon rješavanja trenutnog problema. U mikrokontrolerima se to provodi tako da se primljeni podaci pohranjuju u memorijski niz, a zatim se obrađuju kada se završi izvođenje izvornog programa. Ovakav način servisiranja dobar je kompromis između trenutnog potpunog rukovanja prekidom, što može potrajati, i ignoriranja prekida, što može dovesti do gubitka informacija o događaju koji je uzrokovao prekid.

Vraćanje kontekstnih registara i izvršavanje naredbe za vraćanje prekida vraća procesor u stanje u kojem je bio prije prekida.

Razmotrite što se događa sa sadržajem različitih registara kada se obradi prekid. Sadržaj registra statusa obično se automatski sprema sa sadržajem programskog brojača prije nego što se obradi prekid. Time se eliminira potreba za programskim pohranjivanjem u memoriju pomoću uputa za prijenos, a zatim vraćanjem kada se vratite na izvorni program. Međutim, takvo automatsko spremanje nije implementirano u svim vrstama mikrokontrolera, stoga posebnu pozornost treba posvetiti organizaciji rukovanja prekidima.

Ako je sadržaj registra statusa spremljen prije početka izvršavanja rukovatelja prekida, tada se na naredbi return automatski vraća.

Ako se sadržaj drugih registara procesora promijeni kada se izvrši usluga prekida, tada se također mora spremiti u memoriju prije promjene i vratiti prije povratka u glavni program. Uobičajena je praksa čuvati sve registre procesora kako bi se izbjegle nepredvidive pogreške koje je vrlo teško lokalizirati.

Adresa koja se učitava u programski brojač kada skoči na rukovatelj prekida naziva se "vektor prekida". Postoji nekoliko vrsta vektora. Adresa koja se učitava u programski brojač kada se mikrokontroler pokrene (resetira) naziva se "vektor resetiranja". Za različite prekide mogu se specificirati različiti vektori, eliminirajući potrebu da servisna rutina odredi uzrok prekida. Korištenje jednog vektora različitim prekidima obično ne stvara probleme mikrokontrolerima, jer najčešće mikrokontroler izvršava jedan program. Po tome se mikrokontroler razlikuje od osobnog računala, tijekom čijeg rada se mogu dodavati različiti izvori prekida. (Ako ste ikada spojili dva uređaja na COM1 i COM3, onda znate o čemu se radi). U mikrokontroleru gdje je hardver dobro poznat, ne bi trebalo biti problema s dijeljenjem vektora prekida.

Posljednja stvar koju treba uzeti u obzir su softverski prekidi. Postoje procesorske upute koje se mogu koristiti za simulaciju hardverskih prekida. Najočitija upotreba ovih naredbi je pozivanje sistemskih rutina koje se nalaze na proizvoljnom mjestu u memoriji ili zahtijevaju međusegmentne skokove za pristup. Ova je značajka implementirana u obitelji mikroprocesora Intel i86 i koristi se u osnovnom ulazno/izlaznom sustavu (BIOS) i DOS operativnom sustavu osobnih računala za pozivanje sistemskih rutina bez popravljanja ulazne točke. Umjesto toga, različiti vektori prekida koriste se za odabir instrukcije koja će se izvršiti kada dođe do takvog softverskog prekida.

Možda će vam nakon čitanja ovog poglavlja mehanizam prekida postati razumljiviji, ili obrnuto. Samo ćete se još više zbuniti. Opis svakog mikrokontrolera pokazat će kako korištenje prekida može pojednostaviti njegovu primjenu.

Postoji situacija kada trebate objesiti mnogo različitih zadataka na jedan periferni uređaj, ali postoji samo jedan i potrebno je nešto poduzeti po tom pitanju.

Jednostavan primjer je mjerač vremena i njegov prekid preljeva.
Možemo podesiti brzinu zatvarača i prekinuti za obavljanje nekih operacija. Ali ako u jednom trenutku želimo da tajmer prekida izvrši jednu operaciju, a zatim drugu, treću. Da, koliko je potrebno, ovisno o državi. I postoji samo jedan vektor.

Ili, na primjer, USART. Možda ćemo lako morati izvršiti drugačiji kod ovisno o načinu prekida prilikom dolaska bajta. U jednom načinu - izdavanje pozdrava, u drugom - slanje opscenosti u kupaonicu. U trećem, udarac u glavu. I postoji samo jedan vektor.

Naravno, možete dodati strukturu preklopnog slučaja rukovatelju prekida i odabirom načina rada otići na željeni dio koda, ali to je prilično glomazno, a što je najvažnije, vrijeme prijelaza bit će različito, ovisno o redoslijed kojim će se ići ispitivanje usporedbe slučaja prekidača.

Odnosno, u prekidaču oblika:

prekidač (x) (1: Radnja 1 2: Radnja 2 3: Radnja 3 4: Radnja 4)

Doći će do uzastopne usporedbe x, prvo s 1, zatim s 2, zatim s 3, i tako dalje dok se sve opcije ne nabroje. U ovom slučaju, reakcija na akciju 1 bit će brža od reakcije na akciju 4. To je posebno važno kada se izračunaju točni vremenski intervali na mjeraču vremena.

Ali postoji jednostavno rješenje za ovaj problem - skok indeksa. Dovoljno je prije nego što počnemo čekati da se prekid unaprijed učita u varijable (ili možete izravno u indeksni registar Z) smjer u kojem trebamo preusmjeriti naš vektor i umetnuti skok indeksa u rukovalac prekida. I voila! Prijelaz će biti tamo gdje trebate, bez ikakve usporedbe opcija.

U memoriji kreirajte varijable za plutajući vektor:

Timer0_Vect_L: .byte 1; Dva bajta adrese, visoki i niski Timer0_Vect_H: .byte 1

Priprema čekanja na prekid je jednostavna, uzimamo i učitavamo u našu varijablu sa željenom adresom

CLI; Kritični dio. Prekida OFF LDI R16, nisko (Timer_01); Uzmite adresu i spremite STS Timer0_Vect_L, R16; to u memorijsku ćeliju. LDI R16, visoki (Timer_01); Slično, ali sa starijim vektorom STS Timer0_Vect_H, R16 SEI; Prekida ON

To je to, možete pokrenuti mjerač vremena i čekati naš prekid. Isto je i s drugim slučajevima.

A rukovalac je ovakav:

; ================================; Unos prekida preljeva iz Timera0; ============================= TIMER_0: PUSH ZL; spremi indeksni registar na stog PUSH ZH; od koristimo ga PUSH R2; spasiti R2, jer kvarimo i to IN R2, SREG; Dohvatite i spremite registar zastavice PUSH R2; Ako to ne učinite, 100% će dobiti greške LDS ZL, Timer0_Vect_L; učitaj adresu novog vektora LDS ZH, Timer0_Vect_H; oba bajta. CLR R2; Čistimo R2 ILI R2, ZL; Provjera vektora za nulu. Inače, shvatimo analog OR R2, ZH; reset "a. Provjera prolazi kroz ILI operaciju BREQ Exit_Tm0; s akumulacijom rezultata u R2; tako da ne pokvarimo sadržaj Z i ne moramo; ponovo ga učitati IJMP; Odlazimo s novim vektorom ; Izađite iz prekida Exit_Tm0: POP R2; Vadimo i vraćamo registar zastavice OUT SREG, R2 POP R2; vraćamo R2 POP ZH; Vraćamo Z POP ZL RETI; Dodatni vektor 1 Timer_01: NOP; Ovo su naši novi NOP vektori; ovdje možemo učiniti bilo što NOP; po mogućnosti ne dugo - u NOP prekidu; Ako koristimo bilo koji drugi NOP; registre, tada ih također spremamo u stog RJMP Exit_Tm0; Ovo je prijelaz na izlaz iz prekida; posebno napravljen kroz RJMP tako da; Dodatni vektor 2; spremite deset bajtova na povratni kod :))) Timer_02: NOP NOP NOP NOP NOP RJMP Exit_Tm0; Dodatni vektor 3 Timer_03: NOP NOP NOP NOP NOP RJMP Exit_Tm0

Implementacija za RTOS
Ali što ako je naš program izgrađen na takav način da se sav kod rotira kroz lance zadataka preko RTOS upravitelja? Vrlo je teško izračunati u svojoj glavi kako se ti lanci izvode u odnosu jedan na drugi. I svatko od njih može pokušati preuzeti mjerač vremena (naravno, ne proizvoljno, iz našeg podneska, mi pišemo program, ali bit će teško na vrijeme pratiti koliko će sve biti teško).
U modernim glavnim osovinama za ovaj slučaj postoji mehanizam Mutual Exclusion – mutex. Oni. to je neka vrsta prometne zastave. Ako neki proces komunicira, na primjer, s UART-om, tada se drugi proces ne usuđuje staviti bajt tamo i poslušno čeka dok prvi proces ne oslobodi UART, što će biti označeno zastavicom.

U mom slučaju ne postoje mehanizmi međusobnog isključivanja, ali se mogu implementirati. Napravite barem neki minimalni privid. Ne želim raditi potpunu implementaciju svega ovog smeća, jer moj cilj je zadržati veličinu kernela na 500-800 bajtova.
Najlakši način da rezervirate još jedan bajt u memoriji je varijabla zauzeta. A kada jedan proces zauzme resurs, tada u ovu varijablu upisuje vrijeme kada ga približno oslobađa. Vrijeme ide u otkucajima sistemskog timera, koji ja imam 1ms.
Ako bilo koji drugi proces pokuša pristupiti istom hardverskom resursu, prvo će pogledati stanje svoje zaposlenosti, izbrojati vrijeme tijekom kojeg će biti zauzet i ostaviti pušiti za to razdoblje - učitat će se u red čekanja na tajmeru. Tamo će ponovno provjeriti i tako dalje. Ovo je najjednostavnija opcija.

Ovdje je problem što ako ima puno zainteresiranih za jedan vektor, onda će procesi i dalje teći unaokolo, poput mljevenja mladih oko jedinog zahoda na trgu za vrijeme svečanih fešta. Nečiji mjehur neće izdržati - algoritam će zeznuti. A tko ima smokve ovdje možete pogoditi, tk. bit će teško simulirati.

Rješenje problema je dodavanje još jednog redovnog lanca, ovaj put za pristup resursu. Tako da uopće ne stoji besposlen. Oni. jedan je iskočio, pa drugi, treći, i tako sve dok im svi procesi ne oslobode potrebe za nekom vrstom USART-a.
Nedostatak je očit - drugi red je dodatna memorija, dodatni kod, dodatno vrijeme. Možete se, naravno, izopačiti i postaviti kod glavnog dispečera lanca na red na vektor. Ali ovdje morate pažljivo otkloniti sve greške, jer će biti pozvano na prekidu! Da, i glomazan, potreban je samo kada imamo puno kandidata.

Drugo rješenje je odbaciti varijablu vremena zauzetosti, ostavljajući samo oznaku Zauzeto! A proces koji pokušava kontaktirati ne bježi da popuši, već skoči nekoliko koraka unatrag - do kraja reda čekanja zadataka i odmah prasne natrag. Ljudi oko WC-a ne trče okolo, već guraju laktove na ulazu po principu tko prvi prolazi.
Još jedan nedostatak je veliko opterećenje na glavnom cjevovodu, hrpa zahtjeva za čekanje tako brzo napuhne cijeli RAM i ispuni stog, a to je ispunjeno globalnom apokalipsom.

Naravno, mjerač vremena je ovdje dat kao primjer, većina zadataka se može riješiti s timerom RTOS sustava, ali ako vam odjednom treba manja diskretnost ili visoka stopa reakcije na događaj (a ne dok glavni cjevovod vuče zadatak do izvršenja), zatim mehanizam kontroliranih prekida, IMHO, pa ono što je liječnik propisao.