---

BLOCK 1 — 1–2. előadás + 1–2. labor

---

Beágyazott rendszer: definíció

Mi ez? Olyan számítástechnikai rendszer, amelyet egy adott feladatra terveztek, és fizikailag egy nagyobb gép vagy eszköz részét képezi — szemben az általános célú PC-vel. A JVM-es analogia: olyan, mint egy single-purpose microservice, ami soha nem kap általános update-et, csak az adott interfészt implementálja.

Hogyan működik?

• A HW és SW együttesen kerül tervezésre (Hardware/Software Codesign)
• Az alkalmazás tartósan fut, jellemzően nincs „leállítás/újraindítás”
• A szoftver szorosan kötődik az adott célhardverhez

Exam trap detector ❌ “A beágyazott rendszer általános célú processzort és standard OS-t tartalmaz” — ez a general-purpose PC leírása; a beágyazott rendszer dedikált, sokszor nincs is OS ✅ A beágyazott rendszer egy adott feladatra optimalizált, fizikailag nagyobb rendszerbe épített számítógép

❌ “A beágyazott szoftver könnyen cserélhető, mint egy mobilalkalmazás” — épp ellenkezőleg: a helyszíni frissítés nehéz, a visszahívás drága ✅ A firmware frissítése komoly logisztikai és minőségbiztosítási kihívás

❌ “A beágyazott rendszerben a fejlesztők többsége HW-vel foglalkozik” — tipikusan 70–80% SW fejlesztő, HW <10% ✅ A fejlesztői kapacitás döntő hányada SW oldalon van

Must-know facts

• HW/SW codesign: szimultán HW és SW tervezés
• A hibák nagy részét a szoftver okozza, nem a hardware
• Tesztelés a fejlesztési munka ~70–90%-a

---

Valós idejű rendszer: definíció, hard vs. soft

Mi ez? Olyan rendszer, ahol a helyes működéshez nemcsak a számítási eredménynek, hanem annak időbeli pontosságának is teljesülnie kell. Spring Boot analógia: mintha egy REST endpoint válaszának nemcsak helyes adatot kellene visszaadnia, hanem garantáltan X ms-en belül, különben a rendszer hibásnak minősül.

Hard vs. Soft különbség:

Típus	Határidő megsértése	Példa
Hard real-time	Katasztrofális hiba (rendszer- vagy emberélet veszély)	Légitársaság fly-by-wire, ABS
Soft real-time	Degradált teljesítmény, nem katasztrófa	Videólejátszás, hálózati routing

Exam trap detector ❌ “Egy soft real-time rendszerben sosem szabad a határidőt megszegni” — soft esetén a határidő megszegése tolerálható teljesítménycsökkenést okoz, nem katasztrófát ✅ Soft RT rendszerben a késés degradált minőséget okoz, nem rendszerhibát

❌ “A hard real-time garantált reakcióidőt jelent ms-es pontossággal minden esetben” — a határidő maga rendszerspecifikus, nem feltétlenül ms-es; a lényeg a garantált worst-case ✅ Hard RT esetén a worst-case határidő megszegése megengedhetetlen

Must-know facts

• Hard RT: determinisztikus, garantált worst-case válaszidő
• Soft RT: statisztikusan teljesített, degradáció elfogadható

---

Valós idejű operációs rendszer (RTOS): definíció, követelmények

Mi ez? Olyan OS, amely determinisztikus ütemezést és garantált válaszidőt biztosít a futtatott feladatoknak. Nem csupán “gyors OS” — a lényeg a kiszámíthatóság, nem a sebesség.

Hogyan működik?

1. Prioritásalapú preemptív ütemező fut
2. Megszakítás-kezelési idő garantáltan felülről korlátolt
3. Erőforrások (memória, CPU-idő) determinisztikusan oszthatók fel
4. Nincs tetszőleges méretű kernel-puffer, ami késleltetést okozhatna

Exam trap detector ❌ “Az RTOS gyorsabb, mint egy általános OS” — az RTOS nem gyorsabb, hanem kiszámíthatóbb (determinisztikus) ✅ Az RTOS a worst-case válaszidőt garantálja, nem az átlagos sebességet

❌ “Linux RTOS, mert valós idejű feladatokat is futtat rajta” — a standard Linux nem RTOS, real-time patch nélkül nem garantál determinisztikus latency-t ✅ A standard Linux nem teljesíti a hard RT követelményeket

Must-know facts

• Példák: FreeRTOS, Zephyr, VxWorks, SafeRTOS
• SafeRTOS: IEC 61508 SIL 3 szerint minősített

---

Cyber-Physical System (CPS): definíció

Mi ez? A CPS olyan rendszer, ahol számítási folyamatok és fizikai folyamatok szorosan összefonódnak: a szoftver folyamatosan érzékeli és befolyásolja a fizikai világot visszacsatolásos hurkokban. Például: okos erőmű, önvezető jármű, ipari robot.

Hogyan különbözik az egyszerű beágyazott rendszertől?

• A fizikai és a kibernetikai alrendszer közötti visszacsatolás (feedback loop) alkotja a lényegét
• Jellemzően hálózatba kötött, elosztott
• Az időbeli és térbeli koincidencia kritikus

Exam trap detector ❌ “A CPS = beágyazott rendszer + internet” — ez az IoT leírása; a CPS-ben a hangsúly a fizikai–digitális visszacsatoláson van ✅ A CPS lényege az erős kibernetikai–fizikai kölcsönhatás, nem az internetkapcsolat

Must-know facts

• CPS-ben a fizikai folyamat is tervezett rendszerelemnek számít
• Valós idejűség és megbízhatóság kritikus

---

IoT/IIoT vs. CPS: mi különbözteti meg őket

Mi ez? Az IoT (Internet of Things) elsősorban az internetkapcsolaton és adatgyűjtésen van a hangsúly; az eszközök „bejelentkeznek” egy felhőszolgáltatásba. Az IIoT (Industrial IoT) ugyanez ipari kontextusban. A CPS ezzel szemben a fizikai világgal való szoros, visszacsatolásos kölcsönhatásra koncentrál, ahol a valós idejűség és a fizikai hatás meghatározó.

Szempont	IoT/IIoT	CPS
Fő hangsúly	Kapcsolódás, adatgyűjtés	Fizikai–digitális kölcsönhatás
Valós idejűség	Általában soft/nem RT	Sokszor hard RT
Visszacsatolás	Nem feltétel	Alapkövetelmény
Példa	Okoshőmérő, szenzorhálózat	Önvezető jármű, ABS

Exam trap detector ❌ “Az IoT és a CPS szinonimák” — az IoT nem feltétlenül valós idejű és nem feltétlenül van fizikai visszacsatolás ✅ Minden CPS jellemzően IoT-jellegű is, de nem minden IoT-eszköz CPS

---

CPS architektúra: rétegek és funkcióik

Mi ez? A CPS architektúra tipikusan három rétegre bontható, amelyek az érzékeléstől a döntéshozatalon át a beavatkozásig lefedik a rendszert.

Rétegek:

1. Fizikai/Érzékelő réteg (Physical/Perception layer): Szenzorok és aktuátorok; fizikai jelek digitalizálása és a digitális döntések fizikai végrehajtása
2. Hálózati/Kommunikációs réteg (Network layer): Az adatok továbbítása az érzékelőktől a feldolgozó egységek felé (pl. ipari buszok, IoT protokollok)
3. Alkalmazás/Döntési réteg (Application layer): Adatfeldolgozás, döntéshozatal, vizualizáció, vezérlési logika

Exam trap detector ❌ “A CPS hálózati rétege csak Ethernet-et és TCP/IP-t használhat” — ipari CPS-ben speciális buszok (pl. Profibus, CAN) is lehetségesek ✅ A CPS hálózati rétege bármilyen, az alkalmazásnak megfelelő kommunikációs technológiát alkalmazhat

---

Internet-technológia problémái CPS környezetben: valós idejűség, megbízhatóság, IT biztonság

Mi ez? A szokásos internetes protokollok (TCP/IP, HTTP) CPS-ben számos problémát vetnek fel, mert nem tervezték őket determinisztikus, biztonságkritikus, hosszú élettartamú rendszerekhez.

Problémák:

• Valós idejűség: A TCP/IP nem garantál determinisztikus átviteli időt; a jitter és a csomagvesztés elfogadhatatlan hard RT rendszerekben
• Megbízhatóság: Az internet “best-effort” alapú; CPS-ben garantált kézbesítésre van szükség
• IT biztonság: Az internetes protokollok nyitottak, a CPS-eszközök viszont hosszú élettartamúak (10–20+ év), és frissítésük nehézkes

Exam trap detector ❌ “A TCP garantálja a valós idejű adatátvitelt” — a TCP megbízható, de nem determinisztikus ✅ A TCP csak az adatok sorrendhelyes kézbesítését garantálja, a latency-t nem

---

IT biztonság és CPS: élettartam/tanúsítási kihívások

Mi ez? A CPS-eszközök élettartama sokszor 10–20 év, ezalatt az eredeti IT-biztonsági tanúsítványok elavulnak, a sebezhetőségek felhalmozódnak. A frissítések kiadása, tesztelése és alkalmazása beágyazott környezetben rendkívül költséges és kockázatos.

Kihívások:

• A termék minősítése (pl. IEC 61508, ISO 26262) adott SW-verzióhoz szól; ha a SW-t biztonsági frissítés miatt módosítjuk, az újraminősítés szükséges lehet
• A hosszú élettartam alatt új sérülékenységek kerülnek napvilágra
• A helyszíni SW-frissítés nehéz vagy lehetetlen (pl. ipari berendezés)

Must-know facts

• A tanúsítás és a frissíthetőség között alapvető feszültség áll fenn CPS rendszerekben

---

Szakterületi/alkalmazási szakértők szerepe CPS-ben

Mi ez? A CPS fejlesztéséhez elengedhetetlen a villamosmérnöki, gépészeti, szoftvertechnikai és alkalmazástudományi kompetenciák szoros együttműködése. A szoftvermérnök önmagában nem tudja megítélni pl. az ipari folyamat sajátosságait; a tartomány-szakértő (domain expert) nélkülözhetetlen.

Exam trap detector ❌ “Egy jó szoftvermérnök egyedül fejleszthet teljes CPS-t” — a CPS inherensen multidiszciplináris; a fizikai tartomány ismerete nélkül kritikus hibák fordulhatnak elő ✅ CPS fejlesztésben szükség van domain-specifikus szakértőkre (gépész, folyamatirányítási mérnök, stb.)

---

ANSI/IEC 60529-2004 (IP-védelmi osztály szabvány): alapok és hatókör

Mi ez? Az IP (Ingress Protection) kétjegyű kód, amely megadja, hogy egy burkolat milyen mértékben véd a szilárd részecskék (1. jegy) és folyadékok (2. jegy) behatolásával szemben. Beágyazott eszközök terepi alkalmazásánál alapkövetelmény a megfelelő IP-osztály meghatározása.

IP-kód értelmezése:

• 1. jegy (0–6): Szilárd test/por védelmi szint (pl. IP6X = teljesen porálló)
• 2. jegy (0–9): Folyadék elleni védelem (pl. IPX8 = folyamatos vízbe merítés)
• Pl. IP67: teljesen porálló + 1 m mélységű ideiglenes vízbe merítés ellen véd

Exam trap detector ❌ “Az IP68 jobb, mint az IP69” — a második szám skálája 0–9, de a 9-es (IP69) főleg nyomásos vízsugar ellen véd, nem a tartós merítés ellen; nem egyszerűen lineáris ✅ Az IP-osztályok különböző védelmi jellegeket írnak le, nem csak szintet

Must-know facts

• A szabvány teljes neve: IEC 60529, az ANSI adaptáció azonos tartalmú
• Hatóköre: elektromos berendezések burkolatainak védelmi fokozata

---

MIL-STD-810 szabvány: alapok, hatókör, mit ír elő és mit NEM

Mi ez? Az Egyesült Államok katonai szabványa, amely teszt-módszereket ír elő az eszközök környezeti terhelhetőségének vizsgálatára (rezgés, hő, páratartalom, por, ejtési teszt stb.). Nem tervez elő meghatározott minimumkövetelményeket — csak a tesztmódszereket rögzíti.

Mit MANDÁTÁL:

• Tesztmódszerek definícióit (hőmérséklet, páratartalom, magasság, rezgés, ütés, víz, por, stb.)
• A tesztelési eljárás menetét és eszközeit

Mit NEM MANDÁTÁL:

• Minimális teljesítési szinteket (hogy egy terméknek milyen MIL-STD-810 tesztet kell kiállnia, azt a beszerző/megrendelő határozza meg)
• Konkrét minimumértékeket (pl. „bírnia kell -40°C-ot”)

