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

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

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