RTV forum PL | NewsGroups PL

Procedura komunikacji między mikrokontrolerami 8051 przez I2C - jak to zrobić?

i2c - 2051<->2051

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Procedura komunikacji między mikrokontrolerami 8051 przez I2C - jak to zrobić?

ele mid
Guest

Sat Sep 18, 2004 5:47 pm   



i2c - 2051<->2051 - robił już ktoś z Was coś takiego?

Potrzebowałbym prostej procedurki - dwóch programów do umieszczenia w dwuch
mikrokontrolerach, gdzie uP o danym adresie wysyłał i odbierał do uP o innym
adresie i na odwrót, po szynie i2c.

Ktoś to już robił?

Z góry dzięki za pomoc.

AlexY
Guest

Sat Sep 18, 2004 6:04 pm   



Użytkownik ele mid napisał:
Quote:
i2c - 2051<->2051 - robił już ktoś z Was coś takiego?

Potrzebowałbym prostej procedurki - dwóch programów do umieszczenia w dwuch
mikrokontrolerach, gdzie uP o danym adresie wysyłał i odbierał do uP o innym
adresie i na odwrót, po szynie i2c.

Ktoś to już robił?

jeszcze nie ale sie pomalutku do tego przymierzam
kilka 2051 bedzie robic pomiary a jeden zbierac wyniki i wyswietlac na LCD

Marek Dzwonnik
Guest

Sat Sep 18, 2004 6:23 pm   



Użytkownik "ele mid" <elemid@wp.pl> napisał w wiadomości
news:cii02t$isb$1@nemesis.news.tpi.pl

Quote:
Potrzebowałbym prostej procedurki - dwóch programów do umieszczenia w
dwuch mikrokontrolerach, gdzie uP o danym adresie wysyłał i odbierał
do uP o innym adresie i na odwrót, po szynie i2c.

Akurat programowe I2C do komunikacji pomiędzy uC to niezbyt szczęśliwy
pomysł. Tzn. o ile programowa realizacja Mastera jest banalna, to Slave musi
intensywnie słuchać tego co się dzieje na magistrali i nie zgubić żadnego
zbocza. Problem w tym, ze to Master decyduje o timingu na magistrali a Slave
nie ma na to żadnego wpływu i po prostu musi nadążyć. Np. okres zegara przy
f_scl=100kHz wynosi 10us, natomiast odstęp między zboczami SCL i SDA w
sekwencjach STOP i START może być znacznie krótszy i nie jest ściśle zależny
od szybkości transmisji. Na mój gust nie da się na 51-ce zrealizować
programowo pełnowartościowego slave I2C a tylko _protezę_I2C_ z narzuconymi
sztucznie ograniczeniami czasowymi.

Jeżeli to _musi_ być I2C to wziąłbym uC ze sprzętowym kontrolerem. (Np.
Atmelowe TWI w AVR-ach). Jeżeli nie, to jako sprzętowy Slave może posłużyć
np. PCF8584.

Jeżeli muszą się dogadać 2051 to czemu nie wykorzystać dostępnej w 51-kach
_od_zawsze_ komunikacji wieloprocesorowej przez UART ?


--
Marek Dzwonnik, GG: #2061027 - zwykle jako 'niewidoczny'
(Uwaga Gadu-Gadulcowicze: Nie odpowiadam na anonimy.)

Arek Karas
Guest

Sat Sep 18, 2004 6:34 pm   



Quote:
Akurat programowe I2C do komunikacji pomiędzy uC to niezbyt szczęśliwy
pomysł. Tzn. o ile programowa realizacja Mastera jest banalna, to Slave
musi
intensywnie słuchać tego co się dzieje na magistrali i nie zgubić żadnego
zbocza. Problem w tym, ze to Master decyduje o timingu na magistrali a
Slave
nie ma na to żadnego wpływu i po prostu musi nadążyć. Np. okres zegara
przy

Slave moze wprowadzic "Wait State" przytrzymujac SCK w stanie zero, aby to
jednak dzialalo to programowa implementacja Mastera musi zawierac obsluge
tego mechanizmu.

Pozdr
AK

Jurek Szczesiul
Guest

Sat Sep 18, 2004 7:05 pm   



Sat, 18 Sep 2004 21:23:42 +0200, na pl.misc.elektronika, Marek Dzwonnik
napisał(a):

Quote:
Jeżeli to _musi_ być I2C to wziąłbym uC ze sprzętowym kontrolerem. (Np.
Atmelowe TWI w AVR-ach). Jeżeli nie, to jako sprzętowy Slave może posłużyć
np. PCF8584.


BTW - niektóre '51 mają kontroler 'od zawsze' ( 552, 652, obecnie nowsza
seria P89c66x ).
A programowo - masz całkowitą rację. 2051 absolutnie odpada. Ze 100 kHz
daje sobie radę SX28 50 MHz z przerwaniem co ok. 2,7 us - zupełnie inna
klasa szybkości.

--
Pozdrowienia
Jurek Szczesiul

ziel
Guest

Sat Sep 18, 2004 7:40 pm   



On Behalf Of Arek Karas
Quote:
Slave moze wprowadzic "Wait State" przytrzymujac SCK w stanie zero, aby to
jednak dzialalo to programowa implementacja Mastera musi zawierac obsluge
tego mechanizmu.

Teoretycznie.

W pratyce, albo master się wiesza, w przypadku zwisa Slav'a,
albo robią błędy transmisji, albo całą resztę diabli biorą.
Dla takich układów jedynie słuszne jest "sprzętowe" podejście.
Chciaż osobiście skłaniam za M.Dz. do używania UART'a.
I2C w zasadzie używam do sterowania układami podrzędnymi.

pzdr
Artur

--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika

Dino
Guest

Sat Sep 18, 2004 7:41 pm   



Marek Dzwonnik nastukał:

Quote:
Jeżeli muszą się dogadać 2051 to czemu nie wykorzystać dostępnej w
51-kach _od_zawsze_ komunikacji wieloprocesorowej przez UART ?

lamersko z mej strony: a jak? gógle odsyła mnie do płyt na wiele procesorów,
albo wątków do dyskusji jak _programowo_ jeszcze jednego uart'a zrobić w uC.
Poratuj, Panie kochany, grupowy Arko Zbawienia, objaśnieniem, być może me
młode życie ratujesz przed dożyciem starości przy wymyślaniu wymyślonego....


z góry dzięki

Dino

Jacek Bogusz
Guest

Sat Sep 18, 2004 9:55 pm   



Quote:
lamersko z mej strony: a jak?

Linię RxD jednego procesorka łączysz z linią TxD drugiego. Teraz bierzesz
linię TxD "jednego" i łączysz z linią "RxD" drugiego. Robisz w ten sposób
"krzyżówkę". Oczywiście masy tych obu uK muszą być równiez połączone.
Najwygodniej tego typu system zorganizować w oparciu o przerwania. UART ma
tę cechę, że po odbiorze słowa może generować przerwanie. To z kolei może
posłużyć do interpretacji odebranego bajtu. Nadając bajt wystarczy, że
wpiszesz go do rejestru SBUF i to wszystko. Moim zdaniem jednak cała
trudność tkwić będzie nie tyle w połączeniu uK i wysyłaniu czy odbiorze
bajtów, ile we właściwym zorganizowaniu protokołu komunikacyjnego tak, aby
procesory nie "wtryniały" się sobie nawzajem. I to jest właśnie wyzwanie...
Na pewno potrzebny będzie jakiś prosty arbitraż do rozsądzenia kto nadaje
a kto odbiera. Można do tego celu wykorzystać ot chociażby wolną linię
portu, coś na wzór linii SS w SPI. Można również cały protokół transmisji
zorganizować na zasadzie master - slave tzn. master pyta slave o dane i
oczekuje na odpowiedź. Obawiam się, że wiele będzie zależeć od twojej
inwencji a "gotowca" raczej nie dostaniesz...

Jacek

Marek Dzwonnik
Guest

Sun Sep 19, 2004 12:29 am   



Użytkownik "Jacek Bogusz" <jacek.bogusz@ep.com.pl> napisał w wiadomości
news:opsejom8ra6z87ze@hp_nx9005
Quote:
lamersko z mej strony: a jak?

Linię RxD jednego procesorka łączysz z linią TxD drugiego. Teraz
bierzesz linię TxD "jednego" i łączysz z linią "RxD" drugiego. Robisz
w ten sposób "krzyżówkę". Oczywiście masy tych obu uK muszą być
równiez połączone. Najwygodniej tego typu system zorganizować w
oparciu o przerwania. UART ma tę cechę, że po odbiorze słowa może
generować przerwanie. To z kolei może posłużyć do interpretacji
odebranego bajtu. Nadając bajt wystarczy, że wpiszesz go do rejestru
SBUF i to wszystko.

Dorzucę jeszcze parę groszy organizacji na temat wymiany danych przez UARTY
pomiędzy 51-kami. uC może być kilka, przy czym jeden ma przypisaną odgórnie
rolę Mastera, pozostałe pełnią rolę Slave-ów.
TxD mastera łączysz z wszystkimi RxD slave-ów
TxD wszystkich slave-ów łączysz równolegle z RxD mastera (suma na drucie)

W tym układzie master nadaje jednocześnie do wszystkich, natomiast w danym
momencie może nadawać tylko jeden slave. Jednoczesne nadawanie przez kilka
slave-ów groziłoby kolizją i zniekształęceniem przesyłąnych danych. Dlatego
to master musi dyrygować przepływem danych, odpytując kolejno slave-y i
przydzielając im prawo do nadawania (odpowiedzi). Slave nie ma prawa
rozpocząć nadawania z własnej inicjatywy i musi czekać na przydział
magistrali ze strony mastera.

51-ki mają pewnien sprzętowy mechanizm wspomagajacy adresowanie w sieci
wieloprocesorowej.

UART 51 może w jednym z trybów wysyłać i odbierać słowa 9-bitowe. Do
nadawania/odbioru dziewiątego bitu służą bity TB8 i RB8 w jednym z SFR.
Decyzja o stanie nadawanego bitu (TB8) i interpretacji odebranego (RB8)
należy do programu - może to być np. ustawiany programowo i programowo
weryfikowany bit parzystości.

Tak jak wspomniał Jacek, najefektywniej organizuje się komunikację przez
UART z wykorzystaniem przerwań. Tzn. po odebraniu każdego znaku jak również
zakończeniu nadawania każdego znaku następuje zgłoszenie przerwania z
ustawionym znacznikiem - odpowiednio RI i TI.
Typowo obsługa przerwania UART wygląda tak, że za każdym razem:
- sprawdza się RI, jeżeli ustawiony to: należy go wyzerować, odczytać znak
z SBUF i coś z nim zrobić (np. dopisaćdo bufora odbiorczego)
- sprawdza się TI, jeżeli ustawiony to: należy go wyzerować i jeżeli
zostało coś jeszcze do wysłania (np w buforze) to pobrać kolejny znak i
wpisać go do SBUF. Zapis do SBUF automatycznie inicjuje kolejną transmisję.

Przy połączeniu uC jak wyżej, każdy znak nadawany przez mastera jest
odbierany przez _wszystkie_ slave-y, w każdym z nich wywołując przerwania i
zajmując ich czas. Dlatego wprowadzono mechanizm selektywnego blokowania
przerwań.

W 51-kach można skonfigurować UART w trybie 9-bit i układ przerwań w taki
sposób, że przerwania RI są zgłaszane _tylko_wówczas_ gdy odebrany
dziewiąty bit (dCool ma wartość 1. Jeżeli przyjmie się, ze normalne dane
mają d8=0 natomiast w adresach d8=1 to uC może ignorować strumień danych,
jednocześnie aktywnie nasłuchując słów adresowych.

Organizacja wymiany danych w sieci wieloprocesorowej może wyglądać np. tak:
* Master wysyła na magistralę _adres_ żądanego slave-a (TB8=1)
* Odebrane słowo adresowe z ustawionym 9 bitem (RB8=1) powoduje zgłoszenie
przerwania we wszystkich slave-ach.
* Każdy z układów podrzędnych sprawdza czy to jego adres. Zaadresowany
slave akceptuje wywołanie zdejmując blokadę i zgadzając się na odbieranie
słów z RB8=0 - czyli zwykłych danych. Natomiast pozostałe slave-y utrzymują
(lub przywracają) stan blokady ignorując strumień danych przeznaczony nie
dla nich.
* Master wysyła zapytania do slave-a. Wybrany slave je odbiera i ew. na
żądanie odpowiada własnymi pakietami
* Na zakończenie master kończy sesję, rozadresowując wszystkie slave-y np.
przez wysłanie adresu=0. W konsekwencji _wszystkie_ slave-y przechodzą w
stan selektywego nasłuchu.

Oczywiście protokół można dalej rozbudowywać, ale podstawowa zasada
kolejnego adresowania i odpytywania slave-ów przez mastera, oraz
selektywnego odbioru danych przez układy podrzędne pozostaje ta sama.


--
Marek Dzwonnik, GG: #2061027 - zwykle jako 'niewidoczny'
(Uwaga Gadu-Gadulcowicze: Nie odpowiadam na anonimy.)

Dino
Guest

Sun Sep 19, 2004 4:59 am   



Quote:
lamersko z mej strony: a jak?

Linię RxD jednego procesorka łączysz z linią TxD drugiego. Teraz
bierzesz linię TxD "jednego" i łączysz z linią "RxD" drugiego. Robisz
w ten sposób "krzyżówkę". Oczywiście masy tych obu uK muszą być
równiez połączone. Najwygodniej tego typu system zorganizować w
oparciu o przerwania. UART ma tę cechę, że po odbiorze słowa może
generować przerwanie. To z kolei może posłużyć do interpretacji
odebranego bajtu. Nadając bajt wystarczy, że wpiszesz go do rejestru
SBUF i to wszystko.

No właśnie, zawsze myślałem, że uart można między dwoma urządzeniami
zastosować, a jak chcemy więcej, to trzeba się porwać na jakąś inna
magistralę.


Quote:
Oczywiście protokół można dalej rozbudowywać, ale podstawowa zasada
kolejnego adresowania i odpytywania slave-ów przez mastera, oraz
selektywnego odbioru danych przez układy podrzędne pozostaje ta sama.


Dzięki za wyczerpującą odpowiedz i Jackowi i Markowi.

pozdrawiam

Dino

elektroda NewsGroups Forum Index - Elektronika Polska - Procedura komunikacji między mikrokontrolerami 8051 przez I2C - jak to zrobić?

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map