Spis treści

Wstęp..........................................................................................................5

1. Przegląd stosowanych systemów sterowania i kontroli
na dużych odległościach......................................................................6
1.1. Systemy wykorzystujące sieć internetową do sterowania i
kontroli urządzeń........................................................................7
1.2. Systemy wykorzystujące sieć energetyczną do sterowania i

kontroli urządzeń.......................................................................15

2. Charakterystyka rozległej sieci TCP/IP pod kątem możliwości

jej

wykorzystania w systemach sterowania i kontroli.....................18

2.1. Warstwowy model sieci TCP/IP..............................................19
2.2. Protokół TCP............................................................................22

2.3. Protokół UDP...........................................................................25

2.4. Protokół IP................................................................................26

2.5. Protokół ICMP.........................................................................29

3. Propozycje sposobów przyłączania nadzorowanych urządzeń
do sieci TCP/IP ...................................................................................32

3.1. Sterownik jako konwerter między siecią TCP/IP

a urządzeniem.........................................................................33

4. Projekt sterownika mikroprocesorowego umożliwiającego
zadawanie i odczyt stanów urządzeń poprzez sieć TCP/IP.............34
4.1. Wybór mikrokontrolera...........................................................35

4.2. Projekt schematu blokowego...................................................41

4.3. Blok mikrokontrolera..............................................................43

4.4. Blok pamięci............................................................................44

4.5. Blok PHY................................................................................46

4.6. Blok RTC i adresu MAC........................................................49

4.7. Blok zasilania..........................................................................50

4.8. Blok interfejsu.........................................................................51

4.9. Przystawka do odczytu temperatury oraz

włączania diody LED..............................................................53
4.10. Wykaz elementów..................................................................54

5. Wykonanie i uruchomienie zaprojektowanego sterownika.............56

5.1. Projekt płytki drukowanej.........................................................57

5.2. Wykonanie sterownika..............................................................60

4

5.3. Zainstalowanie środowiska wykonawczego do sterowania.....62
5.4. Uruchomienie przykładowych aplikacji...................................65

6. Przeprowadzeni badań wykonanego sterownika w warunkach
przyłączenia go do wybranych sieci TCP/IP....................................68
6.1. Analiza przepływu danych sterownika podłączonego
do sieci LAN przy wykorzystaniu programu IRIS..................69

Podsumowanie.....................................................................................71

Literatura.............................................................................................72

Załączniki:
Płyta CD

5

Wstęp

Etap mikroprocesorowej rewolucji, która dokonała się w minionym 20-

leciu w obszarze urządzeń powszechnego użytku, na trwałe skomputeryzował

sprzęt gospodarstwa domowego,

sprzęt audio-video czy też branżę

motoryzacyjną. Obsługa tych urządzeń wcale nie musi się odbywać bezpośrednio

przez użytkownika, już dziś mamy wiele systemów sterujących czy też

kontrolujących stan tych urządzeń na odległość. Technologie do centralnego

zarządzania sprzętem powszechnego użytku są rozwijane przez większość

liczących się producentów podzespołów elektronicznych. Sieci internetowe,

które dotąd były wykorzystywane przeważnie do świadczenia usług WWW

(World Wide Web), mogą być wykorzystywane teraz do sterowania i kontroli

innych urządzeń. Wiele urządzeń domowego użytku w przyszłości może być

wyposażone w charakterystyczne gniazdo RJ – 45, np. piekarnik, który może

otrzymywać przepisy kulinarne z internetowej bazy, telewizor kontrolowany

zdalnie przez komputer PC lub magnetowid programowany za pomocą

sieciowego interfejsu.

Celem niniejszej pracy jest charakterystyka sieci TCP/IP pod względem

zastosowania do sterowania i kontroli urządzeń oraz projekt sterownika

umożliwiającego zadawanie i odczyt stanów urządzeń poprzez sieć TCP/IP.

6

1. Przegląd stosowanych systemów

sterowania i kontroli na dużych

odległościach

W rozdziale pierwszym pracy przedstawiono systemy

wykorzystujące sieci internetowe oraz sieci energetyczne do sterowania i

kontroli urządzeń.

7

1.1. Systemy wykorzystujące sieć internetową do

sterowania i kontroli urządzeń

Obecnie jest wiele firm produkujących systemy sterowania i kontroli

urządzeń przez sieć typu Ethernet/Internet. Systemy te charakteryzują się szeroką

gamą urządzeń z nimi współpracujących. Prekursorem zasługującym na uwagę

była firma Dallas Semiconductor a obecnie Maxim/Dallas [1], która

zaproponowała w 1998 roku miniaturowe moduły programowalne w języku

Java, służące do kontroli domowych urządzeń elektrycznych. Medium

komunikacyjne stanowiła w tym przypadku domowa sieć energetyczna . Jednak,

proponowane od roku 1999 rozwiązania bazują na sieci Ethernet i protokołach

standardu TCP/IP. Są to mikroserwery TINI oparte na 8-bitowym

mikrokontrolerze z zaimplementowanym w pamięci stosem TCP/IP. Powszechny

w większości krajów rozwiniętych dostęp do sieci LAN/WAN i jej globalny

zasięg oferuje duże możliwości dla obszaru urządzeń powszechnego użytku

współpracujących z mikroserwerami TINI ( rys. 1.1).

Rys. 1.1. Obszar zastosowań mikroserwerów TINI do sterowania i kontroli

urządzeń (na podstawie materiałów firmy Maxim/Dallas).

Wbudowane w moduł mikroserwera TINI środowisko uruchomieniowe

JVM (Java Virtual Machine), w tym biblioteka java.net do obsługi warstwy

8

gniazd protokołu TCP/IP, pozwoliły na realizację następujących protokołów

warstwy aplikacyjnej: HTTP (Hypertext Transfer Protocol), DNS (Domain

Name System), DHCP (Dynamic Host Configuration Protocol) , Telnet oraz FTP

(File Transfer Protocol). Schemat blokowy modułu TINI został przedstawiony

na rysunku 1.2.[2]

Rys.1.2. Schemat blokowy modułu TINI firmy Maxim/Dallas

W pamięci modułu oprócz stosu TCP/IP i JVM zaimplementowany jest też

prosty system operacyjny RTOS zarządzający obsługę stosu i uruchamiania

aplikacji. Aplikacje są pisane w języku java i wykonywane na mikroserwerze

przez JVM po wcześniejszym skompilowaniu i odpowiednim przygotowaniu

plików. Pomiędzy warstwą aplikacyjną a warstwą protokołów pośredniczy

interfejs gniazd odwzorowujący zunifikowane żądania aplikacji na działania

specyficzne dla implementacji protokołów transportowych (TCP, UDP). Poniżej

warstwy sieci (IP) znajdują się programy komunikujące się z urządzeniami

sieciowymi - kontrolerem Ethernet lub z modemem - za pośrednictwem łącza

szeregowego i protokołu PPP (Point-to-Point Protocol). Urządzeniem sieciowym

wbudowanym w moduł mikroserwera jest kontroler Ethernet obsługujący

standard 10Base-T i 100Base-TX pozwalający na bezpośrednie podłączenie

9

modułu do sieci LAN (Local Area Network). Mikroserver TINI charakteryzuje

się szerokim zestawem interfejsów z urządzeniami zewnętrznymi. Jest on

wyposażony w rozszerzony port I/O, dwa porty szeregowe, interfejs 1-Wire,

magistralę CAN oraz złącze dla układów iButton [3] firmy Maxim/Dallas.

Mikroserver wyposażony jest też w układ RTC (Real Time Clock) mierzący czas,

który może być używany przez użytkownika w niektórych aplikacjach. Cały

mikroserver występuje w postaci dwóch oddzielnych płytek tzn. modułu o

oznaczeniu TINI390 zawierającego mikrokontroler, pamięć i kontroler

Ethernetu oraz z płytki o symbolu E10 wyposażonej we wszystkie niezbędne

interfejsy mikroserwera do komunikacji z urządzeniami zewnętrznymi i

pozostałe układy do jego pracy. Obie płytki łączą się za pomocą gniazda 72 Pin

SIMM. Na rysunku 1.3. przedstawiony jest wygląd modułu TINI390 bazującego

na mikrokontrolerze DS80C390. [3]

Rys.1.3. Widok modułu TINI390 firmy Maxim/Dallas

Na rysunku 1.4. przedstawiony jest widok kompletnego mikroserwera

(płyta E10 z modułem TINI390). [3]

10

Rys.1.4. Widok kompletnego mikroserwera TINI firmy Maxim/Dallas

Zainstalowany w module system operacyjny RTOS umożliwia

nawiązanie połączeń FTP z innymi stacjami w sieci, skonfigurowanie połączenia

sieciowego lub ustawianie czasu mierzonego przez układ RTC. W zależności od

aplikacji wykonywanej przez JVM mikroserwera TINI możliwe jest sterowanie

lub kontrola urządzeń dołączonych do odpowiedniego interfejsu mikroserwera

poprzez sieć TCP/IP. Producent udostępnia wiele przykładowych aplikacji

wykorzystujących sieć TCP/IP do obsługi innych urządzeń dołączonych do

modułu TINI. Interfejs graficzny użytkownika między stanem urządzeń może

stanowić przeglądarka internetowa.

Innym przykładem systemów do sterowania i kontroli urządzeń na

dużych odległościach mogą być konwertery RS-232 – Ethernet . Obecnie jest

dużo firm produkujących takie konwertery, można spotkać również firmy

krajowe produkujące te urządzenia. Jedną z takich firm jest firma

ESP Sp. z o.o.

11

produkująca konwerter RS232-ETHERNET [4], wygląd tego konwertera jest

przedstawiony na rysunku 1.5.

Rys. 1.5. Konwerter RS-232 / ETHERNET firmy ESP

Konwerter RS232/ETHERNET zbudowany jest w oparciu o

mikrokontroler 8-bitowy, obsługuje standard 10Base-T Ethernetu oraz umożliwia

współpracę za pośrednictwem sieci Ethernet z dowolnym urządzeniem

wyposażonym w łącze szeregowe RS232 (lub RS485). Urządzenie z łączem

szeregowym widziane jest jako lokalne urządzenie posiadające unikalny adres.

Dostęp do niego uzyskiwany jest za pośrednictwem protokołu TCP. Dzięki temu

w prosty sposób można monitorować, sterować lub konfigurować urządzenia

rozproszone praktycznie po całym świecie. Oczywiście jeśli nie zachodzi taka

potrzeba, to można ograniczyć się do sieci lokalnej i przy jej wykorzystaniu

zbierać oraz gromadzić na jednym komputerze np. dane pomiarowe z całego

budynku czy kompleksu budynków. Przykład zastosowania konwertera RS-232 /

ETHERNET przedstawiono na rysunku 1.6. Konwerter pozwala na jednoczesne

otwarcie do czterech kanałów komunikacyjnych typu RS232 lub RS485.

Ponieważ konwerter pracuje w oparciu o protokół TCP/IP musi mieć przypisany

unikalny adres sieciowy w postaci xxx.xxx.xxx.xxx (np.: 10.0.0.1). Dostęp do

12

poszczególnych portów szeregowych uzyskuje się poprzez dodanie do adresu

sieciowego odpowiedniego numeru portu TCP. Kompletny adres wygląda

następująco xxx.xxx.xxx.xxx:nn gdzie nn to numer portu TCP (np.: 10.0.0.1:51).

Rys. 1.6. Przykład zastosowania konwertera RS232/Ethernet

(na podstawie materiałów firmy ESP)

Przedstawiony konwerter posiada zestaw diód LED informujący między

innymi: stan połączenia z siecią ethernet, transmisję danych, numer aktywnego

portu szeregowego oraz napięcie zasilania. Przed rozpoczęciem pracy konwerter

RS-ETH powinien zostać skonfigurowany. Parametry konwertera takie jak adres

IP, prędkości kanałów szeregowych konfiguruje się za pomocą łącza

serwisowego i dowolnego terminala znakowego (np. HyperTeminal, Telix lub

Norton Commander Terminal). W celu sprawdzenia komunikacji urządzenia

podłączonego do konwertera można uruchomić usługę Telnet na komputerze PC

poprzez wpisanie w programie Telnet adresu IP konwertera wraz z

przyporządkowanym dla danego numeru portu szeregowego numeru portu TCP.

Zastosowanie dwóch konwerterów RS-232/Ethernet umożliwia prace w trybie

13

wirtualnego kanału RS-232. Tryb kanału wirtualnego dla łącza szeregowego

został przedstawiony na rysunku 1.7.

Rys.1.7. Tryb kanału wirtualnego dla łącza szeregowego z wykorzystaniem

dwóch konwerterów RS232/Ethernet
(na podstawie materiałów firmy ESP)

Zestawienie takiego połączenia umożliwia przesyłanie danych w obu

kierunkach przez sieć Ethernet/Internet. Sieć ethernet „traktowana” jest w tym

wypadku jak kabel RS232 .

Następnym przykładem urządzenia sterującego poprzez sieć internetową

jest miniserwer WebEmbed firmy NETICA [5]. Na rysunku 1.8. został

przedstawiony wygląd miniserwera WebEmbed. Jest on samodzielnym,

maksymalnie zminiaturyzowanym kompletnym serwerem sieci web (serwer

HTTP i FTP), dostosowanym do pracy w warunkach przemysłowych. Jest on

przeznaczony - jako gotowy "front-end" do sieci z protokołem TCP/IP - dla

zarówno już istniejących jak i nowo powstających systemów elektroniki,

automatyki i pomiarów, które takiego interfejsu nie posiadają. Szybka i łatwa

integracja WebEmbed z systemami użytkownika zwiększa ich globalny zasięg,

atrakcyjność i obszar zastosowań. Możliwości zastosowań WebEmbed są

niemalże nieograniczone. Faktycznym ograniczeniem może być wymagana moc

obliczeniowa procesora, pojemność krytycznych zasobów (np. pamięci systemu),

14

czy wymagany czas reakcji systemu na zdarzenia zewnętrzne (np. jeśli musiałby

on być krótszy niż 100 milisekund). Generalnie, potencjalne obszary zastosowań

WebEmbed mogą dla przykładu obejmować:

•

Przemysłowe systemy zdalnego sterowania i monitoringu,

•

Teleserwis, telemetria,

•

Systemy alarmowe,

•

Inteligentne budynki,

•

Systemy grzewcze i klimatyzacyjne, oczyszczalnie ścieków

•

Windy,

•

Telekomunikacja,

•

Parkingi,

•

Stacje pogodowe i monitoring środowiska,

•

Automaty biletowe, z napojami, z papierosami, bankomaty, itp.

•

Medycyna i laboratoria,

•

Kontrola dostępu,

•

Rejestracja danych,

•

E-banking,

•

Monitoring ruchu drogowego,

•

Automatyzacja gospodarstwa domowego i wiele, wiele innych.

Rys. 1.8. Widok miniserwera WebEmbed firmy NETICA

15

1.2. Systemy wykorzystujące sieć energetyczną do

sterowania i kontroli urządzeń

Sterowanie i kontrola urządzeń na dużych odległościach może odbywać

przy wykorzystaniu linii energetycznych. Systemy takie wykorzystują

technologię PLC (Power Line Comunication) jest to metoda transmisji danych w

oparciu o dostępną sieć elektryczną. W chwili obecnej zgodnie z regulacjami

istniejącymi w Unii Europejskiej istnieje kanał transmisji w sieci elektrycznej o

określonej częstotliwości dostępny dla odbiorcy bez specjalnych zezwoleń o

zakresie: 3...148.5kHz. Do połączenia urządzenia z siecią energetyczną

wykorzystywane są modemy PLC. Na rysunku 1.9. przedstawiony jest schemat

blokowy modemu PLC [6].

Rys. 1.9. Schemat blokowy modemu PLC

Podstawową zasadą działania komunikacji PLC jest modulacja i

demodulacja. Modulowany sygnał wysokiej częstotliwości jest dodawany do

przebiegu napięcia zasilania w linii zasilającej. Sygnał ten rozchodzi się po

16

przewodach zasilających. Moduł odbiorczy oddziela ten sygnał w paśmie

nadawczym z napięcia zasilającego. Wyizolowanie sygnału użytecznego z pasma

nadawczego odbywa się za pomocą filtrów wąskopasmowych o ostrych

zboczach oraz szybkiej transformacji Fouriera. Demodulacja sygnału pozwala na

odtworzenie oryginalnych danych. Jako, że sygnał przesyłany linią zasilającą

podlega różnym interferencjom niezbędne jest dokonanie weryfikacji

poprawności. Weryfikacja poprawności odebranych danych jest dokonywana za

pomocą sumy kontrolnej CRC. W innych słowach wartość sumy kontrolnej musi

się zgadzać z wartością sumy kontrolnej obliczonej podczas nadawania i

przesyłanej wraz z danymi. Aby zwiększyć bezpieczeństwo transmitowanych

danych, zastosowano dodatkowe procedury, jak automatyczne powtarzanie,

potwierdzanie odbioru danych lub 100% redundancja wysyłanych informacji, ich

przeplot podczas wysyłania i odbioru.

Jednym z systemów wykorzystujących technologie PLC są moduły

TransTherm oferowane przez firmę TEST-THERM Sp. z o.o [6] . Na rysunku

1.10. przedstawiony jest wygląd modułów TransTherm .

Rys.1.10. Moduły TransTherm firmy TEST-THERM wykorzystujące

technologię PLC do sterowania i kontroli urządzeń

17

Moduły TransTherm są kompleksowym systemem zorientowanym na

pomiary, sterowanie, i odczyt wielkości pomiarowych - temperatury,

wilgotności, ciepła itp. System może być sterowany i wszystkie jego funkcje

dostępne z jednego punktu centralnego, np. komputera podłączonego do

firmowej sieci komputerowej. Komunikacja pomiędzy indywidualnymi

modułami jest utrzymywana z wykorzystaniem technologii PLC. Technologia ta

zapewnia niezawodną komunikację poprzez sieć zasilającą na odległość do 3 km.

Oprogramowanie producenta modułów TransTherm umożliwia gromadzenia

danych pomiarowych, ich archiwizację i przetwarzanie. Ze względu na

modułowość można je łatwo przystosować do szczegółowych wymagań klienta.

System może pracować na pojedynczym komputerze albo na serwerze, skąd

może być dostępny dla całej sieci intranetowej.

18

2. Charakterystyka rozległej sieci

TCP/IP pod kątem możliwości
jej wykorzystania w systemach
sterowania i kontroli urządzeń

Sterowanie i kontrola urządzeń w sieciach internetowych wymaga

wymiany danych między jednostką sterującą/kontrolującą a urządzeniem

sterowanym lub kontrolowanym. Wymiana tych danych musi spełniać

zasady, reguły jakie panują w obszarach połączeń internetowych, gdyż w

przeciwnym razie, może dojść do nieprawidłowego zarządzania czy też

działania wspomnianych urządzeń.

W rozdziale drugim pracy został przedstawiony czterowarstwowy

model TCP/IP służący do wymiany danych między aplikacjami urządzeń

pracujących w sieci internetowej.

19

2.1. Warstwowy model sieci TCP/IP

W teorii sieci internetowej bardzo ważne miejsce zajmuje tzw.

warstwowy model sieci. Najczęściej opisuje się go korzystając z modelu OSI

(Open Systems Interconnection), który wyróżnia 7 warstw. Model OSI opisuje

sposób przepływu informacji między aplikacjami w jednej stacji sieciowej a

aplikacjami w innej stacji sieciowej przy użyciu medium transmisyjnego. W

modelu tym warstwy są to oddzielne części oprogramowania sieciowego

(realizującego funkcje komunikacyjne, organizującego sieć). Jedna warstwa

odpowiada za pewną część funkcji i "kompetencji". Dostarcza usług warstwie

wyższej i korzysta z usług warstwy niższej. Sposób komunikacji między stacjami

sieciowymi można również opisać czterowarstwowym modelem TCP/IP. Na

rysunku 2.1. przedstawione jest porównanie modelu ISO/OSI z modelem

TCP/IP.[7]

Rys. 2.1. Porównanie modelu ISO/OSI i modelu TCP/IP

Warstwa dostępu do sieci odpowiada za dostarczanie danych do innych

urządzeń bezpośrednio dołączonych do sieci. Współpracuje ona bezpośrednio ze

sprzętem i sterownikami odpowiedzialnymi za współpracę z siecią. W sieci

20

lokalnej mogą to być Ethernet lub Token-Ring (różne rozwiązania sieci

lokalnych). W przypadku innych sieci mogą to być protokoły PPP, SLIP lub

inne. Warstwa ta współpracuje więc z interfejsem sieciowym (kartą sieciową),

modemem lub innym urządzeniem pozwalającym na bezpośrednie połączenie

dwóch lub więcej stacji sieciowych i separuje resztę warstw od zastosowanych

rozwiązań fizycznych (niskopoziomowych). Świadczy ona usługę warstwie

wyższej polegającą na wysyłaniu i odbieraniu porcji danych (zwanych ramkami)

z stacjami w danej sieci fizycznej.

Warstwa internet (IP) odpowiada za dostarczanie danych do urządzeń

nie tylko w danej sieci fizycznej. Organizuje ona ruch tzw. pakietów IP między

poszczególnymi sieciami fizycznymi połączonymi w intersieć. Korzysta z usług

warstwy dostępu do sieci, sama zaś świadczy usługi dostarczania pakietu do

