Beágyazott információs rendszerek: ZH felkészítő Jegyzet [Gemini 3.1 Pro (via AI Studio)]

Embedded system: definition

Mi ez? Egy nagyobb rendszer részeként működő, dedikált feladatot ellátó számítógépes rendszer. Szemben a PC-vel vagy egy általános célú Java szerverrel, itt a hardver és a szoftver szorosan együttműködik egyetlen, jól definiált fizikai folyamat vezérlésére vagy megfigyelésére (mint egy Arduino a 3D nyomtatódban).

Exam trap detector ❌ “A beágyazott rendszer mindig operációs rendszer nélkül működik.” — Tévedés, futhat rajta Linux vagy FreeRTOS is. ✅ “A beágyazott rendszerek dedikált, specifikus feladatot látnak el, és gyakran a fizikai környezettel állnak kapcsolatban.” ❌ “A beágyazott rendszer sosem tartalmazhat PC alapú hardvert.” — Tévedés, egy ipari PC is lehet beágyazott rendszer, ha dedikált feladata van. ✅ “A beágyazott rendszer egy nagyobb rendszer része is lehet.”

Must-know facts

Jellemzői: Erőforrás-korlátos, dedikált feladat, fizikai interakció (szenzor/beavatkozó).
Gyakran valós idejű (real-time) követelményekkel rendelkezik.

Real-time system: definition, hard vs. soft real-time

Mi ez? Olyan rendszer (reszponzív rendszer), ahol a helyes működés nemcsak a logikai eredménytől, hanem az eredmény előállításának idejétől is függ.

Exam trap detector ❌ “A valós idejű rendszer azt jelenti, hogy a rendszer rendkívül gyors.” — Tévedés, a valós idő kiszámíthatóságot (garantált válaszidőt) jelent, nem puszta sebességet. ✅ “A hard real-time rendszernél a határidő lekésése végzetes hibát okoz.” ❌ “A soft real-time rendszerek esetében a határidők lekésése sosem okoz problémát.” — Tévedés, okoz problémát (pl. minőségromlást), de nem katasztrofálisat.

Must-know facts

Hard Real-Time: A határidő lekésése katasztrófát okoz (pl. légzsákvezérlő, pacemaker).
Soft Real-Time: A határidő lekésése csak minőségromlást okoz (pl. videó streamelés megszakadása).

Real-time operating system (RTOS): definition, requirements

Mi ez? Egy olyan operációs rendszer, amely garantálja a maximális válaszidőt (kiszámíthatóságot) az események kezelésére. Míg a normál Linux (vagy a JVM Garbage Collector-a) bármikor megakaszthatja a futást, egy RTOS preemtív ütemezője szigorú prioritások alapján biztosítja a hard real-time működést.

Exam trap detector ❌ “Az RTOS mindig gyorsabb a normál operációs rendszereknél.” — Tévedés, az RTOS determinisztikus, nem feltétlenül gyorsabb (sőt, a sok kontextusváltás miatt az átlagos throughput lehet alacsonyabb). ✅ “Az RTOS garantálja a megszakítások és a legmagasabb prioritású taszkok maximális válaszidejét.”

Must-know facts

A legfőbb követelmény a determinizmus (kiszámíthatóság).
Általában preemptív, prioritás-alapú ütemezést (Priority preemptive scheduling) használ.

Cyber-Physical System (CPS): definition

Mi ez? Számítási (kiber) és fizikai folyamatok szoros integrációja. A beágyazott számítógépek és hálózatok monitorozzák és vezérlik a fizikai folyamatokat, egy zárt visszacsatolási hurkot (feedback loop) alkotva.

How it works

Sensing: Szenzorok adatot gyűjtenek a fizikai világból.
Computing/Networking: Az adatokat elemzik, gyakran elosztott hálózaton.
Actuation: A beavatkozók (actuators) megváltoztatják a fizikai világ állapotát a döntés alapján.

Exam trap detector ❌ “A CPS rendszerekben mindig emberi beavatkozás szükséges a hurok bezárásához.” — Tévedés, a cél pont az automatikus, ember nélküli optimalizáció és beavatkozás. ✅ “A CPS-ben az informatikai rendszerrész a begyűjtött információk alapján a fizikai rendszer működésébe beavatkozik.”

Must-know facts

3C alapelv: Communicate, Compute, Control.
Célja a rendszer működésének automatikus optimalizálása.

IoT/IIoT vs. CPS: what distinguishes them

Mi ez? Míg az IoT (Internet of Things) főleg az eszközök hálózatba kötésére és az adatgyűjtésre fókuszál (pl. okosotthon szenzor küldi az adatot a felhőbe), a CPS esetében a hangsúly a fizikai beavatkozáson és a zárt szabályozási hurkon van. Az IIoT (Industrial IoT) az IoT ipari környezetben alkalmazott, robusztusabb változata.

Exam trap detector ❌ “Az IoT és a CPS pontosan ugyanazt a fogalmat takarják.” — Tévedés, az IoT gyakran csak “figyel” és az embert hagyja beavatkozni, a CPS maga avatkozik be. ✅ “A CPS rendszerekben sokkal hangsúlyosabb az automatikus fizikai beavatkozás, mint a tipikus IoT alkalmazásokban.”

Must-know facts

IoT: Adatgyűjtés, felhő, dashboardok (gyakran az ember zárja a hurkot).
CPS: Automatikus beavatkozás, control theory, elosztott valós idejű vezérlés.

CPS architecture: layers and the basic function of each layer

Mi ez? A CPS rendszerek felépítését leíró 5 szintes 5C (Connection, Conversion, Cyber, Cognition, Configuration) architektúra, amely az egyszerű adatgyűjtéstől a teljesen autonóm döntéshozatalig terjed.

How it works

Smart Interconnect (Connection): Szenzorok, hálózat, adatgyűjtés.
Data-to-Information (Conversion): Nyers adatokból hasznos információ (pl. szenzorfúzió).
Cyber-Physical (Cyber): Digitális iker (Digital Twin), modellezés.
Cognition: Helyzetértékelés, diagnosztika (mit tegyünk?).
Self-X / Automation (Configuration): Autonóm beavatkozás, ön-konfigurálás, ön-optimalizálás.

Exam trap detector ❌ “A kognitív szint végzi a nyers szenzoradatok hálózati továbbítását.” — Tévedés, azt az Interconnect (Connection) szint csinálja. ✅ “A Cyber (Kiber-fizikai) szint feladata a rendszer digitális ikrének fenntartása és a modellezés.”

Must-know facts

5 szint: Interconnect -> Konverzió -> Kiber-fizikai -> Kognitív -> Automatizmusok.

Internet technology problems in CPS environments: real-time, reliability, IT security

Mi ez? A hagyományos TCP/IP és Ethernet az “Intranetre/Internetre” lett kitalálva: “best effort” alapú, nem valós idejű, a csomagvesztés újra küldéssel jár (ami idő), és a security fókuszáltan az adat titkosságára épül. A CPS-ben az időzítés (real-time) kritikus, a megbízhatóságnak ms alatti hibatűrést kell garantálnia, és a hálózat nem szakadhat meg.

Exam trap detector ❌ “A hagyományos TCP/IP Ethernet hálózatok kiválóan alkalmasak hard real-time CPS feladatokra.” — Tévedés, a TCP/IP “best effort”, csúszások és újra-küldések vannak benne. ✅ “A CPS rendszerek számára a Time-Sensitive Networking (TSN) nyújt valós idejű, Ethernet alapú alternatívát.”

Must-know facts

Klasszikus Ethernet: Nem determinisztikus, a hibatűrés protokolljai (pl. STP) másodperceket vesznek igénybe.
Biztonság (CIA triád): A CPS-ben a Rendelkezésre állás (Availability) és az Integritás (Integrity) gyakran fontosabb, mint a Titkosság (Confidentiality).

IT security and CPS: lifetime/certification challenges

Mi ez? A CPS eszközök (pl. vonatok, atomerőművek, autók) élettartama 10-50 év. A kriptográfiai protokollok (pl. SSL/TLS) azonban pár évente elavulnak. A szoftverek frissítése ipari környezetben a szigorú újra-minősítési (certification) szabályok miatt extrém drága és lassú.

Exam trap detector ❌ “Egy beágyazott eszköz firmware-jének biztonsági frissítése mindig azonnal, költségmentesen elvégezhető.” — Tévedés, a minősítési folyamatok miatt (pl. vasút, repülés) ez nagyon lassú és drága. ✅ “A CPS rendszerek 10-30 éves élettartama miatt a modern biztonsági protokollok gyors elavulása komoly problémát jelent.”

Must-know facts

Élettartam (10-50 év) vs. IT Security élettartam (pár év) ellentmondása.
Tanúsítványok (Certification) miatti frissítési nehézségek.

Role of domain/application experts in CPS

Mi ez? Mivel a CPS a fizikai világba avatkozik be, a puszta szoftverfejlesztői (IT) tudás kevés. Szükség van az adott iparág (domain) szakértőire (gépészmérnökök, vegyészek, biológusok), hogy megértsék a fizikai folyamatok dinamikáját és határait.

Exam trap detector ❌ “A CPS rendszereket kizárólag informatikusok tervezik, domain szakértők bevonása nélkül.” — Tévedés, interdiszciplináris terület. ✅ “A beágyazó fizikai környezet szabályainak megértéséhez domain szakértőkre (pl. gépész, orvos) van szükség.”

Must-know facts

Interdiszciplináris fejlesztés szükséges.

ANSI/IEC 60529-2004 (IP rating standard): basics and scope

Mi ez? A burkolatok (dobozok) által nyújtott védelem fokozatát megadó nemzetközi szabvány (Ingress Protection). Formátuma: IPxy (pl. IP68). Az első számjegy (x) a szilárd testek (por, ujjak), a második (y) a folyadékok (víz) elleni védelmet jelöli.

Exam trap detector ❌ “Az IP minősítés első számjegye a vízállóságot mutatja.” — Tévedés, az első a szilárd tárgyak/por elleni védelem. ✅ “Az IP68-as besorolású burkolat porálló és víz alá meríthető.”

Must-know facts

Első számjegy: Szilárd test behatolása (0-6, a 6 a teljes porállóság).
Második számjegy: Folyadék behatolása (0-8, ritkán 9K).
Nem tartalmaz vibrációs vagy hőmérsékleti teszteket!

MIL-STD-810 standard: basics, scope, what it mandates and what it does NOT mandate

Mi ez? Amerikai katonai szabvány, amely a környezeti tesztelés módszertanát írja le (hőmérséklet, vibráció, ütés, sóköd stb.). Nem ad meg konkrét “megfelelt/nem felelt meg” határértékeket minden eszközre; a teszteket az adott eszköz specifikus alkalmazási környezetéhez kell szabni.

Exam trap detector ❌ “A MIL-STD-810 szabvány előírja, hogy minden eszköznek ki kell bírnia a -40 fokot.” — Tévedés, a szabvány módszereket ad meg, a konkrét tesztparamétereket az alkalmazás határozza meg. ✅ “A MIL-STD-810 szabvány szerinti megfelelés tesztjeit mindig az adott eszköz specifikus alkalmazási profiljához kell igazítani.”

Must-know facts

Környezeti tesztelési keretrendszer (nem csak katonáknak, iparban is használják).
30+ specifikus teszt (pl. vibráció, gomba, fagyás).

Sensor: definition, basic operation, key properties

Mi ez? Fizikai mennyiséget elektromos jellé alakító eszköz (jelátalakító). Bemenete valamilyen fizikai paraméter (pl. hőmérséklet), kimenete tipikusan feszültség, áram, vagy egy A/D konverzió utáni digitális érték.

Exam trap detector ❌ “A szenzor az elektromos jelet alakítja át fizikai elmozdulássá.” — Tévedés, ez a beavatkozó (actuator) definíciója. ✅ “A szenzor kimenete ideális esetben lineárisan arányos a mért fizikai mennyiséggel.”

Must-know facts

Jellemző hibák: ofszet hiba, nemlinearitás, zaj.
Fontos metrikák: Felbontás (resolution), pontosság (accuracy).

Actuator: definition, basic operation, key properties

Mi ez? Beavatkozó. Elektromos jeleket fizikai mennyiséggé (elmozdulás, nyomás, hő) alakító eszköz. Mivel a fizikai munkavégzéshez energia kell, beépítve szinte mindig működik valamilyen erősítőként is.

Exam trap detector ❌ “A beavatkozók kizárólag digitális jeleket képesek feldolgozni.” — Tévedés, működhetnek analóg feszültséggel vagy árammal is. ✅ “A beavatkozók elektromos jelek hatására megváltoztatják a fizikai környezet állapotát.”

Must-know facts

Fajtái: Elektromos (motor, relé), hidraulikus, pneumatikus.
Erősítő szerepet is betöltenek, mivel az MCU PIN-je (max pár mA) nem tud közvetlenül motort hajtani.

strace: purpose and mechanism

Mi ez? Linux parancssori eszköz, amivel egy futó (vagy újonnan indított) folyamat (process) által hívott rendszerhívásokat (system calls) és a kapott szignálokat tudjuk nyomon követni. Ha a Java appod kifagy egy fájl olvasásánál, az strace megmutatja, melyik read() syscallnál akadt el.

Exam trap detector ❌ “Az strace segítségével nyomon követhetjük a C programon belüli belső függvényhívásokat.” — Tévedés, csak a user-space és a kernel-space közötti hívásokat (syscallokat) látja, a belsőket (pl. egy math() függvényt) nem. ✅ “Az strace megmutatja az alkalmazás által a kernel felé indított rendszerhívásokat és azok visszatérési értékeit.”

Must-know facts

Célja: Debugging és hibakeresés.
Eredményként kilistázza a syscall-ok nevét, paramétereit és az errno értékét hiba esetén.

Linux application structure: parts of a Linux program

Mi ez? A Linux folyamat (process) futási képe a virtuális memóriában. Részei: Kód (Text), Adat szegmensek (Data, BSS), Heap (dinamikus memória) és Stack (verem, lokális változókhoz és függvényhívásokhoz).

Exam trap detector ❌ “A Linux folyamatok esetében a Stack mérete fix, és a memóriacímek alsó részéből nő felfelé.” — Tévedés, a Stack magas memóriacímekről nő lefelé. ✅ “A memóriában a Heap dinamikusan növekszik a magasabb címek felé, a Stack pedig a magas címekről az alacsonyabbak felé.”

Must-know facts

Parancssor (CLI), Konfiguráció kezelés, Logolás, Jelzéskezelés (Signals), Eseményhurok (Event loop).

stdin/stdout/stderr channels and I/O redirection

Mi ez? Minden Linux processz alapértelmezetten 3 nyitott fájlleíróval (File Descriptor) indul. 0: stdin (bemenet), 1: stdout (normál kimenet), 2: stderr (hibaüzenetek). Ezek a shellben könnyen fájlba irányíthatók (mint a logok).

Exam trap detector ❌ “A standard error (stderr) csatorna fájlleírója az 1-es.” — Tévedés, az az stdout. A stderr a 2-es. ✅ “Az > out.txt 2>&1 paranccsal a standard kimenetet és a hiba kimenetet is ugyanabba a fájlba irányítjuk.”

Must-know facts

FD 0 = Standard Input
FD 1 = Standard Output
FD 2 = Standard Error

Configuration management: general purpose and approaches

Mi ez? A szoftver viselkedését meghatározó beállítások kezelése fordítás nélkül. Linuxban az adatok származhatnak beégetett alapértékekből, környezeti változókból (env), konfigurációs fájlokból (pl. INI, JSON, XML), és legmagasabb prioritással a parancssori argumentumokból (CLI).

Exam trap detector ❌ “A környezeti változók (env) mindig felülírják a parancssori argumentumokat (CLI).” — Tévedés, a CLI argumentumoknak van a legmagasabb precedenciája (ők a leginkább specifikusak). ✅ “A konfigurációs fájlokból beolvasott értékeket felülírhatjuk a program indításakor megadott parancssori paraméterekkel.”

Must-know facts

Precedencia (növekvő): Hardcoded default -> Config file -> Környezeti változó -> Parancssori (CLI) paraméter.
Globális változókat (C struct) használnak a tárolásukra.

main() function prototypes: how CLI arguments and environment variables are received

Mi ez? A C program belépési pontja. Két fő paramétere van az argumentumokhoz: argc (darabszám) és argv (string tömb a paraméterekkel). Létezik egy harmadik, ritkábban használt paraméter, az envp, ami a környezeti változókat adja át.

Exam trap detector ❌ “Az argv[0] mindig az első felhasználó által átadott paramétert tartalmazza.” — Tévedés, az argv[0] maga a futtatott program neve/elérési útja. ✅ “A main függvény harmadik paramétere (envp) egy string tömb, amely a program környezeti változóit tartalmazza.”

Must-know facts

Protípus: int main(int argc, char *argv[], char *envp[])
argc: Mindig legalább 1 (ha a programnevet kapjuk).

CLI parameter forms and handling tools: getopt()

Mi ez? A C standard library (libc) függvénye, ami végigmegy a parancssori paramétereken, és egy switch-case szerkezettel segít feldolgozni a rövid opciókat (pl. -v, -f filename). A getopt_long() a hosszú (pl. --version) opciókat is ismeri.

How it works Egy while ciklusban hívjuk a getopt()-ot, ami visszaadja a következő paraméter karakterét. Ha a paraméter vár egy értéket (ezt egy : jelzi az optstringben), az értéket a globális optarg változóba teszi.

Exam trap detector ❌ “A getopt() API automatikusan átalakítja a paraméterként kapott szöveget integer számmá.” — Tévedés, csak stringként (char*) adja vissza az optarg változóban, a konverziót (pl. atoi) a fejlesztőnek kell elvégeznie. ✅ “A getopt függvény az opcióhoz tartozó string értéket a globális optarg változóban teszi elérhetővé.”

Must-know facts

getopt(): Rövid opciók (pl. -a).
getsubopt(): Al-opciók parsingja (pl. -s dev=ttyS0,speed=115200).
optarg: Az éppen feldolgozott paraméter értékét (string) tartalmazza.

Embedded system HW components and interfaces overview

Mi ez? Egy tipikus beágyazott hardver áll egy számítási magból (MCU/SoC/FPGA), fizikai illesztésekből (A/D, D/A, erősítők), humán interfészből (HMI, gombok, LED-ek) és kommunikációs interfészből (Ethernet, Wi-Fi, Bluetooth).

Exam trap detector ❌ “A beágyazott rendszerek sosem tartalmaznak hálózati kommunikációs interfészeket.” — Tévedés, a modern beágyazott rendszerek (IoT/CPS) alapköve a hálózat (M2M). ✅ “A frontend áramkörök teremtik meg a fizikai kapcsolatot a beágyazott számítógép és a fizikai beágyazó környezet között.”

Must-know facts

H2M / HMI: Human-Machine Interface.
M2M: Machine-to-Machine communication.

Microcontroller vs. SoC: comparison

Mi ez?

MCU (Microcontroller): Egyszerű, in-order CPU mag (pl. Cortex-M). Tartalmazza a memóriát (SRAM) és a programtárat (Flash). MMU nélkül, jellemzően RTOS vagy bare-metal kód fut rajta. (Olyan, mint amivel az Arduino épül).
SoC/AP (System on Chip / Application Processor): Erős, spekulatív, többmagos CPU (pl. Cortex-A). Külső memóriát (DDR) és háttértárat (eMMC) igényel. Van benne MMU, így képes teljes értékű Linuxot futtatni. (Mint a Raspberry Pi magja).

Exam trap detector ❌ “A mikrovezérlők (MCU-k) tartalmaznak MMU-t, így ideálisak Linux futtatására.” — Tévedés, az MCU-kban nincs MMU (Memory Management Unit), emiatt nem fut rajtuk hagyományos Linux. ✅ “Az Application Processorok (AP) jellemzően külső memóriát (DDR) igényelnek a működésükhöz, ellentétben a tipikus MCU-kkal.”

Must-know facts

MCU: Belső SRAM/Flash, nincs MMU, RTOS/Bare-metal.
AP (SoC): Külső DDR/eMMC, van MMU, Linux.

Protection rings and the role of the MMU in SoCs

Mi ez? Hardveres védelmi szintek a CPU-ban. A legalacsonyabb szint a Kernel mode (teljes hozzáférés a hardverhez), a magasabb szint a User mode (korlátozott hozzáférés). Az átjárást a rendszerhívások (syscall) biztosítják. Az MMU (Memory Management Unit) hardver végzi a virtuális memóriacímek fordítását fizikai címekké, és védi a folyamatokat attól, hogy egymás memóriájába írjanak.

How it works

User mode-ban a program végrehajt egy syscall-t.
A CPU kontextust vált (Kernel mode-ba lép).
A kernel elvégzi a hardveres műveletet, majd visszatér User mode-ba.

Exam trap detector ❌ “User mode-ban futó programok közvetlenül, a kernel megkerülésével írhatják a fizikai I/O regisztereket.” — Tévedés, az MMU és a Protection ringek blokkolják ezt (kivétel: mmap jogosultsággal, de az is kernel beavatkozást igényel előbb). ✅ “Az MMU felelős a virtuális címek fizikai címekre történő leképezéséért (lapozás).”

Must-know facts

Az MCU-kban (pl. Cortex-M) általában nincs MMU és szigorú védelmi gyűrű (max MPU van).
A Kernel mode privilegizált, a User mode korlátozott.

Kernel/user-space separation and its consequences; Linux in this context

Mi ez? Az operációs rendszer kódja (kernel) és a felhasználói programok (user-space) el vannak választva. Ez drasztikusan növeli a stabilitást (egy bugos C program csak Segfaultot kap, de a kernel fut tovább), viszont lassítja a végrehajtást (overhead), mert a kontextusváltás a gyűrűk között időbe telik.

Exam trap detector ❌ “A kernel-space és user-space szétválasztása növeli a rendszersebességet.” — Tévedés, lassítja (overhead) a kontextusváltások miatt, viszont a biztonságot és a stabilitást növeli. ✅ “Egy user-space program összeomlása nem viszi magával a kernel-t, hála az MMU által biztosított memóriavédelemnek.”

Must-know facts

Rendszerhívás (Syscall) híd köti össze a két teret.
Overheadet (időveszteséget) okoz a váltás.

Virtual memory performance: general case and embedded systems implications

Mi ez? Az MMU segítségével a programok úgy látják, mintha végtelen (és összefüggő) RAM-juk lenne. Ha a fizikai RAM megtelik, az OS a ritkán használt “lapokat” a háttértárra menti (Swap). Ha a program olyan laphoz nyúl, ami nincs a RAM-ban, laphiba (Page Fault) történik, és a kernel visszatölti azt a háttértárról.

Exam trap detector ❌ “Beágyazott rendszerekben mindig javasolt a Swap használata a memória kibővítésére.” — Tévedés, az eMMC/Flash memóriák a sok írástól gyorsan tönkremennek, és az időzítés (real-time) is elromlik a lassú IO miatt. ✅ “A gyakori laphibák (page fault) miatti háttértár-olvasások drasztikusan leronthatják a beágyazott rendszer valós idejű válaszidejét.”

Must-know facts

Trashing (vergődés): Amikor a gép több időt tölt a lapok RAM és háttértár közti mozgatásával, mint tényleges számítással.
Beágyazott Linuxnál a Swap fájl használatát általában kerüljük (Flash kopása miatt).

SoC, PoP, SoP, SoM, SBC: definitions and how to distinguish them

Mi ez? Hardver integrációs szintek.

SoC (System on Chip): Egyetlen szilícium lapka, ami mindent integrál (CPU, GPU, memóriavezérlő).
PoP (Package on Package): Két tokot (pl. SoC és a RAM) egymásra forrasztanak függőlegesen a rövidebb vezetékek és helytakarékosság miatt.
SoP (System in a Package): Egy tokozáson belül több különálló szilícium lapka (chiplet).
SoM (System on Module): Egy kisméretű, cserélhető NYÁK, ami tartalmazza az alapokat (SoC, RAM, Flash), és egy hordozó alaplapra csatlakozik.
SBC (Single Board Computer): Egyetlen NYÁK-on minden benne van (csatlakozók, USB, Ethernet, SoC). Pl. Raspberry Pi, BeagleBone.

Exam trap detector ❌ “A Single Board Computer (SBC) egyetlen szilícium chipet jelent, tokozás nélkül.” — Tévedés, az SBC egy teljes fizikai NYÁK (áramköri lap) csatlakozókkal. Az egyetlen chip a SoC. ✅ “A System on Module (SoM) egy kisméretű áramköri lap, amelyet egy alkalmazásspecifikus hordozó alaplapra (carrier board) csatlakoztatnak.”

Must-know facts

Raspberry Pi / BeagleBone = SBC.
Toradex modulok = SoM.

getsubopt() and getopt_long(): basic purpose

Mi ez?

getopt_long(): A POSIX getopt() kiegészítése, amivel hosszú formátumú, dupla kötőjeles (pl. --version, --help) parancssori paramétereket lehet feldolgozni C-ben.
getsubopt(): Al-opciók (vesszővel elválasztott lista) feldolgozására való, pl. egy mount -o ro,remount parancsnál az ro és remount szétválogatására.

Exam trap detector ❌ “A getsubopt() függvény kifejezetten a dupla kötőjellel kezdődő hosszú opciók (pl. --help) feldolgozására szolgál.” — Tévedés, arra a getopt_long() való. ✅ “A getopt_long() segítségével komplexebb, hosszú formátumú parancssori paraméterek is kezelhetők.”

Must-know facts

A libc részei. A programozónak kell megírnia a parsing logikát egy string formátumú “szótár” (optstring) megadásával.

Logging, log levels, syslog.h usage

Mi ez? A C alkalmazások a szabványos syslog.h könyvtárral tudnak a Linux beépített naplózójába (syslog/journald) írni. A logolás különböző szinteken (Log Levels) történhet.

How it works Használata C-ben: openlog(), majd üzenetek írása syslog(LOG_INFO, "uzenet"), a végén closelog().

