wyklad 4.pdf

Hit roku 2000

BASCOM College

Wykład 4

Witam Studentów BASCOM College na ko−

lejnym wykładzie. Poprzedni wykład rozpo−

cząłem od stwierdzenia, że jestem w znako−

mitym nastroju, spowodowanym mailami od

Czytelników, którzy aktywnie włączyli się

w nasz program zajęć i owocnie próbują sa−

modzielnego myślenia i pisania programów.

Minął miesiąc i mój nastrój polepszył się je−

szcze bardziej. Powód jest ten sam: nie przy−

puszczałem nawet, że tak wielu Kolegów

osiągnie tak dobre rezultaty już w pierwszym

okresie istnienia BASCOM College . Właści−

wie, to może powinienem się martwić, bo je−

żeli uczniowie zaczynają prześcigać mi−

strzów.... Ale po kolei, pora na mały rachu−

nek sumienia!

Z pewnością wielu Czytelników czytając

wykład o sterowaniu wyświetlaczy alfanu−

merycznych LCD zauważyło, że ten tekst

miejscami trochę się “nie kleił”. Od razu za−

częliśmy od “dużych” wyświetlaczy, pomija−

jąc najprostsze, jakimi są wyświetlacze 16*1

znaków. Wyraźnie autor kluczył dookoła te−

go tematu, ale nigdy go nie poruszał. Tak

właśnie było, lawirowałem jak mogłem, po−

nieważ obsługa tych właśnie wyświetlaczy

napotyka jeszcze w BASCOMie na spore

trudności, nie spotykane przy wyświetla−

czach 16*2 i jakichkolwiek innych. Nasz

mistrz, Mark, przesiedział nad tym proble−

mem niejedną noc, ja także dołożyłem swój

wkład pracy w próby jego rozwiązania. Nie−

stety, nasze wysiłki spełzły na niczym. Wy−

świetlanie statycznych napisów działa po−

prawnie, natomiast problemy zaczynają się

przy przesuwaniu napisu lub kursora. Nie po−

maga używanie polecenia konfiguracyjnego

CONFIG LCD = 16*1,a po wydaniu polece−

nia SHIFTLCD napis dzieli się na dwie poło−

wy, z których każda “zaczyna żyć własnym

życiem”. Powód tego jest dość oczywisty:

wyświetlacz 16*1 jest z punktu widzenia ste−

rującego nim programu wyświetlaczem 8*1.

Mark badał ten problem, ale słusznie stwier−

dził, że producenci wyświetlaczy 16*1 stosu−

ją dziwne procedury ich obsługi i że nie bar−

dzo jest w stanie zaproponować jakieś sen−

sowne rozwiązanie problemu z przewijaniem

napisów. Problem w gruncie rzeczy nie jest

zbyt poważny: wyświetlacze 16*2, działają−

ce bez najmniejszych problemów, można ku−

pić w tej samej cenie, co 16*1, a nawet nie−

jednokrotnie taniej. Co jednak mają zrobić ci,

którzy nabyli już displaye 16*1?

Rozwiązanie kłopotliwego problemu

nadesłał mi jeden z Was, kolega Artur Kra−

jewski . Wielkie brawa za błyskotliwe roz−

wiązanie problemu przewijania napisu na

nieszczęsnym wyświetlaczu.

Kolega Artur nadesłał mi także bardzo

“elegancko” napisany program sterowania

silnikiem krokowym . Nie on jedyny, takich

programów otrzymałem wiele i prawie wszy−

stkie napisane były poprawnie, a w każdym

razie wszystkie działały.

Listy Kolegi Artura i innych Czytelników

dały mi wiele do myślenia i zainspirowały do

stworzenia w BASCOM College działu,

który nazwaliśmy BASCOM Forum . Jeżeli

ktoś z Was wpadł na pomysł jakiegoś cieka−

wego rozwiązania programowego, jakiejś in−

teresującej sztuczki, za pomocą której można

w prosty sposób rozwiązać pozornie skom−

plikowany problem programistyczny, to bar−

dzo proszę nadsyłajcie swoje opracowania do

BASCOM Forum , najlepiej na mój adres e−

mail. Chciałbym jednak, abyśmy się dobrze

zrozumieli: nie chodzi mi o skomplikowane

programy, ale wyłącznie o “tips & tricks”,

malutkie programiki w stylu opracowanych

przez Kolegę Artura. Takie listingi będziemy

systematycznie zamieszczać w BASCOM

Forum , oczywiście z podaniem nazwiska

autora. Gorąco zachęcam Was do tej działal−

ności: pamiętajcie, że dla programisty naj−

ważniejsze są inteligencja i wyobraźnia i nie

musicie się wobec tego stresować swoim ma−

łym doświadczeniem.

Także Czytelnicy, którzy napotykają pro−

blemy podczas pisania swoich programów,

proszeni są o nadsyłanie dręczących Ich py−

tań. Opublikujemy je w BASCOM Forum

i być może któryś z Kolegów znajdzie na nie

odpowiedź? Ta forma wymiany informacji

przeznaczona jest przede wszystkim dla tych

z Was, którzy nie posiadają jeszcze stałego

dostępu do Internetu i nie mogą korzystać

z istniejących tam list dyskusyjnych.

Jeśli Wasza aktywność będzie bardzo du−

ża, jeśli otrzymamy dużo listów z opisami

problemów oraz rozwiązaniami problemów,

jeśli ilość tego materiału przerośnie ramy ru−

bryki BASCOM Forum , to mamy już goto−

wą koncepcję wydawania „Biuletynu BA−

SCOM Forum“ − specjalnego dodatku do

EdW, tylko dla prenumeratorów EdW (ok.

98% studentów BASCOM College to prenu−

meratorzy EdW). Łamy tego Biuletynu będą

służyć do wymiany informacji między stu−

dentami BASCOM College .

Chciałbym teraz dokończyć “rachunek

sumienia”, czyli zakomunikować Wam dwie

sprawy, o których zapomniałem wspomnieć

na poprzednich wykładach. Otóż, opisując

konfigurowanie programu BASCOM, nie

wspomniałem o bardzo ważnej opcji, przy−

spieszającej pracę i czyniącej ją bardziej

komfortową. Na usprawiedliwienie mam tyl−

ko jedno: Mark ukrył ją w niezbyt konse−

kwentny sposób w panelu konfigurowania

otoczenia, a nie w okienku, w którym usta−

wiamy parametry pracy programatora. Po−

nadto, opracowując wykład traktujący o kon−

figurowaniu BASCOM−a, znałem dobrze tyl−

ko jego poprzednią wersję, w której opisane

niżej opcje nie występowały.

A zatem, po uruchomieniu BASCOM−

a otwórzcie panel OPTIONS, a następnie

ENVIRONMENT i kliknijcie na przycisk

IDE ( rys.1 ). Następnie zaznaczcie “pta−

szkiem” opcję PROGRAM AFTER COMPI−

LE. Od tego momentu nie będziemy już mu−

sieli po skompilowaniu programu wywoływać

panelu programatora, ani nawet naciskać kla−

wisza F4. Po kompilacji wywołanej klawiszem

Elektronika dla Wszystkich

BASCOM

F7 program automatycznie przystąpi do pro−

gramowania procesora, wyświetlajc stosowa−

ne komunikaty na dole ekranu. Fajne, praw−

da? Żeby tak jeszcze dało się programować

nasze poczciwe “pięćdziesiątki jedynki” bez−

pośrednio w systemie, tak jak procesory

AVR! To dopiero byłby komfort pracy: po

jednym naciśnięciu klawisza moglibyśmy od

razu testować napisany program w jego natu−

ralnym otoczeniu. Szkoda, że procesory

“X051 nie mogą być programowane w trybie

ISP (In System Programming). Nie mogą, je−

steście tego pewni? No to zajrzyjcie do naszej

stałej rubryki opisującej nowości z ostatniej

chwili, przygotowałem tam dla Was niezłą

niespodziankę!

W wolnej linii napiszmy jakiekolwiek polece−

nie języka MCS BASIC, np. CONFIG. Na−

tychmiast po napisaniu ostatniej litery na ekra−

nie ukazał się napis ( rys.3 ) informujący, do ja−

kich wartości może odnosić się to polecenie.

Zacznijmy od uporządkowania terminolo−

gii, niezbyt jasno zdefiniowanej w BA−

SCOM−ie. Podczas tego wykładu i następ−

nych przyjmiemy następujące określenia:

Emulacja programowa − badanie działa−

nia programu z wykorzystaniem wbudowa−

nego w pakiet BASCOM symulatora. W BA−

SCOM−ie stosowane jest określenie “HAR−

DWARE EMULATION”. Do wykonania tej

symulacji nie są potrzebne jakiekolwiek na−

rzędzia sprzętowe.

Symulacja sprzętowa − badanie działania

programu w środowisku, w którym będzie

następnie pracował zaprogramowany proce−

sor. W BASCOM−ie używane jest określenie

“REAL HARDWARE SIMULATION”. Tyz

piknie, jak mawiają starzy górale, ale nasze

określenia bardziej mi się podobają.

W poniższej tabeli zamieszczone zostało

zestawienie funkcji, jakie możemy testować

w każdym z rodzajów symulacji.

Niezły bajerek, ale o jego stosowaniu mu−

sicie już sami zadecydować. Ważne jest to, że

podpowiedzi pojawiające się na ekranie mo−

żemy dowolnie edytować, dostosowując je

do swoich potrzeb, a także dodawać nowe,

związane z dowolnymi słowami. Plik z pod−

powiedziami znajduje się w głównym katalo−

gu BASCOM−a i posiada nazwę: BA−

SCOM.KRF. Poniżej zamieszczony jest

fragment tego pliku wraz z drobnymi zmia−

nami, jakie pozwoliłem sobie w nim poczy−

nić. Oczywiście, nie

ma najmniejszego

znaczenia, w jakim

języku redagowany

jest ten plik i czy sto−

sowane są w nim pol−

skie znaki diakrytycz−

ne.

DISABLE|intsource

PRINTHEX|var

SWAP|var,var

DELAY| krótkotrwałe opóźnienie

TO|end [STEP var]

DOWNTO|end [STEP var]

REM|remark

ENABLE|intsource

I2CSEND|slaveaddress,var [,bytes]

I2CRECEIVE|slaveaddress,var [,bytes to

write,bytes to read]

START|timerx

LOAD|timerx

COUNTER| = wartość

EdW| bardzo fajne pismo!

Tyle rachunku sumienia na dzień dzisiej−

szy. Rozpoczynamy wreszcie nasz wykład,

którego głównym tematem będzie symulacja

programowa i sprzętowa.

Funkcja

Emulacja

programowa

Symulacja

sprzętowa

Dwukiierunkowe operacjje na porttach

ii pojjedynczych wyprowadzeniiach porttów Tak Tak

Obsłługa LCD Tak Tak

Odbiiór kodu RC5 Niie Niie

Operacjje mattemattyczne Tak Tak

Przerwaniia Tak Tak,, z ograniiczeniiamii

Tiimery Tak,, z ograniiczeniiamii Tak

Transmiisjja 1WIIRE Niie Tak,, na szybkiich maszynach

Transmiisjja II2C Niie wykorzysttujje siię Tak

Wszellkiie operacjje w czasiie rzeczywiisttym Niie

Popatrzmy jeszcze chwilę na panel IDE.

Mamy tam dwie interesujące opcje. “Zapta−

szkujmy” okienko z napisem DISPLAY LINE

NUMBERS, wyjdźmy na chwilę z powrotem

do okienka edycji programu. Po zaznaczeniu

wymienionej opcji wygląda ono tak, jak poka−

zano na rysunku 2 . Wszystkie linie programu

zostały ponumerowane, z tym, że numeracja ta

ma znaczenie jedynie informacyjne i zostanie

zignorowana przez kompilator. Mnie ta forma

przedstawiania edytowanego programu nie

bardzo się podoba, ponieważ zbyt przypomina

ekran edytora archaicznych dialektów BASIC−

a, stosowanych jeszcze na komputerach 8−bito−

wych. Ale może dla kogoś taka numeracja bę−

dzie ułatwieniem w pracy?

Niie

Generalnie możemy przyjąć następujące

zasady:

1. Wydarzenia zachodzące podczas symu−

lacji, obojętne czy programowej, czy sprzęto−

wej, zawsze zachodzą znacznie wolniej niż

w zaprogramowanym procesorze (co niekie−

dy jest ogromną zaletą!). To spowolnienie

biegu czasu zależy oczywiście od procesora

komputera, na którym prowadzona jest sy−

mulacja, ale nawet najszybszy PENTIUM

nie będzie w stanie umożliwić symulacji wy−

darzeń rozgrywających się w czasie rzeczy−

wistym.

2. Z wyżej wspomnianych powodów nie

jest możliwe symulowanie np. odbioru kodu

RC5, który nadawany jest przez piloty ze sta−

łą szybkością, której w żaden sposób

nie możemy zmienić. Także symulacja trans−

misji 1WIRE napotyka na poważne trudności

i możliwa jest tylko na najszybszych kompu−

terach.

3. Prosta konstrukcja naszego symulatora

sprzętowego nie umożliwia testowania urzą−

dzeń, które wykorzystują wejścia analogowe

procesora. Przez nasz symulator “przecho−

dzą” jedynie sygnały cyfrowe. Oczywiście,

budowa symulatora realizującego tę funkcję

jest możliwa, ale byłoby to urządzenie bar−

dzo skomplikowane i kosztowne. Nie wyklu−

czam jednak powstania takiego symulatora

w przyszłości.

4. Biorąc pod uwagę powyższe zastrzeżenia,

podczas emulowania pracy procesora należy

Emulacja programowa

i symulacja sprzętowa

w programie BASCOM

8051

Możliwość przetestowania napisanego progra−

mu bez konieczności programowania proceso−

ra i umieszczania go w uruchamianym ukła−

dzie jest jedną z największych zalet pakietu

BASCOM. Z listów, jakie otrzymałem od Czy−

telników wiem, że korzystanie z symulatorów

sprawia im nieco kłopotów i że nie wszystkie

opisy zwarte w helpie są dla nich jasne i zrozu−

miałe. Najwyższa więc pora, aby uporządko−

wać nasze wiadomości o symulatorach pakietu

BASCOM i umożliwić wszystkim Czytelni−

kom korzystanie z tych znakomitych narzędzi.

Znacznie ciekawsza jest opcja DISPLAY

HINTS (wyświetl podpowiedzi). Zaznaczmy

ją zatem i powróćmy do edycji programu.

Elektronika dla Wszystkich

BASCOM

skupić się na badaniu zjawisk zachodzących

“wewnątrz” procesora, badać poprawność

pętli programowych, obliczeń dokonywa−

nych przez procesor, a także transmisji I2C,

która może być symulowana sprzętowo bez

najmniejszych problemów.

Na rysunku 4 zostało pokazane otwarte

okno emulatorów. Zaznaczone zostały naj−

ważniejsze funkcje emulatorów, dotyczące

procesorów ‘X051:

samoczynnego zakończenia lub przerwania

emulacji.

4. Przerwa w testowaniu. Przycisk pauzy,

która może ułatwić przeanalizowanie ostat−

nio wykonanych linii programu.

5. Zatrzymanie symulacji. Powoduje za−

trzymanie wykonywanego programu, bez

możliwości wznowienia od momentu zatrzy−

mania.

6. Praca krokami − polecenie po polece−

niu. Bardzo uży−

teczna funkcja

pozwalająca na

dokładne prze−

śledzenie działa−

nia wybranych

fragmentów pro−

gramu. Każde

naciśnięcie tego

przycisku powo−

duje wykonanie

kolejnej linii

programu

7. Wykona−

nie programu od

początku do bie−

żącej linii (linii

zaznaczonej żół−

tą strzałką na

marginesie okna

programu). Tu ważna uwaga: na nie−

których komputerach ta strzałka zacho−

wuje się dziwnie: pojawia się i znika . Nie

wiem, dlaczego tak się dzieje, ale pisałem już

do Marka w tej sprawie.

8. Przyciski służące do generacji prze−

rwań w symulacji programowej i sprzętowej.

Bardzo ważna funkcja, szczególnie podczas

testowania programów wykorzystujących ti−

mery. Symulacja tak bardzo zwalnia pracę

programów, że oczekiwanie na wystąpienie

przerwania timera może być nieco nużące.

Za pomocą przycisków T0 lub T1 możemy to

oczekiwanie znacznie skrócić.

9. Suwak regulacji szybkości emulacji.

Czasami spowolnienie pracy programu wy−

woływane samym faktem symulacji okazuje

się niewystarczające. Suwakiem tym może−

my jeszcze bardziej zwolnić pracę programu

i w ten sposób dokładnie przeanalizować in−

teresujący nas jego fragment.

10. Wyświetlanie zawartości pamięci pro−

gramu. Opcja dla zaawansowanych: powo−

duje wyświetlenie okienka zawierającego

kod aktualnie testowanego programu.

11. Okienko “podglądu” zmiennych wy−

stępujących w programie i rejestrów emulo−

wanego procesora. Fantastyczna sprawa: da−

je możliwość podglądania tego, co dzieje się

w rejestrach timerów i jak zachowują się za−

stosowane w programie zmienne. Napiszmy

sobie prosty programik:

Dim X As Byte

Dim Z As Byte

Dim Y As Byte

Incr X

Decr Z

Y = X − Z

Loop

Większego sensu ten program nie ma, ale

chodzi nam tylko o pokazanie możliwości

podglądu zmiennych występujących w pro−

gramie. Po skompilowaniu tego wybitnego

dzieła programistycznego uruchamiamy sy−

mulacje programową, a w okienko VARIA−

BLES wpisujemy (po naciśnięciu klawiszy

CTRL + ALT + V) zmienne X, Y i Z. Naci−

skamy przycisk uruchamiania programu,

a efekt możemy zobaczyć na rysunku 6 .

1. Uruchamianie symulacji programowej.

Kliknięcie tego przycisku powoduje wyświe−

tlenie panelu zawierającego wyświetlacz

LCD, wyświetlacz siedmiosegmentowy i zo−

brazowane jako diody LED wyprowadzenia

portu 1 i 3 ( rys. 5 ).

12. Okienko kontroli zawartości reje−

strów. Funkcja tego okienka jest nieco

podobna do roli pełnionej przez podgląd

zmiennych. Umożliwia ono jednak obserwa−

cję wszystkich rejestrów wewnętrznych pro−

cesora. Opcja raczej dla zaawansowanych.

Sądzę, że najlepszą metodą poznania za−

równo emulatora programowego, jak i symu−

latora sprzętowego będzie, jak zwykle, do−

świadczenie praktyczne. Zajmijmy się teraz

okienkiem emulacji terminala, wykorzysty−

wanym zarówno w symulacji programowej,

jak i w emulacji sprzętowej. Jest to jedno

z najsilniejszych narzędzi pakietu BASCOM

i musimy poświecić mu chwilę uwagi.

Procesory ‘X051 posiadają wbudowaną

obsługę interfejsu RS232, a transmisja infor−

macji poprzez to łącze jest z poziomu języka

MCS BASIC szczególnie łatwa. Nie musimy

się nawet zastanawiać, jaki jest protokół

transmisji portu szeregowego: po prostu pi−

szemy np. “PRINT [coś tam] i mamy abso−

lutną pewność, że to nasze “coś tam” zosta−

nie wysłane do portu RS232. Podobnie pro−

ste jest odczytywanie danych z tego portu,

sprowadzające się do wydania jednego lub

kilku poleceń. Jednak ekran terminala nie

służy wyłącznie testowaniu programów,

które komunikują się z komputerem lub in−

nym urządzeniem za pomocą interfejsu

RS232. Jest on jeszcze jednym narzędziem

umożliwiającym “podglądanie” testowanego

programu i sprawdzania, czy wykonywany

jest on zgodnie z naszymi oczekiwaniami.

Napiszmy sobie zatem kolejny, nieco dłuż−

szy program. Właściwie powinniśmy uczynić

2. Uruchamianie emulacji sprzętowej.

Przycisk ten uruchamia emulator progra−

mowy, o ile ten jest dołączony do kompu−

tera. Tu bardzo ważne uwagi: włączenie

emulacji sprzętowej bez dołączenia

emulatora programowego połączonego

z badanym układem drastycznie spo−

walnia pracę programu, a w pewnych

przepadkach może nawet spowodować

zawieszenie się komputera. Symulta−

niczna praca obydwu symulatorów jest

możliwa, ale także znacząco spowalnia

pracę.

3. Start testowanego programu. Naciśnię−

cie tego przycisku powoduje rozpoczęcie

wykonywania ostatnio skompilowanego

programu . Program jest wykonywany aż do

Elektronika dla Wszystkich

BASCOM

to nieco później, na ćwiczeniach, ale nie mogę

wprost się powstrzymać, aby nie pokazać

Wam czegoś ciekawego. Naprawdę, to będzie

rzeczywiście ciekawe, choć nieco wyprzedza−

jące nasz program nauczania. W programie

tym po raz pierwszy zastosujemy transmisję

I 2 C, która będzie tematem dopiero następnej

lekcji i dlatego te fragmenty programu pozo−

stawimy na razie bez komentarza.

ko jeden element: pamięć szeregowa EE−

PROM, czyli IC2. Następnie zakładamy jum−

pery JP2 i JP3 i powracamy do naszego pro−

gramu. Wywołujemy okienko emulatora

i przyciskiem z rysuneczkiem układu scalo−

nego włączamy emulację sprzętową.

Po uruchomieniu programu zostaniemy

poproszeni o podanie pięciu wartości z za−

kresu od 0 do 255, czyli liczb ośmiobito−

wych. Wartości podajemy z klawiatury, po−

twierdzając każdą z nich naciśnięciem EN−

TER. Sekundę po podaniu ostatniej liczby na

ekranie pojawia się komunikat o dokonaniu

weryfikacji poprawności zapisu danych

w pamięci EEPROM ( rys. 7 ).

nie stoi na przeszkodzie, aby zestaw danych

pozyskanych z jakiegoś programu oblicze−

niowego przenieść przez clipboard do edyto−

ra BASCOM−a i następnie ... nie − dość już

tych dygresji, jeżeli tak dalej pójdzie, to na

kolejnej lekcji będziecie mieli innego wykła−

dowcę, a ja dam do gazet ogłoszenie: “Przyj−

mę każdą pracę, może być fizyczna”! Wra−

cajmy do naszego emulatora!

Zajmijmy się teraz dolnym okienkiem

panelu emulatora, tym, w którym wyświe−

tlany jest tekst testowanego programu. Wy−

gląda ono niepozornie, ale kryje w sobie

pewne możliwości. Uruchommy jeszcze raz

nasz program testowania zapisu do EE−

PROM (bardzo proszę, zachowajcie go do

następnej lekcji o I2C, będzie BARDZO po−

trzebny) i zatrzymajmy go, na przykład po

wprowadzeniu 2 liczby. Przez cały czas pra−

cy programu tekst w dolnym okienku prze−

suwał się, a obecnie znieruchomiał ( rys. 8 ).

Najedźmy teraz kursorem myszki na jakąś

zmienną umieszczoną w programie, np. na

VALUE. W tym samym momencie w le−

wym dolnym rogu okienka pojawił się ko−

munikat: “VALUE = 24”. Co to oznacza? To

proste, przecież zatrzymaliśmy program po

wprowadzeniu drugiej liczby, którą było

właśnie ... 24! Naprowadźmy teraz kursor

na inną zmienną, na R. Natychmiast w dol−

nym rogu okna wyświetlił się napis: “R =

2”. A więc doszliśmy do kolejnego ułatwie−

nia oferowanego nam przez emulator BA−

SCOM−a: w okienku z tekstem programu

zmienne przybierają takie wartości, jakie są

im nadawane przez pracujący program

i wartości te, po zatrzymaniu programu, mo−

żemy w każdej chwili odczytać i odpowie−

dnio zinterpretować. No, niech ktoś jeszcze

powie, że nasz BASCOM nie jest najwygo−

dniejszym narzędziem programistycznym,

jakie kiedykolwiek powstało!

$si Metapolecenie $SIM umieszczamy na

początku programu, który ma być testo−

wany w symulacji programowej lub emu−

lacji sprzętowej. P RZED KOMPILACJ ą GOTO −

WEGO PROGRAMU , KTÓRY MA ZOSTAĆ UMIE −

SZCZONY W PROCESORZE , POLECENIE TO NA −

LE ż Y BEZWZGLĘDNIE USUN Ą Ć !

Config Sda = P1.6

Config Scl = P1.7

Declare Sub Write_eeprom(adres As By−

te , Value As Byte)

Declare Sub Read_eeprom(adres As Byte

, Value As Byte)

Dim R As Byte

Dim Value As Byte , Adres As Byte

For R = 0 To 5

Print “Podaj wartość “ ; R ; “[0...255]”;

Input Value

Call Write_eeprom , R , Value

Next R

Czemu właściwie miała służyć ta demon−

stracja? Chciałem pokazać Wam, jak uży−

teczna może być funkcja PRINT, nawet jeże−

li nie jest ona stosowana zgodnie ze swoim

podstawowym przeznaczeniem. Operacje za−

pisu i odczytu danych z pamięci EEPROM

wykonywane są zwykle przez procesor “po

cichu”, bez wysyłania jakichkolwiek komu−

nikatów. W przypadku złego działania pro−

gramu, często nie jesteśmy w stanie stwier−

dzić, czy zapis lub odczyt danych przebiegał

poprawnie. W takiej sytuacji możemy pro−

gram lub jego fragment przetestować za po−

mocą emulatora sprzętowego, dodając we

właściwych miejscach instrukcje PRINT,

które po ewentualnym poprawieniu błędów

możemy usunąć. Wygodne, prawda?

Moi Drodzy, zastanówmy się teraz, co

właściwie najlepszego uczyniliśmy, pisząc

ten program? Będzie to kolejna dygresja ale

koniecznie chcę Wam to powiedzieć. A więc,

co zrobiliśmy, proste ćwiczenie? Nie, zrobili−

śmy ni mniej, ni więcej tylko ... programa−

tor szeregowych pamięci EEPROM ! Prze−

cież za pomocą tego programu, po zmianie

wartości w pętli FOR .... NEXT (z 5 na 255

lub, w przypadku “mniejszych” pamięci, na

127) możemy zaprogramować pamięć dany−

mi, które mogą być wykorzystane w jakimś

budowanym przez nas urządzeniu. Co wię−

cej, ten programator nie będzie kosztował nas

ani grosza, ponieważ jedynym elementem

potrzebnym do jego budowy jest posiadana

już przez nas płytka testowa!

Jasne, że taki “ręczny” programator jest

urządzeniem dość prymitywnym i nie nada−

jącym się do profesjonalnej pracy. Nic jednak

Print “Weryfikacja zapisu:”

For R = 0 To 5

Call Read_eeprom , R , Value

Print “Wartość “ ; R ; “ = “ ; Value

Next R

End

Sub Write_eeprom(adres As Byte , Value

As Byte)

I2cstart

I2cwbyte 160

I2cwbyte Adres

I2cwbyte Value

I2cstop

Waitms 10

End Sub

Sub Read_eeprom(adres As Byte , Value

As Byte)

I2cstart

I2cwbyte 160

I2cwbyte Adres

I2cstart

I2cwbyte 161

I2crbyte Value , 9

I2cstop

End Sub

No dobrze, ale program wykonywany

jest bardzo szybko, nawet w symulacji,

i pewnie trzeba mieć znakomity refleks, aby

zatrzymać go we właściwym momencie?

Ależ nic podobnego, aby zatrzymać pro−

gram dokładnie w tym miejscu, gdzie chce−

my, nie musimy wcale posiadać refleksu te−

ksańskiego rewolwerowca. Metod jest kil−

ka: możemy na przykład w tekst programu

Po “wklepaniu” powyższego programu do

edytora tekstowego BASCOM−a kompiluje−

my go i .... poczekajcie jeszcze moment, mu−

simy przygotować sobie hardware. Dołącza−

my do komputera emulator sprzętowy, a jego

wtyk emulacyjny łączymy z naszą płytką te−

stową. Na płytce musi być umieszczony tyl−

Elektronika dla Wszystkich

BASCOM

wprowadzić dodatkowe polecenia BREAK

(przerwij). Po napotkaniu takiego polecenia

emulator przerywa pracę i należy go po−

wtórnie uruchomić przyciskiem START

(program wykonywany będzie od momentu

wystąpienia instrukcji BREAK). Jednak

wpisywanie dodatkowych poleceń w tekst

programu niesie z sobą pewne ryzyko: jeże−

li zapomnimy je usunąć przed ostateczną

kompilacją i programowaniem procesora, to

biada nam: procesor z pewnością zgłupieje

(można wstrzymać wykonywanie poleceń

BREAK za pomocą metapolecenia $NO−

BREAK, umieszczonego na początku pro−

gramu). Jest jednak znacznie wygodniejsza

metoda, pozwalająca na umieszczanie i usu−

wanie znaczników chwilowego przerywania

pracy programu. Ustawmy teraz kursor na

początku tej linijki programu, przy której

chcemy wstrzymać jego działanie i naciśnij−

my klawisz F9. Z pewnością zauważyliście,

że na marginesie okienka pojawiła się

w tym momencie czerwona kropka. Naci−

śnijmy jeszcze raz F9 − kropka zniknęła.

Przenieśmy teraz kursor na początek innej

linii, znowu naciśnijmy F9 i uruchommy

program. Zauważymy,że program zatrzyma

się na linii, przy której została umieszczona

czerwona kropka. W ten sposób możemy

podczas symulacji zatrzymywać program

w dowolnych momentach, analizować

zmienne lub rejestry i ponownie urucha−

miać. Bardzo ważne jest też to, że wstawia−

ne w ten sposób polecenia przerwania egze−

kucji programu nie “przedostają się” do je−

go kodu źródłowego i nie grozi nam wpad−

ka spowodowana nieusunięciem poleceń

BREAK przed programowaniem procesora.

Moi Drodzy, nie wyczerpaliśmy całego

materiału dotyczącego emulacji sprzętowej

i symulacji programowej. Czeka na Was jed−

nak wyjątkowo ciekawe ćwiczenie i nie

chciałbym, abyście przystąpili do jego wyko−

nywania zbyt zmęczeni. Do tematu symula−

torów BASCOM−a będziemy jeszcze niejed−

nokrotnie powracać, a na razie, jak zwykle

proponuję filiżankę kawy i bierzemy się za

ćwiczenie praktyczne.

Zbigniew Raabe

e−mail: zbigniew.raabe@edw.com.pl

KONKURS

na ciekawe aplikacje zaprojektowane na płytce testowej AVT−2500

Płytka testowa AVT−2500 może służyć nie

tylko do nauki i testowania mniej skompli−

kowanych programów, ale także może stać

się uniwersalnym narzędziem warsztatowym

o ogromnych możliwościach. Zobaczyliśmy

jak można wykonać prostą nawijarkę do ce−

wek. Równie dobrze można przy pomocy

płytki testowej wykonać w parę minut mier−

nik częstotliwości, zegar, itd.

Takich urządzeń może być wiele i to nie−

koniecznie pracujących w naszym warszta−

cie. Płytka testowa może też być swojego

rodzaju terminalem komputera: możemy

przecież skompilować napisany program i

uruchomić go z poziomu emulatora sprzęto−

wego, bez konieczności programowania

procesora.

Podam Wam prosty, banalny przykład.

Zbliżają się święta Bożego Narodzenia i po−

trzebujemy w prosty sposób, bez ponoszenia

kosztów zbudować urządzenie sterujące

w efektowny sposób lampkami na choinkę.

Na płytce testowej mamy driver mocy

(ULN2803), mogący sterować ośmioma

odbiornikami energii pobierającymi prąd

o wartości do 500mA. Cóż wiec prostszego:

należy dołączyć do tego drivera girlandy

lampek, jego wejścia wysterować z wypro−

wadzeń procesora i napisać program, które−

go efekt działania będzie zależeć wyłącznie

od naszej wyobraźni.

Wspominałem już Wam o nowym pro−

gramatorze, który sprowadza wszystkie ope−

racje związane z programowaniem proceso−

ra i testowaniem programu w uruchamianym

układzie do jednego naciśnięcia klawisza F7

(możecie go obejrzeć na załączonej fotogra−

fii na stronie 22 inicjującej wykład). Zmon−

towałem kilka prototypów tego układu: je−

den jest w Pracowni Konstrukcyjnej AVT,

drugi pojechał do Holandii, trzeci pozosta−

wiłem sobie do dalszych testów. Pozostały

jeszcze dwa, w których, tak jak w pozosta−

łych nie trzeba było wykonywać jakichkol−

wiek poprawek. Może komuś z Was mogą

się przydać?

Te dwa programatory przeznaczyłem na

nagrodę dla tych dwóch Czytelników,

którzy przyślą najciekawsze pomysły na

nowe, praktyczne zastosowania naszej

płytki testowej AVT−2500. Oczywiście,

sam pomysł jest najważniejszy, ale chciał−

bym także sprawdzić Wasze umiejętności

i obejrzeć listingi napisanych programów.

Nie ma żadnych ograniczeń, co do rodzaju

urządzeń zbudowanych na płytce testowej.

Narzędzia warsztatowe, układy automaty−

ki domowej, wszystko co wymyślicie mo−

że być zaakceptowane. Ograniczenie jest

tylko jedno: nie można stosować żadnych

dodatkowych układów elektronicznych,

z wyjątkiem najprostszych, takich jak

oporniki, fotorezystory czy pojedyncze

tranzystory. Nie ma natomiast ograniczeń

jeżeli chodzi o układy elektromechanicz−

ne: silniki DC i krokowe, serwomechani−

zmy, elektromagnesy, cały ten złom jest

mile widziany.

Ogłaszamy zatem konkurs na ciekawe

pomysły użytecznych aplikacji płytki testo−

wej. Ponieważ mamy wakacje, więc roz−

strzygnięcie konkursu planujemy dopiero po

30 września.

Oprócz dwóch wymienionych już na−

gród głównych przewidujemy opublikowa−

nie na łamach EdW najciekawszych pro−

jektów. Każdy opublikowany projekt na−

grodzimy darmową prenumeratą roczną

EdW.

Zbigniew Raabe

Zostatniej chwili

nowe edycje tego programu, a także udoskonalona

wersja DEMO, dostępna na stronie www.ep.com.pl

<http://www.ep.com.pl> lub www.mcselec.com

<http://www.mcselec.com> . Rozbudowany pakiet za−

wiera nową wersję symulatora programowego, nie−

stety jeszcze nie oczyszczonego ze wszystkich błędów.

Jednak Mark obiecuje, że do końca roku BASCOM

AVR stanie się w pełni profesjonalnym programem,

nie ustępującym BASCOM−owi 8051.

3. 31 maja. Nowa wersja, a właściwie uaktualnienie

BASCOM−a 8051 na stronie www.mcselec.com

<http://www.mcselec.com> ! Jest to wersja Beta

i Autor bynajmniej nie twierdzi, że jest pozbawiona

błędów w nowo dodanych funkcjach (w końcu po to

tworzy się wersję Beta!). Mimo to warto spróbo−

wać! Po przetestowaniu napiszę, co o tym sądzę.

1. Współpraca pomiędzy MCS Electronics a redak−

cją Elektroniki Praktycznej, reprezentowaną przez

moją skromną osobę, zaowocowała ostatnio skon−

struowaniem, ośmielam się twierdzić, rewelacyjnego

urządzania przeznaczonego do współpracy z pakie−

tem BASCOM8051 SEfEP. Jest nim ... programator

ISP procesorów podrodziny 89CX051! Oczywiście

nie jest to prawdziwe ISP, ale z powodzeniem go uda−

je. Procesor włożony jest w podstawkę programato−

ra i połączony kablem z wtykiem emulacyjnym

umieszczonym w uruchamianym układzie. Przed

rozpoczęciem programowania procesor zostaje odłą−

czony od przeznaczonego dla niego układu, zapro−

gramowany i ponownie połączony ze swoim natural−

nym środowiskiem. Wszystkie te czynności odbywa−

ją się całkowicie automatycznie i kilka sekund po na−

ciśnięciu przycisku F7 możemy już sprawdzić działa−

nie programu w rzeczywistych warunkach. W chwi−

li, kiedy piszę te słowa, programator odbywa właśnie

podróż do Holandii, gdzie zostanie dodatkowo prze−

testowany przez Marka. Jeżeli wyniki testów okażą

się pomyślne, co jest prawie pewne, to opis układu

zostanie opublikowany w jednym z najbliższych nu−

merów Elektroniki Praktycznej.

2. MCS Electronics wyraźnie nabrała tempa w do−

skonaleniu młodszego “brata” naszego BASCOM−a,

czyli pakietu BASCOM AVR, przeznaczonego do

procesorów RISC, produkowanych przez ATMEL’a.

Wciągu ostatniego miesiąca ukazały się kolejno dwie

Elektronika dla Wszystkich

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: