Infinity: system automatyki domowej - Oprogramowanie serwera www cz.3

Pomimo „strasznie” brzmiącej zapowiedzi (sieci na wyższym poziomie), w tym odcinku nie będzie rozgraniczenia na Czytelników bardziej lub mniej zaawansowanych. Poza kilkoma odniesieniami do „niższego” protokołu TCP, głównym celem w tym odcinku jest przedstawienie działania programu serwera jako wytwórcy informacji w języku HTML. Język HTML jest kojarzony ze stronami www. Jednak można spojrzeć na ten język z innej perspektywy i rozpatrywać, jakie znaczenie mają odpowiednie zapisy w tym języku. I właśnie to jest głównym tematem tego artykułu.

Ale na początek jeszcze jedna sprawa dotycząca serwera www: wcześniej opisane było przeznaczenie niektórych elementów przyłączonych do mikrokontrolera, w tym pamięci EEPROM i przełącznika DIPSWITCH. Pozostało przedstawić funkcję lampek LED.

Stan danej diody LED sygnalizuje określone zdarzenie zachodzące w mikrokontrolerze.

• dioda statusu, mrugająca (zaświecana i gaszona) symbolizująca „rytm serca” – jak mruga, to znaczy, że mikrokontroler działa (nie zawiesił się),
• dioda sygnalizująca nadawanie w kanale UART0 mikrokontrolera, zaświecana na ułamek sekundy po każdym wysłanym znaku z UART,
• dioda sygnalizująca odbieranie w kanale UART0 mikrokontrolera, zaświecana na ułamek sekundy po każdym odebranym znaku przez UART,
• dioda sygnalizująca nadawanie w kanale UART1 mikrokontrolera, zaświecana na ułamek sekundy po każdym wysłanym znaku z UART,
• dioda sygnalizująca odbieranie w kanale UART1 mikrokontrolera, zaświecana na ułamek sekundy po każdym odebranym znaku przez UART,
• dioda sygnalizująca połączenie TCP na port o numerze 80, zaświecana w chwili nawiązania połączenia, gaszona z opóźnieniem po zamknięciu połączenia,
• dioda błędu danych odebranych z procesora komunikacyjnego, zaświecana na ułamek sekundy w przypadku wykrycia błędu formatu polecenia.

Diody te pełnią ważne funkcje diagnostyczne, przykładowo w normalnej pracy (pomijając lampkę „rytmu serca”) serwer jest zasilany informacjami pochodzącymi od procesora komunikacyjnego. Oznacza to, że powinna zaświecać się dioda LED sygnalizująca odbieranie danych przez UART1. Jeżeli dioda nie jest włączana, to problemów należy poszukiwać w połączeniu z modułem komunikacyjnym.

A teraz główny temat: aby uzyskać zawartość strony internetowej, to klient (przeglądarka) musi nawiązać połączenie TCP do gniazda o numerze 80. Dlaczego wybrany jest numer 80? Po prostu dla tej usługi (serwowanie stron www) przydzielono taki stały numer. Inne usługi mają przyporządkowane inne numery. Przykładowo, chcąc odebrać pocztę elektroniczną, należy nawiązać połączenie do gniazda o numerze 110.

Takie rozwiązanie występuje powszechnie w życiu codziennym. Chcąc wezwać pogotowie ratunkowe wiemy, że należy zadzwonić pod numer telefoniczny 999, policję wzywa się, dzwoniąc pod numer 997. Określone służby mają przyporządkowany sobie numer (taki „dobrze znany wszystkim numer”). Podobnie jest w sieciach komputerowych, ściśle określone usługi mają przyporządkowane sobie odpowiednie numery.

By nawiązać połączenie do serwera do gniazda o numerze 80, rzeczą oczywistą jest to, że serwer musi się spodziewać takiej operacji. Oprogramowanie w urządzeniu musi je utworzyć. Posługując się analogią telefoniczną, by nawiązać połączenie telefoniczne, druga strona musi „istnieć”, centrala telefoniczna musi „widzieć” docelowy numer telefonu, przy którym siedzi sobie ktoś gotowy w każdej chwili odebrać przychodzące połączenie.

Na identycznej zasadzie w programie zostaje powołane do „istnienia” gniazdo (socket) gotowe na przyjęcie przychodzącego połączenia. Pokazuje to fragment programu na listingu 1. Uwaga! Wszystkie listingi wymienione w artykule dostępne są w Elportalu wśród materiałów dodatkowych do tego numeru EdW.

Wywołanie funkcji CreateTCPSocket utworzy gniazdo TCP, nadając mu jakiś unikalny (w obrębie serwera) numer, wskaźnik do utworzonej struktury, zwrócony jako wynik wywołanej funkcji, identyfikuje je. Wynik wywołania jest zachowany w zmiennej programu (WebSeverInstance.TCPSocket). Ponieważ utworzone gniazdo musi mieć ściśle określony numer (a nie jakiś), wywołanie kolejnej funkcji (BindTCPSocket) modyfikuje numer w utworzonej strukturze, nadając nową wartość (stała TCPPortNumer).

Pozostało jedynie nadać mu status gniazda nasłuchowego (oczekującego na połączenia) w wyniku wykonania funkcji TCPListen, która jednocześnie przyporządkowuje mu dodatkowe funkcje, które będą wywołane w ściśle określonych sytuacjach. Należą do nich próba nawiązania połączenia (przy każdej próbie będzie wywołana funkcja TCPConnectOperation), zestawienie połączenia (po zakończeniu nawiązywania połączenia zostanie wywołana funkcja TCPEstablishOperation), odebranie danych (przy każdym odebraniu danych kierowanych do gniazda o numerze 80 zostanie wywołana funkcja TCPRecvOperation) oraz zamknięcia połączenia (zostanie wywołana funkcja TCPCloseOperation).

Od tej chwili serwer jest gotowy do działania (z punktu widzenia sieciowego, gdyż aby serwował poprawnie strony www, musi być zasilany ważnymi danymi via UART1 – złącze P401 na schemacie serwera). Docelowa funkcjonalność programu jest zawarta w krótkiej niekończącej się pętli for, w której kolejno wywoływane są trzy funkcje: SysTimer-Pool (funkcja do obsługi kolejek czasowych, wszelkich akcji oprogramowania, które mają być wykonane w określonych momentach), WebSeverInstance.IPLayer->IPLayerPoolService (jako wskaźnik do funkcji obsługi sieci: sprawdzenia, czy została odebrana jakakolwiek ramka ethernetowa oraz realizuje działania wynikające z odebranej ramki), SerialPool (funkcja do obsługi transmisji szeregowej, poprzez którą są dostarczane do serwera dane pomiarowe).

Uruchamiając przeglądarkę internetową, zamiast nazwy strony (przykładowo elportal.pl) należy wpisać adres IP serwera (rysunek 1). Spowoduje to nawiązanie przez przeglądarkę połączenia TCP do podanego adresu IP na port o numerze 80.

Rys.1 Adres IP serwera zamiast adresu strony

Po wpisaniu docelowego adresu IP w okienku przeglądarki, tworzy ona gniazdo TCP (system operacyjny nada temu gniazdu jakiś numer) i wysyła pod wskazany adres (adres IP=192.168.0.44 i port=80) „zaczepny” pakiet z prośbą o nawiązanie połączenie. Serwer w wyniku odebrania od klienta (przeglądarki internetowej) sygnału chęci nawiązania połączenia TCP, gdzieś w oprogramowaniu serwera www w obsłudze tego protokołu (dokładnie w funkcji TCPReceivedStateMachine) nastąpi wywołanie odpowiedniej akcji (dowiązanej do obsługi sieci w wyniku użycia funkcji TCPListen), której zadaniem jest zwrócenie statusu, który należy interpretować jako wyrażenie zgody na nawiązywane połączenia.

Podobnie jak w życiu codziennym, mając telefon komórkowy, widzimy na wyświetlaczu, kto do nas próbuje się dodzwonić. Mamy dwa wyjścia: albo odebrać przychodzące połączenie, albo nie. Dokładnie tak samo jest w oprogramowaniu. Odebranie sygnału chęci nawiązania połączenia TCP spowoduje wywołanie funkcji TCPConnectOperation (zgłoszonej w TCPListen), której zapis pokazuje listing 2.

W tym przypadku jest udzielana bezwarunkowa zgoda. Do funkcji w parametrach wniesione są, oprócz struktury identyfikującej połączenie (TCPSocket), adres IP stacji nawiązującej połączenie (RemoteAddress) i numer gniazda TCP klienta, czyli przeglądarki internetowej (RemotePort); to taki odpowiednik danych wyświetlanych przez telefon komórkowy pokazujący, kto do nas dzwoni.

Jest wiele zastosowań, w których taka funkcjonalność może okazać się przydatna. Przykładowo wyobraźmy sobie, że nasz serwer www może być konfigurowany za pośrednictwem sieci (jako ekwiwalent programu SERWCFG opisanego w poprzednim miesiącu). Jest taka usługa w sieci, która do tego doskonale się nadaje (telnet, jako połączenie na port o numerze 24). Używając w Windows standardowego programu (również o nazwie telnet), uzyskuje się zdalny terminal z możliwością przesyłania w obie strony poleceń tekstowych.

Skoro program SERWCFG wymaga danych tekstowych, co stoi na przeszkodzie, by takie dane przesłać za pośrednictwem sieci? Po zamknięciu połączenia takie dane mogą zostać zapisane w pamięci EEPROM i serwer może zrobić restart oprogramowania, po którym może mieć inne parametry sieciowe. W takiej sytuacji jest całkowicie uzasadnione, by modyfikację konfiguracji przeprowadzał jeden operator.

Gdyby zaistniało jednoczesne połączenie telnet kilku operatorów, to mogliby sobie nawzajem przeszkadzać w pracy. Taką możliwość daje powyższa funkcjonalność. Pierwsza próba nawiązania połączenia jest akceptowana, co prowadzi do zestawienia stabilnego połączenia. Zanim połączenie nie zostanie zamknięte (wystarczy w programie utworzyć zmienną mającą znaczenie: czy jest otwarte połączenie typu tak/nie), każda następna próba połączenia może zwrócić w funkcji TCPConnectOperation wartość 0 (odpowiadająca znaczeniu nie), co prowadzi do tego, że do połączenia nie dojdzie.

Oczywiście nasz serwer takiej funkcjonalności nie ma. Dlaczego? Jeżeli, drogi Czytelniku, pomyślałeś w tej chwili, że takiej funkcjonalności nie ma, ponieważ program serwera www nie utworzył gniazda w trybie nasłuchu na porcie o numerze 24, to muszę Ci pogratulować, zaczynasz rozumieć ideę sieci.

Wracając do działania programu, wyrażenie zgody na połączenie rozpoczyna wymianę kilku pakietów TCP pomiędzy serwerem a klientem. Te informacje mają istotne znaczenie w procesie potwierdzania otrzymania danych (brak potwierdzenia doprowadzi do retransmisji niepotwierdzonych danych). Dopiero po zakończeniu wyżej wymienionych uzgodnień pomiędzy stronami połączenie uzyskuje status połączenia nawiązanego.

W tej fazie, również z głębin obsługi TCP, nastąpi wywołanie innej odpowiedniej funkcji sygnalizującej stan uzyskania stabilnego połączenia. Funkcja ta (TCPEstablishOperation, zgłoszona w TCPListen, listing 3) dostaje w parametrach wskaźnik do struktury opisującej połączenie. W serwerze www jej implementacja sprowadza się do włączenia lampki LED sygnalizującej połączenie do serwera.

Od tej chwili w oprogramowaniu powstaje skojarzenie typu nasz adres IP=192.168.0.44 i numer portu 80 z jakimś komputerem o określonym adresie IP i numerze portu. Lampka LED zostanie zgaszona w wyniku zamknięcia połączenia, czyli wywołania kolejnej funkcji odpowiedniej do zaistniałej sytuacji, która jest pokazana na listingu 4. Odebranie pakietu TCP zawierającego przesyłane dane na porcie 80 aktywuje funkcję TCPRecvOperation pokazaną na listingu 5 (nie każdy pakiet TCP niesie w sobie dane „użytkowe”, bowiem jest też przesyłanych wiele pakietów TCP o znaczeniu synchronizującym).

Te dane, nawiązując do historii Jasia Wędrowniczka, to jest zawartość kartki wyjętej z koperty, którą uzyskujemy w wyniku dekapsulacji. Jej zadaniem (TCPRecvOperation) jest rozpoznanie prośby wygenerowanej przez klienta i wysłanie odpowiedniej odpowiedzi (zawartości właściwej strony).

Pierwszy, niejako „zaczepny” pakiet wygenerowany przykładowo przez przeglądarkę CHROME pokazuje listing 6. Prośba o zawartość strony, zawsze w postaci tekstowej, w pierwszym wierszu zawiera istotną informację: GET /HTTP/1.1, co należy interpretować jako „poproszę o stronę startową”. Po ciągu znaków HTTP/ znajduje się numer wersji protokołu HTTP, który jest akceptowany przez przeglądarkę.

Kolejne wiersze, tak zwane metadane, zawierają kolejne szczegóły określające, co jest w stanie zaakceptować przeglądarka. Całość jest zakończona pustym wierszem. W moim oprogramowaniu rozpatrywany jest jedynie pierwszy wiesz, pozostałe wiersze są ignorowane. Wyselekcjonowanie pierwszego wiersza następuje w wyniku wywołania funkcji ExtractHTTPCommand (listing 5). W wariancie polecenia GET (listing 6), należy do przeglądarki wysłać stronę startową, którą pokazuje listing 7.

Zawiera ona w pierwszym wierszu odpowiedź (że strona jest, czyli zapytanie dotyczyło istniejącej strony) oraz po pustym wierszu znajduje się treść strony. Składa się ona z dwóch części: nagłówka i ciała. W części nagłówkowej istotnym elementem jest specyfikacja dotycząca kodowania znaków.

W internecie powszechnie stosuje się kodowanie określane jako UTF-8. Odpowiada ono kodom znaków ISO w zakresie 7-bitowych kodów znaków. Znaki dodatkowe (specjalne, polskie znaki diakrytyczne itp.) są kodowane jako ciąg dwóch bajtów. W przypadku polskich znaków ich kody wymienione są w tabeli 1 (zapisane są jako liczby szesnastkowe). Strona startowa (listing 7) jest stała, i na tyle niewielka, że mieści się w jednym pakiecie odpowiedzi (rysunek 2).

Rys.2 Strona startowa mieści się w jednym pakiecie odpowiedzi

Po przesłaniu zawartości strony program serwera www zamyka połączenie, dając tym samym sygnał dla przeglądarki, że przesłana strona jest kompletna (w ogólnym przypadku może się tak zdarzyć, że przesłanie jej treści wymaga wielu pakietów TCP, toteż zamknięcie połączenia następuje po przesłaniu kompletu danych).

Przeglądarka może otworzyć drugie połączenie (przynajmniej tak robi CHROME) z prośbą o przesłanie pliku favicon.ico o zapisie: GET /favicon.ico HTTP/1.1 (rysunek 3).

Rys.3 Drugie połączenie z prośbą o przesłanie pliku favicon.ico

Jest to polecenie przesłania zawartości ikonki symbolizującej otwieraną stronę, która w tym przypadku nie ma żadnego istotnego znaczenia, jednak należy wygenerować właściwą odpowiedź (jak na listingu 8). Kod błędu to 404 i oznacza, że oczekiwany plik nie istnieje (po tej odpowiedzi musi wystąpić pusty wiersz). W ogólnym przypadku każdy detal strony internetowej jest oddzielnym połączeniem TCP, które jest identyfikowane (oprócz adresu IP) także numerami portów.

Z jednej strony (serwera) port ma ustalony numer: 80, z drugiej strony (klienta) port ma jakiś numer (wynikający z algorytmu przydziału numerów portów przez system operacyjny klienta). Ta para (a właściwie czwórka informacji, gdyż do tego należy dodać adresy IP po obu stronach) identyfikuje połączenie, czyli dotyczy przesłania ściśle określonej informacji (wyspecyfikowanej przez GET), toteż odpowiedź o braku danych jest poprawnie rozpoznana przez przeglądarkę. Gdyby w treści strony znajdowały się jakieś pliki graficzne, to przesłanie każdego oznacza otwarcie kolejnego połączenia TCP.

Wracając do treści strony, zawiera ona wszelkie informacje określające, co (tekst), gdzie (wypośrodkowane, justowane do lewej strony) i jak (rodzaj, wielkość i kolor czcionki, kolor tła) ma być wyświetlone. Dodatkowo znajdują się tam dwa odnośniki do innych stron.

<a href> do </a>

Jeżeli użytkownik kliknie na odnośnik, to przeglądarka otworzy kolejne połączenie, w którym poprosi serwer o zawartość odpowiedniej strony. Przykładowo gdy klikamy na wyraz „KLIK” w wierszu „Pomiary”, przeglądarka wystosuje następującą prośbę o zawartość strony: GET /means HTTP/1.1, gdzie „means” jest identyfikatorem zawartym w opisie

<a href> <!-- (listing 7) -->

.

Na powyższą prośbę serwer www wyśle następujące dane (listing 10). Zawierają one informacje pomiarowe, które są wstawiane przez program do zawartości strony pochodzące od urządzeń pomiarowych udostępniających je poprzez asynchroniczny port szeregowy UART1 (obecnie, gdy nie są one przyłączone, są one reprezentowane przez znaki zapytania). Dynamiczne tworzenie zawartości strony pokazuje listing 9. Wyświetlaną stronę przedstawia rysunek 4.

Rys.4 Strona z informacjami pomiarowymi

Oprócz wyświetlania wartości pomiarowych, na stronie jest pokazany stan wskaźnika dwustanowego (typu jest/nie ma). Reprezentuje on czujnik wykrywający tlenek węgla (CO), a informacja jest niesiona poprzez kolor (niebieski oznacza wyłączony, czerwony oznacza włączony). Efekt lampki kontrolnej jest uzyskany następująco: utworzona jest tabela z jednym wierszem i jedną kolumną z szerokim obramowaniem, dla której modyfikowany jest kolor tła i drukowanych kilka znaków odstępu.

W przypadku strony zawierającej dane pomiarowe istotny jest element w obrębie części nagłówkowej (metadanych), który nie wystąpił w zawartości strony głównej, o następującej postaci:

<meta http-equiv=”refresh” content=”5”>

Zapis ten oznacza, że przeglądarka sama, autonomicznie, zobligowana jest do odświeżania strony co 5 sekund. Z punktu widzenia użytkownika oznacza to, że dane pomiarowe na ekranie same będą się odświeżać z zadanym interwałem czasowym.

Na identycznej zasadzie w sytuacji, gdy użytkownik kliknie na wyraz „KLIK” na stronie głównej w wierszu „Sterowanie” przeglądarka wystosuje inną prośbę o zawartość kolejnej strony: GET /control HTTP/1.1. Analogicznie do wcześniej opisanej strony dotyczącej pomiarów, zostanie wysłana właściwa zawartość strony (listing 11). Wynik pokazuje rysunek 5.

Rys.5 Strona ze sterowaniem

Podobnie jak w przypadku strony zawierającej dane pomiarowe, tutaj również znajduje się specyfikacja, by przeglądarka odświeżała ją co 5 sekund. W identyczny sposób są zrealizowane wskaźniki sygnalizujące stan włączenia/wyłączenia wentylatora oraz oświetlenia. Zamiast wartości liczbowych udostępnione są po dwa odnośniki („WŁĄCZ” i „WYŁĄCZ”) prowadzące do kolejnych stron (identyfikowane przez nazwę zawartą w odpowiedniej specyfikacji

<a href=...>

Kliknięcie na odpowiedni odnośnik generuje kolejne żądanie przeglądarki o zawartość nowej strony. Do serwera trafi jeden z wariantów:

• GET /fon HTTP/1.1

• GET /fof HTTP/1.1

• GET /lon HTTP/1.1

• GET /lof HTTP/1.1

W każdym z tych przypadków program serwera postąpi inaczej, niż zostało to opisane wyżej. W wymienionych wariantach zostaje udostępniona identyczna zawartość strony (listing 12), która oznacza bezzwłoczne przełączenie się na wskazaną inną stronę (url=control), czyli tak jakby zostało kliknięte na stronie głównej przejście do strony sterowania (powód odmiennej realizacji zostanie wyjaśniony w dalszej części), co implikuje kolejne żądanie przeglądarki o zawartość strony identyfikowanej symbolem „control”.

W ogólnym przypadku użytkownik przy komputerze, wpisując w przeglądarce adres IP, może po znaku ukośnika „/” wpisać „cokolwiek”. To oczywiście implikuje, że owe „cokolwiek” trafi do serwera jako specyfikacja w poleceniu GET, a to w konsekwencji doprowadzi do próby otwarcia nieistniejącej strony. Można postąpić identycznie do przypadku żądania przesłania favicon.ico, odpowiedzieć, że takiej strony nie ma. Jednak w tym przypadku program serwera odsyła inne dane, które informują, że pobierana strona nie istnieje (treść odpowiedzi pokazuje listing 13), co z punktu widzenia przeglądarki oznacza otrzymanie właściwej strony.

Wracając do funkcji przetwarzającej prośby o zawartości strony (funkcja TCPRecvOperation, listing 5), w oparciu o odebrane dane ma ona za zadanie rozpoznać polecenie wygenerowane przez przeglądarkę i odpowiednio do niego wykonać naznaczone czynności. Treść pierwszego wiersza jest w dalszej części porównywana ze wzorcami (listing 14) i w przypadku zgodności wykonana jest specyficzna akcja odpowiadająca odpowiedniemu wzorcowi. Porównanie ze wzorcem jest realizowane przez funkcję ComparePageName. W przypadku gdy jest to:

● GET bez symbolu strony lub GET z parametrem index, do przeglądarki wysyłana jest zawartość strony startowej,

● GET z parametrem favicon.ico, do przeglądarki wysyłana jest informacja, że takiej strony nie ma,

● GET z parametrem means (strona prezentująca wartości pomiarowe), do przeglądarki wysłana jest dynamicznie uzupełniona aktualnymi wartościami pomiarowymi zawartość strony z pomiarami,

● GET z parametrem control (strona umożliwiająca sterowanie urządzeniami wykonawczymi), do przeglądarki wysyłana jest dynamicznie uzupełniona aktualnymi statusami (włączony/wyłączony) zawartość strony z kolejnymi odnośnikami typu włącz/wyłącz,

● GET z parametrem fon (zostało kliknięte „WŁĄCZ” w wierszu „Wentylator”), w kanał szeregowy (UART1) wysłane jest odpowiednie polecenie (wywołanie funkcji Device01On), które finalnie ma trafić do właściwego sterownika oraz do przeglądarki zawartość strony nakazującej automatyczne przejście do strony identyfikowanej przez symbol control,

● GET z parametrem fof (zostało kliknięte „WYŁĄCZ” w wierszu „Wentylator”), podobnie jak w wariancie fon, z tą różnicą, że wywołana jest inna funkcja sterująca, wysyłająca inne polecenie w kanał szeregowy UART1 (Device01Off),

● GET z parametrem lon (zostało kliknięte „WŁĄCZ” w wierszu „Oświetlenie”), w kanał szeregowy (UART1) wysłane jest polecenie wykonania funkcji oraz przeglądarka na się przeładować na stronę identyfikowaną symbolem control,

● GET z parametrem lof (zostało kliknięte „WYŁĄCZ” w wierszu „Oświetlenie”), w kanał szeregowy (UART1) wysłane jest polecenie adekwatne do realizowanej funkcji a przeglądarka dostaje polecenie przejścia do strony o symbolu control.

W każdym innym przypadku, jako wariancie nierozpoznanym, wysyłana jest zawartość strony informującej użytkownika, że takiej strony nie ma (listing 13). Po wysłaniu odpowiednich danych inicjowane jest opóźnione zamknięcie połączenia. Wywołanie funkcji AttachTimer doprowadzi do odłożonego w czasie wywołania funkcji (DelayedSocketClose), której zadaniem jest finalne zamknięcie połączenia.

Jak łatwo zauważyć, pobranie strony identyfikowanej symbolem fon generuje wysłanie poprzez kanał szeregowy (UART1) właściwego polecenia do podłączonego sterownika. Przeglądarka od tej chwili będzie uważać, że bieżącą stroną jest strona identyfikowana symbolem fon. W sytuacji, gdy cyklicznie będzie ją odświeżać, żądając ponownego przysłania zawartości tej strony, za każdym razem serwer będzie wysyłał odpowiednie polecenie do podłączonego sterownika.

Zrozumiałe jest oczekiwanie, że jednorazowe kliknięcie na „WŁĄCZ” ma wygenerować jedno polecenie via UART1 do właściwego sterownika, toteż po pierwszym pobraniu zawartości strony, połączonym z wysłaniem specjalizowanego polecenia, nakazuje się przeglądarce, by przełączyła się na stronę o innym symbolu. Każde kolejne odświeżenie strony nie będzie już związane z identyfikatorem fon. Pomimo że identyfikatory stron są różne, do przeglądarki wysyłana jest identyczna zawartość strony. Powyższy tryb postępowania serwera dotyczy każdego innego przypadku związanego z operacją włącz/wyłącz.

Wspomniany kanał szeregowy (UART1 mikrokontrolera LPC2378) jest używany do „zasilania serwera” w dane pomiarowe i statusy. W głównej funkcji programu (main) wywoływana jest funkcja SerialPool (pokazana na listingu 15). Jej zadaniem jest skompletowanie polecenia pochodzącego od procesora komunikacyjnego (o którym była mowa w części wprowadzającej) zawierającego dane pomiarowe.

Kanał UART1 w przerwaniach odbiera pojedyncze znaki i gromadzi je w kolejce FIFO związanej z tym kanałem. Jeżeli są jakieś dane do odczytu (wywołanie funkcji UART-1DataPresent), są one pobrane z kolejki (funkcja UART1GetData) i kompletowane w odpowiednim buforze (zmienna CommandBuffer). Odebranie znaku kontrolnego CR (o kodzie 0D hex) oznacza, że polecenie zostało skompletowane.

W wyniku wywołania funkcji ExecuteSerialCommand następuje analiza znaczenia odebranego polecenia i zapisanie w zmiennych programu serwera danych wynikających z otrzymanych poprzez UART1 informacji. Mogą to być dane pomiarowe lub informacje o statusie (włączone/wyłączone).

Serwer www przekazuje polecenia dla modułów wykonawczych realizujących określone czynności sterujące oraz uzyskuje dane pomiarowe i dane statusowe, wykorzystując jako element pośredniczący pewien moduł, określany jako procesor komunikacyjny (więcej informacji będzie w kolejnej części). Przepływ informacji pomiędzy poszczególnymi modułami jest realizowany w oparciu o specjalnie utworzony protokół komunikacyjny (będzie on szerzej omówiony w kolejnych częściach).

Obecnie zostaną przedstawione jego główne cechy. Jest to protokół tekstowy zawierający trzy istotne elementy, które w skrócie można określić jako: do kogo, od kogo i co. Poszczególne elementy są rozdzielone znakiem dwukropka „:”. Informacja określana jako „od kogo” jest tekstowym identyfikatorem urządzenia (wysyłającego), który jest unikalny w całej gałęzi. Podobnie pole „do kogo” jest unikalnym tekstowym identyfikatorem (adresat). Analogicznie część „co” jest również informacją tekstową zawierającą czasami dodatkowe parametry, które są rozdzielone znakiem kropki.

Serwer www przesyła polecenia do podłączonego procesora komunikacyjnego, używając kanału szeregowego UART1. Informacje zwrotne, dotyczące wartości zmierzonych oraz statusów, pochodzą od procesora komunikacyjnego. Używając analogii sieciowej, procesor komunikacyjny odgrywa rolę bramy domyślnej i realizuje funkcjonalność routera (zajmuje się dalszym przesłaniem transmitowanych danych).

A więc z punktu widzenia serwera www nie jest istotna znajomość topologii „reszty świata” istniejącego za procesorem komunikacyjnym. Ważnym elementem jest jedynie postać wysyłanych i odbieranych danych. W sytuacji, gdzie w obszarze zainteresowania serwera www jest grupa modułów przewidzianych do pomiaru temperatury, czujnik wykrywający tlenek węgla (CO) oraz grupa modułów przeznaczona do włączania/ wyłączania wentylatora i oświetlenia, oprogramowanie serwera www musi się dostosować do tych urządzeń.

Więcej na temat poleceń przesyłanych pomiędzy serwerem www a wspomnianym procesorem komunikacyjnym będzie w kolejnych odcinkach, a teraz jedynie podam przykład polecenia generowanego przez serwer w wyniku kliknięcia na wybrany odnośnik na serwowanej stronie. Aby włączyć wentylator, serwer www musi przesłać do procesora komunikacyjnego polecenie o następującej treści: PWC001:WEBS01:CHON, gdzie PWC001 jest identyfikatorem docelowego sterownika, WEBS01 jest identyfikatorem serwera www, CHON jest poleceniem nakazującym włączyć.

Wyłączenie wentylatora następuje w wyniku wysłania polecenia o następującej treści: PWC001:WEBS01:CHOFF, gdzie CHOFF jest poleceniem nakazującym wyłączenie. W przypadku danych pomiarowych przykładowe polecenie może mieć następującą postać: WEBS01:TMPS001:RPV. T01.45,7. Takie polecenie oznacza, że sterownik identyfikowany symbolem TMPS001 (pomiar temperatury wody w piecu) przesyła do serwera (WEBS01) dane pomiarowe (RPV) dla wielkości fizycznej (identyfikowanej nazwą T01) o podanej wartości (45,7).

Kolejny odcinek będzie poświęcony omówieniu magistrali komunikacyjnej RS485, czyli poznamy protokół komunikacyjny zaprojektowany do przesyłania danych oraz zarządzania komunikacją w obrębie wspomnianej magistrali.