Podstawy projektowania systemów mikroprocesorowych, cz. 12.pdf

K U R S

Podstawy projektowania systemów

mikroprocesorowych, część 12

W†tej czÍúci kursu skupi³em siÍ na omÛwieniu zasad montaøu

i†uruchamiania urz¹dzeÒ elektronicznych, zw³aszcza tych, ktÛre

wykonano z uøyciem mikrokontrolerÛw. Zasady te maj¹†walor

uniwersalnoúci, wiÍc mog¹ przydaÊ siÍ takøe elektronikom

zajmuj¹cym siÍ technik¹ analogow¹.

Montaø i†uruchamianie

systemu mikroprocesorowego

Maj¹c gotowy projekt urz¹dzenia,

moøemy przyst¹piÊ do jego wykona-

nia. W†przypadku firm zajmuj¹cych

siÍ masow¹ produkcj¹ tego rodzaju

urz¹dzeÒ wiele etapÛw produkcji re-

alizowanych jest jednoczeúnie, czego

jednak nie moøna zastosowaÊ w†przy-

padku uk³adu amatorskiego, gdzie za-

zwyczaj ca³¹ pracÍ wykonuje jedna

osoba w nastÍpuj¹cych etapach:

- projektowanie i†wykonanie p³ytki

drukowanej oraz montaø elementÛw,

- uruchamianie i†testowanie czÍúci

sprzÍtowej,

- pisanie programu,

- uruchamianie i†testowanie progra-

mu.

Postaram siÍ przedstawiÊ zasady

postÍpowania w†poszczegÛlnych eta-

pach prac oraz zwrÛciÊ uwagÍ na

pu³apki czyhaj¹ce na konstruktorÛw.

przesad¹ sprawdzenie kaø-

dej úcieøki omomierzem

przed i†po wykonaniu

montaøu.

Mikrokontroler naleøy umieú-

ciÊ w†podstawce, najlepiej precyzyj-

nej, wysokiej jakoúci, gdyø na etapie

uruchamiania oprogramowania bÍdzie

on wielokrotnie wyjmowany w†celu

zmiany zawartoúci pamiÍci Flash.

Podczas projektowania p³ytki dru-

kowanej naleøy pamiÍtaÊ o†takim u³o-

øeniu elementÛw, aby w†pobliøu krÛt-

szej krawÍdzi mikrokontrolera (w

obudowie DIP) nie by³o øadnych

przeszkÛd (np. wysokich kondensato-

rÛw, przekaünikÛw) uniemoøliwiaj¹-

cych ³atwe wyjÍcie go z†podstawki

(przez np. podwaøenie úrubokrÍtem).

Brak dobrego ìdojúciaî w†najlepszym

przypadku skoÒczy siÍ po³amaniem

nÛøek mikrokontrolera.

na inny o†mniejszej up³ywnoúci. Pod-

czas tych prÛb nie naleøy obawiaÊ

siÍ, øe coú z³ego stanie siÍ z†uk³a-

dem wskutek braku programu w†mik-

rokontrolerze - jeøeli testy przeprowa-

dzimy z†mikrokontrolerem fabrycznie

nowym (lub wczeúniej uøywanym, ale

wyzerowanym), to podczas jego pra-

cy na wyprowadzeniach bÍd¹ utrzy-

mywa³y siÍ stany linii takie jak po

wyzerowaniu, a†wspÛ³pracuj¹cy z†mik-

rokontrolerem uk³ad musi byÊ na ta-

ki stan odporny. Dzieje siÍ tak dla-

tego, øe ca³a pamiÍÊ programu wy-

pe³niona jest jedynkami logicznymi,

co w†przekszta³ceniu na instrukcje

asemblera przek³ada siÍ na cykliczne

wykonywanie instrukcji MOV R7,A,

ktÛra nie ma wp³ywu na stan wy-

prowadzeÒ.

Po sprawdzeniu elementÛw wp³y-

waj¹cych na poprawn¹ pracÍ mikro-

kontrolera naleøy wyj¹Ê go z†pod-

stawki i†przejúÊ do testÛw uk³a-

dÛw†peryferyjnych. W†tym celu na

okreúlonych wyprowadzeniach mikro-

kontrolera wywo³ujemy stany logicz-

ne odpowiadaj¹ce sekwencjom steru-

j¹cym poszczegÛlne urz¹dzenia - je-

dynkÍ logiczn¹ uzyskujemy ³¹-

cz¹c†wyprowadzenie do Vcc mikro-

kontrolera poprzez rezystor 10...47

Etap 2

Po zmontowaniu urz¹dzenia nale-

øy przeprowadziÊ sprawdzenie popra-

