RPi3 - GPIO speed test - mivel?

 ( Jason | 2017. december 14., csütörtök - 12:16 )

Üdv!

Van egy RPi3 játszótársam, és szeretném megmérni, mennyi az elméleti, illetve realista sebesség, amit el lehet érni a GPIO lábakon kifele.

Aki csinált már ilyet, hogyan mérte meg a "lábakat"?
Csak ezért nem akarok szkópot venni, se egyéb műszert... vagy mégis?

Tudom, van ez: http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/, de én csak az általam hamisított statisztikáknak hiszek.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Tipp1: arduino, esp8266/esp32 vagy más uC
Tipp2: Saleae Logic klón csájnából
Tipp3: keresel valakit akinek van szkópja, és meglátogatod a pájoddal.

(Azt nem ajánlom fel, hogy lemérem otthon és megírom, mert nekem se hinnél :)

Koszi!

Tipp2-nek utananezek, nem akarok sokat elbaszni a temara.

Óh, néha magamnak se hiszek xd

Ebay-en olyan 2000 HUF magasságában vannak a klónok.

én naivan azt csinálnám hogy két műszakilag azonosnak mondott pint összekötni, az egyik in a másik out, aztán egy megfelelően gyors nyelven (leginkább C) írni egy scriptet ami elkezd állat módon tolni kifele egy előre definiált random bitstreamet, a másik meg nézi hogy mi jön be, a bejövő streamből binary dump aztán a kettőt összehasonlítani. ezt ismételgetni szépen egyre nagyobb sebességgel, ahol elkezd nőni a diszkrepancia na ott van a határ.


"all submitted complaints will be forwarded to /dev/null for further investigation"

Ez jó módszer, ha azonos sebességgel képes adni és venni is. Ha venni lassabban tud, akkor ezzel nem adod meg a maximumot. Bár eleve értelmetlen a maximummal számolni, mert egy komplett OS van alatta, ami simán bekavarhat az egészbe. Jön egy új kernel, aztán lehet hogy máris pár százalékkal többet tud, vagy épp kevesebbet.

ebben van valami, arról viszont mindenképpen hasznos információt szolgáltat hogy mi az a max sebesség amit még megbízhatóan lehet adatátvitelre használni a GPIO-kon


"all submitted complaints will be forwarded to /dev/null for further investigation"

Ez nem fog menni az utemezes, es a - velhetoen - azonos eroforrasfoglalas miatt.
A saleae klon mar jobb, de velhetoen a rpi3 mar nagyobb sebesseget tud nala. Arduino meg defaultban 16MHz-vel megy, meg a logikai analizatornal is lassabban (az asszem 24MS/s-al megy).

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

ebben van valami. akkor 2 RPi között, kölcsön lehet kérni...


"all submitted complaints will be forwarded to /dev/null for further investigation"

ha csak az a kérdés hogy mi az abszolút maximum sebesség akkor nem nagyon fogod megúszni a külső eszközt. amit az előbb írtam az arra alkalmas hogy kiderüljön mi az a tempó amin még megbízhatóan lehet adatokat átvinni.


"all submitted complaints will be forwarded to /dev/null for further investigation"

Leggyorsabb az SPI csatlakozása. Elvileg 32 millió bit/másodpercre képes egy megfelelően gyors másik hardverrel. Én 8 bites mikrovezérlő SPI-jével kötöttem össze, ahol stabil 1,6 Mbps full duplex kapcsolat volt (itt az AVR8 volt a szűk keresztmetszet).

Egyébként ha nagyon gyors és szabályos ütemezésű I/O kell, akkor a Beaglebone Black-et ajánlom, ahol 14 biten 100 Msps mintatempót tudtak elérni az ARM Cortex A8 mellett található PRU-nak hívott 200 MHz-es I/O proci átprogramozásával.
Lásd még:
http://files.linuxgizmos.com/ti_cpu_pru_block.jpg
http://www.righto.com/2016/08/pru-tips-understanding-beaglebones.html

a pru kiszabott jo a bb-ben. mi adc-t csináltunk benne.
------------------------
Jézus reset téged

Köszi az ötlet, felírom következő hobbyprojektnek :)

