Dotaz: Metody pristupu k seriovemu portu v C

[Tomáš Skočdopole]

Ahoj,

chtel bych se zeptat ohledne pristupu k seriovemu portu v linuxu. Nyni pouzivam klasicke
otevreni serioveho portu jako souboru /dev/ttyUSB0, nastaveni struktur termios a v programu
je pak nekonecna smycka ktera kontroluje prichozi data na portu a pripadne odesila data na port. Jenze tato aplikace diky nekonecne smycce zatizi zbytecne procesor na 100 procent.
Moje dosavadni programy, ktere jsem naprogramoval vetsinou neco udelaji a hned skonci. S programovanim aplikace, ktera bezi neustale a kontroluje vstupy z ruznych zdroju (seriovy port, joystick, ...) a na zaklade toho neco udela vubec nemam zadne zkusenosti. Chtel bych se zeptat, jakou metodou se vubec takoveto programy pisou. Napriklad program ceka dokud neprijdou nejaka data na seriovy port, pokud prijdou provede se treba nejaka napsana funkce a pak se zase ceka na dalsi "event".

Mohl bych prosim pozadat o nejakou radu jak se tyto aplikace delaji. Jestli je potreba delat vicevlaknove aplikace, nebo nejake eventy, signaly, semafory.
Budu rad za kazdou radu.

Dekuji Tomas

Odpovědi

[ava]

predpokladam ze nemyslis /dev/ttyUSB0 ale /dev/ttyS0

Chova se to normalne jako soubor, otevri si ho pomoci open (man 2 open) a na otevreny filedescriptor volej select (man 2 select), tomu muzes rict at ceka az nastane na deskriptoru nejaka nova udalost (napr. nova data). Dokonce lze cekat na udalosti na vice deskriptorech najednou i s pripadnym timeoutem.

[Messa]

Ještě man select_tut.

 

[kozzi]

 jen dodam ze klidne mohl mit namysli /dev/ttyUSB0 jelikoz je to taky seriovy port

[Michal Kubeček]

Jako alternativu k select() lze použít také poll(). Jeho rozhraní mi připadá trochu čistší a používání pohodlnější, ale to je asi věc vkusu.

[Tomáš Skočdopole]

Ahoj,

dekuji vsem za reakce. Jenom bych se chtel jeste zeptat:

Jakou technikou by sla naprogramovat trida pro praci se seriovym portem, aby programator, ktery bude potom pracovat s tou tridou, mohl napriklad zaregistrovat si nejakou svoji funkci, ktera se provede jakmile neco prijde na seriovy port.

 

A jeste k te funkci select()  Dle tohoto prikladu funkce select ceka nejaky timeout. Takze v prubehu toho casu je program zablokovany?

Ja bych potreboval spis udelat neco, aby ten program mohl normalne pokracovat ve sve cinnosti a na pozadi prijimat a vysilat data do serioveho portu. To budu muset vytvorit vicevlaknovou aplikaci? Dekuji

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/time.h>

int wait_for_input_2s () {
 fd_set set;
 struct timeval timeout;

 FD_ZERO(&set);
 FD_SET(0, &set); // 0 - stdin

 timeout.tv_sec = 2;
 timeout.tv_usec = 0;

 return select(FD_SETSIZE, &set, NULL, NULL, &timeout);
}

int main (int argc, char ** argv) {
 while (1) {
  printf("napis nieco a stlac ENTER: ");
  fflush(stdout);
  if (wait_for_input_2s() > 0) {
   char * str;
   scanf("%as", &str);
   printf("\nvyborne, vies aj pisat (%s)\n\n", str);
   break;
  } else {
   printf("\nnic si nenapisal, este raz,\n");
  }
 }

 exit(EXIT_SUCCESS);
}


[rastos]

To budu muset vytvorit vicevlaknovou aplikaci?

Ano.

[Tomáš Skočdopole]

Dobre, takze dejme tomu, ze vytvorim instanci te tridy serialport, pak do ni vlozim ukazatel na svoji funkci, kterou chci volat, kdyz prijdou data na seriovy port.

Trida serialport potom vytvori vlakno, ve kterem bude blokujici rezim cteni. Pokud fce read v blokujicim rezimu neco vyhodi, data se ulozi napr do fronty a zavola se prislusna funkce.

Soucasne s timto bude ve fci main provaden jiny vypocet.

Je to tedy takhle spravne?

Dekuji

[Michal Kubeček]

V principu ano, ale při realizaci se tam dá samozřejmě nasekat spousta chyb. :-)

[Tomáš Skočdopole]

Mno, ted jak premejslim nad tou implementaci, napada me nekolik otazek:

ta trida by mela otevreny jeden file deskriptor na ten port v rezimu read&write? Nebo musi mit  kazde vlakno svuj deskriptor v prislusnych rezimech (jedno RD only a druhe WR only)?

Jde mi o to, zda je korektni z jednoho filedeskriptoru naraz cist a naraz zapisovat z techto dvou vlaken.

Dal bych se chtel zeptat jak to bude se zapisem na port - jak to jedno vlakno mam jakoze nechat cekat az mu poslu nejaka data? A pres co mu budu posilat nejake data?

Dekuji za reakce! Tomas

[Messa]

Hm, nebylo by to s tím selectem jednodušší?

Stačí jeden file deskriptor pro všechna vlákna. Naráz číst a zapisovat by neměl být problém, přinejmenším ne u systémových volání (read a write).

"A pres co mu budu posilat nejake data?" Vlákno si na nějaká bude muset počkat. Třeba použitím condition variables. Fronty jsou v úvodech do programování s vlákny časté téma.

[Tomáš Skočdopole]

ano, to je taky vec, kterou jeste netusim jak udelat. Takze rikate condition variables - zkusim o tom neco pocist.

Me napadlo neco jako virtualni roura, nebo nejaky stream. Proste ze to vlakno by stalo na funkci read, ktera by se nastavila jako blokujici. Dokud by uzivatel te dane tridy neposlal nejake data.

Tomas

[Tomáš Skočdopole]

jeste me napadlo, ze by se to vlakno pro odesilani vytvorilo jen na tu dobu, co by bylo potreba neco odeslat ven z portu.

Ale nevim, zda by to nesezralo zbytecne vykon - rezie pro vytvoreni vlakna...

 

[Michal Kubeček]

Hm, nebylo by to s tím selectem jednodušší?

Záleží na tom, co během toho čekání potřebujete dělat. Pokud čekat na jiný descriptor, tak ano. Pokud něco složitějšího, tak ne.

Stačí jeden file deskriptor pro všechna vlákna. Naráz číst a zapisovat by neměl být problém, přinejmenším ne u systémových volání (read a write).

Problém by to neměl být ani u streamových funkcí, protože ty elementární defaultně zamykají, což je někdy potřeba z výkonových důvodů potlačit, viz unlocked_stdio(3).

[trekker.dk]

Proč hned vícevláknovou aplikaci? Co takhle signály? Při použití Qt si lze relativně snadno v reakci na signál vygenerovat událost.

Rozhodně bych neřekl, že vícevláknová aplikace je jediná volba.

[Tomáš Skočdopole]

no mela by to byt nenarocna konzolova aplikace.

Ty signaly jsem zvazoval, jenze pro uzivatelske pouziti jsou k dispozici jen 2 - SIGUSR1 a SIGUSR2.

Coz je pro me malo... :(

[trekker.dk]

Ty signaly jsem zvazoval, jenze pro uzivatelske pouziti jsou k dispozici jen 2 - SIGUSR1 a SIGUSR2.

Já jsem myslel signál od toho portu. Funguje tak, že přijdou data od portu, běh programu se přeruší a skočí se do obslužné funkce. V té se data přijmou, nějak se s nimi naloží, tam záleží na tom, co přesně děláš, pak se funkce ukončí a běh programu se v vrací tam, odkud se vyšlo.

Existují i nějaké možnosti synchronizace - možnost, že se ti ten signál doručí, až když budeš chtít. Základní informace jsou česky popsány např. v knize Jádro systému Linux, další informace najdeš v manuálových stránkách (man signal, sigaction, sigwaitinfo), na webu najdeš příklady.

[Messa]

Jak naprogramovat tu třídu? Třeba aby si uživatel mohl zaregistrovat handler na nějakou událost To je těžké takhle rozhodnout, to záleží na tom, co to má vlastně dělat a umět.

Select čeká, dokud se něco nestane nebo dokud neuběhne timeout. Nebo dokud nepřijde nějaký signál, pokud pracuješ se signály, možná tě bude zajímat pselect, ale to je teď vedlejší. Pokud nechceš, aby select čekal, jednoduše nastav nulový timeout. To je také popsané v té man stránce.

Select a podobná volání existují právě od toho, aby poskytly jednodušší a výkonější řešení než za pomoci vláken (a s otravováním se s mutexy, semafory...). Záleží ovšem, co jiného bude tvá aplikace ještě dělat, pokud budeš spouštět nějaké příkazy (např. z cizí knihovny) které trvají dlouho a jejich autor se o to moc nestaral, asi některé věci půjdou hladce jen s vlákny (nebo procesy).


FD_SETSIZE? Zajímavé použití... Mimochodem, pokud chceš při programování dát najevo, že 0 je standardní vstup, můžeš použít makro STDIN_FILENO z unistd.h.