RTV forum PL | NewsGroups PL

resetowanie urządzenia USB

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - resetowanie urządzenia USB

Goto page 1, 2, 3  Next

Budyń
Guest

Sun Mar 04, 2018 10:12 am   



nie dowiedziałem sie u linuxiarzy jak w raspberrypi programowo wywołać reset urządzenia usb.
Używam 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.



b.

Jarosław Sokołowski
Guest

Sun Mar 04, 2018 10:17 am   



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

Quote:
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. W przypadku urządzeń
USB warto w różnych stanach poparzeć na wynik "udevadm monitor",
stymulując w tym czasie udeva przez "udevadm controll -R && udevadm
trigger".

--
Jarek

Zbych
Guest

Sun Mar 04, 2018 1:40 pm   



W dniu 04.03.2018 o 13:05, Budyń pisze:
Quote:
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 :/

Zacznij od ustalenia co się wiesza - urządzenie ttyUSB* znika, czy
program komunikacyjny nie może się z nim dogadać? W Linuksie jak otwarte
przez program urządzenie znika to trzeba je zamknąć i ponownie otworzyć
(gdy już będzie dostępne). 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.

Budyń
Guest

Sun Mar 04, 2018 2:05 pm   



W dniu niedziela, 4 marca 2018 10:17:24 UTC+1 użytkownik Jarosław Sokołowski napisał:
Quote:
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.

przekzźnik w sterowniku juz jest i nie jest uzywany

Quote:

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 Smile

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



b.

Jarosław Sokołowski
Guest

Sun Mar 04, 2018 2:22 pm   



Budyń napisał:

Quote:
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

Warto w tym miejscu nadmienić, że przekaźniki nie lubią nieużywania.
A używanie ich z prądami mikroamperowymi na stykach (tak może być
w przypadku tego kontrolera) potrafią potraktować jak obrazę -- styki
muszą mieć minimalny prąd do samooczyszczania. W przypadku 5V USB
niepewny styk może być źródłem kolejnych kłopotów.

Tymczasem zwieranie napięcia to jeden tranzystor i opornik dołączony
do jakiegoś gpio.

Quote:
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?

ftdi_sio zapewne.

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

Można do skryptu resetującego dodać moduł śledczy -- jakieś "ls -l /dev",
"usb-devices", "lsusb" czy co tam jeszcze. A potem przejrzeć co zapisano
do pliku.

Quote:
Tyle ze to mi zawiesza sterowanie ogrzewaniem domu Smile

Wiosna idzie, ciepło się robi.

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

Bo jest "in use" -- to nie jest "wygenerowanie awarii".

--
Jarek

Jarosław Sokołowski
Guest

Sun Mar 04, 2018 2:25 pm   



Pan Zbych napisał:

Quote:
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óś.

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

W tym przypadku najłatwiej po porcie USB, do którego toto podłączono.
A tak przy okazji -- bardzo łatwo sterować (przez /sys/clas/leds)
zapaleniem diod w klawiaturze podłączonej do *konktertnego* portu
USB komputera. W ten sposób, podłączając w miejsce diod przekaźniki,
można sobie zrobić tani element wykonawczy ze złomowych pozostałości
po klawiaturze.

--
Jarek

Adam Wysocki
Guest

Sun Mar 04, 2018 4:20 pm   



Budyń <budynpl.poland_at_gmail.com> wrote:

Quote:
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?

Byle się pasożytniczo z linii danych nie zasilał. FTDI raczej nie
powinien.

Jak się objawia ten zwis? Port szeregowy znika? Coś jest w dmesgu? Czy po
prostu port jest jak był, ale martwy?

Widzę, że to ma FTDI i DS2480B. Pytanie, co się zawiesza (który układ).
Same z siebie nie powinny się zawieszać.

Może DS wchodzi w stan, którego soft nie umie ogarnąć, ale powinien?

--
[ Email: a_at_b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Adam Wysocki
Guest

Sun Mar 04, 2018 4:23 pm   



Jarosław Sokołowski <jaros_at_lasek.waw.pl> wrote:

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

W raspi? Nope, tam jest zasilanie na sztywno z zasilacza.

Co tylko dowodzi, że problem jest w sofcie, bo przy reboocie raspi
zasilanie USB nie znika.

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

usbserial a nie ftdi-sio?

--
[ Email: a_at_b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Adam Wysocki
Guest

Sun Mar 04, 2018 4:26 pm   



Zbych <abuse_at_onet.pl> wrote:

Quote:
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).

Dokładnie tak. Miałem tak ze znikającym portem z ttyACM (ale z FTDI jest
tak samo), szło jakieś EMI, urządzenie na chwilę odpinało się od portu i
wracało już na innym porcie, bo stary nadal był otwarty. Trzeba było
napisać kawałek softu, który tego pilnował.

To by się zgadzało. Objaw byłby taki, jak zwiecha, bo urządzenie będzie
już na nowym porcie... i reboot w ciemno pomoże. Tyle, że odpięcie i
podpięcie przekaźnikiem portu nie pomoże.

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

Powinien przede wszystkim otwierać urządzenie na nowo, jeśli przestanie
się z nim dogadywać lub urządzenie mu zniknie (choć nadal będzie otwarte).

--
[ Email: a_at_b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Adam Wysocki
Guest

Sun Mar 04, 2018 4:27 pm   



Jarosław Sokołowski <jaros_at_lasek.waw.pl> wrote:

Quote:
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ą.

--
[ Email: a_at_b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Zbych
Guest

Sun Mar 04, 2018 8:23 pm   



W dniu 04.03.2018 o 14:25, Jarosław Sokołowski pisze:
Quote:
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.

Zbych
Guest

Sun Mar 04, 2018 8:27 pm   



W dniu 04.03.2018 o 15:27, Adam Wysocki pisze:
Quote:
Jarosław Sokołowski <jaros_at_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ą.

Też nie zawsze się to dzieje. Wyjątkiem są np. drukarki i urządzenie do
których napisaliśmy regułki udev wymuszające inne zachowanie. W takim
przypadku po wypięciu urządzenia również trzeba zamknąć plik i ponownie
go otworzyć, bo na uchwycie do "starego" pliku już nie nawiążemy
komunikacji.

Jarosław Sokołowski
Guest

Sun Mar 04, 2018 9:14 pm   



Pan Zbych napisał:

Quote:
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.

--
Jarek

Zbych
Guest

Sun Mar 04, 2018 9:43 pm   



W dniu 04.03.2018 o 21:14, Jarosław Sokołowski pisze:
Quote:
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.

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.

Mario
Guest

Sun Mar 04, 2018 11:09 pm   



W dniu 04.03.2018 o 10:17, Jarosław Sokołowski pisze:
Quote:
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.

Zapalarka może pomóc.


--
pozdrawiam
MD

Goto page 1, 2, 3  Next

elektroda NewsGroups Forum Index - Elektronika Polska - resetowanie urządzenia USB

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map