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 (d

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