wnoúci jego dzia³ania. Na pocz¹tku

do³¹czamy do urz¹dzenia zasilanie

(najlepiej stosowaÊ zasilacze z†ograni-

czeniem pr¹dowym) i†sprawdzamy na-

piÍcia w†uk³adzie, zw³aszcza na szy-

nie zasilaj¹cej. Jeøeli wszystko jest

w†porz¹dku, to moøemy przyst¹piÊ do

testÛw.

Najpierw wk³adamy w†podstawkÍ

mikrokontroler (oczywiúcie po od³¹-

czeniu zasilania) i†sprawdzamy dzia-

³anie oscylatora kwarcowego generu-

j¹cego sygna³ zegarowy. Oscylosko-

pem lub czÍstotliwoúciomierzem

sprawdzamy przebiegi na wyprowa-

dzeniu XTAL1 lub XTAL2 przy uøy-

ciu wysokoimpedancyjnej sondy.

W†przypadku ìduøychî '51 moøna

rÛwnieø sprawdziÊ wystÍpowanie

przebiegu na wyprowadzeniu ALE.

OprÛcz sprawdzenia przebiegÛw zega-

rowych naleøy rÛwnieø woltomierzem

sprawdziÊ wyprowadzenie koÒcÛwki

RESET - napiÍcie na tym wyprowa-

dzeniu nie powinno przekraczaÊ 1†V†-

jeøeli jest inaczej, to naleøy wymie-

niÊ kondensator obwodu zerowania

, natomiast zero logiczne uzysku-

jemy zwieraj¹c wyprowadzenie do

masy. W†ten sposÛb moøemy spraw-

dziÊ dzia³anie wiÍkszoúci uk³adÛw

wspÛ³pracuj¹cych z†mikrokontrolerem.

Niestety nie jest moøliwe spraw-

dzenie w†ten sposÛb skomplikowa-

nych uk³adÛw synchronicznych, re-

aguj¹cych na sekwencje stanÛw linii

- po prostu nie bÍdziemy w†stanie

ich wygenerowaÊ, chociaøby wskutek

wielokrotnych impulsÛw powstaj¹cych

przy do³¹czaniu wyprowadzeÒ do ma-

sy czy Vcc. W†tym przypadku pozo-

staje nam jedynie sprawdzenie popra-

wnoúci po³¹czenia elektrycznego kon-

kretnej nÛøki mikrokontrolera z†wy-

prowadzeniem wspÛ³pracuj¹cego ele-

mentu. Na tym etapie naleøy rÛwnieø

sprawdziÊ napiÍcia poziomÛw logicz-

nych na wyprowadzeniach poszcze-

Etap 1

Jeøeli konstruktor wykona³ kiedy-

kolwiek jakieú urz¹dzenie elektronicz-

ne, to w†zasadzie nie potrzebuje øad-

nych dodatkowych informacji do re-

alizacji tego etapu projektu. Obowi¹-

zuj¹ce zasady postÍpowania s¹ iden-

tyczne jak w†przypadku innych urz¹-

dzeÒ elektronicznych. Naleøy jedynie

pamiÍtaÊ o†tym, aby zwracaÊ uwagÍ

na elektryczn¹ poprawnoúÊ i†czystoúÊ

montaøu - jakiekolwiek zimne luty,

zwarcia, pÍkniÍcia úcieøek czy inne

tego rodzaju uszkodzenia mog¹ byÊ

bardzo trudne do wykrycia, zw³asz-

cza jeøeli pojawi¹ siÍ na liniach, ktÛ-

rych stan moøe byÊ trudny do okreú-

lenia podczas pracy programu (np.

magistrale danych czy adresowe, li-

nie portu szeregowego). Nie bÍdzie

Elektronika Praktyczna 2/2004

K U R S

gÛlnych uk³adÛw, aby unikn¹Ê k³o-

potÛw z ich†interpretacj¹ przez mik-

rokontroler na etapie uruchamiania

programu.

Po sprawdzeniu wszystkich ele-

mentÛw uk³adu i†usuniÍciu ewentual-

nych nieprawid³owoúci moøemy przy-

st¹piÊ do pisania programu.

³owych, ale mniej istotnych z†punk-

tu widzenia uøytkownika urz¹dzenia.

Przyk³adow¹ sekwencjÍ prac przed-

stawiono poniøej:

- Oprogramowanie timerÛw i†ewentu-

alnie obs³ugi ich przerwaÒ wyko-

rzystywanych do synchronizacji

pracy poszczegÛlnych elementÛw

programu.

- Napisanie procedury obs³ugi wy-

úwietlacza i†prÛba wyúwietlenia ja-

kiejkolwiek informacji.

- Napisanie procedury obs³ugi klawia-

tury.

- Przygotowanie procedur obs³uguj¹-

cych komunikacjÍ z†uøytkownikiem,

np. wyúwietlanie komunikatÛw, pre-

zentacja wynikÛw, reakcja na na-

ciskanie klawiszy.

- Przygotowanie fragmentÛw programu

zwi¹zanych z†elementami wspÛ³pracu-

j¹cymi: obs³uga RS-232, I 2 C, do³¹czo-

nych przekaünikÛw, czujnikÛw itp.

- Przygotowanie funkcji realizuj¹cych

pomiary czy w†inny sposÛb pozys-

kuj¹cych dane.

- Przygotowanie procedur obliczenio-

wych wykonuj¹cych operacje na

gromadzonych danych i†wyznaczaj¹-

cych wyniki obliczeÒ przeznaczone

do prezentacji.

Zaprezentowana sekwencja nie

musi byÊ identyczna dla kaødego

systemu mikroprocesorowego, najlepiej

jednak jest, gdy program przygotowu-

jemy z†grubsza zgodnie z†przep³ywem

danych, gdzie wyniki dzia³ania jed-

nej czÍúci programu s¹ danymi dla

innej.

Podczas pisania oprogramowania

obs³ugi kolejnych urz¹dzeÒ czy reali-

zuj¹cych obliczenia, zawsze naleøy

uwzglÍdniaÊ wszystkie moøliwe do

wyst¹pienia sytuacje. Chodzi tutaj np.

o zak³Ûcenia zwi¹zane z†transmisj¹

RS-232 (koniecznoúÊ wprowadzenia

maksymalnego czasu oczekiwania na

dane), przepe³nienie zakresu liczbo-

wego podczas obliczeÒ (przewidywa-

nie maksymalnej wartoúci wynikÛw)

i†inne, a†takøe o†odpornoúÊ np. na

nieodpowiednie kombinacje przyciska-

nych klawiszy, kilka klawiszy wciú-

niÍtych jednoczeúnie, prÛba wprowa-

dzenia parametru spoza dozwolonego

zakresu, itp.

Wszystkie problemy tego rodzaju

powinny byÊ uwzglÍdnione i†odpo-

wiednio rozwi¹zane. Naleøy takøe pa-

miÍtaÊ o†praktycznym sprawdzeniu

tych zabezpieczeÒ (czyli sprÛbowaÊ

wywo³aÊ takie zdarzenie).

W†przypadku, gdy napisany przez

nas program nie dzia³a lub dzia³a

nieprawid³owo, naleøy oczywiúcie od-

naleüÊ b³¹d i†go usun¹Ê. Poszukiwa-

nia b³Ídu wbrew pozorom nie na-

leøy†rozpoczynaÊ od ìgrzebaniaî

w†kodzie ürÛd³owym, ale od zastano-

wienia siÍ nad algorytmem wykorzys-

tywanym do wykonania danej opera-

cji. CzÍsto na tym etapie moøna zna-

leüÊ jakiú b³¹d†w†rozumowaniu czy

inny b³¹d algorytmu. Po upewnieniu

siÍ co do poprawnoúci algorytmu mo-

øemy zacz¹Ê sprawdzaÊ kod ürÛd³o-

wy. Najpierw naleøy sprawdziÊ, czy

napisany przez nas program realizuje

okreúlony algorytm - b³Ídy jak zwyk-

le tkwi¹ w†szczegÛ³ach: np. licznik

licz¹cy od 1†zamiast od 0†(lub od-

wrotnie), üle okreúlone skoki warun-

kowe (przy nieprawid³owym warun-

ku), brak rozkazu powrotu do pro-

gramu g³Ûwnego (jeøeli procedura wy-

wo³ywana przez LCALL), itp.

Niekiedy pojawiaj¹ siÍ problemy

ujawniaj¹ce siÍ dopiero przy wywo-

³ywaniu konkretnych fragmentÛw pro-

gramu, na przyk³ad zbytnie rozrasta-

nie siÍ stosu zwi¹zane z†duø¹ liczb¹

wywo³aÒ LCALL - powoduje to za-

mazywanie najniøej leø¹cych komÛrek

pamiÍci przechowuj¹cych istotne da-

ne.

Etap 3

Naleøy pamiÍtaÊ, øe jest potrzeb-

ny jakiú czas na wykonywanie po-

szczegÛlnych instrukcji, a†zw³aszcza

czas wykonywania pÍtli, ktÛry moøe

byÊ bardzo d³ugi mimo niezbyt

skomplikowanej sekwencji rozkazÛw.

Naleøy o†tym pamiÍtaÊ zw³aszcza

podczas pisania procedur obs³ugi

przerwaÒ - zbytnio rozbudowana pro-

cedura obs³ugi przerwania moøe ca³-

kowicie zablokowaÊ pracÍ programu

g³Ûwnego (kolejne wywo³anie prze-

rwania zanim zakoÒczy siÍ dzia³anie

programu obs³ugi poprzedniego).

Z†punktu widzenia czysto doku-

mentacyjnego warto zadbaÊ o†wprowa-

dzanie komentarzy do kodu ürÛd³o-

wego opisuj¹cych krok po kroku

dzia³anie programu oraz przyjÍcie na-

zewnictwa etykiet opisuj¹cych komÛr-

ki pamiÍci zgodnych z†przechowywa-

n¹ zawartoúci¹ (np. WYNIK,

BAJT_WEJSCIOWY, BLOKADA, itp.).

Znakomicie u³atwi to ewentualne mo-

dyfikowanie programu opracowanego

np. pÛ³ roku temu - same suche in-

strukcje asemblera niestety nie mÛ-

wi¹ zbyt wiele, zw³aszcza jeøeli nie

pamiÍtamy juø dzia³ania poszczegÛl-

nych blokÛw programu.

Oczywiúcie, program nie musi byÊ

pisany w†asemblerze - obecnie do

dyspozycji projektantÛw wykorzystuj¹-

cych w†swoich projektach mikrokont-

rolery '51 jest wiele rÛønych kompi-

latorÛw jÍzyka C, Pascal czy Basic.

Uruchomienie oprogramowania

i†zakoÒczenie jego testÛw w†zasadzie

koÒczy proces budowy uk³adu mik-

roprocesorowego. Pozostaje jeszcze

przygotowanie odpowiedniej obudowy

i†moøna przyst¹piÊ do uøywania za-

projektowanego, wykonanego i†oprog-

ramowanego urz¹dzenia.

ZakoÒczenie

Mam nadziejÍ, øe prezentowany

artyku³ przybliøy³ Czytelnikom zagad-

nienia zwi¹zane z†projektowaniem

systemÛw mikroprocesorowych, a†tak-

øe zwrÛci³ im uwagÍ na fakt,

øe†wbrew pozorom zbudowanie urz¹-

dzenia z†mikrokontrolerem nie jest

ani trudne, ani drogie, a†pe³en suk-

ces zaleøy wy³¹cznie od przestrzega-

nia kilku prostych zasad oraz trzy-

mania siÍ wskazÛwek producenta do-

tycz¹cych parametrÛw†wykorzystywa-

nych uk³adÛw.

Korzystaj¹c z nowoczesnych pakie-

tÛw uruchomieniowych, rÛwnieø op-

rogramowanie takiego systemu nie

jest trudne, a†nic tak przecieø nie

cieszy jak samodzielnie opracowane

urz¹dzenie wyposaøone we wszystkie

potrzebne funkcje, ktÛrego dzia³anie

znamy od podszewki i†w†razie ko-

niecznoúci bÍdziemy potrafili dowol-

nie je zmodyfikowaÊ.

ØyczÍ wszystkim Czytelnikom suk-

cesÛw w†projektowaniu urz¹dzeÒ

z†mikrokontrolerami i†wydaje mi siÍ,

øe jednym z†efektÛw publikacji tego

cyklu bÍdzie duøa liczba urz¹dzeÒ

mikroprocesorowych prezentowanych

w†EP, rÛwnieø w†dziale ìProjekty

CzytelnikÛwî.

Pawe³ Hadam, EP

pawel.hadam@ep.com.pl

Etap 4

Etap tan jest w†zasadzie najbar-

dziej pracoch³onny - rzadko bowiem

siÍ zdarza, øe napisany program ìru-

szaî za pierwszym razem i†pracuje

bez b³Ídu.

Nie bez powodu wúrÛd progra-

mistÛw kr¹øy pogl¹d, øe napisanie

programu to 10% pracy, nastÍpne

90% to usuwanie b³ÍdÛw i†wprowa-

dzanie zabezpieczeÒ zwi¹zanych

z†wystÍpowaniem sytuacji nietypo-

wych. Dlatego juø na etapie pisania

programu warto zaplanowaÊ podzia³

pracy na kilka czÍúci i†uruchamianie

kaødego fragmentu programu oddziel-

nie, dopiero po stwierdzeniu popra-

wnoúci dzia³ania czÍúci poprzedniej.

Najlepiej zacz¹Ê†od elementÛw pro-

gramu przydatnych do testowania

kolejnych czÍúci, a†nastÍpnie prze-

chodziÊ do funkcji bardziej szczegÛ-

Elektronika Praktyczna 2/2004

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: