Dotaz: Něo jako Real-time computing (RTC) programování na Linuxu?

[Martas]

Nevím, zda je to vhodné místo, ale zeptám se. Na úvod přicházím ze světa MCU Real Time systému, tzn. Programuji v C a C++ . Začal jsme se seznamovat s tím jak dalece by šlo neb nešlo něco z mého světa realizovat na něčem jako je Rasperry, obecně jednodeskoný systém s výkonným ARM a Linuxm (Debian, Armbian adp.). Řekněme, že základní krůčky jsem zvládl, Co tím rozumím, dokáži napsat program, který sleduje stav GPIO, leguje změny, nšjak na ně reaguje a stav umí propagovat přes soket. To včem více než tápu a nevím jak na to je, potřeboval bych aby výše popsaný program nebo činnosti byli roděleny do tří „sekcí“ (priorit) 1. Nejvyšší priorita , tato část by němal proběhnout jednu za sekundu, například čtení GPIO nebo čidel na PSI. 2. Tato část probíhá když přijde dotaz, například ono propagování dat přes Socket 3. Tato část probíhá když je čas nebo jedno za x minut, třeba zápis logu na Flash.

Jak se to řeší, rozdělením na Vlákna nebo jinak a kde k tomu najdu nějaké info ideálně s příklady?

Druhá otázka, V mém světě se počítá s tím, že sytém je schopen fungovat dlouho (léta) a spolehlivě to moc nejde dohromady s tím, že si jak můj program tak systém a ostatní programy neustále něco logují na disk, což u těchto jednodesek často znamená na SD kartu. Existuje nějaké globální systémové řešení životnosti SD karet, nevím napadá mě vyčlenění části RAM na RAMDisk, loguje se na ně a jednou za čas nebo při vypínání se RAMdisk synchronizuje na SD kartu. Nebo jiné řešení? Děkuji všem.

Odpovědi

[X]

https://www.abclinuxu.cz/blog/logic/2023/3/jaky-system-rtos-hal-atd...-volit-pro-mensi-mcu

[MM]

Nejdřív se potřebuješ zamyslet, zda realtime skutečně potřebuješ, pokud něco děláš 1x za sekundu asi nepotřebuješ a RP ti bude stačit.

Skutečné realtime vyžaduje definované odezvy i třeba 10000x za sekundu (i víc a přesně se stejnou prodlevou třeba), a to již na běžném nemodifikovaném linuxu zaručit nelze - hlavně to "ve stejný okamžik" a "s přesně definovanou maximální dobou odezvy". jinak gpio, sockety a logování by neměl být problém.

Častěji se setkáš asi s pythonem např. zde, pro návody i pro 'c' mrkni zde

[luky]

Skutečné realtime vyžaduje definované odezvy i třeba 10000x za sekundu (i víc a přesně se stejnou prodlevou třeba), a to již na běžném nemodifikovaném linuxu zaručit nelze - hlavně to "ve stejný okamžik" a "s přesně definovanou maximální dobou odezvy". jinak gpio, sockety a logování by neměl být problém.

Todle byla pravda mozna tak pred deseti lety. Od te doby je mozne poustet baremetal aplikace na vyclenenych jadrech, pripadne normalni aplikace na isolovanych jadrech s max. latenci mnohem mensi nez tech 100us.

[MM]

Ano,

to mě samozřejmě těší stejně jako tebe, ale nepředpokládám, že by to potřeboval pro jeho aplikaci (nakonec se vyklubalo řízení pece). V případě, že by tak rychlé odezvy potřeboval zkus mu ještě poradit nějaký návod, jak to má udělat (třeba na respberry-pi o kterém píše níže). Mě by to o čem píšeš (že jde tak jednoduše udělat na nemodifikovaném linuxu) taky zajímalo.

[luky]

Ctete Documentation/admin-guide/kernel-parameters.rst, parametry nohz_full, isolcpus, rcu_nocbs.

[MM]

Díky

[PetebLazar]

SD karty s nejdelší výdrží (zápisů) jsou dnes postaveny typicky na režimu pseudo-SLC, tj. do typicky TLC flash buněk (schopných udržet tři bity .. tj. rozlišit osm úrovní prahového napětí?) je zapisován pouze jeden bit (tj. dvě úrovně prahového napětí). To usnadňuje rozlišení úrovní a asi i zvyšuje odolnost vůči chybě při vyšším stupni opotřebení buňky. Například Kingston se svými Industrial si věří na 30K P/E cyklů. Vyhnout se (snížit množství) zápisů na SD určitě její životnosti prospěje.

[BFU]

Jde nasadit xenomai nebo preempt-rt , v obou pripadech je potreba opatchovat kernel, prvni moznost ma lepsi latence.

[Martas]

Děkuji za rekce. A úvod mi dovolte poněkud pravit představy o tom co je nebo není RTOS, rozhodně to není něco co vyžaduje definované odezvy „i vic než 10.000x za sekundu“. Jeden z nejrozšířenějších RTOS systému je FreeRTOS má standartně TICK_RATE_HZ nastaven na 1000 tzn základní časové kvantum s kterým pracuje je 1ms, bez problémů ho jde nastavit na 100, pak bude základní časové kvantum 10ms a pořád půjde o RTOS. Nechci zabředat do podrobností, ale Soft RTOS který bude pouštět úlohu 1x za sekundu by měl zajisti asi toto. Představme si, že řídíme pec, tzn sledujeme teplotu a podle porovnání požadované a změřené teploty buď následující sekundu topíme nebo netopíme zpětná vazba nějaký PID, ale to není důležité. Důležité je, že když tohle poběží hodinu a my budeme měřit počet a přesnou délku oněch sekundových úseků tak nakonec zjistíme, že jich bylo 3600 +- 10 a pokud porovnáme délky jednotlivých okének nebudou se tam běžně vyskytovat ani 100ms ani 10sekundové. Pokud jsem se správně dočetl Linux má 139 priorit pro úlohy a 0 až 99 se považuje za Real Time priority. Vim o několika PLC v kterých je Raspberry Pi a tak snad je v silách Linuxu zajisti, aby jedna úloha napsaná v C měla natolik vyšší prioritu než třeba Lighttd, že i když bude probíhat DDS útok na web měla přednost před zpracováním přijatých paketů. Nebo taky ne, ale aspoň by to program poznal a v peci vypnout topení, v nejhorším i za cenu resetu vyvolaného hw Watchdogem.

Proč to vlastně řeším, kamarád chce abych mu udělal řízení pece (proces ohřevu až 12 hodin). Většina opičáren je typicky komunikace, informávání uživatelů a zadávání parametrů programu je jak dělaná pro něco jako Rasperry PI a je mnohem pohodlnější to udělat na něm než na MCU. Pak je samotné čízení pece tam pro změnu je mnohem jednoduší a bezpečnější to udělat na MCU, ale byli by to dvš desky dvoje programování a řešení komunikace mezi tím nebo to narvat do toho většího s Linuxem.

[X]

Ja bych do toho web, informovani uzivatelu etc. vubec nemichal. At to dela co ma a ven to komunikuje pres API ze ktereho vytahnes stav, nebo naopak posledni konfguraci a nic vic. Zbytek si muzes bezpecne zpracovavat, zobrazovat, grafovat bokem.

Tady mas cerstvou bakalarku Operační systém reálného času s fixní prioritou úloh pro Raspberry Pi na tvuj problem:

https://theses.cz/id/b8n2uo/24656.pdf

[Radovan]

RTFM:

man nice

Jak píšeš, realtime není o tom že systém zareaguje tisíckrát za sekundu, ale že zareaguje nejpozději do té tisíciny sekundy. Což u Linuxu nemusí nastat.

Ale na hlídání pece by měla stačit 8051 vyškrábaná ze staré pračky

[D]

Obecne na toto se pouzivaji PLC, ktery maji ruzne druhy certifikace: zivotnost, vibrace, provozovni teplota atd. Provozni parametry programu nebo kratkodobe trendy se zapisuji do RETAIN pameti PLC nebo FRAM. Dlouhodobe trendy se zaznamevaji do databaze.

[Kit]

Jak tak pročítám diskuzi, tak mi to připadá jako práce pro Arduino nebo max Raspberry Pi Pico, které to zvládnou levou zadní i s logováním.

[Bugsa]

Přesně tak. Nebo když to má umět někam reportovat tak ESP8266, ESP32.

[vlastikroot]

Threadum jde nastavit realtime priorita - prepne se na SCHED_FIFO (kdo prvni prijde prvni bere), SCHED_RR (spravedlive stridani se) nebo moderni SCHED_DEADLINE (bezi thread co potrebuje stihnout deadline). Samozrejme aplikace musi byt spravne napsana, vyreena komunikace mezi thready, locky atd. Tohle vsechno funguje i na standardnim (ne RT) linuxu, RT linux jen optimalizuje nektere cesty aby snizil latenci v reakci na interrupty.