Programowanie układu z mikroprocesorami ATmega - współpraca master-slave przez I2C i RS232

Mon Jan 29, 2007 10:10 am   

Witam
Mam pytanie: na czym polega i jak jest realizowana praca układu z 2
zaprogramowanymi w nim mikroprocesorami. Jeden musi być master drugi
slave. A co z oprogramowaniem. jak napisać je dla pierwszego a jak dla
drugiego. Pierwszy np. oprogramowanie głowne (robota kroczącego),
drugi - streowanie serwami modelarskimi, czujnikami. wspólpraca
układów przez I2C. A co ze sterowaniem przez RS232. tylko układ master
i poprzez niego slave, czy oba muszą być przez RSa.

Pytanie podatkowe: jakim układem sterować 20 (25) serwami modelarskimi
z ktorych dodatkowo wyprowadzono sygnał z potencjometrów do mierzenia
poboru prądu pobieranego przez serwo do przetwornika A/C (ten z
mikroprocesora np AT90S8535 odpada bo wykorzystywany do sterowania
serwami). A/C zewnętrzny - PCF. Plus czujniki.
Robert robin1978@o2.pl

Mon Jan 29, 2007 10:32 am   

On Jan 29, 10:10 am, robin1...@o2.pl wrote:

Uporządkuj swoje pytanie tak, żeby było wiadomo, co masz w garści, co
sobie wymyśliłeś i dlaczego, co sobie uroiłeś i skąd się wzięło, a co
byś chciał wiedzieć od nas. Postaw też znaki zapytania przy pytaniach
- uprzednio te pytania formułując.
Wtedy będzie Ci można pomóc, a tak, to to jest burdel, nie post i
kierować go do wróżki, a nie na grupę...

--
Marek Lewandowski
ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl
my gallery: http://www.pbase.com/mareklew
my kind-of-a-blog: http://lockaphoto.stufftoread.com

Mon Jan 29, 2007 12:12 pm   

On 29 Jan 2007 01:10:13 -0800, robin1978@o2.pl wrote:

No normalnie, jeden wydaje rozkazy, drugi je przyjmuje i realizuje.


I2C jest o tyle wredne ze musisz miec procka ze sprzetowym
odbiornikiem. Latwiej znajdziesz uC z odbiornikiem RS [tzn serial
asynchroniczny - prawie kazdy] czy SPI.


dorobic sobie cos na FPGA/CPLD ?
Choc w zasadzie to 25 chyba sie miesci w mozliwosciach jednego procka
z dekoderem - no moze dwa dekodery, albo 2*(uC+dekoder).
Musi miec sprzetowy timer generujacy 1 impuls, wybieramy wlasciwe
serwo, odpalamy impuls, jak sie skonczy przelaczamy na nastepne i znow
odpalamy.

J.

Mon Jan 29, 2007 1:10 pm   

Dokładnie chodzi mi o to:
- jak połaczyć ze sobą 2 procki (magistrala I2C, czy inna)
- jak napisać oprogramowanie dla obu procków (dla drugiego mniej
więcej wiem, ale jak w drugim "wplątać" w kod jego programu obsługę
drugiego procka)
Drugi ma sterować serwami (wpisane komendy ralaizujące ruchu serwa w
górę, w dól, w bok) oraz obsługa czujników (ma poprostu odciążyć
główny procesor). Pierwszy ma generować chód (skałdać komendy ruchu
serw tak aby poruszały się nogi robota) i na podstawie sygnału z
czujników ewentualnie je modyfikować żeby np. omijać przeszkody.
- robot ma mieć możliwośc sterowania z PC poprzez RS232. CZy obsługę
RSa zaimplementować tylko w :głównym: procesorze, czy w "pomocniczym"
też.
Robert

Mon Jan 29, 2007 9:49 pm   

Niekoniecznie, I2C w przeciwieństwie do RSa nie jest czasowo zależne.
Komunikacja odbywa się z potwierdzeniami więc wystarczy przerwanie i
emulacja programowa I2C. Trywialna w oprogramowaniu, nie zajmująca wiele
cennego czasu.

Przy pracy wieloprocesorowej wystarczy procesorki obdzielić zadaniami i
mogą się wymieniać danymi. Niekoniecznie to musi być Master-Slawe.
Konieczne jest wyznaczenie co jakiś czas sesji komunikacji aby w wypadku
gdy jeden z procków "pójdzie w pyry" drugi wiedział co robić. Mogą sobie
wzajemnie oferować usługę watchdog.
Januszr

Mon Jan 29, 2007 11:07 pm   

On Mon, 29 Jan 2007 21:49:34 +0100, JanuszR wrote:

Nie bardzo. Zegar ma 100 do 400kHz. Tak czesto mozesz miec przerwania,
co na wielu prockach albo nie wyjdzie, albo zajmie je calkowicie.
Potwierdzen przy tym nie ma zadnych, wiec spoznic sie nie mozna.

Dla rozpoznawania sekwencji start/stop musisz miec tez przerwanie
wywolywane zboczem danych - czyli juz drugie. A przeciez kolega chce
cos jeszcze zrobic i przerwania sa mu potrzebne.

Bez sprzetowego odbiornika nie wyjdzie.

J.

Mon Jan 29, 2007 11:35 pm   

J.F. napisał(a):


Aż tak źle to nie jest. Kto powiedział, że i2c musi tak gnać? Przecież
można spokojnie zwolnić do 10 - 20kHz, jeśli tylko pasma starczy.