Exam trap detector ❌ “A syslog() függvénnyel közvetlenül egy általunk megadott nevű szöveges fájlba (pl. /home/user/log.txt) tudunk írni.” — Tévedés, a syslog() az OS naplózó démonjának (syslogd/journald) küldi az üzenetet, az dönti el, hova kerül. ✅ “A setlogmask() függvénnyel beállíthatjuk, hogy mely log szintek (pl. csak Error és Warning) kerüljenek ténylegesen naplózásra.”

Must-know facts

Loglevelek csökkenő súlyossággal: 0: Emergency -> 3: Error -> 4: Warning -> 6: Info -> 7: Debug. (Minél kisebb a szám, annál kritikusabb).

Logging challenges specific to embedded systems

Mi ez? Beágyazott eszközökön a naplózás nehézkes: ha eMMC-re (Flash) logolunk sűrűn, a diszk hamar tönkremegy (írási ciklusok korlátja). Ha a memóriába (RAM) logolunk, egy áramszünet esetén a hibaüzenetek elvesznek. Ha hálózatra logolunk (remote syslog), hálózati hiba esetén nincs log.

Exam trap detector ❌ “Beágyazott Linuxon a legjobb megoldás az összes Debug szintű log folyamatos írása a beépített eMMC kártyára.” — Tévedés, az eMMC kártya a túlzott írástól nagyon hamar elkopik és tönkremegy. ✅ “Hálózati naplózás (remote syslog) esetén a naplók rögzítése hálózati kapcsolati hiba esetén meghiúsulhat.”

Must-know facts

Flash kopás (wear out) az egyik legnagyobb ellensége az embedded logolásnak.

Peripheral structure: interface, register file, and peripheral function role

Mi ez? Egy mikrokontroller perifériája (pl. GPIO vezérlő, Timer, UART) hardveres szempontból három részből áll:

Interfész: Rácsatlakozik a CPU belső buszára.
Regiszterfájl: Kis memóriacímekként látszanak a CPU felé (ide írjuk a beállításokat, innen olvassuk az adatokat).
Funkcionális blokk: A tényleges hardver, ami az elektromos jelekkel operál (pl. a soros port shift regisztere).

Exam trap detector ❌ “A periféria regiszterfájljához a CPU kizárólag egy speciális, különálló kommunikációs kábelen keresztül férhet hozzá.” — Tévedés, a belső adatbuszon keresztül memóriacímként (Memory Mapped I/O) éri el. ✅ “A perifériát a CPU a regiszterfájljának írásával és olvasásával tudja konfigurálni és vezérelni.”

Must-know facts

A fejlesztő a regiszterfájlt “látja” a C kódból pointereken keresztül.

Peripheral addressing: dedicated I/O mapping vs. memory-mapped I/O

Mi ez?

Memory-mapped I/O (MMIO): A perifériák regiszterei úgy viselkednek, mintha a RAM részei lennének. Ugyanazokkal a pointer műveletekkel/assembly utasításokkal (LOAD/STORE) lehet őket írni/olvasni, mintha változók lennének. (Ez az ARM és a modern architektúrák sajátja).
Dedicated (Port-Mapped) I/O: A perifériáknak külön memóriatérképük van, és speciális assembly utasítások kellenek az elérésükhöz (pl. x86-on az IN és OUT utasítások).

Exam trap detector ❌ “Memory-mapped I/O esetén a CPU-nak speciális gépi utasításokat (pl. IN, OUT) kell használnia a perifériák eléréséhez.” — Tévedés, ez a Dedicated I/O. Memory-mapped esetén sima memóriaműveletek (load/store) kellenek. ✅ “A modern ARM processzorokban a perifériák elérése memóriába leképzett (Memory Mapped I/O) módon történik.”

Must-know facts

Beágyazott SoC-ken (ARM) szinte kizárólag MMIO-t használnak.

Interrupts at the peripheral level

Mi ez? Hardveres mechanizmus, amivel a periféria (pl. beérkezett egy Ethernet csomag, lejárt a Timer, megnyomtak egy gombot) jelezni tudja a CPU-nak, hogy esemény történt, anélkül, hogy a CPU-nak folyamatosan kérdezgetnie (polling) kellene a perifériát.

Exam trap detector ❌ “Megszakítások (interrupts) használatakor a CPU-nak folyamatosan olvasnia kell a periféria regiszterét, hogy megtudja, történt-e esemény.” — Tévedés, ez a Polling. A megszakítás pont ezt váltja ki. ✅ “A megszakítás hatására a processzor felfüggeszti az aktuális kód futtatását, és egy speciális eseménykezelő rutint (ISR) hív meg.”

Must-know facts

Hardveres megszakítást csak a Kernel (OS) képes lekezelni Linux alatt, user-space program közvetlenül nem!
Interrupt Controller (pl. ARM NVIC) menedzseli a megszakítások prioritásait.

Register file structure: control, status, data registers

Mi ez? A periféria regiszterei funkciójuk alapján bonthatók:

Control (Parancs) / Configuration (Üzemmód): Írható regiszterek. Itt mondjuk meg a perifériának, mit csináljon (pl. baud rate beállítása, vagy “Kezdj el mérni!”).
Status (Állapot): Csak olvasható regiszterek. Itt nézzük meg, kész van-e (pl. “Van-e beolvasatlan adat?”).
Data (Adat): Itt vesszük át az eredményt (pl. az ADC által mért értéket), vagy ide tesszük a kiküldendő bájtot.

Exam trap detector ❌ “Az állapot-regiszterek (Status registers) elsődleges feladata, hogy a programozó beleírja a periféria sebesség-beállításait.” — Tévedés, ez a Control/Config regiszter dolga. A Status regisztert általában csak olvassuk. ✅ “A Data regiszterek szolgálnak a periféria és a processzor közötti tényleges adattartalom (pl. beérkezett karakter) átadására.”

Must-know facts

Egy modern, 32 bites rendszerben a regiszterek 32 bites szavakként érhetők el.

PIN configuration and its function

Mi ez? A modern SoC-k több funkcióval rendelkeznek, mint ahány fizikai lábuk (PIN) van. A Pin Multiplexing (PinMux) segítségével szoftverből konfigurálható, hogy egy adott fizikai láb éppen GPIO, UART TX, PWM kimenet, vagy I2C SDA funkciót lásson el.

Exam trap detector ❌ “Egy modern SoC minden fizikai lábának (PIN) csak egyetlen, gyárilag bedrótozott, fix funkciója lehet.” — Tévedés, a Muxing miatt egy lábnak akár 8 különböző funkciója is lehet. ✅ “A PIN konfiguráció során nemcsak a láb funkcióját, hanem az elektromos tulajdonságait (pl. felhúzó ellenállás engedélyezése) is szoftverből állítjuk be.”

Must-know facts

Alapértelmezett állapot reset után általában a GPIO bemenet (mert az a legbiztonságosabb, nagy impedanciás állapot, nem okoz zárlatot).

GPIO interface rules: logic level constraints, current limits for input and output

Mi ez? A General Purpose I/O (GPIO) egy digitális ki/bemenet. Csak olyan logikai jelszinteket tolerál, ami a tápfeszültségének megfelel (BeagleBone esetén 3.3V). Kimenetként a meghajtóképessége nagyon kicsi (jellemzően 2-6 mA).

Exam trap detector ❌ “Egy SoC 3.3V-os GPIO lábára nyugodtan kapcsolhatunk 5V-os jelet, a beépített feszültségszabályzó kompenzálja azt.” — Tévedés, a láb tönkremegy. Szintillesztő (Level Shifter) kell. ✅ “A mikrovezérlők GPIO lábai jellemzően csak néhány milliamper (mA) áram leadására képesek, így közvetlenül nem hajthatnak meg nagyobb motorokat.”

Must-know facts

Tápfeszültség túllépése károsítja a bemenetet.
Nagyobb teljesítményű eszközök (relé, motor) vezérléséhez tranzisztor / FET / erősítő kapcsolás szükséges.

ADC/DAC fundamentals: quantization, signal range, sampling frequency, on-demand vs. timed sampling

Mi ez?

A/D (Analóg-Digitális konverter): Folytonos analóg feszültséget alakít digitális számmá (kvantálás).
Jellemzői: Felbontás (pl. 12 bit = 4096 lépcső), Mintavételi frekvencia.
On-demand (szoftveres polling): A program mondja meg, mikor mérjen az ADC.
Timed (HW időzített): Egy hardveres Timer fix frekvencián (pl. audio esetén 44.1 kHz) automatikusan indítja a méréseket, amit FIFO/DMA kezel.

Exam trap detector ❌ “A kvantálás során az A/D konverter a jelet időben diszkrét, de feszültségben folytonos formában menti el.” — Tévedés, mind időben, mind értékben (feszültség) diszkrét, lépcsős értéket hoz létre. ✅ “Időzített (timed) mintavételezés esetén általában egy hardveres Timer indítja az A/D konverziókat.”

Must-know facts

ADC bemenetre nem mehet negatív feszültség vagy a referenciánál nagyobb feszültség (jelszint eltolás, erősítő kell hozzá).

Digital inter-component communication options: I2C, SPI, UART basics

Mi ez?

UART (Universal Asynchronous Receiver-Transmitter): 2 vezeték (RX, TX). Aszinkron (nincs órajel vezeték), ezért előre egyeztetni kell a sebességet (Baud rate). Nincs címzés, pont-pont kapcsolat.
I2C: 2 vezeték (SDA - adat, SCL - órajel). Szinkron, buszos topológia (több eszköz), 7 bites hardveres eszközcímzés. Kicsit lassabb.
SPI: 4 vezeték (MISO, MOSI, SCK, CS). Szinkron, nagyon gyors. Nincs címzés az adaton belül, a CS (Chip Select) vezeték lehúzásával választja ki a Master, kivel akar beszélni.

Exam trap detector ❌ “A UART kommunikáció szinkron busz, és külön vezetéket igényel a közös órajel továbbítására.” — Tévedés, a UART aszinkron és nincs órajel vezetéke. ✅ “Az I2C busz használatakor az egyes slave eszközöket egy hardveres cím segítségével lehet azonosítani a buszon.”

Must-know facts

UART: Aszinkron, pont-pont, 2 vezeték.
I2C: Szinkron, busz, címezhető, 2 vezeték.
SPI: Szinkron, busz (Chip Selecttel), nagyon gyors, 4+ vezeték.

I2C and SPI vs. UART from a data access perspective

Mi ez?

I2C/SPI esetén: A szenzorok általában saját belső regiszterfájllal rendelkeznek. A Linux I2C/SPI meghajtónak nemcsak “olvasnia” kell egy bájtfolyamot, hanem konkrét regisztercímekre kell írnia és onnan olvasnia.
UART esetén: Nincs regiszter-címzés. Ez egy szabad formátumú adatfolyam (stream), mintha egy konzolon gépelnél.

Exam trap detector ❌ “A Linux UART meghajtóján keresztül a cél-eszköz belső memóriájának konkrét címeit olvashatjuk ki.” — Tévedés, ez az I2C/SPI (pl. egy LM75 hőmérő) működése. A UART csak egy adatfolyam. ✅ “Az I2C eszközökkel való kommunikáció során a master általában egy regisztercímet küld el, hogy meghatározza, melyik adatot kívánja kiolvasni.”

Must-know facts

I2C/SPI: Regiszter-alapú memória modell a cél hardverben.
UART: Stream alapú (bytefolyam).

BeagleBone overview: board familiarization, serial console access, peripheral access permissions

Mi ez? A BeagleBone Black egy Texas Instruments AM3358 alapú Single Board Computer (SBC). Fut rajta Linux (Debian/Ubuntu). A J1 nevű 6 pines tüskesor a 3.3V-os Serial Console (UART), amin keresztül hálózat nélkül is bele lehet lépni a Linux parancssorába egy USB-UART átalakítóval.

Exam trap detector ❌ “A BeagleBone Black soros konzoljára közvetlenül ráköthetünk egy szabványos PC-s, 12V-os RS232 portot.” — Tévedés, a BBB 3.3V-os TTL jelszintekkel működik, a 12V megsüti a lapot! ✅ “A BeagleBone Black J1-es tüskesorán található a soros konzol (Serial Console), amely 3.3V-os logikai szintekkel működik.”

Must-know facts

A GPIO lábak (és az I2C/SPI eszközök Linux alatt) általában a root felhasználóhoz tartoznak, így sima felhasználóként a kezelésükhöz megfelelő jogosultságok (sudo vagy megfelelő dialout / gpio csoport) szükségesek.

Root causes of embedded SW development problems

Mi ez? Miért nehéz a beágyazott szoftver fejlesztése? Mert a hardver (HW) bonyolult és változatos, a fejlesztői eszközök sokfélék (cross-compiling), nehéz a debugolás (sokszor csak egy villogó LED vagy oszcilloszkóp van), a “normális működés” kódja mellett masszív mennyiségű kód kell a környezeti/HW hibák (Error Handling) kezelésére.

Exam trap detector ❌ “A beágyazott rendszerek szoftverfejlesztése azért egyszerűbb, mert a kód 90%-a kizárólag a normális működést fedi le.” — Tévedés, pont az a baj, hogy a kód zöme a hibakezeléssel (hibás szenzor, szakadás) foglalkozik. ✅ “A beágyazott rendszerek szoftveres hibakeresése (debugging) gyakran speciális műszereket és keresztfordítós (cross-compilation) környezetet igényel.”

Must-know facts

A problémák nagy része a fizikai beágyazó környezet váratlan viselkedéséből fakad.

Embedded software (firmware): key properties and how it differs from “classical” software

Mi ez? A firmware szorosan kötődik az egyedi hardverhez (Hardware/Software Codesign). Míg egy klasszikus SW PC-n elfut bármin (absztrakciós rétegek miatt), a firmware memóriaszinten ismeri a hardvert. Gyakran költségérzékeny, biztonságkritikus, és a hibajavítás a kiadás után (visszahívás, frissítés) rendkívül drága.

Exam trap detector ❌ “Az elkészült beágyazott szoftverek (firmware-ek) hibajavítása a felhasználóknál mindig olcsóbb, mint az asztali szoftvereké.” — Tévedés, sokkal drágább és bonyolultabb (néha autót kell szervizbe vinni érte). ✅ “A firmware-t és a céleszköz hardverét sok esetben párhuzamosan fejlesztik (Hardware/Software Codesign).”

Must-know facts

Költségérzékeny (sokmilliós darabszám x 1 cent hardver spórolás).
Nincs mindig kényelmes OS a kód alatt.

BSP (Board Support Package): precise definition and typical properties

Mi ez? A BSP (Board Support Package) az a szoftvercsomag, amelyet a hardver (SoC/SoM) gyártója biztosít. Tartalmazza a memóriavezérlők, órajelek, alapvető perifériák (UART, Ethernet) inicializálásához szükséges kódot, a bootloadert, és (ha van) a hardverhez igazított OS kernelt (pl. Linux kernelt Device Tree-vel).

Exam trap detector ❌ “A Board Support Package (BSP) egy független szoftverfejlesztő IDE, ami minden mikrokontrollerhez használható.” — Tévedés, a BSP specifikus egy adott hardver (Board) inicializálásához, és a gyártó adja. ✅ “A BSP tartalmazza azokat a hardverspecifikus beállításokat és alapvető illesztőprogramokat, amelyek szükségesek az OS elindulásához az adott panelen.”

Must-know facts

Minimalizálja a fejlesztő dolgát a hardver életre keltésekor.

OS types in embedded systems: NoOS, hidden OS, embedded OS — comparison

Mi ez?

NoOS / Bare Metal: Nincs operációs rendszer. Egy main() függvényben egy végtelen while(1) ciklus pörög. Olcsó, gyors, memóriatakarékos.
Hidden OS: A programozó keretrendszert lát (pl. Arduino setup() és loop()), de a háttérben futhat egy RTOS (pl. ESP32 esetén FreeRTOS a Wi-Fi és TCP/IP kezelésére).
Embedded OS: Teljes értékű RTOS (FreeRTOS) vagy beágyazott Linux. Ad thread kezelést, memóriavédelmet (Linuxnál) és hálózati stacket.

Exam trap detector ❌ “Az Arduino ESP32-es platformján a program kizárólag Bare Metal módban fut, mindenféle operációs rendszer nélkül.” — Tévedés, az ESP32 Arduino alatt rejtve fut a FreeRTOS. ✅ “Bare Metal (NoOS) rendszerek esetében a TCP/IP kommunikáció megvalósítása extrém bonyolult lehet a fejlesztő számára OS támogatás nélkül.”

Must-know facts

Komplex hálózati funkciók igénylik a (legalább) Embedded OS jelenlétét.

Round-robin (körforgó) scheduling: structure and properties

Mi ez? A legegyszerűbb Bare Metal architektúra (Superloop). A main() függvény végtelen ciklusában a részfeladatok (Device1_func(), Device2_func()) egymás után, sorban futnak le.

How it works Végtelen while(1) ciklus -> Task A -> Task B -> Task C -> Vissza az elejére.

Exam trap detector ❌ “A körforgó (round-robin) ütemezés kiválóan alkalmazható hard real-time rendszereknél, mert válaszideje nagyon alacsony.” — Tévedés, a válaszidő a legrosszabb esetben az összes többi task végrehajtási idejének összege. ✅ “A körforgó (round-robin) architektúrában nincs kontextusváltási overhead, mivel megszakítások nélkül, egyetlen szálon fut.”

Must-know facts

Worst-case válaszidő: Az összes többi feladat futási idejének az összege.
Előnye: Nincs lockolás (kölcsönös kizárás), nincs kontextusváltás.

Round-robin with interrupts: structure and properties

Mi ez? A főprogramban továbbra is körforgó ciklus fut, de a nagyon időkritikus feladatokat hardveres megszakítások (Interrupts / ISR) veszik át. A megszakítás beállít egy “flag”-et, a fő ciklus pedig reagál rá.

Exam trap detector ❌ “Körforgó megszakításos architektúra esetén az adatok megosztása az ISR és a fő ciklus között semmilyen szinkronizációt nem igényel.” — Tévedés, a megszakítás bármikor megállíthatja a fő ciklust, ezért a közös változóknál (pl. flageknél) kölcsönös kizárást/atomi műveletet kell biztosítani. ✅ “Ebben az architektúrában a nagyon időkritikus kód a megszakításkezelőben (ISR) fut le, míg a lassabb adatfeldolgozást a fő ciklus végzi.”

Must-know facts

Sokkal jobb válaszidő a kritikus hardvereseményekre.
Itt már megjelenik a “Kölcsönös kizárás” (Mutual Exclusion) problémaköre (volatilis/atomic flag-ek kellenek).

Function-queue scheduling: structure and properties

Mi ez? Egy queue-ba (FIFO sorba) tesszük a végrehajtandó feladatokra (függvényekre) mutató pointereket (Function Pointers). A fő ciklus a queue-ból szedi ki a függvényeket és futtatja őket. (Gyakorlatilag egy prototípus OS).

Exam trap detector ❌ “A függvény-sor (function-queue) alapú ütemezés preemptív, vagyis bármikor megszakíthatja a folyamatban lévő feladatot.” — Tévedés, ez kooperatív. A futó feladatnak le kell futnia a végéig, mielőtt a következőt kiveszi a queue-ból. ✅ “A függvény-sor alapú ütemezés esetén a worst-case válaszidőt a leghosszabb ideig futó feladat határozza meg.”

Must-know facts

Nem preemptív.
Kezeli a prioritásokat, ha a queue prioritásos!

Framework with hidden OS: core advantage and disadvantage

Mi ez? Olyan platform (pl. ESP32 Arduino), ahol a setup() és loop() mögött valójában egy RTOS pörög (pl. hálózatkezelésre külön task van fenntartva).

Előny: A programozónak nem kell értenie az operációs rendszerek elméletéhez, gyors a fejlesztés.
Hátrány: Az OS a háttérben erőforrást fogyaszt (processzor, RAM), és a programozónak tudnia kell (gyakorlati szinten), hogy a kódja alatt konkurens szálak futhatnak, amik blokkolhatnak.

Exam trap detector ❌ “A rejtett operációs rendszeres keretrendszereknél a fejlesztőnek kötelező minden szálat és szemafor mechanizmust manuálisan létrehoznia.” — Tévedés, pont ez van elrejtve előle. ✅ “Bár a fejlesztőnek nem kell tudnia felépíteni egy OS-t, tisztában kell lennie azzal, hogy a háttérfeladatok (pl. Wi-Fi stack) CPU időt emésztenek fel a loop() elől.”

Must-know facts

A komplexitás el van rejtve, de a fizikai limitációk (CPU idő) megmaradnak.

FreeRTOS: fundamental properties; SMP MCU OS pros/cons and rationale

Mi ez? A FreeRTOS egy nagyon népszerű, nyílt forráskódú, valós idejű operációs rendszer mikrokontrollerekre. Támogat többmagos (SMP - Symmetric Multiprocessing) MCU-kat is (pl. ESP32). SMP esetén az OS dinamikusan ütemezi a taszkokat a magok között. Bár jól hangzik, beágyazott környezetben gyakran statikus ütemezést használnak (egyik mag kezeli a rádiót, másik a logikát), mert a dinamikus ütemezés kontextusváltási overheadet okoz és rontja a hard real-time determinizmust.

Exam trap detector ❌ “Beágyazott, valós idejű többmagos (SMP) rendszerekben mindig a dinamikus feladatelosztás a leghatékonyabb, mert garantálja a leggyorsabb hard real-time válaszidőt.” — Tévedés, a dinamikus elosztás bizonytalanságot és overheadet hoz be. Gyakran statikus a feladatkiosztás. ✅ “A FreeRTOS alkalmazása és az OS maga általában egyetlen végrehajtható bináris fájlba (image) fordul össze.”

Must-know facts

Nincs MMU (virtuális memória védelem).
A Kernel és az Alkalmazás egybe van fordítva (statikus).

Linux: fundamental properties in embedded context

Mi ez? Teljes értékű OS memóriavédelemmel (MMU), fájlrendszerrel, felhasználókkal, hálózati stackkel. Bár a beágyazott világban hatalmas az erőforrásigénye és nehéz hard real-time működést kicsikarni belőle (ahhoz Real-Time patch kell), cserébe masszív ökoszisztémát (driverek, hálózati szolgáltatások) ad.

Exam trap detector ❌ “A Linux alapértelmezett, gyári kernellel azonnal tökéletes hard real-time garanciákat nyújt.” — Tévedés, a standard Linux nem real-time. Patch kell hozzá (PREEMPT_RT). ✅ “Beágyazott Linux esetén a hardver elérése drivereken keresztül, kernel módban történik, a megszakításokat is a kernel fogadja.”

Must-know facts

Szeparált kernel és user-space (jó biztonság/stabilitás).
Az életciklusa más: bootol, betölti a fájlrendszert, és onnan indítja az alkalmazásokat dinamikusan.

Choosing between FreeRTOS/Zephyr and Linux: decision criteria

Mi ez?

Mikor MCU + FreeRTOS: Szigorú hard real-time, milliszekundumos válaszidő, alacsony fogyasztás (elemes működés), kevés memória, alacsony költség.
Mikor SoC + Linux: Bonyolult hálózati kommunikáció (VPN, adatbázis kliens), GUI képernyő, hatalmas adatmennyiség tárolása/feldolgozása, meglévő szoftveres ökoszisztéma újrafelhasználása.

Exam trap detector ❌ “Ha a rendszernek egy 3D-s grafikus interfészt és egy webszervert is futtatnia kell, a FreeRTOS jobb választás, mint a Linux, mert gyorsabb.” — Tévedés, erre az MCU gyenge, és a Linux GUI/hálózati stacje sokkal alkalmasabb. ✅ “A FreeRTOS és társai statikus feladatkészlet és korlátozott hardvererőforrás esetén nyújtanak optimális megoldást.”

Must-know facts

Linux: Komplexitás (Network, UI, Storage).
FreeRTOS: Hatékonyság, Real-Time, Olcsó HW.

Signal handling steps: generation, delivery, disposition

Mi ez? A UNIX szignálok aszinkron értesítések egy folyamat számára.

Generation (Létrehozás): A kernel vagy egy másik process (pl. kill paranccsal) létrehozza a jelet.
Delivery (Kézbesítés): A kernel megpróbálja átadni a célnak. Amíg nem kapja meg, a jel “pending” (függőben lévő).
Disposition / Deposition (Kezelés): A processz reagál rá (pl. lefut a signal handler vagy az OS kilövi a programot).

Exam trap detector ❌ “A létrehozott (generated) szignált a kernel minden esetben azonnal, késedelem nélkül kézbesíti (delivery).” — Tévedés, a szignál pending (függő) állapotba is kerülhet, ha pl. a folyamat épp alszik vagy a szignál maszkolva van. ✅ “A szignálok létrehozását (generation) egyaránt indíthatja a kernel egy hardverhiba (pl. segfault) okán, vagy egy felhasználói folyamat (pl. kill parancs).”

Must-know facts

A szignál a legegyszerűbb IPC (Inter-Process Communication), de nem adatterhelésre tervezték.

Possible reactions to signals

Mi ez? Amikor egy folyamat szignált kap, öt alapértelmezett dolog történhet (Action):

Term: Kilépés (process megölése, pl. SIGINT, SIGKILL).
Ign: Figyelmen kívül hagyás (Ignore).
Core: Kilépés memóriaképpel (Core dump, pl. SIGSEGV).
Stop: Futás felfüggesztése (pl. SIGSTOP).
Cont: Felfüggesztett futás folytatása.

Exam trap detector ❌ “Minden Linux szignál egyénileg felülbírálható és elkapható (catch) a felhasználói program által.” — Tévedés, a SIGKILL (9) és a SIGSTOP (19) nem kapható el, nem ignorálható. Ezt a kernel garantálja a fagyott programok megölésére. ✅ “A SIGKILL szignál alapértelmezett viselkedését egy folyamat nem tudja megváltoztatni vagy figyelmen kívül hagyni.”

Must-know facts

SIGINT (Ctrl+C): Megállítja a programot (Term), de elkapható biztonságos leállításhoz.

Handling signals in a Linux program: which signals to handle

Mi ez? A C kódban a sigaction() (vagy a régebbi signal()) függvénnyel lehet megadni egy handler függvényt egy szignálhoz. Jó gyakorlat a SIGINT (vagy SIGTERM) elkapása, hogy a program bezárja a nyitott fájlokat és lekapcsolja a HW perifériákat (pl. GPIO-t nullára húzza) kilépés előtt.

Exam trap detector ❌ “A szignálkezelő (signal handler) rutint mindig érdemes a lehető leghosszabbra írni, beleértve a fájlmentéseket és a printf utasításokat is.” — Tévedés, a signal handler megszakítja a program normál futását (mint egy interrupt). Rövidnek kell lennie, és sok függvény (pl. printf) “async-signal-unsafe”, azaz tilos benne hívni. ✅ “A beágyazott programoknál a SIGINT elkapása lehetőséget ad a biztonságos szoftveres és hardveres leállásra.”

Must-know facts

A szignálkezelő ideális esetben csak egy volatile sig_atomic_t típusú globális flag-et (jelzőbitet) billent be, amit a főprogram while ciklusa érzékel és nyugodtan kilép.

Effect of signals on blocking API calls: sleep() as the worked example

Mi ez? Ha a program hív egy blokkoló rendszerhívást (pl. sleep(), read()), és közben érkezik egy szignál, a rendszerhívás azonnal megszakad! A szignálkezelő lefut, de a blokkoló hívás nem folytatódik onnan, ahol tartott, hanem hibával tér vissza (EINTR - Interrupted system call).

Exam trap detector ❌ “Ha a program egy sleep(10) utasítás alatt kap egy megszakítást az 5. másodpercben, a szignálkezelő lefutása után automatikusan alszik még 5 másodpercet.” — Tévedés, a sleep megszakad, visszatér az 5-ös értékkel, és a kód fut tovább. ✅ “A blokkoló rendszerhívások, mint például a sleep(), szignál érkezésekor megszakadhatnak, és beállítják az EINTR hibakódot.”

Must-know facts

Ha valós idejű pontos várakozás kell, a sleep()/usleep() nem megbízható a szignálok miatt.

System call: API vs ABI

Mi ez?

API (Application Programming Interface): Magas szintű, C nyelvű interfész (pl. printf(), a glibc része), amit a programozó hív. (Mint egy Java Interface).
ABI (Application Binary Interface): Az alacsonyszintű kapocs a user-space és a kernel között. Hardver (architektúra) specifikus, CPU regisztereken és szoftveres megszakításokon (trap) keresztül történik a tényleges syscall.

Exam trap detector ❌ “A beágyazott Linux fejlesztése során a programozóknak rutinszerűen magát az ABI-t kell meghívniuk Assembly kódból a perifériák kezeléséhez.” — Tévedés, a fejlesztők a magas szintű glibc API wrapper függvényeit (pl. open(), read()) használják. ✅ “A libc könyvtár elfedi a platformspecifikus ABI hívások részleteit a programozó elől.”

Must-know facts

A valódi rendszerhívás (syscall) az ABI szintjén történik.
Az strace az ABI (syscall) szintű hívásokat látja.

Typical I/O operation flow in Linux

Mi ez? User-space program nem nyúlhat közvetlenül a hardverhez.

Az alkalmazás Syscall-lal (pl. read()) megkéri a kernelt az I/O műveletre.
Az alkalmazás blokkolódik (várakozik).
A kernel elindítja a hardveres folyamatot.
Amikor a hardver végez, ad egy megszakítást (interrupt) a CPU-nak.
A kernel feldolgozza az adatot, visszatér a Syscall-ból, és a user-space app folytatja a futást.

Exam trap detector ❌ “Egy olvasási rendszerhívás (read) során a felhasználói (user-space) program aktív várakozással (polling) figyeli a hardver állapotát.” — Tévedés, a user-space app jellemzően passzívan blokkolódik, az OS pedig egy hardveres megszakításra ébreszti fel. ✅ “A Linux kernel az I/O művelet befejeződéséről egy hardveres megszakítás (interrupt) révén értesül a perifériától.”

Must-know facts

A rendszerhívások alapértelmezetten blokkolnak.
“Minden fájl” UNIX-ban (a perifériák is).

Linux kernel interface: device files and IOCTL

Mi ez? A Linux a perifériákat (kivéve hálózat) a /dev/ mappában lévő Device File-okon keresztül mutatja (pl. /dev/ttyUSB0 soros port). Olyan, mintha szövegfájlok lennének: lehet őket open(), read(), write(), close() hívásokkal kezelni. Ha egy specifikus hardveres konfigurációt kell beállítani (pl. baud rate egy UART-nál), arra a mindenes IOCTL (Input/Output Control) rendszerhívás való.

Exam trap detector ❌ “A Linux rendszerekben a hálózati kártyákat is a /dev/ könyvtárban található device file-ok olvasásával kezeljük.” — Tévedés, a hálózati interfészek (pl. eth0) a Linuxban kivételek, nincsenek device file-ként a /dev-ben, socketeken keresztül érjük el őket. ✅ “Az IOCTL rendszerhívás segítségével olyan hardverspecifikus beállítások is elvégezhetők, amelyekre a sima read/write nem alkalmas.”

Must-know facts

Block device (pl. merevlemez) vs. Character device (pl. soros port).
ioctl = a svájcibicska a hardver konfigurálására.

Kernel vs user-mode drivers: comparison

Mi ez?

Kernel-mode driver: Az OS kernelébe beépülő, kiváltságos jogokkal futó kód. Hibája (kernel panic) összeomlasztja az egész rendszert. Nagyon nehéz megírni.
User-mode driver: Sima felhasználói program, ami a kernel által biztosított általános interfészeket (pl. sysfs, libusb, /dev/mem) használva vezérli a hardvert. Biztonságosabb (ha kifagy, a kernel fut tovább), gyorsabb fejleszteni, de lehet egy kis kontextusváltási lassulás (overhead).

Exam trap detector ❌ “A user-space driverek fő előnye, hogy hibás működésük esetén azonnal újraindítják a teljes operációs rendszert.” — Tévedés, az előny pont az, hogy nem fagyasztják ki az OS-t, csak a driver program omlik össze. ✅ “User-mode driver írása során a fejlesztő mentesül a Kernel módú programozás szigorú szabályai alól, de cserébe rendszerhívási overhead-del kell számolnia.”

Must-know facts

Ha nem kritikus a sebesség, a User-space driver olcsóbb és biztonságosabb.

Embedded peripheral lifecycle

Mi ez? Az OS és az alkalmazás számára le kell kezelni a periféria és a fizikai beágyazó környezet életciklusát: a tápfeszültség bekapcsolásától, az operációs rendszer bootolásán és a hibaállapotok (szakadás, zárlat) kezelésén át a biztonságos leállításig.

Exam trap detector ❌ “A beágyazott rendszereknél az áramellátás megszűnése (táp kihúzása) az eMMC és SD kártyák számára teljesen veszélytelen művelet.” — Tévedés, a flash memóriák írás közbeni áramkimaradásnál könnyen korrumpálódnak (adatvesztés). ✅ “A perifériák inicializálásakor figyelni kell arra, hogy a kimenetek beállítása ne okozzon veszélyes tranzienst a csatlakoztatott fizikai berendezésben.”

Must-know facts

Egy rendes beágyazott program leálláskor (shutdown/SIGINT) elengedi a lefoglalt I/O lábakat (unexport / alapállapotba állítás).

GPIO properties

Mi ez? A General-Purpose Input/Output (GPIO) a legpuritánabb digitális láb. Vagy magas (1) vagy alacsony (0) logikai szinten van. Hardveres tulajdonságai: felhúzó/lehúzó (pull-up/pull-down) ellenállásokkal konfigurálható a bizonytalan bemenetek elkerülésére.

Exam trap detector ❌ “Egy beágyazott SoC GPIO bemenetére szabadon köthetünk magas feszültségű jeleket is, ha szoftveresen megfelelő állapotba konfiguráljuk.” — Tévedés, a maximális jelszintet (pl. 3.3V) a hardver toleranciája adja, a túlfeszültség megsüti a chipet. ✅ “A GPIO bemenetek lebegésének (bizonytalan állapot) elkerülésére felhúzó (pull-up) vagy lehúzó (pull-down) ellenállásokat kell konfigurálni.”

Must-know facts

A GPIO a legegyszerűbb, de leggyakoribb felület (pl. LED-ek, gombok, egyszerű szenzorok).

GPIO SW architecture & sysfs vs chardev

Mi ez? Két fő módja van a GPIO kezelésének Linuxban user-space-ből:

sysfs (elavult): Fájlok írása/olvasása a /sys/class/gpio/ mappában. (Olyan mint fájlba írni: echo 1 > value). Lassú, és problémás a jogosultságkezelése, több program egyszerre simán összezavarhatja.
chardev (modern): A /dev/gpiochipX karakteres eszközökön keresztül IOCTL hívásokkal. Biztonságos, engedélyezi több láb atomi (egyszerre) átváltását, és modern.

Exam trap detector ❌ “A sysfs alapú GPIO kezelés az új, modern és hivatalosan támogatott módszer a Linux kernel 4.8 után.” — Tévedés, a sysfs deprecated (elavult), a chardev a modern módszer. ✅ “A chardev architektúra támogatja több GPIO láb állapotának egyidejű (atomi) módosítását.”

Must-know facts

sysfs: /sys/class/gpio - könnyű shell szkriptből, de elavult.
chardev: /dev/gpiochip* - C/C++ programból API-n keresztül (pl. gpiod), robusztus.

Linux I2C subsystem: kernel driver vs. user-space access modes

Mi ez?

Kernel I2C driver: Ha az I2C szenzorra van kész Linux modul (pl. egy LM75 hőmérőre), az beépül az OS-be, és a szenzor értéke kényelmesen olvasható pl. egy /sys/class/hwmon/ fájlból. A kernel mindent elintéz.
User-space I2C (i2c-dev): A buszt nyitjuk meg (pl. /dev/i2c-1), és C kódból vagy shellből (i2ctools) direkt küldjük az I2C parancsokat és byte-okat. Ha egyedi vagy új chipet forrasztunk fel amihez nincs Linux driver, így kell kezelni.

Exam trap detector ❌ “A user-space I2C programozás során a fejlesztőnek egy C programban szoftveresen kell generálnia (bit-bang) a fizikai SDA és SCL órajeleket.” — Tévedés, a Linux I2C alrendszere elvégzi az alacsony szintű buszvezérlést, a user-space csak a bájtokat adja át az IOCTL-en keresztül. ✅ “Az i2ctools (pl. i2cdetect, i2cget) segítségével user-space-ből is lekérdezhetjük a buszra kötött I2C eszközök regisztereit anélkül, hogy külön kernel drivert írnánk hozzájuk.”

Must-know facts

/dev/i2c-X az i2c busz user-space interfésze.

libusb: fundamental properties and when to use it

Mi ez? A libusb egy C könyvtár, ami lehetővé teszi, hogy user-space-ből írjunk USB drájvereket. Ha van egy custom USB eszközöd (pl. egyedi szenzor), nem kell bonyolult C kernel drivert írnod, egy Python vagy Java appól a libusb hívásokkal simán tudsz az USB endpointokra adatot küldeni.

Exam trap detector ❌ “A libusb használata elengedhetetlen, ha egy szabványos USB pendrive-ot (Mass Storage) vagy egeret (HID) szeretnénk használni Linux alatt.” — Tévedés, az ilyen standard eszközökhöz a Linux kernel beépített drájvere tökéletes. A libusb az egyedi/specifikus eszközökhöz kell. ✅ “A libusb használatával a fejlesztők user-space alkalmazásból férhetnek hozzá egyedi USB eszközök adatfolyamaihoz (endpoint-ok).”

Must-know facts

Multiplatform (működik Windowson, Macen is).
Csak nem-szabványos (custom) USB eszközökhöz érdemes használni.

TUN and TAP: core idea of each

Mi ez? Virtuális hálózati interfészek. A kernel úgy tesz, mintha lenne egy fizikai hálókártyád (pl. eth0), de az ide érkező csomagokat egy futó user-space C/Java program kapja meg feldolgozásra.

TAP: Ethernet (Layer 2 - MAC cím) szintű csomagokat ad/kér. (Bridge-eléshez).
TUN: IP (Layer 3 - IP cím) szintű csomagokat ad/kér. (Routinghoz, pl. VPN kliensek).

Exam trap detector ❌ “A TUN interfész Layer 2-es, vagyis Ethernet kereteket használó virtuális eszköz, amit főként hálózati bridge-elésre használnak.” — Tévedés, a TAP a Layer 2, a TUN a Layer 3 (IP szintű). ✅ “A VPN kliensek gyakran használnak TUN/TAP interfészeket, hogy a titkosított hálózati forgalmat egy virtuális hálózati kártyaként láttassák az operációs rendszer felé.”

