nie dowiedziałem sie u linuxiarzy jak w raspberrypi programowo wywołać reset urządzenia usb. Używam tego do pomiaru temperatury
formatting link
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.
Budyń nie dowiedział sie u linuxiarzy jak w raspberrypi programowo wywołać reset urządzenia usb, używa tego do pomiaru temperatury:
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".
W dniu niedziela, 4 marca 2018 10:17:24 UTC+1 użytkownik Jarosław Sokołowski napisał:
przekzźnik w sterowniku juz jest i nie jest uzywany
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
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.
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.
ftdi_sio zapewne.
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.
Wiosna idzie, ciepło się robi.
Bo jest "in use" -- to nie jest "wygenerowanie awarii".
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óś.
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.
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.
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).
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.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.