USB bulk transfer scheduling/priority?

Alaplapok

Sziasztok!

Van egy erdekes problemank: adott egy kamera (CCD), amirol az adat az USB2-n jon le. A drivere libusb-n alapul, nyilt, sokat tu'rtam bele en is hogy kello"en jo legyen. Namost, a hardver maga olyan hogy usb_bluk_transferrel kell letolteni ke'penke'nt 32mega adatot, viszont ha csak egy kicsit (1-2 sza'zad masodpercet) ke'sik is a transfer request, akkor a kamera firmware-e lefagy. Ezt vagy hideg inditas (ta'p kihuz-visszadug) oldja meg, vagy egy szoftveres USB reset (USBDEVFS_RESET ioctl() a /dev/bus/usb/xxx/yyy-re). Ezt az egesz aspektust (sajat a'tiratu driver le've'n) jol ki lehet(ett) kiserletezni.

Ha kvazi-mai ertelemben vett gyors asztali ge'pen hasznaljuk a kamera't akkor ugy nagyjabol stabilan megy minden, mondjuk havonta 1-2-3x kiakad igy, de az kvazi "belefer". A vezerlest viszont szeretnenk attenni egy beagyazott, mozgo alkatre'szek nelkuli vasra (pl pcengines/alix-re). Ennel az a tapasztalat, hogy mukodik ugyan, de kabe minden 10-20ik letolte'sne'l ma'r kiakad. Ez meg ugye nem annyira jo.

Kerdes, hogy van-e vmi olyan opcio (/proc, /sys, nice, barmi) ami egy userspace-bol, libusb-n keresztul kihajtott eszkoz I/O priority-je't jo magasra veszi? Amig me'g ki fogok probalni, hogy a processz nice erte'ke't felveszem magasra (maximumra), root-kent, es akkor hatha. De valami ennel konkretabb, specifikusabb barmi?

Vagy egy preemtiv rendszernel felejtsem el ezt az egeszet es oruljunk hogy 1sec-en belul atadodik a vezerles...?

A

  • 3602 megtekintés

( Zs | 2013. 12. 17., k – 15:01 )

A driver saját gyártmány. A kamera firmware mennyire az? Konkrétan: én úgy emlékszem, hogy az USB több átviteli módot is támogat és van benne olyan, ami neked kéne - de az nem a bulk átvitel. Na jó, kerestem kicsit:
Bulk Transfer is typically used for devices that transfer large amounts of non-time sensitive data, and that can use any available bandwidth, such as printers and scanners.
Isochronous Transfer is most commonly used for time-dependent information, such as multimedia streams and telephony.
Szóval ezek ismeretében ha megoldható, akkor a bulk helyett isochronous átvitelt javasolnék.
Ha nem megoldható, akkor az nyilván más eset - akkor viszont marad a trükközés, mert a bulk átvitelnél az átviteli idő nem garantálható.

Nem, a kamera firmware nem sajat gyartamany - akkor fel se merulne a problema ;) Szoval igen, valoszinuleg olyasmi van hogy a kamera A/D konvertere'nek a fifo-ja kicsi. Vagy valami hasonlo lehet es ha nem olvassa ki idoben az ember, akkor a fifo az tulcsordul. Ezek "imaging" kamera'k, szoval nem realtime. Az exp. ido"k tobb masodpercesek - percesek. Raadasul az ADC az kabe 1msps-es, szoval mondjuk 1 masodpercnyi fifo is 2 mega's lenne, ami ugye manapsag ma'r nem eppen szu"k keresztmetszet.

Az usb host-on csak egy device lo'g, szoval az sem lehet hogy to"bb a hub a kellete'ne'l. Ezen nem tudunk javitani.

A gyarto az kreten, csak win-only a nativ support, a linuxos kihajta's az third-party-n keresztul megy, es az is olyan amilyen. Az a driver c++-os bloatware ko'd, ami me'g bugos is itt-ott, azt kellett kigyomlalni nativ c-re, kiszedni a sallangot e's kijavitani a hibait. Es itt a javitgatas soran sikerult odaig eljutni hogyha ez a libusb_bulk_transfer() egy usleep()-pel kesleltetett, akkor rovid ido" utan definite kiakad a firmware (azaz biztos nem amiatt akad ki mert rossz parancs megy elotte, vagy ilyesmi). Emiatt gyengebb gepen, vagy egy erosebb de vmi miatt kesleltetett gepen gyakrabban elofordul ez, es az ugye nem az igazi...

( answ | 2013. 12. 18., sze – 01:24 )

Barmit is ugykodsz a prioritassal csak csokkented a valoszinuseget a problema elofordulasanak es nem szunteted meg.

A megoldas szerintem CONFIG_PREEMPT_RT vagy valami realtime mikrokerneles bohockodas (pl. RTLinux), de mindketto melyviz.