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.

do góry

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

do góry

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

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



b.

do góry

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

do góry

Budyń napisał:

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

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

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

> Tyle ze to mi zawiesza sterowanie ogrzewaniem domu :)

Wiosna idzie, ciepło się robi.

> 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

do góry

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

> 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

do góry

Budyń <b...@g...com> wrote:

> 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@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

Jarosław Sokołowski <j...@l...waw.pl> wrote:

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

> 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@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

Zbych <a...@o...pl> wrote:

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

> 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@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

Jarosław Sokołowski <j...@l...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ą.

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

do góry