Must-know facts

TUN = Network layer (L3, IP).
TAP = Data link layer (L2, MAC).

BeagleBone SBC console port

Mi ez? A BeagleBone-on egy 6 tüskés (J1) port adja a soros konzolt (Serial Console). Ezen a porton rögtön bekapcsolás után ömlik kifelé a bootloader (U-Boot) és a Linux kernel logja, és ha bebootolt, ad egy root parancssort. Hibakereséshez létfontosságú (kiderül, miért fagyott le az OS mielőtt a hálózat felállt volna).

Exam trap detector ❌ “A BeagleBone soros konzolja kizárólag a már teljesen elindult Linux és a hálózat felépülése után válik elérhetővé.” — Tévedés, a betáp pillanatától kezdve kommunikál (kiírja a boot folyamatot is). ✅ “A soros konzol USB-UART átalakítóval történő bekötéséhez feltétlenül figyelni kell arra, hogy 3.3V-os jelszinteket alkalmazzunk.”

Must-know facts

Baud rate tipikusan: 115200.
TX, RX és GND (Föld) pineket kell bekötni. 3.3V logikai szint.

GPIO via sysfs: configuring output, setting value

Mi ez? A sysfs módszernél (bár elavult) bash parancsokkal tudsz GPIO-t váltani a /sys/class/gpio mappában.

echo PIN_SZAM > export (Aktiválás)
echo out > gpioPIN_SZAM/direction (Kimenetté konfigurálás)
echo 1 > gpioPIN_SZAM/value (Magas jelszint beállítása, bekapcsolás)

Exam trap detector ❌ “A sysfs GPIO használatánál a láb értékének módosításához a /sys/class/gpio/gpioX/direction fájlba kell 1-et vagy 0-át írni.” — Tévedés, a direction fájl az irányt állítja (in vagy out). Az értéket a value fájlba írjuk. ✅ “A sysfs architektúrában a GPIO láb használatba vételéhez először a láb számát be kell írni az export fájlba.”

Must-know facts

Direction: in (bemenet), out (kimenet).
Value: 0 (alacsony), 1 (magas).

fflush()

Mi ez? C programokban (és Java I/O-ban is) a fájlba írás (pl. fprintf) először egy belső RAM pufferbe kerül a hatékonyság miatt, és nem íródik ki azonnal az operációs rendszer felé. A fflush() kikényszeríti (flush), hogy a pufferelt adat ténylegesen átkerüljön a kernelbe és a fizikai eszközre.

How it works Ha a /sys/class/gpio/gpioX/value fájlba írsz egy C programban egy while ciklusban, de nem hívsz fflush()-t, a LED nem fog villogni, mert a Linux libc-je magában tartja a 1-eseket és 0-kat, amíg be nem telik a puffer.

Exam trap detector ❌ “C programokban a GPIO sysfs értékek (value) fájlba írásakor minden fprintf parancs garantáltan azonnal végrehajtja a fizikai kimenetváltást.” — Tévedés, a pufferelés miatt az adatok a memóriában rekednek fflush() hívása nélkül. ✅ “Az fflush() függvény meghívása üríti a C standard I/O puffert, biztosítva, hogy az adatok a kernel felé elküldésre kerüljenek.”

Must-know facts

Fájl alapú sysfs GPIO kapcsolgatásnál a fflush() kritikus.

Syscall, waiting, blocking: mechanics

Mi ez? Amikor egy program egy I/O műveletre (pl. adat olvasása a hálózatról) vár, a rendszerhívás (syscall) alapértelmezetten blokkol (blocking). Ilyenkor az OS elveszi a CPU-t a programtól, beteszi egy “Várakozó” (Waiting) állapotba, és más programokat futtat, amíg a hardver be nem fejezi a műveletet (amit egy interrupt fog jelezni). (Ugyanúgy működik, mint a Thread blokkolódása Javaban egy adatbázis hívásnál).

Exam trap detector ❌ “Blokkoló rendszerhívás esetén a CPU 100%-os kihasználtsággal pörögve (aktívan) várja az eredmény beérkezését.” — Tévedés, az OS ilyenkor felfüggeszti a programot, így az nem fogyaszt CPU időt. ✅ “A O_NONBLOCK flag beállításával kérhetjük az operációs rendszertől, hogy a fájl megnyitása és olvasása ne blokkoljon.”

Must-know facts

A blokkolás erőforrás-takarékos a CPU szempontjából.
Ha egy blokkolt syscall közben szignál (Signal) érkezik, a hívás megszakad (EINTR).

Task states

Mi ez? Az operációs rendszer ütemezője állapotgéppel követi a processzeket/szálakat.

Létrejön (Created/New)
Futásra kész (Ready): Van memóriája, csak a CPU-ra vár.
Fut (Run): Övé a CPU.
Várakozik (Waiting/Blocked): Rendszerhívás, esemény (I/O, időzítő, szemafor) bekövetkezésére vár. Itt nem foglal CPU-t.

Exam trap detector ❌ “Egy ‘Futásra kész’ (Ready) állapotban lévő szálnak még nincs lefoglalva a memóriája, azt a ‘Fut’ (Run) állapot elérésekor kapja meg.” — Tévedés, a memóriája már megvan, kizárólag a processzor (CPU) kiosztására vár. ✅ “Amikor a várt hardveres esemény (pl. I/O befejezése) bekövetkezik, a ‘Várakozó’ (Waiting) feladat ‘Futásra kész’ (Ready) állapotba kerül.”

Must-know facts

A megszakítások (interrupts) indítják el a visszatérést Waiting -> Ready irányba.

Polling vs interrupt

Mi ez?

Polling (Lekérdezés): A program ciklusban, folyamatosan kérdezi a hardvert: “Kész vagy már? Kész vagy már?”. 100%-os CPU használattal jár, cserébe picit gyorsabban reagálhat a jelre.
Interrupt (Megszakítás): A program elalszik, és a hardver “szól” (megszakít), ha végzett. Alacsony CPU használat, de az OS felébredése, kontextusváltása (overhead) miatt van egy pici késleltetése.

Exam trap detector ❌ “A Polling (aktív lekérdezés) erőforrás-takarékosabb megoldás, mint az Interrupt (megszakítás).” — Tévedés, a polling 100% CPU terhelést okoz. ✅ “Bár a megszakításos (interrupt) módszer kíméli a CPU-t, a megszakítás feldolgozása (overhead) miatt a válaszidő esetenként nagyobb lehet, mint folyamatos polling esetén.”

Must-know facts

Linux alatt a polling a non-blocking syscall, az interrupt a blocking syscall.

Interrupt pitfalls

Mi ez? A túl sok megszakítás túlterhelheti az operációs rendszert (Interrupt Storm). A kontextusváltások megeszik a CPU-t. Megoldás a megszakítás moderáció (interrupt coalescing), pl. nagy terhelésű gigabites hálózati kártyáknál a kártya vár, és csak N csomagonként ad 1 darab megszakítást, vagy a driver ideiglenesen visszavált polling módba.

Exam trap detector ❌ “Nagy terhelésű hálózatok esetén a leggyorsabb hálózatkezelést az garantálja, ha minden egyes beérkező hálózati keret azonnali, külön hardveres megszakítást generál.” — Tévedés, gigabites hálózatoknál a másodpercenkénti 100 ezres megszakítás teljesen kifagyasztaná az OS-t. ✅ “A megszakítás-moderáció (interrupt coalescing) célja, hogy a hardver több eseményt összegyűjtve, egyetlen közös megszakítással jelezze azt a processzornak.”

Must-know facts

Sok apró interrupt elveszi a CPU időt a hasznos programfutástól.

poll() syscall: role and application

Mi ez? A Linux kernel szolgáltatása, ami egy egyszálú programnak (Event Loop) megengedi, hogy több különböző I/O forrásra (fájlleíróra) várjon egyszerre anélkül, hogy véglegesen blokkolódna egyiken. Megadod neki egy tömbben a fájlleírókat, beállítasz egy timeout-ot, ő pedig elalszik. Ha bármelyiken esemény van, felébred.

Exam trap detector ❌ “A poll() rendszerhívás kizárólag egyetlen fájlleíró (file descriptor) állapotának lekérdezésére alkalmas.” — Tévedés, a legnagyobb előnye épp az, hogy egyszerre egy tömbnyi (akár több száz) fájlleírót tud vizsgálni. ✅ “A poll() hívás paramétereként megadható egy timeout érték is, így az alkalmazás a megadott idő letelte után akkor is futási jogot kap, ha nem érkezett semmilyen I/O esemény.”

Must-know facts

Egyszálú (single-threaded) I/O multiplexálásra való.
A POSIX szabvány része (modern alternatívája Linuxon az epoll()).

Multithreaded architecture vs poll()

Mi ez? Konkurens I/O kezelésre két út van:

Többszálú (Multi-threaded): Minden szenzor/kliens kap egy külön Threadet, ami kényelmesen használja a blokkoló read() hívást. Hátrány: A közös memórián keresztüli adatelérés (Mutex, Lock) miatt könnyű deadlocket csinálni, sok szál = sok memória és overhead.
poll() (Event-driven): Egyetlen thread pörög és szolgálja ki az összes I/O eseményt sorban egymás után (mint a NodeJS). Nincs szükség Mutexre (hiszen csak egy szál van), alacsony memóriafogyasztás.

Exam trap detector ❌ “A poll() alapú, egyszálú eseményvezérelt architektúrában a folyamatváltozók védelme érdekében komplex Mutex és RwLock struktúrákat kell alkalmaznunk.” — Tévedés, mivel csak egyetlen szál fut, nincsenek versenyhelyzetek a változókra, nincs szükség Mutexre! ✅ “A többszálú (multithreaded) architektúra többmagos processzorokon könnyen skálázható, míg az egyszálú poll() alapú program eleve csak egy CPU magot képes terhelni.”

Must-know facts

Többszálú program: Lock-ok (Mutex) kellenek.
poll() event loop: Egy magot hajt, nem kellenek lockok a változókra.

Resource, shared resource, mutual exclusion

Mi ez?

Shared resource: Közös erőforrás (pl. egy globális C struct, fájl, vagy egy I2C busz), amihez több szál (Thread) is szeretne hozzáférni egyszerre.
Mutual exclusion (Kölcsönös kizárás): Annak biztosítása, hogy a közös erőforrást adott időben csak egyetlen szál használhassa, elkerülve az adatok inkonzisztenssé válását (Race condition / Versenyhelyzet). A kódnak azt a részét, ahol az erőforráshoz nyúlunk, kritikus szakasznak (critical section) nevezzük.

Exam trap detector ❌ “A kritikus szakasz (critical section) az a memóriaterület a RAM-ban, ahol a globális változók találhatók.” — Tévedés, a kritikus szakasz az a programkód (utasítássorozat), amely hozzáfér a közös erőforráshoz. ✅ “Kölcsönös kizárás hiányában a közös memóriaírást végző szálak könnyen inkonzisztens (érvénytelen) állapotba juttathatják az adatstruktúrát.”

Must-know facts

Kölcsönös kizárás biztosítja az egyidejűség (Race condition) elkerülését.

Passive vs active waiting: comparison

Mi ez? Amikor egy szál arra vár, hogy egy másik szál elengedje az Erőforrást (Mutex).

Passzív várakozás (Blocking): A szál átadja a CPU-t az OS-nek (sleep), így nem pazarol processzoridőt. Kicsit lassabb a felébredés.
Aktív várakozás (Spinlock / Busy wait): A szál egy végtelen while() ciklusban pörgetve folyamatosan kérdezi, hogy “Szabad már? Szabad már?”. 100% CPU-t eszik, de ha a várható várakozási idő nagyon rövid (pár mikroszekundum), gyorsabb, mint az OS kontextusváltása.

Exam trap detector ❌ “Az aktív várakozás (spinlock) kifejezetten ajánlott, ha a megosztott erőforrást előreláthatólag nagyon hosszú ideig tartják lezárva.” — Tévedés, pont olyankor pazarlás pörgetni a CPU-t. Hosszú lockra a passzív várakozás (Mutex) való. ✅ “Passzív várakozás alkalmazásakor a szál feladja a CPU futási jogát, így energiát és processzoridőt takarít meg.”

Must-know facts

Rövid lock = Spinlock (aktív).
Hosszú lock = Mutex (passzív).

Mutex, rwlock, spinlock

Mi ez?

Mutex (Mutual Exclusion): Klasszikus passzív zár. 1 szálé a lock, a többiek blokkolva alszanak.
rwlock (Read-Write Lock): Megengedett, hogy egyszerre TÖBB szál olvassa az adatot, de ha egy szál ÍRNI akar, mindenki mást kizár. Akkor jó, ha sok az olvasás, ritka az írás.
Spinlock: Aktív zár. A szál pörög a CPU-n (nem alszik be), várva a feloldásra. Gyors válasz, nagy CPU fogyasztás.

Exam trap detector ❌ “A Read-Write Lock (rwlock) lehetővé teszi, hogy több szál egyidejűleg módosítsa (írja) az adatstruktúrát, amíg senki nem olvassa azt.” — Tévedés, író szálból mindig csak egy lehet a kritikus szakaszban! (Multiple readers OR single writer). ✅ “Egy processzoros (egymagos) rendszeren a Spinlock használata könnyen holtponthoz (deadlock) vagy komoly belassuláshoz vezethet.”

Must-know facts

pthread_mutex_t, pthread_rwlock_t, pthread_spinlock_t.
rwlock = Multiple readers, Single writer.

Waiting mechanisms: sleep(), usleep(), nanosleep()

Mi ez? Függvények, amelyekkel egy szál passzívan tud várakozni (elaltatni magát) az OS segítségével. A sleep() másodpercekben, az usleep() mikroszekundumokban mér, a modern és precíz POSIX szabvány a nanosleep() (ami a struct timespec struktúrát használja).

Exam trap detector ❌ “A sleep() függvény használata garantálja, hogy a folyamat mikroszekundum (us) pontossággal ébredjen fel a kért időpillanatban.” — Tévedés, a sleep() csak másodperc (sec) alapú. A usleep() vagy nanosleep() kell hozzá, de egy standard Linux ezeknél sem garantál hard real-time pontosságot. ✅ “Ha egy nanosleep() hívás futása közben egy szignál érkezik a folyamathoz, a várakozás idő előtt megszakadhat.”

Must-know facts

A szignálok (SIGINT stb.) felébresztik/megszakítják az összes sleep hívást (EINTR hibakód).

System time formats: time_t and timespec struct

Mi ez?

time_t: Klasszikus UNIX timestamp. Az 1970. január 1. (UTC) óta eltelt másodpercek száma. Egy szimpla egész szám (integer).
struct timespec: A modern POSIX időformátum. Két része van: tv_sec (másodpercek) és tv_nsec (nanoszekundumok). Ezzel már nanomillió résznyi felbontás is elérhető.

Exam trap detector ❌ “A time_t adattípus nanoszekundum pontosságú időbélyeg tárolására szolgál a Linux kernelben.” — Tévedés, a time_t csak másodperc alapú. A nanoszekundumhoz a struct timespec kell. ✅ “A UNIX timestamp az 1970. január 1-je óta eltelt másodpercek számát méri.”

Must-know facts

time_t = másodpercek (sec).
timespec = másodpercek + nanoszekundumok.

CLOCK_MONOTONIC vs CLOCK_REALTIME

Mi ez?

CLOCK_REALTIME: A rendszer faliórája (Wall-clock time). NTP szinkronizáció vagy az adminisztrátor átállíthatja, visszafelé is ugorhat az időben! Nem szabad stopperelésre (időkülönbség mérésre) használni!
CLOCK_MONOTONIC: Attól a perctől indul, hogy a gép bebootolt, és csakis előre halad. Nem befolyásolja az NTP frissítés. Ez való időintervallumok mérésére (stopperelés).

Exam trap detector ❌ “A CLOCK_REALTIME a legmegbízhatóbb választás két esemény közötti időtartam mérésére, mert nem befolyásolják az NTP időszerverek állításai.” — Tévedés, a REALTIME pontosan azt az időt mutatja, ami átállítódhat (ugorhat is!). A MONOTONIC való időtartam mérésre. ✅ “A CLOCK_MONOTONIC sosem ugrik visszafelé az időben, ami ideálissá teszi szigorú timeout-ok kiszámítására a programban.”

Must-know facts

Stopperként = CLOCK_MONOTONIC
Naptár/Dátumként = CLOCK_REALTIME

Input handling strategies

Mi ez? Három fő módszer egy bemenet (pl. egy gombnyomás vagy hálózati csatlakozás) ellenőrzésére:

Folyamatos Polling (aktív várás): A processzor 100%-on pörgetve kérdezi le a gombot. (Pazarló).
Polling + sleep(): Lekérdezi a gombot, utána alszik (pl. 50 ms-t). Alacsony CPU használat, de 50 ms a késleltetés.
Interrupt alapú / Blokkoló syscall (pl. poll()): Elalszik, és a Linux kernel/hardver felébreszti, abban a pillanatban, ahogy adat érkezett. Nincs CPU pazarlás, azonnali reakció.

Exam trap detector ❌ “A Polling (aktív lekérdezés) kombinálása a sleep() rendszerhívással egyaránt képes garantálni a nulla válaszidőt (késleltetést) és a minimális CPU terhelést.” — Tévedés, a sleep() csökkenti a CPU terhelést, de pont emiatt növeli a válaszidőt (amíg alszik a szál, nem reagál). ✅ “A poll() vagy hasonló blokkoló rendszerhívások használata eseményvezérelt architektúrákban optimális CPU-kihasználtságot tesz lehetővé.”

Must-know facts

A blokkoló rendszerhívás a leghatékonyabb az operációs rendszer felé.

Gyakorló Tesztkérdések (Exam Questions)

1. Melyik állítás IGAZ a valós idejű (real-time) rendszerekkel kapcsolatban? A) A hard real-time rendszereknél a számítási sebességnek meg kell haladnia a 10 GFLOPS-ot. B) A soft real-time rendszerek esetében a határidők lekésése a rendszer azonnali katasztrofális meghibásodásához vezet. C) A real-time rendszer elsődleges követelménye a determinisztikus, garantált maximális válaszidő az eseményekre. D) A valós idejű rendszerek soha nem használhatnak megszakításokat (interruptokat) az események kezelésére.

2. Melyik állítás HAMIS az IP védettségi (ANSI/IEC 60529-2004) szabványra vonatkozóan? A) A besorolás első számjegye a szilárd tárgyak (pl. por) behatolása elleni védelmet jelöli. B) Az IP besorolás egyaránt garantálja az eszköz rezgésekkel és extrém hőmérsékleti sokkal szembeni ellenállását. C) Az IP68-as védettséggel rendelkező eszközök teljesen porvédettek és víz alá is meríthetők. D) A második számjegy a folyadékok (víz) behatolása elleni védelmi fokozatot specifikálja.

3. Melyik állítás IGAZ az MMU (Memory Management Unit) és a védelmi gyűrűk szerepéről a SoC-okban? A) A User mode-ban futó folyamatok az MMU kikerülésével közvetlenül módosíthatják a perifériák hardveres regisztereit. B) Az MMU felelős a futó folyamatok virtuális memóriacímeinek fizikai memóriacímekre történő leképezéséért és elszigeteléséért. C) A beágyazott Cortex-M alapú mikrokontrollerek (MCU) jellemzően mind tartalmaznak teljes értékű MMU-t Linux futtatásához. D) A Kernel mode és User mode elválasztása garantáltan növeli a CPU nyers sebességét és csökkenti a kontextusváltási időt.

4. Melyik állítás HAMIS a beágyazott hardver platformok fogalmaival kapcsolatban? A) A System on Chip (SoC) egyetlen szilícium lapkán integrálja a processzort és a legfontosabb vezérlőket. B) A Single Board Computer (SBC) egy teljesen működőképes, fizikai nyomtatott áramköri lap (pl. Raspberry Pi). C) A System on Module (SoM) egy szabványos tokozású, ám kizárólag a memóriát tartalmazó kiegészítő chip. D) A Package on Package (PoP) technológia segítségével két tokozott chipet (pl. SoC és RAM) forrasztanak egymásra a helytakarékosság érdekében.

5. Melyik állítás IGAZ a beágyazott Linux naplózásával (logging) kapcsolatban? A) Az eMMC / Flash memóriák írási élettartama miatt beágyazott környezetben érdemes minimalizálni vagy távoli hálózatra irányítani a naplófájlok kiírását. B) A syslog() C könyvtári hívás közvetlenül a /home/user/log.txt fájlba végzi a bejegyzések kiírását, megkerülve a kernel démonokat. C) A LOG_DEBUG a legmagasabb súlyosságú riasztási szint a syslog implementációjában. D) A beágyazott Linux rendszereken a Remote Syslog használata minden esetben garantálja a naplók mentését, hálózati megszakadás esetén is visszamenőleg.

6. Melyik állítás HAMIS az A/D (Analóg-Digitális) konverterekkel kapcsolatban? A) A kvantálási folyamat során az A/D konverter a folyamatos analóg feszültségértéket diszkrét, lépcsős digitális értékekké alakítja. B) Egy 12 bites A/D konverter kimenete ideális esetben egy 0 és 4095 közötti egész szám lehet. C) Az időzített (timed) mintavételezés esetén a hardveres időzítő (Timer) tehermentesíti a CPU-t a mérések pontos időközönkénti indításától. D) A mikrokontrollerek A/D konverterei negatív feszültségű bemeneti jeleket is károsodás vagy konverzió nélkül képesek értelmezni alapértelmezett konfigurációban.

7. Melyik állítás IGAZ a Board Support Package (BSP) szoftverkomponensről? A) A BSP egy platformfüggetlen vizuális fejlesztőkörnyezet (IDE) C++ nyelvhez. B) A gyártók által biztosított BSP tartalmazza a hardverspecifikus inicializációs kódokat, bootloadert és az alapvető operációs rendszer integrációt. C) A BSP telepítése automatikusan megkerüli a biztonságkritikus tanúsítási procedúrákat a vasúti iparágban. D) A BSP nem tartalmazhat operációs rendszer szintű drivert, csak felhasználói (user-space) szkripteket.

8. Melyik állítás IGAZ az I2C és a UART kommunikáció összehasonlításakor? A) A UART kommunikáció során a master eszköz a hardveres Slave-cím elküldésével választja ki a célpontot. B) Mindkét protokoll szinkron, azaz egy különálló SCK (Clock) vezetékkel szinkronizálják az adatáramlást a processzorok. C) A Linux alatt az I2C szenzorok gyakran belső regisztercímmel (Register Mapped) érhetők el, míg a UART csak egy szabad formátumú adatfolyam (stream). D) A UART a modern SoC-okban szinte teljesen eltűnt, mert az I2C minden tekintetben gyorsabb és egyszerűbb.

9. Melyik állítás HAMIS a beágyazott operációs rendszerek összehasonlításakor? A) A FreeRTOS-ban jellemzően nincs memóriavédelem, és a kernel egyetlen bináris képbe (image) van fordítva a felhasználói kóddal. B) Egy Linux futtatásához a SoC-nak szüksége van egy MMU-ra (Memory Management Unit) és elegendő külső RAM-ra. C) A Bare Metal (NoOS) fejlesztés előnye a teljes hardver feletti kontroll és a minimális overhead. D) A FreeRTOS rendelkezik a legkiforrottabb, asztali Linux-szal megegyező funkciójú 3D grafikai (GUI) és VPN alrendszerrel.

10. Melyik állítás IGAZ a UNIX szignálok (Jelzések) kezelésére? A) A Linux szignálok érkezésekor az OS sosem szakítja meg a blokkoló rendszerhívásokat (mint pl. a sleep()). B) Bármelyik szignál, beleértve a SIGKILL (9) szignált is, elkapható (catch) és figyelmen kívül hagyható egy jól megírt C programmal. C) A szignálkezelő (signal handler) rutinban javasolt a fájlmentések és bonyolult adatbázis hívások lefuttatása az alapos logolás érdekében. D) A SIGINT (Ctrl+C) szignál elkapásával a beágyazott programok gondoskodhatnak a hardveres perifériák biztonságos állapotba (pl. motor lekapcsolása) állításáról a kilépés előtt.

11. Melyik állítás HAMIS a Linux rendszerhívásaival és diagnosztikai eszközeivel kapcsolatban? A) A valódi rendszerhívások (syscall) a CPU platformfüggő ABI-ján keresztül, kontextusváltással kerülnek át a kernelbe. B) Az strace parancs képes kiírni egy program C kódjában lévő belső függvényhívásokat (pl. egy Math.pow() hívás lépéseit) a forráskód elemzésével. C) A glibc API wrapper függvényei (pl. open()) elfedik a rendszerhívások architektúra-specifikus (pl. ARM vs x86) assembly megvalósítását a fejlesztő elől. D) Egy I/O várakozásnál a Linux kernel jellemzően blokkolja a futó folyamatot, hogy ne pazarolja feleslegesen a CPU időt.

12. Melyik állítás IGAZ a user-mode és kernel-mode eszközmeghajtókra (driverekre)? A) A user-mode driverek kritikus hibája, ellentétben a kernel-mode driverekkel, azonnali Kernel Panic-hoz vezet. B) Kernel-mode driver írásakor a programozó elveszíti az operációs rendszer által biztosított memóriavédelem biztonsági hálóját. C) A libusb segítségével a fejlesztők egyenesen a kernel forráskódjába fordítanak be USB drivert a pendrive-okhoz. D) User-mode driverek fejlesztésekor soha nincs semmilyen kontextusváltási (overhead) lassulás az alkalmazás és az OS között.

13. Melyik állítás HAMIS a Linux GPIO szoftverarchitektúrájával kapcsolatban? A) A modern, hivatalosan támogatott mód a GPIO kezelésére a chardev (/dev/gpiochipX) struktúra alkalmazása. B) Az elavult sysfs megközelítés egyszerű bash szkripteken keresztül is lehetővé tette a GPIO lábak értékének állítását. C) A sysfs felület (/sys/class/gpio) lehetővé teszi több GPIO láb garantáltan egyidejű (atomi) átváltását. D) A BeagleBone Black-en a lábak irányának konfigurálását az out vagy in értékek beírásával határozhatjuk meg a sysfs modellben.

14. Melyik állítás IGAZ a fájl I/O pufferezésre és a perifériakezelésre? A) A standard hibakimenet (stderr) fájlleírója a 0 számú file descriptor. B) A GPIO value értékek fájlba (sysfs) történő írásakor az fflush() függvény kikényszeríti, hogy a C könyvtár puffereiből az adat a kernelbe kerüljön. C) Az fprintf() C függvény a beágyazott Linuxokon minden esetben közvetlenül a fizikai periféria buszra ír, pufferelés nélkül. D) Ha a programot SIGKILL szignállal állítják le, a RAM-ban lévő, be nem zárt (unflushed) pufferek automatikusan kiíródnak az eMMC-re.

15. Melyik állítás HAMIS a poll() rendszerhívásról? A) A poll() lehetővé teszi a fejlesztő számára, hogy egyetlen C szálon több fájlleíró I/O eseményére várakozzon egyszerre. B) A poll() beépítetten tartalmazza a folyamatváltozók globális memóriavédelmét (Mutex), így kizárja a versenyhelyzeteket (Race condition). C) Támogatja a timeout beállítását, így a program felébredhet akkor is, ha semmilyen adat nem érkezett az adott idő alatt. D) Eseményvezérelt architektúrák alapjaként szolgál, ezzel elkerülve a CPU teljes 100%-os leterhelését okozó aktív várakozást.

16. Melyik állítás IGAZ az aktív (Spinlock) és passzív (Mutex) várakozással kapcsolatban? A) A Mutex passzív várakozásnál a szál egy végtelen while ciklusban fut, ami jelentős CPU terhelést okoz. B) A Spinlock alkalmazása akkor javasolt egy többszálas folyamatban, ha a várt erőforrás garantáltan csak nagyon rövid időre (néhány mikroszekundumra) lesz lezárva. C) Egy egymagos (single-core) beágyazott processzoron a Spinlock használata teljesen kizárja a holtpont (deadlock) kialakulásának esélyét. D) A Linux scheduler az aktívan várakozó szálakat automatikusan Waiting állapotba helyezi az energia megtakarítása érdekében.

17. Melyik állítás HAMIS a kölcsönös kizárás (Mutual Exclusion) mechanizmusairól? A) A kritikus szakasz az a programkódrész, amelyen belül az alkalmazás a megosztott erőforráshoz (pl. változóhoz) biztonságosan, atomi módon fér hozzá. B) Az rwlock (Read-Write Lock) lehetővé teszi, hogy egyszerre több szál olvasson egy adatot, de az írást egyszerre csak egy szálnak engedélyezi. C) A Mutex-szel védett kritikus szakaszba egyszerre pontosan annyi szál léphet be, ahány magja (Core) van a processzornak. D) A többszálú környezetben a megfelelő lock-olás hiánya inkonzisztens memóriatartalomhoz (Race condition) vezethet.

18. Melyik állítás IGAZ a Linux rendszeridő-mérési módjairól? A) A time_t adattípus egy lebegőpontos változó, amely mikroszekundum pontossággal követi a faliórát. B) A CLOCK_REALTIME az ideális időzítő pontos stoppereléshez (időtartam-méréshez), mivel azt az NTP sosem állítja át. C) A struct timespec struktúra képes másodperces és nanoszekundumos komponensek együttes tárolására is. D) A CLOCK_MONOTONIC idő visszaugorhat a múltba, amennyiben az operációs rendszer órabeállítása nyári időszámításra vált.

19. Melyik állítás HAMIS az ütemezési elméletekkel kapcsolatban? A) A Bare Metal körforgó (Round-robin) ütemezés teljesen mentes a kontextusváltási időkieséstől (overhead). B) A körforgó (Round-robin) architektúrák esetén a megszakítások (interrupts) integrálása lehetővé teszi az időkritikus események azonnali lekezelését a főciklus lassúsága ellenére is. C) A függvény-sor (function queue) alapú ütemezők preemptív módon, kötelezően megszakítják a futó függvényt a soron következő elem futtatásához. D) Megszakításos (Interrupt) környezetben a főprogram és az ISR (Interrupt Service Routine) között osztott memóriaváltozók alkalmazásakor biztosítani kell az adatintegritást (pl. volatilis változók).

20. Melyik állítás IGAZ a hálózati és rendszer-architektúrákra vonatkozóan? A) A beágyazott rendszerek esetében a “Hardware/Software Codesign” azt jelenti, hogy a firmware és a célhardver fejlesztése szorosan összekapcsolódik és iteratívan hat egymásra. B) A getsubopt() C függvényt a grafikus (X11) ablakok rendereléséhez és méretezéséhez használják a Linux kernelben. C) A TUN és TAP virtuális interfészek lényege, hogy segítségükkel a Linux kernel hardveres megszakításait lehet átirányítani az SPI buszra. D) A “Hidden OS” keretrendszerek, mint az ESP32 Arduino frameworkje, fizikailag kikapcsolják a processzor második magját az energiamegtakarítás érdekében.

Megoldókulcs és Magyarázat (Answer Key)

C – (A hard real-time nem a sebességről, hanem a determinisztikus válaszidőről szól. A ‘D’ hamis, mert az interruptok alapvetőek, az ‘A’ a FLOPS-ok miatt irreleváns, a ‘B’ a soft real-time definíciójánál bukik el.)
B – (A szabvány HAMIS állítása. Az IP szabvány [60529] kizárólag a por és folyadék behatolását vizsgálja, a vibráció/hőmérséklet tesztelésére ott a MIL-STD-810.)
B – (Az MMU végzi a memória lapozását/virtualizációját. Az ‘A’ hamis a védelmi körök miatt, a ‘C’ azért, mert MCU-kban többnyire nincs MMU, a ‘D’ pedig azért, mert az elválasztás overheadet okoz, nem gyorsít.)
C – (A HAMIS állítás. A System on Module (SoM) egy teljes, CPU-t/memóriát tartalmazó modul, nem csak egy memóriachip.)
A – (Az eMMC kopása miatt a túlzott logolást kerülni kell. A ‘B’ azért hamis mert a syslog az OS démonnak delegál, a ‘C’ azért, mert a DEBUG a legkisebb súlyosság [7], a ‘D’ pedig a hálózati megszakadás miatt nem garantálható.)
D – (A HAMIS állítás. Egy átlagos mikrokontroller ADC bemenetét tönkreteszi a negatív feszültség. A többi állítás precízen fedi az ADC tulajdonságait.)
B – (A BSP a hardvergyártótól származó, a bootoláshoz és hardverkezeléshez szükséges kód/driver gyűjteménye. A többi állítás értelmetlen kitaláció.)
C – (Az I2C regiszter-címzős logikát követ, míg a UART stream alapú. Az ‘A’ hamis, mert UART-nál nincs Slave-címzés, a ‘B’ hamis mert a UART aszinkron, a ‘D’ hamis mert a UART ma is elterjedt.)
D – (A HAMIS állítás. A FreeRTOS egy puritán, mikrovezérlőkre írt RTOS, amiben nincsenek komplex Linux-szintű 3D GUI és VPN rendszerek.)
D – (A SIGINT [Ctrl+C] elkapható, hogy biztonságos szoftveres/hardveres leállítás [shutdown] történjen. A SIGKILL nem kapható el, a blokkoló hívásokat az OS megszakítja EINTR-rel.)
B – (A HAMIS állítás. Az strace nem lát be a C kód belső függvényhívásaiba, csak a kernel határt átlépő rendszerhívásokat [syscalls] naplózza.)
B – (A Kernel mode driver összeomlása a memóriavédelem hiányában Kernel Panic-ot, azaz teljes fagyást okoz.)
C – (A HAMIS állítás. A sysfs felület legnagyobb hátránya éppen az, hogy nem támogatja a több lábon történő egyidejű, atomi állítást, szemben a modern chardev-vel.)
B – (A fájlba írás belső puffereit (libc) az fflush() parancs üríti ki, kikényszerítve az I/O adat kernelbe juttatását.)
B – (A HAMIS állítás. A poll() egy egyszálú I/O multiplexer, nem tartalmaz semmilyen beépített memóriavédelmet vagy Mutexet, de mivel csak egyetlen szál fut, eleve nem is jön létre versenyhelyzet a folyamatváltozókra.)
B – (A Spinlock akkor jó, ha a várakozási idő rövidebb, mint az operációs rendszer kontextusváltási ideje [overhead].)
C – (A HAMIS állítás. Egy Mutex-szel védett kritikus szakaszba - függetlenül a CPU magok számától - egyszerre kizárólag egy szál léphet be.)
C – (A struct timespec két tagot tartalmaz: tv_sec és tv_nsec. A ‘B’ azért hamis, mert stopperelni a CLOCK_MONOTONIC-kal kell.)
C – (A HAMIS állítás. A function queue architektúra jellemzően kooperatív, nem preemptív. A hívott függvénynek vissza kell térnie a vezérléssel, nem szakítja meg erőszakosan az ütemező.)
A – (A HW/SW Codesign során a fizikai hardvert és az azt működtető firmware-t szorosan együttműködve fejlesztik a határok optimalizálása miatt.)

Vissza a bloghoz

Tartalomjegyzék

Beágyazott információs rendszerek: ZH felkészítő Jegyzet [Gemini 3.1 Pro (via AI Studio)]

Embedded system: definition

Real-time system: definition, hard vs. soft real-time

Real-time operating system (RTOS): definition, requirements

Cyber-Physical System (CPS): definition

IoT/IIoT vs. CPS: what distinguishes them

CPS architecture: layers and the basic function of each layer

Internet technology problems in CPS environments: real-time, reliability, IT security

IT security and CPS: lifetime/certification challenges

Role of domain/application experts in CPS

ANSI/IEC 60529-2004 (IP rating standard): basics and scope

MIL-STD-810 standard: basics, scope, what it mandates and what it does NOT mandate

Sensor: definition, basic operation, key properties

Actuator: definition, basic operation, key properties

strace: purpose and mechanism

Linux application structure: parts of a Linux program

stdin/stdout/stderr channels and I/O redirection

Configuration management: general purpose and approaches

main() function prototypes: how CLI arguments and environment variables are received

CLI parameter forms and handling tools: getopt()

Embedded system HW components and interfaces overview

Microcontroller vs. SoC: comparison

Protection rings and the role of the MMU in SoCs

Kernel/user-space separation and its consequences; Linux in this context

Virtual memory performance: general case and embedded systems implications

SoC, PoP, SoP, SoM, SBC: definitions and how to distinguish them

getsubopt() and getopt_long(): basic purpose

Logging, log levels, syslog.h usage

Logging challenges specific to embedded systems

Peripheral structure: interface, register file, and peripheral function role

Peripheral addressing: dedicated I/O mapping vs. memory-mapped I/O

Interrupts at the peripheral level

Register file structure: control, status, data registers

PIN configuration and its function

GPIO interface rules: logic level constraints, current limits for input and output

ADC/DAC fundamentals: quantization, signal range, sampling frequency, on-demand vs. timed sampling

Digital inter-component communication options: I2C, SPI, UART basics

I2C and SPI vs. UART from a data access perspective

BeagleBone overview: board familiarization, serial console access, peripheral access permissions

Root causes of embedded SW development problems

Embedded software (firmware): key properties and how it differs from “classical” software

BSP (Board Support Package): precise definition and typical properties

OS types in embedded systems: NoOS, hidden OS, embedded OS — comparison

Round-robin (körforgó) scheduling: structure and properties

Round-robin with interrupts: structure and properties

Function-queue scheduling: structure and properties

Framework with hidden OS: core advantage and disadvantage

FreeRTOS: fundamental properties; SMP MCU OS pros/cons and rationale

Linux: fundamental properties in embedded context

Choosing between FreeRTOS/Zephyr and Linux: decision criteria

Signal handling steps: generation, delivery, disposition

Possible reactions to signals

Handling signals in a Linux program: which signals to handle

Effect of signals on blocking API calls: sleep() as the worked example

System call: API vs ABI

Typical I/O operation flow in Linux

Linux kernel interface: device files and IOCTL

Kernel vs user-mode drivers: comparison

Embedded peripheral lifecycle

GPIO properties

GPIO SW architecture & sysfs vs chardev

Linux I2C subsystem: kernel driver vs. user-space access modes

libusb: fundamental properties and when to use it

TUN and TAP: core idea of each

BeagleBone SBC console port

GPIO via sysfs: configuring output, setting value

fflush()

Syscall, waiting, blocking: mechanics

Task states

Polling vs interrupt

Interrupt pitfalls

poll() syscall: role and application

Multithreaded architecture vs poll()

Resource, shared resource, mutual exclusion

Passive vs active waiting: comparison

Mutex, rwlock, spinlock

Waiting mechanisms: sleep(), usleep(), nanosleep()

System time formats: time_t and timespec struct

CLOCK_MONOTONIC vs CLOCK_REALTIME