Exam trap detector ❌ “Az MIL-STD-810 megfelelőség garantálja, hogy az eszköz minden katonai alkalmazásban használható” — a megfelelőség csak azt jelenti, hogy bizonyos teszteket elvégeztek; a követelményszinteket a megrendelő határozza meg ✅ Az MIL-STD-810 tesztmódszertant definiál, nem teljesítési küszöbértékeket

Must-know facts

• Az MIL-STD-810 kereskedelmi termékek specifikálásában is elterjedt (pl. „rugged laptop”)
• A megfelelőségi szintet mindig az alkalmazási kontextus (megrendelő) határozza meg

---

Szenzor: definíció, alapműködés, főbb tulajdonságok

Mi ez? Fizikai mennyiséget (hőmérséklet, nyomás, gyorsulás stb.) mér és azt elektromos jellé alakítja. Arduino-analógia: az I2C-s BME280 szenzor pontosan ezt csinálja — a fizikai hőmérsékletet digitális értékké konvertálja.

Főbb tulajdonságok:

• Méréstartomány (range): Milyen értékközben mér
• Felbontás (resolution): Legkisebb megkülönböztethető változás
• Pontosság (accuracy): Mért és valós érték eltérése
• Linearitás: A mérési görbe lineárissága
• Válaszidő: Milyen gyorsan követi a fizikai változást
• Érzékenység (sensitivity): Egységnyi fizikai változásra adott jel

Exam trap detector ❌ “A nagy felbontású szenzor egyben pontosabb is” — a felbontás és a pontosság független: egy nagy felbontású de szisztematikus eltérésű szenzor pontatlan ✅ Felbontás és pontosság külön tulajdonság; megkülönböztetendők

---

Aktuátor: definíció, alapműködés, főbb tulajdonságok

Mi ez? Elektromos jelet fizikai hatássá alakít (mozgás, erő, fény, hő stb.). Inverz szenzor: a digitális világ hat vissza a fizikai világba.

Főbb tulajdonságok:

• Teljesítmény/erő: Milyen fizikai hatást képes kifejteni
• Vezérlési tartomány: Milyen bemeneti jelre reagál
• Válaszidő: Milyen gyorsan reagál a bemeneti jelre
• Visszacsatolás: Lehet nyílt vagy zárt hurkú vezérlés

Exam trap detector ❌ “Az aktuátor adatot küld a processzornak” — az aktuátor fizikai hatást fejt ki, nem adatot küld (a visszacsatoló szenzor az, ami adatot küld) ✅ Az aktuátor fizikai energiává/mozgássá/hatássá alakítja az elektromos vezérlőjelet

---

strace: cél és mechanizmus

Mi ez? Linux eszköz, amely egy folyamat által végrehajtott rendszerhívásokat és fogadott jeleket valós időben nyomkövet. Analógia: olyan, mint egy Spring Boot alkalmazásra tett @Around AOP proxy, ami minden kernel-interakciót naplóz — de nem módosítja a viselkedést.

Hogyan működik?

1. Az strace ./program hívja a ptrace() rendszerhívást a folyamat megfigyeléséhez
2. Minden rendszerhívásnál a kernel értesíti az strace-t (befagyasztja a folyamatot)
3. Az strace kiírja a hívást argumentumaival és visszatérési értékével
4. A folyamat folytatódik

Exam trap detector ❌ “Az strace csak az alkalmazási szintű függvényhívásokat figyeli” — az strace kizárólag a kernelhez intézett rendszerhívásokat látja, nem a libc vagy alkalmazás belső hívásait ✅ Az strace kernel/user-space határon működik, rendszerhívás szinten

Must-know facts

• Hasznos: milyen fájlokat nyit meg a program, milyen socketeket használ, mikor blokkol
• Overhead: az strace futtatás lelassítja a programot

---

Linux alkalmazás szerkezete: egy Linux program részei

Mi ez? Egy beágyazott Linux alkalmazás tipikusan az alábbi moduláris részekből áll — ezeket minden saját projektben meg kell valósítani:

Részek (sorrendben, indulástól):

1. Konfiguráció menedzsment (induláskor): default értékek betöltése, config fájl feldolgozás, CLI paraméter feldolgozás (precedencia: default < config fájl <10 CLI)
2. Stdin/stdout/stderr kezelés: Standard I/O csatornák kezelése
3. Naplózás (Logging): Log level kezelés syslog vagy saját rendszerrel
4. Jelzéskezelés (Signal handling): Legalább SIGINT (biztonságos leállítás)
5. Eseményhurok (Event loop): poll()/select()/epoll() alapú vagy többszálú architektúra + alkalmazáslogika

Exam trap detector ❌ “A Linux program induláskor a CLI-t dolgozza fel először, aztán a config fájlt” — a precedencia fordított: a CLI a legmagasabb prioritású, a config fájl ezt felülírhatja, de a CLI felülírja a config fájlt ✅ Precedencia: default (legalacsonyabb) → config fájl → CLI (legmagasabb)

---

stdin/stdout/stderr csatornák és I/O átirányítás

Mi ez? Minden Linux folyamat induláskor 3 megnyitott fájlleírót kap:

• FD 0 – stdin (standard input): Amit a terminálba gépelünk; átirányítható: prog < input.txt
• FD 1 – stdout (standard output): Normál kimenet; átirányítható: prog > out.txt vagy pipeline-ban: prog | wc -l
• FD 2 – stderr (standard error): Hibaüzenetek; átirányítható: prog 2> err.txt

Exam trap detector ❌ “A stderr ugyanoda megy, mint a stdout, ha nem irányítjuk át” — mindkettő alapértelmezetten a terminálra megy, de különálló fájlleírók; pipe csak a stdout-ot fogja meg ✅ A prog | next pipeline csak az stdout-ot továbbítja; a stderr a terminálra marad

Must-know facts

• File descriptor 0, 1, 2 — ezek a számok kötöttek
• 2>&1: stderr átirányítása stdout-ra

---

Konfiguráció menedzsment: általános cél és megközelítések

Mi ez? A konfiguráció menedzsment azt oldja meg, hogy az alkalmazás futtatási idejű paramétereit hogyan kezeljük. Nincs egyetlen szabványos megoldás; tipikus megközelítések kombinálhatók.

Megközelítések és precedencia:

1. Default értékek (legalacsonyabb prioritás): kódban inicializált globális struktúra
2. Konfigurációs fájl: INI, JSON, XML, YAML — pl. inih könyvtárral
3. CLI paraméterek (legmagasabb prioritás): getopt() feldolgozás

Tipikus konfigurációs fájlformátumok:

• INI (kulcs-érték, szekciókkal) — egyszerű, beágyazottban elterjedt
• JSON, XML — gazdagabb struktúra
• Futtatható script (BASH)

Exam trap detector ❌ “A konfigurációs fájl mindig felülírja a CLI paramétereket” — épp fordítva: a CLI a legmagasabb prioritású ✅ Default → config fájl → CLI; a CLI-t nem írja felül semmi

---

main() függvény prototípusok: CLI argumentumok és környezeti változók fogadása

Mi ez? A main() függvénynek két standard prototípusa releváns:

int main(int argc, char *argv[])
int main(int argc, char *argv[], char *envp[])

• argc: parancssori paraméterek száma (0. elem maga a program neve)
• argv[]: pointer-tömb a string paraméterekre; argv[0] = program neve
• envp[]: pointer-tömb a KULCS=ÉRTÉK formátumú környezeti változókra; NULL-lal záródik

Exam trap detector ❌ “argc az argumentumok száma a program nevét nem számítva” — az argc tartalmazza a program nevét is (argv[0]), tehát ha 2 argumentumot adunk meg, argc == 3 ✅ argc mindig legalább 1 (a program neve)

❌ “envp[] tömb hossza argc-vel egyenlő” — az envp[] és az argv[] teljesen független; az envp[] végét NULL jelzi ✅ Az envp[] tömb végét NULL pointer jelzi, nem argc

---

CLI paraméteres formák és kezelő eszközök: getopt() — fogalom és cél

Mi ez? A getopt() a POSIX standard C library függvénye, amely egybetűs opciókat (-x, -f filename) dolgoz fel az argv[] tömbből. A visszatérési értéke az aktuális opció karaktere, vagy -1 ha nincs több.

Szintaxis fogalmilag:

• getopt(argc, argv, "ab:h?") — az a argumentum nélküli, b: paraméteres opció
• A : a betű után jelzi, hogy az opciónak van argumentuma (optarg globálisban)
• Jellemzően while ciklusban + switch-csel feldolgozva

Exam trap detector ❌ “A getopt() hosszú opciókat is tud kezelni (pl. --version)” — a getopt() CSAK egybetűs opciókat kezel; hosszú opciókhoz getopt_long() kell ✅ A getopt() csak -x formátumú, egybetűs opciókat kezel

❌ “A getopt() maga elvégzi az értékek validálását” — a getopt() csak az opció-struktúrát elemzi; az értékek érvényességét a programozónak kell ellenőrizni ✅ A validáció (pl. szám tartomány) mindig a programozó feladata

Must-know facts

• optarg: az aktuális opció argumentumát tartalmazó pointer
• A getopt() > 60 egybetűs opciót tud kezelni (kis-nagybetű + számok + egyes jelek)

---

BLOCK 2 — 3. előadás + 3. labor

---

Beágyazott rendszer HW komponensei és interfészek áttekintése

Mi ez? Egy beágyazott rendszer tipikus HW komponensei: processzor (MCU vagy SoC), memória (SRAM, Flash, DRAM), perifériák (GPIO, UART, I2C, SPI, ADC/DAC, USB, hálózat) és az ezeket összekötő belső buszok (AHB, APB). Az interfészek hierarchikusan kapcsolódnak a processzorhoz.

Fontosabb belső buszok SoC-ban:

• AHB (Advanced High-performance Bus): gyors perifériák, DMA
• APB (Advanced Peripheral Bus): lassú perifériák

Exam trap detector ❌ “Minden periféria közvetlenül a CPU-hoz csatlakozik” — valójában perifériabuszon keresztül csatlakoznak, nem közvetlenül a CPU datapathhoz ✅ A perifériák memóriacímeken keresztül érhetők el (memory-mapped I/O)

---

Mikrokontroller vs. SoC: összehasonlítás

Mi ez? A mikrokontroller (MCU) egy chipen integrálja a CPU-t, memóriát és perifériákat — de korlátozott erőforrásokkal, jellemzően nincs MMU. A SoC (System on Chip) összetettebb: teljes rendszert tartalmaz egy chipen, általában alkalmazásprocesszorral, MMU-val, külső DRAM interfésszel.

Szempont	MCU	SoC
Teljesítmény	Alacsony–közepes	Közepes–magas
Memória	Beépített SRAM/Flash	Külső DRAM + Flash
MMU	Általában nincs	Van
Védelmi szintek	Általában nincs	Van
Tipikus OS	FreeRTOS, NoOS	Linux, Android
Példa	STM32, AVR	AM335x (BBB), i.MX8

Exam trap detector ❌ “Az MCU-n is futtatható Linux” — elvileg igen (pl. x86-os MCU), de az MMU hiánya miatt a standard Linux a legtöbb MCU-n nem fut; ahhoz MMU kell ✅ Linux futtatásához MMU szükséges; MCU-k többségén nincs MMU

---

Védelmi gyűrűk és az MMU szerepe SoC-ban

Mi ez? A modern processzor védelmi szinteket (privilege levels / rings) implementál; az x86-on ring 0–3, ARM-on EL0–EL3. A kernel ring 0-ban (EL1), a felhasználói program ring 3-ban (EL0) fut. Az MMU (Memory Management Unit) a virtuális→fizikai cím-fordítást végzi és jogosultság-ellenőrzést hajt végre: a user-space program nem férhet hozzá a kernel-memóriához.

Exam trap detector ❌ “Az MMU csak a cím-fordítást végzi, a hozzáférési jogokat nem” — az MMU page table-ekben jogosultsági biteket is tárol (read/write/execute, ring-szint) ✅ Az MMU egyszerre végez cím-fordítást és jogosultság-ellenőrzést

❌ “FreeRTOS MMU nélkül nem futtatható” — a FreeRTOS MMU nélküli MCU-kon is fut; az MMU nem feltétel a FreeRTOS számára ✅ A FreeRTOS MCU-kon, MMU nélkül is működik

Must-know facts

• MMU nélkül: single address space (minden szál/folyamat ugyanazt a fizikai memóriát látja)
• MMU-val: multiple address space (folyamatonként virtuális memória)

---

Kernel/user-space szétválasztás és következményei; Linux ebben a kontextusban

Mi ez? A kernel-space-ben fut az OS kernel (ring 0): teljes HW hozzáféréssel. A user-space-ben futnak az alkalmazások (ring 3): HW-hoz közvetlenül nem férhetnek hozzá, csak rendszerhívásokon keresztül. Ez az izolálás véd az alkalmazások hibái ellen (egy rossz app nem tudja összeomlasztani a kernelt).

Linux esetén:

• Minden I/O rendszerhíváson (syscall) keresztül megy
• A context switch kernel/user között overhead-et jelent (néhányszor 10 µs nagyságrendű)
• A GNU libc wrap-eli a syscall-okat — a Spring Boot @RestController-rel analóg: a libc az API, a syscall az ABI

Exam trap detector ❌ “A user-space program közvetlenül olvashat fizikai memória-mapped I/O regisztereket” — ezt nem teheti a védelmi gyűrűk miatt; ehhez /dev/mem vagy kernel driver szükséges ✅ User-space program csak fájlokon/rendszerhívásokon keresztül érheti el a HW perifériákat

---

Virtuális memória teljesítménye: általános eset és beágyazott következmények

Mi ez? A virtuális memória TLB (Translation Lookaside Buffer) gyorsítótáron keresztül működik; TLB miss esetén a page table bejárása szükséges (page walk) — ez overhead-et jelent. Beágyazott rendszerekben ez kritikus:

Következmények:

• Lapcsere (page fault): Ha a szükséges lap nincs a RAM-ban, a kernel cseréli — ez ~ms-es késleltetés, elfogadhatatlan hard RT rendszerekben
• TLB flush context switch-nél: Minden folyamatváltásnál a TLB-t ki kell üríteni (ha nincs ASID támogatás)
• Beágyazott kompromisszum: A virtuális memória védelmet ad, de determinizmus-t csökkent

Exam trap detector ❌ “Virtuális memóriával az alkalmazás mindig ugyanolyan gyorsan fut” — a page fault és TLB miss nem determinisztikus késést okozhat ✅ A virtuális memória kezelés nem determinisztikus latency-t vihet be, ami RT rendszerekben problémás

---

SoC, PoP, SoP, SoM, SBC: definíciók és megkülönböztetés

Mi ez? Különböző integrációs szintek, amelyek meghatározzák, mekkora funkcionális egység kerül egy modulba:

Rövidítés	Teljes név	Tartalom
SoC	System on Chip	CPU + memória vezérlő + perifériák — egy chipen
PoP	Package on Package	Két chip egymás tetejére rétegezve (pl. SoC + DRAM)
SoP	System on Package	Több chip egy tokozásban (más gyártóktól is)
SoM	System on Module	SoC + DRAM + Flash + regulátor + connector — egy kis PCB-n; BSP-vel szállítják
SBC	Single Board Computer	Teljes számítógép egy lapon: SoM vagy SoC + összes perifériával, csatlakozókkal

Exam trap detector ❌ “Az SBC és az SoM szinonimák” — az SoM egy komponens (modul), amit egy carrier boardba kell helyezni; az SBC már teljesen kész, önálló számítógép ✅ A SoM carrier board nélkül nem teljes rendszer; az SBC önállóan használható

Must-know facts

• BSP-t (Board Support Package) tipikusan SoC/PoP/SoP/SoM/SBC gyártó szállítja

---

getsubopt() és getopt_long(): alapcél

Mi ez?

• getsubopt(): Összetett opció-argumentumok (key=value,key2=value2 formátum) feldolgozására. Egy adott opció argumentumán belül szub-opciókat elemez. Pl. -s dev=/dev/ttyUSB0,speed=115200
• getopt_long(): Hosszú opciókat (--version, --output=file) kezel, visszafelé kompatibilis a getopt()-tal

Exam trap detector ❌ “A getopt_long() önmagában is kezeli a key=value formátumú al-opciókat” — ehhez getsubopt() is szükséges; a getopt_long() csak a --opció=értéket elemzi egy szinten ✅ Az összetett szub-opciókhoz (dev=...,speed=...) getsubopt() kell a getopt_long() mellé

---

Naplózás, log szintek, syslog.h használat

Mi ez? A naplózás az alkalmazás futási eseményeinek rögzítése, amely beágyazott rendszerekben elengedhetetlen a hibakereséshez (debugger helyett). Linux alatt a standard 8 log szint (syslog.h):

Érték	Kulcsszó	Leírás
0	emerg	Rendszer használhatatlan
1	alert	Azonnali beavatkozás szükséges
2	crit	Kritikus állapot
3	err	Hibakondíció
4	warning	Figyelmeztetés
5	notice	Normál, de figyelemre méltó
6	info	Tájékoztató üzenet
7	debug	Hibakeresési üzenet

syslog.h API: openlog(), syslog(), closelog(), setlogmask()

Exam trap detector ❌ “A setlogmask() szálbiztos (thread-safe)” — explicit ki van emelve, hogy a setlogmask() NEM szálbiztos ✅ A setlogmask() nem thread-safe; többszálú programban körültekintően kell használni

Must-know facts

• Modern Linux: a syslog() a journald-nak írja az adatot (/var/log/journal/)
• LOG_UPTO(level) makró: az adott szintig minden naplózandó

---

Naplózás beágyazott rendszerben jellemző kihívásai

Mi ez? A szokásos /var/log/ alapú naplózás beágyazott rendszerekben komoly problémákat vet fel:

Kihívások:

• Írható fájlrendszer nem feltétlenül áll rendelkezésre (pl. csak ROM)
• Ha van FLASH, az korlátolt írási ciklus-számmal rendelkezik (véges élettartam)
• Valódi eset: Egy BeagleBone Black-en egy rosszul naplózó program 2 hét alatt tönkretette a 4 GB-os eMMC-t
• Hálózati naplózás (remote syslog) hálózathiba esetén nem megbízható
• RAM disk mérete korlátozott; a naplók elveszhetnek újraindításnál

Exam trap detector ❌ “Beágyazott Linux-ban a /var/log mindig elérhető és írható” — semmi sem garantálja; read-only filesystem is lehetséges ✅ Beágyazott rendszerben a lokális naplózás problémás; a remote logging és FLASH kímélés kritikus szempont

---

BLOCK 3 — 4. előadás + 4. labor

---

Periféria szerkezete: interfész, regiszter-fájl és perifériafunkció

Mi ez? Minden periféria három logikai részre osztható:

1. Periféria funkció: A tényleges fizikai/elektronikus funkció (pl. UART adó-vevő lánc, ADC konverter áramkör)
2. Regiszter-fájl: Vezérlő, státusz és adatregiszterek — a CPU ezen keresztül kommunikál a perifériával
3. Busz interfész: A periféria és a rendszerbusz kapcsolata; a CPU ezen keresztül éri el a regisztereket

Exam trap detector ❌ “A CPU közvetlenül a periféria fizikai áramkörébe ír” — a CPU a regiszter-fájlon keresztül vezérli a perifériát, nem közvetlenül ✅ A periféria vezérlése regiszterek olvasásán/írásán keresztül történik

---

Periféria-címzés: dedikált I/O leképzés vs. memory-mapped I/O

Mi ez? Két módszer a perifériák elérésére:

	Dedikált I/O (port-mapped)	Memory-mapped I/O
Hozzáférés	Speciális I/O utasítások (x86: IN/OUT)	Normál memóriaolvasás/írás
Architektúra	Főleg x86	ARM, RISC-V és a legtöbb beágyazott
Kezelés OS-ben	Dedikált I/O tér	Virtuális memóriában leképzett

Exam trap detector ❌ “Memory-mapped I/O esetén a periféria regisztereket fájlként éri el a kernel” — ez a sysfs/chardev megközelítés; az alacsony szintű kernel driver közvetlenül a fizikai memória-leképzésen keresztül ír/olvas ✅ A kernel driver mmap-en keresztül éri el a periféria regisztereit; a sysfs/chardev csak a user-space interfész

---

Megszakítások periféria szinten

Mi ez? A periféria egy esemény (pl. fogadott adat, konverzió kész) hatására HW jelet küld a CPU megszakítás-vezérlőjének (NVIC/GIC), amely megszakítja az éppen futó kódot és az ISR-t (Interrupt Service Routine) hívja. Arduino analógia: attachInterrupt(pin, ISR, FALLING) — pontosan ezt konfigurálja.

Folyamat:

1. Periféria interrupt flag-et állít (státuszregiszterben)
2. Interrupt vezérlő (NVIC/GIC) prioritás-alapon továbbítja a CPU-nak
3. CPU menti a kontextust, ISR-t futtat
4. ISR törli a flag-et, visszatér
5. CPU visszaállítja a kontextust

Exam trap detector ❌ “A megszakítás automatikusan törli az interrupt flag-et a periférián” — a legtöbb perifériánál az ISR-nek kell explicit törölni a flag-et, különben végtelen megszakítás-vihar alakul ki ✅ Az interrupt flag törlése az ISR felelőssége

---

Regiszter-fájl szerkezete: vezérlő, státusz, adatregiszterek

Mi ez? Minden periféria regiszter-fájlja logikailag három típusú regisztert tartalmaz:

• Control register (vezérlő): A periféria konfigurálása (engedélyezés, üzemmód, interrupt engedélyezés)
• Status register (státusz): A periféria aktuális állapota (adatkész flag, hiba flag, interrupt forrás)
• Data register (adat): Adatcsere — a CPU olvas belőle vagy ír bele (pl. UART RX/TX buffer)

Exam trap detector ❌ “A státuszregiszter írásával konfigurálható a periféria” — a státuszregiszter olvasásra való (jelzi a periféria állapotát); konfiguráláshoz a vezérlőregiszter az eszköz ✅ Vezérlőregiszter = konfigurálás; státuszregiszter = állapot-lekérdezés

---

PIN konfiguráció és funkciója

Mi ez? A SoC lábai (PIN-ek) tipikusan több funkcióra konfigurálhatók (multiplexálás). Egy fizikai PIN lehet GPIO, UART TX, I2C SDA, PWM kimenet stb. — de egyszerre csak egy funkció aktív. BeagleBone-on: minden PIN-nek 0–7 modusa van, a 7-es általában GPIO.

Konfigurálás módjai:

• Device tree (boot-time): statikus PIN-kiosztás
• config-pin program: futási időben módosítható
• Regiszter-fájl közvetlen írása (Pad Control Registers)

Exam trap detector ❌ “A PIN alapértelmezett funkciója RESET után minden SoC-on GPIO” — BBB esetén a 7-es mód (GPIO) az alapértelmezett a legtöbb CAPE PIN-re, de ez SoC és board specifikus ✅ A PIN alapértelmezett funkciójat a board dokumentációjából kell megtudni; általánosítás hibás

---

GPIO interfész szabályai: logikai szintek, áramkorlátok bemenet/kimenet

Mi ez? Az alkalmazásprocesszoros (AP) GPIO lábak jellemzően 3,3V logikai szinttel dolgoznak, és kritikus áramkorlátokkal rendelkeznek:

Főbb szabályok:

• AP GPIO szinte mindig 3,3V (vagy kisebb!), nem 5V toleráns — ne csatlakoztass Arduino (5V) jelet közvetlenül!
• Kimeneti meghajtóképesség tipikusan 2–5 mA AP-on (Arduino-n ~40 mA)
• Bemeneten soha ne vigy a logikai tápnál magasabb feszültséget (tönkremegy)
• RESET után általában magas impedanciájú bemenet (pull-up/pull-down ellenállással)

Exam trap detector ❌ “Az AP GPIO kimenete 20–40 mA áramot tud meghajtani” — ez Arduino (ATmega) érték; AP-on (pl. BBB AM335x) tipikusan 2–5 mA a meghajtóképesség ✅ AP GPIO kimeneti árama 2–5 mA; erősebb terheléshez tranzisztor vagy driver IC szükséges

❌ “Az AP GPIO bemenete tolerálja az 5V-os bemeneti jelet” — szinte soha; 3,3V-os rendszerben 5V bemeneten tönkreteheti a PIN-t ✅ AP GPIO bemeneti feszültséget sosem szabad a tápfeszültségnél nagyobbra vinni

---

ADC/DAC alapok: kvantálás, jelhatár, mintavételi frekvencia, on-demand vs. timed mintavételezés

Mi ez?

• ADC (Analog-to-Digital Converter): Analóg jelet digitálissá alakít; felbontása a bitek száma (pl. 12 bites = 4096 lépés), a kvantálási hiba ±½ LSB
• DAC (Digital-to-Analog Converter): Digitálisból analóg; hasonló felbontás-fogalmak

Kvantálás:

• A kvantálási lépés: LSB = Vref / 2^n (ahol n a bitek száma)
• Minél több bit, annál finomabb felbontás

Mintavételezési módok:

• On-demand (single conversion): A CPU kéri az egyszeri konverziót, megvárja az eredményt
• Timed (continuous/triggered): Időzítő vezérelt, DMA-val az eredmény automatikusan memóriába kerül; CPU nem foglalkozik vele

Nyquist-Shannon: A mintavételi frekvenciának legalább kétszerese kell a jelek legmagasabb frekvenciájának

Exam trap detector ❌ “Az ADC felbontása és pontossága azonos fogalmak” — a felbontás a bitek száma által meghatározott lépések száma; a pontosságot az erősítő- és referenciafeszültség-hibák is rontják ✅ Felbontás ≠ pontosság; egy 12-bites ADC nem feltétlenül 12 bites pontosságú

---

Digitális komponensek közötti kommunikáció: I2C, SPI, UART alapok

Mi ez? A három leggyakoribb digitális soros kommunikációs protokoll beágyazott rendszerekben:

Szempont	I2C	SPI	UART
Vonalak	2 (SDA, SCL)	4+ (MOSI, MISO, SCK, CS)	2 (TX, RX)
Topológia	Busz (több eszköz)	Csillag (CS-enként)	Pont-pont
Sebesség	~100k–400k–3,4M bps	Több MHz	Beállított baud rate
Cím	7/10 bites	CS vonallal	Nincs
Master/slave	Igen	Igen	Nincs

Exam trap detector ❌ “Az UART is master/slave protokoll” — az UART aszimmetrikus, de nincs master/slave hierarchia; mindkét fél önállóan adhat/fogadhat, és nincs cím ✅ Az UART szimmetrikus pont-pont összeköttetés cím nélkül

---

I2C és SPI vs. UART — adathozzáférési szempontból

Mi ez? Az I2C és SPI eszközök egy regiszter fájlon keresztül érhetők el: a buszon lévő IC-nek belső regiszterei vannak (pl. hőmérő hőmérséklet-regiszter), és a kommunikáció lényege ezek read/write-ja. Az UART ezzel szemben egy szabad formátumú kommunikációs csatorna: nincs belső regiszter-modell, az adatot közvetlenül küldik/fogadják — olyan, mint egy TCP socket, ahol az alkalmazásszint definiálja a protokollt.

Hogyan különböznek:

Szempontok	I2C / SPI	UART
Adatmodell	Regiszter fájl (cím → regiszter)	Szabad byte-folyam
Protokoll	HW definiált (eszközcím + regisztercím)	Alkalmazás definiálja
Szinkronizáció	Órajel (SCL/CLK)	Baudrate egyezés (aszinkron)
Tipikus eszközök	Szenzorok, EEPROM, D/A	Konzol, GPS modul, modem

Exam trap detector ❌ “Az UART is regiszter-alapú, hiszen a soros port periféria regisztereket tartalmaz a CPU-ban” — az UART periféria rendelkezik regiszterekkel a CPU oldalán, de maga a kommunikációs modell szabad formátumú; a regiszter-modell a csatlakoztatott külső eszközre vonatkozik ✅ Az I2C/SPI esetén a külső eszköz regisztereit olvasod/írod; UART esetén csak byte-folyamot küldesz

❌ “Az I2C-n egy adott eszköznek csak egy címe lehet” — az LM92 például 2 lábbal 4 különböző cím között állítható; több azonos IC is felkerülhet a buszra ✅ Az I2C 7-bites cím alapján 128 eszközt különböztet meg; egyes eszközök hardveres lábakon keresztül változtatható alapcímmel rendelkeznek

Must-know facts

• I2C: 2 vezéték (SCL, SDA), 100/400 kHz, 7 bites cím
• SPI: minimum 4 vezéték (CLK, MISO, MOSI, CS)
• UART: 2 vezéték (TX, RX), aszinkron, baudrate egyezés szükséges

---

BeagleBone — áttekintés, konzol, jogosultságok

Mi ez? A BeagleBone Black (BBB) egy SBC (Single Board Computer) TI AM3358 SoC-cal (Cortex-A8, max. 1 GHz), 512 MB RAM és 4 GB eMMC tárolóval. A konzolport (soros) a mérnök legfontosabb eszköze: a SoC már bootkori üzeneteket küld ki rajta, és ez egyben a Linux konzol is.

Konzol és jogosultságok:

• Fizikai csatlakozó: J1 tüskesor — GND = PIN1, RX = PIN4, TX = PIN5; 3,3 V logikai szint, 5V-ot NEM visel el!
• Baudrate: 115200; USB–UART átalakítóval érhető el PC-ről
• Linux alatt a soros porthoz (/dev/ttyUSBx) a user alapból nem fér hozzá — Permission denied
• Megoldás: sudo adduser $USER dialout → user hozzáadása a dialout csoporthoz, majd új session szükséges

Exam trap detector ❌ “A BBB konzolportja 5V toleráns, mint az Arduino” — a BBB AP pinjei 3,3V-osak, 5V-ot nem viselnek el ✅ A BBB minden GPIO és UART pinje maximum 3,3V logikai szinttel dolgozik

❌ “A dialout csoport hozzáadása azonnal érvénybe lép” — az új csoporttagság csak új bejelentkezési session-ben aktív ✅ A csoporthoz adás után kilépés/belépés (vagy SSH újraindítás) szükséges

Must-know facts

• BBB: TI AM3358 SoC, Cortex-A8, 512 MB DDR3, 4 GB eMMC
• Konzol: UART0, J1, 115200 baud, 3,3V
• PIN-enkként max. 8 funkció konfigurálható (0–7), alapértelmezett RESET után: 7-es = GPIO

---

BLOCK 4 — 5. előadás + 5. labor

---

Beágyazott SW fejlesztési problémák gyökerei

Mi ez? A beágyazott szoftverfejlesztés problémái nem véletlenszerűek — visszavezető okok: a HW és SW egyszerre fejlődik, a tesztelési lehetőség korlátozott, és a fejlesztők jellemzően nem ismerik kellőképpen az alkalmazási tartományt.

Fő gyökérokok:

1. HW/SW párhuzamos fejlesztés: A szoftvert olyan HW-ra kell írni, ami még nincs kész (szimulátorral, prototípussal)
2. Korlátozott erőforrások: Kis memória, lassú CPU, nincs swap
3. Valós idejű követelmények: A timing hibák funkcionális hibának számítanak
4. Komplex szoftverhibák aránya: A hibák ~70–90%-a szoftver-oldali; tesztelés a fejlesztési munka ~70–90%-a
5. Domain tudás hiánya: A szoftvermérnök nem érti a fizikai folyamatot

Exam trap detector ❌ “A beágyazott HW megbízhatóbb, mint a szoftver, ezért a hibák többsége HW-s” — pontosan fordítva: a hibák nagy része SW-s ✅ A beágyazott projektek sikerét leginkább a szoftverminőség határozza meg

---

Beágyazott szoftver (firmware): főbb tulajdonságok, különbségek a „klasszikus” szoftvertől

Mi ez? A firmware olyan szoftver, ami szorosan kötött a célhardverhez, tartósan fut (nincs „újraindítás”), és frissítése komoly logisztikai kihívás. Szemben a webalkalmazással, nem törheti meg a futást, és nem számíthat tetszőleges erőforrásra.

Fő különbségek:

Tulajdonság	Klasszikus SW	Firmware
Futtatási környezet	PC/szerver, általános OS	Specifikus HW, dedikált OS
Frissíthetőség	OTA, App Store	Nehéz, drága, kockázatos
Erőforrások	Bőséges (GB RAM, swap)	Korlátozott (MB RAM, nincs swap)
Hibatűrés	OS elkapja a hibát	Rendszer leállhat/lefagyhat
Időbeli viselkedés	Soft RT elvárható	Sokszor hard RT kötelező

Must-know facts

• A firmware helyszíni frissítése problémás: tanúsítás, visszahívás, OTA megbízhatóság
• A firmware sokszor a HW-val együtt szállítják, és a vevő nem frissíti

---

BSP (Board Support Package): pontos definíció és jellemzők

Mi ez? A BSP az a szoftvercsomag, amely az adott hardverplatformhoz szükséges minden alacsony szintű szoftvert tartalmaz: bootloader, kernel konfigurációt/patcheket, driver-eket és az alaplap-specifikus inicializációs kódot. Analógia: olyan, mint egy Spring Boot application.properties + pom.xml + HW-specifikus beanek együttese egy adott deploymenten.

Tipikus BSP tartalom:

• Bootloader (pl. U-Boot)
• Linux kernel konfiguráció + HW-specifikus patchek
• Device tree (HW leírás Linuxhoz)
• Alaplap-specifikus driverek
• Gyári tesztek, alap rootfs

Exam trap detector ❌ “A BSP tartalmazza az alkalmazás logikát is” — a BSP csak az OS és a HW közötti réteget fedi le; az alkalmazás a BSP-re épül ✅ A BSP az OS és a célhardver közötti illesztőréteget biztosítja

❌ “A BSP-t általában az alkalmazás fejlesztőcsapat írja” — a BSP-t tipikusan a HW gyártó vagy SoC gyártó szállítja; az alkalmazásfejlesztő erre épít ✅ A BSP tipikusan a hardver gyártójától (TI, NXP, stb.) érkezik

---

OS típusok beágyazott rendszerekben: NoOS, rejtett OS, beágyazott OS

Mi ez? Beágyazott rendszerekben az OS jelenléte egy spektrumon helyezkedik el — a nulla OS-től a teljes általános célú OS-ig.

Típus	Leírás	Előny	Hátrány
NoOS	Nincs OS; végtelen ciklus + megszakítások	Determinisztikus, kis méret	Nincs ütemezés, kézzel kell mindent kezelni
Rejtett OS (hidden OS)	Framework/RTOS belső ütemezőjét a fejlesztő nem látja expliciten (pl. Arduino)	Egyszerű API, gyors fejlesztés	Korlátozott rugalmasság, rejtett overhead
Beágyazott OS	RTOS (FreeRTOS, Zephyr) vagy Linux; az OS explicit jelen van	Taszkkezelés, szinkronizáció, driverek	Erőforrásigény, komplexitás

Exam trap detector ❌ “A NoOS megoldás nem alkalmas valós idejű feladatokra” — a NoOS hard real-time feladatokra is alkalmas lehet, ha az ütemezést és megszakításokat a fejlesztő kézzel kezeli ✅ A NoOS determinisztikus viselkedése egyes hard RT feladatokhoz ideális

---

Körforgó (Round-Robin) ütemezés: felépítés és tulajdonságok

Mi ez? A legegyszerűbb kooperatív ütemező stratégia MCU-kban: minden taszkot sorban, egyszer lefuttatják a végtelen ciklusban. Nincs prioritás, nincs preempció. Spring Boot analógia: egyetlen szálon futó @Scheduled taskok sorozata, ahol egy taszk blokkolása mindenkit blokkol.

Felépítés:

while(1) {
 task1();
 task2();
 task3();
}

Tulajdonságok:

• Egyszerű, determinisztikus sorrend
• Nincs preempció: ha egy taszk soká fut, a többi vár
• Nincs valódi prioritás
• Nem alkalmas valós idejű feladatokra, ahol egyes taszkoknak garantált rövid válaszidő kell

Exam trap detector ❌ “A Round-Robin ütemezés garantálja az egyenlő CPU-időt” — a klasszikus beágyazott Round-Robin nem időosztásos; a taszk annyi ideig fut, amennyi ideig akar (kooperatív) ✅ A beágyazott Round-Robin kooperatív: minden taszk maga adja vissza a vezérlést

---

Körforgó megszakítással (Round-Robin with interrupts): felépítés és tulajdonságok

Mi ez? A körforgó alap-hurok kiegészül megszakításkezelőkkel (ISR-ekkel), amelyek aszinkron futnak és flageket állítanak. A fő hurok ezeket a flageket ellenőrzi és reagál rájuk.

Felépítés:

// ISR: gyors kezelő, csak flaget állít
ISR_timer() { flag_timer = 1; }
// Fő hurok:
while(1) {
 if(flag_timer) { handle_timer(); flag_timer=0; }
 task1();
}

Előny: Időkritikus esemény (pl. szenzor interrupt) gyorsan kezelődik az ISR-ben; a hosszabb feldolgozás a fő hurokban marad.

Exam trap detector ❌ “Az ISR-ben elvégezhető az összes feldolgozás, a fő hurok üresen futhat” — az ISR-nek rövidnek kell lennie (megszakítja az összes többi folyamatot); a hosszú feldolgozást flag+főhurok mintával kell kezelni ✅ Az ISR csak flageket állít és jelzi az eseményt; az érdemi feldolgozás a fő hurokban történik

---

Függvény-sor ütemezés (Function-Queue Scheduling): felépítés és tulajdonságok

Mi ez? Az ISR nem flageket állít, hanem callback függvényeket tesz egy sorba (queue); a fő hurok ezt a sort üríti sorban. Spring Boot analógia: @Async metódusok egy BlockingQueue-n átmennek a worker thread-hez.

Felépítés:

// ISR: függvényt tesz a sorba
ISR_uart() { queue.push(handle_uart_data); }
// Fő hurok:
while(1) {
 fn = queue.pop();
 if(fn) fn();
}

Tulajdonságok:

• Rugalmasabb a sima Round-Robin+flag-nél
• Könnyen bővíthető új eseménykezelőkkel
• Sorrend megmarad (FIFO)
• Még mindig egyszálú, nincs párhuzamos végrehajtás

---

Framework rejtett OS-sel: előny és hátrány

Mi ez? Olyan fejlesztési megközelítés, ahol egy magasabb szintű framework (pl. Arduino, mbed) elfedi a belső RTOS/ütemező működését; a fejlesztő event callback-eket ír, nem foglalkozik explicit taszkkezeléssel.

Előny: Gyors fejlesztés, alacsonyabb belépési szint, a HW-specifikus részeket a framework kezeli.

Hátrány: A rejtett OS korlátai nem nyilvánvalóak; nehéz befolyásolni a timing-ot és a prioritásokat; debug nehezebb, mert az OS viselkedése fekete doboz.

Exam trap detector ❌ “A rejtett OS teljesen eliminálja a valós idejű problémákat” — a rejtett OS is rendelkezik belső ütemezővel, amelynek viselkedése nehezebben befolyásolható, és épp ezért a timing garanciák nehezebbek ✅ A rejtett OS kényelmes, de a fejlesztő elveszíti az ütemezés feletti közvetlen kontrollt

---

FreeRTOS: alapvető tulajdonságok; SMP MCU OS előnyök/hátrányok

Mi ez? A FreeRTOS egy nyílt forráskódú, kis lábnyomú RTOS MCU-khoz. Preemptív prioritásos ütemező, taszkok, queues, szemaforok és mutexek állnak rendelkezésre.

FreeRTOS jellemzők:

• Minimális RAM/ROM igény (akár ~10 KB ROM)
• Portolható: ARM Cortex-M, -R, -A, RISC-V, stb.
• SafeRTOS: IEC 61508 SIL 3 minősített változat
• Egymagos MCU-ra optimalizált; SMP (Symmetric Multiprocessing) támogatás újabb verzióban van

SMP MCU OS előnyök/hátrányok:

Szempont	Előny	Hátrány
SMP MCU OS	Több mag kihasználható, több feladat párhuzamosan	Szinkronizációs problémák, cache-koherencia, drágább HW
Egymagos RTOS	Egyszerűbb, determinisztikusabb	Korlátozott párhuzamosság

Exam trap detector ❌ “A FreeRTOS teljes POSIX API-t valósít meg” — a FreeRTOS saját API-t használ (xTaskCreate, xQueueSend stb.), nem POSIX-kompatibilis; a Zephyr sem teljesen ✅ A FreeRTOS saját, nem-POSIX API-val rendelkezik; a POSIX inkább Linux/embedded Linux területe

---

Linux: alapvető tulajdonságok beágyazott kontextusban

Mi ez? A Linux egy általános célú, preemptív, többfeladatos OS, amelyet beágyazott rendszerekben is széles körben alkalmaznak (Raspberry Pi, BBB, ipari számítógépek). Nem hard real-time alapból, de PREEMPT_RT patchcsel valós idejű viselkedés közelíthető.

Jellemzők beágyazott kontextusban:

• Gazdag driver-ökoszisztéma
• POSIX API: hordozható kód
• Memória minimum: ~32–128 MB RAM szükséges (sokkal több, mint FreeRTOS)
• Nem determinisztikus alapból (ütemező jitter)
• Bootidő: másodpercek (vs. ms FreeRTOS-nál)
• Szükséges: MMU (virtuális memória kezeléshez)

---

FreeRTOS/Zephyr vs. Linux választási kritériumok

Mi ez? A döntés elsősorban a szükséges erőforrásokon, a valós idejű követelményeken és a rendelkezésre álló HW-n alapul.

Kritérium	FreeRTOS/Zephyr	Linux
RAM	~KB–MB	~32–128+ MB
MMU szükséges?	Nem	Igen
RT garancia	Igen (RTOS)	Csak PREEMPT_RT-vel
Driver-ök	Korlátozott	Gazdag ökoszisztéma
Bootidő	ms	Másodpercek
Fejlesztési nehézség	Alacsonyabb (kisebb rendszer)	Magasabb (teljes OS stack)

Döntési szabály: Ha nincs MMU, vagy a RAM néhány MB alatt van → FreeRTOS/Zephyr. Ha gazdag hálózati/fájlrendszer/UI stack kell → Linux.

Exam trap detector ❌ “Linuxot MCU-kon is futtathatunk, ha elég gyors a CPU” — Linux MMU-t igényel; MCU-k tipikusan nem rendelkeznek MMU-val ✅ Linux futtatásának alapkövetelménye az MMU megléte

---

Jelkezelés lépései: generálás, kézbesítés, diszpozíció

Mi ez? A Linux jelzések (signals) aszinkron értesítési mechanizmus: a kernel (vagy másik folyamat) értesíti a fogadó folyamatot egy eseményről. Analógia: olyan, mint egy JVM Thread.interrupt(), de OS szinten.

Három fázis:

1. Generálás (Generation): A jel előáll — pl. kill() rendszerhívással, Ctrl+C billentyűre (SIGINT), hardveres kivételre (SIGSEGV)
2. Kézbesítés (Delivery): A kernel ténylegesen eljuttatja a jelet a folyamathoz; ez a futási állapottól függ (ha a folyamat vár, fel kell ébreszteni)
3. Diszpozíció (Disposition): A folyamat reagál a jelre — elkapja (handler), figyelmen kívül hagyja (ignore), vagy az alapértelmezett OS-akció fut le (pl. terminálás)

---

Lehetséges reakciók jelzésekre

Mi ez? Minden jelre háromféle reakció lehetséges:

1. Alapértelmezett (Default): Az OS hajtja végre — legtöbb jelnél terminálás (pl. SIGTERM, SIGKILL), néhánynál core dump (SIGSEGV), másoknál ignorálás (SIGCHLD)
2. Elkapás (Catch): A program saját signal handler függvényt regisztrál (sigaction()); ha a jel érkezik, a handler fut le
3. Ignorálás (Ignore): A jelet eldobjuk — SIG_IGN handlerrel; SIGKILL és SIGSTOP NEM ignorálható és NEM kapható el!

Must-know facts

• SIGKILL (9): nem elkapható, nem ignorálható — azonnali terminálás
• SIGTERM (15): elkapható és ignorálható — “kérés” a leállásra
• SIGINT: Ctrl+C hatása, elkapható (SIGINT handler = biztonságos leállítás implementálása)

---

Jelkezelés Linux programban: melyeket kell kezelni és miért

Mi ez? Egy jól megírt beágyazott Linux alkalmazásnak legalább a SIGINT-et (Ctrl+C) és a SIGTERM-et kell elkapnia, hogy biztonságosan tudjon leállni: lezárja a fájlokat, elengedi az erőforrásokat, visszaállítja a GPIO-kat.

Miért nem lehet néhányat elkapni:

• SIGKILL: az OS garantált „azonnali halál” mechanizmusa — ha elkapható lenne, egy program sosem lenne leállítható
• SIGSTOP: az OS garantált szüneteltetési mechanizmusa

Tipikus handler struktúra:

volatile sig_atomic_t running = 1;
void handler(int sig) { running = 0; }
// main(): while(running) { ... }

Exam trap detector ❌ “A SIGTERM jelzés nem kapható el, ezért nem kell kezelni” — a SIGTERM elkapható; éppen azért van, hogy a program rendezett leállást hajthasson végre ✅ A SIGTERM elkapható és le kell kezelni; a SIGKILL az, ami nem kapható el

---

Jelzések hatása blokkoló API hívásokra: sleep() példán

Mi ez? Ha egy signal érkezik egy blokkolt rendszerhívás közben (pl. sleep()), a hívás idő előtt visszatér EINTR hibakóddal. Analógia: Java-ban a Thread.sleep() InterruptedException-t dob, ha a szálat megszakítják.

Mechanizmus:

1. Folyamat sleep(10) → blokkoló állapotba kerül
2. SIGINT érkezik → kernel kézbesíti
3. A signal handler lefut
4. A sleep() visszatér — nem 10 másodperc eltelte után, hanem azonnal, EINTR-rel (vagy 0-val a maradék idővel)

Következmény a kódban:

// Helyes megközelítés:
while(running) {
 sleep(1); // ha EINTR jön, a while ellenőrzi a running flag-et
}

Exam trap detector ❌ “A sleep() jelzés hatására megszakad, de a signal handler után folytatja a hátralevő időt” — a standard sleep() visszatér, nem folytatja; a maradék idő elvész (hacsak nem kezeljük) ✅ A sleep() EINTR-rel tér vissza; a maradék alvási idő elvész, hacsak újra nem hívjuk

---

BLOCK 5 — 6. előadás + 6. labor

---

Rendszerhívás programozói szemszögből: API vs. ABI

Mi ez? A programozó az API-t hívja (pl. read() a glibc-ből), ami egy magas szintű C wrapper. Ez a user space-ben fut és kiváltja a tényleges rendszerhívást. A tényleges kernel-átmenet az ABI-n (Application Binary Interface) keresztül történik — ez architektúrafüggő, processzor-szintű mechanizmus (szoftver-megszakítás, syscall utasítás stb.).

Réteg	Hol fut	Mit lát a fejlesztő
API (glibc read())	User space	C függvényhívás
ABI (syscall mechanizmus)	User/Kernel határ	Regiszterek, syscall szám
Kernel handler	Kernel space	Tényleges IO végrehajtás

Exam trap detector ❌ “Az API és az ABI szinonimák; mindkettő a rendszerhívás interfészét jelenti” — az API a fejlesztőnek látható magas szintű felület; az ABI az alacsony szintű bináris formátum ✅ Az API user space-ben fut és elrejti az ABI részleteit; az ABI architektúra-specifikus

---

Tipikus I/O művelet folyamata Linuxban

Mi ez? A Linux I/O eseményvezérelt: az alkalmazás rendszerhívást indít, blokkolódik, a kernel elvégzi az alacsony szintű IO-t, a periféria megszakítással jelez, a kernel felébreszti a várakozó taszkot.

Lépések:

1. Alkalmazás meghívja pl. read() → user space API → syscall ABI → kernel belép
2. Kernel elindítja az IO műveletet (kernel mode)
3. Az alkalmazás blokkoló várakozó (Waiting) állapotba kerül; más taszk futhat
4. A periféria megszakítást küld, jelezve az IO végét
5. OS fut, az IO-ra váró taszkot Futásra kész (Ready) állapotba helyezi
6. Ütemező lefuttatja a taszkot → read() visszatér az adattal

---

Linux kernel interface: device fájlok és IOCTL

Mi ez? Linuxban „minden fájl” — a perifériák /dev/ alatti device fájlokon keresztül érhetők el. Konfigurálásuk az open() opciókkal és az IOCTL mechanizmussal lehetséges.

Device fájl típusok:

• Character device: Tetszőleges méretben adja az adatokat (akár 1 byte) — pl. /dev/ttyS0 (UART), /dev/i2c-1
• Block device: Rögzített méretű blokkokban — pl. storage (/dev/sda)

IOCTL: Eszközspecifikus parancsok küldése device fájlon keresztül; pl. UART sebesség, I2C eszközcím beállítása. Nem standard read()/write(), de ugyanazon fájlleírón keresztül.

Must-know facts

• Kivétel a „minden fájl” szabály alól: hálózati interfészek (Ethernet) — ezeknek socket() + ioctl() a kezelési útja

---

Kernel vs. user-mode driverek: összehasonlítás

Mi ez? A driverek alapvetően kernel módban futnak, de bizonyos esetekben user-space driverek is megvalósíthatók.

Szempont	Kernel driver	User-space driver
Futás helye	Kernel space	User space
Hiba hatása	Kernel panic (OS összeomlik!)	Csak az alkalmazás hal meg
Fejlesztési nehézség	Magas	Alacsonyabb
Sebesség	Gyorsabb	Overhead-je van
Mikor?	Nagy sebesség, megosztott HW	I2C, SPI, USB (libusb), TUN/TAP
Dinamikus betöltés	insmod/rmmod/modprobe	N/A

Exam trap detector ❌ “Egy hibás user-space driver kernel panic-ot okozhat” — user-space driver hiba csak az alkalmazást viszi el, a kernelt nem; ez a fő előnye ✅ Kernel driver hiba kernel panic-ot okoz; user-space driver hiba csak az adott alkalmazást érinti

---

Beágyazott periféria életciklusa

Mi ez? A beágyazott rendszer perifériáinak kezelése az egész rendszer életciklusát le kell fedenie: a tápfeszültség megjelenésétől a rendszer leállásáig.

Tipikus fázisok:

1. Tápfeszültség megjelenik (sokszor több tápfeszültség szekvenciálisan)
2. OS betöltés (bootloader → kernel → rootfs)
3. Alkalmazás betöltés és futás
4. Meghibásodások kezelése (watchdog, újraindítás)
5. Rendszerleállás — az SD kártya/flash különösen érzékeny nem szabályos leállásra (fájlrendszer sérülés!)

Must-know facts

• A flash/SD kártya áramkimaradásra érzékeny; a rendszerleállást mindig szabályosan kell végrehajtani
• Ipari rendszerekben átmeneti táplálást (szuperkondenzátor, akkumulátor) alkalmaznak a szabályos leálláshoz

---

GPIO: tipikus funkciók, tulajdonságok, használati minták

Mi ez? A GPIO (General Purpose Input/Output) bináris digitális be- vagy kimenet. Az AP-kon szinte mindig 3,3V logikai szint, tipikusan 2–5 mA meghajtási képesség.

Főbb tulajdonságok:

• Jelszint: AP-kon szinte mindig 3,3V (nem 5V-toleráns!)
• Meghajtási képesség: 2–10 mA (AP-on tipikusan 2–5 mA)
• Megszakítás: felfutó élre, lefutó élre, szintre konfigurálható
• RESET utáni alapállapot: jellemzően bemeneti (high-impedance) mód
• PIN konfiguráció: device tree (boot-time) vagy config-pin (runtime)

Exam trap detector ❌ “Az AP GPIO pinjei 5V-toleránsak, mint sok Arduino pin” — AP GPIO-k szinte mindig 3,3V-osak, 5V bevitelük tönkreteheti az IC-t ✅ AP-okon a GPIO logikai szint 3,3V; 5V-ot nem viselnek el

---

GPIO SW architektúra Linuxban

Mi ez? A Linux GPIO-t a kernel gpiolib kezeli, amely két user-space interfészt kínál: az elavult sysfs-alapút és a modern chardev-alapút.

Rétegek:

1. HW GPIO vezérlő (gpiochip)
2. Kernel gpiolib (egységes absztrakció)
3. User-space: sysfs (/sys/class/gpio/) VAGY chardev (/dev/gpiochipX)

Must-know facts

• BBB: 4 db 32-bites GPIO modul = 128 GPIO (gpiochip0–3)
• gpiochip0 mindig kap tápot; a többi csak normál működési módban

---

sysfs vs. chardev GPIO elérés: összehasonlítás

Mi ez? Két különböző Linux user-space GPIO interfész, különböző érettségi és használhatósági szinttel.

Szempont	sysfs	chardev
Elérési út	/sys/class/gpio/	/dev/gpiochipX
Státusz	Elavult	Támogatott (kernel 4.8+)
Hozzáférés	Shell-ből is (echo)	Csak programozottan (ioctl)
Többszörös GPIO	Problémás (resource sharing)	Megfelelően kezeli
Újabb AP-k (pl. TI AM6x)	Nem feltétlenül implementálva	Igen

Exam trap detector ❌ “A sysfs GPIO interfész az ajánlott, modern megoldás” — a sysfs elavult; a chardev az ajánlott ✅ Kernel 4.8-tól a chardev a támogatott GPIO user-space interfész

---

Linux I2C alrendszer: kernel driver vs. user-space elérési módok

Mi ez? A Linux teljes I2C alrendszert biztosít, amelyen belül kétféle megközelítés lehetséges: az I2C eszközhöz írt kernel driver (az eszköz /dev vagy /sys alatt jelenik meg), vagy user-space I2C elérés a busz device fájlán keresztül.

Megközelítések:

1. I2C eszköz-specifikus kernel driver: Az I2C eszköz (pl. hőmérő) saját kernel modulja van → az adatok pl. /sys/class/hwmon/ alatt olvashatók (pl. lm-sensors)
2. User-space I2C: Az I2C busz (/dev/i2c-X) jelenik meg eszközként; a user-space program ioctl() hívásokkal kommunikál közvetlenül; eszközspecifikus protokollt a program implementálja

• C-ből: libi2c-dev; parancssori: i2ctools (i2cdetect, i2cdump, i2cget, i2cset)

Exam trap detector ❌ “User-space I2C eléréshez kernel driver szükséges az I2C eszközhöz” — user-space I2C eléréskor az eszköz nem rendelkezik kernel driverrel; a buszra közvetlenül írunk/olvasunk user-space-ből ✅ User-space I2C esetén csak a busz alacsony szintű kernel drivere kell, az eszköznek nincs saját kernel drivere

---

libusb: alapvető tulajdonságok és mikor használjuk

Mi ez? A libusb egy multiplatform user-space könyvtár, amely lehetővé teszi az USB eszközök közvetlen elérését kernel driver nélkül. Több nyelven is elérhető (C, Python, Java, Rust stb.).

Mikor használjuk:

• Ha az eszköz nem implementál standard USB device class-t (HID, MassStorage, Audio, CDC/ACM)
• Régi HW-hoz, amelynek nincs kernel drivere
• Fejlesztés alatt álló beágyazott eszközhöz, amely egyedi protokollt használ
• Ha a HW-t egyetlen alkalmazás használja (nincs szükség OS-szintű megosztásra)

Mikor NE használjuk:

• Ha az eszköz standard class-t implementál → a kernel automatikusan kezeli

---

TUN és TAP: az alap ötlet

Mi ez? A TUN és TAP virtuális hálózati interfészek, amelyek lehetővé teszik, hogy egy user-space alkalmazás hálózati csomagokat fogadjon és küldjön — mintha egy fizikai hálózati kártya lenne, de az adatok egy alkalmazásba kerülnek.

	TUN	TAP
Szint	IP (3. réteg)	Ethernet (2. réteg)
Cím	IP cím szükséges	Bridge-be tehető
Tipikus use-case	VPN (IP tunnel)	Virtualizáció (VM hálózat)

Tipikus alkalmazások:

• VPN implementációk (OpenVPN, WireGuard)
• Virtualizáció (VirtualBox, QEMU/KVM)
• Nem standard hálózati HW kezelése (Zigbee, UWB, Matter)

---

BeagleBone SBC: felépítés és a konzol port szerepe

Mi ez? A BBB esetén a konzol port (UART0, J1 tüskesor) a fejlesztői debuggolás alapeszköze: a SoC már a boot-folyamat legelején, HW szinten erre logol, és ez lesz a Linux konzol is. A mérnök igazi barátja — mert a rendszer akkor is kommunikál rajta, ha a hálózat/USB még nem működik.

Konzol port jellemzők:

• J1 tüskesor: GND=PIN1, RX=PIN4, TX=PIN5
• 115200 baud, 3,3V CMOS logikai szint
• USB–UART átalakítóval érhető el PC-ről
• Linux alatt: dialout csoport szükséges

---

GPIO elérés sysfs-en keresztül: kimenet konfigurálása, érték beállítása

Mi ez? A klasszikus (elavult, de ZH-n releváns) sysfs GPIO kezelés parancssori fájlmüveletekkel történik.

Lépések:

# 1. PIN exportálása user-space kezelésbe
echo 69 > /sys/class/gpio/export

# 2. Irány beállítása kimenetre
echo out > /sys/class/gpio/gpio69/direction

# 3. Érték beállítása
echo 1 > /sys/class/gpio/gpio69/value # HIGH
echo 0 > /sys/class/gpio/gpio69/value # LOW

# 4. Visszaadás kernelnek (opcionális)
echo 69 > /sys/class/gpio/unexport

Megszakítás sysfs-ből:

echo rising > /sys/class/gpio/gpio69/edge
# utána poll()-al vagy select()-tel várhatsz rá

---

fflush(): miért fontos a file I/O korrektségéhez

Mi ez? A C stdio réteg buffereli a fájlba írást — fprintf(fp, "1") nem kerül azonnal a fájlba (pl. /sys/class/gpio/gpioX/value), hanem az OS buffer tárolja. Ha a GPIO-t azonnal reagálnia kell, fflush(fp) szükséges, ami kikényszeríti a buffer kiürítését.

Miért különösen kritikus beágyazott rendszerekben:

• GPIO value fájlba írva a LED nem villan fel, ha a buffer nem ürül
• A sleep() előtt mindig fflush() kell GPIO vezérlésnél
• Rendszerleálláskor puffert nem ürített adat elveszhet

Exam trap detector ❌ “A fprintf() azonnal kiírja az adatot a fájlba” — a stdio layer bufferel; az adat a kernel bufferbe kerül, nem feltétlenül a fizikai eszközre ✅ fflush() szükséges a buffer azonnali kiürítéséhez és a fizikai eszköz frissítéséhez

---

BLOCK 6 — 7. előadás + 7. labor

---

Rendszerhívás, várakozás és blokkolás: mechanizmus

Mi ez? A rendszerhívások alapértelmezetten blokkolnak: addig nem térnek vissza, amíg a kiszolgálás meg nem történt. A kernel addig más taszkot futtathat.

Blokkolás feltételei:

• A kért adat elérhető legyen a lokális memóriában (olvasásnál)
• A küldött adat kernel buffer-be kerüljön (írásnál) — nem feltétlenül a fizikai eszközre; fflush()/fsync() kényszeríti ki a fizikai írást

Nem blokkoló alternatíva: O_NONBLOCK flag az open()-ban → azonnal visszatér 0 byte-tal, ha nincs adat.

---

Feladat állapotok és állapotátmenetek: háttér és következmények

Mi ez? Egy Linux taszk/szál élete során az alábbi állapotokat veszi fel (egyszerűsített modell). Minden állapotátmenet mögött megszakítás áll (HW, szoftver megszakítás = syscall, vagy kivétel).

Állapotok:

Létrejön → Futásra kész (Ready) → Fut (Run)
 ↑ ↓
 Esemény bekövetkezik Lemond / elveszíti a CPU-t
 ↑ ↓
 Eseményre vár (Waiting) ← Rendszerhívás blokkolódik
 ↓
 Befejeződik

Következmények:

• Futó állapotban egyszerre annyi taszk lehet, ahány CPU mag van
• Ha semmi sem fut: idle taszk fut (power management)
• Az OS preemptív ütemező egy megszakítás (timer) segítségével veszi el a CPU-t a futó tasktól

---

Polling vs. megszakítás: összehasonlítás

Mi ez? A periféria állapotváltozásának észlelésére két alapvető stratégia létezik.

Szempont	Polling	Megszakítás
CPU használat	100% (folyamatos lekérdezés)	Minimális (csak eseménynél)
Válaszidő	Jobb lehet (ha fut a taszk)	Minimum n*10 µs overhead
Linuxban	Nem blokkoló rendszerhívás	Blokkoló rendszerhívás
Megbízhatóság	Ütemezéstől függ	Kernel garantálja (extrém terheléstől eltekintve)

Exam trap detector ❌ “A polling gyorsabban reagál, mint a megszakítás minden esetben” — polling csak akkor gyorsabb, ha a taszk éppen fut; ha más taszk fut, nem veszi észre az eseményt ✅ Polling válaszideje az ütemezéstől függ; megszakítás garantált minimális overhead-del reagál

---

Megszakítás buktatói (interrupt pitfalls)

Mi ez? A megszakítások helytelen kezelése a leggyakoribb hibaforrás beágyazott rendszerekben.

Fő buktatók:

• Túl hosszú ISR: Más megszakítások elmaradnak; rendszer látszólag lefagy
• Shared data race: Ha az ISR és a fő kód ugyanazt a változót írja/olvassa atomi garancia nélkül → race condition (ahogy Java-ban volatile nélkül)
• ISR-ben blokkoló hívás: ISR-ben tilos blokkoló OS API-t hívni (pl. sleep(), mutex lock)
• Elveszett megszakítás: Ha az ISR nem törli a megszakítás-flag-et, végtelen megszakítás loop; ha a flag törlése előtt jön egy új, elveszhet

---

poll() rendszerhívás: szerepe és alkalmazása

Mi ez? A poll() lehetővé teszi, hogy egy szál egyszerre több fájlleírót figyeljen eseményre (olvashatóság, írhatóság, hiba) anélkül, hogy aktívan polling-olna. A kernel blokkolva tartja a taszkot, és megszakítás alapon ébreszti fel, amikor valamelyik FD esemény bekövetkezik.

Tipikus alkalmazása:

• Több GPIO bemenet egyszerre figyelése (sysfs edge + poll)
• UART + GPIO egyszerre
• Szerver alkalmazásban több kliens socket figyelése egy szálon

CPU hatás: A poll() blokkolva vár → CPU-t felszabadítja más taszkoknak; POLLIN eseménynél ébred fel.

---

Többszálú architektúra: szerepe és alkalmazása

Mi ez? Ahelyett, hogy poll()-al egy szálban figyelünk sok eseményt, minden eseményforráshoz (GPIO, UART, hálózat) dedikált szálat rendelünk, amely blokkolva vár a saját forrására. Spring Boot analógia: minden endpoint saját @Async worker thread-en fut.

Előnyök: Egyszerűbb kódstruktúra; minden szál a saját forrásával foglalkozik. Hátrányok: Megosztott erőforrások szinkronizációja szükséges (mutex, rwlock); nagyobb stack memória; context switch overhead.

---

poll() vs. többszálú architektúra: összehasonlítás

Szempont	poll()	Többszálú
Komplexitás	Alacsonyabb (egy szál)	Magasabb (szinkronizáció)
Szálak száma	1	N (forrásokként)
Megosztott adat	Nem probléma	Mutex kell
Válaszidő	Egyenletes	Párhuzamos kezelés
Tipikus alkalmazás	Sok FD, kevés esemény	Intenzív I/O blokkok

---

Erőforrás, megosztott erőforrás, kölcsönös kizárás: definíciók

Mi ez?

• Erőforrás: Minden, amire a program működéséhez szüksége van — CPU, memória, fájl, periféria, hálózati kapcsolat
• Megosztott erőforrás: Olyan erőforrás, amelyet több taszk/szál egyidejűleg is elér — pl. globális változó, GPIO, nyomtatósor
• Kölcsönös kizárás (Mutual Exclusion): Garantálja, hogy a megosztott erőforrást egy időben csak egy taszk módosítja (kritikus szekció)

Exam trap detector ❌ “Kölcsönös kizárás szükséges minden megosztott olvasáshoz” — ha csak olvasunk (read-only), kölcsönös kizárás nem szükséges; az rwlock pont erre optimalizált ✅ Kölcsönös kizárás csak akkor kötelező, ha legalább egy hozzáférő ír

---

Passzív vs. aktív várakozás: összehasonlítás

Mi ez?

• Aktív várakozás (Busy waiting / Spinlock): A taszk folyamatosan ellenőrzi a feltételt (while(!ready){}); 100%-os CPU-t használ, de azonnali a reakció
• Passzív várakozás (Blocking wait): A taszk várakozó állapotba kerül (OS elveszi a CPU-t); a CPU más taszkoknak felszabadul; esemény hatására ébredül fel

	Aktív	Passzív
CPU használat	100%	~0% várakozás közben
Válaszidő	Azonnali	OS overhead (~10 µs)
Alkalmazás	Rövid várás, RT kritikus	Hosszú várás, általános eset

---

Linux kölcsönös kizárási mechanizmusok: áttekintés

Mi ez? Amikor több szál közös memóriát (változót, struktúrát, perifériát) oszt meg, a kölcsönös kizárás (mutual exclusion) gondoskodik arról, hogy egy időben csak annyi szál férjen hozzá az erőforráshoz, amely mellett a helyes működés garantálható. Linux user-space-ben a POSIX API biztosítja az eszközöket.

Elérhető POSIX megoldások:

• POSIX mutex — bináris szemafor; tetszőleges erőforráshoz; passzív várakozás
• POSIX rwlock — olvasók-írók zár; sok olvasó, ritka írás esetén hatékony
• POSIX user-space spinlock — aktív várakozás; nagyon rövid kritikus szakaszhoz
• POSIX feltételi változó (conditional variable) — szinkronizáció eseményre; mindig mutex-szel együtt
• (POSIX szemafor: nem ajánlott; inkább mutex-et használj)

Exam trap detector ❌ “A spinlock passzív várakozást hajt végre, akárcsak a mutex” — a spinlock aktívan vár (busy-wait): folyamatosan lekérdezi a lock állapotát, 100%-on tartja a CPU-t ✅ A mutex passzívan vár (az OS várakozási sorba teszi a szálat); a spinlock aktívan vár

---

Mutex, rwlock, spinlock: API-felszín és összehasonlítás

Mi ez? Mindhárom mechanizmus a #include <pthread.h> fejlécből érhető el, és azonos életciklus-mintát követ: init → lock → unlock → destroy.

Összehasonlítás:

Szempont	Mutex	rwlock	Spinlock
Várakozás típusa	Passzív (OS sor)	Passzív (OS sor)	Aktív (busy-wait)
Olvasó/Írás megkülönböztetés	Nem	Igen	Nem
Rendszerhívás?	Igen	Igen	Nem (userspace)
CPU mikor hasznos?	Hosszú várakozás	Sok olvasó, ritka írás	µs-os rövid kritikus szakasz
Egyprocesszoros veszély	Nincs	Nincs	Deadlock (RT FIFO osztályban)
Inicializálás	PTHREAD_MUTEX_INITIALIZER	PTHREAD_RWLOCK_INITIALIZER	Nincs statikus makró

Kulcs API:

// Mutex
pthread_mutex_lock(&m); // blokkoló zárás
pthread_mutex_trylock(&m); // nem blokkoló, EBUSY hiba
pthread_mutex_unlock(&m);

// rwlock
pthread_rwlock_rdlock(&rw); // olvasásra zár
pthread_rwlock_wrlock(&rw); // írásra zár
pthread_rwlock_unlock(&rw);

// Spinlock
pthread_spin_lock(&s);
pthread_spin_unlock(&s);

Exam trap detector ❌ “A spinlock rendszerhíváson keresztül hívja a kernelt, mint a mutex” — a spinlock user-space-ban valósul meg, nincs kernel-átmenet; ez teszi gyorsabbá rövid várakozásnál, de energiapazarlóvá ✅ A spinlock nem valódi rendszerhívás — az API-ban van megvalósítva, nem hívja meg a kernelt

❌ “Az rwlock írásra zárva is megengedi az olvasást” — írásra lezárt rwlock-nál senki nem léphet be sem írásra, sem olvasásra; csak az éppen írást végző szál férhet az erőforráshoz ✅ Írásra zárt rwlock: 0 olvasó + 1 író; olvasásra zárt: N olvasó + 0 író

---

Várakozási mechanizmusok Linuxban: sleep(), usleep(), nanosleep()

Mi ez? A három hívás egy szál futásának szüneteltetésére szolgál, különböző felbontással. Mindhárom blokkoló rendszerhívás (a szál Waiting állapotba kerül), és signal hatására EINTR-rel térhet vissza idő előtt.

Függvény	Felbontás	Fejléc	Megjegyzés
sleep(n)	másodperc	<unistd.h>	Egész másodpercek; signal megszakítja
usleep(n)	mikroszekundum (µs)	<unistd.h>	Elavult (nanosleep ajánlott helyette)
nanosleep(&req, &rem)	nanoszekund (ns)	<time.h>	POSIX; visszaadja a hátralévő időt signal esetén

Miért érdemes nanosleep()-t preferálni:

• Felbontás ns-os (bár az OS nem garantál ns-os pontosságot)
• A rem paraméterben visszaadja a megszakadt alvás maradék idejét
• Hordozható (POSIX), ellentétben az usleep()-pel

Exam trap detector ❌ “A nanosleep() pontosan a megadott nanoszekundum értékre vár” — a kernel minimális alvási ideje a timer felbontásától (HZ, tipikusan 1–10 ms) függ; a nanoszekundumos érték csak egy kérés, nem garancia ✅ A nanosleep() legalább a megadott ideig vár, de a tényleges ébredés az OS ütemezőn múlik

---

Rendszeridő formátumok: time_t (UNIX időbélyeg) és timespec struktúra

Mi ez? Linuxban kétféle időábrázolás dominál a programozásban. Spring Boot analógia: time_t ≈ Instant.getEpochSecond(), timespec ≈ Instant (nanoszekundum pontossággal).

time_t — UNIX timestamp:

• Egész szám (tipikusan long): 1970-01-01 00:00:00 UTC óta eltelt másodpercek
• Olcsó tárolás, de csak másodperces felbontás
• time(NULL) adja vissza az aktuális értéket

struct timespec — nagy felbontású idő:

struct timespec {
 time_t tv_sec; // másodpercek
 long tv_nsec; // nanoszekumdok (0–999 999 999)
};

• clock_gettime(CLOCK_ID, &ts) tölti fel
• nanosleep(), pthread_cond_timedwait() is ezt használja

Exam trap detector ❌ “A time_t nanoszekumdos felbontású” — a time_t csak másodperces; nanoszekumdos felbontáshoz struct timespec szükséges ✅ A struct timespec két mezőből áll: tv_sec (másodpercek) + tv_nsec (nanomásodpercek)

---

CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC, CLOCK_REALTIME: viselkedés és különbségek

Mi ez? A clock_gettime() különböző óraforrásokhoz fér hozzá; a helyes megválasztása kritikus az időmérés pontosságához.

Óra	Visszaállítható?	NTP korrekció?	Tipikus használat
CLOCK_REALTIME	Igen (pl. settimeofday())	Igen (ugrásszerű)	Naplózás, fájlidők, emberi idő
CLOCK_MONOTONIC	Nem	Kis NTP finomhangolás (gradual)	Időintervallum mérés (ajánlott)
CLOCK_MONOTONIC_RAW	Nem	Nem (nyers HW órajel)	Precíz teljesítménymérés, NTP-mentes

Legfontosabb szabályok:

• Időintervallum méréséhez soha ne használj CLOCK_REALTIME-ot — az NTP vagy a felhasználó visszaállíthatja, és hamis értéket kapsz
• CLOCK_MONOTONIC: monotonan növekvő, NTP kis korrekciókat végezhet → stabil, de NTP befoly.
• CLOCK_MONOTONIC_RAW: NTP-től teljesen független nyers HW órajel → a legszigorúbb időméréshez

Exam trap detector ❌ “A CLOCK_MONOTONIC és CLOCK_REALTIME ugyanolyan megbízható időintervallum-méréshez” — a CLOCK_REALTIME visszaállítható, ami hamis időkülönbséget eredményez; a CLOCK_MONOTONIC monotonan növekvő ✅ Időintervallum-méréshez CLOCK_MONOTONIC vagy CLOCK_MONOTONIC_RAW ajánlott; a CLOCK_REALTIME visszaugordhat

---

Bemeneti kezelési stratégiák: polling, polling sleep-pel, poll() kernel megszakítással — CPU hatás

Mi ez? Ez az összehasonlítás a ZH egyik leggyakrabban előforduló témája. Mindhárom stratégia ugyanarra a kérdésre ad választ: „hogyan derítsük ki, hogy megnyomtak-e egy gombot?” — de nagyon különböző CPU-hatással.

Stratégia	Hogyan működik	CPU terhelés	Válaszidő
Folyamatos polling	while(1) { read(fd, ...); } nem blokkoló	100% — más taszk nem tud futni	Maximális (ha fut a taszk)
Polling sleep-pel	while(1) { read(...); sleep(1); }	Alacsony — alvás közben más futhat	Romlik (legfeljebb 1s késés)
poll() kernel megszakítással	poll(fds, 1, -1); blokkoló	Minimális — csak eseménynél ébred	Minimális overhead (~n×10 µs)

Részletek:

• Folyamatos polling: az OS-ben O_NONBLOCK flag-gel megnyitott fd-t lekérdezi; más taszk nem kap CPU-t ezen a magon — ez beágyazott rendszerekben elfogadhatatlan
• Polling sleep-pel: az alvási intervallum alatt a CPU más taszknak adódik át; de ha épp alszik a taszk, és pontosan akkor nyomják meg a gombot, sleep ideje késleltetést jelent; a sleep()-et signal megszakíthatja
• poll() kernel megszakítással: a kernel blokkolja a taszkot (Waiting állapot), eseménynél (GPIO élvezérlés: edge = rising/falling) megszakítás ébreszt; ez az ajánlott megközelítés

Must-know fact: A sysfs GPIO + poll() kombináció: először edge fájlba kell írni (rising, falling, both), ezután a value fájlra meghívott poll() a kernel HW megszakítását képezi le user-space eseménnyé.

Exam trap detector ❌ “A poll()-os megközelítés CPU-igénye azonos a folyamatos polling-gal, mert mindkettő folyamatosan figyeli az eseményt” — a poll() blokkolva vár (a taszk Waiting állapotban van), és csak az esemény bekövetkezésekor ébreszti fel a kernel; a folyamatos polling nem blokkol ✅ poll() CPU-igénye minimális (a szál alszik az eseményig); folyamatos polling 100%-on tartja a CPU-t

---

---

📝 20 Vizsgakérdés — Blockok 3–6

---

1. Melyik állítás IGAZ az I2C és az UART adathozzáférési modelljéről?

