Elektroda.pl
Elektroda.pl
X
Elektroda.pl
SterControl
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Komunikacja po USB: PC<-> ok 70 uC

28 Lip 2008 00:38 3427 18
  • Poziom 9  
    Witam.
    Rozpoczynam właśnie swoją przygodę z mikrokontrolerami na 4tym roku studiów i dzięki lekturze eletrody myślę że zgromadziłem trochę praktycznych wskazówek co do jej bezbolesnego przebiegu :).

    Problem jaki sobie stawiam wygląda następująco: komputer komunikuje się za pomocą USB z ok 70cioma urządzeniami opartymi na mikrokotrolerach. Zarówno budowa jak i oprogramowanie urządzeń są/będą moim dziełem a pisanie sterowników pod nie na USB nie uśmiecha mi się szeroko. Stąd pytanie, czy rozwiązanie zaproponowane przez Igora Cesko będzie prawidłowo funkcjonowało przy tak znacznej liczbie wykrywanych urządzeń? W standardzie USB stoi że max to 128 więc z punktu widzenia magistrali mam zielone światło, nie wiem tylko jak zachowywać się będzie cały "system" przy podłączeniu wszystkiego ostatecznie (przez huby oczywiście) do jednego biednego gniazdka USB.

    A może spróbować pójść po najmniejszej linii oporu i zakupić po prostu uC z wbudowanym interfesjem USB. Z tego co udało mi się znaleźć na stronie Atmela to jest tylko kilka rodzin procesorów oferujących taki "bajer" m.in seria '51. Czy to moja nieumiejętność szukania, czy procesory serii atmega nie dają mają takich zapgrejdowanych odmian?

    Ostatecznie, inną opcją komunikacji jest RS485, ale z tego co wyczytałem w dokumentacji, podłączone urządzenie wykrywane jest dopiero po restarcie systemu (domyślnie winda) a w założeniach mam podłączanie "na gorąco".


    Jakieś porady czy przestrogi związane z podjetym problemem?

    pozdrawiam i z góry dzięki za wyrozumiałość.[b]
  • SterControl
  • Pomocny post
    Poziom 38  
    Użyj gotowych układów do tego celu (ft232, pl2303 i pewnie inne).

    CO do usb megi mają tylko w at90USB coś tam...
    Ja bym się w cesko nie pchał, chociaż atmel to teraz niby wspiera;)
    Oprócz tego pic24 mają niektóre usb otg, w sumie prawie każdy procek ma usb otg (każda rodzina).


    Jak robić to do porządku... ft232rl jest piękny i przy takich ilościach dość tani.
  • Poziom 9  
    Dziękuję za szybką odpowiedź :).
    Podany przez Ciebie układ ft232rl rzeczywiście wygląda apetycznie, zarówno pod względem możliwości jak i wartości w PLN :).
    Jeśli dobrze przeanalizowałem możliwe zastosowania z datasheetu to cały program (skomplikowany bardziej niż zaświecenie przykładowego LEDa) realizowany przez urządzenie wrzucam do dowolnego innego mikrokontrolera i po połączeniu go z ft232rl zapuszkowana całość wykrywana jest z poziomu PCa za pomocą swojego unikalnego numeru.
    Jako,że jest to tylkoli konwerter nie można wrzucić w niego "dodatkowych" linijek kodu, prawda?
  • Poziom 38  
    Owszem nie można.:)
    Ale można go używać zarówno jako wirtualnego portu com jak i normalnego urządzenia i dają do niego biblioteki na PC:)
  • Poziom 29  
    Co do USB: można podpiąć do 127 urządzeń. Adres 0 jest zarezerwowany dla enumerowanych urządzeń. Ale z tych 127 musisz odjąć huby, a będzie ich całkiem sporo. Dodatkowym ograniczeniem jest ilość urządzeń połączonych kaskadowo.

    Dajmy na to, że dysponujesz hubami 4-portowymi. Dla 70 urządzeń potrzebujesz połączyć kaskadowo 4 huby, a jako piąte w kaskadzie owe mikrokontrolery. Nie znalazłem w specyfikacji wprost ilości urządzeń kaskadowo, ale na pewno istnieją ograniczenia, zwłaszcza czasowe.

    Możesz jeszcze pomyśleć nad czymś w rodzaju mostka USB<->inny interfejs, a wszystkie mikrokontrolery sprzęgać do tego interfejsu. W mostku zaimplementować enumerację urządzeń na szynie.
  • Poziom 35  
    Chyba właśnie rozsądniej jest zrobić kontroler np. USB<->RS485 i wtedy urządzenia łączysz po jednej/kilku liniach RS485.

    Nie wyobrażam sobie plątaniny kabli/hubów USB. No i zasięg czegoś takiego jest mizerny.

    Pytanie jest dokładnie co to ma być, bo jak np. sieć czujników temperatury czy coś takiego to właśnie rs485 świetnie się nadaje. Budujesz urządzenie które ma z jednej strony USB a z drugiej strony np. 4 wyjścia rs-485 i ciągniesz 4 linie rs-485 w różne strony świata.
    Ewentualna enumeracja urządzenia podpiętego na żywo to nie problem, bo np. co 10 sec. możesz wysyłać pakiety kontrolne sprawdzające podłączone urządzenia.
  • SterControl
  • Poziom 21  
    Jak to ma być zabawka to rób na USB, jak coś profesjonalnego to RS485.
    Na USB ze swojej strony polecam PIC-i - już nawet w rodzinach PIC18 są sprzętowe (!) USB, nie mówiąc o lepszych 16-o i 32-bitowcach. Rozwiązania programowe ( o których pisałeś) od razu sobie odpuść - mizerna prędkość, brak 100% kompatybilności i awaryjność. Z prostych rozwiązań istnieje jeszcze coś takiego jak LIN - rozszerzenie RS232.
    Wadą USB jest jeszcze to, że będziesz musiał napisać sterownik pod Windę - moim zdaniem, przy tak skomplikowanej sieci, którą opisałeś, będzie to najtrudniejszym problemem.
  • Poziom 38  
    Chyba, że weźmiesz ft232 - i masz biblioteki gotowe , tylko napisać własny soft używając ich:)
  • Poziom 21  
    Balu napisał:
    Chyba, że weźmiesz ft232 - i masz biblioteki gotowe , tylko napisać własny soft używając ich:)

    Proponujesz 70*ft232? Powodzenia :)
    Pozostaje nadal problem hubów i kolizji przy tak dużej ilości urządzeń.
    USB już przy jednym urządzeniu technicznym "się gubi" :)
  • Poziom 38  
    Problem hubów owszem, kolizji? Niewydaje mi się, żeby był większy niż przy normalnej takiej ilości urządzeń, właśnie dla tego, że są to układy stricte do tego celu a nie softusb:]
  • Poziom 33  
    70 wirtualnych COM'ów? Nawet nie wiem czy system takie coś obsłuży. Najlepszym rozwiązaniem aby podłączyć tyle urządzeń to kilka magistral RS485 (już takie rozwiązanie padło wyżej). "Porozumieć" się programowo z taką ilością urządzeń będzie napewno łatwiej operując adresami niż otwierając 70 COM'ów (wirtualnych).
  • Poziom 38  
    markosik dla tego proponowałem użycie nie jako wirtualnych comów tylko jako mostów usb -> nóżki :)
  • Poziom 9  
    Cieszę się że temat spotkał się z tak dużym zainteresowaniem ekspertów.
    Myślę,że mogę nieco sprecyzować problem.
    W planie mam podłączenie urządzeń będących terminalami do testowania ( wyświetlacz 2x16 + 10 przycisków -6 na odpowiedzi i 4nawigacyjne) do komputera PC. Sprawa komunikacji po USB jest wg mnie kluczową z powodu możliwości podłączania urządzeń "na gorąco" jak już wcześniej wspomniałem -w przypadku gdy takie urządzenie ulegnie rozłączeniu od magistrali (błąd programu, przekroczenie limitu czasu, fizycznie), lub gdy student się spóźni nie trzeba restartować całego sytemu i tracić danych coby wszystko sklecić do kupy. Niestety rs-485 nie oferuje takiego rozwiązania, więc dla mnie jest na straconej pozycji (choć nie wykluczam możliwości jego użycia).
    Komunikacja wygląda tak:
    komputer rozgłasza numer pytania, student odpowiada, terminale są odpytywane programowo po kolei i zapisywane są odpowiedzi. Istnieje możliwość powrotu do poprzednich pytań, dlatego pod koniec w przypadku gdy odpowiedzi się zmieniły, urządzenie przesyła pełen komplet odpowiedzi do PCta.
    Tak to z grubsza wygląda, pomysł ewoluuje, więc otwarty jestem na poprawki i sugestie.
    Dodam tylko,że pierwotnie samemu chciałem zastosować Rs485 po przeczytaniu artykułu właśnie na elektrodzie o możliwości podłączenia do magistrali do 128 urządzeń, ale niestety odporność takiego układu na czynnik ludzki będzie mniejsza, na co obawiam się, nie mogę sobie pozwolić.
    Zawsze można zastosować huby 7 i 4 wyjściowe -4 wyjściowe na każdej ławce (sala wykładowa) a 7wyjściowe spinające wszystko do kupy. Poza tym rzeczywiście obawiam się deko o czas komunikacji w momencie gdy wystąpią jakieś błędy w transmisji i będzie ona powtarzana, urządzenia na końcu mogą się "nie doczekać",
    Balu, mógłbyś objaśnić ostatniego posta?
    Cytat:
    "markosik dla tego proponowałem użycie nie jako wirtualnych comów tylko jako mostów usb -> nóżki"

    Czyli urządzenia zostają wykryte jako "nowe urządzenie USB" a nie port COM, tak?
  • Pomocny post
    Poziom 33  
    wielkimechatronik napisał:
    ...
    Balu, mógłbyś objaśnić ostatniego posta?


    Też jestem ciekaw jak to "ugryźć" :wink:.

    Tak czy siak urządzenie USB nie może się zgłosić jako nieznane, gdyż system nie będzie wiedział jak się z nim komunikować.
    Co do odporności układu wszystko zależy od algorytmu postępowania, oprogramowania terminala i programu nadrzędnego.

    wielkimechatronik napisał:

    ...Niestety rs-485 nie oferuje takiego rozwiązania, więc dla mnie jest na straconej pozycji (choć nie wykluczam możliwości jego użycia).


    A dlaczego nie oferuje? Jak urządzenie będzie rozłączone to po prostu nie odpowie. Jeżeli trzeba restartować system żeby dane odzyskać (lub je posklejać) to wina leży tylko w źle opracowanych protokołach i algorytmach postępowania "na wypadek problemów".

    wielkimechatronik napisał:

    komputer rozgłasza numer pytania, student odpowiada, terminale są odpytywane programowo po kolei i zapisywane są odpowiedzi


    A tak nawiasem to dużo danych ma być przesłanych między terminalem a komputerem?
    Weź pod uwagę też fakt że wszystkie przemysłowe magistrale w systemach automatyki (gdzie nie ma mowy o restartach czy gubieniu danych) opiera się właśnie na RS485 (PROFIBUS, MODBUS).
  • Pomocny post
    Poziom 21  
    wielkimechatronik napisał:
    Sprawa komunikacji po USB jest wg mnie kluczową z powodu możliwości podłączania urządzeń "na gorąco" (...)

    Jak będziesz podłączał przez wirtualne porty COM to też nie wykryje, bo port cały czas będzie działał. Jeżeli nie chcesz stosować przejściówek to musisz od początku pisać stery pod Windę.
    Następna sprawa to czas rozruchu systemu: instalowanie każdego nietypowego urządzenia na PC to ok. 10-20sek. Przy 70-u zanim system wstanie minie ok. 15 min. Podobna sytuacja będzie miała miejsce w momencie rozłączenia huba. Jak zamierzasz rozpoznawać urządzenia, bo będą one instalowane w przypadkowej kolejności?

    wielkimechatronik napisał:
    (...) w przypadku gdy takie urządzenie ulegnie rozłączeniu od magistrali (błąd programu, przekroczenie limitu czasu, fizycznie), lub gdy student się spóźni nie trzeba restartować całego sytemu i tracić danych coby wszystko sklecić do kupy. Niestety rs-485 nie oferuje takiego rozwiązania, więc dla mnie jest na straconej pozycji (choć nie wykluczam możliwości jego użycia).


    Rozwiązanie jest banalne: co jakiś czas program odpytuje wszystkie adresy - zresztą musi zebrać odpowiedzi od wszystkich urządzeń, jak dostanie od któregoś odpowiedź typu: "Zaczekaj, ale mój student ma kaca i nie nadąża" to ustawia je na koniec kolejki, jeżeli nie dostanie takiej odpowiedzi, to znaczy że urządzenie jest wyłączone.

    wielkimechatronik napisał:

    Dodam tylko,że pierwotnie samemu chciałem zastosować Rs485 po przeczytaniu artykułu właśnie na elektrodzie o możliwości podłączenia do magistrali do 128 urządzeń, ale niestety odporność takiego układu na czynnik ludzki będzie mniejsza, na co obawiam się, nie mogę sobie pozwolić.

    LOL. Cały przemysł stoi na tym standardzie. Pomyśl tylko co by było, gdyby w fabryce Viagry RS485 zaczął szwankować. W RS485 można podłączyć tylko 32 urządzenia! Maksymalne odległości dla RS485 i USB to 1200m i 5m. Kolejny problem to wydajność prądowa USB - tylko 0,5A, a to na pewno nie wystarczy na tyle urządzeń, chcesz większą to prawdopodobnie nie ominie Cię budowa optoizolacji na USB.
    ...Ale jak się uparłeś na USB to proponuję:
    PIC 18F2455/2458/2550/2553 - USB 2.0, do ok. 12 tys linijek kodu programu, 2kB dla danych, pamięć danych EEPROM do zapamiętania numeru urządzenia i konfiguracji, BOOTLOADER przez USB dla szybkiej zmiany kodu programu, 24 linie IO na klawiaturę i wyświetlacz wystarczą, kompletna implementacja USB w mikroPascalu i mikroBasicu (oczywiście w C i ASM też jest, ale te o których napisałem nie wymagają w zasadzie ingerencji i zmian), darmowe próbki z Microchipa, świetnie działające sprzętowe Debugery/Programatory ICD2 (ja mam klona za kilka zł).
  • Poziom 35  
    czlowieku, zrób na CANie :] Sprzętowa detekcja kolizji i ponawianie, sprzętowe 'quasi-adresowanie' (dlaczego quasi - poczytaj w stronie katalogowej protokołu), no i sprzetowe CRC. Pozbędziesz się wielu trudnych do oprogramowania sytuacji na magistrali :]
  • Poziom 11  
    nsvinc napisał:
    czlowieku, zrób na CANie :] Sprzętowa detekcja kolizji i ponawianie, sprzętowe 'quasi-adresowanie' (dlaczego quasi - poczytaj w stronie katalogowej protokołu), no i sprzetowe CRC. Pozbędziesz się wielu trudnych do oprogramowania sytuacji na magistrali :]


    Również uważam, że CAN jest w tej sytuacji najprostszym rozwiązaniem. Nawet nie trzeba odpytywać wszystkich urządzeń. Wystarczy, że każde z nich będzie nadawać ramki z innym ID. Poza tym okablowanie też będzie dużo prostsze (dwa przewody bez żadnych hubów itp.).
    A jako sterownik do PC można zastosować coś takiego: Link
    Producent udostępnia również biblioteki do tego urządzenia więc napisanie własnego softu na PC to żaden problem.
  • Poziom 9  
    Dziękuję za zainteresowanie tematem. Muszę jeszcze zdobyć trochę wiedzy,aby w pełni wykorzystać zawarte tu rady :). Myślę tu przede wszystkim o wspomnianej przez nsvinc i bobryk magistrali CAN, której wcześniej nie brałem pod uwagę, sądząc,że skoro to "prywatny" interfejs Boscha to urządzenia umożliwiające komunikację będą zbyt kosztowne jak na moją kieszeń i ostatecznie kieszeń uczelni.
    Okazuje się jednak,że układ PIC18F4685 posiadający magistralę CAN kosztuje 8$ i są dostępne jego sample,więc nic nie stoi na przeszkodzie coby spróbować :).
    Z drugiej strony obawiam się zbytniego niewykorzystania potencjału magistrali, coby ktoś mi nie powiedział,że strzelam z armaty do wróbli, używając przemysłowej magistrali do przesłania kilkudziesięciu bitów w warunkach domowych niemalże :].
    Apropos opinii do których mogę się odnieść :):
    wd40 napisał:

    Następna sprawa to czas rozruchu systemu: instalowanie każdego nietypowego urządzenia na PC to ok. 10-20sek. Przy 70-u zanim system wstanie minie ok. 15 min. Podobna sytuacja będzie miała miejsce w momencie rozłączenia huba. Jak zamierzasz rozpoznawać urządzenia, bo będą one instalowane w przypadkowej kolejności?
    (...)
    LOL. Cały przemysł stoi na tym standardzie. Pomyśl tylko co by było, gdyby w fabryce Viagry RS485 zaczął szwankować. W RS485 można podłączyć tylko 32 urządzenia! Maksymalne odległości dla RS485 i USB to 1200m i 5m. Kolejny problem to wydajność prądowa USB - tylko 0,5A, a to na pewno nie wystarczy na tyle urządzeń, chcesz większą to prawdopodobnie nie ominie Cię budowa optoizolacji na USB.


    Nie wziąłem rzeczywiście pod uwagę momentu rozpoznawania urządzeń, sądząc,że po zainstalowaniu sterowników i kilkukrotnym wykryciu urządzeń będą one już inicjalizować się znacznie szybciej. Rozpoznawanie urządzeń chciałem rozwiązać na podstawie adresu wyjścia huba o którego podłączone zostanie urządzenie. Wydajność prądową USB można obejść stosując huby z dodatkowym zasilaniem, pełniące rolę repeterów.
    Dziękuję tutaj z kolei Balu za cierpliwe naświetlanie koncepcji komunikacji po USB.
    Z drugiej strony plątanina kabli i hubów rzeczywiście lekko odstrasza od USB i skłania ku przedstawionej przez wd40 RSce, która (dalej upieram się przy swoim zdaniu dla 485) przy zastosowaniu odpowiednich układów udźwignie 128 urządzeń Link -tu jest dowód :)
    , a podłączane terminale byłyby odpytywane programowo i w razie braku odpowiedzi spychane na koniec kolejki..
    Poza tym, przykład fabryki viagry rzeczywiście daje do myślenia :D.
    Jak napisałem na początku muszę powertować jeszcze trochę dokumentacji coby wybrać najlepsze i przy tym najtańsze rozwiązanie.
    Nie zmienia to faktu,że w dalszym ciągu jestem otwarty na dyskusję i nowe pomysły, których nigdy nie za dużo :).
    Pozdrawiam.