Raspberry Pi interrupt delay

Raspberry Pi interrupt delay
2019-07-22T10:24:39+02:00
2019-08-13T16:13:39+02:00
2022-08-11T14:20:31+02:00
@sanya
Sziasztok.

Egy Raspberry Pi-re írok egy progit ami egy 868MHz-es radio modul-t vezérel. Amikor egy csomag érkezik, egy megszakításon keresztül kapok erről értesítést, ami egy gpio-n keresztül van implementálva. Tehát a radio chip interrupt vonala rá van kötve a rpi egy gpio vonalára, a többi most lényegtelen.
A megszakítást a WiringPi/WiringPi library wiringPiISR() függvénnyel figyelem, ami lényegében létrehoz egy szálat és a poll() api-val figyeli a /sys/class/gpio/gpio... file-t és amikor megszakítás történik meghívja az általam beállított callback-et.
A probléma az, hogy az eltelt idő a reális megszakítás és az ISR között 20-50us között van, ami nagyon sok, igazából nanosec nagyságrendű delay-re vártam.

Létezik valamilyen más megközelítés egy megszakítás figyelésre?
Mutasd a teljes hozzászólást!
SPI olvasási sebességet azért említettem, mert felületesen olvastam az előző kommented. Mindenesetre ha 20 us csak a beolvasás, ezt követően még válasz előállítás, SPI-on kipötyögés is van, akkor ehhez a szumma 30-40-50 us-hoz képest a kezdeti interruptra történő nanoszekundomos reakcióidő teljesen lényegtelen, a fő gondod valóban a linux ütemezőjével lesz. Az meg gondolom attól függ, hogy mennyi egyéb dolgot kell az RPinek csinálnia, pl. webszerver is lesz egyben stb.

Ha csak annyi lenne a feladat amit leírtál (de általában sosem csak annyi), akkor akár FreeRTOS-t is pakolhatsz a Pi-re vagy bare metal fejlesztés is mehetne a garantált válaszidő érdekében, de ezekkel kb. a lényegét veszíti el a Pi.
Ha meg kell tartani a Raspbiant és úgy tapasztalod, hogy a többi taszk az elvártnál sűrűbben szól közbe, akkor vagy a Texas és a Pi közé lehet rakni egy arduinot/ESP-t az üzenet fogadásához és visszaüzenéshez, ahogy többen javasolták, így a Pi mindössze a tárolást csinálja, de ezt mintha nem akarnátok, vagy van az említett Preempt-RT patch, mondjuk egy izolált CPU-val, ami dedikáltan a GPIO-val foglalkozik. Amit még találtam a ma reggeli keresgélés közben, az a Xenomai, amiről először egy svéd szakdoga emlékezett meg, számomra nagyjából értelmezhetetlen latency tesztekkel (negatív válaszidő???), de ennek van saját, Linuxot megelőző(?) interruptkezelője, amiről egy másik szakdoga kicsit értékesebb infókkal bír. A Xenomai latency tesztjei lényegesen rosszabbak a patchelési útmutató alapján - bár szerintem azért, mert nem ezt az IT-kezelőjét használták, a második dolgozatban 20 us alatti latency-t írtak a Pi-hez, viszont ott szerintem csaltak, mert ha jól értem, időzítő megszakítással PWM-et generáltak és annak a jitterét mérték. Közben láttam az RT-Tests és stress-ng toolokat is, szóval ma reggel is érdemes volt guglizni. :)

Az előző, több hetes szívásokat takaró érdekes mérnöki kihívásokat jelentő megoldásokon felül ha jól értem, mivel a szenzor ismétli az adást, egy 0.1%-os hibaráta nem feltétlenül járna adatvesztéssel, és rádiós átvitelnél amúgy is valószínű, hogy a zajok miatt sűrűbben kell majd vételi hiba miatt ismételni, mint a Linux fennakadása miatt, szóval lehet érdemesebb először minimális erőfeszítéssel kipróbálni, és csak ha baj van, akkor trükközni.
Mutasd a teljes hozzászólást!

  • Nanosec?? 

    Fpga-t kellene használnod, ha nanosec-es reakció időt akarsz, és akkor még mindig kérdéses, mit is jelentene a "reakció"? Te egy mips eszközt használsz. Az nagy teljesítményre született, nem kicsi reakció időre.

    A rasp pi 4 b-ről van olyan hírek, hogy 1.5 ghz-es proci hajtja, de az is csak egy talán. (Megnézel 20 darabot belőle, lehet, hogy mind a 20 darab másmilyen procival lesz szerelve. Halom sok made in china átcímkézet cucc. Végső soron harctéri véres kolbász se tudja, milyen mag ketyeg benne.) Amit a marketingesek mondanak, az a cpu felszorzott órajele. Jobban hangzik. A gyakorlatban az /2 helyből. A nyers sebességben a memory cache line a következő csapás. Lazán 40% üres menetbe dobja a magot átlagban, és a fene tudja, mennyivel még jobban, mikrokód válogatja. (Alkalmanként alapos késleltetés is előfordul. Ketyeg a mag sok100 mhz-en, és vár a lassú memóriára lapokat mozgatni, mert éppen másik mag is lapokat cserél, plussz a dinamikus ram frissítés is akkor jött rá, hogy neki most dolga van.) Az eddigi eredmény még mindig csak cpu mikrokód sebesség. Azon még ott a kernel, a magok közötti szinkronizáció, a thread vezérlés. Mire engedélyt kapott az interrupt kiszolgáló thread-ed valamelyik magon (mert tegyük fel, éppen elég magas volt a prioritás, amire ne számíts a gyakorlatban minden alkalommal), alaposan lefutott pár utasítás (tuti biztos 1000 fölött, és még amennyivel több). Ha csak alkalmi jelleggel megközelíteni tudsz 2-5 usec-et akárhogyan, már mázlista vagy. A 20-50 usec átlag a gyakorlatban olyan érték, hogy ha én azt mérném, elkezdeném átgondolni, mit is mértem félre. Talán néha-néha összejön, nem lehetetlen, de ha nem fordul elő ugyan úgy a 20-50 msec (!) esete is, akkor valamit elnéztem.

    Nanosec..

    Ha időkritikus problémád van hardver vezérléssel, rakj rá a jelre valami memória buffert, ami feljegyez időt is, eseményt is, adatokat is. Ha mázlid van, és nem túl sok adatot kell jegyezni alkalmanként, plusz az átlag sebességed sem nagy, valami olcsóbb pic mikrovezérlő elég lesz. Ha időkritikus parád van, és abban a rádióban kajak semmi sincs beépítve, fpga-t kell majd használnod.

    Kellemes szórakozást.
    Mutasd a teljes hozzászólást!
  • Szia, köszi a válaszod.
    Úgy látszik túl sokat reméltem a rpi-től. :)
    Az erre célzó kommentekból amiket tatáltam a neten, én is sejtettem, hogy nehéz vagy lehetetlen elérni a nanosec nagyságrendet, de gondoltam hátha valakinek sikerült legalább egy jobb időt kihozni belőle.
    Ami a hw-t illeti a rpi adott, ezt akarja a kliensem, gondolom az ára miatt döntöttek mellette.
    Esetleg még próbálkozok egy driverrel, csak azt a kernelbe kell fordítani, abban meg nincs túl sok tapasztalatom...

    Nah, kb ennyi, egyelőre a topic még marad, hátha valaki okosabb idekukkant...
    Mutasd a teljes hozzászólást!
  • Interrupt response times on Arduino and Raspberry Pi
    Python/Raspberry Pi guaranty about interrupt response time
    Benchmarking Raspberry Pi GPIO Speed

    Egybehangzóan az látszik, hogy kernel-be érdemes fordítanod, amúgy nem lesz sok esélyed a kívánt pontosság közelébe se menni. (Valószínűleg így sem)
    Mutasd a teljes hozzászólást!
  • Amiket olvastam nem éppen kedvező neked. Lehetséges ilyen gyors reakció, de kérdés pontosan mire kell és miért ragaszkodik a megrendelő ehhez. Rpi helyett teljes mértékben mikrokontroller kellene neked szerintem.

    6 Best Arduino Alternative Microcontrollers

    Mi a pontos feladat, mit kell feldolgozni minél gyorsabban? (Összeadni, szorozni, logaritmus stb?) Vagy keresel megfelelő mCU-t erre a feladatra, vagy megépíted analóg eszközökkel. (Programozható analog áramkörökkel, vagy műveleti erősítőkkel. Azok elég gyorsak.) De nem tudjuk mi a feladat.
    Mutasd a teljes hozzászólást!
  • A GPIO lassú, nem igazán erre való.
    Mutasd a teljes hozzászólást!
  • 1.5GHz órajel sem nagyon elég erre ezek szerint, nem vágom nagyon a dolgot. Ha 10-20 óraciklus kellene neki (ok, van aminek kevesebb), akkor is 13 nano sec az elérhető legkisebb idő. Ha 'csak' 2 órajel ciklus alatt képes lenne megoldani a problémát, akkor is 1.3 nano sec lenne. (mcu-k nak kevesebb órajel kell mint a PI-nek szerintem, de ott meg nincs 2GHz.) Bármi is a feladat arra szerintem cél chip kell, amivel esetleg eldumálgat a PI.
    Mutasd a teljes hozzászólást!
  • Ilyen nagyságrendű időzítésekhez sztem. valamilyen hardveres előfeldolgozó egység kellene. Nem teljesen világos, mi a cél, de pl. az elektronika egy CMOS regiszterbe betolja az adatokat, majd a pi kiolvassa, amikor tudja... Nanosecundumos jeleket nem csak Pi-vel, hanem semmilyen kommersz számítógéppel nem tudsz lekezelni...

    Üdv

    KGy
    Mutasd a teljes hozzászólást!
  • Éppen összejön a 4 mag cache line frissitése a rendszer memória frissítési ciklussal, egy árva asm utasítás végre nem lesz hajtva nagyon sok usec ideig. Teljesen dedikálni kellene a magot arra az interrupt válaszra. Kellene egy arra megcsiszolt cpu profil is. Ha létezne is, az átlagos teljesítmény a bányász breki ülepe alatt kötne ki. De nem fog létezni. A gyártók nem adják ki annak a procinak a doksiját nyíltan. Az a cpu profilod van, amit a gyártó ad az android image-ekhez, és arra berhelnek gnu linuxot is. Azért is nem lesz az hatékony sosem.
    Mutasd a teljes hozzászólást!
  • Ohhh a jó öreg érzés, amikor az ember 5 évente kérdez valamit a prog.hu-n, mert előtte már átnyálazta az internetet és feladott minden reményt - erre a prog.hu se viszi előre.

    Lehet egy kicsit több infót kapni a dologról?
    Lehet, hogy igazából az alapvető megközelítés rossz.
    Milyen rádió modulról van szó? Milyen sebességre volna szükség? Mennyire low-level a radio modul?
    Az is lehet, hogy az egészet meg tudod oldani LIRC-el.


    Mennyire (nem) opció az, hogy a modul és a pi közé beraksz egy ESP8266-ot vagy ESP32-t?

    Ezek olcsók (< $10), könnyű őket programozni és könnyű őket összekötni a Pi-vel - van egy pár példakód a neten 868Mhz transceivingre.
    Mutasd a teljes hozzászólást!
  • Nekem nem (sem) túl egyértelmű, hogy mi a cél.

    Ha nagyon gyors reakcióidőt akarsz, akkor gondolom a kernelbe kellene belenyúlnod, és a GPIO-ra interruptut rakni, nem pollolni a Raspberryvel, de ez eléggé túlmutat a szívesen bevállalt szívás kategórián. Itt van egy mérés, sajnos nem derül ki belőle hogy user space-e, de gyanítom: Does the Raspberry Pi manage hardware interrupts? itt 300 mikroszekundum alatt maradt a válaszidő, tipikusan 50-70 us.

    De az "amikor egy csomag érkezik" mondat alapján van egy olyan érzésem, hogy nem kell neked 868 MHz meg nanoszekundumos felbontás/reakcióidő, hanem valami magasabb szintű protokoll megy a 868 MHz-es frekvencián, azt kell lekezelned.

    Ehhez meg tudni kéne, hogy a vivőfrekvenciáról való kikódolást mi és hogyan végzi, mert ha végeredményben egy 10 kilobit/s adatátvitelt akarnak megvalósítani a rádiós chippel, és annak a kimeneti bufferét kell csak olvasni mondjuk SPI-on az interrupt hatására, az teljesen más műfaj, mint amikor egy low level rádiós chip kimenetén még az analóg szűrést is szoftverből akarod megvalósítani. 

    (Mivel nem értek különösebben hozzá, az esetleges hülyeségekért/pongyola megfogalmazásért elnézést.)
    Mutasd a teljes hozzászólást!
  • Na akkor, először is elnézést kérek a nagy delay-ért :) ez most én voltam...
    Nagyon köszönöm a sok és hasznos hozzászólást és linkeket. Sajnos nem tudok mindenkinek külön válaszolni, ezért megpróbálom egybe leírni.

    Úgy látom igazatok van abban, hogy a ns reakcióidő csak egy álom ebben az esetben. Igazából a megrendelőm szerette volna ezt elérni.
    Úgy veszem észre nem teljesen egyértelmű mindenkinek, ezért elmondom miről van szó még egyszer (bocsi, hogy nem voltam elég világos a nyitó topikban):
    Egy szenzor küld adatokat 868MHz-en (egy TI chip ami rádió és MCU is) x percenként, ehhez nem lehet nyúlni viszont dokumentálva van. A vevő oldal (amivel én foglalkozom) ugyancsak egy TI rádió chip (csak rádió, MCU nélkül, ezért kell a rpi), aminek van egy megszakítás vonala és egy SPI interface-e. Akit érdekel a chip: http://www.ti.com/lit/ds/symlink/cc1101.pdf
    Szóval, amikor egy csomag* megérkezett**, a rádió chip megszakítással jelzi ezt, amit én a rpi egy gpio-ján látok, tehát a rádió chip interrupt szála össze van kötve a rpi egy gpio-jával, majd SPI-on keresztül lehet kiolvasni a csomagot.

    A konkrét kérdés az volt, hogy lehetne-e rövidíteni az időt a fizikai megszakítás és a megszakítás hívás (aka ISR) között. Gondolom egyértelmű, hogy hogyan mértem le az időt, de leírom azt is: egy logic analyzert kötöttem az interrupt vonalra és egy tetszőleges másik GPIO-ra. A megszakítás függvény legelső sora pedig egy toggle a tetszőleges GPIO-ra. A mért idő a megszakítás és a toggle közötti távolság. (Bocsi, ha túl redundáns amit írok :))
    A mért reakcióidő 20-50us, de gondoltuk, hogy ezt lennebb lehetne hozni. Maga a program egyáltalán nem egy nagy durranás, csak a tesztek át kell menjenek az elvárásokon.

    Sajna mindent nem írhatok le, NDA alatt vagyok, még csak annyit, hogy a szenzor egy adott időt vár a válaszra, ami ha nem jön meg ezen belül, akkor újraküldi a csomagot, de persze ezt el kellene kerülni. Ezzel egyelőre nincs gond, a válasz időben visszaérkezik, lemértem az időt a csomag érkezése és a válasz küldése között, ami nagyon jó (tehát feldolgozás, tárolás, válasz előállítása, titkosítás, crc, visszaküldés ...). Igazából még 10-12ms kellene elteljen ahhoz, hogy a szenzor újraküldje a csomagot. Remélem érthetően fogalmaztam. :)

    Az egyetlen ami kifut a kezemből az a reakcióidő amit már írtam.
    Gondolom/remélem, hogy az nem fog soha túl nagy lenni (mondjuk > 1 ms).

    Elgondolkodtam egy driveren is, de attól tartok, hogy azzal sem fogok túl nagyot ugrani, esetleg ha nem sysfs, hanem valamilyen event-tel kommunikálnék a user space felé, nem is tudom ez lehetséges-e...

    Időközben rátaláltam a libgpiod-re: libgpiod/libgpiod.git - C library and tools for interacting with the linux GPIO character device ami a sysfs pollingot akarja helyettesíteni.
    Összedobtam egy nagyon egyszerű kis progit vele, de úgy látom ez még lassúbb mint az elődje: a legjobb mért idő 80us körül van. Belekukkantottam a forrásba és meglepődve láttam, hogy majdnem ugyanazt csinálja mint a wiringPi: megnyit egy file-t (amit a kernel módosít interrupt esetén), majd poll()-ozik rajta.

    Pár dolog amire nem sikerült válaszolni, így konkrétan:
    @Andi37 A 868MHz-es rádió adott, azzal kell dolgoznom és amint írod, az fölött van egy protokoll, nekem azt kell kezelni csak, ezt kapom meg amikor SPI-on keresztül leolvasom. Minden egyebet előre állítok be: baudrate, RX filter BW, deviation, offset compensation stb.

    @Argathron A megközelítés szerintem(!) nem rossz, nem látom hogy lehetne másképp megoldani. A chip annyira low-level amennyire csak lehet, fennebb vagy egy link hozzá.
    Nem értem mit szeretnél mondani a LIRC-kel.
    Van pár ESP8266 alapú cuccom itthon amiket én forrasztgattam össze, tudomásom szerint csak WiFi-n keresztül kommunikál, légyszi szólj ha tud valami mást is... :) Köszi!

    Remélem mindenkinek sikerül válaszolnom...

    Egy kicsit hosszú lett, bocsi :)

    * Egy csomagnak van fejléce, payload és egy crc-je

    ** A fejléc, payload és crc a vevő RX FIFO-jában készen áll olvasásra.
    Mutasd a teljes hozzászólást!
  • Akkor annyira nem is lőttem mellé a lehetséges céloknak. :) Mások is küzdöttek már interruptokkal, ott úgy tűnik, driver space-ben átlag 12us, worst case 43 us volt a válaszidő Pi1 esetén, szóval ennél csak jobb lehet egy Pi4. A rádiós chip SPI-án úgy láttam, 10 MHz a maximum, amit tud, úgy meg a bitidő 100 ns, ez alá nem nagyon látom értelmét lemenni (sőt 1 us alá sem).

    Sokkal nagyobb gondod lesz azzal egy user space program esetén, ha valami alacsony szintű dolog, mondjuk hardver blokkolja a rendszert 100ms-ra, mert épp buffert ürít SD kártyára... Nem tudom ilyenek történhetnek-e. Írtak az előző linken CONFIG_PREEMPT_RT-tel való kernelújrafordítást is meg említették a BeagleBone-okat, amik hardveres támogatást nyújthatnak a garantált válaszidő érdekében (PRU) de ezekhez megint pont annyira értek, mint a Pi-n futó linux kernelhez. :)

    Hajrá!
    Mutasd a teljes hozzászólást!
  • Az SPI olvasási sebesség teljesen lényegtelen (az egész csomag ~20 byte, ami előreláthatóan 20us), csak az a késés aggaszt amit már írtam, mivel nagyon változhat ha pl a CPU jobban van terhelve. Elvileg felmehet még több 100ms-re is, ami elfogadhatatlan.
    A CONFIG_PREEMPT_RT-re nemrég találtam rá én is, csak azt kell leellenőriznem, hogy bele lehet-e fordítani a raspbian-ba, mivel az nem a main stream kernelt használja.

    Köszi :)
    Mutasd a teljes hozzászólást!
  • A technika ördöge lenyelte az előző válaszomat, ha duplázok, bocsi.

    A beérkezett üzenet átvételénél ha parás a reakció idő, berakhatsz az rpi meg a rádió közé egy bármilyen mcu-t, amivel jó barátságban vagy, és simán csak buffereled az spi üzenetet oda-vissza. Egy átlagos mcu a 32 bites sorozatból 2 spi-vel simán ketyeg 40 mhz-en, és ha csak low-lvl program fut rajta, azzal nem problémás 5 usec alatti reakció időt elérni. Ha a 20-50 usec elfogadható volt, problémamentesnek kell lennie az átvételnek. Az üzenetet buffereled, az rpi késhet akármennyit - abba az említett 10-12 msec időbe az esetek többségében bele fog férni.

    Fogalmam sincs, mit jelentene a "feldolgozás", de ha különösebben nagy teljesítmény igénye nincs, egy erősebb mikrovezérlőre is felférhet ez-az, és akkor kihagyható az rpi végleg. Érthető a ragaszkodásod az rpi-hez, ha a vásárló direkt azt kérte, de arról ugye felvilágosítottad a vásárlót, hogy az rpi nem garantált működésű eszköz? Ha lefagy, akkor lefagyott, és akkor nem csak pár msec késés lesz, hanem out of service, kakukk. A fair tájékoztatásnak része, hogy arra felhívod szíves figyelmét, mert bizony meg tud történni. Ha elfogadta, elfogadta, egyébként pedig megérhet egy említést, hogy más megoldás üzemstabilabb lehet.
    Mutasd a teljes hozzászólást!
  • Köszi a megjegyzésed.
    Más hw (mcu vagy bármi) nem jöhet szóba. A "feldolgozás" mindegy hogy mennyi idő, egyébként nem bonyolult, egy kis kripto egy crc és egy zárt protokol, amúgy rövid idő alatt hajtódik le és főleg prediktíven.
    A megrendelő azért tudja jól mivel eszik ezeket a cuccokat, természetesen beszéltünk már ezekről a problémákról, csak gondolta egy próbát megér.
    Mutasd a teljes hozzászólást!
  • SPI olvasási sebességet azért említettem, mert felületesen olvastam az előző kommented. Mindenesetre ha 20 us csak a beolvasás, ezt követően még válasz előállítás, SPI-on kipötyögés is van, akkor ehhez a szumma 30-40-50 us-hoz képest a kezdeti interruptra történő nanoszekundomos reakcióidő teljesen lényegtelen, a fő gondod valóban a linux ütemezőjével lesz. Az meg gondolom attól függ, hogy mennyi egyéb dolgot kell az RPinek csinálnia, pl. webszerver is lesz egyben stb.

    Ha csak annyi lenne a feladat amit leírtál (de általában sosem csak annyi), akkor akár FreeRTOS-t is pakolhatsz a Pi-re vagy bare metal fejlesztés is mehetne a garantált válaszidő érdekében, de ezekkel kb. a lényegét veszíti el a Pi.
    Ha meg kell tartani a Raspbiant és úgy tapasztalod, hogy a többi taszk az elvártnál sűrűbben szól közbe, akkor vagy a Texas és a Pi közé lehet rakni egy arduinot/ESP-t az üzenet fogadásához és visszaüzenéshez, ahogy többen javasolták, így a Pi mindössze a tárolást csinálja, de ezt mintha nem akarnátok, vagy van az említett Preempt-RT patch, mondjuk egy izolált CPU-val, ami dedikáltan a GPIO-val foglalkozik. Amit még találtam a ma reggeli keresgélés közben, az a Xenomai, amiről először egy svéd szakdoga emlékezett meg, számomra nagyjából értelmezhetetlen latency tesztekkel (negatív válaszidő???), de ennek van saját, Linuxot megelőző(?) interruptkezelője, amiről egy másik szakdoga kicsit értékesebb infókkal bír. A Xenomai latency tesztjei lényegesen rosszabbak a patchelési útmutató alapján - bár szerintem azért, mert nem ezt az IT-kezelőjét használták, a második dolgozatban 20 us alatti latency-t írtak a Pi-hez, viszont ott szerintem csaltak, mert ha jól értem, időzítő megszakítással PWM-et generáltak és annak a jitterét mérték. Közben láttam az RT-Tests és stress-ng toolokat is, szóval ma reggel is érdemes volt guglizni. :)

    Az előző, több hetes szívásokat takaró érdekes mérnöki kihívásokat jelentő megoldásokon felül ha jól értem, mivel a szenzor ismétli az adást, egy 0.1%-os hibaráta nem feltétlenül járna adatvesztéssel, és rádiós átvitelnél amúgy is valószínű, hogy a zajok miatt sűrűbben kell majd vételi hiba miatt ismételni, mint a Linux fennakadása miatt, szóval lehet érdemesebb először minimális erőfeszítéssel kipróbálni, és csak ha baj van, akkor trükközni.
    Mutasd a teljes hozzászólást!
  • Nagyon jó cikkeket mutattál, köszi! Ma is tanultam valamit. 
    Bocsi a lassú reagálásért, de épp szabadságra mentem közben.
    Mutasd a teljes hozzászólást!
  • Ha esetleg konkrét eredményekhez jutsz, amik az eddiginél jobbak, majd oszd meg légyszi röviden a tapasztalatokat, hogy ne kelljen kipróbálni mindent, ha egyszer ilyesmire lesz szükségem! :) Köszi.
    Mutasd a teljes hozzászólást!
  • Hali!

    Bocsi a késésért! Sajna konkrét eredmény nem született, újrafordítottam a kernelt a PREEMPT_RT patch-el, de úgy látszik eléggé bibis lesz. Eleinte nem indult el, valahol a bootoláskor meghalt, próbáltam uboot-tal meg anélkül is, utána újrafordítottam arm64 formátumra. Így elindult, persze a hálózattal gond volt, amint megoldottam, nem volt SPI, próbálom uboot nélkül, na így aztán nagy küzdelmek árán elindult az SPI is, indítom az applikációmat, lefagy, gdbserver-rel nem tudok debuggolni, szóval kiborultam/tunk és egyelőre pending-el a projekt... Minden esetre az a sanda gyanúm, hogy nagy változás nem lesz, bármit is tennék, mindenképp egy poll() epoll() select() -et kell majd használjak, ami ugye eléggé költséges hívás, szóval megbeszéljük és meggyőzöm a megrendelőt, hogy nem érdemes ebbe több időt fektetni.
    Még valami: a múlt héten a wiringPi-t karbantartó srácnak tele lett a töke: wiringPi – deprecated… Aki esetleg használta ezt a libet jó ha tud róla.

    Végül most nagy bajban vagyok, nem tudom kinek adjam a pontokat, annyi sok konstruktív választ kaptam...
    Nah, újraolvastam az egész topikot és And37 mellett döntöttem, a 2019.07.24-es kommentjére.

    Nagyon köszönöm mindenkinek
    s
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd