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

[gld17]

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

---

---

Odpovědi

[stativ]

Proč prostě nepoužiješ JNI?

[gld17]

Díky, už se na to dívám

[rADOn]

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.

[gld17]

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]

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".

[rADOn]

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.

[Sten]

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]

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

[Josef Kufner]

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.

[rADOn]

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 :->

[gld17]

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]

No nerikal jsem to? Jsme jen banda idiotu, skutecny (budouci ) programator se pozna podle toho co vsechno nechce a nepotrebuje znat.

[pavlix]

Made my day :D.

[gld17]

To jsem vůbec neřekl, snad můžu mít svůj názor

Děkuju za vysvětlení.

[pavlix]

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.

[stativ]

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.

[pavlix]

To by dávalo smysl.

[rADOn]

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

[pavlix]

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.

[rADOn]

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

[pavlix]

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í ;).

[gld17]

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]

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ě.

[rADOn]

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.

[gld17]

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]

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.

[Petr Bravenec]

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

[pavlix]

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ě.

[gld17]

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]

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ý.

[Josef Kufner]

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.

[Petr Bravenec]

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.

[pavlix]

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.

[Josef Kufner]

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ě.

[pavlix]

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ě.

[Petr Bravenec]

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.