Sziasztok
Valakinek van tapasztalata a real time kernelekkel?
Mivel jobb mint egy hagyományos kernel?
Virtualizált környezetben is használhatóak?(Azure, Vmware,Xen) A node Overalloc-áció esetében is?
Streaming software-ek esetében hasznos?
- 1752 megtekintés
Hozzászólások
Anno amikor még gamehostinggal foglalkoztam használtunk realtime kernelt (2009-10 környékén). Ha jól emlékszem akkoriban csak közvetlenül gépen (tehát nem VM) futtatva működött. Azóta nem követtem.
Játékokhoz (pl CS) kifejezetten hasznos volt.
1904.04.08.
RIP Jákub.
neut @
- A hozzászóláshoz be kell jelentkezni
Köszi. A játékok oldalán azaz software oldalon kellet valamit még "mókolni", belenyúlni a kódba?
- A hozzászóláshoz be kell jelentkezni
Nope, a program nézőpontjából nem sok különbség van RT és nem RT közt.
1904.04.08.
RIP Jákub.
neut @
- A hozzászóláshoz be kell jelentkezni
Attol fugg, a soft realtime/lowlatency kernel patch (PREEMPT_RT) eseten valoban mindegy.
Ha RTAI-t hasznalsz, akkor van. Ez a korabbi RTL (Real Time Linux) forkja, ahol van egy kulon, apro, real-time kernel, sajat driverekkel. Ha a real-time vezerlesed akar futni, akkor o fut, ha nem, akkor az RT kernel beutemezi a sima Linux kernelt, ami futtatja magat vagy valamelyik processt. Ezen tul megadhatod, hogy milyen hardware-t hasznaljon az RT kerneled, es mit adjon tovabb a Linuxodnak. Van par HW, aminek nagyon egyszeru a drivere (parhuzamos/soros port), es ilyen mindenfele vezerlesekhez jo tud lenni. Van par bonyolultabb vas (RTL8139, meg E1000, meg 1-2 masik halokartya), aminek szinten megy az RT-s drivere, de tipikusan kinszenvedes. USB-rol (mar a csomagmeret es bonyolultsaga miatt sem) kb. ne is almodj. Kicsit komolyabb kutyuhoz van a Mesanak egy termeksorozata, amin egy Xilinx FPGA van, PCI-hoz illeszkedik, es ad neked valahany GPIO labat, 10kHz frissitessel (vagy definialhatsz hozza par SPI-t, UARTot, meg amit akarsz), ehhez is van RT driver. Ezen tul van az RTAI-nak egy par fuggvenye, amivel pl. meg tudsz adni egy threadet, meg hogy mennyi idonkent hivogassa, a sima userspace progiddal kommunikaciohoz kerhetsz shared memoryt (igy a RT kernelben futo thread-ed eleri annak a dolgait, es tudja mit kell csinalni), meg van egy csomo, hasonlo dolog. Jobban nem mentem eddig bele, de van olyan kollegam, aki igen.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Nyilván a hardware közreműködése nélkül a kernel sem tud garantálni semmit. (Pl. Én mint RT-kernel megígérem, hogy minden 10ms-ben kap a folyamatod 1ms CPU-t. De ha én egy virtuális készülék vagyok, és mondjuk 50ms eltelik anélkül, hogy én magam CPU-t kapnék, akkor ez az ígéret nem ér semmit.)
- A hozzászóláshoz be kell jelentkezni
Teljesen igaz, amit írsz.
De kíváncsiságból rákerestem, és ilyen is van: https://www.congatec.com/us/technologies/real-time-hypervisor/, https://acontis.com/en/realtime-hypervisor.html, https://www.real-time-systems.com/index.php
- A hozzászóláshoz be kell jelentkezni
Xen oldalán esetlegesen belelehet nyúlni a domu cfg-be.:
https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#CPU-Allocation
megmondani, hogy melyik CPU val dolgozzon az adott domU, hátránya a node-n futó többi domU-t is konfigurálni kellene stb..
Tegnap találkoztam először a real-time kernel lehetőséggel. Csak érdeklődők, hogy esetlegesen online video meeting, stream esetén jobb szolgáltatás érhető-e el egy ilyen "fejlesztéssel".
- A hozzászóláshoz be kell jelentkezni
Nem streamingre valo, azon nem segit. Az ilyenen a buffereles segit, meg a stabil netkapcsolat.
A real-time kernel akkor jo, ha valamilyen fizikai dolgot akarsz ugy vezerelni, hogy arra azonnali reakcio kell. Ha a fizikai vilagban tortenik valami, akkor az idonkent megkapott CPU ido nem feltetlenul eleg, mert siman lemaradhatsz a dolgokrol. Van mondjuk egy lezervagod, 200mm/perces elotolas mellett masodpercenkent kb. 3.33mm-t tesz meg, egy mikront 0.3ms alatt. Ha ms-enkent kapod csak meg a procit, azalatt tulfut, es tobbet vag, mint amit szeretnel. Es mar leteznek szubmikronos CNC gepek is. Persze kerdezhetned, hogy miert nem szervezik ki a real-time reszt mikrokontrollerre, es jogos is lenne a kerdesed, az a masik - ma mar talan elterjedtebb - megoldas a problemara. De ha amugy is ott egy PC a vezerloben egy olyan CPU-val, ami amugy mindent ki tudna szamolni, akkor igazabol real-time kernellel is megoldhato. A masik, hogy vannak CPU-igenyesebb feladatok is (mondjuk robotkarnal inverz kinematika szamitas), amivel egy x64 siman megkuzd, egy mikrokontrolleren meg vert izzadsz mig kiszenveded. (talan meg valami nagyobb, ARM alapuval is)
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Köszönöm a részletes magyarázatot.
- A hozzászóláshoz be kell jelentkezni
Nincs konkrét tapasztalatom, illetve egy Windows-t használtam 2010 előtt. Azonnal válaszolt (xy sec időn belül) de a komolyabb feladat végrehajtás kárára.
A zenélős Linuxok használják, a bank automatákon és a légi-irányítási terminálokon kívül:
"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett"
és 100 éve még boszorkányt is égettek
- A hozzászóláshoz be kell jelentkezni
szerk.: invalid
- A hozzászóláshoz be kell jelentkezni
Épp most raktam össze egy lomiból megmentett gépből egy midi vezérelt virtuális zongorát futtatót, ahol ubuntustudio a rendszer és az realtime kernellel jött alapból. Nyilván itt nagyon fontos a válaszidő. Igazából engem is ez a kérdés foglalkoztat, h mennyire szükséges a rt kernel!
Itt pl azt mondják h nem feltétlenül kell: https://jackaudio.org/faq/linux_rt_config.html
Egyenlőre rt kernel fut, és mostanra sikerült elég jól belőnöm a dolgokat, h szépen szóljon és használható legyen - majd lehet írok róla blog postot is. Csak ezzel a kernel kérdéssel vagyok elveszve. pl. CPU Frequency Scalingre vonatkozó dolgokat nem találok, gondolom az RT patch kiszedte azokat.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
- A hozzászóláshoz be kell jelentkezni
Ki kellene normál Kernelt is próbálni, mert igen sokat fejlődött a kernel audio része, új ütemező, csoportok ...stb Én nem is szoktam késést tapasztalni.
https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel
"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett"
és 100 éve még boszorkányt is égettek
- A hozzászóláshoz be kell jelentkezni
Azt hiszem hülyeséget írtam. Tulképp low-latency -nek nevezik kernelt amivel gyárilag jön és én meg ezt gondoltam realtime kernelnek.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
- A hozzászóláshoz be kell jelentkezni
Nekem volt egy jó realtime oprendszerem. Úgy hívták, hogy DOS 6.22
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Melyik DOS rendszerhívásnak volt időbeli felső korlátja, amit nem lépett túl a művelet sosem? Egyiknek sem.
A DOS nem realtime rendszer.
- A hozzászóláshoz be kell jelentkezni
NMI-vel bármit bármikor meg lehetett szakítani, csak át kellett írni a megszakítás vektortábláját.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Csak az NMI-t a CMOS hozzáférésekkor le lehet tiltani a 70h port legfelső bitjének magasra állításával.
mov al, 80h
out 70h, al- A hozzászóláshoz be kell jelentkezni
Ez így van, kérdés azonban az, hogy a rendszerhívások, amit persicsb kolléga hivatkozott, kimaszkolják-e a nem kimaszkolhatót. Ezzel kapcsolatban kétségeim vannak. Ha erről van némi info, akkor azt szívesen venném.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Szükséges, hogy a rendszerhívás maga maszkolja ki? Kimaszkolhatja a program is a rendszerhívás előtt. A lényeg, hogy MS-DOS alatt minden további nélkül preventálni lehet, hogy elvegyék a rendszerhívást indító userspace programtól a vezérlést.
- A hozzászóláshoz be kell jelentkezni
Én ezt fordítva látom: A felhasználói program bármit megtehet attól a pillanattól kezdve, hogy megkapta a vezérlést. Ha akarja SOHA nem hívja meg az oprendszert. Ki veszi el ekkor a vezérlést?
A '90-es évek elején, a 286-os korszak végefelé DOSos alapokon vettünk 96kHz-val mintát és lapátoltuk ki az adatokat winchesterre.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Ugyanazt magyarázzuk két irányból: bármelyik userspace program tud kizárólagos módon futni MS-DOS alatt, a rendszer helyett, gyakorlatilag mindennemű megkötés és teketória nélkül, csak a megszakításokat kell letiltania. Amiben nem értünk egyet az az, hogy ez RTOS-nak számít-e, vagy sem.
AFAIK, egy RTOS esetén ilyesmi nem történhet meg, maximum egy kernelspace-ben futó app futhat megszakítás nélkül, ha kizárólagosságot szerez a rendszertől. Itt viszont a rendszer irreleváns, ahogy írod, ha nem akarja, meg sem hívja: nem a rendszer garantálja a kizárólagosságot egy kernelspace programnak, hanem bármely userspace program a kedve szerint szert tehet rá és onnantól kezdve tkp. ő az OS az OS helyett - azaz akár egymástól is elvehetik a futás privilégiumát, ha az egyik meghívja a másik programot.
- A hozzászóláshoz be kell jelentkezni
Pontosan!
- A hozzászóláshoz be kell jelentkezni
És akkor mi van? Ez ugyanúgy RT rendszer. µC/OS II-ben is megteheti a task, hogy nem adja vissza a vezérlést. Csak nem multitasking.
- A hozzászóláshoz be kell jelentkezni
Persze akkor vegulis egy MCU-n futo while(1) {} ciklus is RTOS :) Nem minden RT rendszer RTOS.
µC/OS II preemptive scheduler-t hasznal, ugyhogy ha nem adja vissza a vezerlest, akkor elveszik azt.
- A hozzászóláshoz be kell jelentkezni
Hiába preemptive, ha magasabb prioritású a taszk, akkor mindig ő kerül kiszolgálásra.
Nem RR vagy WRR alapján kap CPU időt.
- A hozzászóláshoz be kell jelentkezni
De a scheduler elveszi tole a vezerlest majd ugy dont visszadja, nem ragad be. Csak ugy tunik mintha nem adna vissza a vezerlest.
- A hozzászóláshoz be kell jelentkezni
Tény. De azért dönt úgy, mert a taszk nem megy aludni, ami az ő döntése.
- A hozzászóláshoz be kell jelentkezni
"megteheti a task, hogy nem adja vissza a vezérlést"
A task es a scheduler nem fut parhuzamosan. Altalaban egy timer interruptot hasznalnak erre, hogy kirangassak a normal futasbol a rendszert es a scheduler veszi at az iranyitast. A scheduler megnezi a kis listait: lejart-e egy delay, szukseg van-e task switchingre stb...
Igy ez nem a task dontese hanem a scheduler/kernel muve. A task max annyit tud csinalni, hogy hamarabb visszadja a stafetabotot.
Mondjuk ha csak egy task van es mindig az fut, nem sok ertelme van RTOS-t hasznalni.
- A hozzászóláshoz be kell jelentkezni
Még 1x elmondom: ha egy task magasabb prioritású (vagyis értékben kisebb) és egy végtelen ciklus van benne, amiben nem megy aludni, akkor soha nem fog senki sem CPU időt kapni. Sosem fog az ütemező másik tasknak időt adni, mert kiéhezteti. Ez pedig a task döntése. Próbáld ki ha nem hiszed! Régen programoztam már µC/OS-II-re épülő beágyazott rendszert, de nem 1 évet..
uC/OS-II is preemptive, but only in one direction - it will preempt a lower-priority thread to allow a higher priority thread to run, but will not do the reverse.
μC/OS-III-ban már van RR ütemezés. FreeRTOS-t nem használtam, arról nem tudok nyilatkozni.
- A hozzászóláshoz be kell jelentkezni
En preemptive scheduling-rol beszeltem. Amirol te beszelsz az nem az, hanem a kooperativ vagy non-preemptive. Amit ideztel, az a igaz, de stackoverflow helyett ez jobb (Micrium doksi):
"... µC/OS-II and most commercial real-time kernels are preemptive... To summarize, a preemptive kernel always executes the highest priority task that is ready to run. An interrupt preempts a task. Upon completion of an ISR, the kernel resumes execution to the highest priority task ready to run (not the interrupted task). Task-level response is optimum and deterministic. µC/OS-II is a preemptive kernel."
En is lattam mar tobb RTOS-t, par oraja bokdostem egy debuggert amin lattam ezt mukodni.
Nem kotekedni akarok, csak a tudasomat osztom meg. Elhiszem, hogy neked ugy mukodott. Sokminden okozhatja ... pl. ha nem fut az ISR periodikusan, akkor pontosan ugy viselkedik ahogy irtad.
- A hozzászóláshoz be kell jelentkezni
Hiába fut az ISR periódikusan. Ha a te taszkod úgy dönt, hogy ő mindig ready to run (és neki van a legnagyobb prioritása), akkor soha az életben más taszk időt nem fog kapni. Ez by design ilyen. Ez nem hiba, ez egy feature. Képzeld azt, hogy egy autóban mondjuk van az elektromos fék és az elektromos gázpedál. Mindkettő egy taszk. Értelemszerűen az elektromos féknek magasabb prioritása van. Ezért ha fékezel, akkor a másik taszk (a gáz) soha egy másodperc CPU időt nem fog kapni. Persze a valóságban ez nem így működik (több okból is). De mondom próbáld ki nyugodtan, kb 10 perc.. Csinálj két taszkot, egyiknek magasabb, másiknak alacsonyabb legyen a prioritása! Mindkettő végtelen ciklus. Az alacsonyabb prioritású 1 db órajelet nem fog kapni.
Ahogy látom egyébként FreeRTOS-ban is hasonlóan van, csodálom hogy nem találkoztál még vele:
Starvation
There is no mechanism implemented in FreeRTOS that prevents task starvation: the programmer has to make
sure there is no higher priority task taking all running time for itself.
https://www.google.com/url?sa=t&source=web&rct=j&url=http://stiff.univ-…
- A hozzászóláshoz be kell jelentkezni
"Az alacsonyabb prioritású 1 db órajelet nem fog kapni."
Akkor felreertesz, en nem ezt vitatom ... Persze, ez teny.
"Ha a te taszkod úgy dönt, hogy ő mindig ready to run"
Olvasd vissza, en csupan azt vitatom (meg mindig), hogy preemptive scheduling eseten ez nem a task dontese. Ennyi.
A taskok listajat es azok prioritasat a kernel/scheduler tartja nyilvan. Idokozonkent a kernel kodja fog futni, ami kitalalja, hogy melyik task fusson. Ennek a logikanak az oka, hogy starvation lephet fel, hisz itt mindig a legmagasabb prios ready state-es taskot fogja kvalasztani.
De lehet csak mashogy mukodik az agyunk. Te a task szempontjabol nezed en meg az utemezo oldalarol.
- A hozzászóláshoz be kell jelentkezni
Te a task szempontjabol nezed en meg az utemezo oldalarol.
Így van. Akkor egyetértünk :)
- A hozzászóláshoz be kell jelentkezni
RT rendszer lehet, csak nem RT oprendszer. És itt nem azon van a hangsúly, hogy "nem adja vissza" a vezérlést, hanem azon, hogy el tudja venni, a rendszertől függetlenül. Ez ugyanaz a szint, mint amikor a C64-en elindított program (nem, nem a Contikiről van szó, hanem a classic módon, a BASIC által betöltött, "valós módban" futkosókról) kirugdalja a KERNAL-t és a BASIC-et a címtérből és átveszi a vezérlést. Ezzel az erővel most akkor a C64 KERNAL/BASIC is RTOS-nak számít. :P
- A hozzászóláshoz be kell jelentkezni
Hova vezet egy elgépelés! :) Ritka furcsa assembly volt ez. Nem bánom, hogy ez kimaradt.
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Mitől furcsább a 6502, mint akármelyik másik?
- A hozzászóláshoz be kell jelentkezni
Nekem szokatlan.
PC assemblyn ez
mov dx,message
mov ah,9
int 21hÉs a szöveg természetesen a message után.
Nem kell ilyen next done külön meg
beq done
jsr CHROUT
inx
bne next“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Egyszerűbben mondva: nincs string-író rutin a Commodore-kernalban. (Vagy elbújt.)
https://sta.c64.org/cbm64krnfunc.html
- A hozzászóláshoz be kell jelentkezni
Azt írod, fura egy assembly ez, aztán beírsz egy olyan példát, amikor egy BIOS (vagy DOS?) szubrutint hívsz meg, hogy kiírjon egy szöveget, és ezt összehasonlítod egy forrással, ahol valaki egy ciklusban írja ki a szöveget karakterenként.
Ha tippelnem kellene, az általad elegánsan int 21h módon meghívott szubrutin belsejében egy hasonló ciklust fogsz találni, ami hasonló módon, karakterenként kiírja a szöveget.
De akár így van akár nem, ez nem az assembly nyelv összehasonlítása.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
- A hozzászóláshoz be kell jelentkezni
Mivel 21h ezért DOS.
Nem is assembly nyelvek összehasonlításról írtam. Csak, hogy PC-n ez szerintem egyszerűbb, úgy is ha az általad írt szubrutin van mögötte, amiben valószínűleg igazad van.
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Ritka furcsa assembly volt ez
Ennek alapján azt hittem, az assembly nyelvek összehasonlításáról írsz.
Amúgy persze hogy eltér a kettő. De az lenne furcsa, ha nem térne el. Más processzor, más architektúra, más OS, és más a felhasználás módja is.
Annak, aki csak egy assembly nyelvet látott egyféle módon írva, csak egy rendszeren, minden más assembly furcsa lesz.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
- A hozzászóláshoz be kell jelentkezni
Rendszerhívást hasonlítottál az inline copy-val, ez nem az assembly "furasága". A 9-es funkció belül ugyanazt csinálja, csak dollárjel zárja a stringet, nem NUL.
- A hozzászóláshoz be kell jelentkezni
Ebben igazad van. RT rendszer, de nem RT oprendszer.
- A hozzászóláshoz be kell jelentkezni
Azota van SMI.
https://en.wikipedia.org/wiki/System_Management_Mode
sok szerencset ;-)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
MS-DOS-ról és 286-osról volt szó, nem baj?
- A hozzászóláshoz be kell jelentkezni
Ettol meg a DOS nem lesz RTOS ... De teny, hogy meg lehetett kalapalni, masok is csinaltak: http://www.on-time.com/rtkernel-dos.htm
- A hozzászóláshoz be kell jelentkezni
Ezt olvasd el: https://www.redhat.com/sysadmin/real-time-kernel
A lenyeget mar fentebb leirtak ... altalaban idokritikus alklamazasoknak jo ez, ahol ha beakad valami x ms-re akkor nagy baj van. Bar nem vezerlesre, de a SpaceX is hasznalja, illetve van csomo erre epulo project, pl.: LinuxCNC
Automotive-ban is eleg komolyan hasznaljak.
Ha tippelni kell 99%, hogy nem kell neked.
- A hozzászóláshoz be kell jelentkezni
A LinuxCNC project elegge epit ra, de igazabol nem ezen mulik a dolog. (CNC-hez hasznaljuk mi is, de a sima low-latency-hez kepest nincs nagy kulonbseg) Az RTAI raadasul kicsit mas interface-t ad a real-time threadedhez, ez lehet elony, meg hatrany is. Neked valoszinuleg nincs ra szukseged.
Virtualizalva nem akarnam futtatni, maximum ugy, hogy a real-time kerneles gep a host, es virtualizalt kornyezetben fut valami hozza.
Amugy meg: Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT. - Linus Torvalds
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Streamer gépen használtam, mert volt egy rendszeres 'underrun pipe'-megszaladás, amit nyomoztam és emiatt kínomban már ezt is kipróbáltam. Gyakorlatilag semmit nem baszott...
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
"Virtualizált környezetben is használhatóak?"
igen
" A node Overalloc-áció esetében is?"
A hoston igen ;-) , SDN vagy akarmi amit futtatsz az RT lesz ..
Guesten nincs ertelme over allokacio eseten.
Ill. erdemes hostnak is RT -nek lennie, ha RT guestet akkarsz,
dedikalni CPU -t lehet RT kernel neluk is, de barmi olyan dolog
eseteben amiben a host kozremukodese kell ne varj RT -t nem RT hostol.
(PCI passthrough eszkozok szinten nem fugnek host RT-tol ..)
VM -lehet RT, egy rakplap cpu pinning utan,
tenylegesen kissebb latency szorast lehet latani.
A troughtput roszabb lessz.
"Streaming software-ek esetében hasznos?"
Nem hinnem,
legtobb esetben az RT nem hasznos.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Nem RT host rendszeren RT rendszer guestként használatának nincs sok értelme. Kivéve persze a rendszerrel való ismerkedést.
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Ha már realtime rendszerek: a Beaglebone lapkákban található Texas gyártmányú ARM proci megoldása tetszik.
- Időosztásos Linux oprendszer az ARM Cortex A8 vagy ARM Cortex A15 alapú processzoron
- RT folyamatokra az ARM procival közös tokban 2 darab PRU (Programmable Realtime Unit), amely önálló 200 MHz-es mikrovezérlő GPIO és RAM eléréssel rendelkezik.
https://slideplayer.com/slide/4901100/16/images/5/Programmable+Real-Tim…
- A hozzászóláshoz be kell jelentkezni
Mindig viccess amikor PC-tol varnak real timeot,
legtobb baj nem is az OS miatt van ..
zynq FPGA+ARM is erdekes.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Mindig viccess amikor PC-tol varnak real timeot, legtobb baj nem is az OS miatt van ..
Jo, jo hakolas az egesz, de ha pl. nekem 10ms kell, akkor mondhatom ra, hogy real-time a rendszerem, hisz a kovetelmenyt teljesitette. Egy mai PC-vel jitter ide vagy oda, <50us siman garantalhato, ami mar sokmindenre jo.
En inkabb azt tartom viccesnek, hogy gorcsosen mindenre PC-t akarnak hasznalni, olyanra is amit egy 5$-os MCU-val rovidebb ido alatt meg lehet oldani.
Nekem az megoldas tetszik, amikor egy multi-core MCU-n az egyik non-checked core-on fut egy linux egy checked-en pedig egy RTOS.
- A hozzászóláshoz be kell jelentkezni
akkor mar (a linux + RTOS fan kollegank, Ar0n kedveert): zynqus: FPGA + quad A53 + dual R5.
mi csinaltunk ilyet regebben (PPC + microblaze @ virtex4), es imadtam, de az az erzesem mindegy milyen szuper a hw, valahogy elverzik a dolog a heterogen arhitektura miatti extra sw nehezsegeken.
de hatha mostanra megerett a vilag erre.
- A hozzászóláshoz be kell jelentkezni
Erdekes. Hol van szukseg ilyen megoldasokra?
- A hozzászóláshoz be kell jelentkezni
zynq FPGA+ARM is erdekes.
Érdekes és sok szívás is volt vele. Vivadonak kb. atomerőmű kell és debug is nehézkes. Ráadásul egy csomó dolog keményen fizetős. Én egy algoritmus gyorsítását implementáltam rajta AXI buszon keresztül, de nem volt leányálom. Meg van valahol még a ZedBoardom.
Nem szívesen dolgoztam vele, pedig nagyon tetszett először a dolog. Kb mint a NetFPGA.
- A hozzászóláshoz be kell jelentkezni
ha ez elojon meg: a zynq (nem ultrascale, hanem sima, abbol is a korai darabok) megy ISE alatt is, a 14.7 tamogat(ott) parat a 7 seriesbol.
hogy mennyire hasznos ez az fugg attol, hogy milyen gyari IP-ket hasznalsz. mi DSP-t csinalunk, neha kiprobaljuk zynq-en ISE alatt is a designt, regebbi xilinx FPGA csaladok es mas gyartok fele kacsingatva.
- A hozzászóláshoz be kell jelentkezni