Callback funkce z kernel modulu

[prezek]

Zdravím, potřeboval bych předávat data z kernel modulu do uživatelského programu.
Kernel modul by v přerušení od přijatých znaků z GPS přečetl a dekódoval NMEA zprávu a do programu předával souřadnice. Poradíte mi někdo, prosím, jaký zvolit přístup k předávání dat z modulu do uživatelské aplikace?

[Reklama]

[Ivan]

Asi bych to udelal "postaru". Ovladac by vytvoril vlastni znakovy zarizeni a vracel by radky se souradnicema v textovy forme.

Moderni reseni by byl Netlink socket.

[Jakub Váňa]

procfs nebo sysfs - přijde mi to nejrychlejší - pracuje se s tim fakt snadno

[RDa]

pokud uz pises kernel modul, podivej se zda neni nejaky standard k gps device. nejspis nejstandardnejsi je seriovy port, poskytujici nmea komunikaci - takze vazne nechapu k cemu je treba nejaky modul do kernelu ktery nic, co by neslo udelat v userspace, delat nebude

[prezek]

RDa: mám své důvody přesunout zpracování do modulu - zpracování musí proběhnout rychle a v určeném čase. Nemůžu si dovolit zpracovávat data v náhodném čase několik desítek ms po jejich přijetí a nedokážu si představit, jak k tomu donutit program v user space.

Myslíte, že by mohlo být rychlé poslat signál z modulu, který by informoval, že v procfs jsou aktuální data?

[Reklama]

[Franta.]

Viz GPSD: http://www.catb.org/gpsd/

Proč tohle cpát do jádra?

[Jakub Váňa]

Mám obavu, že zaslání signálu nepovede k okamžitému přeplánování userspace aplikace a nemyslím, že přinese něco navíc proti blokujícímu read z daného procfs souboru. Naopak bych čakal, že taková aplikace, která čeká na data bude přeplánována daleko dříve po jejich přípravě ...

Signálama bych to asi nekomplikoval.

[RDa]

normalni kernel vam nezaruci o nic lepsi planovani nez userspace, takze porad tomu nerozumim. a pokud uz jedete na kernelu s rtai patchem, tak tam mate realtime fifo jeste trocha lazeni a bude to stabilni na 3.5.7 (donedavna byla jen pro starsi jadra)

[noh]

Proboha k cemu tohle bude dobry??? Pokud to je GPS, ktera posila NMEA, nikdy to z ni nedostanes "v realnem case". NMEA veta ale vzdy bude obsahovat timestamp fixu, tak se podle nej rid. Pouzij GPSD jako kazdej normalni clovek a smir se s tim, ze ty data budes mit o par ms pozdeji. Pokud to totiz neni DGPS, nutna chyba je podstatne vetsi nez to, co by mohlo byt jen teoreticky vzniknout tim, co tady resis...
A ano, da se postavit i GPS kompas, kde anteny jsou pul metru od sebe, ale to je zcela jina story a z pouzityho hardware tam tece dost podstatne jiny krmivo.

[jenicek]

Jak se to co měříš pohybuje? Je nepřesnost GPS menší než to kolik to uletí/ujede za "pár" milisekund?

[prezek]

Situace je poněkud složitější a já se nechtěl zamotat do zbytečného vysvětlování. Mám desku s ARMem, která má dotykový display a běží na ní Linux s jádrem 2.6.28 s tickem 10 ms. K desce je připojený radiový modul, který komunikuje po SPI, GPS, která komunikuje po UARTU a další nedůležité kravinky. Bezdrátová komunikace musí probíhat v určeném čase - to je dáno omezením vyplývajících z příslušných norem, takže RF komunikace probíhá v přerušení a odchylka ve zpracování se pohybuje v řádu mikrosekund (handler přerušení má poměrně velkou prioritu a startuje 10 - 12 us po události). Další zesložitění vyplývá z toho, že když běží aktivní aplikace, tak procesor ruší RF modul a dosah se zkracuje zhruba o 1/3 až 1/2, proto potřebuju aby byl v předem určené době neběžela aplikace a procesor byl v některém z úsporných režimů. Zkoušel jsem změřit zpoždění mezi přijetím dat po sériové lince a jejich zpracováním v userspace a vypadá to, že nejdelší čas je malinko delší, než 1 tisk (cca 10 ms), což se dá akceptovat.
Zpracování dat GPS, vykreslování na display, snímání dotykového displaye apod. tedy asi nechám na userspace program. RF komunikace a časová synchronizace podle GPS poběží v modulu. Pro komunikaci mezi modulem a userspace vyzkouším tedy 2 možnosti:
1. blokové zařízení namapované v modulu a userspace se synchronizací pomocí signálů
2. znakové zařízení
Díky za inspiraci a kdybyste měli další připomínky, tak prosím napište.
Petr

[Jarek]

Latence sériového portu se dá snížit nastavením ASYNC_LOW_LATENCY ve struct serial_struct. Používal jsem to na 486 a latenci to snížlo z 10 ms na nějaké 2 ms.