i2c - 2051<->2051
Masz problem? Zapytaj na forum elektroda.pl
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
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
=======
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
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
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
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
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
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
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
=======
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:
- 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 (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:
- 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.)
========
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
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