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

Najlepszy interfejs do przesyłąnia danych?

grafiksaba 06 Sie 2008 07:57 1895 14
  • #1 06 Sie 2008 07:57
    grafiksaba
    Poziom 10  

    Serdecznie witam,

    Jaki jest najlepszy interfejs do przesyłania danych pomiędzy mikroprocesorami, przy założeniu że do programowania będziemy używać BASCOMa? np. do przesłania tekstu do wyświetlenia na wyświetlaczu podłączonym do innego procesora.

    pozdrawiam

    0 14
  • #2 06 Sie 2008 08:01
    adamusx
    Poziom 27  

    Pytanie między iloma uC będa przesyłane dane. Jeśli między dwoma to najprostrzy będzie UART (oczywiscie gdy nie przewidujecie podlaczenie uC do kompa).
    Jeśli więcej niz 2 uC to zdecydowanie SPI.

    0
  • #3 06 Sie 2008 08:41
    autoservice
    Poziom 20  

    ...zależy też jaka odległość... najlepszy to pojęcie względne... bez tych danych pod najlepszy to można chyba wrzucić rs485
    pzdr.

    0
  • #4 06 Sie 2008 09:08
    kekon
    Poziom 17  

    Z punktu widzenia języka programowania nie ma to właściwie większego znaczenia gdyż każdy z nich obecnie obsługuje większość popularnych interfejsów.
    Do tego celu bardzo dobrze się nadaje interfejs I²C. Większość współczesnych mikrokontrolerów ma go "na wyposażeniu". Standardowo prędkość transmisji jest 100 kbit/s a w trybie szybkim 400 kbit/s. I²C ma tę zaletę, że prowadzi się tylko 2 przewody niezależnie od tego ile układów jest połączonych. Interfejs SPI jest znacznie szybszy (typowo ponad 1Mb/s) ale do każdego obsługiwanego układu jest potrzebny dodatkowy sygnał strobujący CS (im więcej połączonych układów tym więcej sygnałów CS trzeba poprowadzić, co wiąże się się z koniecznością utraty części linii I/O w kontrolerze który steruje całą siecią połączonych układów). Zarówno SPI jak i I²C nie wymagają podłączania dodatkowych driverów.
    Gdy odległość między procesorami ma być duża (np. powyżej kilkudziesięciu cm) i wymagana jest szybka transmisja to wówczas lepszym rozwiązaniem będzie RS485 lub RS422. Te interfejsy są odporne na zakłócenia, mogą być stosowane do długości linii 1200m i prędkości 10Mb/s. W przypadku RS485 są tylko 2 przewody (nie prowadzi się przewodu masy, gdyż transmisja jest symetryczna)
    Wymagane jest jednak dołączenie driverów np. MAX485 oraz - w przypadku długich kabli - rezystorów (terminatorów) na najbardziej od siebie oddalonych końcach kabla.

    0
  • #5 06 Sie 2008 09:55
    Bigfoot
    Poziom 25  

    kekon - rezystory terminujace stosuje sie chyba w RS485 ZAWSZE, nie tylko w przypadku dlugich kabli. Tak?

    BF

    0
  • #6 06 Sie 2008 10:03
    kekon
    Poziom 17  

    Code:
    kekon - rezystory terminujace stosuje sie chyba w RS485 ZAWSZE, nie tylko w przypadku dlugich kabli. Tak?


    Na szczęście nie. Przy wolnych transmisjach i gdy RS485 używa się do połączenia np. kilku płytek w urządzeniu to rezystory nie są konieczne. Projektowałem takie systemy do zastosowań w gazownictwie. Mieliśmy np. przelicznik przepływu gazu zbudowany z kilku płyt (płyta procesora + kilka płyt z układami pomiarowymi). Były one połączone przez RS485 ale nie dawaliśmy rezystorów terminujących gdyż transmisja była raczej wolna - 115 kbit/s przy odległości pomiędzy płytkami zaledwie 10..15 cm.
    Nie było żadnych problemów z błędami tramisji (odbiciami sygnału, przesłuchami itp.) Gdy już stosuje się rezystory to przy zwykłej skrętce 2-przewodowej typowo daje się po 120Ω.

    0
  • #7 06 Sie 2008 12:23
    Pituś Bajtuś
    Poziom 28  

    kekon napisał:
    Interfejs SPI jest znacznie szybszy (typowo ponad 1Mb/s) ale do każdego obsługiwanego układu jest potrzebny dodatkowy sygnał strobujący CS (im więcej połączonych układów tym więcej sygnałów CS trzeba poprowadzić, co wiąże się się z koniecznością utraty części linii I/O w kontrolerze który steruje całą siecią połączonych układów).

    A kto zabroni zastosować w SPI adresowanie układów pracujących na wspólnej linii CS? Przykładem takiego rozwiązania są ekspandery MCP23Sxx Microchipa.

    0
  • #8 06 Sie 2008 12:37
    kekon
    Poziom 17  

    Nikt nie zabrania, tylko że ekspandery są znacznie mniej popularne i trudniejsze do dostania niż np. drivery do RS485, które można kupić za 2 zł a nawet taniej. Expandery Microchipa są typowo w większych obudowach, drivery RS485 typowo w SOIC-8. RS485 dodatkowo umożliwia połączenie na dużych odległościach czego nie da się zrobić w SPI (no chyba że sie zastosuje dodatkowe nadajniki/odbiorniki linii)

    0
  • #9 09 Sie 2008 21:39
    Fyszo
    Spec od GSM

    Te 1200m przy 10Mb/s to z jakieś książki wziąłeś?

    0
  • #10 09 Sie 2008 22:00
    Pituś Bajtuś
    Poziom 28  

    kekon napisał:
    Nikt nie zabrania, tylko że ekspandery są znacznie mniej popularne i trudniejsze do dostania niż np. drivery do RS485, które można kupić za 2 zł a nawet taniej. Expandery Microchipa są typowo w większych obudowach, drivery RS485 typowo w SOIC-8.

    Przecież ja nie każę stosować do tego ekspanderów! Tylko wysłać dodatkowy bajt z adresem, ekspander był tylko przykładem, że w SPI też można.

    0
  • #11 09 Sie 2008 23:04
    MarasK
    Poziom 18  

    Zależy od 'algorytmu wymiany' danych - można standardowo zmusić wszystkie układy do pracy jako nasłuch, a tylko po odebraniu odpowiedniego adresu urządzenie przestawia się w nadawanie. System może pracować jako master-slave ze stałym masterem, albo przekazywaniem tokena - możliwości jest bardzo wiele :)
    W takim wypadku nie potrzeba osobnych linii CS.

    Zgadzam się, że SPI jest bardzo dobre, ale za I2C przemawia mnogość układów (ekspandery itp) i wsparcie sprzętowe w uP.

    0
  • #12 10 Sie 2008 10:47
    nsvinc
    Poziom 35  

    Jest jeszcze troche inaczej:

    Niezaleznie od uzytego interfejsu obowiązkowe jest opracowanie warstwy protokołu. (oprócz i2c)

    I2c zawiera juz wg specyfikacji tą warstwę, dlatego można uzywać prostych sekwencji wysylania/odbierania danych z dowolnego innego kontrolera i2c.

    Wszystkie inne interfejsy tej warstwy nie posiadają, dlatego jesli chce się stworzyć system komunikacji między mikrokontrolerami trzeba samemu się zastanowić nad adresowaniem, wysylaniem/odbieraniem danych, handshakingiem, ack itp itd, w innym wypadku transmisja będzie kaleka i mogą dziać się cyrki z synchronizacją.

    Protokoły mogą być pakietowe lub strumieniowe - pakietowe mają przewaznie jakis znacznik 'start' i 'stop', pomiedzy nimi znajduje się adres, dane i CRC.

    Strumień to ciągły przepływ danych nie ciętych na 'poczatki' i 'końce', lecz CRC jak i inne dane informacyjne są 'wklejane' w payload.

    Są też kombinacje tych dwóch protokołów, np. wysyłanie do kazdego bajtu/słowa payloadu dodatkowego bajtu/słowa kontrolnego. (dobra metoda, sam stosowałem).
    Bajt kontrolny zawiera informację o adresie docelowym, poleceniu, i znaczników akcji (np. 'do CRC 3 bajty', 'CRC 8 poprzednich bajtów'). W połączeniu z fifo w nadajniku i odbiorniku mozna miksować pojedyncze dane ze sobą w jednej kolejce i wysyłać je bezposrednio z tej kolejki - i jest ta pewnosc ze kazdy bajt dotrze do adresu docelowego....

    Jedyny problem to chyba tylko siąść i przemyśleć protokół :] Interfejs nie gra istotnej roli.... (no bo kto broni zastosować protokół TCP via UART? Mozna, pytanie PO CO :] )

    0
  • #13 10 Sie 2008 15:07
    kekon
    Poziom 17  

    Cytat:
    Te 1200m przy 10Mb/s to z jakieś książki wziąłeś?


    Jest to możliwe jeśli zastosujesz repeatery.

    0
  • #14 10 Sie 2008 18:10
    Fyszo
    Spec od GSM

    kekon napisał:
    Cytat:
    Te 1200m przy 10Mb/s to z jakieś książki wziąłeś?


    Jest to możliwe jeśli zastosujesz repeatery.

    Wtedy to wogóle nie ma granic - dla żadnej magistrali.
    I rację ma kolega nsvinc że to warstwa protokołu/aplikacji będzie najtrudniejsza do 'obmyślenia'.

    0
  • #15 10 Sie 2008 18:21
    kekon
    Poziom 17  

    Warstwa protokołu jest prosta. Ja zawsze stosuję taką, że pierwszy bajt oznacza początek pakietu, drugi rozmiar całego pakietu, trzeci adres nadawcy, czwarty adres docelowy, potem idą dane a po nich crc. Na końcu jest bajt stopu. Do crc nie wliczane są bajty startu i stopu. To oczywiście tylko jeden z przykładów.
    W przemysłowych sieciach z RS485 taki sposób jest bardzo często stosowany. Co innego jest w USB. Tam każdy pakiet jest narzucony przez specyfikację. Są bajty startu i stopu SYNC i EOP (w high-speed są to nawet 4 bajty) Jednak CRC jest obliczane sprzętowo co znacznie przyśpiesza działanie programu.

    0
  Szukaj w 5mln produktów