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

http://www.meraprojekt.com.pl/mp00202.html i zdarza się ze coś
się zwiesi i nie czyta. Fizyczne wyciągnięcie z gniazda i powtórne
włożenie pomaga. Obszedłem problem wywołując reboot całego systemu :/
Mam tam wolny przekaźnik - puściłbym zasilanie tamtędy, czy możnaby
zasilanie +5V wyłączać na chwilę aby urządzenie się zresetowało?

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

W dniu niedziela, 4 marca 2018 10:17:24 UTC+1 użytkownik Jarosław Sokołowski napisał:
Budyń nie dowiedział sie u linuxiarzy jak w raspberrypi programowo
wywołać reset urządzenia usb, używa tego do pomiaru temperatury:

http://www.meraprojekt.com.pl/mp00202.html i zdarza się ze coś
się zwiesi i nie czyta. Fizyczne wyciągnięcie z gniazda i powtórne
włożenie pomaga. Obszedłem problem wywołując reboot całego systemu :/

Budyń nie dowiedział sie u linuxiarzy jak w raspberrypi programowo
wywołać reset urządzenia usb, używa tego do pomiaru temperatury:

http://www.meraprojekt.com.pl/mp00202.html i zdarza się ze coś
się zwiesi i nie czyta. Fizyczne wyciągnięcie z gniazda i powtórne
włożenie pomaga. Obszedłem problem wywołując reboot całego systemu :/
Mam tam wolny przekaźnik - puściłbym zasilanie tamtędy, czy możnaby
zasilanie +5V wyłączać na chwilę aby urządzenie się zresetowało?

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

Jeśli faktycznie *zawiesi się urządzenie USB*, to już trudno z nim
się dogadać przez USB (bo przez co innego?) -- pozostaje tylko
odcięcie zasilania. I tak czasem się robi, gdy nie ma innego wyjścia.
Przekaźnik to spory overkill, tu prąd nie przekracza 100 mA, lepszy
byłby jakis półprzewodnik.

W tym przypadku najpewniej mamy do czynienia z wyżej opisaną sytuacją,
ale nic nie szkodzi, by zbadać sprawę dokładniej i spróbowac innych
sztuczek. Datasheet podaje, że toto komunikuje się z systamem przez
port rs232 wytworzony z USB przez chip FT232RL. Czy w momencie zwiechy
ten port znika? Najpewniej jest to plik /dev/ttyUSB0, o ile udev
inaczej nie postanowił. Można spróbowac usunąć i załadować ponownie
moduł kernela, licząc na to, że diwajs się przy tym jakoś ogarnie
("modprobe -r usbserial" i "modprobe usbserial").

Jeśli faktycznie *zawiesi się urządzenie USB*, to już trudno z nim
się dogadać przez USB (bo przez co innego?) -- pozostaje tylko
odcięcie zasilania. I tak czasem się robi, gdy nie ma innego wyjścia.
Przekaźnik to spory overkill, tu prąd nie przekracza 100 mA, lepszy
byłby jakis półprzewodnik.

przekzźnik w sterowniku juz jest i nie jest uzywany

W tym przypadku najpewniej mamy do czynienia z wyżej opisaną sytuacją,
ale nic nie szkodzi, by zbadać sprawę dokładniej i spróbowac innych
sztuczek. Datasheet podaje, że toto komunikuje się z systamem przez
port rs232 wytworzony z USB przez chip FT232RL. Czy w momencie zwiechy
ten port znika? Najpewniej jest to plik /dev/ttyUSB0, o ile udev
inaczej nie postanowił. Można spróbowac usunąć i załadować ponownie
moduł kernela, licząc na to, że diwajs się przy tym jakoś ogarnie
("modprobe -r usbserial" i "modprobe usbserial").

modprobe próbowałem, ale nie było na pewno usbserial. ftd-costam?

Qurcze, az wywale ten reboot, poczekam az sie zwiesi i zobaczę.

Tyle ze to mi zawiesza sterowanie ogrzewaniem domu

wiec tak:
próbowałem wygenerowac awarię poprzez modprobe -r usbserial
ale dostałem
FATAL: module usbserial is in use

Gdy urządzenie na nowo się pojawia a stare połączenie nie zostało
zamknięte to zostanie użyta nowa nazwa (np. zamiast ttyUSB0 będzie
ttyUSB1).

Program komunikacyjny musi to uwzględniać i zamiast na sztywno
otwierać ttyUSB0, to powinien szukać urządzenia na podstawie VID/PID,
numeru seryjnego itp.

Mam tam wolny przekaźnik - puściłbym zasilanie tamtędy, czy możnaby
zasilanie +5V wyłączać na chwilę aby urządzenie się zresetowało?

