abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 5
dnes 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 0
včera 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 5
včera 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 33
včera 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 9
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 25
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 18
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 6
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 774 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Způsoby komunikace dvou běžících aplikací

24.3.2014 16:55 gld17 | skóre: 4 | blog: GLDiuv_blog
Způsoby komunikace dvou běžících aplikací
Přečteno: 697×
Dobrý den,

stavím si quadcopteru s Raspberry Pi. Mám servrovskou aplikaci běžící na mém notebooku a klientskou aplikaci běžící na Raspberry (s Raspianem (Debianem)).

Klientskou aplikaci mám napsanou v javě. Potřebuji však komunikovat s modulem MPU6050 (akcel.+gyro) připojeným přes I2C.

Pro MPU6050 existuje jediná napsaná knihovna, která umí plně využít jeho možnosti (MPU6050 umí totiž provádět výpočty přímo v sobě). Tato knihovna je napsaná v C++ a nedovedu si představit jí přepisovat do javy.

Chci se proto zeptat linuxáků, co by mi poradili jako nejvhodnější řešení.

Zatím mám takovou představu, že napíšu aplikaci v C++ která bude obsluhovat akcelerometr, tu spustím hned při bootování a já si z ní budu nějakým způsobem v mě klientské aplikaci (napadlo mě udělat to přes Socket) odebírat data.

Ale nejvíc by se mi líbilo využít mechanismy Linuxu (které moc neznám) a napsat to jako modul (říkám to správně?).

Děkuji za pomoc


Řešení dotazu:


Odpovědi

stativ avatar 24.3.2014 17:29 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Proč prostě nepoužiješ JNI?
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
24.3.2014 18:04 gld17 | skóre: 4 | blog: GLDiuv_blog
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Díky, už se na to dívám :-)
rADOn avatar 24.3.2014 18:40 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Jestli to nema moc komplikovany protokol tak muzes videt na i2c primo z userspace.
Zatím mám takovou představu, že napíšu aplikaci v C++ která bude obsluhovat akcelerometr, tu spustím hned při bootování a já si z ní budu nějakým způsobem v mě klientské aplikaci (napadlo mě udělat to přes Socket) odebírat data.
Cili spousta srani pro nic za nic. Pokud se to cely nema zasekavat na blokujicim cteni, budes muset napsat select/poll handler a postavit nad tim protokol na posilani zprav. To uz mas jednodussi psat si navzajem do sdileny pameti, tam se musis starat akorat o atomicitu. Ale jestli se opravdu chces s takovou silenosti matlat, tak existujou hotovy protokoly (dbus, corba, ice…)
Ale nejvíc by se mi líbilo využít mechanismy Linuxu (které moc neznám) a napsat to jako modul (říkám to správně?).
Jestli myslis modul do kernelu kterej by rozumel primo protokolu toho cipu, to by bylo nejlepsi. Ale jestli se musis na takovou vec ptat tak je to, bez urazky, zcela mimo tvoji ligu. Jinak je nejbeznejsi praxe ze co se nevejde do kernelu se zabali do pekny userspace knihovny s nejakym peknym API v C nebo prinejhorsim C++ a to pak jde nalinkovat vicemene z jakyhokoliv slusne vychovanyho jazyka. Coz je v jave to vyse zminene JNI.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
25.3.2014 00:45 gld17 | skóre: 4 | blog: GLDiuv_blog
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Děkuji, použiju JNI.

Jen informativně, jak fungují vlastně ty soubory v /dev? Nešel by nějaký takový vytvořit a komunikovat přes něj s tím ovladačem MPU6050 napsaným v C/C++?
rADOn avatar 27.3.2014 17:41 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Soubory v /dev spravuje a udrzuje primo jadro, to je "kralovstvi nebeske". Pokud bys chtel komunikovat pres soubor tak zalozis trubku pres mkfifo (1), do ni pak muze jeden proces psat a jinej cist a tim spolu kecat. Ale komunikace pres fifo ma takovou vlastnost ze kdyz neni co cist tak se cteci proces zablokuje. To je sice sikovny pacz tim pusti procesor delat neco uzitecnyho (treba zrovna ten zapisujici proces) ale pro rizeni letajicho hardwaru (a obecne rt ulohy) asi neni uplne dobry kdyz se ti proces na predem neznamou dobu zastavi. Proto se to pouziva spis pro zpracovani dat ve stylu fronty a ne na rizeni veci. (Neblokujici cteni pro jednoduchost vynechavam, to ma zase jiny problemy. Zvracenosti jako nechavat si posilat "vyprostovaci" signal casovace jsou svyho druhu reseni, ale je to takovej narovnavak-na-ohejbak.) Na komunikaci s hotovou knihovnou se hodi spis RPC a to se dela asynchrone pres socket jak jsem psal vyse.

Vsechno tohle zahrnuje prinejmesim nejakou de/serializaci coz je podstatne komplikovanejsi (a ma z hlediska RT ulohy nezanedbatelny overhead) nez volat tu knihovnu primo. I kdyz to pozenes pres hotovy protokol (ted je zrovna v kurzu dbus) tak s tim bude dost prace navic. Jestli je nejaky problem napsat si wrapper (nemuzu posoudit, nikdy jsem JNI v ruce nemel) tak asi Java neni "slusne vychovany jazyk".
"2^24 comments ought to be enough for anyone" -- CmdrTaco
rADOn avatar 27.3.2014 17:51 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Podle toho co se pise tady neni cteni pres i2c zadnej problem, akorat clovek musi vedet spravny adresy a konstanty. Coz bude asi to co dela ta knihovna… Takze mozna nejjednodussi bude najit knihovnu na smbus a napsat si ten ovladac celej.

"2^24 comments ought to be enough for anyone" -- CmdrTaco
27.3.2014 20:47 Sten
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Proč vynecháváte neblokující volání (resp. jaké problémy dle vás má)? Vždyť je přeci přesně to, co by RT úlohy měly používat. Pro časování se pak používá message loop postavená na select nebo epoll, což by ale RT úlohy měly používat tak jako tak.
rADOn avatar 27.3.2014 23:18 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Ja jsem nepsal ze rt ulohy nemaji pouzivat neblokujici cteni! Psal jsem ze to neni "reseni" blokovani roury, protoze pokud neco takovyho potrebuje tak to muze honit rovnou nad socketem. A select()/poll() jsem zminoval vyse. Rouru jsem zminil jen proto ze se tazatel ptal na komunikaci "pres soubor".

Stejne je to jen akademicka debata, pacz na tazateluv problem je to prekomplikovany a nejspis ani nechape o cem je tady rec :-)
"2^24 comments ought to be enough for anyone" -- CmdrTaco
Josef Kufner avatar 27.3.2014 22:04 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
A nebylo by lepší tu javovou aplikaci přepsat do C++ a Qt? Odpadnou komplikace s knihovnou a budeš to mít rychlejší a míň nenažrané, což by se na Malině mohlo hodit. Qt má slušný event loop, integrovanou implementaci stavových automatů a dobrou dokumentaci.
Hello world ! Segmentation fault (core dumped)
rADOn avatar 27.3.2014 23:27 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
To by bylo urcite lepsi a jednodussi. A prave proto kdyz nekdo pri smyslech a dusevnim zdravi napise ze to pise v Jave, tak soudim ze o lepsi a jednodussi reseni nema zajem a nema cenu to ani zminovat :->
"2^24 comments ought to be enough for anyone" -- CmdrTaco
28.3.2014 01:30 gld17 | skóre: 4 | blog: GLDiuv_blog
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Jenomže ja v C++ pořádně neumím, to jednak (ale pořád bych byl ochoten se naučit) ale za druhé mám problém s kompilací - s Javou si klienta klidně napíšu ve svých Winech v NetBeans, tam si ho i zkompiluju, přetáhnu do RPi jar a rovnou to spustím (popřípadě můžu i debuggovat přímo z RPi v NetBeans). Ono jaksi kompilovat C++ nebo nedej bože to i psát rovnou na RPi to bych fakt nechtěl.

A za třetí, odmítám si dělat servrovskou část v C++, Qt rozhodně používat nechci, jak na RPi (tam nepotřebuju GUI), tak u serverové aplikace - a to proto, že stejně nepodporuje tolik možností (např. různé eventy nad objekty gui, jako je odchyt souřadnic kurzoru apod.) jako Java nebo C# - je to pro moje budoucí povolání programátora ztráta investovat do takové věci čas, už jsem Qt zkoušel a odinstaloval to hned co jsem zjistil, že si tam některé věci budu muset komplet celé napsat, když jsem potřeboval udělat jeden projekt. Tak proč se to vůbec učit když to můžu dělat v Javě a mám spoustu času ušetřeno? Java je fajn a ve všech směrech mi vyhovuje.

Jinak ano, uznávám, profík programátor v C++ je borec a špička, ale moje stanovisko je, že nechci trávit u PC zbytečně moc času. Já hodlám být ten střední proud :-)
rADOn avatar 28.3.2014 10:33 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
No nerikal jsem to? Jsme jen banda idiotu, skutecny (budouci :-) ) programator se pozna podle toho co vsechno nechce a nepotrebuje znat.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
pavlix avatar 28.3.2014 11:15 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Made my day :D.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
28.3.2014 11:51 gld17 | skóre: 4 | blog: GLDiuv_blog
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
To jsem vůbec neřekl, snad můžu mít svůj názor

Děkuju za vysvětlení.
pavlix avatar 28.3.2014 11:59 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
rADOn je holt v tomhle ohledu trochu přísnější. Všichni víme, že Java je the cool enterprisy programming language. Python je příliš amatérský a C++ je příliš low level pro bežného aplikačního programátora.

Nicméně, co jsem vůbec nepochopil je, co se tu vlastně řeší. V nadpisu je komunikace běžících aplikací, ale pak se řeší I2C a mezitím JNI. To je fakt děsivý mišmaš. Pokud člověk chce jen komunikaci mezi aplikacemi, tak prostředky systému jdou najít pod klíčovými slovy pipe a socket. High-level programovací jazyky a knihovny poskytují prostředky většinou na socketech postavené, tudíž jaksi není co řešit.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
stativ avatar 28.3.2014 15:19 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Nicméně, co jsem vůbec nepochopil je, co se tu vlastně řeší. V nadpisu je komunikace běžících aplikací, ale pak se řeší I2C a mezitím JNI. To je fakt děsivý mišmaš. Pokud člověk chce jen komunikaci mezi aplikacemi, tak prostředky systému jdou najít pod klíčovými slovy pipe a socket. High-level programovací jazyky a knihovny poskytují prostředky většinou na socketech postavené, tudíž jaksi není co řešit.
Je to tu celé nějak zmatené. Ale vzhledem k tomu, že tazatel evidentně nemá moc chuť do C/C++, ale přitom má Céčkovou knihovnu, která umí všechno, co potřebuje, tak mi přijde jako nejschůdnější udělat okolo té knihovny malý wrapper pomocí JNI a pak už jen používat Javu.
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
pavlix avatar 28.3.2014 22:38 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
To by dávalo smysl.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
rADOn avatar 28.3.2014 15:28 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
executive summary: Jde tady o to ze tazatel jako spravny javista zacatecnik vymejsli narovnavak na ohejbak. Ale protoze projevil vice invence nez bezni entrprajs frikulini tak jsem ho nechtel odbyt s "je to blbost, nedelej to" a snazil jsem se trochu osvetlit jak a na na co se v realu pouzivaji ta ruzna sprosta slova ktera se tu padla. Jak vidno, marna snaha, javisti jsou proste nepoucitelni :-)
"2^24 comments ought to be enough for anyone" -- CmdrTaco
pavlix avatar 28.3.2014 22:42 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Nebuď zlý. Náhodou se mi stalo, že pracuju ve firmě, kde je javistů jak nasráno a musím říct, že o nás linuxácích a našich způsobech nemají zrovna valné mínění. Tak proč je v tom ještě pomáhat. Stačí, že se musejí mordovat s tou Javou, která na první pohled působí hrozně uceleně a jednoduše a teprve potom se ukáže, co to všechno obnáší, aby to vůbec trochu jelo.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
rADOn avatar 29.3.2014 00:15 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Zlej? Kdybych chtel bejt zlej tak mu poradim uplne jiny veci :-)

BTW v javovy firme jste taky delal, dokonce jsem tam tu javu psal... kde myslis ze se moje extremisticky nazory na javu vzaly? :-) No vlastne tam tak uplne ne. Extremisticky zacaly bejt az kdyz jsem v soucasnym jobu dostal pricuchnout k C++. S linuxackymi zpusoby nebyl problem, spis naopak. Kdyz jsem nekdy treti den zjistil ze se nestydi psat "programy" na preklapeni csvcek do sql insertu tak jsem nazhavil awk a razem byli linuxaci a jejich zpusoby oblibeny :-p
"2^24 comments ought to be enough for anyone" -- CmdrTaco
pavlix avatar 29.3.2014 09:48 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Tož u nás se Java tuším objevila nějakou velkou akvizicí, takže to je něco jako dvě firmy pod jednou střechou. Já jsem ani tak nemyslel způsoby práce jako způsoby chování, když se někdo zeptá na řešení v linuxáky neoblíbeném prostředí ;).
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
28.3.2014 16:45 gld17 | skóre: 4 | blog: GLDiuv_blog
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Abych celý problém objasnil, ten modul, pro který mám ovladače v C++, je MPU6050 - gyro s akcelerometrem. Ano, komunikuje přes I2C, ano, dají se z něj normálně získávat raw údaje z gyra a akcelerometru, ale on si je umí i sám uvnitř zpracovat (dělá fůzi z gyra a akcelerometru což je nutné, jinak se to nedá praktikcy pořádně použít) a to obstarává právě ta knihovna, která je mimochodem pro tento modul jediná co existuje; takže ne, nejedná se jen o prostou komunikaci přes I2C, proto musím tu knihovnu použít :-)

Zkoušel jsem JNI ale poněvač jsem nezjistil, jak uchovat proměnné, které se vyvořily při inicializaci modulu, tak jsem to předělal nakonec na Socket a funguje mi to, ačkoliv mám trochu obavy z narůstajícího zpoždění, už teď to není ideál.

Jesli můžu, využil bych příležitost a zeptal se, o kolik je pomalejší volání konzolového příkazu přes EXEC(String command) (utility ServoBlaster která nastaví DMP modul na RPi kvůli změně PWM signálu do regulátoru motorů) než-li zavolání přímo funkce této knihovny z mé aplikace?
stativ avatar 28.3.2014 17:22 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Zkoušel jsem JNI ale poněvač jsem nezjistil, jak uchovat proměnné, které se vyvořily při inicializaci modulu, tak jsem to předělal nakonec na Socket a funguje mi to, ačkoliv mám trochu obavy z narůstajícího zpoždění, už teď to není ideál.
Pokud nejdou použít globální proměnné, tak bych se ještě podíval na použití NewGlobalRef pro vytvoření globální reference.
Jesli můžu, využil bych příležitost a zeptal se, o kolik je pomalejší volání konzolového příkazu přes EXEC(String command) (utility ServoBlaster která nastaví DMP modul na RPi kvůli změně PWM signálu do regulátoru motorů) než-li zavolání přímo funkce této knihovny z mé aplikace?
To ti nikdo přesně neřekne, muselo by se to vyzkoušet oboje a porovnat. Troufám si ale tvrdit, že to bude o hodně.
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
rADOn avatar 28.3.2014 21:53 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Jesli můžu, využil bych příležitost a zeptal se, o kolik je pomalejší volání konzolového příkazu přes EXEC(String command) (utility ServoBlaster která nastaví DMP modul na RPi kvůli změně PWM signálu do regulátoru motorů) než-li zavolání přímo funkce této knihovny z mé aplikace?
To ti nikdo přesně neřekne, muselo by se to vyzkoušet oboje a porovnat. Troufám si ale tvrdit, že to bude o hodně.
Hodne hodne moc. Nekolik radu. Vystreleni novyho procesu znamena kontext switch a uz jen to je draha operace. Ne jenom ze musis nakopirovat kodovej segment, musi planovac udelat svoje kolecko a takovy ty kernelovy veci. Docela velkej zarez je ze se vicemene invalidujou zahraty cache linky, by woko bych si tipnul ze to bude asi nejvetsi brzda. Plus takovy ty detaily jako nakopirovani enviromentu, commandlajny a nejaka ta knihovni omacka.

Zavolani funkce primo z nalinkovany knihovny je otazka lookupu v tabuli symbolu a dereference pointeru. Nula nula nic. Proto se taky knihovny pouzivaji. Ve tvem pripade tam bude jeste rezie JNI pacz musis preklopit javovsky datovy typy na ceckovy, coz bude drazsi nez to samotny volani :-) ale ve srovnani s saskarnou kolem execu je to porad zanedbatelny.

BTW tohle je ale akademicka otazka - dokonce i na raspi nebude rozdil okem viditelny. Pokud je to RT uloha, tak to daleko spis zabije nedeterminimismus. Pri execu musi kernel nabrat nakou pamet pro proces a kernelovy pameti pro novej task, coz muze zabrat jakykoliv cas mezi nulou a nekonecnem. Nula je samozrejne "normalni" stav, ale kdyz je masina pod tlakem (napriklad proto ze nejaky proces vyzral veskerou volnou pamet :-) a kernel zacne hledat co kde muze vysypat do swapu tak si muzes pekne pockat.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
29.3.2014 02:35 gld17 | skóre: 4 | blog: GLDiuv_blog
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
No z praxe se zdá, že cela sekvence "Prijem zpravy ze serveru a nalezite zavolat 4x EXEC pro 4 motory" trvá tak 50-60ms (protože když dám co 50ms odesílání zprávy ze serveru, tak už se mi to celé zahltí a motory začnou reagovat se zpožděním) a já si myslím že za to může ten exec().

Nicméně nakonec to dělám v C++ a není to náhodou tak špatné :-)
rADOn avatar 29.3.2014 10:29 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Ze by jsi nakonec nebyl uplne beznadejnej pripad? ;-) Ja ti povim jedno takovy stary moudro.

Kdyz umis jenom Javu, tak jsi javista. Kdyz umis pascal, tak jsi pascalista. Kdyz umis C tak jsi ceckar... Az budes znat tak tri-ctyri jazyky, tak si muzes rikat programator.

BTW zahlceni se ti muze stat bezne. i2c je podstatne pomalejsi nez kod na cpu, pokud s tim nepocitas neni problem dostat sezrat a zpracovat toho vic nez kolik se ti pak povede skutecne poslat na drat. Jestli s tim nepocita ta knihovna tak si to budes muset nejak zaridit.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
Petr Bravenec avatar 29.3.2014 10:40 Petr Bravenec | skóre: 43 | blog: Bravenec
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Ten zápisek, kde vysvětlujete, proč Javu a proč ne Qt se mi líbí. "Dělám v Javě a basta" je lepší, než "když já nevím..."

Ale jestli to nakonec budete dělat v C++, dejte Qt ještě šanci. Qt není jen GUI, je to i spousta dalších užitečných věcí. Na server to zrovna není, ale pořád to bude jednodušší, než obsluhovat sockety v C++ jinak.

Pro podobné prostředí (BeagleBone) vyvíjím aplikaci pro sběr dat - má to vestavěný http server, databázi a moduly pro komunikaci po sériovém portu, velká část je postavená na už hotových knihovnách: http://www.hobrasoft.cz/cs/fotomon/fotobot
Petr Bravenec - Hobrasoft s.r.o.
pavlix avatar 29.3.2014 11:05 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Ale jestli to nakonec budete dělat v C++, dejte Qt ještě šanci. Qt není jen GUI, je to i spousta dalších užitečných věcí. Na server to zrovna není, ale pořád to bude jednodušší, než obsluhovat sockety v C++ jinak.
Je spousta knihoven s event loopem popřípadě zapojitelných do prakticky libovolného event loopu a čtení a zápis do socketu zvládnou všechny tak nějak podobně.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
29.3.2014 15:07 gld17 | skóre: 4 | blog: GLDiuv_blog
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Jo dělám to v Qt na RPi, trochu jsem si ho přetaktoval (na 950MHz) ať to jede rychleji, kompilace sice i tak trochu trvá ale dá se to zvládnout :-)

Chápu to správně, že Qt má svoje knihovny, jako třeba sockety nebo thready (prootže Linux používá pthreads), takže pak můžu jeden projekt napsaný v Qt bez problému zkompilovat na Linux i na Win?
Petr Bravenec avatar 29.3.2014 15:50 Petr Bravenec | skóre: 43 | blog: Bravenec
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Ano. Běžně vyvíjím aplikace pro Windows tak, že vše dělám v Linuxu a když potřebuji balík pro Windows, pouze předhodím programu qmake jiný spec soubor a přeložím aplikaci pro windows, instalační balík vyrobím pomocí nsis. Podobně se dají dělat aplikace i pro Android, ale tam je rozdíl v prostředí trochu větší. Mezi Linuxem na ARM a na x86 nebude rozdíl prakticky žádný.
Petr Bravenec - Hobrasoft s.r.o.
Josef Kufner avatar 29.3.2014 16:07 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Můžeš to kompilovat i na výkoném stolním PC a pak nahrát na RPi – viz návod, ale asi to půjde i jednodušeji.

Implementace socketů a vláken v Qt je jen tenký wrapper okolo nativních funkcí, takže program napsaný v Qt používá na Linuxu pthread a klasické BSD sockety, stejně jako ostatní programy. Počítej ale s tím, že každá platforma má své speciality a i když se Qt snaží poskytnout univerzální API, ne vždy zvládne podchytit všechny detaily.
Hello world ! Segmentation fault (core dumped)
Petr Bravenec avatar 29.3.2014 17:24 Petr Bravenec | skóre: 43 | blog: Bravenec
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Ještě k tomu "wrapperu okolo socketů": Qt je událostní. Sockety typicky používám tak, že vytvořím třídu QSocket, propojím s okolím a nechám ji být. Program pak většinu času tráví kdesi ve smyčce zpráv a až v momentě, kdy má socket nějaká data, můj program se o tom dozví a můžu data v nějaké metodě zpracovat. Je to pohodlnější, než se trápit s blokujícími io operacemi (program pak nedělá nic jiného, než čeká na zprávu), nebo periodicky kontrolovat socket selectem.
Petr Bravenec - Hobrasoft s.r.o.
pavlix avatar 29.3.2014 21:24 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Především je program v době zablokování technicky vzato mrtvý, neschopný reagovat na jakékoliv jiné události než tu jednu konkrétní, na které je zablokovaný. To se hodí tak u jednoduchých skriptů nebo ekvivalentních binárek.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
Josef Kufner avatar 30.3.2014 13:49 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Main loop v Qt a i jiných framworcích není nic jiného než šikovně udělané čekání se select, poll, nebo nějakou modernější variantou téhož. Události jsou jen nepřímá volání metody podle výsledku toho selectu uvnitř.

Za zmínku stojí, že jedním z těch filedescriptrů je typicky i spojení na X server, kudy přichází informace o akcích uživatele a odchází příkazy ke kreslení na obrazovku. Totéž platí pro stdio.

Ten program je zablokovaný úplně stejně jako při prostém blokujícím čtení z jednoho filedescriptoru, jen to systémové volání čeká na více filedescriptorech najednou a pak řekne, který to byl.

Select není nějaké periodické čekání. Je to zablokování s timeoutem, aby program mohl čas od času pohnout animací nebo něco zatahat za nohu. Periodické čekání by vypadalo tak, že by se ve smyčce kontrolovalo, zda přišla data a když ne, tak by se chvilku spalo. Select to dělá naopak, chvilku čeká a pak řekne, že nic nepřišlo, ale když něco přijde, program to ví okamžitě.
Hello world ! Segmentation fault (core dumped)
pavlix avatar 30.3.2014 17:34 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Ten program je zablokovaný úplně stejně jako při prostém blokujícím čtení z jednoho filedescriptoru, jen to systémové volání čeká na více filedescriptorech najednou a pak řekne, který to byl.
Čekání na události z více zdrojů je hlavním smyslem event loopů postavených nad nějakým systémovým voláním, které toto umožňuje.
Select není nějaké periodické čekání. Je to zablokování s timeoutem, aby program mohl čas od času pohnout animací nebo něco zatahat za nohu.
A na linuxu je i ten timeout zbytečný, vzhledem k dostupnosti timerfd lze časovač jednoduše považovat za další zdroj událostí, a též ho tak technicky realizovat.

Podle mě to Petr napsal správně.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
Petr Bravenec avatar 30.3.2014 21:00 Petr Bravenec | skóre: 43 | blog: Bravenec
Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
Ono je celkem fuk, jestli jsem to napsal správně - použít select se dá všelijak. Myslím, že Josef podle toho popisu funkce selectu v nakonec používá select úplně stejně, ve smyčce, periodicky.

Podstatná je jiná věc: Qt či jiný framework dokáže programátora této činnosti ušetřit, nabízí mu hotové, odladěné řešení. Navíc Qt některé věci uklidí transparentně i do jiných vláken, kde už pak postup blokující / neblokující + select nehraje roli.

Pracovat s Qt nemusí být vždy jednodušší, ale připadá mi to trochu bezpečnější, není tam tolik míst, kde se dá něco pokazit.
Petr Bravenec - Hobrasoft s.r.o.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.