Érzek igazságot abban, amit mondasz. Ugyanakkor itt nem az van, hogy a hostra kell írnom egy ismeretlen USB-s eszközhöz valamiféle programot, amely képes parancsot adni, illetve mérési eredményt átvenni az eszköztől, hanem az USB-s eszközt is magam csináltam, így pontosan ismert, mennyi idő az, amíg legfeljebb magába fordulhat. Ha több, az valóban hiba, bár már élesítettem rajta a watchdogot. Amúgy a watchdoggal nem fedek el hibát, előtte sem szállt el a mikrokontrollerben a program, csak szeretem, ha van egy ilyen védelem is.
Visszatérve a felvetésedhez. A libusb_claim_interface() nem fatális hibát mond, nem arról van szó, hogy nincs a kábel végén eszköz, csak azt mondja a host kernele, hogy valaki használja. Erre mondom én a programmal, hogy jó, akkor várjunk picit, aztán bízzunk abban, hogy az eszköz felszabadul. Lényegében ugyanez lenne az eredmény, ha az USB kábelen magától az eszköztől tudnám meg, hogy ő használatban van. Így nem járatom meg a kábelen az infót, hiszen a host kernele is tudja, hogy megszólította az eszközt, válaszra vár, de még nem érkezett az meg.
Persze nagy mértékben igaz az is, hogy a kényelmes, gyors megoldásomban az is benne volt, hogy fogalmam sincs, hogyan tudok kommunikálni egy olyan USB-s eszközzel, amely amúgy foglalt. Ezt jó is volna megértenem, mert valahol ez a projectem célja. Vélelmezem - de nem tudom -, attól, hogy a bulk transferben várakozás van, még control transferben lehet üzenetváltás. Ha ez így van, meg lehet csinálni azt, amit mondasz, s valószínűleg épp a tanulás miatt meg is fogom csinálni.
Az is érdekes, hogy lekérdezem az eszközt, az szabad, majd lehet, mire kommunikálnék vele, addigra busy. Tehát kellene olyasmi, hogy control transferben elküldi a host program például a pid-jét, az eszköz innentől kezdve csak azzal hajlandó kommunikálni, aki ezzel a pid-del azonosította magát. (Itt a pid-en process id-t értek.)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE