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

Dokładność kwarcu - jednoprzewodowa transmisja między uc

pgnige 29 Sty 2010 16:39 5056 62
  • #1 7611505
    pgnige
    Poziom 14  
    Witam wszystkich.
    Mam problem odnośnie synchronizacji dwóch atmega8 za pomocą jednej linii.
    Mam do wykorzystania jeden przewód, którymi płyną dane w obu kierunkach (po 3 bajty). Nie ma możliwości dodania kolejnego z sygnałem zegarowym.
    Tak więc sygnały zegarowe muszą być generowane przez oba mikroprocesory oddzielnie za pomocą timer'ów. I wszystko byłoby w porządku gdyby nie to, że identyczny program wgrany do obu uc działa "nie identycznie" tzn. generowane przerwania lekko różną się czasowo (co można dostrzec jedynie na oscyloskopie), skutkuje to "rozjeżdżaniem" obu zegarów przez co dane odbierane są niepoprawnie.
    Dodam, że oba mikroprocesory taktowane są zewnętrznymi kwarcami 16MHz oraz kondensatory 33pF oraz będą pracowały w zupełnie różnych warunkach (wilgotność, temperatura...)
    Dotykając lub zbliżając palec (zmieniając pojemność) do tych kondensatorów generowane przerwania lekko zmieniają się w czasie, więc ewidentnie dobierając odpowiednie pojemności kondensatorów timer'y ustabilizowałyby się względem siebie.

    Dołączam kod programu napisanego w bascom'ie (na 100% nie jest to wina języka):
    
    $regfile = "m8def.dat"                                     
    $crystal = 8000000                                      
    
    Config Portb = Output
    Portb = 0
    
    Config Timer0 = Timer , Prescale = 1
    Enable Timer0                                            
    Enable Interrupts                                        
    On Timer0 Io_data                                     
    
    Do
    Loop
    End
    
    Io_data:
       Toggle Portb.2
    Return
    


    Moje pytanie brzmi:
    Jak idealnie zsynchronizować częstotliwość kwarców tych atmeg (jeżeli to w ogóle możliwe)?
    W przeciwnym wypadku jak ma wyglądać transmisja danych na jednym przewodzie tak aby można było wysyłać dane synchronizacji timer'ów (i jak je przestawiać)?

    Z góry dziękuję za pomoc.
  • Pomocny post
    #2 7612029
    janbernat
    Poziom 38  
    Sposób 1- drogo i kłopotliwie:
    Dwa generatory kwarcowe- nie kwarce- parowane i każdy umieszczony w termostacie.
    Sposób 2- przemyśleć co się chce- 3bajty- jak szybko mają być przesyłane i jak często.
  • Pomocny post
    #3 7612151
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #4 7612154
    megao
    Poziom 24  
    pgnige napisał:
    Dotykając lub zbliżając palec (zmieniając pojemność) do tych kondensatorów generowane przerwania lekko zmieniają się w czasie, więc ewidentnie dobierając odpowiednie pojemności kondensatorów timer'y ustabilizowałyby się względem siebie.

    Nie dobierzesz raczej parametrów taktowania tak żeby transmisja się nie rozjeżdżała. Zawsze po jakimś czasie będzie problem z synchronizacją.

    pgnige napisał:
    W przeciwnym wypadku jak ma wyglądać transmisja danych na jednym przewodzie tak aby można było wysyłać dane synchronizacji timer'ów (i jak je przestawiać)?

    Transmisja danych jednym przewodem powinna być asynchroniczna. Wówczas pewne błędy zegara (w zakresie poprawnego próbkowania na odbiorniku) będą dopuszczalne. Odpadnie więc problem dokładnego doboru rezonatorów kwarcowych. Niewątpliwie transmisja będzie wolniejsza. Poczytaj trochę specyfikację najprostszego interfejsu asynchronicznego - UART.
  • Pomocny post
    #5 7612170
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #6 7612287
    ZbeeGin
    Poziom 39  
    Poczytaj sobie o kodowaniu MFM, w którym na podstawie przebiegu danych można odtworzyć sygnał zegarowy.
  • #7 7612291
    pgnige
    Poziom 14  
    Bardzo dziękuje za odpowiedzi, ale zapomniałem dodać że transmisja danych ma odbywać się na odcinku przewodu 150m.
  • Pomocny post
    #8 7612461
    janbernat
    Poziom 38  
    Napowietrznym?
    Czy wkopanym?
    W zasadzie w obu przypadkach będzie ciekawie- ale inaczej.
    P.S.
    W zasadzie dopiero teraz sformułowałeś problem a nie "Dokładność kwarcu - transmisja między uc; jednoprzewodowa".
  • #9 7612654
    pgnige
    Poziom 14  
    Na świeżym powietrzu, nawinięty na bęben.
    atom1477 - mógłbyś podać swój algorytm dwukierunkowej transmisji danych na jednej linii?
  • #10 7613052
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #11 7613251
    _Robak_
    Poziom 33  
    Coś mnie tu nie gra. To jak szybka jest niby ta transmisja, że zmiany częstotliwości mają znaczenie dla 3 bajtów. Zakładam że synchronizacja zaczyna się od bitu startu czy czegoś takiego, a nie np. startujesz oba procki które się synchronizują i tak sobie pracują. Jeśli to drugie to nie ma takiej możliwości żeby sie nie rozjechały. Możesz też łapać sygnał który jest nadawany na jakiejś częstotliwości radiowej, służący właśnie do synchornizacji (z tego co sie orientuję:) ). Druga sprawa, to że jak puścisz sobie taki sygnał z portu po 150m kablu to to co doleci do drugiego procka będzie na pewno ciekawym spektrum otoczenia ;)
  • #12 7613337
    Konto nie istnieje
    Poziom 1  
  • #13 7614683
    pgnige
    Poziom 14  
    Prędkość przesyłu jest dowolna, ale najlepiej powyżej 100Hz.
    W moim programie nie ma czegoś takiego jak bit startu, stopu czy synchronizacji.
    Oba procesory zaczynają pracy wraz z otrzymaniem zasilania i tak sobie taktują samoczynnie. W raz z danymi, które momentalnie zostają przesyłanie (24 bity w jedną stronę i bez żadnego powiadomienia 24 bity w drugą).

    Sygnał radiowy, ani żadna droga bez przewodowa nie wchodzi w grę.
    Do wykorzystania mam jedynie jeden ekranowany przewód i to nie może ulec zmianie.

    Warunki pracy obu mikroprocesorów będą zupełnie inne, ze względu na to, że jeden będzie pracował na świeżym powietrzu, a drugi w rurze kanalizacyjnej.
    Tak więc wilgotność, temperatura oraz inne czynniki będą bardzo zróżnicowane.
  • #14 7614763
    _Robak_
    Poziom 33  
    No to w takiej postaci nie ma kompletnie szans na powodzenie. Po pierwsze nie wiem jak chcesz zrobić żeby oba procesory ruszyły w tym samym momencie. Po drugie, jeśli nie chcesz bitu startu, bez synchronizacji co jakiś czas musi się wszystko rozjechać. A co do sygnału radiowego, to nie chodzi o przesyłanie tą drogą informacji, tylko o synchronizację do sygnału nadawanego, jak się to nazywa musiałby ktoś napisać, bo ja nie pamiętam. Ale układ taki był w EP czy EDW. Poza tym, nie wierze żeby ci to działało na takiej odległości bez żadnego układu który by ci zniekształcenia odfiltrował. Jak masz oscyloskop to sobie sprawdź.
  • Pomocny post
    #15 7614817
    Balu
    Poziom 38  
    Skoro masz ekran ekran i sygnal, to może jednak jakaś róznicówka?
    To raz. Dwa:
    Musisz zrobić jakieś dodatkowe bajty startu po których się będzie synchronizować, potem nawet nie musi być UART, wystarczy zwykłe nadawanie jakimś bifazowym kodowaniem (manchester np) i masz z głowy.
    Synchronizację robisz na bajtach startu - badasz dlugość 1 i 0.
    Potem znając czas, odmierzasz kolejne odcinki czasu i sprawdzasz dane później dekodujesz do byteu tą bifazówkę i jesteś w domu.
    Rozumiem że uC odpowiadają Sobie na jakieś pytania a nie mowią kiedy im się podoba i nie ma szans na konflikt...Generalnie problem na kilkanaście minut;) Ew. można dodać tranzystory które będą wzmacniały sygnał i that's it.
    3zł się należy ^^

    Dodano po 1 [minuty]:

    masz wtedy 2bajty startu+3bajty danych => 10bajtów kodem bifazowym danych, lub na upartego nawet bez bifazowego kodowania masz 5 bajtów...I PEWNOŚĆ, że nic się nie rozjedzie bo synchronizacja następuje na początku każdej transmisji.
  • Pomocny post
    #16 7614845
    mirekk36
    Poziom 42  
    pgnige --> tak patrzę sobie, patrzę - temat się toczy - a ty sam nie dość, że nie wiesz czego chcesz to nie masz pojęcia o żadnych sposobach transmisji. Dlatego snujesz jakieś fantasmagoryczne plany o rozjeżdżająych się kwarcach, zegarach i tym podobnych banialukach. Dlaczego tak sądzę - bo wystarczy poczytać o twoich pomysłach na komunikację między procesorami - to aż się włos jeży na głowie ;) Co to w ogóle za sposób na przesyłanie danych poprzez twoje "togglowanie" - sorry ale to jest chory pomysł.

    Proponuję - zejdź na ziemię ..... poczytaj o takich sposobach transmisji jak RS232 , RS485 - wysil się i doczytaj co to są bity startu i jak w ogóle ta komunikacja działa na najniższym poziomie. I - może to dla ciebie będzie jakieś naprowadzenie - doczytaj sobie dlaczego akurat RS485 nadaje się do przesyłania sygnałów na większe odległości i to nawet w warunkach gdzie są zakłócenia, i dlaczego wykorzystywany jest do transmisji sygnał różnicowy.

    Bo jak będziesz cały czas patrzył tylko przez czubek nosa i Bascoma - w którym do przesłania danych nawet przez RS485 wystarczy tylko wiedza o tym, że trzeba napisać:

    PRINT jakieś_dane

    to daleko nie zajedziesz. I tylko tracisz czas w którym mógłbyś sporo się dowiedzieć i wtedy dopiero zrozumiałbyś dlaczego musisz zmienić założenia swojego projektu. Dlaczego nie jeden przewód w takich warunkach o jakich piszesz.

    A już wyżej padały sugestie żebyś poczytał sobie np: o UART, o kodowaniu MFM, a także o RS485 ..... a ty dalej z uporem brniesz w totalnie ślepą dla siebie uliczkę - nie szkoda ci czasu? ;)
  • #17 7614967
    pgnige
    Poziom 14  
    Nie chodzi o to, że nie chcę żadnych bitów startu czy stopu, tylko teraz nie mam tego zastosowanego i nie bardzo wiem jak miałoby to działać. Stąd moje pytanie w pierwszym poście: Jak zsynchronizować ze sobą zegary za pomocą jakiś danych synchronizacyjnych.
    Oscyloskopem sprawdzałem zniekształcenia sygnału cyfrowego, ale z tym sobie poradziłem bez problemu, dlatego można przyjąć, że zniekształceń na wyjściu brak, bo jest idealny prostokąt.
    W innych moich projektach stosowałem RS232, ale nie sądziłem, że może pracować na tak duże odległości. Co do RS485 - nigdy nie miałem z tym do czynienia.

    Balu - mógłbyś "łopatologicznie"; krok po kroku opisać jak zrealizować takie połączenie?

    mirekk36 - podany przeze mnie program nie realizuje transmisji. Funkcja Toggle testowo pełniła funkcję zegara, abym mógł na oscyloskopie sprawdzić kiedy są wywoływane przerwania w obu mikroprocesorach - stwierdziłem, że mimo tego iż program w dwóch przypadkach jest identyczny to i tak przerwania wywoływane są z lekko inną częstotliwością. Później doszedłem do wniosku, że to wina rezonatora kwarcowego i kondensatorów z nim współpracujących.
    Oto faktyczny aktualny wycinek programu (przerwanie od timer'a) do transmisji danych:
    Io_data:
          If Ddrb.1 = 0 Then
             If Pinb.1 = 1 Then Incr Help_byte
             Incr N_bit
             Rotate Help_byte , Right
             If N_bit = 8 Then
                N_bit = 0
                Portc = Help_byte
                Get_byte(n_byte) = Help_byte
                Help_byte = 0
                Incr N_byte
                If N_byte > 3 Then
                   N_byte = 1
                   Toggle Ddrb.1
                End If
             End If
          Else
             If Send_byte(n_byte).n_bit = 1 Then
                Set Portb.1
             Else
                Reset Portb.1
             End If
             Incr N_bit
             If N_bit = 8 Then
                N_bit = 0
                Incr N_byte
                If N_byte > 3 Then
                   N_byte = 1
                   Toggle Ddrb.1
                End If
             End If
          End If
    Return
    


    Dodam, że PORTB.1 jednego mikroprocesora jest na początku inicjalizowany jako wejście, a drugi wyjście. Oraz to na tym pinie odbywa sie transmisja danych.
    Zmienna tablicowa Send_data zawiera liczby do wysłania, a do zmiennej Get_data są wpisywane odebrane wartości.
  • #18 7615015
    Balu
    Poziom 38  
    Co to jest "takie połaczenie"
    Jeśli ekran masz na przewodzie możesz go użyć jako drugiego przewodu w różnicówce (rs485), rs232 nie działa z zasady na takie odległości.
    Co prawda z różnicówki nie będzie miało wiele, ale zawsze:)
    Jeśli nie o to "takie połączenie" Ci chodzi, to o jakie?
  • #19 7615025
    pgnige
    Poziom 14  
    Nie mam pojęcia co to jest różnicówka.
  • #20 7615082
    Balu
    Poziom 38  
    RS485:)
    TO przykład gdzie używamy transmisji różnicowej. Nie masz sygnału odniesienia (wspólnej masy). Tylko "mierzysz napięcie" na koncu kabla i na podstawie tego wiesz jaki stan, a dlatego to jest dobre, że nakładają się zakłócenia jednocześnie na dwa przewody więc w napięciu ich nie widać:)

    Więc tak, rs485 to przykład różnicówki.
    Innym jest ethernet;)
  • #21 7615120
    pgnige
    Poziom 14  
    Tak ale ja mam do wykorzystania tylko 1 przewód, więc RS485 nie będzie.
  • #22 7615133
    mirekk36
    Poziom 42  
    no no nooo - to widzę, że zaczyna się temat typu serial brazylijski ;) ....

    Balu napisał:
    RS485:)
    TO przykład gdzie używamy transmisji różnicowej. Nie masz sygnału odniesienia (wspólnej masy). Tylko "mierzysz napięcie" na koncu kabla i na podstawie tego wiesz jaki stan,


    Balu - skoro autor z takim zacięciem nie chce nic poczytać i się czegoś dowiedzieć - to sądzę że za chwilę weźmie miernik w ręce i zacznie mierzyć to napięcie na końcach kabla - dziwiąc się nadal o co chodzi w tej różnicówce

    ..... ale ....

    pgnige napisał:
    Tak ale ja mam do wykorzystania tylko 1 przewód, więc RS485 nie będzie.


    ... o proszę - już chyba pomierzył i stwierdził, że jednak to nie dla niego ;)
  • #24 7615191
    janbernat
    Poziom 38  
    Nie ma transmisji przez jeden przewód- zawsze jest jakiś drugi.
    Czasem go nie widać.
    Masa, ekran , ziemia- na stałe albo przez pojemność która też zawsze jakaś jest.
    Zrób doświadczenie- połącz dwa układy procesorów na dwóch oddzielnych płytkach jednym przewodem.
    Nie łącz ich mas w żaden sposób- ani ekranem ani przez zasilanie itp.
    P.S.
    To będzie serial "True 1wire"- bez masy.
  • #26 7615202
    mirekk36
    Poziom 42  
    Balu napisał:
    No kuźwa mówiłeś,że masz przewód + ekran... Ja nie umiem pisać jaśniej...
    mirekk36 toć to w weekendy same seriale lecą, nie wiedziałeś?:)


    hyhyhyhy

    masz rację od wczoraj wieczorem właśnie pojawiło się na elektrodzie kilka takich tematów - pretendujących do nominacji na brazylo-kamery rozku ;)

    ale ten temat jest coraz bardziej w czołówce - toż kable raz są takie a raz inne, raz mają się pojawiać bity startu a innym razem znikają bo są nie potrzebne - dobre dobre ;)
  • #27 7615484
    janbernat
    Poziom 38  
    Ale problem pgnige nie został nierozwiązany.
    A problem przesyłania danych z rury kanalizacyjnej jest.
    A jakąś wolną transmisję z wykorzystaniem ekranu jako masy i z jakimś sensownym protokołem transmisji i weryfikacji błędów dałoby się zrobić.
  • #28 7615487
    pgnige
    Poziom 14  
    Oczywiście jest masa - ekran, ale tą wiązką przewodów nie płyną tylko dane cyfrowe, ale też analogowe.
    Masa (ekran) jest wspólny dla wszystkich przewodów, tak więc ekranem nie można przesyłać zupełnie żadnych danych, to jest 0V i koniec.
    W przeciwnym wypadku zakłóciłoby to sygnał analogowy, którego punktem odniesienia jest właśnie ten sam ekran.
    Mówię od samego początku, że zupełnie nie przeszkadzają mi żadne bity startu, stopu, tylko nie wiem jak zrealizować taką transmisję.

    Proszę o pomoc.
  • #29 7615503
    Konto nie istnieje
    Poziom 1  
  • #30 7615522
    mirekk36
    Poziom 42  
    janbernat napisał:
    A jakąś wolną transmisję z wykorzystaniem ekranu jako masy i z jakimś sensownym protokołem transmisji i weryfikacji błędów dałoby się zrobić.


    no pewnie, że dałoby radę, wszystko by dało radę zrobić tylko sam przyznasz chyba, że do tego trzeba mieć jednak jakąś tam podstawową wiedzę m.inn o różnych innych protokołach transmisji danych, sposobach kodowania danych itd itd ..... czego autor sukcesywnie unika forsując swoje teorie i założenia z kosmosu. Toż gdyby choć trochę się wysilił i przeczytał dokładnie - zapoznał się hmm nie wiem np z RS485 - to może by się nawet okazało, że ..... "aaaaa co tam, zamiast tego jednego przewodu puszczę skrętkę czy jakiś podobny kable, a dzięki temu będę miał wszystko co najlepsze i najprostsze w transmisji i do tego z zapsasem na przyszłe potrzeby"

    Może i jeszcze inne założenia by się zmieniły.

    Ale nie - autor raczej czeka aż mu napiszesz , przetestujesz i wręcz wdrożysz, podpowiesz i objaśnisz wszystko tu na forum - pisząc w zasadzie dobrą książkę ;)
REKLAMA