A) Az UART is regiszter-fájl alapú, a külső eszköz belső regisztereit olvasod/írod B) Az I2C egy szabad formátumú byte-folyamot küld, a protokollt az alkalmazás definiálja C) Az I2C kommunikáció során a külső eszköz belső regisztereit olvasod/írod, az UART szabad formátumú byte-folyam D) I2C és SPI mindkettő aszinkron, baudrate-egyezés szükséges

---

2. Melyik állítás HAMIS a BeagleBone Black (BBB) konzolportjáról?

A) A konzolport J1 tüskesor, GND = PIN1, RX = PIN4, TX = PIN5 B) A baudrate 115200 C) A BBB konzolportja 5V-toleráns, USB–UART adaptereknél nincs veszély D) A konzolporthoz Linux alatt dialout csoporttagság szükséges

---

3. Melyik állítás IGAZ a BSP (Board Support Package) definíciójáról?

A) A BSP az alkalmazáslogikát is tartalmazza, belértve az üzleti logikát B) A BSP az OS és a célhardver közötti illesztőréteget biztosítja (bootloader, kernel konfig, device tree, HW-specifikus driverek) C) A BSP-t mindig az alkalmazásfejlesztő csapat írja a projekt során D) A BSP Linux esetén nem tartalmaz bootloadert, csak kernelkonfigurációt

---

4. Melyik állítás HAMIS a beágyazott OS-típusokról?

A) NoOS esetén a fejlesztő végtelen ciklussal és megszakításokkal valósítja meg az ütemezést B) A rejtett OS (hidden OS) explicit taszkkezelési API-t nyújt a fejlesztőnek C) FreeRTOS egy beágyazott RTOS explicit taszk-, szemafor- és queue-API-val D) Linux beágyazott kontextusban MMU-t igényel

---

5. Melyik állítás IGAZ a körforgó (Round-Robin) ütemezésről beágyazott MCU-kon?

A) A Round-Robin preemptív: a kernel timer megszakítással veszi el a CPU-t az egyes taszktoktól B) A Round-Robin kooperatív: minden taszk maga adja vissza a vezérlést, preempció nincs C) A Round-Robin prioritások alapján rendezi a taszkokat, magasabb prioritású taszkot futtat előbb D) Round-Robin esetén az ISR közvetlenül az esemény teljes feldolgozását végzi el

---

6. Melyik állítás HAMIS a FreeRTOS-ról?

A) FreeRTOS minimális ROM/RAM igénnyel üzemel (akár ~10 KB ROM) B) FreeRTOS saját, nem-POSIX API-t használ (xTaskCreate, xQueueSend stb.) C) FreeRTOS teljes POSIX API-t valósít meg, így Linux programok módosítás nélkül futtathatók D) FreeRTOS MCU-kra optimalizált, és MMU nélkül is működik

---

7. Melyik állítás IGAZ a Linux rendszerben a jelzések (signals) kezeléséről?

A) A SIGKILL elkapható egy signal handler függvénnyel, ha a program időben regisztrálja B) A SIGTERM nem kapható el, kizárólag az OS alapértelmezett terminálásával kezelhető C) A SIGINT és SIGTERM elkapható; a SIGKILL és SIGSTOP nem elkapható és nem ignorálható D) Ha egy program ignorálja a SIGKILL-t, az OS más jelzéssel kénytelen leállítani

---

8. Melyik állítás HAMIS a sleep() és jelzések kapcsolatáról?

A) Ha sleep() futása közben signal érkezik, a handler lefut, majd a sleep() EINTR-rel visszatér B) A sleep() visszatérése után a maradék alvási idő automatikusan folytatódik anélkül, hogy újra kellene hívni C) A sleep() blokkoló rendszerhívás, a szál Waiting állapotba kerül futása közben D) A running flag mintával a signal handler és a főciklus biztonságosan kommunikálhat

---

9. Melyik állítás IGAZ az API és az ABI összehasonlításáról Linux kontextusban?

A) Az API és az ABI szinonimák; mindkettő a rendszerhívás bináris interfészét jelenti B) Az API (pl. glibc read()) user space-ben fut és elfedi az architektúra-specifikus ABI részleteket C) Az ABI a fejlesztő számára látható magas szintű C függvényhívási felület D) A glibc megkerülhető; az alkalmazás közvetlenül az API-n keresztül hívhat kernel funkciót

---

10. Melyik állítás HAMIS a Linux kernel device fájl interfészéről?

A) A character device fájl tetszőleges méretben adja az adatokat (akár 1 byte) B) Az Ethernet hálózati interfészek is /dev/ alatti device fájlokon keresztül kezelhetők, akárcsak az UART C) Az IOCTL mechanizmus eszközspecifikus parancsok küldésére szolgál, pl. UART sebesség beállítása D) A block device adott méretű darabokban (tipikusan 512 B) adja az adatot

---

11. Melyik állítás IGAZ a kernel driver és user-space driver összehasonlításáról?

A) Egy hibás user-space driver kernel panic-ot okozhat, mert közvetlenül a kernel memóriaterületéhez fér hozzá B) A kernel driver hiba kernel panic-ot okozhat; user-space driver hiba csak az alkalmazást veszi el C) A user-space driver mindig gyorsabb, mint a kernel driver, mert elkerüli a kontextusváltást D) A kernel driver dynamically loadolható, de user-space driver nem tölthető be futás közben

---

12. Melyik állítás HAMIS a GPIO sysfs és chardev összehasonlításáról?

A) A sysfs GPIO interfész elavult; a chardev a támogatott megoldás kernel 4.8-tól B) A sysfs GPIO interfész Shell scriptből is kezelhető egyszerű echo parancsokkal C) A chardev a modern, ajánlott GPIO interfész, amely programozottan érhető el D) A sysfs GPIO interfész az új TI AM6x processzorokban is garantáltan implementálva van

---

13. Melyik állítás IGAZ a libusb használatáról?

A) A libusb akkor szükséges, ha az USB eszköz standard device class-t implementál (HID, MassStorage) B) A libusb akkor hasznos, ha az eszköz egyedi (non-standard) USB protokollt használ és nincs kernel drivere C) A libusb csak C nyelvből érhető el; más nyelvekből (Python, Java) nem használható D) A libusb mindig kernel módban fut, mert az USB stack kernel-szintű hozzáférést igényel

---

14. Melyik állítás HAMIS a feladat (taszk/szál) állapotátmeneteiről Linuxban?

A) A Waiting állapotból a taszk közvetlenül futó (Run) állapotba kerülhet, az ütemező közbejötte nélkül B) Minden állapotátmenet megszakítás hatására következik be (HW, szoftver megszakítás, kivétel) C) Futásra kész (Ready) állapotban a taszknak minden erőforrás rendelkezésre áll, kivéve a CPU-t D) Ha nincs futtatható taszk, az idle taszk fut (power management)

---

15. Melyik állítás IGAZ a polling és a megszakítás összehasonlításáról?

A) A folyamatos polling garantáltan gyorsabb válaszidőt ad minden esetben, mint a megszakítás B) A blokkoló (megszakítás alapú) megközelítés CPU-igénye a várakozás során minimális; a folyamatos polling 100%-on tartja a CPU-t C) A blokkoló rendszerhívás pontosan 1 µs overhead-del ébreszti fel a Waiting állapotú taszkot D) A nem blokkoló polling megbízhatóbb megszakítás-kezelést biztosít, mert az OS garantálja a futási frekvenciát

---

16. Melyik állítás HAMIS a mutex és a spinlock összehasonlításáról?

A) A mutex passzívan vár: az OS várakozási sorba teszi a szálat, amíg az erőforrás felszabadul B) A spinlock aktívan vár: folyamatosan lekérdezi a lock állapotát, ami 100% CPU-t jelent C) A spinlock rendszerhíváson keresztül hívja a kernelt, akárcsak a mutex D) Egyprocesszoros RT FIFO ütemezési osztályban a spinlock deadlock-ot okozhat

---

17. Melyik állítás IGAZ a poll() rendszerhívás és a többszálú architektúra összehasonlításáról?

A) A poll() alapú architektúra párhuzamosan futtatja az eseménykezelőket, így skálázhatóbb sokmagos CPU-n B) A poll() alapú egyszálú megközelítés kölcsönös kizárás nélkül kezeli az eseményeket; a többszálú megközelítés közös erőforrásoknál kölcsönös kizárást igényel C) A többszálú architektúra kisebb erőforrás-igényű egyprocesszoros beágyazott rendszerekben, mint a poll() alapú egyszálú megközelítés D) A poll() nem képes egyszerre több file leírót figyelni; minden file leírót külön rendszerhívással kell kezelni

---

18. Melyik állítás HAMIS az időmérési óraforrásokról?

A) A CLOCK_REALTIME visszaállítható (pl. NTP vagy settimeofday() hívással), ezért időintervallum mérésre nem megbízható B) A CLOCK_MONOTONIC monotonan növekvő és NTP finomhangolást nem tud befolyásolni, teljesen NTP-független C) A CLOCK_MONOTONIC_RAW nyers HW órajelet tükröz, NTP-korrekcióktól teljesen független D) Időintervallum mérésére CLOCK_MONOTONIC vagy CLOCK_MONOTONIC_RAW ajánlott

---

19. Melyik állítás IGAZ a fflush() szerepéről GPIO sysfs elérésnél?

A) A fflush() csak hálózati socketekre vonatkozik; fájlok esetén nincs hatása B) A fprintf() a stdio buffer kiürítése nélkül is azonnal frissíti a GPIO value fájlt, ezért fflush() felesleges C) A stdio réteg buffereli az írást; fflush() nélkül a GPIO value fájlba írt érték nem kerül azonnal a kernelhez, és a LED nem reagál D) A fflush() csak akkor szükséges, ha a fájl bináris módban van megnyitva

---

20. Melyik állítás HAMIS a Linux I2C user-space elérésről?

A) User-space I2C eléréskor a busz /dev/i2c-X eszközfájlként jelenik meg B) User-space I2C elérés esetén az I2C eszköznek is rendelkeznie kell saját kernel driverrel, különben a kommunikáció nem lehetséges C) Az i2cdetect, i2cdump, i2cget, i2cset parancsok az i2ctools csomagból érhetők el D) User-space I2C esetén a busz alacsony szintű kernel drivere szükséges, de az eszköznek nem kell saját kernel driver

---

---

✅ Válaszkulcs

#	Válasz	Indoklás
1	C	Az I2C/SPI regiszter-fájl modellt használ; az UART szabad formátumú byte-folyam
2	C	A BBB konzolportja 3,3V-os; 5V bevitel tönkreteheti a SoC-ot
3	B	A BSP az OS és a HW közötti illesztőréteget biztosítja; nem tartalmaz alkalmazáslogikát
4	B	A rejtett OS éppen hogy elrejti az ütemezési API-t; a fejlesztő nem kezeli explicit módon
5	B	Beágyazott Round-Robin kooperatív: minden taszk maga adja vissza a vezérlést, nincs preempció
6	C	A FreeRTOS saját, nem-POSIX API-t használ; a POSIX API a Linux területe
7	C	SIGINT/SIGTERM elkapható; SIGKILL/SIGSTOP nem elkapható és nem ignorálható
8	B	A sleep() EINTR-rel visszatér, a maradék idő elvész; újra kell hívni, ha szükséges
9	B	Az API (glibc wrapper) user space-ben fut és elfedi az architektúra-specifikus ABI-t
10	B	Az Ethernet hálózati interfészek kivételt képeznek; nem device fájlokon, hanem socket+ioctl-en keresztül érhetők el
11	B	Kernel driver hiba kernel panic-ot okoz; user-space driver hiba csak az adott alkalmazást viszi el
12	D	Az újabb TI AM6x processzorokon a sysfs GPIO nem feltétlenül implementált; ez az egyik oka, hogy a chardev a jövő
13	B	A libusb non-standard USB protokollokhoz ideális, ahol nincs kernel driver; standard class-nál felesleges
14	A	Waiting → Ready → Run a sorrend; a taszk soha nem kerül közvetlenül Waiting-ből Run állapotba, az ütemező közbejötte szükséges
15	B	Blokkoló hívás CPU-igénye minimális (szál alszik); folyamatos polling 100%-on tartja a CPU-t
16	C	A spinlock nem rendszerhívás — user-space-ben valósul meg, a kernelt nem hívja meg
17	B	A poll() egyszálú, szekvenciális, kölcsönös kizárás nélkül; a többszálú megközelítésnél kell mutex
18	B	A CLOCK_MONOTONIC NTP kis korrekciókat (gradual adjustment) elvégez; teljesen NTP-független csak a CLOCK_MONOTONIC_RAW
19	C	A stdio réteg bufferel; fflush() kell, hogy az érték ténylegesen a kernelhez kerüljön és a GPIO reagáljon
20	B	User-space I2C esetén az eszköznek nincs saját kernel drivere; csak a busz alacsony szintű drivere szükséges

---

Vissza a bloghoz