Ha bármi okból a Raspberry-hez ragaszkodsz, de kell a feladathoz a garantált szinkron vezérlés, akkor az általam imént írt >> illessz Raspberryre mikrovezérlőt a GPIO UART vagy SPI csatlakozóján keresztül << egy praktikus megoldás.
A Raspberry UART-on vagy SPI-n keresztül csak az előre definiált parancskészlet szerinti parancsot + paramétereit adja át a mikrovezérlőnek, az pedig elvégzi a multitask és bármi zavaró tényező nélküli szinkron bitműveleteket.
Az AVR8 azért volt érdekes, mert a szűz mikrovezérlőre a Raspberry SPI csatlakozásán keresztül tudtam letölteni a mikrovezérlő szoftverét.

Ez az AVR+ISP jo otlet! Egy gondot latok egyebkent vele, vagy 3.3V-rol jaratod, vagy jelszintet illesztesz. Egyik sem lehetetlen, csak enyhe kellemetlenseg.

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

SPI lesz az. Gondolom, a szinkron soros buszra gondolsz, amely lényegében egy shift regiszter.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

AVR-nel ISP-nek hivjak az In System Programmert. De igen, GND+VCC+a speci szerepu RST van az SPI-nak megfelelo 3 pin (MOSI, MISO, SCK) mellett. Ez egy 6 vagy 10 tus (GND 4x + 1 nem hasznalt) csatirol ismerheto fel sokszor.

Ezert is tetszik a felvetes, mert ha a resetet nem basztatod, akkor van egy tapod + SPI a kommunikaciora. Ha meg ujra akarod egetni, akkor mar be is van kotve.

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

Bocsánat, akkor én értettelek félre. :(


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az RPI-n van 3V3Out valamelyik GPIO headeren, az AVR-ek pedig nagyon jol elketyegnek 3V3-rol is :) Pl ATmega328P, teljesen jo. Es akkor akar SPI, akar UART-on is lehet a mikrokontrollerrel beszelgetni mindenfele jelszintillesztes nelkul.

Es ha az AVRdude tud(na) nativ ISP over SPI-t is, akkor ket legy + egy csapas uzemmodban a programozas es a kommunikacio is megoldhato. 1-2 plusz GPIO azert kell ezutobbi esetben is (\RST, \CS), de ott mar aztan tenyleg nem szamit a sebesseg (raadasul ha jol latom, az RPI tud hardveres \CS-t is, szoval megjobb).

Tudja. Az első ilyen kísérletet 4 éve így csináltam. Akkor még fordítani kellett a GitHUB-ról levő frissból. Ma már a Raspbian-ban levő is tudja. Lásd: http://xham.myiot.hu/forum/index.php?topic=183

A 3V3 tápfesz a Raspberry speckója szerint 50 mA-rel terhelhető. Ha több kell, akkor az 5V-ból magad állítsd elő. Szerencsére a mikrovezérlőnek + némi plusz áramkörnek ez elég.

Most egyébként erre vetettem szemet: https://www.aliexpress.com/item/1-pices-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-arduino-Sensing-Evaluation-for-Skiller/32765534610.html
Kérdés, hogy Rpi3 GPIO + OpenOCD segítségével bele tudom-e varázsolni a kódot?

Tudja
Ah, oke. Igen, ha jol latom a nativ avrdude nem tudja de keringenek a neten ilyen linuxspi-s programozokak/peccsek. Mondjuk nem ertem hogy miert nem tudja nativan mert a linux SPI API-ja is viszonylag kiforrott, az AVR ISP meg elegge sztenderdnek tunik (bar ha a pl. STK500-as reteg elnyeli az esetleges apro kulonbsegeket az egyes tipusok kozott akkor nem biztos, ennyire nem mentem meg bele ebbe).

Most egyébként erre vetettem szemet:
Igenigen, ez openocd-vel menni fog, de joesellyel kell meg valami plusz hardver is ami megcsinalja a SWD illesztest (merthogy az SWDIO az ketiranyu, pullup-os vonal). Gondolom ez full nyilt szabvany, szoval nem kizart hogy valakik mar megcsinaltak :)

Köszi hogy szóltál az SWDIO kétirányúságáról. De erre is van megoldás: Input-Output átkapcsolás a GPIO-n.
Lásd: http://catch22.eu/baremetal/openocd_sysfs_stm32/ ... ott az ábra, simán a GPIO-ra rakja (ami default bemenet)
... mire megkapom az STM32-t, már tudni fogom hogyan töltsem rá a kódot RPI-ből. :)

Egyébként mint írtam, a mostani Raspbianos avrdude legutóbbi emlékeim szerint már tudja, nem kell GitHUB-ról fordítani. Azt a hozzászólást még 4 éve írtam, akkor még tákolni kellett.

PC-n pedig annó "bsd" letöltőt használtam. Ez a parallel portból csinál SPI mastert a letöltéshez.
Lásd: "avrdude -c -h"
http://www.qucosa.de/fileadmin/data/qucosa/documents/5550/data/bsd_programmer.png

Köszi hogy szóltál az SWDIO kétirányúságáról. De erre is van megoldás: Input-Output átkapcsolás a GPIO-n.
Ezt nezd meg pontosabban, mert szerintem nem _ugy_ ketiranyu (hogy valtoztatod a DDR-t), hanem pullup-pulldown rendszerben mukodik. Az nem kizart hogy van olyan GPIO amit igy is (open collector v. open drain) uzemben is ki lehet hajtani, de akkor azt kell megnezni hogy mindket iranyban irhato/olvashato-e az adott GPIO-port: azaz igy hajtja meg mind a master (rpi) mind a slave (STM32fFxx).

De ha letezik ilyen RPI-hez irt extension/cfg az openocd-hez akkor biztos minden oke ezekkel :) En egyelore maradtam az stlinkv2-nel illetve a a jovoben a flash write + in-application (re)programming lesz itt is az alap.

Egyébként mint írtam, a mostani Raspbianos avrdude legutóbbi emlékeim szerint már tudja, nem kell GitHUB-ról fordítani
Ah, az lehet. Most itten mezei debian alatt neztem, es ott nem tudta.

Ha az adatot konstans alacsony szintbe teszed, s az irányt hol beforgatod, hol pedig ki, akkor épp egy open drain kimenetet kaptál amelyben a vonalat olvasni is tudod, amennyiben befelé forgattad azt.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jogos, tkp igen ;) Legalabbis AVR-nel egy utasitasbol lehet igy forditani (portxy=0, ddrxy=0 vs. 1). Es ha jol latom, a pinxy az mindket esetben olvashato (persze sok ertelme nincs olvasni akkor ha a ddrxy az 1, de papiron legalabbis lehet). Egyetlen apro hatulutoje lehet hogy a ddrxy-be irt kimenetet akkor invertalni kell. Mas architekturanal (stm32f3xx, arm), ott ezt nem kell invertalnunk mert van egy plusz bit erre.

Akinek mikrokontrolleren problémát okoz egy bit negálása, az menjen inkább kapálni. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ja, nem problema, csak figyelni kell :) Ettol fuggetlenul persze kapalni is jo lesz majd! Egy kis testmozgas sosem art.

Ha konkrétan GPIO-ra akarod használni, akkor a linux több eszközt is ad hozzá, egészen eltérő sebességekkel.
A hivatkozott lista egyébként miért is nem jó?

Reprodukálni akarom, mert ennyire ráérek, illetve megkokeszoltam a programot amit a srác használt, hogy ne a devmem kelljen neki, hanem az újabb /dev/gpiomem (ehhez nem kell root ugye), meg baszkódni kicsit az ütemezéssel és lehet majd ilyen fancy táblázatokat csinálni :)

a rendszer nem realtime. majdnem mindegy egy bizonyos sebesség után.

------------------------
Jézus reset téged

Kérdés, hol van ez a "majdnem mindegy" vonal.

Ugye CNC step-dir vezérlésnél ez egy kardinális kérdés, így a LinuxCNC-s arcok körbejárták ezt a problémát:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TweakingSoftwareStepGeneration#Run_a_Latency_Test

Oh, nice

Ott van, hogy nincs garantálható válaszidőd.
Ha a kernelnek épp jobb dolga van, akkor azzal fog foglalkozni, te pedig a gpio-ddal így jártál. Ezért szoktak a kritikus dolgokhoz valamilyen mikrokontrollert használni, aminek a Pi (vagy akármi más) átadja a szükséges paramétereket, az pedig utána garantált válaszidővel működik. Már ha nem cseszted el a kódot...

valahogy azzal is dumálni kell

Persze, de azzal jó lassan. Mert egy mikrokontrollernek elmesélheted 19200 bit/s-mal is azt, hogy akkor most tessen kitolni magából 1.2 MHz-et. Real time feladatot ne akarj operációs rendszerre bízni. Arra ott a mikrokontroller, benne mindenféle timer-ek, pwm-ek, baud rate generátorok, megannyi hardware támogatás, de assembly-ben CPU időzítéssel is szinte bármit meg tudsz csinálni, mert rajtad múlik, mi történik. Egy oprendszerben meg a kernel gondol valamit, akkor az lesz, vagy akár az egész buszt elveszi a dma kontroller, aztán nézhetsz, hogy most mi van. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Real time feladatot ne akarj operációs rendszerre bízni"
Miért is ne? Linuxnak is van RT ága ami használható, de ott van az RTOS és még kb tucatnyi commercial és ingyenes oprendszer, pont erre a célra.
Ezért van annyi raspberry meg arduino-s szemét project, mert mindenki tákol jobbról balról ahelyett hogy legalább a google-t felcsapná


// Happy debugging, suckers
#define true (rand() > 10)

1x probalgattam a LinuxCNC-t. Es ugy mukodgetett hellyel-kozzel de mar a 30microsec-es jittert is aligalig birta tartani parhuzamos porton. Inkabb a 50-100microsec lenne az amire aztmondanam hogy na, az igy bitbang-szinten vallalhato. Ami persze 2-3 nagysagrenddel jobb mint amit egy mezei preemtiv rendszertol elvarhatunk (es sok feladatra pont jo is lehet), ugyanakkor meg mindig 2-3 nagysagrenddel pontatlanabb mint amit egy AVR + (pl.) UART kombinaciobol kihozhatunk. Egy ARM-mel meg meg egy nagysagrendet lehet javitani.

Egyebkent meg egyetertek a sok "ez megvan irva rpi-re meg arduino-ra _tehat_ biztos fasza lesz" mentalitassal, vagyis az ebbol fakado irdalmatlan mennyisegu ganyolmannyal ami ellepi az osszes internetet. Pont ugyanannyi azokban a hasznalhato programok aranya mint az "ez mar megvan irva python-ban _tehat_ biztos kurvajo es semmit nem kell mar foglalkozni vele" takolasokban.

A linuxcnc nem RT kernellel van. Az egy sima linux, cnc-s cuccokkal megpakolva


// Happy debugging, suckers
#define true (rand() > 10)

A LinuxCNC eleg sok modon hasznalhato (raadasul nem csak cnc-re).
Adnak egy debian alapu telepitot, ami RTAI kernellel jon, de hasznalhatsz Xenomai-t is (mindketto hard realtime, asszem a regi RTL tovabbfejlesztese). A Linux kernel "alatt" fut, azzal vagy a userspace-szel shared memoryn keresztul kommunikal. Irhatsz hozza kisebb real time modulokat, es megadhatod, hogy ezt hogy utemezze (talan interruptot is tud). Amikor nem a te kodod fut, akkor a normal kernelt utemezi (ott van a legtobb driver is), es a sima userspace programok is itt futnak. Ebbol rogton latszik a hatranya: sajat driver kell ahhoz, amit innen hasznalsz (ami egy parport eseten nem gond, de vannak bonyolultabbak is). A masik, hogy ha valamit a Linux kernel hajt, az csak kerulouton jut el hozzad.
Ha masok az igenyeid, van sima RT patch. Ez az utemezovel varial valamit, emiatt soft realtime, de sokkal egyszerubb a hasznalata. Raadasul a driverekkel sem kell annyit trukkozni. Ha van egy modern geped, megengedheted magadnak, hogy a - mondjuk - 8 magbol egy parat adott processzeknek adsz dedikaltan, igy nagyon sok feladatra eleg, sokkal egyszerubben. Egy x64-es gep meg szamitasi teljesitmenyben egyelore veri az ARM (es persze az AVR) vonalat. Ubuntu csomagol RT kernelt is, innentol a karbantartasa sem gond. Egyebkent van LinuxCNC Beaglebone-ra is, Machinekit neven.

Szemely szerint a LinuxCNC alap elkepzeleset mar hatranyosnak tartom, ki lehetne szervezni egy csomo dolgot uC-re, ahol trivialis a RT mukodes. De ez nem jelenti azt, hogy ne lehetne megoldani. A parhuzamos portos stepdires bohockodasrol meg plane le kene szokni.

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

Persze, ez stimmel, de az rtai (ami csak és kizárólag egy interface a kernel irányából) nem valódi rt kernelt takar ;)
Ezert is mondtam hogy az egy sima kernel (szamoljuk le ezt az interface-t mert nem ugyan az)


// Happy debugging, suckers
#define true (rand() > 10)

Ugye, nem kell elhinnem, hogy az valóban real-time? Azért, mert nem erre való, szerintem nem lehet megcsinálni, mert real-time igények is ütközhetnek, továbbá legfeljebb akkor menne, ha kernel modulokat írogatnál assembly-ben.

Ezzel szemben mikrokontrolleren CPU futásidőt is ki tudsz egyensúlyozni úgy, hogy az elágazástól függetlenül ugyanannyi ideig fusson mindkét ág. Valós időre mikrokontroller való, ne akarj meggyőzni arról, hogy egy olyan oprendszernek kell pontosan időzíteni, ahol lehet IT, DMA, de a felsőbb rétegek felé is ő szolgál ki mindent.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hála égnek ez nem hit kérdése, különben nagyon nagyon sok minden nem működne a mai világban ;)


// Happy debugging, suckers
#define true (rand() > 10)

Ez csak azért van, mert

a) programozók hoznak döntéseket villamosmérnökök helyett
b) vannak igénytelen villamosmérnökök, akik úgy vannak vele, ha működik, akkor az egyben jó is.

Pedig dehogy. Az nem jelenti azt, hogy nincs benne potenciális hibalehetőség. Egy elvi kérdés. Ha épp DMA-zol egy blokkot, hogyan szolgálsz ki egy beeső kérést azonnal, valós időben?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

" b) vannak igénytelen villamosmérnökök, akik úgy vannak vele, ha működik, akkor az egyben jó is."
Gondolsz itt arra hogy kiszervez olyan feladatokat egy olyan helyre amit ismer, egy olyan helyről ahol szintén megoldható, de ismeretlen terep? Ismerősnek tűnik

" a) programozók hoznak döntéseket villamosmérnökök helyett"
Igen, logikusnak tűnik hogy olyanok írnak kernelt, akik nem értenek a gépek működéséhez :D

" Ha épp DMA-zol egy blokkot, hogyan szolgálsz ki egy beeső kérést azonnal, valós időben?"
ez a kérdés most egy vicc akar lenni?


// Happy debugging, suckers
#define true (rand() > 10)

Azonnal vagy valós időben?
Lásd alább a kérdés tisztázását, hogy "Mit takar az a fogalom hogy real-time?"

A DMA érdekes téma. Attól hogy pl. egy SPI hardverre DMA-zol attól még a CPU tud dolgozni más I/O-kkal, hiszen

1. felkonfolod a DMA kontrollert (néhány byte) és elstartolod
2. végzed a dolgodat, de másik I/O-k felé (háttérben tököl az adott hardverrel a DMA)
3. a DMA ha kész, interruptot kap a CPU a DMA kontrollertől

A nagyobb gáz, amikor pl. memória defragmentáció miatt RAM-RAM DMA van, ez tényleg meg tudja akasztani a CPU-t a DMA-zás idejére. Ezen azzal lehet segíteni, hogy RT rendszereknél a reagálási idő korlátait figyelembe véve az egyazon RAM-RAM DMA folyamattal másolható blokkméretet a reagálási idővel összhangban korlátozod. Extrém reagálási idő követelmény esetén RAM-RAM DMA off.

Érdekes előadás: https://www.slideshare.net/jserv/realtime-linux
Itt azt vesézi ki az előadó, hogy az RT Linux nem minden követelményhez elég, és csináltak módosításokat (performancia vesztés árán), hogy az esemény bekövetkezésétől számított legrosszabb lekezelési késleltetés szűkebb specifikációt is teljesítsen.

Ha pedig az időosztásos Linux nem elég, akkor mint fentebb már kiveséztük,
- BeagleBone PRU-ja (mint 32 bites 200 MHz-es I/O processzor)
- vagy egyéb külső mikrovezérlő
végezze a szűk időkorlátra specifikált feladatokat és a Linux csak lazább időkorlátokkal rendelkező folyamattal foglalkozzék.

Csak leírtad, amiről én is beszélek. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Attól, hogy kalapácsa van, ezért mindent szögnek néz, még nem lehet minden problémát kalapáccsal megoldani.

Elhiszem, hogy aki kernelt ír, ért a gépek működéséhez. A gond ott van, hogy ellentmondás feszül egy real-time rendszer és egy kernellel szemben támasztott követelményrendszer között. Tehát vagy real-time, vagy kernel. Különben legfeljebb olyan lesz, mint a pulseaudio, amely néha valóban szól. Mondom: néha.

Nem viccnek szántam a kérdést. Arra utaltam, egy nagyobbacska gépben a kölcsönös kizárások - például ilyen a busz foglaltsága - miatt ez a valósidejű mizéria nem fog menni. Ugyan le lehet tiltani egy rakat perifériát, lehet mikrokontrollert csinálni a CPU-ból, csak akkor máris nincs kernelünk, mert nem csinálja azt, amit várunk tőle.

Tudom, hogy létezik realtime kernel, de én ezt úgy tekintem, hogy valamelyik PR-os megdolgozott az év végi prémiumért azzal, hogy kitalálta ezt az elnevezést. Valós idejű az, amit mikrokontrollerre assembly-ben írsz, s kommentben melléírod, mi hány gépi ciklus. Arról elhiszem, a többi vágyálom, valamiféle közelítés. Olyan, mint amilyen közelítése a körnek a szabályos hatszög. :)

Apropó, real-time. Ott van a cache kontroller. Vannak mindenféle pipeline-ok, utasítás queue, cache-ből futás, aztán cache miss, s máris memóriához fordulás van, jó eséllyel burst-ösen. Mi hány órajel lesz pontosan? Hogyan alakulnak majd a futásidők? Mi lesz a jitterrel? Persze, mondhatod, hogy valós idejű rendszerhez legyen hardware támogatás. Akkor lazább a feltételrendszer, de ilyen hardware támogatásnak tekinthetünk egy MCU-t is akár.

Szerintem real-time rendszer az, amelyben például CPU időzítéssel videojelet tudunk előállítani, mint egykor a Sinclair ZX-81-ben. Bár ott volt egy számláló meg egy shift regiszter hardware támogatásként, ha jól emlékszem.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

szkóp

Ön nyert, nyereménye átvételéhez postázzon nekem egyet előbb :-)

Viccet félretéve: ha lenne, ez a poszt se született volna meg... de ha nyerek a lottón, veszek egyet. Vagyis faszt, kölcsönzök egyet.

- Beaglebone PRU + külső A/D a GPIO lábakra
- Red Pitaya - minden benne van ami neked a szkóphoz kell.
https://d1fl6fn6zyj2cc.cloudfront.net/wp-content/uploads/2014/04/redpitaya_hardware1.x77412.jpg

- vagy kész külső hardver: http://my.bitscope.com/store/?p=view&i=item+0
- 32 bites mikrovezérlővel 12 bites felbontással 1 .. 2 Msps tempóval tudsz mintavételezni jittermentesen a mikrovezérlő belső RAM-jába. Rpi felé a GPIO SPI-jén a legkönnyebb illeszteni.

„... vagy mégis?”

Mit takar az a fogalom hogy real-time?

Definíciót kérsz? Én biztosan nem mondok, de a magam részéről azt jelenti, hogy van valamilyen hardware környezet, s annak valamilyen specifikációja, kiszolgálási igénye, amelyben fontosak a pontos időzítések, illetve az, hogy jól meghatározott, rövid időn belül mindenképpen, adatvesztés nélkül megtörténjék a kiszolgálás.

Mondok példát. Rohan a léptetőmotorod, visz magával valamekkora tömeget egy bordás szíjon. Ha ebben a környezetben a megfeleő időben nem szolgálod ki a PWM-et, s egy pillanatra megáll a motor, jobb esetben csak lesz egy nagy kattanás, rosszabb esetben ugrik a szíj, még rosszabb esetben szakad, netán eldobod a szállított tömeget. Operációs rendszer szerintem felsőbb réteg, kezelői felület kiszolgálására és összetett számítások végzésére való, ahol nagyjából az a specifikáció, hogy egyszer csak készen lesz, s az pont jó is úgy, mert senkit sem érdekel, hogy 123 vagy 125 ms alatt lesz eredményed.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

csinalsz akarmilyen gpio ki be kapcsolast, es azt megnezed counterrel ( freqvencia merovel)? Egyszeru merok mar vannak kezi muszerekben is.
RPI3 nincsen keznel, de rpi2 van, kuldesz imaget hozza, akkor rarakom merore, es megmondom mennyit ir.

Azabajhogy, idén még ötletem sincs, hogy a memóriába írás és a lábra kikerülés között van-e bármi blokkolás, csúszás, összefüggés, etc.
De az ötletet bírom, köszi :)