Uk?ad z 2 mikroprocesorami w systemi - programowanie

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

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.

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

Witam, 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

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.

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

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

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.

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.

Nie ma potrzeby zwalniać bardziej niż potrzeba i idliczać opóźnienia. Po 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

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.

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