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

Jednoprzewodowy system komunikacji jednokierunkowej - co wybrać.

piotrva 07 Lis 2011 00:04 3105 23
REKLAMA
  • #1 10111432
    piotrva
    VIP Zasłużony dla elektroda
    Witam Kolegów.
    Zbudowałem dalmierz do robota jako moduł. Sercem sonaru jest attiny13 (może być też tiny85) ale mam dylemat co do komunikacji jednokierunkowej ze sterownikiem. Obecnie mam 3 pomysły:
    a. 1wire - fajny, możliwość podpięcia innych modułów, ale tryb slave rozbudowany w implementacji i brak gotowców
    b. Uart tx programowy - stosunkowo prostszy niż 1w, ale też po stronie mastera trzeba zaimplementować programowo (sprzetowy uart zajęty)
    c. Wyjście typu PWM - banalna implementacja, ale wolalbym coś w 100% cyfrowego z korekcją błędów, które tu czasem się pojawiają i utratę dokładności względem rzeczywistego całkiem dokładnego pomiaru.
    I tu moje pytanie. Jakie są inne ciekawe i łatwe oraz mało pamięciożerne interfejsy, lub ew. czy ktoś ma jakiś ciekawy pomysł na realizację takiej transmisji.
  • REKLAMA
  • Pomocny post
    #2 10111583
    MirekCz
    Poziom 35  
    PWM jest w 100% cyfrowy (o ile nie zamieniasz go potem filtrem na sygnał analogowy), prosty w implementacji (po stronie slave tylko PWM, po stronie Master jedno przerwanie).
    Gorzej z korekcją błędów, ale w sumie co tu korygować - to tylko jedno przejście z "0" do "1" i z "1" do "0".
    Mógłbyś zrobić prostą "korekcję" na zasadzie:
    1.Puścić sygnał PWM o małym wypełnieniu (np. 5 lub 10%) - swoisty bit startu
    2.Następnie puścić trzy PWM o wypełnieniu równym faktycznemu pomiarowi w zakresie 20-100% (żeby nie pomylić z bitem startu).

    Po stronie mastera czekasz na bit startu (pwm ~5% lub 10%) a następnie czytasz trzy kolejne PWM i jeżeli są one równe +/- jakiś mały przedział typu 0,1% to masz prawidłowy pomiar. Jak nie to czekasz na następny.
    W ten sposób SLAVE może też pokazać pomiar nieprawidłowy (np. wysłać trzy razy wynik 10%, albo wręcz trzy razy zupełnie inny wynik typu 20,50,80% - master będzie wiedział, że to błędny pomiar).

    Taka implementacja jest dużo prostsza i mniej obciąży CPU niż jakieś 1wire z dokładnymi timingami itd. a dodatkowo jest mniej podatna na zakłócenia.
  • #3 10111747
    piotrva
    VIP Zasłużony dla elektroda
    Cóż, obecnie właśnie chodzi to na PWM, a pisząc cyfrowy miałem na myśli bardziej złożony. Pomysł z ramkami startu raczej na niewiele się zda - teraz też mogę odczytać n kolejnych wyników i odrzucać błędne. Mimo wszystko szukalbym czegoś niezależnego bezpośrednio od pomiaru czasu.
  • Pomocny post
    #4 10112104
    nsvinc
    Poziom 35  
    Dysponuję autorskim protokołem transmisji danych przez pojedynczy kabel. Szybki, niezawodny, odporny na zakłócenia.
    Wymaga jednego timera z jednym kanałem capture i jednym kanałem match. Oczywiscie mozna to zrobić po prostu na przerwaniach programowo, ale wtedy osiągane prędkości są raczej nie... imponujące. Protokół jest zasobożerny, lecz implementuje kontrolę transmisji i CRC. W wersji którą mogę udostępnić nie ma arbitrażu ani ACKów.

    Wadą jest, że został on stworzony na ARMy i tylko na ARMy jest implementowany (na dsPIC33 w planach), więc AVR może sobie po prostu nie poradzić z "prędkościami", i obslugiwac transmisje tylko rzędu 500 bitów na sekundę...
  • Pomocny post
    #5 10112581
    Jado_one
    Poziom 22  
    Może spróbuj transmisji protokołem podobnym do tych jakie są używane w pilotach IR?... (jest kilka rodzajów). Ilość bitów w ramce, ilość bajtów w pakiecie i CRC możesz sobie ustalić sam (niezależnie od standardów jakie są proponowane w IR) - w zależności od potrzeb.
    Ale tak czy inaczej musisz dokonywać samplowania PIN'u w określonej jednostce czasu - w końcu to transmisja szeregowa :-)
  • REKLAMA
  • #7 10112647
    kriss68
    Poziom 20  
    A może skorzystaj z jednej linii rs'a albo coś jak S/PDIF albo standard NEC'a w pilotach
  • #8 10112656
    Jado_one
    Poziom 22  
    Zdaje się, że trochę inaczej rozumiemy słowo samplowanie :-)
    Nie musi być programowe - można uzyć Timera czy przerwania...wazne, żeby w określonej jednostce czasu móc stwierdzić stan logiczny na określonym przez nas pinie (lub ilość impulsów jakie zdąży zliczyć licznik przez czas trwania danego stanu logicznego na interesujacym nas pinie).
    Zeby sie uniezaleznic od pomiaru czasu (od strony odbiornika transmisji) musiałbyś miec conajmniej dwie linie - clock i data.
  • Pomocny post
    #9 10112813
    kriss68
    Poziom 20  
    Ja bym wykorzystał jedną linię rs'a jeśli dane będziesz przesyłał na nie zbyt dużej odległości albo coś jak standard NEC'a w pilotach Link wtedy ustalasz sobie czas trwania dla preambuły, dla "1" i dla "0" a żeby to zdekodować używasz w AVR icp jednego z timerów i mierzysz czas między poszczególnymi zboczami narastającymi i na jego podstawie decydujesz czy odebrałeś właśnie preambułę albo "1" lub "0"
  • Pomocny post
    #10 10112919
    mirekk36
    Poziom 42  
    Tak, ja też uważam że skorzystanie ze sposobu stosowanego w pilotach (oczywiście bez generowania nośnej) .... to dobry pomysł. Prędkości można uzyskać o wiele wiele większe, a zorganizowanie odbioru na przerwaniu ICP jakiegoś timera sprzętowego da bardzo dobry efekt. I będzie to jakaś alternatywa dla 1wire ;) sam niedługo będę musiał nad takim rozwiązaniem pomyśleć i przetestować.
  • #11 10112959
    piotrva
    VIP Zasłużony dla elektroda
    1. Do rozważenia dodaję pochodną standardów pilotowych - może nawet wystarczy kodowanie manchester.
    2. Zainteresował mnie protokół kół. Nsvic - czy można prosić o jakieś szczegóły?
    3. Dodam że transmitowana będzie 1 zmienna 16bit z częstotliwością kilkudziesięciu hercy.
  • #12 10112997
    kriss68
    Poziom 20  
    Wydaję mi się, że łatwiej od manchestera będzie zdekodować kod w którym 1 i 0 mają różny czas trwania. A to jak długa będzie ramka danych zależy już tylko od Ciebie :) Można to zrobić na AVR np tak:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
    W tym kodzie założone jest, że time_0<time_t<time_preamble można też sprawdzić czy czas nie jest za mały żeby omyłkowo nie zdekodować 0
    A potem zapisujemy tylko to co dostajemy:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    To taka najprostsza wersja którą można jeszcze spokojnie ulepszyć dla zwiększenia pewności transmisji.
  • #13 10113925
    piotrva
    VIP Zasłużony dla elektroda
    Kody nie potrzebne jak dla mnie bo sam sobie dałbym rady. W każdym razie dzięki za podpowiedzi. Na razie trochę u mnie krucho z czasem ale będę powoli nad tym pracować i zobaczę co dam rady upchnąć do tiny13. Czekam jeszcze na wypowiedź kol. Nsvic.
  • REKLAMA
  • Pomocny post
    #14 10115676
    nsvinc
    Poziom 35  
    TEORIA
    cały bajer polega na tym, aby teoretycznie zwykłego PWMa odpowiednio enkodować, celem uzyskania własności 1 zbocze = 1 bit. Bittime to konkretny wycinek czasu - jeśli zbocze wystąpi w pierwszej połówce bittime'a, to wartośc bitu wynosi 0, jeśli w drugiej - bit wynosi 1.
    Zachodzi wtedy następująca zależność, łatwo dekodowalna przez mikrokontroler:
    - jeśli między zboczami minął czas 1BT, to bierzący bit == poprzedni bit
    - jeśli między zboczami minęło 0.5BT, to poprzednio była 1, a teraz jest 0
    - jeśli między zboczami minęło 1.5BT, to poprzednio było 0, a teraz jest 1
    - każda inna konfiguracja czasów jest niedozwolona i wskazuje na błąd tx-a lub kolizję.

    STANY
    Linia transmisyjna jest podciągana do jakiegoś plusa rezystorem o dobranej wartości (nieźle sprawdza się 4k7), i ten plus jest stanem spoczynkowym, i recesywnym. Linia jest ściągana otwartym drenem/kolektorem do masy, wymuszając stan dominujący.
    Wiemy, ze na takiej linii zbocze narastające będzie trwalo znacznie dłużej niż zbocze opadające. Więc każdy stan wysoki będzie trochę krótszy niż stan niski - na to jest brana poprawka na podstawie pomiaru czasów w trakcie trwania preambuły. Dzięki temu nawet na bardzo długim kablu można popychać te kilkadziesiąt kbps.

    PREAMBUŁA
    przed nadaniem payloadu wysyła się preambułę jak na rysunku. Dzięki temu rx wie, ile wynosi 1BT a dodatkowo, mierzy czas trwania stanu niskiego i stanu wysokiego.

    Jednoprzewodowy system komunikacji jednokierunkowej - co wybrać.

    FICZERY
    Na jednej linii transmisyjnej mogą ze sobą rozmawiać urządzenia, które nadają z różnymi prędkościami. Wykorzystując efekt stanu dominującego, możliwa jest implementacja arbitrażu według następujących wytycznych:
    - wolniejszy tx ma priorytet nad szybszym, już na etapie preambuły, gdyż jego pierwszy stan dominujący będzie trwał dłużej, niż w przypadku szybszego tx-a
    - gdy w dowolnym momencie transmisji linia trwa w stanie dominującym, mimo tego, że "bierzący" tx go nie wystawia, znaczy, że "bierzący" tx przegrał arbitraż
    - po wysłaniu ostatniego bitu mozliwa jest implementacja ack-slota w postaci 1BT stanu recesywnego, który wszystkie rx-y mają nadpisać stanem dominującym.
  • REKLAMA
  • Pomocny post
    #15 10115703
    Urgon
    Poziom 38  
    AVE...

    Trochę to skomplikowane, Nsvinc. Ja bym to zrobił inaczej...
    Nadajnik generuje sygnał PWM do kodowania danych. W pierwszym cyklu sygnał PWM ma wypełnienie 50% i służy do skalibrowania modułu Capture/Compare w odbiorniku oraz wywołania przerwania do obsługi transmisji. W kolejnych cyklach PWM jest ustawiany na 25% dla zera i 75% dla 1. Transmisję kończy cykl 50%. W ten sposób nadajnik może mieć dowolną prędkość pracy PWM, o ile będzie ona mniejsza od maksymalnej prędkości, z jaką program może odczytać licznik modułu Capture/Compare, zresetować go i przygotować do kolejnego pomiaru oraz przeliczyć odebraną wartość na zera lub jedynki i wpisać do zmiennej...
  • #16 10115722
    nsvinc
    Poziom 35  
    Niestety wtedy nie jest utrzymana zasada 1 zbocze - 1 bit. Masz częsciej zbocza, z czego co bit tracisz jedno zbocze "dla zartu", nie niesie ono zadnych informacji.
    A w tym przypadku liczy się ilość zbocz na jednostkę czasu, które można popchnąć kablem - w szczególności ilość zbocz narastających. Więc twoje rozwiązanie będzie generowało więcej zakłóceń, i przy tej samej prędkości będzie chodzić na krótszym kablu...

    A dodatkowo, wspomnę, że wykorzystanie nawet zwykłych transceiverów różnicowych (np. do RS485), pozwala z odpowiednio szybkim mikrokontrolerem uzyskać kilka..kilkanaście Mbps po bardzo długich kablach. Wykorzystując mały CPLD prędkości najpewniej byłyby jeszcze bardziej imponujące...
  • #17 10115754
    Urgon
    Poziom 38  
    AVE...

    W tym przypadku raczej długość przewodu nie ma znaczenia. Ponadto zapominasz o tym, iż przewody mają indukcyjności i pojemności pasożytnicze, co przy dużych prędkościach może sprawić, iż zanim zbocze zejdzie poniżej progu wykrywania zbocza opadającego w odbiorniku, a już może narastać, choć po stronie nadajnika wszystko ładnie wygląda. Zwróć też uwagę na łatwość implementacji tego rozwiązania, gdzie zbocze narastające sygnalizuje tylko początek bitu, zaś położenie zbocza opadającego określa jego wartość. Do tego możesz też w ten sposób kodować więcej wartości pośrednich w jednym cyklu PWM stosując zasadę, iż 10% to zero, zaś 80% to 7 przykładowo. Dodatkowo można oszczędzić timer stosując ADC, rezystor i kondensator do odczytywania danych cyfrowych w formie zmian napięcia...

    Swoją drogą implementacja skomplikowanego protokołu do tak prostego zadania to inżynieryjny masochizm. Doskonale sobie zdaję sprawę, iż moje rozwiązanie jest wręcz prymitywne, ale przez to jest proste i wydajne dla tego konkretnego problemu...
  • #18 10115780
    nsvinc
    Poziom 35  
    Mój protokół został stworzony jako substytut zastrzeżonego 1wire, a to, że znalazły się w nim ficzery takie jak multimaster, arbitraż i lepsze prędkości, to już inna bajka.
    Jestem w 110% świadomy zjawisk zachodzących w kablach - nie od wczoraj zajmuję się przewodowym przesyłem danych... Właśnie dlatego jednym z celów głównych była minimalizacja ilości zbocz na bit, z jednoczesnym umożliwieniem arbitrażu, ackslotów, i mozliwosci transmisji z różnymi prędkościami po tej samej linii. Ten sposób transmisji umożliwia również łatwą implementację DC-blanking...

    A do czego Kol. piotrva dokładnie chce użyć protokołu, nie wiadomo ;] Może buduje sieć, i multimaster jest mu na rękę. W szczególności w robocie, gdzie normalnie wypadałoby używać CANa do przesyłu danych między kolejnymi modułami czujników i układami wykonawczymi, właśnie wykorzystując multimastering.

    Faktycznie twoje rozwiązanie jest proste, ale toż to najzwyklejszy PWM. Niektóre czujniki temperatury Analoga wykorzystują taki sposób transmisji.
  • #19 10115812
    Urgon
    Poziom 38  
    AVE...

    A co złego jest w najzwyklejszym PWM? Transmisja na małe odległości, prędkość wystarczająca dla rozwiązania problemu kolegi Piotrva, w sumie moje rozwiązanie od rozwiązania kol. Kriss68 różni się tylko przesunięciem wartości wypełnienia do porównania na 50%. Wszystko powyżej 50% to jeden, a poniżej to zero. Proste jak drut, nie jest zasobożerne i jeszcze daje w miarę sporą odporność na zakłócenia przy mniejszych prędkościach transmisji. Dla większej pewności można zastosować na przykład przewód ekranowany...

    Twoje rozwiązanie jest bardzo dobre od strony technicznej, nie neguję tego. Ale poza technologią liczy się też ekonomia danego rozwiązania. I Twoje ma sens tam, gdzie potrzeba dużej pewności komunikacji, większych zasięgów, dużej prędkości, i tych wszystkich elementów, które zaimplementowałeś. Gdy trzeba przesłać dwa bajty z czujnika oddalonego od mikrokontrolera o kilkadziesiąt centymetrów maksymalnie i z prędkością poniżej 1Mbps, to Twoje rozwiązanie staje się nieopłacalne...

    W układzie z dużą ilością czujników i modułów wykonawczych też bym użył protokołu CAN lub czegoś podobnego...
  • #20 10115866
    nsvinc
    Poziom 35  
    Nie da się dyskutować z tymi argumentami ;] Przesyłanie dwóch bajtów 10cm kabelkiem to "nie transmisja", w szczególności gdy jest jeden master.
    Ale sądzę, że w robocie byłoby na rękę użyć czegoś multimasterowego (nie mówię, że musi to być moje rozwiązanie), gdyż łatwiej wtedy opanować system - czujnik może rzucać jednoznaczne komunikaty które nie muszą być pośrednio obrabiane przez główny procesor, tylko są intepretowane przez konretne układy wykonawcze, które te komunikaty rozumieją. Dokładnie tak, jak jest to rozwiązane w automotive...
  • #21 10115899
    Urgon
    Poziom 38  
    AVE...

    Ten sposób też ma sens tylko w zastosowaniach produkowanych seryjnie. W pojedynczym egzemplarzu to sensowne dla celów edukacyjnych. Dlaczego? Ano dlatego, iż każdy moduł musi dysponować jakąś logiką obsługującą sam protokół i sposób zachowania zależny od przesyłanych danych. W przypadku jednego urządzenia to podnosi koszta, a gdy korzystasz z własnych układów, zmusza do oprogramowania każdego z nich. Z drugiej strony specjalizowane układy używające CAN są dość drogie u nas. Czyli znów walka między sensem technicznym i ekonomicznym...
  • #22 10117226
    piotrva
    VIP Zasłużony dla elektroda
    1. Napisałem że to ma być wykorzystane do komunikacji dalmierz->sterownik.
    2. Protokół bardzo fajny, ale to ma być transmisja na długości max10 cm, nie musi być szybka, ale za to prosta w implementacji - zobaczymy co wejdzie na t13
  • #23 10117876
    Jado_one
    Poziom 22  
    @nsvinc
    Protokół interesujący - ciekawe czy sprawdziłby się przy transmisjach przez RF lub PowerLine....
    Ciekawe czy jest margines czasowy miedzy stanem 0 i 1? czyli cos w rodzaju stanu (a tutaj czasu) zabronionego?
  • #24 10117942
    nsvinc
    Poziom 35  
    Oczywiście że jest. W chwili obecnej kod interpretujący czasy trwania stanów pierwszy przekłamany czas traktuje jako błąd nadajnika/kolizję/przekłamanie, i zaprzestaje regularnego odbioru bitów; lecz na bieżąco musi nadal śledzić tok transmisji aby zlokalizować koniec ramki (śledzenie o ile nadajnik nie zauważył zonka, i nadaje w najlepsze dalej).
    Można iść dalej i wymyślić sobie jakiś ECC, aby móc naprawić/zgadnąć uszkodzony bit...

    Protokół w przypadku RF lub powerline ma ograniczone zastosowanie, gdyż praca polega na prostym on/off, i to jeszcze off jako stan recesywny. Jak uzyskać recesywny stan na radiu, inny niż po prostu brak nośnej? Dodatkowo, potężną ilość przekłamań będą dostarczać sygnały odbite, które mogą wbijać niechciane stany dominujące lub przesuwać pozycję zbocz, przekłamując bity. Detekcja i naprawa tego jest prawie niemożliwa...

    Z powyższych powodów protokół nie był, i nie będzie implementowany do transmisji przez eter lub inne medium nad którym nie ma 99% kontroli, za to bardzo dobrze sprawdza się po kablu lub optyce. Niebawem (jak dotknę kiedyś CPLD) zastosuję to do popychania danych światłowodem, i sądzę, że wynik będzie równie satysfakcjonujący, jak w przypadku kabelka.
REKLAMA