Można nawet zwierać na moment do masy linię zasilającą port USB.

moduł kernela, licząc na to, że diwajs się przy tym jakoś ogarnie
("modprobe -r usbserial" i "modprobe usbserial").

Gdy urządzenie na nowo się pojawia a stare połączenie nie zostało
zamknięte to zostanie użyta nowa nazwa (np. zamiast ttyUSB0 będzie
ttyUSB1).

Program komunikacyjny musi to uwzględniać i zamiast na sztywno
otwierać ttyUSB0, to powinien szukać urządzenia na podstawie VID/PID,
numeru seryjnego itp.

To jednak rzadki (niespotykany?) przypadek, by tty faktycznie zniknął,
a plik z diwajsem pozostał. Ale w ogólności uwaga słuszna -- warto tak
to opisać w udev, by diwajs dostawał zawsze alias /dev/OneWire czy cóś.

Pan Zbych napisał:

Gdy urządzenie na nowo się pojawia a stare połączenie nie zostało
zamknięte to zostanie użyta nowa nazwa (np. zamiast ttyUSB0 będzie
ttyUSB1).

To jednak rzadki (niespotykany?) przypadek, by tty faktycznie zniknął,
a plik z diwajsem pozostał. Ale w ogólności uwaga słuszna -- warto tak
to opisać w udev, by diwajs dostawał zawsze alias /dev/OneWire czy cóś.

Jarosław Sokołowski <jaros@lasek.waw.pl> wrote:

To jednak rzadki (niespotykany?) przypadek, by tty faktycznie zniknął,
a plik z diwajsem pozostał. Ale w ogólności uwaga słuszna -- warto tak
to opisać w udev, by diwajs dostawał zawsze alias /dev/OneWire czy cóś.

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

Gdy urządzenie na nowo się pojawia a stare połączenie nie zostało
zamknięte to zostanie użyta nowa nazwa (np. zamiast ttyUSB0 będzie
ttyUSB1).

To jednak rzadki (niespotykany?) przypadek, by tty faktycznie zniknął,
a plik z diwajsem pozostał. Ale w ogólności uwaga słuszna -- warto tak
to opisać w udev, by diwajs dostawał zawsze alias /dev/OneWire czy cóś.

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

Pan Zbych napisał:

Gdy urządzenie na nowo się pojawia a stare połączenie nie zostało
zamknięte to zostanie użyta nowa nazwa (np. zamiast ttyUSB0 będzie
ttyUSB1).

To jednak rzadki (niespotykany?) przypadek, by tty faktycznie zniknął,
a plik z diwajsem pozostał. Ale w ogólności uwaga słuszna -- warto tak
to opisać w udev, by diwajs dostawał zawsze alias /dev/OneWire czy cóś.

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.

Budyń nie dowiedział sie u linuxiarzy jak w raspberrypi programowo
wywołać reset urządzenia usb, używa tego do pomiaru temperatury:

http://www.meraprojekt.com.pl/mp00202.html i zdarza się ze coś
się zwiesi i nie czyta. Fizyczne wyciągnięcie z gniazda i powtórne
włożenie pomaga. Obszedłem problem wywołując reboot całego systemu :/
Mam tam wolny przekaźnik - puściłbym zasilanie tamtędy, czy możnaby
zasilanie +5V wyłączać na chwilę aby urządzenie się zresetowało?

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

Jeśli faktycznie *zawiesi się urządzenie USB*, to już trudno z nim
się dogadać przez USB (bo przez co innego?) -- pozostaje tylko
odcięcie zasilania. I tak czasem się robi, gdy nie ma innego wyjścia.
Przekaźnik to spory overkill, tu prąd nie przekracza 100 mA, lepszy
byłby jakis półprzewodnik. Można nawet zwierać na moment do masy
linię zasilającą port USB.

W tym przypadku najpewniej mamy do czynienia z wyżej opisaną sytuacją,
ale nic nie szkodzi, by zbadać sprawę dokładniej i spróbowac innych
sztuczek. Datasheet podaje, że toto komunikuje się z systamem przez
port rs232 wytworzony z USB przez chip FT232RL. Czy w momencie zwiechy
ten port znika? Najpewniej jest to plik /dev/ttyUSB0, o ile udev
inaczej nie postanowił. Można spróbowac usunąć i załadować ponownie
moduł kernela, licząc na to, że diwajs się przy tym jakoś ogarnie
("modprobe -r usbserial" i "modprobe usbserial").

Z obsługa awarii ogólnie jest ciężka sprawa, bo trudno sytuację
wywołać na żądanie by popatrzeć co się dzieje.