Prekidi i posebni slučajevi. Primjeri prekida

Mehanizam prioriteta (PM) označava koji uređaji se prvo trebaju servisirati. MP rješava sljedeće zadatke:

Popravlja prioritet bilo kojeg programa koji izvršava procesor.

Identificira RFP od VU s najvišim prioritetom.

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

Prekid rutine usluge prekida naziva se ugniježđeni prekid.

Rice. 6.4 Primjer CPU-a u ugniježđenom režimu prekida.

Slika 6.4 prikazuje primjer ugniježđenog prekida:

Prije t 1 nema plate

t 1 → RFP od 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: Sa velikom učestalošću primanja plate, CPU ne radi efikasno, jer mnogo CPU vremena se troši na ZP, vraćanje registara procesora, prelazak s jednog programa na drugi.

Možete smanjiti frekvenciju ZP uključivanjem međuspremnika.

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

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

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

U porodici kompjutera Macintosh prioritet programa je naznačen u drugoj riječi VI.

U porodici kompjutera IBMPC prioritet programa se postavlja pomoću posebnog LSI (veliki integrirani krug) - programabilnog kontrolera prekida.

Tehnička implementacija višeslojnih ugniježđenih prioritetnih vektorskih prekida u računaru zasnovanom na jednom glavnom kanalu za razmjenu podataka.

Implementacija višeslojnih VI-ova u računarima porodiceIBM .

Za implementaciju višestepenog VI u računaru porodice IBM primijenjen LSI Intel 8259A.

Specifikacije za Intel 8259a.

Broj RFP nivoa = 8.

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

Programski se postavlja način rada za plaće, nivoi prioriteta, WUA.

Tehnička implementacija prioritetnih vektorskih prekida u računaru sa izolovanim magistralnim kanalima za razmenu podataka (porodica IBMAT): režimi rada programabilnog kontrolera prekida (SCP),

dijagram povezivanja centrale sa sistemskom magistralom,

Šema povezivanja centrale na VU sistemsku magistralu.

Rice. 6.7 Šema povezivanja centrale na sistemsku magistralu i centralu.

LSI dodjela pinova:

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

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

~ Cs (čip izaberite) - izbor kristala, omogućava ili onemogućuje komunikaciju kontrolera sa sistemskom magistralom.

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

Prva kontrolna tabla koristi adrese - 20 h, 21 h.

Drugi kontrolni panel 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) kontrolnog panela.

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

funkcionalni sastav i programski model centrale.

Prekini- radi se o promeni prirodnog redosleda izvršavanja programa, koja je povezana sa potrebom da sistem reaguje na rad eksternih uređaja, kao i na greške i posebne situacije koje su nastale tokom izvršavanja programa. Ovo zove poseban program - rukovalac prekida, specifičan za svaku nastalu situaciju, nakon čijeg izvršenja se nastavlja rad prekinutog programa.

Mehanizam prekida obezbjeđuje odgovarajući hardver i softver računara.

Klasifikacija prekida prikazana je na Sl. 7.1.

Rice. 7.1.

Zahtjevi za hardverski prekid nastaju asinhrono u odnosu na rad mikroprocesora i povezani su s radom vanjskih uređaja.

Zahtjev od neprekidi koji se ne mogu maskirati stiže na ulaz NMI mikroprocesor i ne može se softverski zaključati. Obično se ovaj ulaz koristi za traženje prekida od strujnih kola za kontrolu napajanja ili fatalnih I/O grešaka.

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

Softverski prekidi se, striktno govoreći, nazivaju izuzecima ili posebnim slučajevima. Povezuju se sa posebnim situacijama koje nastaju tokom izvršavanja programa (nedostatak stranice u RAM-u, kršenje zaštite, prelivanje), odnosno sa onim situacijama koje programer ne može da predvidi ili sa prisustvom posebne INT n komande u program, koji programer koristi za pozivanje funkcija operativnog sistema ili BIOS-a koji podržavaju rad sa vanjskim uređajima. U nastavku, kada govorimo o radu sistema za prekide, koristićemo jedan termin "prekid" za hardverske prekide i izuzetke, osim ako nije drugačije naznačeno.

Softverski prekidi su sljedećih tipova.

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

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

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

Nalog za rukovanje prekidom

Prekidi i izuzeci se prepoznaju na granicama instrukcija, a programer možda neće brinuti o stanju 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 - rukovalac 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 se sastoji od:

• "refleksne" akcije procesora, koje su iste za sve prekide i posebne slučajeve i koje programer ne može kontrolisati;
• izvršavanje rukovaoca kreiranog od strane programera.

Da bi mikroprocesor identifikovao izvor prekida i pronašao rukovaoca koji odgovara primljenom zahtevu, svakom zahtevu za prekidom se dodeljuje svoj broj ( tip prekida).

Tip 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 oni mogu biti kodirani u 1 bajt.

"Refleksne" akcije mikroprocesora na obradu zahtjev za prekid izvode se putem MP hardvera i uključuju:

• definicija tip prekida ;
• čuvanje 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 pohranjuju EIP i CS, definišući tačku povratka na prekinuti program, i registar oznaka EFLAGS. Ako se rukovalac prekida poziva pomoću kapije zadatka, tada je segment TSS stanja prekinutog zadatka u potpunosti pohranjen u memoriji;
• definicija adrese rukovalac prekida i prenošenje kontrole na prvu komandu ovog rukovaoca.

Nakon toga, program se izvršava - rukovalac prekida odgovara primljenom zahtjevu. Ovaj program piše i stavlja u memoriju aplikacijski ili sistemski programer. 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 rukovaoca prekida, mikroprocesora kada radi u realni mod koristi tabela 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 od jedinog TI tablični indikator v selektor segment pruža izbor samo između tabela 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 reset.

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

• trap gateway,
• interrupt gateway, pristupnik zadatka.

Watchdog tajmeri.

Č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“). Da bi se pratile takve situacije, u mikrokontroler su često uključeni watchdog tajmeri.

Ovaj uređaj uzrokuje da se mikrokontroler resetuje ako se njegov sadržaj ne ažurira u određenom vremenskom periodu (obično od nekoliko desetina milisekundi do nekoliko sekundi). Ako promjena sadržaja programskog brojača ne odgovara navedenom programu, naredba za modifikaciju watchdog timera neće se izvršiti. U ovom slučaju, watchdog timer resetuje mikrokontroler, postavljajući ga u prvobitno stanje.

Mnogi programeri ne koriste watchdog tajmere u svojim aplikacijama, jer ne vide potrebu da ih koriste za borbu protiv efekata električne buke, na primjer, kada postavljaju mikrokontroler u katodni displej u blizini transformatora koji obezbjeđuje prigušenje povratni put snopa, ili pored namotaja za paljenje u automobilu. U modernoj elektronici je malo vjerovatno da će doći do električnih smetnji, iako se ponekad javljaju u situacijama poput gore navedenih.

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

Mnogi korisnici vjeruju da su prekidi dio hardvera koji je najbolje ostaviti na miru, jer njihova upotreba zahtijeva odlično poznavanje procesora da bi se razvio rukovalac prekidom. U suprotnom, kada dođe do prekida, sistem "zaspi" ili "pedali". Ovaj osjećaj obično dolazi kod programera nakon iskustva s prekidima za personalni računar, koji ima niz karakteristika koje otežavaju kreiranje rukovaoca prekida. Mnogi od ovih problema se ne javljaju u hardveru zasnovanom na mikrokontroleru. Upotreba prekida u ovoj opremi može uvelike pojednostaviti njen dizajn i upotrebu.

Ako se nikada niste bavili prekidima, onda se postavlja pitanje - šta je to? U računarskom sistemu, prekid je pokretanje posebnog potprograma (koji se naziva "upravljač prekidom" ili "rutina usluge prekida") koji se pokreće hardverskim signalom. Tokom izvršavanja ovog potprograma, implementacija trenutnog programa je zaustavljena. Termin zahtjev za prekidom se koristi jer ponekad program odbija da potvrdi prekid i odmah izvrši rukovalac prekidom (slika 2.19).

Prekidi u kompjuterskom sistemu slični su prekidima u svakodnevnom životu. Klasičan primjer takvog prekida je telefonski razgovor tokom gledanja TV programa. Kada telefon zazvoni, imate tri opcije. Prvi je ignorisanje poziva. Drugi je da odgovorite na poziv, ali da kažete da ćete se javiti kasnije. Treće je da se javite na poziv, odgađajući sve tekuće poslove. Računarski sistem 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 obavljenog zadatka moguća je jedna od dvije opcije: resetovanje maske i omogućavanje servisa, što će dovesti do poziva rukovaoca prekida, ili analiza vrijednosti bitova („polling“). što ukazuje na dolazak zahtjeva za prekidom i direktno izvršavanje uslužnog programa bez pozivanja rukovatelja prekida. Ovaj metod rukovanja prekidom se koristi kada je potrebno da se obezbedi određeno vreme izvršavanja glavnog programa, pošto svaki prekid može da naruši implementaciju zahtevanog interfejsa.

Rice. 2.18 - Izvršavanje prekida.

Dugotrajno maskiranje prekida se ne preporučuje, jer se za to vrijeme može preklapati nekoliko događaja koji uzrokuju prekide, a samo će jedan biti prepoznat. Dozvoljeno 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 polovine minimalnog očekivanog perioda niza događaja koji zahtijevaju prekide.

Obrađivač prekida uvijek pruža sljedeći niz akcija:

2. Resetirajte kontroler prekida i hardver koji je izazvao 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 tokom obrade prekida, tako da se njihov sadržaj takođe mora sačuvati. Svi ostali registri su specifični za određeni mikrokontroler i njegovu primjenu.

Nakon resetiranja, kontroler prekida je spreman da prihvati sljedeći zahtjev, a oprema koja uzrokuje prekid je spremna da pošalje zahtjev kada je to prikladno. Ako stigne novi zahtjev za prekid, procesorov registar za maskiranje prekida će spriječiti 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 kod nekih tipova mikrokontrolera koji nemaju stek. Ovi prekidi također mogu uzrokovati probleme prelijevanja steka. Problem prelivanja je relevantan za mikrokontrolere zbog ograničene količine njihove memorije podataka i steka: niz ugniježđenih prekida može dovesti do činjenice da će više podataka biti gurnuto u stog nego što je dozvoljeno.

Konačno, prekid se obrađuje. Drugi TV primjer pokazuje da možete brzo odgovoriti na zahtjev za prekid prihvatanjem potrebnih podataka, koji će se potom koristiti nakon rješavanja trenutnog problema. U mikrokontrolerima se to implementira tako što se primljeni podaci pohranjuju u memorijski niz i zatim ih obrađuju kada se završi izvršavanje originalnog programa. Ovaj način servisiranja je dobar kompromis između trenutnog potpunog rukovanja prekidom, što može potrajati dugo, 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 prekida.

Razmotrite šta se dešava sa sadržajem različitih registara kada se obradi prekid. Sadržaj statusnog registra se obično automatski pohranjuje sa sadržajem softverskog brojača prije nego što se obradi prekid. Ovo eliminira potrebu za programskim pohranjivanjem u memoriju pomoću uputa za prijenos, a zatim vraćanjem kada se vratite na originalni program. Međutim, takvo automatsko spremanje nije implementirano u svim tipovima mikrokontrolera, stoga posebnu pažnju treba posvetiti organizaciji rukovanja prekidima.

Ako se sadržaj statusnog registra sačuva prije početka izvršavanja rukovaoca prekida, tada se na naredbi return automatski vraća.

Ako se sadržaj drugih registara procesora promijeni kada se izvrši usluga prekida, onda se on također mora sačuvati u memoriji prije promjene i vratiti prije povratka u glavni program. Uobičajena je praksa da se sačuvaju svi registri procesora kako bi se izbjegle nepredvidive greške koje je vrlo teško lokalizirati.

Adresa koja se učitava u programski brojač kada skoči na rukovalac prekida naziva se "vektor prekida". Postoji nekoliko vrsta vektora. Adresa koja se učitava u programski brojač kada se mikrokontroler pokrene (resetuje) naziva se "vektor resetovanja". Za različite prekide mogu se specificirati različiti vektori, eliminirajući potrebu da servisna rutina odredi uzrok prekida. Upotreba jednog vektora različitim prekidima obično ne stvara probleme mikrokontrolerima, jer najčešće mikrokontroler izvršava samo jedan program. Po tome se mikrokontroler razlikuje od personalnog računara, tokom čijeg rada se mogu dodati različiti izvori prekida. (Ako ste ikada povezivali 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 sa deljenjem vektora prekida.

Posljednja stvar koju treba uzeti u obzir su softverski prekidi. Postoje procesorske instrukcije koje se mogu koristiti za simulaciju hardverskih prekida. Najočitija upotreba ovih naredbi je pozivanje sistemskih rutina koje se nalaze na proizvoljnoj lokaciji u memoriji ili zahtijevaju međusegmentne skokove da im se pristupi. Ova funkcija je implementirana u familiji mikroprocesora Intel i86 i koristi se u osnovnom ulazno/izlaznom sistemu (BIOS) i DOS operativnom sistemu ličnih računara za pozivanje sistemskih rutina bez potrebe za popravkom ulazne tačke. Umjesto toga, različiti vektori prekida se koriste 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 će pokazati kako upotreba 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 učiniti po tom pitanju.

Jednostavan primjer je tajmer i njegov prekid prelivanja.
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, zavisno od države. I postoji samo jedan vektor.

Ili, na primjer, USART. Možda ćemo lako morati da izvršimo drugačiji kod u zavisnosti od načina prekida pri dolasku bajta. U jednom načinu - izdavanje pozdrava, u drugom - slanje opscenosti u kupatilo. U trećem, udarac u glavu. I postoji samo jedan vektor.

Naravno, možete dodati konstrukciju u slučaju prekida u rukovaocu prekida i odabirom moda ići na željeni dio koda, ali to je prilično glomazno, a što je najvažnije, vrijeme prijelaza će biti različito, ovisno o redoslijed kojim će se ići upoređivanje-polling-case switch-cause strukture.

To jest, u prekidaču oblika:

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

Doći će do uzastopnog poređenja x, prvo sa 1, zatim sa 2, zatim sa 3, i tako dalje dok se sve opcije ne nabroje. U ovom slučaju, reakcija na akciju 1 će biti brža od reakcije na akciju 4. Ovo je posebno važno kada se računaju tačni vremenski intervali na tajmeru.

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 direktno u indeksni registar Z) smjer gdje trebamo preusmjeriti naš vektor i umetnuti skok indeksa u rukovalac prekida. I voila! Prijelaz će biti tamo gdje trebate, bez ikakvog poređenja 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 našu varijablu sa željenom adresom

CLI; Kritični dio. Prekida OFF LDI R16, nizak (Timer_01); Uzmite adresu i sačuvajte STS Timer0_Vect_L, R16; 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 tajmer i čekati naš prekid. Isto je i sa drugim slučajevima.

A rukovalac je ovakav:

===============================; Unos prekida prekoračenja iz Timera0; ============================= TIMER_0: PUSH ZL; spremi indeksni registar na stek PUSH ZH; pošto koristimo ga PUSH R2; uštedite R2, jer pokvarimo i to IN R2, SREG; Preuzmi i sačuvaj PUSH R2 registar zastavice; Ako to ne učinite, tada će 100% dobiti greške LDS ZL, Timer0_Vect_L; učitati adresu novog vektora LDS ZH, Timer0_Vect_H; oba bajta. CLR R2; Brišemo R2 ILI R2, ZL; Provjera vektora za nulu. Inače, hajde da shvatimo analog OR R2, ZH; reset "a. Provjera ide kroz ILI operaciju BREQ Exit_Tm0; sa akumulacijom rezultata u R2; tako da ne kvarimo sadržaj Z i ne moramo; ponovo ga učitavamo IJMP; odlazimo sa novim vektorom ; Izlaz 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 šta NOP; po mogućnosti ne dugo - u NOP prekidu; Ako koristimo bilo koji drugi NOP; registre, onda 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; sačuvajte deset bajtova na povratnom kodu :))) 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 šta ako je naš program izgrađen na takav način da se sav kod rotira kroz lance zadataka preko RTOS menadžera? Vrlo je teško izračunati u svojoj glavi kako se ti lanci izvode jedan u odnosu na drugi. I svako od njih može pokušati da preuzme tajmer (naravno, ne proizvoljno, po našem podnesku, mi pišemo program, ali će biti teško na vrijeme pratiti koliko će sve biti teško).
U modernim glavnim osovinama postoji mehanizam Mutual Exclusion za ovaj slučaj - mutex. One. to je neka vrsta prometne zastave. Ako neki proces komunicira, na primjer, sa UART-om, onda se drugi proces ne usuđuje da tu stavi bajt 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. Barem napravite neki minimalan privid. Ne želim da radim potpunu implementaciju svega ovog smeća, jer moj cilj je zadržati veličinu kernela na 500-800 bajtova.
Najlakši način da rezervišete još jedan bajt u memoriji je varijabla zauzeto. A kada jedan proces zauzme resurs, onda u ovu varijablu upisuje vrijeme kada ga približno oslobađa. Vrijeme ide u otkucajima sistemskog tajmera, koji ja imam 1ms.
Ako bilo koji drugi proces pokuša pristupiti istom hardverskom resursu, prvo će pogledati stanje svoje zaposlenosti, izbrojati vrijeme tokom kojeg će biti zauzet i ostaviti da pušiti za ovaj period - učitat će se u red čekanja na tajmeru. Tamo će ponovo provjeriti i tako dalje. Ovo je najjednostavnija opcija.

Ovdje je problem u tome što ako ima mnogo zainteresovanih za jedan vektor, onda će se procesi i dalje odvijati unaokolo, poput mlaćenja mladih oko jedinog klozeta na trgu tokom prazničnih fešta. Nečija bešika to neće izdržati - algoritam će zeznuti. A ko ima smokve ovdje možete pogoditi, tk. biće teško simulirati.

Rješenje problema je dodavanje još jednog redovnog lanca, ovog puta za pristup resursu. Tako da uopšte ne stoji besposlen. One. jedan je iskočio, pa drugi, treći, i tako sve dok svi procesi ne oslobode potrebe za nekom vrstom USART-a.
Nedostatak je očigledan - drugi red je dodatna memorija, dodatni kod, dodatno vrijeme. Možete, naravno, biti izopačeni i postaviti kod glavnog dispečera lanca u redu 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 da stupi u kontakt ne bježi da popuši, već skače nekoliko koraka unazad - do kraja reda zadataka i odmah se vraća nazad. Ljudi oko toaleta ne trče okolo, već guraju laktove na ulazu po principu ko prvi prolazi.
Još jedan nedostatak je veliko opterećenje na glavnom cjevovodu, gomila zahtjeva za čekanje tako brzo napuhne cijeli RAM i ispuni stog, a to je preplavljeno globalnom apokalipsom.

Naravno, tajmer je ovde dat kao primer, većina zadataka se može rešiti pomoću RTOS sistemskog tajmera, ali ako vam odjednom zatreba manje diskretnosti ili visoka stopa reakcije na događaj (a ne dok glavni cevovod vuče zadatak do izvršenja), pa mehanizam kontrolisanih prekida, IMHO, pa ono što je lekar propisao.