Jak programowo zresetować urządzenie USB w Raspberry Pi dla czujnika temperatury?

Jakies inne opcje? Albo jakas znana metoda resetu programowego? To
widzia
łbym najchętniej.

To jest normalny przypadek, potrafię go wywołać na zawołanie. Usunięte
pliki w uniksach znikają po zamknięciu ostatniego uchwytu.

Dobrze wiem jak jest w uniksach, chodziło mi o konkretny plik /dev/*
i tak gapowaty program z nim współpółpracujący, że się nie połapie
gdy mu partner do rozmowy zemrze.

Gapowate w tym przypadku jest zachowanie funkcji write i read, które
nie zwracają kodów błędów gdy próbujemy pisać/czytać ze "znikniętego"
urządzenia.

Pan Zbych napisał:

To jest normalny przypadek, potrafię go wywołać na zawołanie. Usunięte
pliki w uniksach znikają po zamknięciu ostatniego uchwytu.

Dobrze wiem jak jest w uniksach, chodziło mi o konkretny plik /dev/*
i tak gapowaty program z nim współpółpracujący, że się nie połapie
gdy mu partner do rozmowy zemrze.

Gapowate w tym przypadku jest zachowanie funkcji write i read, które
nie zwracają kodów błędów gdy próbujemy pisać/czytać ze "znikniętego"
urządzenia.

Funkcje write i read nie są gapowate, robia dobrze to, co do nich należy.

To jest normalny przypadek, potrafię go wywołać na zawołanie.
Usunięte pliki w uniksach znikają po zamknięciu ostatniego uchwytu.

Dobrze wiem jak jest w uniksach, chodziło mi o konkretny plik /dev/*
i tak gapowaty program z nim współpółpracujący, że się nie połapie
gdy mu partner do rozmowy zemrze.

Gapowate w tym przypadku jest zachowanie funkcji write i read, które
nie zwracają kodów błędów gdy próbujemy pisać/czytać ze "znikniętego"
urządzenia.

Funkcje write i read nie są gapowate, robia dobrze to, co do nich należy.

Pisanie do nieistniejących urządzeń bez sygnalizacji błędów? Chyba mamy
inną definicję poprawności.

Pan Zbych napisał:

Gapowate w tym przypadku jest zachowanie funkcji write i read, które
nie zwracają kodów błędów gdy próbujemy pisać/czytać ze "znikniętego"
urządzenia.

Funkcje write i read nie są gapowate, robia dobrze to, co do nich należy.

Pisanie do nieistniejących urządzeń bez sygnalizacji błędów? Chyba mamy
inną definicję poprawności.

Chyba. W każdym razie jest to najbardziej prawdopodobne wyjaśnienie.

On Sun, 4 Mar 2018 00:12:39 -0800 (PST),
Budyń wrote:
Jakies inne opcje? Albo jakas znana metoda resetu programowego? To
widzia
łbym najchętniej.

Jedynie możesz przeładować moduły uhci/ohci, ale to nie zawsze
pomaga. To jest faktycznie problematyczne, bo czegoś takiego jak
programowy reset USB faktycznie nie ma.

Zbych <abuse@onet.pl> wrote:

Z manuala funkcji read i write:
On error, -1 is returned, and errno is set appropriately.

I tego wspomniane funkcje read/write nie robią jeśli urządzenie zniknie.

Spodziewałbym się EIO. Ciekawe, czemu tak się nie dzieje (nie sprawdzałem,
bo teraz nie mam jak, ale wierzę).

I tego wspomniane funkcje read/write nie robią jeśli urządzenie
zniknie.

Plik urządzenia znika, ale nadal jest otwarty przez program. Przez to
nowy pojawia się pod inną nazwą.

Też nie zawsze się to dzieje.

To jest normalny przypadek, potrafię go wywołać na zawołanie. Usunięte
pliki w uniksach znikają po zamknięciu ostatniego uchwytu.

Z manuala funkcji read i write:
On error, -1 is returned, and errno is set appropriately.

I tego wspomniane funkcje read/write nie robią jeśli urządzenie zniknie.

Ja zazwyczaj używam IO w wersji nieblokującej (O_NONBLOCK), z ciekawości
muszę sprawdzić czy bez tej flagi też jest problem z sygnalizacją błędów.

Zapalarka może pomóc.

Zbych <abuse@onet.pl> wrote:

Ja zazwyczaj używam IO w wersji nieblokującej (O_NONBLOCK), z ciekawości
muszę sprawdzić czy bez tej flagi też jest problem z sygnalizacją błędów.

W sumie nie powinno to nic zmieniać. Spodziewałbym się, że po odpięciu
urządzenia select() zwróci odczytywalność, a read() zwróci 0 (ale nie
sprawdzałem).

Tak się składa, że mam teraz na tapecie program, który gada z ttyACM
(moduł cdc_acm) blokującym I/O (naprzemiennie pisze do portu i czeka na
odpowiedź). Po odpięciu kabelka blokujący read() zwrócił 0 (EOF), a
późniejszy tcdrain (wywołujący ioctl TCSBRK) -1 (errno = EIO).

Dodatkowy test pokazał, że gdy read() zwróci EOF, to kolejny read()
również zwraca EOF, ale kolejny write() zwraca -1 z errno = EIO. Kołacze
mi się po głowie, że w przypadku socketów zachowanie read() było inne (gdy
zwrócił EOF, to kolejny read() zwracał błąd), ale głowy za to uciąć nie
dam -- może mi się coś przywidziało.

Nie wiem czy cokolwiek zmienia fakt, że urządzenie nie jest podłączone
bezpośrednio, tylko przez "przejęcie" portu w VirtualBox (ten Linux chodzi
w wirtualce na Windows 7). Niby nie powinien.

2. read w trybie blokującym czeka na dane, jak wypnę w trakcie czekania
wtyczkę to przerywa czekanie zwracając 0, czego nie traktuję jako błąd.
Kolejne wywoływania read zwracają cały czas 0

Problem polega na tym, że mam urządzenia z który tylko czytam dane
(skanery, klawiatury) i takie zachowanie read jest delikatnie mówiąc
irytujące.