dowolnego komputera w Internecie.

Warstwa transportowa odpowiedzialna jest za niezawodną wymianę

danych z dowolnym komputerem w Internecie. Organizuje też i utrzymuje tzw.

sesje, czyli wirtualne połączenia między komputerami. Korzysta z warstwy IP,

sama zaś dostarcza usług niezawodnego transportu danych.

Warstwa aplikacji jest najwyżej położona. Tej warstwie odpowiadają

wszelkie programy (aplikacje) internetowe korzystające z warstwy

transportowej. Tu znajdują się wszelkie konkretne zastosowania Internetu -

przesyłanie plików (FTP), poczty (SMTP) i inne.

Współpraca między warstwami polega na świadczeniu usług przez

warstwy niższe warstwom wyższym (Rys.2.2.) Związane to jest także z

przepływem danych w dół sterty warstw (przy wysyłaniu danych) i w górę (przy

odbieraniu). Moduł warstwy aplikacji w stacji A (najczęściej program

użytkownika) wysyła dane do warstwy transportowej. Ta odpowiednio formatuje

je (dzieli lub łączy, dodaje nagłówek) i wysyła do warstwy IP. Ta z kolei dodaje

swój nagłówek i wysyła do warstwy dostępu do sieci. Warstwa również dołącza

swój nagłówek (związany ze sprzętowym rozwiązaniem komunikacji, np. tzw.

21

nagłówek MAC) i wysyła pakiet fizycznie do sieci. Podobna droga, ale w drugą

stronę, czeka dane w stacji je odbierającej (stacja B). Pakiet wędruje ku górze i

jest pozbawiany odpowiednich nagłówków, by wreszcie dotrzeć do warstwy

aplikacji w formie identycznej porcji danych jaką wysłała warstwa aplikacji w

stacji wysyłającej.

Rys. 2.2

Współpraca międzywarstwowa w modelu TCP/IP

W koncepcji warstw istnieje jeszcze coś takiego jak wirtualny (logiczny)

obieg danych. Występuje on pomiędzy odpowiadającymi sobie warstwami w

odległych systemach. Warstwy dostępu do sieci wymieniają między sobą ramki -

tu jeszcze wspomniana wirtualność jest mało widoczna. Warstwy IP wysyłają do

siebie pakiety IP - choć w rzeczywistości muszą się ze sobą komunikować

poprzez swoje niższe warstwy, to z logicznego punktu widzenia istnieje między

22

nimi wirtualne połączenie, które pozwala na wymianę pakietów. Podobnie jest z

warstwami transportowymi, które wysyłają między sobą poprzez swój wirtualny

kanał pakiety danych (segmenty TCP) i inne komunikaty zapewniające

utrzymanie sesji i niezawodne dostarczenia danych (potwierdzanie).

2.2 Protokół TCP

Protokół TCP (Transmission Control Protocol) jest to protokół

zorientowany połączeniowo, czyli umożliwia zestawienie połączenia w którym

efektywnie i niezawodnie przesyłane są dane. Połączenie to charakteryzuje się

możliwością sterowania przepływem, potwierdzania odbioru, zachowania

kolejności danych, kontroli błędów i przeprowadzania retransmisji. Blok danych

wymieniany między współpracującymi komputerami nosi nazwę segmentu

(nagłówek + dane) . Na rysunku 2.3. przedstawiony jest format segmentu TCP .

Rys. 2.3. Format segmentu TCP

23

Pole port źródłowy (16 bitów) i pole port docelowy (16 bitów)

zawierają numery portów procesów aplikacyjnych korzystających z usług TCP.

Kombinacja tych numerów z adresami sieciowymi określa parę gniazd

tworzących połączenie protokołu TCP. Pole numer sekwencyjny (32 bity)

zawiera numer sekwencyjny pierwszego bajtu danych w segmencie. Ta wartość

określa pozycję segmentu w strumieniu bajtów. Podczas ustanawiania

połączenia, i jeśli bit syn w polu znaczniki jest ustawiony na 1, to w tym polu

zawarty jest inicjujący numer sekwencyjny isn, od którego rozpoczyna się

numerację bajtów w połączeniu. Zatem pierwszy wysłany bajt ma numer isn + 1.

Pole numer potwierdzenia (32 bity) zawiera numer sekwencyjny następnego

oczekiwanego bajtu po stronie odbiorczej. Jednocześnie jest to potwierdzenie

poprawnego odbioru bajtów o numerach sekwencyjnych mniejszych od

zawartego w tym polu. Potwierdzenia mówią nadawcy ile bajtów danych zostało

już poprawnie odebranych. Pole długość nagłówka (4 bity) określa liczbę 32 -

bitowych słów w nagłówku segmentu TCP. Tym samym określone zostaje

miejsce, w którym rozpoczynają się dane. Pole to ma tak określone znaczenie

tylko wtedy, gdy bit ack równy jest 1. Pole rezerwa (6 bitów) jest przeznaczone

dla przyszłych zastosowań. Zawiera same zera. Pole znaczniki składa się z

sześciu bitów sterujących, które ustawione na 1 mają następujące znaczenie :

a) UGR wskazuje na ważność pola wskaźnik pilności,

b) ACK wskazuje na ważność pola numer potwierdzania,

c) PSH wskazuje na działanie funkcji wymuszającej wysyłanie

segmentu,

d) RST wyzerowanie połączenia,

e) SYN wskazuje, że w polu numer sekwencyjny umieszczony jest inicjujący

numer sekwencyjny INS. Jest on przeznaczony do synchronizacji numerów

sekwencyjnych w fazie ustanowienia połączenia.

f) FIN wskazuje, że nadawca nie ma nic więcej do nadania - sygnał końca

danych.

24

Pole okno (16 bitów) określa liczbę bajtów jaką może jeszcze

zaakceptować odbiorczy moduł TCP. Pole suma kontrolna jest 16 - bitowym

jedynkowym uzupełnieniem jedynkowo uzupełnionej sumy wszystkich 16 -

bitowych słów w segmencie. Ta suma obejmuje zarówno nagłówek jak i dane

segmentu. Pole wskaźnik pilności (16 bitów) jest interpretowane tylko wtedy,

gdy bit UGR jest równy 1. Pole to zawiera numer sekwencyjny bajtu

następującego po pilnych danych. Pole opcje ma długość zmienną będącą

wielokrotnością 8 bitów. Zawiera ono numery opcji - każdy numer zapisany w

jednym bajcie. Dla protokołu TCP zdefiniowano trzy opcje.

0 - koniec listy opcji,

1 - brak działania,

2 - maksymalna długość segmentu.

Pole wypełnienie uzupełnia nagłówek do wielokrotności 32 bitów.

Ponieważ

TCP jest protokołem zorientowanym połączeniowo, więc w celu przesłania

danych między dwoma modułami TCP, zainstalowanymi w różnych stacjach

sieciowych , konieczne jest ustanowienie, utrzymanie i rozłączenie połączenia

wirtualnego. Ustanowienie połączenia odbywa się w następujących etapach :

-nadawczy moduł TCP wysyła do odbiorczego modułu TCP segment z

bitem SYN=1 i z proponowanym numerem ISN w polu numer sekwencyjny,

-odbiorczy moduł TCP, jeśli zgadza się na ustanowienie połączenia, to

przesyła zwrotnie segment z bitami SYN=1 i ACK=1, a w polu numer

sekwencyjny podaje numer INS, z którym rozpocznie działanie,

-nadawczy moduł TCP wysyła segment z potwierdzeniem otrzymania

zgody (ACK=1) na ustanowienie połączenia i równocześnie zawierający dane.

W ten sposób zostaje ustanowione połączenie wirtualne między dwoma

modułami TCP i mogą zostać przesyłane segmenty z danymi. Segmenty te mogą

25

być przesyłane tym połączeniem w obu kierunkach, ponieważ TCP umożliwia

transfer danych między dwoma modułami w trybie dupleksowym.

Dla zapewnienia niezawodnej transmisji TCP wykorzystuje sekwencyjną

numerację bajtów oraz mechanizm pozytywnych potwierdzeń z retransmisją.

Numer sekwencyjny przypisany do każdego przesyłanego bajtu danych pozwala

na jego jednoznaczną identyfikację, a także jest używany w mechanizmie

przesyłania potwierdzeń. Ponieważ kolejne bajty są numerowane począwszy od

ISN, a zatem numer pierwszego bajtu wysłanego w połączeniu wirtualnym

wynosi ISN+1 ( zazwyczaj ISN=0).

Nadawczy moduł TCP dokonuje retransmisji danych do czasu, aż

otrzyma potwierdzenie poprawnego ich przyjęcia przez odbiorczy moduł TCP.

Rozpoczęcie retransmisji uwarunkowane jest przekroczeniem wcześniej

ustalonego czasu oczekiwania na nadejście potwierdzenia. Po stronie odbiorczej

poprawność odbioru danych sprawdzana jest przy użyciu pola suma kontrolna

znajdującego się w nagłówku segmentu. Jeżeli dane są akceptowane to moduł

TCP wysyła zwrotnie pozytywne potwierdzenie. Jest ono zawarte w polu numer

potwierdzenia. Wszystkie bajty danych o numerach sekwencyjnych mniejszych

od wartości zawarte w tym polu zostały odebrane poprawnie. W sytuacji, gdy

dane zostały odebrane poprawnie, a nadawczy moduł TCP retransmitował je np.

z powodu zaginięcia segmentu z pozytywnym potwierdzeniem, odbiorczy moduł

TCP ma możliwość odrzucenia nadmiarowych danych (duplikatów).

2.3 Protokół UDP

Protokół UDP (User Datagram Protocol) jest protokołem

bezpołączeniowym, nie posiadającym mechanizmów sprawdzających

poprawność dostarczenia danych. Protokół UDP został opracowany w celu

stworzenia aplikacjom możliwości bezpośredniego korzystania z usług IP.

26

Pozwala on aplikacjom na dołączanie do datagramów IP adresów portów

komunikujących się aplikacji. Strukturę pakietu protokołu UDP

przedstawiono na rysunku 2.4.

Rys. 2.4. Struktura pakietu protokołu UDP

Pole port źródłowy (16 bitów) określa numer portu nadawczego procesu

aplikacji. Jeśli pole to nie jest wykorzystane, to zawiera same zera. Pole port

docelowy (16 bitów) zawiera numer procesu aplikacji na komputerze

docelowym. Pole długość (16 bitów) zawiera całkowitą długość pakietu

(nagłówek i dane) w bajtach. Pole suma kontrolna jest szesnastobitowym

jedynkowym uzupełnieniem jedynkowo uzupełnionej sumy słów nagłówka i

danych pakietu. Protokół UDP jest wykorzystywany w sytuacjach, gdy

przesyłamy niewielką liczbę danych. Również protokół ten mogą używać

aplikacje działające według modelu zapytanie-odpowiedź. Ogólnie możemy

powiedzieć, że protokół UDP może być z powodzeniem używany tam gdzie nie

są wymagane usługi protokołu TCP.

2.4 Protokół IP

Protokół IP (Internet Protocol) jest przeznaczony do sieci z komutacją pakietów.

Pakiet jest nazywany przez IP datagramem. Każdy datagram jest podstawową,

samodzielną jednostką przesyłaną w sieci na poziomie warstwy Internet.

27

Datagramy mogą być adresowane do pojedynczych węzłów lub do wielu

węzłów. W przesyłaniu datagramów poprzez sieci uczestniczą routery (węzły

sieci), które określają dla każdego datagramu trasę od węzła źródłowego do

węzła docelowego. W różnych sieciach mogą być ustalone różne maksymalne

długości datagramów, więc w zależności od potrzeb, datagram może być

podzielony na kilka mniejszych części, tzn. na kilka datagramów. Tę operacją

nazywamy fragmentacją datagramów. Format każdego fragmentu jest taki sam

jak format każdego innego niepodzielnego datagramu. Konieczność fragmentacji

datagramu może być również następstwem przesyłania datagramów przez sieci

rozległe dopuszczające inne protokoły i inne długości pakietów, np. sieci X.25 z

pakietami o maksymalnej długości 128 bajtów. Kompletowanie pierwotnego

datagramu z fragmentów dokonuje się w komputerze docelowym. Z chwilą

nadejścia pierwszego fragmentu ustala się czas oczekiwania na skompletowanie

datagramu. Jeśli w tym okresie czasu nie nadejdą pozostałe fragmenty to

następuje przerwanie oczekiwania i skasowanie już otrzymanych fragmentów.

Na rysunku 2.5. została przedstawiona struktura datagramu IP.

Rys. 2.5. Struktura datagramu IP

Pole wersja (4 bity) określa numer użytej wersji protokołu IP. Jest ono

konieczne, ponieważ routery lub komputery w sieci mogą używać różnych wersji

IP. Pole długość nagłówka (4 bity) określa liczbę słów 32 bitowych

28

składających się na nagłówek datagramu. Typowa (minimalna) długość

nagłówka wynosi 5. Pole typ usług (8 bitów) określa jakość usług jakiej wymaga

się od sieci. Znaczenie poszczególnych bitów tego pola jest następujące:

1. Pierwsze trzy pola określają tzw. pierwszeństwo, np. 000 - oznacza datagram

zwykły, 001 - priorytetowy, 010 - natychmiastowy, 011 błyskawiczny, a 100 -

datagram super błyskawiczny.

2. Bit czwarty to bit D określający opóźnienie w sieci (D=0 oznacza normalne,

D=1 małe opóźnienie).

3. Kolejny bit to bit T związany z przepustowością (T=0 oznacza normalną, a

T=1 dużą przepustowość).

4. Bit szósty R pozwala wybrać niezawodność w dostarczeniu datagramu (R=0

normalna, R=1 duża niezawodność).

5. Ostatnie dwa bity mają wartości równe zeru i są zarezerwowane dla

przyszłych zastosowań.

Pole całkowita długość pakietu (16 bitów)definiuje długość datagramu

IP w bajtach (oktetach). Maksymalna długość datagramu wynosi 65535 bajtów.

Kolejne trzy pola w nagłówku są wykorzystywane przez protokół IP do

fragmentacji datagramów i do operacji odwrotnej, tzn. do składnia z krótkich

fragmentów pierwotnego datagramu. Te pole to identyfikacja, flaga i przesunięci

fragmentu. Pole identyfikacja (16 bitów) jest używane do jednoznacznego

oznaczenia każdego fragmentu pierwotnego datagramu. Identyfikator

zamieszczony w tym polu jest powtarzany we wszystkich fragmentach

składających się na pierwotny datagram. Pole flagi zawiera 3 bity. (pierwszy -

zawsze zero, drugi określa czy można (1) czy nie można (0) fragmentować

datagram, trzeci - identyfikacja ostatniego fragmentu składającego się na

pierwotny datagram (wartość 0 określa ostatni, 1 oznacza kolejny fragment).

Pole przesunięcie fragmentu (13 bitów) wskazuje, którą częścią całości

pierwotnego datagramu jest dany fragment.

29

Poszczególne fragmenty mają pola danych o długości będącej wielkością

8 bitów. Wyjątkiem jest ostatni fragment, którego długość wynika z długości

pierwotnego datagramu. W polu tym podaje się o ile zawartość fragmentu jest

przesunięta w stosunku do początku pola danych pierwotnego datagramu.

Pole

czas życia (8 bitów) jest parametrem określającym ile czasu datagram może

przebywać w sieci. Czas życia datagramu ustala nadawca umieszczając w tym

polu liczbę naturalną. Przy przejściu przez kolejny router liczba ta jest

zmniejszana o 1. Zmniejszenie do zera powoduje odrzucenie datagramu. Pole

protokół (8 bitów) określa numer protokołu warstwy transportowej, do którego

należy przesłać dane z datagramu; np. numer 6 oznacza protokół TCP, a numer 1

protokół ICMP. Pole suma kontrolna nagłówka (16 bitów) służy do

sprawdzania poprawności odbioru wyłącznie nagłówka datagramu. Jest to

szesnastobitowe jedynkowe uzupełnienie jedynkowo uzupełnionej sumy

wszystkich szesnastobitowych słów nagłówka i danych pakietu. Przy obliczaniu

sumy kontrolnej przyjmuje się, że pole to zawiera same zera. Suma ta podlega

weryfikacji i modyfikacji np. w trakcie zmian pola czas życia w każdym węźle

sieci. Pola adres źródła i adres docelowy (po 32 bity) zawierają adresy IP

odpowiednio komputera źródłowego i docelowego. Pole opcje, zmiennej

długości będącej wielokrotnością 8 bitów, jest wykorzystywane do określenia

dodatkowych wymagań dotyczących sposobu przesyłania datagramu, np. do

rejestrowania przebytej trasy lub do zapamiętania trasy zdefiniowanej w węźle

źródłowym. Pole to nie musi występować w nagłówku datagramu. Pole

wypełnienie jest ewentualnym dopełnieniem pola opcje do wielokrotności 32

bitów .

2.5. Protokół ICMP

Protokół IP jako protokół bezpołączeniowy nie posiada mechanizmów

informowania o błędach. Do tego celu przeznaczony jest protokół ICMP(Internet

30

Control Message Protocol). Umożliwia on przesyłanie między komputerami lub

routerami informacji o błędach występujących w funkcjonowaniu sieci IP np.:

a) brak możliwości dostarczenia datagramu do miejsca przeznaczenia,

b) zmiana wcześniej wyznaczonej trasy przez jeden z pośredniczących routerów,

c) brak wolnej pamięci buforowej dla zapamiętania datagramu.

Informacje o tych zaburzeniach w działaniu sieci noszą nazwę

komunikatów. Komunikaty protokołu ICMP są przesyłane wewnątrz

datagramów IP. Każdy komunikat ma własny format. Jednak wszystkie

rozpoczynają się takimi samymi polami: typ, kod oraz suma kontrolna. Dalsze

pola zależą od typu komunikatu ICMP. Przykład formatu komunikatu o

kłopotach z parametrami datagramu IP jest przedstawiony na rysunku 2.6.

Rys. 2.6. Format komunikatu o ICMP

Pole typ określa rodzaj komunikatu, a pole kod opisuje kod błędu. W

polu suma kontrolna zawarte jest szesnastobitowe jedynkowe uzupełnienie

jedynkowo uzupełnionej sumy szesnastobitowych słów komunikatu ICMP. Pole

wskaźnik określa bajt, w którym wystąpił błąd, natomiast pole informacja

zawiera nagłówek oraz pierwsze 64 bity datagramu IP, w którym wykryto błąd .

Protokół ICMP posługuje się 12 komunikatami, które są wymieniane między

routerami i / lub komputerami. Komunikaty te dotyczą przede wszystkim:

31

a) przekroczenie czasu życia datagramu. Komunikat jest wysyłany jeśli po

wykonaniu odpowiednich obliczeń, wartość pola czas życia datagramu IP

osiągnie zero,

b) wystąpienia niezrozumiałego parametru. Komunikat ten sygnalizuje

wystąpienie niedopuszczalnej wartości w pewnym polu nagłówka datagramu IP,

c) wykrycie nieosiągalnych miejsc przeznaczenia. Jeśli nieosiągalnym adresatem

jest komputer w sieci, to komunikat ten jest wysyłany przez routery

pośredniczące w transferze datagramów. Jeżeli nieosiągalnym miejscem

przeznaczenia jest port, to komunikaty wysyła docelowy komputer,

d) chwilowego wstrzymania nadawania, gdy datagramy przybywają do

komputera lub pośredniczącego routera szybciej niż można je przetworzyć i

brakuje wolnej pamięci buforowej do ich zapamiętania,

e) sprawdzenia zasobów sieciowych. W celu sprawdzenia poprawności działania

zdalnego systemu wysyła się sygnał echa. System, po otrzymaniu tego

komunikatu, musi natychmiast odesłać go do nadawcy. Brak odpowiedzi

oznacza, że testowany system nie jest sprawny,

f) wskazania innej (krótszej) trasy dla datagramów,

g) określenia opóźnienia związanego z przesyłaniem datagramów przez sieć,

h) identyfikacji sieci przez dołączony do niej komputer (konfiguracja

komputera),

i) otrzymania przez komputer maski podsieci wykorzystywanej w sieci fizycznej.

32

3. Propozycje sposobów przyłączania

nadzorowanych urządzeń do sieci
TCP/IP

W trzecim rozdziale pracy został przedstawiony sposób

podłączania urządzeń do sieci TCP/IP przy wykorzystaniu sterownika

mikroprocesorowego pracującego jako konwerter interfejsów między

danym urządzeniem a różnym typem sieci.

33

3.1. Sterownik jako konwerter między siecią TCP/IP

a urządzeniem

Nadzorowanie urządzeń poprzez sieć TCP/IP, które nie posiadają

interfejsu sieciowego umożliwiającego bezpośrednie podłączenie urządzenia do

danego typu sieci, wymaga podłączenia modułu (sterownika) między interfejsem

danego urządzenia a interfejsem sieciowym. Moduł ten powinien odpowiadać za

konwersję sygnałów wejścia/wyjścia danego urządzenia na sygnały panujące w

medium transmisyjnym w danym typie sieci internetowej i odwrotnie, czyli

konwertować sygnały sieciowe na sygnały odpowiadające obsłudze danego

urządzenia. Przykład urządzenia podłączonego do sieci TCP/IP poprzez

sterownik odpowiadający za konwersję interfejsów jest przedstawiony na

rysunku 3.1.

Rys.3.1. Sposób podłączania nadzorowanych urządzeń do sieci TCP/IP

34

4. Projekt sterownika mikropro-

cesorowego umożliwiającego
zadawanie i odczyt stanów
urządzeń poprzez sieć TCP/IP

W tym rozdziale przedstawiłem projekt sterownika

umożliwiającego zadawanie i odczyt stanów poprzez sieć TCP/IP.

Najpierw scharakteryzowałem wybrany do sterownika mikrokontroler a

następnie przedstawiłem schemat blokowy urządzenia i schematy ideowe

jego poszczególnych bloków. Na końcu tego rozdziału umieściłem wykaz

elementów użytych w zaprojektowanym sterowniku.

35

4.1. Wybór mikrokontrolera

Projekt sterownika mikroprocesorowego umożliwiającego zadawanie i

odczyt stanów urządzeń poprzez sieć TCP/IP wykonałem na bazie

mikrokontrolera DS80C400 firmy Maxim/Dallas[8]. Wybrałem ten

mikrokontroler ze względu, iż producent zaimplementował pełny stos

protokołów TCP/IP w pamięci ROM mikrokontrolera oraz udostępnia pełne

oprogramowanie do tego mikrokontrolera. Przy projektowaniu sterownika

pomocny przydał się kit oferowany przez firmę Maxim/Dallas o nazwie TINI400

[10], gdzie wykonany przeze mnie projekt oparty jest na tym zestawie.

Wbudowanie stosu TCP/IP przez producenta ułatwiło mi wykonanie sterownika

pracującego w sieci internetowej. Oprócz zaimplementowania stosu TCP/IP,

producent wyposażył mikrokontroler DS80C400 w wiele urządzeń

peryferyjnych. Posiada on trzy porty szeregowe, kontroler interfejsu CAN 2.0B,

interfejs jednoliniowy (1-Wire Master) i 64 linie we/wy. Zaimplementowany stos

TCP/IP pozwala na obsługę jednocześnie do 32 połączeń TCP i na transfer

danych do 5Mbps przez sieć Ethernet. Maksymalna częstotliwość oscylatora

zasilającego mikrokontroler wynosząca 75MHz pozwala na uzyskanie

minimalnego cyklu instrukcji równego 54ns. Dostęp do zewnętrznej pamięci

programu i danych jest realizowany przez 24-bitowe adresowanie, które

umożliwia zaadresowanie 16MB obszaru danych. W celu poprawy transferu

danych pomiędzy mikrokontrolerem a pamięcią wprowadzono cztery rejestry

indeksowe, które mogą być konfigurowane tak, aby inkrementowały lub

dekrementowały swoją zawartość w zależności od wykonywanej instrukcji.

Sprzętowy „math accelerator” znacznie przyspiesza wykonywanie 32- i 16-

bitowego mnożenia i dzielenia i innych operacji arytmetycznych.

Cechy układu :

36

• Wykonuje pojedynczy cykl instrukcji w 54 ns .

• Częstotliwość oscylatora od DC do 75MHz.

• Ciągła przestrzeń adresowa do 16MB.

• Cztery rejestry indeksowe z automatyczną inkrementacją/dekrementacją.

• Sprzętowy 16/32-bitowy Math Accelator.

• Kontroler 10/100Ethernet Media Accese Controller (MAC).

• Kontroler interfejsu 1-Wire Net.

• Trzy full-duplex porty szeregowe.

• Do ośmiu dwukierunkowych 8-bitowych portów (64 linie we/wy).

• Zapewnia możliwość bootowania (Network Boot Over Ethernet) za

pomocą protokołów DHCP i TFTP.

• Posiada zaimplementowany w ROM pełny, dostępny przez aplikację

użytkownika stos TCP/IP.

• Zaimplementowano protokóły IPv4 i IPv6.

• Zaimplementowano protokoły UDP, TCP, DHCP, ICMP, i IGMP.

• Adres MAC może być opcjonalnie pobrany z układu IEEE-Registered

DS2502-E48.

• Interfejs Ethernet obsługujący standardy IEEE 802.3 MII (10/100Mbps) i

ENDEC (10Mbps) z możliwością wybory PHY.

• 8kB pamięci w układzie dla pakietów danych wysyłanych i odbieranych

na TX/RX z jednostką kontroli bufora redukującą obciążenie jednostki
centralnej.

• Realizuje operacje half- lub full-duplex z kontrolą przepływu danych.

• Filtracja adresów Multicast/Broadcast z obsługą VLAN.

• W pełni funkcjonalny kontroler interfejsu CAN 2.0B(obsługa 11-

bitowych i 29-bitowych identyfikatorów).

• Obsługa 16 źródeł przerwań w tym 6 zewnętrznych.

• Układ posiada cztery 16-bitowe Timer/Couters.

• Układ redukcji zakłóceń elektromagnetycznych (EMI).

• Programowalny układ watchdog.

• Układ detekcji uszkodzenia oscylatora.

• Programowany generator wykorzystywany przez interfejs IrDA.

• Zaawansowany układ redukcji pobieranej mocy (praca rdzenia przy 1,8V,

operacje przy napięciu 3,3V, tryby idle i stop.

• Możliwość wyboru 8/10-bitowego wskaźnika stosu.

• Dodatkowa 1kB wewnętrzna pamięć SRAM wykorzystywana jako stos

dla danych.

• 16-bitowe/24-bitowe strony w trybie 24-bitowej obsługi pamięci.

• Możliwość wyboru pracy interfejsu do obsługi pamięci zewnętrznej :praca

multipleksowa lub niemultipleksowa.

•

Możliwość programowania mikrokontrolera w systemie (In-System
Programming).

37

Schemat blokowy mikrokontrolera DS80C400 jest przedstawiony na rysunku
4.1.

Rys.4.1. Schemat blokowy mikrokontrolera DS80C400

38

Kontrloler Ethernetu 10/100Mbps układu DS80C400 obsługuje

protokoły warstwy fizycznej wymagane przez standard Ethernet/IEEE 802.3.

Zapewnia on mechanizmy do odbioru, nadawania i kontroli przepływu danych

przez niezależny od nośnika interfejs (MII), który zawiera szeregowy interfejs

pozwalający na konfiguracje zewnętrznych urządzeń fizycznych (external PHY

devices). Interfejs MII może być konfigurowany do pracy w trybie half-duplex

lub full-duplex przy prędkości 10Mbps lub 100Mbps, lub może pracować w

trybie 10Mbps ENDEC. Dla trybu half-duplex układ DS80C400 współdzieli

fizyczny nośnik Ethernetu z innymi stacjami w sieci. DS80C400 przy dostępie

do sieci korzysta z metody CSMA/CD. Schemat blokowy interfejsu Ethernet

mikrokontrolera DS80C400 jest przedstawiłem na rysunku 4.2.

Rys.4.2. Schemat blokowy interfejsu Ethernet mikrokontrolera DS80C400

Mikrokontroler DS80C400 posiada 64kB wewnętrzną pamięć ROM

(TINI400 ROM), w której zaimplementowano wiele funkcji dostępnych dla

aplikacji napisanych przez użytkownika. Każda z tych funkcji znajduje się pod

39

określonym adresem w pamięci programu. Adres absolutny każdej funkcji z

TINI400 ROM musi być przeczytany z tabeli eksportu adresów (również

znajdującej się w pamięci ROM). Ze względu na elastyczność oprogramowania

tabela eksportu adresów nie znajduje się pod określonym adresem, lecz jej

początek jest wskazywany przez 3-bajtowy wskaźnik znajdujący się pod adresem

(trzema adresami): FF0002h (XSB), FF0003h (MSB), FF0004h (LSB). Trzy

pierwsze bajty tabeli zawierają liczbę funkcji w niej zawartych. Pozostałe bajty

tabeli (z krokiem co 3 bajty) zawierają absolutne adresy funkcji eksportowanych

z pamięci ROM. Sposób obliczania absolutnych adresów funkcji jest

przedstawiony na rysunku 4.3

.

Rys. 4.3. Sposób obliczania absolutnych adresów funkcji w mikrokontrolerze

DS80C400

W pamięci ROM mikrokontrolera zostały zaimplementowane funkcje

obsługi gniazd TCP/IP zgodnie ze standardem Berkley. Stos obsługuje protokoły

TCP i UDP, umożliwiając utworzenie do 24 gniazd klient/serwer dla IPv4 lub

IPv6. W tabeli 4.1 przedstawiona jest lista funkcji obsługi gniazd, które zostały

zaimplementowane w pamięci ROM.

40

Tabela. 4.1 Funkcje obsługi gniazd zaimplementowane w pamięci ROM.

N

Na rysunku 4.4. przedstawiona jest typowa kolejność wywołań funkcji do

tworzenia połączeń server - klient dla protokołów TCP i UDP w

mikrokontrolerze DS80C400.

Rys.4.4. Tworzenie połączeń TCP i UDP

41

4.2. Projekt schematu blokowego sterownika

Przy projektowaniu schematu blokowego sterownika umożliwiającego

zadawanie i odczyt stanów poprzez sieć TCP/IP uwzględniłem następujące

czynniki:

• Mikrokontroler DS80C400 nie ma wewnętrznej pamięci do

przechowywania aplikacji napisanych przez użytkownika .

• Sterownik będzie korzystał z aplikacji napisanych w języku Java oraz

do pamięci programu zostanie zainstalowanie środowisko wykonawcze

TINI Java Runtime Environment [9] poprzez program MTK

(Microcontroller Tool Kit) [10] całość jest udostępniona przez firmę

Maxim/Dallas.

•

Sterownik zostanie podłączony do sieci typu Ethernet standardu

10Base-T i 100Base-TX.

• Mikrokontroler będzie się łączył z układem PHY(PHysical laYer)

wykorzystując interfejs MII (Media Independent Interface).

• Adres fizyczny MAC będzie odczytywany przez mikrokontroler z

układu DS2502-E48 [11].

• Sterownik zostanie wyposażony w układ RTC (Real Time Clock).

•

Uruchamianie aplikacji na sterowniku będzie wymagało wyposażenia

go w port szeregowy RS-232 typu DCE (Data Communication

Equipment) dodatkowo sterownik będzie wyposażony w port

szeregowy RS-232 typu DTE(Data Terminal Equipment).

42

• Sterownik będzie wyposażony w układ rezerwowego zasilania (battery

backup) dla przechowywania zawartości pamięci RAM i modułu

liczącego w układzie RTC, w chwili zaniku zasilania zasadniczego.

• Projekt sterownika zostanie wyposażony w blok zasilania z

odpowiednimi wartościami napięć do poszczególnych bloków

sterownika.

Projekt schematu blokowego umieściłem na rysunku 4.5

Rys.4.5 Schemat blokowy sterownika

43

4.3. Blok mikrokontrolera

Schemat ideowy bloku mikrokontrolera przedstawiłem na rysunku 4.6.

Mikrokontroler DS80C400 jest zasilany dwoma napięciami +1,8V(praca rdzenia)

i +3V(operacje logiczne na I/O). Z blokiem pamięci pracuje w trybie

demultipleksowym. Mikrokontroler taktowany jest kwarcem o częstotliwości

14,7456 MHz, jest to optymalna częstotliwość kwarcu dla tego mikrokontrolera,

z faktu, że DS80C400 ma wewnętrzny mnożnik 2X/4X częstotliwości

rezonatora kwarcowego.

Rys.4.6. Schemat ideowy bloku mikrokontrolera

44

Blok mikrokontrolera został wyposażony w dwie listwy szpilkowe 4Pin

(J10 i J11) oraz punkt lutowniczy J12, służące jako port I/O sterownika.

4.4. Blok pamięci

Schemat ideowy bloku pamięci jest przestawiony na rysunku 4.7. Blok

pamięci został wyposażony w 1MB pamięci Flash realizowanej na układzie U4

firmy AMD o oznaczeniu AM29LV081[12]. Jest to pamięć o organizacji

1MBx8bit, pamięć ta cechuje się niskim poborem mocy oraz ma gwarantowaną

przez producenta ilość cykli zapisu danych równą 10

6

.

Rys.4.7. Schemat ideowy bloku pamięci

45

Uaktywnienie pamięci Flash przez mikrokontroler jest dokonywane poprzez

wstawienie stanu niskiego na linii EnFlash. Podanie przez mikrokontroler stanu

niskiego na linii OutReset powoduje reset pamięci Flash. Blok pamięci RAM

mikrosterownika tworzą dwie 512kB pamięci RAM, o organizacji 512kBx8bit,

układy U2 i U3 firmy AMIC o symbolu LP62S4096[13]. Pamięci RAM również

mają niski pobór mocy oraz mogą pracować w trybie rezerwowego zasilania w

tzw. „battery backup operation”. Wybór danej pamięci RAM jest dokonywany

przez wstawienie przez mikrokontroler stanu niskiego na linii EnRAM1 lub

EnRAM2. Zastosowane pamięci, zarówno Flash i RAM maja jednakowy czas

dostępu równy 70ns. Układy U5, U6 produkcji Maxim/Dallas o oznaczeniu

MAX 6365[14], tworzą wraz z 3-voltową baterią litową układ rezerwowego

zasilania pamięci RAM. Układy firmy w zależności od wersji mają różny próg

napięcia V

TH

, przy którym w przypadku zaniku napięcia zasilania pamięci RAM

następuje przełączenie na zasilania bateryjne tej pamięci. W projekcie

sterownika zastosowane są układy MAX6365PKA31 z typową wartością

napięcia progu przełączania V

TH

= 3,08V, tak więc jeżeli napięcie zasilania

pamięci RAM obniży się poniżej danej wartości V

TH

, nastąpi przełączenie

zasilania na zasilanie bateryjne pamięci RAM. W czasie zaniku

zasilania układy

U5 i U6 generują sygnał resetu poprzez wyjście

RST

dla mikrokontrolera oraz

wstawiają stan niski na wyjściach

CEO

, uniemożliwiając w ten sposób wybór

pamięci dokonywany na liniach EnRAM1 i EnRAM2. Linia ResetIn służy do

resetowania mikrokontrolera DS80C400 w momencie uruchamiania programu

MTK na komputerze PC. Linia ta wykorzystuje sygnał DTR portu szeregowego.

Podanie stanu niskiego na linii ResetIn powoduje wstawienie sygnału niskiego

na wyjściach

RST

układów U5 i U6. Ponieważ mikrokontroler DS80C400 do

resetowania się potrzebuje sygnału wysokiego na linii Reset, konieczne jest

zastosowanie inwertera, który jest wykonany na tranzystorze Q3 produkcji

Fairchild semiconductor o symbolu BS84. Zapis i odczyt pamięci RAM i Flash

jest wykonywany przez mikrokontroler poprzez podanie sygnału niskiego

odpowiednio na liniach Wr i Psen.

46

4.5. Blok PHY

Schemat ideowy bloku PHY przedstawiłem na rysunku 4.8. Transceiver

do sieci Ethernet tworzy układ U7 produkcji Realtek o oznaczeniu RTL

8201BL[15]. Układ ten obsługuje standardy sieci Ethernet typu 10Base-T,

100Base-TX oraz 100Base-FX. Praca układu może odbywać się w trybie full

duplex / half duplex, w strukturze układu zawarty jest mechanizm

autonegocjacji, służący do ustalania parametrów łącza(100Base-TX), układ

obsługuje interfejs MII i SNI, ten ostatni jest dostępny tylko dla standardu

10Base-T.

Rys.4.8. Schemat ideowy bloku PHY

47

Konfiguracja układu może odbywać sprzętowo poprzez podanie odpowiednich

stanów logicznych na wybranych wejściach układu, lub tez może odbywać

programowo przez kontroler MAC poprzez linie MDC/MDIO

.

Schemat blokowy

układu RTL8201 BL umieściłem na rysunku 4.9.

Rys.4.9. Schemat blokowy układu RTL8201 BL

Struktura układu zawiera blok obsługi prędkości łącza 100Mbit/s (

wykorzystuje kod 4B/5B oraz liniowy trójpoziomowy kod MLT-3), blok obsługi

prędkości łącza 10Mbit/s (wykorzystywany kod Manchester) oraz jednostkę

przełączającą 10/100 half/full Switch Logic, która komunikuje bezpośrednio z

48

kontrolerem MAC poprzez interfejs MII/SNI . Interfejs MII składa się z 18

sygnałów (TXD[3:0], TXEN, TXCLK, CRS, COL, MDC, MDIO, RXD[3:0],

RXDV, RXCLK oraz RXER/FXEN). Dane są obsługiwane w sposób

synchroniczny i w zależności od prędkości łącza sygnały zegara TXCLK,

RXCLK wynoszą 25MHz przy 100Mbit/s i 2,5MHz przy 10Mbit/s. Podczas

nadawania MAC najpierw wstawia „jedynkę” na linii TXEN a następnie

zamienia dane na 4-bitowe ramki i podaje je na linie TXD[3:0] bloku PHY.

Transceiver PHY próbkuje dane na liniach TXD[3:0] z częstotliwością zegara na

linii TXCLK. Podczas odbioru danych układ PHY wstawia „jedynkę” na linii

RXEN a następnie podaje układowi MAC z częstotliwością zegara RXCLK, 4-

bitową ramkę na linie RXD[3:0]. Linie CRS i COL służą do detekcji i obsługi

kolizji. Układ RTL8201BL jest odseparowany od sieci Ethernet poprzez

transformator separujący. W projekcie został użyty transformator T1 firmy

Bothhand o oznaczeniu 16PT8515[20], z specyfikacją zgodną do układu

RTL8201BL. Jest to podwójny transformator separujący, z przekładnią sygnałów

nadawania równą 1:

2

oraz z przekładnią sygnałów odbierania równą 1:1.

Sprzętowa konfiguracja parametrów łącza jest wykonywana przez

przełącznik S1, gdzie poszczególne sekcje przełącznika oznaczają:

1. Tryb PWD (Power Down Mode), tryb o obniżonym poborze mocy, odłączony

zostaje interfejs zarządzania MDC/MDIO, tryb aktywowany stanem wysokim.

2. Sekcja nie podłączona

3. Tryb LDPS (Link Down Power Saving)

4. Tryb RPTR

5.Wybór prędkości pracy transceivera (10Mbit/s -stan niski lub 100Mbit/s-stan

wysoki).

6.Wybór trybu pracy transceivera Full duplex-stan wysoki lub Half duplex-stan

niski.

7. Tryb autonegocjacji.

49

4.6. Blok RTC i adresu MAC

Schemat ideowy bloku RTC i adresu MAC przedstawiłem na rysunku

4.10. Adres fizyczny MAC sterownika jest pobierany z układu U9 firmy

Maxim/Dallas o oznaczeniu DS2502-E48. Jest to pamięć o pojemności 1kbit-a

typu OTP-EPROM, gdzie w pierwszych 32-bajtach tej pamięci jest zawarty

unikatowy 48-bitowy adres MAC przydzielony przez IEEE. Pierwsze 32-bajty

pamięci DS2502-E48 są chronione przed zapisem, tak więc dla użytkownika jest

dostępne raz programowalne 768 bity. Do komunikacji pamięci U9 z

mikrokontrolerem wykorzystywany jest interfejs 1-Wire.

Rys.4.10. Schemat ideowy bloku adresu MAC (po lewej stronie) i bloku RTC (po

prawej stronie)

Blok RTC oparty jest na układzie U8 o symbolu DS1672U-33 [16] firmy

Maxim/Dallas. Jest to układ czasowy rodziny Timekeeper, wyposażony w

wewnętrzny obwód resetujący i przełącznik zasilania podtrzymującego. Pozwala

wyeliminować kilka niezależnych układów scalonych, wymaganych dotąd do

realizacji tych funkcji oraz pracuje z niskim napięciem zasilania z zakresu od

2,0V do 3,3V. Komunikacja z mikroprocesorem jest realizowana za

50

pośrednictwem 2-żyłowego interfejsu. DS1672U-33 zawiera 32-bitowy licznik

sekund, z którego na podstawie programowego algorytmu wyznaczane są data i

godzina. W projekcie sterownika układ DS1672 jest

taktowany wbudowanym

generatorem, wymagającym dołączenia zewnętrznego rezonatora kwarcowego

32,768 kHz. Podtrzymanie pracy zegara zapewnia dodatkowe wyprowadzenie

zasilające, przeznaczone do podłączenia baterii o napięciu 3 V.

4.7. Blok zasilania

Schemat ideowy bloku zasilania jest przedstawiony na rysunku 4.11. Do złącza

J2 dostarczane jest napięcie niestabilizowane ze zewnętrznego zasilacza o

wartości DC = 8 V...12V. Układ U9 jest to typowy stabilizator 5V w obudowie

TO-220 o oznaczeniu UA7805. Układ U11 tworzy stabilizator napięcia 3,3V,

który jest wykonany na układzie MAX1692 [17] firmy Maxim/Dallas. Jest to

impulsowy stabilizator PWM, charakteryzujący się bardzo dobrą sprawnością

(95% według danych producenta) i z wydajność prądową około 600mA Na

rysunku 4.11 jest przedstawiony typowy układ połączeń dla tego stabilizatora.

Ponieważ jest to stabilizator impulsowy na wyjściu został zastosowany koralik

ferrydowy L4 służący do tłumienia częstotliwość pracy stabilizatora. Układ U12

o symbolu MAX1792EUA18 [18] również produkcji MaximDallas jest 1,8 V

stabilizatorem napięcia typu Low-dropout dla zasilania rdzenia mikrokontrolera

DS80C400.

51

Rys. 4.11 Schemat ideowy bloku zasilania

4.8. Blok interfejsu RS-232

Schemat ideowy bloku interfejsu RS-232 umieściłem na rys.4.12. Układ

U13 o oznaczeniu MAX560 [19] produkcji Maxim/Dallas, jest 3,3V

transceiverem obsługującym standard transmisji szeregowej RS-232. W 28-

nóżkowej obudowie typu SOP producent umieścił bufory odwracające składające

się z czterech linii nadawczych i pięciu linii odbiorczych oraz konwerter

poziomów napięć z +3,3V na

±6,6V. Konwerter napięć wymaga dołączenia

czterech kondensatorów o pojemności 1

µF .

Rys.4.12 Schemat ideowy bloku interfejsu RS-232

W projekcie został użyty port typu DCE (złącze J8), do którego jest

„ładowane” oprogramowanie sterownika poprzez komputer PC z interfejsem

52

szeregowym oraz port typu DTE (złącze J9) oraz port typu DTE (złącze J9),

gdzie w przypadku odpowiedniego programu umieszczonego w sterowniku

mogą zostać podłączone inne urządzenia posiadające port szeregowy. Układ

MAX560 posiada tzw. tryb „Shutdown Mode”, przy którym linie nadawcze

transceivera są odłączone, wyłączony zostaje też konwerter napięć a sygnały +V

i –V zostają podłączone z sygnałami odpowiednio VCC i GND. Uaktywnienie

tego trybu jest dokonywane przez wstawieni stanu L na linii

SHDN

transceivera

do którego służy złącze J7. Złącze J6 umożliwia reset mikrokontrolera w

momencie uruchamiania programu MTK na komputerze PC.

4.9. Układ do odczytu temperatury i włączania

diody LED

Zaprojektowany sterownik umożliwia poprzez sieć TCP/IP odczyt

temperatury z zewnętrznego czujnika temperatury oraz zapalanie diody LED .

Do obsługi tych urządzeń potrzeba jest przystawka (oddzielna płytka PCB),

schemat ideowy przystawki umieściłem na rysunku 4.13.

53

Rys.4.13. Schemat ideowy przystawki do pomiaru temperatury i
włączania

diody LED

Czujnikiem temperatury jest układ U15 o oznaczeniu DS1820 [20]

produkcji Maxim/Dallas. Jest cyfrowy czujnik temperatury o bardzo dobrej

dokładności pomiaru (

± 0,5°C w zakresie od -10°C do +85°C), wyposażony w

interfejs 1-Wire. Układ U14 o symbolu DS2480B [21] również firmy

Maxim/Dallas jest konwerterem interfejsu jednoliniowego (1-Wire) na interfejs

szeregowy. Dioda D4 jest zapalana przez odpowiednią aplikację wykorzystującą

sieć TCP/IP.

4.10. Wykaz elementów

Wykaz elementów użytych do wykonania sterownika jest przedstawiony poniżej.

Rezystory :
R5,R11,R12,R13,R14,R15,R16....................................................................5,1k
R27............................................................................................................... 10
Rezystory SMD :
R1,R3,R4,R10,R31,R33............................................................................... 10k
R2................................................................................................................ 1,8k
R6................................................................................................................ 5,6k
R20,R21,R24,R25...................................................................................... 5,1k
R7,R8,R9,R10.............................................................................................. 50
R17,R18....................................................................................................... 75
R19,R22,R34................................................................................................ 510
R28............................................................................................................... 2,2k
R29.............................................................................................................. 200k
R30.............................................................................................................. 120k
R32.............................................................................................................. 47k

Kondensatory SMD :
C1,C2,C3,C4,C5,C8,C9,C10,C11,C12,C13,C16, C17,C18,
C20,C21,C22,C23,C24,C26,C27,C28,C30,C32,C35,C39,C45,C48...........100nF
C6,C7...........................................................................................................27pF
C14,C15.......................................................................................................20pF
C34...............................................................................................................220nF
C36...............................................................................................................47pF

Kondensatory tantalowe SMD :

54

C25,C33,C38,C40........................................................................................22uF/16V
C41,C42,C43,C44,C46................................................................................1uF/16V

Kondensatory elektrolityczne :
C31.......................................................................................... ...................47uF/16V

Diody SMD :
DN1..............................................................................................................BAT54S
D3.................................................................................................................BAT54

Tranzystory SMD :
Q1,Q3,Q4…………………………………………………………………..BSS84
Q2…………………………………………………………………………..2N7002

Układy scalone :
U1……………………………………………………………………….DS80C400




U2,U3……………………………………………….………………… LP62S4096
U4.............................................................................................................AM29LV081
U5,U6.....................................................................................................MAX6365PKA31
U7............................................................................................................RTL8201BL
U8............................................................................................................DS1672U-33
U9............................................................................................................DS2502-E48
U10............................................................................................................UA7805
U11............................................................................................................MAX1672
U12.......................................................................................................MAX1792EUA18
U13..............................................................................................................MAX560
U14..............................................................................................................DS2480B
U15...............................................................................................................DS1820


Rezonatory kwarcowe:
Y1................................................................................................................14,7456MHz
Y2................................................................................................................25,0000MHz
Y3................................................................................................................32,768kHz




Inne :
Bateria litowa 3V BT1: CR2016
Diody LED :D1,D2
Gniazda : RJ-45, DB9-M, DB9-F, gniazdo zasilania
Przełącznik typu „SwitchDIP”
Listwy szpilkowe

55

:

5. Wykonanie i uruchomienie zapro-
jektowanego sterownika

W rozdziale piątym pracy przedstawiłem projekt płytki drukowanej

sterownika, sposób wykonania płytki drukowanej, uruchomienie

sterownika oraz zainstalowanie przykładowych aplikacji do danego

sterownika.

56

5.1. Projekt płytki drukowanej

Płytkę drukowaną sterownika internetowego zaprojektowałem przy

pomocy programu Protel 99 SE, firmy Protel International. Projekt płytki

drukowanej wykonałem przy użyciu dwóch warstw, co zminimalizowało

wymiary płytki, jej wymiary wynoszą 115mmx115mm. Dla skutecznego

rozprowadzenia prądów zasilania, szerokości ścieżek zasilających i masy zostały

powiększone do niezbędnych rozmiarów. Szerokości ścieżek zaczynają się od

0,2mm do 3mm. Małe szerokości połączeń są użyte do komunikacji

mikrokontrolera z blokiem pamięci i blokiem PHY, ponieważ większość tych

układów ma rozstaw wyprowadzeń równy 0,5mm, a to z kolei wymusza

odpowiednią szerokość ścieżki. Najgrubsze połączenia stanowią linie zasilające

poszczególne układy sterownika. Na płytce drukowanej sterownika zostały

umieszczone wszystkie złącza występujące w schemacie ideowym sterownika.

W warstwie tylnej płytki drukowanej zostało przewidziane miejsce na 3-voltową

57

baterię BT1 dla układu rezerwowego zasilania. Na rysunku 5.1. przedstawiłem

widok górnej warstwy płytki drukowanej (Top Layer), natomiast na rysunku 5.2

przedstawiony jest widok tylnej warstwy płytki drukowanej (Bottom Layer).

Zamieszczone na rysunkach płytki są przedstawione w skali 1:1.

58

Rys.5.1. Widok górnej warstwy płytki drukowanej sterownika

w skali 1:1

59

Rys.5.2. Widok dolnej warstwy płytki drukowanej sterownika

w skali 1:1

5.2 Wykonanie sterownika

Płytka drukowana została wykonana metodą fotolitografii. Jako środek

światłoczuły został użyty positiv20. Na początku laminat dwustronny został

odpowiednio wycięty (1cm więcej od każdego boku ) a następnie został

wypolerowany bardzo drobnoziarnistym papierem ściernym. Użycie papieru

ściernego dokładnie wyczyściło laminat od innych substancji. Po przygotowaniu

laminatu została nałożona warstwa emulsji światłoczułej (positiv20), która

następnie została wysuszona. Widoki warstwy górnej i dolnej zostały

wydrukowane na folii z drukarki atramentowej ustawionej na maksymalną

rozdzielczość. Do naświetlania emulsji użyłem lampy halogenowej. Na każdą

powierzchnię laminatu nakładem folię z wzorem płytki ( atramentem do

powierzchni laminatu) i przyciskałem kawałkiem pleksy w celu dokładnego

dociśnięcia folii do laminatu. Przedstawiony proces naświetlania wymagał około

30 minut naświetlenia emulsji światłoczułej dla każdej z obu powierzchni

laminatu. Trudnością przy naświetlaniu laminatu okazało się spasowanie obu

60

warstw co wymagało wywiercenia kilku otworów służących jako przelotki na

płytce drukowanej i spasowania folii pod „światło”. Po naświetleniu

poszczególnych warstw płytka drukowana musiała zostać wywołana

wykorzystując do tego wodorotlenek sodu NaOH w odpowiedniej proporcji z

wodą. Po wywołaniu płytki drukowanej została ona wytrawiona za pomocą

środka trawiącego B327. Mając gotowa płytkę drukowaną sterownika

przystąpiłem do nawiercania otworów na poszczególne elementy sterownika oraz

przelotek, które w projekcie są wykonane poprzez cienki drucik lutowany na

górnej i dolnej warstwie płytki. Otwory były wiercone wiertłem o średnicy od

0,5mm do 0,8mm. Następnym etapem wykonania sterownika było wlutowanie

wszystkich układów sterownika. Na początku zostały zalutowane druciki służące

jako przelotki oraz najmniejsze elementy ( rezystory SMD, kondensatory SMD

diody SMD i tranzystory SMD). Następnym krokiem było zmontowanie bloku

zasilania , gdzie po sprawdzeniu zgodności napięć wyjściowych zamontowane

zostały pozostałe układy sterownika. Płytka drukowana została wyposażona w

„stopki” wykonane z czterech śrubek M3 wkręconych na rogach płytki. Zdjęcie

wykonanego sterownika umieściłem na rysunku 5.3.

61

5.3.

Zdjęcie wykonanego sterownika umożliwiającego zadawanie i odczyt

stanów poprzez sieć TCP/IP

5.3. Zainstalowanie środowiska wykonawczego do

sterownika

Przedstawiony projekt sterownika umożliwiający zadawanie i odczyt

stanów poprzez sieć TCP/IP wykorzystuje aplikacje napisane w języku Java.

Aplikacje te są wykonywane w sterowniku poprzez środowisko wykonawcze

TINI Java Runtime Environment, które musi być zainstalowane wewnątrz

sterownika. Do zainstalowania środowiska wykonawczego potrzebny jest

program o nazwie MicroController Tool Kit (MTK) oraz oprogramowanie TINI

SDK w wersji co najmniej 1.1. Program MTK pracuje pod systemem Windows

98/Me/2000/XP. Po uruchomieniu programu MTK, musimy skonfigurować port

szeregowy do którego jest podłączony sterownik. Połączenie sterownika z

komputerem PC odbywa się kablem typu „prosty”. Po skonfigurowaniu portu

szeregowego i jego otwarciu wyświetla program ładujący tzw. Auto Boot

Loader, który jest na stałe zapisany w pamięci ROM mikrokontrolera. Program

ładujący zarządza ładowanie środowiska wykonawczego do pamięci flash

62

sterownika. Na rysunku 5.4. przedstawiłem widok programu MTK z

uruchomionym Auto Boot Loader-em. Do zainstalowania TINI Java Runtime

Environment wymagane jest załadowanie dwóch plików : tini.tbin oraz

slush.tbin, które znajdują się w oprogramowaniu TINI SDK. Pliki można

załadować wybierając zakładkę File

→Load Tbin i ustawiająć ścieżkę dostępu do

TINI SDK. Plik tini.tbin jest ładowany w pamięci flash o adresie od 400000h do

47000h natomiast plik slush.tbin załadowany zostaje w pamięci flash od adresu

47100h do adresu 48000h ,przestań pamięci miedzy adresami 47000h a 47100h

zostaje wykorzystana do zapamiętywania ustawień sieciowych. sterownika. Po

załadowaniu tych dwóch plików sterownik ma zainstalowane środowisko

wykonawcze, które składa się z systemu operacyjnego TINI OS wirtualnej

maszyny Java i interfejsu API (Application Programming Interface ). Widok

programu MTK przedstawiającego system operacyjny TINI OS umieściłem na

rysunku 5.5.

Rys.5.4 Widok programu MTK z uruchomionym Auto Boot Loader -em

63

Rys.5.5 Widok programu MTK z uruchomionym systemem operacyjnym

TINI OS

Po zalogowaniu się do środowiska TINI uruchamia się prosty interpretator

poleceń systemu operacyjnego tzw. Slush. Interpretator ten steruje funkcjami

sytemu poprzez wpisanie odpowiedniego polecenia np. dane o konfiguracji

sieciowej są wywoływane poprzez wpisanie polecenia ipconfig. Na rysunku 5.6.

umieściłem widok programu MTK przedstawiającego ustawienia sieciowe

sterownika, wyświetlany jest również na nim adres MAC (Ethernet Address)

pochodzący od układu DS2502-E48.

64

Rys.5.6 Widok programu MTK przedstawiającego ustawienia sieciowe sterownika

Zmiana ustawień sieciowych jest dokonywana poprzez dodanie do polecenia

odpowiedniego znaku oraz wartości danej np. polecenie ipconfig –a 192.168.0.2

ustawia adres IP sterownika. Oprócz ustawień sieciowych slush umożliwia

sterowaniem układu RTC, umożliwia połączenia sieciowe FTP oraz połączenia

Telnet. Uruchamia również aplikację pisane w języku Java po wcześniejszym

przekształceniu beta kodu ( pliki z rozszerzeniem .class) na pliki uruchamiane

przez maszynę wirtualną Java w środowisku TINI (pliki z rozszerzeniem .tini).

5.4. Uruchomienie przykładowych aplikacji

W projekcie zostały użyte dwie aplikacje napisane w języku Java (po

niewielkiej modyfikacji), które dostępne są na stronie internetowej

producenta mikrokontrolera po DS80C400. Aplikacje te umożliwiają

zadawanie i odczyt stanów poprzez sieć TCP/IP. Pierwsza z nich o

nazwie TINIWebServer umożliwia odczyt temperatury z czujnika

dołączonego do sterownika. Druga aplikacja o nazwie TINIWebSwitch

umożliwia zadawanie stanu (włączanie/wyłącznie diody LED

podłączonej do sterownika). Do komunikacji z użytkownikiem obie

aplikacje wykorzystują przeglądarkę internetową np. Internet Explorer.

Uruchomienie danej aplikacji wymaga załadowania do pamięci RAM

sterownika poprzez połączenie ftp komputera PC z sterownikiem, pliku

65

odpowiednio TINIWebSwitch.tini lub TINIWebServer.tini. Najpierw

pliki źródłowe muszą zostać skompilowane do czego wykorzystuje się

środowisko JDK Standard Edition 1.2.2 firmy Sun [22], które jest

instalowane na komputerze PC. Po skompilowaniu plików źródłowych

muszą one zostać poddane konwersji aby mogły być uruchamiane przez

JVM środowiska TINI, do czego służą aplikacje Java o nazwie

TINIConvertor lub BuildDependency znajdujące się w TINI SDK w

pliku tini.jar . Uruchamiane są one na komputerze PC korzystając z

wiersza poleceń. Przykład konwersji plików z rozszerzeniem .class na

pliki z rozszerzeniem .tini aplikacji TINIWebServer umieściłem poniżej:

C:\jdk1.2.2\bin>java –classpath h:\tini1.12\bin\tini.jar BuildDependency –f
h:\tini1.12\bin\WebWorker.class –f h:\tini1.12\bin\TemperatureWorker.class
-f h:\tini1.12\bin\TINIWebServer.class -o h:\tini1.12\bin\TINIWebServer.tini
-d h:\tini1.12\bin\tini.db –add OneWireContainer10 –x h:\tini1.12\bin\owapi_
dep.txt –p h:\tini1.12\bin\owapi_dependencies_TINI.jar –p h:\tini1.12\bin\
modules.jar –add HTTPSERVER

Ścieżka dostępu h:\tini1.12\bin wskazuje na oprogramowanie TINI SDK dla

systemu TINI .Poszczególne znaczniki oznaczają:

-f - wskazuje , które pliki muszą być skonwertowane (pliki z

rozszerzeniem .class),

-o - wskazuje miejsce umieszczenia pliku skonwertowanego (plik z

rozszerzeniem .tini),

-d - wskazuje miejsce utworzenia bazy danych dla systemu TINI,
-p -wskazuje miejsce klasy zależnej,
-x -wskazuje listę plików zależnych,
-add -dodaje bibliotekę,

Po wygenerowaniu pliku z rozszerzeniem .tini należy umieścić go w

pamięci sterownika, do czego wykorzystujemy połączenie ftp. Następnie

przy włączonym interpretatorze poleceń Slush uruchamiamy aplikację

TINIWebServer poprzez polecenie java TINIWebServer.tini .Możemy

teraz włączyć przeglądarkę i w pasku adresu wpisać adres internetowy

sterownika poprzez http:// 192. 168. 0. 2. przy prawidłowo skonfigurowanej

66

sieci lokalnej uruchamia się strona internetowa sterownika odczytująca

temperaturę czujnika w stopniach Fahrenheita oraz czas odczytujący z

układu RTC. Na rysunku 5.7 przedstawiłem widok uruchomionej strony .

Rys.5.7. Widok strony generowanej przez sterownik (aplikacja TINIWebServer)

Uruchomienie aplikacji TINIWebSwitch wymaga zainstalowania do

przeglądarki internetowej wirtualnej maszyny java JVM, ponieważ

aplikacja ta uruchamia Aplett Java na przeglądarce. Widok strony

przedstawiający aplikacje pozwalającą na włączanie i wyłączanie diody

LED jest przedstawiony na rysunku 5.8.

67

Rys.5.8. Widok strony generowanej przez sterownik (aplikacja

TINIWebSwitch)

6. Przeprowadzenie badań wyko-

nanego sterownika w warunkach
przyłączenia go do wybranych sieci
TCP/IP.

W szóstym punkcie pracy została dokonana analiza przepływu

danych sterownika podłączonego do sieci lokalnej przy pomocy programu

IRIS w wersji 4.06.

68

6.1. Analiza przepływu danych sterownika

podłączonego do sieci LAN przy wyko-

rzystaniu programu IRIS.

Sterownik został podłączony do innego komputera w sieci LAN, gdzie na

tym komputerze odbywało się włączanie i wyłączanie diody LED podłączonej do

sterownika. Uruchomiony program IRIS na komputerze pozwalał na odczyt

ruchu przepływu danych w sieci między komputerem a sterownikiem. Na

rysunku 6.1. przedstawiony jest widok programu IRIS z pokazanym ruchem

przepływu danych między komputerem a sterownikiem. Dla lepszego widoku

został wycięty i powiększony obszar z danymi programu, który jest

przedstawiony na rysunku 6.2.

69

Rys.6.1. Widok programu IRIS z wyświetlonym przepływem danych w sieci między

komputerem a sterownikiem.

Rys.6.2. Widok programu IRIS z wyświetlonym przepływem danych w sieci między

komputerem a sterownikiem (powiększenie).

Konfiguracja sieciowa komputera i sterownika jest przedstawiona na

rysunku 6.3. Cztery pierwsze linie danych w programie IRIS przedstawiają

proces ruchu danych w sieci przy włączeniu diody LED zainicjowany przez

przeglądarkę internetową komputera. Cztery ostatnie linie pokazują proces ruchu

70

danych w sieci przy wyłączeniu diody LED zainicjowany przez przeglądarkę

komputera.

Rys. 6.3. Widok konfiguracji sieciowej komputera i sterownika w sieci LAN

Podsumowanie

Zaprojektowany sterownik do sterowania i kontroli urządzeń

poprzez sieć TCP/IP całkowicie spełnił swoje zadania. Bardzo duży obszar

możliwości współpracy z urządzeniami zewnętrznymi sprawia, że

sterownik jest doskonałym systemem do kontroli i sterowania urządzeń

rozproszonych praktycznie na całym świecie. W dobie wielkiej i

obciążonej sieci internetowej systemy te być może nie najlepiej się

sprawdzą przy kontrolowaniu czy też sterowaniu urządzeń wymagających

71

dużych przepustowości danych, jednak z pewnością systemy te poradzą z

urządzeniami wykorzystywanymi przez człowieka do powszechnego

użytku, które nie wymagają aż tak znacznej ilości danych do ich działania.

Literatura:

1.

www.maxim-ic.com

2.

www.I-buttom.com

3.

www.maxim-

ic.com/products/microcontrollers/pdf/DS80c390_user_guide.pdf

4.

www.pomiary.pl

5.

www.netica.com.pl

6.

www.test-therm.com.pl

7.

www.computerworld.pl

8.

http://pdfserv.maxim-ic.com/en/ds/DS80C400.pdf

72

9.

ftp://ftp.dalsemi.com/pub/tini

10.

ftp://ftp.dalsemi.com/pub

11.

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3748

12.

www.amd.com

13.

www.amic.com

14.

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2251

15.

www.realtek.com.tw

16.

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2750

17.

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1932

18.

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2355

19.

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1544

20.

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2815

21.

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2923

22.

www.sun.com