i2c - 2051<->2051

Użytkownik ele mid napisał:

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

U¿ytkownik "ele mid" snipped-for-privacy@wp.pl napisa³ w wiadomo¶ci news:cii02t$isb$ snipped-for-privacy@nemesis.news.tpi.pl

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 ?

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

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

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.

On Behalf Of Arek Karas

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

Marek Dzwonnik nastuka³:

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

Użytkownik Dino napisał: >

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>

:)

eL eS

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

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

U¿ytkownik "Jacek Bogusz" snipped-for-privacy@ep.com.pl> napisa³ w wiadomo¶ci news:opsejom8ra6z87ze@hp_nx9005

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.

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

Dziêki za wyczerpuj±c± odpowiedz i Jackowi i Markowi.

pozdrawiam

Dino