Jeśli by dać odpowiednio szybki zegar w porównaniu do prędkości
magistrali i2c to można by się z tym wyrobić. Jednak zgodzę się z Tobą
,że to szalenie karkołomne i dużo prostszym/tańszym rozwiązaniem jest
użyć sprzętowy driver i2c.

Pzdro

Mon Jan 29, 2007 11:52 pm   

zegar ma do 400kHz w rozwiązaniach sprzętowych. W praktyce pisałem na
sędziwą 51 12MHz zegar do współpracy z szeregową pamięcią flash.
Poczytaj zasadę komunikacji I2C, komunikacja jest w pełni z
potwierdzeniami. Nie sugeruj się rozwiązaniami sprzętowymi, spokojnie
leci na programie. Jest wolniej ale idzie bezproblemowo. Pisałem RSy na
PICe. Aby to zrobić mając 4MHz zegar i osiągnąć 19200 trzeba się nieżle
nagimnastykować szlifując kod w asemblerze. Z uwagi na uwarunkowania
czasowe RSa strasznie dużo czasu procka szło na oczekiwania bo na
obsługę przerwań już nie można sobie pozwolić bo można się spóźnić. I2C
w porównaniu z RSem to bułka z masłem.
JanuszR

Tue Jan 30, 2007 12:59 am   

On Mon, 29 Jan 2007 23:52:10 +0100, JanuszR wrote:

Czyli proponujesz tak bardzo zwolnic zeby odbiornik na pewno zdazyl ?


No wlasnie - robiles mastera a nie slave. Zupelnie inna para kaloszy.
i znacznie latwiejsza.


Akurat. Potwierdzenie nr dwa to mozliwosc przytrzymania stanu zegara
niskiego przez slave celem spowolnienia. Ale jak twoj softwareowy
slave sie nie wyrobi, to nawet nie zdazy tego zrobic. zgubi bit
a reszta potwierdzen sie juz tylko rozjedzie.


No, a tu piszac slave masz ok 5x szybciej.
Owszem - majac obok mastera w programie mozna i jego zwolnic, nawet
bardziej, ale wtedy on nic nie robi tylko opoznienia odlicza.


Master, nie slave.
A RS nie chce programowo tylko sprzetowego uzyc.

J.

Tue Jan 30, 2007 9:59 am   

Jasne, że mastera bo slave był sprzętowy. Jak zauważyłeś sprawa
trywialna. W wypadku "sieciowej" pracy mikroprocesorków znacznie
elastyczniejsza jest SPI. Też łatwa, wymaga odrobinę więcej przewodów
(pinów). Można przerwać komunikację w dowolnym momencie bez obawy o
straty a przy tym równie szybka jak I2C (oczywiście w wypadku emulacji
programowej) i slave jest znacznie łatwiejszy.


prostu leci z maksymalną prędkością procesorka. Mastera mogę w każdej
chwili zawiesić aby po chwili powrócić do obsługi łącza bez utraty
danych przez slava.

JanuszR

Tue Jan 30, 2007 11:37 am   

On Tue, 30 Jan 2007 09:59:34 +0100, JanuszR wrote:

A kolega chce dwa uC laczyc ze soba. Czyli jeden musi byc slave.
I ten praktycznie _musi_ miec interfejs sprzetowy, bo inaczej
nie wyrobi.

Jak znajdzie takowy - pieknie. Ale latwiej mu bedzie znalezc
z innym interfejsem.


Niestety nie w przypadku slave programowego :-)

A i w przypadku jak master jest szybki, to moze sie okazac ze
przekroczyl tych 400kHz i sprzetowe slave nie odbieraja.
[patrz niedawny post]
Trzeba wsadzic w program opoznienia, a procek sterujacy czasem ma co
robic i marnowac czas na petle opozniajace szkoda.

J.

Tue Jan 30, 2007 12:51 pm   

Tak, dlatego najlepszy jest SPI programowy bo wtedy połaczenie i
czterech procków nie stanowi problemu. Niestety aby było mało kabelków
musimy dać wyjścia typu otwarty kolektor co w większości procków jest
łatwe do ustawienia. Jeżeli nie chcemy marnować czasu procesora na
badanie zajętości magistrali, wyczekiwanie i konkurencję dostępu, plus
jeden pin na znacznik zajętości magistrali czyli w sumie 3 kabelki. W
wypadku programowego mastera slave nie musi być aż tak szybki. Nie musi
być to I2C sprzętowy w każdym razie nie do końca. Do badania stanu linii
doskonale nadają sie timery wbudowane w wiekszość mikrokontrolerów. Takt
wysoki zegara I2C wyzwala timer i ten próbkuje powiedzmy 4 razy stan
linii danych aż do momentu opadnięcia stanu zegara. Wyzwolenie timera
oczywiście obsłużone przerwaniem. Mikrokontroler w tym czasie zajmuje
się swoją robotą, za wyjątkiem obsługi 4 przerwań timera. W wypadku
programowej emulacji interface zarówno po stronie Master jak i Slave nie
musimy stosować standardów komunikacji np. I2C. Możemy dać własny
protokół. Chciałem tylko powiedzieć, że do obsługi typowych kości ze
sprzętowym I2C z reguły będących slave (jak pamięci, display'e) z
powodzeniem możemy stosować interface programowe jako master. Nie musimy
koniecznie szukać procka ze sprzętem bo obsługa takiego łącza niewiele
czasu kosztuje.
Pozdrawiam JanuszR