logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[At8][C++][FT232RL] połączenie USB z komputerem się zawiesza

JuanD 02 Mar 2012 10:27 3790 18
REKLAMA
  • #1 10622526
    JuanD
    Poziom 9  
    Witam!

    Ponieważ po raz pierwszy nie udało mi się znaleźć odpowiedzi na forum, nadszedł czas na pierwsze pytanie.

    Układ z którym mam problem, jest częścią większego projektu. W uproszczeniu sprawa wygląda tak: At8 podłączona do konwertera USB na bazie FT232 RL (linie Rx, Tx i GND). At8 zasilana z zasilacza. Konwerter zasilany przez USB (zworki pozwalają na taką konfigurację. Na lapku mam program napisany w C++ Builder 6.

    Do AT8 podpięty jest czujnik - impulsator. uC zlicza impulsy z czujnika i po otrzymaniu zapytania z lapka odsyła aktualny wynik. Transmisja szeregowa, w lapku konwerter USB występuje jako wirtualny COM.

    Program na PC ma odpytuje np co 1sek uC, odbiera odpowiedź przelicza jednostki i zapisuje wynik do pliku. Czas odmierzany jest w oddzielnym wątku przez Sleep lub za pomocą komponentu Timer. Procedura odpytywania i zapisywania wyników jest w drugim wątku.

    Niby proste i działa, ale do czasu... Sęk w tym, że program ma chodzić bez przerwy przez 2-3 tygodnie. Tymczasem niby dobrze działający program zawiesza się po 1-5 dniach. Nie widzę żadnej regularności. Wygląda to tak jakby w pewnym momencie program tracił adres do portu COM i nie mógł nic wysyłać.

    Co ciekawe przy zamknięciu programu w którym transmisja się zawiesiła, port COM pozostaje nadal otwarty - zamyka się dopiero po odłączeniu kabla USB. Jeżeli natomiast przerwę "aktywny" pomiar i zakończę program to port zamyka się bez problemu.

    Czy ktoś miał już podobny problem z utrzymaniem połączenia przez USB? Może jest jakaś metoda żeby zmusić komputer do priorytetowego traktowania tego portu?

    Proszę o pomoc.
  • REKLAMA
  • #2 10622561
    mirekk36
    Poziom 42  
    Tak - dokładnie identyczne problemy mają ludzie np podczas korzystania na PC z połączenia COM na virtualnym porcie przy użyciu komponentu COMPort w Delphi. Wiem że ty korzystasz tu z czegoś innego i na dodatek w C++.... no ale opisywane efekty szczególnie jeśli chodzi o tą konieczność rozłączania kabla żeby zresetować połączenie....

    Wiesz co jest przyczyną tych wszystkich problemów z komponentem ComPort ? - nie żaden FT232 - tylko oprogramowanie na PC ... i podejrzewam, że tak samo jest u ciebie tym bardziej, że piszesz że robisz coś w oddzielnym wątku za pomocą Timer. Timer wykorzystuje zdarzenia a nie wątki - tym bardziej coś ci się chyba miesza :(

    Może spróbuj w jakimś C# na gotowych klasach z frameworka do obsługi portów com
  • #3 10622622
    tehaceole

    Poziom 28  
    W jaki sposób się zawiesza? Rzuca jakimś wyjątkiem? Próbowałeś wstawiać ich obsługę? Czy problemem na 100% jest port COM a nie jakaś inna część programu?
  • #4 10623554
    JuanD
    Poziom 9  
    kolego tehaceole:

    Zawiesza się część odpowiedzialna za pomiar. Nie przybywa wyników, zatrzymuje się licznik mierzący czas, który upłynął od rozpoczęcia pomiaru, co oznacza że stoi cały wątek odpytujący urządzenie. Działają natomiast wszystkie przyciski nie związane z komunikacją z uC. Nie rzuca żadnym wątkiem. Wszystko niby ok, ale cisza.

    Nie wiem, czy na 100% to port COM. Ale w efekcie na pewno tracę do niego dostęp.



    kolego mirekk36:
    Cytat:
    Może spróbuj w jakimś C# na gotowych klasach z frameworka do obsługi portów com


    Spróbuję przez weekend. Zobaczymy co z tego wyjdzie ;)

    Cytat:
    Wiesz co jest przyczyną tych wszystkich problemów z komponentem ComPort ? - nie żaden FT232 - tylko oprogramowanie na PC ... i podejrzewam, że tak samo jest u ciebie tym bardziej, że piszesz że robisz coś w oddzielnym wątku za pomocą Timer. Timer wykorzystuje zdarzenia a nie wątki - tym bardziej coś ci się chyba miesza Sad


    W programie zdefiniowałem 2 wątki, które są uruchamiane po wybraniu opcji "start pomiaru". Jeden wątek odmierza odstępy czasu i ustawia jakąś zmienną. Drugi wątek czeka na tą zmienną, jak ją wykryje uruchamia procedurę komunikacji.

    [/quote]
  • Pomocny post
    #5 10623572
    tehaceole

    Poziom 28  
    Czy w wątku obsługi każdorazowo:
    - otwierasz port (sprawdzając oczywiście czy nie jest już otwarty)
    - przesyłasz zapytanie
    - odczytujesz zwrot z ukontrolera
    - zamykasz port
    ?
    Miałem podobny do Twojego przypadek, gdy nie zamykałem portu po każdej tego typu transmisji. Program niby działał ok ale co jakiś czas się wykrzaczał.
  • REKLAMA
  • #6 10624332
    JuanD
    Poziom 9  
    Port otwieram tylko raz na początku i zamykam po zakończeniu wszystkich pomiarów. Zaraz skompiluje z każdorazowym zamykaniem i otwieraniem. Poczekam co z tego wyjdzie.
  • #7 10633417
    carek49
    Poziom 13  
    Stawiam na soft. Miałem podobny problem - zobacz sobie jak wygląda zużycie pamięci przez twój sofcik. Jeśli pamięć przydzielona do procesu cały czas rośnie to masz problem (zweryfikujesz to szybko w menedżerze zadań) ;) u mnie na przemian zmieniałem cyklicznie ikonkę w trayu i w pewnym momencie była zwiecha (po kilku dniach).

    Okazało się, że nie zwalniałem w odpowiedni sposób zasobów po przeładowaniu nowej ikony do traya.
  • REKLAMA
  • #8 10644703
    JuanD
    Poziom 9  
    Wprowadziłem kilka sugerowanych zmian.

    Zgodnie z radą kolegi tehaceole wprowadziłem otwieranie i zamykanie portu w każdym cyklu pomiarowym. Nie pomogło.

    Zgodnie z zaleceniami kolegi carek49 sprawdziłem ilość zajmowanej pamięci. Odchudziłem kod - wywaliłem m.in. z formy wykres, na którym były prezentowane wszystkie wyniki. Po uruchomieniu programu ilość zajmowanej pamięci się nie zmienia, jest tylko lekki skok przy zapisywaniu wyników na dysk co 5 pomiarów.
    Pomiar wciąż się zawiesza.

    Proces po uruchomieniu wykorzystuje ok 38% procka i 2332 K, po w chwili zawieszenia mam 50% i 2348 K.

    Nie rozumiem dlaczego gdy po zawieszeniu się pomiarów zamykam program port wciąż pozostaje otwarty. Do przycisku zamknij mam kod:

    Kod: text
    Zaloguj się, aby zobaczyć kod


    I wszystko się pięknie zamyka dopóki pomiar się nie zawiesi.Cry...
  • #9 10645001
    hotdog
    Poziom 26  
    Ja uważam że problem może być sprzętowy.

    Sam kiedyś czegoś takiego doświadczyłem.

    Pokaż schemat...

    Masę złącza USB gdzie masz podłączoną?

    W pewnych wypadkach zakłócenia mogą przenosić się po przewodzie na sterownik USB host na komputerze. Wtedy pomaga tylko podłączenie i odłączenie kabla. U mnie podłączenie odpowiednio masy i zastosowanie dobrej jakości krótkiego kabla problem rozwiązało.

    Zabicie procesu powinno pozwolić na ponowne otworzenie portu szeregowego, więc nie szukał bym problemu po stronie programu.
  • #10 10645368
    JuanD
    Poziom 9  
    To jest odręczny schemat.

    [At8][C++][FT232RL] połączenie USB z komputerem się zawiesza

    Korzystam z konwertera na bazie FT232:
    [At8][C++][FT232RL] połączenie USB z komputerem się zawiesza
  • REKLAMA
  • #11 10645838
    hotdog
    Poziom 26  
    brakuje schematu tego konwertera.

    Sprawdź multimetrem, lub wzrokowo do czego podłączony jest ekran złącza USB.

    Powinien być do GND.

    Pozdrawiam
  • #12 10646113
    JuanD
    Poziom 9  
    schematu konwertera też nie mam. Tu jest link do sklepu:
    Link

    Na oko ciężko powiedzieć gdzie jest podłączony, bo druk jest wielowarstwowy. Między obudową gniazda a pinem GND mam w każdym razie 0V.
  • #13 10646431
    mirekk36
    Poziom 42  
    Nie ma co się doszukiwać błędu w takiej przejściówce - wszystkiemu winny jest ewidentnie soft na PC. Jak mówiłem identyczne zachowanie jest przy obsłudze podobnego komponentu w Delphi (ComPort) .... Dopiero jak zrobiłem sobie na wątkach wszystko po swojemu to problemy skończyły się raz na zawsze. Tyle że ciężko mi coś tu podpowiedzieć bo nie znam na tyle C# czy C++ na PC. Za to wiem, że nie ma co iść w stronę błędu w sprzęcie bo to doprowadzi tylko do straty czasu.
  • Pomocny post
    #14 10647036
    hotdog
    Poziom 26  
    JuanD napisał:
    schematu konwertera też nie mam. Tu jest link do sklepu:
    LinkNa oko ciężko powiedzieć gdzie jest podłączony, bo druk jest wielowarstwowy. Między obudową gniazda a pinem GND mam w każdym razie 0V.

    Zmierz rezystancję miedzy GND a obudową gniazda. Jeżeli jest przejście (bliskie 0Ohm) to znaczy że jest ok. Jedyne co jeszcze można wtedy zrobić to zastosować jak najkrótszy i jak najlepszej jakości kabel USB.

    mirekk36 napisał:
    Nie ma co się doszukiwać błędu w takiej przejściówce - wszystkiemu winny jest ewidentnie soft na PC. Jak mówiłem identyczne zachowanie jest przy obsłudze podobnego komponentu w Delphi (ComPort) .... Dopiero jak zrobiłem sobie na wątkach wszystko po swojemu to problemy skończyły się raz na zawsze. Tyle że ciężko mi coś tu podpowiedzieć bo nie znam na tyle C# czy C++ na PC. Za to wiem, że nie ma co iść w stronę błędu w sprzęcie bo to doprowadzi tylko do straty czasu.

    Wiem co piszę, bo piszę z własnego doświadczenia. Moim zdaniem warto wyeliminować wszystkie zmienne, a nie na wyczucie być pewnym że to przez program. Oczywiście sam tej możliwości nie wykluczam, jednak sprawdzenie mojej teorii to kilka chwil.

    Zauważ że autor nie może otworzyć portu po zakończeniu zawieszonej aplikacji. Nie wiem jak w C++, ale w C# po takiej zawieszce można normalnie port otworzyć. Zresztą prosty test niech autor zakończy aplikację z otwartym portem w menedżerze zadań. Jak będzie mógł podłączyć się do portu po otworzeniu na nowo aplikacji, to błąd programu jest mało prawdopodobny. Jeżeli natomiast jest inaczej, to wtedy jest bardziej prawdopodobny.

    Pozdrawiam
  • #15 10647549
    mirekk36
    Poziom 42  
    hotdog napisał:

    Zauważ że autor nie może otworzyć portu po zakończeniu zawieszonej aplikacji. Nie wiem jak w C++, ale w C# po takiej zawieszce można normalnie port otworzyć.


    Nie mam najmniejszego zamiaru się tu z tobą kłócić czy spierać. Ty wyrażasz swoje zdanie a ja swoje i to wszystko. To po pierwsze.

    A po drugie to przepraszam ale jak na tak ogólnym poziomie można porównywać jakieś zawieszenia i to pomiędzy frameworkiem C# a gołym C++ bazującym na API. Przecież nieumiejętne posługiwanie się wątkami może w 5 sekund załatwić takie efekty i ja np głowę za to daję - że z tym autor ma problem a nie z tym czy obudowa jest na potencjale masy czy nie - tu nawet w ogóle nie upatrywałbym żadnej przyczyny bo mowa byłaby o całkiem innej warstwie na której problem występuje i dotyczyłoby to każdego języków czy C++ czy C# czy Delphi.....

    A problem z niemożliwością otwarcia portu po takim opisywanym zawieszeniu zwykle bierze się z jednego i to też można sobie sprawdzić, nie trzeba nawet wiele cudować. Jeśli kolejna instancja aplikacji nie może go otworzyć to warto sprawdzić czy nie jest już otwarty - a na pewno dostanie się komunikat że jest otwarty ?

    Dlaczego? ano dlatego że wątek z poprzedniej aplikacji zapodział się w systemie jako samotny mohikanin. Można sprawdzić w menadżerze urządzeń nawet czy nie istnieje przypadkiem nawet cały proces exe odpalony i nie zakończony - tyle że już niewidoczny. Zabicie go z tego poziomu zwykle po chwili przyniesie oczekiwany skutek, że port zostanie zwolniony i już będzie się można z nim komunikować z innej aplikacji.....
  • #16 10647940
    hotdog
    Poziom 26  
    wątek nie może się zabłądzić, jak aplikacja jest zabita... Proces zabity - wszystkie wątki zabite, zasoby zwolnione...

    Ja swoje zdanie wyraziłem, dalej je podtrzymuje... Ty wróżysz że kolega nie umie programować, ja miałem podobny problem i wiem co go rozwiązało. Zawieszało się to nawet na zarządzalnym C# :)

    Podobny temat:
    https://www.elektroda.pl/rtvforum/topic1702671.html

    Ja w swoim urządzeniu miałem przekaźniki sterowane z PC. Podłączenie przez FT232RL + avr + uln2803. Przekaźniki zasilane z USB. Wszystko działało pięknie bez podłączonego obciążenia. Po podłączeniu do przekaźników 230V (żarówka 60W), zakłócenia indukcyjne szły powietrzem, trafiały na antenę jaką był oplot kabla USB. I zawieszały sterownik host na płycie głównej. Pomagało tylko wypięcie tyczki. Problem ręką odjął po podłączeniu masy do ekranu gniazda USB. Problem od tej pory pojawił się mi tylko na kilku komputerach wbudowanych.
  • #17 10648951
    mirekk36
    Poziom 42  
    hotdog napisał:
    wątek nie może się zabłądzić, jak aplikacja jest zabita... Proces zabity - wszystkie wątki zabite, zasoby zwolnione...


    No to właśnie to samo powiedziałem - że zamknięcie programu i zniknięcie głównej formatki z ekranu nie zawsze musi się równać zniknięciu procesu, bo jakiś wątek trzyma, i dlatego pisałem o menadżerze - żeby tą drogą go zabić - wtedy rzeczywiście zniknie - no nie tak pisałem ?

    hotdog napisał:
    Ja swoje zdanie wyraziłem, dalej je podtrzymuje... Ty wróżysz że kolega nie umie programować, ja miałem podobny problem i wiem co go rozwiązało. Zawieszało się to nawet na zarządzalnym C# :)


    Powiem na spokojnie tak (bo jeszcze raz podkreślam nie szukam żadnej sprzeczki z tobą) .... ja wróżę swoje a ty swoje i dobrze - na końcu pewnie się okaże co było przyczyną. A ja wcale nie twierdzę na 100% że winą nie będzie jakiś problem sprzętowy na takiej przejściówce..... A już na pewno nie wmawiam nikomu że nie umie programować - to raczej (sorki ale już twoje zaczepne trochę fantasmagorie) ..... Po prostu stawiam na błąd w programie i tyle, więc i ty dyskutuj a nie kłóć się ok ?
  • #18 10649101
    hotdog
    Poziom 26  
    Patrząc z tej strony możesz mieć rację. Jeżeli wg autora "zamknięcie" to kliknięcie na "X" to może być tak jak mówisz. Dla mnie zamknięcie to "kill" lub brak procesu w menedżerze :) Zakładam, że jak ktoś się bierze za aplikację wielowątkowe, to ma o takich rzeczach pojęcie.

    Sorry, rzeczywiście nie potrzebnie się czepiam ;p

    Peace
  • #19 10695157
    JuanD
    Poziom 9  
    Działa!

    Trochę czasu było potrzebne żeby to sprawdzić, ale teraz już wiem, że działa!

    Problemy zniknęły po połączeniu obudowy gniazda USB z GND.

    Kolego hotdog, dzięki za podsunięcie tego rozwiązania. Szukanie błędu w "handlowym" konwerterze to jedna z ostatnich rzeczy jakie przyszły by mi do głowy. Klikam zasłużone pomógł.

    Dziękuję również tehaceole za udostępnienie własnych kodów do działających aplikacji. Dzięki nim mogłem się upewnić, że problem leżał po stronie sprzętowej.

    Dzięki za wszystkie porady i twórczą dyskusję. Temat zamykam.
REKLAMA