Komunikacja mikrokontrolerów 1 masteri i 4 slave'y 89s52

Question

Witam, chciałbym zrobić coś takiego, że na jednej magistrali równoległej pracowałoby 5 uP, z czego jeden byłby master a 4 slave'y. Rozumiem, że z mastera oprócz magistrali, do każdego slave'a muszę wyprowadzić sygnał odczytu i zapisu.

Poradźcie, na co muszę zwrócić uwagę.

Pozdrawiam

markosik20 · Answer

Niekoniecznie, możesz zaadresować układy SLAVE i wtedy będzie się zgłaszał ten którego MASTER zapyta. Pozostaje jeszcze wybór interfejsu, może być I2C, SPI, UART (w poziomie TTL), 1WIRE lub równoległy.

rysiek182 · Answer

Jednak pokusiłbym się o magistralę równoległą, 8 bitów na magistrali wystarczy

markosik20 · Answer

Czyli zależy Ci na czasie komunikacji? .

rysiek182 · Answer

nie, nie zależy mi na szybkości transmisji

markosik20 · Answer

To proponuję I2C (lub sprzętowego UARTA), tylko dwa przewody i obsługa bardzo prosta. Trzeba będzie tylko sobie wymyśleć jakiś prosty protokół transmisji z adresowaniem układów.

MarasK · Answer

i2c chyba najwygodniejszy się wydaje. A pomysł z adresami slave'ów bardzo dobry. Oprócz SCL i SDA możesz dodać jeszcze linię INT - suma logiczna wyjść sygnalizacji przerwania z uP. Transmisję wykonywałbyś tylko wtedy, jeśli którykolwiek z uP zgłosiłby chęć komunikacji.

Fyszo · Answer

I2C nie ma w 89c52. Programowa obsługa i2c, przy napiętym czasowo algorytmie innych funkcji - pewnie się wyłoży. Uart w 89c51 ma możliwość adresowania, wykorzystuje się tu 9bit jako znacznik ramki 'pytającej', wysyła się adres, a jedno z urządzeń go ropoznaje (software'owo) potem wyłaczamy bit 9 i pozostałe urządzenia ignorują transmisję tylko zaadresowany slave działa.

MarasK · Answer

I2C to nie 1wire - tu nei ma ścisłych timeslotów - wszystko nadaje zegar.
Chociaż skoro jest opcja komunikacji multi-uP to czemu z niej nie skorzystać? Pytanie tylko jak połączyć wyjścia tych uP, aby nie uległy spaleniu

avatar · Answer

jakims konwenterem np max485

Fyszo · Answer

Bit SM2 w rejestrze SCON jest flagą 'czy ignorować' przychodzące dane przez UART (tryb 2 i 3). Jesli 9 bit w transmisji jest '1' i SM2 mamy ustawiony również na '1' to UART odbiorcy akceptuje dane. Można to wykorzystać to adresowania slave'ów. 4 slave mają swój adres i ustawione bity SM2, master wysyła 8bit adres i 9bit jako '1'. Potem zaadresowany slave zeruje SM2 a transmisja przebiega normalnie z wyzerowanym 9 bitem, reszta UARTów nie reaguje na dane bo mają ustawiony SM2. Porty się nie spalą bo pracują jako wejścia czekające na transmisję (Rx), dopiero zaadresowany slave może ustawić 'sztywny' stan na porcie Tx. Pilnując zasady że: 'tylko zapytany slave odpowiada' nic się nie stanie.
Dla 100% pewności można dodać po diodzie separującej każde wyjście Tx.

rysiek182 · Answer

hmm, widzę, że wszyscy opisują magistralę szeregową, ja natomiast jednak chciałbym zrobić tą komunikację na równoległej.

Jak muszę podłączyć porty tych uP, żeby nie popalić tychże portów

Pozdrawiam, Rysio

rysiek182 · Answer

Witam ponownie,
Zerknijce na ten schemacik i ocencie, czy to może zadziałać,

Mam zamiar zrobić tak, że jak Master chce sie skomunikowac z któryms slavem, to zeruje bit adresu i wystawia na szyne danych wartosc, wtedy slave odbiera i gra gitara. a jak slave chce cos przeslac do mastera to też zeruje drugi bit adresu i czeka na sygnal gotowosci od mastera

W te sposób nie bedzie kolizji na szynie danych.

Co o tym sądzicie??

Pozdrawiam[/img]

Balu · Answer

Równie dobrze możesz Sobie podpiąć dwie 4bitowe magistrale zupełnie niezależnie wyjdzie tak samo pinowo:> (przy 2 prockach slave).

rysiek182 · Answer

generalnie nie chodzi mi o ilość linii, bo mam trochę miejsca, tylko chodzi mi o zasadę działania, czy przypadkiem, nie zdziwię się, jak bede chciał to uruchomić

Balu · Answer

Jeśli nie chodzi Ci o ilość linii to po co komplikować? Zrób komunikację oddzielnie z każdym prockiem:>

Komunikacja mikrokontrolerów 1 masteri i 4 slave'y 89s52

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Podsumowanie tematu