Prosta komunikacja i2c między mikrokontrolerami 2051 - przykładowe programy

i2c - 2051<->2051





Poprzedni Następny
Wiadomość
Spis treści
From: "ele mid" <elemid_at_nospam_wp.pl>
Subject: i2c - 2051<->2051
Date: Sat, 18 Sep 2004 20:47:46 +0200


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.



========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: AlexY <alexy_at_nospam_irc.-cut_this-.pl>
Subject: Re: i2c - 2051<->2051
Date: Sat, 18 Sep 2004 21:04:58 +0200


Użytkownik ele mid napisał:
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

=======

Poprzedni Następny
Wiadomość
Spis treści
From: "Marek Dzwonnik" <mdz_at_nospam_WIADOMO_PO_CO_TO.message.pl>
Subject: Re: i2c - 2051<->2051
Date: Sat, 18 Sep 2004 21:23:42 +0200


Użytkownik "ele mid" <elemid_at_nospam_wp.pl> napisał w wiadomości
news:cii02t$isb$1_at_nospam_nemesis.news.tpi.pl

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.)


========
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Arek Karas" <arkkarREMOVE_at_nospam_2com.pl>
Subject: Re: i2c - 2051<->2051
Date: Sat, 18 Sep 2004 21:34:26 +0200


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


========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsgate.onet.pl!newsgate.p

Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_poczta.onet.pl (ziel)
Subject: RE: i2c - 2051<->2051
Date: 18 Sep 2004 22:40:03 +0200


On Behalf Of Arek Karas
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


========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: i2c - 2051<->2051
Date: Sat, 18 Sep 2004 22:05:45 +0200


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

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

========
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Dino" <din0_at_nospam_[spamerownielubie]gazeta.pl>
Subject: Re: i2c - 2051<->2051
Date: Sat, 18 Sep 2004 22:41:26 +0200


Marek Dzwonnik nastukał:

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



========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: =?UTF-8?B?xYF1a2FzeiBTb2vDs8WC?= <el_es_at_nospam_p0cz74.0n37.pl>
Subject: Re: i2c - 2051<->2051
Date: Sat, 18 Sep 2004 23:08:35 +0200


Użytkownik Dino napisał:
>
> 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....

1) Zakładam, że procki są dwa.
2) W tym przypadku najprościej będzie połączyć TXD jednego z RXD
drugiego i vice versa.
3) obsługa na przerwaniach - to znaczy, program główny jakoś-tam
obrabia sobie dane,a procedura odbierająca podkłada mu co trzeba gdzie
trzeba.Ale jak to ma być wykorzystane, to zależy, co który procek ma
robić ponadto.
Bo <wróżka> pewnie jeden jest od klawiatury a drugi od wyświetlacza,
to np. ten od wyświetlacza odbiera kody ASCII i kody sterujące,
umieszcza je w swojej pamięci i w razie potrzeby wysyła na display,
a znĂłw ten od klawiatury odbiera rozkaz ^G (beep)
i odpowiednio uruchamia piszczyk
jak ten od wyświetlacza da mu znać,
że już nic nie zmieści
i trzeba nacisnąć backspace (#127),
a ten od wyświetlacza może mieć jeszcze przetwornik C/A
i wtedy musi wiedzieć,
Ĺźe to co odbiera tak,
to dla przetwornika
a to drugie to dla displaya,
a moĹźe jeszcze niech ten od klawiatury
ma interface i2c do komunikacji
z procesorem obrazu dla telegazety
sterowane danymi wysylanymi
z pamieci proca od displaya
a proc od displaya może mieć podłączony dodatkowo
układ pamięci ram na i2c
a w ogóle niech gadają ze sobą w protokole Jabber
a każdy z nich niech realizuje kawałek jądra Linuxa
a mój avr 2313 ma tylko 1kSłów pamięci programu
i nie mieści mi się skompilowany OpenMosix
(wdech)
</wróşka>

)

> Dino
>
eL eS

I WYSYŁAJ POSTY W ISO 8859-2 A NIE W UTF8!



--
| W T F |
| O M F G |
| I HATE 1337 |
|speak so damn|
|much it hurts|

========
Path: news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.pionier.net.pl!news.dialog.net.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Jacek Bogusz" <jacek.bogusz_at_nospam_ep.com.pl>
Subject: Re: i2c - 2051<->2051
Date: Sun, 19 Sep 2004 00:55:46 +0200


lamersko z mej strony: a jak?

Lini=EA RxD jednego procesorka =B3=B1czysz z lini=B1 TxD drugiego. Teraz=
bierzesz =

lini=EA TxD "jednego" i =B3=B1czysz z lini=B1 "RxD" drugiego. Robisz w t=
en spos=F3b =

"krzy=BF=F3wk=EA". Oczywi=B6cie masy tych obu uK musz=B1 by=E6 r=F3wniez=
po=B3=B1czone.
Najwygodniej tego typu system zorganizowa=E6 w oparciu o przerwania. UAR=
T ma =

t=EA cech=EA, =BFe po odbiorze s=B3owa mo=BFe generowa=E6 przerwanie. To=
z kolei mo=BFe =

pos=B3u=BFy=E6 do interpretacji odebranego bajtu. Nadaj=B1c bajt wystarc=
zy, =BFe =

wpiszesz go do rejestru SBUF i to wszystko. Moim zdaniem jednak ca=B3a =

trudno=B6=E6 tkwi=E6 b=EAdzie nie tyle w po=B3=B1czeniu uK i wysy=B3aniu=
czy odbiorze =

bajt=F3w, ile we w=B3a=B6ciwym zorganizowaniu protoko=B3u komunikacyjneg=
o tak, aby =

procesory nie "wtrynia=B3y" si=EA sobie nawzajem. I to jest w=B3a=B6nie =
wyzwanie...
Na pewno potrzebny b=EAdzie jaki=B6 prosty arbitra=BF do rozs=B1dzenia k=
to nadaje =

a kto odbiera. Mo=BFna do tego celu wykorzysta=E6 ot chocia=BFby woln=B1=
lini=EA =

portu, co=B6 na wz=F3r linii SS w SPI. Mo=BFna r=F3wnie=BF ca=B3y protok=
=F3=B3 transmisji =

zorganizowa=E6 na zasadzie master - slave tzn. master pyta slave o dane =
i =

oczekuje na odpowied=BC. Obawiam si=EA, =BFe wiele b=EAdzie zale=BFe=E6 =
od twojej =

inwencji a "gotowca" raczej nie dostaniesz...

Jacek

=======

Poprzedni Następny
Wiadomość
Spis treści
From: "Marek Dzwonnik" <mdz_at_nospam_WIADOMO_PO_CO_TO.message.pl>
Subject: Re: i2c - 2051<->2051
Date: Sun, 19 Sep 2004 03:29:37 +0200


Użytkownik "Jacek Bogusz" <jacek.bogusz_at_nospam_ep.com.pl> napisał w wiadomości
news:opsejom8ra6z87ze_at_nospam_hp_nx9005
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:
z SBUF i coś z nim zrobić (np. dopisaćdo bufora odbiorczego)
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 (d8) 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:
przerwania we wszystkich slave-ach.
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.
żądanie odpowiada własnymi pakietami
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.)


========
Path: news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!newsfeed.pionier.net.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!airbus.lido-tech.net!new

Poprzedni Następny
Wiadomość
Spis treści
From: "Dino" <din0[bezspamu]_at_nospam_gazeta.pl>
Subject: Re: i2c - 2051<->2051
Date: Sun, 19 Sep 2004 07:59:28 +0200



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ę.


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



========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai