Dotaz: ARMbian, raspberry přerušení, timer, sleep?

[Fiuala]

Nemam mohho zkušensotí s programováním pro linux a potřebuji napsat drobnost pro Raspberry Pi 2 v C/C++. To s čím si nevím tak uplně rady je ve své podsttě čítač ,který má počítat náběžné hrany signálu na jednom z GPIO za řekněme 100s.

Knihovna Wiring PI má funkci pro obsluhu přerušení wiringPiISR (),kterou vyvola zvolená událost na GPIO , tady problém není stačí v přerušení inkementovat proměnnou předstvující počet pulsů. Zde si jen nejsem jist, jak je to s prioritou, pokud půjde uloha do sleep, funguje i ve sleep ulohy přerušení od Winirng Pi?

Předevšěím,ale nevím jak co nejpřesněji změřit oněch 100s? Ideální by bylo pokud by šlo přímo využít některý z hw čítačů v procesoru, který by opět při přetečení vyvolat přerušení. Jasně jde to udělat i jako cyklus se sleep 1ms a ten nechat projít 100.000 krát a asi i exituje nějaká funkce navázanaá na některý z čítačů času linuxu. Jde o to, že nevím a potřebuji poradt pokud možno co nejpřesnější a co nejméně zatěžuijící způsob .

Poradíte. Děkuji

Odpovědi

[NN]

pokud půjde uloha do sleep

Tim je mysleno co konkretne?

[Tešař]

Předpokládal bych volání některé s sleep funkci z unistd.h nebo timer.h tj. sleep() , případně usleep() či nanosleep().

[Jendа]

Zde si jen nejsem jist, jak je to s prioritou, pokud půjde uloha do sleep, funguje i ve sleep ulohy přerušení od Winirng Pi?

Ano.

Předevšěím,ale nevím jak co nejpřesněji změřit oněch 100s?

Pokud to stačí s přesností na řádově milisekundy, tak to dělám tak, že zjistím aktuální čas pomocí clock_gettime, a pak si naplánuju usnutí pomocí poll na správný počet milisekund. Pokud potřebuješ větší přesnost, tak bych zkusil naplánovat pomocí poll probuzení o trochu dříve a následně točit gettime ve smyčce. Pro ještě vyšší přesnost tohle spusť jako separátní proces, nastav mu vlastní CPU a vyřaď z toho CPU jiné procesy (isolcpus). Někde na Rootu k tomu psali že

Myslím, že i non-RT kernel má /proc/irq/$IR­Q/smp_affinity, kam lze zapsat CPU mask. Kernel s RT-Preempt navíc vytváří pro každý interrupt handler vlastní kernel thread, kterému lze nastavit RT scheduling class a RT prioritu přes chrt, a případně na něj použít taskset (to ale možná není ani potřeba, když už je nastaveno smp_affinity).

Linux má v tomhle ale pořád ještě rezervy, jeden z největších problémů je, že na všech CPU (i těch vyjmenovaných v isolcpus) se spouští nějaké servisní operace s periodou CONFIG_HZ. Nějakou dobu je k dispozici NO_HZ_FULL option, ale to si podle našich zkušeností moc nerozumí s RT-Preempt, a stejně to funguje jen když je na daném CPU jen jeden thread - viz https://lwn.net/Articles/549580/. Kromě toho pomáhá ještě kernel option rcu_nocbs=<cpu­list>. Na ARM Cortex-A9 se nám ještě osvědčila konfigurace L2 cache CPU locking, tedy pevné vyhrazení části L2 cache pro CPU s realtime tasky. Jak moc je tohle zdokumentované u RPi jsem zatím nezkoumal. Ta izolace ale pořád není úplně dokonalá, zejména při vytváření nových procesů na non-realtime CPU dochází k drobnému "zakopnutí", jehož příčina mi zatím není úplně jasná, možná něco s TLB.

Ideální by bylo pokud by šlo přímo využít některý z hw čítačů v procesoru, který by opět při přetečení vyvolat přerušení.

Možná by kernelový čas mohl mít paradoxně lepší přesnost než čítač ze kterého je odvozený, protože NTP říká, jestli jde špatně, a počítají se korekce.

[VSi]

Pro přesné odměření času je nejlepší použít clock_nanosleep() např. podle příkladu: https://rt.wiki.kernel.org/index.php/Squarewave-example - přesnost je v zásadě nejlepší možná na daném HW, po zprůměrování jitteru minimálně na mikrosekundy. Řešit nějak přímý přístup k HW čítači nemá smysl.

RT-PREEMPT by určitě pomohl, zvlášť pokud na tom HW poběží ještě další úlohy. Vyhrazení jednoho CPU pro tuto úlohu by také pomohlo, ale je třeba nastavit i to IRQ affinity.

Další tipy zde: https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/application_base