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