mikrokontrolery peryferyjne

U¿ytkownik "peters" snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news:cqpiur$bdo$ snipped-for-privacy@nemesis.news.tpi.pl...

Takim mikrokontrolerem jest np. PIC 16F877. Mo¿na go do³±czyæ do magistrali dowolnego systemu ktory potrafi gadaæ z 8-bitowymi peryferiami. Oczywi¶cie nie nale¿y przesadzaæ z transferem, bo musi on miec czas na reakcje po wykonaniu zapisu lub odczytu. Ale on nie ma DP-RAM...

ARC

I to jest wlasnie podstawowy problem. Sa rozne proste sposoby na laczenie procesorow, ale maja jedna zasadnicza wade -transfer. Nawet nie chodzi o to, ze sie nie wyrobie czasowo. Chodzi o to, ze musze rzygac bajt po bajcie. Miedzy bajtami przerwy sa na tyle dlugie, ze nie oplaca sie czekac w petli. Sa jednak na tyle krotkie, ze wysylajac dane na przerwaniu bardzo wiele trace. Operacje dodatkowe zwiazane z obsluga przerwania trwaja dlugo i znaczaco obciazaja procesor. Gdyby przynajmniej fifo tam bylo ... Procesory peryferyjne stosuje sie przeciez aby odciazyc procesor glowny, a nie po to by zajac go czasochlonna obsluga transmisji.

peters

Bardzo wygodne w takim zastosowaniu jest użycie portu szeregowego, najlepiej synchronicznego (z zegarem). Wtedy z jednego procesora wysyłasz paczkę danych np. z użyciem DMA (nie tracąc czasu na wpychanie kolejnych bajtów danych do USARTu), a drugim procesorem odbierasz. Wolniejszy procesor powinien taktować transmisję. Kilka Mbps można osiągnąć bez problemu (zależy jeszcze z czym gadasz, wiadomo że nie przy '51 @ 1 MIPS), szczególnie łącząc dwa "organizmy" o podobnej wydajności, np. ARMy czy DSPki.

Wydaje mi siê, ¿e nale¿y zacz±æ od za³o¿eñ. a) Jaki transfer jest zadawalaj±cy ? b) Ile bajtów nale¿y przenie¶æ ? lub c) ile czasu mo¿na po¶wiêciæ na przekazywanie danych ?

Inaczej pisz±c, nale¿y najpierw ustaliæ maksymaln± prêdko¶æ, a potem dobraæ procesor, zapewniaj±cy ten transfer. Je¶li PIC16F877 jest niewystarczaj±cy, nale¿y wybraæ inny - mo¿e z serii 18F np. 18F4320 (512 bajtów RAM, PSP - Parallel Slave Port, max. Fclk= 40MHz/

Procesor moze i fajny, ale to niczego nie zmienia. Zostawmy na razie transfer. Mymy taka sytuacje. Procesor glowny musi przeslac do procesora slave powiedzmy 100 bajtow danych. Chce to zrobic natychmiast, bo za chwile zajmie sie innym waznym zadaniem. Procesor slave wykonuje co jakis czas krytyczne czasowo operacje i wylacza w tym czasie przerwanie. Z tego co widze to w tych PICkach transmisja opiera sie na przerwaniach. Co bajt to przerwanie. W tym momencie klapa, PIC danych nie odbierze a procesor glowny bedzie musial czekac.

peters

No to teraz mamy jasn± sytuacjê. W zwi±zku z powy¿szym, widzê, ¿e jest to system z kolejkowaniem zadañ. Czyli kolega chce mieæ MASTERA i SLAVEA. W ten sposób mamy dwa zasoby. Dodatkowo MASTER ma zarz±dzaæ zadaniami. Typ zarz±dzania jest prosty: MASTER decyduje, czy zadanie ma byæ wykonane przez SLAVEa. Je¶li zadanie jest dla SLAVEa to przesy³a do niego "zlecenie". SLAVE natomiast ma na sta³e przypisane swoje zadania. Problem w tym, ¿e nie mo¿e przyj±æ "zlecenia", w czasie, gdy wykonuje w³asne zadanie. W zwi±zku z powy¿szym jest problem typu GONIEC. Rozwi±zania proponowa³bym nastêpuj±ce: a) dual port RAM - owszem dobry, ale nie rozwi±zuje wszystkich problemów. Trzeba zaimplementowaæ metodê przekazywania informacji o nowym zleceniu i o zakoñczeniu realizacji. b) trzeci procesor jako goniec. Rozwi±zanie ciekawe, ale komplikuje nieco uk³ad c) programowalny uk³ad logiczny zamiast dual RAM. To wydaje siê równie¿ ciekawe, a w miarê nieskomplikowane. d) daæ jeden szybki procesor, który obs³u¿y wszystkie zadania, kolejkuj±c je, lub przydzielaj±c im jednakow± porcjê czasu. e) Inna propozycja: Mo¿e jednak tylko MASTER i SLAVE, ale okre¶liæ moment czasowy transmisji. Wydaje mi siê, ¿e ostatni pomys³ jest ciekawym wyzwaniem, a mo¿e nie tak trudnym, jak by siê wydawa³o. Proszê zauwa¿yæ, ¿e MASTER nie musi wysy³aæ zlecenia w chwili, gdy SLAVE jest zajêty, gdy¿ i tak SLAVE nie ma czasu, aby je wykonaæ. Mo¿e mo¿na zaczekaæ z transferem, do czasu, kiedy SLAVE znajdzie trochê czasu? Warunkiem tutaj musi byæ istnienie takiego odcinka czasu, potrzebnego na przes³anie danych, kiedy oba procesory mog± mieæ wolny czas. Wtedy tylko (bez dodatkowych rozwi±zañ sprzêtowych lub bardziej zaawansowanych, dro¿szych procesorów) wydaje siê mo¿liwe zrealizowanie tego pomys³u. Chodzi o to, ¿e nie mo¿na pomin±æ czasu transmisji. Czas transmisji równie¿ nale¿y traktowaæ, jako ZADANIE i równie¿ trzeba je kolejkowaæ. Przy czym mamy tu 2 czasy transmisji (nawet jak uda siê znale¼æ DPRAM) Tt MASTERA oraz Tt SLAVEA. £±czny czas wykonania transmisji bêdzie wynosi³ TtM+TtS i nie da siê go pomin±æ, ale byæ mo¿e da siê go skróciæ. Zale¿y to od faktu: czy czas zapisu do SLAVEa mo¿e byæ krótszy ni¿ do DPRAM? Je¶li tak, to mo¿e warto znale¼æ czas na wspóln± transmisjê, wtedy rozwi±zanie sprzêtowe bêdzie bardziej proste. Mam nadziejê, ¿e pomog³em :-) pozdrawiam Sylwester £azar

Mniej wiecej, tyle ze mam dwa SLAVEy. Kolejkowania zadan tez nie mam, raczej jest wiele zadan roznych typow.

Niestety rozwiazanie dosc kosztowne. Potrzebne ok 32KB. Dlatego wlasnie pytam o procesory z wbudowanym dual port RAM.

Masz na mysli takiego PICa z slave portem? jak go podlaczyc do mastera to oczywiste, ale jak prosto do SLAVEa?

z pewnych przyczyn nie wchodzi w gre.

Moze. Ale komunikacja przez 8-bitowy port to jak zagladanie przez dziurke od klucza. Przesylanie kazdorazowo wszystkich danych jest bezcelowe. Trzeba podczas takich sesji posprawdzac co jest do przeslania w jedna i druga strone a potem przeslac tylko istotne dane. Wydaje mi sie, ze taka transmisja troche potrwa - odpowiedzi na porcie SLAVEa nie pojawiaja sie natychmiast.

W tej chwili transmisja funkcjonuje w oparciu o dodatkowy RAM, widoczny na zmiane w przestrzeniach adresowych kazdego z 3 procesorow. Jesli mialbym je zmieniac, to na cos bardziej wygodnego, szybszego i wymagajacego mniej US.

peters

Przyznam, ze nie do konca rozumiem. Chodzi Ci o procesor, ktory potrafi nadac i odebrac sprzetowo caly blok danych przez synchroniczny port szeregowy? Rodzina 167 Infineona (moj procesor glowny) ma cos takiego jak PEC, ale i tak synchroniczny port szeregowy mam juz zajety przez karty pamieci SD. Moze wiec jakis dodatkowy uklad DMA? 167 mozna odciac na chwile od magistrali. Ale transmisja musialaby byc bardzo szybka.

peters

O czym jeszcze siê dowiemy w nastêpnych odcinkach :-) Czyli pewnie kolejkowanie jest - okre¶lone poprzez prze³±czanie RAMu do kolejnych przestrzeni adresowych. Bez kolejkowania oznacza, ¿e s± 3 procesory i ka¿dy wykonuje swoj± robotê.

Ten procesor ma wiêcej portów :-) PSP dzia³a na porcie D, a na E ma linie sygna³owe programowy port równoleg³y mo¿na daæ na C, a potrzebne linie sygna³owe na A. Ja bym pod³±czy³ siê z GOÑCEM sprzêtowym PSP do MASTERA, a programowo obs³u¿y³ komunikacjê ze SLAVEM. Je¶li SLAVE by³by procesorem tego samego typu, to pod³±czy³bym go przez jego PSP do GOÑCA. Czyli: SLAVE PSP <=>SOFT GONIEC PSP <=> MASTER SLAVE niech tylko wystawia sygna³ np. pGO=1 (gdy ma czas), ¿e chce dane, a GONIEC mu je sukcesywnie bêdzie wysy³a³. Gdy SLAVE siê rozmy¶li to wystawia pGO=0 i SLAVE siê wstrzymuje.

No a jak trzeba by drugiego SLAVA podpi±æ do goñca to te¿ jest to mo¿liwe, ale ju¿ zaczyna brakowaæ portów.

Wtedy powstanie inteligentna prze³±cznica GONIEC na 1 scalaku. Ale to ju¿ jest du¿o bardziej skomplikowane, choæ mo¿liwe.

P³ytka drukowana jest wtedy bardzo rozbudowana. Widzê tutaj minimum 4 warstwy, choæ pewnie i tak ju¿ jest, bo przecie¿ prze³±czany RAM to jeszcze wiêksze wyzwanie projektowe dla PCB :-)

Jest jeszcze jedna opcja: Powa¿na propozycja jest od Pana Adama. (BTW: ¶wietny Debugger dla 51 - u¿ywa³em go parê lat temu. Gratulujê!) Mo¿na to po³±czyæ: MASTER || GONIEC --- SLAVE Równolegle dane do GOÑCA, a szeregowo, synchronicznie z du¿± prêdko¶ci± do SLAVEa lub SLAVEów. Mog³aby byæ du¿o ³adniejsza p³ytka. Choæ nieco wiêcej zachodu w programie, ale to jak zwykle jest dyskusyjne:-) pozdrawiam Sylwester £azar