Uploaded by xqzme

STM32. Ethernet. I i s Marcin Peczarski. w p v z y k Z a à a c k

advertisement
STM32
I i
s i@
o
Ethernet
w
p
Marcin Peczarski
v z y k Z
a
à
a
c k
Spis treści
3
Przedmowa....................................................................................................................7
1.
2.
Podstawy......................................................................................................................11
1.1.
M ikrokontroler S T M 3 2 F 1 0 7 ..............................................................................................12
1.2.
Struktura p rzy k ład ó w ........................................................................................................... 13
1.3.
Przykład I a - m iganie diodam i św ie c ą c y m i..................................................................15
1.3.1. Plik ex_ied.c.......................................................................................................................16
1.3.2. Pliki util_delay.h i util_delay.c.........................................................................................17
1.3.3. Pliki board_led.it i board_led.c........................................................................................17
1.3.4. Pliki stni32fi0x_gpio.lt i slin32fl0x_rcc.lt...................................................................... 18
1.3.5. Pliki stni32fl0x.lt, system_stm32fi0x.h i core_an3.h....................................................19
1.3.6. Plik Iibstiii32fi0x.a............................................................................................................ 19
1.3.7. Plik stm32f KLconf.h........................................................................................................ 20
1.3.8. Pliki board_def.lt i board_defs.lt..................................................................................... 21
1.3.9. Plik stdiiit.h........................................................................................................................ 22
1.3.10. Plik startup_stm32_cld.c.................................................................................................. 22
1.4.
K om pilow anie p rz y k ła d ó w ................................................................................................ 23
1.5.
W ejścia i w yjścia b in arn e....................................................................................................26
1.6.
W yśw ietlacz c ie k ło k ry staliczn y ........................................................................................30
1.7.
Przykład lb - test w yśw ietlacza ciek ło k ry staliczn eg o ...............................................33
1.7.1. Pliki board_lcd.lt i board_lcd_ksO108.c.........................................................................34
1.7.2. Pliki fotil5x8.lt \font5x8.c.................................................................................................37
1.7.3. Pliki ntil_lcd.lt i a liljc d .c ................................................................................................37
1.7.4. Plik ex_lcd.c...................................................................................................................... 38
1.8.
O rganizacja pam ięci p ro g ra m u ..........................................................................................38
1.8.1. Sekcje..................................................................................................................................38
1.8.2. Procedura startowa............................................................................................................42
1.8.3. Skrypt konsolidatora.........................................................................................................45
1.9.
Styl pisania i kom entow ania tekstu źró d ło w eg o ..........................................................49
Intersieci......................................................................................................................51
2.1.
M odel w a rstw o w y ................................................................................................................52
2.2.
E th ern et....................................................................................................................................54
2.3.
IP - protokół in tersieci........................................................................................................ 60
2.4.
A R P - tłum aczenie adresów sieciow ych na adresy sp rzęto w e................................ 66
2.5.
Sieć testow a............................................................................................................................ 67
2.6.
Przykład 2 - m onitor s ie c i..................................................................................................69
2.6.1. Pliki board_init.lt i b o a rd jn it.c ......................................................................................70
2.6.2. Pliki util_led.h i util_led.c............................................................................................... 79
2.6.3. Plik ex_eth.c...................................................................................................................... 80
Spis treści
4.2.3.
4.2.4.
4.2.5.
4.2.6.
4.2.7.
3. Stos TCP/IP................................................................................................................83
3.1.
Przegląd im p lem en tacji....................................................................................................... 84
3.2. B iblioteka Iw IP ...................................................................................................................... 86
3.2.1. Dopasowanie do architektury mikrokontrolera - plik conex-in3.li..............................86
3.2.2.
3.2.3.
3.2.4.
3.2.5.
Parametry konfiguracyjne - plik Iwipopts.h.................................................................. 93
Kompilowanie - plik liblwipd.ci..................................................................................... I^0
Kody błędów.................................................................................................................... I01
Struktura p b u f ................................................................................................................. 101
3.2.6.
Struktura n e t i f .........................................................................................................................104
3.3.
4.4.
5.
3.7.
Testy stero w n ik ó w .............................................................................................................. 136
3.8.
1CMP - kom unikaty kontrolne i kom unikaty o b łę d a c h .......................................... 137
3.8.1. Sprawdzanie osiągalności odbiorcy...............................................................................138
3.8.2. Powiadamianie o nieosiągalności odbiorcy..................................................................139
3.8.3. Kontrola przepływu.........................................................................................................139
3.8.4. Przekroczenie czasu.........................................................................................................140
3.8.5. Problem z parametrem..................................................................................................... 140
3.9.
D H C P - konfigurow anie ustaw ień sieciow ych w ę z ła .............................................. 141
4. Programowanie w modelu klient-serwer
4.1.
143
N um er p o rtu .......................................................................................................................... 145
4.2. T C P .......................................................................................................................................... 146
4.2.1. Podstawowe własności.................................................................................................... 146
4.2.2. Nagłówek.......................................................................................................................... 147
U wagi k o ń co w e ..................................................................................................................166
Serwer TCP.............................................................................................................. 169
5.1. Protokół w arstw y ap lik acji............................................................................................... 170
5.1.1. Projekt protokołu............................................................................................................. 170
5.1.2. Projekt implementacji protokołu.................................................................................. 172
5.2. Przykład 5a - pierw sza w ersja serw era T C P ............................................................... 178
5.2.1. Pliki tcp_server.h i tcp_server.c..................................................................................... 178
5.2.2. Plik ex_tcpd.c...................................................................................................................185
5.2.3. Testowanie przykładu..................................................................................................... 186
3.5.
Przykład 3b - sterow nik E thernetu bez k opiow ania................................................. 127
3.5.1. Plik util_eth_nc.c - inicjowanie interfejsu sieciowego............................................... 127
3.5.2. Plik util_eth_nc.c - wysyłanie ramek ethernetowych................................................130
3.5.3. Plik util_eth_nc.c - odbieranie ramek ethernetowych............................................... 130
3.6.
Przykład 3c - eksperym entalny sterow nik E thernetu bez k opiow ania............... 132
3.6.1. Plik util_eth_zc.c - inicjowanie interfejsu sieciowego................................................133
3.6.2. Plik util_etli_zc.c - wysyłanie ramek ethernetowych.................................................. 134
Otwieranie połączenia.....................................................................................................149
Przesyłanie danych...........................................................................................................152
Zamykanie połączenia.....................................................................................................153
Funkcje biblioteczne........................................................................................................154
Funkcje zw rotne...............................................................................................................160
4.3.
U D P ........................................................................................................................................162
4.3.1. Podstawowe własności....................................................................................................162
4.3.2. Nagłówek..........................................................................................................................162
4.3.3. Inicjowanie klienta i serw era..........................................................................................163
4.3.4. Przesyłanie danych.......................................................................................................... 163
4.3.5. Funkcje biblioteczne........................................................................................................164
4.3.6. Funkcja zw rotna.............................................................................................................. 166
D M A ....................................................................................................................................... 1°6
3.4. P rzykład 3a - p ierw sza w ersja sterow nika E th ern e tu ............................................... 109
3.4.1. Pliki util_liine.li i utU_time.c...........................................................................................109
3.4.2. Pliki util_eth.li i util_eth.c - inicjowanie interfejsu sieciowego.................................. 112
3.4.3. Plik ulil_eth.c - wysyłanie ramek ethernetowych.........................................................117
3.4.4. Plik utU_eth.c - odbieranie ramek ethernetowych........................................................118
3.4.5. Pliki utiijw ip.h i utiljw ip .c - inicjowanie interfejsu sieciowego.............................. 120
3.4.6. Pliki util_lwip.h i utiljw ip .c - budziki..........................................................................122
3.4.7. Pliki board_conf.li i boardjconf.c................................................................................. 124
3.4.8. Pliki util_lcd_ex.h i util_lcd_ex.c.................................................................................. 125
3.4.9. Plik ex_ip.c.......................................................................................................................125
5
5.3. Przykład 5b - serw er T C P z n a d z o rc ą ........................................................................ 188
5.3.1. Pliki util_wdg.h i util_wdg.c.......................................................................................... 189
5.3.2. Plik ex_tcpd_wdg.c......................................................................................................... 190
5.3.3. Testowanie przykładu..................................................................................................... 191
6.
Klient T C P ............................................................................................................... 193
6.1.
Projekt protokołu............................................................................................................... 194
6.2.
Przykład 6a - pierw sza w ersja klienta T C P ...............................................................197
6.2.1.
6.2.2.
6.2.3.
6.2.4.
6.2.5.
6.2.6.
Tryby o obniżonym poborzem ocy............................................................................... 198
Pliki util_rtc.h i ulil_rtc.c...............................................................................................198
Pliki tcp_client.h i tcp_client.c..................................................................................... 202
Plik util_error.h............................................................................................................... 210
Plik ex_tcp_client.c.........................................................................................................211
Testowanie przykładu.................................................................................................... 212
6.3.
Przykład 6b - klient T C P z obsługą rejestrów z a p aso w y ch ..................................214
6.3.1. Pliki util_bkp.h i util_bkp.c...........................................................................................2 14
6.3.2. Plik lcp_client_bkp.c.......................................................................................................216
6.3.3. Plik ex_tcp_clnt_bkp.c....................................................................................................217
6.3.4. Testowanie przykładu.................................................................................................... 217
Spis treści
6
7.
Serwer li DI»..............................................................................................................219
7.1.
Projekt p rotokołu.............................................................................................................. 220
7.2.
Przykład 7 - prosty serw er U D P .................................................................................221
7.2.1.
Pliki udp_server.h i udp_server.c................................................................................ 221
7.2.2.
Plik ex_udpd.c................................................................................................................ 224
7.2.3.
Testowanie przykładu................................................................................................... 225
8.
Klient UDP................................................................................................................227
8.1.
D N S ...................................................................................................................................... 228
8.2.
S N T P ................................................................................................................................... 229
8.3.
Przykład 8 - autom atyczna synchronizacja zegara czasu rzeczy w isteg o
232
8.3.1.
Pliki sntpjciient.h i sntp_client.c.................................................................................232
8.3.2.
Plik ex_sntp.c................................................................................................................. 238
8.3.3.
Testowanie przykładu....................................................................................................240
8.3.4.
Uwagi końcowe............................................................................................................. 241
9.
Rozgłaszanie UDP................................................................................................... 243
9.1.
Przykład 9a - rozgłaszanie dalagram ów U D P ..........................................................244
9.1.1.
Plik ex_send_bcast.c......................................................................................................244
9.1.2.
Testowanie przykładu....................................................................................................247
9.2.
Przedmowa
Proponując C zytelnikow i kolejną na naszym rynku książkę o m ikrokontrolerach,
pow inienem na w stępie udzielić odpow iedzi na dw a istotne pytania. O czym je s t ta
książka? Do kogo je s t skierow ana?
Na pierw sze pytanie najkrócej m ógłbym odpow iedzieć, że książka traktuje o im ple­
m entow aniu protokołów i tw orzeniu aplikacji sieciow ych na m ikrokontrolery, które
są w yposażone w interfejs E thernet. W ydajność obliczeniow a m ikrokontrolerów sta­
le rośnie (przy zachow aniu poboru m ocy w granicach rozsądnych dla lego rodzaju
układów ). U m ożliw ia to zaim plem entow anie stosu protokołów sieciow ych TCP/IP,
dotychczas dostępnego tylko na dużych m aszynach i kom puterach osobistych.
M oim zdaniem spow oduje to rew olucję zastosow ań m ikrokontrolerów , podobną
do tej, jak ą spow odow ało kilkadziesiąt lat tem u łączenie kom puterów osobistych
w sieci lokalne (ang. local area netw orks) i intersieci (ang. internets). U rządzenia
sterow ane m ikrokontroleram i m ogą stać się częs'cią Internetu, co stw arza zupełnie
now e m ożliw ości.
Specyfika urządzeń sterow anych m ikrokontroleram i polega m iędzy innym i na ko­
nieczności reagow ania na w iele zdarzeń zew nętrznych i sterow ania w ielom a p e­
ryferiam i. C zasy reakcji pow inny być na tyle krótkie, aby spraw iać w rażenie, że
w szystko dzieje się niejako rów nolegle. Stosow ane są tu dw a podejścia:
-
cala aplikacja napisana jest w postaci jed n eg o program u, m ającego dostęp do
całości zasobów sprzętow ych, bezpośrednio obsługującego układy peryferyjne
i w ykorzystującego intensyw nie system przerw ań
-
działaniem m ikrokontrolera steruje system operacyjny, ukryw ający obsługę
sprzętu i przerw ań w sterow nikach urządzeń, a aplikacja jest podzielona na za­
dania, procesy lub w ątki w ykonyw ane w spółbieżnie pod kontrolą tego system u
operacyjnego.
Przykład 9b - odbieranie datagram ów U D P
9.2.1.
9.2.2.
................................................. 247
Plik ex_recv_bcast.c...................................................................................................... 248
Testowanie przykładu....................................................................................................249
10. Serwis W W W ...........................................................................................................251
łO .I. K om unikacja m iędzy klientem a serw erem W W W .................................................252
10.1.1. URI.................................................................................................................................. 252
10.1.2. H TTP...............................................................................................................................253
10.1.3. HTML.............................................................................................................................. 256
10.2. Przykład 10 - prosty serw is W W W .............................................................................259
10.2.1. Pliki httpjm rser.h i http_jmrser.c................................................................................ 259
10.2.2. Pliki http_server.h, littp.lt i http_applicatian.h........................................................... 265
10.2.3. Plik http_server.c - obsługa H TTP.............................................................................. 266
10.2.4. Plik lutp_server.c - obsługa połączenia TCP.............................................................. 271
10.2.5. Plik littp_(ipplication.c.................................................................................................. 273
10.2.6. Plik stm32_logo.h........................................................................................................... 277
10.2.7. Plik exjittpd.c.................................................................................................................278
10.2.8. Testowanie przykładu.............................................................................................
278
Dodatek. Narzędzia G NU............................................................................................. 281
Literatura......................................................................................................................... 286
W niniejszej książce prezentuję pierw sze podejście, które sprzyja zm niejszaniu
rozm iaru pam ięci zajm ow anej przez aplikację, co byw a nadal istotne w system ach
w budow anych.
K siążka ta m a w założeniu być podręcznikiem i przew odnikiem . C hcąc zrealizow ać
zasadę, że najlepiej uczyć się na przykładach, stanąłem przed koniecznością w ybo­
ru platform y sprzętow ej i środow iska program istycznego. Prezentow ane w książ­
ce zagadnienia ilustruję przykładam i napisanym i na m ikrokontroler STM 32F107
z rdzeniem A R M C ortex-M 3 firm y ST M icroeleclronics. Do ich przetestow ania uży­
łem zestaw u Z L29A R M z m odułem ethernetow ym ZL3E T H oraz w yśw ietlaczem
ciekłokrystalicznym W G 12864A . Przykłady napisane są w języ k u C, w którym
obecnie najczęściej program uje się m ikrokontrolery. K om pilow ałem je za pom ocą
G C C w w ersji 4.4.3, z w ykorzystaniem G N U B inutils w wersji 2.20.1 i N ew iib
w w ersji 1.18. U żyłem w nich publicznie dostępnej im plem entacji stosu T C P/IP
- biblioteki lw IP w w ersji 1.3.2. S korzystałem też z bibliotek dostarczanych przez
S T M icroeleclronics: C M SIS (C ortex M icrocontroller Softw are Interface Standard)
w w ersji 1.30, ST M 32F10x Standard P eripherals Library w wersji 3.3.0 i ST M 32
E TH F irm w are Library w w ersji 1.1.0.
8
Przedmowa
Św iadom ie zrezygnow ałem z pisania przykładów w języku C++, który zyskuje ostat­
nio coraz w iększą popularność w s'wiecie m ikrokontrolerów . C ++ ujaw nia sw oje za­
lety przy dużych program ach, zw łaszcza gdy intensyw nie korzysta się ze standardo­
wej biblioteki w zorców STL (ang. Standard Template Library). Nie m a co ukrywać,
że C ++ je st bardzo trudnym językiem . C hcę, aby książka była w pełni dostępna dla
C zytelnika nieznającego C++. U żyw ając pełnej siły wyrazu C++, ryzykow ałbym nie­
zrozum ienie przykładów, a nie ma tu m iejsca na szczegółow e objaśnianie zaaw anso­
w anych konstrukcji tego języka. N atom iast pisanie przykładów w jakiejś' okrojonej
w ersji C ++ byłoby tylko niepotrzebnym dodaw aniem lukru obiektow ości. C zytelnik
znający C ++ bez problem u przełoży na ten języ k przykłady napisane w C.
Przykłady starałem się pisać w sposób ogólny, aby m ogły być łatw o przeniesione
na inne m ikrokontrolery. Jedynym rzeczyw iście specyficznym i m ocno zależnym
od sprzętu fragm entem kodu jest sterow nik (ang. driver) pośredniczący m iędzy bi­
blioteką lw IP a m ikrokontrolerem . Szczegółow o w yjaśniam , ja k napisać taki ste­
row nik i ja k dopasow ać bibliotekę lw iP do architektury konkretnego m ikrokontro­
lera. Pozostała część prezentow anego przeze m nie oprogram ow ania w cale lub tylko
w bardzo niew ielkim stopniu zależy od architektury sprzętu i daje się łatw o zaadap­
tow ać na dow olny m ikrokontroler.
Postaram się teraz odpow iedzieć na drugie z postaw ionych na początku pytań.
K siążka przeznaczona jest dla osób, które ju ż m ają jak ieś dośw iadczenie w pro­
gram ow aniu m ikrokontrolerów. Zakładam , że C zytelnik um ie program ow ać w C.
C hcącym poszerzyć sw oją w iedzę o tym języ k u polecam klasyczną książkę Język
A N SI C, napisaną przez je g o tw órców , K ernighana i R itchiego [2J. N ie je st potrzebna
znajom ość A sem blera ARM . O czekuję co najm niej podstaw ow ej w iedzy z zakresu
elektroniki, tak aby na podstaw ie opisów i schem atów zam ieszczonych w książce
oraz danych katalogow ych um ieć sam odzielnie zm ontow ać układ prototypow y lub
w ykonać niezbędne połączenia w jak im ś zestaw ie uruchom ieniow ym , których wiele
jest dostępnych na rynku. Nie oczekuję natom iast żadnej w iedzy o sieciach kom pu­
terow ych czy protokołach sieciow ych - staram się w yjaśniać w szystko od podstaw.
Z akładam też, że C zytelnik m a w ystarczające obycie inform atyczne, aby sam odziel­
nie zainstalow ać środow isko program istyczne (edytor, kom pilator itd.) i zapoznać
się ze szczegółam i je g o obsługi. M am nadzieję, że książka będzie ciekaw ą lekturą
zarów no dla profesjonalisty, zaw odow o projektującego układy z m ikrokontroleram i,
ja k i hobbysty zajm ującego się tym tylko dla w łasnej satysfakcji. M oże też zaintere­
sow ać osoby, które nigdy dotąd nie program ow ały m ikrokontrolerów , a chciałyby się
dow iedzieć, ja k im plem entuje się protokoły sieciow e na taki komputer.
W ydaje mi się, że dodatkow ym atutem książki jest zaprezentow anie Czytelnikow i
przedstaw iciela now oczesnej rodziny m ikrokontrolerów STM 32. Jest to niew ątpli­
wie rodzina układów, które m ają szansę odnieść rynkow y sukces w najbliższej przy­
szłości. W ybrany do napisania przykładów m ikrokontroler STM 32F107 należy do
linii zorientow anej na kom unikację (ang. connectivity line). O prócz zw ykle spotyka­
nych w m ikrokontrolerach interfejsów I2C, SPI i US ART, w yposażony jest w CAN,
Ethernet, I2S i U SB. Interfejs Ethernet może pracow ać z przepływ nością 10 M b/s
lub 100 M b/s w trybie dw ukierunkow ym naprzem iennym (ang. half-duplex) lub
dw ukierunkow ym jednoczesnym (ang. full-duplex). Interfejs USB m oże pracow ać
Przedmowa
9
z przepływ nością 12 M b/s (ang. fu ll speed) jako urządzenie (ang. device) oraz z prze­
pływ nością 1,5 M b/s (ang. low speed) lub 12 M b/s jako host. Ponadto STM 32F107
zaw iera dość typow e układy licznikow e oraz przetworniki analogow o-cyfrowe i cy­
frowo-analogowe. Skonstruow any jest w oparciu o 32-bitowy rdzeń ARM Cortex-M 3, który można taktować m aksym alnie z częstotliw ością 72 M Hz. Rdzeń ten za­
projektow ano specjalnie do sterow ania system am i głęboko w budowanym i (ang. de­
eply em bedded). O feruje rozbudow any system przerwań z krótkim i przewidywalnym
czasem rozpoczęcia obsługi oraz typow e dla tego segm entu układów tryby oszczędza­
nia energii. Rdzeń obsługuje tylko zestaw instrukcji Thum b-2, rozszerzający zestaw
instrukcji T hum b o kodach 16-bitowych o instrukcje o kodach 32-bitowych. Thum b-2
je st reklam ow any jak o osiągający w ydajność tylko nieznacznie mniejszą od zestawu
instrukcji A RM o kodach 32-bitow ych przy zm niejszeniu o około 25% zapotrzebo­
w ania na pam ięć program u, co je st porów nyw alne z gęstością kodu osiąganą przy
zastosow aniu okrojonego zestawu instrukcji Thum b, który jednak cechuje się istotnie
m niejszą w ydajnością od pełnego zestawu instrukcji ARM .
U kład książki jest następujący. R ozdział 1 pełni funkcję rozbudow anego wstępu.
Poruszam w nim zagadnienia niezw iązane bezpośrednio z tytułem książki, ale po­
trzebne w dalszej jej części. O pisuję obsługę w ejść i w yjść ogólnego przeznaczenia
(ang. general purpose input-output) na przykładzie diod św iecących i w yśw ietla­
cza ciekłokrystalicznego. W yjaśniam strukturę archiw um z przykładam i i param etry
kom pilacji. Omawiam, też organizację pam ięci program u oraz działanie procedury
startow ej (ang. startup code) i skryptu konsolidatora (ang. linker script). Rozdział
2 zaczynam od przedstaw ienia m odelu w arstw ow ego intersieci. N astępnie opisuję
technologię Ethernet, ale skupiam się tylko na jej w ariantach i trybach pracy ob­
sługiw anych przez m ikrokontroler. Przedstaw iam budow ę ramki i rodzaje adresów
ethernetow ych. N astępnie w yjaśniam , ja k ram ki podstaw ow ego protokołu intersie­
ci, czyli IP (ang. Internet Protocol), są przesyłane w ram kach Ethernet. O pisują też
działanie A R P (ang. A ddress Resolution Protocol), czyli protokołu tłum aczącego ad­
resy IP na adresy ethernelow e. Rozdział ten kończę przykładem prostego m onitora
sieci. W rozdziałach 3 i 4 om aw iam bibliotekę lw iP im plem entującą stos protokołów
TCP/IP. W rozdziale 3 zajm uję się w spółpracą tej biblioteki ze sprzętem - pokazuję
trzy w ersje sterow nika Ethernetu. Poszczególne sterow niki różnią się trybem pracy
D M A (ang. D irect M em ory A ccess) oraz sposobem obsługi buforów odbiorczych
i nadaw czych. Pokazuję w ersję z kopiow aniem zaw artości buforów i bez kopiow a­
nia ich zaw artości (ang. zero copy). N a końcu tego rozdziału przedstaw iam nieco
inform acji o protokołach IC M P (ang. Internet C ontrol M essage Protocol) i DHCP
(ang. D ynam ie H ost Configuration Protocol). W rozdziale 4 zajm uję się interfejsem
program istycznym API (ang. application program m ing interface) m iędzy bibliote­
ką lw iP a aplikacją. O pisuję podstaw ow y interfejs udostępniany przez tę bibliotekę,
czyli interfejs surow y (ang. raw). Pokazuję, jak w ykorzystać ten interfejs do tw orze­
nia aplikacji w m odelu klient-serw er. W rozdziale tym przedstaw iam też niezbędne
inform acje o protokołach T C P (ang. Transmission Control Protocol) i U DP (ang.
U ser D atagram Protocol). Rozdział 4 jest jedynym w książce niezakończonym
żadnym przykładem , gdyż w łaściw ie kolejne rozdziały do końca książki zaw ierają
przykłady korzystające z w iadom ości przedstaw ionych w tym rozdziale. W rozdziale
5 opisuję dw a przykłady serw erów TCP, czyli podstaw ow ego strum ieniow ego pro-
10
Przedmowa
tokołu w arstwy transportow ej intersieci. W drugim z tych serw erów urucham iam
układ nadzorcy (ang. w atchdog) w celu zopobieżenia trw ałem u zaw ieszeniu się
program u. W rozdziale 6 om aw iam dw a przykłady klientów TCP. K orzystają one
z w budow anego w m ikrokontroler zegara czasu rzeczyw istego RTC (ang. R eal Time
C lock), w celu urucham iania się w zadanych odstępach czasu. Ponadto korzystają leż
z trybu czuw ania (ang. standby), aby zm niejszyć pobór prądu zasilania m iędzy ko­
lejnymi uruchom ieniam i. D rugi z klientów dodatkow o używ a rejestrów zapasow ych
(ang. backup registers) m ikrokontrolera STM 32F107, aby m iędzy kolejnym i urucho­
m ieniam i przechow ać w nich dane aplikacji. W rozdziale 7 zam ieszczani przykład
prostego serw era UDP, czyli podstaw ow ego pakietow ego protokołu w arstw y trans­
portow ej intersieci. S erw er ten pozw ala zdalnie sterow ać portam i w ejścia-w yjścia
m ikrokontrolera. W rozdziale 8 opisuję przykład klientów dw óch protokołów bazu­
jących na UDP, a m ianow icie DNS (ang. D om ain N am e System ) i S N T P (ang. Sim ple
N etw ork Time Protocol). S N T P służy do synchronizacji czasu w sieci i um ożliw ia
zsynchronizow anie zegara czasu rzeczyw istego m ikrokontrolera z jak im ś dostępnym
w Internecie atom ow ym w zorcem czasu. W rozdziale 9 zajm uję się rozgłaszaniem
(ang. broadcast) w UDP. W rozdziale 10 pokazuję, ja k skom unikow ać się z m ikro­
kontrolerem za pom ocą przeglądarki internetow ej i opisuję im plem entację prostego
serw isu W W W (ang. World Wide Web). Listę książek i dokum entów , z którym i w ar­
to się zapoznać, zam ieszczam w spisie literatury. W dodatku opisuję narzędzia G NU ,
których użyłem do skom pilow ania przykładów.
D uża część książki, począw szy od rozdziału 4, zaw iera szczegółow e opisy, jak
im plem entuje się w łasne protokoły i tw orzy aplikacje korzystające bezpośrednio
z protokołów transportow ych T C P i UDP. W szystkie przykłady używ ają interfejsu
surow ego, który pozw ala na lepszą integrację aplikacji ze stosem TCP/IP. Interfejs
surow y jest preferow any w sy stem ach w budow anych, gdyż ma m ale w ym agania
pam ięciow e i nie potrzebuje dużej m ocy obliczeniow ej - nie m a w ątków ani p ro ­
cesów , nie trzeba zm ieniać kontekstu. P rzykładow e program y są sterow ane zdarze­
niami (ang. event based) za pom ocą funkcji zw rotnych (ang. callback functions).
Ź ródłem zdarzeń są przerw ania. Przykłady konstruuję przyrostow o - kolejne korzy­
stają z m odułów zaprogram ow anych na potrzeby poprzednich przykładów .
W szystkie pliki źródłow e przykładów , łącznie ze źródłam i biblioteki lw IP oraz
źródłam i specyficznych dla m ikrokontrolerów S T M 32 bibliotek dostarczanych
przez ST M icroelectronics, dostępne są w postaci skom presow anego archiw um , k tó ­
re m ożna ściągnąć ze strony W ydaw nictw a BTC http://w w w .btc.pl lub strony d o m o ­
wej A utora h ttp://w w w .m iinuw .edu.pl/~ nw rpe/book.
C hcę w yraźnie zaznaczyć, że książka nie je st instrukcją obsługi narzędzi progra­
m istycznych ani nie stanow i w yczerpującej dokum entacji sprzętu użytego do prze­
testow ania zam ieszczonych przykładów . C zytelnik z łatw ością znajdzie potrzebną
dokum entację na stronach internetow ych odpow iednich producentów .
Staram się prom ow ać polską term inologię. D la w ygody C zytelnika, zw ykle zm u­
szonego korzystać z dokum entacji w języku angielskim , przy pierw szym , a czasem
i przy kolejnym , użyciu term inu, który nie je s t pow szechnie znany, um ieszczam
w naw iasach je g o angielski odpow iednik.
M arcin P eczarski, W arszaw a 2011
Podstawy
12
I. Podstawy
W tym rozdziale poruszam zagadnienia niezw iązane bezpośrednio z tytułem książki.
Z apoznanie się z w iększością tego m ateriału uw ażam jed n ak za potrzebne do zro ­
zum ienia przykładów zam ieszczonych w następnych rozdziałacłi. Ponadto niektóre
z tych zagadnień nie są, m oim zdaniem , dostatecznie obszernie opisane w literatu­
rze pośw ięconej m ikrokontrolerom , a w ydają mi się w ażne i ciekaw e. Staram się
tu przedstaw ić tylko niezbędne podstaw y, ujęte w takiej kolejności, aby C zytelnik
m ógł ja k najszybciej zacząć urucham iać program y. C zytelnik czujący, że przedsta­
w ione w tym rozdziale tem aty są m u dobrze znane, m oże go szybko przekartkow ać
lub przejść od razu do następnego rozdziału, czyli do zasadniczej części książki.
1.1.
Mikrokontroler STM32F107
W szystkie prezentow ane w lej książce przykłady napisałem w języ k u C na m ikro­
kontroler ST M 32F107, który w yposażony jest w 32-bitow y rdzeń A RM C ortexM 3. Ponadto m ikrokontroler ten m a w iele układów peryferyjnych, m.in. interfejs
E thernet, który um ożliw ia podłączenie go do sieci lokalnej, a za je j pośrednictw em
do Internetu. U ktad S T M 32F107 je s t dostępny w kilku w ersjach różniących się
w ielkościam i pam ięci i liczbą w yprow adzeń. Z estaw iono je w tabeli 1.1. S krót KiB
oznacza niedaw no w prow adzoną do inform atyki now ą jed n o stk ę rozm iaru pam ięci
- kibibajt (kilobinarybajt), czyli d okładnie 1024 bajty, w odróżnieniu od kilobajta
(skrót kB), który form alnie pow inien m ieć 1000 bajtów. O bsługa E thernetu i stosu
T C P /IP je st bardzo „pam ięciożerna” , m im o to w szystkie zam ieszczone w tej książ­
ce przykłady m ożna uruchom ić na najskrom niejszym m odelu.
W tabeli 1.2 przestaw iono podstaw ow e typy C obsługiw ane sprzętow o przez rdzeń
C ortex-M 3. W celu w ykonania operacji arytm etycznych na innych typach, w szcze­
gólności na 64-bitow ym typie całkow itym ł o n g l o n g i typach zm iennoprzecinko­
w ych, w yw oływ ane są funkcje biblioteczne. D latego ze w zględów w ydajnościo-
Tab. 1.1. Dostępne wersje mikrokontrolera STM32F107
Model
Flash
SRAM
STM 32F107R B
12 8 KiB
48 KiB
LQFP64
STM 32F107R C
25 6 KiB
64 KiB
LQFP64
STM 32F107VB
128 KiB
4 8 KiB
LQFP100 lub LFBGA100
STM 32F107VC
2 5 6 KiB
64 KiB
LQFP100 lub LFBGA100
a tires, void*, char* itd.
R ozm iar
8 bitów
16 bitów
32 bity
32 bity
32 bity
13
w ych, jeśli jest to m ożliw e, należy unikać stosow ania typu long long, a przede
w szystkim typów zm iennoprzecinkow ych f l o a t , d o u b le i long double.
W m ikrokontrolerach STM 32 rdzeń C ortex-M 3 je st skonfigurow any na stale w try­
bie cienkokońców kow ym (ang. little-enclian). Z atem zm ienna w ielobajtow a prze­
chow yw ana jest w pam ięci od najm niej do najbardziej znaczącego bajtu. Ilustruje
to poniższy fragm ent program u w języku C.
union {
unsigned short s;
unsigned char c [2);
} a;
a.s = 0xla2b;
if (a.c[0) == Qx2b 66 a.cli] == Qxla)
/* Jestem cienkokońcówkowy (ang. little-endian). */
else if (a.cfO] == Gxla 66 a.c[l] == 0x2b)
/* Jestem grubokońcówkowy (ang. big-endian). */
C ortex-M 3 m a typow y dla architektury A RM zestaw rejestrów:
-
RO do R12 - rejestry ogólnego przeznaczenia (ang. general purpose registers),
SP (R13) - w skaźnik stosu (ang. stack pointer),
LR (R 14)- adresu pow rotu (ang. link register),
PC (R15) - licznik program u (ang. program counter),
PSR - rejestr znaczników (ang. program status register),
PRIMASK, FAULTMAyJK, BASEPRI - rejestry m askujące przerw ania (ang. exception
m ask registers) - w dokum entacji przerw ania nazyw ane są w yjątkam i,
-
CONTROL - rejestr sterujący trybam i pracy rdzenia.
O bszerniejszy opis architektury m ikrokontrolera STM 32F107 znajduje się w kolej­
nych rozdziałach, gdzie będzie potrzebny w prezentow anych przykładach. Czytelnik
zainteresow any szczegółam i m oże też zaw sze sięgnąć do dokum entacji dostępnej
w Internecie. O gólny przegląd architektury i param etry elektryczne zam ieszczone
są w [9]. N iezbędne dla program istów inform acje o rdzeniu m ożna znaleźć w |7],
a w szystkie układy peryferyjne są opisane szczegółow o w [8].
Obudowa
Tab. 1.2. Podstawowe typy języka C i ich rozmiary w architekturze Cortex-M3
Typ
char
signed char
unsigned char
short
unsigned short
int
unsigned
long
unsigned long
1.2. Struktura przykładów
Struktura przykładów
Integralną częścią książki są teksty źródłow e przykładów . Skom presow ane archi­
w um zaw ierające aktualną ich w ersję m ożna ściągnąć ze strony W ydaw nictw a
B TC http://w w w .btc.pl lub ze strony dom ow ej A utora htip://www.minutw.echt.
p t/~m a rpe/book. Spora część tekstów źródłow ych m a charakter dość standardo­
wy, bardzo techniczny i ich dokładne poznanie je st zbędne do zrozum ienia dzia­
łania program u. Ponadto przeglądanie długich w ydruków program ów byw a nu­
żące. N atom iast przestudiow anie całości teksów źródłow ych staje się oczyw iście
konieczne, gdy chcem y je zm odyfikow ać. D latego w książce zam ieszczam tylko
kluczow e fragm enty tekstów źródłow ych, a chcących poznać całość odsyłam do
archiw um w w ersji elektronicznej. A rchiw um to zaw iera strukturę katalogów po­
k azaną na rysunku 1.1. Ż eby zachow ać przejrzystość, niektóre podkatalogi - nie­
istotne z punktu w idzenia zrozum ienia treści książki - na tym rysunku pom inięto.
Ścieżki w tym archiw um podaję w konw encji uniksow ej z ukośnikiem w praw ą
14
■exam ples -
stronę. Jeśli nazw a ścieżki rozpoczyna się od kropki, to je s t to ścieżka w zględem
katalogu, w którym rozpakow ano archiw um z przykładam i. Jestem przekonany, że
taka konw encja pozw oli C zytelnikow i łatw o odnajdow ać p otrzebne katalogi i pliki
w system ie, którego używ a.
K atalog ./exam ples zaw iera teksty źródłow e w szystkich przykładów opisanych
w tej książce. Podkatalog ./exam ples/src zaw iera pliki z im plem entacją. P odkatalog
./exam ples/include zaw iera pliki nagłów kow e. Jego podkatalogi butterfly, p ro to ty­
p e, z,l29ann+z.l3eth zaw ierają pliki nagłów kow e definiujące k onfigurację sprzętu.
P odkatalog ./exam ples/scripts zaw iera skrypty konsolidatora (ang. lin ker scripts).
W nazw ach plików stosuję następ u jącą konw encję. Pliki, których nazw a zaczyna
się od przedrostka board, zaw ierają tekst źródłow y zależny od użytego zestaw u
uruchom ieniow ego, czyli od schem atu elektrycznego k onstruow anego urządzenia.
Pliki, których nazw a zaczyna się od przedrostka util, zaw ierają funkcje użyteczne
w w ielu przykładach i niezależne od schem atu elektrycznego, ale być m oże nadal
zależne od architektury m ikrokontrolera. N azw y głów nych plików poszczeg ó l­
nych przykładów , zaw ierających funkcję m ain, zaczynają się od przedrostka ex.
P ozostałe pliki nie zależą w cale lub zależą w niew ielkim stopniu od arch itek tu ­
ry m ikrokontrolera, a tym bardziej nie zależą od schem atu elektrycznego. N azw a
pliku, który im plem entuje protokół sieciow y, zaw iera skrót nazw y tego protokołu
(np. tcp, udp, snip, http) o raz pełn io n ą w tym protokole funkcję (np. client, se­
rver). Poszczególne pliki źródłow e, um ieszczone w katalogu ./exam ples, opisuję
sukcesyw nie w rozdziałach dotyczący ch odpow iednich przykładów , w których są
w ykorzystyw ane.
i
W katalogu ./lw ip-1.3.2 znajdują się źródła biblioteki iw IP im plem entującej stos
protokołów TCP/IP. Do napisania przykładów prezentow anych w tej książce w yko­
rzystałem jej w ersję 1.3.2. K atalog ./excim ples/include/arcli zaw iera pliki nagłów ­
kow e specyficzne dla architektury C ortex-M 3 i potrzebne do skom pilow ania tej
biblioteki. Ponadto w katalogu ./exam ples/include znajduje się plik nagłów kow y
lw ipopts.li, za pom ocą którego konfiguruje się opcje stosu TCP/IP. B ibliotekę IwIP
i w szystkie te pliki nagłów kow e opisuję szczegółow o w rozdziale 3.
W katalogu Jst/L ibraries um ieszczone są źródła bibliotek dostarczanych przez
ST M icroelectronics. Są to C M SIS (C ortex M icrocontroller Softw are Interface
Standard) w wersji 1.30, S T M 32FIO x Standard P eripherals L ibrary w wersji 3.3.0
[6] i ST M 32 ETH F irm w are L ibrary, przez producenta określana też ja k o STM 32
ETH Driver, w wersji 1.1.0 patrz rów nież [3], W szystkie razem nazyw am dalej
skrótow o biblioteką STM 32. Sposób skom pilow ania biblioteki STM 32 opisuję
w rozdziale 1.4. U dostępniane przez nią struktury i funkcje, które w ykorzystuję,
om aw iam przy odpow iednich przykładach. W katalogu ,/st znajdują się też dw a pli­
ki w form acie chm. Jeden zaw iera d o kum entację S T M 32F10x Standard P eripherals
Library, a drugi - opis S T M 32F 107 L w lP D em onstration Package w raz z doku­
m entacją ETH Firm w are Library. W katalogu ./st/L ibraries/C M SIS/D ocum entation
znajduje się dokum entacja C M SIS w form acie htm l.
K atalog ./m ake zaw iera skrypty dla program u m ake. O pisuję je w dodatku. K atalog
ten zaw iera rów nież program y pom ocne przy urucham ianiu niektórych przykładów.
Przedstaw iam je w odpow iednich m iejscach, gdzie są w ykorzystyw ane.
15
1.3. Przykład la - miganie diodami świecącym i
I. Podstawy
-s rc
- Include
- arch
- butterfly
- prototype
- zl29arm +zl3eth
— scripts
-s rc —
- lw lp -1 .3 .2 -
-Ip v4
- n etif
- include
I
- s t — L ib ra rie s-
ipv4
-S T M 3 2 F 1 O x_S tdP eriph_D river-S T M 3 2 ETH D riv e r --------------- CM SIS -
■make
n
src
inc
- C M 3 —i— C oreSupport
'— D evice S u pp o rt-
-S T -
-STM 32F10X
Rys. 1.1. Struktura katalogów archiwum z przyktadami
1.3.
Przykład 1a - miganie diodami świecącymi
W w ielu książkach uczących program ow ania pierw szym prezentow anym przykła­
dem je s t zw ykle program typu W itaj Św iecie. W św iecie m ikrokontrolerów oznacza
to zam iganie diodą św iecącą. N ie je ste m oryginalny i leż w pierw szym przykła­
dzie m igam diodam i. Posłuży mi to jed n ak do czegoś w ięcej, do opisania kolejnych
składników architektury m ikrokontrolera, zależności m iędzy plikam i nagłów kow y­
mi, sposobu konfigurow ania zestaw u uruchom ieniow ego oraz kom pilow ania cało­
ści. Przykłady, które prezentuję w kolejnych rozdziałach, są coraz bardziej skom ­
plikow ane, składają się czasem naw et z kilkudziesięciu plików źródłow ych, ale ich
struktura je s t analogiczna do struktury pierw szego przykładu. Poznanie tej struktury
na prostym przykładzie um ożliw i później skupienie się na m erytorycznej zaw ar­
tości przykładów , bez potrzeby opisyw ania za każdym razem , gdzie w archiw um
znajdują się potrzebne pliki, ja k dopasow ać przykład do innego schem atu elektrycz­
nego, ja k go skom pilow ać itd.
W zestaw ie Z L29A R M do m ikrokontrolera podłączone są dw ie diody św iecące.
Załóżm y, że je d n a je s t czerw ona, a druga zielona. W pierw szym przykładzie m iga­
ją one w nieskończonej sekw encji: św ieci czerw ona, św iecą obie, św ieci zielona,
obie nie św iecą. W ta b e li 1.3 zestaw iono nazw y plików źródłow ych i bibliotecz­
nych, które trzeba w yspecyfikow ać kom pilatorow i, aby skom pilow ać ten przykład.
Tab. 1.3. Pliki przykładu 1a
Źródłowe I biblioteczne
e x je d .c
startup _stm 32_cld. c
boardJ e d .c
util_delay.c
Iibstm 32/10x.a
Nagłówkowe
board_def.h
board_defs.li
board led.h
utH_delay.h
Stm32t10x_conf,h
16
17
1.3. Przykład la - miganie diodami świecącymi
1. Podstawy
1.3.2.
Pliki util_delay.h i util_delay.c
Plik util_delay.h znajduje się w katalogu ./exam ples/include, a plik util_delay.c w ka­
talogu ./exam ples/src. Pierw szy z tych plików deklaruje sygnaturę funkcji opóźnia­
jącej, a drugi zaw iera jej im plem entację. F unkcja ta je st bardzo prosta:
void Delay(volatile unsigned count) (
while(count— );
I
U zyskanie w ym aganego opóźnienia w ym aga eksperym entalnego skalibrow ania
w artości argum entu, gdyż czas opóźnienia zależy od częstotliw ości taktow ania
i ustaw ienia opcji kom pilatora. Ponadto w szelkie przerw ania obsługiw ane w trak­
cie w ykonyw ania tej funkcji w ydłużają opóźnienie. Precyzyjne odm ierzanie cza­
su m ożna uzyskać, w ykorzystując układy licznikow e, co jednak w ym aga znacznie
w ięcej pracy program istycznej. Jednak w wielu zastosow aniach taka prosta funkcja
jest w ystarczająca i będziem y z niej korzystać w kolejnych przykładach.
Rys. 1.2. Pliki nagłówkowe przykładu 1a
Ponadto zaw iera ona nazw y plików nagłów kow ych w ykorzystyw anych w tym
przykładzie i znajdujących się w podkatalogu ./exam ples/include. Pliki nagłów ­
kow e bibliotek nie są w ym ienione. N a rysunku 1.2 zobrazow ano g raf zależności
w łączania plików nagłów kow ych z uw zględnieniem plików nagłów kow ych biblio­
tek. W kolejnych podrozdziałach opisuję szczegółow o zaw artość poszczególnych
plików. O opcjach kom pilacji piszę w rozdziale 1.4. U staw ienia zw orek zestaw u
Z L29A R M w tym przykładzie nie m ają istotnego znaczenia. N ależy tylko w ybrać
sposób zasilania płytki zw orką PW R SE T (U SB lub E X T - zew nętrzny zasilacz)
i zw orkam i BOOTO i BOOT1 m iejsce, skąd startuje program . Ja ustaw iam BOOTO
w pozycji 0, aby program startow ał z pam ięci Flash. W tym przypadku ustaw ienie
BOOT1 nie m a znaczenia.
1.3.1.
1.3.3.
Pliki boardJ e d .h i boardJ e d .c
P lik boardJ e d .li znajduje się w katalogu ./exam ples/include, a plik b o a r d je d .c
w katalogu ./exam ples/src. W pierw szym z tych plików deklarujem y sygnatury funk­
cji obsługujących diody św iecące, a w drugim um ieszczam y ich im plem entacje.
N ajpierw uzależniam y tekst źródłow y program u od połączeń w zestaw ie urucho­
m ieniow ym . D eklarujem y, że diody św iecące podłączone są do portu E (G PIO E,
ang. g eneral purposeńnput-output E), czerw ona dioda do w yprow adzenia 15, a zie­
lona - do w yprow adzenia 14. D o w yprow adzeń podłączone są katody diod, zatem
następnie definiujem y, że dioda św ieci, gdy na w yprow adzeniu je st stan niski (stała
Bit_RESET), a nie św ieci w stanie w ysokim (stała Bit_SET). O dpow iedni fragment
program u w ygląda następująco:
Plik e x je d .c
((include <board_def,h>
Plik e x j e d .c znajduje się w katalogu ./exam ples/src i zaw iera funkcję main przy­
kładu. W funkcji main najpierw w yw ołujem y funkcję LED configure konfigurującą
w yprow adzenia, do których podłączone są diody św iecące, a następnie w nieskoń­
czonej pętli w yw ołujem y funkcje w łączające lub w yłączające odpow iednią diodę
św iecącą, poprzedzielane w yw ołaniem funkcji opóźniającej D elay. Funkcje te o p i­
suję w następnych podrozdziałach.
lifndef BOARD_TYPE
lerror BOARD_TYPE undefined
(fendif
int main(void) |
static const unsigned delay_time = 2000000;
LEDconfigure();
for (;;) {
RedLEDonO;
Delay(deiay_time);
GreenLEDonO ;
Delay (delay_tiine);
RedLEDoff();
Delay(delay_time);
GreenLEDoff();
Delay(delay_time);
)
)
łif BOARD_TYPE ==* PROTOTYPE i | \
BOARD_TYPE == BUTTERFLY !! \
BOARD_TYPE == ZL29ARM
(¡define GPIO_LED
(¡define REDDLED
fdefine GREEN_LED
idefine RCC_APB2Periph_GPIO_LED
¡(define LED_ON
Idefine LED_OFF
(¡else
terror Undefined BOARD_TYPE
fendif
GPIOE
GPIO_Pin_15
GPIO_Pin_14
RCC_APB2Periph_GPIOE
BitJtESET
Bit SET
W t-U .J .
S tała BOARD_TYPE musi być zdefiniow ana w pliku board_def.li. W artości, do których
porów nyw ana je st ta stała, zdefiniow ane są w pliku board_defs.Ii. Pliki board_def.lt
i board_defs.h opisuję w jednym z następnych podrozdziałów .
W m ikrokontrolerach ST M 32 przed użyciem jakiegokolw iek układu peryferyjne­
go m usim y w łączyć taktow anie tego układu. D om yślnie, po w yzerow aniu m ikro­
kontrolera, w szystkie sygnały taktujące peryferie są w yłączone. Jest to rozsądne,
18
I. Podstawy
gdyż oszczędza energię - nieużyw ane układy nie pobierają niepotrzebnie prądu.
Z atem w funkcji konfigurującej diody św iecące najpierw m usim y uaktyw nić tak­
tow anie portu, do którego są one podłączone. N astępnie, przed w łaściw ym skon­
figurow aniem , ustaw iam y tak port w yjściow y, aby diody były początkow o w yłą­
czone. W yprow adzenia konfigurujem y w trybie w yjściow ym przeciw sobnym (ang.
push-pull output). Poniew aż sterow anie diodam i św iecącym i nie w ym aga strom ych
zboczy sygnału, ustaw iam y najm niejszą (z trzech m ożliw ych: 2 M H z, 10 M H z lub
50 M H z) szybkość zm ian sygnału na tych w yprow adzeniach. C ała funkcja konfigu­
rująca diody św iecące w ygląda tak:
1.3. Przykład la - miganie diodami świecącym i
3.5.
ffdefine __10 volatile
typedef struct f
_ I 0 uint32_t CRŁ;
10 uint32_t CRH;
10 uint32_t IDR;
10 uint32_t ODR;
_ X 0 uint32__t BSRR;
10 uint32_t BRR;
_ I 0 uint32__t LCKR;
) GPIOJTypeDef;
ffdefine PERIPH_BASE
ifdefine APB2PERIPHJ3ASE
ffdefine GPIOE_BASE
ffdefine GPIOE
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIO_LED, ENABLE);
GPIOJiriteBit(GPIO_LED, RSD_LED | GREEN_LED, LEDJ3FF);
GPIO~StructInit{&GPIO_InitStruct};
GPIO_InitStruct.GPI0_Pin * GREEN_LED j RED_LED;
GPI(f InitStruct.GPIOJfode = GPIO_Mode_Out_PP;
GPIO_InitSŁruct.GPIO_Speed = GPI0_Speed_2MHz;
GPX0 Init (GPI0_LED, &GPIO_InitStruct:);
}
Dla każdej z diod św iecących definiujem y trzy funkcje: w łączającą, w yłączającą
oraz zw racającą stan diody, czyli 1, gdy dioda św ieci, a 0 w przeciw nym przypad­
ku. Funkcje te obudow ują w yw ołania funkcji z biblioteki ST M 32. D la czerw onej
diody w yglądają one następująco:
j
}
'
“
{(uint32_t) 0x40000000)
(PERIPHJBASE + 0x10000)
(APB2PERIPH_BASE + 0x1800}
((GPIOJTypeDef *) GPIOE_BASE)
Pow yższe definicje spraw iają, że np. do rejestru w yjściow ego ODR (ang. output data
register) portu E m ożem y się odw ołać, pisząc:
GPIOE->ODR
void RedLEDoff (void) {
GPIO WriteBit(GPICJLED, RED_LED, LED OFF) ;
Taki bezpośredni sposób odw oływ ania się do rejestrów w ejścia-w yjścia będziem y
jeszcze w ykorzystyw ać w dalszej części lego rozdziału. Innym przykładem są, zde­
finiow ane w pliku core_cm 3.h, funkcje w łączające i w yłączające przerw ania:
)
int RedLEDstate(void) (
return GPIOJleadOutputDataBit(GPI0_LED, RED_LED) == LED_0M;
1.3.4.
Pliki stm 32f10x.h, system_stm32f10x.h i core_cm3.h
Pliki stm 3 2 fl0 x.h i system _ stm 3 2 fl0 x.h znajdują się w katalogu Jst/L ib ra ries/
C M SIS/C M 3/D eviceSupport/ST /STM 32F ]0x, a plik core_cm 3.h w katalogu J s t/
L ibraries/C M SlS/C M 3/C oreSupport. Są one częścią biblioteki STM 32. W plikach
tych zdefiniow ane są adresy rejestrów w przestrzeni w ejścia-w yjścia, m akra obu­
dow ujące instrukcje A sem blera, num ery przerw ań i przeróżne stale potrzebne, aby
program ow anie było w ygodniejsze. Przykładow o, użyty w yżej port E i rejestry, za
pom ocą których funkcje biblioteczne odw ołują się do niego, są zdefiniow ane na­
stępująco:
void LEDconfigure(void) {
GPICJInitTypeDef GPIO_InitStruct;
void RedLEDon(void) (
GPIOJłriteBit(GPIO_LED, RED_L£D, LED O N ) ;
1
static inline void
static inline void
Funkcje obsługujące zieloną diodę są analogiczne.
Te i inne podobne m akra pojaw ią się w rozdziale 3.
Pliki s tm 32f10xjjp io .h i stm 32f10x_rcc.h
Pliki stm 32fl0x_ g p io .il i stm 3 2 fI0x_rcc.li znajdują się w katalogu J st/L ib ra ries/
STM 32F 10x_StdP eripli_D river/inc. Pliki te są częścią biblioteki ST M 32. W pli­
ku stm 3 2 f¡0x_gpio.lt zdefiniow ane są struktury, stałe i funkcje obsługujące p or­
ty w ejścia-w yjścia, a w pliku stm 3 2 fl0 x _ rc c.h - obsługujące zerow anie układów
m ikrokontrolera i dystrybucję sygnałów zegarow ych do układów peryferyjnych.
Identyfikatory (funkcji, stałych, typów ) zdefiniow ane w pliku stm 3 2 fl 0x_gpio.lt
m ają prefiks G PIO (ang. G eneral P urpose Input-O utput), a te w pliku stm 3 2 fl0 x _
rec.h - prefiks RCC (ang. Reset a n d d o c k Control). W katalogu J st/L ib ra ries/
ST M 32F 10x_StdP eriph_D river/src znajdują się odpow iednie pliki stm 32fW x_gpio.
c i stm32j'10x_rcc.c z im plem entacją. D o każdego układu peryferyjnego m ikrokon­
trolera biblioteka STM 32 dostarcza odpow iednią parę plików, np. dla układów licz­
nikow ych są to pliki stm 3 2 fl0 x _ tim .h i stm 32fJ0x_tim .c.
19
3.6.
enable_irq()
( asm volatile ("cpsie i");)
disable_irq() { asm volatile ("cpsid i");)
Plik Iibstm 32f10x.a
Do każdego przykładu m usim y dołączyć w łaściw e pliki biblioteczne - ten przykład
w ym aga plików stm 3 2 fl0 x_ g p io .c i stm 32fl0x_rcc.c. Z astanaw ianie się, które pliki
są niezbędne w konkretnym program ie i dołączanie do każdego projektu innego
zestaw u plików bibliotecznych je s t czasochłonne i nużące. Lepszym rozw iązaniem
je st skom pilow anie raz w szystkich dostarczonych plików źródłow ych biblioteki
ST M 32 i zebranie ich w jed n y m binarnym pliku bibliotecznym , który potem tyl­
ko konsolidujem y z plikam i przykładu. D odatkow ym zyskiem je s t skrócenie czasu
rekom pilacji, jeśli m odyfikujem y przykład - pliki biblioteczne nie są rekom pilow ane. Plik U bsim 32f]0x.a zaw iera w łaśnie skom pilow aną bibliotekę ST M 32, którą
m ożem y konsolidow ać z plikam i przykładów . Plik U bstm 32fl0x.a m usim y utw o­
rzyć sam i - pow staje on przez skom pilow anie w szystkich plików z rozszerzeniem
c z następujących katalogów :
20
I. Podstawy
-
./'st/U braries/ST M 32F I0x_StdP eriph_D river/src,
-
./st/Libraries/STM 32_ETJ-J_D river/src,
-
Jst/Libraries/C M SlS/C M 3/C oreSupport,
-
Jst/L ibraries/C M SIS/C M 3/D eviceSttpport/ST /ST M 3 2 F 1Ox.
Pliki nagłów kow e biblioteki znajdują się w katalogach:
-
Jst/L ibraries/S I'M 3 2 F JO x_StdPeriph_D river/inc,
-
./.st/Libntries/ST M 32_E T JJ_D river/inc,
-
./.sl/L ibraries/C M SIS/C M 3/C oreSupport,
-
Jst/L ibraries/C M SIS/C M 3/D eviceSupport/SIZ ST M 32F 10x.
Ponadto potrzebny je st jeszcze plik nagłów kow y stm 32flO x_conf.li, który je s t w ka­
talogu ./exam ples/include. Przydatne opcje kom pilatora opisuję szczegółow o w ro z­
dziale 1.4.
1.3.7.
Plik stm32f10_conf.h
Plik stm 3 2 f]0 _ c o iifh zn ajduje się w katalogu ./exam ples/include. W zam yśle
tw órców biblioteki S T M 32 m a on być cen tralnym m iejscem konfigurow ania
opcji projektu. Z aleca się, aby w nim um ieszczać dyrektyw y # in c lu d e w szyst­
kich używ anych plików stm32J'10x_*.h o raz definicje zw iązane z konfiguracją
sprzętu, zestaw u uruchom ieniow ego itp., czyli definicje zależne od schem atu elek ­
trycznego. N iestety takie rozw iązanie się nie spraw dza. Jak w idać na rysunku 1.2,
każdy z plików stm 32flO x_*.h w łącza p lik stm 3 2 fI0 _ co n f.h - pośrednio poprzez
plik stm 32j'I0x.h. Z atem w łączanie plików stm 3 2 fI0 x_ * .h w pliku stm 3 2 fl O_conf.
h pow oduje pow stanie cykli w łączeń plików nagłów kow ych. K om pilator sobie z
nim i radzi. Jednak przy tw orzeniu w iększych projektów , w celu skrócenia cza­
su rekom pilacji, stosujem y zw ykle narzędzia, które w ykryw ają zależności m iędzy
plikam i. D zięki tem u po edycji plików źródłow ych w ykonyw ana je s t rekom pila­
cja przyrostow a - kom pilow ane są ty lk o zm ienione pliki i pliki od nich zależne.
W ystępow anie cyklu w łączeń plików nagłów kow ych je s t błędem , gdyż w prow adza
zbędne zależności m iędzy plikam i i m oże pow odow ać niepotrzebne kom pilow anie
wielu plików. Ponadto zależność plików nagłów kow ych biblioteki S T M 32 od p li­
ku sttn 3 2 fJO_conf.lt spraw ia, że jak ak o lw iek zm iana w nim w ym aga p rzekom pi­
low ania tej biblioteki, co je s t n ieuzasadnione - biblioteka nie pow inna zależeć od
plików nagłów kow ych projektu. B łędem je s t też w łączanie w szędzie w szystkich
m ożliw ych plików nagłów kow ych, g d y ż niepotrzebnie w ydłuża czas kom pilow a­
nia projektu.
Z w yżej om ów ionych pow odów zrezygnow ałem w tej książce z w ykorzystyw ania
pliku stin32fJ0_conf.h. Stosuję tradycyjne podejście i w każdej jed n o stce translacji
(dla języ k a C je st to zw ykle pojedynczy plik źródłow y z rozszerzeniem c) w łączam
tylko te pliki, które są tam niezbędne. N iestety pliku stm 3 2 f 10_conf.lt nie m ożna się
pozbyć całkow icie i trzeba go dostarczyć, gdyż zaw iera definicję m akra a s s e r t _
param, które je st używ ane przez b ibliotekę STM 32. M akro to służy do spraw dzania
popraw ności argum entów w funkcjach bibliotecznych. M oże to być w ykorzystane
na etapie urucham iania program u, ale w wersji ostatecznej takie spraw dzanie raczej
1.3. Przykład Ja - miganie diodami iw iecqcym i
21
należy w yłączyć, gdyż zw iększa rozm iar kodu w ynikow ego i w ydłuża czas w y­
konyw ania program u. N a potrzeby tej książki plik stm 32fJ O_conf.il zaw iera tylko
puste makro:
idefine assert_param(expr)
1.3.8.
((void)0)
Pliki board_def.li i board_defs.h
Pliki bounl_def.h i boayd_defs.h są m oją propozycją rozw iązania problem u konfi­
gurow ania elem entów projektu zależnych od schem atu elektrycznego. Plik bottrd_
defs.li znajduje się w katalogu ./exam ples/include i zaw iera definicje stałych dla
poszczególnych w ariantów sprzętu:
idefine
idefine
idefine
Idefine
idefine
BUTTERFLY
PROTOTYPE
ZL29ARM
STE100P
ZL3ETH
10700
10701
10729
100
300
Plik baaixl_defs.liym l w łączany przez plik bocird_def.li, który definiuje używ any w pro­
jekcie w ariant sprzętu. Przykładow o w katalogu ./exaniples/incliide/zl29ann+zl3elli
jest plik b o a n l_ d e fh określający, że chcem y użyć zestaw u ZL29A R M z m odułem
ethernetow ym ZL3ETH . Z aw iera on definicje:
Idefine B O A R D T Y P E ZL29ARM
Idefine ETI1__B0ARD ZL3ETH
Plik b o a rd _ d efh je st .włączany każdorazow o, gdy w którym ś pliku źródłow ym trze­
ba uzależnić jak ieś definicje od w ariantu sprzętu, ja k to pokazałem w rozdziale
1.3.3. M am y dw ie m ożliw ości użycia tego pliku. Po pierw sze, m ożem y podać kom ­
pilatorow i, żeby poszukiw ał plików nagłów kow ych m .in. w katalogu ./exam ples/
inclttde/zl29ann+ zl3eth. Dla każdego projektu m ożem y indyw idualnie ustawić tę
ścieżkę. D la każdego w ariantu sprzętu tw orzym y osobny podkatalog z inną w ersją
pliku board_def.h. Po drugie, m ożem y po prostu um ieszczać w bieżącym katalogu
projektu w łaściw y plik b oard_defli. T rzeba w tedy pam iętać, żeby przy w łączaniu
ujm ow ać jeg o nazw ę w cudzysłow y, co w ym usza poszukiw anie pliku nagłów ko­
w ego najpierw w katalogu bieżącym . W łaściw a dyrektyw a preprocesora pow inna
zatem w yglądać lak:
iinclude "board_def.h"
K olejnym zadaniem pliku board_def.hJ e s t w eryfikacja spójności definicji w ym aga­
nych przez bibliotekę STM 32. U życie tej biblioteki w ym aga zdefiniow ania trzech
stałych preprocesora języka C. Pierw sza z nich to stała USE_STDPERIPH_DRIVER
oznaczająca w łaśnie, że chcem y korzystać ze Standard Peripherals Library, któ­
ra je st częścią biblioteki STM 32. D ruga stała definiuje m odel m ikrokontrolera.
ST M 32F107 należy do linii zorientow anej na kom unikację (ang. connectivity line)
i odpow iednia stała to STM32F10X_CL - dw ie ostanie litery nazw y są skrótem angiel­
skiej nazw y tej linii m ikrokontrolerów . T rzecia stała HSE_VALUE definiuje częstotli­
wość w hercach kw arcu, którym taktujem y m ikrokontroler. D efinicje tych trzech
stałych m uszą być w idoczne we w szystkich plikach nagłów kow ych i źródłow ych
biblioteki STM 32 oraz w plikach źródłow ych projektu, w których w łączane są pliki
nagłów kow e tej biblioteki. Ponadto definicje te m uszą być w szędzie jednakow e.
N ajw łaściw szym rozw iązaniem byłoby zdefiniow anie tych stałych w jakim ś pli­
22
ku nagłów kow ym . Z oczyw istego pow odu nie m oże to być board_def.h, bo nie
je st on w łączany przez pliki biblioteki STM 32. M ógłby to być plik stm 3 2 fl()_ c o n f
h, ale niestety je g o w łączenie je s t uzależnione od w cześniejszego zdefiniow ania
stałej USE_STDPERIPH_DRIVER, a p o nadto pozostałe dw ie stale są używ ane w pli­
ku slm 3 2 fl0 x.h jeszcze przed w łączeniem w nim pliku stm 3 2 fl0 _ c o n fh . Jedynym
rozw iązaniem je st zdefiniow anie tych trzech stałych ja k o argum entów kom pilatora,
ja k opisuję to w rozdziale 1.4. Ż eby je d n ak uniknąć niespójności w ich definicji, co
m oże pow odow ać błędne działanie program u, dobrze je st zw eryfikow ać te definicje
w pliku board_def.lv.
łifndef USE_STDPERIPH_DRIVER
łerror USE_STDPERIPH_DRIVER not defined
ffendif
iifndef STM32F10X_CL
fierror STM32F10X_CL not defined
ffendif
Iifndef HSE_VALUE
fierror HSE_VALUE not defined
ffendif
ffif HSE_VALUE != 10000000
terror ZL29ARM board uses 10 MHz external quarz,
tendif
N a koniec należy zw rócić uw agę, że w w ersjach Standard Peripherals Library star­
szych niż 3.2.0 stała HSE_VALUE nazyw ała się HSE_Value. T rzeba w tedy za pom ocą
argum entu kom pilatora zdefiniow ać w artość stałej HSE_Value, a przed pierw szym
użyciem HSE_VALUE dodać definicję:
łdefine HSE_VALUE HSE_Value
1.3.9.
!
Plik s tdinth
Plik stdint.h jest częścią standardow ej biblioteki języ k a C i znajduje się w k atalo ­
gu ze standardow ym i plikam i nagłów kow ym i. Standardow a biblioteka jest zw ykle
dostarczana razem z zestaw em narzędzi (ang. toolchain) lub środow iskiem progra­
m istycznym (IDE, ang. integrated d evelopm ent environm ent). W tej książce uży­
wam biblioteki N ew lib - popularnej im plem entacji standardow ej biblioteki C na
m ikrokontrolery. Plik stdint.h definiuje m.in. typy calkow itoliczbow e uniezależnia­
jące im plem entację od architektury procesora, np. typy: in t 8 _ t , u in t 8 _ t, i n t l 6 _ t ,
u i n t l 6 _ t , in t 3 2 _ t, u in t3 2 _ t. D efiniuje też m akra do obsługi tych typów. Potrzeba
takich definicji w ynika z tego, że ję z y k C pozostaw ia pew ną sw obodę je g o im plem entatorom co do rozm iarów poszczególnych typów. P rzykładow o typ i n t w archi­
tekturach 16-bitowych ma zw ykle 16 bitów, a w architekturach 32- i 64-bitow ych
- 32 bity. Z kolei typ lo n g w architekturach 16- i 32-bitow ych m a zw ykle 32 bity,
a w architekturach 64-bitow ych - 64 bity.
1.3.10.
Plik startup_stm32_cld.c
Plik startup_stm 32_cld.c znajduje się w katalogu ./exam ples/src i zaw iera definicję
w ektora przerw ań oraz przykładow ą procedurę startow ą, w ykonyw aną przed w y­
w ołaniem funkcji main program u. N ajpraw dopodobniej najlepszym rozw iązaniem
je st dołączenie do projektu pliku startow ego dostarczonego w raz z używ anym ze­
staw em narzędzi. Plik ten m a zw ykle nazw ę podobną do tej w tytule podrozdziału.
23
1.4. Kompilowanie przykładów
I. Podstawy
Przykłady plików startow ych dla różnych kom pilatorów , napisane w A sem blerze,
znajdują się w archiw um w katalogu Jst/L ibraries/C M SlS/C M 3/D eviceSupport/ST /
STM 32F 10x/startup. W ażne jest, aby użyć pliku w łaściw ego do zastosow anego m i­
krokontrolera. Pliki startow e dla ST M 32F107 m ają w końców ce nazw y litery cl
(ang. connectivity line). Poznanie zaw artości pliku z procedurą startow ą nie jest
konieczne do zrozum ienia zaw artości książki. Tym bardziej nie je s t w ym agana też
um iejętność pisania procedury startow ej. D la zainteresow anych opisuję te zagadnie­
nia w rozdziale 1.8.
1.4.
Kompilowanie przykładów
Zakładam , że C zytelnik m a ju ż ja k ie ś dośw iadczenie w program ow aniu m ikrokon­
trolerów A R M w języku C, m a zainstalow ane jak ieś ulubione środow isko progra­
m istyczne i um ie w nim skonfigurow ać projekt. D latego nie będę rozw odził się
na tem at instalow ania narzędzi program istycznych i ograniczę się do w yjaśnienia
ustaw ień kom pilatora i konsolidatora. W szystkie darm ow e zestaw y narzędzi i w iele
kom ercyjnych w ykorzystuje oprogram ow anie stw orzone w ram ach projektu G N U ,
czyli kom pilator C /C ++ z pakietu G C C (ang. G N U C om piler C ollection) oraz pa­
kiet G N U B inary U tilities, w skrócie nazyw any B inutils, zaw ierający konsolidalor
Id oraz inne pom ocnicze program y do m anipulow ania plikam i binarnym i, ja k np.
ar, objcopy, objdum p itd. D o kom pilow ania opisyw anych w tej książce przykładów
używ ałem w łaśnie tych narzędzi i dlatego ograniczam się tylko do opisu ich opcji.
Inne narzędzia m ają bardzo podobny zestaw opcji i C zytelnik z łatw ością dobierze
odpow iednie ustaw ienia. D la zw olenników program u m ake i kom pilow ania z linii
poleceń zam ieszczam w archiw um w katalogu ./m ake zestaw plików m akefile - za­
w artość tego katalogu opisuję w dodatku.
W środow isku program istycznym trzeba ustaw ić katalog ./exam ples/src jak o m iej­
sce, gdzie kom pilator m a szukać plików źródłow ych. Przypom inam , że je s t to
ścieżka w zględem m iejsca, gdzie zostało rozpakow ane archiw um z przykładam i. Tę
i w szystkie kolejne ścieżki trzeba dopasow ać do konkretnego system u.
P odstaw ow e opcje kom pilatora zam ieszczone są w tabeli 1.4. K ażdy plik źródłow y
języ k a C (jednostka translacji) kom pilujem y do binarnego pliku pośredniego, który
ma tę sam ą nazw ę, co odpow iedni plik źródłow y, a tylko rozszerzenie zm ienione
z c na o. Z pew nością w arto w łączyć w ypisyw anie przez kom pilator w szystkich
ostrzeżeń, no i oczyw iście należy czytać te ostrzeżenia. Sam fakt, że program się
skom pilow ał, nie daje żadnej gw arancji je g o popraw ności. U w ażna analiza każdego
ostrzeżenia i zastanow ienie się nad przyczyną, dla której kom pilator je w ypisał,
m oże uchronić przed w ielogodzinnym poszukiw aniem błędu w program ie. D obry
styl program ow ania to m iędzy innym i dbanie o to, aby w raporcie kom pilacji nie
Tab. 1.4. Podstawowe opcje kompilatora
Znaczenie
Opcja
-c
Tylko kompilacja do pliku pośredniego (z rozszerzeniem o)
-Wa 1.1
Włączenie generowania wszystkich ostrzeżeń
-g
Włączenie informacji dla debuggera
-mcpu=cortex-m3
W ybór architektury mikrokontrolera, rdzeń Cortex-M3
-mthumb
Zestaw instrukcji Thumb lub Thum b-2
24
1. Podstawy
Tab. 1.6. Miejsca poszukiwania plików nagłówkowych
Tab. 1.5. Opcje kompilatora sterujące optymalizacją
Znaczenie
Opcja
-oo
25
1.4. Kompilowanie przykładów
Wyłączenie wszelkich optymalizacji
-Os
Minimalizacja rozmiaru kodu wykonywalnego
oi io i o
Maksymalizacja szybkości wykonywania kodu, większe wartości oznaczają bardziej
agresywną optymalizację
-ffunction-sections
Każda funkcja w osobnej sekcji
-fdata-sections
Każda zmienna globalna i statyczna w osobnej sekcji
pojaw iały się żadne ostrzeżenia, oczyw iście nie przez w yłączenie ich w ypisyw ania.
K ażdy program da się tak napisać, aby kom pilator nie zgłaszał żadnych ostrzeżeń.
C o do pozostałych opcji, to z kodu w ynikow ego nie m usim y usuw ać inform acji dla
debuggera, bo nie są one zapisyw ane w pam ięci program u m ikrokontrolera - debugger je s t urucham iany na kom puterze, z którego w ykonuje się program ow anie
m ikrokontrolera. N iezbędne je s t w ybranie włas!ciw ej architektury m ikrokontrolera
i obsługiw anego zestaw u instrukcji. M ikrokontrolery z rdzeniem C ortex-M 3 w yko­
nują tyiko zestaw instrukcji T hum b-2.
B ardzo w ażne je s t w ybranie pożądanego poziom u optym alizacji kodu w ynikow ego.
K om pilator m a bardzo dużo szczegółow ych opcji sterujących procesem optym aliza­
cji. Z w ykle w ystarczy jed n ak w ybrać m iędzy m inim alizacją rozm iaru kodu w yko­
nyw alnego a szybkością je g o w ykonyw ania za pom ocą opcji z tabeli 1.5.
Panuje dość pow szechne przekonanie, że program ując m ikrokontrolery, należy pre­
ferow ać m inim alizację rozm iaru kodu w ynikow ego. T rzeba jednak pam iętać, że p o ­
szczególne w arianty optym alizacji nie są całkiem niezależne. M niejszy kod na ogól
w ykonuje się szybciej, dlatego zastosow anie opcji -Os w pływ a też na przyspiesze­
nie w ykonyw ania program u. Z drugiej strony, ustaw ienie jed n ej z opcji -0 1 , -02 lub
-03 w łącza rów nież te optym alizacje, które zm niejszają rozm iar kodu w ynikow ego
i nie spow alniają w ykonyw ania program u, zatem m oże rów nież przyczynić się do
zm niejszenia rozm iaru kodu w ynikow ego. C hoć oczyw iście niektóre optym aliza­
cje, takie ja k um ieszczanie ciała funkcji w m iejscu jej w yw ołania (ang. inline) czy
rozw ijanie pętli, istotnie zw iększają rozm iar kodu w ynikow ego. U w ażam , że d o p ó ­
ki rozm iar dostępnej pam ięci na to pozw ala, pow inniśm y optym alizow ać szybkość
w ykonyw ania program u. M inim alizow anie rozm iaru kodu jest uzasadnione, jeśli
pozw oli zastosow ać tańszy m odel m ikrokontrolera - z m niejszą pam ięcią lub jeśli
bez takiej m inim alizacji program nie m ieści się w najw iększej dostępnej w danej
rodzinie m ikrokontrolerów pam ięci. Z apew ne jed n ak najw ięcej pam ięci m ożna za­
oszczędzić przez w łaściw y do b ó r stru ktu r danych i algorytm ów .
Istotną redukcję rozm iaru kodu w ynikow ego m ożna też stosunkow o prosto osiąg­
nąć, nie rezygnując z optym alizacji szybkości w ykonyw ania. O kazuje się, że sporo
m iejsca w pam ięci program u zajm uje kod dołączanych bibliotek. K ażda biblioteka
zaw iera bardzo w iele użytecznych funkcji i zm iennych globalnych, z których nasz
program zw ykle w ykorzystuje tylko niew ielką część. Sam i piszem y też w łasne b i­
blioteki i nie zaw sze w yw ołujem y w szystkie zaim plem entow ane funkcje w każdym
projekcie. A by pozbyć się tego nieużyw anego kodu, m ożem y ustaw ić dw ie ostat­
nie opcje w ym ienione w tabeli 1.5, a następnie w fazie konsolidow ania program u
ustaw ić opcję odśm iecania (ang. garbage collector) - patrz tabela 1.9. U staw ienia
________________________ Param elry kompilatora
_______ __
-I./examples/include
-I ./examples/include/zl29arm+zl3eth
- I ./st/Libraries/STM32F10x_StdPeriph_Driver/inc
- I ./st/Librari.es/STM32_ETH__Driver/inc
- I ./st/Libraries/CMSIS/CM3/CoreSupport
- I ./st/Libraries/CMSIS/CM3/DeviceSupport/ST/STM32F10x
- I ./lwip-1.3,2/src/.tnclude
-I ./lwip-1.3.2/src/include/ipv'l________________________
Tab. 1.7. Stale konfigurujące bibliotekę STM32
Param etr kompilatora
-DUSE STDPERIPH DRIVER
Znaczenie
Użyj Standard Peripherals Library
-DSTM32F10X CL
Kompiluj dla STM 32F105 lub STM 32F107 (ang. connectivity line device)
-DIISE VALUE=10000000
Zainstalowany jest kwarc 10 MHz
te spraw iają, że kom pilator um ieści każdą funkcję i zm ienną globalną lub statyczną
w osobnej sekcji, a konsolidator spraw dzi, do których funkcji i zm iennych są odw yw ołania w tekście źródłow ym i pozostaw i w kodzie w ynikow ym tylko te funkcje
i zm ienne, które są rzeczyw iście w ykorzystyw ane. N ależy zaznaczyć, że uzyskanie
zadow alającego rezultatu w ym aga, aby w szystkie pliki źródłow e poddać tej opty­
m alizacji. D otyczy to rów nież bibliotek. S ą to, oprócz biblioteki STM 32, przede
w szystkim libc, czyliistandardow a biblioteka C oraz libm , czyli standardow a biblio­
teka funkcji m atem atycznych. Ponadto należy zadbać o zoptym alizow anie, dostar­
czanej w raz z G CC , niskopoziom ow ej biblioteki czasu w ykonania libgcc (ang. Iow
level runtim e library). W libgcc im plem entuje się konstrukcje języ k a C niew spierane bezpośrednio przez sprzęt - dla C ortex-M 3 jest to np. arytm etyka na typach,
które nie są w ym ienione w tabeli 1.2. N ieco w ięcej o kom pilow aniu tych bibliotek
piszę w dodatku. Przykłady zam ieszczone w tej książce i w szystkie biblioteki kom ­
pilow ałem z następującym i opcjam i optym alizacji:
-02 -ffunction-sections -fdata-sections
W tabeli 1.6 zam ieszczone są param etry kom pilatora ustaw iające nazwy katalogów,
w których należy poszukiw ać plików nagłów kow ych. Pierw szy w iersz konfiguruje
ścieżkę do katalogu, w którym znajduje się w iększość plików nagłów kow ych przy­
kładów . D rugi w iersz w tej tabeli to ścieżka do pliku bo a rd _ d efh . Jak napisałem
wyżej, przy om aw ianiu tego pliku, ścieżka ta m oże być inna i w skazyw ać na inny
plik b oard_def.h, konfigurujący inny w ariant sprzętu. K olejne cztery wiersze zaw ie­
rają ścieżki do plików nagłów kow ych biblioteki STM 32. O statnie dw a w iersze to
ścieżki do plików nagłów kow ych biblioteki lwIP. O m aw iam tę bibliotekę dopiero
w rozdziale 3, ale w arto m ieć zaw czasu ustaw ione w szystkie potrzebne ścieżki.
W rozdziale 1.3.8 napisałem , że biblioteka STM 32 w ym aga zdefiniow ania trzech
stałych preprocesora. O dpow iednie param etry kom pilatora, definiujące te stale, są
w ym ienione w tabeli 1.7. Param etry te m uszą być rów nież ustaw ione podczas kom ­
pilow ania plików źródłow ych w łączających plik board_ d e fh . N ajlepiej jest ustawić
je dla w szystkich plików źródłow ych przykładów , czyli w szystkich plików z kata­
logu Jexam ples/src.
26
I. Podstawy
Tab. 1.8. Katalogi z plikami źródłowymi biblioteki STIVI32
Jst/Ubraries/STM32F10x_StdPeriph_Driver/src
./stlLibrarieslSTM 32JTH_Driver/src
Jst/Libraries/CMSIS/CM3/CoreSupport
Jst/LibraneslCIVISIS/Cl/l3/DeviceSupport/ST/STM32F10x
Tab. 1.9. Opcje konsolidatora
Znaczenie
Opcja
-mcpu-cortex-m3
-mthumb
W ybór architektury mikrokontrolera
-nostartfiles
Wyłączenie domyślnego pliku z procedurą startową
-L./make/lib/7.129arm+zi3eth
Miejsce poszukiwania plików bibliotecznych
-L./examples/scripts
Miejsce poszukiwania skryptu konsolidatora
-Tstm32f107vc.Ids
Nazwa skryptu sterującego procesem konsolidacji
-Wl,— gc-secfcions
Uaktywnienie odśmiecania - usuwanie zbędnego kodu
A by utw orzyć bibliotekę Iib stm 3 2 fl0 x.a , trzeba skom pilow ać do odpow iednich
plików pośrednich z rozszerzeniem o w szystkie pliki źródłow e z rozszerzeniem c
z katalogów w ym ienionych w tabeli 1.8, a następnie połączyć je w jed en plik b i­
blioteczny. K ażde Środowisko program istyczne m ożna tak ustaw ić, aby w ynikiem
kom pilacji zam iast pliku w ykonyw alnego była biblioteka. M ożna to też zrobić z li­
nii poleceń za pom ocą program u ar, przykładow o:
arm-elf-ar -rcs Iibstm32fł0x.a *.o
O statnim etapem tw orzenia program u je s t konsolidacja. W tabeli 1.9 zaw arto opcje
w ykorzystyw ane przy łączeniu (konsolidow aniu, linjkowaniu) plików pośrednich
i bibliotek do pliku w ykonyw alnego. Zakładam , że konsolidalor nie je s t urucham ia­
ny bezpośrednio za pom ocą np. polecenia a nn-elf-ld, a poprzez kom pilator polece­
niem arm -elf-gcc. Taki sposób urucham iania konsolidatora je st w ygodniejszy, gdyż
jest w tedy autom atycznie dołączana standardow a biblioteka języ k a C. Podobnie ja k
podczas kom pilacji, trzeba w yspecyfikow ać architekturę m ikrokontrolera. Jeśli d o ­
łączam y nasz plik z procedurą startow ą, to trzeba w yłączyć dołączanie dom yślnej
procedury startow ej. M ożna też ustaw ić ścieżkę do m iejsca, gdzie poszukiw ane m ają
być nasze biblioteki, jeśli nie znajdują się w katalogu bieżącym . N a razie m am y tylko
jedną bibliotekę, czyli Iibstin32fl0x.a, ale w rozdziale 3 utw orzym y drugą z im ple­
m entacją stosu TCP/IP. K onsolidatorow i trzeba też podać nazw ę skryptu sterującego
procesem konsolidacji i ścieżkę do katalogu, gdzie m a poszukiw ać tego skryptu.
Najpraw dopodobniej najlepiej jest zdać się na skrypt konsolidatora dostarczony wraz
ze środow iskiem program istycznym . D la zainteresow anych zrozum ieniem , ja k dzia­
ła konsolidator, opisuję w rozdziale 1.8.3 prosty skrypt do architektury C ortex-M 3.
Aby skutecznie m inim alizow ać rozm iar generow anego program u, bardzo w ażne jest
też uaktyw nienie opcji odśm iecania w fazie konsolidacji.
1.5.
Wejścia i wyjścia binarne
M ikrokontroler S T M 32F 107 m a pięć, oznaczonych literam i od A do E, 16-bitow ych portów w ejścia-w yjścia. Jak w każdym m ikrokontrolerze, ich k o n fig u ro w a­
nie i dostęp do nich odbyw a się za pom ocą rejestrów w przestrzeni adresow ej
w ejść-w yjść. Jest to o pisane szczeg ó ło w o w [8 |. N ajw ażniejsze rejestry, z któ-
27
1.5. Wejścia i wyjścia binarne
rych będziem y korzystać, przestaw ione są na rysunku 1.3. D ane z wejść czyta
się z rejestru ID R (ang. input data register), który je s t rejestrem tylko do odczytu.
Stan w ejść znajduje się w m łodszych 16 bitach tego rejestru. Pozostałe bity nie
są używ ane. D ane w yjściow e zapisuje się do rejestru ODR (ang. output data regi­
ster). D ane zapisane do tego rejestru m ogą być rów nież odczytyw ane. K orzysta się
przy tym tylko z m łodszych 16 bitów rejestru. P ozostałe bity są zarezerw ow ane.
A tom ow e, nieprzeryw ane obsługą przerw ań, operacje na poszczególnych bitach
m ożna w ykonać za pom ocą rejestrów BRR (ang. bit reset register) i BS R R (ang. bit
set/reset register), które są rejestram i tylko do zapisu. Starszych 16 bitów rejestru
BRR nie używ a się. Z apisanie jed y n k i na bicie B R x rejestru BRR zeruje odpow ied­
ni bit O D R x w rejestrze O DR . Z apisanie jed y n k i na bicie B S x rejestru B S R R ustaw ia
odpow iedni bit O D R x w rejestrze O D R. Z apisanie jed y n k i na bicie B R x rejestru BSRR
zeruje odpow iedni bit O D R x w rejestrze O D R. Z apisyw anie zera na bitach B S x i B R x
nie zm ienia w artości bitów rejestru ODR. Jeśli w rejestrze B S R R oba bity B S x i B R x są
jed n o cz eśn ie zapisyw ane w artością 1, to pierw szeństw o m a bit B S x - odpow iedni
bit O D R x zostaje ustaw iony.
Tryb pracy portów w ejścia-w yjścia konfiguruje się za pom ocą rejestrów CRL (ang.
configuration register Iow) i CRH (ang. configuration register high). K ażde w ypro­
w adzenie m ożna skonfigurow ać indyw idualnie. D la każdego w yprow adzenia prze­
w idziano po cztery bity konfiguracyjne: CNFxl, CNFxO, MODExl, MODExO. R ejestr CRL
konfiguruje w yprow adzenia 0 ...7 , a CRH - w yprow adzenia 8 ...1 5 . D ostępne tryby
pracy portów w ejścia-w yjścia i odpow iadające im ustaw ienia bitów konfiguracyj­
nych zam ieszczone są w tabeli 1.10. N ależy zw rócić uw agę, że rezystory podciąga­
ją c e do zasilania i ściągające do m asy są ustaw iane za pom ocą rejestru ODR. W przy­
padku ustaw ienia funkcji alternatyw nej w yprow adzenie m oże być też dw ukierunko­
we (ang. bidirectional) - w tedy kierunkiem w yprow adzenia steruje w łaściw y uktad
peryferyjny. G dy w yprow adzenie je st ustaw ione w trybie w yjściow ym , bity MODExl
i MODExO określają m aksym alną częstotliw ość sygnału na w yjściu, przy obciążeniu
50 p F i założeniach, że w spółczynnik w ypełnienia sygnału w ynosi 4 5 -5 5 % , a cza­
sy narastania i opadania (m ierzone standardow o ja k o zm iana m iędzy 10% a 90%
poziom u w ysokiego) nie przekraczają w sum ie 2/3 okresu sygnału. U staw ienia tych
bitów podane są w tabeli 1.11.
Tab. 1.10. Tryby pracy portów wejścia-wyjścia
,
Tryb pracy
;jtópExif MODExO . CNFxl
CNFxO
0
0
0
0
Nieistotne
floating input
0
0
0
1
Nieistotne
pull-down input
0
0
1
0
0
pull-up input
0
0
1
0
1
0
0
0 lub 1
Nazwa anglelska
Wejście analogowe
analog input
Wejście pływające
(stan po resecie)
Wejście ściągane do masy
Wejście podciągane do zasilania
Wyjście przeciwsobne
Wyjście z otwartym drenem
push-pull output
open-drain output
Funkcja alternatywna,
wyjście przeciwsobne
alternate lunction pushpull output
Funkcja alternatywna,
wyjście z otwartym drenem
alternate function open-drain output
01
10
11
(patrz tabela
1.11)
ODRx ,
0
1
0 lub 1
1
0
Nieistotne
1
1
Nieistotne
I. Podstawy
28
30
31
2Q
29
26
27
25
24
23
22
21
20
19
18
17
16
Zarezerw ow ane
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
IDR15
IDR14
IDR13
IDR12
IDR11
IDR10
IDR9
!DR8
IDR7
IDR6
!DR5
IDR4
IDR3
IDR2
IDR1
IDRO
r
r
Tab. 1.11. Maksymalna częstotliwość sygnału wyjściowego
M0DExl
15
MODExO
1
30
31
28
29
26
27
24
25
23
22
20
21
19
18
17
16
Zarezerw ow ane
14
15
13
12
10
11
BRR
8
7
6
5
4
3
2
ODR8
O DR7
ODR6
O DR5
ODR4
O DR3
ODR2
ODR1
ODRO
9
ODR15 ODR14 ODR13 ODR12 ODR11 ODR10 ODR9
0
rw
rw
rw
rw
rw
rw
rw
rw
rw
rw
rw
rw
rw
rw
rw
rw
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
BR15
BR14
BR13
BR 12
BR11
BR10
BR9
BR8
BR7
BR6
BR5
BR4
BR3
BR2
BR1
BR0
w
w
w
w
w
w
w
w
w
w
w
w
w
w
w
W
Z a rezerw ow ane
0
Częstotliwość
10 MHz
0
r
r
29
1.5. Wejścia i wyjścia binarne
0
2 MHz
1
50 MHz
Z w ykle dużo w ygodniejsze je s t konfigurow anie portów w ejścia-w yjścia za pom ocą
funkcji bibliotecznej niż operow anie bezpośrednio na rejestrach C R L i CRH. W celu
w ygodnego konfigurow ania portów biblioteka STM 32 dostarcza strukturę typu
G P IO _InitT ypeD ef.
typedef struct {
uintl6_t
GPIG^Pin;
GPIOSpeed_TypeDef GPIO_Speed;
GPIOMode_TypeDef GPIOJtode;
) GPIO_IniŁTypeDef;
Jak o w artość składow ej GPI0_Pin podaje się m askę bitow ą w yprow adzeń, które są
konfigurow ane. N ajlepiej je s t używ ać alternatyw y następujących stałych, zdefinio­
w anych w bibliotece STM 32.
idefine GPIO_Pin_0
idefine GPIO_Pin__l
idefine GPI0_Pin_2
(£uintl6_t)0x0001)
((uintl6_t) 0x0002)
£ (uin 1 16__t) 0x0004)
Idefine GPI0_Pin_15 £ (Uintl6_t) 0x8000)
idefine GPIO_Pin_All ((uintl6_t) 0xFFFF)
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
BR15
BR14
BR13
BR12
BR11
BR10
BR9
BR8
BR7
BR6
BR5
BR4
BR3
BR2
BR1
BR0
W
w
w
w
w
w
w
w
w
w
w
w
w
w
w
w
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
BS15
BS14
BS13
BS12
BS11
BS10
BS9
BS8
BS7
BS6
BS5
BS4
BS3
BS2
BS1
BSO
w
w
w
w
w
w
w
w
w
w
w
w
w
w
w
W
31
30
CNF7[1:0|
rw
rw
14
15
CNF3|1:0]
CRH
rw
rw
31
30
CNF15£1:0j
rw
[
15
rw
14
CNF11[1 :QJ
rw
|
rw
28
29
MODE7(1:0]
26
27
CNF6(1:0j
rw
rw
rw
12
13
MODE3[1:0]
11
10
rw
rw
rw
rw
29
26
27
26
rw
MODE15[1:Oj
rw
13
|
rw
12
MODE11[1:0J
rw
rw
CNF2[1:0]
CNF14£1:0]
rw
11
j
rw
8
9
MODE2(1:0]
rw
rw
25
24
MODE14[1:0]
rw
10
9
rw
24
rw
rw
CNF10£1:0]
rw
25
MODE6[1:0]
i
Rys. 1.3. Podstawowe rejestry portów wejścia-wyjścia
20
21
MODE5[1:0j
19
18
CNF4[1:0]
rw
rw
rw
rw
rw
rw
7
6
5
4
3
2
CNF1(1:0]
rw
rw
23
22
CNF 13f 1:0]
rw
8
7
rw
22
CNF5{1:0!
rw
MODE10[1:0J
rw
23
I
rw
rw
21
20
MODE13f1:QJ
rw
rw
6
5
CNF9(1:0J
rw
MODE1[1:0|
rw
|
rw
rw
19
18
CNF12]1:0]
rw
rw
4
3
MODE9{1:OJ
rw
CNF0(1:0)
rw
|
rw
rw
rw
rw
17
16
MODE12[1;0]
rw
2
1
rw
rw
0
MODE0{1;0]
rw
CNF8[1;0]
16
17
MODE4(1:0}
|
rw
typedef enum {
GPIO_Speed_10MHz - 1,
GPIO_Speed_2MHz,
GPIO~Speed_50MHz
} GPIOSpeed_TypeDef;
Składow a GPIO_Mode określa tryb pracy w yprow adzenia. Stale reprezentujące po­
szczególne tryby pracy zdefiniow ano w bibliotece ST M 32 jak o typ w yliczeniow y
GPIOMode_TypeDef. N azw y poszczególnych trybów jednoznacznie je identyfikują,
a dodatkow o dla klarow ności kolejność definicji na poniższym w ydruku odpow iada
kolejności opisów w tabeli 1.10.
typedef enum {
GPIO__Mode_AIN
GPIO_Mode_IN_FŁOATING
GprO_Mode_IPD
GPIO_Mode_IPU
GPI0J4ode_0ut_PP
GPI0_Mode_0ut_0D
G PI0~Mode_AF_P P
GPI0J4ode_AF_0D
GPIOMode_TypeDef;
0x0,
0x04,
0x28,
0x48,
0x10,
0x14,
= 0x18,
“ 0xlC
=
=
=
=
0
MODE8[1:0]
rw
Składow a GPIO_Speed określa m aksym alną „prędkość” pracy wyprowadzenia.
D opuszczalne wartości zdefiniow ane są jako typ w yliczeniow y GPIOSpeed_TypeDef.
j
rw
A by skonfigurow ać w yprow adzenia portu, należy zainicjow ać strukturę typu
GPIOMode_TypeDef i w yw ołać funkcję G P I0 _ In it, przekazując jak o jej param etry
nazw ę portu i adres tej struktury, ja k przedstaw iono to w rozdziale 1.3.3. Do zmie-
1. Podstawy
30
niania stanu w yjść oraz czytania stanu w ejść i w yjść biblioteka S T M 32 udostępnia
następujące funkcje.
uintl6_t
uint8__t
uintl6_Ł
uint8_t
void
void
void
void
GPIO_ReadInputData(GPIO_TypeDef *GPI0x);
GPIO_ReadInputDataBit(GPIG_TypeDe£ *GPI0x, uintl6_t GPI0_Pirt);
GPIO_ReadOutputData{GPIO_TypeDef *GPI0x);
GPIO_ReadOutputDataBit(GPIO_TypeDef *GPI0x, uintl6_t GPI0_Pin);
GPIO_ResetBits(GPIOJTypeDef *GPlOx, uint!6_t GPIO_Pin};
GPIO_SetBits(GPIOJTypeDef *GPX0xf uintl6_t GPIO_Pin);
GPIO_Wrifce(GPIOJTypeDef *GPI0x, uint!6_t PortVai);
GPI0_WriteBit(GPIOJTypeDef *GPlOx, uintl6_t GPICJPin,
BitAction BitVal);
N azw y tych funkcji są sam otłum aczące się. P aram etr GPIOx musi w skazyw ać port
w ejścia-w yjścia i przyjm uje je d n ą z w artości GPIOA, GPIOB, GPI0C itd. P aram etr
GPI0_Pin to m aska bitow a określająca w yprow adzenia - najlepiej je s t stosow ać
alternatyw ę opisanych w yżej stałych G PI0_Pin_x, gdzie x je st num erem w yprow a­
dzenia. Funkcje G P IO _R eadInputD ataB it i G PIO _R eadO utputD ataBit zw racają 1,
gdy odpow iednio co najm niej jed n o z w yspecyfikow anych w ejść lub w yjść ma stan
w ysoki. Funkcja GPIO__WriteBit pow inna w łaściw ie nazyw ać się GPIO_Wri.teBi.ts,
gdyż um ożliw ia jed n o czesn e w yzerow anie lub ustaw ienie w szystkich bitów w yspe­
cyfikow anych za pom ocą param etru G PI0_Pin. P aram etr B itV a l przyjm uje w artość
Bit_RESET lub Bi.t_SET, ja k to ju ż w idzieliśm y w rozdziale 1.3.3. B iblioteka ST M 32
nie dostarcza niestety atom ow ej (niepodzielnej) operacji, pozw alającej jed n o cześn ie
na w yzerow anie pew nych bitów i ustaw ianie innych. Taka operacja będzie nam
potrzebna w następnym przykładzie i tam opiszę jej im plem entację.
1.6.
Wyświetlacz ciekłokrystaliczny
W kilku przykładach w ykorzystuję w yśw ietlacz ciekłokrystaliczny (L C D , ang. liq­
uid crystal display). Z astosow ałem w yśw ietlacz graficzny typu W G 12864A z m a­
trycą m onochrom atyczną szerokości 128 i w ysokości 64 pikseli. W yśw ietlacz ten
zbudow any je s t w oparciu o dw a sterow niki kom patybilne z układem K S0108.
Pojedynczy sterow nik obsługuje połów kę w yśw ietlacza, czyli fragm ent obrazu 64
na 64 piksele. O rganizację je g o pam ięci obrazu pokazano na rysunku 1.4. Pam ięć
obrazu je s t podzielona na 8 bloków po 64 bajty każdy. W dokum entacji w yśw ietla­
cza bloki nazyw ane są stronam i (ang. pa g e), co w odniesieniu do w yśw ietlaczy w y­
daje mi się bardzo m ylące. Każdy blok odpow iada za w yśw ietlanie jed n eg o w iersza
składającego się z 8 linii. Pojedynczy bajt w bloku steruje w yśw ietlaniem kolum ny
składającej się z 8 pikseli. Jeśli bit je s t ustaw iony, to piksel je s t ciem ny, a w prze­
ciw nym przypadku - jasny. Są też produkow ane m odele w yśw ietlaczy, w których
je s t odw rotnie - obraz jest w yśw ietlany w negatyw ie. N ajm niej znaczący bit odpo­
w iada pikselow i w górnej linii w iersza, a najbardziej znaczący - dolnej. S terow nik
przechow uje trzy zm ienne (adresy). X je st adresem (num erem ) bieżącego wiersza.
Y je s t adresem (num erem ) kolum ny. Z je st num erem linii (a nie w iersza), która
je s t w yśw ietlana ja k o pierw sza na g órze ekranu. Z m ienna Z um ożliw ia realizację
przew ijania obrazu, ale nie będziem y z tego korzystać w przykładach. Z apis i o d ­
czyt pam ięci obrazu zaw sze dotyczy bajtu w skazyw anego przez zm ienne X i Y. Po
zapisie lub odczycie adres Y je s t autom atycznie zw iększany o jeden.
31
1.6. Wyświetlacz ciekłokrystaliczny
- adres bloku (wiersza)
i— Num er bitu
Z - adres pierwszej wyświetlanej llnll —
Y - adres k o lu m n y ____
* 0 1
63
’ LSB 0
—
1
2
3
4
5
Blok 0
6
.M SB 7
’ LSB 0
1
2
3
4
5
6
.M SB 7
Blok 1
_
15
• LSB 0
1
2
3
4
5
Blok 7
6
63
.M SB 7
Rys. 1.4. Organizacja pamięci obrazu LCD
W yśw ietlacz W G 12864A podłącza się w zestaw ie Z L29A R M do złącza 20-stykow ego. T rzeba też pam iętać o przestaw ieniu zw orki D ISPLAY w pozycję G R A PII.
Schem at pokazujący podłączenie poszczególnych w yprow adzeń w yśw ietlacza do
w yprow adzeń m ikrokontrolera je s t przedstaw iony na rysunku 1.5. W yśw ietlacz
S TM 32F107V C
PEO
PE1
Y:PE 2
ÍÍÍP É 3
Y PE4
n:P E 5
PE6
PE7
PE8
Y PE9
PE10
PE11
PE12
nRST
LCD
98
1
2
3
4
5
38
0
9
10
11
12
13
14
DO
D1
D2
D3
D4
D5
D6
D7
39
40
41
42
43
14 .
4
6
5
15
16
17
RS
E
R /ffl
CS1
CS2
-
Rys. 1.5. Schemat podłączenia LCD
2'
VEE
R5T
-0 + 5 V
18
LEDA
LEDK
D IS P L A Y
JP 3
□
|
VO
^ RESET
i
VSS
VDD
10k
GRAPH
CHAR
/. Podstawy
32
Tab. 1.12. Polecenia sterownika KS0108
s 1000 ms
£ 450 ms
RS
^ 450 ms
0
J
S 140 ms
> 10 ms
R /W W i
D6
0
D5
D4
D3
1
1
1
1
1
1
D2
0
0
0
0
0
1
0
0
1
0
0
0
1
1
0
1
B
0
1
0
zapisywany bajt
1
1
odczytany bajt
DO
D1
1
1
C
Y
Ustaw adres bloku, numer wiersza X
Ustaw numer początkowej linii Z
Z
”\ r
D 0-7
Rys. 1.6. Cykl zapisu LCD
___________ a 1000 ms_____________
R
0
0
0
0
Czytaj status:
B = 0 - gotowy, B = 1 - zajęty,
C = 0 - wyświetlanie włączone, C = 1 - wyłączone,
R = 0 - aktywny, R = 1 - w trakcie zerowania
Zapisz bajt do pamięci obrazu
Czytaj bajt z pamięci obrazu
W tabeli 1.12 zestaw ione są polecenia w ykonyw ane przez sterow nik w yśw ietlacza.
Pierw sze polecenie w łącza i w yłącza w yśw ietlanie. D ane z pam ięci obrazu są prze­
syłane na ekran dopiero po w łączeniu w yśw ietlania. K olejne trzy polecenia usta­
w iają w artości adresów X, Y i Z. P rzedostatnie polecenie zapisuje dane do pam ięci
obrazu. O statnie polecenie odczytuje dane z pam ięci obrazu. Po w ydaniu każdego
z w ym ienionych w yżej poleceń sterow nik zm ienia status na zajęty. Przed w ysia­
niem kolejnego z tych poleceń trzeba poczekać, aż sterow nik pow róci do stanu
gotowy. Stan sterow nika spraw dza się za pom ocą polecenia Czytaj status. Podczas
operacji zapisu (bit R /W w yzerow any) linie danych D 0 ...D 7 po stronie m ikrokon­
trolera m uszą być ustaw ione jak o w yjścia, a podczas odczytu (bit R/W ustaw iony)
- ja k o wejścia.
DL
W G 12864A kom unikuje się z m ikrokontrolerem za pom ocą interfejsu rów noleg­
łego, który m a osiem dw ukierunkow ych linii danych D 0 ...D 7 , linię RS w yboru
m iędzy transm isją danych a w ysyłaniem kom endy lub odczytem statusu, linię w y­
boru zapisu lub odczytu R /W , linię zezw olenia E (ang. enable) oraz linię zerow ania
R ST. Zaw iera też linie w yboru sterow nika CS1 i C S2 (ang. chip select), na których
stanem aktyw nym je s t stan w ysoki. N a rysunku 1.6 pokazano cykl zapisu oraz
zależności czasow e podane w nocie katalogow ej sterow nika K S0108, a na rysu n ­
ku 1.7 - cykl odczytu.
C
Opis
C = 0 - wyłącz wyświetlanie,
C = 1 - włącz wyświetlanie
Ustaw adres kolumny Y
X
R/W
CS1, CS2 r
RS
33
1.7. Przykład Ib - test wyświetlacza ciekłokrystalicznego
1.7.
Przykład 1 b - test wyświetlacza
ciekłokrystalicznego
a 450 ms
> 140 ms
a 10 ms
R/W
Przykład ten dem onstruje użycie opisanego w poprzednim podrozdziale graficzne­
go w yśw ietlacza ciekłokrystalicznego. W tabeli 1.13 zaw arto nazw y plików, które
należy podać kom pilatorow i jak o pliki źródłow e tego przykładu. Ponadto zaw iera
nazw y tych plików nagłów kow ych w ykorzystyw anych w tym przykładzie, które
znajdują się w podkatalogu ./exam ples/include. W kolejnych podrozdziałach opisuję
zaw artość poszczególnych plików. Z arów no w tym , jaki i w kolejnych przykładach
nie opisuję plików, które opisałem ju ż poprzednio.
Tab. 1.13. Pliki przykładu 1b
CS1, CS2 '
RS
ł
Źródłowe I biblioteczne
_ A _
,a 20 ms
e x jc d .c
fonl5x8.c
startup _ s tm 3 2 jtld .c
board_lcd_ks0108.c
Sont5x8.h
b o a rd jle ł.h
board_defs.h
board Icd.h
u tiljlelay .c
utilJod . c
Ilbstm32f10x.a
Nagłówkowe
D 0-7
Rys. 1.7. Cykl odczytu LCD
-v/—
uliljdelay.h
u liljc d .li
stm 32HOx_conl.h
I. Podstawy
34
1.7. Przykład Ib - test wyświetlacza ciekłokrystalicznego
Pliki boardJ c d .h i board_lcd_ks0108.c
szego w yprow adzenia definiujem y jak o stałą D 0 _ S H IF T . O dpow iednie definicje dla
Z L 29A R M są następujące:
Plik boctrdJlcd.h znajduje się w katalogu ./exam ples/include. D efiniuje on prosty
interfejs program istyczny do obsługi w yśw ietlacza w trybie tekstow ym . Interfejs
len z założenia m a być niezależny od zastosow anego w yśw ietlacza i każdy typ w y­
św ietlacza pow inien bez problem u m óc go zrealizow ać. O czyw iście poszczególne
typy w yśw ietlaczy będą różnić się liczbą w ypisyw anych w ierszy tekstu i liczbą zna­
ków w w ierszu. N a opisanym w ro zdziale 1.6 w yśw ietlaczu będziem y w ypisyw ać 8
w ierszy tekstu po 21 znaków w w ierszu. Interfejs, zdefiniow any w pliku board J c d .
/?, udostępnia tylko bardzo skrom ny zestaw funkcji:
void
void
void
void
void
łdefine DATA_PORT GPIOE
łdefine D0_D7 (GPIO_Pin_0 | GPIO_Pin_l | GPI0_Pin_2 | \
GPI0_Pin_3 | GPIcfpinj! | GPI0_Pln_5 | \
GPI0_Pin_6 | GPI0J>in_7)
łdefine D0_SHIFT 0
O dczytyw anie danych nie nastręcza żadnych problem ów . Im plem entujem y prostą
funkcję, korzystającą z rejestru ID R (ang. input data register):
static uint8_t Dataln(void) |
return (DATA_PORT->IDR s D0_D7) »
D0_SHIFT;
1
LCDconfigure(void);
LCDciear(void);
LCDgoto{int textLine, int charPos);
LCDputchar(char c);
LCDputcharWrap(char c ) ;
U życie rejestru ODR (ang. output data register) w celu zapisyw ania danych w yda­
je się naturalnym pom ysłem . S ytuacja nie je s t jed n ak tak prosta, ja k przy odczy­
cie. M odyfikujem y tyiko 8 bitów portu, a pozostałe m ogą być używ ane przez inne
urządzenia. N ajpierw należy odczytać aktualną zaw artość rejestru ODR, a następnie
zm odyfikow ać w łaściw e bity i zapisać now ą w artość. Z auw ażm y jednak, że taka
sekw encja nie jest atom ow a. Potencjalnie m iędzy odczytem w artości ODR a zapi­
sem now ej m oże zostać zgłoszone przerw anie. Jeśli w trakcie je g o obsługi m ody­
fikow ane są inne bity rejestru ODR tego sam ego portu, to m am y pow ażny problem
- nasz program nadpisze m odyfikacje w ykonane w procedurze obsługi przerw ania.
R ozw iązaniem je s t w ykorzystanie rejestru B S R R (ang. b it set/reset register), który
zapew ni atom ow ość operacji m odyfikow ania bitów. F unkcja zapisująca dane w y­
gląda następująco:
Jak nazw a w skazuje, funkcja LC D configure inicjuje w yśw ietlacz. M usi ona zostać
w yw ołana, zanim zostanie w yw ołana jak ak o lw iek inna funkcja odw ołująca się do
w yśw ietlacza. Funkcja LCDciear czyści (zeruje) zaw artość pam ięci obrazu. Funkcja
LCDgoto ustaw ia bieżącą pozycję znaku (kursora), ale żaden znak kursora nie je st
w yśw ietlany. Funkcje LCDputchar i LCDputcharWrap w ypisują w pozycji kursora
znak o podanym kodzie A SCII i przesuw ają kursor o jed en znak w praw o. R óżnią
się tym , że jeśli znak nie m ieści się ju ż w w ierszu, to funkcja LCDputcharWrap prze­
suw a kursor na początek kolejnego w iersza (zaw ija w iersz) i tam w ypisuje podany
znak. N atom iast funkcja LCDputchar traktuje wienjz, jak b y byl bardzo długi, ale
tekst niem ieszczący się w w ierszu je s t ignorowany.
łdefine SET_BITS!x)
łdefine CLR_BITS(x)
P lik boardJ c d J c s O l 0 8 .c zn a jd u je się w k atalo g u ./exa m p le s/src. Z aw iera on
im p lem en tację p rzed sta w io n y ch w yżej funkcji d la w y św ietlaczy ze ste ro w n i­
kam i k o m p aty b iln y m i z u k ład em K S 0108 i u k ry w a w szy stk ie sz czeg ó ły im ­
p lem en tacji sp ec y fic z n e d la teg o stero w n ik a. D zięki tak iem u p o d ejściu , chcąc
zastosow ać inny typ w y św ie tla cz a , nie trzeb a m o d y fik o w ać w ielu plik ó w p ro ­
gram u - w y starczy tylk o z m o d y fik o w a ć ten p lik lub p o d m ien ić go na inny, im ­
p lem en tu jący taki sam in terfe js d la p o siad an eg o typu w y św ie tla c z a. D lateg o nie
o p isu ję w szy stk ich szczeg ó łó w im p le m e n ta cji, z w łaszcza że o b słu g a w y św ie tla ­
cza nie je s t g łó w n y m tem atem tej k siążk i. S k u p iam się tylk o na ty m , co w yd aje
mi się ciekaw e, a C zy teln ik z aw sz e m o że zajrze ć d o arch iw u m , g d z ie z n ajd u je
się pełny tekst źró d ło w y tego p rz y k ła d u i g d zie zam ie śc iłe m też d o d atk o w e k o ­
m entarze.
B iblioteka ST M 32 nie dostarcza w ygodnych funkcji do operow ania na dw ukierunkow ych liniach danych. W szczególności struktura G PIO _InitTypeD ef i funkcja
G P IO _Init są co praw da bardzo w ygodne do konfigurow ania w yprow adzeń, ale ta
w ygoda okupiona je s t dodatkow ym narzutem czasow ym - aby obsłużyć w szystkie
przypadki, im plem entacja tej funkcji je s t stosunkow o skom plikow ana. Przy pew ­
nych założeniach upraszczających m ożna to zrobić bardziej efektyw nie. Załóżm y,
że w yprow adzenia danych w yśw ietlacza rozm ieszczone są po kolei na w spólnym
porcie. D efiniujem y identyfikator portu DATA_PORT, do którego podłączone są linie
danych w yśw ietlacza, i m askę bitow ą D0 D7 dla tych w yprow adzeń. Pozycję pierw ­
35
((uint32_t)(x))
((uint32_t)(x) «
16)
static void DataOut(uint8_t x) (
DATA_PORT->BSRR = CLRJ3ITS (~ ( (ulnt32_t) X «
SET~BITS( {(uint32_t)X «
D0_SIIIFT) S D0_D7) |
D0_SHIFT) « D0_D7);
)
Pozostało jeszcze zaim plem entow anie operacji zm iany kierunku w yprow adzeń. Tu
niestety nie uda się zapew nić alom ow ości tej operacji i trzeba uw ażać, aby uniknąć
konkurencyjnych zm ian, skutkujących niedeterm inislycznym zachow aniem się pro­
gram u. D odatkow y problem przy rekonfiguracji portu spraw ia konieczność odw o­
ływ ania się do dw óch rejestrów , a m ianow icie do C R L (ang. configuration register
Iow) i CRH (ang. configuration register high). F unkcje przełączające w yprow adzenia
danych w tryb w ejściow y i w yjściow y w yglądają tak:
!s
k
i
¡j:
static void DataLinesIn(void) (
uint32_t r;
DATA_PORT->BSRR = SET_BXTS(DQ_D7);
lif D0_SHIFT < 8
r - DATA__PORT->CRL;
r &= ~(OxffffffffU « (4 * D0_SHIFT));
r i=
0x88888888U « (4 * D0_SHIFT);
DATA_PORT->CRL = r;
lehdif
fif D0_SHIFT > 0
r = DATA PORT->CRH;
I. Podstawy
36
r &= ~(Oxff£f£fffU »
r (=
0x88888S88U »
DATA_PORT->CRH “ r;
łendi£
(32 - 4 * DO_SHIFT));
(32 - 4 * DO_SHIFT);
static void DataLinesOut(void)
uint32_t r;
#i£ D0_SHIFT < 8
r = DATA_PORT->CRL;
r s= ~(0xf££££f££U «
r |=
OxlinilllU «
DATA_PORT->CRL = r;
iendif
łif D0_SHIFT > 0
r = DATA_PORT->CRH;
r s= ~(0xff£ff££fU »
r |=
OxlllllillU »
DATA_PORT->CRH = r;
iendif
1.7. Przykład Ib - test wyświetlacza ciekłokrystalicznego
P odobną staranność należy też w ykazać podczas konfigurow ania wyjść. Początkow y
stan w yprow adzenia m ożna ustaw ić, zanim to w yprow adzenie zostanie ustaw ione
w tryb w yjściowy. W ięcej o tym m ożna przeczytać w kom entarzach w pliku b o ­
ard _lcd_ksOJ 08. c.
Z apew ne w arto byłoby rozszerzyć przedstaw iony w tym podrozdziale interfejs pro­
gram istyczny w yśw ietlacza np, o funkcje udostępniające inform acje, ile wierszy
i ile znaków w w ierszu m oże być w yśw ietlonych. Taką rozbudow ę pozostaw iam
C zytelnikow i jak o ćw iczenie.
(
(4 * D0_SHIFT));
(4 * D0_SHIFT);
1.7.2.
(łdefine FIRST_CIIAR 32
łdefine LAST_CHAR 126
łdefine CHAR_WIDTH 5
extern const char £ont5x8(LAST_CHAR - FIRST_CHAR + 1 1 (CHAR_WIDTH];
)
Z rozum ienie pow yższego fragm entu program u w ym aga ponow nego spojrzenia na
rysunek 1.3 oraz tabele 1.10 i 1.11. Stała 0x88888888U oznacza ustaw ienie w ypro­
w adzeń w trybie w ejściow ym z rezystorem podciągającym do zasilania lub ścią­
gającym do masy. Przed przełączeniem w yprow adzeń w tryb w ejściow y, ustaw ia­
my je w stan w ysoki (za pom ocą B S R R ), co spraw ia, że po przełączeniu będą
ustaw ione rezystory podciągające. D zięki tem u unikam y stanów nieustalonych na
w yprow adzeniach. Stała O x l l l l l i l l U oznacza ustaw ienie w yprow adzeń w trybie
w yjściow ym przeciw sobnym 10 M H z. Przy przełączaniu kierunku w yprow adzeń
pew nej uw agi w ym aga też w łaściw a kolejność zm ian kierunku i sygnału na linii
R /W , którą sterujem y za pom ocą poniższej funkcji:
Plik fo n t5 x 8 .c znajduje się w katalogu Jexam ples/src i zaw iera definicje wzorów
bitow ych poszczególnych znaków. Pojedynczy bajt definiuje jedną kolum nę znaku.
N ajbardziej znaczący bit je st na dole, a najm niej znaczący - na górze. K olejne bajty
definiują kolum ny od lewej do praw ej.
const char font5x8[LAST_CHAR - FIRST_CHAR + 1 ] [CHARJIIDTHI = (
(0x00, 0x00, 0x00, 0x00, 0x00], /* spacja */
(0x00, 0x00, Qx5F, 0x00, 0x00}, /* ! */
(0x00, 0x07, 0x00, 0x07, 0x00}, /* " */
(0x10,
R W (0);
/* Najpierw wystaw sygnał WRITE. */
DataLinesOut(); /* Potem ustaw jako wyjścia. */
/* ~ */
N iew ątpliw ie w arto byłoby mieć m ożliw ość w yśw ietlania polskich liter ze znakam i
diakrytycznym i, czyli ą, ę, ć itd. N ajprościej jest uzupełnić pow yższą tablicę o zna­
ki kodow ane zgodnie z norm ą ISO /IEC 8859-2. Jak w poprzednim podrozdziale,
takie rozszerzenie zbioru w yśw ietlanych znaków pozostaw iam C zytelnikow i jak o
ćw iczenie.
static void RW(int x) (
if (x)
CTRL_P0RT->BSRR = RW_LINE;
else
CTRL_P0RT->BRR = RW_LINE;
/* Najpierw ustaw jako wejścia. */
/* Potem wystaw sygnał READ. */
0x08, 0x08, 0x10, 0x08}
};
łdefine CTM,_P0RT GPI0E
łdefine RW_LINE
GPIO_Pin_10
DataLinesIn();
RW(1);
Pliki font5x8.h i font5x8.c
W yśw ietlacz W G 12864A nie m a w budow anego generatora znaków. Trzeba je ge­
nerow ać program ow o. Plik fo n t5 x8 .h znajduje się w katalogu ./exam ples/include.
D eklaruje on tablicę fo n t5 x 8 w zorów bitow ych znaków o kodach A SC II od FIRST_
CHAR (spacja) do LAST_CHAR (tylda). W zory znaków m ają w ysokość 8 pikseli i sze­
rokość CHAR_WIDTH pikseli.
(32 - 4 * D0_SHIFT));
(32 - 4 * D0_SHIFT);
I
W arto zaznaczyć, że dobry ko m p ilato r potrafi rozw inąć funkcję RW w m iejscu jej
w yw ołania i zoptym alizow ać instrukcje w arunkow e, jeśli argum ent tej funkcji je st
stalą. K olejność zm ian kierunku w yprow adzeń i sygnału R /W pow inna uniem oż­
liwić sytuację, gdy linie danych są ustaw ione w tryb w yjściow y jednocześnie w
w ięcej niż jed n y m układzie do nich podłączonym . W łaściw e sekw encje przełączeń
są następujące:
37
.7.3.
Pliki u tiljc d .h i u tiljc d .c
Plik u ti lj c d .c znajduje się w katalogu ./exam ples/src, a odpow iadający mu plik
nagłów kow y u tiljc d .h - w katalogu ./exam ples/include. Pliki te udostępniają cztery
przydatne w ysokopoziom ow e funkcje ogólnego przeznaczenia:
void
void
void
void
LCDwrite(const char *s);
LCDwriteWrap(const char *s);
LCDwriteLen(const char *s, unsigned n);
LCDwriteLenWrap(const char *s, unsigned n);
F unkcje te korzystają z niskopoziom ow ego interfejsu zdefiniow anego w pliku b o­
a r d J e d .h , dzięki czem u ich im plem entacja nie zależy od konkretnego m odelu w y­
św ietlacza. Pierw sze dw ie funkcje w ypisują ciąg znaków zakończony term inalnym
I. Podstawy
38
1.8. Organizacja pam ięci programu
39
FLASH
zerem (tak zw ykle kończą się napisy w C), z tym że druga zaw ija tekst, jeśli nie
mieści się w w ierszu. K olejne dw ie funkcje służą do w ypisyw ania ciągu znaków
niezakończonych term inalnym zerem . T rzeba w tedy jak o drugi argum ent podać
liczbę znaków do w ypisania. A nalogicznie druga z tych funkcji zaw ija zbyt długi
tekst.
Jeśli, ja k to zaproponow ałem w poprzednim podrozdziale, utw orzym y tablicę zna­
ków w edług norm y 1SO/IEC 8859-2, to przedstaw ione w tym podrozdziale funkcje
bez żadnych m odyfikacji będą m ogły ich używ ać. N ieco bardziej am bitnym ćw i­
czeniem je s t dodanie, choćby w ograniczonym zakresie, w ypisyw ania ciągu zna­
ków w kodow aniu UTF-8.
sidata = etext
1.7.4.
Plik e x jc d .c
Plik e x j c d .c znajduje się w katalogu ./exam ples/src. D em onstruje on użycie niektó­
rych z w yżej opisanych funkcji. W nieskończonej pętli w yśw ietlane są na przem ian
dw a testy. Pierw szy test w ypisuje m .in. w szystkie znaki zdefiniow ane w pliku fo n t5x8.c. Drugi testuje przem ieszczanie kursora po ekranie i zaw ijanie tekstu.
1.8.
Organizacja pamięci programu
W tym podrozdziale opisuję, ja k w pam ięci m ikrokontrolera rozm ieszcza się kod
program u i je g o zm ienne, co dzieje się zanim zostanie w yw ołana funkcja main,
jak w yw oływ ane są procedury obsługi przerw ań oraz ja k to kontrolow ać i m ody­
fikować. O pis dotyczy języ k a C, architektury C ortex-M 3 i narzędzi G N U (GCC
i B inutils), ale w innych języ k ach program ow ania i ińnyeh architekturach w szystko
dzieje się bardzo podobnie. Z akładani też, że program ładow any je st do pam ięci
Flash.
1.8.1.
Sekcje
Kod program u oraz dane, na których on operuje, są w pam ięci zblokow ane w sek­
cjach. Na ry s u n k u 1.8 przedstaw iono typow e rozm ieszczenie sekcji w pam ięci m i­
krokontrolera.
Sekcja , i s r _ v e c t o r je s t specyficzna dla architektury C orlex-M 3. Z aw iera tablicę
adresów procedur obsługi przerw ań, a ponadto początkow ą w artość w skaźnika sto­
su oraz adres, od którego zaczyna się w ykonyw anie program u. W ięcej o tym piszę
w następnych podrozdziałach.
Sekcja . t e x t zaw iera kod w ykonyw alny, czyli skom pilow ane w szystkie funkcje
naszego program u oraz w szystkie funkcje biblioteczne, które do niego dołączam y.
Sekcja .r o d a t a zaw iera dane tylko do odczytu. Są to te zm ienne, któ re zostały
zadeklarow an e ja k o stale z uży ciem słow a k luczow ego c o n s t i nie zostały zo p ­
tym alizow ane. K o m p ilato r nie m usi alokow ać p am ięci dla zm iennej, która nie
zm ienia sw ojej w artości i je j zak res w ido czn o ści je s t o g ran iczo n y do je d n e g o blo ­
ku, je d n ej funkcji lub jed n o stk i translacji. Z op ty m alizo w an a m oże być zm ienna
lokalna (zad ek laro w an a w ew n ątrz bloku instrukcji o to czo n eg o naw iasam i k lam ­
row ym i lub w ew nątrz funkcji) w y sp ecy fik o w an a ja k o c o n s t lub s t a t i c c o n s t
albo zm ienn a glob aln a w y sp ecy fik o w an a ja k o s t a t i c c o n s t. Z m ienna globalna
0x08000000
Rys. 1.8. Typowa organizacja pamięci programu
w ysp ecy fikow ana tylko ja k o c o n s t nie m oże być zoptym alizow ana, gdyż je j na­
zw a je s t w idoczna na zew nątrz jed n o stk i translacji i potencjalnie m ożna odw ołać
się do niej z innych je d n o stek translacji, a standardow y proces kom pilow ania ję ­
zyka C nie przew iduje optym alizacji p om iędzy jed n o stk am i translacji. W sekcji
. r o d a ta um ieszczane są też stale napisow e, n iezależnie od tego, czy m ają jaw n ie
zd efin io w aną nazw ę.
Sekcja .d a ta zaw iera zm ienne globalne i statyczne, które są inicjow ane w artościa­
mi niezerow ym i. W artość zerow a to taka, której binarna reprezentacja ma w szystkie
bity w yzerow ane. W artość niezerow a to w artość, która nie je s t zerow a, czyli jej
reprezentacja binarna m a co najm niej jed en bit różny od zera. W tej sekcji znajdują
się tylko zm ienne zadeklarow ane bez kw alifikatora c o n s t. Są to w szystkie takie
zm ienne globalne oraz te lokalne, które są dodatkow o opatrzone słow em kluczo­
w ym s t a t i c .
Sekcja .b s s zaw iera dokładnie te sam e kategorie zm iennych co sekcja .d a ta , ale
są to te zm ienne, które są inicjow ane w artościam i zerow ym i lub nie podano żadnej
w artości inicjującej. Z m ienna, dla której nie podano w artości inicjującej, je s t (zw y­
kle) dom yślnie inicjow ana w artością zerow ą.
S ekcja heap to sterta przydzielona program ow i. Na stercie zm ienne są alokow ane
za pom ocą funkcji bibliotecznych przydzielających pam ięć, takich ja k np. raallo c.
1. Podstawy
40
Sekcja s t a c k zaw iera stos program u. N a stosie um ieszczane są zm ienne lokalne
(autom atyczne). N azw a zm ienna autom atyczna oznacza, że zm ienna laka znika au­
tom atycznie, gdy sterow anie program u w ychodzi poza zakres jej w idoczności. N a
stosie odkładane są też w artości argum entów aktualnych w yw ołania funkcji, czyli
w artości tych argum entów , które zostały przekazane funkcji w aktualnym jej w yw o­
łaniu. Z m ienne autom atyczne i argum enty funkcji są najczęściej optym alizow ane
przez kom pilator i o ile je st to tylko m ożliw e, nie są przechow yw ane na stosie,
a w rejestrach procesora. N a stosie odkładane m ogą też być adres pow rotu z funkcji
oraz w artości rejestrów , których funkcja używ a i których w artości musi odtw orzyć
przed pow rotem . W architekturze A R M nie odkłada się adresu pow rotu na stos
bezpośrednio - je st on trzym any w rejestrze procesora LR. Jeśli LR je s t potrzebny do
zagnieżdżonego w yw ołania funkcji, to dopiero w tedy jeg o w artość jest odkładana
na stos.
W ątpliw ości, co do um ieszczania zm iennych globalnych w poszczególnych sek­
cjach, pow inny w yjaśnić poniższe przykłady. Z m ienne a, b, c zostaną um ieszczone
w sekcji .r o d a ta :
1.8. Organizacja pam ięci programu
N apis zostanie um ieszczony w sekcji .r o d a t a , ale w skaźnik s8 w sekcji .d a ta :
const char * s8 = "Ala ma kota.";
N apis będzie um ieszczony w sekcji .d a ta , a w skaźnik s9 w sekcji .r o d a ta lub
zostanie zoptym alizow any:
char * const s9 = "Ala ma kota.";
N apis i w skaźnik slO zostaną um ieszczone w sekcji .r o d a ta , w skaźnik może zo­
stać zoptym alizow any:
const char * const slO = "Ala ma kota.";
W skaźniki s i l , s ł 2 zostaną um ieszczone w sekcji .b s s :
char * sil;
char * sł2 = NULL;
K olejny przykład pokazuje sposób przydziału pntięci dla zm iennych lokalnych.
void funkcja(char *p, int n) {
/* p - stos lub rejestr */
/* n - stos lub rejestr */
const int a ~ 5;
const: int b = 0/
const int c;
int i;
char q f 10];
static char x;
static char y = 'a';
const char z = 'b';
Z m ienne d, e, f zostaną um ieszczone w sekcji .r o d a t a lub zoptym alizow ane:
/* stos lub rejestr */
/*
/*
/*
/*
stos */
.bss */
.data */
.rodata łub optymalizacja */
static const int d = 5;
static const int e = 0;
static const int f;
/* alokacja n bajtów na stercie */
p = malloc(n);
Z m ienne g, j zostaną um ieszczone w sekcji .d a ta , a zm ienne h, i , k, m w sekcji
.b s s :
/* napis w .rodata */
strcpy(p, "Ala ma kota.");
int g = 5/
int h = G;
int i;
static int j = 5;
static ,i.nt k = 0;
static int m;
for (i = 0; i < n; -Hi) (
char s;
/* stos lub rejestr */
static char t;
/ * .bss */
static char u = ,c';
/* .data */
const char w = ’
d'; /* .rodata lub optymalizacja */
Sytuacja nieco bardziej się kom plikuje, gdy używ am y globalnych tablic lub w skaź­
ników, gdyż kw alifikator c o n s t m oże dotyczyć sam ego w skaźnika lub w artości,
na którą w skazuje, co d em onstrują następujące przykłady. Tablice s l , s2 zostaną
um ieszczone w sekcji .r o d a ta :
static const char sl{} = "Ala ma kota.";
const char s2[) = "To jest kot Ali.";
T ablice s3, s4 będą um ieszczone w sekcji .d a ta :
static char s3|j = "Ala ina kota.";
char s4[] = "To jest kot Ali.";
Tablice s5, s6 zostaną um ieszczone w sekcji .b ss :
static char s5(10];
char S6110];
N apis i w skaźnik s7 będą um ieszczone w sekcji .d a ta :
char * s7 = "Ala ma kota.";
41
i
1
Sekcje . isr_ _ v ecto r, . t e x t i .r o d a t a zaw ierają dane tylko do odczytu i dlatego
m ogą być um ieszczone w pam ięci Flash. M ożna je też um ieścić wRAM - m ikro­
kontrolery A RM m ogą w ykonyw ać kod z RAM . Sekcje .b s s , heap is ta c k za­
wierają dane, które m ogą być m odyfikow ane przez program i dlatego muszą być
um ieszczone w RAM . Zauw ażm y, że są dw ie sekcje .d a ta , jedna w Flash, a druga
w RAM . Sekcja .d a ta zaw iera dane, które z jednej strony m ają nadane jak ieś niezerow e w artości początkow e, a z drugiej strony m ogą być m odyfikow ane przez
program . Sekcja .d a ta um ieszczona w pam ięci Flash przechow uje w artości począt­
kow e, które są przepisyw ane do RAM przed rozpoczęciem w ykonyw ania progra­
mu. Ponadto przed rozpoczęciem w ykonyw ania program u trzeba w yzerow ać sekcję
.b s s , gdyż zaw artość RAM po w yzerow aniu m ikrokontrolera je st niezdefiniow ana.
Zatem sekcje .d a ta i .b s s w ym agają program ow ego inicjow ania. Z ajm uje się tym
procedura startow a, o której piszę w następnym podrozdziale.
42
1.8.2.
I. Podstawy
Procedura startowa
Procedura startow a zależy od architektury procesora i używ anego kom pilatora, gdyż
z reguły je s t pisana w A sem blerze konkretnego procesora. Tu przedstaw iam m ini­
malną, ale w pełni funkcjonalną i w w iększości przypadków zupełnie w ystarczającą,
procedurę startow ą dla architektury C ortex-M 3 i kom pilatora C z pakietu G CC. Na
jej podstaw ie C zytelnik m oże stw orzyć w łasną, bardziej rozbudow aną i dostosow a­
ną do sw oich potrzeb. R ozszerzenia dodane do języ k a C przez G N U C um ożliw ia­
ją napisanie procedury startow ej b ez użycia A sem blera. Pełny tekst źródłow y dla
m ikrokontrolera ST M 32F107, opatrzony kom entarzam i, znajduje się w archiw um
z przykładam i w pliku startup_ stm 3 2 _ cld .c, który je st w katalogu ./exatnples/src.
W tym m iejscu opisuję tylko kluczow e fragm enty procedury startow ej.
Z aczynam y od z ad ek laro w an ia p seu d o zm ien n y ch , któ re w sk azu ją g ran ice sekcji.
D eklarujem y je ja k o e x te r n , g dy ż są d efin io w an e p rze z k o n so lid ato r, co zo b a­
czym y w następnym p o d ro zd ziale. P o p atrzm y na ry su n ek 1.8. Z m ien n a s i d a t a
zachow uje się tak, ja k b y b y ła u m ieszczo n a w pierw szy ch czte rech bajtach sekcji
.d a t a w pam ięci F lash — je j ad res je s t ad resem p o czątku tej sekcji w Flash.
U w aga, lokacja zm iennej _ s i d a t a i p o zo stały ch p seu d o zm ien n y ch p o k ry w a się
w pam ięci z p raw d ziw y m i zm ien n y m i naszeg o pro g ram u . Te p seu d o zm ien n e
służą tylko do o k reślen ia adresów , gdzie zaczy n ają się i ko ń czą p o szczeg ó ln e
sekcje, Z m ien n a _ s d a ta je s t p o ło żo n a w czterech pierw szy ch bajtach dan y ch in i­
cjow anych w R A M , a zm ien n a __edata zajm u je cztery bajty tu ż za dan y m i in i­
cjow any m i, czyli adres zm iennej __sdata w sk azu je i p ierw szy ad res sekcji .d a ta
w R A M , adres zm iennej _ e d a ta - pierw szy adres ża tą sekcją. Z m ien n a _ s b s s
zajm uje p oczątk o w e czte ry bajty d an y ch zero w an y ch , a zm ien n a _ e b s s - cztery
bajty tuż za tym i d an ym i, czyli ad res zm iennej s b s s w sk azu je pierw szy ad ­
res sekcji .b s s , a ad res zm iennej _ e d a ta - pierw szy adres za tą sekcją. A dres
zm iennej e s t a c k w sk azu je p ierw szy adres za pam ięcią R A M , czyli początkow y
w ierzchołek stosu.
extern
extern
extern
extern
extern
extern
unsigned long
unsigned long
unsigned long
unsigned long
unsigned long
void _estack;
_sidata;
__sdata;
_edata;
_sbss;
_ebss;
N astępnie pow inniśm y zadeklarow ać sygnaturę głów nej funkcji, od której rozpo­
czyna się w ykonyw anie program u i która zw yczajow o nazyw a się main. Funkcja ta
musi być zdefiniow ana (zaim plem entow ana) w jak iejś jed n o stce translacji. N asza
funkcja main nie przyjm uje żadnych argum entów , choć nic nie stoi na przeszkodzie,
aby takie argum enty zadeklarow ać, jeśli znajdziem y po tem u sensow ny pow ód.
K onw encja nakazuje, aby funkcja m ain była typu i n t , choć nie będziem y w yko­
rzystyw ać zw racanej w artości - w św iecie m ikrokontrolerów funkcja ta nigdy nie
kończy działania. Jednak kom pilatory traktują ją specjalnie i w ypisują ostrzeżenie,
jeśli dostarczym y jej im plem entację innego typu.
int main(void);
1.8 . Organizacja pam ięci programu
43
D efiniujem y dom yślną procedurę obsługi przerw ania D e f a u l t j ł a n d l e r - nieocze­
kiw ane przerw anie zaw iesza m ikrokontroler. M ożna oczyw iście, jeśli potrzebujem y,
zaim plem entow ać bardziej w yrafinow aną obsługę.
static void Defaultjłandler(void) (
for (;;);
1
M usim y koniecznie napisać procedurę R e se t_ H a n d le r w yw oływ aną po w yzero­
w aniu m ikrokontrolera. M inim alna im plem entacja lej procedury rozpoczyna się od
dw óch pętli. Pierw sza pętla kopiuje sekcję .d a ta z Flash do R A M , a druga - zeruje
sekcję .b s s . Po tym m ożna ju ż rozpocząć w ykonyw anie program u - w yw ołujem y
funkcję main. Funkcja ta zw ykle nigdy się nie kończy, ale gdyby jed n ak nastąpił
z niej pow rót, zapętiam y się w nieskończoność.
static void Reset_Handler(void) {
unsigned long *src, *dst;
for (dst
*dst =
for (dst
*dst =
main ();
for
= &_sdata, src = &_sidata; dst < &_edata; ++dst, -i+src)
*src;
= &_sbss; dst < &_ebss; ++dst)
0;
1
Kolej na deklaracje procedur obsługi przerw ań - dla każdego przerw ania trzeba
dostarczyć bezparam etrow ą funkcję typu v o id . Funkcje te deklarujem y z atry­
butem weak, co w yjaśniam w dalszej części tego podrozdziału. M ikrokontroler
ST M 32F107 m oże zgłaszać kilkadziesiąt przerw ań. Poniższy w ydruk obejm uje tyl­
ko fragm ent ich listy.
Idefine WEAK
attribute
((weak))
void WEAK NMIJ-Iandler (void) ;
void WEAK HardFault_Handler(void);
void WEAK MemManage_Handler(void);
void WEAK BusFault_Handler(void);
void WEAK UsageEault_Handler(void)/
void WEAK SVCJIandler (void);
void WEAK DebugMon_Handler(void);
void WEAK PendSV_Handler(void);
void WEAK SysTick_Handler(void);
void WEAK WWDG_IRQHandler(void);
void WEAK PVD_IRQHandler(void);
void WEAK TAMPER_IRQHandler(void);
void WEAK RTC_IRQHandler(void);
void WEAK RTCAlarm_IRQ!Iandler (void);
void WEAK ETH_IRQHandler(void);
void WEAK OTGJf’
SJRQHandler(void);
Tablicę przerw ań um ieszczam y w specjalnie dla niej przeznaczonej sekcji , i s r _
v e c to r . Jest ona zadeklarow ana ja k o tablica stałych w skaźników do bezparam etrow ych funkcji typu v o id . D la ST M 32F107 tablica ta m a 84 elem enty, ale nie
w szystkie są obecnie używ ane - część je s t zarezerw ow ana do przyszłego w yko­
44
1. Podstawy
rzystania. Pierw szy elem ent (o indeksie 0) tablicy przerw ań zaw iera początkow ą
w artość w skaźnika stosu, ładow aną do rejestru SP po w yzerow aniu m ikrokontrole­
ra, Drugi elem ent (o indeksie 1) w skazuje na procedurę w yw oływ aną po w yzero­
waniu. K olejne 14 elem entów to adresy obsługi procedur przerw ań zdefiniow anych
w architekturze C ortex-M 3. Pozostałe 68 elem entów to adresy obsługi przerw ań
układów peryferyjnych, specyficznych dla ST M 32F107. Z arezerw ow ane elem enty
tablicy przerw ań są inicjow ane zeram i.
attribute
((section(".isr_vector")))
void (* const g pfnVectors(])(void) = {
&_estack,
Resetjlandler,
/* Przerwania Cortex-M3 */
MMIJiandler,
HardFault_Handler,
MemManage_Handler,
BusFault_Handler,
UsageFault_Handler,
0, 0, 0, 0,
SVCJiandler,
DebugMonJlandler,
0,
PendSV_Handier,
SysTick__Handler,
/* Przerwania układów peryferyjnych */
WWDG_IRQHandler,
PVDJRQHandler,
TAMPER_IRQHandler,
RTC_IRQHandler,
45
1.8. Organizacja pam ięci programu
m ultiple dęfinition). Z kolei brak im plem entacji dom yślnej w ym agałby dostarcze­
nia im plem entacji procedur obsługi w szystkich przerw ań, gdyż inaczej konsolidator
zgłosiłby bkjd odw yw ołania do niezdefiniow anej nazw y (ang. w u lefm ed rejerence).
fpragma weak NMI_Handler
= Default_Hancłler
fpragma weak HardFaułt_Handler = Defaultjiandler
fpragma weak MemManage_ilandler = Defaułt_Handłer
fpragma weak OTG_FS_IRQHandier = Default_Handler
Pow yższe instrukcje spraw iają, że nazw y procedur obsługi przerw ań są słabymi
aliasam i nazw y dom yślnej procedury obsługi. Jeśli konsolidator nie znajdzie de­
finicji jak iejś procedury, to użyje aliasu, czyli w stawi do tablicy przerw ań adres
procedury dom yślnej.
Skrypt konsolidatora
W w yniku kom pilacji, na podstaw ie każdej jednostki translacji, tw orzony jest odpo­
w iadający jej plik pośredni, zaw ierający w szystkie sekcje, których w ygenerow anie
było niezbędne dla tej jednostki translacji. Jest to plik relokow alny, co oznacza, że
każda sekcja m oże być um ieszczona pod dow olnym adresem w pam ięci procesora.
Pliki pośrednie m ogą być łączone w w iększe pliki, tw orząc biblioteki. Aby po­
wstał program w ykonyw alny, trzeba połączyć w łaściw e pliki pośrednie i biblioteki.
W tym procesie łączenia scalane są w je d n ą sekcję w szystkie sekcje pełniące tę
sam ą funkcję ze w szystkich plików poddanych łączeniu. Łączeniem plików pośred­
nich i rozm ieszczaniem poszczególnych sekcji w pam ięci zajm uje się konsolidator.
W przypadku konsolidatora Id z pakietu B inutils przebiegiem konsolidacji steruje
skrypt, co um ożliw ia bardzo elastyczne sterow ania tym procesem .
ETH_IRQHandler,
W katalogu Jcza tn p les/scn p ts znajdują się skrypty w ym ienione w tabeli 1.14.
D la każdego m odelu m ikrokontrolera S T M 32F107 je st tam um ieszczony osobny
skrypt. Są one jed n ak bardzo podobne, dlatego tu zam ieszczam tylko w ydruk pliku
stm 3 2 fl 07vc. Ids:
OTG_FS_IRQHandler
MEMORY
RTCAiarm_IRQHandler,
);
Ż eby tablica przerw ań m ogła być skonsolidow ana z resztą program u, czyli żeby
k onsolidator m ógł do niej pow staw iać w łaściw e adresy procedur, to dla każdej w y­
specyfikow anej w tablicy przerw ań nazw y procedury musi być dostarczona je j im ­
plem entacja. Procedury obsługi przerw ań definiujem y zw ykle w różnych je d n o st­
kach translacji. Na ogól jed n ak nie chcem y im plem entow ać procedur dla w szyst­
kich przerw ań, a tylko dla tych używ anych w danym program ie - pozostałym
najchętniej przypisalibyśm y adres dom yślnej procedury D e fa u lt_ H a n d le r. D o tego
w łaśnie służy, w spom niany w yżej, m echanizm słabego (ang. w e a k ) w iązania nazw.
Jeśli konsolidator znajdzie procedurę, której nazw a została um ieszczona w tablicy
przerw ań, to w staw i do tej tablicy jej adres. Jeśli jed n ak takiej procedury nie znaj­
dzie, to w staw i adres procedury dom yślnej. B ez m ożliw ości słabego w iązania nie
udałoby się tego zrobić elegancko. Z aim plem entow anie dom yślnego zachow ania
w e w szystkich procedurach i próba dostarczenia później w łaściw ej im plem entacji
spow odow ałaby błąd konsolidacji - dw ukrotnie zdefiniow ana ta sam a nazw a (ang.
(
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 256K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 6<1K
I
_mininuim_stack_and_heap_size = 8192;
INCLUDE cortex-m3.1ds
Z a pom ocą instrukcji MEMORY deklarujem y dostępne obszary pam ięci, ich atrybuty
(r - upraw nienie do odczytu, w - m ożliw ość zapisu, x - zezw olenie na w ykony­
w anie kodu z tej pam ięci), adres początku i rozm iar. N ależy podkreślić, że alryTab. 1.14. Skrypty konsolidatora dla STM32F107
Skrypt
Opis
cortex-m3.lds
Część wspólna dla architektury Cortex-M3
stm 32H07rb.lds
Część specyliczna dla STM 32F107RB
stm 32H 07rc.lds
Część specyficzna dla STM 32F107RC
stm 32l107vb.lds
Część specyficzna dla STM 32F107VB
stm 32n07vc.lds
Część specyficzna dla STM 32F107VC
I. Podstawy
46
buty te są tylko inform acją dla konsolidatora i nie w ym uszają żadnych ograniczeń
dostępu do fizycznej pam ięci m ikrokontrolera. N astępnie deklarujem y m inim alny
rozm iar pam ięci, która m usi pozostać w olna dla stosu i sterty (sekcje s ta c k i heap).
K onsolidator zgłosi błąd, gdy w R A M zostanie za m ało m iejsca. W reszcie na koń­
cu, za pom ocą instrukcji IN C L U D E , przechodzim y do w ykonania głów nego skryptu
cortex-m 3.lds, w spólnego dla w szystkich modeli m ikrokontrolera. Jest to m inim al­
ny, ale w pełni funkcjonalny, skrypt dla architektury C orlex-M 3. P oznaw szy jeg o
strukturę, C zytelnik m oże stw orzyć w łasny, bardziej rozbudow any i dostosow any
do sw oich potrzeb. Skrypt ten w ygląda tak:
SECTIONS
(
.text :
f
K E E P (*(.isr_vector))
* E.text)
* (.text.*)
*{.rodata)
* (.rodata.*)
. = AL I G N (4);
_etext =
_sidata = _etext;
) >FLASH =0xf f
1.8. Organizacja pamięci programu
47
osobnych sekcji. Na om aw ianym w ydruku pom inąłem fragm ent tw orzący sekcje
dla debuggera, gdyż nie m a to w pływ u na organizację pam ięci program u - zaintere­
sow any C zytelnik m oże po prostu zajrzeć do pliku ./exam ples/scripts/cortex-m 3.lds.
Poniżej opisuję szczegółow o poszczególne konstrukcje użyte w tym skrypcie.
SECTIONS
{
1
Instrukcja S E C T IO N S rozpoczyna głów ną część skryptu definiującą sposób przetw a­
rzania sekcji z plików pośrednich na sekcje w pliku w ynikow ym (w ykonyw alnym ).
Z aw iera definicje poszczególnych sekcji w pliku w ynikow ym . W tym konkretnym
przypadku są to sekcje . t e x t , .d a ta i .b s s .
.text :
1
) >FLASH =0xff
Pow yższa instrukcja tw orzy sekcję . t e x t , która zostanie um ieszczona w pam ięci
Flash, a ew entualne puste, nieużyw ane m iejsca zostaną w ypełnione w artościam i
0xf f .
.data : AT(_sidata)
.data : AT(_sidata)
I
i
. = AL I G N (4);
_sdata =
M.data)
M.data.*)
. = AL I G N (4);
_edata =
) >RAM =0
) >RAM =0
i
.bss :
{
. = AL I G N (4) ;
_sbss = .;
* ( .bss)
* {.bss.*)
* (COMMON)
. = A L I G N (4);
_ebss = .;
) >RAM
_estack = (ORIGIN(RAM) + LENGTH(RAM)) & OxFFFFFFFC;
ASSERT(_ebss + _minimum_stack_and_heap size <= _estack,
"There is not enough space in RAM for stack and heap.")
PROVIDE(end = _ebss);
/* Teraz zostały już tylko informacje dla debuggera. */
)
Pow yższy skrypt tw orzy trzy sekcje: . t e x t , .d a ta i .b s s . W sekcji . te x t są um iesz­
czane w spólnie sekcje ,i s r _ v e c t o r , . t e x t i .r o d a t a - nie m a potrzeby tw orzenia
Pow yższa instrukcja tw orzy sekcję .d a ta . A dresy w tej sekcji m ają być tak w ylicza­
ne (relokow ane), jak b y była um ieszczona w R A M , ale zaw artość tej sekcji zostanie
fizycznie załadow ana pod adres _ s i d a t a , który je s t pierw szym adresem w pam ięci
Flash tuż za sekcją . t e x t (połączonym i sekcjam i . is r _ v e c to r , . t e x t i .ro d a ta ).
E w entualne puste, nieużyw ane m iejsca zostaną w ypełnione zeram i.
.bss :
I
| >RAM
P ow yższa instrukcja tw orzy sekcję .b s s , która zostanie um ieszczona w RAM .
* {. text)
*(.text.*)
P o w y ższa instrukcja w ybiera o k reślo n e sek cje z w yspecyfikow anych plików.
W yrażenie reg u larn e przed n aw iasem je s t w zorcem nazw y pliku - gw iazdka
o zn acza w szy stk ie pliki. W yrażenie reg u larn e w n aw iasie je s t w zorcem nazw y
sek cji, którą należy w ybrać z tego pliku. G w iazdka zastępuje dow olny ciąg
znaków . W ybierane są w szy stk ie sek cje o nazw ach pasujących do w zorca ze
w szy stk ich plików o nazw ach pasu jący ch do w zorca. S ekcje, których nazw a ma
d o d atk o w y su fik s rozpoczynający się kropką, pow stają, jeśli p odczas kom p ilo ­
w ania ustaw im y op cję um ieszczan ia w szy stk ieg o w osobnych sekcjach (patrz
o statn ie dw a w iersze w tabeli 1.5). P rzykładow o funkcja o nazw ie xyz zostanie
um ieszczo n a w tedy w sw ojej sekcji o nazw ie .t e x t . x y z . Jeśli opcje te nie z o ­
stan ą u staw ione, to funkcja ta zo stan ie um ieszczo n e w e w spólnej sekcji . t e x t
I. Podstawy
48
'S
1.9. Styl pisania i komentowania tekstu źródłowego
ASSERT (_ebss + jiunimuni_stack_and_heap_size <= _eatack,
w raz z innym i funkcjam i z tej sam ej je d n o stk i tran slacji. P o w y ższe instrukcje
p o k ry w ają o b ie sytuacje.
"There is not enough space in RAM for stack and heap.")
Instrukcja A S S E R T spraw dza popraw ność w arunku. Jeśłi w yrażenie w pierw szym
argum encie jest fałszyw e, to konsolidator przeryw a pracę i w ypisuje tekst będący
drugim argum entem . Z asady w yliczania w artości w yrażenia w arunkow ego są ana­
logiczne ja k w języ k u C. W tym konkretnym przykładzie konsolidator zgłosi błąd,
gdy po scaleniu w szystkich sekcji, które m ają znaleźć się w RAM , zostanie za mało
m iejsca na stos i stertę.
K E E P (*(.isr_vector))
Pow yższa instrukcja K E E P spraw ia, że sekcja , i s r _ v e c t o r , czyli tablica adresów
procedur obsługi przerw ań oraz sam e procedury obsługi przerw ań nie zostaną
usunięte z pliku w ynikow ego przez ods'm iecacz (patrz opcja odśm iecania w tabeli
1.9). D o tablicy przerw ań i do procedur przerw ań nie m a zw ykle żadnych odw ołań
w tekście źródłow ym - procedur przerw ań raczej nie w yw ołujem y ja w n ie - są na
ogól w yw oływ ane przez sprzęt, w ięc odśm iecacz m iałby w szelkie podstaw y, żeby
je usunąć z pliku w ynikow ego.
PROVIDE (end = __ebss) ;
P ow yższa instrukcja P R O V ID E pow oduje, że jeśli w ja k iejś jed n o stce translacji jest
o dw yw ołanie do zew nętrznego sym bolu o nazw ie end, a sym bol ten nie został nig­
dzie zdefiniow any, to zostanie on zdefiniow any przez konsolidator i zostanie mu
p rzydzielony adres będący w artością w yrażenia um ieszczonego po praw ej stronie
operatora przypisania. W tym konkretnym przypadku będzie to pierw szy wolny
adres za sekcją .b s s . Z m ienna o nazw ie end je st w ykorzystyw ana przez standardo­
w ą bibliotekę jęz y k a C do w skazania początkow ego końca sterty. M ianow icie ad­
res tej zm iennej je s t używ any do zainicjow ania zm iennej heap_end, która pam ięta
pierw szy w olny adres nad stertą, w ięc na początku działania program u sterta ma
zerow y rozm iar. Jeśli trzeba przydzielić now ą pam ięć i nie ma m iejsca na stercie,
to spraw dza się, czy m ożna rozszerzyć stertę. Sterta je s t rozszerzana, jeśli m iędzy
heap_end a w skaźnikiem stosu (rejestr S P ) je s t dostateczna ilość w olnego m iej­
sca. Z m ienna heap_end je s t tylko zw iększana, nigdy zm niejszana. Zarządzaniem
rozm iarem sterty zajm uje się funkcja, której nazw a zaw iera zw ykle napis sb rk
- w b ibliotece N ew lib dla architektury A RM je s t to funkcja _ sb rk . W niektórych
im plem entacjach biblioteki standardow ej zm ienna używ ana do w skazania począt­
kow ego końca sterty nazyw a się _end. T rzeba w tedy odpow iednio zm odyfikow ać
instrukcję P R O V ID E .
. = ALIGNH);
Jeśli nie zdecydujem y inaczej, to konsolidator, analizując skrypt, układa scalane
sekcje po kolei. K ropka oznacza adres, pod którym zostanie um ieszczona kolejna
scalana sekcja, czyli docelow y adres początku tej sekcji. Z nak rów ności je s t opera­
torem przypisania. Jeśli do kropki przypiszem y w artość, to zm odyfikujem y bieżący
adres i następna scalana sekcja zostanie um ieszczona pod tym now ym adresem .
O perator ALIGN zw raca najbliższy adres, który je s t w ielokrotnością je g o argum entu
i służy do w yrów nyw ania położenia sekcji w pam ięci. A RM je st architekturą 32-bitow ą. A rchitektury 32-bitow e w ym agają zw ykle, aby adresy początków sekcji
były w yrów nyw ane do w ielokrotności 4.
_etext = .;
Pow yższa instrukcja przypisuje sym bolow i __etext bieżący adres. W tekście źród­
łow ym w C ten sym bol będzie w idoczny jak o zm ienna um ieszczona pod tym ad­
resem .
_sidata = _etext;
Pow yższa instrukcja sym bolow i _ s i d a t a przypisuje w artość w yrażenia po praw ej
stronie znaku rów ności. W tym przypadku je st to w artość przypisana poprzednio
sym bolow i e te x t . Zauw ażm y, że k onsolidator operuje na adresach, ale defin io ­
w ane sym bole są w tekście źródłow ym w idziane ja k o zm ienne i dla uzyskania ad­
resu trzeba użyć operatora dereferencji &, czyli aby uzyskać adres przypisany przez
konsolidator sym bolow i __sidata, trzeba w C użyć w yrażenia & _ sid ata. Po praw ej
stronie operatora przypisania m oże pojaw ić się w yrażenie składające się z poprzed­
nio zdefiniow anych sym boli połączonych za pom ocą w iększości operatorów arytm etyczno-logicznych, które są d ostępne w języ k u C, a dla w ym uszenia kolejności
działań m ożna użyć naw iasów , ja k w poniższym przykładzie.
_estack = (ORIGIN(RAM)
I LEHGTH(RAM)) S OxFFFFFFFCj
Pow yższa instrukcja definiuje p o czątkow ą w artość rejestru S P , czyli w ierzchołka
stosu. R ejestr SP w skazuje na ostatnio odłożoną na stos w artość. W architekturze
A RM , jak w w iększości procesorów , stos rośnie w dól, w kierunku m niejszych ad­
resów. Poniew aż je s t to architektura 32-bitow a, na stosie odkładane są w ielokrotno­
ści czterech bajtów, a w artość rejestru SP musi być podzielna przez cztery. Zatem
początkow a w artość w ierzchołka stosu pow inna być pierw szym adresem za RAM ,
a jeśli ten adres nie je s t w ielokrotnością czterech, to należy go zm niejszyć do naj­
bliższego podzielnego przez cztery.
49
1.9.
Styl pisania i komentowania tekstu źródłowego
Tekst źródłow y program u je s t czytany nie tylko przez kom pilator (lub interpreter),
którem u styl program ow ania je s t obojętny. Jest też czytany przez ludzi, którzy chcą
lub m uszą go pielęgnow ać i dalej rozw ijać. D obrze napisany program kom puterow y
daje się łatw o m odyfikow ać i rozszerzać o now ą funkcjonalność. Program żyje, gdy
jest rozw ijany i popraw iany, często przez kolejne pokolenia program istów , którzy
w zajem nie się nie znają. Program , którego nie m ożna zm odyfikow ać, m a dużą szan­
sę stać się m artw y i przestać być używany. C ałość lub fragm enty dobrze napisanego
program u pow inno dać się w ykorzystać w kolejnych projektach. Jedną z w ażniej­
szych przyczyn trudności m odyfikow ania program u je s t nieczytelnie napisany tekst
źródłowy, którego po pew nym czasie naw et autor nie rozum ie. D ołożyłem w szel­
kich starań, aby zam ieszczone w tej książce przykłady były napisane elegancko,
w dobrym stylu. Program y kom puterow e m ają jed n ak taką przypadłość, że zaw sze
m ożna w nich coś popraw ić i napisać lepiej.
W ażnym elem entem popraw iającym czytelność program u są kom entarze. Nie nale­
ży je d n a k przesadzać i kom entow ać każdej linijki - to w brew pozorom m oże u trud-
50
1. Podstawy
niać czytanie tekstu źródłow ego. N ależy bezw zględnie kom entow ać te fragmenty,
których działanie je st nieoczyw iste albo pow ód ich napisania trudno odgadnąć.
K om entarze pow inny być pisane pełnym i zdaniam i i popraw nym językiem . N ie na­
leży um ieszczać kom entarzy tryw ialnych, opisujących to, co w idać w tekście źród­
łow ym program u. Z am iast długich opisów często w ystarczy w łaściw ie dobrać na­
zwy funkcji, ich param etrów i zm iennych. O dpow iednie nazw y spraw iają, że tekst
źródłow y sam odokum entuje się, a niew ielka ilość kom entarzy w ystarcza do jego
zrozum ienia. Taki sam okom entujący się tekst źródłow y czyta się bardzo przyjem ­
nie. Teksty źródłow e zaw arte w archiw um z przykładam i są skom entow ane, lecz nie
przesadnie. Pew nym uspraw iedliw ieniem je st fakt, że cała treść książki je st sw ego
rodzaju kom entarzem do tych przykładów . Z oszczędności m iejsca, w głów nym
tekście książki, w e fragm entach program ów ilustrujących opisyw ane zagadnienia
i przykłady pom ijam w iększość kom entarzy. N ie są one tu potrzebne, g dyż sam
tekst książki stanow i dostateczne w yjaśnienie.
Intersieci
2.1. M odel warstwowy
Intersieć (ang. internet) składa się z w ielu autonom icznych, w spółdziałających sieci
lokalnych (LA N, ang. local area netw ork). N ajw iększą intersiecią, ja k ą dotychczas
stw orzono, jest Internet. Intersieci zarządzane są w sposób rozproszony - poszczę- *
gólne organizacje, firnty nadzorują sw oje fragm enty sieci. Z apew nienie popraw - $
nej w spółpracy w takim środow isku w ym aga standaryzacji. W iększość aspektów ;p
działania intersieci je s t opisana w dokum entach R FC (ang. R equest fo r Continents). rj
N iektóre z nich uzyskały status o ficjalnego standardu, ale w iększość nie m a charak- g
teru norm atyw nego, będąc tylko niezobow iązującym i zaleceniam i albo inform acja-/^,
mi, lecz m im o to są pow szechnie stosow ane i przestrzegane przez tw órców opro­
gram ow ania sieciow ego. D okum enty RFC są publikow ane na stronie http://w w w . jrfc-editor.org.
.;1|
Ten rozdział zaczynam od przedstaw ienia m odelu w arstw ow ego intersieci. N astępnie
opisuję zasady działania E thernetu, czyli najpow szechniejszej obecnie technologii
budow y przew odow ych sieci lokalnych. Potem w yjaśniam , ja k sieci lokalne oparte
na E thernecie łączy się w intersieć. S poro m iejsca pośw ięcam adresow aniu w intersieciach. P odaję tylko niezbędne m inim um inform acji potrzebnych do program ow ania usług sieciow ych, a chcących w iedzieć w ięcej odsyłam do studiow ania RFC.
Jako przykład kończący ten rozdział proponuję napisanie prostego m onitora sieci.
#
'jjj
';|
;r
V
;■
'jf
'i*
Term inem p a kiet nazyw am d o w olną porcję danych w ysyłanych przez dow olny !i.
protokół sieciowy. W odniesieniu do poszczególnych protokołów stosuję bardziej
precyzyjne nazwy. P akiet m oże w ięc oznaczać ram kę E thernetu, datagram IP, da­
tagram UDP, segm ent TCP, kom unikat jak ieg o ś protokołu pom ocniczego lub apli­
kacyjnego.
Ś~
2.1.
Model warstwowy
O program ow anie sieciow e tw orzy się w arstw ow o. W arstw a definiuje protokół ko­
m unikacyjny udostępniający pew ną usługę. T ypow e w arstwy, które m ożem y w yod­
rębnić w intersieciach, przedstaw ione są na ry s u n k u 2.1. U m ieściłem na nim też
skróty nazw protokołów , które p o jaw iają się w tej książce. P rzyporządkow anie kon­
kretnego protokołu do określonej w arstw y nie zaw sze jest proste i jednoznaczne.
W arstw a korzysta z usług w arstw y niższej, znajdującej się w m odelu w arstw ow ym
bezpośrednio pod nią, na podobnej zasadzie ja k chcący w ysiać przesyłkę korzy­
sta z firm y kurierskiej. Podział kom unikacji sieciow ej na w arstw y m a szereg za­
let. Poszczególne w arstw y są projektow ane i im plem entow ane niezależnie. Z usług
udostępnianych przez daną w arstw ę m ożna korzystać ja k z gotow ego kom ponentu,
nie trzeba go sam odzielnie im plem entow ać. W arstw ę m ożna traktow ać ja k czarną
skrzynkę - żeby jej używ ać, nie trzeba znać szczegółów w ew nętrznych - w ystar­
czy znać interfejs program istyczny udostępniany przez im plem entację tej warstwy,
Im plem entację w arstw y m ożna łatw o zastąpić inną, o ile m a podobny interfejs pro­
gram istyczny. W praktyce pełna separacja i niezależność w arstw nie je st osiągana.
w ypełnionego na stronie przez użytkow nika itd. H TT P nie musi nic w iedzieć, jak
te dane są przesyłane przez sieć. Tym zajm uje się protokół w arstw y transporto­
wej. P odstaw ow ym i protokołam i transportow ym i w intersieciach są T C P (ang.
Transm ission Contro! ProtocoI) i U D P (ang. U ser D atagram Protocol). H TTP
akurat korzysta z TCP, który gw arantuje, że jeśli dane dotrą do odbiorcy, to dotrą
we w łaściw ej kolejności. Z apew nia też, że dane zostaną w ysiane ponow nie (będą
retransm itow ane), gdy ich otrzym anie nie zostanie potw ierdzone w pew nym usta­
lonym czasie. Protokół transportow y z kolei nie musi znać topologii sieci - nie
musi w iedzieć, gdzie w sieci znajduje się odbiorca danych. Z najdow aniem drogi
do odbiorcy, czyli trasow aniem (ang. routing), zajm uje się w arstwa sieciow a. W in­
tersieciach jest jeden podstaw ow y protokół w tej w arstw ie, m ianow icie IP (ang.
Internet P rotocol), który działa niezależnie od zastosow anego m edium transm isyj­
nego - m ożna w tym celu użyć kabli elektrycznych, św iatłow odów , fal radiow ych,
a naw et gołębi pocztow ych (patrz R FC 1149). Z a obsługę konkretnego medium
odpow iada w arstw a dostępu do sieci. W arstw ę tę zw ykle dzieli się na dw ie podw arstwy. Warstwa łącza zajm uje się kodow aniem liniow ym , synchronizacją odbiornika
do nadajnika i kontrolą jakości transm isji. K odow anie liniow e m a na celu dopa­
sow anie sekw encji transm itow anych bitów do w łasności nośnika, np. gdy niepo­
żądane jest w ysyłanie długich ciągów sam ych zer lub jedynek. Warstwa fizyczna
definiuje param etry elektryczne nośnika. Z ależnie od użytego m edium są to przy­
kładow o poziom y napięć w kablu, długość fali, rodzaj m odulacji itp. D efiniuje też
param etry m echaniczni złączy.
W popularnym siedm iow arstw ow ym m odelu OSI (ang. Open System Interconnection
Reference M odel), prom ow anym przez ISO (ang. International O rganization fo r
Standardization), m iędzy w arstw ą aplikacji a transportow ą w yróżnia się dw ie dodat­
kow e. Warstwa prezentacji m a za zadanie ustalenie jednolitego form atu danych. Są
•i1
I
Na szczycie m odelu w arstw ow ego znajduje się w arstw a aplikacji. Protokoły tej
w arstw y definiują sposób interakcji m iędzy aplikacjam i. Przykładow o H TT P (ang.
H ypertext Transfer P rotocol) służy do przesyłania zaw artości stron www. D efiniuje fi.
on m iędzy innym i, ja k przeglądarka m a poprosić o zaw artość strony, ja k serw er ■.
odsyła odpow iedź z tą zaw artością, ja k przesłać do serw era zaw artość form ularza
53
Rys. 2.1. Model warstwowy intersieci
55
2.2. Ethernet
to m iędzy innym i: porządek bajtów (little-endian lub big-endian), kodow anie liczb
(uzupełnieniow e do dw ójki, uzupełnieniow e do jed y n ek itp.) i napisów (ASCII,
EB C D IC , U TF-8 itp.). Warstwa sesji odpow iada za m ultiplcksow anie danych róż­
nych aplikacji. W tych w arstw ach m oże leż odbyw ać się szyfrow anie danych, czego
przykładem st| protokoły SSH (ang. Secure S h ell) i T L S /S S L (ang. Transport Layer
Security, Secure Socket Layer).
Ethernet
E thernet jest jed y n y m przedstaw icielem w arstw y dostępu do sieci rozw ażanym
w tej książce. Sieć E thernet m ożna zbudow ać w oparciu o różne rodzaje m edium
transm isyjnego. Na początku stosow any był gruby, a potem cienki kabel koncen­
tryczny. O becnie najpow szechniej w ykorzystuje się kable skrętkow e, popularnie
nazyw ane skrętką. M ożna też użyć św iatłow odu w ielom odow ego lub jednom odow ego. W spółpracę z w łaściw ym m edium transm isyjnym zapew nia nadajnik-odbiornik (ang. transceiver), obecnie częściej nazyw any zew nętrznym urządzeniem
w arstw y fizycznej (ang. external p h ysic a l layer device), a w żargonie skrótow o
PHY. O bsługą sam ego protokołu E thernetu zajm uje się układ sterow ania dostępem
do m edium M A C (ang. M edia A ccess C ontrol). M A C i P ifY połączone są za po­
mocą ustandaryzow anego interfejsu, np. M II (ang. M edia Independent Interface),
RM II (ang. R educed M edia In d ependent Interface) lub G M II (ang. G igabit M edia
Independent Interface), co uniezależnia M A C od zastosow anego rodzaju m edium
transm isyjnego i gw arantuje popraw ną w spółpracę układów różnych producentów.
M ożna pow iedzieć, że M A C realizuje w arstw ę łącza, a PH Y w arstw ę fizyczną.
W tab eli 2.1 zestaw ione są w ybrane w arianty E thernetu stosow ane w przeszło­
ści i obecnie. Dla kabli skrętkow ych podano liczbę w ykorzystyw anych par, a dla
św iatłow odu najczęściej używ aną długość fali. Podane są też typow e zasięgi dla
standardow ego okablow ania - lepszej jak o ści kable lub św iatłow ody um ożliw iają
zw iększenie zasięgu.
Tab. 2.1. Wybrane warianty Ethernetu
Przepływność
10 Mb/s
Oznaczenie
Gruby kabel koncentryczny
10BASE2
Cienki kabel koncentryczny
10BROAD36
10BASE-T
100 Mb/s
1 Gb/s
10 Gb/s
Opis
10BASE5
Kabel współdzielący różne usługi, np. z telewizją kablową
Zasięg
185 m
100BASE-T4
Skrętka min. kategorii 3, cztery pary
ÏO OrrT
100BASE-TX
Skrętka min. kategorii 5, dwie pary
100 m
100BASE-FX
Światłowód wielomodowy, 13 10 nm
412 m
1000BASE-T
Skrętka min. kategorii 5, cztery pary
100 m
10GBASE-T
Skrętka min. kategorii 6, cztery pary
Światłowód wielomodowy, 8 5 0 nm
10GBASE-LR
Światłowód jednomodowy, 13 10 nm
Jako zw ykli użytkow nicy sieci najczęściej spotykam y się z E thernetem w wersji
100B A SE-TX lub 10BASE-T. W szystkie urządzenia obsługujące w ariant 100BA­
SE -T X obsługują też 10BASE-T. U rządzenia obsługujące tylko 10B A SE-T są aktu-
87654321
w m m
22 0 m
5000 m
55 m
82 m
10 0 0 0 m
R J-45 Fem ale
R J-45 M ale
36 00 m
100 m
10GBASE-SR
Przem ysł telekom unikacyjny stosuje ustandaryzow ane oznaczanie przew odów ko­
loram i. Skrętka używ ana w E thernecie m a cztery pary w kolorach biało-niebieskim ,
biało-pom arańczow ym , biato-zielonym i biało-brązow ym . Pierw szy przew ód w pa­
rze ma izolację w kolorze białym z paskiem lub paskam i w drugim kolorze. Drugi
przew ód w parze ma izolację w drugim kolorze z opcjonalnym paskiem lub paska­
mi w kolorze białym . W szystkie kom ponenty sieci E thernet zbudow anej w oparciu
0 skrętkę w yposaża się w złącza R J-45, przedstaw ione na ry s u n k u 2.2. K artę sie­
ciow ą z koncentratorem (ang. hub), przełącznikiem (ang. sw itch) lub gniazdem sieci
strukturalnej łączy się za pom ocą kabla prostego (ang. patch cable, patch cord),
którego dw a w arianty są zam ieszczone na r y s u n k u 2.3. W arianty te m ają identycz­
ne połączenia elektryczne, różnią się przyporządkow aniem par do poszczególnych
końców ek złącza. W szafach krosow niczych sieci strukturalnej też stosuje się kable
proste. D o połączenia dw óch kart sieciow ych 10B A SE -T lub 100B A SE-TX trzeba
użyć kabla skrzyżow anego (ang. crossover cable) z ry s u n k u 2.4. W 10BASE-T
1 100BASE-TX w ykorzystyw ane są tylko pary biało-pom arańczow a i bialo-zielona
oraz styki 1, 2, 3 i 6 złącza RJ-45.
50 0 m
Skrętka min. kategorii 3, dwie pary
1000BASE-SX Światłowód wielomodowy, 8 5 0 nm
1000BASE-LX Światłowód jednomodowy, 13 10 nm
K ategoria kabla skrętkow ego określa jeg o w łasności elektryczne. O gólnie, czym
w yższa je st kategoria, tym szersze pasm o przenoszenia i m niejsze są przesłuchy
m iędzy param i. D la 10B A SE-T w ystarczy kabel kategorii 3, przenoszący pasm o
16 M H z. D la 100B A SE-TX potrzebny je s t kabel kategorii co najm niej 5 o paśm ie
100 M H z. W now ych instalacjach stosuje się okablow anie kategorii 5e, 6 lub 6a.
K able kategorii 5e m ają zredukow ane przesłuchy w stosunku do kategorii 5. K able
kategorii 6 i 6a m ają pasm o przenoszenia odpow iednio 250 M H z i 500 M Hz. Na
potrzeby bardzo szybkich sieci zdefiniow ano kategorie 7 i 7a, które m ają pasm o
przenoszenia odpow iednio 600 M H z i 1000 M H z. Stosow ane są kable nieekranow ane U TP (ang. unshielded tw isted pair) lub ekranow ane. Ekran m oże być w yko­
nany z oplotu lub folii m etalow ej. Ekran m oże obejm ow ać cały kabel, każdą parę
oddzielnie lub jednocześnie każdą parę i cały kabel. K able ekranow ane m ają różne
oznaczenia, np.: FT P (ang. fo iled tw isted pair), ST P (ang. shielded tw isted pair),
SFT P (ang. screened fu lly shielded tw isted pair).
Rys. 2.2. Złącze RJ-45
12345678
□
12345678
Wersja A
____________________ Blalo-zieiony______________________^
_________________Zletono-blały ______________________ ^
<D-
Niebiesko-blaly
0^ -------------------------------^ ---- l-------------------------- ^0
B la ło -n ie b ie s k i
^ ___________________Pomarańczowo-bialy__________________ ^
_____________________ Bialo-brązowy_____________________
Bialo-brązowy
q
Brązowo-bialy
-
Wersja B
^ __________________ Błalo-poroarańczowy__________________ ^
^ __________________ Pomarańczowo-bialy__________________ ^
©_____________ aatojgto^r----------------------@
_____________________ Nieblesko-bialy____________________ ^
^
Bialo-niebieski____________
^
Brązowo-bialy
Rys. 2.3. Kabel prosty
alnie w zaniku. Jeszcze niedaw no E thernet 1 G b/s stosow any byl przede w szystkim
do łączenia urządzeń sieciow ych, które m uszą obsługiw ać duży ruch (przełączni­
ki, rutery, serw ery), ale obecnie co raz częściej w interfejs m ogący pracow ać rów ­
nież ja k o 1000B A SE-T w yposażane są kom putery osobiste. U kład testow y użyty
do napisania tej książki, czyli zestaw Z L29A R M z m odułem Z L 3E T H , obsługuje
10B A SE-T i 100BA SE-TX . D alszy opis będzie dotyczył przede w szystkim tych
wariantów.
Brązowo-bialy
Rys. 2.4. Kabel skrzyżowany dla 10BASE-T i 100BASE-TX
6 oktetów
6 oktetów
2 oktety
4 6 do 1 5 0 0 oktetów
4 oktety
ADRES
ODBIORCY
ADRES
NADAWCY
DŁUGOŚĆ
TYP
DANE
SEKWENCJA
KONTROLNA
D ane w sieci E thernet są przesyłane w ram kach. Istnieje kilka standardów opisu­
jący c h form at ram ki. Nie w chodząc w niepotrzebne szczegóły, w szystkie one defi­
niują strukturę przedstaw ioną na ry s u n k u 2.5. W term inologii sieciow ej oktet (ang.
octet) oznacza 8 kolejnych bitów. Pojęcie to w prow adzono dla odróżnienia od bajlu,
który w przeszłości nie zaw sze oznaczał 8 bitów. Przy zapisyw aniu w ysyłanego
siecią ciągu oktetów obow iązuje konw encja, że oktety w ysyłane są od lewej do
praw ej. Podobnie zapisuje się ciąg bitów przesyłanych siecią. Pierw szy w ysyłany
bit je s t zapisyw any po lewej. N atom iast pew nej uwagi w ym aga konw encja, któ­
ra określa, że w E thernecie bity oktetu transm itow ane są od najm niej znaczącego.
R am ka zaczyna się od pream buły, która zaw iera na przem ian bity 1 i 0, począw szy
od jedynki. W yjątkiem je s t ostatni bit, który też je s t jedynką - pream buła kończy
się dw om a jedynkam i. Pream buła w yglądu zatem następująco:
10101010 1 0101010 10101010 10101010 10101010 10101010 10101010 10101011
*'
W zapisie szesnastkow ym je st to ciąg ośm iu oktetów:
55 55 55 55 55 55 55 d5.
Zielono-bialy
^ ______________________Bialo-brązowy_________________
8 oktetów
PREAMBUŁA
Rys. 2.5. Ramka Ethernetu
Biało-pomarańczowy
© -
<D-
57
2.2. Ethernet
2. ¡ntersieci
56
Pream buła w E thernecie łO M b/s zapew nia synchronizację odbiornika do nadajni­
ka. O dbiornik m oże zgubić początkow e bity ram ki, ale w ystarczy, aby popraw nie
rozpoznał koniec pream buły. G ubienie początkow ych bitów pream buły niczym nie
grozi. W w ariantach E thernetu o w iększej przepływ ności stosuje się bardziej w y­
rafinow ane kodow anie bitów, zapobiegające gubieniu początku ram ki, ale pream ­
buła została zachow ana ze w zględu na kom patybilność. Pream buła je st obsługiw a­
na przez sprzęt. O program ow anie tw orzy ram ki bez pream buły i otrzym uje ramki
z usuniętą pream bułą.
K olejne dw a pola ram ki to adres odbiorcy i nadawcy. Każdy interfejs w sieci
E thernet musi m ieć unikalny adres, który nazyw am y adresem sprzętow ym lub ad­
resem M A C . Jeśli pierw szy bit adresu odbiorcy je s t zerem , to jest to adres pojedyn­
czego interfejsu. Jeżeli pierw szy bit adresu odbiorcy jest jedynką, to je st to adres
grupow y (ang. m ulticast). W iele interfejsów m oże m ieć w spólny adres grupowy.
W ysianie ram ki na adres grupow y oznacza w ysłanie jej do w szystkich interfejsów
w spółdzielących ten adres. A dres odbiorcy składający się z sam ych jedynek, czyli
szesnastkow o adres ff ff ff ff ff ff, jest adresem rozgłoszeniow ym (ang. broadcast)
i oznacza w szystkie interfejsy w danej sieci lokalnej. Jako adres nadaw cy um iesz­
cza się adres interfejsu, który w ysyła ram kę. A dres nadaw cy nie pow inien być ad­
resem grupow ym ani rozgłoszeniow ym . Jeśli drugi bit adresu je st zerem , to jest to
adres adm inistrow any globalnie. W tedy kolejne 22 bity adresu są unikalnym kodem
producenta danego urządzenia (karty sieciow ej), a ostatnie 24 bity są unikalnym
num erem tego urządzenia nadaw anym przez producenta. W ten sposób zapew nia
się, że w jednej sieci nie znajdą się dw a interfejsy o tym sam ym adresie. Jeśli dru­
gi bit adresu je st jedynką, to je s t to adres adm inistrow any lokalnie. W tedy pozo­
stałe 46 bitów adresu m ożem y przydzielić w edług w łasnego uznania, pam iętając,
59
2.2. Ethernet
Tab. 2.2. Wybrane wartości pola typ ramki Ethernetu
W1
k
J
0x0800
IP wersfa 4
0x0806
ARP
0x8100
VLAN
0x86dd
IP wers)a 6
W2
I
Koncentrator
lub
przełącznik
W4
aby adresy w jed n ej sieci lokalnej się nie pow tarzały. D aw niej adresy sprzętow e j®
były zapisyw ane na stale w RO M urządzenia. O becnie najczęściej są zapisyw ane
w pam ięci Flash i m ogą być m odyfikow ane program ow o. Pam iętajm y, że w zapisie i
szesnastkow ym pierw szy bit adresu to najm łodszy bit pierw szego oktetu.
§
K olejnym polem ram ki je s t pole D LU G O ŚĆ -T Y P, które m ożna interpretow ać dwojako: jak o długość pola danych lub ja k o typ pola danych. Jeśli w tym polu je s t wartość od 46 do 1500, to należy go interpretow ać ja k o liczbę oktetów w polu danych,
Je.śli natom iast je s t tam w artość w iększa lub rów na 1536 (0x0600), to pole to należy
interpretow ać ja k o typ pola danych, określający protokół w arstw y w yższej przesylany w tej ram ce. Przykładow e, najczęściej spotykane typy pola danych są zam iesz­
czone w ta b e li 2.2. O protokołach tych piszę w ięcej w dalszej części tego rozdziału.
Jeśli pole D L U G O Ś Ć -T Y P je s t interpretow ane jak o długość danych, to typ danych
m oże być określony za pom ocą dodatkow ego nagłów ka, um ieszczonego w początku pola danych. W praktyce stosuje się w yłącznie ram ki z polem D LU G O ŚĆ -T Y P
interpretow anym ja k o typ. P oniew aż sprzęt je s t w stanie rozpoznać koniec nadaw ania ram ki, to długość pola danych nie musi być przesyłana.
Jeśli pole T Y P ma w artość 0x8100, to m am y do czynienia z ram ką sieci wirtualnej
(V LA N , ang. virtual local area n etw o rk), przedstaw ioną na ry s u n k u 2.6. Takie
ram ki um ożliw iają w ydzielenie w jed n ej sieci fizycznej wielu sieci w irtualnych,
rozróżnianych za pom ocą znacznika (ang. ta g ) V LA N . W łaściw e pole D ŁU G O ŚĆ -T Y P je st w tedy um ieszczone za tym znacznikiem .
>’
%
.■$,
:Ę
¡'
,1
ft
M
T
X
Pole danych może m ieć zm ienną długość, zależnie od ilości danych, które m ają być
przesiane. Pole danych nie m oże być krótsze niż 46 oktetów (42 oktety dla ram ek : j |
V LA N ). Jeśli je st mniej danych do przesiania, to pole danych je st uzupełniane zera-.'M
mi do m inim alnej długości. M inim alna długość pola danych w ynika z potrzeby za- | j |
pew nienia pew nej ustalonej m inim alnej długości ram ki, co je s t potrzebne do prawi- m
dlow ego w ykryw ania kolizji, o których poniżej. M aksym alny rozm iar pola danych (
ogranicza ilość danych, które m ożna przesiać w pojedynczej ram ce. M aksym alna
długość pola danych nazyw a się M T U (ang. m axim um transm ission unit) sieci. H
M TU Ethernetu w ynosi 1500 oktetów .
|J
O statnim polem ramki je st sekw encja kontrolna (ang. fr a m e check sequence). J e s t;;j j
ona liczona za pom ocą algorytm u C R C -32 (ang. cyclic redundancy check) opisanego | j |
w norm ie IEEE 802.3 i służy do w eryfikacji integralności ram ki. Sekw encja kontrolna ram ki je st w yliczana przez nadajnik i w eryfikow ana przez odbiornik sprzętow o. ■■
8 oktetów
6 oktetów
6 oktetów
PREAMBUŁA
ADRES
ODBIORCY
ADRES
NADAWCY
W7
Protokół przesyłany w polu danych
W artość w polu TYP
2 oktety
2 oktety
2 oktety
0x8100
ZNACZNIK
VLAN
"d ł u g o ś ć "
TYP
Rys. 2.6. Ramka Ethernetu ze znacznikiem VLAN
4 2 do 15 0 0 oktetów
4 oktety
DANE
SEKWENCJA
KONTROLNA
1 W6
----------
W5
Rys. 2.7. Topologia sieci Ethernet opartej o kabel skrętkowy
E thernet oparty na skrętce m a topologię gw iazdy, pokazaną na ry s u n k u 2.7. Każde
urządzenie sieciow e m a jed en port (interfejs sieciow y), za pom ocą którego łączy się
ze w spólnym centralnym urządzeniem w ieloportow ym , czyli koncentratorem (ang.
hub) lub przełącznikiem (ang. sw itch). W celu zbudow ania w iększej sieci koncentra­
tory i przełączniki m ożna łączyć ze sobą hierarchicznie. K oncentrator i przełącznik
różnią się zasadą pracy. K oncentrator je st urządzeniem biernym . K ażdą odebraną
ram kę retransm ituje do w szystkich sw oich portów , z w yjątkiem oczyw iście portu,
z którego ram kę odebrał. Przełącznik natom iast analizuje adresy w nagłów kach ra­
m ek i zapam iętuje adresy sprzętow e (M A C ) urządzeń podłączonych do poszczegól­
nych portów. Jeśli przełącznik w ie, do którego portu je st podłączony adresat ram ki,
to w ysyła ją tylko do tego portu. Poniew aż urządzenia m ogą zm ieniać port, do któ­
rego są podłączone, przełączniki nie pam iętają przyporządkow ania adresu do portu
w nieskończoność - jeśli urządzenie nie je s t aktyw ne przez pew ien ustalony czas, to
inform acja o jeg o adresie je s t zapom inana. Ponow na aktyw ność urządzenia odśw ie­
ża tę inform ację. Przełącznik m ożna zw ykle konfigurow ać, aby filtrow ał i separo­
wał ruch sieciow y m iędzy pew nym i portam i i tw orzyć w ten sposób sieci w irtualne.
P rzełączniki, w porów naniu z koncentratoram i, zm niejszają zbędny ruch w sieci.
O becnie w now o budow anych sieciach instaluje się w yłącznie przełączniki.
R ozw ażm y sytuację, gdy w centrum sieci z rysunku 2.7 je s t koncentrator.
K oncentrator retransm ituje natychm iast każdą odebraną ram kę do w szystkich por­
tów, oprócz tego, z którego tę ram kę odebrał. O znacza to, że żaden port nie m oże
jed n o cz eśnie nadaw ać i odbierać. Z atem w szystkie interfejsy pracują w trybie na­
przem iennym (ang. half-cluplex). Ponadto w danym m om encie tylko jed n o urządze­
nie podłączone do koncentratora m oże nadaw ać. Jeśli w ięcej niż jed n o urządzenie
nadaje, pow staje kolizja i żadna ram ka nie je s t popraw nie odbierana. M usi w ięc
istnieć ja k iś sposób spraw iedliw ego rozstrzygania o kolejności nadaw ania ram ek.
W E thernecie je s t stosow any rozproszony protokół bazujący na śledzeniu stanu do­
stępności m edium transm isyjnego i w ykryw aniu kolizji (C SM A /C D , ang. C arrier
Sense M ultiple A ccess with C ollision D etection). U rządzenie m oże rozpocząć nada­
w anie, gdy ustali, że żadne inne urządzenie nie nadaje przez ustalony w standardzie
czas odstępu m iędzyram kow ego (ang. interfram e gap). Jeśli jak ieś urządzenie roz­
pocznie nadaw anie ram ki, pozostałe odbierają ją (koncentrator rozsyła ją do w szyst­
kich) i w strzym ują się z nadaw aniem . Sygnały w sieci nie rozchodzą się jed n ak nie­
skończenie szybko. M oże się w ięc zdarzyć, że dw a urządzenia w ykryją, że m edium
je st w olne i rozpoczną nadaw anie praw ie rów nocześnie. Jednak po jak im ś czasie
oba stw ierdzą, że w ystąpiła kolizja. W tedy przestają nadaw ać. Po w ykryciu kolizji
każde urządzenie odczekuje pseudolosow y czas, zanim znów zacznie testow ać do­
60
2. Intersieci
stępność m edium . Pseudolosow ość zm niejsza szansę w ystąpienia ponow nej kolizji
i zapew nia spraw iedliw y dostęp do m edium . Po każdej kolejnej kolizji zw iększa-1
ny je st przedział w artości, z którego losow any je s t czas oczekiw ania na kolejna 5
próbę transm isji. Jeśli w ysianie ram ki nie pow iedzie się kilkanas'cie razy, ramka
jest porzucana. A by m echanizm w ykryw ania kolizji działał popraw nie, pierw szy bit 0
ram ki musi dotrzeć do najdalszego zakątka sieci E thernet, zanim zostanie wysiany |"
ostatni bit tej ram ki. N ależy przy tym uw zględnić opóźnienia w noszone przez kable 'i
i w szystkie interfejsy sieciow e po drodze. D latego w łaśnie w standardzie zdefiniow ano m inim alną długość ram ki. N ajkrótsza ram ka bez pream buły m a 64 oktety.
N ależy w yraźnie zaznaczyć, że kolizje nie są niczym negatyw nym , są nieodzowny £
częścią protokołu rozstrzygania o kolejności dostępu do m edium .
2.3.
2.3. IP - protokół intersieci
61
z początkow ych 24 bitów, a sufilcs to końcow e 8 bitów. M aski, podobnie ja k adresy,
zapisuje się za pom ocą notacji dziesiętnej z kropkam i. Pow yższa m aska jest więc
zapisyw ana jak o 255.255.255.0. K iedyś rozw ażano stosow anie m asek, w których
jedynki i zera m ogły się dow olnie przeplatać, ale obecnie takich m asek się nie uży­
wa. Z atem m askę m ożna jednoznacznie zdefiniow ać, podając liczbę od 0 do 32,
określającą liczbę jedynek znajdujących się na początku m aski. A dres w raz z m a­
ską zapisuje się alternatyw nie, podając tę liczbę po ukośniku. P rzykładow o napis
192.168.51.84/24 oznacza adres 192.168.51.84 z m aską 255.255.255.0.
R ozw ażm y teraz sytuację, gdy w centrum sieci je s t przełącznik. Sieć nadal może \
pracow ać w trybie half-duplex i stosow ać C SM A /C D . Jednak przełącznik umożli- j
w ia bardziej efektyw ne w ykorzystanie m edium . N ie rozsyła on każdej odebranei ;
ram ki do w szystkich portów. Interfejsy m ogą być teraz skonfigurow ane w trybii
jednoczesny m {¡mg. fu ll-d u p lex), czyli m ogą jed n o cześn ie nadaw ać i odbierać ram- ji!'
ki. N ie w ystępują kolizje i nie używ a się C SM A /C D . W E thernecie 1 G b/s i 10 Gb/s R?
w praktyce stosuje się tylko tryb jednoczesny.
Prefiks adresu w raz z m aską w yznacza pulę adresów, do której należą w szystkie
adresy m ające ten sam prefiks. Przykładow o 192.168.51.0/24 oznacza przedział ad­
resów od 192.168.51.0 do 192.168.51.255. Pew ne przedziały adresów m ają specjal­
ne znaczenie. A dresy 127.0.0.0/8, czyli adresy od 127.0.0.0 do 127.255.255.255, są
zarezerw ow ane dla tzw. pętli zw rotnej. A dresy te nie m ogą pojaw ić się w żadnej
sieci fizycznej. Pętla zw rotna jest fikcyjnym interfejsem sieciow ym , dostarczanym
przez oprogram ow anie stosu protokołów sieciow ych, stosow anym do testow ania
program ów - w szystko w ysłane przez ten interfejs w raca do niego. Z w ykle w tym
celu używ a się adresu 127.0.0.1. N astępujące pule adresów są zarezerw ow ane dla
intersieci pryw atnych i nie m ogą pojaw iać się w Internecie:
Interfejsy ethernetow e um ożliw iają zw ykle negocjow anie trybu pracy. W ybierany
je st tryb o najw iększej w spólnie obsługiw anej przepływ ności. Ponadto preferow anj '
jest tryb jednoczesny.
- od 10.0.0.0 do 10.255.255.255,
- od 172.16.0.0 do 172.31.255.255,
- od 192.168.0.0 do 192.168.255.255.
IP - protokół intersieci
Podstaw ow ym protokołem intersieci je s t IP (ang. Internet Protocol). M im o że daw ­
no tem u opracow ano ju ż je g o w ersję 6, obecnie nadal najpow szechniej używ ana .
je st w ersja 4, która je s t opisana w R FC 791 i przyjęto ja k o standard intersieci STD
5. W dalszej części książki pom ijam num er w ersji i jeśli piszę o IP, to należy do­
m niem yw ać w ersję 4.
IP definiuje adresy sieciow e, nazyw ane adresam i IP. A dres IP je s t przypisany do
interfejsu sieciow ego, a nie do urządzenia. Pojedynczy w ęzeł sieci (ang. nade, host)
m oże mieć w iele interfejsów i każdy z nich m a swój unikalny adres IP. Jednem u
interfejsow i m ożna przypisać w iele adresów IP. K ojarzenie adresu IP z w ęzłem
sieci, spotykane w zw rotach typu „adres IP kom putera” , w ynika stąd, że wiele
kom puterów (osobistych) ma tylko jed en interfejs sieciow y i w tedy taki zw rot jesi
jednoznaczny. A dres IP je st liczbą 32-bitow ą. Posługiw anie się zapisem dw ójko­
w ym jest niew ygodne, dlatego zw ykle stosuje się notacją dziesiętną z kropkam i
32 bity adresu dzieli się na 4 oktety. Każdy oktet zapisuje się ja k o liczbę dziesiętną.
Poszczególne liczby oddziela się kropką. Przykładow o adres 11000000 10101000
00110011 01010100 zapisuje się ja k o 192.168.51.84.
A dres IP składa się z prefiksu i sufiksu. Prefiks w yróżnia się za pom ocą maski,
która jest, tak ja k adres IP, liczbą 32-bitow ą. Pozycje bitów, na których w m asce jest
jedynka, to pozycje bitów adresu należące do prefiksu, a pozycje bitów, na których
w m asce jest zero, to pozycje bitów adresu należące do sufiksu. P rzykładow o m a­
ska 11111111 11111111 11111111 00000000 oznacza, że prefiks adresu IP składa się
Pula od 169.254.0.0 do 169.254.255.255 je s t przeznaczona na adresy lokalne, które
w ęzły m ogą sobie przydzielać autom atycznie, ale są to adresy nierutow alne, czyli
nie m ogą pojaw ić się w Internecie. A dresy od 224.0.0.0 do 239.255.255.255 są
adresam i grupow ym i (ang. m ulticast). A dres grupow y w skazuje w iele interfejsów
sieciow ych.
Intersieci buduje się z m niejszych sieci, nazyw anych podsieciam i, sieciam i fizycz­
nymi lub sieciam i lokalnym i. Podsieć m ożna zbudow ać ja k o sieć Ethernet. Podsieć
m ożna rów nież utw orzyć jak o sieć w irtualną, stosując technikę V LA N. Podsieci
łączy się za pom ocą ruterów. R uter (ang. router) to w ęzeł, który m a w iele interfej­
sów sieciow ych - po jednym w każdej łączonej podsieci. W sieciach w irtualnych
interfejsy rutera rów nież m ogą być w irtualne - jeden interfejs fizyczny może być
w spółdzielony przez w iele sieci w irtualnych. P rzykładow a intersieć je s t pokazana
na ry s u n k u 2.8.
W szystkie adresy IP w obrębie jednej podsieci m ają w spólny prefiks. Prefiks adresu
IP w yznacza adres tej podsieci. Sufiks adresu IP oznacza unikalny adres w pod­
sieci. Pulę adresów podsieci określa się, podając prefiks adresu IP i m askę, np.
192.168.51.0/24 oznacza adresy od 192.168.51.0 do 192.168.51.255. A dresu z sufiksem składającym się z sam ych zer nie przydziela się ze w zględów historycznych.
A dres z sufiksem składającym się z sam ych jed y n ek je s t adresem ukierunkow anego
rozgłaszania - adresatam i są w szystkie interfejsy w danej podsieci. Przykładow o
dla sieci 192.168.51.0/24 je s t to adres 192.168.51.255. A dres 255.255.255.255 jest
adresem rozgłaszania (ang. broadcast) w bieżącej podsieci. A dres, którego prefiks
składa się z sam ych zer, je s t zaw sze adresem w bieżącej podsieci, np. adres 0.0.0.84
w podsieci 192.168.51.0/24 w skazuje interfejs o adresie 192.168.51.84.
62
63
2.3. IP - protokół intersieci
2. Intersieci'
Tab. 2.3. Tablica tras węzła W1
Adres odbiorcy
Interfejs
Następny
1 0 .0 .0.0/24
ethO
Bezpośrednio
Dowolny
ethO
10.0.0,1
się w tym celu tablicą tras (ang. routing labie) i w ykonuje algorytm w yznaczania
tras, nazyw any też algorytm em trasow ania (ang. routing algorithm ). Szczególną
rolę w algorytm ie trasow ania odgryw ają rutery. W niektórych system ach ruter byw a
nazyw any bram ą (ang. gatew ay).
Przypuśćm y, że węzeł W1 chce w ysiać datagram IP do w ęzła W 2. Posługuje się
w tym celu sw oją tablicą tras, przedstaw ioną w tabeli 2.3. O program ow anie trasu­
ją c e p rzegląda pierw szą kolum nę tablicy tras, w iersz po w ierszu, w poszukiw aniu
w zorca zgodnego z adresem odbiorcy. W tym przypadku pierw szy w iersz opisuje
przedział, do którego należy adres w ęzła W 2. Po znalezieniu zgodności datagram
IP jest w ysyłany przez interfejs w ym ieniony w drugiej kolum nie tego w iersza do
następnego węzła, którego adres jest um ieszczony w trzeciej kolum nie. W rozw aża­
nym przypadku zostanie użyty jed y n y interfejs w ęzła W l, czyli ethO, a datagram IP
zostanie w ysiany bezpośrednio do w ęzła W 2. B ezpośrednie w ysłanie jest m ożliw e,
gdyż W l i W 2 są podłączone do w spólnego przełącznika. Pierw szy w iersz tablicy
tras w ęzła W l opisuje w łaśnie te węzły, do których W l m oże w ysyłać datagram y
IP bezpośrednio.
bezpośrednio rutery R1 i R2. A dresy w tej podsieci należą do puli 192.168.1.128/
30, czyli m ożna w niej rozdzielić tylko dw a adresy: 192.168.1.129 i 192.168.1.130.
Pierw szy z nich przydzielono intefrejsow i e lh l rutera R l, a drugi - interfejsow i
ethO rutera R2. W tej podsieci adresem rozgłaszania je s t 192.168.1.131, choć
m ało praw dopodobne, aby rozgłaszanie było w ykorzystyw ane w sieci dwuwęzlow ej. R uter R l ma jeszcze interfejs eth2, który łączy naszą przykładow ą sieć
z Internetem . Po praw ej stronie rysunku w idzim y podsieć 172.19.0.0/20. M ożna
w niej przydzielić 4094 adresy: od 172.19.0.1 do 172.19.15.254. A dresem rozgła­
szania jest 172.19.15.255.
i?
--i
.
V
.•
W ęzły końcow e sieci m ają po jed n y m interfejsie sieciow ym . K ażdy ruter m a co
najm niej dw a interfejsy. K ażdy interfejs pracujący w w arstw ie sieciow ej (patrz ry- ■
sunek 2.1) m a przypisany adres IP. Interfejsy (porty) przełączników P I i P2 ethernetow yeh nie m ają przypisanych adresów IP, gdyż przełącznik pracuje w warstwie
dostępu do sieci.
Pora teraz w yjaśnić, ja k IP przesyła dane w intersieciach. D ane do w ysiania pako­
w ane są w datagram y IP i w ysyłane w polu danych ram ki ethernetow ej, której pole /
T Y P ma w artość 0x0800 (patrz tabela 2.2). Ten proces nazyw a się kapsulkow aniem
(ang. eiicapsulrition). D atagram IP zaw iera w nagłów ku adres odbiorcy, na którego
podstaw ie w ęzeł podejm uje decyzję, co zrobić z tym datagram em . W ęzeł posługuje
R ozw ażm y teraz sytuację, gdy w ęzeł W l chce w ysłać datagram IP do w ęzła W 4.
N ie m oże tego zrobić bezpośrednio, bo w ęzły te są w różnych podsieciach. A dres
W 4 pasuje do w zorca adresów w drugim w ierszu tablicy tras w ęzła W l. Z w ykle
ostatni w iersz w tablicy tras opisuje dom yślne (ang. clefault) zachow anie algoryt­
mu trasow ania i obejm uje w szystkie adresy, które nie pasują do poprzednich w ier­
szy. W tym przypadku w ęzeł W l w yśle datagram na adres 10.0.0.1, czyli do rutera
R l. W datagram ie w ysyłanym do rutera adres odbiorcy to nadal adres docelow ego
odbiorcy, a nie rutera. Ruter, otrzym aw szy ten datagram , posłuży się w celu jeg o
dostarczenia sw oją tablicą tras, przedstaw ioną w tabeli 2.4. W tej tablicy tras ad­
res w ęzła W 4 pasuje do w zorca w drugim w ierszu i dlatego datagram IP zostanie
w ysiany przez interfejs etlil do kolejnego rutera o adresie 192.168.1.130, czyli do
rutera R2, który ju ż jest we w spólnej podsieci z w ęzłem W 4 i m oże dostarczyć
datagram IP bezpośrednio do odbiorcy.
Tablica tras rutera je st zazw yczaj bardziej rozbudow ana niż tablica tras w ęzła koń­
cow ego. W ęzłowi końcow em u w ystarczają zw ykle dw a w pisy - jed en dotyczący
podsieci, w której je s t ten w ęzeł, a drugi dom yślny, kierujący w szystkie datagram y
do rutera. R uter m a po jed n y m w pisie dla każdej bezpośrednio do niego podtączoTab. 2.4. Tablica tras rutera R1
Adres odbiorcy
Interfejs
Następny
10 .0 .0.0/24
ethO
Bezpośrednio
17 2.1 9 .0 .0 /2 0
ethl
19 2.1 6 8 .1 .1 3 0
1 9 2 .1 6 8 .1 .1 2 8 /3 0
ethl
Bezpośrednio
eth2
Bezpośrednio
eth2
212.85.125.1
. 2 1 2 .8 5 .1 2 5 .0 /2 4
Dowolny
64
2. Intersieći
31
WERSJA
[0:3]
D L NAGŁ.
[4:7]
ZNACZNIKI
[16:18]
IDENTYFIKACJA
[0:15]
CZAS ŻYCIA
[0:7]
DŁUGOŚĆ CAŁKOWITA
[16:31]
TYP OBSŁUGI
[8:15]
PROTOKÓŁ
[8:15]
PRZESUNIĘCIE FRAGMENTU
[19:31]
SUMA KONTROLNA NAGŁÓWKA
[16:31[
ADRES IP NADAWCY
[0:31]
ADRES IP ODBIORCY
[0:31]
Rys. 2.9. Podstawowy nagłówek datagramu IP
nej podsieci oraz po jed n y m w pisie dla każdej podsieci, która nie je s t b ezp o śred n io ’:
podłączona, ale ruter zna do niej trasę. R uter m a też zw ykle w pis dom yślny, który
kieruje do innego rutera. R uter nie musi znać tras do w szystkich podsieci - data
gram y do nieznanych podsieci przesyła tem u dom yślnem u ruterow i w nadziei, że l
tam ten zna trasę.
W w yżej przedstaw iony sposób rutery przekazują sobie datagram y IP, aż do pom yśl­
nego dostarczenia do odbiorcy lub w ystąpienia błędu - ruter na ścieżce m oże być ;
uszkodzony lub przeciążony, ruter m oże nie znaleźć w łaściw ego w pisu w tablicj
tras, interfejs m oże być w yłączony lub uszkodzony, dostarczanie na pew ne adresy
m oże być zablokow ane adm inistracyjnie itd. IP je s t usługą bezpołączeniow ą - dla
każdego datagram u trasa w inlersieci je st w yznaczana indyw idualnie. Teoretycznie
datagram y IP m iędzy tą sam ą parą w ęzłów m ogą poruszać się różnym i trasam i. IP
je s t usługą zaw odnego d o starczania w ram ach dostępnych m ożliw ości. O znacza to.
że oprogram ow anie IP stara się dostarczać datagram y, używ ając w szelkich dostęp­
nych tras, ale datagram y m ogą być gubione i dostarczane w innej kolejności niż
zostały w ysiane. T eoretycznie datagram y m ogą też być duplikow ane, czyli odbiorca
m oże dostać ten sam datagram w ięcej niż jed en raz.
D atagram IP składa się z nagłów ka i przesyłanej po nim zaw artości. Podstaw ow y
nagłów ek je s t pokazany na rysunku 2.9. Jest to typow y sposób przedstaw iania
struktur danych w intersieeiach, używ any w dokum entach RFC. Każdy w iersz re­
prezentuje kolejne 32 bity, czyli 4 oktety struktury. O ktety są w ysyłane wierszami
od góry do dołu, a w w ierszu od lew ej do praw ej. N um eracja bitów je s t od lewej
do praw ej - od 0 do 31. Jeśli ja k ie ś pole je s t interpretow ane ja k o liczba dw ójko­
w a, to najbardziej znaczący bit (M SB , ang. m ost significant bit) je s t pierw szy od
lew ej, a najm niej znaczący (LSB, ang. least significant b it) - pierw szy od prawej.
W ynika z tego, że liczby, których reprezentacja zajm uje w ięcej niż jed en oktet, są
w ysyłane w tak zw anym sieciow ym porządku oktetów, tożsam ym z porządkiem
grubokońców kow ym (ang. big-endian), czyli ja k o pierw szy jest przesyłany najbar­
dziej znaczący oktet, a ja k o ostatni - najm niej znaczący. Zauw ażm y, że sieciowa
kolejność oktetów je st odw rotna do kolejności oktetów stosow anej w kom puterach
osobistych o architekturze x86 i m ikrokontrolerach STM 32, które są maszynami ;
cienkokońców kow ym i (ang. little-eiulian). W rócę jeszcze do tego przy opisie ada­
ptacji biblioteki lw IP do architektury STM 32.
2.3. IP - protokół inlersieci
65
Pole W E R SJA zajm uje pierw sze 4 bity nagłów ka IP i je st w nim num er wersji,
czyli 4. Pole DL. N AG Ł. (ang. internet h eader length) zajm uje kolejne 4 bity i za­
w iera długość nagłów ka w w ielokrotnościach 4 oktetów. Podstaw ow y nagłów ek
m a 20 oktetów, więc w tym polu jest zw ykle liczba 5. N agłów ek m oże zaw ierać
dodatkow e opcje i być dłuższy, ale zaw sze je g o długość je st uzupełniana do w ie­
lokrotności 4 oktetów. Z atem pierw szy oktet nagłów ka IP zaw iera zw ykle wartość
szesnastkow ą 0x45. Pole T Y P O B SŁ U G I (ang. type o f service) określa priorytet
datagram u. Pole D ŁU G O ŚĆ C A Ł K O W IT A zaw iera sum aryczną długość nagłów ka
i zaw artości datagram u w oktetach. Poniew aż pole to je st 16-bitowe, m aksym alna
długość datagram u wynosi 65 535 oktetów , a m aksym alna długość jego zaw artości
nie m oże przekroczyć 65 515 oktetów.
K olejne trzy pola ID E N T Y FIK A C JA , Z N A C Z N IK I i PR Z E S U N IĘ C IE F R A G ­
M E N T U w ykorzystuje się podczas fragm entow ania i składania datagram ów IP.
M im o że datagram m oże m ieć m aksym alnie 65535 oktetów, m aksym alna jeg o
długość w konkretnej technologii dostępu do sieci nie m oże przekroczyć MTU
tej sieci. Przypom inam , że M T U E thernetu w ynosi zw ykle 1500 oktetów. Jeśli
zachodzi potrzeba w ysiania datagram u IP dłuższego niż M TU sieci, to taki data­
gram musi zostać podzielony na fragm enty o rozm iarach nie w iększych niż M TU.
S ytuacja taka m oże w ystąpić u pierw otnego nadaw cy datagram u lub w ruterze łą­
czącym sieci o różnych M TU . Po podzieleniu poszczególne fragm enty są przesy­
łane osobno. Składaniem tych części w całość zajm uje się końcow y odbiorca. Jest
to m ożliw e, gdyż w szystkie fragm enty datagram u IP m ają tę sam ą w artość w polu
ID E N T Y FIK A C JA . Pole P R Z E S U N IĘ C IE FR A G M E N T U (ang. fra g m e n t offset)
inform uje o położeniu fragm entu w oryginalnym datagram ie. Pole Z N A C ZN IK I
zaw iera dw a znaczniki:
-
nie fragm entuj - tego datagram u IP nie w olno fragm entow ać; jeśli ten datagram
je st za długi, należy go porzucić;
-
w ięcej fragm entów - inform uje, że to nie je s t ostatni fragm ent, pozw ala rozpo­
znać ostatni fragm ent.
P ole C ZA S Ż Y C IA (TTL, ang. tim e to live) określa, ile razy ten datagram IP m oż­
na przesiać przez sieć. K ażdy w ęzeł (zw ykle jest to ruter), przesyłając datagram
dalej, zm niejsza w artość tego pola o jed en . Jeśli w artość czasu życia osiągnie zero,
to datagram jest usuwany. C hodzi o to, aby datagram y, których nie można dostar­
czyć, nie krążyły w sieci w nieskończoność. D atagram m oże być niedostarczalny
np. z pow odu błędu w konfiguracji tablic tras w ruterach, skutkującego pow staniem
cyklu.
Pole PR O T O K Ó Ł zaw iera num er protokołu kapsulkow anego (przenoszonego)
w tym datagram ie IP. N ajczęściej spotykane w artości tego pola są zam ieszczo­
ne w tabeli 2.5. T C P i U D P są protokolarni w arstw y transportow ej. IC M P (ang.
Internet C ontrol M essage Protocol) je s t protokołem diagnostycznym w arstwy sie­
ciow ej i transportow ej, um ożliw iającym m iędzy innym i w ykryw anie problem ów
z trasow aniem . N a przykład kom unikat IC M P w ysyła się do pierw otnego nadaw cy
datagram u IP, jeśli datagram ten usunięto z pow odu upłynięcia jeg o czasu życia
- patrz też rozdział 3.8.
2.5. Sieć testowa
Tab. 2.5. Wybrane wartości pola PROTOKÓŁ nagłówka IP
W artość w polu PROTOKÓŁ
Kapsulkowany protokół
1
ICMP
6
TCP
17
UDP
w ego w oktetach i dla IP m a w artość 4. Pole O PER A C JA przyjm uje w artość 1 dla
prośby o przetłum aczenie adresu, a w artość 2 dla odpow iedzi na tę prośbę. K olejne
pola to odpow iednie adresy. D ługości tych pól są określone przez w artości pól DL.
A DR. SPR ZĘTÓ W , i DL. A DR. SIECIOW .
W ęzeł, chcąc w ysiać datagram IP do odbiorcy, którego adresu ethernetow ego nie
zna, rozgłasza do w szystkich w ęzłów w sw ojej podsieci prośbę A R P (w artość 1
w polu O PE R A C JA ). Prośba je s t w ysyłana za pom ocą sprzętow ego m echanizm u
rozgłaszania na adres elhernetow y ff ff ff ff ff ff. N adaw ca w ypełnia pola A DRES
SPR ZĘ T O W Y N A D A W C Y i A D R E S SIE C IO W Y N A D A W C Y sw oim i adresam i.
W polu A D R ES SIE C IO W Y O D B IO R C Y um ieszcza adres IP w ęzła, którego ad­
res ethernetow y chce otrzym ać. W prośbie zaw artość pola A DRES SPR ZĘ T O W Y
O D B IO R C Y je s t nieistotna. W ęzeł, który ma poszukiw any adres IP, odpow iada bez­
pośrednio pytającem u, gdyż zna je g o adres ethernetow y, bo przed chw ilą otrzyma!
od niego ram kę z prośbą. W odpow iedzi pole O PE R A C JA m a w artość 2. N adaw ca
odpow iedzi um ieszcza sw oje adresy w polach A D R ES SPR ZĘ T O W Y NAD AW CY
i A D R E S SIE C IO W Y NADAW CY. W polach A D R ES SPR ZĘ T O W Y O D B IO R C Y
i A D R ES SIE C IO W Y O D B IO R C Y um ieszcza odpow iednie adresy węzła, który
przysłał prośbę - te pola są kopiow ane z odpow iednich pól kom unikatu z prośbą.
Pole SU M A K O N TR O LN A N A G Ł Ó W K A służy do spraw dzania integralności n u -1
głów ka. Pola A D R ES IP N A D A W C Y i A D R E S IP O D B IO R C Y zaw ierają o d p o -fj
w iednie adresy, zgodnie z nazw am i tych pół.
ARP - tłumaczenie adresów sieciowych na adresy
sprzętowe
W poprzednim podrozdziale pom inąłem bardzo istotny problem . Napisałem ,
że w ęzeł m oże w ysłać datagram IP bezpośrednio do innego w ęzła (w tym rutera) w sw ojej podsieci, kapsułkując go w ram ce ethernetow ej. Pow staje probiem.
gdyż datagram y posługują się adresam i sieciow ym i IP, a E thernet używ a adresów
sprzętow ych M A C. Potrzebny je s t ja k iś m echanizm pozw alający w ęzłow i ustalić na
podstaw ie adresu sieciow ego odbiorcy je g o sprzętow y adres, który trzeba umieścić
w nagłów ku ram ki ethernetow ej. T łu m aczeniem adresów sieciow ych na sprzętowe
zajm u je się A R P (ang. Acldress R esolution P rotocol), opisany w R FC 826 i przyjęty
jak o standard intersieci STD 37. A R P m oże tłum aczyć adresy dow olnego protokołu
sieciow ego na adresy dow olnego protokołu sprzętpw ego. W dalszym ciągu ograni­
czam się do najbardziej interesującego nas przypadku, czyli do zam iany adresów IPna adresy ethernctow e.
K om unikat A R P podróżu je w polu danych ram ki ethernetow ej, która m a w polu typ
w artość 0x0806 (patrz tabela 2.2). Struktura kom unikatu A R P je st przedstaw iona
na ry s u n k u 2.10. Pole R O D Z A J A D R E SU SPR Z Ę T O W E G O dla E thernetu ma
w artość 1. Pole R O D Z A J A D R E SU SIE C IO W E G O dla IP m a w artość 0x0800.
Pole DL. A DR. SPRZĘTÓ W , określa długość adresu sprzętow ego w oktetach i dla
Ethernetu ma w artość 6. Pole D L. A D R . SIECIO W . określa długość adresu siecio31
RODZAJ ADRESU SPRZĘTOWEGO
[0:15]
DL. ADR. SPRZĘTÓW.
[0:7]
RODZAJ ADRESU SIECIOWEGO
[16:31]
D L ADR. SIECIOW.
[8:15]
OPERACJA
[16:31]
..
Sieć testowa
ADRES SPRZĘTOWY ODBIORCY (oktety 1 -2 )
ADRES SIECIOWY NADAWCY (oktety 3 - 4 )
[16:31]
[0:15]
ADRES SPRZĘTOWY ODBIORCY (oktety 3 -6 )
[0:31]
Rys. 2.10. Format komunikatu ARP dla Ethernetu i IP
G dyby ograniczyć się tylko do przedstaw ionego w yżej algorytm u, kom unikacja
byłaby bardzo nieefektyw na - w ysianie każdego datagram u IP w ym agałoby prze­
siania trzech ram ek ethernetow ych, w tym jednej rozgłoszeniow ej. A by popraw ić
efektyw ność kom unikacji, w ęzły utrzym ują pam ięć podręczną (ang. cache) ARP,
gdzie przechow ują poznane dotychczas przyporządkow ania adresów ethernetow ych
do adresów IP. W ystarczy w ięc tylko raz na początku kom unikacji zapytać o ad­
res ethernetow y. D odatkow o w ęzeł proszony o adres zapam iętuje w sw ojej pam ięci
podręcznej A R P pow iązanie adresu IP proszącego z je g o adresem ethernetow ym ,
gdyż prośba A R P poprzedza zw ykle w ysłanie datagram u IP i je s t w ysoce praw do­
podobne, że węzeł proszony o adres ethernetow y za chw ilę będzie m usiał odpo­
w iedzieć na otrzym any datagram - w ysianie prośby A R P je s t zw ykle początkiem
kom unikacji dw ukierunkow ej. P oniew aż w ęzły w sieci m ogą znikać i zm ieniać
adresy, to w pisy w pam ięci podręcznej A R P uaktualnia się co pew ien czas przez
w ysianie ponow nego zapytania oraz na podstaw ie analizy nagłów ków otrzym yw a­
nych ram ek, rów nież tych kierow anych do innych węzłów. Jeśli w ęzeł przestaje być
aktyw ny i nie odpow iada na prośby ARP, to dotyczący go w pis usuw a się z pam ięci
podręcznej ARP.
-
ADRES SPRZĘTOWY NADAWCY (oktety 1 -4 )
[0:311
ADRES SIECIOWY NADAWCY (oktety 1 -2 )
ADRES SPRZĘTOWY NADAWCY (oktety 5 - 6 )
[16:31]
[0:15]
ADRES SIECIOWY ODBIORCY (oktety 1 -4 )
10:31]
67
!
î
A by uruchom ić kolejne przykłady, potrzebujem y stw orzyć m ałą sieć testow ą. M ożna
ją zbudow ać w oparciu o zestaw Z L 29A R M z m ikrokontrolerem ST M 32F107, który
jest w yposażony w interfejs E thernet zgodny z norm ą IE E E 802.3-2002. W sam ym
m ikrokontrolerze je st w budow any układ M A C . U zyskanie w pełni funkcjonalnego
interfejsu w ym aga dołączenia PIIY. W zestaw ie Z L29A R M je s t gniazdo do w ło­
żenia. m odułu Z L3E T H z PH Y zrealizow anym na układzie D P83848C . Potrzebny
■nam je s t jeszcze kom puter w yposażony w kartę elhernetow ą z gniazdem RJ-45,
obsługującą 100B A SE-TX lub 10BASE-T. K om puter z m odułem ZL3E T H łączy
2.6. Przykład 2 - monitor sieci
2. Inlersieci
68
69
•s>
się za pom ocą kabla skrzyżow anego, ja k to pokazano na ry s u n k u 2.11. Niestety .®
nie w szystkie przykłady uda się przetestow ać w tak prostej sieci. A by sprawdzić .«
dynam iczne przydzielanie adresów , trzeba na kom puterze uruchom ić serw er Dl l( P.
Przykład 8 w ym aga dostępu do Internetu - aby go uruchom ić, kom puter musi miet
jeszcze jakiś' inny interfejs sieciow y, łączący go z Internetem . M oże to być np. draga karta E thernet, interfejs W i-Fi, m odem A D SL podłączony do USB lub modem
G SM . T rzeba w tedy na kom puterze uruchom ić funkcję rutera. Z apew ne lepszym ’§
rozw iązaniem jest zbudow anie małej sieci lokalnej.
Przykłady, które opisuję w tej książce, testow ałem w sieci przedstaw ionej na ry s u n ­
k u 2.12. Z budow ałem ją na bazie w ielofunkcyjnego urządzenia W R T54G L firmy
Linksys, która je s t częścią koncernu C isco. U rządzenie to je s t nazyw ane ruterem
dom ow ym , ale zaw iera znacznie w ięcej niż tylko ruter. W R T54G L zaw iera przełącznik ethernetow y, którego cztery porty w yprow adzone są na gniazda R J-45. Do
jed n eg o z nich podłącza się układ z m ikrokontrolerem . P ozostałe m ożna w ykorzystać do rozbudow y sieci i podłączenia kom puterów lub kolejnych m ikrokontrole­
rów. K om putery m ożna też podłączać bezprzew odow o, w ykorzystując w budow any
punkt dostępow y (ang. access p o in t) W i-Fi. K onfigurow anie ustaw ień sieciow ych
kom puterów w sieci testow ej, czyli uzyskiw anie adresu IP, m aski podsieci, adresu rutera i adresu serw era nazw (ang. D N S server) zapew nia zintegrow any serw er
D H C P (ang. D ynam ie H ost C onfiguration P rotocol). Sieć testow ą z Internetem łą­
czy ruter, będący centralną częścią W RT54G L. D ostęp do Internetu zapew nia niodem A D SL (ang. A sym m etric D ig ita l S ubscriber Line). R uter od strony Internetu
ma klienta DHCP, co um ożliw ia uzyskanie od dostaw cy Internetu (ang. Internet
service provider) potrzebnych ustaw ień sieciow ych. R uter m a w budow aną prostą
ścianę ogniow ą (ang. fire w a ll), która chroni sieć testow ą przed niektórym i zagroże­
niam i pochodzącym i z Internetu. C ałe urządzenie konfiguruje się za pom ocą prze­
glądarki internetow ej, łącząc się z w budow anym serw erem zarządzającym .
;
i
'
■
i
■ ;
i’|. jJ
•/ ;
■
;
; |
Rys. 2.12. Typowa domowa sieć lokalna
zarezerw ow ałem do konfigurow ania m anualnego. Adresy od 192.168.51.88 do
192.168.51.94 przeznaczyłem do konfigurow ania za pom ocą serwera DHCP. Adresem
ukierunkow anego rozgłaszania w tej sieci jest 192.168.51.95. Sieć testow a używa ad­
resów z puli prywatnej. Poniew aż adresy takie nie mogą pojaw iać się w Internecie,
trzeba zastosow ać ich konw ersję. Zastosow any ruter m a w budowaną usługę NAT
(ang. NetWork Address Translation). NAT polega na podm ienianiu „w locie” adresów
w nagłów kach datagram ów IP. Sieć testow a jest w idziana w Internecie, jakby była
pojedynczym w ęzłem końcow ym o adresie przyznanym przez dostaw cę Internetu.
D odatkow ą zaletą stosow ania NAT je st zw iększenie poziom u bezpieczeństwa. Węzły
sieci testowej m ogą inicjow ać kom unikację do Internetu, ale nie jest m ożliw e zaini­
cjow anie kom unikacji z Internetu do w ęzła sieci testowej.
W sieci testowej, której używ ałem , skonfigurow ałem pulę adresów 192.168.51.80/28.
A dres 192.168.51.81 przypisałem ruterow i. A dresy od 192.168.51.82 do 192.168.51.87
N a rynku je s t dostępnych w iele urządzeń funkcjonalnie podobnych do wyżej opi­
sanego. R óżnią się m .in. liczbą portów. M ogą m ieć w budow any m odem ADSL.
C zasem są też oferow ane przez dostaw cę Internetu „za złotów kę” .
2.6.
ZL29ARM
Rys. 2.11. Prosta sieć testowa
Przykład 2 - monitor sieci
Jako przykład kończący ten rozdział proponuję napisanie prostego m onitora sieci.
B ędzie on w yśw ietlał na LCD inform acje o ram kach ethernetow ych i protokołach
przenoszonych przez te ram ki. Jeśli sieć zbudow ana jest w oparciu o koncentrator,
to m am y szansę oglądać w szystkie ram ki. JesTi zaw iera przełącznik, to zobaczym y
tylko te ram ki, które przełącznik w yśle do naszego m onitora. Ekran LCD , którym
71
2.6. P rzykład 2 - m onitor sieci
Tab. 2.6. Pliki przykładu 2
Źródłow e 1 biblioteczne
ex eth.c
lont5x8.c
startup slm 32_cld.c
board init.c
board led ks0108.c
board led.c
Iibstm32f10x.a
Nagłów kow e
•
font5x8.li
util delay, c
util led.c
util led.c
util_delay.h
u tiljc d .h
u tilje d .li
board_det.h
board_dels.li
b o a rd jn it.h
boardJ c d .h
board led.h
Nr kolejny ramki
D ługość ramki
Kom unikat ARP
Prośba ARP
Datagram IP
TCP
Jeef
| IFfFfCffffEffH
►lOOOG] 119 2.168 ."5 1 .88p
; - » fo o o il (1 9 2 . 168 .51 . B2\‘‘ ID
00003943ee£6
^ ( T T l lQ 0 2 5 9 c 4 4 0 c d d h HOBOOl 192 .1 6 8 . 51 . 88
—— ►i61 1 1 9 3 . 0 . 9 6 . 21-»____
stm 32f10x_cont.h
- A dres ethernetowy nadawcy
- R am ka rozgłoszeniowa
- Adres IP nadawcy
- A dres IP, o którego adres
ethernetowy je st prośba
~ Adres ethernetowy odbiorcy
- Adres IP odbiorcy
Rys. 2.13. Wynik działania monitora sieci
dysponujem y, nie je s t w ielki i m ieszczą się na nim tylko inform acje o dw óch ostat­
nio odebranych ram kach. W ys'w ietlane są: num er kolejny odebranej ram ki ethernc-1
tow ej, jej długość i pola z nagłów ka, czyli ethernetow y adres odbiorcy, ethernetowy^
adres nadaw cy oraz zaw artość pola dlugość-typ. Jeśli ram ka zaw iera datagram IP,\
to dodatkow o w yśw ietlane są: protokół kapsulkow any w tym datagram ie or:
resy IP nadaw cy i odbiorcy. Jeśli ram ka zaw iera kom unikat ARP, to dodatkowo.,,
w yśw ietlane są: o peracja A R P o raz adresy IP. N a LCD pow inniśm y zobaczyć obi a/
podobny do przedstaw ionego na rysu n k u 2.13.
W tabeli 2.6 zaw arto nazw y plików , które należy podać kom pilatorow i ja k o pliki;;
źródłow e tego przykładu. Ponadto zaw iera ona nazw y tych w ykorzystyw anych u
tym przykładzie plików nagłów kow ych, które znajdują się w podkatalogu ./exam - ;
pies/include. W kolejnych podrozdziałach prezentuję now e pliki, których opis nie
pojaw ił się w poprzednim rozdziale. P oniew aż używ am y w yśw ietlacza graficznego,
to w zestaw ie Z L 29A R M należy ustaw ić zw orkę D ISPLA Y w pozycji GRAPH.
Ponadto w m odule Z L 3E T H trzeba ustaw ić zw orkę PW R _D N w pozycji uC, co
w yjaśniam pod koniec n astępnego podrozdziału.
2.6.1.
Pliki boardJ n it h i boardJ n iL c
Pliki b o a r d jn it.h i bo ardJ n it .c o dpow iadają za zainicjow anie w ejść-w yjść binar­
nych, skonfigurow anie taktow ania m ikrokontrolera i m odułu ethernetow ego ora/
uruchom ienie interfejsu M II (lub RM1I) m iędzy m ikrokontrolerem a modułem
ethernetow ym . Inicjow anie niektórych układów m ikrokontrolera, np. oscylatorów,
w ym aga pew nego czasu. C zęsto nie m ożna w ykonyw ać dalszej części programu,
zanim nie zakończy się u rucham ianie takiego układu. Z reguły najprościej je s t po­
czekać aktyw nie na zakończenie tego procesu. W tym celu w pliku b o a rd jn it.h
definiujem y m akro a c tiv e _ c h e c k .
jfdefine active_check(cond, limit) |
int. i;
for (i = (limit); ¡(cond); — i)
if (i <= 0)
return -1;
}
\
\
\
\
\
M akro to spraw dza w pętli, czy je s t spełniony w arunek cond. W arunek dobieram y
tak, aby przyjął w artość niezerow ą, gdy urucham ianie zakończy się pow odzeniem .
W tedy m akro kończy działanie. Ż eby je d n ak m akro nie zapętlilo się w nieskończo­
ność, liczba spraw dzeń je s t ograniczona param etrem l i m i t . Jeśli lim it spraw dzeń
zostanie przekroczony, m akro pow oduje zakończenie bieżącej funkcji z błędem .
Przyjm ujem y często stosow aną konw encję, że funkcja zw raca zero, gdy kończy się
sukcesem , a w artość ujem ną, gdy w ystąpił błąd. Przykłady użycia tego m akra zo­
baczym y niżej.
Pliki b o a r d jn it.h i board J n it .c udostępniają następujące funkcje:
void AllPinsDisable(void);
int CLKconfigure(void);
int ETHconfigureMII(void);
void ETHpowerDown(void);
void ETHpowerUp(void);
Funkcja A łlP in s D is a b le konfiguruje w szystkie w yprow adzenia m ikrokontrolera
ja k o w ejścia analogow e (ang. analog input m ode). W yłączone zostają w ejściow e
bram ki Schm itta (ang. Schm itt trigger off), co zm niejsza pobór prądu przez m ikro­
kontroler i zw iększa odporność układu na zakłócenia elektrom agnetyczne. Funkcję
tę w yw ołujem y na początku program u, a potem konfigurujem y tylko używ ane w y­
prow adzenia - te nieużyw ane pozostaną w ejściam i analogow ym i.
B iblioteka ST M 32 udostępnia porty w ejścia-w yjścia poprzez stale GPIOA, GPIOB
itd. P oszczególne m odele m ikrokontrolerów m ają różną liczbę portów. Czasem
chcem y iterow ać po w szystkich portach w ejścia-w yjścia, ja k na przykład w funkcji
A llP in s D is a b le , ale chcem y też uniezależnić program od liczby portów. W tym
celu deklarujem y w pliku b o a r d jn it.h tablicę g p io zaw ierającą identyfikatory
w szystkich portów oraz stalą gpioC ount określającą liczbę portów.
extern GPIO_TypeDef * const gpio[];
extern const int gpioCount;
Teraz m ożem y odw oływ ać się do kolejnych portów, pisząc g p io [ 0 ] , g p i o [ l ] , ...,
g p io [ g p io C o u n t- l] . D efinicje tablicy g p io i stałej gpioC ount znajdują się w pliku
board J n it.c . D la ST M 32F107V C , który m a pięć portów w ejścia-w yjścia, są one
następujące:
GPIO_TypeDef * const g p i o U = IGPIOA, GPIOB, GPIOC, GPIOD, GPIOEI;
const int gpioCount = sizeoffgpio} / sizeof(gpio(O));
Funkcja C LK configure konfiguruje oscylator kw arcow y m ikrokontrolera, pętle
fazow e (PLL, ang. phase locked loop) oraz sygnały taktujące rdzeń i peryferie,
w tym m oduł ethernetow y. D ystrybucja sygnałów zegarow ych w ST M 32F107 jest
w uproszczony sposób przedstaw iona na rysunku 2.14. Rdzeń je st taktow any sy­
gnałem H C L K , którego m aksym alna częstotliw ość w ynosi 72 M H z. Peryferie są
taktow ane, sygnałam i PCLK1 i PC LK 2 otrzym yw anym i z H C LK za pom ocą dziel­
ników w stępnych (ang. prescalers) APB1 i A PB2. Sygnał IIC L K otrzym yw any jest
2. lntersie
72
2.6. Przykleili 2 - monitor sieci
73
z w yjścia dzielnika A H B , na którego w ejście podaw any je st sygnał SY SCLK . M oże
to być sygnał 8 M H z z w ew nętrznego oscylatora RC HSI (ang. high speed internal)
- tak dzieje się po w łączeniu zasilania lub po w yzerow aniu m ikrokontrolera, sy­
gnał U SE (ang. high sp eed external) z oscylatora kw arcow ego lub sygnał PLLC LK
z w yjścia PLL1. Do w ejścia PLL1 m ożna dołączyć sygnał HSI podzielony przez
2 lub sygnał z w yjścia dzielnika PRED1V1. Do w ejścia dzielnika PRED1V1 m oż­
na dołączyć sygnał H SE lub sygnał PL L 2C L K z w yjścia PLL2. Na w ejście PLL2
podaw any je s t sygnał H SE przez dzielnik PR ED IV 2. D obierając w artości w spół­
czynników podziału i m nożniki pętli fazow ych, m ożem y uzyskać w iele różnych
częstotliw ości taktow ania rdzenia.
Sygnał potrzebny do taktowania m odułu etliernetow ego m ożna uzyskać z wyjścia
M C O (ang. m icrocontroller clock output), na które m ożna podać następujące sygnały:
SY SCLK , HSI, HSE, PLLCLK podzielony przez 2, PLL2C LK , PLL3CLK, PLL3CLK
podzielony przez 2, XT1 bezpośrednio z w yprow adzenia kwarcu. Sygnał PLL3CLK
pochodzi z wyjścia pętli fazowej PLL3, która ma w spólne w ejście z PLL2.
Funkcja C LK configure zw raca zero, gdy zakończyła się sukcesem lub w artość
ujem ną, gdy nie udało się w ystartow ać oscylatora kw arcow ego lub któraś pętla fa­
zow a się nie zsynchronizow ała. K onfigurow anie zaczynam y od przyw rócenia usta­
wień dom yślnych. N astępnie próbujem y uruchom ić oscylator kw arcow y HSE. Jeśli
się nie udało, funkcja kończy działanie, sygnalizując błąd.
RCC_DeInit();
j
RCCJISEConf ig(RCC_HSE_ON ) ;
if (RCC_WaitForHSEStartUp() == ERROR)
return -1;
O program ow anie sieciow e w ym aga stosunkow o dużej m ocy obliczeniow ej. Aby
uzyskać krótkie czasy reakcji m ikrokontrolera, będziem y taktow ać rdzeń z m aksy­
m alną dopuszczalną częstotliw ością, czyli 72 M Hz. N iestety przy tej częstotliw ości
pam ięć Flash nie m oże dostatecznie szybko dostarczać kolejnych instrukcji do w y­
konania i aby odczyty z Flash nie stanow iły w ąskiego gardła, należy w łączyć bufor
w stępnego ładow ania instrukcji (ang. prefetch buffer). Ż eby pam ięć Flash w ogóle
działała przy tej częstotliw ości, trzeba jej ustaw ić dw a cykle opóźnienia (ang. la­
tency).
HSI
HS1 8 MHz
FLASH_PrefetchBu£ferCmd(FLASH_PrefetchBuf ferJSnable);
FLASH_SetLatency{FLASH_Latency_2);
Rys. 2.14. Uproszczony schemat dystrybucji sygnałów taktujących w STM32F107
Aby uzyskać sygnał H CLK o częstotliw ości 72 M H z, ustaw iam y dzielnik AHB na
1. Sygnały PCLK1 i PC LK 2 m ogą m ieć m aksym alne częstotliw ości odpow iednio
36 i 72 M H z, dlatego ustaw iam y w artości dzielników APB1 i A PB2 odpow iednio
na 2 i 1.
RCCJiCLKConfig(RCC_SYSCLK_Divl) ;
RCC_PCLKlConfig(RCC_HCLK_Div2) ;
RCC_PCLK2Con fig(RCCJICLK_Divl);
Zakładam y, że oscylator kw arcow y H SE m a częstotliw ość 5, 10, 15, 20 lub 25 M Hz.
Sygnał z tego oscylatora przez dzielnik RREDIV2 je s t podaw any na w ejście PLL2.
W artość dzielnika RCC_PREDIV2_DivX dobieram y tak, aby na w ejściu PLL2 mieć
zaw sze sygnał o częstotliw ości 5 M Hz. M nożnik PL L 2M U L ustaw iam y na 8, za-
2.6. Przykład 2 —monitor sieci
2 . Intersiec i
74
75
RCC_MCOCotlfig (RCC_MCO_PLL3CLK_Div2) ;
tem na w yjściu PL L2 uzyskujem y sygnał P L L 2C L K o częstotliw ości 4 0 MHz,
N astępnie w łączam y PL L 2 i czekam y na jej zsynchronizow anie się.
Jeśli konfigurow anie sygnałów taktujących zakończy się pow odzeniem i w szystkie
oscylatory się zsynchronizują, funkcja C LK configure kończy działanie, zw racając
zero.
Sdefine RCC_PREDIV2_DivX RCC_PREDIV2_Div2
RCC_PREDIV2Config(RCC_PREDIV2_DivX);
RCC_PLL2Con£ig(RCC_PLL2Mul_8);
RCC_PLL2Cmd(ENABLE);
active_check(RCC_GetFlagStatus(RCC_FLAG_PLL2RDY), maxAttempt5);
Jeśli PL L2 się nie zsynchronizuje, m akro a c tiv e _ c h e c k zakończy działanie funkcji, ■
sygnalizując błąd. L im it spraw dzeń definiujem y jak o stałą m axA ttem pts.
static const int maxAttempts = 1000000;
Sygnał PL L2C L K podajem y na w ejście dzielnika P R E D IV I, który ustaw iam y na .k
5. Z atem na w yjściu d zielnika PR ED IV 1 m am y sygnał o częstotliw ości 8 MHz.-;Jf.
Sygnał ten podajem y na w ejście P L L l. M nożnik P L L M U L ustaw iam y na 9, aby
uzyskać na w yjściu P L L l sygnał PL L C L K o częstotliw ości 72 M H z, p o czym cze-;,-|
kam y na zsynchronizow anie się P L L L
Funkcja ETH configureM Il konfiguruje interfejs m iędzy układem M A C w m i­
krokontrolerze a zew nętrznym PHY. M oże to być interfejs M II lub RM II. Każdy
z tych interfejsów m ożna skonfigurow ać na dw a sposoby: z dom yślnym albo al­
ternatyw nym (ang. rem aped) rozkładem w yprow adzeń. Szczegóły są w tabeli 2.7.
W yprow adzenia oznaczone literą I konfiguruje się jak o w ejścia pływ ające. Na w y­
prow adzeniach oznaczonych literą O należy skonfigurow ać funkcję alternatyw ną
z w yjściem przeciw sobnym 50 M Hz.
M II używ a 17 sygnałów :
-
M II_C O L (ang. collision d etect) - w ystąpienie kolizji w trybie naprzem iennym
(ang. h alf-duplex),
-
M II_C R S (ang. carrier sense) - obecność nośnej, czyli sygnału w m edium (ang.
non-idle),
-
M II_ R X D 0 .. .M I1_RXD3 (ang. receive data) - czterobitow a szyna odbiorcza,
Jako sygnał SY SC L K , podaw any na w ejście dzielnika A H B , w ybieram y sygnał
PL LC L K z w yjścia P L L l i czekam y na synchronizację.
-
M 1I_RX _CLK (ang. receive clock) - zegar szyny odbiorczej, 25 M H z dla
100 M b/s lub 2,5 M H z dla 10 M b/s,
RCC_SYSCLKCon£ig(RCC_SYSCLKSource_PLLCLK);
active_check(RCC_GetSYSCI,KSource() = = 0 x 0 8 , maxAttempts) ;
-
M II_R X _D V (ang. data valid) - na szynie odbiorczej są dane do odczytania,
RCC_PREDIVlConfig(RCC_PREDIVl_Source_PLL2, RCC_PREDIVl_Div5);
RCC_PLLCon£ig(RCC_PLLSource_PREDIVl, RCC_PLLMul_9);
RCC_PLLCmd(ENABLE);
active_check(RCC_GetFlagStatus(RCC_FLAG_PLLRDY), maxAttempts);
i;
'i,
M ikrokontroler ST M 32F 107 o bsługuje dw a w arianty interfejsu m iędzy M A C a PHY:
M II (ang. M edia Independent In terfa ce ) i R M II (ang. R ed u ced M edia Independent y
Interface). M II w ym aga taktow ania sygnałem o częstotliw ości 25 M H z, a RMII
- 50 M H z. W artości tych częstotliw ości w ynikają z szerokości szyn danych w tych
interfejsach, co stanie się ja sn e po przeczytaniu dalszej części tego podrozdziału. 5
Jeśli potrzebujem y na M C O sygnału 25 M H z i m am y akurat taki kw arc, to najpro­
ściej je s t użyć sygnału H SE lub X T1.
-
MII_RX__ER (ang. receive error) - odebrano błędny sym bol w trybie 100 M b/s,
-
M II__TX D 0...M II_TX D 3 (ang. transm it data) - czterobitow a szytia nadaw cza,
Tab. 2.7. Warianty konfiguracji MII/RMII w STM32F107
Sygnał M II
Sygnał R M II
Kierunek
MII C0L
I
MII CRS
I
W yprowadzenie
domyślne
W yprowadzenie
alternatywne
PA3
PAO
'Jj
;f§
MII RXD0
RM II RXD0
I
PC4
PD9
MII RXD1
RMII RXD1
I
PC5
PD10
W przeciw nym przypadku trzeba w ykorzystać PLL3. Poniew aż PL L 2 i PLL3 1
m ają w spólny dzielnik w stępny PR ED IV 2, w yżej opisana konfiguracja sprawia, >
że na w ejściu PLL3 m am y sygnał 5 M H z z tego dzielnika. U staw iam y
m nożnik m
PL L 3M U L na 10, dzięki czem u na w yjściu PLL3 dostajem y sygnał PL L3C L K
•
o częstotliw ości 50 M H z. N astępnie czekam y na zsynchronizow anie się PLL3.
MII RXD2
I
PB0
PD11
MII RXD3
I
PB1
RCC_MCOConfig(RCCJCO_HSE);
RCC_MCOConfig(RCC_MC0_XT1);
RCC_PLL3Con£ig(RCC_PLL3Mul_10);
RCC_PLL3Cmd(ENABLE);
active_check(RCC_GetFlagStatus{RCC_FLAG_PLL3RDY), maxAttempts);
■
)
Jeśli używ am y PH Y z interfejsem R M II, to na M C O podajem y bezpośrednio sygnał
PLL3C LK .
RCC_MCOConfig(RCC_MC0_PLL3CLK);
Jeśli używ am y PH Y z interfejsem M II, to na M C O podajem y sygnał PLL3C LK
przez dzielnik o w spółczynniku 2.
;
MII RX CLK
RMII REF CLK
I
MII RX DV
RMII CRS DV
I
MII RX ER
PD12
PA1
PA7
PD8
I
PB10
MII_TXD0
RM II TXD0
0
PB12
MII TXD1
RMII TXD1
0
PB13
MII TXD2
0
PC2
MII TXD3
0
PB8
MII TX CLK
MII TX EN
RMII TX EN
I
PC3
0
PB11
M D I0
0
PA2
. MDC
0
PC1
76
-
77
2.6. Przykład 2 - monitor sieci
2 . Intersieci'È
M 1I_TX_CLK (ang. transm it d o c k ) - zegar szyny nadaw czej, 25 M H z dlai|
100 M b/s lub 2,5 M H z dla 10 M b/s,
M11_TX_EN (ang. transm it enable) - na szynie nadaw czej są dane do wysiania,i;
M D IO (ang. m anagem ent d a ta input/outpnt) - dw ukierunkow a linia danych in­
terfejsu służącego do konfigurow ania układu PHY,
M D C (ang. m anagem ent data d o c k ) - linia taktująca interfejs M D IO .
a
H O F
a: o a:
2
O
d d
cc a
Sygnał zegarow y na liniach M 1I_RX _C LK i M II_T X _C L K jest generow any prze/
PHY. Jego częstotliw ość w ynika z szybkości przesyłania danych (10 lub 100 MbA ^
i szerokości szyny danych (4 bity). RM1I używ a tylko 9 spośród w yżej opisanych'.-;'
sygnałów. Poniew aż w RM1I dane są przesyłane szynam i dw ubitow ym i, sygnał ze
garow y R M II_R E F _C L K musi m ieć częstotliw ość 50 M Hz.
Zależnie od w ybranego wariantu konfiguracji M II lub RM1I funkcja ETHconf igureMi;
w yw ołuje jed n ą z czterech funkcji konfiguracyjnych:
static
static
static
static
void
void
void
void
ETHinterfaceMIIconfigure(void);
ETilinterfaceRemapedMIIconfigure (void) ;
ETHinterfaceRMIIconfigure(void);
ETHinterfaceRemapedRMIIconfigure(void);
LQ_
■(.£
Schem at m odułu ethernetow ego Z L 3E T H je st przedstaw iony na ry s u n k u 2.15, ÿ
N atom iast sposób je g o podłączenia w zestaw ie Z L 29A R M znajduje się na rysun- ;V
k u 2.16. Jak w idać, zastosow ano M II z alternatyw nym układem wyprowadzeń, $
D latego zaim plem entow ano tylko funkcję ETHinterfaceRemapedMIIconfigure. Im­
plem entację pozostałych funkcji pozostaw iam jak o ćw iczenie C zytelnikow i, który
będzie ich potrzebow ał.
K onfigurow anie M il rozpoczynam y od w łączenia taktow ania peryferii i ustawienia
w łaściw ego w ariantu interfejsu.
i;>|
<-81=1
X <N -T-
Q,
Z h -1
2B
29
30
31
32
33
34
35
36
2 o, a, y at. %
to ; to
N astępnie konfigurujem y w yprow adzenia zgodnie z tabelą 2.7, a na koniec wy­
prow adzenie sygnału zegarow ego M C O (PA8). D la M II z alternatyw nym układem
w yprow adzeń odpow iedni fragm ent funkcji ETHinterfaceRemapedMIIconfigure
w ygląda następująco:
GPIO_InitTypeDef GPI0_InitStructure;
GPI0_InitStructure.GPI0_Mode = G PI0_M ode_IN_FL0ATING ;
GPI0__InitStructure.GPI0_Speed = 0;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 i GPI0_Pin_l | GPI0_Pin_3;
GPI0_Init(GPIOA, ŁGPIO_InitStructure);
GPIO_InitStructure.GPI0_Pin = GPIO_Pin_10;
GPI0_Init (GPI0B, &GPI0__InitStructure) ;
GPI0_InitStruciure.GPI0_Pin = GPIO_Pin_3;
GPÎ0 Init(GPI0C, &GPI0 InitStructure);
5
4
3
2
1
eaxi
zaxi
ta x i
oaxi
N3 X I
X1D X I
O Q O O zrr»
GND
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPI0A |
RCC_APB2Periph_GPI0B I
RCC_APB2Periph_GPI0C |
RCC_APB2Periph_GPI0D |
RCC_APB2Periph_AFI0,
ENABLE);
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_ETH_MAC |
RCC_AHBPeriph_ETH_MAC_Tx |
RCC_AIIBPe riph_ETH_MAC_Jtx,
ENABLE);
GPI0_PinRemapCon£ig (GPIG__Reniap_ETH, ENABLE) ;
GPIOJSTHJfedialnterfaceConfig (GPIO_BTH_MediaInterface_MII) ;
LED SPD
LED LINK
nRST
MDIO
MDC
"1
RESERVED
RESERVED
RESERVED
RESERVED :
RESERVED
PW R_D OW N/INT
TX D 3 7S N LM 0D E
TX D_2
TXD 1
TXD 0
‘
TX EN
TX CLK
Rys. 2.15. Schemat modułu ZL3ETH
2.6. Przykład 2 - monitor sieci
GPIO_InitStructure.GPIO_Pin = GPIO Pin_8 | GPIO_Pin_9 |
GPIO~Pin_10 t GPIO_Pin_l1 I
GPI(Tpin_12;
GPIO__Init(GPIOD, &GPIO_InitStructure);
GPIO_InitStructure.GPIO_Mode = GPIO_Mode___AF_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;
GP10_Init(GPIOA, &GPIO_InitStructure);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_ll I
GPIO__Pin_12 | GPIO_Pxn_13;
GPIO_Init (GPIOB, &GPIO_InitStructure);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_l I GPIO_Pin_2;
GPIO__Init (GPIOC, SGPIO_I ni tStructure) ;
GPIO_InitStructure.GPXO_Pin = GPIO_Pin_8;
GPIO_Init(GPIOA, &GPIO_InitStructure);
D P83484C pobiera typow o 14 mA. W ten tryb m ożna go w prow adzić, podając ni­
ski poziom na w yprow adzenie PW R D O W N . W yprow adzenie to je st podłączone do
w yjścia inw ertera. Jeśli zw orka PW R _D N (JP3) w m odule ZL3E T H je s t w pozycji
O ff (2 -3 ), na w ejściu tego inw ertera je s t w ym uszony poziom niski, co w ym usza
na w ejściu PW R D O W N stan w ysoki i m oduł Z L3E T H jest zaw sze w stanie ak­
tyw nym . U staw ienie zw orki PWR__DN w pozycji uC (1 -2 ) um ożliw ia program ow e
sterow anie trybem oszczędzania prądu. Do w ejścia inw ertera je st podłączone w y­
p row adzenie PCO m ikrokontrolera. W yprow adzenie to konfigurujem y jak o w yjście
z otw artym drenem . Jeśli podajem y na nie stan niski, m oduł ZL3E T H je st w stanie
aktyw nym . Jeśli w yprow adzenie PCO je s t w stanie w ysokiej im pedancji, rezystor
na w ejściu inw ertera w ym usza, że m oduł Z L 3E T H je s t w stanie niskiego pobo­
ru prądu. W yprow adzenie PCO jest w stanie w ysokiej im pedancji, zanim zostanie
skonfigurow ane, a rów nież wtedy, gdy układy peryferyjne m ikrokontrolera nie są
zasilane, co pow oduje autom atyczne w yłączanie m odtilu Z L3E T H , gdy m ikrokon­
troler przestaje być zasilany lub gdy przechodzi w tryb oszczędzania prądu z w y­
łączonym i peryferiam i. W yprow adzenie PCO konfiguruje się za pom ocą funkcji
ETHpowerConfigure.
M oduł ZL3E T H m ożna w prow adzić w £ryb niskiego poboru prądu (ang. p o w e r clown
m odę). Byw a to istotne w urządzeniach zasilanych bateryjnie. Interfejs E thernet po­
biera niestety sporo prądu. W edług danych katalogow ych układu D P83484C , za­
stosow anego w Z L 3E T H , w trybie 10 M B /s pobiera on typow o 92 m A, a w trybie
100 M b/s - typow o 81 m A. D o tego jeszcze kilka m A pobierają diody sfwiecące
zainstalow ane w gnieździć RJ-45. N atom iast w trybie niskiego poboru prądu układ
static void ETHpowerConfigure(void);
Pow yższa funkcja je st zadeklarow ana ja k o s t a t i c , poniew aż je s t używ ana tyl­
ko w ew nątrz jednostki translacji. Z asilanie m odułu ethernetow ego w łącza funk­
cja ETHpowerUp. Przełączenie w tryb oszczędzania prądu w ykonuje funkcja
ETHpowerDown.
S TM 3 2F 1 0 7V C
RXD1
RXD2
RXD3
RX ER
—
1
—
—
57
58
59
47
t
RX C LK
R X DV
TX CLK
24
55
18
M D IO
25
MDC
CRS
CDI
.
PD9
PD10
PD11
PD12
N a zakończenie sw ojego działania funkcja ETH configureM II w łącza zasilanie m o­
dułu Z L 3E T H , a następnie w ykonuje zerow anie interfejsu ethernetow ego. Jeśli
zerow anie się pow iodło, funkcja zw raca zero, w przeciw nym przypadku zw raca
w artość ujem ną, sygnalizującą błąd.
ż
PC3
PA2
ETHpowerConfigure();
ETHpowerUp0 ;
ETiI_DeInit{);
ETH_SoftwareReset();
active_check(ETH GetSoftwareResetStatus{) == RESET, maxAttempts);
return 0;
16
P C I?
23
PAO
26
,
PA3
C O N 12/JP 2
---
TX D1
TX D 2
TX D 3
t
,
,
P B12
53
P B13
17
PC2
95
P B 8 !*
25 M H z
T X EN
,
48 PAB
PB11
PWRDW N
,
Funkcje i stałe, których nazw y zaczynają się od ETH_, są zdefiniow ane w bibliote­
ce S T M 32 w pliku stm 32_eth.h. Im plem entacje są w pliku stm 32_eth.c. D la nazw
zaczynających się od FLASH_, GPI0_ i RCC__ są to odpow iednio pliki stm 3 2 f!0 x_
Jlash.li, s tm 3 2 fl0 x J la s h .c , stm 3 2 fl0 x_ g p io .h , stm 32fI0x_gpio.c, stm 32fJ0x_rcc.li,
stm 3 2 fl 0x_rcc.c.
67
---2.6.2.
15
PCO
14
nR S T
3.3V
100n:
79
Plikf u tilje d .h i u łilje d .c
Pliki u tilje d .h i u ti lj e d .c dostarczają dw óch pom ocniczych funkcji diagnostycz­
nych. F unkcja OK m iga n razy zieloną diodą św iecącą. Funkcja E rro r m iga n razy
czerw oną diodą św iecącą.
void 0K(int n);
void Error(int n);
Rys. 2.16. Podłączenie modułu ethernetowego w ZL29ARM
Ponadto w u tilje d .h definiujem y m akro error__check, które w yw ołujem y, aby
spraw dzić, czy jak aś funkcja zakończyła się popraw nie. Jako pierw szy argum ent
81
2.6. Przykład 2 - monitor sieci
fcjsu ethernetow ego zajm uje się funkcja ETH__Init, która zw raca zero, gdy wystąpił
błąd - w tedy nasza funkcja musi zw rócić w artość ujem ną.
um ieszczam y w yw ołanie funkcji, która zw raca zero przy popraw nym zakończeniu, '!'•
a w artość ujem ną, gdy w ystąpił błąd. Jako drugi argum ent podajem y num er błędu :
- liczbę m ignięć czerw onej diody.
i
łdefine error_check(expr,
if ((expr) < 0! (
for (;;) (
Error(err);
)
err) \
\
\
\
int ETHconfigureRX(uint8_t phyAddress)
(
ETH_Init'fypeDef e;
'(»
'i
\
ł
ETH_StructInit(&e);
e.ETH_AutoNegotiation = ETH_AutoNegotiation_Enable;
e.ETH_ReceiveAlł - ETH_ReceiveAlł_Enable;
if (ETH_Init(&e, phyAddress) == 0}
return -1;
i
:,j
Plik ex_eth.c
i
W pliku ex_eth.c zaim plem entow ane są dw ie funkcje:
-
ETHconf igureRX konfiguruje o d bieranie ram ek przez interfejs E thernet,
-
main konfiguruje sprzęt, a potem w nieskończonej pętli czyta odebrane ramki
Jeśli pow yższe nie zadziała, m ożna w yłączyć negocjow anie trybu pracy i spróbo­
wać ustaw ić go m anualnie. Przydatne ustaw ienia są następujące:
i w ypisuje ich zaw artość na LCD.
Do jednego M A C m ożna podłączyć w iele układów PHY. A by je rozróżnić, każdy
musi m ieć przypisany unikalny adres, który jed n ak nie m a nic w spólnego z adresem
ethernetow ym . PH Y w m odule Z L 3E T H m a adres 1. N ajlepiej je s t zdefiniow ać go ■
ja k o stalą:
łdefine PHY_ADDRESS 1
Z acznijm y od funkcji konfigurującej odbieranie ram ek. Jej argum entem je s t adres ■'*
PHY. Funkcja ta zw raca zero, gdy konfigurow anie zakończyło się sukcesem , a war- ■<$
tość ujem ną, gdy w ystąpił błąd. Jej sygnatura je s t następująca:
' '“i1“
static int ETHconfigureRX(uint8_t phyAddress);
M ikrokontroler ST M 32F107 używ a układu D M A do odbierania i w ysyłania r;
ethernetow ych. W ięcej o D M A piszę w rozdziale 3.3. W funkcji ETHconfigureRX
deklarujem y E T HRXBUFNB odbiorczych deskryptorów D M A oraz po jed n y m buforze
odbiorczym na każdy deskryptor. B ufory m ają rozm iar ETH_MAX__PACKET__SIZE. Stała
ta je st zdefiniow ana w pliku stm 32_etli.h i m a w artość 1520, co jest m aksym alnym
rozm iarem ram ki ethernetow ej (bez pream buły) pow iększonym do w ielokrotności
4, gdyż bufory DM A pow inny być w pam ięci pod adresam i w yrów nanym i do wie­
lokrotności 4 bajtów. Fragm ent inicjujący odbiorczą część D M A w ygląda tak:
int ETHconfigureRX(uint8_t phyAddress) |
łdefine ETHRXBUFNB 4
static ETH_DMADESCTypeDef DMARxDscrTab[ETHRXBUFNB)
attribute
((aligned (4)));
Static uint8_t RxBu£f[ETHRXBUFNB)[ETH_MAX_PACKET_SIZE|
attribute
((aligned (4)));
{
e.ETH_AutoNegotiation = ETii__AutoNegotiation_Disable;
e.ETH_Speed = ETH_Speed_100M;
e.ETH_Speed = ETH_Speed_10M;
e.ETHJłode = ETH_Mode_FullDnpIex;
e.ETH_Mode = ETH_Mode_HałfDuplex;
Jeśli funkcja ETH^Init zw róci w artość niezerow ą, czyli jeśli inicjow anie interfejsu
się pow iedzie, m ożem y w łączyć odbieranie ram ek za pom ocą funkcji ETH_Start
i zakończyć funkcję ETHconfigureRX, zw racając 0, oznaczające sukces,
int ETHconfigureRX(uint8_t phyAddress) (
ETH_Start();
return 0;
1
P rzejdźm y teraz do opisu funkcji main. Z aczyna się ona od typow ej sekw encji ini­
cjującej kolejne układy:
'
/■
/'
int main() {
Delay (1000000);
AllPinsDisable(};
LEDconfigure{) /
RedLEDoni);
LCDconfigureO ;
LCDtirite ("CLK ");
error^check(CLKconfigure(), 1);
LCDwrite("PASS\n");
LCDwrite("MII ");
error_check(ETHconfigureMII (), 'I) ;
LCDwrite{"PASS\n");
LCDwrite("ETH ");
error_ciieck(ETHconfigureR)i (PHV_ADDRESS), 5);
LCDwrite (ł,PASS\n");
RedLEDoff 0 ;
ETH_DMARxDescChainInit(DMARxDscrTab, SRxBuf£[0][OJ, ETHRXBUENB);
)
1
Param etry pracy interfejsu E thernet zebrane są w strukturze ETH_InitTypeDef.
W w iększości przypadków najlepiej je s t ustaw ić w artości dom yślne za pom ocą
funkcji ETH_StructInit. W arto spróbow ać ustaw ić negocjow anie trybu pracy in­
terfejsu. Poniew aż nasz program m a być m onitorem sieci, m usim y skonfigurow ać
odbieranie w szystkich ram ek, niezależnie od adresu odbiorcy. Inicjow aniem inter-
N ajpierw czekam y pól sekundy - w ym agają tego niektóre kom binacje JTAG i pro­
gram u go obsługującego. Podczas całego procesu konfigurow ania św ieci czerw ona
dioda, a jej w yłączenie sygnalizuje zakończenie konfigurow ania sprzętu. M iganie
czerw onej diody oznacza w ystąpienie błędu. Pojedyncze m ignięcia oznaczają
problem z, synchronizacją sygnałów taktujących. M iganie w rytmie: 4 m ignięcia
- dłuższa przerw a, oznacza błąd interfejsu M II (m iędzy M A C a PH Y ) - np. nie
82
2. Inter
«E
jest w łożony m oduł Z L3E T H . M iganie w rytm ie: 5 m ignięcia - dłuższa przerwa;
oznacza błąd konfiguracji E thernetu - np. sieć nie działa albo do Z L3E T H nie je s l|
podłączony kabel. Inform acja o postępie urucham iania program u je st też wyświeilana na LCD.
Po uruchom ieniu interfejsu ethernetow ego program w nieskończonej pętli czytaj]
kolejne odebrane ram ki za pom ocą funkcji ETH_BandłeRxPkt z biblioteki STM32'fl
i w yśw ietla icli zaw artość. A rgum entem funkcji ETH_HandleRxPkt je st adres bufo-Jjj
ra, do którego zostanie skopiow ana odebrana ram ka. P ream buła i sekw encja kon-'
trolna ram ki nie są kopiow ane. Jeśli jak a ś ram ka została odebrana, to funkcja tal]
zw raca liczbę skopiow anych bajtów. N ajkrótsza ram ka ethernetow a bez preambuły»!
i sekw encji kontrolnej m a 60 oktetów . S zkielet końcow ego fragm entu funkcji raair.
w ygląda następująco:
int main () {
unsigned pkts;
pkfcs = 0;
for (;;) f
static uir>t8_t packet (ETH_MAX_PACKET_SIZE];
uint32_t size;
size = ETH_HandleRxPkt(packet);
if (size >= 60) {
pkts++;
... /* Wypisz ramkę na LCD. */
)
StOS TCP/IP
3.1. Przegląd implementacji
Stosem T C P /IP nazyw a się kom plet protokołów intersieci (ang. internet protocol,
suite). C entralnym protokołem tego stosu jest 1P, opisany w poprzednim rozdziale’,,
M inim alna im plem entacja musi zaw ierać obsługę protokołów transportow ych T C P
i UDP. O bow iązkow ą częścią T C P /IP je st też ICMP, który opisuję pod koniec tegov
rozdziału. Ponadto im plem entacja stosu zaw iera zw ykle kilka pom ocniczych protod
kolów, np. w spom niany w poprzednim rozdziale ARP.
A by tw orzyć aplikacje korzystające z intersieci, m usim y m ieć im plem entację ,stosu;
TCP/IP. N ie m a potrzeby sam odzielnego im plem entow ania całego stosu. To bylohyi
zbyt pracochłonne i niepotrzebnie pow tarzało ju ż w ykonaną przez innych pracę,¡,
Ten rozdział zaczynam od p obieżnego przeglądu dostępnych im plem entacji stosu!
TCP/IP. N astępnie skupiam się na w ybranej im plem entacji. Przedstaw iam , ja k dotj
pasow ać ją do architektury m ikrokontrolera i ja k ją skonfigurow ać. Potem opisuję!
zainstalow any w m ikrokontrolerze S T M 32F107 przeznaczony do obsługi Ethernetu,
układ D M A. G łów nym celem tego rozdziału je s t przedstaw ienie im plem entacji ste­
row nika (ang. driver) E thernetu, pośredniczącego m iędzy stosem protokołów sL
ciow ych a sprzętem . O m aw iam trzy w ersje sterow nika:
-
pierw sza używ a dodatkow ych buforów do przekazyw ania ram ek ethernetow y"'
m iędzy stosem a D M A;
druga nie potrzebuje dodatkow ych buforów w części odbiorczej, D M A kopiuje!
odebrane ram ki bezpośrednio do buforów stosu;
trzecia nie m a rów nież dodatkow ych buforów w części nadaw czej.
Pozbycie się dodatkow ych buforów odbiorczych lub nadaw czych zm niejsza zaję-,'^
tość R A M i spraw ia, że ram ki nie są niepotrzebnie kopiow ane (ang. zero copy)!-M
Pow odem prezentacji aż trzech sterow ników je s t też chęć przedstaw ienia różnych i
trybów pracy DM A. Z aim plem entow ane sterow niki porów nuję pod w zględem
jętości pam ięci RAM i Flash o raz szybkości działania. Na koniec tego rozd
podaję nieco użytecznych inform acji o protokołach IC M P i DHCP.
Przegląd implementacji
D ostępne są zarów no kom ercyjne, ja k i darm ow e im plem entacje stosu TCP/IP,•';(
Przykładem rozw iązań kom ercyjnych są stosy oferow ane przez firm ę InterNiche
Inform acje o nich m ożna znaleźć na stronie http://w w w .iniche.com . Jest tam
w ie w szystko, czego m ożem y potrzebow ać w system ie w budow anym . Jednak cenyi|;
poszczególnych pakietów są zaporow e naw et dla dużej firmy, nie wspomii
o hobbystach. InterN iche, aby zachęcić do sw oich produktów , oferuje darm ow y
N icheL ite [4]. Z aim plem entow ano w nim okrojoną w ersję IP nieobslugującą nag
m entacji. N icheL ite zaw iera protokoły TCP, UDP, ICMP, A R P oraz klienty p
kolów BOOTP, DHCP, D N S, TFTP. Jest też dem onstracyjna w ersja serw era H I 1P •
N icheL ite udostępnia interfejs program istyczny m inisockets, naśladujący inlt
gniazd (ang. sockets), dostępny w uniksow ych system ach operacyjnych i systemach •■
W indow s, ale nie w pełni z nim kom patybilny. Pow ażną w adą stosu N ichiL ite
licencja, na której je s t udostępniany. Z abrania ona łączenia N ichiL ite z oprogram ow aniem , które je s t ro zpow szechniane ja k o oprogram ow anie otw arte (ang. open",
source softw are) i tw orzenia aplikacji używ ającycli N ichiL ite za pom ocą otwartych
85
narzędzi program istycznych, np. narzędzi pow stających w ram ach projektu GNU
i udostępnianych na licencji G PL (ang. general public license).
Na drugim biegunie są w pełni darm ow e im plem entacje stosu TCP/IP. Przykładem
jest projekt ulP (m ikro IP), którego strona znajduje się pod adresem littp://www.
sics.se/~adain/uip. O ryginalnie stw orzono go dla m ikrokontrolerów 8-bilow ych, ale
został przeniesiony też na architekturę ARM . Ź ródła tego stosu są przyzw oicie udo­
kum entow ane i skom entow ane. W ym aga on niew ielkiej pam ięci, zarów no RAM ,
jak i Flash. Im plem entuje podstaw ow y zestaw protokołów : IP, TCP, UDP, ICMP,
ARP, SLIP. D ostępne są też dem onstracyjne im plem entacje serw era i klienta HTTP,
klienta D N S, klienta SM T P oraz serw era protokołu Telnet. Jest udostępniany na
licencji um ożliw iającej jeg o kom ercyjne w ykorzystanie.
Do napisanie tej książki w ybrałem stos lw IP (ang. lightw eight IP) [5]. Projekt lwIP
ma sw oją stronę http://savannah.nongnu.org/projects/lw ip. Biblioteka lw IP jest
dystrybuow ana na bardzo liberalnej licencji, która um ożliw ia tw orzenie produktów
kom ercyjnych zaw ierających lw IP i ich sprzedaw anie bez konieczności udostępnia­
nia tekstu źródłow ego. W bibliotece lw IP zaim plem entow ano standardow y zestaw
protokołów : IP, TCP, UDP, ICMP, ARP. Ponadto lw IP zaw iera dodatkow e moduły:
-
D H C P - klient konfigurujący ustaw ienia sieciow e w ęzła, czyli uzyskujący adres
1P, m askę podsieci, adres rutera i adres serw era nazw (w podsieci musi działać
serw er tej usługi);
-
D NS - klient tłum aczący nazw y dom enow e na adresy IP;
-
A utoIP - protokół APIPA (ang. A utom atic P rivate IP A ddressing), udostępniają­
cy alternatyw ny do D H C P sposób zdobyw ania adresu IP, opisany w RFC 3927,
przydziela adresy nierutow alne z puli 169.254.0.0/16, nie w ym aga żadnego ser­
wera;
- S N M P (ang. Sim ple N etw ork M anagem ent Protocol) - protokół służący do zdal­
nego m onitorow ania w ęzłów sieci i zarządzania urządzeniam i sieciow ym i, np.
ruteram i (w brew nazw ie w cale nie je s t to prosty protokół);
- 1GMP (ang. Internet G roup M anagem ent Protocol) - protokół służący do zarzą­
dzania grupam i węzłów, osiąganym i pod w spólnym adresem grupow ym (ang.
m ul t i cast address)',
-
SL IP (ang. Serial Line Internet Protocol) - kapsulkow anie IP w łączach szerego­
wych;
-
PPP (ang. P oint to P oint Protocol) - protokół w arstw y łącza używ any w wielu
interfejsach szeregow ych.
B iblioteka lw IP udostępnia trzy interfejsy program istyczne:
-
Interfejs surow y (ang. raw), który je s t podstaw ow ym interfejsem biblioteki
lwIP.
-
Interfejs sekw encyjny (ang. neteonn), który obsługuje kom unikację sieciow ą
w paradygm acie otw órz-czytąj-pisz-zam knij. W yw ołania funkcji tego interfejsu
są blokujące. W ynika stąd, że biblioteka i aplikacja m uszą działać w osobnych
w ątkach - potrzebny je s t system operacyjny, który um ożliw ia urucham ianie w ie­
lu w ątków lub procesów.
86
3. Stos TCP/ip
Interfejs gniazd (ang. sockets), który obudow uje interfejs sekw encyjny i w zalo-;
żenili m a być zgodny z interfejsem gniazd używ anym w „dużych” komputerach
- nie je st jed n ak z nim w pełni zgodny.
B iblioteka lw IP je st ustaw icznie rozw ijana, co kilka m iesięcy pojaw ia się jej nowa
w ersja. W niniejszej książce korzystam z w ersji 1.3.2. Jest niem al pew ne, żcw chw ili ukazania się tej książki będzie ju ż dostępna kolejna w ersja tej biblioteki,
Jest to jed n ak zaleta, a nie w ada, gdyż nie w arto pośw ięcać czasu na poznawanie
oprogram ow ania, które nie je s t popraw iane i rozw ijane. O program ow anie, które nie
je s t rozw ijane, po ja k im ś czasie staje się bezużyteczne. N ie należy też obaw iać się.
że napisane dotychczas program y nie będą działać z now ym i w ersjam i biblioteki,
Z apew ne m ogą w ystąpić ja k ie ś problem y, ale tw órcy biblioteki lwIP, będąc prze­
cież jednocześnie jej użytkow nikam i, nie będą chcieć utrudniać sobie pracy i na
pew no będą starać się zachow ać w steczną kom patybilność.
,;
finclude "cortex-m3.h"
R dzenie A R M m ogą pracow ać ja k o grubokońców kow e (ang. big-endion) lub cieńkokońców kow e (ang. little-endian). W S T M 32 rdzeń C ortex-M 3 m a na stale usta­
w ioną cienkokońców kow ą kolejność bajtów (ang. byte order). B ibliotekę lw IP trze­
ba poinstruow ać o rodzaju końców kow ości za pom ocą definicji:
-.w,-
W następnych rozdziałach staram się szczegółow o w yjaśnić, ja k pisze się aplika­
cje sieciow e korzystające z biblioteki lw IP i używ ające protokołów transportowych
T C P i UDP. Spośród dodatkow ych m odułów prezentow ane przykłady korzystają
z Dł-ICP i D N S. W szystkie przykłady używ ają interfejsu surow ego. Pozw ala on na
lepszą integrację aplikacji ze stosem TCP/IP. Stos i aplikacja działają we wspólnym
w ątku. Program je st sterow any zdarzeniam i (ang. event based) za pom ocą funkcji,
zw rotnych (ang. callback fu n c tio n s) w yw oływ anych przez stos. Ź ródłem zdarzeń
są przerw ania. Interfejs surow y je s t preferow any w system ach w budow anych, gdy/ '
z trzech interfejsów dostarczanych przez bibliotekę lw IP m a najm niejsze narzuty "i,
pam ięciow e i czasow e. Interfejs surow y je st trudniejszy do opanow ania przez pro--'-'
gram istę od pozostałych dw óch, ale je d n y m z celów tej książki je s t w łaśnie przy­
bliżenie go C zytelnikow i.
Żaden z wyżej opisanych darm ow ych stosów nie im plem entuje IP w w ersji fi. ■'
Tw órcy lw IP podjęli próbę zaim plem entow ania tej w ersji IP, ale w chw ili rozpoczy­
nania pisania książki im plem entacja nie była jeszcze w pełni gotow a.
3.2.
Biblioteka lwIP
W ielką zaletą biblioteki lw IP je s t m ożliw ość bardzo elastycznego je j skonfigurow ania. D zięki tem u m ożem y skom pilow ać tylko te protokoły i moduły, które są nam
rzeczyw iście potrzebne. Im plem entacje protokołów są sparam elryzow ane i możemy ■
je łatw o dopasow ać do w ym agań konkretnej aplikacji. M anipulując param etram i bi­
blioteki, m ożem y leż w szerokich granicach zm ieniać zapotrzebow anie na pamięć,
co pozw ala pisać aplikacje zarów no na system y dysponujące gigabajtam i pamięci
operacyjnej, ja k i na m ikrokontrolery w yposażone w kilkadziesiąt kilobajtów RAM.
O czyw iście zm niejszenie rozm iaru potrzebnej pam ięci nic jest za darm o, w iąże się
zw ykle ze zm niejszeniem w ydajności lub ograniczeniem liczby w ęzłów , z którymi ■
m ożna się rów nocześnie kom unikow ać.
3.2.1.
87
liniow ać m akra do pom iaru w ydajności (ang. perform ance) im plem entacji. W tej
książce nie korzystam y jed n ak z tej m ożliw ość, pozostaw iając dom yślny plik, do­
starczany w raz z biblioteką. W szelkie pozostałe adaptacje należy um ieścić w pliku
cc.h. Żeby jed n ak nie m odyfikow ać pliku dostarczonego z biblioteką, tw orzym y
w łasny plik cortex-m 3.h, w którym um ieszczam y w szystkie niezbędne definicje,
a w pliku cc.h um ieszczam y tylko dyrektyw ę preprocesora:
t z y pij.-
-
3.2. Biblioteka lwIP
łdefine BYTE_ORDER L i m E _ E N D M N
B iblioteka lw IP używ a w łasnych nazw dla typów reprezentujących liczby całkow ite
(ang. integral types). D efiniujem y te typy, korzystając z definicji typów dostarcza­
nych przez standardow ą bibliotekę języ k a C w pliku stdint.h. Typ mem p t r t jest
ogólnym w skaźnikiem . N ie je s t on zdefiniow any ja k o void*, jak b y tego należało
oczekiw ać w języku C, aby m ożna były w ykonyw ać na nim w szystkie operacje
arytm etyczne.
typedef
typedef
typedef
typedef
typedef
typedef
typedef
int8_fc
uint8_t
intl6_t
uint!6_t
int32_t
uint32_t
u32__t
s8_t;
u8_L;
sl6_t;
ul6_t;
s32_t;
u32__t;
mem_ptr_t;
P oniew aż standard języka C pozostaw ia jeg o im plem entatorom pew ną sw obodę,
typy 16-bitow e i 32-bitow e m ogą być różnie zdefiniow ane w różnych architektu­
rach. D la architektur A RM typy i n t l 6 _ t , u i n t l 6 _ t , in t3 2 _ t, u in t3 2 _ t są zde­
finiow ane w stdint.h odpow iednio ja k o s h o r t, u n sig n ed s h o r t, lo n g , u n sig n ed
lo n g . D la tych typów biblioteka lw IP potrzebuje specyfikatorów form atow ania dla
funkcji p r i n t f , s n p r i n t f itp. S pecyfikatory zaczynające się od litery X służą do
w ypisyw ania danych szesnastkow o. Ponadto definiujem y speeyfikator form atow a­
nia SZT_F dla typu size__t.
ffdefine
Idefine
idefine
Idefine
Idefine
Idefine
Idefine
S16_F
U16_F
X16 F
S32~F
U32~F
X32~F
SZT_F
"hd"
"hu"
"hx"
"Id"
"lu"
"lx"
"zu"
Przykład użycia jednej z pow yższych stałych w idzieliśm y ju ż w pliku util_lcd.c,
gdzie znajduje się następujący fragm ent program u:
Dopasowanie do architektury mikrokontrolera - plik cortex-m3.h
uintl6_t port;
char b u f [8);
snprintf(buf, sizeof(buf), ":V'U16_F, port);
Za adaptację biblioteki lw IP do konkretnej architektury odpow iadają pliki nagłów ­
kow e um ieszczone w katalogu ./exam ples/include/arch. W pliku perf.h m ożna zde-
Sieciow y porządek oktetów je st porządkiem grubokońców kow ym , a zastosow any
m ikrokontroler je s t cienkokońców kow y, zatem oprogram ow anie sieciow e bardzo
88
89
3.2. Biblioteka lwIP
3. Stos T C P /n t
często musi odw racać kolejność oktetów (bajtów ). B iblioteka lw IP m a zaimplemen-'l;
tow ane odpow iednie funkcje i jeśli nie zdefiniujem y w łasnych operacji odwracania,
to zostaną skom pilow ane te dom yślne funkcje, które są jed n a k napisane w C, aby.,|'
były przenośne i w zw iązku z tym nie są optym alne. A rchitektura A R M m a instruk- fe'
cje asem blerow e REV16 i REV um ożliw iające szybkie (realizow ane sprzętow o) od-,§
w racanie kolejności bajtów odpow iednio w słow ie dw ubajtow ym i czterobajtowym ,
B iblioteka STM 32 dostarcza funkcji korzystających z tych instrukcji, co u m o ż liw ia j
proste zdefiniow anie potrzebnych operacji.
pobiera dw a m łodsze bajty z rejestru %1, zam ienia ich kolejność i um ieszcza w ynik
w rejestrze %0. Przypisanie konkretnych rejestrów pozostaw iam y jednak kom pila­
torow i. W napisie
idefine LWIP_PLATFORM_HTONS (x) _RE V 1 6 ( x )
»define LWIP_PLATFORM_HTONL(x)
REV(x!
"r" (x)
fl
W nazw ach pow yższych m akr sk ró t H TO N S (ang. host to netw ork short) o zn a -ij
cza zam ianę kolejności w słow ie dw ubajtow ym (ang. short) z porządku używanego "$
przez daną m aszynę, w ęzeł (ang. host) na porządek sieciow y. N atom iast H T O N L $
(ang. host to netw ork long) oznacza analogiczną zam ianę w słow ie czterobajtow ym
(ang. long). D ualnych operacji N TO H S (ang. netw ork to h ost short) i N TO H L (ang.Vf
netw ork to host long) nie m usim y definiow ać, bo są identyczne. Pow yższe makra (ï
są przeznaczone tylko do użycia w ew nątrz biblioteki lwIP. W naszych programach
pow inniśm y w łączać plik Iwip/inet.h (lub ja k iś inny go w łączający) i używ ać zdr- '
finiow anych w nim m akr h to n s , n to h s , h to n l, n to h l, które m ają standardow e na- p
zwy, pow szechnie używ ane w oprogram ow aniu sieciow ym .
ul6__t
u!6_t
u32_t
u32__t
htons(u!6_t
ntohs(u!6_t
htonl(u32_t
ntohl(u32_t
x);
x);
x);
x);
•■
Pow yższe m akra zaim plem entow ano za pom ocą m akr LWIP_PLATFORM_HTONS
i LWI P_PLATFORM_HTONL. Im plem entację tych m akr m ożna jeszcze bardziej zoptym alizow ać, likw idując narzut w yw ołania fu n k c ji REV16 i REV przez zdefiniow a- ■
nie w staw ek asem blerow ych. Jest to jed n a k bardzo zależne od użytego kom pilatora.
N iestety w staw ki asem blerow e często blokują kom pilatorow i m ożliw ość optym ah- t
zacji kodu w ynikow ego. G C C m a m echanizm definiow ania takich w staw ek nieblo- /■:
kujący optym alizacji kodu. O kupione je st to jed n ak bardzo skom plikow aną składnią, którą zaprezentuję na przykładzie m akra H TO N S. M akro H T O N L definiuje się
analogicznie.
»define LWIP_PLATFORM_HTONS (x) ((
u!6_t result;
asm ("revl6 $0, '-U" : "=r"(result)
result;
i)
\
\
)ji
: "r" <x> ) ; \
\
Treść m akra otaczają podw ójne naw iasy składające się z naw iasu okrągłego i kłamrow ego. M akro operuje na dw óch zm iennych: sw oim argum encie x oraz zadeklaro- ).
w anej w ew nątrz m akra 16-bitowej zm iennej r e s u l t . U m ieszczenie nazw y r e s u l t (
w ostatnim w ierszu treści m akra oznacza, że je s t to w artość zw racana przez makro. ■■
W iersz zaczynający się od słow a kluczow ego asm definiuje operację, którą chcemy
w ykonać. Instrukcja
rev!6 40, %1
"=r" (result)
litera r oznacza, że argum ent %0 musi być rejestrem . Instrukcja r e v l6 nie może
um ieścić w yniku w pam ięci. Z nak rów ności oznacza, że rejestr jest m odyfikow any
przez tę instrukcję. N azw a zm iennej w naw iasach oznacza, że rejestr ten musi prze­
chow yw ać w artość tej zm iennej. N apis
oznacza, że argum ent %1 m usi być rejestrem , gdyż drugi argum ent instrukcji r e v i 6
rów nież m usi być rejestrem . B rak znaku rów ności oznacza, że w artość tego rejestru
nie je st m odyfikow ana przez instrukcję. Ponadto rejestr len musi przechow yw ać
w artość zm iennej x.
B iblioteka lw IP zaw iera sporo kodu diagnostycznego. Jeśli chcem y z tego skorzy­
stać, m usim y zaim plem entow ać urządzenie, na które będą w ypisyw ane kom unikaty
diagnostyczne i m akra w ypisujące te kom unikaty. O pcja ta jest przydatna przede
w szystkim tw órcom biblioteki, dlatego definiujem y dw a puste makra:
»define LWIP_PLATFORM_ASSERT(x)
»define LWIP_PLATFORM_DlAG(x)
((void)0)
((void)0)
A rgum ent m akra LWIP_PLATFORM_ASSERT je s t w skaźnikiem na kom unikat, który ma
być w ypisany. K om unikat je st napisem w stylu C i m usi być zakończony term i­
nalnym zerem . A rgum ent m akra L W I P _ P L ATFORM_DIAG jest otoczonym naw iasam i
okrągłym i ciągiem argum entów , które akceptuje funkcja p r i n t f . Zakładając, że
dysponujem y funkcją p r i n t f , w ypisującą gdzieś w ynik sw ojego działania, m akra
to m ogłoby być w ięc zaim plem entow ane tak:
»define LWIP__PLATFORM_ASSERT (x) printf (x)
»define LWIP_PLATFORM_DIAG(x)
printf X
A plikacje, które prezentuję w tej książce, dla zapew nienia w spółbieżności korzysta­
ją z system u przerw ań. Funkcje biblioteki lw IP są w yw oływ ane w program ie głów ­
nym i w procedurach obsługi przerw ań. N iektóre krytyczne fragm enty program u
nie m ogą być przeryw ane. Jednak funkcje biblioteczne w wielu przypadkach nie
są w spółużyw alne (ang. reentrant). O gólnie każdą funkcję, która odw ołuje się do
ja k ic h ś globalnych zasobów , np. zm iennych globalnych czy układów peryferyjnych
m ikrokontrolera lub używ a zm iennych statycznych, należy traktow ać jak o niew spółużyw alną. Funkcje zarządzające pam ięcią program u (przydzielające i zw alniają­
ce pam ięć) nie są w spółużyw alne, gdyż korzystają z globalnej struktury, jak ą jest
sterta. N iew spółużyw alność oznacza, że jeśli w ykonyw anie takiej funkcji zostanie
przerw ane (np. przez procedurę obsługi przerw ania) i zostanie w yw ołana ta sam a
lub inna, ale korzystająca z tych sam ych zasobów funkcja, to istnieje pow ażne ryzy­
ko błędnego działania program u. M ożna oczyw iście zabronić w yw ołania niew spółużyw ałnych funkcji w procedurach obsługi przerw ań, ale zapew ne lepszym roz­
w iązaniem jest w ykonyw anie krytycznych fragm entów program u z w yłączonym i
przerw aniam i. W bibliotece lw IP przew idziano w tym celu trzy makra.
»define SYS_ARCH_DECL_PROTECT(x)
u32 t X
\
91
3.2. Biblioteka IwlP
łdefine SYS_ARCII_PROTECT(x)
\
(x =
get_PRIMASK(),
disable_irq())
łdefine SYS_ARCH_UNPROTECT(x)
\
_set_PRIMASK(x)
'if
Ą
M akro S Y S _ A R CH_DECL_PROTECT d eklaruje zm ienną x, w której zapisuje się aktualif'
m askę przerw ań. M akro S YS_ARC H _ P R O T E C T zapisuje w zm iennej x aktualną zawati;
tos'ć rejestru PRIMASK i w yłącza przerw ania. U żyw a do tego f u n k c ji get_PRlMAs;J
i
disable_irq z biblioteki ST M 32. R ejestr PRIMASK je st jed n y m ze specjalnyoi|
rejestrów rdzenia C ortex-M 3 i służy d o m askow ania przerw ań o konfigurow alny^
priorytecie. W C ortex-M 3 są to w szystkie przerw ania z w yjątkiem zerow ania (ang^
reset), przerw ania niem askow alnego N M I (ang. non-m askable interrupt) i poważ*
nego niepow odzenia (ang. hard fa u lt). Jeśli najm łodszy bit rejestru PRIMASK je j'
w yzerow any, przerw ania są w łączone, a jeśli je st ustaw iony - w yłączone. Pozostał
bity tego rejestru nie są używ ane - są zarezerw ow ane do przyszłego wykorzystania'5
F u n k c ja disable_irq w yw ołuje instrukcję A sem blera cpsid (ang. change prók.
cessor state, disable interrupt), która ustaw ia najm łodszy bit w rejestrze PRIMASK,
M akro SYS_ARCH__UNPROTECT przyw raca poprzednią, zapam iętaną w zmiennej x;:
w artość rejestru PRIMASK.
Jako przykład użycia pow yższych m akr rozw ażm y chronione w ersje standardów
w ych funkcji zarządzających pam ięcią: m a llo c , f r e e , c a l l o c , r e a l l o c . Wersje
chronione nazw ijm y odpow iednio: p r o te c te d _ m a llo c , p r o t e c te d _ f r e e , p ro te c ted _ _ callo c, p r o t e c t e d _ r e a l l o c . W ołają one o d pow iednie funkcje niechronionc
przy w yłączonych przerw aniach. Ż eby ich w yw ołanie było efektyw ne, są zadekhw
row ane jak o rozw ijane w m iejscu (ang. inline). S ta ła INLINE dla poszczególnych
kom pilatorów je s t zdefiniow ana w pliku core_cm 3.h, który je s t częścią biblioteki;.’
ST M 32 i znajduje się w katalogu Jst/L ibraries/C M S IS /C M 3 /C o reS u p p o rt/. Niżej
podałem przykłady dw óch funkcji w w ersji chronionej. Im plem entacja dw óch po­
zostałych je s t analogiczna.
static
INLINE void *protected_malloc(size_t size) {
void *ret;
SYS_ARCH_DECL_PROTECT(v);
SYS_ARCH_PROTECT(v);
ret = mal l o c (size);
SYS_ARCH_UNPROTECTfv);
return ret;
)
static
INLINE void protected_free(void *ptr) {
SYS_ARCH__DECL_PROTECT (v) ;
SYS_ARCH_PROTECT(v);
free (ptr);
SYS_ARCH_UNPROTECT(v);
3
Jak poprzednio, jeśli używ am y G C C , m ożem y m akra zaim plem entow ać efektyw ­
niej, bezpośrednio w A sem blerze. Instrukcja mrs (ang. m ove from special register
to register) przepisuje zaw artość rejestru specjalnego do rejestru ogólnego prze­
znaczenia. Instrukcja msr (ang. m ove from register to special register) przepisuje
zaw artość rejestru ogólnego przeznaczenia do rejestru specjalnego. Znaki \ n \ t po
tej instrukcji oznaczają przejście do now ego w iersza i tabulator. S łużą one tylko do
form atow ania tekstu, który jest przekazyw any do asem blacji.
Idefine SYS_ARCH_DECL_PROTECT(x)
u32_t x
»define SYS__ARCH_PROTECT(x) !l
asm volatile (
"mrs %0, PRIMASK\n\t"
"cpsid i" :
"=r" (x) :
);
\
\
\
\
\
\
\
1)
»define SYS_ARCH_UNPROTECT(x> (1
\
asm volatile C'msr PRIMASE, 10" : : ”
r" (x)i; \
I)
O pisany dotychczas m echanizm m oże być niew ystarczający. W ykonyw anie długich
fragm entów program u przy w yłączonych przerw aniach je s t niepożądane. Z w ykle
w ystarczy zablokow ać tylko pew ną grupę przerw ań. M ożna to zrobić, w ykorzystu­
jąc priorytety. W architekturze C orlex-M 3 m ożna przerw aniom przydzielać prio­
rytety od 0 do 15. Przerw ania, których priorytet nie je st konfigurow alny, m ają na
stale przypisany priorytet ujem ny: zerow anie m a priorytet -3 , N M I m a priorytet
- 2 , a pow ażne niepow odzenie priorytet - 1 . Jak to zw ykle byw a, w yższy priorytet
ma m niejszą w artość. Przerw ania są w yw łaszczalne. Jeśli w trakcie w ykonyw ania
procedury obsługi przerw ania pojaw i się przerw anie o w yższym priorytecie, to ak­
tualnie w ykonyw ana procedura obsługi zostanie przerw ana i procesor przejdzie do
obsługi przerw ania o w yższym priorytecie. Przerw ana procedura zostanie dokoń­
czona, gdy nie będzie ju ż żadnych przerw ań o w yższym priorytecie do obsłużenia.
Priorytet przerw ania je s t zapisyw any na czterech bitach, które m ożem y podzielić na
dw a pola: priorytet w yw łaszczania (ang. preem ption priority) i podpriorytet (ang.
subpriority). Przerw anie m oże być w yw łaszczone tylko przez przerw anie o w yż­
szym priorytecie w yw łaszczania. Podpriorytet decyduje o kolejności obsługi p rze­
rwań w ram ach tego sam ego priorytetu w yw łaszczania.
N a potrzeby tej książki ustalam y za pom ocą stałej PRE£MPTION_PRIORITY_BITS, że
dw a bity priorytetu określają priorytet w yw łaszczania, a dw a pozostałe podprio­
rytet. M am y w tedy m ożliw ość zdefiniow ania czterech priorytetów w yw łaszczania.
W ystarczą nam trzy. Z najw yższym priorytetem , oznaczonym HIGH_IRQ_PRIO, o b­
sługujem y przerw ania w ym agające szybkiej reakcji. Ich czas obsługi m usi być krót­
ki i nie m ogą w nich być w ołane żadne funkcje biblioteki lwIP. Średni priorytet,
oznaczony LWIP_IRQ_PRIO, przypisujem y przerw aniom biblioteki lwIP. Pozostałym
przerw aniom nadajem y niski priorytet LOW_IRQ_PRIO.
Idefine
łdefine
łdefine
łdefine
PREEMPTION_PRIORITY_BITS 2
l!IGH_IRQ_PRIO 1
LWIP__IRQ_PRIO 2
LOW_IRQ_PRIO 3
M akro S E T_IRQ_PROTECTION uaktyw nia m ożliw ość blokow ania przerw ań zależnie
od ich priorytetu i musi być w yw ołane na początku program u, zanim w łączym y
jak iek o lw iek przerw anie. A by ustaw ić liczbę bitów przeznaczonych na priorytet
w yw łaszczania, najlepiej je s t w yw ołać funkcję NVIC__SetPriorityGrouping z bi­
blioteki STM 32.
idefine SET_IRQ_PROTECTION()
\
NVIC_SetPriorityGrouping(7 - PREEMPTION_PRIORITY_BITS)
92
93
3.2. Biblioteka IwlP
3. Stos TCP/lp$
■
]W
"~r" (prv), "=r" (tmp) :
\
"i" ((lvl) « (8 - PREEMPTION_PRIORITY_BITS)) \
A by ustaw ić priorytet przerw ania, m ożna użyć funkcji NVIC_SetPriority, do-j"
starczanej przez bibliotekę ST M 32, a dokładniej przez C M SIS. N iestety fu n k cja^
ta nie uw zględnia zm ienionej liczby bitów priorytetu w yw łaszczania i używ a dof'
tego stałej
NVIC__PRIO_BITS, która m a w artość 4, Żeby zm ienić tę w artość, na-ji.
leżałoby zm odyfikow ać pliki źródłow e biblioteki C M SIS. Stała la je s t zdefiniow al i
na w pliku stm 3 2 fI0 x.h , który znajduje się w katalogu Jst/L ibraries/C M SIS/C M 3/Ą
D eviceSupport/ST /ST M 32 F 10x, a potem używ ana w pliku core_cm 3.h. Funkcja bi-’
blioteczna nie uw zględnia rów nież podpriorytetu. A by nie m odyfikow ać biblioteki,
co m ogłoby spow odow ać problem y z kom patybilności;! naszych program ów z jej ”
przyszłym i w ersjam i, definiujem y w łasne m akro SET_PRIORITY, które umieszcza,,
priorytet w yw łaszczania w starszych bitach, a podpriorytet w m łodszych bitach ’'
priorytetu.
łdefine SET_PRIORITY(irq, prio, subprio)
\
NVIC_SetPriority((irq), (subprio) [ ((prio) <<
\
(__NVIC_PRIO_BITS - PREEMPTION_PRIORITY_BITS) ) )
);
0 poprzedniej w artości priorytetu, pow yżej którego przerw ania nie są b lo k o w an e.,
M akro IRQ_PROTECT zapisuje w zm iennej p rv stan aktualnie blokow anych przerwań '■
1 blokuje przerw ania o priorytecie niższym lub rów nym l v ł . M akro IRQ_UNPROTECT
przyw raca stan blokow ania przerw ań zapisany w zm iennej p rv. Priorytet, powyżej ■
którego przerw ania nie są blokow ane, przechow yw any je s t w m ikrokontrolerach
C ortex-M 3 w rejestrze BASEPRI. D o tego rejestru m ożem y odw oływ ać się za pom o­
cą fu n k c ji get__BASEPRI i
set_BASEPRI z biblioteki STM 32. W artość argum en­
tu ł v l trzeba przesunąć o odpow iednią iiczbę bitów w lew o, we w łaściw e miejsce;
w rejestrze BASEPRI.
H f defined
GNUC__
idefine ALIGN4
attribute
{{aligned (4)))
ielse
terror Define ALIGNS macro for your compiler,
iendif
?
T ab .
\
\
\
\
\
\
3.1. Stale identyfiku ące kompilator
Kompilator
ARMCC
GCC
IAR
TASKING
łdefine IRQ_DECL_PROTECT(prv)
\
u32 t prv
Idefine IRQ_PROTECT(prv, lvl)
\
(prv =
get_BASEPRI{),
\
_set_BASEPRIiilvl) « (8 - PREEMPTION_PRIORITY_BITS}))
Idefine IRQ__UNPROTECT (prv)
\
_set_BASEPRI(prv)
\
\
(prv)); \
A by pisać program y, które używ ają konstrukcji specyficznych dla kom pilatora, do­
brze je s t posługiw ać się instrukcjam i kom pilacji w arunkow ej i stałym i definiow a­
nymi w tym celu przez poszczególne kom pilatory. Stałe dla popularnych kom pila­
torów zam ieszczone są w tabeli 3.1. Popatrzm y na następujący przykład kom pilacji
w arunkow ej, zależnej od użytego kom pilatora.
¥
M ożem y teraz zdefiniow ać m akra analogiczne do w yżej opisanych m akr SYS
łdefine IRQ_DECL_PROTECT(prv)
u32_t prv
łdefine IRQ_PROTECT(prv, lvl) ((
u32_t tmp;
asm volatile (
"mrs *0, BASEPRI\n\t"
"movs %1, t2\n\t"
"msr BASEPRI, %1" :
1,0"; : "r"
Przestaw ione tu sposoby ochrony krytycznych i niew spółużyw alnych fragm entów
program u m ogą w ydać się przesadzone ja k na potrzeby stosunkow o prostych przy­
kładów zam ieszczonych w kolejnych rozdziałach. Jednak w bardziej skom plikow a­
nych aplikacjach porządne przem yślenie tego problem u i zaim plem entow anie odpo­
w iednich m echanizm ów chroni przed bardzo trudnym i do zlokalizow ania błędam i,
których usuw anie je st bardzo czasochłonne. Z aprezentow ane w tym podrozdziale
rozw iązania należy traktow ać jako przykład i inspirację do w łasnych przem yśleń
na ten tem at.
ARCH. M akro I RQ_DECL_PROTECT deklaruje zmienni! p rv przechow ującą informację
Pow yższych m akr używ a się podobnie ja k m akr SYS_ARCH. Jak poprzednio, dła
G CC m ożem y je zdefiniow ać bardziej optym alnie. Z m ienną p rv przechow ujem j
w rejestrze ogólnego przeznaczenia %0. Zakładam y, że ja k o argum ent l v l zawsze
podaw ana jest je d n a z w yżej zdefiniow anych stałych IRQ_PRIO. Poniew aż argu­
m entem instrukcji msr nie m oże być stała, m usim y najpierw tę stałą załadow ać do
rejestru ogólnego przeznaczenia 41 (zm ienna tmp) za pom ocą instrukcji movs. Napis
" i " oznacza, że argum ent %2 je st stałą. W naw iasach za tym napisem jest podana
w artość tej stałej.
\
))
łdefine IRQJ)NPROTECT(prv) ((
asm volatile ("msr BASEPRI,
I)
Siata
CC ARM
GNUC
ICCARM
TASKING
C ortex-M 3 je st architekturą 32-bitow ą i czasem , ze w zględu na efektyw ność, do­
brze je st w yrów nać położenie danych w pam ięci do adresu będącego w ielokrotno­
ścią 4 bajtów. Przykład użycia atrybutu a lig n e d w idzieliśm y ju ż w poprzednim
rozdziale, przy deklaracji deskryptorów i buforów D M A . Poniew aż w yrów nyw anie
nie je st częścią standardu języ k a C, każdy kom pilator m a w tym celu sw oje specy­
ficzne instrukcje. Pow yższy fragm ent program u je st przeznaczony dla G CC. Inny
k om pilator w ypisze błąd przypom inający, że należy dodać w łaściw ą definicję.
3.2.2.
Parametry konfiguracyjne - plik Iwipopts.h
W szystkie param etry, które m ożem y ustaw ić w bibliotece IwlP, są zgrom adzone
w jed n y m m iejscu - znajdują się w pliku opt.h. K ażda opcja je st opatrzona kom en­
tarzem i m a zdefiniow aną w artość dom yślną. Plik ten je s t w archiw um w katalo­
gu ,/lw ip -1.3.2/src/include/lw ip, ale nie należy go m odyfikow ać. Plik opt.h w łącza
plik Iw ipopts.h, który pow inniśm y dostarczyć. W szelkie zm iany param etrów należy
um ieścić w pliku Iwipopts.h. Jeśli nie zdefiniujem y jak ieg o ś param etru, zostanie
użyta je g o w artość dom yślna. Plik Iwipopts.h dla przykładów prezentow anych w tej
95
3.2. Biblioteka Iw IP
książce znajduje się w katalogu ./exam ples/include. O piszę teraz po kolei zdefinio-i;
w ane w tym pliku param etry konfigurujące bibliotekę lwIP.
Idefine LWIP_PLATFORM_BYTESWAP
1
W artość 1 w łącza używ anie przez bibliotekę lw IP operacji odw racania kolejności ,;Ji
bajtów LWIP_PLATFORM_HTONS i LWIP_PLATFORM__HTONL, które przedstaw iłem w p0.
przednim podrozdziale. W artość 0 oznacza, że używ ane są operacje dom yślne, do - ;»
starczane w raz z biblioteką.
Idefine SYS_LIGHTWEIGHT_PROT
1
W artość 1 spraw ia, że funkcje biblioteczne przydzielające i zw alniające bufory
chronione w ew nątrz m akram i SYS_ARC H _ P R O T E C T i SYS_ARCH_UNPROTECT. W ailnA %
0 w yłącza tę ochronę.
Idefine NO SYS
1
'■
W artość 1 oznacza, że nie ma
system u operacyjnego - cala aplikacja działa jak o po-ijfl.
jedynczy wątek. W artość 0 oznacza, że używ am y system u operacyjnego, w którym i,i
m ożna urucham iać w iele w ątków lub procesów.
Idefine LWIPJJETCONN
idefine LWIP__SOCK£T
0
0
Pow yższe ustaw ienia w yłączają interfejsy sekw encyjny i gniazd, pozostaw iając tyl- i
ko podstaw ow y interfejs surowy.
idefine LWIP_STATS
0
W artość 0 w yłącza zbieranie statystyk, co przyspiesza działanie stosu. U stawienie
,4
w artości 1 um ożliw ia zbieranie statystyk. W yśw ietlanie statystyk w ym aga zaim ple­
m entow ania, w spom nianego w poprzednim podrozdziale, m akra LWIP_PLATFORM
DIAG. Statystyki te są niew ątpliw ie bardzo użyteczne dla program istów chcących rozw ijać bibliotekę lwIP, ale ich interpretacja w ym aga głębokiego w niknięcia w
tekst źródłowy.
''tw
idefine MEM_LIBC_MALLOC
1
W artość 1 spraw ia, że biblioteka lw IP używ a sterty i funkcji zarządzających pa­
m ięcią na stercie dostarczanych przez standardow ą bibliotekę C, czyli funkcji
lo c , f r e e , c a l l o c i r e a l l o c . U staw ienie w artości 0 pow oduje, że biblioteka używa
sw ojej w ew nętrznej sterty i w łasnego m echanizm u alokacji pam ięci. T rzeba wted\
zdefiniow ać rozm iar M EM_SIZE tej w ew nętrznej sterty.
idefine MEM_SIZE
(0 * 102-1)
Jeśli aplikacja w ysyła dużo danych, które w ym agają kopiow ania, sterta ta pow inna V
być duża. K opiow anie jest potrzebne, jeśli aplikacja przekazuje dane do w ysiania ■
w buforze i używ a ponow nie tego bufora, zanim dane zostaną faktycznie wysiane.
Sterta w ew nętrzna je s t alokow ana w sekcji ,bss. Jeśli staia M E M _LIBC_MALLOC ma
w artość I , sterta w ew nętrzna nie je s t alokow ana.
{(define
idefine
idefine
idefine
mem_free
mem_calloc
mem_malloc
mem_realloc
protected_free
prot:ected_calloc
protected_malloc
protected_realloc
B iblioteka lw IP nie w yw ołuje bezpośrednio funkcji zarządzających stertą. W szystkie
w yw ołania realizuje poprzez identyfikatory poprzedzone prefiksem mera_. D zięki
tem u pow yższe definicje um ożliw iają użycie chronionych w ersji tych funkcji, które
przedstaw iłem w poprzednim podrozdziale.
idefine MEM_ALIGNMENT
-I
Pow yższa stała definiuje w yrów nyw anie struktur alokow anych w pam ięci. Różni
się od opisanego w poprzednim podrozdziale m akra A L I G N -l tym , że tam to m akro
służy do w yrów nyw ania w czasie kom pilacji, a staia MEM_ALIGNMENT je s t używ ana
w czasie w ykonyw ania program u.
K olejne stale definiują rozm iary w ew nętrznych struktur biblioteki i m ają istotny
w pływ na zajętość RAM . Stale te zostały dobrane do prezentow anych w tej książce
przykładów . Inne aplikacje będą z pew nością w ym agały dopasow ania tych w arto­
ści. Z naczenie poszczególnych struktur będzie się stopniow o w yjaśniać w m iarę
poznaw ania kolejnych przykładów użycia biblioteki lwIP.
Idefine PBUF_P00L_SIZE
16
D efiniuje liczbę buforów puli zarządzanej przez bibliotekę lwIP. Z puli tej aloko­
w ane są m iędzy innym i bufory, w których um ieszczane są odbierane ram ki ethernetowe.
Idefine PBUF_POOL_BUFSIZE
152-1
D efiniuje rozm iar pojedynczego bufora w puli. R ozm iar ten jest dobrany tak, aby
w buforze zm ieściła się cala ram ka ethernetow a, która bez pream buły, ale z uw zględ­
nieniem sekw encji kontrolnej, m oże m ieć m aksym alnie długość 1518 bajtów. N a
przyszłość uw zględniam y też dodatkow e 4 bajty na znacznik V LA N . R ozm iar bu­
fora w yrów nujem y do w ielokrotności 4 bajtów.
Idefine MEMP_NUM_PBUF
16
D efiniuje liczbę struktur typu p b u f, które są alokow ane jak o PBUF_REF lub PBUF_
ROM, patrz rozdział 3.2.5. Struktury te opisują m iędzy innym i dane um ieszczone
w pam ięci stałej, czyli RO M lub Flash. Jeśli aplikacja w ysyła dużo danych bez­
pośrednio z pam ięci stałej, bez ich kopiow ania do R A M , to liczba tych struktur
pow inna być duża.
(define MEMP_NUM_UDP_PCB
5
D efiniuje liczbę jednocześnie otw artych deskryplorów U D R L iczba ta determ inuje
ilość sym ultanicznie prow adzonych kom unikacji za pom ocą U D P i m usi uw zględ­
niać deskryptory używ ane przez D H C P i D NS. D eskryptory U D P są potrzebne tyl­
ko wtedy, gdy używ a się U D P lub protokołów korzystających z UDP.
Idefine MEMP_NUM_TCP_PCB
2
D efiniuje liczbę jednocześnie otw artych połączeń TCP. Jeśli T C P nie je s t używany,
m ożna zrezygnow ać z tych struktur.
Idefine MEMP_NUM_TCP_PCB_LISTEN 3
D efiniuje rozm iar kolejki połączeń T C P oczekujących na otw arcie. K olejka jest
potrzebna w aplikacji działającej ja k o serw er TCP. N ie je st natom iast potrzebna
w aplikacji działającej ja k o klient.
96
—
łdefine MEMP_NUM_TCP_SEG
3. Stos TCP/a• '
.
i;
8
D ane przesyłane za pom ocą T C P są dzielone na segm enty, które są przesyłanej
w datagram ach IP. Stała ta definiuje liczbę jednocześnie kolejkow anych segmentów' ,4i
TCP.
Idefine MEMP_NUM_REASSDATA
4
O dbierane datagram y IP m ogą przychodzić pofragm entow ane. Stała ta definiuje'^;
liczbę jed no cześn ie kolejkow anych datagram ów IP (całych datagram ów , a nie frag-!-||.
m entów ) czekających na złożenie.
K olejne definicje ustalają szczegółow e opcje dla poszczególnych protokołów'.;^.
W iększość z nich nie w pływ a na zajętość RA M lub w pływ a w niew ielkim stopniuj;.*,
ale m a istotne znaczenie dla d ziałania biblioteki lwIP.
Sdefine ARP QUEUEING
1
W
' '■'■‘•i
W łącza kolejkow anie datagram ów IP, które pow inny zostać w ysiane, ale oczekują"/;
na przetłum aczenie za pom ocą A R P adresu IP na adres ethernetow y.
V
97
3.2. Biblioteko lwIP
Jeśli stała ta ma w artość 0, odebrane datagram y IP, których nagłów ek m a dodatko­
we opcje, nie będą przetw arzane. Jeśli stała ta ma w artość 1, w szystkie odebrane
datagram y IP będą przetw arzane, ale dodatkow e opcje um ieszczone w nagłów ku
datagram u IP będą ignorow ane. B iblioteka lw IP nie obsługuje dodatkow ych opcji
w nagłów kach IP.
łdefine IP_REASSEMBLY
1
W artość 1 w łącza składanie odbieranych pofragm entow anych datagram ów 1P.
W artość 0 pow oduje, że przetw arzane będą tylko niepofragm entow ane datagram y,
a w szystkie odebrane fragm enty datagram ów IP będą ignorowane.
łdefine IP_ERAG
1
W artość 1 w łącza fragm entow anie w ysyłanych datagram ów IP, jeśli ich rozm iar
przekracza M TU sieci. W artość 0 pow oduje, że próba w ysiania datagram u dłuższe­
go niż M TU się nie pow iedzie.
łdefine IP_REASS_MAXAGE
3
D efiniuje m aksym alną liczbę je d n o cz eśn ie kolejkow anych datagram ów IP, czeka- -le­
jących na przetłum aczenie adresu za pom ocą ARP. O pcja ta w ym aga, aby stała .‘iy
A R P _ Q UEUEING m iała w artość 1.
T-."
D efiniuje m aksym alny czas oczekiw ania na otrzym anie w szystkich fragm entów da­
tagram u IP. Jeśli w tym czasie w szystkie fragm enty nie zostaną odebrane, to cały
datagram je s t porzucany. C zas je s t liczony w w ielokrotnościach kw antu czasu okre­
ślonego za pom ocą stałej IP_TMR_INTERVAL. D om yślnie stała ta definiuje interw al
1000 ms.
łdefine ARP_TABLE_SIZE
łdefine IP_REASS_MAX_PBUE;S
łdefine MEMP_NUM_ARP_QUEUE
3
.ifc
4
10
D efiniuje rozm iar pam ięci podręcznej ARP. W artość ta pow inna być rów na przewi
dyw anej m aksym alnej liczbie w ęzłów , do których w danej podsieci będą bezpośred-, d
nio w ysyłane datagram y IP, z uw zględnieniem rutera.
i,.’
D efiniuje m aksym alną liczbę buforów odbiorczych z czekającym i na złożenie frag­
m entam i datagram ów IP. W artość ta m usi być m niejsza niż PBUF_P00L_SIZE, żeby
stos lw IP byl w stanie odbierać kolejne datagram y i się nie zablokow ał.
łdefine ETHARP_TRUST_IP_MAC
łdefine IP_DEFAULT_TTL
1
W artość 1 oznacza, że pam ięć podręczna A R P będzie uaktualniana na podstawie
inform acji z nagłów ków w odbieranych ram kach ethernetow ych. W artość 0 blokuje d
takie uaktualnianie - w tym przypadku pam ięć podręczna A R P m oże być m o d y f ik o - .
w ana tylko po w ysianiu prośby A R P i odebraniu na nią odpow iedzi. Z ablokow anie'
tej opcji w prow adza dodatkow e, niew ielkie opóźnienia w tłum aczeniu adresów, a]e
też w prow adza pew ne zabezpieczenie przed zatruw aniem pam ięci podręcznej ARP
(ang. spoofing). Jeśli w szystkie w ęzły w podsieci są zaufane, m ożem y śm iało uaktyw nić tę opcję.
łdefine ETHARP_SUPPORT_VLAN
0
W artość 1 uaktyw nia odbieranie ram ek ethernetow ych V LA N . Z nacznik V LA N ra­
m ek, które m ają być odbierane, należy zdefiniow ać ja k o stalą ETHARP_VLAN_CHECK.
Jeśli stała ta nie je s t zdefiniow ana, to odbierane są ram ki ze w szystkim i znaczni- ,
kam i.
łdefine IP_FORWARD
0
W artość 1 uaktyw nia przekazyw anie datagram ów IP, co oznacza, że w ęzeł mo/e
być ruterem . Jeśli w ęzeł m a jed e n interfejs sieciow y, raczej nie będzie ruterem i n a-':
leży tej stałej przypisać w artość 0.
łdefine IP OPTIONS ALLOWED
1
64
D efiniuje dom yślną w artość czasu życia (TTL, ang. tim e to live) um ieszczaną w na­
głów kach w ysyłanych datagram ów IP.
łdefine
łdefine
łdefine
łdefine
LWIP_ICMP
ICMPJTTL
LWIP_BROADCAST_PING
LWIP_MULTICAST_PING
1
64
0
0
Pierw sza z pow yższych opcji w łącza obsługę ICMP. D ruga ustaw ia w artość czasu
życia um ieszczaną w nagłów kach datagram ów IP, w których są w ysyłane kom u­
nikaty ICMP. D w ie ostatnie opcje w yłączają odpow iadanie na kom unikaty ECH O
(używ ane przez program p in g ) w ysyłane na adres rozgłoszeniow y (ang. broadcast)
i grupow y (ang. m ulticast). Ze w zględu na bezpieczeństw o w ęzeł nie pow inien od­
pow iadać na takie kom unikaty, gdyż m ogą one być próbą ataku typu odm ow a usłu­
gi (D oS, ang. denial o f service). O pcje te m ożem y uaktyw nić w zam kniętej sieci,
w której w szystkie w ęzły są zaufane,
ijdefine LWIP_RAW
0
W artość 1 tej stałej w łącza m ożliw ość bezpośredniego korzystania z w arstwy sie­
ciow ej. M ożem y być w tedy pow iadam iani o odebraniu datagram u IP i możem y
w ysyłać w łasne datagram y IP. O pcja ta je s t użyteczna, gdy chcem y rozszerzyć bi­
bliotekę lw IP o obsługę dodatkow ych opcji 1P lub zaim plem entow ać w łasny proto­
kół transportow y. Jeśli używ am y standardow ych protokołów transportow ych T C P
3. Slos TCP/IpL
98
i UDP, nie potrzebujem y bezpośredniego dostępu do w arstw y sieciow ej i dlatego y
przypisujem y tej staiej w artość 0.
łdefine LWIPJJDP
»define UDP_TTL
1
64
•■
■
'jj
Pierw sza z pow yższych staiych w łącza obsługę UDP. D ruga ustaw ia w artość czasu$
życia um ieszczaną w nagłów kach datagram ów 1P, w których są w ysyłane datagra-..^
my UDP.
łdefine LWIPJTCP
łdefine TCP_TTL
1
64
Pierw sza z pow yższych stałych w łącza obsługę TCP. D ruga ustaw ia w artość czasu ’■
życia um ieszczaną w nagłów kach datagram ów IP, w których są w ysyłane segmenty ...
TCP.
łdefine TCP_MSS
(1500
- 40)
D efiniuje m aksym alny rozm iar segm entu TCP, tak aby w ysyłane datagram y IP za-':/;
w ierające segm enty T C P nie m usiały być fragm entow ane. W artość tej stałej powin­
na być rów na w artości M TU sieci pom niejszonej o sum ę rozm iarów nagłów ków ll> ..
i TCP. M TU E thernetu w ynosi zw ykle 1500 oktetów. N agłów ki IP i T C P g e n e ro -/
w ane przez bibliotekę lw IP m ają po 20 oktetów - porów naj w pliku pbuf.h definicje^
stałych PBUF_IP_HLEN i PBUF_TRANSPORT_HLEN, które określają odpow iednio długo-"”
ści tych nagłów ków i obie m ają w artość 20.
łdefine TCP_WND
(4‘TCP_MSS)
D efiniuje m aksym alny rozm iar okna odbiorczego JC P . O kno odbiorcze m usi po­
m ieścić co najm niej dw a segm enty danych. O kno odbiorcze je st w irtualnym buforem służącym do kontroli przepływ u. R ozm iar okna w yznacza ilość danych, które X'
w ęzeł je s t skłonny przyjąć. W ęzeł odbierający inform uje w ęzeł w ysyłający o swi
im aktualnym rozm iarze okna. W ysłanie zerow ego rozm iaru okna oznacza piośbę
0 w strzym anie transm isji, gdyż w ęzeł odbierający nie przetw orzył jeszcze dotych- f ;
czas otrzym anych danych. P óźniejsze zaproponow anie niezerow ego rozm iaru
oznacza prośbę o w znow ienie transm isji. W bibliotece lw IP okno odbiorcze nie jest /
alokow ane ja k o ciągły obszar R A M . T w orzą go bufory alokow ane z puli ipołącząne w listę. D latego w artość tej stałej nie w pływ a istotnie na zajętość pam ięci.
łdefine TCP_QUEUE_0OSEQ
0
D atagram y IP m ogą być dostarczane w innej kolejności niż zostały w ysłane. Wartość
1 tej stałej spraw ia, że stos kolejkuje segm enty TCP, które zostały odebrane w złej
kolejności. W artość 0 w yłącza to kolejkow anie. D ostarczanie datagram ów w zmie­
nionej kolejności w praktyce zdarza się bardzo rzadko, a w sieciach lokalnych praw ie nigdy. System y w budow ane m ają m ało pam ięci, a kolejkow anie blokuje bufory, ,
dlatego przypisujem y tej stałej w artość 0.
łdefine TCP_SND_BUF
(4 * TCP_MSS)
D efiniuje rozm iar w irtualnego bu fo ra nadaw czego TCP. B ufor ten pełni lunkcję
podobną do okna odbiorczego, ale po stronie nadaw czej. Sieć nie działa nieskoń­
czenie szybko. Ponadto odbiorca m oże w strzym ać nadaw cę, w ysyłając mu zerowy ;
rozm iar okna. B ufor nadaw czy służy do przechow yw ania danych czekających na ■
w ysłanie. A plikacja przed w ysłaniem kolejnej porcji danych pow inna sprawdzić. ;
3.2. Biblioteka lwIP
99
czy jest dostatecznie dużo m iejsca w buforze nadaw czym . Jeśli nie ma, próba wy­
słania zakończy się niepow odzeniem - w yw ołanie funkcji w ysyłającej zakończy
się błędem . O kno nadaw cze nie je s t alokow ane ja k o ciągły obszar pam ięci. Tw orzą
go połączone w listę bufory z ram kam i do w ysłania. D latego w artość tej stałej nie
w pływ a istotnie na zajętość pam ięci.
łdefine TCP__SND_QUEUELEN
(4 * TCP_SND_BUF / TCP_MSS)
D efiniuje m aksym alną liczbę fizycznych buforów , które m ogą tw orzyć bufor
nadaw czy. D la praw idłow ego działania biblioteki param etr ten m usi m ieć w artość
co najm niej 2*TCP_SND_BUF/TCP_MSS. W artość lego param etru nie w pływ a istotnie
na zajętość pam ięci,
łdefine LWIP_DHCP
1
W artość 1 w łącza kom pilow anie klienta DHCP, który um ożliw ia uzyskanie adresu
IP, m aski podsieci, adresu rutera i adresu serw era nazw. W artość 0 w yłącza m ożli­
w ość konfigurow ania za pom ocą DHCP.
łdefine
łdefine
łdefine
łdefine
LWIP_DNS
DNS_TABLE_SI2E
DNS_MAX_NAME_LENGTH
DNS_MAX_SERVERS
1
3
48
2
Pierw sza z pow yższych stałych w łącza kom pilow anie klienta D N S. K olejne defi­
niują rozm iary struktur danych używ anych przez tego klienta. Stała DNS_TABLE_
SI ZE określa, ile odw zorow ań nazw dom enow ych na adresy IP będzie pam iętanych.
Stała DNS_MAX_NAME_LENGTH definiuje m aksym alną długość nazw, które będą obsłu­
giw ane. Stała DNS_MAX_SERVERS definiuje m aksym alną liczbę serwerów , które są do
dyspozycji klienta D N S. O pcje te m ają w pływ na zajętość RAM .
łdefine DNS_SERVER_ADDRESS
inet_addr("194.204.152.34")
K lient D N S potrzebuje adresu serw era D N S. A dresy serw erów D NS m ożna konfi­
gurow ać na kilka sposobów :
-
Jeśli nie podam y żadnego adresu, to w pliku dns.c zdefiniow any je s t adres d o ­
m yślny 208.67.222.222. Plik dns.c je s t w katalogu Jlw ip-1,3.2/src/core.
-
A dres dom yślny m ożna podać, przedefiniując stałą DNS_SERVER_ADDRESS.
-
A dres m ożna uzyskać za pom ocą DHCP.
-
A dres m ożna skonfigurow ać za pom ocą funkcji d n s _ s e ts e r v e r .
U żyta w yżej funkcja i n e t ad d r je s t przestarzała (ang. obsolete), ale je s t nadal uży­
w ana w pliku dns.c. W now ych projektach należy raczej używ ać funkcji in e t_ a to n .
Jeśli nie chcem y korzystać z D N S łub nie m a dostępu do serw era D N S, m ożna
skonfigurow ać listę stałych odw zorow ań nazw na adresy IP - patrz opis stałej DNS_
L0CAL_H0STLI ST w pliku opt.h.
O statnia grupa opcji, które m ożem y skonfigurow ać, dotyczy obliczania sum kontrol­
nych. Jak być m oże pam iętam y, sekw encja kontrolna w ram ce elhernelow ej jest w y­
liczana i spraw dzana sprzętow o przez układ M A C m ikrokontrolera. M ikrokontroler
S T M 32F107 m oże też sprzętow o w yliczać i spraw dzać sum y kontrolne w nagłów ­
kach protokołów IP, TCP, U D P i ICMP. Jest to kusząca propozycja, gdyż realizacja
sprzętow a jest zaw sze szybsza od im plem entacji program ow ej. N iestety w yliczanie
sum kontrolnych protokołów intersieci przez sprzęt łam ie fundam entalną zasadę po­
działu na warstwy. Popraw na im plem entacja sum kontrolnych w ym aga uw zględnie­
nia w szystkich opcji protokołu, co w praktyce je st niem ożliw e, gdyż oznacza ko­
nieczność zaim plem entow ania całości protokołu. Jak należało się tego spodziewać,
im plem entacja sum kontrolnych w ST M 32F107 jest niepełna. N ie uw zględnia fragm entacji IP. Jest też praw dopodobne, że nie poradzi sobie z dodatkow ym i opcjami"
IP. Ponadto w bibliotece lw IP nie przew idziano prostego sposobu przekazania stoso­
wi inform acji o stw ierdzeniu przez sprzęt błędnej sum y kontrolnej. W łączenie przez
sprzęt w yliczania sum kontrolnych IC M P w ym aga dodatkow o m odyfikacji tekstu
źródłow ego biblioteki lwIP, co m oże pow odow ać problem y z kom patybilnością apli
kacji z przyszłym i w ersjam i tej biblioteki. W szystko to przem aw ia przeciw w łącza­
niu sprzętow ych sum kontrolnych. W poniższych definicjach w artość 0 oznacza uak­
tyw nienie realizacji sprzętow ej, a 1 oznacza w łączenie im plem entacji programowej.
łdefine CHECKSUM_GEN_IP
znajduje się w katalogu ./exam ples/include. O pisana w poprzednim podrozdziale
konfiguracja biblioteki lw IP w ym aga skom pilow ania tylko plików, których nazwy
są zam ieszczone w tabeli 3.3.
3.2.4.
0
Tab. 3.4. W artości zwracane przez funkcje biblioteki lwIP
Stała
1
Sum a kontrolna odbieranych datagram ów IP je st spraw dzana program ow o, gdyż ; |
m ogą pojaw ić się nagłów ki IP z dodatkow ym i opcjam i.
łdefine
łdefine
łdefine
łdefine
CHECKSUM_GEN_UDP
CHECKSUM_GEN_TCP
CHECKSUM_CHECK_UDP
CHECKSUM_CHECK_TCP
1
1
1
1
Sum y kontrolne U D P i T C P są generow ane i spraw dzane program ow o.
3.2.3.
Kody błędów
F unkcje biblioteki lw IP i funkcje w spółpracujące z nią zw racają w artość typu e r r _ t ,
sygnalizującą popraw ne zakończenie lub kod błędu, gdy w ykonanie funkcji zakoń­
czy się niepow odzeniem . Stale reprezentujące w artości typu e r r _ t są zdefiniow ane
w pliku err.h. Znaczenie poszczególnych stałych jest opisane w tabeli 3.4. Stała
E R R _ 0 K ma w artość 0 i oznacza popraw ne zakończenie funkcji. Pozostałe stale mają
w artości ujem ne i oznaczają w ystąpienie błędu. W przykładach stosuję podobne
podejście. Jeśli funkcja m a poinform ow ać, że zakończyła się popraw nie, to zwraca
zero. G dy w ystąpił błąd, funkcja zw raca w artość ujem ną.
Sum a kontrolna w ysyłanych datagram ów IP je st generow ana sprzętow o. Tę opcję"’'
m ożem y w łączyć, poniew aż lw IP praw dopodobnie nigdy nie w ygeneruje nagłówka:;
IP z dodatkow ym i opcjam i,
łdefine CHECKSUM_CHECK_IP
101
3.2. Biblioteka lwIP
3. Stos TCP/IP
100
Opis
ERR OK
Poprawne zakończenie
ERR MEM
Brak pamięci
ERR BUF
Problem z buforem
ERR TIMEOUT
Przekroczony czas
ERR RTE
Problem z trasowaniem
ERR ABRT
Połączenie przerwane
ERR RST
Połączenie skasowane
ERR CLSD
Połączenie zamknięte
ERR CONN
Połączenie nieotwarte
ERR VAL
Błędna wartość
Kompilowanie - plik Iiblw ip4.a
ERR ARG
Problem z argumentem
B ibliotekę lw IP należy skom pilow ać, posługując się w skazów kam i podanymi
w rozdziale 1.4. D alej zakładam , że skom pilow ana biblioteka została um ieszczo­
na w pliku liblw ip4.a. N azw y katalogów , które zaw ierają pliki biblioteki lwIP, s ą ,
zebrane w tabeli 3.2. Ponadto potrzebny je s t plik nagłów kow y Iw ipopts.h, który
ERR USE
Adres lub port zajęty
ERR IF
Niskopoziomowy błąd interfejsu sieciowego
Tab. 3.2. Katalogi z plikami biblioteki lwIP
Źródłowe
Jlw ip-1.3.2/src/api
Jlw ip-1.3.2/srclcore
Jlw ip-1.3.2/src/carelipv4
J lw ip -1.3.2/src/core/snm p
Jlw ip-1.3.2/src/netif
3.2.5.
Nagłówkowe
ERR ISCONN
Połączenie już zestawione
ERR INPROGRESS
Operacja w trakcie
Struktura pbuf
B iblioteka lw IP przechow uje pakiety sieciow e w buforach, które są w skazyw ane
za pom ocą struktury typu pbuf zdefiniow anej w pliku pbuf.h. Zrozum ienie zasad
posługiw ania się buforam i je st bardzo istotne. B ez tego trudno jest pisać popraw ne
i efektyw ne aplikacje używ ające biblioteki lwIP. Struktura typu p b u f opisuje poje­
dynczy bufor.
Jlw ip-1,3.2/srclinclude/ipv4/lwip
Jlw ip -1.3.2/srclincludellwip
Jlw ip-1.3.2/srclinclude/netif
Jexampleslinclude/arch
Tab. 3.3. Pliki źródłowe biblioteki lwIP
Inicjow anie 1 obsługa pam ięci
Jlw ip- 1.3.2/src/core/inlt.c
. /Iw ip -1.3.2/src/core/m em . c
Jlw ip- 1.3.2lsrclcorelm em p. c
Jlwip- 1.3.2lsrc/core/pbuf.c
A R P IIP
Jlw ip-1.3.2/src/netifletharp.c
Jlwip- 1.3.2/src/core/neti!.c
./Iw ip -1.3.2lsrc/core/ipv4/icm p. c
J lw ip -1.3.2/src/core/ipv4/inet. c
Jlw ip-1.3.2/src/corelipv4/inet_chksum .c
Jlw ip -1.3.2/srclcorelipv4/ip. c
Jlwip-1.3.2/src/corelipv4/ip_addr.c
Jlw ip- 1.3.2/src/corelipv4/lp Irag.c
W arstw y transportowa 1 aplikacji!
Jlw ip -1.3.2/srclcore/dhcp. c
Jlwip- 1.3.2/srclcore/dns.c
Jlw ip-1.3.2/src/core/lcp.c
Jlwip- 1.3.2/src/c o re ltcp jn .c
.Ilw ip -1.3.2/src/co re /tcp jiu t. c
Jlwlp-1.3.2/src/core/udp.c
struct pbuf (
struct pbuf
void
uI6 t
ul6_t
uB t
u8_t
ul6 t .
);
*next;
*payload;
tot len;
len;
type;
flags;
ref;
102
3.2. Biblioteka lwiP
3. Stos TCP/ip
tokołów. D zięki tem u dokładanie tych nagłów ków nie w ym aga polem dodatkow ej
alokacji pam ięci czy kopiow ania zaw artości bufora. A rgum ent ten m oże przyjm o­
wać następujące w artości:
Składow a p ay lo a d je s t w skaźnikiem do bufora przechow ującego dane. B ufor może,
być zarów no w pam ięci operacyjnej (R A M ), ja k i w pam ięci staiej (R O M , Flash),
W skaźnik n e x t łączy struktury w listę. W skaźnik ten w ostatniej strukturze na li:
scic m a w artość NULL. L ista struktur p bu f um ożliw ia podział pakietu na fragmenty,
i um ieszczenie poszczególnych fragm entów w kolejnych buforach. Taka lista na-:
żyw a się w dokum entacji biblioteki lw IP łańcuchem buforów (ang. buffer chain);
Z a pom ocą w skaźnika n e x t pakiety m ogą też być łączone w kolejkę (ang. packetqueue). Z atem kolejka pakietów składa się z jed n eg o lub w iększej liczby pakietów,'
z których każdy je st um ieszczony w łańcuchu buforów. Łańcuch m oże zawierać'}
jeden lub w iele buforów. K oniec łańcucha m ożna rozpoznać za pom ocą składowych -;
t o t _ l e n i len . Składow a l e n zaw iera długość bufora. S kładow a to t _ l e n zawieracałkow itą długość pakietu, czyli sum ę długości w szystkich buforów w łańcuchu.,
O statnia struktura w łańcuchu m a rów ne w artości tych składow ych i je s t to je d y n v
popraw ny sposób rozpoznaw ania k ońca łańcucha buforów. Ponadto dla łańcucha
buforów obow iązuje niezm iennik:
-
Funkcja p b u f _ r e a l l o c zm niejsza rozm iar łańcucha buforów w skazyw anego przez
p do podanego rozm iaru new le n . Z ależnie od podanej nowej długości łańcuch
m oże zostać skrócony, a niepotrzebne bufory m ogą być zw olnione. W brew nazw ie,
funkcja ta nie m oże pow iększyć rozm iaru bufora. Jeśli bufor je s t typu PBUF REF łub
PBUF_R0M, m odyfikow ane są tylko składow e t o t _ l e n i le n struktury typu pbuf.
Składow a ty p e oznacza sposób alokacji bufora i m oże przyjm ow ać następujące;
w artości:
-
PBUF RAM - bufor je s t alokow any w jed n y m kaw ałku na stercie;
PBUF_R0M - struktura opisuje dane tylko do odczytu, bufor je s t w pam ięci stałej; A;
PBUF_REF - struktura je s t referencją do innej struktury typu pbuf, żaden bufor nic ij|
je st alokow any;
(
PBUF_P00L - bufor je s t alokow any z puli buforów biblioteki lw iP o stałym roz- ■
m iarze; jeśli żądam y bufora o rozm iarze w iększym niż PBUF_P00L_SIZE, to jest-'(j!>
przydzielany łańcuch buforów zaw ierający w iele buforów.
.!;)
Składow a f l a g s je s t przeznaczona do przechow yw ania znaczników , ale w ydaje się, ■
że nie je s t używ ana przez bibliotekę lwiP. Składow a r e f je s t licznikiem referencji,
zaw iera liczbę w skaźników odw ołujących się do tej struktury. M oże to być wskażnik n e x t w innej strukturze typu p b u f lub ja k iś inny w skaźnik w ew nątrz biblioteki .“
lw iP lub aplikacji.
W pliku p hu f.c zaim plem entow ane są funkcje obsługujące bufory. N ajw ażniejsze
z nich opisuję niżej.
void
pbuf_ref(struct pbuf *p ) :
Funkcja p b u f _ r e f zw iększa licznik referencji w podanej strukturze typu pbuf.
u8_t
pbuf_£ree(struct pbuf *p);
Funkcja p b u f f r e e zm niejsza licznik referencji i jeśli licznik ten osiągnie zero,
zw alnia nieużyw ane bufory i struktury je opisujące. D la łańcucha buforów operacja
ta je st pow tarzana dla w szystkich struktur na liście, aż do natrafienia na pierw szą,
która po zm niejszeniu nadal ma licznik referencji w iększy od zera. Zatem , jeśli
w szystkie liczniki referencji w łańcuchu m ają w artość jed en , cały łańcuch je st zw al­
niany. F unkcja ta zw raca liczbę zw olnionych struktur typu pbuf.
u8_t
pbuf_clen(struct pbuf *p);
struct pbuf *
pbuf_alloc{pbuf_layer layer,
ul6_t length,
pbuf_type type);
Funkcja p bu f a l l o c alokuje łańcuch buforów. Z w raca w skaźnik do pierwszej
struktury typu pbuf w łańcuchu łub w artość NULL, gdy alokacja się nie powiodła.
A rgum ent ty p e ma to sam o znaczenie, co składow a o lej sam ej nazw ie w struktu­
rze typu pbuf i określa sposób alokacji buforów. A rgum ent l e n g t h określa żądanj
rozm iar bufora. Jeśli żądam y alokacji z puli buforów biblioteki lw iP i rozm iar teri
jest w iększy niż rozm iar pojedynczego bufora w puli, to przydzielony będzie łań­
cuch składający się z odpow iedniej liczby buforów. A rgum ent l a y e r określa, ile
dodatkow ego m iejsca na początku bufora m a być zarezerw ow ane na nagłów ki pro­
PBUF_TRANSPORT - alokujem y bufor na dane protokołu transportow ego (T C P lub
U D P);
PBUF IP - alokujem y bufor na pole danych datagram u 1P;
PBUF_LINK - alokujem y bufor na pole danych protokołu dostępu do sieci, np.
pole danych ram ki ethernetow ej;
PBUF RAW - alokujem y bufor na surow e dane, np. kom pletną ram kę ethernetow ą.
void
pbuf_realloc(struct pbuf *p,
u!6_t new_len);
p->tot_len == p->len + (p->tot_len != p->len ? p->next->tot_len ; 0)
-
103
Funkcja p b u f c le n zw raca liczbę struktur na liście, począw szy od w skaźnika p, aż
do napotkania w skaźnika n e x t zaw ierającego NULL.
.
err_t
pbuf_take(struct pbuf *buf,
const void *dataptr,
u!6 t len);
F unkcja p b u f _ t a k e kopiuje le n bajtów danych w skazyw anych przez d a t a p t r do
łańcucha buforów w skazyw anego przez b uf. Z w raca ERR_0K, gdy kopiow anie po­
w iodło się, a ERR ARG, gdy jeden z podanych w skaźników jest zerow y lub w łańcu­
chu buforów nie m a dostatecznie dużo m iejsca.
'I
vj
3. Stos TCP/ft*
104
F unkcja p b u f _ c o p y j ? a r t i a l kopiuje dane z łańcucha buforów b u f do bufora dat a p t r . K opiow anych je st le n bajtów, ale nie w ięcej niż b u f - > t o t _ l e n . A rgum ent'!
o f f s e t je s t przesunięciem , od którego dane są kopiow ane z łańcucha buforów,tj
Funkcja ta zw raca liczbę skopiow anych bajtów lub zero, gdy w ystąpił błąd.
Struktura
n e tif
B iblioteka lw IP przechow uje konfigurację interfejsu sieciow ego w strukturze typu
n e t i f , która jest zdefiniow ana w pliku netif. h. Struktura ta m a w iele pól. Niektóre $
pola są kom pilow ane w arunkow o, zależnie od ustaw ień w plikach opt.h i lwiopts.h]$B
Poglądow a definicja tej struktury, ale zupełnie w ystarczająca do zrozum ienia /a s.i- $
dy działania sterow nika interfejsu sieciow ego, je s t następująca:
struct netif {
struct netif *next;
struct ip_addr ip_addr;
struct ip_addr netmask;
struct ip_addr gw;
err_t {* input)(struct pbuf *p, struct netif *inp);
err_t {* output)(struct netif *netif, struct pbuf *p,
struct ip_addr *ipaddr);
err_t (* linkoutput)(struct netif *netif, struct pbuf *p);
void *state;
struct dhcp *dhcp;
ul6_t mtu;
u8_t hwaddr_len;
u8_t hwaddr [NETIF_MAX__HWADDR_LEN) ;
u8_t flags;
char name(2);
u8_t num;
105
w arstw y dostępu do sieci. D la Ethernetu biblioteka lw IP m a ju ż gotow ą funkcję
odbiorczą e t h e r n e t in p u t , która jest zadeklarow ana w pliku etharp.h, a jej im ­
plem entacja znajduje się w pliku etharp.c. Funkcja e t h e r n e t _ i n p u t analizuje na­
głów ek ram ki ethernetow ej i zajm uje się obsługą ARP, dlatego w tym przypadku
bufor pow inien zaw ierać ram kę ethernelow ą. Jeśli używ am y w arstw y dostępu do
sieci innej niż E thernet, to jak o funkcji odbiorczej m ożna użyć funkcji ip _ i n p u t ,
która je s t zadeklarow ana w pliku ip.h, a jej im plem entacja znajduje się w pliku ip.c.
F unkcja ip _ i n p u t oczekuje w buforze datagram u IP i w tym przypadku to sterow ­
nik interfejsu sieciow ego musi przeanalizow ać nagłów ek w arstw y dostępu do sieci,
a następnie usunąć go z odebranego pakietu.
ul6_t
pbuf_copy_partial{struct pbuf *buf,
void *dataptr,
ul6_t len,
ul6 t offset);
3.2.6.
3.2. Biblioteka IwiP
r(*
'.¿T
•
J"•$,
v.
l;
B iblioteka lw IP m oże obsługiw ać w iele interfejsów sieciow ych. S truktury typu
t i f opisujące kolejne interfejsy tw orzą listę. Składow a n e x t w skazuje na następną
strukturę na lis'cie i je st używ ana tylko w ew nątrz biblioteki lwIP.
Składow e ip__addr, netmask, gw zaw ierają odpow iednio adres IP, m askę podsieci
i adres rutera. D ane te są zapisyw ane w sieciow ym porządku oktetów. Składowi
te są inicjow ane w funkcji n e t i f _ a d d , której opis znajduje się w dalszej c
rozdziału. Ponadto są też m odyfikow ane przez klienta DHCP, jeśli zostanie urucho- *
miony.
Składow a in p u t zaw iera adres funkcji odbiorczej, którą sterow nik interfejsu sie­
ciow ego w yw ołuje, aby przekazać odebrany pakiet do stosu TCP/IP. Składow a l
je st konfigurow ana za pom ocą funkcji n e t i f _ a d d . Pierw szym argum entem funkcji-'A*
odbiorczej je s t w skaźnik do struktury typu pbuf, która opisuje b u for zawiei
odebrany pakiet. D rugim argum entem je s t w skaźnik do struktury typu n e t i f , o p i­
sującej interfejs sieciow y, który odebrał pakiet. Funkcja odbiorcza zależy od użył
-•pili
■¿c
Składow ej o u t p u t należy podczas inicjow ania sterow nika przypisać adres funk­
cji nadaw czej, którą stos TCP/1P pow inien w yw ołać, aby w ysiać datagram IP. Dla
E thernetu należy użyć funkcji e t h a r p _ o u t p u t , która obsługuje A R P i je st częścią
biblioteki lwIP. F unkcja ta je s t zadeklarow ana w pliku etharp.h, a jej im plem entacja
je st w pliku etharp.c. Pierw szym argum entem funkcji nadaw czej je s t w skaźnik do
struktury typu n e t i f , opisującej interfejs sieciow y, przez który ma być wystany
datagram . D rugim argum entem jest w skaźnik do struktury typu pbuf, opisującej
łańcuch buforów z datagram em IP do w ysiania. Trzeci argum ent jest w skaźnikiem
do .struktury zaw ierającej adres IP, na który należy w ysiać datagram . Pam iętajm y, że
datagram często je s t w ysyłany na inny adres niż ten um ieszczony w jeg o nagłów ku,
np. na adres rutera.
I
Składow ej l i n k o u t p u t należy podczas inicjow ania sterow nika interfejsu sieciow e­
go przypisać adres niskopoziom ow ej funkcji nadaw czej, która pow inna być w y­
w ołana w celu w ysiania pakietu przez ten interfejs. Ta niskopoziom ow a funkcja
m usi być zaim plem entow ana w sterow niku i zw ykle nazyw a się l o w _ le v e l _ o u tp ut. P ierw szym jej argum entem je st w skaźnik do struktury typu n e t i f , opisującej
interfejs sieciow y, przez który m a być w ysłany pakiet. D rugim argum entem je st
w skaźnik do struktury typu pbuf, opisującej łańcuch buforów zaw ierający w ysyłany
pakiet, który m usi zaw ierać nagłów ki w szystkich w arstw kom unikacji. Funkcja ta
nie pow inna m odyfikow ać w ysyłanych danych.
Składow a s t a t e je s t przew idziana do w ykorzystania przez sterow nik interfejsu sie­
ciow ego. B iblioteka lw IP je j nie czyta i nie m odyfikuje. W tej składow ej m ożna
przechow yw ać adres struktury zaw ierającej pryw atne dane sterow nika.
Składow a dhcp zaw iera adres struktury w ykorzystyw anej przez klienta D H C P zw ią­
zanego z interfejsem sieciow ym .
Składow a mtu zaw iera M T U sieci. Składow a hw addr_len zaw iera długość w okte­
tach adresu sprzętow ego. Składow a hwaddr zaw iera adres sprzętow y. Stała NETIF_
MAX_HWADDR_LEN m a w artość 6. Składow e te m uszą być ustaw ione podczas inicjo­
w ania sterow nika interfejsu sieciow ego.
Składow a f l a g s jest zbiorem jednobitow ych znaczników opisujących stan interfejsu
sieciow ego. Z naczniki zdefiniow ano w pliku n e tif h. Są one zam ieszczone w ta b e ­
li 3.5. Z naczniki należy m odyfikow ać za pom ocą operatora alternatyw y logicznej,
gdyż biblioteka lw IP rów nież m odyfikuje niektóre z nich.
107
3.3. DMA
Jeśli ram ka nie m ieści się w pojedynczym buforze, m oże być um ieszczona w kilku
kolejnych buforach, w skazyw anych przez kolejne deskryptory. W trybie pierście­
niow ym każdy deskryptor m oże w skazyw ać na dw a kolejne bufory.
Tab. 3.5. Znaczniki opisujące stan interfejsu sieciowego
Opis
Znacznik
NETIF FLAG UP
W arstwa sieciowa jest aktywna - interfejs przetwarza pakiety
NETIF FLAG BROADCAST
Ten interfejs może wysyłać pakiety rozgloszeniowe
NETIF FLAG POINTTOPOINT
Jest to interfejs typu punkt-punkt
NETIF FLAG DHCP
Dla tego interfejsu został skonfigurowany klient DHCP
NETIF FLAG LINK UP
Warstwa dostępu do sieci jest aktywna
NETIF FLAG ETHARP
Jest to interfejs ethernetowy używający ARP
NETIF FLAG IGMP
Ten interfejs używa IGMP
Z astosow any w m ikrokontrolerze S T M 32F 107 układ D M A nie m oże obsługiw ać
jed n o cześnie obu kolejek. Jeśli w kolejce nadaw czej czekają ram ki do w ysłania
i rów nocześnie są odbierane ram ki, które trzeba skopiow ać do kolejki odbiorczej,
potrzebny je st arbitraż. P rzew idziano dw a w arianty arbitrażu:
-
Składow a name zaw iera dw uznakow ą nazw ę interfejsu sieciow ego. N azw a pozwala-1;
w yszukiw ać interfejs za pom ocą funkcji n e t i f _ f i n d . O pcja ta je s t przydatna, gdy.',
je s t w iele interfejsów sieciow ych. S kładow a num zaw iera num er interfejsu sieciowe- "
go. Pozw ala to rozróżniać interfejsy o tej sam ej nazw ie. Składow a nura ja k dotąd nie :
je s t używ ana w ew nątrz biblioteki lwiP.
stosow any je s t karuzelow y algorytm szeregow ania (ang. round robin scheduling
a lg o rithm );
- zaw sze preferow ana je s t kolejka odbiorcza, ram ki są kopiow ane z buforów
nadaw czych do M A C tylko wtedy, gdy żadna odebrana ram ka nie czeka na sko­
piow anie do bufora odbiorczego.
Tab. 3.6. Składowa s ta tu s deskryptora odbiorczego
Pola
DMA
status
Bufor
Bufor 1
Deskryptor 0
Jest to pole statusu, wypełniane przez DM A po zakończeniu kopiowania. Najważniejsze bity
tego pola opisane są w następnych wierszach
FL
2 9 ...1 6
Całkowita długość w bajtach odebranej i skopiowanej ramki (ang. tramę length). To pole
jest istotne tylko dla deskryptora, który ma wyzerowany bit e s i ustawiony bit l s
ES
15
W artość 0 oznacza, że kopiowanie zakończyło się poprawnie. Wartość 1 oznacza, że w y­
stąpił błąd (ang. error sum m ary). Dokładny opis błędu zawierają inne bity pola status
FS
9
Wartość 1 oznacza, że jest to pierwszy w kolejce deskryptor opisujący odebraną ramkę.
Innymi słowy, ten deskryptor wskazuje na bufor zawierający pierwszy fragment ramki (ang.
lirst segment)
LS
8
Wartość 1 oznacza, że jest to ostatni w kolejce deskryptor opisujący odebraną ramkę.
Innymi słowy, ten deskryptor wskazuje na bufor zawierający ostatni fragment ramki (ang.
last segment)
Tab. 3.7. Składowa controlB ufferSize deskryptora odbiorczego
Polo
Deskryptor 0
31
O
*
OWN
Opis
W artość 1 oznacza, że DMA jest właścicielem (ang. own) deskryptora. DMA zeruje ten bit,
gdy zakończy kopiowanie odebranej ramki i wypełni bufor lub bufory wskazywane przez
ten deskryptor. Program ustawia ten bit, aby zwrócić deskryptor odbiorczy układowi DMA
O
co
Do obsługi interfejsu ethernetow ego przew idziano w m ikrokontrolerze STM 32F107
układ D M A , który używ a dw óch cyklicznych kolejek buforów. D M A kopiuje ode­
%
brane przez układ M A C ram ki d o kolejki odbiorczej, gdzie czekają na obsłużenie
przez aplikację. A plikacja w staw ia ram ki do kolejki nadaw czej, gdzie czekają na ł.Wf
•tttt
skopiow anie ich przez D M A do układu M A C . K olejki zorganizow ane są za pom o­ i f
cą deskryptorów D M A . D eskryptor m a dw ie składow e, które przechow ują adresy.
K olejka buforów m oże tw orzyć łańcuch (ang. chain), ja k w idać to na ry s u n k u 3.1.
Jeden z adresów jest w tedy używ any do w skazania bufora w pam ięci, a drugi w ska­
zuje następny deskryptor w kolejce. M ożna też użyć tablicy deskryptorów , ja k na
ry s u n k u 3.2, Ten w ariant nazyw any je st w dokum entacji pierścieniem (ang. ring).
W tedy oba adresy w deskryptorze m ogą w skazyw ać bufory w pam ięci, a o kolejno­
ści deskryptorów w kolejce decyduje indeks w tablicy. A by uzyskać zapętlenie, po
ostatnim deskryptorze następuje pierw szy - o zerow ym indeksie. K olejki działają
w edług zasady: pierw szy zgłoszony - pierw szy obsłużony (ang. fir s t in , fir s t out).
Bity
DIC
Biły
Opis
31
Ustawienie tego bitu blokuje zgłaszanie przerwania po odebraniu ramki (ang. disable inter­
rupt on completion). Gdy jest wyzerowany, przerwanie jest zgłaszane po odebraniu i skopio­
waniu ramki
Bufor 2
30...29 Zarezerwowane
Bufor 1
Bufor 2
Bufor
D eskryptor n -
15
Gdy bit r c h ma wartość 0, to wartość 1 w tym polu oznacza, że jest to ostatni deskryptor
w pierścieniu (ang. receive end o! ring)
RCH
14
Wartość 0 oznacza, że ten deskryptor jest skonfigurowany w trybie pierścieniowym. War­
tość 1 oznacza, że ten deskryptor jest skonfigurowany w trybie łańcuchowym (ang. receive
chain), a składowa Bu£fer2NextDescAddr zawiera adres następnego deskryptora
13
Zarezerwowane
Bufor 1
D eskryptor n-1
RBSł
Rys. 3.2. Pierścień deskryptorów
Gdy bit r c h ma wartość 0, pole to zawiera długość w bajtach bufora (ang. receive buffer 2
size) wskazywanego przez składową Bu£fer2NextDescAddr. Wartość w tym polu musi
być wielokrotnością 4. Gdy bit r c h ma w artość 1, pole to nie jest używane
RER
Bufor 2
Rys. 3.1. Łańcuch deskryptorów
CD
Deskryptor 1
RBS2
Deskryptor 1
CO
CO
Bufor
1 2 .. .0
Zawiera długość w bajtach bufora (ang. receive buffer 1 size) wskazywanego przez składo­
w ą Buf feriAddr. Wartość w tym polu musi być wielokrotnością 4
3.4. Przykład 3a - pierwsza wersja sterownika Ethernetu
Tab. 3.9. Składowa controiB ufferSize deskryptora nadawczego
Jeśli stosujem y arbitraż karuzelow y, to m ożna dodatkow o ustaw ić w sp ó łc z y n n ik
określający, ile razy częściej je st w ybierana kolejka odbiorcza w stosunku do koJi
lejki nadaw czej. W spółczynnik ten m oże mieć jed n ą z czterech w artości: 1 do 1, '¿Ą
do 1, 3 do 1, 4 do 1.
Pole
TBS2
typecief struct {
uint32_t Status;
uint32_t ControlBufferSize;
uint32_t BufferlAddr;
uint32_t Buffer2NextDescAddr;
} E?H__DMADESCTypeDef;
TBS1
Bity
Opis
OWN
31
Wartość 1 oznacza, że DMA jest właścicielem (ang. own) deskryptora. DMA zeruje ten bit, gdy zakończy t
kopiowanie z bufora lub buforów wskazywanych przez ten deskryptor. Program ustawia ten bit, aby zasy­
gnalizować układowi DMA, że deskryptor wskazuje na dane, które są gotowe do wysiania
IC
30
Wartość 1 oznacza, że po zakończeniu transmisji ramki, opisanej tym deskryptorem, zostanie zgłoszone
przerwanie (ang. interrupt on completion)
LS
29
Wartość 1 oznacza, że jest to ostatni w kolejce deskryptor opisujący ramką do wysiania, Innymi słowy, ten'
deskryptor wskazuje na bufor zawierający osfafni fragment ramki (ang. iast segment)
FS
28
W artość 1 oznacza, że jest to pierwszy w kolejce deskryptor opisujący ramkę do wysiania. Innymi stówy,
ten deskryptor wskazuje na bufor zawierający pierwszy fragment ramki (ang. //rei segment)
DC
27
W artość 1 blokuje automatyczne dołączanie przez MAC sekwencji kontrolnej (ang. disable CRC) do wysy­
łanej ramki. Ten bit jest istotny tylko dla deskryptora, w którym bit f s m a wartość 1
26
Wartość 1 blokuje automatyczne uzupełnianie przez MAC wysyłanej ramki do minimalnej długości (ang.
disable pad). Ten bit jest istotny tylko dla deskryptora, w którym bit f s ma wartość 1
25
W artość 1 aktywuje dla wysyłanej ramki, opisanej tym deskryptorem, znacznik czasu zgodny z normą
IEEE 1588 (ang. transmit time stamp enable). Ten bit jest istotny tylko dla deskryptora, w którym bit fs
m a wartość 1
24
Zarezerwowane
DP
TTSE
X*
3.4.
10 - wstawiane są suma kontrolna nagłówka datagramu IP oraz sumy kontrolne ICMR TCP i UDR ale
suma kontrolna pseudonaglówka nie jest wyliczana sprzętowo,
11 - wstawiane są suma kontrolna nagłówka datagramu IP oraz sumy kontrolne ICMR TCP I UDR suma
kontrolna pseudonaglówka jest wyliczana sprzętowo
TER
21
Gdy bit TCH ma wartość 0, to wartość 1 w tym polu oznacza, że jest to ostatni deskryptor w pierścieniu
(ang. transmit end o1 ring)
TCH
20
Wartość 0 oznacza, że ten deskryptor jest skonfigurowany w trybie pierścieniowym. W artość 1 oznacza,
że ten deskryptor jest skonfigurowany w trybie łańcuchowym (ang. transmit Chain), a składowa Buf fer2NextDescAddr zawiera adres następnego deskryptora
TTSS
17
status
1 6 ...0
ES
15
Zarezerwowane
Wartość 1 oznacza, że składowe BufferlAddr i Buf fer2NextDescAddr zawierają znacznik czasu wysta­
nej ramki, opisanej tym deskryptorem, zgodny z IEEE 1588 (ang. transmit time stamp status). Ten bit jest
istotny tylko dla deskryptora, w którym bit l s m a wartość 1
Jest to pole statusu, wypełniane przez DM A po zakończeniu transmisji. Najważniejszy bit tego pola jest
opisany w następnym wierszu
Wartość 0 oznacza, że transmisja przebiegła poprawnie. Wartość 1 oznacza, że wystąpił błąd (ang. error
sum m ary). Dokładny opis błędu zawierają pozostałe biiy pola status
12. ..0
Zarezerwowane
Długość w bajtach butora wskazywanego przez składową BufferlAddr (ang. transmit
bul/er 1 size)
Przykład 3a - pierwsza wersja sterownika
Ethernetu
Podstaw ow ym celem tego przykładu je s t napisanie sterow nika pośredniczącego
m iędzy biblioteką lw IP a m ikrokontrolerem . N azw y plików, które zaw ierają im ­
plem entację przykładu, zam ieszczone są w tabeli 3.10. Sterow nik prezentow any
w tym przykładzie jest pierw szym z trzech, które opisuję. Stosuje on najprostsze
podejście, polegające na alokow aniu statycznych buforów odbiorczych i nadaw ­
czych. D M A kopiuje odebraną ram kę ethernetow ą do takiego bufora odbiorczego.
N astępnie sterow nik kopiuje odebraną ram kę z bufora odbiorczego do bufora bi­
blioteki lwIP. W ysyłaną ram kę sterow nik kopiuje z bufora biblioteki lw IP do bufora
nadaw czego, z którego D M A kopiuje ją do układu M AC.
01 - wstawiana jest tylko suma kontrolna nagłówka datagramu IR
1 9 ...1 8
2 8 . . .16
B ardziej szczegółow y)opis deskryptorów m ożna znaleźć w 1.8]. O m ów ienie znacz­
ników czasu i norm y IE E E 1588 w ykracza poza zakres tej książki. Sumy kontrolne
i pseudonaglów ki U D P i T C P są opisane odpow iednio w RFC 768 i RFC 793.
Sum a kontrolna IC M P je st opisana w RFC 792.
%A'
To pole steruje wstawianiem sum kontrolnych (ang. cliecksum insertion contro1) w protokołach intersieci:
2 3 ...2 2
Opis
Zarezerwowane
Jeśli pole TCH składowej status ma wartość 0, pole to zawiera długość w bajtach drugiego
bufora (ang. transmit butler 2 size), wskazywanego przez składową Buffer2NextDescAddr. Jeśli pole t c h składowej status ma wartość 1 , pole to nie jest używane
D eskryptor zajm uje 128 bitów. W bibliotece ST M 32, w pliku stin32_elh.li zde­
finiow ano go ja k o strukturę ETH_DMADESCTypeDef składającą się z czterech słów
32-bilow ych. Składow a B u ffe r lA d d r struktury typu ETH_DMADESCTypeDef zaw iera
adres pierw szego bufora. Składow a B uffer2NextDescAddr w trybie łańcuchow ym
zaw iera adres następnego deskryptora, a w trybie pierścieniow ym - adres drugiego
bufora. Poszczególne bity dw óch pierw szych składow ych dla deskryptora odbior­
czego są om ów ione w tabelach 3.6 i 3.7. O pisy tych składow ych dla deskryptora
nadaw czego zam ieszczone są w tabelach 3.8 i 3.9. Bity w tabelach num erow a­
ne są typow o dla procesora cienkokońców kow ego, czyli od najm niej znaczącego
do najbardziej znaczącego. N ajstarszy bit składow ej S t a t u s w yznacza w łaściciela
deskryptora. G dy w łaścicielem deskryptora je s t D M A , program ow i nie w olno go
m odyfikow ać i nie pow inien też go czytać.
00 - sumy kontrolne nie są wstawiane,
CIC
Bity
31...29
15...13
Tab. 3.8. Składowa status deskryptora nadawczego
Polo
109
i
i
■
3.4.1.
Pliki u tiljim e .h i u tiljim e .c
P rotokoły sieciow e w ym agają odm ierzania czasu. Jest to potrzebne na przykład
po to, aby nie czekać w nieskończoność na odpow iedź. B iblioteka lw IP je st ste­
row ana zdarzeniam i. Jednym ze zdarzeń jest odebranie pakietu sieciow ego. Innym
rodzajeni zdarzenia je st upłynięcie czasu. B iblioteka lw IP potrzebuje zegara, któ­
ry będzie zgłaszał cykliczne zdarzenia. Jednak im plem entacja takiego zegara jest
110
3. Stos TCP/lfiI
Tab. 3.10. Pliki przykładu 3a
Źródłowe i biblioteczne
e x jp .c
font5x8.c
startup _stm32__cld. c
board conf.c
board init.c
board_lcd_ks0108.c
boardJed. c
lont5x8.h
board conf.h
board def.h
board deis.h
board init.h
b o a rd je d .h
b o a rd je d .h
util delay, c
util eth.c
utilJed. c
utilJed_ex,c
utilJ e d . c
util Iwip.c
util time.c
Iiblwip4.a
Iibstm 32l10x.a
Maylówkowe
util delay.h
util eth.h
util led.h
util led ex.h
u tilje d .h
ulHJwip.h
util time.h
cc.h
cortex-m 3.li
Iwipopts.h
stm 32/10x conf.h
bardzo zależna od sprzętu. W rdzeniach C ortex-M 3 przew idziano do tego celu 24-’;
-bitow y licznik system ow y (ang. system tim er), nazyw any w dokum entacji SysTick..
W ykorzystam y ten licznik do cyklicznego zgłaszania przerw ania, które będzie sy­
gnalizow ało bibliotece lw IP upływ czasu. W tym podrozdziale opisuję m oduł ob-’
sługujący SysTick. Jest on napisany na tyle ogólnie, że m oże być w ykorzystany nie';
tylko z biblioteką lwIP.
W pliku nagłów kow ym util_tim e.h definiujem y częstotliw os'ć zegara biblioteki
lw IP w H z i je g o okres tykania w m ilisekundach. Lcjkalny czas będziem y mierzyć,'
w m ilisekundach za pom ocą 64-bitow ych liczb bez znaku. W praktyce pozw ala to;.’,
odm ierzać dow olnie długie odstępy czasu. Z m ienne przechow ujące lokalny czas;
będą typu l t i m e _ t . Ponadto definiujem y typ t i m e _ c a l l b a c k _ t funkcji zwrotnej,;,
którą będzie m ożna skonfigurow ać, aby była cyklicznie w yw ołana w procedurze,
obsługi przerw ania zegara system ow ego. Podana funkcja zw rotna będzie generowa-;
la w łaściw e zdarzenia czasow e. D efinicje te są następujące:
(¡define
łdefine
typedef
typedef
SYSTICK_FREQUENCY 100
SYSTICK_PERIOD_MS (1000 / SYSTICK_FREQUENCY)
unsigned long long ltime_t;
void (*time_callback_t)(void);
W pliku u tiljtim e .c deklarujem y dw ie zm ienne globalne. Z m ienna lo c a lT im e od-:
m ierzą czas od uruchom ienia m ikrokontrolera. Z m ienna tim eC allB a ck zaw iera ad­
res funkcji zw rotnej. A dres o w artości zero oznacza, że żadnej funkcji zw rotnej nie
skonfigurow ano. Z m ienne te są zadeklarow ane ja k o s t a t i c , aby nie były w idocz­
ne na zew nątrz m odułu obsługującego SysTick. Z m ienna lo c a lT im e je s t ponadto
zadeklarow ana jak o ulotna (ang. volatile), gdyż je st m odyfikow ana w procedurze
obsługi przerw ania.
static volatile ltime_t localTime » 0;
static time__callback t timeCallBack = 0;
Procedura obsługująca przerw anie licznika system ow ego nazyw a się SysTick
H andler. W tej procedurze zw iększam y czas, który upłynął od uruchom ienia mi­
krokontrolera i jeśli skonfigurow ano funkcję zw rotną, w yw ołujem y ją.
3.4. Przykład 3a - pierwsza wersja sterownika Ethernetu
111
void SysTickJtandler(void) (
localTime += SYSTICK_PERIOD_MS;
if (timeCallBack)
timeCallBack();
I
L icznik system ow y m oże być taktow any z tą sam ą częstotliw ością co rdzeń lub
przez dzielnik z częstotliw ością 8 razy m niejszą. L icznik ten zlicza w dół do zera, po
czym je s t przeładow yw any w artością początkow ą. Po osiągnięciu zera m oże zgłosić
przerw anie. A by go skonfigurow ać, najw ygodniej je s t użyć funkcji SysTick_Conf ig
z biblioteki ST M 32. Jako argum ent należy podać okres, który je s t rów ny w artości
początkow ej licznika zw iększonej o jed en . F unkcja S ysT ick_C onfig aktyw uje prze­
rw anie licznika system ow ego i ustaw ia ja k iś priorytet, który trzeba zm ienić zgodnie
z naszym w ym aganiem . L icznikow i system ow em u przypisujem y w ysoki priorytet,
aby czas biegi rów nież podczas obsługi przerw ań o niższych priorytetach. Funkcja
RCC_GetClocksFreq z biblioteki S T M 32 oblicza częstotliw ości sygnałów , którym i
taktow any je s t m ikrokontroler (sygnał SY SC L K ), rdzeń (sygnał H C LK ) i peryferie
(sygnały PC LK 1, PC LK 2, A D C C L K ) i um ieszcza ich w artości w strukturze typu
RCC ClocksTypeDef. C zęstotliw ości te są w yrażone w hercach. K onfigurow anie
licznika system ow ego im plem entujem y w funkcji LocalTim eC onfigure.
int LocalTimeConfigure(void) I
RCC_ClocksTypeDef RCC_Clocks;
RCC_GetClocksFreq(&RCCClocks);
if (SysTick Config(RCC_Clocks.HCLK_Frequency / SYSTICK_FREQUENCY))
return -1;
SET_PRIORITY(SysTick_IRQn, HIGH_IRQ_PRIO);
return 0;
}
F unkcję zw rotną konfigurujem y za pom ocą funkcji TiraerC allBack. M ożna ją skon­
figurow ać w dow olnym m om encie, dlatego odbyw a się to przy w yłączonych prze­
rw aniach. Podanie zerow ego adresu pow oduje usunięcie funkcji zw rotnej.
void TimerCallBack(time_callback_t f) (
IRQ_DECL_PROTECT(x ) i
IRQ_PROTECT(x, HIGH_IRQ_PRIO);
timeCallBack = Ł;
IRQJJNPROTECT(X);
}
M oduł obsługujący licznik system ow y pow inien udostępniać w artość czasu, któ­
ry upłynął od uruchom ienia m ikrokontrolera. B ezpośrednie udostępnienie global­
nej zm iennej lo c a lT im e je s t bardzo złym pom ysłem . Lepiej je st zaim plem entow ać
w tym celu funkcję, którą nazw iem y LocalTime. Poniew aż zm ienna loca lT im e je st
64-bitow a, jej odczyt nie je s t atom ow y. A by zapew nić odczytanie spójnej w artości,
odczyt odbyw a się przy zablokow anym przerw aniu SysTick. W ym aga to zadekla­
row ania zm iennej tym czasow ej i zadeklarow ania w artości zw racanej przez funkcję
ja k o ulotnej, żeby kom pilator, optym alizując, nie usunął tej zm iennej tym czaso­
wej.
volatile ltime_t LocalTime(void) (
ltime_t t;
IRQ DECL PROTECT(x);
112
3.4. Przykład 3ct - pierwsza wersja sterownika Ethernetu
3. Stos TCP/ip
113
.»—
IRQ_PROTECT(x, HIGH_IRQ_PRIO) ;
t = looalTime;
IRQJJNPROTECT(x);
return t;
I
Funkcja LocalTime zw raca czas w m ilisekundach. D la w ygody dobrze je st też mieć
funkcję, która zw raca czas w bardziej przyjaznym form acie. W m odule obsługują­
cym licznik system ow y im plem entujem y funkcję GetLocalTime, która podaje czas
od uruchom ienia m ikrokontrolera w dniach, godzinach, m inutach, sekundach i mili­
sekundach. Jako argum enty należy podać w skaźniki do zm iennych, w których mają
być zapisane te w artości.
void GetLocalTime(unsigned *day, unsigned ‘hour,
unsigned ‘
minute, unsigned ‘
second,
unsigned ‘
milisecond);
3.4.2.
Pliki u tiljeth .h i utU eth.c - inicjowanie interfejsu sieciowego
Pliki opisane w tym i kolejnych dw óch podrozdziałach zaw ierają w łaściw ą im ple­
m entację sterow nika interfejsu ethernetow ego. W tym podrozdziale opisuję inicjo­
w anie interfejsu. W pliku util_eth.h zdefiniow any je s t adres układu PH Y oraz struk­
tura typu e t h n e t i f , która przechow uje ten adres i statystyki działania interfejsu
U kład PH Y w m odule Z L 3 E T II m a adres 1. Statystyki zaw ierają:
-
R X _packets - liczba prób w ysiania ram ki,
-
T X _packets - liczba w szystkich odebranych ram ek,
R X _errors - liczba nieudanych prób w ysiania ram ki,
T X _errors - liczba odebranych ram ek, które okazały się błędne.
idefine PHYJtDDRESS 1
struct ethnetif f
uint8__t phyAddress;
unsigned RX_packets;
unsigned TX_packets;
unsigned RX_errors;
unsigned TX_errors;
i;
W pliku util_eth.h zadeklarow ana je s t też funkcja ETHinit, która w ykonuje niskopoziom ow e inicjow anie interfejsu ethernetow ego. A dres tej funkcji jest przekazywany
jak o argum ent w spom nianej ju ż funkcji netif__add biblioteki IwIP. Funkcja ETHinit
m a jeden argum ent. Jest to w skaźnik do struktury typu n e t i f opisującej inicjowany
interfejs. Przekazyw ana struktura n e t i f m usi m ieć w składow ej hwaddr adres sprzę­
tow y interfejsu. Ponadto składow a s t a t e musi zaw ierać w skaźnik do struktury typu
e t h n e t i f zw iązanej z tym interfejsem . Ta struktura e t h n e t i f musi m ieć zainicjow a­
ną składow ą phyAddress. Składow a s t a t e struktury n e t i f je s t inicjow ana w funkcji
n e t i f _ a d d . G dy inicjow anie interfejsu się pow iodło, funkcja E THinit zw raca war­
tość ERR_OK. W przeciw nym przypadku funkcja ta zw raca kod błędu wg tabeli 3.4.
Im plem entacja funkcji ETH init znajduje się w pliku util_eth.c.
err__t ETHinit (struct netif ‘netif) {
struct ethnetif ‘
ethnetif = netif->state;
if (ETHconfigurePHY(ethnetif->phyAddress) < 0)
return ERR IF;
ETHconfigureMAC(netif);
ETHconfigureDMA{netif, LWIP_IRQ_PRIO, 0);
netif->name(0] = ,s';
netif->name(ł] « , t';
netif->output = etharp_output;
netif->linkoutput = low_level_output;
ethnetif->RX_packets = 0;
ethnetif->TX_packets = 0;
ethnetif~>RX_errors = 0;
ethnetif->TX_errors = 0;
ETH_Start();
netif->flags i= NETIF_FLAG_LINK_UP;
return ERR_OK;
1
W łaściw e inicjow anie zostało podzielone pom iędzy, opisane niżej, funkcje
ETHconfigurePHY, ETHconfigureMAC, ETHconfigureDMA. K ażda z tych funkcji,
zgodnie ze sw oją nazw ą, konfiguruje odpow iedni podukład interfejsu etherneto­
wego. Po skonfigurow aniu tych podukładów inicjow ane są składow e struktur typu
n e t i f i e t h n e t i f . Składow ej o u t p u t przypisujem y adres funkcji e t h a r p _ o u t p u t ,
która je s t dostarczana przez bibliotekę IwIP, zajm uje się pakow aniem datagram ów
IP w ram ki ethernetow e i obsługą ARP. Jeśli przed w ysłaniem pakietu sieciow ego
trzeba w ykonać jak ieś działania, np. spraw dzić stan łącza, to tej składow ej m ożna
przypisać adres w łasnej funkcji, która w ykonuje to zadanie, a następnie w yw ołuje
funkcję e t h a r p o u tp u t . Składow ej l i n k o u t p u t przypisujem y adres niskopoziom ow ej funkcji lo w _ le v e l _ o u tp u t , która zajm uje się w ysyłaniem gotow ych ram ek
elhernetow ych i je s t opisana w następnym podrozdziale. N a koniec w yw ołujem y
funkcję ETH_Start, która je s t dostarczana przez bibliotekę STM 32 i w łącza inter­
fejs ethernetow y.
Funkcja ETHconfigurePHY zajm uje się przede w szystkim konfigurow aniem układu
PHY, ale też, z uw agi na strukturę biblioteki ST M 32, konfiguruje niektóre ustaw ie­
nia układów M A C i DM A. A rgum entem tej funkcji je s t adres układu PHY. Funkcja
ta zw raca zero, gdy zakończyła się sukcesem , a w artość ujem ną w przeciw nym
przypadku. K onfigurow anie m oże zakończyć się niepow odzeniem , jeśli nie uda się
skontaktow ać z układem PHY.
static int ETHconfigurePHY(uint8_t phyAddress)
ETH_InitTypeDef e;
{
ETłi_Struct2nit (Se);
e.ETH AutoNegotiation = ETH_AutoNegotiation_Enable;
e.ETH_BroadcastFramesReception =
ETH BroadcastFramesReception_Enable;
e.ETH ReceiveOwn = ETH_ReceiveOwn_Disable;
U f CHECKSUM_GEN__IP == 0
e.ETH ChecksuroOffload = ETJ!_ChecksumOffload_Enable;
e.ETH DropTCPIPChecksumErrorFrame =
ETH_DropTCPIPChecksumErrorFrame_Disabłe;
iendif
e .ETH_SecondFrameOperate = ETH_SecondFrameOperate_Enable;
e .ETH_FixędBurst = ETH_FixedBurst_Enabłe;
e.ETH_RxDMABurstLength = ETll_RxDMABurstLength_32Beat;
e.ETH TxDMABurstLength = ETH_TxDMABurstLength__32Beat;
114
3.4. Przykład 3a - pierwsza wersja sterownika Ethernetu
3. Stos TCP/ip
if (!ETH_Init(&e, phyAddress))
return -1;
-
F unkcja ETHconfigureMAC konfiguruje adres sprzętow y M A C , M TU sieci i znacz­
niki. N ależy zadbać, aby w artość, opisanej w cześniej, stałej TCP_MSS, zdefiniow anej
w pliku Iw ipopts.h, była spójna z w artością M T U ustaw ianą przez tę funkcję. Stała
MAX_ETH_PAYLOAD je s t zdefiniow ana w pliku stm 32_eth.h i m a w artość 1500. Stała
ETHARP_HWADDR_LEN jest zdefiniow ana w pliku etharp.h i ma w artość 6.
phyreg = ETH_ReadPHYRegister(phyAddress, PHYCR);
phyreg &= - (LED__CNFG0 I LED_CUFG1);
ETH_WritePHYRegister(phyAddress, PHYCR, phyreg);
lendif
return 0;
I
A by ułatw ić konfigurow anie interfejsu ethernetow ego, w b ibliotece ST M 32 zdefi-J
niow ano strukturę ETH_InitTypeDef oraz funkcję E T H _ S tr u c tI n i t, która in ic ju je ^
tę strukturę w artościam i dom yślnym i. W iększości ustaw ień dom yślnych nie trzeba/jjj
zm ieniać. W arto natom iast ustaw ić au tom atyczne negocjow anie trybu pracy inter-■>
.
fejsu ethernetow ego. Jeśli auto m aty czn e negocjow anie nie działa, m ożna spróbo-f
w ać ustaw ień opisanych w ro zdziale 2.6.3. N a pew no też należy uaktyw nić o d b ić-1 |
ranie ram ek rozgloszeniow ych. G dy zam ierzam y używ ać sprzętow ego wsparcia M
dla sum kontrolnych (ang. checksum offload) protokołów intersieci, trzeba uaktyw- -;
nić tryb zapisz i w yślij (ang. store a n d fo rw a rd ) dla w ysyłania i odbierania. Wtedy .fi
cala ram ka je s t grom adzona w F IF O , zanim zostanie przesiana, aby m ożna b ylo'i|*
w staw ić lub zw eryfikow ać sum ę kontrolną. T ryb zapisz i w yślij jest ustaw iany!
dom yślnie przez funkcję E T H _ S tr u c tI n i t. D om yślhie też ustaw iany je s t karuzc- $
Iowy algorytm szeregow ania kolejek nadaw czej i odbiorczej ze w spółczynnikiem •
1 do 1. W funkcji ETHconfigurePHY o statnie cztery p rzy p isan ia d o pól struktu-.-w
ry e dotyczą DM A. Ich celem je s t zo p tym alizow anie działan ia transakcji DMA. W
A by skonfigurow ać interfejs, w yw ołana je s t funkcja ETH_Init z biblioteki S T M 32/'-|,
Pierw szym je j argum entem je s t w skaźnik do struktury e, a drugim arg u m en tem ; “
je st adres układu PHY.
-
zielona dioda sygnalizuje status łącza (ang. link status):
• św ieci się, gdy łącze pracuje popraw nie (ang. g o o d link),
• nie św ieci się, gdy w kablu nie m a w łaściw ego sygnału lub kabel je s t odł;
ny (ang. no link),
• m iga, gdy transm itow ane są ram ki (ang. activity):
pom arańczow a dioda sygnalizuje przepływ ność (ang. speed):
• św ieci się, gdy jest to 100 M b/s,
* nie św ieci się, gdy je s t to 10 M b/s.
#if ETH__BOARD == ZL3ETH
Idefine PHYCR
0x19
Sdefine LED_CNFG0 0x0020
idefine LED_CNFG1 0x0040
uintl6_t phyreg;
N a zakończenie funkcji ETHconfigurePHY konfigurujem y ustaw ienia zależne od
użytego układu PHY. K ażdy układ PH Y m a rejestry konfiguracyjne, pozwalaj;
dostosow ać je g o ustaw ienia do potrzeb konkretnej aplikacji. D ostęp do rejestrów
układu PH Y um ożliw iają funkcje ETH_ReadPHYRegister i ETH_WritePHYRegister
z biblioteki STM 32. W m odule ZL3ETI-I zastosow ano układ D P83848C oraz gniazdo RJ-45 z dw om a diodam i św iecącym i. Po szczegóły odsyłam do schem atu modułu ZL3E T H i noty katalogow ej układu D P83848C . Jako przykład ilustrujący użycie
rejestrów układu PIIY zm ieńm y konfigurację tych diody św iecących. W yzerowanie
bitu LED_CNFG0 i bitu LED_CNFG1 w rejestrze PHYCR (ang., P H Y contro! register)
pow oduje, że:
115
r',|
!■
j>:
f.
’d
'A.
static void ETHconfigureMAC{struct netif *netif) {
netif->hwaddr_len = ETHARP_HWADDR_LEN;
neti£->mtu = MAX_ETH_PAYLOAD;
neti£->flags = NETIF_FLAG_BROADCAST |
NETIF_FLAG_ETHARP;
ETH_MACAddressConfig(ETH_MAC_AddressO, netif->hwaddr ) ;
i
O statnim układem do skonfigurow ania je s t D M A . T rzeba określić, ja k ą liczbą bu­
forów nadaw czych i odbiorczych będzie dysponow ać D M A . Poniższe w artości są
w ybrane dość sw obodnie, przy założeniu, że przykładow e aplikacje nie generują
dużego ruchu sieciow ego.
łdefine ETH_RXBUFNB 4
{(define ETH_TXBUFNB 4
D M A będzie zgłaszało przerw anie po odebraniu ram ki. Procedura przerw ania musi
m ieć dostęp do struktury typu n e t i f , opisującej interfejs sieciow y. N ajprostszym
rozw iązaniem jest zadeklarow anie globalnego w skaźnika, który będzie przechow y­
wał adres tej struktury.
static struct netif *p_netif;
DM A konfigurujem y za pom ocą funkcji ETHconfigureDMA. Pierw szym jej argu­
m entem je st w skaźnik do struktury typu n e t i f . D rugim i trzecim argum entem są
odpow iednio priorytet w yw łaszczania i podpriorytet, z jakim i m a być obsługiw ane
przerw anie D M A.
static void ETHconfigureDMA(struct netif *netif,
uint8_t priorityi
uint8_t subpriority) (
static ETH_DMADESCTypeDef DMARxDscrTab[ETII_RXBUFNB] ALIGN4;
static ETH_DMADESCTypeDef DMATxDscrl'ab[ETH_TXBUFNB| ALIGN4;
static uint8_t RxBuff{ETH_RXBUFNBJ{ETH_MAXJ>ACKET_SIZE] ALIGN4;
static uint8_t TxBuff|ETH_TXBUFNB)[ETH_MAX_PACKET_SIZE1 ALIGN4;
ETH_DMARxDescChainInit(DMARxDscrTab, SRxBuff[0)[0], ETH_RXBUFNB);
ETH_DMATxDescChainInit(DMATxDscrTab, STxBuff(OJ[OJ, ETHJFXBUFNB ) i
NVIC__InitTypeDef NVIC_InitStruct;
int i;
p netif = netif;
MVIC_InitStruct.NVIC_IRQChannel = ETH_IRQn;
NVIC InitStruct.NVIC_IRQChannelPreemptionPriority = priority;
3.4. P n yld a d 3a - pierwsza wersja sterownika Ethernetu
NVIC_InitStruct.NVIC_IRQChannelSubPriority = subpriority;
NVIC_InitStruct.NVIC_IRQChanneiCmd * ENABLE;
NVIC_Init(SNVIC_InitStruct);
ETH_DMAITConfig(ETH_DMA_IT_NIS ! ETH_DMA_IT_R, ENABLE);
for (i = 0; i < ETH_RXBUFNB; ++i)
ETH__DMARxDescReceiveITConfig (&DMARxDscrTab{i ], ENABLE);
iif CHECKSUM_GEN__IP == 0
for (i = 0; i < ETH_TXBUFNB; ++i)
ETH_DMATxDescChecksumInsertionConfig(&DMATxDscrTab(i),
ETH_DMATxDesc_CIC_IPV4HeaderJ;
iendif
i
N a początku funkcji ETHconfigureDMA deklarujem y deskryptory oraz bufory o
biorcze i nadaw cze. Później za pom ocą funkcji ETH_DMARxDescChainInit z 1
blioteki S T M 32 konfigurujem y łańcuch deskryptorów odbiorczych, a za ponio
funkcji ETH_DMATxDescChainInit łańcuch deskryptorów nadaw czych. Pierwszy
argum entem tych funkcji je s t tablica deskryptorów , choć w trybie łańcuchowy
deskryptory nie m uszą zajm ow ać ciągłego obszaru pam ięci. U żyw ając tych fun
cji, nie m ożem y zm ienić rozm iaru buforów, gdyż obie funkcje ja k o drugi argumeijl
oczekują adresu ciągłego obszaru pam ięci o rozm iarze ETH_MAX_PACKET_SIZE ra/\
liczba buforów. Pow iększenie rozm iaru buforów je st konieczne, jeśli chcielibyśmy
używ ać ram ek V LA N , g dyż stała ETH_MAX_PACKET_SIZE, zdefiniow ana w pliku
stm 32_eth.h, m a w artość 1520, co nie uw zględnia dodatkow ych pól w ramkach''
V LA N . T rzecim argum entem tych funkcji je s t liczba deskryptorów w łańcuchu, bęV
dąca zarazem liczbą buforów. Jak w idać, funkcje z biblioteki S T M 32 nie pozwalają
na dow olne konfigurow anie łańcucha deskryptorów .
‘
Plik u tilje th .c - wysyłanie ramek ethernetowych
A by w ysłać ram kę, trzeba znać adres pierw szego w olnego deskryptora w kolejce
nadaw czej D M A i w staw ić tę ram kę do tej kolejki. W bibliotece STM 32 w pliku
stm 32_eth.c zdefiniow ano w tym celu zm ienną DMATxDescToSet, która w skazuje
bieżący, pierw szy w olny deskryptor nadaw czy. D ostęp do tej zm iennej zapew nia
poniższa deklaracja.
extern ETH_DMADESCTypeDef *DMATxDescToSet;
W staw ianiem ram ek ethernetow ych do kolejki nadaw czej zajm uje się funkcja łow_
l e v e l _ o u t p u t , którą m usim y zaim plem entow ać. Pierw szym argum entem tej funk­
cji je s t w skaźnik do struktury typu n e t i f opisującej interfejs sieciow y, przez który
ma być w ysiana ram ka. D rugim argum entem je s t w skaźnik do łańcucha buforów
zaw ierających ram kę do w ysiania. F unkcja ta zw raca w artość ERR_0K, gdy zakoń­
czyła się pow odzeniem , a w przeciw nym przypadku w łaściw y kod błędu.
static err_t low__level_output (struct netif *netif, struct pbuf *p) {
((struct ethnetif *)netif->state)->TX_packets++;
if (p == NULL) |
((struct ethnetif*) netif->state) ->TX_errors-H-;
return ERR_ARG;
1
if (p->tot__len > ETH__MAX_PACKET_SIZE - ETH_CRC) (
((struct ethnetif *)netif->state)->YX_errors++;
return ERRJ3UF;
}
if (DMATxDescToSet->Stiatus & ETH_DMATxDesc_OWN) (
((struct ethnetif *)netif->state)->TX_errors++;
return ERR_IF;
1
pbuf_copy_partial(p, (void *)DMATxDescToSet->BufferlAddr,
p->tot_len, 0);
DMATxDescToSet->ControlBufferSize p->tot_len £ EYH_DMATxDesc_TBS2;
DMATxDescToSet->Statuś 1= ETH_DMATxDesc_FS |
E'i’
H_DMATxDesc__LS 1
ETH_DMATxDesc_OWN;
if (ETH->DMASR h ETH_DMASR_TBOS) i
ETH->DMASR = ETH_DMASR_TBUS;
ETH->DMATPDR = 0;
N astępnie w funkcji ETHconfigureDMA konfigurujem y przerw anie D M A . Wszystkie]
źródła przerw ań zw iązane z interfejsem ethernetow ym zgłaszają przerw anie . 1
IRQn. Przerw anie ustaw iam y tak, aby było zgłaszane, gdy D M A odbierze ramkę
i skopiuje ją do sw ojego bufora odbiorczego. W procedurze obsługi tego przerwania
ram ka będzie kopiow ana z bufora D M A do bufora biblioteki lwIP, po czym będ zię;
w yw ołana funkcja biblioteki lw IP przetw arzająca tę ram kę. N ajpierw inicjujemy,1
globalny w skaźnik p _ n e t i f , aby procedura obsługi m iała dostęp do struktury typy
n e t i f . N astępnie korzystam y z funkcji biblioteki STM 32:
-
-
konfigurujem y priorytet przerw ania i uaktyw niam y go za pom ocą funkcji NY ;
In it;
ustaw iam y źródło przerw ania za pom ocą funkcji ETH_DMAITConfig, ustawieni^
bitu ETH_DMA_IT_R aktyw uje p rzerw anie odbiorcze (ang. receive interrupt), usta*
w ienie bilu ETH_DMA_IT_NIS aktyw uje podstaw ow e przerw ania D M A (ang. nor­
m al interrupt sum m ary);
aktyw ujem y zgłaszanie przerw ania (zerujem y bit D IC w deskryptorach odbior
czych) za pom ocą funkcji ETH_DMARxDescReceiveITConfig.
N a koniec funkcji ETHconfigureDMA, jeśli została skonfigurow ana opcja sprzęt ,
w ego w staw iania sum kontrolnych w nagłów kach datagram ów IP, trzeba ustawić tę(
opcję w e w szystkich deskryptorach nadaw czych za pom ocą funkcji ETH_DMATxDt
C h e c k su m ln se rtio n C o n fig .
117
)
DMATxDescToSet =
(ETH_DMADESCTypeDef *)DMATxDescToSet->Buffer2NextDescAddr;
return ERR OK;
1
F unkcja lo w _ le v e l _ o u tp u t najpierw spraw dza popraw ność argum entów i uaktu­
alnia statystykę w ysłanych ram ek. W ysyłana przez bibliotekę lw IP ram ka ethernetow a nie zaw iera sekw encji kontrolnej, która je s t w yliczana przez układ M AC.
D latego przekazana do w ysiania ram ka nie m oże być dłuższa niż m aksym alny
rozm iar ram ki ethernetow ej (siała ETH_MAX_PACKET_SIZE) pom niejszony o długość
sekw encji kontrolnej (stała ETH_CRC). Funkcja spraw dza też, czy bieżący deskryp­
tor nadaw czy nie je s t zajęty przez D M A , czyli czy je s t w yzerow any bit OWN. Jeśli
spraw dzenia w ypadną pozytyw nie, funkcja kopiuje ram kę do bufora w skazyw ane­
go p rzez bieżący deskryptor i ustaw ia w tym deskryptorze długość tej ram ki (pole
TBS1). N astępnie inform uje D M A , że bufor zaw iera całą ram kę (ustaw ia bity ES
3.4. Przykład 3a - pierwsza wersja sterownika Ethernetu
i LS) oraz zw raca deskryptor układow i D M A (ustaw ia bit OWN). N a koniec trze
ba jeszcze spraw dzić, czy przeglądanie kolejki nadaw czej nie zostało w strzym ani
Sygnalizow ane je s t to przez ustaw ienie bitu TBUS w rejestrze DMASR (ang. D M A staI
lus register). P rzeglądanie zatrzym uje się, gdy w łaścicielem kolejnego deskryptor’'
w kolejce nie je s t D M A , czyli gdy nie m a nic do w ysiania. P rzeglądanie kolcjk'1'
nadaw czej w znaw ia się przez w yzerow anie bitu TBUS (w pisując do niego jedynkę)'
i zapisanie jakiejk o lw iek w artości do rejestru DMATPDR (ang. D M A transm it p o ll de'ir
ntancl register). O statnią czynnością je s t przesunięcie w skaźnika bieżącego deskryp'i
tora na następny deskryptor w łańcuchu.
119
((struct ethnetif *)netif->state)->RX_errors++;
pbuf_free(p);
1
return err;
Plik utiljeth .c - odbieranie ramek ethernetowych
)
B iblioteka lw IP w ym aga, aby odebrana ram ka została um ieszczona w buforze opi­
syw anym strukturą typu pbuf. Z ajm uje się tym funkcja lo w _ łe v e l_ in p u t, która
alokuje bufor i kopiuje do niego ram kę. Z w rócony przez tę funkcję w skaźnik do
bufora je st przekazyw any do funkcji w skazyw anej za pom ocą składow ej in p u t
struktury n e t i f . B iblioteka lw IP nie zw alnia przekazanego jej bufora, jeśli prze­
tw arzanie ram ki zakończy się błędem . D latego w przypadku błędu trzeba w funkcji
e t h e r n e t i f _ i n p u t zw olnić przekazany bibliotece bufor.
A dres pierw szego deskryptora w kolejce odbiorczej, gdzie zostanie um ieszczona kor
lejna odebrana ram ka elhernetow a, przechow yw any je st w zm iennej DMARxDescToGelj*
zdefiniow anej w bibliotece ST M 32 w pliku stm 32_eth.c.
static struct pbuf * low_level_input(struct netif ‘netif) (
struct pbuf *p = NULL;
uint32__t len;
extern ETH_DMADESCTypeDef ‘DMARxDescToGet;
if
O debrane ram ki są przetw arzane w procedurze ETH_IRQHandler obsługującej przeć
rw anie, które je st zgłaszane przez D M A po um ieszczeniu ram ki w kolejce odbiorczej;'
Poniew aż jed n o przerw anie m oże zostać zgłoszone dla w ielu ram ek, spraw dzam ^
w pętli, czy bieżący deskryptor, w skazyw any przez zm ienną DMARxDescToGet, miii)
w yzerow any bit OWN. W yzerow anie tego bitu oznacza, że deskryptor został zwolnioi)
ny przez DM A i w skazuje na o debrane dane. R am ka je st przetw arzana przez funk^
cję e th e r n e tif_ _ in p u t, po której zakończeniu w skaźnik DMARxDescToGet wskazujó$
na następny deskryptor w kolejce. A by nie zgubić,żadnego przerw ania, bity o c /e -■
kującego (ang. pend in g bit) p rzerw ania ETH_DMA_IT‘_NIS i ETH_DMA_IT_R m uszą hyć,'n
w yzerow ane przed spraw dzeniem bitu OWN w kolejnym deskryptorze.
void ETH_IRQHandler(void) (
ETH_DMAClearITPendingBit(ETH_DMA_IT_NIS I ETH_DMA_IT_R);
while {!(DMARxDescToGet->Status 6 ETH_DMARxDesc_OWN))
ethernetif__input (p_netif};
)
err = netif->input(p, netif);
if (err != ERR OK) (
DMARxDescToGet~>Status = ETH__DMARxDesc_OWN;
DMARxDescToGet (ETH_DMADESCTypeDef *)DMARxDescToGet“>Buffer2NextDescAddr;
if (ETH->DMASR & ETH_DMASR_RBUS) {
ETH->DMASR = ETH__DMASR__RBUS;
ETH->DMARPDR = 0;
}
A rgum entem funkcji e t h e r n e t i f _ i n p u t je st w skaźnik do struktury n e t i f opisują­
cej interfejs sieciow y. Z godnie z konw encją obow iązującą w bibliotece lw IP funk­
cja ta zw raca w artość E R R „O K , gdy zakończyła się sukcesem , lub w łaściw y kod1
błędu w przeciw nym przypadku. Jednak w szelkie błędy zw racane przez tę funkcję
są ignorow ane, gdyż nie m a realnej m ożliw ości ich obsłużenia w procedurze ob- j
sługi przerw ania. Z am iast tego funkcja ta uaktualnia w strukturze typu e th n e tif-.'
statystykę odebranych ram ek.
((struct ethnetif *)netif->state)->RX_packets++;
p = Iow level_input(netif);
if (p == NULL) {
((struct ethnetif *)netif->state)->RX_errors++;
return ERR_MEM;
)
}
return p;
)
static err_t ethernetif__input{struct netif *netif) {
struct pbuf *p;
err_t err;
((DMARxDescToGet->Status fiETH_DMARxDesc_£S) =*= 0 &&
{DMARxDescToGet~>Status fi £TH_DMARxDesc_LS) != 0 &&
(DMARxDescToGet->Status & ETH_DMARxDesc_FS)
1= 0) {
len = ETH_GetDMARxDescFrameLength(DMARxDescToGet);
if (len >= ETHJiEADER + MIN__ETH_PAYLOAD + ETH_CRC) {
len
ETH_CRC;
p « pbuf_alloc(PBUF^RAW, len, PBUF_P00L);
pbuf take(p, (void *)DMARxDescToGet->BufferlAddr, len);
1
)
A rgum entem funkcji io w _ le v e l_ in p u t jest w skaźnik do struktury n e t i f opisują­
cej interfejs sieciow y. Funkcja ta najpierw spraw dza, czy bieżący deskryptor za­
w iera popraw nie odebraną ram kę i czy ram ka ta nie je s t za krótka. Funkcja ETH_
GetDMARxDescFraraeLength z biblioteki S T M 32 zw raca długość odebranej ram ki,
łącznie z sekw encją kontrolną. Jeśli spraw dzenie w ypadnie pozytyw nie, alokow any
je s t now y bufor i kopiow ana jest do niego ram ka bez sekw encji kontrolnej. Jeśli
alokacja bufora nie pow iedzie się i do funkcji p b u f ta k e zostanie przekazany zero­
wy w skaźnik p, to funkcja ta nie w ykona żadnego kopiow ania. Funkcji pbuf ta k e
je s t odporna na zerow ą w artość pierw szego argum entu. N astępnie funkcja low l e v e l_ in p u t zw raca deskryptor układow i D M A (ustaw ia bit OWN) i przesuw a w skaź­
nik bieżącego deskryptora na następny deskryptor w łańcuchu. N a koniec trzeba
jeszcze spraw dzić, czy przeglądanie kolejki odbiorczej nie zostało w strzym ane.
S ygnalizow ane je s t to przez ustaw ienie bitu RBUS w rejestrze DMASR. Przeglądanie
zatrzym uje się, gdy w łaścicielem kolejnego deskryptora w kolejce nie je st D M A
(w yzerow any je s t bit OWN). M oże się to zdarzyć, gdy kolejka odbiorcza zapełni się,
bo aplikacja nie nadąża przetw arzać odebranych ram ek. Przeglądanie kolejki od-
3.4. Przykład 3a - pierwsza wersja sterownika Ethernetu
biorczej w znaw ia się przez w yzerow anie bitu RBUS (w pisując do niego jedynkę
i zapisanie jakiejkolw iek w artości do rejestru DMARPDR (ang. DMA receive poll (/e
m and register).
3.4.5.
Pliki u tiljw ip .h i u łiljw ip .c - inicjowanie interfejsu sieciowego
Plik u tiljw ip .h zaw iera deklarację funkcji LWIPinterfacelnit inicjującej bibli
tekę IwIP, a następnie konfigurującej interfejs sieciow y do w spółpracy z tą bibli
teką.
int LWIPinterfacelnit(struct netif *netif,
struct ethnetif *ethnetif);
Im plem entacja tej funkcji znajduje się w pliku u tiljw ip .c . Jej argum entam i są, opi­
sane w poprzednich podrozdziałach, w skaźniki do struktur, które przechow ują daru?
konfigurow anego interfejsu. Jeśli składow a ip_addr w strukturze netif m a wartość
różną od zera, interfejs sieciow y zostanie skonfigurow any statycznie z adresem 1
m aską podsieci i adresem rutera przekazanym i w tej strukturze. Jeśli składow a t
m a w artość zero, to w celu pozyskania ustaw ień sieciow ych dla tego interfejs zost'-'
nie podjęta próba uruchom ienia klienta DHCP. W przekazanej strukturze typu n.
tif m usi być w ypełniony adres sprzętow y. W przekazanej strukturze typu ethn
tif m usi być w ypełniony adres układu PHY. Funkcja zw raca zero, gdy zakończył
się sukcesem , a w artość ujem ną, gdy w ystąpił błąd. F unkcja je s t przeznaczona do;
w yw ołania z program u głów nego, dlatego w szystkie w ystępujące w niej wywołania'
funkcji biblioteki IwIP są otoczone m akram i chroniącym i przed konkurencyjnj
w ykonyw aniem . Funkcja ta korzysta z niżej przedstaw ionych funkcji biblioteki',
IwIP.
void
Iwip_init(void);
F unkcja lwip_init je st zadeklarow ana w pliku init.h i zaim plem entow ana w pliku
init.c. Inicjuje w szystkie skom pilow ane m oduły biblioteki IwIP.
struct netif *
netif add(struct netif *netif,
struct ip_addr *ipaddr,
struct ip_addr *netmask,
struct ip addr *gw,
void *state,
err_t (* init)(struct netif *netif),
err_t (* input)(struct pbuf *p, struct netif *netif));
Funkcja netif_add je s t zadeklarow ana w pliku netif.h i zaim plem entow ana w pliku
netif.c. D odaje interfejs sieciow y do listy interfejsów obsługiw anych przez bibliote­
kę IwIP. Param etr netif je st w skaźnikiem do struktury opisującej dodaw any inter-i.
fejs. Param etry ipaddr, netmask i gw są odpow iednio w skaźnikam i do struktur za­
w ierających adres IP, m askę podsieci i adres rutera. Jeśli zam ierzam y użyć DHCT,
należy podać zerow e w artości adresów i m aski. Param etr State je s t wskaźnikiem,
do struktury zaw ierającej pryw atne dane sterow nika interfejsu sieciow ego. W na-,
szym przypadku przekazujem y w skaźnik do struktury typu ethnetif. Parametr.
121
init musi zaw ierać adres funkcji inicjującej sterow nik. Przekazujem y adres funkcji
ETHinit, która została opisana w poprzednim podrozdziale. Param etr input musi
zaw ierać adres funkcji przetw arzającej odebrane ram ki sieciow e. Przekazujem y ad­
res funkcji ethernet__input z biblioteki IwIP. G dy funkcja zakończyła się sukce­
sem , zw raca w skaźnik do skonfigurow anej struktury typu netif, a gdy wystąpił
błąd, zw raca w artość NULL.
void
netif_set_defauit(struct netif *netif);
F unkcja n e t i f _ s e t _ d e f a u l t je s t zadeklarow ana w pliku netif.h i zaim plem entow a­
na w pliku n e tif c. U staw ia interfejs sieciow y w skazyw any przez param etr n e t i f
ja k o dom yślny. W szystkie datagram y IP bez jaw nie określonej trasy są w ysyłane
przez interfejs domyślny.
err_t
dhcp_start(struct netif *netif);
F unkcja d h c p _ s t a r t je s t zadeklarow ana w pliku dhcp.h i zaim plem entow ana
w pliku dhcp.c. U rucham ia klienta D H C P w celu zdobycia ustaw ień sieciow ych
dla interfejsu w skazyw anego za pom ocą argum entu netif. Jeśli klient D H C P był
ju ż uruchom iony dla tego interfejsu, restartuje tego klienta. Z w rócenie w artości
ERR OK oznacza tylko p o m yślne uruchom ienie klienta, a nie zakończenie konfigu­
row ania ustaw ień siećiow ych. K lient działa niejako w tle. G dy klient zdobędzie
u staw ienia sieciow e, odblokow uje interfejs sieciow y, ustaw iając znacznik NETIF_
FLAG UP.
void
netif_set_up(struct netif *netif);
F unkcja n e tif_ _ set_ u p je st zadeklarow ana w pliku netif.h i zaim plem entow ana w pli­
ku netif.c. Jeśli konfigurujem y statyczne ustaw ienia sieciow e, pow inniśm y w ywołać
tę funkcję w celu odblokow ania interfejsu sieciow ego przez ustaw ienie znacznika
NETIF_FLAG__UP. Jeśli używ am y DHCP, w yw ołanie tej funkcji jest zbędne.
O prócz pow yższych funkcji, użyteczne m ogą być rów nież inne funkcje dostarczane
w plikach netif.h i netif.c. Z a pom ocą następujących funkcji m ożna zablokow ać
interfejs sieciow y, spraw dzić jeg o stan i skonfigurow ać statyczny adres IP, maskę
podsieci oraz adres rutera.
void
u8_t
void
void
void
netif_set_down(struct netif ‘netif);
netif_is_up(struct netif ‘netif);
netif_set__ipaddr (struct netif ‘netif, struct ip__addr ‘ipaddr);
netif_set__netmask (struct netif ‘netif, struct ip_addr ‘
netmask);
netif_set_gw(struct netif ‘
netif, struct ip_addr *gw);
K onfigurow anie ustaw ień sieciow ych za pom ocą D H C P trwa pew ien czas. Przed
je g o zakończeniem nie m a sensu podejm ow ow anie jakiejkolw iek kom unikacji sie­
ciow ej. W funkcji DHCPwait im plem entujem y aktyw ne (w pętli) oczekiw anie na
zakończenie procesu konfigurow ania.
int DHCPwait(struct netif ‘netif, unsigned timeout, unsigned tries);
122
3. Stos TCP/ip
Funkcja DHCPwait zw raca zero, gdy konfigurow anie za pom ocą D H C P zakończy-;
lo się sukcesem lub gdy nie je s t używ any klient DHCP. Funkcja zw raca w artość1
ujem ną, gdy konfigurow anie nie zakończyło się w ciągu tim e o u t sekund lub klient1’
w ykonał bez pow odzenia co najm niej t r i e s prób. Jeśli aktyw ne oczekiw anie na i
zakończenie procesu konfigurow ania je s t nieakceptow alne, to m ożna użyć funkcji:
zw rotnej inform ującej o zm ianie stanu interfejsu. W tym celu należy w pliku Zwi-:
popis, h zdefiniow ać następującą opcję:
łdefine LWIP_NETIF_STATUS_CALLBACK
void
netif_set_status_callback(struct netif *netif,
void (* status_callback)(struct netif *netif));
Przydatne m ogą okazać się rów n ież następujące funkcje dostarczane w plikach
dhcp.h i dhcp.c.
void
dhcp_stop(struct netif ‘netif);
Funkcja d h cp _ sto p zatrzym uje działanie klienta DHCP.
err_t
dhcp_release(struct netif ‘netif);
Funkcja d h c p _ re le a s e zw alnia w ynajęte od serw era DFICP ustaw ienia sieciowe.
Serw er D H C P w ynajm uje ustaw ienia sieciow e na określony czas - patrz rozdział
3.9. Funkcja ta jest zw ykle w yw ołana przed funkcją d h cp _ sto p .
err t
dhcp_renew(struct netif *netif);
Funkcja dhcp renew odnaw ia w ynajem ustaw ień sieciow ych. N orm alnie nie ma
potrzeby w yw ołania lej funkcji, gdyż klient D H C P autom atycznie próbuje odnowić
w ynajem przed je g o zakończeniem .
3.4.6.
Tab. 3.11. Budziki biblioteki lwiP
Funkcja
Pliki u tiljw ip .h i u tiljw ip .c - budziki
B iblioteka lw IP musi być pobudzana do działania w regularnych odstępach czasu.
W szystkie jej budziki opisane są w ta b e li 3.11. Pierw sza kolum na zaw iera nazwę
funkcji, która m a być w yw ołana. D ruga kolum na zaw iera nazw ę stałej definiującei
odstęp czasu, w którym m a być w yw ołana ta funkcja. T rzecia kolum na zawiera
dom yślną w artość tego czasu.
O prócz budzików biblioteki lw iP będziem y jeszcze potrzebow ać budzika dla pro­
tokołu w arstw y aplikacji. C ałość im plem entacji budzików znajduje się w plikach
u tiljw ip .h i u tiljw ip .c . W dalszym ciągu zam ieszczam tylko tekst źródłow y dla
Stała dolinlująca Interw al czasowy w y­
wołania
Dom yślna wartość
Interwalu
ip reass_tmr
IP_TMR_INTERVAL
1000 ms
etharp_tmr
ARP_TMR_INTERVAL
5 0 0 0 ms
tcp_tmr
TCP TM R INTERVAL
2 5 0 ms
dhcp_fine_tmr
DHCP FINE TIMER MSECS
50 0 ms
DHCP_COARSE_TIMER_MSECS
60 0 0 0 ms
1
Funkcja zw rotna s t a t u s _ c a l l b a c k pow inna być typu v o id i przyjm ow ać jed en ar­
gum ent, który musi być w skaźnikiem do struktury typu n e t i f opisującej interfejs
sieciow y. Funkcję zw rotną ustaw ia się za pom ocą funkcji n e t i f s e t s t a t u s c a l ­
lb ack .
123
3.4. Przykład 3a - pierwsza wersja sterownika Ethernetu
dhcp coarse tmr
DHCP_COARSE_TIMER_SECS
60s
dns tmr
DNS_TM RJNTERVAL
1000 ms
autoip_tmr
AUTOIP_TMR_INTERVAL
100 ms
igmp tmr
IGMP TM R INTERVAL
10 0 ms
budzików D H C P i budzika aplikacji. Im plem entacja pozostałych budzików je st ana­
logiczna. N ajpierw deklarujem y zm ienne odm ierzające czas.
static ltime_t DHCPfineTimer;
static ltime_t DHCPcoarseTimer;
static ltime_t appTimer;
N astępnie deklarujem y typ app_callback_t dla funkcji zw rotnej budzika aplikacji. Typ ten oznacza w skaźnik do bezparam etrow ej funkcji typu void. Zm ienna
app trar przechow uje w skaźnik tego typu, czyli adres budzika aplikacji. Z m ienna
app tmr_interval przechow uje interw al czasow y budzika aplikacji.
typedef void (*app_callback_t)(void);
static app_callback_t app_tmr = 0;
static unsigned app_tmr_interval = 0;
C zas je s t odm ierzany w m ilisekundach za pom ocą licznika system ow ego SysTick.
Funkcja LWIPtimersStart inicjuje budziki biblioteki lw iP i ustaw ia funkcję zw rot­
ną LWIPtmr, która będzie w yw ołana cyklicznie w przerw aniu SysTick. Funkcja
LWIPtimersStart je s t przew idziana do w yw ołania z program u głów nego i m anipu­
luje zm iennym i używ anym i w procedurze obsługi przerw ania, dlatego w ykonuje się
przy zablokow anych przerw aniach. P oczątkow e w artości budzików lw iP ustalam y
tak, aby uniknąć czasow ej korelacji ich w yw ołania.
void LWIPtimersStart(void) {
IRQ__DECL__PROTECT (X } ;
ltime_t localTime = LocałTimeO;
IRQ_PROTECT(x, LWIP_IRQ_PRIO);
DHCPfineTimer = localTime + 31/
DHCPcoarseTimer = localTime;
SET_PRIORITY (PendSV__IRQn, LWIP_IRQ_PRIO, 0);
TimerCallBack(LWIPtmr);
IRQ_UN PROTECT(x );
1
P rzerw anie SysT ick ma w yższy priorytet (HIGH_IRQ_PRIO) niż priorytet przerw ań
biblioteki lw iP (LWIP_IRQ_PRIO), gdyż czas m usi biegnąć podczas przetw arzania
pakietów przez bibliotekę. D latego funkcja zw rotna LWIPtmr nie w yw ołuje bez­
pośrednio budzików , a tylko zgłasza przerw anie PendSV, które je s t obsługiw ane
3.4. Przykład 3a - pierwsza wersja sterownika Ethernetu
z tym sam ym priorytetem co przerw ania biblioteki IwIP. Przerw anie PendSV nię
je s t zw iązane z żadnym sprzętem . Jest to przerw anie program ow e, przeznaczone clij'1
w yw oływ ania niskopoziom ow ych usług system u operacyjnego, np. do przełączania'
kontekstu w s'rodowisku w ielozadaniow ym , a zatem doskonale nadaje się do wyi|
w ołania budzików . Jedynym sposobem w yzw olenia tego przerw ania je st ustawieni^
bitu PENDSVSET w rejestrze ICSR (ang. interrupt control a n d state register), któr'$
znajduje się w bloku rejestrów sterujących SCB (ang. system control block) rdzenia1'
C ortex-M 3.
graniu od stanu pew nych w yprow adzeń m ikrokontrolera. W zestaw ie ZL29A R M
m ożna do tego w ykorzystać zw orkę B O O T1, podłączoną do w yprow adzenia PB2.
Z w orka ta w ym usza na tym w yprow adzeniu stan niski lub w ysoki. Stan zw orki od­
czytujem y na początku program u za pom ocą funkcji GetConfBit, która znajduje się
w pliku board_conf.c. D eklaracja tej funkcji znajduje się w pliku boarcl_conf.lt.
idetine GPIO_CONF
łdetine CONF_PIN
idefine RCC_PERIPH_CONF
GPIOB
GPI0_Pin_2
RCC_APB2Periph_GPI0B
static void LWIPtmr(void) {
SCB->ICSR |* SCB_ICSR_PENDSVSET;
uint8_t G e t C o n f B i t (void)
uinŁ8__t bit;
(
)
RCC_APB2Per i p h C l o c k C m d ( R C C _ P E R I P H _ C O N F , E N A B L E ) ;
bit = GPIO__ReadInputDataBit (GPIO_CONF, CONFJ?IN);
D opiero procedura obsługi przerw ania PendSV PendSV_Handler w yw ołuje właścbj
we budziki biblioteki IwIP. 64-bitow a zm ienna typu
zliczająca milisekundy,
przepełni się po ok. 584 m ilionach lat. Z atem w praktyce m ożem y założyć, że nigdy’1;,
się nie przepełnia, co upraszcza im plem entację.
void PendSV_Handler(void) {
ltime_t localTime = LocalTime();
RCC__APB2PeriphClockCmd (RCC_PERIPH_CONF, DISABLE) ;
return bit;
i
3.4.8.
void LCDwritelP(const struct ip_addr *ip);
void LCDwriteXPport(const struct ip_addr *ip, uintl6_t port);
void LCDwriteRXTX(unsigned rx_pkts, unsigned rx_errs,
unsigned tx_pkts, unsigned tx_errs);
void LCDwriteTime(time_t rtime);
i
if (localTime >= DHCPcoarseTimer) (
DHCPcoarseTimer += DHCP_COARSEJHMER_MSECS;
dhcp_coarse__tmr ();
Pow yższe funkcje korzystają z funkcji LCDwrite. Funkcja LCDwritelP w ypisuje
adres 1P w postaci czytelnej dla człow ieka, czyli jak o cztery liczby dziesiętne od­
dzielone kropkam i. Jej argum entem jest adres struktury reprezentującej adres IP
w ew nątrz biblioteki IwIP. Funkcja LCDwriteIPport w ypisuje adres IP i num er por­
tu oddzielone dw ukropkiem . Funkcja LCDwriteRXTX w ypisuje liczby odebranych
i w ysianych pakietów oraz błędów transm isji. Statystyk tych będzie nam dostarczał
sterow nik m odułu ethernetow ego. W reszcie funkcja LCDwriteTime w ypisuje datę
i czas w form acie czytelnym dla człow ieka. Jako argum ent pobiera liczbę sekund,
które upłynęły od początku epoki uniksa, czyli od godziny 0:00:00 dnia 1 stycznia
1970 roku.
I
if (app_tmr__interval > 0 && localTime >= appTimer) {
appTimer += app_tmr interval;
if (app_tmr)
app tmr();
Funkcja LWIPsetAppTimer konfiguruje budzik aplikacji. F unkcja ta manipuluje ;
zm iennym i używ anym i w procedurze obsługi przerw ania, dlatego w ykonuje się-;
przy zablokow anych przerw aniach. Pierw szym jej argum entem je s t adres funkcji:
zw rotnej. D rugim argum entem je s t interw al czasow y w yw ołania budzika aplikacji'!
w m ilisekundach.
void LWIPsetAppTimer(app_callback t tmr, unsigned tmr interval) {
IRQ_DECL_PROTECT(x);
IRQ_PROTECT(x, LWIP_IRQm PRIO);
app_tmr = tmr;
app_tmr_interval = tmr_interval;
appTimer = LocalTime();
IRQ_UNPROTECT(x);
Pliki u tiljc d je x .h i u tiIJ c d je x .c
Pliki u tiljc d _ e x .il i u tiljc d _ e x .c udostępniają bardzo przydatne funkcje przezna­
czone do w ypisyw ania specyficznych danych:
if (localTime >= DHCPfineTimer) {
DHCPfineTimer += DHCP_ITINE_TIMER_MSECS;
dhcp_fine tmr();
3.4.7.
125
3.4.9.
Plik e x jp .c
Plik e x j p . c zaw iera funkcję main przykładu. N a początku tej funkcji czytam y stan
zw orki B O O T 1, od której ustaw ienia będzie zależeć konfiguracja adresów.
int main () {
uint8_t confBit;
confBit = GetConfBit{) ;
}
i
Pliki board_conf.h i board_conf.c
Potem konfigurujem y poszczególne podukłady m ikrokontrolera, analogicznie jak
bylo to w przykładzie 2. Podczas konfigurow ania św ieci czerw ona dioda.
U staw ienia sieciow e w przykładow ych program ach m ogą być konfigurow ane sta-.;,
tycznie lub dynam icznie za pom ocą DHCP. Sposób konfiguracji je s t w ybierany pr/>
starcie program u. Z astosow ałem typow e rozw iązanie, które uzależnia działanie pro-;;;|
int m a i n () (
AllPinsDisable();
127
3.5. Przykład 3b - sterownik Ethernetu bez kopiowania
LEDconfigure{);
RedLEDonO;
LCDconfigure {);
SET_IRQ_PROTECTION();
LCDwrite("Clock ");
error_check{CLKconfigure(}, 1);
LCDwrite("PASS\n");
LCDwrite("Local Time ");
error_check(LocalTimeConfigure(), 2);
LCDwrite("PASS\n"};
LCDwrite("Ethernet ");
error_check(ETHconfigureMII(), 4);
LCDwrite("PASS\n");
K ażde urządzenie w sieci E thernet pow inno m ieć inny adres M A C . W ykorzystujeiij
dostępne stale, aby utw orzyć niepow tarzalny adres. Przydzielam y adres M A C adni
nistrow any lokalnie. Jeśli zw orka BOOT1 jest w pozycji 0, konfigurujem y ustawie’
nia sieciow e statycznie. Jeśli zw orka ta je st w pozycji 1, używ am y DHCP. Poniżśajf
fragm ent program u konfiguruje interfejs sieciow y i bibliotekę lwIP.
int m a i n O (
static struct netif netif;
static struct ethnetif ethnetif = {PHY_ADDRESS};
LCDwrite("lwIP stack ");
netif,hwaddr[0]
2;
netif.hwaddr(l)
(BOARD_TYPE » 8) & Oxff;
netif.hwaddr[2]
BOARDJTYPE 6 Oxff;
netif,hwaddr[3]
(ETHJ30ARD » 8) & Oxff;
netif.hwaddr(4}
ETH_BOARD & Oxff;
netif.hwaddr[5]
1 + confBit;
if (iconfBit) {
IP4_ADDR(&neti£.ip_addr, 192, 168, 51, 84);
IP4_ADDR(&netif.netmask, 255, 255, 255, 240);
IP4_ADDR(finetif.gw,
192, 168, 51, 81);
else {
IP4_ADDR(Snetif.ip__addr,
IP4_ADDR ({¿netif.netmask,
IP4_ADDR(&neti£.gw,
0, 0, 0, 0)
0, 0, 0, 0)
0, 0, 0, 0)
error_check (LWIPinterfacelnit (Snetif, {¿ethnetif), 5);
LWIPtimersStart();
LCDwrite("PASS\n");
O statnią czynnością zw iązaną z konfigurow aniem je s t poczekanie na zakoric/cnie zdobyw ania ustaw ień sieciow ych przez klienta DHCP. C zekam y maksymalnie
10 sekund lub 4 próby. W artości te w ybrano dość sw obodnie i m ogą w ym agać mo-'
dylikacji. Funkcja DHCPwait kończy działanie natychm iast, sygnalizując poprawne
zakończenie, jeśli nie je s t w ykorzystyw any klient DHCP. Skonfigurow any adres II’
w yśw ietlam y na ekranie LCD. Z gaśnięcie czerw onej diody oznacza zakończenie
konfigurow ania.
C l o c k PASS
L o c a l T i m e PASS
E t h e r n e t PASS
l w I P s t a c k P A S S ..
Liczba odebranych
ramek ’
1 P 1 1 92,166,51.89
Liczba prób
wysłania ramki
Inform acje o uruchom ieniu
" poszczególnych podukładów
Skonfigurowany
adres IP
Liczba błędnie
odebranych ramek
Liczba błędów podczas
w ysyłania ramek
Rys. 3.3. Wygląd LCD podczas działania programu
int raaind
(
LCDwrite("IP
error_check{DHCPwait(Snetif, 10, 4), 6);
LCDwritelP(snetif.ip_addr);
RedLEDoff 0 ;
I
W głów nej pętli program u w yśw ietlam y statystyki odebranych i w ysłanych ram ek
ethernetow ych. W ygląd w yśw ietlacza ciekłokrystalicznego przedstaw iono na r y ­
s u n k u 3.3.
int main{)
1
for (;;} {
LCDgoto(6, 0);
LCDwriŁeRXTX(ethnetif,RX_packets, ethnetif.RX_errors,
ethnetif,TX_packets, ethnetif.TX_errors);
Delay(1000);
ł
)
Przykład 3b - sterownik Ethernetu bez kopiowania
W tym przykładzie prezentuję ulepszony sterow nik interfejsu ethernetow ego. Jest to
podstaw ow y sterow nik dla w szystkich przykładów w kolejnych rozdziałach. Jest on
kom patybilny z poprzednim i w e w szystkich przykładach oba m ogą być stosow ane
zam iennie. U lepszenie polega na rezygnacji z buforów odbiorczych D M A i kopio­
w aniu odebranych ram ek bezpośrednio do buforów biblioteki lwIP. Ponadto w tym
sterow niku w kolejkach odbiorczej i nadaw czej używ am y pierścieni deskryptorów .
N azw y plików , które zaw ierają im plem entację tego przykładu, zam ieszczone są
w ta b e li 3.12. W stosunku do przykładu poprzedniego je s t tylko jed n a różnica. Plik
util_eth.c zastąpiono plikiem util_etli_nc.c. W dalszym ciągu opisuję tylko różnice
m iędzy tym i plikam i.
Plik u tilje th jjc .c - inicjowanie interfejsu sieciowego
W tej w ersji sterow nika bufory odbiorcze pochodzą z puli buforów biblioteki lwIP.
D o ich obsługi definiujem y dw ie globalne tablice. W tablicy rxBuf ferFlags prze­
chow ujem y znaczniki. W tablicy rxBuffer przechow ujem y w skaźniki do struktury
typu pbuf opisującej bufory odbiorcze. Tablice te m ają tyle sam o elem entów co
pierścień deskryptorów , czyli po jed n y m elem encie dla każdego deskryptora.
128
3. Stos TCp/ffl
Tab. 3.12. Pliki przykładu 3b
Zrńdlnwi! i biblioteczne
ex_ip.c
font5x8.c
startup_stm 32_cld. c
board_conf.c
boardJn it.c
board_lcd_ks0108. c
board led.c
utiljfelay.c
util_eth_nc.c
u tiljc d .c
u tiljcd _e x.c
u tilje d .c
u tiljw ip .c
util time.c
tibtwip4.a
Hbstm32f10x.a
font5x8.h
board_conl.li
board_def.fi
board_defs.li
b o a rd jn it.li
b o a rd jc d .li
b o a rd je d .h
CC.Il
cortex-m 3.h
Iwipopts.h
stm 32l10x_conf.li
static uint8_t rxBufferFlags[ETH_RXBUFNB);
static struct pbuf *rxBuffer(ETiJRXBUFNB);
B ufory odbiorcze alokuje funkcja A l locRxBuffers w yw ołana w funkcji ETHiniii
przed skonfigurow aniem D M A . Z m iana w funkcji ETHinit jest następująca:
if (AllocRxBufferso < 0)
return ERR MEM;
ETHconfigureDMA(netif, L W I P J R Q J R I O , 0};
Funkcja A l locRxBuffers zw raca zero, gdy zakończyła się sukcesem , a warlo?
ujem ną w przeciw nym przypadku. B ufory alokujem y z puli buforów bibliote!
lwIP. Poniew aż alokujem y bufory o rozm iarze rów nym buforom w puli, przydziel
ne łańcuchy buforów m ają p o jed n y m elem encie, czyli bufory są w jed n y m kawat
(patrz opis stałej PBUF_POOL_BUFSIZE zdefiniow anej w pliku Iw ipopts.h).
static int AllocRxBuffers(void)
int i, j;
(
for (i = 0; i < ETHJWBUFNB; ++i) {
rxBufferFlags(i) = 0;
rxBuffer[il = pbuf_alloc(PBUF_RAW, PBUF_POOL_BUFSIZE, P B U F J O O L ) ;
if (rxBufferii] == NULL) (
for (j = i - 1; j >= 0; — j)
pbuf free(rxBuffer(i));
return -1;
D o w ysyłania ram ek będziem y, ja k w poprzednim sterow niku, używ ać statycznych
buforów nadaw czych. Jednak, aby om inąć ograniczenia ukryte w im plem entacji bi­
blioteki ST M 32, nie skorzystam y z funkcji oferow anych przez tę bibliotekę. Dzięki
tem u m ożem y na przykład zdefiniow ać w łasny rozm iar buforów nadaw czych, aby
uw zględniał ram ki V LA N, które być m oże w przyszłości zechcem y obsługiw ać.
Funkcja ETHconf igureDMA m a podobną strukturę do jej odpow iednika z poprzednie­
go sterow nika. R óżnica polega na tym , że teraz konfigurujem y kolejki deskryptorów
ja k o pierścienie i nie używ am y do tego funkcji z biblioteki STM 32. N ajpierw kon­
figurujem y pierścień deskryptorów odbiorczych. Składow ą ControlBufferSize we
w szystkich deskryptorach zerujem y m iędzy innym i po to, aby w yzerow ać bit DIC
i tym sam ym uaktyw nić przerw anie odbiorcze. W łaściw ym inicjow aniem deskryp­
torów odbiorczych zajm uje się, opisana niżej, funkcja DMAr x B u f ferSet. N astępnie
konfigurujem y pierścień deskryptorów nadaw czych. Z erujem y też indeksy bieżą­
cych deskryptorów . R eszta funkcji je s t analogiczna ja k w poprzednim sterow niku.
static void ETHconfigureDMA(struct netif ‘netif,
uint8_t priority,
uint8_t subpriority)
NVIC_InitTypeDef NVIC_IniŁStruct/
int i;
{
DMArxIdx = 0;
j
for {i * 0; i < ETH_RXBUFNB; ++i) i
DMArxRing[ij.ControlBufferSize = 0;
DMArxBufferSet(&DMArxRing{i], rxBuffer[i]);
}
DMArxRingfETH_RXBUFNB - 1).ControlBufferSize ¡= ETH_DMARxDesc_RER;
ETH->DMARDLAR = (uint32_t)DMArxRing;
DMAtxIdx = 0;
for (i = 0; i < ETHJXBUFNB; ++i) !
i if CHECKSUMJ5ENJP =* 0
DMAtxRing[i).Status = ETHJ)MATxDesc_CICJPV4Header;
jjelse
DMAtxRingEi].Status = 0;
tfendif
DMAtxRing[i].ControlBufferSize = 0;
DMAtxRing[i].BufferlAddr = (uint32_t)TxBuff(i);
DMAtxRing(i].Buffer2NextDescAddr = 0;
)
}
I
return 0;
)
K olejną różnicą w stosunku do poprzedniego sterow nika je st użycie pierścienia <
skryptorów . D eklarujem y dw ie tablice, w których zorganizujem y te pierścienie <
dw a indeksy, które będą w skazyw ać odpow iednio bieżący deskryptor odbiorczy
i
i nadawczy.
static
static
static
static
129
»define TX_BUFFER_SIZE (ETIi MAX_PACKET_SIZE ł VLAN_TAG - ETH_CRC)
static uint8_t TxBuff(ETH_TXBUFNBJ¡TX_BUFFER_SIZEj ALIGN4;
Nagłówkowe
util_delay.il
utH_eth.h
u tiljc d .h
u tiljcd _e x.li
u tilje d .h
u tiljw ip .h
util time.h
3.5. Przykład 3b - sterownik Ethernetu bez kopiowania
ETH_DMADESCTypeDef DMArxRin g {ETH_RXBUFNB] ALIGN4;
ETH_DMADESCTypeDef DMAtxRing[ETHJ’
XBUFNB] ALIGN4;
int DMArxIdx;
int DMAtxIdx;
DMAtxRing (ETHJ’
XBUFNB - 1].Status |= ETH_DMATxDesc J E R ;
ETH->DMATDLAR = (uint32_t)DMAtxRing;
p_netif = netif;
NVIC_InitStruct .NVICJRQChannel = ETHJRQn;
NVICJnitStruct .NVICJRQChanneiPreemptionPriority = priority;
NVICJnitStruct.NVICJRQChannelSubPriority = subpriority;
NVICJnitStruct.NVICJRQChannelCmd * ENABLE;
NVI C J n i t ( S N V I C J n i t S t r u c t ) ;
ETH_DMAITConfig(ETH_DMAJT_NIS ! ETH_DMAJT_R, ENABLE);
)
Pierw szym argum entem funkcji DMArxBuf ferSet je s t w skaźnik do inicjow anego deskryptora odbiorczego. D rugim argum entem je s t w skaźnik do struktury typu pbuf
3. Si os TCP/ip<
13 0
opisującej bufor, do którego m a być skopiow ana odebrana ram ka. B ufor je st przy-,
dzielony w jednym kaw ałku, w ięc w ykorzystujem y tylko składow ą B ufferlA dd:
Adres drugiego bufora B uffer2N extD escA ddr zerujemy. N a koniec zerujem y polo
statusu i przekazujem y w łasność dcskryptora układow i DM A.
static void DMArxBufferSet(ETH_DMADESCTypeDef *rxDesc,
struct pbuf *p) {
rxDesc->ControlBufferSize &= ~ (E'i'H_DMARxDesc_RBSl j
ETH_DMARxDesc_RBS2) ;
rxDesc->ControlBufferSize |= p->len & ETH_DMARxDesc_RBSl;
rxDesc->BufferlAddr = (uint32_t) p->payload;
rxDesc->Buffer2NextDescAddr = 0;
rxDesc->Status = ETH DMARxDesc OWN;
3.5.2.
Plik util_eth_nc.c - wysyłanie ramek ethernetowych
Jedyną istotną różnicą w funkcji l ow_level_output w ysyłającej ram ki elhernetovu'
w stosunku do poprzedniego sterow nika je s t użycie pierścienia zam iast łańcucha
deskryptorów .
static err_t low_level_output(struct netif *netif, struct pbuf *p) {
((struct ethnetif *)netif->state)->TX_packets++;
if (p == NULL) {
{(struct ethnetif *)netif->state)->TX_errors++;
return ERR_ARG;
)
if (p->tot_łen > TX_BUFFER_SIZE) {
((struct ethnetif *)netif->state)->TX_errors+-ł;
return ERR_BUF;
I
if (DMAtxRing[DMAtxIdx].Status & ETH_DMATxDesc_OWN)
((struct ethnetif *) netif->state) ->TX__errors+ł;
return ERR_XF;
i
{
i
pbuf_copy_partial(p, (void *)DMAtxRing(DMAtxIdx).BufferlAddr,
p->tot_len, 0);
DMAtxRing[DMAtxIdx].ControlBufferSize =
p->tot_len & ETH_DMATxDesc__TBSl;
DMAtxRing(DMAtxIdx).Status j= ETH_DMATxDesc_FS I
ETH_DMATxDesc_LS i
ETH_DMATxDesc_OWN;
if (ETH->DMASR & ETH_DMASR_TBUS) (
*
ETH->DMASR = ET H_DMAS R_T BUS;
ETH->DMATPDR = 0;
)
if (DMAtxRing(DMAtxIdx] .Status 6 ETHJ3MATxDescJFER)
DMAtxIdx = 0;
else
-i+ DMAtxIdx;
return ERR OK;
3.5.3.
Plik util_eth_nc.c - odbieranie ramek ethernetowych
DM A kopiuje odebraną ram kę do bufora, który przekazujem y bibliotece lwIP. Od
tego m om entu w łaścicielem tego bufora je s t biblioteka. B iblioteka zw olni bufoi,
gdy ju ż nie będzie je j potrzebny. Z w alniany b u for w raca do puli buforów biblioteki.
Z atem bufor przekazany bibliotece nie m oże ju ż dłużej być w skazyw any przez de-
3.5. Przykicui 3b - sterownik Ethernetu bez. kopiowania
131
skryptor w kolejce odbiorczej i w jeg o m iejsce trzeba przydzielić nowy bufor z puli.
A lokow aniem now ych buforów zajm uje się funkcja ReallocRxBuffers, w yw ołana
w procedurze obsługi przerw ania ETH_IRQHandler.
void ETH_IRQHandłer(void) |
ETH_DMACiearITPendinqBit(ETH_DMR_IT_NIS | ETH_DMA_IT_R);
while (!(DMArxRinglDMArxIdxJ.Status s ETH_DMARxDesc_OWN)) 1
ethernetif_input(p_netif);
ReallocRxBuffers ( ) t
)
)
Funkcja ReallocRxBuffers przegląda cyklicznie kolejkę odbiorczą. Statyczna
zm ienna idx je s t indeksem w pierścieniu deskryptorów . W skazuje deskryptor, któ­
ry należy uaktualnić. U staw iony znacznik RX_BUF_U S E D _ U P oznacza, że deskryptor
został w ykorzystany i trzeba go zw rócić układow i D M A . W artość NULL w tablicy
rxBuffer oznacza, że bufor został przekazany bibliotece lw IP i trzeba przydzielić
now y bufor. Jeśli nie uda się przydzielić bufora, funkcja kończy działanie oczeku­
jąc, że uda się to przy następnym jej w yw ołaniu. Jeśli bufor je s t przydzielony, czyli
w skaźnik w tablicy rxBuffer je s t niezerow y, to zerujem y znacznik RX_BUF_USED_
UP i inicjujem y deskryptor za pom ocą funkcji DMArxBufferSet.
Idefine RX_BUF_USED_UP 1
static void ReallocRxBuffers(void)
static int idx = 0;
{
while (rxBufferFlags(idx) & RX_BUF_USED_UP) {
if (rxBuffer[idx] == NULL) {
rxBufferfidx] = pbufj*lloc(PBUF_RAW, PBUF_POOL__BUFSIZE,
PBUF__POOL) ;
if (rxBufferfidx] == NULL)
return;
)
rxBufferFlags(idx] &= ~RX_BUF_USED_UP;
DMArxBufferSet(SDMArxRing(idx ) , rxBuffer(idx));
if (DMArxRing(idx].ControlBufferSize & ETH_DMARxDesc_RER)
idx * 0;
else
++idx;
)
}
Jak poprzednio przekazaniem odebranej ram ki bibliotece lw IP zajm uje się funkcja
ethernetif_input. Poniew aż funkcja ta je s t w yw ołana w procedurze obsługi prze­
rw ania, gdzie nie m ożna zrobić w ielkiego użytku ze zw racanego przez nią kodu
błędu, ta jej w ersja nie zw raca żadnej w artości. Funkcja la uaktualnia statystykę
odebranych ram ek. N ależy pam iętać, że jeśli w yw ołanie funkcji przetw arzającej
ram ki w bibliotece lwIP, czyli funkcji w skazyw anej przez składow ą input struk­
tury netif, zakończy się pow odzeniem , to bufor został zw olniony. Jeśli natom iast
zakończy się błędem , to m usim y zw olnić ten bufor.
static void ethernetif_input(struct netif *netif) {
struct pbuf *p;
((struct, ethnetif *) netif->state) ->RX_packets-M;
p = low__łevel_input (netif);
if (p «= NULL)
3.6. Przykład 3c - eksperymentalny sterownik Ethernetu bez. kopiowania
((sfcruct ethnetif *)netif->state)->RX_errorsi+;
else if <netif->input(p, netif) !«* ERR_OK) {
pbuf_free(p)/
{(struct ethnetif *)netif->state)->RX_errors++;
)
}
N iskopoziom ow ą obsługą odebranej ram ki zajm uje się funkcja low_level_inputf
F unkcja la najpierw spraw dza, czy bieżący deskryptor zaw iera popraw nie odebraną,
ram kę i czy ram ka nie je st za krótka. Jeśli spraw dzenie w ypadnie pozytyw nie,
funkcja zw róci w skaźnik do struktury typu p b u f opisującej bufor z odebraną rani-'
ką. Z anim jed n ak zakończy działanie, w pisuje do tablicy rx B u ff e r w artość NUL
aby poinform ow ać funkcję R e a llo c R x B u ffe rs, że trzeba przydzielić nowy bufoi*B iblioteka łw IP oczekuje ram ki ethernetow ej bez sekw encji kontrolnej. Funkcj
p b u f_ _ reallo c ustaw ia w łaściw y rozm iar ram ki. D la buforów typu PBUF_POOL funk*
cja ta niczego nie kopiuje, uaktualnia tylko składow e le n i tot__len struktury typ'1
p b u f. N a koniec, ja k poprzednio, trzeba jeszcze w znow ić przeglądanie kolejki od­
biorczej, jeśli zostało w strzym ane.
static struct pbuf * low_level_input(struct netif *netif) {
struct pbuf *p = NULL;
uint32_t len;
if {(DMArxRing[DMArxIdxl.Status £ ETH_DMARxDesc_ES) == 0 ££
(DMArxRing[DMArxIdx).Status £ ETH_DMARxDesc_LS) != 0 ££
(DMArxRing[DMArxIdx).Status £ ETH_DMARxDesc_FS) != 0} I
len = ETl!_GetDMARxDescFrameLength (£DMArxRing(DMArxIdxj);
if (len >= ETH_HEADER + MIN_ETH_PAYLOAD + ETH_CRC) f
len -= ETH_CRC;
p = rxBuffer(DMArxIdx);
pbuf_realloc(p, len);
rxBuffer(DMArx!dx] = NULL;
i
}
rxBufferFlags(DMArxIdx) j» RX_BUF_USED_UP;
if (DMArxRing[DMArxIdx}.ControlBufferSize £ ETH_DMARxDesc_RER)
DMArxIdx = 0;
else
+ t-DMArxIdx;
if (ETH->DMASR £ ETH_DMASR_RBUS) {
ETH->DMASR = ETH_DMASR_RBUS;
ETH->DMARPDR = 0;
I
return p;
Przykład 3c - eksperymentalny sterownik
Ethernetu bez kopiowania
W tym przykładzie prezentuję kolejne ulepszenie sterow nika interfejsu sieciowego.
U lepszenie zm ierza w kierunku pełnej realizacji idei „zero-copy” . Rezygnujemy
z buforów nadaw czych D M A i w ysyłam y ram ki bezpośrednio z buforów bibliote­
ki IwIP. N azw y plików, które zaw ierają im plem entację, zebrane są w tabeli 3.13.
W stosunku do poprzedniego przykładu plik util_eth_nc.c został zastąpiony plikiem
util_eth_zc.c. W dalszym ciągu opisuję tylko różnice m iędzy tym i plikam i.
133
Tab. 3.13. Pliki przykładu 3c
Źródłowe i biblioteczne
BX_ip.C
lonl5x8.c
startup_stm32_cld. c
board_conl.c
b o a rd jn it.c
b o a rd jcd _k s01 08.c
b o a rd je d .c
font5x8.h
board_conl.lt
board_del.lt
board_deis.it
b o a rd jn it.h
board_lcd.lt
b o a rd je d .h
util_delay.c
util_eth_zc.c
u tiljc d .c
u tiljc d _ e x .c
u tilje d .c
u tiljw ip .c
u tiljim e .c
Iiblwip4.a
Iibstm 32l10x.a
Nagłówkowe
util_delay.h
util_eth.li
u liljc d .h
utilJcd_ex.it
u tilje d .h
u liljw ip .h
util time.b
CC.il
corlex-m 3.li
Iwipopts.li
stm 32l10x_con/.h
S terow nik ten je st eksperym entalny, gdyż nie będzie działał ze w szystkim i przykła­
dam i. Pow ody są następujące:
- -Biblioteka IwIP um ieszcza w ysyłaną ram kę w łańcuchu buforów. Zakładam , że
łańcuch składa się z co najw yżej dw óch struktur typu pbuf. Ten sterow nik nie
potrafi w ysiać ram ki rozm ieszczonej w łańcuchu składającym się z w iększej
liczby elem entów . Z aobserw ow ałem jednak, że biblioteka sporadycznie generuje
dłuższy łańcuch, eh^tć zaw sze było to w sytuacji, gdy w cześniej w ystąpił pro­
blem z siecią. W praktyce, gdy sieć działa stabilnie, sterow nik spisuje się zado­
w alająco.
- B iblioteka IwIP m oże m odyfikow ać zaw artość bufora z ram ką przekazaną do
w ysiania, jeśli w ykonuje retransm isję segm entu TCP. Z atem sterow nik musi zdą­
żyć w ysiać ram kę, zanim biblioteka podejm ie decyzję o retransm isji. W prakty­
ce, gdy sieć pracuje popraw nie, zaw sze zdąży.
- D M A m a problem z w ysyłaniem danych um ieszczonych w pam ięci Flash. Zw ykle
jed n ak w ysyłane dane są przygotow yw ane w buforze, który jest w RAM , więc
problem ten nie je s t dotkliw y. Jeśli jed n ak dane do w ysiania są w e Flash, trzeba
je najpierw skopiow ać do RAM . Jest to sprzeczne z ideą „zero-copy” przyśw ie­
cającą stw orzeniu tego sterow nika. Do problem u w ysyłania danych um ieszczo­
nych w pam ięci Flash w rócę jeszcze w kolejnym przykładzie.
M im o pew nych niedoskonałości tego sterow nika, postanow iłem go jednak zapre­
zentow ać w takiej postaci, aby nie kom plikow ać tekstu źródłow ego. N apisanie na
tej podstaw ie w pełni funkcjonalnego sterow nika pozostaw iam C zytelnikow i jako
ćw iczenie.
Plik util_eth_zc.c - inicjowanie interfejsu sieciowego
Ta w ersja sterow nika nie używ a statycznych buforów nadaw czych. Z am iast nich
używ a buforów z puli biblioteki IwIP. W globalnej tablicy tx B u ff e r przechow u­
jem y otrzym ane od biblioteki IwIP w skaźniki do struktur typu pbuf. Tablica ta ma
tyle sam o elem entów , ile je s t deskryptorów w pierścieniu nadaw czym , czyli po je d ­
nym dla każdego deskryplora.
3.6. Przykład 3c - eksperymentalny sterownik Ethernetu bez, kopiowania
static struct pbuf ‘txBufferIETHJTXBUFNB];
Teraz w funkcji E T H init przed skonfigurow aniem D M A , oprócz alokow ania bii'
forów odbiorczych, trzeba jeszc z e zainicjow ać pow yższą tablicę wskaźnikó,"
M odyfikacja je s t następująca:
Aj
if (AilocRxBuffers() < 0)
return ERR_MEM;
InitTxBuffers{);
ETHconfigureDMA(netif, LWIP__IRQ_PRIO, 0) ;
135
B uforów nadaw czych je s t niew iele, w ięc funkcja FreeTxBuf f e r s m oże przy każ­
dym w yw ołaniu przeglądać j e naiw nie, liniow o. Jeśli znajdzie w tablicy tx B u ff e r niezerow y adres łańcucha buforów i deskryptor o tym sam ym indeksie został
zw olniony przez DM A, to zw alnia ten łańcuch buforów . Funkcja ta uaktualnia też
statystykę błędów.
static void FreeTxBuffers(struct netif *netif) (
int i;
for (i = 0; i < ETHJTXBUFNB; ++i) I
if (txBuffer(i) SS
(DMAtxRingli].Status s ETH_DMATxDesc_OWM) == 0) (
if (DMAtxRingli).Status S ETH_DMATxDesc_ES)
((struct ethnetif *) netif->state) ->TX_errorst *f;
pbuf_free(txBuffer(i}};
txBuffer(i) = NULL;
Funkcja in itT x B u ff e r s po prostu zeruje w szystkie w skaźniki. W łaściw e wartośęi
będą przypisyw ane d y nam icznie w funkcji w ysyłającej ram ki. N iezerow a warlośd
w skaźnika będzie oznaczać, że w skazuje on na łańcuch buforów.
static void InitTxBuffers(void) (
int i;
)
for (i = 0; i < ETH_TXBUFNB; ++i)
txBuffer[i] = NULL;
1
:!'/
Funkcja ETHconfigureDMA różni się od sw ojej poprzedniczki tylko dw om a instruk­
cjam i:
DMAtxRing[i].BufferlAddr = 0;
ETH_DKAXTConfig(ETH_DMA_IT_NIS | £TH_DMA_IT__R | ETH_DMA_IT_T,
ENABLE);
Nie znam y adresów buforów z w ysyłanym i ram kam i, więc na razie zerujem y skla*
dow ą B u ffe rlA d d r we w szystkich deskryptorach nadaw czych. A by móc dynamicz^
nic obsługiw ać bufory nadaw cze, potrzebujem y inform acji o zakończeniu transmisji;
D latego, oprócz przerw ania zgłaszanego po skopiow aniu odebranej ram ki, uaktyw­
niam y też przerw anie inform ujące o zakończeniu przez D M A transm isji wysyłanej
ram ki (ustaw iam y dodatkow o bit ETH_DMA_IT_T).
Plik util_eth_ 2c.c - wysyłanie ramek ethernetowych
Poniew aż uaktyw niliśm y now e źródło przerw ania, m usim y zm odyfikow ać proce
durę ETH_IRQHandler o bsługującą przerw ania E thernetu. C zęść obsługująca pi/c-1
rw anie odbiorcze je st w zasadzie identyczna ja k w poprzedniej w ersji sterownik
W części obsługującej przerw anie nadaw cze w yw ołujem y funkcję FreeTxB uffers',
zw racającą do puli te bufory, których zaw artość została ju ż w ysłana przez DMA.
void ETH_IRQHandler(void) (
ETH_DMAClearITPendingBit(ETH_DMA_IT_NIS ) ;
if (ETH_GetDMAITStatus(ETH_DMA_IT_T)) (
ETH_DMAClearITPendingBit(ETH_DMA_IT_T);
FreeTxBuffers(p_netif);
)
if (ETH_GetDMAITStatus(ETH_DMA_IT_R)) (
ETH_DMAClearITPendingBit(ETH_DMA_IT_R);
while (!(DMArxRing[DMArxIdx).Status S ETIl_DMARxDesc_OWN)) (
ethernetif_input(p_netif);
ReallocRxBuffers();
)
,
!
Za w staw ienie ram ki do kolejki nadaw czej odpow iada, jak poprzednio, funkcja
lo w _ le v e ł_ o u tp u t. Funkcja ta najpierw spraw dza popraw ność argum entów i do­
stępność w olnego deskryptora w kolejce nadaw czej oraz uaktualnia statystykę w y­
słanych ram ek. N astępnie zw iększa licznik referencji łańcucha buforów p i zapisuje
je g o adres w tablicy tx B u ffe r. B iblioteka lw IP po popraw nym zakończeniu funkcji
lo w _ łe v e l_ o u tp u t w yw ołuje na łańcuchu buforów funkcję pbuf__free. Z w iększenie
licznika referencji spraw ia, że bufory zostaną zw olnione dopiero wtedy, gdy funkcja
p b u f_ f re e zostanie w yw ołana po raz drugi w funkcji FreeTxBuf f e r s . D eskryptor
je st inicjow any za pom ocą funkcji DMAtxBuff e r S e t. N a koniec w znaw iane jest
przeglądanie kolejki nadaw czej i indeks DMAtxIdx jest przesuw any na następny de­
skryptor w pierścieniu.
static err t low__level_output (struct netif *netif, struct pbuf *p) (
{(struct ethnetif *)netif->state)->TX_packets+-f-;
if (p
NULL) (
({struct ethnetif *)netif->state)->TX_errors++;
return ERR ARG;
3
if (pbuf_chain_łen(p) > 2 |j
txBuffer[DMAŁxIdx] ||
DMAtxRing[DMAtxIdx].Status & ETH_DMATxDesc_OWN)
({struct ethnetif *)netif->state)->TX_errors++;
return ERR_IF;
}
pbuf_ref(p);
txBuffer[DMAtxIdx] = p;
DMAtxBufferSet(SDMAtxRingfDMAtxIdx], p ) ;
if (ETff->DMASR & ETH_DMASR_TBUS) i
ETH->DMASR - ETH_DMASR_TBUS;
ETH->DMATPDR = 0;
)
if (DMAtxRing(DMAtxIdxj.Status & ETH_DMATxDesc_TER)
DMAtxIdx «= 0;
else
■f+DMAtxIdx;
return ERR_0K;
{
137
3.8. ICMP - komunikaty kontrolne i komunikaty o błędach
Jak napisałem w cześniej, zakładam y, że w ysyłana ram ka będzie umieszczony
w 7łańcuchu buforów o długości co najw yżej dw a. D ługość łańcucha sprawdzarriyj,
za pom ocą funkcji p b u f_ c h a in _ le n , która je st bardzo podobna do funkcji pb
c le n z biblioteki łwIP, ale w przeciw ieństw ie do niej je s t popraw na.
static iiit pbuf_chain_len(struct pbu£
int len;
T a b . 3 .1 4 .
■pi i
Porównanie sterowników
Przykład
Sterownik
Flash
HAM
3a
util_eth.c
53 488
42 988
917 ± 1 2 p s
3b
util eth nc.c
53556
36924
877 ± 3 2 ps
3c
u til_ e th jc .c
53768
30 860
85 9 ± 2 5 ps
Tab. 3.15. Użyte parametry programu p in g
len = p != NULL;
while (p i= NULL &S p->tot_len != p->len) {
•H len;
p “ p~>next:;
Param etr Linux
Param etr Windows
-n liczba
Wysyła podaną liczbę próśb o echo
-s liczba
-1 liczba
Tworzy komunikat z polem danych o podanej długości. Wysyłając
więcej niż 1472 oktety danych, można przetestować poprawność
działania tragmentacji i składania datagramów IP
-n
Funkcja DM AtxBufferSet inicjuje deskryptor w kolejce nadaw czej i przekazu­
je go układow i DM A. U staw ia też b it IC, aby po zakończeniu transm isji zostĄ
ło zgłoszone przerw anie. Z ależnie od długości łańcucha buforów p wykot/yi
styw any je st tylko adres je d n eg o bufora lub oba adresy (składow e B u fferlA d d '
i Buf fer2N extD escA ddr).
Nie podejmuje próby przetłumaczenia adresu IP na nazwę węzła
192.168.51.89
Adres węzła, do którego są wysyłane prośby o echo
że kolejne w ersje sterow ników m ają coraz bardziej skom plikow any tekst źródłow y
i zajm ują coraz w ięcej pam ięci program u, ale przyrost ten jest nieznaczny i nie ma
praktycznego znaczenia. N atom iast likw idacja statycznych buforów odbiorczych
w przykładzie 3b, a następnie rów nież statycznych buforów nadaw czych w przy­
kładzie 3e, w yraźnie zm niejsza zajętość pam ięci danych. Pozostaje więcej m iejsca
na stertę i stos, co pozw ala bardziej elastycznie gospodarow ać niew ielką pam ięcią
m ikrokontrolera.
static void DMAtxBufferSet(ETH_DMADESCTypeDef *txDesc,
struct pbuf *p) {
txDesc->ControłBufferSize = (uint32_t)p->len & ETHJ3MATxDesc_TBSl;
txDesc->BufferlAddr = (uint32_t)p->payload;
if (p->tot_len > p->len) {
p - p->next;
txDesc->ControlBufferSize |= ((uint32_t)p->len « 16) S,
ETH_DMATxDesc_TBS2;
txDesc~>Buffer2NextDescAddr = (uint32_t)(p->payload);
Aby spraw dzić, czy pozbycie się kopiow ania ram ek przyspiesza ich obsługę, zm ie­
rzyłem za pom ocą program u ping czasy odpow iedzi program u na kom unikaty p ro ś­
ba o echo protokołu IC M P - patrz rozdział 3.8. W L inuksie polecenie jest nastę­
pujące:
)
else
txDesc->Buffer2NextDescAddr = 0;
txDesc->SŁatus 1= ETH_DMATxDesc_IC | ETH_DMATxDesc_FS |
ETH_DMATxDescJLS i ETH_DMATxDesc_OWN;
ping -c 100 -s 1472 -n 192.168.51.89
W system ach W indow s w ygląda tak:
i
Jeśli chcielibyśm y zaim plem entow ać obsługę łańcuchów buforów o długości w ic i­
szej niż dw a, to do w ysłania jednej ram ki m ożna użyć kilku kolejnych deskryptoiów
W pierw szym z tych deskryptorów ustaw iam y tylko bit FS, a w ostatnim tylko bi^
LS. O czyw iście w tedy odpow iednio kom plikuje się też zw alnianie buforów. Nalęż
rów nież pam iętać, żeby bit OWN w pierw szym z tych deskryptorów ustaw ić dopierona końcu, po zainicjow aniu w szystkich deskryptorów . W przeciw nym przypadk
D M A m oże rozpocząć transm isję, zanim cała ram ka będzie golow a do wysłania.
W tabeli 3.14 zam ieszczone je s t porów nanie w yżej opisanych sterow ników . W ko?;
lum nie Flash je st podana całkow ita zajętość pam ięci program u, uw zględniająca ta-*
blicę przerw ań, sekcję . t e x t (w tym sekcję .r o d a ta ) oraz sekcję .d a ta . W kolunP
nie R A M je s t pod an a zajętość pam ięci danych, uw zględniająca sekcje .d a ta i J'-: 3
ale nieuw zgłędniająea pam ięci alokow anej dynam icznie na stosie i stercie. Wida
Opis
-c liczba
}
return len;
Testy sterowników
Czas odpowiedz!
ping -n 100 -1 1472 192.168.51.89
U żyte param etry opisane są w tabeli 3.15. Test polegał na w ysianiu 100 próśb, z któ­
rych każda zaw ierała po 1472 oktety danych, aby w ypełnić całą ram kę ethernetow ą.
O statnia kolum na tabeli 3.14 zaw iera średni czas oczekiw ania na otrzym anie odpo­
wiedzi i je g o odchylenie standardow e, w ypisane przez linuksow ą w ersję program u
ping. W ersja w system ie W indow s m ierzy czas zbyt m ało dokładnie. M im o sporego
rozrzutu tych czasów w idać, że likw idacja niepotrzebnego kopiow ania przyspiesza
przetw arzanie ram ek.
3.8.
ICMP - komunikaty kontrolne i komunikaty
o błędach
IC M P (ang. Internet C ontro/ M essage Protocol) to intersieciow y protokół kom u­
nikatów kontrolnych, opisany w RFC 792. Jest on obow iązkow ą częścią IP, co
oznacza, że każda im plem entacja IP musi też im plem entow ać ICMP. Przyjęto go
138
3.8. ICM P —komunikaty kontrolne i komunikaty o błędach
3' •V,','v lifts
k om po n en ty intersieci d ziałają praw id ło w o - o p ro g ram o w an ie IP nadaw cy w y­
syła i o d b iera datagram y, rutery p o średnie m iędzy nad aw cą a od b io rcą p raw id ­
łow o p rzesy łają datagram y, w ęzeł d o celo w y je s t u ru chom iony i d ziała na nim
o p ro g ram o w an ie IP. N ależy je d n a k zazn aczy ć, że w ęzły nie m uszą odpow iadać
na p ro śb ę o ech o - m oże to być ze w zględów b ezp ieczeń stw a zablokow ane ad ­
m in istracyjnie.
Tab. 3.16. Wybrane wartości pola TYP komunikatu ICMP
Komunikat
Typ
Odpowiedź z echem
0
3
Odbiorca nieosiągalny
4
Tłumienie nadawcy
8
Prośba o echo
11
Przekroczenie czasu
12
Problem z parametrem
TYP
[0:7]
3.8.2.
IDENTYFIKACJA
(0:31)
DANE
Rys. 3.4. Format komunikatu ICMP
O dbiorca m oże być nieosiągalny z w ielu pow odów . M oże w ystąpić aw aria odcina­
ją c a podsieć, w której znajduje się w ęzeł odbiorcy. W ęzeł m oże być po prostu w yłą­
czony. T rzeba jednak jasn o zaznaczyć, że w sieci E thernet nie m a prostego sposobu
stw ierdzenia, że ja k iś w ęzeł nie działa. M im o działania w ęzła odbiorcy, m oże nie
działać aplikacja, do której adresow any je s t datagram IP. K om unikat o nieosiągal­
ności m oże też pojaw ić się, gdy kom unikacja z odbiorcą je s t zablokow ana adm ini­
stracyjnie.
w spólnie z 1P, ja k o standard intersieci S T D 5. IC M P um ożliw ia diagnozow anie prdł
blcm ów w działaniu intersieci. IC M P pow iadam ia pierw otnego nadaw cę datagram!
IP o problem ie z tym datagram em . K om unikaty ICM P są kapsulkow ane w data*
graniach IP, aby m ogły być dostarczane w dow olne m iejsce intersieci. Mimo
IC M P nie je st uw ażany za protokół w arstw y transportow ej. JesTi w ystąpi probier)
z dostarczeniem datagraniu przenoszącego kom unikat ICMP, nie w ysyła się koloj^
nego kom unikatu IC M P inform ującego o tym błędzie, aby nie spow odow ać lawiny
kom unikatów , które m ogłyby zapchać sieć.
K om unikat odbiorca nieosiągalny um ożliw ia rów nież poznanie M TU ścieżki do
odbiorcy. M T U ścieżki je s t to najm niejsze M T U w śród w szystkich sieci, przez któ­
re w ędruje datagram IP. Z najom ość M T U ścieżki um ożliw ia w ysyłanie datagraniów
IP o takiej długości, aby nie m usiały być po drodze fragm entow ane. A by poznać
M T U ścieżki, w ysyła się próbne datagram y IP o różnych długościach z ustaw ioną
w nagłów ku IP opcją nie fra g m en tu j. Jeśli datagram IP je s t za długi, to ruter po­
rzuci go i poinform uje nadaw cę kom unikatem odbiorca nieosiągalny z polem KOD
rów nym 4, co oznacza, że konieczna je s t fragm entacja, ale ustaw iona je s t opcja nie
fra g m en tu j. M TU ścieżki to długość najdłuższego datagram u IP, który dotrze do
odbiorcy. O dotarciu datagram u IP do odbiorcy m ożna przekonać się za pom ocą na­
stępującego triku. W ysyła się datagram IP zaw ierający datagram UDP, skierow any
do usługi, która nie jest uruchom iona w w ęźle odbiorcy. Jeśli taki datagram U DP
dotrze do odbiorcy, odeśle on nadaw cy kom unikat odbiorca nieosiągalny z polem
K O D rów nym 2 lub 3, inform ującym o nieosiągalności usługi, co jed n ak ew ident­
nie św iadczy o osiągalności w ęzła odbiorcy.
Form at kom unikatu IC M P je s t przedstaw iony na ry s u n k u 3.4. W ybrane, najczy­
ściej spotykane w artości pola T Y P zam ieszczone są w ta b e li 3.16. W polu SUN
K O N TR O LN A um ieszcza się sum ę spraw dzającą integralność kom unikatu. Pól.
KOD, ID E N T Y FIK A C JA i D A N E są interpretow ane zależnie od w artości poi:
TYP. Pole D A N E je s t opcjonalne i nie musi w ystępow ać.
3.8.1.
Sprawdzanie osiągalności odbiorcy
A by spraw dzić osiągalność odbiorcy, w ysyła się kom unikat prośba o echo (warto
8 w polu T Y P). Pole KOD zaw iera 0. Pole ID E N T Y F IK A C JA składa się wtedy,
z dw óch 16-bitowych pól. W pierw szych 16 bitach um ieszcza się unikalny identyfH;:
kator kom unikatu. W pozostałych 16 bitach um ieszcza się kolejny num er komunika­
tu. Pole D A N E m a dow olną zaw artość. W ęzeł, który odbierze prośbę o echo, odpo.-;
w iada kom unikatem o d p o w ied ź z. echem . O dpow iedź zaw iera w polu T Y P wartość
0. W polu KOD też jest w artość 0. Pola ID E N T Y F IK A C JA i D A N E zaw ierają danfe. ^
skopiow ane z odpow iednich pól kom unikatu z prośbą. Pole ID EN TY FIK A t ■
um ożliw ia pow iązanie odpow iedzi z prośbą.
K om unikaty p ro śb a o echo i o d p o w ie d ź z echem są u ży w an e przez progi
p in g do sp raw d zan ia o siąg aln o ści w ęzłów . P o n iew aż k o m u n ik aty IC M P w ędrują^,
w d atag ram ach IP, o trzy m an ie pop raw n ej odp o w ied zi św iadczy, że p o d staw
Powiadamianie o nieosiągalności odbiorcy
Jeśli datagraniu IP nie m ożna dostarczyć, w ysyła się je g o pierw otnem u nadaw ­
cy kom unikat odbiorca nieosiągalny. Pole T Y P zaw iera w artość 3. Pole K OD
zaw iera szczegółow ą inform ację o przyczynie odrzucenia datagraniu. Pole
ID E N T Y FIK A C JA nie je s t używ ane i zaw iera 0. Pole D A N E zaw iera początkow y
fragm ent datagraniu, który spow odow ał problem . Fragm ent ten zaw iera nagłów ek
datagraniu i początkow e 64 bity je g o pola danych. Początkow e 64 bity poła danych
datagraniu IP zaw ierają zw ykle kluczow e inform acje z nagłów ka protokołu trans­
portow ego. D zięki tem u odbiorca kom unikatu IC M P m oże łatwiej zidentyfikow ać
przyczynę problem u.
SUMA KONTROLNA
[16:31]
KOD
[8:15]
13 9
3.8.3.
Kontrola przepływu
Jeśli ruter je s t przeciążony i nie je s t w stanie przetw arzać odbieranych datagraniów
IP, w ysyła ich nadaw com kom unikaty tłum ienie nadaw cy. Pole T Y P m a w artość 4.
Pole K O D zaw iera 0. Pole ID E N T Y FIK A C JA nie je s t używ ane i m a w artość 0.
140
3. Stos TOjM
Pole D A N E zaw iera, ja k poprzednio, początkow y fragm ent dalagram u, którego ni
m ożna przetw orzyć.
P rzeciążenie (ang. congestion) m oże być spow odow ane przez jed en bardzo szff
ki kom puter, który w ysyła datagram y IP szybciej niż ruter potrafi je obsłużyć
R uter m oże też być przeciążony przez w iele kom puterów , w ysyłających do n ić *
rów nocześnie datagram y IP, m im o że żaden z tych kom puterów osobno nie wywo
lałby tego problem u. Przeciążenie m oże być objaw em ataku typu odm ow a usług
P rzeciążenie m oże pojaw ić się też, gdy ruter łączy dw ie sieci o różnych p rze p ły ń
nos'ciach, na przykład szybką sieć lokalną (L A N , ang. local area netw ork) z wo»
ną siecią rozległą (W AN, ang. w ide area netw ork). W tedy datagram y naplywajäf*
z sieci lokalnej m ogą pojaw iać się zbyt szybko, aby w szystkie m ogły być p r z e |||
zane do sieci rozleglej.
R uter broni się przed przeciążeniem , stosując buforow anie, które zabezpiecza prze
chw ilow ym zw iększeniem natężenia ruchu. Jeśli zw iększony ruch trw a dostateczni'
długo, to każdy bufor w reszcie zapełni się i datagram y IP będą tracone. Ruter mozje"
stosow ać różne strategie. M oże w ysyłać po jed n y m kom unikacie tłum ienie nadaWi
cy dla każdego straconego datagram u. R uter m oże w ysyłać ten kom unikat tylko cii)
nadaw ców przysyłających najw ięcej datagram ów . R uter m oże też próbow ać uniknij
przeciążenia, w ysyłając tłum ienie na d a w cy, gdy je g o bufor będzie blisko przepej£
nienia. W ęzeł, który otrzym uje kom unikaty tłum ienie n adaw cy, pow inien zmniojj
szać liczbę w ysyłanych datagram ów , aż przestanie otrzym yw ać te komunikaty. Pty
pew nym czasie m oże spróbow ać zw iększyć liczbę w ysyłanych datagram ów , dopókj
'A
znów nie zacznie być tłum iony.
■ '.iii
3.8.4.
Przekroczenie czasu
K om unikat przekroczenie czasu m a w polu T Y P w artość 11. Pole KOD ma wartość/''
0, gdy w yczerpał się czas życia datagram u IP, a w artość 1, gdy upłynął czas nąskładanie fragm entów . Pole ID E N T Y F IK A C JA nie je s t używ ane i zaw iera 0. Pole''
D A N E zaw iera początkow y fragm ent datagram u, który został porzucony.
141
je st rów nież wtedy, gdy pojaw i się problem , który nie da się opisać żadnym innym
kom unikatem ICMP. Pole T Y P m a w artość 12. Pole KOD zaw iera 0 lub 1. Jeśli ma
w artość 0, to pierw sze 8 bitów pola ID E N T Y FIK A C JA w skazuje na oktet, który
spow odow ał problem , a pozostałe 24 bity tego pola są w ypełnione zeram i. Jeśli
pole K O D m a w artość różną od 0, to pole ID E N T Y FIK A C JA nie jest używ ane
i zaw iera 0. Pole D A N E zaw iera początkow y fragm ent datagram u, który spow odo­
wał problem .
DHCP - konfigurowanie ustawień sieciowych
węzła
D H C P (ang. D ynam ie Most C onfiguration P rotocol) je s t protokołem d y n am icz­
nego k o n fig u ro w an ia w ęzłów . O pisany je st w R FC 2131. Za pom ocą D H C P w ę­
zeł m oże uzyskać w szystkie niezbędne ustaw ien ia sieciow e, do których należą
adres IP, m aska podsieci, nazw a w ęzła, adres rutera, adres serw era D N S, adresy
serw erów innych usług. K om unikaty D H C P są k apsułkow ane w datagram ach
UDP, które z kolei są kapsu łk o w an e w datag ram ach IP. P ierw szy problem , który
w ym aga ro zw iązania, to sposób, w ja k i w ęzeł m oże używ ać IP, zanim pozna
sw ój adres. D H C P ro zw iązuje go tak, że pierw szy kom unikat je s t w ysyłany za
p o m o cą ro zg łaszan ia UDP. W ten sposób m ożna w ysłać kom unikat do w szy st­
kich w ęzłów w podsieci. O d p o w ied ź też m oże być w ysłana za pom ocą ro zg ła­
szania. Po otrzym aniu odpow iedzi w ęzeł pozn aje adres drugiej strony i dalsze
ko m u n ikaty m ogą być w ysyłane ju ż bezpośrednio. R o zgłaszanie m oże odbyw ać
się tylk o w obrębie podsieci, w ięc D H C P w ym aga, aby w każdej podsieci zn aj­
dow ał się serw er tego protokołu albo je g o p ośrednik (ang. relay agent), który
d ziała w im ieniu serw era.
Problem z parametrem
W ęzeł, rozpoczynając pracę, staje się klientem DHCP. N ajpierw rozgłasza kom uni­
kat m ający na celu poznanie serw erów DHCP. K lient czeka przez określony czas na
oferty od serwerów . Po upłynięciu tego czasu, jeśli nie dostał żadnej oferty, ponaw ia
rozgłoszenie. Jeśli dostał co najm niej je d n ą ofertę, w ysyła do w ybranego serw era
żądanie w ynajm u ustaw ień sieciow ych. Jeśli w szystko poszło dobrze, serw er po­
tw ierdza w ynajem . U staw ienia w ynajm ow ane są na określony czas. Jeśli upłynęła
połow a czasu w ynajm u, klient zw raca się do serw era, od którego w ynajął ustaw ie­
nia, o przedłużenie czasu w ynajm u. Jeśli serw er potw ierdzi nowy czas w ynajm u,
to klient zaczyna odliczać go od początku. Jeśli klient nie uzyskał przedłużenia
w ynajm u i m inęło 87,5% czasu w ynajm u, klient próbuje przedłużyć w ynajem od
w szystkich serw erów , które poznał po fazie rozgłaszania. Jeśli m im o to klient nie
uzyskał przedłużenia w ynajm u i miną! cały czas w ynajm u, klient rezygnuje z uży­
w ania otrzym anych ustaw ień sieciow ych. W tej sytuacji klient musi rozpocząć całą
procedurę od now a. W praktyce zdarza się to rzadko i zw ykle jest spow odow ane
aw arią serw era DHCP. K lient w każdej chw ili m oże też sam zrezygnow ać z dalsze­
go w ynajm u.
Jeśli zostanie stw ierdzony błąd w nagłów ku dalagram u IP, jeg o pierwotnem
nadaw cy odsyłany je s t kom unikat problem z param etrem . Taki kom unikat o d sy ła n y
S erw er D H C P rozpoznaje klienta za pom ocą identyfikatora przesyłanego w fazie
rozgłaszania. Z w ykle identyfikatorem je s t adres sprzętow y klienta. Strategia przy­
Poniew aż rutery podejm ują d ecyzje o przesyłaniu datagram ów IP na podstawie;];
lokalnych tablic tras, błąd w ich konfiguracji m ógłby spow odow ać nieskończone:/
krążenie datagram ów w sieci. N agłów ek datagram u IP zaw iera licznik czasu życia,
(ang. tim e to live), nazyw any też licznikiem etapów . R uter zm niejsza licznik czasu*
życia datagram u przed je g o przetw orzeniem i porzuca datagram , gdy licznik tetk
osiągnie w artość zero. K om unikat przekroczenie czasu pozw ala w ykryw ać zbyt diu/*'
gie lub zapętlone trasy.
L icznik czasu na składanie datagram u IP startuje, gdy przychodzi pierw szy frag'
m ent datagram u. W ęzeł porzuca w szystkie dotychczas otrzym ane fragm enty data­
gram u i w ysyła kom unikat p rzekroczenie czasu, gdy w ustalonym czasie nie odbieg,
rze w szystkich fragm entów .
•
3.8.5.
3.9. DHCP —konfigurowanie ustawień sieciowych węzła
dzielania adresu IP m oże być konfigurow ana. S erw er m oże przydzielać klientowi
zaw sze ten sam adres.
U żyw anie klienta D H C P za pom ocą biblioteki lw IP opisałem w rozdziale 3.4,5ę
O protokole UDP, rozgłaszaniu i m odelu klient-serw er piszę w ięcej w dalszych roz­
działach.
Programowanie w modelu
klient-serw er
4. Programowanie w modelu klient-seiĘk
14 4
S erw er to program kom puterow y św iadczący jak ą ś usługę sieciow ą. Przykłada5
usług najczęściej oferow anych w sieciach kom puterow ych są w ysyłanie e-matí
przesyłanie stron www, przesyłanie plików czy tłum aczenie nazw dom enow ych)!
adresy IP. K lient to program kom puterow y korzystający z usługi oferow anej pr2¿
serwer. Serw erem często też nazyw a się kom puter (w ęzeł sieci), na którym d ziff
serwer. P odobnie klientem m ożna nazyw ać w ęzeł, na którym działa klient, je'^j
z kontekstu w ynika, o które z tych znaczeń chodzi. Z punktu w idzenia komunik
cji sieciow ej serw er je s t stroną pasyw ną, a klient stroną aktyw ną. S erw er o c z e k ||
na kom unikaty od klienta. K lient inicjuje kom unikację sieciow ą z serw erem , v.y
syłając prośbę lub żądanie realizacji określonej usługi. .Serwer realizuje tę usługi
odpow iadając klientow i na o trzym ane od niego kom unikaty. W tym m odelu serwe*
je s t często centralnym w ęzłem . Jeśli klienty m uszą kom unikow ać się ze sobą, ((j
serw er pośredniczy w ich kom unikacji - klient nie m oże w ysiać kom unikatu bèzi'
pośrednio do innego klienta. M odel klien t-serw er przedstaw iony je st schematycznie'
na ry s u n k u 4.1. Jak zobaczym y w dalszej części tego rozdziału, protokoły transí
portow e intersieci i interfejs program istyczny biblioteki lwJP tak zaprojektowano!1
aby w spierać ten m odel kom unikacji. Interfejs program istyczny biblioteki IwIP nić
jest tu bynajm niej w yjątkiem . Inne interfejsy program istyczne, w tym powszechnie',
stosow any interfejs gniazd, też preferują m odel klient-serw er.
Innym m odelem kom unikacji, często spotykanym w intersieciach, je s t m odel równy)
z rów nym (ang. peer-to-peer). M odel ten je st pokazany na r y s u n k u 4.2. W tym'
m odelu w szyscy uczestnicy są rów nopraw ni, nie m a w yróżnionego żadnego cen-1'
tralnego węzła. D zięki tem u m odel ten je st bardziej odporny na aw arie niż model.'
klient-serw er. W m odelu k lient-serw er w yłączenie centralnego serw era uniemożliw
w ia jak ąk o lw iek dalszą kom unikację. Pierw otnie Internet miał być siecią wojskową;?
a potem akadem icką, odporną na aw arie pojedynczych kom puterów i byl projekto-
Rys. 4.1. Wlodel klient-serwer
Rys. 4.2. Model równy z równym
4 .1. Num er portu
145
wany ja k o sieć rów nopraw nych węzłów . Jednak postępująca kom ercjalizacja sieci
spraw ia, że obecnie w iększość usług oferow anych w Internecie opiera się na m o­
delu klient-serw er.
Z punktu w idzenia program isty m odel klient-serw er je st bardzo ważny rów nież dla­
tego, że aplikacje działające w m odelu rów ny z rów nym używ ają w w arstw ie trans­
portow ej m odelu klient-serw er. T ransport kom unikatów m iędzy dw om a instancjam i
aplikacji odbyw a się zaw sze w m odelu klient-serw er. W danym m om encie jedna
instancja pełni rolę klienta, a druga serw era. R óżnica w stosunku do czystego m o­
delu klient-serw er je st taka, że aplikacja m oże dow olnie często zm ieniać pełnioną
funkcję. Ponadto ta sam a instancja aplikacji m oże w stosunku do jednej instancji
odgryw ać rolę klienta, a w stosunku do innej rolę serw era. Taka aplikacja, pełniąca
w sieci obie funkcje, je st po angielsku określana term inem servent. Termin ten po­
wstał z połączenia dw óch angielskich term inów - początkow ej części słow a server
z końcow ą częścią słow a client. Jak w przypadku serw era i klienta, servent może
też. oznaczać w ęzeł, na którym działa taka aplikacja.
N ależy przypom nieć, że rzeczow nik klient w znaczeniu inform atycznym przyjm uje
w m ianow niku i bierniku liczby m nogiej form ę klienty. W tym znaczeniu odm ienia
się tak sam o ja k rzeczow nik pilot, oznaczający urządzenie do zdalnego sterow ania.
Numer portu
A dres IP identyfikuje jednoznacznie interfejs sieciow y, a dzięki tem u rów nież w ę­
zeł sieci. N atom iast w rzeczyw istości to nie w ęzły sieci kom unikują się ze sobą,
a aplikacje uruchom ione w tych w ęzłach. D latego potrzebny je st dodatkow y po­
ziom adresow ania, um ożliw iający w skazanie aplikacji, która w ysyła dane i do
której te dane są skierow ane. Protokoły transportow e intersieci, czyli T C P i UDP,
używ ają w tym celu portów. P ort je s t abstrakcyjnym końcem kom unikacji. Porty
są num erow ane liczbam i całkow itym i od 1 do 65 535. N um er portu m ożna więc
zapisać ja k o liczbę 16-bitową. K lient, który inicjuje kom unikację z serw erem , może
w ybrać dow olny num er portu. Serw er, aby m ożna się było z nim skom unikow ać,
musi nasłuchiw ać na porcie o pow szechnie znanym num erze. D latego num er portu,
na którym nasłuchuje serwer, identyfikuje też usługę św iadczoną przez ten serw er
i używ any przez niego protokół. A ktualna lista przydzielonych num erów portów
znajduje się pod adresem http://w w w .iana.org/assignm ents/port-num bers.
W ta b e li 4.1 zam ieszczone są najpopularniejsze usługi internetow e w raz z przy­
dzielonym im num erem portu i używ anym protokołem transportow ym . Krótki opis
usługi w ym aga kilku w yjaśnień. W FT P (ang. File Transfer Protocol) serw er na­
słuchuje na porcie 21, ale to połączenie je s t używ ane tylko do przesyłania poleceń.
W celu przesiania pliku budow ane je s t oddzielne połączenie m iędzy klientem a ser­
w erem . W trybie aktyw nym serw er inicjuje takie połączenie z portu 20 na uzgod­
niony w cześniej port klienta. W trybie pasyw nym połączenie, którym będzie prze­
syłany plik, inicjuje klient. W niektórych protokołach, np. DHCP, rów nież klient
m usi nasłuchiw ać odpow iedzi od serw era na porcie, którego num er je st pow szech­
nie znany. W pozostałych przypadkach (patrz tabela 4.1) podany je s t num er portu,
na którym serw er odbiera kom unikaty od klienta.
14 6
TCP, w przeciw ieństw ie do IP, je s t protokołem połączeniow ym . Z anim rozpocz­
nie się przesyłanie danych, trzeba zbudow ać połączenie. B udow anie połączenia
je st asym etryczne. Jedna strona (zw ykle nazyw ana serw erem ) w ykonuje otw arcie
pasyw ne, czyli nasłuchuje na w ybranym porcie. D ruga strona (zw ykle nazyw ana
klientem ) w ykonuje otw arcie aktyw ne, czyli inicjuje połączenie z aplikacją, któ­
ra w ykonała w cześniej otw arcie pasyw ne. D la każdego zestaw ionego połączenia
oprogram ow anie stosu T C P /IP utrzym uje w pam ięci pew ne struktury danych, m.in.
bufor nadaw czy i odbiorczy. Z w olnienie tych struktur następuje po zam knięciu po­
łączenia.
Tab. 4.1. Niektóre powszechnie znane numery portów i przyporządkowane im usługi
Num er
portu
Protokół
transportowy
Protokół w arstw y
aplikacji
20
TCP
FTP
Przesyłanie plików
21
TCP
FTP
Przesyłanie plików
Królkl opis usługi
.
22
TCP
SSH
Zdalny terminal, transmisja szyfrowana
7$
23
TCP
TELNET
Zdalny terminal, transmisja nieszyfrowana
"71
25
TCP
SMTP
Wysyłanie poczty elektronicznej
53
UDP
DNS
Tłumaczenie adresów domenowych na adresy IP i er: ■ u
wrotnie
67
UDP
DHCP
Konfigurowanie ustawień sieciowych, port serwera
68
UDP
DHCP
Konfigurowanie ustawień sieciowych, port klienta
69
UDP
TFTP
Prosty protokół przesyłania plików
T C P korzysta z zaw odnego dostarczania oferow anego przez IP. Segm enty T C P są
k apsulkow ane w datagram ach IP. Ż eby zapew nić, że w szystkie dane dotrą do od­
biorcy, T C P potw ierdza otrzym anie danych i retransm ituje te segm enty, które nie
zostały potw ierdzone przez określony czas. W celu w yznaczenia czasu, po którym
m a nastąpić retransm isja (RTO, ang. retransm ission tim eout), T C P estym uje średni
czas od w ysiania segm entu do otrzym ania potw ierdzenia jeg o odbioru (ang. SRTT
- sm o o th ed round trip tim e) i w ariancję tego czasu (RTTVAR, ang. round trip time
variation). Do pom iaru brane są tylko czasy dla segm entów , które nie były retransm itow ane, gdyż dla retransm itow anego segm entu nie m ożna stw ierdzić, której
z w ysianych jeg o kopii dotyczy odebrane potw ierdzenie. Czas, po którego upływ ie
następuje retransm isja, je s t obliczany ze w zoru
iąi
^
TT
80
TCP
HTTP
Przesyłanie stron w w w
■} '<
110
TCP
POP3
Odbieranie poczty elektronicznej
'ą
123
UDP
NTR SNTP
Synchronizowanie czasu
K om unikaty w ym ieniane m iędzy klientem a serw erem są identyfikow ane za
m ocą czterech w artości: adres IP klienta, num er portu klienta, adres IP serwcraj
num er portu serw era. D zięki tem u w iele klientów działających w jed n y m w ęźle s
ci m oże kom unikow ać się rów nocześnie z tym sam ym serw erem . M im o że wtcciyJ
w szystkie klienty używ ają tego sam ego adresu IP, m ożna je rozróżnić za pomocy
num eru portu. U żyw anie w intersieciach ja k o adresu źródłow ego lub docełowegój
łącznie adresu IP i num eru portu zaciera nieco granicę m iędzy w arstw ą sieciow^
a transportow ą.
4.2.
4.2.1.
RTO = SRTT + m ax(G , 4 • RTTVAR),
gdzie G (ang. granularity) je s t rozdzielczością zegara używ anego do pom iaru cza­
su. Jako początkow ą w artość RTO, zanim w yznaczy się estym aty SR TT i RTTVAR,
przyjm uje się 3 sekundy. Szczegóły są opisane w R FC 2988. D zięki dynam iczne­
mu w yznaczaniu czasu retransm isji T C P skutecznie adaptuje się do sieci o różnych
opóźnieniach transm isji.
TCP
T C P (ang. T ransm ission C ontrol P rotocol) je s t głów nym protokołem transporto
w ym inlersieci, co w yraża się w pow szechnie stosow anej nazw ie stosu protokołów
intersieci, czyli TCP/IP. P odstaw ow a w ersja T C P je s t opisana w RFC 793. TCP1;
przyjęto jak o standard intersieci S T D 7.
Podstawowe własności
, /1.'.
T C P je st protokołem strum ieniow ym . Przesyłany strum ień danych nie ma żadnej ¡»I
struktury. O znacza to, że jeśli ap likacja przekazuje dane do w ysiania w jakichś por-'1
cjach, to nie ma gw arancji, że aplikacja, która te dane odbiera, odczytu je w takich;.!
sam ych porcjach. T C P przesyła sw oje dane w datagram ach IP. IP je st protokoienhí
pakietow ym , więc T C P musi dzielić przesyłany strum ień danych na porcje, nazyV^
w ane segm entam i, m ieszczące się w polu danych datagram ów IP. T C P optymalizuje#!
rozm iar segm entów danych, aby m aksym alnie w ykorzystać przepustow ość sieciAjg
T C P stara się najlepiej w ykorzystać M TU sieci i dzieli w ysyłany strum ień danych:'^
na segm enty o najw iększym m ożliw ym rozm iarze, który nie spow oduje jeszc/e ■
fragm entacji datagram ów IP. W tym celu T C P buforuje przesyłane dane. Dane.ii
przekazyw ane do w ysiania przez aplikację m ogą być łączone w w iększe porcje lub.;
dzielone na m niejsze kaw ałki.
147
4.2. TCP
4. Programowanie w modelu klient-seĄm,
T C P um ożliw ia kom unikację dw ukierunkow ą. D ane m ogą być transm itow ane je d ­
nocześnie w obu kierunkach połączenia. Segm ent przesyłany w jed n y m kierunku
zaw iera potw ierdzenie danych w ysłanych w przeciw nym kierunku.
4.2.2.
Nagłówek
S egm ent T C P składa się z nagłów ka i następującego po nim pola danych, przy
czym pole danych jest opcjonalne - m oże go nie być, jeśli nie ma żadnych da­
nych do w ysiania. C ały segm ent T C P je s t przesyłany w polu danych datagram u IP.
Form at podstaw ow ej w ersji nagłów ka je s t przedstaw iony na ry s u n k u 4.3. Pierw sze
dw a pola, zgodnie z ich nazw am i, zaw ierają num er portu nadaw cy i odbiorcy. Pole
DL. N A G Ł. zaw iera długość nagłów ka w stów ach 32-bilow ych. Specyfikacja okre­
śla, że pole to zaw iera przesunięcie części z danym i w ew nątrz segm entu (ang. data
offset). N agłów ek m oże być rozszerzony o pola zaw ierające dodatkow e opcje, ale
zaw sze musi m ieć długość, która je s t w ielokrotnością 4 oktetów. P odstaw ow a w er­
sja nagłów ka m a 20 oktetów, w ięc w tedy pole DL. N A G Ł. m a w artość 5. Bity,
które zarezerw ow ano do przyszłego w ykorzystania, pow inny być rów ne zeru.
P ole SU M A K O N TR O LN A służy zapew nieniu integralności segm entu. Jest obli­
czana na podstaw ie nagłów ka TCP, pola danych T C P i pseudonagłów ka utw orzo-
148
4. Programowanie w modelu klient-serwe jf-
Tab. 4.2. Znaczniki TCP
NR PORTU NADAWCY
NR PORTU ODBIORCY
Znacznik
Bit
[0:15]
[16:31]
CWR
8
NUMER PORZĄDKOWY
[0:311
NUMER POTWIERDZENIA
zarezerwowane
[5:7]
ZNACZNIKI
[8:15]
SUMA KONTROLNA
[0:15]
ECE
9
Potwierdza informację o przeciążeniu (ang. explicit congestion echo)
URG
10
Przesyłany segment zawiera dane pilne (ang. urgent)
ACK
11
Pole zawierające numer potwierdzenia jest Istotne
ROZMIAR OKNA
[16:31]
PSH
12
Ten segment jest prośbą o wypchnięcie (ang. push) danych. Poinformuj aplikację, że po­
winna przeczytać dane z bufora odbiorczego
WSKAŹNIK DANYCH PILNYCH
[16:31]
RST
13
Natychmiast skasuj połączenie w obu kierunkach
SYN
14
Synchronizuj numer porządkowy. Tylko pierwszy komunikat wystany w danym kierunku
może mieć ustawiony ten bit
FIN
15
Oznacza koniec strumienia danych u nadawcy i początek procedury zamykania połącze­
nia. Każdy kierunek transmisji jest zamykany osobno
[0:31]
DL. NAGL.
[0:4]
Opis
Okno przeciążeniowe zo siato zredukowane (ang. congestion window reduced)
Rys. 4.3. Format nagłówka TCP bez dodatkowych opcji
nego na podstaw ie nagłów ka IP. Pseudonagłów ek składa się z adresów IP nadawcyS
i odbiorcy, pola PR O T O K Ó Ł z nagłów ka dalagram u IP oraz pola zaw ierającego'!
obliczoną długość całkow itą segm entu TCP. Po szczegóły dotyczące dodatkowych’®;
opcji nagłów ka T C P i sposobu liczenia sum y kontrolnej odsyłam do RFC 793.it
Zauw ażm y, że w nagłów ku nie m a inform acji o dlugos'ci pola danych. Ta długość’;!
musi być obliczona. Od całkow itej długości datagram u IP trzeba odjąć długości'
nagłów ków IP i TCP. Sposób liczenia długości pola danych segm entu T C P i sumyf
kontrolnej T C P są kolejnym i przejaw am i ścisłego zw iązku protokołów IP i TCP,1,
oraz braku w intersieciach ostrej granicy m iędzy w arstw ą sieciow ą a transportową,1?
IP nie gw arantuje, że datagram y d o trą do odbiorcy w tej sam ej kolejności, w kuuej
zostały w ysłane. TCP, aby zapew nić, że dane dotrą do odbiorcy w e w łaściw ej kolej-;;
ności, num eruje przesyłane oktety m odulo 2 32 . N um eracja je st prow adzona osobno?;?
dla każdego kierunku transm isji. Pole N U M E R PO R Z Ą D K O W Y (ang. sequence:|j
num ber) zaw iera num er pierw szego oktetu w ysyłanego w bieżącym segm encie’^
Pole N U M E R P O T W IE R D Z E N IA (ang. acknow ledgm ent nu m b er) zaw iera numery
następnego oczekiw anego oktetu. Innym i słowy, potw ierdza popraw ne odebranie.?
oktetów o poprzednich num erach. Pole to je st w ażne tylko wtedy, gdy ustawio-,£
ny jest znacznik A C K (ang. ackn o w led g m en t), patrz ta b ela 4.2. P ole ROZMIAR?/
O K N A określa ilość m iejsca w buforze odbiorczym , służy do kontroli przepływu,:n
inform uje drugą stronę kom unikacji, ile oktetów danych m oże być odebranych’.':;'
T C P dopasow uje rozm iar okna do szybkości przetw arzania danych przez aplikację??;
Jeśli dane napływ ają szybciej, niż aplikacja je s t w s ta n ie je czytać, b ufor odbiorc/y ’
zapełnia się i T C P w strzym uje drugą stronę kom unikacji, w ysyłając zerow y roz­
m iar okna. W znow ienie przesyłania, czyli zaproponow anie niezerow ego rozmia-'
ru okna nastąpi wtedy, gdy w buforze odbiorczym zrobi się m iejsce na segment?
o m aksym alnym rozm iarze. W ten sposób T C P unika nieefektyw nego przesyłaniu?■■
m ałych porcji danych. P odsum ow ując, odebranie potw ierdzenia i niezerow ego roz­
m iaru okna oznacza, że druga strona kom unikacji oczekuje na oktety o numerach..?!
od N U M E R P O T W IE R D Z E N IA do (N U M ER P O T W IE R D Z E N IA + R O Z M IA R ''
O K N A - 1) m od 2 n .
C zasem zachodzi potrzeba przesłania danych poza głów nym strum ieniem transjJ
m isyjnym , na przykład gdy trzeba przerw ać działanie aplikacji, z którą się komuĄ,
nikujenty. W T C P przew idziano w tym celu m ożliw ość przesiania danych pilny
(ang. urgent). Pole W S K A Ź N IK D A N Y C H PIL N Y C H określa num er oktetu, od
którego w przesyłanym segm encie rozpoczynają się dane pilne. Pole to je st ważne
tylko w tedy, gdy ustaw iony je st znacznik U RG , patrz tabela 4.2. T C P nie okre­
śla dokładnie, jak aplikacja ma być poinform ow ana o odebraniu danych pilnych.
S zczegóły pozostaw iono im plem entatorom stosu. B iblioteka lw IP nie obsługuje
danych pilnych.
Z naczniki przesyłane w nagłów ku T C P są opisane w tabeli 4.2. Pierw otnie w RFC
793 bity num er 8 i 9 w polu znaczników były zarezerw ow ane do przyszłego w y­
korzystania i pow inny mieć w artość 0. W R FC 3168 do obsługi zatorów zdefinio­
w ano now e znaczniki C W R i ECE, które um ieszczono w tych bitach. Nie opisu­
ję ich, gdyż w bibliotece lw IP nie zaim plem entow ano ich obsługi. W yzerow anie
tych bitów zapew nia popraw ną w spółpracę z oprogram ow aniem , które je obsługuje.
U życie pozostałych znaczników w yjaśniam w kolejnych podrozdziałach.
4.2.3.
Otwieranie połączenia
D iagram sekw encji otw ierania połączenia T C P jest przedstaw iony na ry s u n k u 4.4.
W idzim y na nim zaznaczone schem atycznie dw ie instancje biblioteki lwIP. Po lewej
stronie um ieszczone są funkcje klienta, a po praw ej funkcje serw era. Strzałka skie­
row ana od funkcji do biblioteki oznacza, że jest to funkcja biblioteki lwIP w yw ołana
przez klienta lub serwer. Strzałka skierow ana od biblioteki do funkcji oznacza, że
je s t to funkcja zw rotna, w yw ołana przez bibliotekę lwIP. Strzałka z gw iazdką ozna­
cza, że to w yw ołanie je st opcjonalne. Pośrodku, m iędzy instancjam i biblioteki lwIP,
narysow ane są segm enty T C P w ym ieniane m iędzy nimi. D la przejrzystości diagram
nie uw zględnia obsługi błędów, których jed n ak nie w olno ignorow ać. N ależy bez­
w zględnie spraw dzać w artości zw racane przez funkcje i w łaściw ie reagow ać, jeśli
ja k a ś funkcja zakończy się niepow odzeniem . Przykłady klientów i serw erów pre­
zentow ane w następnych rozdziałach obsługują błędy.
B iblioteka lw IP przechow uje inform acje o stanie połączenia T C P w strukturze typu
tc p _ p c b (ang. TCP protocol control błock). K lient rozpoczyna sw oje działanie od
w yw ołania funkcji tcp_new , która przydziela now ą strukturę typu tcp_pcb i zw raca
w skaźnik do niej. W skaźnik ten jest następnie przekazyw any w szystkim funkcjom
obsługującym TCP. Przydzieloną strukturę typu tcp _ p cb nazyw am dalej deskryptorem TCP.
15 0
4. Programowanie w modelu klient-serw eł
Klient
IwIP
Iw/P
pcb « tcp_new{) -->
S erw er
<—
tcp_bind(pcb, addr, port) *->
pcb = tcp_new()
<-- tcp_bind(pcb, addr, port)
tcp_arg(pcb, arg) *->
<—
tcp_err(pcb, conn_err_callback) — >
li3ten_pcb » tcp_listen(pcb)
<-* tcp_arg(listen_pcb, arg)
tcp_rGcv(pcb, recv_callback) *->
<-- tcp_accept (Xisten_pcb, accept_c.i iIbackjf
tcp_sent(pcb, sent_calłback) *->
tcp_poll(pcb, poll_callback, time) *->
tcp_connect(pcb, addr, port,
connect_callback) — >
SYN(/?k)
>
SYN(ns),
connect_callback(arg, pcb, err) <—
ACK(nk +
1)
tcp_recv(pcb, recv_callback) *->
tcp_sent(pcb, 3ent_calłback) *->
tcp_poll(pcb, polł_callback, time) ł->
A CK(ns + 1)
— > accept_callback(arg, conn_pcb, err)
<-* tcp_arg(conn_pcb, conn_arg)
<-- tcp_err(conn_pcb, conn_err_callback)
<-- tcp_recv (conn_pcb, recv__cailback)
<-* tcp_sent(conn_pcb, sent__callback)
< - ‘ tcp_poll (conn_pcb, połl jjallback, tim<’
i
Rys. 4.4. Otwieranie połączenia TCP
K lient w yw ołuje funkcję tc p _ b in d , aby w ybrać adres IP i port, których będzie uży­
wał. O czyw iście m ożna w ybrać tylko adres IP, który został skonfigurow any. Adres ,
1P je s t zaw sze zw iązany z określonym interfejsem sieciow ym . Z atem w ybór adresu
determ inuje też interfejs, przez który będzie odbyw ać się kom unikacja. Jeśli jest
tylko jed en adres IP, to w yw ołanie tej funkcji m ożna pom inąć. K lient m oże wybrać
dow olny port. Jeśli nie w yw ołam y funkcji tc p _ b in d , biblioteka przydzieli kliento­
wi jak iś w olny port.
Za pom ocą funkcji tc p _ a rg m ożna ustaw ić w deskryptorze T C P dodatkow y ar­
gum ent arg , który będzie przekazyw any w szystkim funkcjom obsługującym TCP.
A rgum ent ten najczęściej je s t w skaźnikiem do struktury przechow ującej prywatne
dane klienta. Dla każdego p ołączenia T C P przydzielam y now ą instancję tej struk­
tury. Dzięki tem u za pom ocą w spólnej funkcji zw rotnej m ożna obsługiw ać sym ul­
tanicznie w iele klientów.
Funkcja tcp__err rejestruje funkcję zw rotną c o n n _ e rr _ c a łlb a c k , która będzie wy­
w ołana przez bibliotekę IwIP, gdy w ystąpi ja k iś błąd, np. próba otw arcia połączenia
zakończy się niepow odzeniem lub połączenie zostanie skasow ane. W tej funkcji
zw rotnej trzeba zw olnić całą pam ięć przydzieloną klientow i, a w szczególności .
strukturę przechow ującą pryw atne dane klienta.
Funkcje tc p _ r e c v i tc p _ s e n t rejestrują funkcje zw rotne r e c v _ c a llb a c k i sent
c a llb a c k , które będą w ołane odpow iednio, gdy zostaną odebrane dane lub zostanie
odebrane potw ierdzenie dostarczenia danych. F unkcja tc p p o l l rejestruje funkcję
zw rotną p o ll_ c a łl b a c k , która będzie w yw ołana cyklicznie w ustalonych odstępach
czasu tim e, co um ożliw ia zaim plem entow anie budzika w aplikacji klienta. Funkcje .
4.2. TCP
151
te są opcjonalne i trzeba ich użyć tylko w tedy, gdy potrzebna je s t odpow iednia
funkcja zw rotna. Jeśli klient chce odbierać dane od serw era, to oczyw iście musi
zarejestrow ać funkcję re c v _ c a llb a c k . Te funkcje zw rotne m ożna też zarejestrow ać
później, gdy ju ż zostanie otw arte połączenie.
W łaściw e otw ieranie połączenia przez klienta rozpoczyna się od w yw ołania funkcji
te p c o n n e c t. Jako jej argum enty podaje się adres IP i num er portu serw era oraz ad­
res funkcji zw rotnej c o n n e c t_ c a llb a c k , która zostanie w yw ołana, gdy serw er odpo­
w ie pozytyw nie na prośbę otw arcia połączenia. Funkcja tc p c o n n e c t tylko inicjuje
otw ieranie połączenia i nie czeka na zakończenie procedury otw ierania. O tw arcie
połączenia T C P w ym aga zsynchronizow ania num erów porządkow ych. W tym celu
w ym ieniane są trzy segm enty. R ozpoczyna biblioteka IwIP po stronie klienta, w y­
syłając pierw szy segm ent zaw ierający sam nagłów ek TCP, bez pola danych, z usta­
w ionym znacznikiem SY N i początkow ym num erem porządkow ym nk, nazyw anym
w skrócie segm entem SY N . B iblioteka Iw IP po stronie serw era odpow iada drugim
segm entem , który zaw iera sam nagłów ek T C P z ustaw ionym i znacznikam i SY N
i A CK . Ten drugi segm ent je s t w skrócie nazyw any segm entem SY N +A C K . Za
pom ocą tego segm entu strona serw era proponuje sw ój początkow y num er porząd­
kow y ns i potw ierdza, że oczekuje pierw szego oktetu o num erze n k + 1, um ieszcza­
ją c tę w artość ja k o num er potw ierdzenia. G dy strona klienta odbierze ten segm ent,
w yw ołana je s t funkcja zw rotna c o n n e c t_ c a llb a c k . N a koniec, po zakończeniu tej
funkcji biblioteka Iw IP po stronie klienta za pom ocą trzeciego segm entu potw ier­
dza, że oczekuje pierw szego oktetu o num erze ns + 1, um ieszczając w nagłów ku
T C P tę w artość jako num er potw ierdzenia i ustaw iając znacznik ACK. Ten trzeci
segm ent je s t nazyw any w skrócie segm entem A CK . Od tego m om entu połączenie
je s t otw arte i m ożna przesyłać dane w obu kierunkach. W łaściw ie to klient może
ju ż w ysiać dane w segm encie A C K , kończącym procedurę otw ierania połączenia.
W funkcji c o n n e c t_ c a lIb a c k m ożna opcjonalnie w yw ołać funkcje tcp__recv, tcp__
s e n t i tc p _ p o ll, jeśli odpow iednie funkcje zw rotne nie zostały dotychczas zareje­
strow ane. Jeśli funkcja tc p _ c o n n e c t zw róci w artość ERR_0K i zbudow anie połącze­
nia nie pow iedzie się, czyli nie dotrze praw idłow y segm ent SY N +A C K , to zam iast
funkcji c o n n e c t_ c a llb a c k zostanie w yw ołana funkcja c o n n _ e rr_ c a llb a c k .
Ze w zględów bezpieczeństw a początkow e num ery porządkow e pow inny być w y­
bierane pseudolosow o, aby utrudnić ataki na TCP, czyli np. nieupraw nione w strze­
lenie segm entów w strum ień danych (ang. TC P session hijackitig) lub nieupraw nio­
ne zestaw ienie połączenia (ang. TC P spoofing).
Serw er, podobnie ja k klient, rozpoczyna działanie od w yw ołania funkcji tcp_new,
która przydziela nowy deskryptor TCP. N astępnie za pom ocą funkcji tc p _ b in d ser­
w er w ybiera adres IP i port, na których będzie nasłuchiw ał połączeń od klientów.
Funkcja t c p _ l i s t e n uaktyw nia kolejkę klientów oczekujących na zaakceptow anie
połączenia patrz opis stałej MEMP_NUM_TCP_PCB_LISTEN w pliku Iwiopts.h. Należy
zw rócić uw agę, że funkcja t c p _ l i s t e n przydziela now y deskryptor TCP. U w aga,
to w skaźnik zw rócony przez funkcję te p l i s t e n , a nie w skaźnik zw rócony przez
funkcję te p new, musi być przekazany ja k o argum ent dw óm następnym w ołanym
funkcjom . Funkcja tcp__accept rejestruje funkcję zw rotną a e c e p te d _ c a llb a c k ,
która będzie w yw ołana po zaakceptow aniu połączenia od klienta. Funkcja te p a rg
152
4. Programowanie w modelu klient-serwer
cjach, ja k i aplikacją, która w ysyła dane znak po znaku. N atychm iastow e w ysianie
danych m ożna w ym usić za pom ocą funkcji tc p _ o u tp u t. Biblioteka lw lP w ywołuje
tę funkcję przy okazji obsługi różnych zdarzeń. Jeśli funkcja tc p _ w rite jest w y­
w ołana w ew nątrz jak iejś funkcji zw rotnej, to zw ykle nie trzeba w yw oływ ać funkcji
tc p _ o u tp u t. N atom iast jej w yw ołanie m oże okazać się konieczne, gdy tc p _ w rite
je st w yw ołana spoza biblioteki lwlP.
ustaw ia w deskryptorze T C P argum ent a rg , który zw ykle je s t w skaźnikiem do pryw alnych danych serw era i który będzie przekazyw any funkcji a c c e p te d _ c a llb a c k . i
co um ożliw ia obsługę w ielu serw erów za pom ocą w spólnej funkcji zw rotnej. Każdy 'i
serw er m oże mieć sw oją pryw atną strukturę danych.
Jeśli biblioteka lw lP po stronie serw era zaakceptuje now e połączenie od klienta'
tw orzy dla tego połączenia now y deskryptor T C P i w yw ołuje funkcję zw rotną ac- a
c e p t_ c a llb a c k , której drugim argum entem je st w skaźnik do tego now ego deskryp-j!
tora. Każde połączenie T C P m a sw ój unikalny deskryptor. W funkcji a c c e p t ca'
Ib a c k trzeba zarejestrow ać funkcje zw rotne, które będą w ołane dla tego nowego.!*
połączenia. N ajpierw je d n a k funkcja tc p _ a r g ustaw ia w deskryptorze T C P argu- f
rnent conn_arg, który będzie przekazyw any funkcjom zw rotnym . A rgum ent ten jest
zw ykle w skaźnikiem do alokow anej w ew nątrz funkcji a c c e p t_ c a llb a c k struktury:
zaw ierającej pryw atne dane zw iązane z połączeniem , co um ożliw ia obsługę wie­
lu połączeń za pom ocą w spólnych funkcji zw rotnych. Podobnie ja k w przypadku i
klienta, funkcja t c p _ e r r rejestruje funkcję zw rotną c o n n _ e rr _ c a llb a c k wołaną,
gdy w ystąpi błąd. Funkcje tc p _ r e c v i tc p _ s e n t rejestrują funkcje zw rotne recv ■
c a llb a c k i s e n t_ c a llb a c k w ołane odpow iednio, gdy zostaną odebrane dane lub'
zostanie odebrane potw ierdzenie dostarczenia danych. F unkcja tc p p o l l rejestruje
cyklicznie w ołaną funkcję zw rotną p o ll _ c a ll b a c k , co um ożliw ia zaim plem ento­
w anie budzika w aplikacji serw era.
4.2.4.
Strona B odbiera dane za pom ocą funkcji zw rotnej re c v _ c a lłb a c k . W ew nątrz tej
funkcji po przetw orzeniu odebranych danych trzeba poinform ow ać o tym bibliotekę
lw lP za pom ocą funkcji tc p _ re c v e d , która oblicza now y rozm iar okna odbiorczego
po stronie B. Jeśli strona A zarejestrow ała funkcję zw rotną s e n t_ c a llb a c k , to za
jej pom ocą zostanie poinform ow ana o otrzym aniu od strony B potw ierdzenia ode­
brania danych.
T C P przesyła dane łącznie z potw ierdzeniem otrzym ania danych przesianych w dru­
gim kierunku. Strona A, w ysyłając segm ent danych do B, rów nocześnie inform uje
B o num erze oktetu, którego oczekuje od B, ustaw iając w nagłów ku T C P znacznik
A C K i odpow iedni num eru potw ierdzenia. Strona B po otrzym aniu od A segm entu
danych potw ierdza go i jednocześnie w tym sam ym segm encie w ysyła do A dane,
które czekają na w ysianie w buforze nadaw czym B. N ie każdy segm ent musi być
potw ierdzony. Specyfikcja T C P nakazuje potw ierdzanie przynajm niej co drugiego
segm entu. Zauw ażm y, że potw ierdzenie danych otrzym anych w jak im ś segm encie
oznacza też polw ierdzęnie w szystkich danych z poprzednich segm entów.
Przesyłanie danych
Sekw encja zdarzeń tow arzysząca przesyłaniu danych za pom ocą T C P przedstawio-"
na je s t na ry s u n k u 4.5. P oniew aż w ym iana danych jest sym etryczna, kom unikujące ,
się strony są oznaczone literam i A i B. W konkretnym przypadku A je s t klientem,
a B serw erem albo odw rotnie - A je s t serw erem , a B klientem .
Strona A przekazuje dane do w ysiania za pom ocą funkcji tc p _ w rlte . T C P tyl-lk
ko pierw szą porcję danych w
now o otw artym połączeniu w ysyła natychmiast, i:
N atom iast z w ysianiem kolejnych porcji czeka, aż uzbiera się dostatecznie dużo :
danych, aby w ypełnić segm ent o m aksym alnym rozm iarze. Ponadto T C P wysyła
zgrom adzone w buforze nadaw czym dane, niezależnie od ich rozm iaru, rów nie/
wtedy, gdy otrzym a potw ierdzenie o trzym ania poprzednio w ysianych danych. Taka"
strategia zm niejsza liczbę przesyłanych segm entów i narzut zw iązany z wysyłaniem.,
m ałych porcji danych, unikając jed n o cz eśn ie sytuacji, w której dane czekałyby zbyt’,:
długo w buforze nadaw czym . A plikacja m oże nigdy nie w staw ić do w ysiania w y -.
starczająco dużej porcji danych, aby zapełnić segm ent o m aksym alnym rozmiarze
T C P dobrze w spółpracuje zarów no z aplikacją, która w ysyła dane w dużych por1::
i ’1:
A
lw lP
tcp_write(pcb, data, len, flags) — >
lw lP
sent_callback(arg, pcb, len) <-*
Rys. 4.5. Przesyłanie danych TCP
Zamykanie połączenia
Sekw encja zdarzeń podczas zw ykłego zam ykania połączenia T C P jest pokazana na
ry s u n k u 4.6. N atom iast na ry s u n k u 4.7 przedstaw ione jest aw aryjne zam ykanie
(kasow anie) połączenia TCP. K ażda ze stron m oże zainicjow ać zam knięcie połącze­
nia. D latego na tych diagram ach strony kom unikacji są oznaczone, ja k poprzednio,
literam i A i B.
Strona A inicjuje zw ykle zam knięcie połączenia, w yw ołując funkcję tc p _ c lo s e . Po
w yw ołaniu tej funkcji do B je s t w ysyłany segm ent FIN, czyli segm ent, w którego
nagłów ku T C P je s t ustaw iony znacznik FIN , co oznacza, że rozpoczyna się zam y­
kanie połączenia w kierunku od A do B i strona A nie będzie ju ż w ysyłać do B żad­
nych danych. N atom iast strona A nadal m oże odbierać dane od B i po w yw ołaniu
przez A funkcji tc p _ c lo s e biblioteka lw lP m oże w yw ołać funkcję zw rotną recv_
c a llb a c k , jeśli pojaw ią się jak ieś now e dane od B. Jeśli nie chcem y otrzym yw ać
A
RN
callback(arg, pcb, pbuf, err) <-*
[A C K ] data
................>
— > recv_całlback(arg, pcb, pbuf, er ii
1
<
...............
--------- >
<—
<
---------
<
---------
FIN
--------- >
tcp_recved(pcb, len)
Rys. 4.6. Zamykanie połączenia TCP
— > recv_callback(arg
ACK
ACK
ACK [data]
B
lwlP
lwlP
tcp_close(pcb) -->
B
tcp_write(pcb, data, len, flags) — >
tcp_outpiłt (pcb) *->
4.2.5.
<—
tcp_close(pcb)
154
4. Programowanie w modelu klient-seńW
A
Iw IP
IwIP
B
RST
tcp abort{pcb) — >
— > conn_err_callback(arg,
void
tcp_abort(struct tcp_pcb *pcb);
conn_err_callback(arg, err) <—
Rys. 4.7. Awaryjne zamykanie połączenia TCP
danych po w yw ołaniu tc p _ c lo s e , trzeba w cześniej w yrejestrow ać funkcję zwr<
za pom ocą funkcji tc p _ re c v , podając NULL ja k o adres nowej funkcji zwrotnej.
Strona B, otrzym aw szy znacznik FIN , odsyła segm ent ze znacznikiem A ''” "
A plikacja po stronie B o zam knięciu połączenia je st inform ow ana dopiero po
czytaniu w szystkicli danych z bufora odbiorczego. O dbyw a się to za pom ocą koś
lejnego w yw ołania funkcji zw rotnej r e c v _ c a llb a c k , w której w skaźnik do buforai
z odebranym i danym i m a w artość NULL. W ew nątrz tej funkcji zw rotnej strona 13
zw ykle zam yka połączenie w kierunku od B do A, w yw ołując funkcję tc p clo r c,
co inicjuje w ysłanie do A segm entu ze znacznikiem FIN. Strona A, po otrzyma^
niu takiego segm entu, odsyła segm ent ze znacznikiem A CK . To kończy procedurę;
zw ykłego zam ykania połączenia. O program ow anie T C P po obu stronach zwalnia’
zasoby biblioteki IwIP zw iązane z tym połączeniem , czyli strukturę typu tc p buf;
oraz bufor nadaw czy i odbiorczy.
Połączenie m ożna też zam knąć aw aryjnie (skasow ać) za pom ocą funkcji tcp_aboi t.
W tedy w szelkie dane nieodczytane z buforów odbiorczych i czekające na wysłanie
w buforach nadaw czycli zostają utracone. Strona inicjująca aw aryjne zamknięcie
w ysyła segm ent RST (ang. reset), czyli segm ent z ustaw ionym w nagłów ku znaczki
nikiem RST. Segm ent len nie w ym aga potw ierdzenia. Funkcja tc p _ a b o r t zwalnia;
zasoby biblioteki IwIP zw iązane z połączeniem . A by rów nież aplikacja m ogła zwol­
nić sw oje zasoby, biblioteka IwIP w yw ołuje bo obu stronach skasow anego połącze­
nia funkcję zw rotną c o n n _ e rr _ c a llb a c k .
4.2.6.
Funkcje biblioteczne
Teraz opiszę bardziej szczegółow o i w kolejności alfabetycznej poszczególne funk­
cje biblioteki iw IP w ykorzystyw ane przy pisaniu aplikacji kom unikujących się z.i
pom ocą TCP.
void
tcp_abandon(struct tcp_pcb *pcb,
int reset);
F unkcja tcp_abandon kasuje połączenie i zw alnia deskryptor TCP. Pierw szym ar­
gum entem tej funkcji je s t w skaźnik pcb do deskryptora T C P opisującego kasowane
połączenie. Jeśli drugi argum ent r e s e t je st różny od zera, to w ysyłany je st seg­
m ent RST. W yw ołanie funkcji tcp _ ab a n d o n z argum entem r e s e t rów nym zeru nic
pow oduje żadnej kom unikacji sieciow ej. Jest to przydatne przy obsłudze błędów,
gdy trzeba zw olnić deskryptor TCP, a połączenie nie zostało jeszcze otw arte. Przed
zakończeniem tej funkcji w yw ołana je s t funkcja zw rotna c o n n _ e rr_ c a llb a c k , w
której należy zw olnić przydzielone przez aplikację zasoby zw iązane z kasowanym
połączeniem .
F unkcja tc p a b o r t kasuje połączenie i zw alnia deskryptor TCP. A rgum ent pcb jest
w skaźnikiem do deskryptora T C P opisującego kasow ane połączenie. A ktualna im ­
plem entacja biblioteki IwIP definiuje tę funkcję jak o makro:
idefine tcp_abort(pcb) tcp_abandon((pcb), 2)
void
tcp accept(struct tcp pcb *pcb,
err t (* accept callback)(void *arg,
struct tcp pcb *conn_pcb,
err t err));
—
Funkcja tc p _ a c c e p t rejestruje funkcję zw rotną, którą biblioteka IwIP w oła, gdy
w stanie pasyw nego nasłuchiw ania zostanie odebrane now e połączenie. Pierw szym
argum entem tej funkcji je s t w skaźnik pcb do deskryptora T C P przydzielonego za
pom ocą funkcji t c p _ l i s t e n . D rugi argum ent a c c e p t_ _ callb ack je st adresem reje­
strow anej funkcji zw rotnej.
void
tcp_accepted(struct tcp_pcb *pcb|;
Funkcja tc p _ a c c e p te d inform uje bibliotekę IwIP, że należy zaakceptow ać odebrane
połączenie. Funkcja ta pow inna być w yw ołana w ew nątrz funkcji zw rotnej a c c e p t_
c a llb a c k . A rgum ent pcb je st w skaźnikiem do deskryptora T C P zw róconego przez
funkcję tc p l i s t e n , a nie w skaźnikiem do deskryptora T C P now ego połączenia,
przekazanym jak o drugi argum ent funkcji a c c e p t_ c a lłb a c k , co bardzo kom plikuje
logikę program u. N a szczęście funkcja ta m usi być w yw ołana tylko wtedy, gdy do
nasłuchiw ania przychodzących połączeń używ am y kolejki o zm iennym rozm iarze,
czyli gdy w pliku Iw ipopts.h została zdefiniow ana stała TC P_LISTEN_BACKLOG o w ar­
tości 1. W m ałych aplikacjach m ikrokontrolerow ych nie w ydaje się to potrzebne.
D latego proponuję używ anie kolejki o stałym rozm iarze zdefiniow anym w pliku
Iw ipopts.h za pom ocą stałej MEMP_NUM_TCP_PCB_LISTEN. A ktualna im plem entacja
biblioteki Iw IP definiuje tę funkcję ja k o m akro, które je s t puste, jeśli w pliku Iw i­
p o pts.h nie zdefiniujem y stałej TCP_LISTEN_BACKLOG.
void
tcp_arg(struct tcp_pcb *pcb,
void *arg);
Funkcja tc p a rg przypisuje do deskryptora T C P w skaźnik, który będzie przeka­
zyw any funkcjom zw rotnym , w ołanym z tym deskryptorem . Pierw szym argum en­
tem tej funkcji je st w skaźnik pcb do deskryptora TCP. D rugim argum entem jest
w skaźnik a rg , który m oże być w dow olny sposób w ykorzystyw any przez aplika­
cję. N ajczęściej je s t to w skaźnik do struktury przechow ującej stan kom unikacji. Za
przydzielenie i zw olnienie pam ięci adresow anej tym w skaźnikiem odpow iedzialna
je st aplikacja.
156
4.2. TCP
4. Programowanie w modelu klient-serweM
err_t
tcp_bind(struct tcp_pcb ‘
pcb,
addr,
struct ip_addr ‘
u!6 t port);
§
Funkcja tc p _ b in d w iąże deskryptor T C P z lokalnym adresem IP i portem . P ie rw v \ mi®
argum entem tej funkcji je s t w skaźnik pcb do deskryptora TCP. D rugim argumenteijtff
jest w skaźnik a d d r do struktury zaw ierającej adres IP. Jeśli argum ent ten m a wartości
IP_ADDR_ANY, deskryptor je st w iązany ze w szystkim i skonfigurow anym i w węźla
adresam i IP. Jest to szczególnie przydatne, gdy w ęzeł m a w iele interfejsów siecio-i
wych (co oznacza, że ma też w iele adresów IP) i chcem y uruchom ić serwer, któryś
będzie odbierał połączenia na w szystkich interfejsach. Trzeci argum ent p o r t jest'f
num erem portu, który ma być użyty. Jeśli argum ent ten m a w artość zero, biblioteka"
lw IP przydzieli dow olny niezajęty port. Ten argum ent m a zw ykle w artość zero, gdyj
urucham iam y klienta, gdyż w tedy num er portu je s t nieistotny. D la serw era zwykle*
podaje się w artość niezerow ą, g dyż serw er m usi nasłuchiw ać na pow szechnie zna-'
nym porcie. Funkcja zw raca ERR_OK, gdy zakończyła się sukcesem , lub ERR USEji
gdy nie m ożna użyć podanych w artości, np. żądany port je s t zajęty.
err_t
tcp_close(struct tcp^pcb 'pcb);
Funkcja tc p _ c lo s e inicjuje zam ykanie połączenia i zw alnianie deskryptora TCP;
A rgum ent pcb jest w skaźnikiem d o deskryptora T C P opisującego zam ykane połą­
czenie. D eskryptor je s t utrzym yw any przez bibliotekę lw IP jeszcze przez pewien
czas i jest zw alniany dopiero po zakończeniu procedury zam ykania połączenia, ale
po w yw ołaniu tej funkcji aplikacja pow inna przestać go używ ać. Jedynym wyjął,
kiem jest sytuacja, gdy w tym połączeniu są jeszcze ja k ie ś dane do przeczytania
i biblioteka lw IP przekaże aplikacji w skaźnik do tego deskryptora w funkcji zwrot­
nej re c v _ c a llb a c k . F unkcja zw raca ERR_OK przy popraw nym zakończeniu lub kod ■ f
błędu, gdy w ystąpił problem , np. brakuje pam ięci, aby w ysiać segm ent FIN. Jeśli
funkcja ta kończy się niepow odzeniem , deskryptor T C P nie je st zwalniany.
err t
tcp connect(struct tcp pcb *pcb,
struct ip__addr *addr,
u!6 t port,
err t {* connect callback)(void *arg,
struct tcpjpcb *pcb,
err t err));
—
1
#1
157
m iast kończy działanie, zw racając ERR_OK, gdy tylko uda się w ysłać segm ent SYN
rozpoczynający otw ieranie połączenia. Jeśli w ysłanie segm entu SY N nie pow iodło
się, funkcja zw raca kod błędu inform ujący o przyczynie niepow odzenia.
void
tcp err(struct tcp pcb *pcb,
void (* conn err collback)(void *arg,
err t err));
Funkcja t c p _ e r r rejestruje funkcję zw rotną w ołaną przez bibliotekę lwIP, gdy połą­
czenie zostanie skasow ane. Pow odem skasow ania połączenia może być na przykład
otrzym anie segm entu RST, w yw ołanie funkcji tcp_abandon, tc p _ a b o r t łub brak
pam ięci. Pierw szym argum entem tej funkcji je s t w skaźnik pcb do deskryptora TCP.
D rugi argum ent c o n n _ e rr_ c o llb a c k je s t adresem rejestrow anej funkcji zw rotnej.
struct tcp_pcb *
tcp^listen(struct tcp_pcb *pcb);
Funkcja t c p _ l i s t e n inicjuje pasyw ne otw arcie, czyli nasłuchiw anie połączeń TCP.
A rgum ent pcb je s t w skaźnikiem do deskryptora TCP, który m a być użyty. Funkcja
zw raca now y deskryptor T C P i zw alnia deskryptor przekazany jako argum ent. Takie
d ziw ne zachow anie biblioteki lw IP w ynika z tego, że deskryptor potrzebny do na­
słuchiw ania połączeń zajm uje mniej pam ięci. D eskryptor przeznaczony do pasyw ­
nego nasłuchiw ania połączeń m oże być używ any przez serwer, ale nie m oże być
używ any przez klienta - nie m ożna za je g o pom ocą zainicjow ać aktyw nego otw ar­
cia połączenia. Jeśli nie udało się utw orzyć now ego deskryptora, funkcja zw raca
NULL. A ktualna im plem entacja biblioteki lw IP definiuje tę funkcję jak o makro:
Idef ine tcp_listen (pcb) tcp_listen_with_backlog (pcb, 255)
struct tcp__pcb *
tcp__listen_with_backiog (struct tcp_pcb *pcb,
u8_t backlog);
F unkcja tc p _ lis te n _ w ith _ _ b a c k lo g działa analogicznie ja k funkcja t c p _ ł i s t e n ,
ale ogranicza rozm iar kolejki oczekujących połączeń do w artości podanej jak o dru­
gi argum ent b ack lo g . A by móc używ ać tej funkcjonalności, trzeba w pliku Iwip o pts.h zdefiniow ać stałą T C P _ L I S TEN_BACKLOG o w artości 1.
m
struct tcp_pcb *
tcp__new(void);
>
■
Funkcja tc p _ c o n n e c t inicjuje aktyw ne otw arcie połączenia i rejestruje funkcję : '{'r ■
zw rotną, którą biblioteka lw IP w yw oła, gdy połączenie zostanie otw arte. Pierwszym mm
argum entem tej funkcji je st w skaźnik pcb do deskryptora TCP, który ma być użyty
do otw arcia połączenia. D rugim argum entem je s t w skaźnik a d d r do struktury za­
w ierającej adres IP, z którym chcem y się połączyć. Trzeci argum ent p o r t je s t nu­
m erem portu, z którym chcem y się połączyć. C zw arty argum ent c o n n e c t_ c a llb a c ;i
je st adresem funkcji zw rotnej, która będzie w yw ołana, gdy zostanie odebrany seg­
m ent SY N +A C K . F unkcja tc p _ c o n n e c t nie czeka na otw arcie połączenia i natych-.
Funkcja tcp_new przydziela nowy deskryptor TCP. Z w raca w skaźnik do now ego
deskryptora lub NULL, gdy nie udało się przydzielić now ego deskryptora.
err__t
tcp__output (struct tcp_pcb *pcb);
F unkcja tc p _ o u tp u t w ym usza w ysłanie segm entów czekających w buforze nadaw ­
czym . A rgum ent pcb je s t w skaźnikiem do deskryptora T C P opisującego połączenie,
przez które dane m ają być w ysiane. Funkcja zw raca ERR_OK, gdy w ysianie pow iod-
158
4. P rogram ow an ie w m odelu klient-seiĘ
io się lub nie m a nic do w ysiania. W przeciw nym przypadku zw raca właściwy ko
błędu. Funkcja ta je st używ ana w ew nątrz biblioteki IwlP. A plikacja nie m u si.
w yw oływ ać, gdy funkcja tc p _ w r ite je st w yw ołana w ew nątrz obsługi jakiegoś zd'i'
rżenia biblioteki IwlP, czyli np. w ew nątrz jak ie jś funkcji zw rotnej.
i
void
top_poll(struct tcp_pcb *pcb,
err_t {* poll_callback)(void *arg,
struct tcp_pcb 'pcb),
u8_t time);
Funkcja tc p _ p o ll rejestruje w ołaną cyklicznie funkcję zw rotną. Pierw szym argijf
m entem tej funkcji je s t w skaźnik pcb do deskryptora TCP. D rugi argum ent p o l$
c a llb a c k je s t adresem funkcji zw rotnej. Trzeci argum ent tim e określa interwał cząii
sow y w yw ołania funkcji zw rotnej. Interw al ten wynosi
4.2. TCP
argum entem tej funkcji je s t w skaźnik pcb do deskryptora TCP. D rugi argum ent
s e n t_ c a llb a c k je s t adresem rejestrow anej funkcji zw rotnej.
ul6_t
tcp sndbuf (struct tcp__pcb *pcb);
Funkcja tc p _ s n d b u f zw raca liczbę bajtów, które m ogą być w staw ione do bufora
nadaw czego. Próba w ysłania w iększej porcji danych za pom ocą funkcji t c p w r i t e zakończy się niepow odzeniem . A rgum ent pcb je st w skaźnikiem do deskryptora
T C P opisującego połączenie, przez które dane m ają być w ysiane. A ktualna im ple­
m entacja biblioteki Iw lP definiuje tę funkcję ja k o makro.
err_t
tcp_write(struct tcp_pcb *pcb,
const void *data,
ul6_t len,
u8_t flags);
2 • time • TCP_TMR_INTERVAL,
gdzie TCP_TMR_INTERVAL je s t interw alem czasow ym w yw ołania budzika T C P w i
lisekundach. Standardow o budzik ten je s t w ołany co 250 ms. Z atem funkcja zv
na p o łl _ c a ll b a c k je s t w yw ołana co tim e /2 s.
void
tcp_recv(struct tcp_pcb *pcb,
err_t {* recv_callback)(void *arg,
struct tcp_pcb *pcb,
struct pbuf *p,
err t err));
i.
Funkcja tcp__recv rejestruje funkcję zw rotną, którą biblioteka Iw lP w ola, aby pi za­
kazać aplikacji dane odebrane w połączeniu TCP. Pierw szym argum entem tej funk­
cji je s t w skaźnik pcb do deskryptora TCP. D rugi argum ent r e c v _ c a llb a c k jest adv
resem rejestrow anej funkcji zw rotnej.
void
tcp_recved(struct tcp_pcb rpcb,
ui6 t len);
Funkcja tc p re c v e d inform uje bibliotekę IwlP, że aplikacja przetw orzyła otrzymane dane i je st gotow a na otrzym anie kolejnej porcji danych. P ierw szym argumentem iii
tej funkcji jest w skaźnik pcb do deskryptora T C P opisującego połączenie, z kt<
otrzym ano dane. Drugi argum ent l e n zaw iera liczbę bajtów przeczytanych przez i
aplikację. Po w yw ołaniu tej funkcji biblioteka oblicza now y rozm iar okna odbii
czego i jeśli rozm iar okna zm ienił się, inform uje o tym drugą stroną komuniki
void
tcp_sent(struct tcp_pcb *pcb,
err_t (* sent_callback)(void *arg,
struct tcp_pcb *pcb,
u!6 t len));
Funkcja tc p _ s e n t rejestruje funkcję zw rotną, którą biblioteka Iw lP w ola, aby
inform ow ać aplikację, że druga strona potw ierdziła odebranie danych. Pierwsz;
159
F u n k cja t c p _ w r i t e w staw ia dane do bufora nadaw czego. P ierw szym argum en­
tem tej funkcji je s t w skaźnik pcb do d esk ry p to ra T C P o p isu jąceg o połączenie,
przez któ re dan e m ają być w ysiane. D ru g im argum entem je s t w sk aźn ik d a t a
do w y sy łan y ch danych. T rzeci argum ent l e n o k reśla ilość danych do w ysiania
w bajtach . C zw arty argum ent f l a g s m oże być zerem lub altern aty w ą n astęp u ją­
cych w artości:
-
TCP_WRITE_FLAG_COPY - skopiuj dane do pam ięci stosu;
-
TCP_WRITE_FLAG__MORE - będą następne dane.
Jeśli nie użyjem y opcji TCP_WRITE_FLAG_COPY, biblioteka Iw lP zakłada, że dane
w skazyw ane przez d a ta nie ulegną m odyfikacji, aż zostaną w ysiane i potw ierdzo­
ne. O dpow iada za to aplikacja. Jest to szczególnie użyteczne, gdy d a ta w skazuje na
dane w pam ięci stałej. U nika się w tedy zbędnego kopiow ania. Jeśli ustaw im y opcję
TCP_WRITE_FLAG_COPY, dane w skazyw ane przez d a ta zostaną skopiow ane do pa­
mięci zarządzanej przez bibliotekę IwlP. W tym przypadku, jeśli funkcja tc p w r ite
zakończy się popraw nie, aplikacja m oże natychm iast zw olnić pam ięć w skazyw aną
przez d a ta lub użyć jej ponow nie. Jeśli używ am y sterow nika util_eth__zc.c i d a ta
w skazuje na obszar pam ięci Flash, należy koniecznie ustaw ić opcję TCP_WRITE_
FLAG_C0PY.
B iblioteka Iw lP dzieli dane otrzym ane do w ysłania na segm enty i w staw ia te seg­
m enty do kolejki nadaw czej. W ostatnim w staw ionym segm encie ustaw ia znacznik
PSH , chyba że podana została opcja TCP_WRITE_FLAG_MORE. W tedy znacznik PSH
nie je s t ustawiany. O pcja ta je st przydatna, jeśli w ysyłam y dane za pom ocą wielu
kolejnych w yw ołań funkcji tc p _ w ite . W tedy ustaw iam y tę opcję w e w szystkich
w yw ołaniach tej funkcji z w yjątkiem ostatniego.
F unkcja t c p _ w r i t e zw raca ERR OK, jeśli w staw ienie danych do bufora nadaw czego
pow iodło się, a w przeciw nym przypadku zw raca kod błędu inform ujący o przyczy­
nie niepow odzenia.
160
4.2.7.
4.2. TCP
4. Programowanie w modelu klient-scrwek
Funkcje zwrotne
W tym podrozdziale opisuję bardziej szczegółow o, w kolejności alfabetycznej'*
funkcje zw rotne używ ane przez bibliotekę lwIP. Te funkcje zw rotne, które w danej1'
aplikacji są nam potrzebne, m usim y zaim plem entow ać sami.
err_Ł
accept_callback(void *arg,
struct tcp_pcb *conn_pcb,
err t err);
Funkcja zw rotna a c c e p t_ c a llb a c k je s t w yw ołana po stronie w ykonującej otwarcie’?
pasyw ne (zw ykle je st to serw er). B iblioteka lw IP w yw ołuje ją po odebraniu m-um entu A C K kończącego otw ieranie połączenia. Pierw szym argum entem tej funk-;'i
cji je s t w skaźnik a rg do danych aplikacji, przypisany za pom ocą funkcji tc p a r :..’
D rugim argum entem je s t w skaźnik conn pcb do now ego deskryptora TCP, utwórz, i
nego dla w łaśnie otw artego połączenia. W szelkie dalsze operacje zw iązane z tym ^
połączeniem pow inny używ ać tego now ego deskryptora, a nie deskryptora zwró-Kconego przez funkcję t c p _ l i s t e n ani tym bardziej deskryptora zw róconego przez ’
funkcję tcp__new. Trzeci argum ent e r r je st kodem błędu. A naliza tekstu źródłowego >'
biblioteki lw IP pokazuje, że m a on zaw sze w artość ERR_0K. F unkcja a c c e p t_ c a l] back pow inna zw rócić ERR_0K, jeśli połączenie m a być kontynuow ane. Jeśli zwróci'^
w artość różną od ERR_0K, połączenie zostanie skasow ane.
err_t
connect_callback(void *arg,
struct tcp_pcb *pcb,
err t err);
.«SI
Funkcja zw rotna c o n n ect_ _ callb ack je s t w yw ołana po stronie w ykonującej otwar-1
cie aktyw ne (zw ykle je s t to klient). B iblioteka lw IP w yw ołuje ją po odebraniu seg­ ł1wBBB
f|||l
mentu SYN+ACIC. Pierw szy argum ent a rg je s t w skaźnikiem przypisanym za po-;
■i
m ocą funkcji tc p _ a rg . D rugi argum ent pcb je s t w skaźnikiem do deskryptora TCP
opisującego otw arte połączenie. T rzeci argum ent e r r zaw iera kod błędu. Analiza
tekstu źródłow ego biblioteki lw IP pokazuje, że ten argum ent m a zaw sze wartość'
ERR_0K. Po zakończeniu tej funkcji zw rotnej biblioteka lw IP w ysyła segm ent ACK.
kończący otw ieranie połączenia. A naliza tekstu źródłow ego pokazuje też, że biblio­
teka lw IP nie spraw dza w artości zw racanej przez ąędiinkcję.
;
i
i
void
conn_err_coilback(void *arg,
err t err);
iftw&S
■
m
n i
Funkcja zw rotna c o n n _ e rr_ c o llb a c k je s t w yw ołana przez bibliotekę lw IP w celu
poinform ow ania aplikacji o aw aryjnym zam knięciu połączenia. M oże to być skut-j
kiem otrzym ania segm pntu RST, w yw ołani^ funkcji tcp_abandon, w yw ołania funk-j,
cji tc p _ a b o r t lub w ystąpienia błędu, np. braku pam ięci. Pierw szym argumentem;
tej funkcji je st w skaźnik a rg do danych aplikacji, przypisany za pom ocą funkcji;
tc p _ a rg . A plikacja pow inna zw olnić zasoby w skazyw ane przez ten wskaźnik,*;
Drugi argum ent e r r je s t kodem błędu, który spow odow ał skasow anie połączenia,v\
161
Zauw ażm y, że funkcja ta nie dostaje w skaźnika do deskryptora TCP, gdyż w m o­
m encie jej w yw ołania połączenie m oże ju ż nie istnieć.
err_t
poll__callback(void *arg,
struct tcp_pcb *pcb);
Funkcja zw rotna p o ll _ c a łl b a c k jest w yw ołana cyklicznie przez bibliotekę lwIP.
Pierw szym argum entem tej funkcji je st w skaźnik a rg ustaw iony dla tego deskrypto­
ra za pom ocą funkcji tc p _ a rg . D rugim argum entem je s t w skaźnik pcb do deskryp­
tora TCP. Jeśli funkcja p o ll _ c a ll b a c k zw róci w artość ERR_0K, to po jej zakończe­
niu zostanie w yw ołana funkcja tc p _ o u tp u t. A naliza tekstu źródłow ego biblioteki
lw IP pokazuje, że inne zw racane w artości są ignorow ane.
err_t
recv_callback(void *arg,
struct tcp_pcb ‘
pcb,
struct pbuf *p,
err_t err);
Funkcja zw rotna re c v _ c a llb a c k je s t w yw ołana przez bibliotekę lw IP w celu po­
inform ow ania aplikacji o otrzym aniu danych, które aplikacja pow inna przeczytać.
P ierw szym argum entem tej funkcji je s t w skaźnik a rg do danych aplikacji, przypi­
sany za pom ocą funkcji tc p _ a rg . D rugim argum entem jest w skaźnik pcb do de­
skryptora T C P opisującego połączenie, z którego zostały odebrane dane. Trzecim
argum entem je st w skaźnik p do łańcucha buforów zaw ierającego odebrane dane.
C zw arty argum ent e r r jest kodem błędu. A naliza tekstu źródłow ego biblioteki lw IP
pokazuje, że argum ent ten m a zaw sze w artość ERR_0K. Funkcja re c v _ c a llb a c k słu­
ży też do poinform ow ania aplikacji, że połączenie zostało zam knięte przez drugą
stronę kom unikacji i nie m a ju ż żadnych danych do przeczytania. W tedy w skaźnik
p m a w artość NULL. A plikacja pow inna zam knąć połączenie w przeciw nym kierun­
ku za pom ocą funkcji tc p _ c lo s e .
Jeśli otrzym ane dane zostały przetw orzone, to aplikacja pow inna w ew nątrz funkcji
recv _ _ callback poinform ow ać o tym bibliotekę lw IP za pom ocą funkcji tc p _ r e cved, zw olnić łańcuch buforów w skazyw any przez p za pom ocą funkcji p b u f_ fre e
i zw rócić w artość ERR_0K. Jeśli aplikacja z jak ieg o ś pow odu nie m oże przetw orzyć
otrzym anych danych, to funkcja recv__calłback m oże zw rócić kod błędu różny od
EPf^OK.i nie w olno jej w tedy zw alniać łańcucha buforów. W tym przypadku biblio­
teka lw IP spróbuje w yw ołać funkcję zw rotną ponow nie z tymi sam ym i danymi.
S tanie się to przy najbliższej okazji, czyli po w ystąpieniu następnego zdarzenia w y­
w ołującego bibliotekę lwIP. C iągle odrzucanie danych przez aplikację m oże pow o­
dow ać odrzucanie przez bibliotekę lw IP kolejnych napływ ających segm entów T C P
z pow odu przepełnienia bufora odbiorczego. N ie pow oduje to utraty danych, bo
T C P radzi sobie z taką sytuacją i retransm ituje niepotw ierdzone segm enty. W pływ a
to jed n ak niekorzystnie na w ydajność aplikacji.
err__t
sent ¿callback(void ‘
arg,
*0zt
aJ*i struct tcp_pcb *pcb,
•.
~ ' i-ul6 t len);
----------- 1— (LI
Z-----------------
162
4. Programowanie u* modelu klient-serweĄ
Funkcja zwrotna se n t_ c a llb a c k jest wywołana przez bibliotekę lwIP, gdy otrzyJi!
mano potwierdzenie odebrania danych. Pierwszym argumentem tej funkcji jecP
wskaźnik arg do danych aplikacji, przypisany za pomocą funkcji tcp_arg. Drugi
argumentem jest wskaźnik pcb do deskryptora TCP opisującego połączenie, z kti
rego odebrano potwierdzenie. Trzeci argument len to liczba oktetów, które zosta
potwierdzone od poprzedniego potwierdzenia. Analiza tekstu źródłowego pokazuje '3
że biblioteka lwIP ignoruje wartość zwracaną przez tę funkcję.
4.3.
metyce uzupełnieniowej do jedynek, gdzie zero ma dw ie reprezentacje: wszystkie
bity równe zeru oraz w szystkie bity równe jedności. Gdy w yliczona suma kontrolna
jest równa zeru, używa się reprezentacji zawierającej jedynki. Suma kontrolna UDP
obejmuje nagłówek UDP, pole danych U DP i pseudonagłówek utworzony na pod­
stawie nagłówka IP, co jest kolejnym przejawem zacierania w intersieciach granicy
między warstwą sieciow ą a transportową. Sposób obliczania sumy kontrolnej UDP
jest opisany szczegółow o w RFC 768.
4.3.3.
UDP
Podstawowe własności
U DP rozszerza 1P o numery portów, zachowując w szystkie pozostałe własnos;ci II* '
czyli przesyłanie bezpołączeniowe i zawodne. Jednak w praktyce datagramy giną;
bardzo rzadko. UDP bardzo dobrze sprawdza się w protokołach typu pylanie-odpo-.'
wiedź, gdzie cała komunikacja sprowadza się do wymiany dwóch pakietów: klient1
zadaje serwerowi pytanie, a serwer odpowiada klientowi. Według takiej zasady *
działa na przykład protokół D N S. Przy tego rodzaju komunikacji zgubienie data-,
graniu nie jest groźnie. Klient nie otrzym awszy odpowiedzi w ustalonym czasie,
zadaje pytanie ponownie. Zaletą UDP, w stosunku do TCP, jest mniejszy narzut:
komunikacyjny. Nie trzeba otwierać i zamykać połączenia. Nagłów ek UDP je st..
krótszy niż nagłówek TCP.
*.
4.3.2.
Za pom ocą funkcji udp_recv klient i serwer rejestrują funkcję zwrotną r e c v _ c a llb ack , która będzie w ywołana przez bibliotekę lwIP, gdy pojawią się dane. Serwer
w yw ołuje funkcję udp_bind, aby uaktywnić nasłuchiwanie na wybranym adresie
IP i porcie. R ów nież klient m oże użyć tej funkcji. Funkcja udp con n ect ustawia w
lokalnej strukturze typu udp pcb adres IP i numer portu serwera, co powoduje, że
będą odbierane tylko datagramy U D P od tego serwera. Jeśli nie w yw ołuje się tej
funkcji, będą odbierane w szystkie datagramy kierowane pod adresem IP i na port
klienta. W ołanie funkcji udp_bind i udp_connect po stronie klienta jest opcjonal­
ne.
Nagłówek
Pakiety U DP nazywane są datagram am i. Datagram U DP składa się z przedsta- '
w ionego na rysunku 4.8 nagłówka i następującego po nagłówku pola danych, ,
Datagram UDP jest przesyłany w polu danych datagramu IP. U DP rozszerza IP :
o mechanizm portów, w ięc dwa pierwsze pola nagłówka zawierają odpowiednio
numer portu nadawcy i odbiorcy. P ole DŁUGOŚĆ DATAGRAMU UDP zawiera ,
całkowitą długość w oktetach datagramu, łącznie z nagłówkiem. Wartość w tym .
polu jest zaw sze większa lub równa 8. Projektanci protokołów intersieci postąpili
niekonsekwentnie. D ługość datagramu U DP daje się w yliczyć na podstawie długo­ 1*
ści datagramu IP, podobnie jak w TCP, gdzie nic.,,przcwidziano w nagłówku pola
zawierającego długość segmentu TCP.
•.
W UDP suma kontrolna jest opcjonalna. Jeśli pole SUM A KONTROLNA zawiera
zero, to nie obliczono sumy kontrolnej. Pojawia się problem, co zrobić, gdy wyli-; '.'¡'■A
czona suma kontrolna jest równa zeru. Suma kontrolna U DP jest obliczana w arytI®
b
'W
®
0
31
'/!?
NR PORTU ODBIORCY
. NR PORTJJ NADAWCY
Klient
pcb » udp_new() — >
[0:15]
[16:31]
SUMA KONTROLNA
[16:31]
Rys. 4.8. Format nagłówka UDP
■
lw IP
<—
Serw er
pcb = udp_new()
<— udp_recv(pcb, recv_cailback,
arg)
<— udp_bind(pcb, s_addr, s_port)
udp_connect(pcb, s_addr, sjport) *->
ucp_recv(pcb, recv_callback, arg) — >
Rys. 4.9. Inicjowanie klienta i serwera UDP
4.3.4.
Przesyłanie danych
Diagram przesyłania danych za pom ocą UDP przedstawiony jest na rysunku 4.10.
Biblioteka lwIP udostępnia dw ie funkcje w ysyłające datagram UDP. Można go
Klient
lw IP
udp_send(pcb, pbuf) -->
udp_sendto (pcb, pbuf, s__addr, s_port) — >
%
lw IP
S erw er
— > recv_callback(arg, pcb, pbuf,
c_addr, c_port)
— > recv_callback(arg, pcb, pbuf,
c_addr, c__port)
recv ¿jallback(arg, pcb, pbuf,
■i®
1
lw IP
udp_bind{pcb, c_addr, c_port) *->
1
DŁUGOŚĆ DATAGRAMU UDP
[0:151
Inicjowanie klienta i serwera
Procedury inicjowania klienta i serwera U DP przedstawione są schem atycznie na
rysunku 4.9. U DP nie tworzy połączenia, w ięc podczas inicjowania nie są w y­
mieniane żadne datagramy m iędzy klientem i serwerem, nie jest generowany ża­
den ruch w sieci. Funkcja udp_new przydziela strukturę typu udp_pcb (ang. UDP
p ro toco l control błock), w której biblioteka lwIP przechowuje kontekst komunika­
cji UDP. Strukturę tę nazywam deskryptorem UDP. Wskaźnik do tego deskryptora
jest przekazywany jako argument pozostałym funkcjom obsługującym komunikację
UDP.
U DP (ang, User D atagram Protocol) jest pakietowym protokołem transportowym'!
intersieci. Jest opisany w RFC 768 i został przyjęty jako standard intersieci STD 6. '4
4.3.1.
163
4.3. UDP
# m idr' s_p°r t i
Rys. 4.10. Przesyłanie danyijh UDP
<—
udp_sendto(pcb, pbuf, c_addr, c_port)
164
4. Programowanie w modelu klient-serwefc
•:»n
w ysiać za pom ocą funkcji u d p _ se n d to , podając adres 1P i num er portu odbiorcy.Jeśli klient skonfigurow ał adresu IP i port serw era za pom ocą funkcji udp_oc:',J
n e c t, to nie m usi ich podaw ać za każdym razem i m oże w ysiać datagram za poi*
m ocą funkcji udp sen d . A plikacja je s t inform ow ana o odebraniu datagram u /.¡p
pom ocą funkcji zw rotnej re c v _ c a llb a c k . U D P nie potw ierdza o debrania danycl{$
Jeśli takie potw ierdzenie je s t w ym agane, m usi być zaim plem entow ane w warstwi^;
aplikacji.
4.3.5.
4.3. UDP
165
udp_bind. D latego funkcja u dp_connect m oże zw rócić te sam e w artości co funkcja
udp_bind.
void
udp_disconnect(struct udp__pcb *pcb);
F unkcja u d p _ d is c o n n e c t usuw a z deskryptora U D P adres IP i num er portu zdalne­
go końca kom unikacji. O dw raca działanie funkcji udp_connect. N ie generuje żad­
nego ruchu w sieci. A rgum ent pcb je s t w skaźnikiem do deskryptora UDP.
Funkcje biblioteczne
. 'Si
W tym podrozdziale opisuję bardziej szczegółow o i w kolejności alfabetycznej
funkcje biblioteki lw IP obsługujące kom unikację za pom ocą UDP.
Funkcja udp_new przydziela now y deskryptor UDP. Z w raca w skaźnik do przydzie­
lonego deskryptora lub N U L L , gdy nie udało się go przydzielić.
err t
udp bind (struct udp_pcb *pcb,
struct ip addr *addr,
u!6_t port);
Funkcja udp b in d w iąże deskryptor U D P z lokalnym adresem IP i portem, któ’
re m ają być używ ane do o d bierania datagram ów . W ybrany adres i port będą też'15
um ieszczane ja k o adres i port nadaw cy w w ysyłanych za pom ocą tego deskryptofąf
datagram ach UDP. Pierw szym argum entem tej funkcji je st w skaźnik pcb do de-,
skryptora UDP. D rugim argum entem je s t w skaźnik a d d r do struktury zawierającej?
adres IP. Jeśli argum ent ten m a w artość IP_ADDR_ANY, deskryptor w iązany jest n ■
w szystkim i lokalnym i adresam i IP, co je s t przydatne, gdy je s t tylko jeden interfejs1
sieciow y lub gdy chcem y, aby serw er odbierał datagram y U D P ze w szystkich in-'
terfejsów sieciow ych. Trzeci argum ent p o r t je s t num erem portu. Jeśli ma w artość
zero, to biblioteka lw IP przydziela dow olny niezajęty port. Ten argum ent m a zwyt*
kle w artość zero, gdy urucham iam y klienta, gdyż w tedy num er portu je s t nieistotny,.
D la serw era zw ykle podaje się w artość niezerow ą, gdyż serw er m usi nasłuchiwać.;
na pow szechnie znanym porcie. F unkcja zw raca ERR_OK, gdy zakończyła się suk­
cesem , a ERR_USE, gdy nie m ożna użyć podanych w artości, np. żądany port jesti'
zajęty.
err_t
udp_connect(struct udp_pcb *pcb,
struct ip_addr *addr,
ul6_t port)/
struct udp_pcb *
udp j i e w (void);
*
Funkcja udp _ co n n ect przypisuje d o deskryptora U D P adres IP i num er portu zdah;
nego końca kom unikacji. U staw ia dom yślny adres IP i port, na które będą wysy-'
lane datagram y U D P za pom ocą funkcji udp send. Ponadto pow oduje, że będą
odbierane i przetw arzane tylko datagram y, które zostały w ysłane z podanego źrór
dla. Pierw szym argum entem je s t w skaźpjk pcb do deskryptora UDP. D rugim atr
gum entem je s t w skaźnik a d d r jlo.stru k tu fy zaw ierającej adres IP. Trzeci argumenj?
p o r t je s t num erem portu. Podany adres IP i num er portu są tylko zapisyw ane w ItA,
kalnym deskryptorze UDP. N ie odbyw a się żadna kom unikacja sieciow a. Jeśli me;
został przypisany lokalny adres IP i num er portu, najpierw je s t w yw ołana funkcją
void
udp__recv (struct udp_pcb *pcb,
void (* recv__callback) (void *arg,
struct udp_pcb *pcb,
struct pbuf *p,
struct ip_addr *addr,
u!6_t port),
void *arg);
Funkcja u d p _ recv rejestruje funkcję zw rotną, która będzie w yw ołana przez biblio­
tekę lw IP po odebraniu datagram u UDP. Pierw szym argum entem tej funkcji jest
w skaźnik pcb do deskryptora UDP, w którego kontekście będą odbierane datagra­
my. D rugi argum ent recv__callback je s t adresem rejestrow anej funkcji zw rotnej.
T rzecim argum entem je st w skaźnik a rg do danych aplikacji. W skaźnik ten będzie
p rzekazyw any jttko pierw szy argum ent funkcji zw rotnej, co um ożliw ia obsługę w ie­
lu klientów i serw erów za pom ocą w spólnej funkcji zw rotnej.
void
udp_remove(struct udp pcb *pcb);
Funkcja udp_remove zw alnia deskryptor UDP. A rgum ent pcb je st w skaźnikiem
do deskryptora, który m a być zw olniony. F unkcja ta pow inna być w yw ołana, gdy
klient lub serw er kończą działanie.
w--------- -------------------------------- -—-------------------------- -----------------------------------err_t
udp_send(struct udp_pcb *pcb,
struct pbuf *p)
F unkcja udp_send w ysyła datagram U D P na adres IP i port, które zostały skon­
figurow ane za pom ocą funkcji u d p _connect. Pierw szym argum entem tej funkcji
jest w skaźnik pcb do deskryptora UDP, w którego kontekście m ają być w ysyłane
datagram y UDP. D rugim argum entem je st w skaźnik p do łańcucha buforów z da­
nymi, które m ają być um ieszczone w polu danych datagram u UDP. Ten łańcuch
bufonów przydzielam y za pom ocą funkcji p b u f_ a llo c , której pierw szy argum ent
poW łmen ¡htUć w artość P B U F _ T R A N S P O R T . A ktualna im plem entacja funkcji udp_send
w yw ołuje >pó ¡prostu funkcję ud p _ sen d to z adresem IP i num erem portu pobranym i
4. Programowanie w modelu klicnt-serwem
166
4.4. Uwagi końcowe
im plem entow ać sam em u. O czyw iście zaproponow ane nazw y funkcji zw rotnych są
tylko przykładow e i m ożna je w ybrać dow olnie.
z przekazanego jej deskryptora UDP. Funkcja udp_send zw raca te sam e wartości Gęjl
funkcja udp_ sen d to .
err_t
udp_sendto(struct udp_pcb *pcb,
struct pbuf *p,
struct ip_addr *addr,
ul6_t port);
Funkcja ud p _ sen d to w ysyła datagram U D P na podany adres IP i port. Pierwszymi!
argum entem tej funkcji je s t w skaźnik pcb do deskryptora UDP, w którego kotWi
tekście m ają być w ysyłane datagram y UDP. D rugim argum entem je s t wskaźnik p i|
do łańcucha buforów z danym i, które m ają być um ieszczone w polu danych d au ,.^
gram u UDP. Łańcuch buforów przydzielam y za pom ocą funkcji p b u f_ a llo c , któi-J
rej pierw szy argum ent m a w artość PBUF_TRANSPORT. T rzecim argum entem funkcji'
u d p _ sen d to je s t w skaźnik a d d r do struktury zaw ierającej adres IP, na który ma by<$
w ysłany datagram UDP. C zw arty argum ent p o r t je st num erem portu, na który ma]
być w ysłany ten datagram . Jeśli nie został przypisany lokalny adres IP i num er por-i^
tu, najpierw w yw ołana je s t funkcja udp__bind. Funkcja u d p _ sen d to zw raca ERR_0K,:i
gdy udało się w ysłać datagram UDP. Jeśli w ystąpił problem , funkcja ta zw raca właściw y kod błędu.
4.3.6.
Funkcja zwrotna
O program ow anie U D P używ a tylko jed n ej fu n k c ji,zw rotnej, która służy do odbieg
rania danych. M usim y ją sam i zaim plem entow ać.
void
recv_caliback(void *arg,
struct udp_pcb *pcb,
struct pbuf *p,
struct ip_addr *addr,
u!6_t port);
Funkcja zw rotna r e c v _ c a llb a c k je s t w yw ołana przez bibliotekę łwIP, gdy zosta-'
nie odebrany datagram UDP. P ierw szym argum entem tej funkcji je s t w skaźnik arg;
podany przy rejestrow aniu lej funkcji zw rotnej. D rugim argum entem je st wskaźnik
pcb do deskryptora UDP, w którego kontekście odebrano datagram UDP. Trzecim
argum entem je st w skaźnik p do łańcucha buforów ^żaw ierającego pole danych datagranut UDP. C zw artym argum entem je st w skaźnik a d d r do struktury zaw ierającej,
adres IP nadaw cy datagram u U D P Piąty argum ent p o r t je s t num erem portu nadaw-cy datagram u UDP. A rgum enty a d d r i p o r t są potrzebne, aby aplikacja mogła odr
pow iedzieć na otrzym any kom unikat. A rgum enty te m ogą być przekazane wprost
funkcji udp _ sen d to .
4.4.
Uwagi końcdwe
O pisane w tym rozdziale struktury danych i funkcje biblioteki łwIP, z wyjątkiem
funkcji zw rotnych, są zadeklarow ane w plikach tcp.h i udp.h, a ich implementację l l l
5^
znajdują się w plikach tcp.c, tcp_in.c, tcp_oul.c, udp.c. Funkcje zw rotne trzeba z.i-
167
W tym m iejscu książki kończy się opis dolnych w arstw inter,sieci. Stąd je st to dobre
m iejsce na m ale podsum ow anie. Przedstaw iony dotychczas m aterial w ystarcza, aby
zacząć pisać aplikacje sieciow e na m ikrokontroler ST M 32F107 z w ykorzystaniem
biblioteki lwIP, co je st tem atem następnych rozdziałów , które zaw ierają przykłady
serw erów i klientów korzystających z opisanego w tym rozdziale interfejsu progra­
m istycznego. W kolejnych rozdziałach pojaw ią się rów nież dodatkow e inform acje
0 protokołach intersieci. Przykłady będą też okazją do zaprezentow ania niektórych
peryferii m ikrokontrolerów STM 32. C zytelnikom , którzy chcieliby bliżej poznać
zasady działania intersieci i nie chcą czytać dokum entów RFC, polecam w yda­
ną przed w ielom a laty, ale w ciąż aktualną i bardzo przystępnie napisaną książkę
D ouglasa C om era [1].
D otychczas kilka razy w spom niałem o bezpieczeństw ie. Ten tem at w ym aga po­
św ięcenia mu nieco uw agi. B ezpieczeństw o w inform atyce należy postrzegać jak o
odporność na celow e działanie zm ierzające do zm uszenia system u inform atycznego,
aby działał niezgodnie z je g o pierw otnym przeznaczeniem , niezgodnie ze specyfi­
kacją lub w ręcz, aby w ogóle przestał działać. N a bezpieczeństw o m ożna patrzeć
z różnych punktów w idzenia.
Jednym z fundam entalnych elem entów bezpieczeństw a aplikacji je s t jej popraw ­
ność. Jeśli aplikacja działająca w sieci kom puterow ej ma ja k iś błąd lub lukę, to
kiedyś zostanie to w ykorzystane. Pisząc aplikacje sieciow e, należy zakładać, że
druga strona kom unikacji m oże zachow ać się złośliw ie. W szczególności nie w ol­
no zakładać, że otrzym yw ane kom unikaty zaw sze będą zgodne z ich specyfikacją
1 należy przeprow adzać ich skrupulatną w alidację. Jeśli na przykład program ista
piszący serw er założy, że kom unikaty od klienta są zaw sze popraw ne i zaniecha ich
spraw dzania, to zaw sze znajdzie się inny program ista, który napisze klienta w ysy­
łającego niepopraw ny kom unikat, co w najlepszym przypadku doprow adzi do unie­
ruchom ienia serw era. W mniej optym istycznym w ariancie błąd w im plem entacji
m oże doprow adzić do nadużycia usługi. N ikt nigdy nie zw olni nas z obow iązku
pisania popraw nych program ów , a program y sieciow e w ym agają szczególnej sta­
ranności. N ależy przyjąć założenie, że druga strona kom unikacji m oże zachow yw ać
się zupełnie dow olnie lub w ręcz złośliw ie i należy m aksym alnie uodparniać pisaną
aplikację, na takie zachow ania. Takie podejście staram się prezentow ać w przykła­
dach.
Innym i, nie mniej istotnym i, elem entam i bezpieczeństw a są:
-
poufność (ang. confidentiality),
integralność (ang. integrity),
-
dostępność (ang. availability).
N ieprzypadkow o pierw sze litery angielskich nazw tych elem entów bezpieczeństw a
tw orzą skrót CIA . P oufność oznacza ochronę inform acji przed nieautoryzow anym
ujaw nieniem . R ealizuje się ją , stosując kontrolę dostępu do usługi np. za pom ocą
hasei'® szy-ffijłjąc przesyłane dane. Integralność oznacza ochronę inform acji przed
ich nieupraw nionym zm odyfikow aniem . Z w ykle integralność chroni się przez sku-
168
4. Programowanie w modelu klient-serwer
teczne w ykryw anie każdej próby m odyfikacji. Protokoły sieciow e stosują w tym 1''
celu sum y kontrolne. Jednak zw ykle sum y kontrolne są łatw e do podrobienia i z.!
pew niają ochronę tylko przed losow ym i przekłam aniam i. N ie zapew niają je d n a k ;
żadnej ochrony przed celow o w prow adzanym i zm ianam i. W celu zapew nienia ■
integralności stosuje się kryptograficzne sum y kontrolne i podpisy elektroniczne. ■
Podpis elektroniczny służy też do zapew nienia autentyczności (ang. authenticity)
inform acji, czyli pew ności co do pochodzenia danych i ich autorstw a. D ostępność
je st to zdolność do św iadczenia usługi bez przerw, 24 godziny na dobę, 7 dni w ty- ‘
godniu itd. N ajczęstszą przyczyną braku dostępności w sieci są aw arie i ataki typu ;
odm ow a usługi (D oS). D ostępność zapew nia się, stosując rozw iązania programowe
i sprzętow e, np. przez dublow anie krytycznych elem entów system u. N ależy wy- '■
raźnie zaznaczyć, że pełna ochrona nie je st m ożliw a, a stosow ane środki zawsze
w ynikają z pew nego kom prom isu, często o podłożu ekonom icznym .
Pow yższy akapit ma tylko uczulić C zytelnika na w spom niane problemy. Ich ■
uw zględnienie w ykracza daleko poza ram y tej książki. W w ielu zastosow aniach nie
je st to też konieczne. W dalszym ciągu zakładam , że przykłady będą urucham iane ■'
w zaufanej sieci lokalnej, chronionej od niebezpieczeństw czyhających w Internecie',
co najm niej za pom ocą ściany ogniow ej.
Serwer TCP
170
5. Sen
Tem atem tego rozdziału je st serw er używ ający protokołu transportow ego T C p |
M ateriał podzieliłem na dw a przykłady. W pierw szym z nich pokazuję, ja k zaii
plem enlow ać kom unikację sieciow ą. P rzykładow a aplikacja um ożliw ia zdalne w łąi
czanie i w yłączanie diod św iecących podłączonych do m ikrokontrolera oraz odczy t!
czasu, jaki upłynął od w łączenia układu, ale m ożna ją łatw o rozbudow ać i dodać ste-tl
row anie innym i peryferiam i. Drugi przykład je st rozszerzeniem pierw szego. Serwera
pow inien działać bezobsiugow o i radzić sobie z sytuacjam i aw aryjnym i. W tyłgl
celu w drugim przykładzie dodaję obsługę układu nadzorcy (ang. watchclog), k t ó lf
ry zeruje m ikrokontroler, gdy oprogram ow anie sieciow e nie w ykazuje aktywno
przez określony czas. N adzorca w ym usza też ponow ienie próby uruchom ienia :
w era, gdy w ystąpi problem podczas konfigurow ania ustaw ień sieciow ych.
5.1.
Protokół warstwy aplikacji
Przystępując do napisania aplikacji sieciow ej, m usim y w ybrać protokół warsty/y*
aplikacji. M ożem y użyć jakiegoś istniejącego protokołu lub zaprojektow ać własr '
Przykłady w ykorzystujące istniejące standardow e protokoły aplikacyjne intersieM ■
pojaw iają się w rozdziale 8 i rozdziale 10. W tym rozdziale oraz w rozdziale 6 :
i rozdziale 7 pokazuję, ja k zaprojektow ać w łasny protokół.
5.1.1.
Projekt protokołu
Projekt protokołu pow inien zaw ierać specyfikację w ym ienianych komunikatów
i opis interakcji m iędzy klientem a serw erem . Istnieją zasadniczo dw a podejścia
do projektow ania form atu kom unikatów : kom unikaty m ogą być opisane za pomocą
struktur binarnych albo m ogą to być kom unikaty tekstow e, czytelne dla człowieka, i
K om unikatom tekstow ym też m ożna nadać strukturę - zw ykle za pom ocą X M L -a,,
W szystkie dotychczas opisane w tej książce protokoły intersieci m ają komunikaty,-'
zdefiniow ane ja k o struktury binarne. N atom iast w iele protokołów aplikacyjnych in -.
tersieci używ a kom unikatów tekstow ych. O ba podejścia m ają sw oje zalety i w ady.,
K om unikaty binarne są zw ykle krótsze od odpow iednich kom unikatów tekstowych
niosących tę sam ą treść i łatwiej je s t zaim plem entow ać analizę kom unikatów bi­
narnych niż tekstow ych, dlatego kom unikaty binarne są preferow ane w dolnych
w arstw ach intersieci. Jednak człow iekow i zdecydow anie łatwiej czytać komunikaty i
tekstow e. W przypadku kom unikatów tekstow ych ułatw iona je s t analiza śladu (ang,. ■
tracę) przebiegu protokołu i ..łatwiej je s t napisać-skrypty testujące protokół, d la te-. #r:. «■
go kom unikaty tekstow e tak często są używ ane' w^-protokołach w arstw y aplikacji,:;
Do testow ania kom unikacji z serw erem używ ającym protokołu tekstow ego możnaw ykorzystać program telnet, który je s t standardow o dostępny zarów no w systemie
Linux, ja k i W indow s. P rogram telnet je s t klientem protokołu Telnet, cłioć sam ter;
stow any serw er nie m usi w pełni obsługiw ać tego protokołu. W tym rozdziale oraz •
w rozdziałach 6 i 10 pokazuję protokoły tekstow e. Protokoły aplikacyjne, których
kom unikaty mają posłać binarną, pojaw iają się jeszcze w rozdziałach 7 i 8.
Interakcję m iędzy klientem a serw erem iribżna opisać słow nie lub w yrazić za po­
m ocą diagram u autom atu stanow ego. O pis słow ny byw a preferow any w przypadku ;
prostych protokołów bezslanow ych. B ezstanow ość oznacza, że reakcja protokołu.,
zależy tylko od aktualnie odebranego kom unikatu i nie zależy od komunikatów
171
5.1. Protokół warstwy aplikacji
Tab . 5 .1 .
Polecenia obsługiwane przez serwer
Opis
Polecenie
h
?
Wyświetl tekst pomocy zawierający opis obsługiwanych poleceń
G
Włącz zieloną diodę świecącą
g
R
Wyłącz zieloną diodę świecącą
r
Wyłącz czerwoną diodę świecącą
t
Podaj, ile czasu upłynęło od włączenia mikrokontrolera
X
Zakończ komunikację
Wyświetl tekst pomocy zawierający opis obsługiwanych poleceń
Włącz czerwoną diodę świecącą
w ym ienionych poprzednio. O pis za pom ocą autom atu byw a bardziej precyzyjny.
W dokum entach RFC przeplatają się oba podejścia. Z aprojektow any na potrzeby
przykładów zam ieszczonych w tym rozdziale protokół je st bardzo prosty i bezstanowy, dlatego w zupełności w ystarczy je g o opis słowny. N ależy zw rócić uw agę, że
projekt protokołu je st czym ś innym niż projekt im plem entacji protokołu. Projekt
protokołu opisuje głów nie kom unikację sieciow ą, czyli przede w szystkim dane,
które m ożna podejrzeć w kanale kom unikacyjnym , w pinając się analizatorem sieci.
Projekt protokołu opisuje też inform acje, które m ożna w yw nioskow ać na podsta­
wie obserw acji tej kom unikacji. Protokół m usi dać się zaim plem entow ać w różnych
środow iskach i nie m oże zależeć od architektury sprzętu, języ k a program ow ania
czy interfejsu program istycznego udostępnianego przez jak ieś biblioteki. N atom iast
p rojekt im plem entacji m usi uw zględniać specyficzne w łasności sprzętu, języ k a p ro ­
gram ow ania i w ykorzystyw anych bibliotek.
Po tym krótkim w stępie przejdźm y do opisu protokołu, za pom ocą którego będzie­
my kom unikow ać się z naszym serw erem . W tab eli 5.1 zaw arto polecenia, które ob­
sługuje serwer. W ta b eli 5.2 podano odpow iedzi udzielane przez serwer. D ziałanie
protokołu je st następujące. K lient inicjuje połączenie T C P z serw erem . Serw er po
zaakceptow aniu połączenia w ysyła klientow i tekst pow itania i znak zachęty do w pi­
sania polecenia. K lient w ysyła jednoliterow e polecenie zakończone znakiem końca
w iersza. Jeśli klient poprosi o tekst pom ocy, serw er w ysyła go i ponow nie w ysyła
Tab . 5 .2 .
Odpowiedzi udzielane przez serwer
Odpowiedź
This is TCP server running on top of the
IwIP-st^ek..
Press h or ? to get help.
Opis
Tekst powitania
>
Znak zachęty db wpisania polecenia
h or ? print this help
G
turn on the green led
g
turn off the green led
R
turn on the red led
r
turn off the red led
t
get microcontroller running time
x
exit
Tekst pomocy
d gg:mm:ss.xxx
Czas w formacie: liczba dni, godzin, minut, sekund,
milisekund
ERROR
B *3 |
„1;
Przekroczony czas oczekiwania na polecenie
Błędne polecenie
173
5.1. Protokół warstwy aplikacji
znak zachęty. Jeśli klient zażąda w ykonania operacji na diodzie św iecącej, serwer■:
w ykonuje tę operację i w ysyła kolejny znak zachęty. Jeśli klient zażąda informacji
cji o czasie, serw er odsyła czas, który upłynął od uruchom ienia m ikrokontrolera^
w form acie: liczba dni, godzin, m inut, sekund i m ilisekund, a następnie wysyła
znak zachęty do w pisania kolejnego plecenia. Jeśli klient w yśle polecenie zakoń,)*;
czenia połączenia, serw er nie odpow iada i natychm iast zam yka połączenie TCP,,
Jeśli klient w yśle puste polecenie, sam znak końca w iersza, serw er odsyła znaki1'
zachęty. Jeśli klient przez 30 sekund nie w ykazuje żadnej aktyw ności, nie przysyła
żadnego polecenia, serw er w ysyła kom unikat o przekroczeniu czasu i zam yka pot'
łączenie TCP. Jeśli serw er odbierze polecenie, którego nie potrafi zinterpretować/^*
to w ysyła kom unikat inform ujący, że odebrał błędne polecenie i ponow nie w y s y ła ć
znak zachęty.
Przesyłane teksty są kodow ane za p om ocą A SCII. K lient i serw er ja k o znak końca'1
w iersza w ysyłają kolejno znak pow rotu karetki C R (ang. carriage return) i znakżprzejścia do now ego w iersza LF (ang. line fe e d ). K onw encja ta je st pow szechnie.
stosow ana w protokołach intersieci, np. w protokołach Telnet i HTTP. Program tel-'X
net po w ciśnięci klaw isza E nter w ysyła w łaśnie znaki C R i LF. Taką sam ą kon- ;$
w encję stosuje się w system ie W indow s. W A SC II znak CR m a kod 0x0D , a znak
L F kod 0x0A . S erw er pow inien pom ijać białe znaki w poleceniach odbieranych od1,
klienta. B iałym i znakam i, oprócz C R i LF, są np. spacja (znak SP, kod A SC II 0x20) •
i tabulacja (znak HT, kod A SCII 0x09).
Projekt implementacji protokołu
if.
G dy m am y ju ż gotow y projekt protokołu, m ożem y przejść do im p lem en to w an ia"'^ ,
serw era obsługującego ten protokół. W ym aga to najpierw zaprojektow ania analiza- -'4\
tora (ang. parser) odbieranych kom unikatów . W tym celu najw ygodniej jest u/ \ i
autom atu stanow ego. N a ry s u n k u 5.1 um ieszczone są sym bole, których będę u;
wał do rysow ania takich autom atów .
A utom at m a pew ną skończoną liczbę stanów. Jest to pam ięć autom atu. M ożna sobie '
w yobrażać, że stan to zm ienna w yliczeniow a przyjm ująca tyle różnych w artości, ile
autom at m a stanów. Podczas pracy autom at zm ienia stan. Z m iana stanu m oże być
w ynikiem odebrania kom unikatu lub zajścia zdarzenia. K om unikaty są zdefinio­
w ane przez protokół i pochodzą z sieci. N atom iast zdarzenia są generow ane lokal­
nie. Z darzenia m ogą być generow ane przez sp rzę tJu b m ogą być efektem działania
użytkow nika. Specjalnym rodzajem zdarzenia jest.b u d zik inform ujący o upłynięciu
określonego czasu. Sym bol budzika przypom ina klepsydrę. Podczas zm iany stanu .■j.yij.
autom at m oże w ysłać kom unikat do sieci lub w ygenerow ać zdarzenie, które może .
być też inform acją dla użytkow nika. K om unikaty i zdarzenia reprezentow ane są"'
przez pięciokąty w kształcie strzałek z opisem w środku. Strzałka po praw ej ozna­
cza kom unikaty, a strzałka po lew ej - zdarzenia. Strzałka skierow ana do wewnątrz
oznacza odebranie kom unikatu lub zajście zdarzenia, a strzałka skierow ana na ze
w nątrz oznacza w ysłanie kom unikatu lub m y generow anie zdarzenia.
A utom at rozpoczyna pracę w stanie początkow ym . Podczas pracy autom at pr/.ei
dzi pom iędzy stanam i w ew nętrznym i, które m ożna ponum erow ać. Jednak wygod­
niej je s t nadać stanom nazwy, co istotnie popraw ia czytelność rysunku i ułatwia zro-1
O d ebranie
k o m unikatu
Z
W ysianie
kom unikatu
Zajście
zd arzenia
W yg e ne ro w an ie
zdarzenia
M odyfikacja
zm ie n n ej w ew n ę trzn ej
!
S tan począ tkow y
Stan końcow y
S tan w ew n ę trzn y
B udzik
A ltern a tyw a
P rze pływ ste ro w a n ia
Rys. 5.1. Symbole używane w automatach stanowych opisujących protokół
zum ienie algorytm u, yżedług którego działa autom at. Stan w ew nętrzny reprezento­
w any jest przez ow al z nazw ą tego stanu. A utom at m oże zatrzym ać się i zakończyć
pracę w stanie końcow ym . Stanów końcow ych m oże być w iele. Stanu końcow ego
m oże też nie być, gdy nie przew idujem y zatrzym ania autom atu. Przepływ sterow a­
nia w autom acie zaznaczam y, łącząc poszczególne sym bole strzałkam i. Z danego
stanu autom at m oże zostać w yprow adzony przez w iele różnych kom unikatów lub
zdarzeń, co rysujem y za pom ocą rozgałęziających się strzałek.
A by nie tw orzyć zbyt w ielu stanów, czasem w ygodnie jest w prow adzić do auto­
m atu zm ienne w ew nętrzne. Z m iany w artości zm iennych w ew nętrznych rysuje się
w prostokątach. Jeśli autom at zaw iera zm ienne w ew nętrzne, to przepływ sterow a­
nia m ożna uzależnić od ich w artości. R ysuje się to przez um ieszczenie w łaściw ego
w arunku w rom bie, do którego prow adzi je d n a strzałka, a z którego w ychodzą dw ie
strzałki. Jedna, ta oznaczona etykietą tak, pokazuje przepływ sterow ania, gdy waru"ifek“je ś f spełniony, a druga - oznaczona etykietą nie - gdy nie je st spełniony.
F orm alnie w szystkie zm ienne w ew nętrzne tw orzą pam ięć autom atu, czyli są częścią
je g o stanu. W szystkie zm ienne w ew nętrzne m ożna usunąć, w prow adzając dodatko­
we stany. Przykładow o, jeśli zm ienna m oże przyjm ow ać 30 w artości, to każdy stan
należy zastąpić trzydziestom a stanam i, po jednym dla każdej w artości usuw anej
zm iennej. W idać, że prow adzi to do law inow ego w zrostu liczby stanów i zm niej­
sza czytelność diagram u opisującego autom at. Z drugiej strony, m ożna zredukow ać
liczbę nazw anych stanów w ew nętrznych do jednego, um ieszczając całą pam ięć au­
tom atu w zm iennych. Takie skrajne podejście też zm niejsza czytelność diagram u.
0 .'W b q ^ |e ), co m a być stanem , a co zm ienną, decyduje więc przede w szystkim
czytelnosś ćji(izyskanego projektu autom atu.
-K.v:
174
5. Serwer TCP.i*
N a kolejnych rysunkach pokazano projekt im plem entacji serw era realizującego’’
protokół opisany w poprzednim podrozdziale. D la każdego połączenia serw er uru-ą
cham ia now ą kopię autom atu. N a r y s u n k u 5.2 przedstaw iony je s t początkowyfragm ent działania autom atu. Po odebraniu now ego połączenia serw er w ysyła d o /
klienta tekst p ow itania oraz znak zachęty do w pisania p o lecenia i przechodzi do"'
stanu InilState, w którym czeka na polecenie. P oniew aż T C P je s t protokołem stru-,;'/
m ieniow ym , o dbierane dane trzeba analizow ać znak po znaku. W stanie InitStale.:
serw er ignoruje znaki spacji SP, tabulacji IIT i pow rotu karetki C R , a po każdym i
znaku now ego w iersza w ysyła kolejny znak zachęty. Z e specyfikacji protokołu wi,j.'
dać, że końcem w iersza je s t para znaków C R i LF. Form alnie należałoby traktować \
sam znak LF ja k o błąd. Jednak w sy stem ach uniksow ych ja k o znak końca w iers/a
stosuje się sam znak LF. Z atem bardziej rozsądnym podejściem je s t uznanie sam e­
go znaku LF ja k o popraw nego zak ończenia w iersza. U praszcza to im plem entację '
- nie trzeba w prow adzać d o datkow ego stanu o czekiw ania po znaku C R na znak ’
LF. Ponadto taka im plem entacja serw era toleruje klienta, który nie działa w pełni '<•
zgodnie ze specyfikacją, ale odstęp stw o od niej je s t na tyle drobne, że polece- ■
nia m ogą być popraw nie zinterpretow ane. A lternatyw nie należałoby potraktow ać
brak znaku CR przed LF ja k o błąd, ale takie rygorystyczne traktow anie błędów
nie zaw sze je s t dobrą strategią. O d ebranie w stanie InitS tale je d n eg o ze znaków
w ym ienionych w tabeli 5.1 pow oduje przejście do stanu, w którym serw er bę­
dzie oczekiw ał na zakończenie polecenia, czyli na o debranie znaku LF. Serw er ma "
w spółpracow ać z klientem protokołu Telnet, w ięc dodatkow o w stanie InilState
rozpoznaje znak IA C (ang. interpret cis com m and) o kodzie OxFF, o czym dalej.
175
5 . 1. Protokół warstwy aplikacji
SP, HT, CR <(
LF
Tekst pom ocy \
1znak zachęty /
Rys. 5.3. Projekt implementacji serwera - stan HelpState
D o im plem entacji serw era w prow adzam y celow y błąd. O debranie znaku dolara
zaw iesza działanie serw era - na rysunku nie m a strzałki w ychodzącej z sym bolu
o zn aczającego odebranie tego znaku. Ten błąd posłuży w następnym przykładzie
do przetestow ania działania nadzorcy. O debranie każdego innego znaku w stanie
InilS tate w prow adza autom at serw era w stan E rrorState.
N a r y s u n k u 5.3 zilustrow ane je s t działanie serw era w stanie H elpState. B iałe zna­
ki są ignorow ane. Po odebraniu znaku L F serw er w ysyła tekst pom ocy i znak za­
chęty, po czym w raca do stanu InitState, w którym będzie oczekiw ał na kolejne
polecenie. O debranie niebiałego znaku w stanie H elpState pow oduje przejście do
stanu E rrorS tate. Na r y s u n k u 5.4 w idoczne je s t działanie serw era w stanach do­
tyczących obsługi diod św iecących. Jak poprzednio w tych stanach białe znaki
są ignorow ane. Po odebraniu znaku L F serw er zależnie od stanu, w którym się
znajduje, w łącza lub w yłącza odpow iednią diodę, a następnie w ysyła znak zachęty
i w raca do stanu InitState. O debranie niebiałego znaku traktow ane je s t jak o błąd
i pow oduje przejście do stanu E rrorS tate. N a r y s u n k u 5.5 przedstaw iony je st frag­
m ent autom atu dotyczący stanu G etL ocalT im eState. Schem at działania je st analo-
lim
1
Rys. 5.2. Projekt implementacji serwera - stan początkowy
II I
■
In n y znak <(
1
Rys. 5.4. Proijśkt implementacji serwera - stany LedState
5. /. Protokół warstwy aplikacji
177
Rys. 5.5. Projekt implementacji serwera - stan GetLocalTimeState
Rys. 5.8. Projekt implementacji serwera - stan ErrorState
giczny ja k na poprzednich rysunkach, z tą tylko różnicą, że po odebraniu znaku j
L F serw er w ysyła klientow i inform ację zaw ierającą czas, który upłynął od urucho-L
m ienia m ikrokontrolera. N a r y s u n k u 5.6 pokazano fragm ent autom atu dotyczący;;;
stanu E xitState. Po odebraniu znaku L F serw er zam yka p o łączenie i kończy działanie autom atu.
N a ry s u n k u 5.7 pokazano działanie serw era w stanie lA C State. Serw er znajdzie
się w tym stanie po odebraniu znaku IAC, który oznacza początek polecenia pro­
tokołu Telnet. Pow odem w prow adzenie tego stanu je s t um ożliw ienie w spółpracy
serw era z program em telnet. W tym celu w ystarczy, aby serw er ignorow ał polece­
nia D O (kod OxFD), D O N T (kod OxFE), W IL L (kod OxFB) i W O N T (kod OxFC).
Po każdym z tych poleceń w ystępuje jednooktetow y kod opcji, na którą serw er
czeka w stanie O ptionState i którą ignoruje, w racając po je g o odebraniu do stanu
InitState. Inne polecenje nie pow inno się pojaw ić i jest traktow ane przez serw er
ja k o błąd. W ięcej na teh tem at m ożna przeczytać w [1, rozdz. 23].
N a r y s u n k u 5.8 objaśniono działanie serw era w stanie ErrorState. W tym stanie
serw er pow inien starać się w yjść z błędu i rozpoznać początek popraw nego polece­
nia. D latego serw er ignoruje w szelkie znaki z w yjątkiem LF, po którego odebraniu
w ysyła do klienta inform ację o błędzie i znak zachęty do w pisania popraw nego
polecenia, po czym w raca do stanu InitState.
Rys. 5.6. Projekt implementacji serwera - stan ExitState
I
,
Nowe połączenie <T
tłm eout = 30
Tekst powitania \
i znak zachęty /
• lii
Rys. 5.7. Projekt implementacji serwera - stan lACState
s ||
Rys. 5.9. Projdikt implementacji serwera - przekroczenie czasu
5.2. Przykład 5a - pierwsza wersja serwera TCP
5. Serwer 7
178
179
R. f
poczekają w kolejce odbiorczej D M A i zostaną przetw orzone przez stos dopiero po
ponow nym uaktyw nieniu przerw ań - nic złego się nie stanie.
Specyfikacja protokołu nakazuje serw erow i zaniknięcie poleczenia TCP, gdy kii
nie odzyw a się, nie przysyła żadnego polecenia przez 30 sekund. A by zrealizowa
to w ym aganie, dodajem y budzik, który generuje zdarzenie upływ u czasu co sekuĄl
dę. Ponadto dodajem y zm ienną timeout, która zlicza upływ czasu - je st zr
szana o jed en po odebraniu zdarzenia budzika. O dpow iednie m odyfikacje automatu!
przedstaw ione są na ry s u n k u 5.9. Po odebraniu now ego połączenia serw er inicji
zm ienną timeout w artością 30. D odatkow o w każdym stanie (na rysunku zaznaczo-^
nym ja k o ow al z w ielokropkiem ) po odebraniu dow olnego kom unikatu (na rysunkui
kom unikat oznaczony w ielokropkiem ) trzeba ponow nie zainicjow ać tę zmienną,i'
W każdym stanie należy też dodać obsługę zdarzenia budzika: serw er zm niejsza’!
w artość zm iennej timeout i jeśli osiągnie ona w artość zero, to inform uje klientki!
o upłynięciu czasu oczekiw ania na polecenie i zam yka połączenie TCP.
5.2.
int TCPserverStart(uintl6__t port) {
struct tcp_pcb *pcb, *listen_pcb;
err_t err;
IRQ~DECL_PROT£CT(x) ;
IRQ^PR0TECT(x, LWIP_IRQ_PRI0) ;
pcb = tcp_new();
IRQ UNPROTECT(X);
i f Tpcb *== NULL)
return -1;
IRQ^PROTECT(x, LWIP_IRQ_PRI0);
err = tcp_bind(pcb, IP_ADDR_ANY, port);
IRQ_UNPROT£CT(x);
i f (err != ERR_0K) (
IRQ_PROTECT(x, LWIP_IRQ_PRI0);
tcp_abandon(pcb, 0);
IRQ_UNPROTECT(x);
return -1;
Przykład 5a - pierwsza wersja serwera TCP
N azw y plików przykładu 5a zam ieszczone są w ta b e li 5.3. W iększość z nich zosta­
ła ju ż opisana w poprzednich rozdziałach. D alej opisuję tylko now e pliki.
5.2.1.
}
IRQ_PR0TECT(x , LWIP_IRQ_PRIO);
listen_pcb = tcp_listen(pcb);
if (listen_pcb)
tcp_accept(listen_pcb, accept_callback);
IRQJJNPROTECT(x) ;
Pliki tcp_server.h i tcp_server.c
Plik tcp_server.h zaw iera sygnaturę funkcji TCPserverStart, która urucham ia ser-:i'ij
w er TCP. .lej im plem entacja znajduje się w pliku lcp_servenc. A rgum entem funkcji'-,?
TCPserverStart je s t num er portu, na którym serw er m a nasłuchiw ać. Funkcja ta jfjj
zw raca zero, gdy uruchom ienie pow iodło się, a w artość ujem ną, gdy nie udało się-żłj|
uruchom ić serw era. Funkcja TCPserve r S t a r t działa zgodnie z diagram em serwera,śj
przedstaw ionym w poprzednim ro zdziale na rysunku 4.4, a dodatkow o sprawdza:
w artości zw racane przez poszczególne funkcje z biblioteki lw IP i obsługuje błędy.
Funkcja ta je s t przeznaczona do w yw ołania z program u głów nego, a więc spoza ■
biblioteki lwIP, dlatego w yw ołania funkcji bibliotecznych odbyw ają się przy zablo­
kow anych przerw aniach biblioteki. Funkcja tcp_listen w ykonuje pasyw ne otwar-:
cie - aktyw uje nasłuchiw anie połączeń od klientów . F unkcja tcp_accept rejestruje
funkcję zw rotną obsługującą faktyczne otw ieranie połączenia. M iędzy wywołaniem .
tcp_listen a tcp_accept stos lw IP nie m oże odebrać połączenia, ale ponieważ
przerw ania są zablokow ane, to ew entualne odebrane w tym czasie pakiety sieciov
Tab. 5.3. Pliki przykładu 5a
board_conl.c
boardJ n il.c
boardJ e d .c
„
tcp_server.li
}
return 0;
)
Stan autom atu serw era przechow ujem y w strukturze typu s t a t e . Składow a ti­
meout tej struktury zaw iera liczbę sekund, przez które serw er m a jeszcze czekać
na polecenie od klienta, patrz rysunek 5.9. Składow a function tej struktury je st
adresem funkcji, która ma być w yw ołana w celu obsłużenia kolejnego odebranego
znaku.
struct state {
err t (* function) (struct state *, struct tcp_pcb *,..uint8__t);
int timeout;
■■
Źródłowe i biblioteczne
e x jc p d .c
startup_stm 32j:ld . c
tcp_server.c
if (listen pcb == NULL) {
IRQ__PROTECT(x, LWIP_IRQ_PRI0);
tcp_abandon(pcb, 0);
IRQJJNPROTECT(x);
return -1;
util_delay.c
util_eth_nc.c
u li/Je d .c
u tiljw ip .c
ulil tim e.c
Nagłówkowe
board_conf.h
board_de!.h
board_de!s.h
boardjn it.h
board led.h
util_delay.h *
util_eth.li
u tilje d .li
u tiljw ip .h
util time.ti
tibiwip4.a
iibstm32f10x.a
■
■
:
i
1;
1
i i
iS
■
V
.
CC./)
cortex-m3, h
lwipopts.li
stm 32!10x_conf.h
1111
;JjV ’
■7’5'i
T
D la każdego stanu definiujem y osobną funkcję, której nazw a je s t taka sam a jak
nazw a tego stanu. Zm iana stanu odbyw a się przez zm ianę w artości składow ej
function. W szystkie funkcje m ają tę sam ą sygnaturę. Pierw szym argum entem jest
w skaźnik do struktury typu state, co um ożliw ia obsługę w ielu klientów (połą­
czeń T C P ) za pom ocą tych sam ych funkcji - funkcja dostaje w skaźnik do struktury
zw iązanej z klientem (połączeniem T C P ), którego m a obsłużyć. D rugim argum enlem ijast y |k |a ź n ik do deskryptora T C P opisującego połączenie, z którego odebrano
dane. Trzccjin argum entem je s t odebrany znak. Funkcje obsługujące stany zw racają
5.2. Przykład 5a - pierwsza wersja serwera 'PCP
state = mein__malloc (sizeof (struct state));
if (state == NULL)
return ERR_MEM;
state->function = InitState;
state->timeout = SERVER_TIMEOUT;
tcp_arg(pcb, state);
tcp_err (pcb, conn__err_callback) ;
tcp_recv (pcb, recv__callback) ;
tcp_poli (pcb, poU__callback, POLL_PER__SECOND) ;
return tcp_write_from_rom(pcb, invitation);
w artości typu e r r _ t zgodnie z konw encją przyjętą w bibliotece lwlP, czyli ERR_; y
przy popraw nym zakończeniu lub w łaściw y kod błędu. D odatkow o m ogą zwrócier
w artość ERRJLXIT, która oznacza, że funkcja zakończyła się popraw nie, ale n a le n
zam knąć połączenie TCP.
łdefine ERRJ1XIT 100
Funkcje obsługujące poszczególne stany autom atu serw era są następujące:
static
static
static
static
static
err__t
err_t
err t
err_t
err_t
static err_t
static err_t
static err_t
static err t
static err_t
static err_t
InitState (struct state *, struct tcp_pcb *, uint8_t);
lACState(struct state *, struct tcp_pcb *, uint8_t);
OptionState(struct state *, struct tcp_pcb *, uint8_t);
HelpState(struct state *, struct tcp_pcb *, uint8_t);
OnGreenLedState(struct state * struct tcp_pcb *,
uint8_t);
struct tcp_pcb *
OffGreenLedState(struct state
uint8_t);
OnRedLedState(struct state * struct tcpjpcb *,
uint8_t);
OffRedLedState(struct state , struct tcp_pcb *,
uint8_t);
struct tcp__pcb
GetLocalTimeState(struct state
uint8_t);
ExitState(struct state *, struct tcp_pcb *, uint8_t);
ErrorState(struct state *, struct tcp_pcb *, uint8_t);
W iększość odpow iedzi udzielanych przez serwer, zam ieszczonych w tabeli 5.2,.
to stale napisy, które znajdują się w pam ięci tylko do odczytu (R O M lub racz oi ■
Flash). A by skrócić tekst program u, do ich w ysyłania definiujem y m akro tc p
^
te_from _rora. A rgum ent p je st w skaźnikiem do deskryptora T C P opisującego polą-i^
czenie, przez które ma być w ysłana odpow iedź. A rgum ent x je st nazw ą tablicy typu.fjj
c h a r zaw ierającej napis do w ysiania zakończony zerow ym bajtem , który nie jest;1
w ysyłany. M akro nie działa popraw nie, jeśli x je st w skaźnikiem typu c h ar* . Należy
też zw rócić uw agę, że jeśli używ am y sterow nika util_eth_zc.c, to dane do wysłania'!
trzeba skopiow ać do pam ięci biblioteki - ostatni argum ent funkcji tc p _ w r ite m usi$
m ieć w tedy w artość TCP_WRITEJTLAG_COPY.
jjdefine tcp_write__from_rom(p, x) tcp_write(p, x, sizeof(x) - 1, 0)
Funkcja zw rotna accept_c a l l b a c k je s t w yw ołana, gdy zostanie odebrane nowći^jf
połączenie. Funkcja ta realizuje p ozostałą część diagram u serw era z rysunku 4.4.''-|;
N ajpierw alokujem y now ą strukturę typu s t a t e i inicjujem y jej składow e. Struktura;
s t a t e je s t zw iązana z now ym połączeniem (klientem ), a je j adres będzie przeka-jd
zyw any funkcjom zw rotnym obsługującym to połączenie. N a koniec w ysyłam y doljij
klienta tekst pow itania i znak zachęty.
’
static const char invitation!} »
"\r\n"
"This is TCP server running on top of the lwlP stack.\r\n"
"Press h or ? to get help.\r\n"
"\r\n"
idefine SERVER_TIMEOUT '30
idefine POLL PER SECOND 2
static errjt accept_caUback(void *arg, struct tcp_pcb *pcb,
err_t err) {
struct state *state;
181
}
G dy połączenie zostanie zam knięte aw aryjnie lub z pow odu w ystąpienia błędu, bi­
blioteka lw lP w yw ołuje funkcję zw rotną c o n n _ e rr_ c a llb a c k . Zadaniem tej funkcji
je st zw olnienie pam ięci przydzielonej strukturze typu s t a t e w funkcji a c c e p t_ c a llb a c k . A dres struktury typu s t a t e , która m a być usunięta z pam ięci, jest pierw ­
szym argum entem funkcji c o n n _ e rr_ c a llb a c k .
static void conn_err_callback(void *arg, err_t err) (
mem_free(arg);
i
W kilku m iejscach w program ie serw era w ystępuje potrzeba zam knięcia połącze­
nia T C R T rzeba w tedy zw olnić pam ięć przydzieloną strukturze typu s t a t e oraz
w yw ołać funkcję tc p _ c lo s e z biblioteki lwlP. A by nie pow tarzać tych sam ych se­
kw encji instrukcji, im plem entujem y funkcję tc p _ e x i t zam ykającą połączenie TCP.
Pam iętajm y, że po w yw ołaniu tc p _ c lo s e m ogą jeszcze przyjść dane, ale nie bę­
dziem y m ogli ich obsłużyć, gdy w cześniej zw olnim y pam ięć przechow ującą stan
połączenia. Z kolei, jeśli nie zw olnim y tej pam ięci, to po zakończeniu funkcji tc p _
e x i t nie będzie ju ż okazji do jej zw olnienia. D latego na początku funkcji tc p _ e x i t
w yrejestrow ujem y funkcję zw rotną służącą do odbierania danych, w yw ołując funk­
cję tc p _ re c v .
static void tcp_exit(struct state ‘
state, struct tcp_pcb *pcb) (
tcp_recv(pcb, NULL);
if (state) (
mesi_free (state) ;
tcp_arg(pcb, NULL);
I
tcp_close(pcb);
I
P rzetw arzanie odebranych danych i w ysyłanie odpow iedzi odbyw a się w funkcji
zw rotnej recv_callback. N ajpierw spraw dzam y, czy w yw ołanie tej funkcji jest
skutkiem odebrania now ych danych, czy też zostało zainicjow ane zam ykanie połą­
czenia TCP. Jeśli w skaźnik p je st niezerow y, to ożhiicza, że odebrane zostały dane.
N ajpierw w yw ołujem y funkcję tcp_recved, która inform uje stos lwlP, że aplikacja
odebrała dane. W łaściw e przetw arzanie delegujem y do funkcji StateAutomaton.
Jeśli funkcja StateAutomaton zakończy się sukcesem i funkcja zw rotna recv_calIback m a zw rócić w artość ERR_OK, to należy zw olnić łańcuch buforów w skazyw any
przez p. Jeśli funkcja StateAutomaton zw róci w artość ERR_EXIT lub w skaźnik p
je st rów ny zeru (druga strona zam knęła połączenie od swojej strony), to należy
zam knąć połączenie T C P za pom ocą funkcji tcp_exit.
errjjt recv_callback(void *arg, struct tcpjpcb *pcb,
*
I
struct pbuf *p, err_t err) (
if (p) t )'i
5.2. Przykład 5a ~ pierwsza wersja serwera TCP
tcp_recved(pcb, p->Łot_len);
err = StateAutomaton(arg, pcb, p ) ;
if {err == ERR_OK j| err == ERR_EXIT)
pbuf_free(p);
if (err == ERR_EXIT) {
tcp_exit(arg, pcb);
err * ERR_OK;
case 'h ' :
case '?':
state->function
return ERRJ3K;
case 1G ':
state->function
return ERR_0K;
case 'g':
state->function
return ERR_OK;
case *R * :
state->function
return ERR_0K;
case 'r1:
state->function
return ERR_0K;
case 11':
state->function
return ERR_0K;
case 1x ' :
state->function
return ERR OK;
case
for {;;);
default:
state->function
return ERR_0K;
1
)
else {
tcp^exit(arg, pcb);
err"~= ERR__OK;
)
return err;
i
Funkcja S tateA utom aton obsługuje autom at stanow y serwera. N ajpierw ponownie'
inicjujem y składow ą ti m e o u t - klienent je st aktywny, więc czas połączenia wydłu­
żam y o kolejne 30 sekund. N astępnie przeglądam y w skazyw any przez p łańcuch
buforów zaw ierający odebrane dane i dla każdego znaku w yw ołujem y funkcję wska­
zyw aną przez składow ą f u n c t i o n struktury s t a t e . Pam iętajm y, że ta funkcja mo/e
zm ienić w artość składowej f u n c t i o n - autom at m oże przejść do innego stanu.
static err_t StateAutomaton(struct state *s, struct tcp_pcb *pcb,
struct pbuf *p) I
s->timeouŁ = SERVER_TIMEOUT;
for {;;) (
uint8_t *c = (uint8_t *)p->payload;
uint!6_t i;
err__t err;
j
= OnGreenLedState;
» OffGreenLedState;
= OnRedLedState;
= OffRedLedState;
= GetLocalTimeState;
- ExitState;
= ErrorState;
}
F unkcje obsługujące kolejne stany są bardzo podobne. D latego prezentuję tylko nie­
które z nich. N ajpierw jed n a z funkcji zajm ujących się obsługą diod św iecących.
D ziała ona zgodnie z diagram em z rysunku 5.4.
static err_t OnGreenLedState(struct State *state,
struct tcp_pcb *pcb, uint8_t c) {
switch (c) (
case ' ':
case '\t':
case '\r':
return ERR_0K;
case '\nł:
state->function » InitState;
GreenLEDon{) ;
return tcp write from_rom{pcb, prompt);
% default:
state->function = ErrorState;
return ERR OK;
~ *
}
return ERR_OK;
}
Przetw arzaniem w stanie I n i t S t a t e zajm uje się funkcja o tej sam ej nazw ie. Funkcja
ta działa zgodnie z diagram em z rysunku 5.2.
static const char promptf] =
"\r\n"
' ' *"*'
static err_t InitState(struct state *state,
struct tcp_pcb *pcb, uint8_t c) (
switch (c) {
case IAC:
state->function = IACState;
return ERR_0K;
case ' ':
"
/
case *\ t 1:
t
case 1\r':
return ERR_OK;
case '\n *:
return tcp write from rom(pcb, prompt);
» HelpState;
!
for (i = 0; i < p->len; ++i)
if (ERR_OK != (err = s->function(s, pcb, c (iJ)))
return err;
if (p~>len == p->tot_len)
break;
else
p = p->next;
"> ";
183
J-fir
„
W ysłaniem inform acji z czasem , który upłynął od w łączenia m ikrokontrolera, zaj­
m uje się funkcja G etL o calT im eS tate. Funkcja ta działa zgodnie z diagram em z ry­
sunku 5.5. N apis m ożna sform atow ać za pom ocą funkcji s n p r i n t f , która należy do
standardow ej biblioteki C, ale nie je s t w spółużyw alna. Z am iast niej lepiej jest użyć
funkcji s n p r i n t f r, która je s t w spółużyw alna i je s t dostarczana przez bibliotekę
Newj-ib. O bie funkcje tw orzą napis, który zgodnie z konw encją obow iązującą w ję zyRirfc zM dńczony je s t zerow ym bajtem . Im plem entow any protokół, ja k w iększość
protokołów fintersieci, nie w ysyła w napisach tego term inalnego zera.
18 4
5.2. Przykład 5a - pierwsza wersja serwera TCP
5. Serwer T( p;
">
static const char timefrml) =
"\r\n"
"%u ^02u:ł02u:%02u.%03u\r\n"
"\r\n"
static err t ErrorState{struct state ‘state,
struct tcp_pcb *pcb, uint8_t c) {
switch {c) {
case '\n':
state->function = InitState;
return tcp_write_from_rom{pcb, error);
default:
return ERR OK;
">
static err_t GetLocalTimeState{struct state ‘state,
struct tcp_pcb *pcb, uint8_t c) {
switch (c) {
case ' ’:
case ’
\t';
case *\r':
return ERR_OK;
case *\n *: {
char buf[TIME_BUF_SIZE];
unsigned d, h, m, s, ms;
int size;
struct _reent reent;
)
i
F unkcja zw rotna p o ll _ c a ll b a c k im plem entuje fragm ent diagram u z rysun­
ku 5.9 obsługujący zdarzenie budzika. Pozostałe fragm enty tego diagram u, ini­
cjujące zm ienną tim e o u t, są zaim plem entow ane w funkcjach a c c e p t_ c a llb a c k
i S tateA u tom aton. Jeśli w skaźnik s t a t e m a w artość NULL, m oże to oznaczać, że
w ystąpił problem z zam knięciem połączenia - struktura s t a t e została zw olniona,
a w yw ołanie tc p _ c lo s e nie pow iodło się i połączenie nadal jest otw arte. T rzeba
spróbow ać zam knąć je ponow nie.
state->function = InitState;
GetLocalTime{&d, &h, &m, &s, &ms);
size = _snprintf_r{6reent, buf, TIME_BUF__SIZE,
timefrm, d, h, m, s, ms);
if (size <- 0)
return tcp_write_from_rom{pcb, error);
if {size >= T IME__BUF_SIZE)
size = TIME_BU?_SIZE - 1;
return tcp_write(pcb, buf, size, TCP_WRITE_E,LAG_COPY);
static const char timeout U =
"\r\n"
"TIMEOUT\r\n";
static err_t poll_callback{void *arg, struct tcp_pcb *pcb) {
struct state ‘state = arg;
)
default:
state->function
return ERR OK;
185
if (State == NULL)
'
tcp_exit{arg, pcb);
else if {— (state->timeout) <= 0) {
tcp_write_from_rom(pcb, timeout);
tcp_exit(arg, pcb);
ErrorState;
)
I
)
return ERR_OK;
Polecenie, które klient w ysyła do serw era, chcąc zakończyć z nim połączenie, < sługuje funkcja Exitstate, działająca zgodnie z diagram em z rysunku 5.6. Aby -f
zakończyć działanie autom atu i zam knąć połączenie z klientem , funkcja ta zwraca 1
w artość ERR_EXIT.
static err_t Exitstate{struct state ‘state,
struct tcp_pcb ‘
pcb, uint8_t c) (
switch {c ) {
case ‘ ':
case *\t *:
case *\ r 1:
—
return ERR— OK;
t •r-Ł-łtr
case '\ n ':
return ERR_EXIT;
default:
state->function = ErrorState;
return ERR OK;
1
static const char error[] =
"\r\n"
a
"ERROR\r\n"
"\r\n"
2.
■
, • 'fir '
,
P --
1
Poinform ow aniem klienta o błędnym poląceniu zajm uje się funkcja E r r orSt
działająca zgodnie z diagram em po k azan y ń i na rysunku 5.8.
)
"'¿i.
gPP
ta j l l
Plik e x jc p d .c
Plik e x jc p d .c zaw iera funkcję main przykładu. W funkcji tej urucham iam y ko­
lejne potrzebne układy m ikrokontrolera i stos lw IP oraz konfigurujem y ustaw ienia
sieciow e, analogicznie ja k w opisanym w cześniej przykładzie 3a. N a zakończe­
nie urucham iam y serw er TCP. Serw er nasłuchuje na standardow ym porcie usługi
Telnet, czyli na porcie 23. M ożna w ybrać dow olny num er portu z przedziału od
1 do 65 535. N ie pow inno się jed n ak używ ać portów pow szechnie znanych usług
w brew ich przeznaczeniu. Podczas urucham iania-św ieci się czerw ona dioda. Jej
zgaśnięcie sygnalizuje zakończenie urucham iania serw era. M iganie czerw onej dio­
dy w rytm ie zdefiniow anym drugim argum entem m akra e rr o r_ c h e c k oznacza, że
w yw ołanie funkcji, um ieszczone jak o pierw szy argum ent tego makra, zakończyło
się niepow odzeniem .
int main{) {
static struct netif netif;
static struct ethnetif ethnetif = {PHYJVDDRESS};
uiqt8_t confBit;
Deii^dSjdoO);
confBit ,= ffetConfBit{);
186
5. Serwer TCl\
AllPinsDisable{);
LEDconfigureO ;
RedLEDonf);
SET__IRG_PROTECTION {) ;
error_check(CLKconfigure(), 1);
error_check(LocalTimeConfigure(), 2);
error_check(ETHconfigureMII{), 4);
netif.hwaddr(O) - 2;
netif.hwaddr[l] = (BOARDJTYPE » 8) & Oxff;
netif.hwaddr[2] = BOARD_TYPE & Oxff;
netif.hwaddr[3J «= (ETHJ30ARD » 8) & Oxff;
netif.hwaddr[4] = ETH_BOARD & Oxff;
netif.hwaddr[5] = 1 + confBit;
if (iconfBit) |
IP4_ADDR(Snetif.ip_addr, 192, 168, 51, 84};
IP4__ADDR(&netif.netmask, 255, 255, 255, 240);
IP4_ADDRf&netif.gw,
192, 168, 51, 81);
5.2. Przykład 5a - pierwsza wersja serwera TCP
187
Jako h o s t m ożna też podać nazw ę w ęzła. W L inuksie w pliku /etc/h o sts m ożem y
zdefiniow ać nazw y w ęzłów w naszej sieci lokalnej. Jeśli um ieścim y w tym pliku
w pis
192.168.51.89
local-89.localdomain
local-89
to będziem y m ogli połączyć się z serw erem za pom ocą polecenia
telnet local-89
lub
telnet local-89.localdomain
Przykładow ą sesję, w której w ypróbow ano w szystkie polecenia, przedstaw iono
w ta b e li 5.4. Podczas tej sesji pow inniśm y zaobserw ow ać w łączanie i w yłączanie
diod św iecących. W trakcie połączenia m ożem y za pom ocą kom binacji klaw iszy
C trl+] przełączyć program telnet w tryb w ydaw ania lokalnych poleceń. O pis pole-
}
else {
IP4_ADDR(&netif.ip^addr,
IP4_ADDR(finetif.netmask,
IP4_ADDR(&neti f .gw,
0, 0, 0, 0) ;
0, 0, 0, 0);
0, 0, 0, 0);
1
error_check(LWIPinterfacelnit(Snetif, Sethnetif), 5);
LWIPtimersStart();
error__check(TCPserverSŁart(23), 7);
RedLEDoff{);
return 0;
|
!
Z w róćm y uw agę, że funkcja main kończy się instrukcją r e t u r n . Jest to dopuszczal­
ne, gdy używ am y pliku startup_stm 32_cld.c. Procedura startow a zaim plem entow a­
na w tym pliku w chodzi w nieskończoną pętlę, gdy funkcja main zakończy działa­
nie. Jeśli używ am y innej procedury startow ej, bezpieczniejszym rozw iązaniem jest
zastąpienie instrukcji r e t u r n nieskończoną pętlą:
for
5.2.3.
Testowanie przykładu
U rucham iając przykład w zestaw ie Z L 29A R M , w ybieram y za pom ocą zworki
BOOT1 sposób skonfigurow ania ustaw ień sieciow ych. Jeśli zw orka je st w pozy­
cji 0, użyte zostaną ustaw ienia zdefiniow ane statycznie w funkcji main. Jeśli jest
w pozycji 1, to zostanie uruchom iony klient D H CR "Serw er przystosow any je s t do
w spółpracy z program em telnet. W najprostszym przypadku urucham iam y go z linii
poleceń system u W indow s lub konsoli L inuksa, pisząc
Jako h o s t podajem y adres IP przydzielony zestaw ow i uruchom ieniow em u, uży­
w ając notacji z kropkam i. Jako p o r t podajem y num er portu, na którym nasłuchu­
je serwer. Jeśli nie podam y num eru portu, Jo zostanie użyty dom yślny port usłu­
gi Telnet, czyli port 23. Z atem zakładając, że zestaw uruchom ieniow y ma adres
192.168.5U 89, m ożem y połączyć się z nim za pom ocą polecenia
telnet 192.168.51.89
Test poleceń serwera
Linux
$ telnet 192.168.51.89
Trying 192.168.51.89...
Connected to local-89.localdomain
(192.168.51.89).
Escape character is , A] ' .
This is TCP server running on top of the
lwlP stack.
Press h or ? to get help.
> h
h or ? print this help
g'
turn on the green led
turn off the green led
g
R
turn on the red led
r
turn off the red led
t
get microcontroller running time
X
exit
Windows
C:\>telnet 192.168.51.89
This is TCP server running on top of the
lwlP stack.
Press h or ? to get help.
> h
h or ? print this help
G
turn on the green led
turn off the green led
g
R
turn on the red led
r
turn off the red led
t
get microcontroller running time
X
exit
> G
> g
> G
> R
> g
> r
> R
> t
> r
0 00:05:01.990
> t
> a
0 00:07
CO
«sr
telnet host port
T ab . 5 .4 .
ERROR
> a
>
X
ERROR
Connection to host lost.
> xÆ
Connect io^fei-osed by foreign host.
$
. Ù
C:\>
189
5.3. Przykład 5b - serwer TCP z nadz,orcą
Tab. 5.7. Pliki przykładu 5b
Tab. 5.5. Test zamknięcia połączenia
Linux
$ telnet 192.168.51.89
Trying 192.168.51.89...
Connected to local-89.localdomain
(192.168.51.89).
Escape character is ’
W indows
C:\>telnet 192.168.51.89
This is TCP server running on top of the
lwIP stack.
Press h or ? to get help.
> t
0 00:06:22.210
> t
> A3
0 00:08:57.230
Welcome to Microsoft Telnet Client
> A1
telnet> quit
Connection closed.
e9
Escape Character is 'CTRL+}*
lf: S
Źródłowe i biblioteczne
This is TCP server running on top of the
lwIP stack.
Press h or ? to get help.
r
C:\>
Tab. 5.6. Test przekroczenia czasu
Windows
C:\>telnet 192.168.51.89
This is TCP server running on top of the
lwIP stack.
Press h or ? to get help.
> t
> t
This is TCP server running on top of the
lwIP stack.
Press h or ? to get help.
0 00:08:45 200
>
TIMEOUT
0 00:11:59.220
Connection to host lost.
TIMEOUT
Connection closed by foreign host.
$
C:\>
ceń dostępnych w tym trybie m ożna uzyskać, w ydając polecenie h e lp . Połączenie
m ożna zam knąć poleceniem c lo s e . Połączenie m ożna też zam knąć, kończąc jedno­
cześnie działanie program u telnet, poleceniem q u i£ f a w L inuksie dodatkow o kom­
binacją klaw iszy C trl-D . O dpow iedni przykład pokazano w tabeli 5.5. Z naczki ' '
oznaczają w ciśnięcie klaw iszy C trl-]. W tabeli 5.6 zam ieszczono test zam knięcia
połączenia T C P w w yniku przekroczenia czasu oczekiw ania na polecenie.
Przykład 5b - serwer TCP z nadzorcą
b o a rd jo n l.c
b o a rd jn it.c
boardJed. c
tc p je r m .h
b o a rd jo n f.h
board_dei.li
board_dels.li
b o a rd jn ith
b o a rd je d .li
:
Microsoft Telnet> quit
Linux
$ telnet 192.168.51.89
Trying 192.168.51.89...
Connected to local-89.localdomain
(192.168.51.89).
Escape character is ,A3'.
e x jc p d _ w d g .c
startup_stm 32_cld. c
tc p je rv e r.c
*
Serw er z poprzedniego przykładu m a pew ną w adę. Jeśli w ystąpi problem podczas
jeg o urucham iania, to program kręci się w nieskończonej pętli w ew nątrz m akra ei ro r_ c h e c k . N iezłym pom ysłem je s t w tej sytuacji w yzerow anie m ikrokontrolera
util_delay.c
u t iljth jic .c
ulUJedTc
u tiljw ip .c
u tiljim e .c
u lf j/d g .c
Iiblwip4.a
Iibstm32t10x.a
Nagłówkowe
util_delay.h
u t iljth .il
u tilje d .h
u tiljw ip .li
u liljim e .h
util wdg.h
CC.Il
cortex-m 3.li
lwipopts.li
s tm 3 2 t1 0 x jo n t.h
i ponow ienie próby uruchom ienia serw era. Ponadto sam serw er je s t dość skom pli­
kow aną aplikacją i trudno w ykluczyć w ystąpienie w jeg o im plem entacji jakiegoś
błędu, który doprow adzi do zaw ieszenia. W im plem entacji serw era w prow adzili­
śm y celow o taki błąd. A plikacje urucham iane na m ikrokontrolerach m ają działać
bezobsługow o i aby radzić sobie z takim i problem am i, m ikrokontrolery w yposaża­
ne są w układ nadzorcy (ang. watchclog). W tym przykładzie dodajem y do serw era
T C P obsługę układu nadzorcy. N azw y plików potrzebnych do jeg o skom pilow ania
zam ieszczone są w tabeli 5.7. Są to w w iększości te sam e pliki co w poprzednim
przykładzie. W dalszyńt ciągu opisuję tylko różnice m iędzy tymi przykładam i.
Pliki util_wdg.h i utiljw dg.c
M ikrokontrolery ST M 32 w yposażone są w dw a układy nadzorców : IW DG (ang.
independent w atchdog) i W W D G (ang. witulow wcitchdog). U kład IW D G jest ty­
pow ym układem nadzorcy, jak i znajduje się w w iększości m ikrokontrolerów i dla­
tego w ykorzystam y w łaśnie ten układ. U kład IW D G zaw iera 12-bitowy licznik zli­
czający od zadanej w artości początkow ej do zera. Taktow any je s t przez dzielnik
w stępny (ang. prescaler) w łasnym generatorem LSI (ang. Iow speed internal) RC
0 nom inalnej częstotliw ości 40 kHz. G enerator ten m a spory rozrzut produkcyjny
1 w edług danych katalogow ych [8, 9] je g o rzeczyw ista częstotliw ość w aha się m ię­
dzy 30 a 60 kHz.
W pliku util__wgd.h deklarujem y m akro WatchdogReset, które restartuje licznik nad­
zorcy. W tym celu w yw ołuje funkcję IWDG_ReloadCounter z biblioteki STM 32.
łdefine WatchdogReset IWDG_ReloadCounter
Funkcja IWDG_ReloadCounter je st bezparam etrow a, ustaw ia początkow ą wartość
licznika układu nadzorcy i nie zw raca żadnej w artości. A by zapobiec w yzerow aniu
m ikrokontrolera przez układ nadzorcy, funkcja ta pow inna być w yw ołana w re­
gularnych odstępach czasu. Do inicjow ania układu nadzorcy deklarujem y w pliku
util_w gd.h funkcję WatchdogStart. Jej im plem entacja znajduje się w pliku util_
wgd.c. N a początku tego pliku definiujem y tablicę prescalerTbl dopuszczalnych
w artości dzielnika w stępnego.
't liii
li I
static conirc'jgint8__t prescalerTbl [] = {
IWDG_Presciiłer_4,
5.3. Przykład 5b - serwer TCP z nadzorcą
5. Seerwer
190
Zakładając nom inalną częstotliw ość LSI, m aksym alny czas m ożliw y do uzyskania
za pom ocą układu IW D G w ynosi ok. 26 sekund. Interw al restartow ania licznika
nadzorcy pow inien być odpow iednio m niejszy - m usi uw zględniać rozrzut częstot­
liwości taktow ania.
IWDG_Prescaler_8,
IWDG_Prescaler_16,
IWDG_Prescaler_32,
IWDG_Prescaler_64,
IWDG_Prescaier__128,
IWDG_Prescaler 256
i;
static const int maxldx =
sizeof(prescalerTbl) / sizeof(prescalerTbl[0]) - 1;
Testowanie przykładu
Ten przykład pow inien pozytyw nie przejść te sam e testy, które przeszedł poprzedni
przykład. D odatkow o należy przetestow ać nadzorcę. P rzykładow e w ydruki z term i­
nalu pokazane są w ta b e li 5 .8 . W celu zaw ieszenia serw era w ysyłam y znak dolara.
P oniew aż w w yniku zaw ieszenia oprogram ow anie stosu lw IP nie działa, w ysłany
do serw era segm ent T C P ze znakiem dolara nie zostanie nigdy potw ierdzony i opro­
gram ow anie T C P po stronie klienta retransm ituje ten segm ent. Po restarcie serw era
stos lw IP dostaje taki relransm itow any segm ent, który nie należy do żadnego ak­
tyw nego połączenia, w ięc odsyła segm ent z ustaw ionym znacznikiem RST, aby po­
inform ow ać o tym drugą stronę kom unikacji. W ten sposób klient m oże dow iedzieć
się, że połączenia ju ż nie ma. N iestety program telnet z system u W indow s nie roz-
A rgum entem funkcji W a tc h d o g S ta rt jest czas, po którym licznik układu nai
ina osiągnąć w artość zero i w yzerow ać m ikrokontroler. W artość tego czasu podaj
my w m ilisekundach. D okładnej w artości nie uda się uzyskać, choćby ze wz
na niedokładność częstotliw ości taktow ania. W ybieram y w artość dzielnika
nego i początkow ą w artość licznika, aby ja k o ś przybliżyć ten czas. Do obliczeprzyjm ujem y nom inalną częstotliw ość taktow ania 40 kH z. U kład IW D G konfjgu'.
rujem y za pom ocą funkcji z biblioteki STM 32. N azw y tych funkcji rozpoczynaj
się prefiksem IWDG. Funkcja IWDG_WriteAccessCmd uaktyw nia zapis do rejestrókonfiguracyjnych układu nadzorcy. Funkcja IW D G _SetPrescaler ustaw ia dzielni
w stępny układu nadzorcy. F unkcja lWDG__SetReload ustaw ia w artość, którą jest Ini
cjow any licznik nadzorcy po w yw ołaniu funkcji IWDG_ReloadCounter. N a koni
układ nadzorcy uaktyw niam y za pom ocą funkcji IWDG_Enable, która włącza tążgenerator LSI.
T ab .
Linux
This is TCP server running on top of the
lwIP stack.
Press h or ? to get help.
Plik ex_tcpd_wdg.c
Plik ex_tcpd_w dg.c zaw iera funkcję main tego przykładu. F unkcja ta je st bardzo
podobna do funkcji main z poprzedniego przykładu. R óżnice są następujące. Na
sam ym początku funkcji main urucham iam y układ nadzorcy:
WatchdogStart (WDG_TIMEOUT__MS| ;
Po uruchom ieniu serw era konfigurujem y regularne w yw ołanie funkcji restartującej
licznik nadzorcy:
(
^
LWIPsetAppTimer(WatchdogReset, WDG_RESET_IN'#ERVAL_MS);
N a początku pliku ex_tcpd_jvdg.c m usim y jeszcze zdefiniow ać stale czasow e:
This is TCP server running on top of the
IwIP stack.
Press h or ? to get help.
> t
> t
> $
0 00:11:08.800
0 00:17:59.980
IWDG_WriteAccessCmd(IWDG_WriteAccess_Enable);
IWDG_SetPrescaler(prescalerTbl(idx));
IWDG_SetReload{timeout - 1);
IWDG_ReloadCounter();
IWDG Enable();
łdefine WDG_TIMEOUT_MS
26000
idefine WDG RESET INTERVAL MS 13000
Windows
C:\>telnet 192.168.51.89
'
)
5.3.2.
5.8. Test nadzorcy
$ telnet 192.168.51.89
Trying 192.168.51.89...
Connected to local-89.localdomain
(192.168.51.89).
Escape character is ,A)’.
void WatchdogStart(unsigned timeout) {
int idx;
timeout *= 10U;
for (idx = 0;
timeout > OxlOOOU && idx <= maxldx;
timeout » = 1, ++idx);
if (idx > maxldx) {
idx = maxldx;
timeout = OxlOOOU;
191
Welcome to Microsoft Telnet Client
> $
Connection closed by foreign host.
'i
$ telnet 192.168.51.89
Trying 192.168.51.89...
Connected to local-89.localdomain
(192.168.51.89) .*
Escape character is ,Aj'.
This is TCP server running on top of the
IwIP stack.
Press h or ? to get help.
Escape Character is 'CTRL+J
Microsoft Telnet> quit
C:\>telnet 192.168.51.89
This is TCP server running on top of the
IwIP stack.
Press h or ? to get help.
> t
> t
0 00:00:53.550
0 00:00:48.350
>
X
Connection to host lost.
Con^^ftioi^losed by foreign host.
$
‘
C:\>
poznaje popraw nie tej sytuacji. T rzeba go zakończyć poleceniem q u it . O poprav..
nym działaniu, czyli zrestartow aniu układu przez nadzorcę, m ożna się p rzek o n ać1,
obserw ując diody św iecące. Św iadczy o tym rów nież to, że m ikrokontroler zaczyna'
odm ierzać czas od początku. W idzim y to, w ysyłając polecenie t po ponow nym po.-:
łączeniu się z serw erem . R estartow anie serw era zaobserw ujem y rów nież, gdy nie
pow iedzie sie jeg o uruchom ienie, np. gdy odłączym y kabel ethernetow y.
Klient TCP
194
6. Klient Tl />
6.1, Projekt protokołu
195
Tem atem tego rozdziału je s t klient używ ający protokołu transportow ego TCl1
R ozdział zaw iera dw a przykłady. W pierw szym z nich pokazuję klienta, którego',!
zadaniem je s t okresow e łączenie się z serw erem w celu przesłania danych p o c h o ij
dzących na przykład z czujników . W przerw ach m iędzy połączeniam i kłient p rz ę ś l
chodzi w tryb czuw ania (ang. standby), który zapew nia najm niejszy pobór prądu'-;
przez m ikrokontroler. C zas przebyw ania w trybie czuw ania odm ierza zegar czastiw
rzeczyw istego (RTC, ang. real tim e clock). Po w ejściu w ten tryb utracona zostaje;*
zaw artość pam ięci operacyjnej (R A M ) i w iększości rejestrów. Z achow yw ana jest-Jj
jed y n ie zaw artość rejestrów zapasow ych (ang. backup regisłers), w których moż­
na przechow ać niezbędne ustaw ienia program u. D rugi przykład rozszerza klientaH
0 obsługę rejestrów zapasow ych. Podobnie ja k serw er z poprzedniego rozdziału;-,
klient prezentow any w tym rozdziale też pow inien działać bezobslugow o i radzićfl
sobie z sytuacjam i aw aryjnym i. S erw er z poprzedniego rozdziału używ ał w typ
celu układu nadzorcy. W tym ro zdziale pokazuję inne m etody zerow ania mikrokon­
trolera i restartow ania program u. Przedstaw iony klient je s t w zasadzie tylko szkie­
letem aplikacji, nie obsługuje żadnych czujników , ale łatw o m ożna go rozbudować ^
1 zaim plem entow ać obsługę potrzebnych peryferii, co pozostaw iam Czytelnikow i ja k o ćw iczenie.
6.1. Projekt protokołu
K om unikaty w ym ieniane m iędzy klientem a serw erem opisane są w ta b e li 6.1.
K om unikaty są kodow ane ja k o teksty A SCII. K om unikat składa się ze słow a klu­
czow ego, po którym m ogą w ystępow ać param etry! oddzielone spacją. Parametry
W
m ogą być opcjonalne. K ażdy kom unikat kończy się znakiem końca w iersza, czyli
iists
i.py''
sekw encją znaków C R i LF.
Protokół je s t stanowy. Stanow ość tego protokołu została niejako w ym uszona prze/
to, że interpretacja kom unikatu S E T zależy od typu kom unikatu, na który je st od- -y
pow iedzią. A utom at dla klienta je s t przedstaw iony na ry s u n k u 6.1. N ie będziemy '
im plem entow ać serw era, ale dla pełności opisu potrzebny je st rów nież jeg o aui
m at. Jedna z wielu m ożliw ych w ersji autom atu serw era je s t przedstaw iona na ry ­
s u n k u 6.2. Jak w idać, autom aty te różnią się, w szczególności m ają różne zl
stanów.
Po otw arciu połączenia T C P klient w ysyła kom unikat H EL L O i przechodzi do sta­
nu H elloState, w którym oczekuje na o d p o w ie d z ie ć serw era. Jeśli w tym stanie
klient odbierze kom unikat O K, czyli pozytyw ne-potw ierdzenie, to w ysyła kom uni­
kat PARAM i przechodzi do stanu P aram State, w którym oczekuje na odpowiedź
od serw era. Jeśli w stanie H elloS tate k lient odbierze kom unikat SET, czyli prośbę
0 zsynchronizow anie zegara czasu rzeczyw istego, to próbuje go ustaw ić. Jeśli pr;
siane data i czas m ają popraw ny form at i prośba pow iedzie się, to klient odsyła
kom unikat O K ze zm ienionym czasem , a po nim kom unikat PARAM i przechud/:
do stanu Param State. „W przeciw nym przypadku klient w ysyła kom unikat ERROK
1 zam yka połączenie TCP. Jeśli w stanie Param State klient odbierze kom unikat OK.
to w ysyła kom unikat B Y E i zam yka połączenie TCP. Jeśli w tym stanie odb
rze kom uńikat SE T i przesłane param etry m ają popraw ne w artości, to ustaw ia je,
co potw ierdza kom unikatem O K z now ym i w artościam i param etrów , a nasti
.i
Rys. 6.1. Automat stanowy protokołu po stronie klienta
w ysyła kom unikat B Y E i zam yka połączenie TCP. Jeśli param etry w odebranym
k om unikacie S E T m ają niepopraw ne w artości, to klient w ysyła kom unikat ERR O R
i zam yka połączenie TCP.
H. .
,■
!.
Przejście do stanu końcow ego oznacza zam knięcie połączenia TCP. K lient zam y­
ka 'rlw n ip j (połączenie T C P zaw sze po odebraniu kom unikatu E R R O R lub BYE.
Zam knięcierpołączenia T C P przez drugą stronę należy traktow ać ja k odebranie ko-
6.2. Przykhul 6a - pierwsza wersja klienta TCP
197
Tab. 6.1. Komunikaty
Komunikat
Opis
HELLO
Jest to pierwszy komunikat wysyłany przez klienta do serwera po zestawieniu połączenia
TCP w celu zainicjowania komunikacji. Parametrami są data i czas, odczytane z zegara
czasu rzeczywistego klienta, w formacie RRRR.M M .DD gg:mm:ss (rok, miesiąc, dzień, go­
dzina, minuta, sekunda). Serwer powinien odpowiedzieć komunikatem OK lub SET
PARAM
Komunikat ten jest wysyłany przez klienta do serwera w celu przesłania swojej konfiguracji.
M a dwa parametry. Parametr C 0 N N E C T I0 N J IM E 0 U T jest czasem, po którym klient, nie do­
czekawszy się na odpowiedź od serwera, zamyka połączenie TCP Parametr STANDBY_TIME
jest czasem przebywania klienta w uśpieniu. Oba parametry są podawane w sekundach jako
liczby przy podstawie dziesięć. Serwer powinien odpowiedzieć komunikatem OK lub SET
SET
Komunikat ten jest wysyłany przez serwer do klienta w celu zmiany ustawień przesłanych
za pomocą komunikatu HELLO lub PARAM. Parametry tego komunikatu mają taki sam
format jak parametry komunikatów HELLO i PARAM. Na ten komunikat klient odpowiada
komunikatem OK, jeśli dokonał zmiany ustawień zgodnie z intencją serwera. W przeciwnym
przypadku klient odpowiada komunikatem ERROR
OK
Komunikat ten jest wysyłany przez klienta lub serwer w celu potwierdzenia odebrania
komunikatu. Jeśli jest odpowiedzią na komunikat SET, to zawiera parametry, które zostały
ustawione. W innych przypadkach parametry po tym komunikacie są opcjonalne i mogą być
ignorowane. Na ten komunikat się nie odpowiada
ERROR
Komunikat ten jest wysyłany przez klienta lub serwer w celu poinformowania, że odebrany
komunikat nie może być zinterpretowany. Parametry po tym komunikacie są opcjonalne
i mogą być ignorowane. Na ten komunikat nie odpowiada się, a strona, która go wysiała,
natychmiast po jego wysianiu zamyka połączenie TCP
BYE
Komunikat ten jest wysyłany przez klienta lub serwer w celu zakończenia komunikacji. Pa­
rametry po tym komunikacie są opcjonalne i mogą być ignorowane. Na ten komunikat nie
odpowiadajsię, a strona, która go wysiała, natychmiast po jego wysianiu zamyka połączenie
TCP
tent SE T. W ybór m iędzy tymi dw iem a m ożliw ościam i zależy od strategii działania
serw era i nie musi być częścią specyfikacji, która tylko opisuje m ożliw e działania.
2.
Przykład 6a - pierwsza wersja klienta TCP
N azw y plików przykładu
sałem ju ż w poprzednich
przykład korzysta z trybu
obniżonego poboru m ocy
6a zam ieszczone są w tabeli 6.2. W iększość z nich opi­
rozdziałach. Poniżej om aw iam now e pliki, ale poniew aż
czuw ania, zaczynam od krótkiego przedstaw ienia trybów
w m ikrokontrolerach STM 32.
Tab. 6.2. Pliki przykładu 6a
Źródłowe i biblioteczne
Rys. 6.2. Automat stanowy protokołu po stronie serwera
■
m unikatu BYE. Jeśli k lient nie otrzym a żadnego kom unikaty przez określony c 2.is
lub odbierze błędny kom unikat, to w ysyła kom unikat E R R O R i zam yka połączę-, a l l
nie. D om yślny czas oczekiw ania na odpow iedź w ynosi 30 sekund. Jego wartość BIS
nie m oże być m niejsza niż 5 sekund, aby kom unikaty zdążyły dotrzeć do odbiorcy
i serw er miał dostatecznie dużo czasu na w ysianie odpow iedzi. Po zam knięciu połą-,
czenia klient przechq/Jzi w stan uśpienia, p o m y śln y czas przebyw ania w tym stanie
w ynosi 20 sekund. Takie początkow e w artości tych czasów m ają ułatw ić testowanie,
program u.
W autom acie serw era nie je s t określone, kiedy na kom unikat H EL L O lub PARAM
serw er m a odpow iedzieć kom unikatem O K , a kiedy zm ienić ustaw ienia komunika-
ex jc p _clie n t.c
startup_stm 32_cld.c
tcp_client.c
bo a rd jto n l.c
b o a rd jn iic
b o a rd je d .c
tcp_client.h
board_conf.h
b o a rd J e l.ti
board_dels.il
bo a rd jn it.h
boardJed. h
util_delay.c
util_elh_nc.c
utilJ e d . c
u tiljw ip .c
u tiljtc .c
u tiljim e .c
Iiblwip4.a
libstm 32M0x.a
Nagfri wkowe
« li
_
.....
iii ....
util_delay.li
util_error.h
u tije th .h
u tilje d .h
u tiljw ip .h
u tiijtc .h
util lime.h
cc.h
cortex-m 3.li
Im popts.h
stm 32l10x_conl.h
6.2. Przykład 6a - pierwsza wersja klienta TCP
int RTCconfigure(void) 1
£XTI_InitTypeDef EXTI_InitStructure;
NVIC_Ini.tTypeDef NVIC_InitStructure;
Tryby o obniżonym poborze mocy
6 .2 .1 .
M ikrokontrolery S T M 32 w yposażono w kilka trybów o obniżonym poborze
W trybie uśpienia (ang. sleep m ode) w strzym yw ane je s t taktow anie rdzenia j4
m ięci, w szystkie układy peryferyjne pozostają taktow ane. W trybach głębokie
uśpienia (ang. deep sleep m ode) w strzym yw ane je s t taktow anie rdzenia, pamji
i w iększości peryferii. Są dw a tryby głębokiego uśpienia: tryb zatrzym ania (ąt
stop m ode) i tryb czuw ania (ang. standby).
RCC_APBlPeriphClockCmd(RCC_APBiPeriph_PWR | RCC_APBlPeriph_BKP,
ENABLE) ;
PWR_BackupAccessCmd(ENABLE) ;
if (PNR_GetFlagStatus(PWR_FLAG_SB)
PWR_ClearFlag(PWR_FLAG_SB);
RTC_WaitForSynchro () ;
Rdzeń m ikrokontrolera zasilany je s t napięciem 1,8 V. W trybie zatrzym ania wyj"
czone są w szystkie sygnały taktujące w dom enie 1,8 V. W strzym ane są oscy łat
RC HS1, oscylator kw arcow y H S E i w szystkie pętle fazow e - patrz rysunek ż.jf
W ew nętrzny regulator napięcia 1,8 V może pozostać w stanie norm alnej pracy al
zostać przełączony w stan niskiego poboru m ocy (ang. low p o w e r m ode). W trybf
zatrzym ania zaw artość rejestrów i pam ięci pozostaje niezm ieniona. Mikrokontrotó’
m ożna w ybudzić z tego trybu za pom ocą jed n eg o z 16 przerw ań zewnętrznyc
EXTI (ang. external interrupt), przerw ania w ygenerow anego przez programową!'
ny detektor napięcia zasilania P V D (ang. program m able voltage detector), alarm''
zegara czasu rzeczyw istego lub sygnału budzenia (ang. w ake-up) w y g en ero w an e/
przez interfejs USB albo E thernet.
^
)
!
EXTI_StructInit(6EXTI_InitStructure);
EXTI_InitStructure.EXTI_Line = EXTI_Linel7;
EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Rising;
EXTI_InitStructure.EXTI_LineCrad = ENABLE;
EXTI_InitStructure.EXTI_Mode » EXTI_Mode_Interrupt;
EXTI_Init(SEXTI_InitStructure);
NVXC_InitStructure.NVIC_IRQChannelPreemptionPrior.ity =
L0W_IRQ_PRI0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd “ ENABLE;
NVIC_InitStructure.NVIC_IRQChannel = RTC_IRQn;
NVIC_Init(SNVIC_InitStructure);
NVIC InitStructure.NVIC_IRQChannel = RTCAlarm_IRQn;
NVIC~Init(SNVIC_InitStructure);
return 0;
We w szystkicli trybach o obniżonym poborze mocy m ogą pozostaw ać włączone: .;;f
-
6.2.2.
w ew nętrzny oscylator RC LSI (ang. Iow speodr internal) o częstotliw ości nomi
nalnej 40 kH z, zw ykle taktujący układ nadzorcy IW D G;
zew nętrzny oscylator kw arcow y L S E (ang. low sp eed external), którego częstot- i.
liwość w ynosi zw ykle 32 768 Hz i który taktuje zegar czasu rzeczyw istego.
Pliki u t iljtc .h i u t iljt c .c
Pliki util_rtc.h i util_rtc.c zaw ierają im plem entację obsługi zegara czasu rzeczyw istego oraz trybu ęzuw ania. U m aw iam y się, że zegar odlicza sekundy od początku dnia 1 stycznia 1970 roku, czyli zgodnie z konw encją obow iązującą w systcmach uniksow ych. Funkcja R T C c o nfigure konfiguruje zegar czasu rzeczywistego,
Fu n k cja'ta zw raca zero, gdy konfigurow anie pow iodło się, a w przeciw nym przypadku w artość ujem ną.
!= RESET) {
else (
BKP_DeInit();
RCC_LSEConf ig (RCC_LSE_0N) ;
active_check(RCC_GetFlagStatus(RCC_FLAG_LSERDY), 10000000);
RCC_RTCCLKConfig(RCC_RTCCLKSource_LSE);
RCC_RTCCLKCmd(ENABLE);
RTC_WaitForSynchro();
RTC_SetPrescaier(32767);
RTC_WaitForLasŁTask();
W trybie czuw ania w ew nętrzny reg u lato r napięcia 1,8 V je s t w yłączony. Oscylatory
H SI, H SE i w szystkie pętle fazow e są rów nież w yłączone. Z aw artość pamięć’
i w iększości rejestrów zostaje utracona. Z achow yw ana je s t jed y n ie zawartość re­
jestrów zapasow ych. M ik rokontroler z trybu czu w ania m ożna w ybudzić na kilk’
sposobów : zerując go za pom ocą w yprow adzenia R E SE T , zerując go za pomo4;
cą nadzorcy, podając narastające zbocze na w yprow adzenie WKUP-PAO lub zgla'
szając alarm zegara czasu rzeczyw istego. Tryb czuw ania różni się od pozostałych
jeszcze tym, że po w ybudzeniu z niego w ykonyw anie program u rozpoczyna się od1
początku. W pozostałych trybach w ykonyw anie program u je s t w znaw iane od miej,
sca, gdzie nastąpiło uśnięcie. Jeśli odłączym y głów ne zasilanie m ikrokontrolera, tc
zegar czasu rzeczyw istego i rejestry zapasow e są zasilane przez wyprowadzenL,
V bat* c*° którego m ożna podłączyć baterię podtrzym ującą zasilanie tych układów,’Program w ykorzystujący tryb czuw ania pow inien spraw dzić, czy przyczyną rozpo­
częcia w ykonyw ania jest w ybudzenie, czy w łączenie zasilania.
-
199
.
■.
;
1
Poniew aż zegar czasu rzeczyw istego je s t sprzętow o zw iązany z układem zarzą­
dzającym trybam i obniżonego poboru m ocy (PW R ), a je g o rejestry znajdują się
w tej sam ej dom enie zasilania i taktow ania co rejestry zapasow e (B K P), w funkcji
RTCconfigure najpierw uaktyw niam y taktow anie tych układów i dostęp do reje­
strów zapasow ych. N astępnie spraw dzam y za pom ocą funkcji PWR GetFlagStatus,
czy m ikrokontroler obudził się ze stanu czuw ania - czy ustaw iony je st bit PWR_
FLAG_SB. Jeśli się obudził, to zegar czasu rzeczyw istego działa i nie trzeba go kon­
figurow ać. T rzeba tylko w yzerow ać znacznik PWR_FLAG_SB i poczekać za pom ocą
funkcji R T C _ W a i tForSynchro na zsynchronizow anie zegarów . Jest konieczne, gdyż
układy zegara czasu rzeczyw istego są taktow ane z dw óch źródeł: z oscylatora kw ar­
cow ego L SE i sygnałem PCLK1 z w yjścia dzielnika A B P I. Synchronizację nale­
ży przeprow adzić po każdym w łączeniu któregoś z tych sygnałów, np. za pom ocą
funkcji RCC_APBlPeriphClockCmd.
Jeśli ^przyczyną rozpoczęcia w ykonyw ania program u nie je s t obudzenie ze stanu
c z u w h ia j Ji | w łączenie zasilania m ikrokontrolera, to trzeba skonfigurow ać zegar
czasu rzeczyw istego. N ajpierw jed n ak za pom ocą funkcji BKP_DeInit zerujem y
6.2. Przykład 6a - pierwsza wersja klienta TCP
układ sterujący rejestram i zapasow ym i. Z a pom ocą funkcji RCC_LSEConfig*
tyw niam y oscylator LSE, który używ a zew nętrznego kw arcu 32 768 Hz. Fm
R C C _G etFlagStatus spraw dza, czy oscylator ten w ystartow ał. Funkcja ta jesllfj
w olyw ana m aksym alnie 10 m ilionów razy przez m akro a c tiv e _ c h e c k . Makro
je s t zdefiniow ane w pliku board_ init.h i pow oduje, że jeśli w tym czasie osćfl
tor się nie uruchom ił, to funkcja R TC configure kończy działanie i zw raca warfe1
ujem ną. Funkcje RCC_RTCCLKConfig i RCC_RTCCLKCmd w łączają taktow anie zeg'
czasu rzeczyw istego oscylatorem L SE. Funkcja R T C _ S e tP re sca le r ustawia dzie
nik w stępny, tak aby licznik zegara czasu rzeczyw istego byl zw iększany z częst'
tliw ością 1 Hz. W spółczynnik podziału je s t o jed en w iększy od w artości argumeii
tej funkcji. F unkcje biblioteki S T M 32 m odyfikujące rejestry konfiguracyjne zeg ‘
czasu rzeczyw istego tylko inicjują tę operację. Z apis do rejestrów RTC trwa śt*
sunkow o długo (kilka taktów zegara LSE) i przed kolejnym zapisem lub odcz
tern, aby upew nić się, że poprzedni zapis się zakończył, trzeba w yw ołać funkii
RTC_W aitForLastTask.
N a koniec w funkcji R TC configure konfigurujem y przerw ania zegara czasu rzec>/?
w istego. Przerw anie RTC_IRQn je s t zgłaszane po każdym zw iększeniu licznika /.''
gara czasu rzeczyw istego, czyli w naszym przypadku co jed n ą sekundę. Przerwanie
alarm u RTCAlarm_IRQn jest zgłaszane przez licznik zegara czasu rzeczywistego,
po osiągnięciu zadanej w artości. Przerw ania konfigurujem y z niskim prioryteteiS!
w yw łaszczania, niższym niż biblioteka lwIP. N a razie nie aktyw ujem y przerw ali
Z ostaną uaktyw nione przez kolejne funkcje.
'.
Funkcja R T C setC allback ustaw ia funkcję zw rotną, która m a być w yw ołana po ka^I
dym w ystąpieniu przerw ania RTC_IRQn. Jej jed y n y m argum entem je s t adres funkęjlij
zw rotnej, która je s t bezparam etrow a i nie zw raca żadnej w artości. Jeśli argum ent
ten m a w artość NULL, to blokujem y przerw anie RTC_IRQn za pom ocą funkcji RTCji.'
IT C onfig - zerow any je st bil RTC__IT_SEC. W przeciw nym przypadku adres funkcji;'
zw rotnej zapisujem y w zm iennej globalnej c a llb a c k , a następnie aktyw ujem y prze*
rw anie RTC_IRQn - ustaw iany je s t bit RTC_IT_SEC.
,
static void (*callback)(void) = NULL;
void RTCsetCallback(void (*f) (void)) (
if (f == NULL) (
RTC_WaitForLastTask();
RTC_ITConfig(RTC_IT_SEC, DISABLE);
callback = £;
if (f) I
RTC_WaitForLastTask();
RTC_ITCon£ig(RTC_IT_SEC, ENABLE);
,,....
1
)
O bsługą przerw ania RTC_IRQn zajm uje się funkcja RTC_IRQHandler. Zeruje ona'
znacznik przerw ania (bit RTC_IT_SEC) i w yw ołuje funkcję zw rotną, jeśli została ona
skonfigurow ana.
"
£
void RTC_IRQHandler(void) (
if (RTCLGetITStatus(RTC_IT_SEC) != RESET) (
RTC_WaitForLastTask();
RTC ClearITPendingBit(RTC IT SEC);
201
if (callback)
callback ();
}
)
Licznik zegara czasu rzeczyw istego odczytujem y i m odyfikujem y odpow iednio za
pom ocą funkcji G etR ealT im eC lock i SetR ealT im eC łock.
uint32_t GetRealTimeClock(void) (
RTC_WaitForLastTask();
return RTC_GetCounter();
}
void SetRealTimeCłock(uint32_t t) (
RTC_WaitForLastTask(};
RTC_SetCounter(t);
}
Funkcja S tandby w prow adza m ikrokontroler w tryb czuw ania. A rgum entem tej
funkcji je s t czas, po którym m ikrokontroler m a się obudzić. Czas podajem y w se­
kundach. M ikrokontroler w ybudzi się, gdy w ystąpi zdarzenie alarm u, czyli gdy
licznik zegara czasu rzeczyw istego osiągnie w artość ustaw ioną za pom ocą funkcji
RTC_SetAlarm. N ie ma potrzeby aktyw ow ania przerw ania zw iązanego z alarmem .
Podanie jak o argum entu funkcji S tandby w artości 0 spow oduje uśpienie na 232 se­
kund, czyli w praktyce na czas nieograniczony. M ikrokontroler w tryb czuw ania
w prow adza funkcja PWR_EnterSTANDBYMode. Przedtem jednak za pom ocą funkcji
ETHpowerDown w stan; obniżonego poboru m ocy przełączam y rów nież interfejs
ethernetow y.
void Standby(uint32_t time) (
RTC_Wa i t ForLas tTa s k ();
RTC_SetAłarm(RTC_GetCounter{) + time);
RTC_WaitForLastTask{);
ETHpowerDown();
PWR_EnterSTANDBYMode();
}
A larm zegara czasu rzeczy w istego je st zgłaszany w ostatnim cyklu oscylatora LSE,
taktującego RTC, odpow iadającego sekundzie, w której alarm należy zgłosić. Zatem
rzeczyw isty czas do zgłoszenia alarm u m oże być nieco dłuższy od zadanego, w naj­
gorszym przypadku o niecałą sekundę.
C zasem pożądane m oże być przejście w tryb czuw ania z pew nym opóźnieniem .
Zajm uje się tym funkcja D elayedStandby. Pierw szym je j argum entem jest żądane
opóźnienie. D rugim argum entem je s t czas, po którym m ikrokontroler m a się obu­
dzić. O ba czasy podajem y w sekundach. C zas uśpienia zapam iętujem y w zmiennej
globalnej standbyT im e. O późnienie realizujem y za pom ocą alarm u zegara czasu
rzeczyw istego. A larm w yw ołuje przerw anie RTCAlarm_IRQn, które aktyw ujem y za
pom ocą funkcji RTC_ITConfig - ustaw iam y bit RTC_IT_ALR. A by zabezpieczyć się
przed fałszyw ym alarm em - rejestr alarm u m a zaw sze jak ąś w artość - w zmiennej
globalnej magicNumber ustaw iam y pew ną ustaloną w artość MAGIC_NUMBER. Jest bar­
dzo m ało praw dopodobne, że taka w artość znajdzie się tam przypadkow o,
idefine MAGIC_NUMBER 1836547290
stat^jL uint3£_t magicNumber;
stat‘
iSAurtL$fe|t standbyTime;
void Delayódiftandby (uint32_t delay, uint32_t time) 1
6.2. P rzykła d 6 a ~ p ierw sza w ersja klienta TCP
6. Klient TY.'/"
202
uint32_t pa r a m (PARAM_NUMBER);
uint32_t timer;
unsigned idx;
char msg[MSG_SIZE];
if (delay > 0) (
magicNumber = MAGIC_NUMBER;
standbyTime = time;
RTC_WaitForLastTask();
RTC SetAlarm(RTC_GetCounter() + delay);
RTC_WaitForLastTask();
RTC~ITConfig(RTC_IT__ALR, ENABLE);
1;
Składow a fu n c tio n struktury typu s t a t e je s t adresem funkcji, która m a być w yw o­
łana w celu obsłużenia odebranego kom unikatu. Pierw szym argum entem tej funkcji
je st w skaźnik do struktury typu s t a t e . D rugim argum entem je st w skaźnik do deskryptora T C P opisującego połączenie, z którego odbieram y kom unikaty. Składow a
param struktury typu s t a t e je s t tablicą param etrów klienta. W tej tablicy pod in­
deksem CONNECTIONJTIMEOUT przechow ujem y czas oczekiw ania na kom unikat. Po
przekroczeniu tego czasu klient, nie otrzym aw szy żadnego kom unikatu, zam yka
połączenie TCP. W tablicy param pod indeksem STANDBYJTIME przechow ujem y
czas przebyw ania klienta w trybie czuw ania. Składow a tim e r odlicza czas, przez
który klient będzie jeszcze czekał na kolejny kom unikat i po którego upłynięciu, nie
otrzym aw szy kom unikatu, zam knie połączenie. W artości czasów są w sekundach.
S kładow a msg służy do zgrom adzenia odbieranego kom unikat. Składow a id x je st
indeksem pierw szego w olnego znaku w tablicy msg, czyli je s t to liczba dotychczas
odebranych znaków kom unikatu. Stała MSG SIZE określa m aksym alną długość ko­
m unikatu pow iększoną o jed en , tak żeby w buforze zm ieściło się jeszcze term inalne
zero, zw ykle kończące napisy w języku C.
)
else
Standby(time);
)
V,
Przerw anie RTCAlarm_IRQn jest obsługiw ane przez funkcję RTCAlarm_IRQHandle:t;;ji
która w prow adza m ikrokontroler w tryb czuw ania, gdy w artość zm iennej magic-ijj'
Number zgadza się z w artością u staw ianą przez funkcję D elayedS tandby.
void RTCAlarmJRQHandler (void) (
if (RTC_GetITStatus(RTC_IT_ALR) != RESET)
EXTI_ClearITPendingBit(EXTI_Linel7);
RTC_WaitForLastTask();
RTC_ClearITPendingBit(RTC_IT_ALR);
if TraagicNumber == MAGICJtUMBER) 1
magicNumber = 0;
SŁandby(standbyTime);
(
)
K lienta urucham ia się za pom ocą funkcji T C P c lie n tS ta r t. Jej sygnatura znajduje
się w pliku tcp_client.h. Ta funkcja je s t przeznaczona do w yw ołania z program u
głów nego, dlatego w ołane w niej funkcje z biblioteki lw IP otoczone są m akram i
chroniącym i przed w spółbieżnym w ykonyw aniem kodu tej biblioteki. Pierw szy ar­
gum ent a d d r funkcji T C P c lie n tS ta r t je s t adresem IP serw era, z którym m a być
naw iązane połączenie TCP. D rugi argum ent p o r t je s t num erem portu, na którym
nasłuchuje serwer. Funkcja ta działa w edług diagram u klienta przedstaw ionego na
rysunku 4.4. Z w raca zero, gdy zostało zainicjow ane urucham ianie klienta, czyli gdy
udało się w ysiać segm ent SY N , a w artość ujem ną w przeciw nym przypadku. N a
początku alokujem y i inicjujem y strukturę typu s t a t e . N a razie param etry inicjuje­
my w artościam i dom yślnym i. Im plem entację czytania tych param etrów z rejestrów
zapasow ych odkładam y do następnego przykładu.
)
6.2.3.
Pliki tcp_client.h i tcpjclient.c
<
W pliku tcp_client.c znajduje się im plem entacja klienta realizującego protokół <
sany w rozdziale 6.1. Z aczynam y od zdefiniow ania stałych reprezentujących ko- - ■■
m unikaty, które odbiera klient. D efiniujem y też form aty kom unikatów , które kiieni
w ysyła. Ponadto definiujem y form aty param etrów kom unikatu SET.
»define TIME_FRM "%Y.%m.%d %H:%M:%S"
Idefine PARAM_FRM "%"U32_F" %"U32_F
static const char ok_msg(]
static const char s e tjn s g f]
static const char b y e jn s g U
static const char error_msg(]
static const char heilo_msg_frm{|
static const char param_msg_frm(]
static const char ok_time_msg__frm( ]
static const char ok_param_msg_frm(]
static const char bye_msg_frm(]
static const char error_msg_frm[]
static const char set_time_frm[]
static const char setj?aram_frmU
"OK";
"SET";
"BYE";
"ERROR";
"HELLO ”
TIME_FRM”\r\n";
"PARAM "PARAM_FRM"\r\n";
"OK "TIME_FRM"-YFYn";
"OK "PARAM_FRM»U\n";
"BYE "TIME_FRM"\r\n";
"ERROR "TIME_FRM"\r\n";
TIME_FRM;
PARAM FRM;
w
32
0
1
2
p
;
*
f.«i
struct state {
err_t (* function)(struct state
struct tcp_pcb *);
idefine DEFAULT_CONNECTION_TIMEOUT
Idefine DEFAULT_STANDBY_TIME
idefine POLL_PER_SECOND
30
20
2
int TCPclientStart (struct ip_addr *addr, uint!6_t port] (
struct tcp pcb *pcb;
struct state *state;
err_t err;
IRQ_DECL_PROTECT(x);
Stan klienta przechow ujem y w strukturze typu s t a t e .
łdefine MSG_SIZE
»define CONNECTIONJTIMEOUT
»define STANDBYJTIME
»define PARAM NUMBER
203
state = mem_malloc(sizeof(struct state));
if (state == NULL)
return -1;
state->function = HelloState;
/SlfcpO: Jj&zeczytać ustawienia z rejestrów zapasowych. */
staif->piifirltCONKęCTION_TIMEOUT) = DEFAULT_CONNECTION_TIM£OUT;
state->paraflli[STANDBY TIME] = DEFAULT STANDBY TIME;
205
6.2. Przykład 6a - pierwsza wersja klienta TCP
Jeśli zostaną odebrane dane lub połączenie zostanie norm alnie zam knięte przez ser­
wer, to biblioteka lw IP w yw ołuje funkcję zw rotną recv_callback. D ziałanie tej
funkcji je s t analogiczne ja k w przykładach 5a i 5b.
state->timer = state->param(CONNECTION_TXMEOUT];
state->idx = 0;
IRQ_PROTECT(x, LWIP_IRQ_PRIO) ;
pcb = tcp_new{);
IRQJJNPROTECT(x);
if {pcb « NULL) {
mem_free(state);
return -1;
#define ERR_£XIT 100
static err_t recv_callback(void *arg, struct tcp_pcb *pcb,
struct pbuf ‘p, err_t err) (
if ip) (
tcp_recved(pcb, p->tot_len);
err = StateAutomaton(arg, pcb, p ) ;
if (err == ERR_OK !| err == ERR_EXIT)
pbuf_free(p);
if (err == ERR_EXIT) {
tcp_ex.it(arg, pcb);
err~= ERR_OK;
i
IRQ_PROTECT(x, LWIP_IRQ_PRIO);
tcp_arg(pcb, state);
tcp_err(pcb, conn_err_callback);
tcp_recv(pcb, recv_całlback);
tcp_poii(pcb, poll_callback, POLL_P£R_SECOND);
IRQ UNPROTECT(x);
m
}
)
else (
tcp_exit(arg, pcb);
IRQ_PRO?ECT(x, LWIP_IRQ_PRIO);
err = ERR_0K;
err = tcp_connect{pcb, addr, port, connect callback);
IRQ_UNPROTECT(x);
if (err != ERR_OK) {
return err;
)
mem_free(state);
IRQ_PROTECT(x, LWIP_IRQ_PRIO) ;
tcp_abandon(pcb, 0);
IRQ_UNPROTECT(x);
return -1;
)
return 0;
Jeśli połączenie T C P do serw era zostanie ustanow ione, to biblioteka lw IP wywołuję:'1
funkcję zw rotną c o n n e c t_ c a łlb a c k , w której klient w ysyła do serw era komunią:
kat H ELLO . Funkcję tc p _ w rite _ tim e _ ra sg , w ysyłającą do serw era kom unikaty
znacznikiem czasu, opisuję nieco dalej.
static err_t connect_callback(void *arg, struct tcp_pcb *pcb,
err_t err) (
return tcp_write_time msg(pcb, hello_msg_frm);
i
Jeśli połączenie T C P nie zostanie otw arte lub zostanie zam knięte aw aryjnie (sl.i-ow ane), to biblioteka lw IP w yw ołuje funkcję zw rotną c o n n _ e rr_ c a llb a c k . W funltr
cji tej pow inniśm y zapisać do rejestrów zapasow ych param etry klienta, co zaimple­
m entujem y w następnym przykładzie. R eakcją ritr skasow anie połączenia T C P jest
w prow adzenie m ikrokontrolera w tryb czuw ania na czas określony przez parametr/
p aram [ STA N D B Y _ T I M E ] . Z aśnięcie opóźniam y o 2 sekundy, aby dać bibliotece Iv.lP ■
i interfejsow i E thernet szansę w ysiania kom unikatu kasującego połączenie TCP. Je
to potrzebne w sytuacji, gdy kasow anie połączenia je s t inicjow ane przez bibliotekę
lw IP po stronie klienta, co m oże być skutkiem w ystąpienia ja k ieg o ś błędu.
static void conn_errjsallback(void
struct state *statę =,arg;
)
arg, erf t err)
/* TODG: Zapisać ustawienia do rejestrów zapasowych.
DelayedStandby(2, state->param[STANDBY_TIME));
Połączenie T C P zam yka funkcja tcp_exit. N ie m usim y w niej zw alniać pam ięci
przydzielonej strukturze typu state, gdyż po zam knięciu połączenia m ikrokontro­
ler je s t w prow adzany w tryb czuw ania, a po obudzeniu rozpocznie w ykonyw anie
program u od początku, jakby został w yzerow any. Jeśli nie pow iodło się w yw oła­
nie funkcji tcp_close, to w yw ołujem y funkcję tcp_abort, która z kolei w yw ołuje
funkcję conn_err_callback. Jeśli w yw ołanie funkcji tcp_close zakończy się suk­
cesem , to w prow adzam y m ikrokontroler w tryb czuw ania na czas określony przez
param etr p a r a m [ S T A N D B Y _ T I M E ] . Jak poprzednio zaśnięcie opóźniam y o 2 sekundy,
aby dać bibliotece lw IP szansę dokończenia procedury zam ykania połączenia TCP.
Przed zaśnięciem pow inniśm y zapisać do rejestrów zapasow ych param etry klienta,
co zaim plem entujem y w następnym przykładzie.
static void tcp_exit(struct state *state, struct tcp pcb *pcb)
if (tcp_close(pcb) != ERR_OK ) (
tcp ab o r t (pcb);
(
1
else {
/* TODO: Zapisać ustawienia do rejestrów zapasowych. */
DelayedStandby (2, state->paramiSTANDBY_TIME] );
I
i
Przekroczenie czasu oczekiw ania na kom unikat obsługuje funkcja zw rotna p o ll _
c a llb a c k . Jeśli czas upłynie, czyli licznik tim e r zm niejszy się do zera, to w ysyła­
my kom unikat o błędzie i zam ykam y połączenie TCP.
static err_t polł_callback(void *arg, struct tcp_pcb *pcb)
struct state *state = arg;
if (— (state->tirner) <= 0) {
tcp_write_time_jnsg(pcb/ error_msg_frm);
tcp_exit(arg, pcb);
{
6.2. Przykład 6a - pierwsza wersja klienta TCP
Funkcja tc p _ w rite _ tim e_ m sg w ysyła kom unikat zaw ierający znacznik czasu (
i czas w ysłania kom unikatu). P rotokół nakazuje w ysyłać znacznik czasu tylko w
m unikacie H ELLO , ale nie zabrania w ysyłania go w innych kom unikatach, Dlateg
w szystkie kom unikaty w ysyłane przez klienta, jeśli to tylko m ożliw e, zawieraj
znacznik czasu, co ułatw ia testow anie program u. Pierw szy argum ent pcb funkcj
tc p _ w rite _ tim e _ m sg je st w skaźnikiem do deskryptora T C P opisującego połączenie
przez które ma być w ysłany kom unikat. D rugi argum ent fo rm a t je s t wskaźnikiem*
do stałego napisu zaw ierającego form at kom unikatu do w ysłania. Funkcja zwraoa
kod zakończenia typu e r r _ t zgodnie z konw encją stosow aną w bibliotece IwIP, ‘
static err_t tcp__write_time_msg (struct tcp_pcb *pcb,
const char ‘format) {
char msg(MSG_SIZE];
time_t rtime;
struct tm tm;
size_t size;
SYS_ARCH_DECL_PROTECT(x);
rtime = GetRealTimeClock();
if (localtime_rf&rtime, &tm) == NULL)
return ERR__OK;
SYS_ARCH_PROTECT(x );
size = strftime(msg, MSG_SIZE, format, &tm);
SYS_ARCH_UNPROTECT(x);
return tcp__write (pcb, msg, size, TCP_WRITE_FLAG_COPY);
struktury typu s t a t e , w której są przechow yw ane param etry klienta. Trzeci argu­
m ent fo rm a t je s t w skaźnikiem do stałego napisu zaw ierającego form at kom unikatu
do w ysłania. Funkcja zw raca kod zakończenia typu e r r t zgodnie z konw encją
stosow aną w bibliotece IwIP.
static err_t tcp_write_param_msg(struct tcp_pcb *pcb,
s t ruct State *s,
c onst char ‘formatl
(
char msg(MSG_SIZEJ;
size_t size;
SYS_ARCH_DECL_PROTECT(x);
S m
'J?
SYS_ARCH_PROTECT(x);
size = snprintf(msg, MSG_SIZB, format,
s->param(CONNECTION_TIMEOUT],
s->param(STANDBY_TIME));
SYS_ARCH_UNPROTECT(x);
i f T size >= MSG_SIZE)
s i z e = MSG_SIZE - 1;
r e tu rn tcp _write (pcb, msg, s i z e , TCP_WRITE_F1,AG_C0PY) ;
'%
i
,fi
)
Funkcja tcp_w rite_param _m sg korzysta z funkcji s n p r i n t f , która nie je s t w spół­
używ alna i dlatego jej w yw ołanie otoczone je s t m akram i blokującym i przerw ania.
F unkcja s n p r i n t f um ieszcza w buforze msg m aksym alnie MSG_SIZE znaków, w łą­
czając term inalne zero. N atom iast zw raca liczbę bajtów, które zostałyby um iesz­
czone w buforze, gdyby miał on dostateczny rozm iar, ale nie w łączając term inal­
nego zera. D latego jeśli w artość zm iennej s i z e je s t w iększa lub rów na MSG_SIZE,
to oznacza, że napis nie zm ieścił się w buforze msg i został obcięty. K om unikat
w ysyłam y za pom ocą funkcji tc p _ w r ite , naw et jeśli nie zm ieścił się w buforze.
N ie w ysyłam y term inalnego zera.
. -'i
\
;
}
~
4
W funkcji tc p _ w rite_ tim e _ m sg najpierw za pom ocą funkcji GetRealTimeClc.-.'
odczytujem y liczbę sekund, które upłynęły od pdczątku epoki U niksa, czyli odj
1 stycznia 1970 roku, a następnie konw ertujem y ją na datę i czas za pom ocą funk“,
cji lo c a ltim e r z biblioteki standardow ej C. Jeśli konw ersja się nie powiedzie;'1,
to nie m ożna nic rozsądnego zrobić i funkcja kończy działanie, zw racając ERR_'d,„;
Funkcja s t r f t i m e z biblioteki standardow ej C form atuje kom unikat i umieszcza;,
go w buforze msg, ale kopiuje do tego bufora nie w ięcej niż MSG_SIZE bajtów, wli­
czając term inalne zero. N atom iast zw raca liczbę bajtów um ieszczonych w bufoi/.e,
nie w liczając w to term inalnego zera. P oniew aż funkcja ta nie je s t współużywalna,
jej w yw ołanie otoczone je s t m akram i blokującym i przerw ania. F unkcja tcp _ w rit e w ysyła kom unikat, zgodnie ze specyfikacją protokołu, bez term inalnego zeia.
Struktura tm jest zdefiniow ana w bibliotece standardow ej C.
struct tm {
int tm_sec;
int tmjnin;
int tm_hour;
int tmjnday;
int tm_mon;
int tm_year;
int tm_wday;
int tm_yday;
int tm isdst; /*
207
Funkcja S tateA utom aton obsługuje autom at stanow y klienta. Jej pierw szy argu­
m ent s je s t w skaźnikieni do struktury zaw ierającej stan autom atu. D rugi argum ent
pcb je s t w skaźnikiem do deskryptora T C P opisującego połączenie, z którego ode­
brano kom unikat. Trzeci argum ent p je s t w skaźnikiem do łańcucha buforów, któ­
re zaw ierają odebrane dane. Funkcja zw raca kod zakończenia typu e r r _ t zgodnie
z konw encją stosow aną w bibliotece Iw IP lub w artość ERR_EXIT, gdy połączenie
T C P m a zostać zam knięte.
static err_t StateAutomaton(struct state *s, struct tcp_pcb *pcb,
struct pbuf *p) {
s->timer » s->param[C0NNECTI0N_TIME0UT];
for {;;) {
uint8_t *c = (uint8_t *)p->payload;
uintl6_t i;
err_t err;
sekunda */
minuta */
godzina */
dzień miesiąca */
miesiąc */
rok */
dzień tygodnia */
dzień roku */
znącznik czasu letniego 7
);
Funkcja tcp_w rite_j>aram _m sg w ysyła kom unikat PARAM z param etram i klienta.
Pierw szy argum ent pcb je st w skaźnikiem do deskryptora T C P opisującego połącze­
nie, przez które m a być w ysłany kom unikat. D rugi argum ent s je s t w skaźnikiem do
Ht
‘
ff,
for (i = 0; i < p->łen; ++i) (
i f (c [i ] == ,\n/) {
s->msg(s->idx++) = cji];
s->msg[s->idx) = '\0';
s->idx = 0;
. err = s->function (s, pcb);
'iw
ii M v 'c != ERR_0K)
• r e t u r n err;
;
. iń
208
6. Klient l e p '
else if (s->idx < MSG_SIZE - 2)
s->msg[s->idxt+J = c [i };
}
if (p->len == p->tot_len)
break;
else
p = p->next;
)
return ERR_OK;
!
W funkcji S tateA u to raato n przeglądam y odebrany kom unikat znak po znakuj
D opóki nie napotkam y znaku L F (w języ k u C zapisyw anego ja k o ' \ n '), kopiujemyj
kolejne znaki kom unikatu do bufora msg, który je s t składow ą struktury typu s ta te r
K opiujem y m aksym alnie MSG SIZE - 2 znaków , aby w buforze pozostało jeszcze
m iejsce na znak LF i term inalne zero. Jeśli napotkam y znak LF, w staw iam y go';
w raz z term inalnym zerem do bufora msg i w yw ołujem y funkcję w skazyw aną pi/oz
składow ą f u n c tio n struktury typu s t a t e . D la każdego stanu je st zdefiniowaną,
funkcja, której nazw a je s t taka sam a ja k nazw a stanu i która obsługuje komunikaty'
odebrane w tym stanie. A utom at klienta m a dw a stany, w ięc są dw ie takie funkcje,
H e llo S ta te i P aram S tate. Pierw szy argum ent s t a t e tych funkcji je s t wskaźnikier/.
do struktury typu s t a t e . D rugi argum ent pcb je s t w skaźnikiem do deskryplora T( 'P
opisującego połączenie. Funkcje te zw racają kod zakończenia typu e r r _ t zgodnie:
z konw encją stosow aną przez bibliotekę lw IP lub w artość ERR_EXIT, gdy połączenie
T C P ma zostać zam knięte.
fdefine msglen(s) (sizeof(s) - 1)
Idefine msgncmp(sl, s2, n) \
(strncmp(sł, s2, n) == 0 && isspace((int)sl[nj))
6.2. Przykład 6a - pierwsza wersja klietita TCP
else if {msgncmp(state->msg, bye_msg, msglen(byejnsg)) i i
msgncmp{state->msg, errorjnsg, msglen(errorjnsg)))
return ERR_EXIT;
else {
tcp_write_time__msg (pcb, error_msg__frm);
return ERR__EXIT;
)
}
Funkcja H e llo S ta te realizuje górną część diagram u z rysunku 6.1. Funkcja s t r p ­
tim e z biblioteki standardow ej C konw ertuje datę i czas reprezentow ane za pom ocą
napisu do postaci struktury typu tm. Z w raca zero, gdy konw ersja się nie pow iodła.
F unkcja mktime też z biblioteki standardow ej C konw ertuje datę i czas reprezento­
wane za pom ocą struktury tm na liczbę sekund, które upłynęły od początku 1 stycz­
nia 1970 roku. Z w raca w artość -1 zrzutow aną na typ tim e _ t, gdy konw ersja się
nie pow iodła.
łdefine
idefine
łdefine
łdefine
1
if (!strptime(state->msg + msglen{setjnsg), set_time_frm, &tm)) {
tcp_write_timejnsg(pcb, error_msg_frm);
—
return ERR_ EXIT;
".,v
j
1
else (
state->param[CONNECTION_TIMEOUT] = timeout;
state->param(STANDBY_TIME3 = sleep_time;
tcp_write__param_msg (pcb, state, ok_param_msg_f rm);
tcp_write_time_msg (pcb, bye_msg_frm);
I
}
~
SYS_ARCHJ?HOTECT(x);
ret = sscanf(state->msg + msglen(setjnsg), set_param_frm,
&timeout, &sleep__time);
SYS_ARCHJJNPROTECT(x) ;
if (ret != 2 H
timeout < MIN_CONNECTIOK_TIMEOOT ||
timeout > MAX_CONNECTIONJfIMEOUT |[
sleep_time < MIH_STANDBY_TIME 1|
sleep_time > MAX_STANDBY_TIME) {
tcp_write_time_msg(pcb, error_msg_frm);
}
!
5
600
1
1800
else if (msgncmp(stateu >msg, setjnsg, msglen(setjnsg))) {
uint32_t timeout, sleep time;
int ret;
SYS_ARCH_DECL_PROTECT(x);
else if {msgncmp{state->msg, setjnsg, msglen(setjnsg))) {
err_t err;
time_t t;
struct tm tm;
SetRealTimeClock(t);
err = tcp_write_timejnsg(pcb, ok_timejnsgjfrm);
if (err != ERR_OK)
>
return err;
state->jfunction = ParamState;
return tcp__write_param_msg (pcb, state, paramjnsg_f rm);
MXN_C0NNECTI0N_TIME0UT
MAX_CONNECTION_TIMEOUT
MIN_STANDBY_TIME
MAX_STANDBY_TIME
static err_t ParamState(struct state *state, struct tcp_pcb *pcb) {
if (msgncmp(state->msg, okjnsg, msglen(ok_msg))} 1
tcp_write time_msg(pcb, byejnsg_frm);
static err_t HelloState{struct state ‘state, struct tcp_pcb *pcb) {
if {msgncmp(state->msg, okjnsg, msglen(okjnsg))) {
state->function = ParamState/
return tcp write__paramjnsg (pcb, state, paramjnsg_frm) /
t = mktime(&tm);
if {t == (time_J:)-l) (
tcp_write_time_msg(pcb, error jnsg_frm);
return ERR_EXIT;
20 9
i
)
else if (¡msgncmp(state->msg, byejnsg, msglen(byejnsg)) &&
!msgncmp(state->msg, errorjnsg, msglen(errorjnsg)))
tcp_write_time_msg(pcb, errorjnsg_frm);
return ERR_EXIT;
Fuńfeja#sf6):an>State realizuje dolną część diagram u zam ieszczonego na rysun­
ku 6.1. N ajiparam etry czasow e nakładam y pew ne ograniczenia. D olne ograniczę-
210
łdefine error_temporary(expr, err) \
if ((expr) < 0 ) 1
\
int i;
\
for (i = 0; i < 3; ++i) (
\
Error(err);
\
nie na czas oczekiw ania na kom unikat zabezpiecza klienta przed ustaw ienie
krótkiego czasu, który uniem ożliw iłby odebranie kom unikatu. D olne ogranie ż e n ili
na czas uśpienia zabezpiecza przed zerow ą w artością tego czasu, co oznaczałoby?
w praktyce uśpienie na zaw sze - patrz opis funkcji Standby. G órne ograniczenia ngj
param etry klienta m ają ułatw ić je g o testow anie. O dczyt param etrów z komunikatij|
SE T w ykonujem y za pom ocą funkcji s s c a n f z biblioteki standardow ej C. Funkćjai
ta nie je s t w spółużyw alna.
«|'i|
I
Standby(10);
Plik utiljerror.h
„V -j
fdefine error_permanent(expr, err) error_check(expr, err)
)
\
\
\
\
►
\
I
Błędy, których przyczyna m oże ustąpić po w yzerow aniu m ikrokontrolera, obsługuje
m akro e r r o r _ r e s e t a b l e . Za pom ocą tego m akra najpierw inform ujem y o rodzaju
błędu, trzykrotnie w yw ołując funkcję E rro r , a następnie zerujem y mikrokontrolci
za pom ocą funkcji NVIC_SystemReset z biblioteki STM 32. M ikrokontroler STM32
podczas zerow ania w ym usza stan niski na w yprow adzeniu R E S E T , dzięki czemu
cale urządzenie je st restartow ane.
f
fdefine error_resetable(expr, err)
if {(expr) < 0) i
int i;
for (i = 0 ; i < 3; ++i) (
Error(err);
int main{) {
static struct netif netif;
static struct ethnetif ethnetif = {PHY_ADDRESS};
static struct ip_addr addr;
uint8_t confBit;
il
■' |
Delay(1000000);
confBit = GetConfBit{);
AllPin s D i s a b l e O ;
LEDconfigure();
RedLEDonO;
SET_IRQ_PROTECTION{);
error_resetable(CLKconfigure{), 1);
error_permanent(LocalTimeConfigure{), 2);
error_resetable(RTCconfigure{), 3);
error_resetable (ETHconfigureMII (), 4);
.ty
1
NVIC_SystemReset();
D o obsługi błędów, których przyczyna m oże ustąpić po pew nym czasie, przezna­
czone je s t m akro e rrq r_ te m p o ra ry . N ajpiąrw inform ujem y o rodzaju błędu, trzy­
krotnie w yw ołując funkcję E rro r , a następnie w prow adzam y m ikrokontroler w stan
czuw ania na 10 sekund. C zas czuw ania m ożna oczyw iście w ydłużyć lub uczynić
go param etrem makra. Po w ybudzeniu m ikrokontroler rozpoczyna wykonywanie
program u od początku.
Plik ex_tcp_client.c
Plik ex_tcp_client.c zaw iera funkcję main przykładu. F unkcja ta je s t w sw ojej struk­
turze bardzo podobna do funkcji main z poprzednich przykładów . G łów na różni­
ca polega na tym , że używ am y m akr z pliku util_error.h. B łędy zgłaszane przez
funkcje urucham iające układy sprzętow e zaklasyfikow ano jak o takie, które m ogą
ustąpić po w yzerow aniu m ikrokontrolera i restarcie urządzenia. D latego funkcje
urucham iające układy sprzętow e w ołane są za pom ocą m akra e r r o r _ r e s e t a b l e ,
które zeruje m ikrokontroler, gdy funkcja zasygnalizuje błąd. W yjątkiem jest funk­
cja L o calT im eC onfigurę, gdyż analiza jej tekstu źródłow ego w skazuje, że je d y ­
nym pow odem jej błędnego działania m oże być funkcja S ysT ick_C onfig, która
zakończy się niepow odzeniem tylko wtedy, gdy otrzym a niepopraw ną w artość
param etru. Taki błąd nie ustąpi po w yzerow aniu m ikrokontrolera. D latego funk­
cję L o calT im eC onfigure w yw ołujem y za pom ocą m akra e rro r_ p e rm a n e n t. Błędy
zgłaszane przez funkcje urucham iające protokoły sieciow e zaklasyfikow ano jako
chw ilow e problem y z siecią, które najpraw dopodobniej ustąpią po pew nym czasie.
D latego te funkcje w yw ołujem y za pom ocą m akra e r r o r tem porary.
D otychczas na w szystkie błędy pod czas urucham iania program u reagow aliśm yn
je g o zaw ieszeniem w nieskończonej pętli - m akro e rro r_ c h e c k . W poprzeddjfajfl
rozdziale w celu w y prow adzenia m ikrokontrolera z tego stanu używ aliśm y nàd»';;f|
zorcy. W tym podrozdziale p o kazuję inne rozw iązanie tego problem u. W pliku'ï*!
util_error.h zdefiniow ane są m akra służące do obsługi błędów . P ierw szym argU-*$l
m entem każdego z tych m akr je s t w yw ołanie funkcji, która zw raca w artość zeró,®
przy popraw nym zakończeniu, a w artość ujem ną, gdy w ystąpi! błąd. R odzaj błędCF
sygnalizuje funkcja E rro r , która m iga czerw oną d iodą św iecącą. D rugi argu .
m akra określa liczbę m ignięć. D o obsługi błędów , których przyczyna w ydaje mc
nieusuw alna, przeznaczone je s t m akro e r r o r jo e r m a n e n t. M akro to zaw iesza pro- ;V.
gram i tak napraw dę je s t przem ianow anym m akrem e rr o r_ c h e c k zdefiniow anym '3
w pliku util_led.h.
łdefine error_check(expr, errl
if ((expr) < 0) {
for (;;) {
Error(err);
\
\
1
6.2.5.
6.2.4.
211
6.2. Przykład 6a - pierwsza wersja klienta TCP
6- Klient / q J
SijJ
•■
netif.hwaddr[0] = 2;
netif.hwaddrdJ = (BOARDJTYPE » 8) 6 0xff;
netif.hwaddr[2] = BOARD TYPE & Oxff;
netif,hwaddr(3] - {ETH_BOARD » 0) & 0xff;
netif.hwaddr|4) = ETH_BOARD & Oxff;
netif.hwaddr(5] * 1 + confBit;
if (¡confBit) {
IP4_ADDR(&netif.ip_addr, 192, 168, 51, 84);
IP4__ADDR(&netif .netmask, 255, 255,255, 240);
.jli|^_ADD^(Snetif ,gw,
192, 168, 51,
81);
else i
, jil
-
212
6. Klient T( p
IP4_ADDR(&netif.ip_addr,
IP4_ADDR(6netif.netmask,
IP4_ADDR(&netif.gw,
O, O,
O, O,
O, O,
O, 0);
O, 0);
O, O J ;
)
error_temporary(LWIPinterfacelnit(&netif, Łethnetif), 5);
LWIPtimersStart(};
error_temporary(DHCPwait(&netif, 10, 4), 6);
IP4_ADDR{&addr, 192, 168,
51, 88);
error_temporary{TCPclientStart Uaddr, 22222), 7);
RedLEDoff () ;
for
W zestaw ie Z L29A R M sposób uzyskania ustaw ień sieciow ych w ybieram y jak po­
przednio za pom ocą zw orki B O O T1. Po uruchom ieniu biblioteki lw IP i skonfipu- J
row aniu ustaw ień sieciow ych urucham iam y klienta. Łączy się on z serw erem , który Ć
nasłuchuje pod adresem 192.168.51.88 na porcie 22222. Podczas całego procesu ,»3
konfigurow ania św ieci się czerw ona dioda. Jej zgaśnięcie oznacza koniec urucha- ■;
m iania, a m iganie sygnalizuje w ystąpienie problem u.
6.2.6.
Testowanie przykładu
Do przetestow ania przykładu je st potrzebny serw er TCP. M ożna w tym celu uz
program u netcat, który je s t standardow o um ieszczany w dystrybucjach L im iku
i urucham iany poleceniem nc. Jest też dostępna w Internecie je g o darm ow a w
sja przeznaczona dla system ów W indow s. P rogram netca t, którego używałem
_
do testow ania przykładów w środow isku W indow s, zn ajduje się w pliku n c lh
zip w archiw um z przykładam i w katalogu ./m ain/netcat. N etcat je s t narzędziem ■
używ anym z linii poleceń (ang. co m m a n d linę). C zyta ze standardow ego wejść
i pisze na standardow e w yjście. Ł atw o daje się go użyć w skrypcie. W ta b e li a *
zam ieszczone są przykładow e sposoby je g o uruchom ienia. W p ierw szym wii
jest polecenie urucham iające serw er tylko na je d n o połączenie - netcat końc.
d ziałanie po zam knięciu p o łączenia. W drugim w ierszu je s t polecenie umożliw
ją c e odbieranie w ielu kolejnych połączeń od klienta. Jeśli nie będzie ono dzii
popraw nie, to m ożna użyć, zam ieszczonych w o statnim w ierszu tabeli, poleceń . -/i
u rucham iających serw er w nieskończonej pętli.. ,Wr przypadku L inuksa całą sekw encję poleceń m ożna po prostu w pisać w linii poleceń. W przypadku Window
trzeba utw orzyć plik w sadow y (z rozszerzeniem bat) z podaną w tabeli sekwen«
poleceń.
Tab. 6.3. Uruchamienie serwera
Linux
nc -1 22222
nc -lk 22222
while truei do nc -1 22222; done
W indows
nc -1 -p 22222
nc -L -p 2^222
Secho off
:forever
nc -i -p 22222
goto forever
3
6.2. P rzykład 6a - pierwsza wersja klienta TCP
213
Pierw szy test polega na ogólnym spraw dzeniu działania klienta oraz działania ze­
gara czasu rzeczyw istego i trybu czuw ania. N a w szystkich poniższych w ydrukach
kom unikaty bez param etrów i kom unikaty S E T są w ysyłane przez serwer, czyli są
w pisyw ane z konsoli, a pozostałe kom unikaty pochodzą od klienta.
HELLO 1970.01.01 00:00:03
OK
PARAM 30 20
OK
BYE 1970.01.01 00:00:11
HELLO 1970.01.01 00:00:38
SET 2010.08.05 12:00:00
OK 2010.08.05 12:00:00
PARAM 30 20
OK
BYE 2010.08.05 12:00:01
Po w łączeniu zasilania zegar czasu rzeczyw istego zaczyna odliczanie od północy
1 stycznia 1970 roku. M iędzy kom unikatem B Y E a H E L L O upłynęło 27 sekund.
M ikrokontroler spal przez 20 sekund, a pozostałe 7 sekund zajęło ponow ne uru­
chom ienie klienta. Przekroczenie czasu m ożna przetestow ać, nie odpow iadając na
kom unikat H ELLO .
HELLO
ERROR
HELLO
ERROR
2010.08.05
2010.08,05
2010.08.05
2010.08.05
12:00:28
12:00:58
12:01:25
1 2 :01:5Ś
M iędzy kom unikatem H EL L O a E R R O R upłynęło zgodnie z oczekiw aniem 30 se­
kund. M iędzy kom unikatem E R R O R a H EL L O upłynęło ja k poprzednio 27 sekund.
K olejny test polega na próbie zm iany param etrów.
HELLO 2010.08.05 12:10:51
OK
PARAM 30 20
SET 10 10
OK 10 10
BYE 2010.08.05 12:10:57
HELLO 2010.08.05 12:11:14
OK
PARAM 30 20
OK
BYE 2010.08.05 12:11:20
O ba param etry czasow e klienta zostały zm ienione na 10
dzy kom unikatem B Y E a H EL L O upłynęło 17 sekund,
10 sekund i urucham iał się ponow nie przez następne 7
przyw rócono dom yślne w artości param etrów . N a koniec
w ać, czy klient popraw nie reaguje na błędne kom unikaty.
HELLO 2010.08.05 12:16:28
KO
ERROR 2010.08.05 12:16:30
HELLO 2010.08.05 12:16:57
I
ERROR 2010-.0$j05 12:17:03
sekund. Tym razem m ię­
czyli klient spał zadane
sekund. Po w ybudzeniu
należałoby też przetesto­
6.3. Przykład 6b - klient TCP z. obsługą rejestrów zapasowych
Przykład 6b - klient TCP z obsługą rejestrów
zapasowych
215
strów zapasow ych ja k o pam ięć 21 słów czterobajtow ych (ang. words). Jedno z tych
słów rezerw ujem y na sum ę kontrolną (C R C , ang. cyclic redundancy check), o czym
poniżej. Z atem w ST M 32F107 do dyspozycji pozostaje nam 20 słów pam ięci za­
pasow ej. A by uczynić oprogram ow anie m ożliw ie przenośnym , definiujem y stałą
BKPwords, która oznacza liczbę stów m ożliw ych do zapisania w pam ięci zapaso­
wej.
N azw y plików przykładu 6b zam ieszczone są w ta b e li <5.4. W dalszym ciągu opisu^
ję tylko różnice w stosunku do przykładu 6a.
Pliki util_bkp.h i util_bkp.c
static const int BKPwords =
(sizeof(BKPdataReg) / (2 * sizeof(BKPdataReg[0]))) - 1;
Pliki ulil_bkp.li i util_bkp.c zaw ierają im plem entację funkcji obsługujących reje- ,
stry zapasow e. Poszczególne m odele m ikrokontrolerów z rodziny STM 32 mają!
różną liczbę rejestrów zapasow ych. N iektóre m ają ich tylko 10. M ikrokontroler
ST M 32F107 w yposażono w 4 2 dw ubajtow e rejestry, których zaw artość je st pod-"'
trzy m yw ana przez zasilanie podłączone do w yprow adzenia V BAT. R ejestry te nieste-:'
ty nie zajm ują ciągłego obszaru pam ięci w przestrzeni adresow ej m ikro k o n tro ler.
Ż eby łatwiej było się nim i posługiw ać, w bibliotece S T M 32 zdefiniow ano stale
BKP_DR1 do BKP_DR42. K ażdej z tych stałych przypisano w artość przesunięcia (an g ,1
offset), pod którym znajduje się odpow iedni rejestr zapasow y. Przesunięcia są wy-A
znaczane w zględem adresu 0x40006C 00. Ż eby m ożna było traktow ać rejestry za- 1
pasow e jak o ciągły obszar pam ięci o rozm iarze 84 bajtów, będziem y je adresować-;
pośrednio za pom ocą tablicy BKPdataReg.
Podukład m ikrokontrolera odpow iedzialny za obsługę rejestrów zapasow ych kon­
figurujem y za pom ocą funkcji B K Pconfigure, która w łącza potrzebne sygnały tak­
tujące i uaktyw nia dostęp do tych rejestrów . U aktyw nia też układ liczący sprzę­
tow o sum ę kontrolną. D o je j obliczania je s t używ any ten sam w ielom ian, który
je s t stosow any do w yliczania sekw encji kontrolnej ram ki ethernetow ej. Z aw artość
rejestrów zapasow ych m ożna skasow ać za pom ocą w yprow adzenia PC 13 m ikro­
ko n tro lera (ang. tam per). W zestaw ie Z L 29A R M do tego w yprow adzenia podłą­
czony je s t przycisk SW 4, który po w ciśnięciu w ym usza na tym w yprow adzeniu
stan niski.
static const uintl6_t
BKP_DR1, BKP_DR2,
BKP_DR7, BKP_DR8,
BKP_DR13, BKP_DR14,
BKP_DR19, BKP_DR20,
BKP_DR25, BKP_DR26,
BKP_DR31, BKP_DR32,
BKP DR37, BKP DR38,
BKPdataReg|] = {
BKPJDR3, BKP__DR4,
BKP_DR9, BKPJJR10,
BKP_DR15, BKP_DR16,
BKP_DR21, BKP_DR22,
BKP_DR27, BKP_DR28,
BKP_DR33, BKP_DR34,
BKP_DR39, BKP_DR40,
BKP_DR5,
BKP_DRll,
BKP_DR17,
BKP_DR23,
BKP_DR29,
BKP_DR35,
BKP_DR41,
void BKPconfigure(void) (
RCC_APBlPeriphClockCmd(RCC_APBlPeriph_PWR | RCC_APBlPeriph_BKP,
ENABLE|;
RCC_AHBPeriphClockCmd(RCC__AHBPeriph_CRC, ENABLE);
PWR BackupAccessCmd(ENABLE);
BKP_ClearFlag();
BKP TamperPinLevelConfig(BKP_TamperPinLevel_Low);
BKP_DR6,
8KPJ)R12,
BKP_1)R1B,
BKPJ3R24,
BKP_DR30,
BKP_DR36,
BKP_DR42
BKPJTamperPinCmd(ENABLE);
)
Stała BKPwords je st w idoczna tylko w ew nątrz jednostki translacji util_bkp.c.
A by uzyskać do niej dostęp z innych jed n o stek translacji, definiujem y funkcję
BKPnumberWords.
1;
Poniew aż m ikrokontrolery S T M 32 są 32-bitow e, w ygodnie i efektyw nie je st p r/e
sylać dane w porcjach czterobajtow ych. D latego będziem y traktow ać pam ięć rejeTab.
int BKPnumberWords(void) {
return BKPwords;
- V
)
Funkcja BKPwrite zapisuje dane do pom ięci zapasow ej. Pierw szy argum ent d a ta
je s t w skaźnikiem do tablicy słów, które m ają być zapisane. Drugi argum ent co u n t
je st liczbą słów do zapisania. F unkcja zw raca liczbę faktycznie zapisanych słów.
K ażde słow o zapisujem y w dw óch kolejnych rejestrach zapasow ych. N a końcu za­
pisujem y sum ę kontrolną, która pozw ala zw eryfikow ać popraw ność późniejszego
odczytu i co być m oże w ażniejsze, pozw ala leż stw ierdzić, czy odczytane zerow e
dane są w ynikiem w yzerow ania zaw artości rejestrów zapasow ych, czy rzeczyw iście
takie dane w nich zapisano.
cc.h
cortex-m3.h
Iwipopts.h
stm 32t10x cont.h
int BKPwrite (const uint32__t ‘
data, int count) {
int idx;
uint32_t crc;
6.4. Pliki przykładu 6b
Źródłowe i biblioteczne
ex tcp clnt bkp.c
startup stm 32 cld.c
tcp_client_bkp.c
board conf.c
board init.c
boardJe d .c
tcp client, h
board cont.h
board def.h
boarfi dets.h
board init.h
b o a rd je d .h
u til bkp.c
u til delay, c
util_etli_nc.c
u til J e d .c
u tiljw ip .c
u t iljtc . c
u til tim e.c
Iiblwip4.a
■Iibsten32i10x.a
Nagłówkowe
-
u til bkp.h
u til delay.h
u til error.h
u til eth.h t
u tilje d .li
u tiljw ip .li
u t iljt c . li
u til time.h
i m
■at
v
*
if®,county > BKPwords)
^unt^*P &KPwords;
CRC ResetP${};
6.3. Przykład 6h - klient TCP z obsługą rejestrów zapasowych
Pozostałe różnice polegają na zapam iętaniu param etrów klienta w rejestrach za­
pasow ych przed uśpieniem m ikrokontrolera w funkcjach, które kończą działanie
klienta, czyli co n n _ _ err_ callb ack i tc p _ e x it.
for (idx = 0; idx < count; ł+idx) {
BKP__WriteBackupRegister(BKPdataReg(2 * idx],
data[idx] & 0xffff);
BKP_WriteBackupRegister(BKPdataReg[2 * idx + 1 ] ,
static void conn_err_callback(void *arg, err_t err) (
struct state ‘
state = arg;
data{idx] >> 16);
CRC^CalcCRC{data[idx]);
BKPwrite(state->param, PARAM_NUMBER);
DelayedStandby(2, state->param(STANDBY_TIME));
}
crc = CRC__GetCRC () ;
BKP_WriteBackupRegister(BKPdataReg[2 * idx], crc £ Qxffff);
BKP_WriteBackupRegister(BKPdataReg(2 * idx + ł], crc » 16);
return idx;
)
static void tcp_exit(struct state ‘
state, struct tcp_pcb *pcb) {
if (tcp_close(pcb) != ERR_OK) |
tcp_abort(pcb);
)
)
Funkcja BKPread odczytuje dane z pam ięci zapasow ej. Pierw szy argum ent data jest
w skaźnikiem do tablicy słów, gdzie m ają być um ieszczone odczytane dane. Drugi1
argum ent c o u n t je s t liczbą słów do odczytania. F unkcja zw raca liczbę odczytanych
słów albo w artość ujem ną, gdy nie zgadza się sum a kontrolna.
int BKPread(uint32_t *data, int count)
else {
BKPwrite(state->param, PARAM_NUMBER);
DelayedStandby(2, state->param(STANDBY_TIME]);
)
1
1
int idx;
uint32_J: crc;
6.3.3.
data(idx] = BKP_ReadBackupRegister(BKPdataReg(2 * idxj) f
(BKP_ReadBackupRegister(BKPdataReg[2 * idx + 1 ] ) « 16);
crc = BKP_ReadBackupRegister(BKPdataReg [2 * idx}) |
(BKP^ReadBackupRegister(BKPdataReg[2 * idx + 1]) « 16);
BKPconfigure{);
6.3.4.
i
Testowanie przykładu
P rzykład pow inien najpierw przejść pozytyw nie w szystkie testy, którym i byl te­
stow any poprzedni przykład. N astępnie m ożna przystąpić do testow ania rejestrów
zapasow ych. N ajpierw próbujem y zm ienić w artości param etrów klienta.
CRC_ResetDR{);
if (crc !- CRC_CalcBłockCRC(data, idx))
return -1;
return idx;
HELLO 2010.08.05 12:25:29
OK
PARAM 30 20
SET 10 10
OK 10 10
BYE 2010.08.05 12:25:35
Plik tcp_client_bkp.c
Plik tcp_client_bkp.c zaw iera im plem entację klienta realizującego rozw ażany w tym
rozdziale protokół i dodatkow o w yposażonego W .flbsługę rejestrów zapasowych.
W stosunku do im plem entacji klienta z pliku tc p ^ lie n t.c są tylko trzy różnice.
Pierw sza różnica w ystępuje w funkcji T C P c łie n tS ta r t. Spraw dzam y, czy rejestry
zapasow e zaw ierają param etry klienta i jeśli zaw ierają, to je czytam y. Jeśli nie uda
się odczytać param etrów , to są one inicjow ane w artościam i dom yślnym i.
Spraw dzam y, czy rzeczyw iście param etry zapisano.
HELLO 2010.08.05 12:25:51
OK
PARAM 10 10
OK
BYE 2010.08.05 12:25:54
HELLO 2010.08.05 12:26:10
ERROR 2010.08.05 12:26:20
int TCPcłientStart(struct ip_addr *addr, uintl6_t port) (
if (BKPread(state->param, PARAMJ1UMBER) != P^RAM_NUMBER) {
state->param(CONNECTION_TIMEOUT) = DEFAUL%CONNECTION_TIMEOUT;
state->param[STANDBY_TIME] = DEFAULT_STANDBY_TIME;
Plik ex_tcp_clnt_bkp.c
Plik ex_tcp_client_bkp.c zaw iera funkcję main przykładu. Funkcja ta jest praw ie
identyczna ja k w poprzednim przykładzie. Jedyna różnica polega na w yw ołaniu na
jej początku funkcji B K Pconfigure konfigurującej rejestry zapasow e.
if (count > BKPwords)
count - BKPwords;
for (idx = 0; idx < count; ++idx)
I
217
H.
M iędzy kom unikatem B Y E a H EL L O upłynęło 16 sekund, a m iędzy kom unikatem
H EL L O a E R R O R m inęło 10 sekund, co św iadczy o tym , że param etry zm ieniono, zapisano w rejestrach zapasow ych i odczytano z nich po w ybudzeniu mikrok o n tfo le rą N a s tę p n ie , gdy m ikrokontroler śpi, w ciskam y przycisk tam per (SW 4
w ZL29ARNii).
218
6. Klient TCI'
HELLO 2010.08.05 12:28:46
OK
PARAM 30 20
OK
BYE 2010.08.05 12:20:49
HELLO 2010.08.05 12:29:15
ERROR 2010.08.05 12:29:45
W idać, że przyw rócono dom yślne w artości param etrów. M iędzy kom unikatem BYH ■'
a H EL L O upłynęło 26 sekund, a m iędzy kom unikatem H E L L O a E R R O R m inęło' .<
30 sekund.
Serwer UDP
220
7.2. Przykład 7 - prosty serw er UDP
7. Serwer U lf
iB Sl
W tym rozdziale przedstaw iam prosty serw er używ ający protokołu transportowego
UDP. Serw er ten um ożliw ia zdalne m anipulow anie rejestram i w ejścia-w yjścia1rrilv
krokontrolera (przedstaw ionym i na rysunku 1.3 i opisanym i w rozdziale 1.5), alg“
m ożna go łatw o rozbudow ać, aby um ożliw ia! sterow anie dow olnym i peryferiam i
m ikrokontrolera, co pozostaw iam C zytelnikow i jak o ćw iczenie. Przykład bardziej;
skom plikow anego serw era korzystającego z protokołu transportow ego U DP moi na'
znaleźć w nocie aplikacyjnej [5]. Jest lam opisany serw er T F T P (ang. Trivial File
Transfer P rotocol), czyli serw er prostego protokołu do przesyłania plików.
■ !
7.1.
Projekt protokołu
T ab . 7 .1 .
w tym polu są przesyłane w porządku sieciow ym (ang. big-endian), czyli najbar­
dziej znaczący bit pola D A N E m a num er 16, a najm niej znaczący je s t bit 31.
Protokół działa w edług zasady żądanie-odpow iedź. K lient w ysyła polecenie, serw er
je w ykonuje i odsyła w łaściw ą odpow iedź. Jeśli serw er nie m oże popraw nie zinter­
pretow ać polecenia, to odpow iada kom unikatem , w którym pole O PER A C JA m a
w artość PD U _E R R O R (ang. protocol data unit error).
7.2.
|
Tym razem zaprojektujem y protokół bezstanow y, w którym kom unikaty będą mied
postać binarną. Form at kom unikatu je s t w idoczny na ry s u n k u 7.1. Wszystkie
kom unikaty m ają 32 bity. P oczątkow e 4 bity zaw ierają num er w ersji protokolu;J'
W prow adzenie w kom unikatach pola inform ującego o w ersji protokołu je st bafi$
dzo pow szechną praktyką. U łatw ia rozw ijanie protokołu i w prow adzanie jego noi?
w ych w ersji z zachow aniem kom patybilności z w ersjam i poprzednim i. Opisywaną^
tu w ersja protokołu m a w polu W E R S JA w artość 1. K olejne czterobitow e pole';6
O PE R A C JA w kom unikatach w ysyłanych przez klienta zaw iera polecenie do wy*
konania, a w kom unikatach w ysyłanych przez serw er zaw iera odpow iedź. Poleceniair
m ają w artości od 0 do 7, a odpow iedzi od 8 do 15. A ktualnie zdefiniow ane operacje)
opisane są w ta b e li 7.1. W artości nieuw zględnienie w tabeli są zarezerw ow ane dof
przyszłego w ykorzystania. O śm iobitow e pole PO RT zaw iera num er portu wejścia-!.---w yjścia m ikrokontrolera. N um er 1 oznacza port A, num er 2 port B itd. Numeryi,^.
które nie odpow iadają żadnem u fizycznem u portow i m ikrokontrolera, są zarezer- j|
w ow ane do przyszłego w ykorzystania. O statnie 16 bilów kom unikatu zajm uje pole';!
D A N E. Jego interpretacja zależy od operacji i je s t opisana w tabeli 7.1. W artośoil|
Wartość
T a b . 7 .2 .
1
READ_OUTPUT_BITS
2
Polecenie - odczytaj rejestr wyjściowy o d r .Zawartość pola DANE jest nieistotna. Serwer.
odpowiada komunikatem z operacją OUTPUT BITS
RESET_BITS
3
Polecenie - wyzeruj w rejestrze wyjściowym o d r bity, które mają wartość 1 w polu
DANE. Serwer odpowiada komunikatem z operacją OUTPUT BITS
SET_BITS
4
Polecenie - ustaw w rejestrze wyjściowym ODtyBity, które mają wartość 1 w polu DANE.
Serwer odpowiada komunikatem z operacją OUTPUT BITS
WRITE_BITS
5
Polecenie - zapisz do rejestru wyjściowego o d r wartość pola DANE. Serwer odpowiada _
komunikatem z operacją OUTPUT BITS
PDU ERROR
8
Odpowiedź serwera informująca o błędnym poleceniu. Pola PORT i DANE zawierają zera
INPUT BITS
9
Odpowiedź serwera - pole DANE zawiera wartość odczytaną z rejestru wejściowego lim
OUTPUT BITS
10
Odpowiedź serwera - pole DANE zawiera wartość odczytaną z rejestru wyjściowego opi«.
OPERACJA
- [4:7]
'
'
PORT
[8:15]
DANE
[16:31]
e x jid p d .c
startup_stm 32_cld.c
udpjserver.c
board_con!.c
boardJ n it.c
board J e d .c
udp_server.h
board_conU i
boardjJef.h
b o a rd je ts .h
b o a rd jn it.h
boardJe d .h
7.2.1.
Iiblwip4.a
Iibstm32t10x.a
.:■!
w-
*>1,
uliljdelay.h
util_error.h
util_eth.h
u tilJed.h
u tiljw ip .b
U tiljlC .il
u til time.h
cc.h
cortex-m3.h
Iwipopts.h
stm32i10x_conf.h
Pliki udp_server.h i udp_server.c
Pliki udp_server.h i udp_server.c zaw ierają im plem entację serwera, który realizuje
opisany w yżej protokół. Serw er urucham ia się za pom ocą funkcji UDPserverStart.
Jej argum entem je s t num er portu, na którym serw er m a nasłuchiw ać. Funkcja ta
zw raca zero, gdy uruchom ienie serw era pow iodło się, a w artość ujem ną w prze­
ciw nym przypadku. Funkcja UDPserverStart realizuje diagram serw era przedsta­
w iony na rysunku 4.9. D odatkow o spraw dzam y w artości zw racane przez funkcje
biblioteki lw IP i stosow nie reagujem y, jeśli któraś funkcja zw róci błąd. Funkcja
UDPserverStart je st przeznaczona do w yw ołania z program u głów nego, dlatego
w yw ołania funkcji z biblioteki lw IP otoczone są m akiam i, które zabezpieczają
przed ich w spółbieżnym w ykonyw aniem . Za pom ocą-funkcji udp_recv ustawiam y
funkcję zw rotną recv_callback, która będzie w yw ołana po odebraniu przez serw er
danych. O statni argum ent w w yw ołaniu funkcji udp_recv m a w artość NULL, gdyż
nasz serw er je st bezstanow y i nie m a potrzeby przechow yw ania żadnych informacji
m iędzy kolejnym i je g o w yw ołaniam i.
int UDPserverStart(uint!6_t port) {
struct udp_pcb *pcb;
err t err;
IH0~|ECL_PH0TECT (x);
—^
I R Q _ r e O T llć l( |( ,
Rys. 7.1. Format komunikatu
u tiljte la y .c
util_eth_nc.c
util J e d .c
u liljw ip .c
util time, c
Nagłów kowe
■>
WERSJA
[0:3]
Pliki przykładu 7
Źródłowe i biblioteczne
opis
,.2 i2 B
Polecenie - odczytaj rejestr wejściowy i d r .Zawartość pola DANE jest nieistotna. Serwer-odpowiada komunikatem z operacją INPUT BITS
READJNPUTJ3ITS
Przykład 7 - prosty serwer UDP
N azw y plików przykładu 7 zam ieszczone są w ta b e li 7.2. W iększość z nich opisa­
łem ju ż w poprzednich rozdziałach. Poniżej om aw iam tylko now e pliki.
Pole OPERACJA
Operacja
221
L W IP _IR Q _P R IO );
pcb = udp<_n(j/w{);
7. Serwer Uft
222
łdefine PDU ERROR
łdefine INPUT_BITS
łdefine OUTPUT_BITS
IRQ_UNPROTECT(x);
if (pcb == HÜLL)
return -1;
IRQ_PROTECT(x, LWIP_IRQ_PRIO) ;
err = udp_bind(pcb, IP_ADDR_ANY, port);
IRQJJNPROTECT(x);
if (err != ERR_OK) {
IRQ_PROTECT(x, LWXP_IRQ_PRIO);
udp_remove(pcb);
IRQ_ÜNPROTECT(x);
return -1;
)
)
Form at kom unikatu, przedstaw iony na rysunku 7.1, definiujem y ja k o strukturę I
pdu t (ang. protocol data unit type), Pola kom unikatu W E R SJA i OPERACJA
definiujem y ja k o w spólną składow ą v e r s io n _ o p e r a tio n . A lternatyw nie można je
zdefiniow ać ja k o dostępne w języ k u C pola bitowe. Jednak pola bitow e nie są prze­
nośne - sposób ich realizacji zależy od konkretnej im plem entacji jęz y k a C. Dlatego;,
należy ich unikać w definicjach struktur, których postać binarna je s t ustalona.
PACK_STRUCT_BEGIN
struct pdu_t {
PACK_STRUCT_FIELD(u8_t version_operation);
PACK_STRUCT_FIELD(u8~t port);
PACK_STRUCT_FIELD{ul6_t pins);
) PACK_STRUCT_STRUCT;
PACK__STRUCT_END
:
■1 ■
*
‘
K om pilator nie m a obow iązku um ieszczania składow ych struktury w ciągłym ob­
szarze pam ięci. Z e w zględu na szybkość realizacji operacji na składow ych struk­
tury, kom pilator m oże zoptym alizow ać ich rozm ieszczenie w pam ięci, zostawiając
m iędzy kolejnym i składow ym i puste, niew ykorzystane m iejsce. A by w yłączyć takie
optym alizacje, w bibliotece IwIP zdefiniow ano m akra, których nazw a zaczyna się
od przedrostka PACK. W iększość kom pilatorów pozw ala program iście decydow ać o
rozm ieszczeniu składow ych struktury w pam ięci, ale nie je s t to ujęte w standardzie
języ k a C. Poszczególne kom pilatory oferują w tym celu różne rozszerzenia. Poniżej
przedstaw iam realizację m akr PACK dla GCC. Te definicje oraz definicje dla innych
kom pilatorów znajdują się w pliku cc.h.
PACK__STRUCT__BEGIN
PACK_STRUCT_STRUCT _ a t t r i b u t e _ (( _ p a c k e d _ ) )
PACK_STRUCT_END
PACK_STRUCT_FIELD(x) x
N um er wersji protokołu oraz operacje i odpowiedzi protokołu definiujem y jako stale.
PDU_VERSION
*
READ_INPUT_BITS
READ_OUTPUT_BITS
RESET_BITS
SET_BITS
WRITE BITS
1
1
'2
3
4
5
,
8
9
10
łdefine pdu_version(pdu)
((pdu)->version_operation >> 4)
łdefine pdu_operation(pdu) ((pdu)->version_operation &0xf)
łdefine pdu_port(pdu)
((pdu)->port)
łdefine pdu_data(pdu)
ntohs((pdu)->data)
łdefine set_pdu_version_operation(pdu, v, c) \
((pdu)->version_operation = ((v) << 4) i ((c) & 0xf))
łdefine set_pdu_port(pdu, x) ((pdu)->port = (x))
łdefine set_pdu_data(pdu, x) ((pdu)->data - htons(x))
return 0;
łdefine
łdefine
łdefine
łdefine
łdefine
łdefine
223
A by tekst źródłow y byl przejrzysty, definiujem y m akra odczytujące i zapisujące
poszczególne pola w strukturze typu p d u _ t. A rgum ent pdu jest w skaźnikiem do
struktury tego typu. Zauw ażm y, że dostęp do pola DATA je s t zrealizow any za po­
m ocą funkcji n to h s i h to n s . Jest to potrzebne, gdyż pole DATA jest w porządku
sieciow ym .
IRQ__PROTECT (x, LWIP_IRQ_PRIO);
udp__recv (pcb, recv_callback, HULL);
IRQ_ÜNPROTECT(x);
łdefine
łdefine
łdefine
łdefine
7.2. Przykład 7 - prosty serwer U DP
I
*
Z asadniczą obsługę protokołu im plem entujem y w funkcji zw rotnej re c v c a llb a c k .
N a początku za pom ocą funkcji p b u f _ a llo c przydzielam y bufor, w którym serw er
um ieści sw oją odpow iedź. Poniew aż potrzebny je s t bufor o bardzo m ałym rozm ia­
rze, alokujem y go na stercie (param etr PBUF_RAM), a nie z puli buforów. Faktyczny
rozm iar przydzielonego bufora będzie w iększy niż rozm iar struktury
typu pdu t,
w yspecyfikow any ja k o drugi argum ent funkcji p b u f a l l o c . N a początku bufora
zostanie pozostaw ione m iejsce na w staw ienie nagłów ków protokołów w arstw y do­
stępu do sieci, sieciow ej i transportow ej (param etr PBUF_TRANSPORT). Jednak, dla
ułatw ienia posługiw ania się buforem , składow a p a y lo a d w przydzielonej strukturze
typu p b u f w skazuje na początek m iejsca w buforze, gdzie m ają być um ieszczone
dane w arstw y transportow ej.
void tecv_callback(void *arg, struct udp_pcb *pcb, struct pbuf *p,
struct ip_addr *addr, uint!6_t port) {
struct pbuf *q;
struct pdu_t *src, *dst;
q = pbuf alloc (PBUF TRANSPORT, sizeof (struct pdu_t), PBUF__RAM);
if (q =»~NULL) {
pbuf_free(p);
return;
)
sre = p->payload;
dst * q->payload;
if (p->len < sizeof(struct pdu_t) II
pdu_version(sre) != PDU_VERSION II
pdu_port(sre) < 1 II
pdu_port(sre) > gpioCount) {
set_pdu version_operation(dst, PDU_VERSION, PDU_ERR0R);
set_pdu_port(dst, 0);
set_pdu data(dst, 0);
I
else {
GPIO_TypeDef *io * gpio|pdu_port(src) - 1};
^^tchi(^du_operation (sre)) (
case JiE^)_IKPUT_BITS:
224
7.2. Przykład 7 - prosty serwer UDP
7. Serwer (Jl)p
set_pdu_version_operation (dst, PDU__VERSION,
set_pdu_port(dst, pdu_port(src))/
set_pdu_data(dst, GPIO_ReadInputData(io));
break;
case READ__OUTPUT__BITS:
set_pdu_version_operation(dst, PDU__VERSION,
set_pdu_port(dst, pdu_port(src));
set_pdu_data(dst, GPIO_ReadOutputData(io));
break;
case RESET_BITS:
GPIOJlesetBits (io, pdu_data (src));
set_pdu__version operation (dst, PDIM/ERSION,
set_pdu__port (dst, pdu_port (src));
set_pdu_data(dst, GPIO_ReadOutputData(io));
break;
case SET_BITS:
GPIO_SetBits(io, pdu_data(src));
setj?du__versionjDperation (dst, PDU_VERSION,
set_pdu__port (dst, pdu_port(src));
set_pdu_data(dst, GPIO_ReadOutputData(io));
break;
case WRITE_BITS:
GPIO_Write(io, pdu_data(src));
set_pdu_version_operation(dst, PDUJflSRSION,
set_pdu_port(dst, pdu_port(src));
set_pdu_data(dst, GPIO_ReadOutputData(io));
break;
default:
set_pdu_version_operation(dst, PDU_VERSION,
set_pdu_port(dst, 0);
set_pdu_data(dst, 0);
INPUT_BITS) ;
225
GPIO_Pin_8 | GPIO_Pin_9 |
GPIO_Pin_12 | GPI0_Pin_13;
GPIO_InitStruct,GPIO_Mode = GPIO_Mode_IN_FLOATING;
GPIO__Init (GPIOC, SGPIO_InitStruct) ;
)
OUTPUT_BITS);
W funkcji main inicjujem y poszczególne potrzebne w tym przykładzie układy m i­
krokontrolera, m oduły biblioteki IwlP, a następnie konfigurujem y ustaw ienia sie­
ciow e, podobnie jak w poprzednich przykładach. Na końcu za pom ocą funkcji
UDPserverStart urucham iam y serw er U D P na porcie 33333, a za pom ocą funkcji
PORTCconf igure konfigurujem y port C.
OUTPUT_BITS) ;
int m a i n {) (
static struct netif netif;
static struct ethnetif ethnetif = (PHY_ADDRESS);
uint8_t confBit;
OUTPUT_BITS);
Delay(1000000);
confBit “ GetConfBit();
AllPinsDisable();
LEDconfigure {);
RedLEDon{);
SET_IRQ_PROTECTION();
OUTPUT_BXTS);
error_resetable(CLKconfigure(), 1);
error_permanent(LocalTimeConfigure{), 2);
error_resetable (ETHconf igureMII (), 4);
PDU_ERROR);
netif.hwaddr(0] = 2 ;
?
netif.hwaddrflj = (BOARDJFYPE » 8) S 0xff;
netif.hwaddr[2] = BOARDJFYPE fi 0xff;
netif.hwaddr[3) = (ETHJ30ARD » 8) & 0xff;
netif,hwaddr[4) = ETHJ30ARD & 0xff;
netif.hwaddr|5) = 1 + confBit;
if (¡confBit) {
IP4_ADDR(finetif.ip__addr, 192, 168,
51, 84);
IP4_ADDR i&netif.netmask, 255, 255, 255, 240);
IP4_ADDR(&netif.gw,
192, 168,
51, 81);
!
1
pbuf_free(p);
udp_sendto(pcb, q, addr, port);
pbuf_free(q);
)
Jeśli bufor zostanie przydzielony, to d alsza część funkcji recv__callback je st dość
typow a. N ajpierw spraw dzam y popraw ność odebranego kom unikatu. Jeśli komuni­
kat je s t popraw ny, to w ykonujem y zaw arte w nim polecenie i odsyłam y odpowiedź.
N a koniec trzeba też zw olnić przydzielone bufory.
S
else {
IP4_ADDR(inetif.ip_addr,
IP4__ADDR(Łnetif.netmask,
IP4_ADDR (Snetif .gw,
0, 0,
0, 0,
0, 0,
0, 0);
0, 0);
0, 0);
)
7.2.2.
error_resetable(LWIPinterfacelnit(Snetif, Sethnetif), 5);
LWIPtimersStart();
error_resetabie(DHCPwait(Snetif, 10, 4), 6);
error resetabłe(UDPserverStart(33333), 7);
Plik ex_udpd.c
Plik ex_udpd.c zaw iera funkcję main przykładu. Z aw iera też funkcję PORTCconf igure,
która konfiguruje niektóre w yprow adzenia portu C ja k o w ejścia, żebyśm y mieli co
testow ać. W zestaw ie Z L 29A R M d o w yprow adzeń P C 5 ...P C 9 je st podłączony
dżojstik (m g . jo ystick), do w yprow adzenia P C I 2 - przycisk SW 3, a do w yprowa­
dzenia PC 13 - przycisk SW 4. Jako w yjść użyjem y diod św iecących podłączonych
w zestaw ie Z L29A R M do w yprow adzeń PE 14 i PE15.
static void PORTCconf icjure (void)
{
t
GPIO_InitTypeDef GPIO_InitStruct;
*
RCC_APB2EeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);
GPIO_StructInit(SGPIO_InitStruct);
GPIO InitStruct.GPIO Pin = GPIO Pin 5 I GPIO Pin 6 I GPIO Pin 7 I
RedLEDoff{);
PORTCconfigure();
for {;;};
}
7.2.3.
' .w'
Testowanie przykładu
D o przetestow ania przykładu w ykorzystam y program netcat. K om unikat do serwera
można wysłać za pom ocą poleceń z tabeli 7.3. W dalszym ciągu zakładam, że ser­
w er ijjfcywa adresu 192.168.51.89. N ajpierw rozw ażm y polecenie dla system u Linux.
Za pćim odppjolecenia echo m ożna wysiać napis na standardow e wyjście. Parametry
-ne powoduj'4, że po w ysianiu tego napisu nie jest w ysyłany znak końca wiersza,
7. Serwer U D p
~
'
Tab. 7.3. Uruchamianie klienta
echo -ne
i nc -u -wł 192,168.51.89 33333 I hexdump -C
"nc" -u -wl 192.168.51.09 33333 < infile > outfile
____
Tab. 7.4. Przykładowe testy w zestawie ZL29ARM
Poleconie
Odpowiedź
Wciśnięty przycisk SW 3
ii 03 00 00
19 03 23 eO
Wciśnięty przycisk SW4
ii 03 00 00
19 03 13 e8
Oba przyciski wciśnięte
ii 03 00 00
19 03 03 e8
Sprawdzenie stanu diod
12 05 00 00
la 05 cO 00
Włączenie zielonej diody
13 05 40 00
la 05 80 00
Włączenie czerwonej diody
13 05 80 00
la 05 00 00
Wyłączenie zielonej diody
14 05 40 00
la 05 40 00
Wyłączenie czerwonej diody
14 05 80 00
la 05 cO 00
Włączenie obu diod
15 05 00 00
la 05 00 00
Błędne polecenie
20 00 00 00
18 00 00 00
Test
a znak lew ego ukośnika (ang, backslash) je st traktow any jak o znak rozpoczynający
sekw encję specjalną, co um ożliw ia w ysyłanie napisów, które zaw ierają dane binarne.
A by wysiać znak (bajt) o w artości szesnastkow ej hh, należy w pisać \xhh. Dane do.
w ysiania umieszczam y w cudzysłow ach. W yjście polecenia echo przekierowujemy
na w ejście program u netcat (polecenie nc). Param etr -u oznacza w ysyłanie danych za
pom ocą UDP. Param etr -w l nakazuje program ow i neicat czekać m aksym alnie jedną
sekundę na odpow iedź. K olejnym i argum entam i polecenia nc są adres IP i num er por­
tu serwera. Program netcat po odebraniu odpow iedzi od serw era w ypisuje ją na stan­
dardow ym wyjściu, które przekierow ujem y na w ejście polecenia hexdump. Program
hexdum p um ożliw ia w ypisyw anie danych w różnych formatach. Param etr -C ozna­
cza w yświetlanie szesnastkow o każdego bajta oddzielnie. Polecenie echo w syste­
m ie W indow s nie jest tak elastyczne ja k w Linuksie. N ajprostszym rozw iązaniem jest
przygotow anie polecenia, które chcem y w ysiać, w pliku i n f i l e za pom ocą edytora
binarnego. Zawartość pliku i n f i l e w ysyłam y na w ejście polecenia nc, a odpowiedz
zapisujem y w pliku o u t f i l e . D obrym pom ysłem je st przygotow anie sobie całego ze­
stawu plików z poszczególnym i potrzebnym i poleceniami.
W następującym przykładzie odczytujem y stan w ejść.portu C w zestaw ie ZL29ARM .
czyli w ysyłam y kom unikat zapisany szesnastko\yo. U 030000.
5 echo -ne "\xll\x03\x00\x00" | nc -u -wl 192.168.51.89 33333 |
hexdump -C
00000000 19 03 33 eO
00000004
O trzym aliśm y odpow iedź 190333e0, co oznacza, że wejścia PC 13, PC 12, PC9, PC8,
PC7, PC6 i PC5 są w stanie w ysokim , a pozostałe w stanie niskim , czyli oba przy­
ciski i dżojstik nie są- wciśnięte. K olejne przykłady zam ieszczone są w tabeli 7.4.
Zauważm y, że w niektórych odpow iedziach W ejście PC3 m a poziom wysoki. D o wej­
ścia tego je st podłączony sygnał zegara M 1I_TX_CLK z m odułu ethernetow ego, dla­
tego m ożem y się spodziew ać odczytu dość przypadkow ych wartości na tym wejściu.
Klient UDP
8.2. SNTP
229
T em atem tego rozdziału są klienty protokołów D NS i SNTP. O ba używ ają protoko'^
łu transportow ego UDP. Przykładem ich użycia będzie program , który komunikuje'’
się z internetow ym serw erem czasu i synchronizuje zegar czasu rzeczyw istego rfuijt
krokontrolera.
nikiern do struktury zaw ierającej przetłum aczony adres IP lub m a wartość NULL,
gdy w ystąpił błąd, np. nazw a nie m oże być przetłum aczona lub nie istnieje. Trzeci
argum ent a rg je st w skaźnikiem przekazanym jak o czw arty argum ent w yw ołania
funkcji d n s_g ethostbynam e. Funkcja zw rotna je st typu v o id , czyli nie zw raca żad­
nej w artości.
DNS
O pis konfigurow ania adresów serw erów D N S znajduje się rozdziale 3.2.2. A dresam i
serw erów DNS m ożna też zarządzać za pom ocą dw óch poniższych funkcji.
D NS (ang. D om ain Narne System ), czyli system nazw dom enow ych, je s t je d ri|l
z podstaw ow ych usług w intersieciach. Z apew nia tłum aczenie nazw domenowych?
w ęzłów sieci, znanych użytkow nikom sieci, czyli nazw takich ja k www.niema.pl :nat,
adresy IP. U m ożliw ia też tłum aczenie odw rotne, czyli spraw dzenie, ja k a nazw a do'y
nienow a odpow iada danem u adresow i IP. D NS składa się z protokołu kom unikacyj-'
nego i hierarchicznego system u serw erów . D NS używ a protokołu transportowego?
UDP, choć serw ery m iędzy sobą m ogą kom unikow ać się rów nież za pom ocą TCP.!;
Serw er nasłuchuje na porcie 53. Z asadnicze elem enty D N S są opisane w dokumem ;
tach RFC 1034 i RFC 1035, które razem tw orzą standard intersieci ST D 13.
void
dns_setserver(u8_t numdns,
struct ip_addr *dnsserver);
Funkcja d n s _ s e ts e r v e r ustaw ia adres serw era D N S. Pierw szy argum ent numdns
je s t indeksem w w ew nętrznej tablicy m odułu D NS przechow ującej adresy serw erów
i m usi być m niejszy niż stała DNS_MAX_SERVERS zdefiniow ana w pliku Iwipopts.h.
Drugi argum ent d n s s e r v e r je s t w skaźnikiem do struktury zaw ierającej adres IP ser­
w era DNS.
W bibliotece lw lP zaim plem entow ano prostego klienta D NS - pliki clns.h i dns.c,'
K onfiguruje się go w pliku Iw ipopts.h, co opisałem w rozdziale 3.2.2. D o obsługi ,
klienta protokołu D NS biblioteka lw lP dostarcza kilku funkcji.
errj:
dns__gethostbyname (const char *name,
struct ip_addr *addr,
dns_found_callback found,
void *arg);
»
struct ip_addr
dns_getserver(u8_t numdns);
Funkcja d n s _ g e ts e r v e r zw raca adres IP serw era D NS o indeksie numdns. Jeśli in­
deks m a niepopraw ną w artość lub pod tym indeksem nie został skonfigurow any
żaden serw er, to zw raca adres składający się z sam ych zer.
8.2.
SN TP (ang. Sim ple N etw ork Time Protocol) to protokół um ożliw iający synchroni­
zację zegarów w intersieciach, je st opisany w R FC 4330. SN TP jest uproszczoną
w ersją N TP (ang. N etw ork Time P rotocol), ale zupełnie w ystarcza do precyzyjnej
synchronizacji zegara czasu rzeczyw istego w dow olnym urządzeniu, które ma d o ­
stęp do Internetu. SN TP używ a protokołu transportow ego UDP. Serw ery czasu na­
słuchują na porcie 123. SN TP jest protokołem bezstanow ym . K lient w ysyła do ser­
w era żądanie (ang. request) podania aktualnego czasu, a serw er odsyła odpow iedź
(ang. reply) z czasem . SN TP je st kom patybilny z N T P w tym sensie, że serw ery
N T P odpow iadają na żądania SNTP.
Funkcja d n s_ g eth o stb y n am e odw zorow uje nazw ę dom enow ą na adres IP. Pierw-,/>
jej argum ent name je s t w skaźnikiem d o napisu zaw ierającego nazw ę, która ma być.
przetłum aczona. D rugi argum ent a d d r je st w skaźnikiem do struktury, w której m a ‘;
być um ieszczony przetłum aczony adres IP, jeśli został on ju ż pozyskany wcześniej
przez klienta D NS i znajduje się w je g o lokalnej pam ięci. W tym przypadku funk-,
cja zw raca w artość ERR_0K. L iczbę pam iętanych lokalnie odw zorow ań określa stała
DNS_TABLE_SIZE zdefiniow ana w pliku Iw ipopts.h. Jeśli adres IP nie je s t jeszcze /n.iny, to funkcja w ysyła prośbę do serw era D NS i kończy działanie, zw racając wartość .
ERR_INPROGRESS. W tym przypadku aplikacja zostanie pow iadom iona o odebraniu,,
odpow iedzi od serw era za pom ocą funkcji zw rotnej^której adres found je s t trzecim,
argum entem . C zw arty argum ent a rg je s t wskaź.nijdem, który zostanie przekazany
funkcji zw rotnej, co um ożliw ia obsługę w szystkich odw zorow ań za pom ocą wspók,
nej funkcji zw rotnej. W przypadku w ystąpienia problem u funkcja m oże też zwrócić
inny kod błędu typu e r r _ t , zgodnie z konw encją stosow aną w bibliotece lwlP.
typedef void
(* dns_found_callback)(const char *name,
struct ip_addr *addr,
1 void *arg);
^
I
Jeśli klient D NS odbierze o d pow iedź od serw era, to biblioteka lw lP wywołuje
funkcję zw rotną typu d n s_ fo u n d _ c a llb a c k . Pierw szy jej argum ent name wskazuje
nazw ę w ęzła, którego adres IP chcem y poznać. D rugi jej argum ent ad d r je st wskaź-
SNTP
‘"I
C zas w N T P i SN TP je st reprezentow any za pom ocą 64-bitow ego znacznika cza­
su (ang. tim estam p). Z nacznik czasu je s t zapisyw any w sieciow ym porządku okte­
tów i zaw iera liczbę sekund, które upłynęły od dnia 1 stycznia 1900 roku czasu
uniw ersalnego (U TC, ang. U niversal Time Clock). Początkow e 32 bity znacznika
zaw ierają część całkow itą, a kolejne 32 bity to część ułam kow a. Taki form at za­
pisu czasu zapew nia rozdzielczość około 233 pikosekundy. Jeśli taka precyzja nie
je st potrzebna, to nieużyw ane, najm niej znaczące bity znacznika czasu w ypełnia
się zeram i. Z nacznik czasu rów ny zeru oznacza niepraw idłow y lub nieosiągalny
czas. Z nacznik czasu przepełnia się co 232 sekund, czyli co około 136 lat, lecz nie
pow inno to pow odow ać w iększych problem ów , gdyż je st to na tyle długi okres, że
mozrni z ś ^ j e g o źródła łatw o określić, którego 136-lelniego okresu czasu dotyczy
dany znacznik. D robnym problem em je s t w ystępow anie raz na 136 lat niereprezen-
8.2. SNTP
tow alnego okresu o długości 233 pikosekund, gdy znacznik czasu musiałby ,
w artość zero.
Ż ądanie i odpow iedź m ają w spólny form at, taki sam ja k w NTP. Jest on
staw iony na ry s u n k u 8.1. W szystkie liczby w ielooktetow e zapisuje się w
ku sieciow ym . D w ubitow e pole LI zaw iera ostrzeżenie o sekundach przestępn
(ang. leap im licator). W artość 0 oznacza brak ostrzeżenia. W artości 1 i 2 oznaczają
że ostatnia m inuta bieżącego d nia będzie m iała odpow iednio 61 lub 59 sekund!
W artość 3 oznacza, że zegar serw era nie został jeszcze zsynchronizow any. To pjest istotne tylko w kom unikatach zaw ierających odpow iedź od serw era. Klient'.w sze w staw ia w nim w artość 0. T rzybitow e pole V N zaw iera num er wersji pr0;
tokołu. O pisyw ana tu w ersja m a num er 4. T rzybitow e pole M ode zaw iera rod/
operacji. Klient, w ysyłając żądanie, ustaw ia w artość 3, a serw er w odpow iedzi usta*»
wia w artość 4. S erw er pracujący w trybie rozgloszeniow ym , w ysyłający cyklicznie"
w ustalonych odstępach czasu inform ację o aktualnym czasie, um ieszcza w tvn>
polu w artość 5. Inne m ożliw e w artości tego p ola opisane są szczegółow o w doku-',
m encie R FC 4330.
II
[0:1]
VN
[2:4]
Mode
[5:7]
Stratum
[8:15]
Root Delay
[32 bity]
Root Dispersion
[32 bity]
Reference Indentifier
[32 bity]
Reference Timestamp
[64 bity]
Originate Timestamp
[64 bity]
Receive Timestamp
[64 bity]
Transmit Timestamp
[64 bity]
Key Identifier (opcjonalne)
[32 bity]
Message Digest (opcjonalne)
[1284>itów]
Rys. 8.1. Format komunikatu NTP
Poll
[16:23]
Precision
[24:311
231
Pole Stratum inform uje o położeniu (num erze warstwy) serwera w hierarchii synchro­
nizacji. Klient zaw sze ustawia w nim wartość 0. Jest ono istotne tylko w odpowiedzi
udzielonej przez serwer. Wartość 0 w tym polu oznacza kom unikat „kiss-o’-death”,
który informuje, że serw er nie chce udzielić odpow iedzi, gdyż np. jest przeciążony.
Klient, otrzym aw szy taki kom unikat, pow inien przestać wysyłać żądania do tego ser­
wera i zw rócić się do innego serwera. Jeśli żaden alternatywny serw er nie jest dostęp­
ny, to klient może ponaw iać żądanie do tego serwera, zwiększając wykładniczo od­
stęp czasu między kolejnymi żądaniami, jeśli serw er nadal nie odpowiada. Wartość 1
w polu Stratum w ysyłają serwery pierwotne (pierwszej warstwy), najczęściej synchro­
nizow ane własnym zegarem atom owym . Wartości od 2 do 15 wysyłają serwery w tór­
ne, synchronizow ane za pom ocą N TP do serwerów, które należą do warstwy o jeden
mniejszej. Wartości od 16 do 255 są zarezerw ow ane do przyszłego wykorzystania.
Pole Poll zaw iera inform ację o m aksym alnym interw ale m iędzy kolejnym i kom uni­
katam i serw era, gdy działa on w trybie okresow ego rozgłaszania. Pole Precision za­
w iera inform ację o dokładności zegara, którego używ a serwer. C zasy te określa się
ja k o 2X sekund, gdzie x jest w artością um ieszczoną w danym polu, interpretow aną
ja k o ośm iobitow a liczba ze znakiem w kodzie uzupełnieniow ym do dw ójki. K lient
zaw sze zeruje w szystkie bity w tych polach i m oże ignorow ać w artości otrzym ane
od serw era, jeśli ich nie potrzebuje.
Pole R oot D elay zaw iera różnicę czasu w sekundach m iędzy tym serw erem a ser­
w erem pierw otnym , z którym się on synchronizuje, w ynikającą m .in. z opóźnień
przesyłania kom unikatów w sieci. W artość w tym polu interpretuje się ja k o liczbę
ułam kow ą slalopozycyjną ze znakiem w kodzie uzupełnieniow ym do dw ójki, gdzie
przecinek je s t postaw iony m iędzy 15. a 16. bitem . W artość w tym polu m oże być
ujem na. Pole to je s t istotne tylko w kom unikatach w ysyłanych przez serwer. K lient
ustaw ia w nim zaw sze zero.
Pole R oot D ispersion zaw iera m aksym alny błąd czasu w sekundach, w ynikający
z tolerancji częstotliw ości zastosow anego w serw erze zegara. W artość w tym polu
interpretuje się ja k o liczbę ułam kow ą bez znaku, gdzie przecinek je s t postaw iony
m iędzy 15. a 16. bitem . Pole to je s t istotne tylko w kom unikatach w ysyłanych przez
serwer. K lient ustaw ia w nim zaw sze zero.
W polu R eference Identifier serw er pierw otny um ieszcza sw ój identyfikator, zaw ie­
rający m aksym alnie cztery znaki A SC II i dopełniony zerow ym i oktetam i. Serw ery
w arstw 2. do 15. um ieszczają w tym polu adres IP serw era, do którego się synchro­
nizują. Pole to je s t istotne tylko w kom unikatach w ysyłanych przez serwer. Klient
ustaw ia w nim zaw sze zero.
K olejne cztery pola zaw ierają znaczniki czasu. R eference T im estam p inform uje,
kiedy zegar serw era byl po raz ostatni synchronizow any. K lient um ieszcza w tym
polu zero. W polu O riginate T im estam p klient um ieszcza zero, a serw er kopiuje
do niego zaw artość pola T ransm it T im estam p z żądania klienta. W polu R eceive
Tim estam p klient um ieszcza zero, a serw er um ieszcza w nim czas odebrania żąda­
nia od klienta w edług sw ojego zegara. W polu T ransm it T im estam p klient i serw er
um ieszczają czas w ysiania kom unikatu, posługując się sw oim lokalnym zegarem .
WaiTOŚci tt f pozw alają oszacow ać czas podróży kom unikatów , co um ożliw ia do­
kładniejszą Synchronizację. O znaczm y O riginate T im estam p, R eceive T im estam p
232
8.3. Przykład 8 - automatyczna synchronizacja zegara czasu rzeczywistego
& Klient U pp
- ►
T ab . 8 .1 .
C zas klienta
233
Pliki przykładu 8
Źródłowe i biblioteczne
Żądanie \
/
O dpow iedź
- ►
R ys.
C zas serw era
font5x8.h
sntp_client.h
board_cont.li
board_del.lt
board_dels.h
board_init.il
board_lcd.li
b o a rd je d .h
Przykład 8 - automatyczna synchronizacja zegara
czasu rzeczywistego
■
N azw y plików przykładu 8 zam ieszczone są w ta b e li 8.1. W iększość z nich opis;
lem ju ż w poprzednich rozdziałach. Poniżej opisuję tylko now e pliki.
Pliki sntp_clienł.h i sntpjclient.c
Pliki sntp_client.h i sn tp jc lie n t.c zaw ierają im plem entację klienta protokołu SN'I P
Z aczynam y od zdefiniow ania stałych i struktur tego protokołu. Pow inniśm y zdf
niow ać stałą NTP_P0RT reprezentującą num er portu, na którym nasłuchują serwery
W N T P czas odm ierza się w sekundach od 1 stycznia 1900 roku, a nasz zegar czast
rzeczyw istego liczy sekundy od 1 stycznia 1970-ruku. Do przeliczania deiiniujem j
stalą NTP_T0_UNIX, której w artością je s t liczba sekund m iędzy tym i datam i.
łdefine N T P J O R T
łdefine NTP_TOJJNIX
Iiblwip4.a
Iibstm 32tl0x.a
■.
util_delay.h
util_error.h
utit_eth.h
u tiljc d .h
u tiijc d _ e x .il
u tfje d .h
u tiljw ip .h
util_rtc.li
util tinie.h
cc.h
cortex-m3.h
lwipopts.li
stm32t10x_cont.h
dziale, czyli nieprzenośności pól bitow ych języ k a C, trzy pierw sze pola kom unikatu
definiujem y ja k o w spólną ośm iobitow ą składow ą LI_VN_Mode.
PACK_STRUCT_BEGIN
struct ntpjnsg {
PACK_STRUCT__FIELD(uint;'8_t LI_VN Mode);
PACK_STRUCT_FIELD(uint8_t Stratum);
PACK_STRUCT_FIELD(uint8_t Poll);
PACK_STRUCT_FIELD(int8_t Precision);
PACK_STRUCT_FIELD(uint32_t RoofcDeiayi;
PACK_STRUCT_FIELD(uint32_t RootDispersion);
PACK_STRUCT_FIELD(uint8_t Referenceldentifier[4});
PACK_STRUCT_FIELD(struct ntp_timestamp ReferenceTimestamp);
PACK_STRUCT_FIELD(struct ntp_timestamp OriginateTimestamp);
PACK_STRUCT_FIELD(struct ntp_timestamp ReceiveTimestamp);
PACK_STRUCT_FIELD(struct ntp_timestamp TransmitTimestamp);
l PACK_STRUCT_STRUCT;
PACK_STRUCT_END
W artości, które pojaw iają się w polach w ysyłanych i odbieranych kom unikatów , też
trzeba zdefiniow ać jak o stałe.
łdefine
idefine
łdefine
łdefine
łdefine
łdefine
łdefine
123
2208988800U
Z nacznik czasu reprezentujem y ja k o strukturę typu n tp _ tim esta m p .
PACK_STRUCT_BEGIN
struct ntp_timestamp (
PACK_STRUCT_FIELD(uint32_t Secondsl;
PACK STRUCTJ?IELD(uint32_Ł SecondsFraction/;
util_delay.c
u til_ e llijic .c
u iiijc d .c
u tiljc d _ e x .c
u til Je d .c
u tiljw ip .c
u tiijtc .c
u tiljim e .c
Natjlówk owe
Pola K ey Identifier i M essage D igest są opcjonalne i nie są używ ane w uproś/ ,r
czonej w ersji protokołu, czyli w SNTP. Podsum ow ując, w najprostszym przypadki 1
klient w prośbie ustaw ia w polu V N w artość 4, w polu M ode w artość 3, a w po/o
stałych polach w artość 0. M oże też ustaw ić sw ój czas w polu T ransm it Timestamp
W odpow iedzi uzyskanej od serw era klient spraw dza popraw ność pól LI, VN
M ode i Stratum . D o korekty sw ojego czasu korzysta z w artości w polu Transmi
T im estam p, ew entualnie też z czasów O riginate T im estam p i R eceive Timestamp
a zaw artość pozostałych pól ignoruje. K lient pow inien też spraw dzać, czy otrzyma-!
ne znaczniki czasow e-są praw idłow e, czyli niezerow e.
8.3.1.
board_con!.c
boardJ n it.c
boardJ c d J s 0 108. c
boardJe d .c
8.2. Wymiana komunikatów NTP między klientem a serwerem
i T ransm it T im estam p z odebranej od serw era odpow iedzi odpow iednio przez 'I I
T2 i T 3. Przez T4 oznaczm y czas odebrania odpow iedzi przez klienta w edług jego
lokalnego zegara, patrz ry s u n e k 8.2. W tedy łączny czas podróży komunikatów
w obie strony szacuje się ja k o T 4 - T l - T3 + T2, a korektę czasu klienta, czyli
różnicę m iędzy czasem serw era a klienta, ja k o (T2 + T3 - T l - T 4) / 2.
8.3.
ex_sntp.c
iont5x8.c
sntp_ciient.c
startupjtm 3 2 _ c ld . c
.■ „
i PACiTsTRUCTJBTRUCT; . ,
PACK_STRUCT__END
O bow iązkow ą część kom unikatu NTP, zam ieszczoną na rysunku 8.1, reprezenti
my ja k o strukturę typu n tp jn s g . Z tych sam ych pow odów co w poprzednim r<>/-
NTP_LI_NO_WARNING
NTP_LI_ĄLARM_CONDITION
NTP_VERSI0N
NTP_MODE_CLIENT
NTP_HODE_SERVER
NTP_STRATUM_KISS_OF_DEATH
NTP STRATUM MAX
0
3
4
3
4
0
15
Pola LI, V N, M ode kom unikatu zdefiniow aliśm y jak o składow ą LI_VN_Mode struk­
tury typu n tp jn s g . Do obsługi tych pól służą poniższe makra. M akro n tp _ le a p _ in d i c a t o r daje w artość pola LI. M akro n tp _ v e r s io n daje w artość pola VN. M akro
ntp_raode daje w artość pola M ode. A rgum entem tych m akr jest w skaźnik pdu do
struktury typu n tp jn s g . M akro n tp _ co m p o se_ li_ v n jn o d e pom aga w ypełnić sklad o w if Li Mm Mode tej struktury. A rgum entam i są odpow iednio w artości pól LI, VN
i M ode. . i,li'
8. Klient UDp
234
fdefine
Sdefine
idefine
fdefine
({(li)
ntp_leap_indicator(pdu) ((uint8_t)((pdu)->LI_VN_Mode >> 6))
ntp_version(pdu) {(uint8_t){((pdu)~>LI_VN_Mode » 3) & 0x7))
ntp_mode (pdu) ((uint8_t)((pdu)->LI_VN_Mode & 0x7))
ntp_compose_li_vn_mode(li, vn, mode)
\
« 6} | ({(vn) « 3) & 0x38) | {(mode) & 0x7})
K lienta urucham ia się za pom ocą funkcji S N T P c lie n tS ta rt. Jej pierw szy argument
serverN am e je st nazw ą serw era, do k tórego m a być w ysiane żądanie SNTP. Funkcja
ta je s t przeznaczona do w yw ołania z program u głów nego i tylko inicjuje klienta,
który następnie działa w przerw aniu biblioteki lwIP, czyli w tle w stosunku do pro­
gram u głów nego. D latego funkcja S N T P c lie n tS ta rt nie zw raca żadnej wartości,
a drugi jej argum ent s t a t u s je s t w skaźnikiem do zm iennej typu i n t , w której klient
um ieszcza status, czyli inform ację o w yniku sw ojego działania. W artości, które
m oże przyjm ow ać status, są opisane w ta b e li 8.2. O dpow iednie stale definiujemy
za pom ocą dyrektyw i d e f i n e w pliku sntp_client.h. W yw ołania funkcji bibliote­
ki lw IP w ew nątrz funkcji S N T P c lie n tS ta rt są otoczone m akram i wykluczającym i
w spółbieżne w ykonyw anie kodu tej biblioteki.
void SNTPclientStart(const char ‘serverName, int ‘status) {
struct ip_addr serverIP;
err_t err;
IRQ_DECL_PROTECT(x) ;
IRQ__PROTECT {x , LWIP_IRQ_PRIO);
err = dns_gethostbyname(serverName, SserverlP, SNTPrequest,
(void*)status);
IRQJJNPROTECT(x);
¡,
if (err == ERR_OK) {
IRQ_PROTECT(x, LWIP_IRQ_PRIO) ;
SNTPrequest(serverName, &serverIP, (void*)status);
IRQJJNPROTECT(x) ;
‘
status = SNTP_IN_PROGRESS;
)
else if (err =* ERR_INPROGRESS)
‘
status = SNTP_IN_PROGRESS;
else
‘status = SNTP DNS ERROR;
T ab . 8 .2 .
Status klienta SNTP
Slata
SNTP NOT RUNNING
W artość
' " U p ls
2
Klient nie został jeszcze uruchbrtllóny
SNTP_SYNC!1R0NIZED
1
Klient uzyskał czas od serwera, zsynchronizował zegar czasu rzeczywi­
stego i zakończył działanie
SNTP IN PROGRESS
0
Klient wysłał żądanie do serwera DNS lub SNTP i oczekuje na odpowiedź
8.3. Przykład 8 - automatyczna synchronizacja zegara czasu rzeczywistego
235
Funkcja S N T P c lie n tS ta rt zaczyna od przetłum aczenia nazw y serw era na adres IP.
Jeśli funkcja d ns_gethostbynam e zw róci w artość ERR_0K, to struktura s e r v e r I P za­
w iera adres IP i w yw ołana je s t funkcja SN TPrequest, której zadaniem je s t w ysianie
żądania SNTP. Jeśli funkcja d n s_ g eth o stb y n am e zw róci w artość ERR_INPROGRESS,
co oznacza, że żądanie D NS zostało w ysłane, to po otrzym aniu odpow iedzi zosta­
nie w yw ołana funkcja SN TPrequest, której adres je st trzecim argum entem w yw o­
łania funkcji dns__gethostbynarae. C zw arty argum ent s t a t u s funkcji d n s_ g e th o stbynam e je s t w skaźnikiem , który m a być przekazany ja k o trzeci argum ent funkcji
SN TPrequest. Przed zakończeniem funkcja S N T P c lie n tS ta rt ustaw ia status klienta
w zm iennej w skazyw anej przez w skaźnik s t a t u s .
O pisyw ana im plem entacja um ożliw ia urucham ianie w iele (sic!) klientów rów nocześ­
nie. D la każdego klienta alokujem y strukturę typu s n tp c l i e n t . Struktury klientów
tw orzą listę. N a pierw szy elem ent listy w skazuje zm ienna globalna f i r s t C l i e n t .
Składow a n e x t w skazuje na następny elem ent na liście. Składow a pcb jest w skaźni­
kiem do deskryptora UDP, używ anego do w ysłania żądania i odebrania odpow iedzi.
Składow a tim e r je s t licznikiem odm ierzającym czas, przez który klient będzie je s z ­
cze czekał na odpow iedź serw era. G dy w artość tej składow ej zm niejszy się do zera,
klient zakończy działanie, a je g o dane zostaną usunięte z pam ięci. Składow a s t a t u s
w skazuje na zm ienną, w której m a być um ieszczony status klienta.
struct sntp_client {
struct sntp__client ‘next;
struct udp_pcb
*pcb;
int
timer;
int
‘status;
};
static struct sntp_client ‘firstClient = NULL;
Po otrzym aniu odpow iedzi od serw era D NS w celu w ysiania żądania do serw era
S N T P w yw ołujem y funkcję SN TPrequest. Jej pierw szy argum ent w skazuje nazw ę
serw era SN T P i nie jest używ any. A rgum ent ten je s t potrzebny, gdyż adres tej funk­
cji je st przekazyw any do funkcji dns_ g eth o stb y n am e jak o adres funkcji zw rotnej,
co w ym aga zgodności sygnatur funkcji. D rugi argum ent s e r v e r I P je s t w skaźnikiem
do struktury zaw ierającej adres IP serw era. Jeśli w skaźnik ten ma w artość NULL, to
w ystąpił ja k iś błąd podczas kom unikacji z serw erem D N S. Przyczyną m oże być
p odanie błędnej nazw y serw era SN TP lub aw aria sieci. Trzeci argum ent s t a t u s je s t
w skaźnikiem do zm iennej, w której klient m a um ieścić sw ój status.
static void SNTPrequest(const char ‘serverName,
struct ip_addr ‘serverIP, void*‘status) {
struct sntp__client ‘client;
if (NULL ” serverIP) {
* (int*)status = SNTP_DNS_ERROR;
return;
SNTP_DNS_ERROR
-1
Klient zakończył działanie, gdyż nie udało się przetłumaczyć nazwy ser­
wera na adres IP
SNTP MEMORY ERROR
-2
Klient zakończył działanie z powodu błędu alokacji pamięci
SNTP UDP ERROR
- '3
Klient zakończył dzialańie, gdyż nie udało się wysłać żądania do serwera
SNTP_NO_RESPONSE
-4 '
Serwer SNTP nie odpowiedział w przewidzianym czasie ł klient zakończył
działanie
client = mem_malloc(sizeof(struct sntp_client));
if (client == NULL) f
* (int*)status - SNTPJ4EMORY_ERROR;
return;
SNTP_RESPONSE_ERROR
-5
Serwer SNTP odpowiedział, ale odpowiedź jest błędna i nie można na jej
podstawie zsynchronizować zegara. Klient zakończył działanie
ciient->pctffi“ NULL;
)
) Ulr
¡ j |j
8.3. Przykład 8 - automatyczna synchronizacja zegara czasu rzeczywistego
client->timer = SNTPJfIMEOUT;
client->status = (in Ł * )s ta t u s i
client->next * firstClient;
firstClient = client;
if (NULL != (client->pcb = udp_new()) &£
ERR OK == udp__bind (client->pcb, IP_ADDR_ANY, 0} £fi
ERR_OK == udp_connect(client->pcb, serverIP, NTP^PORT))
struct pbuf *p;
1
p = pbuf alloc(PBUFJTRANSPORT, sizeof{struct ntpjnsg), PBUF_RAM);
if tp) r
struct ntpjnsg *msg = p->payload;
memset(msg, 0, sizeof(struct ntpjnsg));
m s g - > U _VN_Mode = ntp_compose_li vn inode(NTP_U_NO_WARNING,
NTP_VERSION,
NTP_MODE__CLIENT);
udp_recv(client->pcb, SNTPrepiy, client);
if (ERR_OK != udp send(client->pcb, p>) {
* (intMstatus =“SNTP_UDP_ERR0R;
client->timer = 0;
237
Po otrzym aniu odpow iedzi od serw era SN TP biblioteka w yw ołuje funkcję zw rot­
ną SNTPrepiy. Pierw szym argum entem tej funkcji je s t w skaźnik do struktury typu
sntp_client. Drugi argum ent pcb je st deskryptorem UDP. Trzeci argum ent p jest
w skaźnikiem do bufora, który zaw iera odpow iedź serw era. C zw arty argum ent s e ­
rverIP je s t w skaźnikiem do struktury zaw ierającej adres IP serw era. Piąty argu­
m ent serverPort je s t num erem portu, którego serw er użył do w ysłania odpow iedzi.
W dalszym ciągu potrzebne nam są tylko w skaźniki arg i p. Po zw eryfikow aniu
popraw ności odebranego kom unikatu uaktualniam y licznik zegara czasu rzeczy­
w istego za pom ocą funkcji SetRealTimeClock. Z w róćm y uw agę na odw racanie
kolejności bajtów za pom ocą funkcji ntohl i konw ersję czasu za pom ocą stałej
NTP_TO_UNIX. N a koniec w funkcji S NTPrepiy ustaw iam y odpow iedni status klien­
ta, zw alniam y bufor zaw ierający odebrany kom unikat i zerujem y składow ą timer
struktury client, aby natychm iast usunąć niepotrzebnego ju ż klienta.
static void SNTPrepiy(void *arg, struct udp_pcb *pcb, struct pbuf *p,
struct ip_addr *serverIP, ul6_t serverPort) (
struct sntp_client *client = arg;
struct ntpjnsg *msg;
i
pbuf_free(p);
msg = p->payload;
if (p->len >= sizeof(struct ntpjnsg) ££
ntp_leap__.indicator (msg) !~ NTP LI_ALARM_CONDITION ££
ntp_version(msg) == NTPJ/ERSION ££
ntpjnode(msg) =*= Ni;P_MODE_SERVER ££
msg->Stratum != NTP_STRATUM_KISS_0F_DEAT1I ££
msg->Stratum <= NTP_STRATUM_MAX ££
(msg->TransmitTimestamp.Seconds != 0 |j
msg->Transmit?imestamp.SecondsFraction != 0)) {
SetRealTimeCiock{ntohl(msg->TransmitTimestarap.Seconds) NTP_TO_UNIX);
Mciient->status) = SNTP__SYNCHRONIZED;
}
else {
* (int*)status = SNTP_MEMORY_ERROR;
client->timer = 0;
)
i
else {
* (intMstatus = SNTp_UDP_ERROR;
client->timer = 0;
}
I
W funkcji SNTPreguest próbujem y przydzielić klientow i now ą strukturę typu
sntp_client i jeśli alokacja się pow iodła, inicjujem y składow e tej struktury ora/
w staw iam y ją na początek listy klientów . N astępnie próbujem y uzyskać deskryptoi
U D P za pom ocą funkcji udp new. Jeśli się pow iodło, próbujem y za pom ocą funkcji
udp_bind uzyskać port, który posłuży do w ysiania żądania i na którym będziemy
oczekiw ać odpow iedzi od serw era. Jeśli dostaliśm y port, w yw ołujem y funkcję udp_
connect, aby przypisać do deskryptora U D P adres i num er portu serw era. Dzięki
tem u odebrana zostanie tylko o d pow iedź od tego serw era, do którego wysialiśm y
żądanie, a w szelkie inne datagram y U D P będą ignóiTRrane. Jeśli pow yższe się uda­
ło, próbujem y przydzielić za pom ocą funkcji pbu'fJ l l o c bufor, w którym zosta­
nie um ieszczone żądanie SNTP. Po przydzieleniu bufora w ypełniam y pola żądania;
SNTP. N astępnie ustaw iam y funkcję zw rotną udp_recv, która zostanie w yw ołana1
po odebraniu odpow iedzi od serw era. Funkcja zw rotna ja k o argum ent dostanie;
w skaźnik client do struktury typu sntp_client opisującej klienta. W reszcie cale:
żądanie w ysyłam y za pom ocą funkcji udp_send. N a koniec, po w ysłaniu żądania
zw alniam y bufor z niepotrzebnym ju ż kom unikatem . Jeśli w pow yższej procedu­
rze napotkaliśm y ja k iś problem , ustaw iam y*odpow iedni status klienta i zerujemy
składow ą timer struktury client, aby przyspieszyć usunięcie klienta z pamięci,
o czym dalej. Przed usunięciem klienta zostanie też zw olniony przydzielony mu
deskryptor UDP.
}
else
* (client->status) = SNTPJiESPONSEJSRROR;
pbuf_free(p);
client->timer = 0;
i
D o obsługi przekroczenia czasu oczekiw ania na odpow iedź serw era im plem entuje­
my budzik. Przyjm ijm y, że będzie on w ołany co 200 m ilisekund oraz że klient bę­
dzie czekał na odpow iedź m aksym alnie 4 sekundy. Z apew ne w ystarczyłoby czekać
krócej, bo zw ykle serw ery N T P odpow iadają szybko, a nie m a sensu synchronizo­
wać się do serw era, na którego odpow iedź trzeba 'długo czekać, ale - aby ułatwić
testow anie - dobrze jest jed n ak ustaw ić odpow iednio długi czas oczekiw ania. O kres
budzika i liczbę okresów, które klient ma czekać na odpow iedź od serw era, definiu­
jem y odpow iednio jak o stale SNTP_TIMER_MS i SNTP_TIMEOUT.
łdefine SNTP_TIMER_MS 200
Idefine SNTPJTIMEOUT 20
Z darzenie budzika obsługiw ane jest przez funkcję SNTPtimer, w której przegląda­
my liptę klientów . Z listy usuw am y te klienty, które działają ju ż zbyt długo. Jeśli
ldieimiwit ¡¡tiy.ydzielono deskryptor UDP, to zw alniam y ten deskryptor przed usunię­
ciem z pamjięci danych klienta.
238
8. Klient Ul)/*
8.3. Przykład 8 - automatyczna synchronizacja zegara czasu rzeczywistego
static void ClockCallback(void)
static int f = 0;
int i;
void SNTPtimer(void) {
struct sntp_client *curr, *prev, *next;
curr = firstCIient;
prev = NULL;
while (curr) {
if (— (curr->timer)
0) {
if (curr->pcb)
udp_remove(curr->pcb);
if (prev)
next = prev->next = curr->next;
else
next = firstCIient = curr->next;
if {*(curr~>status) == SNTP_IN_PROGRESS)
* (curr->status) - SNTP_NO_RESPONSE;
mem_free(curr);
curr = next;
else {
prev
8.3.2.
{
LCDgoto(0, 1);
LCDwriteTime(GetRealTimeCiock());
for (i = 0; i < COUNT; ++i) i
LCDgoto(2 + i, 0);
if (f == 0) (
LCDwrite(serverTbl(i]);
LCDwritet"
");
)
else if (f == 2 j| f
3) f
switch (status(i}) {
case SNTP_N0T_RUNNING:
LCDwrite("SNTP not running
break;
case SNTP__S YNCHR0NI ZED:
LCDwrite("Time synchronized
break;
case SNTP_IN_PR0GRESS:
LCDwrite("SNTP in progress
break;
case SNTP_DNSJERR0R:
LCDwrite("DNS error
break;
case SNTP_MEM0RY_ERR0R:
LCDwrite("Memory error
break;
case SNTP_UDP_ERR0R:
LCDwrite("UDP error
break;
case SNTPJ10_RESP0NSE:
LCDwrite("SNTP no response
break;
case SNTP_RESP0NSE_ERR0R:
LCDwrite("SNTP response error
break;
curr;
curr->next;
Plik ex_sntp.c
Plik ex_siitp.c zaw iera im plem entację testów klienta SNTP. N ajpierw deklarujem y '
tablicę s e r v e rT b ł w skaźników do nazw serwerów . W śród tych nazw je st serwer
nieoferujący usługi SNTP. Jego nazw a w ystępuje dw ukrotnie, aby przetestować
pam ięć lokalną D N S. Żeby przetestow ać D N S, na drugiej pozycji je s t nazw a, któ­
ra nie istnieje w Internecie. D w ie o statnie pozycje w tablicy w skazują na nazwy
oficjalnych serw erów czasu, synchronizow anych zegarem atom ow ym i zainstalo­
w anych w G łów nym U rzędzie M iar. D la każdego serw era urucham iam y osobnego
klienta. Statusy klientów przechow ujem y w tablicy s t a t u s .
ffdefine COUNT 5
static const char * const serverTbl(COUNT] = j
"wikipedia.org",
"nie.ma.takiego.serwera",
"wikipedia.org",
"tempusł.gum.gov.pl",
"tempus2.gum.gov.pi"
239
");
");
");
");
");
");
");
}
i
}
f = (f + 1) & 3;
}
•-,**.
1;
static int status[COUNT] = (
SNTP_NOT_RUNNING,
SNTP__NOT_RUNNING,
SNTP_NOT_RUNNING,
SNTP_NOT_RUNNING,
SNTP_NOT_RUNNING
);
W przerw aniu zegara czasu rzeczyw istego, /zgłaszanym co sekundę, w yw ołujem y
funkcję zw rotną C lo c k C a llb ac k , której zadhniem je st w yśw ietlenie na LCD aktu­
alnego czasu oraz inform acji o działaniu poszczególnych klientów . N a przem ian
przez dw ie sekundy w yśw ietlam y nazw y serw erów , a przez kolejne dw ie sekundy
- statusy klientów , które uruchom iliśm y.
W funkcji main inicjujem y poszczególne układy m ikrokontrolera, ustaw iam y funk­
cję zw rotną C lo c k C a llb a c k w ołaną w przerw aniu zegara czasu rzeczyw istego, kon­
figurujem y ustaw ienia sieciow e, ustaw iam y budzik SNTPtimer dla klientów SNTP,
a na koniec urucham iam y po kolei, w niew ielkich odstępach czasu, klienty SN TP
za pom ocą funkcji S N T P c lie n tS ta rt.
int main() {
static struct netif netif;
static struct ethnetif ethnetif = (PHY^ADDRESS};
int i;
uint8_t confBit;
Dehy (1%Ł&00);
confBit .= ¿btConfBit();
240
8. Klient UDP
AllPinsDisable();
LEDconfigure();
R e d LEDonO ;
LCDconfigure ( } ;
SET_IRQ_PROTECTION(};
netif.hwaddr[0] = 2;
netif.hwaddr[l] = (BOARDJl'YPE » 8) & Oxff;
netif.hwaddr[2} = BOARDJTYPE & Oxff;
netif.hwaddr[3J = (ETH_BOARD » 8) & Oxff;
netif.hwaddr[41 = ETH_BOARD & Oxff;
netif.hwaddr[5) = 1 + confBit;
if (¡confBit) {
IP4_ADDR(6netif.ip_addr, 192, 168, 51, 84);
IP4_ADDR(&netif.netmask, 255, 255, 255, 240);
IP4_ADDR(&netif.gw,
192, 168, 51, 81);
1
0, 0, 0, 0);
0, Ö, 0, 0);
0, 0, 0, 0);
I
error_resetable(LWIPinterfacelnit(&netif, Sethnetif), 5);
LWIPtimersStart(};
LWIPsetAppTimer(SNTPtimer, SNTP_TIMER_MS);
error_resetable(DHCPwait{&netif, 10, 4), 6);
RedLEDoff ();
tem pus2.gum .gov.pl, 212.244.36.228, cezow y zegar atom owy, G łów ny U rząd
M iar, oficjalny serw er dostarczający czas urzędow y w Polsce;
- vega.cbk.poznan.pl, 150.254.183.15, cezow y zegar atom owy, Polska A kadem ia
N auk, C entrum B adań K osm icznych, O bserw atorium A strogeodynam iczne
w B orow cu k. Poznania;
-
ntp.itLw aw .pl, 193.110.137.171, cezow y zegar atom owy, Instytut Łączności
w W arszaw ie;
-
ntp.elprom a.cotn.pl, 83.19.137.3, rtibidow y zegar atom owy, laboratorium porów ­
nujące w zorce czasu, Ł om ianki k. W arszawy;
-
L pl.po ol.ntp.org, pula serw erów rozm ieszczonych na terenie Polski;
-
Leurope.pool.ntp.org, pula serw erów rozm ieszczonych w Europie;
L pool.ntp.org, ogólnośw iatow a pula serwerów .
Do testow ania sam ego protokołu SNTP, w archiw um z przykładam i w katalogu
./m ake/ex8_udp_clnt znajduje się plik linux_sntp_clnt.c, który zaw iera im plem enta­
cję prostego klienta SN TP dla system u Linux. Program ten w yśw ietla szczegółow e
inform acje zaw arte w odpow iedzi otrzym anej od serw era. U rucham ia się go, po­
dając ja k o argum ent nazw ę serw era SNTP. K lient ten nie obsługuje przekroczenia
czasu - jeśli nie dostaniem y odpow iedzi, trzeba usunąć program za pom ocą kom ­
binacji klaw iszy Ctrl-C.
Uwagi końcowe
N iew łaściw ie używ ane i skonfigurow ane klienty SN TP m ogą niepotrzebnie zw ięk­
szyć ruch w sieci i bardzo obciążyć serwery czasu. N ależy bezw zględnie stosow ać się
do dobrych praktyk (ang. best practlces) podanych w RFC 4330, a w szczególności:
-
I
-
Jeśli nazw a lub adres IP serw era SN T P są zapisane w pam ięci stałej urządzenia,
które jest w ytw arzane w celach kom ercyjnych, to musi to być serw er zarządzany
przez producenta lub sprzedaw cę tego urządzenia.
-
Jeśli nie je s t w ym agana dokładność oferow ana przez zegar atom owy, nie należy
korzystać z serw erów pierw otnych, a raczej z puli serwerów , które są synchroni­
zow ane do serw erów pierw otnych.
Testowanie przykładu
Po uruchom ieniu program u w zestaw ie Z L 29A R M ‘w pierw szym w ierszu LC D po­
w inny pojaw ić się data i czas. N a początku je s t to godzina 00:00:00 dnia 1 stycz­
nia 1970 roku. Po zsynchronizow aniu zegara pow inny pojaw ić się aktualna data
i aktualny czas U TC. C zas ten, zależnie od pory roku, spóźnia się w stosunku do
czasu polskiego o jed n ą lub dw ie godziny. W w ierszach od trzeciego do siódm ego
w yśw ietlane są na przem ian nazw y serw erów i statusy klientów.
O prócz serw erów , których nazw y są um ieszczone w pliku źródłow ym ex_sntp.
c, m ożna w ypróbow ać inne serw ery N TP.j N astępujące serw ery są wymienione
w W ikipedii:
-
N ie w olno w ysyłać żądań do serw era częściej niż co 15 sekund.
K lient pow inien zw iększać w ykładniczo odstęp czasu m iędzy kolejnym i żąda­
niam i, jeśli serw er nie odpow iada w rozsądnym czasie.
N ależy używ ać serwerów , które są w sieci położone m ożliw ie najbliżej klienta.
for (i = 0; i < COUNT; ++i) {
Delay (10000000);
SNTPclientStart(serverTbl(i), &status[i });
for {;;);
8.3.3.
241
-
error_resetable(CLKconfigure{), 1) ;
error_permanent (Locall’
imeConfigure (), 2);
error_resetable(RTCconfigure(), 3);
RTCsetCaliback(CiockCallback);
error_resetable(ETHconfigureMII(), 4);
else {
IP4_ADDR(&netif.ip_addr,
IP4_ADDR(£netif.netmask,
IP4_ADDR(finetif.gw,
8.3. Przykład 8 - automatyczna synchronizacja zegara czasu rzeczywistego
tem pusL gum .gov.pl, 212.244.36.227, cezow y zegar atom ow y, G łów ny Urząd
M iar, oficjalny serw er dostarczający czas urzędow y w Polsce;
P rzedstaw iona w yżej im plem entacja je s t bardzo uproszczona. N ie uw zględnia
opóźnień w transm isji pakietów sieciow ych. N ie obsługuje stref czasow ych ani
zm ian czasu na letni i zim owy. Form uły um ożliw iające oszacow anie czasu podróży
pakietów i w yznaczenie korekty czasu klienta zam ieściłem w podrozdziale opisu­
jący m SNTP. Strefy czasow e oraz czas letni i zim ow y są w spierane przez standar­
dow ą bibliotekę języ k a C i dość łatw o m ożna dodać ich obsługę. Jeśli potrzebu­
jem y precyzyjnie określić czas zdarzenia w przeszłości lub różnicę czasu między
zdarzęniam i, trzeba uw zględnić sekundy przestępne, w staw iane od czasu do czasu
dla tsKoryąjjo>vania zegara z położeniem Z iem i w zględem Słońca. Ponadto, m ając
jeszcze św iężo w pam ięci zam ieszanie z „problem em roku 2000” , należy zastano-
242
8. Klient UDI'
wić się nad „problem em roku 2036”, kiedy to 7 lutego o godzinie 6:28:16 1 | ( '
przepełni się znacznik czasu NTP. Z am ieszczona tu im plem entacja w ydaje się naVW '
ten problem odporna. K olejnego problem u m ożem y spodziew ać się w roku 2038,
gdy czas uniksow y w system ach 32-bitow ych stanie się ujem ny. Typ time__t zwy- n-®;
kle definiuje się ja k o liczbę ze znakiem i po doliczeniu do m aksym alnej wartości
231 - 1 następuje warlos'ć ujem na - 2 31, czyli dnia 19 stycznia 2038 roku po godzinie !'!$ i
3:14:07 nastąpi godzina 20:45:52 d nia 13 grudnia 1901 roku. Tak włas'nie zadziała i’
biblioteka N ew lib, użyta do napisania przykładów prezentow anych w tej książce, v
C hoć zapew ne do tego czasu w szystkie kom putery będą ju ż reprezentow ać czas
w arytm etyce co najm niej 64-bitow ej i ich ten problem nie dotknie, to w ciąż mogą ■■
jeszcze pozostaw ać w użyciu 32-bitow e m ikrokontrolery. Pow yższe uw agi należy
uw zględnić, jeśli w ym agam y bardzo dokładnego odm ierzania czasu. Odpowiednie
m odyfikacje program u pozostaw iani C zytelnikow i ja k o am bitne ćw iczenie.
Rozgłaszanie
244
9. Rozgłaszanie UDp
U D P um ożliw ia rozgłoszenie (ang. broadcast) datagram u, czyli w ysianie go je d - '
noczcsnie do w szystkich odbiorców w danej podsieci. W tym rozdziale prezentuję1
dw a przykładow e program y. P ierw szy rozgłasza datagram y U D P i w zasadzie jest.
prostym klientem UDP. D rugi je s t prostym serw erem U D P i je s t przeznaczony do
testow ania tego pierw szego - w yśw ietla na L C D w szystkie odebrane datagram y'
UDP. Z asady działania klienta i serw era U D P w yjaśniłem ju ż w poprzednich 10 / .
działach, w ięc bez zbędnego w stępu teoretycznego przystępuję od razu do opisuprzykładów.
9.1.
Przykład 9a - rozgłaszanie datagramów UDP
N azw y plików przykładu 9a zam ieszczone są w ta b e li 9.1. W śród nich je s t tylko
jeden now y plik, który opisuję w następnym podrozdziale.
T ab . 9 .1 .
Pliki przykładu 9a
Źródłowe i biblioteczne
ex_send_bcast.c
tonl5x8.c
slarlup_stm 32_cld. c
board_conl.c
boardJn i t c
b o a rd jcd_ ks0 1 0 8.c
board Je d . c
iont5x8.h
board_conl.il
board_del.li
board_defs.li
boardJnit.h
b o a rd jc d .h
b o a rd je d .h
u tiljle la y .c
util_eth_nc.c
u til Je d . c
u lilje d .c
u liljw ip .c
util lime.c
Iiblwip4.a
Iibstm32l10x.a
Nagłówkowe
9.1.1.
util_delay.h
util_error.h
u iiijih . b
u liljc d .li
u tilje d .li
u tiijw ip .il
U iiljtC .il
u til lim e.li
CC.Il
cortex-m 3.li
lwipopts.li
slm 32f10x_conf.l)
Plik ex_send_bcast.c
Plik ex_send_bcast.c zaw iera im plem entację prostego klienta UDP, rozsyłającego
cyklicznie datagram y U D P do w szystkich w ęzłów w sw ojej podsieci. W opisanych
dotychczas klientach pozostaw ialiśm y bibliotece lwj.P w ybór portu źródłowego
i w tym celu podaw aliśm y zero ja k o n u m er portu w .jrzecim argum encie wywołania
funkcji udp_bind. W odróżnieniu od tam tych, w tym kliencie używ am y ustalonego
portu źródłow ego, którego num er definiujem y ja k o stalą SRC_PORT. N um er portu,
na który będą w ysyłane datagram y UDP, definiujem y jak o stalą DST_PORT. Stała.
BCAST_TIMER_MS określa okres pow tarzania transm isji w m ilisekundach. Stała BUF_
SI ZE definiuje rozm iar pom ocniczego bufora.
łdefine SRC_PORT
5001
łdefine DST_P0RT
5002
łdefine BCAST_TIMER_MS 2666
łdefine BUF ŚI2E
64
ł
245
9.1. Przykład 9a - roz.glasz.anie datagramów UDP
R ozgłoszenie datagram u realizuje funkcja SendBroadcast. W ysyła ona p oje­
dynczy datagram na przem ian na adres ukierunkow anego rozgłaszania i adres
rozg łaszania w bieżącej podsieci, czyli 255.255.255.255. Podsieć testow a ma
przy d zieloną pulę adresów 192.168.51.80/28, a zatem adresem ukierunkow ane­
go ro zg łaszania w niej je s t 192.168.51.95. Funkcje z biblioteki lw lP przecho­
w ują adres IP w strukturze typu ip_addr, a funkcje z biblioteki standardow ej C
w stru k tu rze typu in_addr. W ysyłany datagram U D P zaw iera krótki tekst A SCII.
T ekst ten zaw iera num er kolejny datagram u, potem adres 1P rozgłaszania i num er
portu, na który datagram je s t w ysyłany. T ekst kończy się znakiem końca w ier­
sza, czyli sekw encją znaków CR i LF. W ysyłany datagram U D P w yśw ietlam y
też na L C D - każdy datagram w osobnym w ierszu. U żyty LC D m oże w yśw ietlić
tylko 8 w ierszy tekstu, w ięc po w yśw ietleniu każdych kolejnych 8 datagram ów
czyścim y ekran L C D . N ależy pam iętać, że funkcja s nprintf i funkcje o bsługu­
ją c e w y św ietlacz ciekłokrystaliczny nie są w spółużyw alne, co spraw ia, że rów ­
nież funkcja SendBroadcast, w której są one w ołane, nie jest w spółużyw alna.
W tym przykładzie w ykonanie funkcji S en d B r o a d c a s t nie zostanie je d n a k nigdy
w yw łaszczone przez przerw anie, w którym m ogłaby zostać ponow nie w yw ołana,
w ięc nie m a problem u.
static void SendBroadcast(void) (
static unsigned count = 0;
struct udp_pcb *pcb;
struct pbuf *p;
1
struct ip_addr broadcast_ip;
struct in_addr ip;
int size;
char b u f fBUF_SIZKJ;
count++;
if (count & 1)
IP4_ADDR(&broadcast_ip, 192, 168, 51, 95);
else
IP4_ADDR(&broadcast_ip, 255, 255, 255, 255);
ip.s_addr = broadcast_ip.addr;
size - snprintf (buf, BUF_SIZE, "%u %s:%u\r\n",
count, inet_ntoa(ip), DST_PORT);
if (size <= 0 J! size >= BUFJJIZE)
return;
pcb = udp_new();
if (pcb == NULL)
return;
*• *
if (ERR_0K != udp_bind (pcb, IP_ADDR_ANY, SRC_P0RT) j)
NULL == (p » pbuf_alloc(PBUF_TRANSPORT, size, PBUF_RAM))} {
udp_remove(pcb);
\-
'Ili-'-,Vi
* ;■£
i ':-'v
9. Rozgłaszanie UI)P
246
udp_sendto(pcb, p, &broadcast_ip, DST_PORT);
pbuf_free(p);
udp_remove(pcb);
9.1.2.
Testowanie przykładu
Do przetestow ania tego przykładu m ożna użyć prostego serw era, który prezentuję
w przykładzie 9b. W ym aga to jed n ak posiadania dw óch zestaw ów uruchom ienio­
w ych. Innym rozw iązaniem jest uruchom ienie prostego serw era na kom puterze, któ­
rego używ a się do program ow ania m ikrokontrolera. Prosty serw er U D P dla system u
L inux, um ożliw iający testow anie tego przykładu, znajduje się w archiw um z przy­
kładam i w pliku U nux_recv_bcast.c, który je s t w katalogu ./m ake/ex9a_send_bcast.
Program ten w yw ołuje się z linii poleceń, podając ja k o argum ent num er portu, na
którym m a nasłuchiw ać serwer. D la każdego odebranego datagram u U D P w yśw iet­
la on inform ację o adresie IP i num erze portu źródłow ego, z którego ten datagram
został w ysłany. W yśw ietla też zaw artość otrzym anego datagram u UDP, zakładając,
że je s t to tekst A SCII. Po skom pilow aniu i uruchom ieniu tego program u, a na­
stępnie uruchom ieniu układu z m ikrokontrolerem , pow inniśm y zobaczyć w ydruk
podobny do poniższego.
if {(count & 7> =— 1>
LCDclear ();
LCDwrite(buf);
)
Funkcja raain nie różni się istotnie od analogicznych funkcji z poprzednich przykła­
dów. Z asadnicza różnica polega na tym , że przed w ejściem w nieskończoną pętlę
ustaw iam y funkcję S en d B ro ad cast ja k o budzik w ołany okresow o co BCAST_TIMER_
MS m ilisekund.
int main () 1
static struct netif netif;
static struct ethnetif ethnetif = (PHY_ADDRESS);
uint8_t confBit;
$ ./linux recv_bcast.elf 5002
Listening on port 5002
Delay(1000000);
confBit = GetConfBit();
AIlPinsDisabłeO;
LEDconfigure();
RedLEDon();
LCDconfigure();
SET_IRQ_PROTECTION();
From:192.168.51.89:5001
Content:! 192.168.51.95:5002
From:192.168.51.89:5001
Content:2 255.255.255.255:5002
error_resetable(CLKconfigure(), 1);
error_permanent(LocalTimeConfigure(), 2);
errorjresetable(ETHconfigureMII{), 4);
t
9.2.
netif.hwaddr[Q) - 2;
netif.hwaddr[l) *= (BOARDJFYPE » 8) & 0xff;
netif.hwaddr(2) = BOARD__TYPE fi 0xff;
netif.hwaddr{3} = (ETH_B0ARD » 8) & 0xff;
netif.hwaddr{41 = ETH_BOARD & Oxff;
netif.hwaddr(5] = 1 + confBit;
if {!confBit) (
IP4_ADDRfŁnetif.ip_addr, 192, 168,
51, 84);
IP4_ADDR(&netif.netmask, 255, 255, 255, 240);
IP4_ADDR(&netif.gw,
192, 168,
51, 81);
1
else 1
IP4_ADDR(fi.netif.ip_addr, 0, 0, 0, 0);
IP4_ADDR(&netif.netmask, 0, 0, 0, 0);
IP4_ADDR(&netif.gw,
0, 0, 0, 0);
Przykład 9b - odbieranie datagramów UDP
N azw y plików przykładu 9b zam ieszczone są w ta b e li 9.2. Jedyny now y plik opi­
suję w następnym podrozdziale.
Tab. 9.2. Pliki przykładu 9b
Źródłowo i biblioteczna
ex recv bcast.c
lont5x8.c
startup_stm32_cld. c
board cont.c
board init.c
boardJcd_ks0108.c
boardJed.o
font5x8.h
board conf.h
board det.h
board dets.h
b o a rd jn it.h
b o a rd jc d .h
b o a rd je d .h
^
- •***■
RedLEDoffO;
>
LWIPsetAppTimer(SendBroadcast, BCAST_TIMER_MS);
for (;;);
util delay. c
u til eth nc.c
u tiljc d .c
utilJod_ex.c
u tilje d .c
u tiljw ip .c
util time.c
Nagłówkowe
1
error_resetable(LWIPinterfaceInit(&netif, fiethnetif), 5);
LWIPŁimersStart();
error_resetable{DHCPwait(Snetif, 10, 4), 6);
)
247
9.2. Przykład 9b - odbieranie datagramów U DP
}
- 4
- 4 * ---------------
util delay.h
u til error.h
u til eth.h
u ffljc d .h
util_lcd_ex.h
u tilje d .h
u tiljw ip .h
u tiljtc .h
u til time.h
Iiblwip4.a
Ubstm32t10x.a
.......
cc.h
cortex~m3.h
Iwipopts.h
stm 32/10x_conUi
248
9,2.1.
9.2. Przykład 9b - odbieranie datagramów UDP
9. Rozgłaszanie UDl'
SET_IRQ_PROTECTION();
Plik ex_recv_bcast.c
error_resetable(CLKconfigure(), 1};
error_permanent(LocalTimeConfigure(), 2);
error_resetable (ETHconfigureMII (), *1);
Plik ex_recv_bcast.c zaw iera im plem entację prostego serw era U D P przeznaczonego
do w spółpracy z klientem z przykładu 9a. S erw er urucham iam y za pom ocą funk­
cji U D P se rv e rS ta rt. A rgum entem tej funkcji je s t num er portu, na którym serwer
m a nasłuchiw ać. Funkcja ta zw raca zero, gdy uruchom ienie serw era pow iodło się.
a w artość ujem ną w przeciw nym przypadku. Jest ona identyczna ja k funkcja o tej
sam ej nazw ie z przykładu 7.
netif.hwaddr[0} = 2;
netif.hwaddr(l) = (BOARD_TYPE » 8) & Oxff;
netif.hwaddr[2] = BOARD_TYPE £ Oxff;
netif.hwaddr[3] = (ETH_BOARD » 8) & Oxff;
netif,hwaddr[4] = ETH_BOARD & Oxff;
netif.hwaddr[5) = 3 + confBit;
if (¡confBit) {
IP4_ADDR(£netif.ip^addr, 192, 168, 51, 85);
IP4__ADDR(£netif .netmask, 255, 255, 255, 240);
IP4_ADDR(£netif.gw,
192, 168, 51, 81);
static int UDPserverStart(uintl6_t port);
Funkcja U D P se rv e rS ta rt ustaw ia funkcję zw rotną re c v _ c a llb a c k , która obsługuje
odbierane datagram y. W funkcji r e c v _ c a llb a c k w yśw ietlam y w pierw szym wier­
szu L C D adres IP i num er portu źródłow ego, z k tórego został w ysłany datagram
UDP, a w pozostałych w ierszach zaw artość odebranego datagram u, zakładając, że
je s t to tekst A SCII. P rzed w yśw ietlen iem kolejnego datagram u czyścim y ekran
LCD.
\
else {
IP4_ADDR(£netif.ip_addr,
IP4 ADDRiinetif.netmask,
IP4_ADDR(£netif.gw,
static void recv_callback(void *arg, struct udp_pcb *pcb,
struct pbuf *p, struct ip_addr *addr,
uintl6_t port) (
struct pbuf *q;
uint!6__t len;
)
)
error_resetable(UDPserverStart(UDP_PORT), 7);
RedLEDoff();
for (;;);
2.
A by ten program m ógł odbierać datagram y w ysyłane przez program z przykładu
9a, serw er musi nasłuchiw ać na porcie 5002.
5002
Funkcja main je s t bardzo podobna do analogicznej funkcji z poprzedniego przykła­
du. Są dw ie istotne różnice. K onfigurujem y inne adresy M A C i IP, aby program y
z przykładów 9a i 9b m ogły być uruchom ione rów nocześnie w tej sam ej sieci testo­
w ej. N a końcu zam iast klienta urucham iam y serw er'U D P.
int main () {
static struct netif netif;
static struct ethnetif ethnetif « (PHY_ADDRESS);
uint8_t confBit;
Delay(1000000);
confBit = GetConfBit();
AllPinsDisable();
"
LEDconfigure(};
RedLEDonO ;
LCDconfigureO /
*
0, 0, 0, 0);
0, 0, 0, 0);
0, 0, 0, 0);
error_resetable(LWIPinterfacelnit(Snetif, £ethnetif), 5);
LWIPtimersStart();
error_resetable (DHCPwait (Snetif, 10, *1), 6);
LCDclear();
LCDwriteIPport(addr, port);
LCDputchar(,\n');
for (len = 0, q = p; len < p->Łot_len; len += q->łen, q = q->next)
LCDwriteLenWrap(q->payload, q->len);
pbuf_free(p);
»define UDP_P0RT
249
Testowanie przykładu
P rzykład ten zasadniczo m a ch arak ter pom ocniczy. A le aby móc go przetestow ać
sam odzielnie, w archiw um z przykładam i um ieszczony je s t prosty klient U D P dla
L inuksa, w ysyłający cyklicznie co 4 sekundy datagram na podany adres 1P i nu­
m er portu. Im plem entacja tego klienta znajduje się w pliku linux_send_bcast.c,
który znajduje się w katalogu ,/m ake/ex9b_recv_bcast w archiw um z p rzykłada­
mi. P rogram ten w yw ołujem y, podając dw a argum enty: docelow y adres IP i nu­
m er portu. Program w ysyła takie sam e datagram y U D P jak program z przykładu
9a. Z aw artość w ysłanych datagram ów U D P w ypisuje na standardow e w yjście.
Z a po m o cą tego program u m ożna w ysyłać je n a ”adres rozgłaszania w bieżącej
podsieci:
$ ./łinux_send_bcast.elf 255.255.255.255 5002
1 255.255.255.255:5002
2 255.255.255.255:5002
M ożna też w ysyłać datagram y U D P na adres ukierunkow anego rozgłaszania:
$ ./linux_send_bcast.elf 192.168.51.95 5002
1 192^.68.51.95:5002
2 19i|i68.$ 1 ^ 5 : 5 0 0 2
250
9. Rozgłaszanie UDP
Ponadto w celach testow ych m ożna rów nież w ysyłać datagram y U DP po prostu na
adres jednostkow y:
$ ,/linux___send_bcast.elf 192.168.51.90 5002
1 192.168.51.90:5002
2 192.168.51.90:5002
Serwis WWW
10.1. Komunikacja między klientem a serwerem WWW
Jedną z bardzo ważnych usług w Internecie, a być m oże w ręcz usługą najw ażn iej-'
szą, jest W W W (ang. worlcl wide web). N ajpraw dopodobniej w iększość internau- ■,
tów utożsam ia Internet z WWW. U sługa W W W działa w m odelu klient-serwer.
Serw ery udostępniają różnego rodzaju w itryny i portale, a klientam i są przeglądarki1
internetow e, instalow ane w każdym urządzeniu m ającym dostęp do intersieci, obec­
nie rów nież w telefonach kom órkow ych. W iele urządzeń sieciow ych, np. rutery do­
m ow e, w yposaża się w serw ery W W W , um ożliw iające zarządzanie nim i za pomocą •
przeglądarki internetow ej. Popularność W W W w ynika z atrakcyjnego i intuicyjne­
go interfejsu graficznego. R ów nież konstruow ane przez nas urządzenia sterowane
m ikrokontroleram i chcielibyśm y w yposażać w taki interfejs, dlatego w tym ro z d zia -1
le przedstaw iam przykład bardzo prostego serw isu W W W , który zajm uje mniej niż 1
80 KiB pam ięci Flash. Jak przystało na ostatni rozdział książki, jest to najbardziej
skom plikow any z prezentow anych w niej przykładów.
< sch em a t> ://< w ęze i> :< p o rt> /< śc ież k a> ? < z ap y ta m e> if< IY u g m en t>
Pole <w ęzeł> je s t nazw ą dom enow ą w ęzła lub adresem IP w notacji dziesiętnej
z kropkam i. Pole <port> je s t num erem portu usługi sieciow ej, zapisanym jako
liczba przy podstaw ie dziesięć. Pole to um ożliw ia określenie niestandardow ego
num eru portu, innego niż dom yślny dla danego schem atu. O ddziela się go od
poprzedzającej części U RI dw ukropkiem . Pole <ścieżka> określa zw ykle nazw ę
pliku zaw ierającego zasób. Jest oddzielone od poprzedzającej części U RI uko­
śnikiem . Pole < zapytanie> zaw iera dodatkow e param etry, w ysyłane do serw era
usługi i m ające w pływ na udzieloną przez niego odpow iedź. M a to na przykład
zastosow anie przy dynam icznym generow aniu stron W W W . K ażdy param etr
składa się z nazw y i w artości oddzielonych znakiem rów ności. Pole <zapytanie>
je s t o d dzielone od poprzedzającej je części U R I pytajnikiem . K olejne param etry
o ddziela się od siebie znakiem et (ang. am persaiul), czyli &. Pole <fragm ent>
specyfikuje fragm ent zasobu. Jest oddzielone od poprzedzającej je części URI
krzyżykiem . P oszczególne pola identyfikatora są opcjonalne i nie m uszą w ystę­
pow ać. Jeśli jak ieś pole nie w ystępuje, to nie w ystępuje też znak oddzielający to
pole od poprzedniej części URI, przy czym nie dotyczy to znaków oddzielających
schem at od dalszej części URI. Te znaki przynależą do schem atu i m uszą się
pojaw ić, jeśli podany je s t schem at. A plikacja m oże określić schem at dom yślny.
D la przeglądarki internetow ej dom yślnym schem atem je s t http. K ażdy schem at
ma zw ykle przypisany dom yślny port. Jeśli używ any je s t port dom yślny, to pole
<port> nie m usi w ystępow ać. D la http dom yślnym num erem portu je s t 80. W ięcej
na tem at U RI m ożna przeczytać w dokum encie R FC 3986. Poniżej zam ieszczone
są przykładow e URI.
10.1. Komunikacja między klientem a serwerem WWW
K om unikację m iędzy użytkow nikiem oraz reprezentującym go klientem a serwe­
rem W W W m ożna podzielić na trzy fazy:
-
U żytkow nik, posługujący się przeglądarką internetow ą, w pisuje nazw ę serwisu
albo klika na odnośnik lub przycisk. W w yniku tego przeglądarka generuje iden­
tyfikator zasobu, który ma być w yśw ietlony użytkow nikow i.
-
Przeglądarka w ysyła do serw era żądanie dostarczenia zasobu.
Serw er odsyła żądany zasób lub inform ację o błędzie.
Z w ykle
zasobów
form acji
zasobów
253
w yśw ietlenie strony internetow ej w ym aga ściągnięcia wielu kolejnych
zaw ierających tekst i grafikę. N a podstaw ie otrzym anych dotychczas in­
przeglądarka autom atycznie generuje kolejne identyfikatory potrzebnych
i dla każdego z nich pow tarza dw ie ostatnie fezy kom unikacji.
fi!e :///k a ta lo g l/k a ta lo g 2 /p !ik
ftp://ftp.is.co.za/ric/rrc3y86.txt
URI (ang. U niform R esource Identifier) je st ustandaryzow anym sposobem identy­
fikow ania różnego rodzaju zasobów , w tym przede w szystkim zasobów interneto­
wych. Szczególnym i przypadkam i U RI są U RN (ang. U niform R esource Name)
i U R L (ang. Uniform R esource Locator). U RN określa tylko nazw ę zasobu, a URL
oprócz identyfikacji zasobu w skazuje rów nież sposSb'dostępu do niego. Podzbiory
U RN i U RL nie są rozłączne, konkretny identyfikator m oże być zaklasyfikow any
jednocześnie jak o U RN i URL. Identyfikator U RI rozpoczyna się od pola <schemat>, które określa form at pozostałej części identyfikatora, protokół kom unikacyjny
itd. Po tym polu następuje dw ukropek i część specyficzna dla danego schem atu.
B ardzo często spotykanym i schem atam i są: file , ftp , http, m ailto itd.
< sc h e m u t> :< c z ę & sp ecy ficr.u a d la sc h e m a tu >
W śród w szystkich form atów URI, ze w zględu na zastosow anie w W W W , najbar­
dziej dla nas interesujący jest schem at hierarchiczny, w którym część specyficzna
schem atu rozpoczyna się dw om a ukośnikam i.
h ttp ://w w w .ietf.o rg /rfc/3 9 8 6 .tx t
h ttp ://w w w ,se rw e r:8 0 8 0 /k a ta lo g /in d e x .lu m l? p a ra m e trl= a b c & p a ra m e tr2 = i2 3 # ro z iiz ia l-l
U lap ://[2 0 0 I:cib 8 ::7 ]/c-G B 7 o b je ctC lass? o n e
n u iilto :J o h n .D o e@ e x am p le.co m
n ew .s:co m p .in fo sy sien is.w w w .serv ers.u n ix
ie i:- f l - 8 16-555 -1 2 1 2
te ln e t://! 9 2 .0 .2 .1 6 :8 0 /
u rn :o a sis:n a m e s:sp e c ific a tio n :d o c b o o k :d td :x m ł:4 .1 .2
1 2 7 .0 .0 .1 :8 0 8 0
1.1.2.
HTTP
H TTP (ang. H ypertext Transfer Protocol) je s t protokołem , za pom ocą którego prze­
glądarka internetow a kom unikuje się z serw erem WWW. A ktualna w ersja tego pro­
tokołu, czyli w ersja L I, jest opisana w dokum encie RFC 2616. H TT P używ a proto­
kołu transportow ego TCP. Serw er standardow o nasłuchuje na porcie 80. H TTP jest
protqkolem bezstanow ym - w ym iana kom unikatów składa się z żądania w ysyłane­
go [t®ez k,|tąnta i odpow iedzi odsyłanej przez serwer. W yśw ietlenie strony W W W
w ym aga zw ykle ściągnięcia wielu zasobów (tekst, obrazki), a dla każdego z nich
10.1. Komunikacja między klientem a serwerem WWW
musi zostać w ysiane osobne żądanie. W wersji 1.0 H TTP każda taka komunikacją
odbyw a się w osobnym połączeniu TCP. W wersji 1.1 HTTP, w celu zmniejszenia
narzutu zw iązanego z budow aniem i rozłączaniem połączenia, w pojedynczym po- :
łączeniu T C P m ożna przesłać w iele kolejnych żądań i odpow iedzi.
Protokół H TT P je s t d o ić ro zbudow any i nie m a tu m iejsca, aby przedstaw ić go 4,
w całości. P okażę tylko k ilk a przykładów . K om unikaty kodow ane są tekstowo.;';!:
W niektórych m iejscach w ielkość liter nie m a znaczenia (ang. case insensiti
ve), w innych zaś je s t istotna (ang. case sen sitive) - je s t to szczegółow o opisi
ne w specyfikacji p rotokołu. K ażdy w iersz kończy się sek w en cją znaków CK
i LF. Ż ądan ie w ysyłane p rz e z k lien ta składa się z nagłów ka (ang. header), I
ry kończy się pustym w ierszem , czy li dod atk o w ą sekw encją znaków CR i LI-. ■'
Po nagłów ku m oże w ystępow ać o p cjo n aln e ciało (ang. body) żądania. Pierw:
w iersz nagłów ka zaw iera nazw ę m etody, U RI oraz w ersję p rotokołu używi
przez klienta. P oszczególne sk ład n ik i p ierw szego w iersza o d d ziela się pojedy
czym i spacjam i. N ajczęściej uży w a się m etody GET, któ ra ozn acza żądanie do­
starczenia zasobu. U RI żądanego zasobu m ożna podać w cało ści, ale m ożna
pom inąć pola < schem at> , < w ęzeł> i < port> , g dyż żądanie je s t k ierow ane przi
połączenie TCP, któ re w łaśnie zo stało otw arte do serw era o k reślo n eg o w polat
< w ęzeł> i <port>, a pole < sch em at> je s t w tym p rzypadku nadm iarow e, bo w ia­
dom o, że p rzesyła się k o m unikaty pro to k o łu HTTP. K olejne w iersze nagłów ka U
um ożliw iają przekazanie d o d atk o w y ch param etrów . W iersze z param etram i skła­
dają się z nazw y param etru, d w u k ro p k a i w artości param etru. W artość param etru ,,
m oże być po p rzed zo n a białym i znakam i - p referpw ana je s t po jed y n cza spacja. '
B iałe znaki na końcu w iersza są ignorow ane. Ż ąd an ie z m etodą G E T nie zaw ie -1 ..
ra ciała. Z atem n ajp ro stsze m ożliw e żąd an ie w ygląda następ u jąco (pusty w ie rv
kończący żądanie je s t istotny):
G E T / H T T P / 1 .0
C zęsto zdarza się, że jeden fizyczny serw er pod tym sam ym adresem IP obsługuje
w iele nazw dom enow ych. Z punktu w idzenia klientów w ygląda to ja k w iele wirtu­
alnych serwerów. A by to um ożliw ić, klient um ieszcza nazw ę serw era ja k o parametr
H ost, który jest obow iązkow y od w ersji 1.1 HTTP.
G E T /pub/index.html H T T P / 1 .!
Host: www.nazwa.serwera
••• “
*1
Zw ykle przeglądarka internetow a w ysyła w żądaniu więcej inform acji. Popatrzmy
na poniższy przykład. Param etr U ser-A gent identyfikuje przeglądarkę, a czasem też
system operacyjny zainstalow any na kom puterze użytkow nika. K olejne parametry
A ccept inform ują serw er o akceptow anych przez przeglądarkę form atach danych,
obsługiw anych językach, m etodach kom presow ania danych, obsługiw anych rodza­
jach kodow ania znaków narodow ych ild. Płiramelr C onnection inform uje, czy po­
łączenie ma być zam knięte (w artość close) natychm iast po odesłaniu odpowiedzi,
czy utrzym yw ane (w artość keep-alive) przez serwer, gdyż będą w nim przesyłane
kolejne żądania.
255
G E T / l e d ? L E D = R & L E D = G H T T P / 1 .1
Host: localhost
User-Agent: Firevox/1.0 (Operating Systcm/3.0)
Accept: text/html.text/plain,image/png
Accept-Language: pl,en-us,en
Accept-Encoding: gzip,deflate
Acccpt-Charsct: ISO-8859-2,UTF-8
Connection: close
Zauw ażm y, że w pow yższym przykładzie w URI przesyłane są param etry zapyta­
nia. Jeśli tych param etrów je s t dużo, jeśli pochodzą z rozbudow anego formularza,
w ygodniej je st użyć w tym celu m etody POST. W tedy param etry zapytania zostaną
um ieszczone w ciele kom unikatu, ja k w poniższym przykładzie. Param etr C ontenl-Type inform uje, że kom unikat zaw iera ciało i podaje sposób jeg o kodow ania.
N atom iast w artość param etru C ontent-L ength inform uje o długości ciała w okte­
tach. Zw róćm y uw agę, że ciało kom unikatu nie kończy się znakiem końca w iersza
(czego nie w idać na w ydruku). Z w róćm y też uw agę na pusty w iersz oddzielający
nagłów ek od ciała kom unikatu.
P O S T /led H T T P / 1 .1
1-Iost: localhost
User-Agent: Firevox/1.0 (Operating System/3.0)
Connection: close
Cnntent-Typc: application/x-www-fonn-urlencoded
Content-Length: 11
LED=R&LED=G
O dpow iedź serw era składa się z nagłów ka, który kończy się pustym w ierszem . Po
nagłów ku m oże w ystępow ać ciało zaw ierające zasób, o który prosił klient. Pierwszy
w iersz nagłów ka zaw iera w ersję protokołu używ aną przez serwer, kod statusu (ang.
status code) i jego opis tekstow y (ang. reason phrase). Poszczególne składniki
pierw szego w iersza oddziela się pojedynczym i spacjam i. K od statusu inform u­
je o w yniku działania serw era. Jest to trzycyfrow a liczba dziesiętna. Interpretacja
poszczególnych zakresów w artości je st zam ieszczona w tab eli 10.1. O pis teksto­
wy nie je s t interpretow any przez oprogram ow anie klienta i je s t przeznaczony dla
T ab . 1 0 .1 .
Niektóre kody statusu HTTP
1 0 0 ...1 9 9
Informacje o postąpię przetwarzania żądania, np.:
100 — cząść żądania została odebrana i zaakceptowana
2 0 0 ...2 9 9
Żądanie klienta zostało poprawnie odebrane, zrozumiane i zaakceptowane, np.:
20 0 - odpowiedź zawiera żądany zasób
3 0 0 ...3 9 9
Klient musi podjąć dodatkową akcją w celu uzyskania zasobu, np.:
301 - żądany zasób został przeniesiony na stale i znajduje sią pod innym adresem
4 0 0 ...4 9 9
Wystąpił błąd po stronie klienta, np.:
4 0 0 - przestane żądanie ma niepoprawną składnią,
40 4 - żądany zasób nie istnieje
Wystąpił błąd po stronie serwera, np.:
500'.ł .% 9 9 i Siffl - nie można obsłużyć żądania z powodu nieoczekiwanego problemu,
5 0 S i- serwer nie obsługuje wersji HTTP podanej w żądaniu
256
użytkow nika. Podobnie ja k w żądaniu, kolejne w iersze nagłów ka odpow iedzi i
opcjonalne i um ożliw iają przekazanie dodatkow ych param etrów. W iersze z pari
metram i składają się z nazw y param etru, dw ukropka i wartos'ci param etru. Warto:
param etru m oże być poprzedzona białym i znakam i - preferow ana je st pojedyn<
spacja. Białe znaki na końcu w iersza są ignorow ane. W poniższym przykłai
param etr D ate inform uje o dacie i czasie w ysłania odpow iedzi. P aram etr Server
identyfikuje serw er i system operacyjny. Param etr Last-M odified inform uje o da<
i czasie ostatniej m odyfikacji przesyłanego zasobu. Param etr Connection o w
tości close inform uje, że serw er zam knie połączenie po w ysłaniu tej odpow ied/i
W artość param etru C ontent-Length określa długość ciała w iadom ości w oktetach,
czyli rozm iar przesyłanego zasobu. P aram etr Content-Type określa rodzaj zasobi
i sposób jego kodow ania. C zęsto spotykanym i w artościam i tego param etru są: lex
htm l, text/plain, text/xm l, text/css, application/octet-stream , application/pdf, image'
gif, im age/jpeg, im age/png, im age/svg+xm l, im age/tiff, im age/vnd.m icrosoft.ici
itd. N azw y te jednoznacznie identyfikują rodzaj zasobu i nie w ym agają objaśnienia.
D odatkow e pole charset specyfikuje sposób kodow ania zasobu, inform uje o sposi
bie kodow ania znaków. W poniższym przykładzie ciało odpow iedzi zaw iera teksi
zapisany w H TM L z użyciem kodow ania U TF-8. Z asadniczą część ciała odpowie­
dzi tu pom inięto i zastąpiona w ielokropkiem .
H T T P / 1.1 200 O K
Dale: Fri, 20 A u g 2010 10:38:34 G M T
Server: Apacz/i.O (Operating Sys(em/3.0)
Last-Modified: Fri, 20 A u g 2010 10:11:55 G M T
Connection: close
Content-Length: 937
Content-Type: text/html; charset=UTF-8
<h tm l>
10.1.3.
10.1. Komunikacja między klientem a serwerem WWW
10. Serwis VVU II
HTML
H TM L (ang. H ypertext M arkup Language) jest podstaw ow ym językiem opisu stron
WWW. O pisuje strukturę dokum entu W W W za pom ocą znaczników (ang. tags).
N azw a znacznika jest otoczona naw iasam i ostrokątpym i. W iększość znaczników
w ystępuje w parach: znacznik otw ierający i z.naczni^zam ykający. W znaczniku za­
m ykającym jeg o nazw a poprzedzona je s t ukośnikiem . N a przykład cały dokument
rozpoczyna się znacznikiem <htm l>, a kończy znacznikiem </htm l>. Znaczniki
<head> i </head> otaczają nagłów ek dokum entu. Znaczniki <title> i </title> iden­
tyfikują tekst, który przeglądarka pow inna w yśw ietlić na pasku tytułow ym swojego
okna. Znaczniki <body> i </body> otaczają opis strony, która m a być w yśw ietlo­
na w ew nątrz okna przeglądarki. Z naczniki < h ł> , < /h l> , <h2>, </h2> itd. służą do
w skazania nagłów ków poszczególnych rozdziałów i sekcji w tekście.
H TM L um ożliw ia też zdefiniow anie sposobu prezentacji dokum entu w przeglą­
darce internetowej. Znaczniki <center> i </center> nakazują w ycentrow anie treści,
którą otaczają. Z nacznik <p> rozpoczyna nowy paragraf, a znacznik </p> kończy
,,
257
go. N iektóre znaczniki nie m ają pary, w ystępują sam odzielnie, np. znacznik <hr />
w yśw ietla poziom ą linię. Takie znaczniki, w edług najnow szej specyfikacji, mają
po nazw ie spację i ukośnik. Z nacznik m oże też mieć param etry, które um ieszcza
się w znaczniku otw ierającym po nazw ie i oddziela białym i znakam i. Param etry
mają zw ykle postać: nazw a param etru, znak rów ności, wartość param etru w cu ­
dzysłow ach. Przykładow o znacznik <font size= ”6”> nakazuje zm ianę rozm iaru
czcionki. O dpow iadający mu znacznik dom ykający </font> przyw raca poprzed­
ni rozm iar czcionki. N ow oczesne serw isy W W W nie korzystają z tej możliwości
H TM L-u i opisują w ygląd strony za pom ocą arkuszy stylów CSS (ang. Cascading
Style Sheets).
H TM L pozw ala na osadzanie w tekście rysunków, filmów, odnośników do innych
dokum entów itp. Na przykład znacznik <im g src=” ...” alt=”...” /> nakazuje um iesz­
czenie obrazka. Param etr sre w skazuje URI zasobu, który zaw iera ten obrazek i któ­
ry trzeba ściągnąć. Param etr alt określa tekst, który m a być w yświetlony, gdy tego
zasobu nie udało się ściągnąć lub gdy przeglądarka pracuje w trybie tekstow ym
i nie um ożliw ia w yśw ietlenia grafiki. Znaczniki <a href=” ...”> i </a> otaczają tekst
odnośnika, zw ykle podkreślony i w yśw ietlany w kolorze niebieskim . Param etr href
określa U RI zasobu, którego przeglądarka m a zażądać po kliknięciu na ten tekst.
H TT P pozw ala też na osadzanie w dokum entach ciągów instrukcji języków skryp­
towych.
H TM L um ożliw ia tw orzenie interaktyw nych formularzy. Znacznik <form action=
”...” m ethod=”...”> rozpoczyna definicję form ularza. P aram etr action definiuje URI,
który ma być w ysłany do serwera. Param etr m ethod określa m etodę (zw ykle POST),
która ma być użyta. Z nacznik </lbrm > kończy definicję formularza. W ewnątrz for­
m ularza m ożna zdefiniow ać kontrolki za pom ocą znacznika <input />. Param etr
type określa typ kontrolki. Przykładow o w artość checkbox oznacza pole wyboru,
a w artość subm it - przycisk, na który trzeba kliknąć, aby przeglądarka wykonała
akcję opisaną w param etrach action i m ethod znacznika <form >. Interpretacja para­
metrów znacznika kontrolki zależy od typu kontrolki. Param etr value w kontrolce
typu subm it określa tekst, który ma być w yśw ietlany na przycisku. Param etry name
i value kontrolki typu checkbox oznaczają odpow iednio nazw ę i wartość param etru
w ysyłanego w zapytaniu, które dla m etody G E T je st um ieszczane w polu <zapytanie> URI, a dla metody PO ST w ciele żądania, jak to przedstaw iono w przykładach
w rozdziale 10.1.2.
Nie ma tu miejsca na szczegółowy opis składni i \yszystkich elementów HTML-u.
Czytelnik zainteresowany poznaniem tego języka bez problemu znajdzie w Internecie
jakiś samouczek. Zamiast kontynuować jego opis, obejrzyjmy następujący przykład
strony wygenerowanej przez serwer z prezentowanego w tym rozdziale przykładu 10.
<himl>
<headxtitle>Przykladowy Serwer HTTP</litlex/head>
<bodyxcenler>
< p x i m g src=”slm32_logo.gif”alt=”S T M 3 2 L O G O " / x / p >
< p x f i § i t s iy ^ F |’6” > 0 0 0 : 0 9 : 0 2 . 4 7 0 < / f o n t x / p x h r />
< f o r m action=’
l/led”melhod="post”>
259
10.2. Przykład 10 - prosty serwis WWW
< p > C z e r w o n a dioda świecąca <inpul type=”chcckbox”n a m e = ”L E D ”value=”R ”/></p>
<p>Ziclona dioda świecąca cinput type="chcckbox”n a m e = " L E D ”value=”G ”checked /></p>
|
f
..
10 2
Prezentow any w tym podrozdziale przykład serw isu W W W składa się z serw era
H TT P i aplikacji WWW. Serw er jest bardzo prosty, obsługuje tylko fragm ent proto­
kołu H TT P i nie je s t w pełni zgodny ze specyfikacją zaw artą w RFC 2616, ale jest
w ystarczająco funkcjonalny, aby m ożna było oprzeć na nim aplikację kom unikują­
cą się z m ikrokontrolerem za pom ocą przeglądarki internetowej. Serw er ten może
też być podstaw ą do w łasnej, pełniejszej im plem entacji HTTP. N azw y plików tego
przykładu zebrano w ta b e li 10.2. W iększość z nich opisałem ju ż w poprzednich
rozdziałach. W kolejnych podrozdziałach om aw iam szczegółow o pliki specyficzne
dla tego przykładu.
< p x i n p u t type=”submit”valuc=”Z m i e ń ”/></p>
< / f o r m x h r />
<p>iwIP/i.3.2 C M S i S / i . 3 0 S T M 3 2 F 1 0 x Standard Periplicrals Library/3.3.0 ncwlib/i.!8.0</p>
</ccntcrx/body>
</html>
Na podstaw ie pow yższego opisu przeglądarka internetow a w yśw ietla stronę poka­
zaną na ry s u n k u 10.1. N a górze je s t w yśw ietlany obrazek, a poniżej niego czas,
który upłyną! od uruchom ienia m ikrokontrolera. Pom iędzy poziom ym i liniami znaj­
duj;) się pola w yboru i przycisk Z m ień um ożliw iające sterow anie diodam i świecący-;
mi w zestaw ie ZL29A R M . N a dole w yśw ietlane są inform acje o w ersjach bibliotek
użytych do skom pilow ania przykładu.
;
<3 Przykładowy Serwer HTTP - Microsoft In te l net rnplm er
File
Edit
g )B a c k -
View
Favorites
- ¿ j)
Tools
jj|
M B
Help
_
. ■ x ') |y P
Address | ÿ | h ttp :// 192. l 68. 51.B9/
s” reh
Favorites
_
.
s
___ _____
_
[ f, j j - ,;v
@
- iJ k £ j Go
„
l Unl^ r "
-Tv'
■•-S T M . ' ■$
..." A
■U33 OfG. niiam al, duel CAN. ;u';'.c i. ¡'ss Is!
0 00 :09 :02.470
Przykład 10 - prosty serwis WWW
...
10 2 1
Pliki http_parser.h i http_parser.c
H TTP je st protokołem tekstow ym , więc serw er m usi przetłum aczyć odebrany ko­
m unikat na postać lepiej nadającą się do dalszego przetw arzania, zw ykle na postać
binarną. Proces ten nazyw a się parsow anie i obejm uje analizę leksykalną oraz skła­
dniow ą tekstu. N ie w dając się w szczegóły, chodzi w skrócie o pom inięcie nieistot­
nych fragm entów tekstu (białych znaków, kom entarzy), w yszukanie słów kluczo­
w ych, specjalnych sekw encji znaków (operatorów ), nazw (identyfikatorów ), stałych
(literałów ), a następnie spraw dzenie popraw ności składni i stw orzenie struktury da­
nych, którą będzie m ożna dalej w ygodnie przetw arzać. K om unikaty H TTP są dość
skom plikow ane i napisanie pcinego parsera H TT P je s t zadaniem czasochłonnym .
Z w ykle nie pisze się parserów od podstaw. Istnieją dobre darm ow e narzędzia, ta­
kie ja k na przykład Flex i Bison, um ożliw iające przyspieszenie i zautom atyzow a­
nie procesu im plem entow ania parsera. Poniew aż jed n ak przykładow y serw er ma
być bardzo prosty, napiszem y też prosty parser. Jego interfejs definiujem y w pliku
h ttp jm rse r .h , a im plem entację um ieszczam y w pliku http_jmrser.c. Zaczynam y od
zdefiniow ania typu w yliczeniow ego m ethod_t dla m etod, które parser m a rozpo­
znaw ać.
typedef enum (GET_METHOD = 1, POST__METHOD = 2| method_t;
Tab. 10.2. Pliki przykładu 10
Źródłowe 1 biblioteczne
C z e r w o n a dioda świecąca JH_.
Zielona dioda świecąca
*
‘Zmień
ex_httpd.c
http_application.c
http_parser.c
htlp_server.c
startup_stm32_cld.c
board_conl.c
boardJ n il.c
boardJe d .c
http.h
http_applicalion.li
http_parser.h
http_serm .h
stm32_logo.h
board_conf.h
board_del.h
board_dels.h
boardJnit.h
bo a rd je d .h
util_delay.c
util_eth_nc.c
u tilje d .c
u liljw ip .c
util time.c
Iiblwip4.a
Iibstm32l10x.a
Nagłówkowe
lwIP/1.3.2 C M S I S / 1 . 3 0 S T M 3 2 F 1 0 x Standard Peripherals Library/3.3.0 newlib/1.18.0
.¿J
[ ¿ j Done
Rys. 10.1. Główna strona serwisu WWW z przykładu 10
| $ Internet
- ..-------------------------------------
ulil_delay.h
util_error.h
ulil_elh.li
u lilje d .h
u tiljw ip .h
u tiljtc .h
u til tim e.li
cc.h
cortex-m3.h
Iwipopts.h
stm32t10x_conf.h
260
10. Serwis WWW
D efiniujem y też typ w yliczeniow y s t a t u s _ t dla kodów statusu odsyłanych klien­
towi przez serwer. Są to tylko niektóre, w ybrane kody statusu, spośród zdefinio-F
w anych w RFC 2616. N asz serw er je s t bardzo uproszczony i w iększość b łę d ó w :
w żądaniu otrzym anym od klienta kw ituje statusem „400 Bad R equest” . Naton
napotkaw szy problem z udzieleniem odpow iedzi, w ysyła klientow i status „51
Internal Server E rror” . D odatkow o serw er rozpoznaje błędną nazw ę zasobu i nieoh- '■
sługiw aną w ersję HTTP, w ysyłając odpow iednio status „404 N ot Found” lub „51 ■' .
H TTP Version N ot Supported” . Status „100 C ontinue” je st używ any wewnętrznie, •>.;
przez serw er i oznacza, że analiza żądania jeszcze się nie zakończyła. Jeśli żądl
klienta je s t popraw ne, to serw er odsyła żądany przez niego zasób i w odpowied ■
um ieszcza status „200 O K ” .
typedef enum (Continue_X00
=
OK_200 ~
=
Bad_Request_400
=
Not_Found_404
=
Internal_Server_Error_500
=
HTfP_Version_Not_Supported_505 =
10.2. Przykład 10 - prosty serwis W W W '
261
p aram _len. Jeśli param etr zostanie znaleziony, to pod odpow iednim indeksem w tej
tablicy parser um ieszcza wartość 1.
struct http_parser *
http_parser_new(char const * const * const res_tbl, int res_len,
char const * const * const prm_tbl, int prm_len) {
struct http_parser *s;
s = memjnailoc(sizeof(struct http_parser) + prm_len - 1);
if (s) (
s->state « METHOD_STATE;
s->method = 0;
s->buffer_idx = 0;
s->resource_tbl = res tbl;
s->resource__len = res_len;
s->resource_idx = -ł;
s->content_len = 0;
s->param_tbl = prm_tbl;
s->param_len = prm__len;
memset(s->param_flag, 0, prm_len);
100,
200,
100,
404,
500,
505) status_t;
}
return s;
W ew nętrzny stan parsera przechow ujem y w strukturze typu h ttp _ p a r s e r .
i
łdefine BUFFER_SIZE 32
struct http_parser {
state;
state_t
method;
method t
buffer[BUETER_SIZE];
char
buffer idx;
int
char const * const * resource_tbl;
resource len;
int
resource idx;
int
content len;
int
char const * const * param tbl;
param len;
int
param flag 11j;
char
Funkcja p arser_ n ew tw orzy now y parser, czyli alokuje nową strukturę typu h ttp _
p a r s e r i inicjuje jej składow e. Jej pierw szy argum ent r e s _ t b l je st wskaźnikiem
do tablicy w skaźników do nazw zasobów, które parser m a rozpoznaw ać. Drugi
argum ent re s _ le n zaw iera rozm iar tablicy r e s _ tb l. Trzeci argum ent prm _tbl
je st w skaźnikiem do tablicy w skaźników do napisów z param etram i, które parser
ma rozpoznaw ać. C zw arty argum ent prm _len zaw iera rozm iar tablicy prra_tbl.
Funkcja ta zw raca w skaźnik do struktury typu h tt p _ p a r s e r , która identyfikuje par­
ser. W skaźnik ten je s t przekazyw any ja k o pierw szy argum ent pozostałych funkcji
m odułu parsera. Dzięki tem u m ożna utw orzyć w iele parserów - każde odebrane
przez serw er połączenie T C P m a przydzielony w łasny parser. Funkcja zw raca N U L L ,
gdy nie udało się przydzielić pam ięci.
Parser im plem entujem y jak o autom at stanowy. Stan parsera przechow ujem y w skła­
dow ej s t a t e . D efinicja typu s t a t e _ t znajduje się w dalszej części tego podrozdzia­
łu, przy opisie autom atu. W składow ej raethod parser zapisuje identyfikator rozpo­
znanej metody. W składow ej b u f f e r parser przechow uje fragm ent analizowanego
kom unikatu. Składow a b u f f e r _ id x zaw iera liezfię,-znaków zapisanych aktualnie
w tym buforze. Składow a r e s o u r c e _ tb ł jest w skaźnikiem do tablicy wskaźników
do nazw zasobów, które parser m a rozpoznaw ać. Składow a re s o u rc e _ łe n zawiera ,
rozm iar tej tablicy, czyli liczbę zasobów , które m ają być analizow ane. W składowe)
resource__idx parser um ieszcza indeks znalezionego zasobu. Składow a contc:v__
le n zaw iera liczbę znaków , które pozostały jeszcze do przeanalizow ania w ciele
żądania. Składow a p a ra m _ tb l je st w skaźnikiem do tablicy w skaźników do napisów
zaw ierających param ęjry, które parser ma rozpoznaw ać w ciele żądania. Każdy na­
pis składa się z nazw y param etru, znaku rów ności i w artości param etru. Składowa
p aram _len zaw iera rozm iar tej tablicy w skaźników . Składow a p a ram _ flag je st ta­
blicą, w kfórej parser um ieszcza inform acje o znalezionych param etrach. Tablica ta
jest alokow ana dynam icznie i inicjow ana zeram i, a jej rzeczyw isty rozm iar wynosi
void http_parser_delete(struct http_parser *s) {
mem free(s);
i
Funkcja p a r s e r _ d e le t e usuw a parser i zw alnia zajm ow aną przez niego pamięć. Jej
argum entem jest w skaźnik do struktury opisującej parser, który m a być usunięty.
K olejne trzy funkcje um ożliw iają odczytanie w yniku parsowania.
method_t http_parser_method(const struct http_parser
return s ? s->method : -1;
1
Funkcja h ttp _ p a rse r_ m e th o d zw raca identyfikator rozpoznanej w żądaniu metody.
Jej argum entem je st w skaźnik do struktury opisującej parser. Popraw ny identyfika­
tor m etody nigdy nie je st liczbą ujem ną.
int http_parser_resource(const struct http_parser *s) (
return s ? s->resource_idx : -1/
F unlJlja h |t)p _ p a rser_ _ reso u rce zw raca indeks rozpoznanego zasobu. Jej argu­
m entem jestji'wskaznik do struktury opisującej parser. Z w rócenie w artości ujem nej
262
10. Serwis WWW1
oznacza, że nie znaleziono zasobu - składow a re s o u rc e _ id x je s t inicjow ana w ar-’,
tością -1 .
int http_parser_param(const struct http_parser *s, int idx) {
return s SS idx >= 0 ss idx < s->param_len ?
s->param_£laq[idx) : 0;
I
Funkcja h ttp _ p a rs e r_ p a ra m zw raca w artość 1, gdy parser znalazł param etr o in—;
deksie id x , a w artość 0 w przeciw nym przypadku. Jej pierw szym argum entem jest
w skaźnik do struktury opisującej parser. Drugi argum ent id x je st indeksem spraw ­
dzanego param etru.
status_t http_parser_do(struct http_parser *s, char x) 1
if (! s)
return Internal_Server_Error_500;
else if {s->bu£fer_idx < BUFFER_SIZE)
s->buffer[s->buffer_idx+t-] = x;
switch (s->state) {
)
}
W łaściw ym parsow aniem żądania zajm uje się funkcja h ttp _ p a rs e r _ d o . Jej pierw­
szym argum entem je st w skaźnik do struktury opisującej parser. Funkcja ta jest
w yw oływ ana po kolei dla każdego znaku analizow anego kom unikatu. Jej drugi
argum ent x zaw iera kolejny analizow any znak. Funkcja zw raca status procesu parsow ania. Jeśli zw róci w artość C ontinue_100, oznacza to, że parsow anie nie zostało
jeszcze zakończone, a funkcja w yw ołująca parser pow inna kontynuow ać odbieranie
znaków ze strum ienia T C P i przekazyw anie ich parserow i. Jeśli parser zw róci inny
status, to oznacza, że parsow anie zostało zakończone i funkcja w yw ołująca parser
pow inna podjąć akcję stosow ną do otrzym anego statusu oraz przestać wywoływać
parser. A nalizow ane znaki grom adzim y w pom ocniczym buforze b u f f e r . Zakładamy
przy tym , że żaden poszukiw any U RI ani param etr (w raz ze znakiem końca wier­
sza) nie je st dłuższy niż BUFFER_SIZE znaków. L iczbę dotychczas zgrom adzonych
znaków przechow ujem y w składow ej b u ff e r_ id x . Parser im plem entujem y jak o au­
tom at stanowy. Instrukcja sw itc h rozdziela sterow anie zależnie od aktualnego sta-,
nu s t a t e . D la każdego stanu im plem entujem y sekcję c a se . Identyfikatory stanów
autom atu definiujem y ja k o typ w yliczeniow y s t a t e _ t .
typedef enum {METHOD_STATE, URI_STATE, VERSION_STATE,,,p*RAM_STATE,
CONTENT_STATE, END_STATE, ERROR__STATE) state_t;
Parser zaczyna od stanu METHOD_STATE (patrz funkcja h ttp _ p a rse r_ n e w ) i jeśli,
zm ienia stan, to zaw sze na stan o w yższym num erze. Stan ERROR_STATE oznacza
w ystąpienie błędu i parser ju ż nigdy nie w ychodzi z tego stanu. Poniżej opisuję
kolejne sekcje ca se , czyli działanie parsera w poszczególnych stanach. W stanie
M ETHOD_STATE parser próbuje rozpoznać m etodę żądania. A ktualnie parser rozpo­
znaje tylko dw ie metody, ale dodanie kolejnych nie pow inno spraw ić kłopotu.
case METHOD_STATE:
>
if {s->buffer_idx == 4
strncmp(s->buffer, "GET ", 4) == 0) {
s~>method = GET_METHOD;
s->buffer idx = 0;
¡0.2. Przykład 10 - prosty serwis WWW
263
s->state = URI_STATE;
i
else if {s->buffer_idx == 5 &&
strncmp(s~>buffer, "POST ", 5) == 0} {
s->method = P0ST_METH0D;
s->buf fer__idx = 0;
s->state * URI_STATE;
)
else if (s->buffer_idx >= 5) {
s~>state = ERROR__STATE;
return Bad_Request 400;
}
return Continue_100;
Po rozpoznaniu m etody przechodzim y do stanu URI STATE. W tym stanie analizu­
jem y URI żądania. Parsow anie U RI jest bardzo uproszczone. Zaim plem entow anie
pełnego parsera U RI je st trudne, gdyż ten sam identyfikator m oże być zapisany na
wiele sposobów, dopuszczalne jest szesnastkow e kodow anie znaków (sekw encja roz­
poczynająca się od znaku procentu) itd. Spacja nie je st popraw nym znakiem w URI
- jest zapisyw ana jako sekw encja %20. D latego koniec U RI rozpoznajem y po otrzy­
maniu spacji oddzielającej U RI od pola zaw ierającego w ersję HTTP. Poniew aż spa­
cja nie jest częścią URI, przed dalszym i spraw dzeniam i trzeba ją usunąć z bufora.
O trzym any U RI porów nujem y po kolei ze w szystkim i U RI um ieszczonym i w tabli­
cy re s o u r c e _ tb l. Po w ykryciu zgodności zapam iętujem y indeks znalezionego URI
w składowej re s o u rc e _ id x i przechodzim y do stanu VERSION_STATE.
case URI_STATE:
if (x = = ' ' ) !
int i;
if (s->bufferis->buffer_idx - 1 ] == 1 '}
s->buffer_idx— ;
for (i = 0; i < s->resource_len; ++i) (
if {strncmp(s->buffer, s->resource_tbifi],
s->bu£fer_idx) =« 0) {
s->resource_idx = i;
s->buffer_idx = 0;
s->state = VERSION_STAT£;
return Continue_100;
}
)
s->state = ERROR__STATE;
return Not_Found_404;
)
else if {s->buffer_idx >= BUFFER_SIZE) {
s->state = ERROR__STATE;
return Bad_Request_400;
}
return Continue_100;
W stanie VERSION_STATE sprawdzamy, czy n u m e r wersji w o t r z y m a n y m żądaniu
zgadza się z obsługiwanymi wersjami HTTP. D o p u s z c z a m y obie istniejące aktu­
alnie wersje protokołu. Po p o p r a w n y m zweryfikowaniu wersji przechodzimy d o
stanuj,PARAM STATE.
* lt
case VESS^ON_STATE:
if (S“2ttfuffer idx == 10 &&
10.2. Przykład 10 - prosty serwis WWW
(strncmp(s->bu£fer, "HTTR/l.0\r\n", 10) = = 0 1 1
strncmp(3->buffer, "HTTP/l.l\r\n", 10) == 0)) (
s->buf fer_.idx = 0;
s->state = PARAM_STATE;
i
ełse if {s->buffer_idx >= 10) {
s->state = ERROR_STATE;
return HTTP_Version_Not_Supported_505;
265
czonym i w tablicy p arara_ tb l. Inform ację o wykryciu zgodności zapam iętujem y
w tablicy p aram _ flag . Jeśli cala zaw artość ciała kom unikatu została ju ż przetw o­
rzona, to przechodzim y do stanu końcow ego END_STATE.
case CONTENT_STATE:
s->content_len— ;
if (x == *6' |j s->content_len == 0) {
int i;
)
return Continue_100;
W stanie PARAM_STATE analizujem y pozostałą część nagłów ka HTTP, zawierającą
param etry żądania. W ykryw am y dw ie sytuacje: koniec nagłów ka (bufor zawiera '
tylko znaki C R i LF) i w ystąpienie param etru Content-Length. W artość tego para­
m etru oznacza długość ciała w iadom ości. Jeśli kom unikat nie m a ciała, to przecho­
dzim y do stanu końcow ego END_STATE, a jeśli ciało w ystępuje (param etr Conte:.- Length m a dodatnią w artość), to przechodzim y do stanu CONTENT_STATE.
case PARAM_STATE:
if (x == <\ n ') t
if (s->buffer__idx == 2 66
s->bu£fer(0) == *\ r * 66
s->bufferilj == '\n'} (
if (s->content__len > 0)
s~>state = CONTENT_STATE;
else {
5->state o END_STATE;
return OK_20Q;
i
}
else if (s->buffer_idx >= 19 66
strncmp(s->buffer, "Content-Length: ", 16) == 0 66
s->buffer[s->bu£fer_idx - 2) == '\r' 66
s->buffer{s->buffer_idx - 1] == *\ n 1) {
int i;
for (i = 16; i < s->buffer_idx - 2; ił-i) {
if (isdigit{(int)s->bufferti])) {
s->content_len *= 10;
s->content_len += s->buffer(ij - *0';
)
else 1
s->5tate = ERROR_STATE;
return Bad_Request 400;
,
i
i
s->buffer_idx = 0;
}
return Continue_100;
W stanie CONTENT_STATE analizujem y zaw artość ciała kom unikatu i poszukujem y pa-;
ram etrów z form ularza H TM L. Parsow anie je s t bardzo uproszczone. Przyjmujemy,
że param etry rozdzielane są znakiem &. K oniec param etru rozpoznajem y po otrzy­
m aniu tego znaku lub gdy nie m a ju ż więcej znaków do przetw orzenia. Z nak & nie
je st częścią param etru, dlatego przed dalszym i spraw dzeniam i usuw am y go z bufo­
ra. O trzym any param etr porów nujem y po kolei ze w szystkim i param etram i umiesz-
if (s->buffer{s->bu£fer_idx - 1] == '6')
s->buffer_idx— ;
for (i = 0 ; i < s->param_len; ++i)
if (strncmp(s->buffer, s->param_tbl(i),
s->buffer_idx) == 0)
s->param flag(i] = 1;
s->buffer_idx = 0;
)
if (s->content_len == 0) {
s->state = END_STATE;
return OK_200;
}
return Continue_100;
Jeśli co ś poszło źle, np, funkcja http__parser_do została ponow nie wywołana,
m im o że w cześniej zw róciła status różny od C ontinue_100, to w ykonujem y sekcję
d e f a u l t. Jedyne co można zrobić w tej sytuacji, to zw rócić inform ację o błędzie.
default:
s->state = ERROR_STATE;
return Internal_Server_Error_500;
Pliki http_server.h, http.h i http_application.h
Plik http_server.h zaw iera definicję dom yślnego num eru portu H TTP oraz deklara­
cję funkcji H T T P serv erS tart, która urucham ia serw er HTTP. Funkcja ta jest zaim ­
plem entow ana w pliku http_server.c i je st identyczna ja k funkcja T C P s e rv e rS ta rt
z przykładów 5a i 5b, zaim plem entow ana w pliku tcp_servei:c. A rgum entem tych
funkcji je st num er portu, na którym serw er m a nasłuchiw ać. Funkcje te zw racają
zero, gdy uruchom ienie serw era pow iedzie się, a w artość ujem ną w przeciwnym
przypadku.
idefine HTTP_RORT 80
int HTTPserverStart (uint!6__t);
W pliku http.h zadeklarow ana jest struktura typu h tt p . D efinicja tej struktury znaj­
duje się w pliku http_server.c. Struktura h t t p przechow uje w szystkie niezbędne
inform acje zw iązane z obsługą żądania i w ysyłaniem odpow iedzi HTTP.
struct http;
Ponadto w pliku http.h zadeklarow ane są poniższe funkcje operujące na strukturze
typu h t t p i używ ane w pliku http_application.c\ który opisuję w jednym z następ­
nych podrozdziałów. Im plem entacja tych funkcji znajduje się w pliku http__server,c.
charjj|phttpj|data_new{struct http *, size_Ł);
void http_dat^_len(struct http *, size_t);
void http_dat!a_rom(struct http *, const char *, size t);
10. Serwis WFiy
266
W pliku http_application.h znajdują się deklaracje pozw alające w sposób ogólny
zdefiniow ać algorytm działania prostego serwisu WW W . W tablicy r e s o u r c e _ tb l
należy um ieścić w skaźniki do napisów reprezentujących URI, które m ają być ob­
sługiw ane przez serw is. Z m ienna r e s o u r c e _ tb l_ le n m usi zaw ierać rozm iar tej ta­
blicy, czyli liczbę obsługiw anych URI. W tablicy p a ra r a e te r_ tb l należy umieścić
w skaźniki do napisów zaw ierających param etry, które są generow ane przez for­
m ularze generow ane przez nasz serw is. Z m ienna p a ra m e te r _ tb l_ le n musi zaw ie­
rać rozm iar tej tablicy, czyli liczbę obsługiw anych param etrów. Pow yższe tablice
i zm ienne definiujem y w pliku http_applicałion.c.
extern
extern
extern
extern
const
const
const
const
char * const resource_tbi(j;
int resource_tbl_len;
char * const parameter_tbl(j;
int parameter_tbl_len;
size_t
size_t
uint32
Sam ą logikę działania serw isu im plem entujem y też w pliku http_application.c
w funkcji m ake_http_answ er. A rgum entam i tej funkcji są w skaźniki do struktur
opisujących stan obsługi żądania H T T P oraz parser. Funkcja ta na podstaw ie in­
formacji uzyskanych od parsera m usi w ygenerow ać odpow iedź H TT P i zwrócić
status HTTP. Z w rócenie w artości OK_200 oznacza, że w ygenerow anie odpowiedzi
pow iodło się i należy ją w ysiać klientow i. Inny status oznacza w ystąpienie proble­
mu. W tedy funkcja, która w yw ołała funkcję m ake_http_answ er, musi obsłużyć ten
problem - w tej sytuacji najlepiej je s t w ysiać klientow i inform ację zaw ierającą ten
status.
);
Składow a d a ta _ f la g s struktury typu h t t p przechow uje znaczniki potrzebne do
obsługi bufora danych. A ktualnie zdefiniow any je st tylko jeden w skaźnik F L A G _
NEEDS__FREE. M usi być on ustawiony, gdy bufor d a ta został przydzielony na stercie
za pom ocą funkcji m em jnalloc i przed usunięciem z pam ięci struktury typu h t t p
musi zostać zw olniony za pom ocą funkcji mem_f re e . Jeśli składow a d a ta w skazuje
na dane w pam ięci stałej (w naszym przypadku Flash), to nie zw alnia się pam ięci
zajm ow anej przez te dane i znacznika F L A G _ N E E D S _ F R E E nie ustawiamy.
static struct http * http_new(void) (
struct http parser *parser;
struct http *bttp;
parser = http_parser_n e w (resource_tbl, resource_tbl_len,
parameter_tbl, parameter__tbl_len);
if (parser == NULL)
return NULL;
http = memjnałloc(sizeof(struct http));
if (http) {
http->parser = parser;
http->data = NULL;
http->data_flags = 0;
http->data_idx = 0;
hfctp->data_left = 0;
http~>status = Continue_100;
http->timeout * SERVERJFIMEOUT;
Plik http_server.c - obsługa HTTP
1
10
Serw er przechow uje dane niezbędne do obsłużenia klienta w strukturze typu h ttp .
Składow a p a r s e r je s t w skaźnikiem do struktury opisującej parser przypisany temu
klientow i. Składow a s t a t u s zaw iera aktualny statuę»absługi żądania H TTP zgodnie
z tabelą 10.1. Składow a tim e o u t zaw iera liczbę sekund, które pozostały jeszcze
do zakończenia obsługi klienta. Składow a d a ta jest w skaźnikiem do bufora z od­
pow iedzią, która m a być w ysłana klientow i. O dpow iedź często je st zbyt duża, aby
m ogła być w ysiana w jed n y m segm encie TCP. D latego m usim y zaim plem entow ać
w ysyłanie odpow iedzi w kaw ałkach. Składow a d a ta _ id x w skazuje pozycję pierw ­
szego jeszcze niew ysłanego bajtu w buforze w skazyw anym przez d a ta . Składow a
d a ta l e f t zaw iera liczbę bajtów, które pozostają jeszcze do w ysiania.
struct http {
struct http_parser
status_t
*
int
char
*
*parser;
status;
timeout;
*data;
1
N ie należy bezpośrednio m anipulow ać składow ym i struktury typu h tt p . D o obsługi
tej struktury im plem entujem y szereg funkcji. Funkcja h t t p new przydziela nową
strukturę typu h t t p i inicjuje jej składow e. Z w raca w skaźnik do tej struktury lub
w artość NULL, gdy w ystąpił problem z alokacją pam ięci. Funkcja ta tw orzy też nową
instancję parsera.
Plik http_server.c zaw iera im plem entację serw era HTTP. N ajpierw zajm ijm y się
obsługą żądania HTTP. A by serw er nie został zaw ieszony przez złośliw ego klien­
ta, ustalam y, że połączenie z klientem m oże trw ać m aksym alnie 10 sekund. Jest
to czas zupełnie w ystarczający, aby odebrać i przeanalizow ać żądanie oraz wysłać
odpow iedź.
łdefine SERVER_TIMEOUT
t
267
data_idx;
data_left;
data_flags;
Idefine FLAG_NEEDS_FREE
status_t make__http_answer (struct http *, const struct http_parser *);
10.2.3.
10.2. Przykład 10 - prosty serwis VkWW
else
http_parser_delete(parser);
return http;
)
Funkcja h tt p _ d e le t e usuw a z pam ięci strukturę typu h tt p . N ajpierw jednak usu­
w am y parser i ew entualnie zw alniam y bufor w skazyw any przez składow ą d a ta .
A rgum entem tej funkcji je st w skaźnik do zw alnianej struktury typu h ttp .
static void http_delete(struct http *http) (
http_parser_delete(http->parser);
if (http->data_flags S FLAG_NEEDS_FREE)
meą_free(http->data);
mem free(httpl;
1
Funkcja h t t p d a ta new alokuje bufor, w którym m a być um ieszczona odpow iedź
udłfclanu$p|rzez serwer. Pierw szym argum entem tej funkcji jest w skaźnik do struk­
tury typu h & p , do której m a być przypisany alokow any bufor. Drugi argum ent s i z e
268
10. Serwis WWW
zaw iera żądany rozm iar tego bufora. Funkcja ta zw raca w skaźnik do przydzieli
go bufora lub w artość NULŁ, gdy przydzielenie pam ięci się nie pow iodło. Funkcja
h ttp _ d ata_ n ew je st przew idziana do w yw ołania przez aplikację W W W zaim
m entow aną w pliku http_application.c.
char * http_data_new(struct http *http, size_t size) {
http->data = memjnalloc(size);
if (http->data) {
http->data_idx = 0;
http->data_left = size;
http~>data_flags = FLAG_NEEDS_FREE;
)
return http->data;
)
Funkcja h tt p _ d a ta _ d e łe te zw alnia bufor przypisany do składow ej d a ta struktury
typu h tt p . Jej argum entem je st w skaźnik do struktury typu h tt p , do której przypi­
sany je s t zw alniany bufor.
static void http_data_delete(struct http *http) (
if (http->data_flags & FLAG_NEEDS_FREE) {
mem_free(http->data);
http->data = NULL;
http->data__idx = 0;
http~>data_left - 0;
http->data_flags » 0;
■
10.2. Przykład 10 - prosty serwis WWW'
static int http_sent(struct http *http) {
return http->data_left == 0;
!
F unkcja h ttp _ tim e o u t zm niejsza licznik czasu, który pozostał jeszcze do zakoń­
czenia obsługi klienta. Z w raca zero, gdy obsługa klienta m a być kontynuow ana,
a jeden w przeciw nym przypadku, czyli gdy należy zakończyć obsługę klienta. Jej
pierw szym argum entem jest w skaźnik do struktury typu h ttp .
static int http_timeout(struct http *http) (
return — (http->timeout) <= 0;
1
F unkcja h ttp _ s e n d w ysyła porcję danych z odpow iedzią serwera. Jej pierwszym
argum entem je s t w skaźnik do struktury typu h tt p . Drugi argum ent pcb jest w skaź­
nikiem do deskryptora T C P opisującego połączenie TCP, przez które dane mają
zostać w ysiane. Funkcja ta najpierw spraw dza za pom ocą funkcji tc p _ sn d b u f ilość
w olnego m iejsca w buforze nadaw czym TCP. Jeśli jest w nim dostatecznie dużo
m iejsca, aby w ysiać w szystkie dane, to w ysyłam y je w całości. Jeśli bufor nadaw ­
czy je st zbyt mały, to w ysyłam y tylko fragm ent danych i ustaw iam y znacznik TCP_
WRITE_FLAG_MORE oznaczający, że będą jeszcze w ysiane kolejne fragmenty.
static void http_send(struct http ‘
http, struct tcp_pcb *pcb) |
uintl6_t len;
uint8 t flag;
len = Łcp_sndbuf (pcb) ;*
if (len > 0 SS http~>data && http->data_Ieft > 0) (
if (len >= http->data_left) (
len = http->data__left;
flag => 0;
)
1
Funkcja h ttp _ d a ta _ łe n m odyfikuje rozm iar danych, które pozostały jeszcze do
wysiania. Jej pierw szym argum entem je st w skaźnik do struktury typu h tt p . Drugi
argum ent s i z e zaw iera nowy rozm iar danych. Funkcja h tt p _ d a ta _ le n je s t przew i­
dziana do w yw ołania przez aplikację W W W zaim plem entow aną w pliku http_applicalion.c.
)
else
flag * TCP_WRITE_FLAG__MORE;
if (ERR_OK == tcp_write(pcb, http->data + http->data_idx,
len, flag)) {
http->data_idx i= len;
http->data_JLeft -= len;
void http_data_len(struct http *http, size_t size) {
http->data_ieft = size;
)
Funkcja h ttp _ d a ta _ ro ra przypisuje do struktury typu h t t p odpow iedź serw era znaj­
dującą się w pam ięci stałej. Jej pierw szym argum entem je s t w skaźnik do struktury
typu h tt p . Drugi argum ent d a ta je st w skaźnikiem do m iejsca w pam ięci, gdzie
znajduje się odpow iedź serw era. Trzeci argum ent s i a e zaw iera rozm iar tej odpo­
w iedzi. Funkcja h ttp _ d a ta _ ro m je st przew idziana d e w yw ołania przez aplikację
W W W zaim plem entow aną w pliku http_application.c.
void http_data_rom(struct http *http, const char *data,
size_t size) (
http->data = (char *)data;
http->data_idx = 0;
http->data_left = size;
http->data_flags = 0; •*
i
>
Funkcja h tt p _ s e n t spraw dza, czy w szystkie dane zostały ju ż w ysiane. Z w raca zero,
gdy jeszcze jakieś' dane pozostały do w ysłania, a jeden w przeciw nym przypadku.
Jej pierw szym argum entem je st w skaźnik do struktury typu h ttp .
269
}
)
I
Funkcja h ttp _ e n g in e obsługuje żądanie klienta. Jej pierw szym argum entem jest
w skaźnik do struktury typu h tt p . Drugi argum ent pcb je st w skaźnikiem do de­
skryptora T C P opisującego połączenie TCP, z którego odebrano żądanie. Trzeci ar­
gum ent p je st w skaźnikiem do łańcucha buforów, które zaw ierają odebrane dane.
D opóki status H TTP ma w artość C ontinue_100, czyli serw er oczekuje na kolejne
porcje żądania, to funkcja ta dla każdego odebranego znaku w yw ołuje funkcję parsera h ttp _ p a rs e r_ d o . Jeśli status H TTP zm ieni się na OK_200, co oznacza, że zosta­
ło odebrane popraw ne żądanie, to w yw ołujem y funkcję m ake_http_answ er, której
zadaniem jest przygotow anie odpow iedzi dla klienta. W trakcie przygotow yw ania
odpow iedzi status H TTP może się zm ienić. Jeśli się zm ienił, to usuw am y ew entualnąjprzygotow aną przez funkcję m ake_http_answ er odpow iedź za pom ocą funkcji
h t t ^ d a t # J d e l e t e . N astępnie, jeśli status H TTP jest różny od OK_200, w yw ołuje­
my funkcjęi|lh ttp _ e r r o r _ r e s p o n s e , której zadaniem jest przygotow anie odpowiedzi
10.2. Przykład ¡0 - prosty serwis
10. Serwis lVW\y
270
"Content-Type: text/html\r\n"
"\r\n"
"<html>"
"<headxtitie>£rror</titlex/head>"
"<bodyxhl>404 Not Found</hlx/body>"
"</html>";
static const char internai_server_error_500_htmł{) =
"HTTP/1.1 500 Internal Server Error\r\n"
"Connection: close\r\n"
"Content-Type: text/htmł\r\n"
"\r\n"
"<html>"
"<headxtitłe>Error</titlex/head>"
"<bodyxhl>500 Internal Server Error</hlx/body>"
"</html>";
static const char version_not_supported_505_html[] =
"HTTP/1.1 505 HTTP Version Not Supported\r\n"
"Connection: close\r\n"
"Content-Type: text/html\r\n"
"\r\n"
"<html>"
"<headxtitle>Error</title></head>"
"<body><hl>505 HTTP Version Not Supported</hlx/body>"
"</html>";
inform ującej o błędzie. N a koniec w yw ołujem y funkcję h ttp _ s e n d , która inicjuje
w ysłanie odpow iedzi.
static void http_engine{struct http *http, struct tcp_pcb *pcb,
struct pbuf *p) {
struct pbuf *q;
if {http->status == Continue_100) {
for (q = p;; q = q->next) {
uint8_t *c = (uint8_t *)q->payload;
uint!6__t i;
for (i = 0 ; i < q->len; ++i) {
http->status = http_parser_do{http->parser, c[i]);
if (http->status == Continue_100)
continue;
else if {http->status *= OK_200) {
http->status = make_http_answer{http, http->parser);
if {http->status != OK_200)
http_data delete{http);
1
if {http->status != OK__200)
http_error_response{http);
http_send{http, pcb);
return;
switch{http->status) {
case Bad_Request_400:
http data_rom(http, bad_request 400_html,
sizeof(bad_request_400_html) - 1);
return;
case Not_Found_404:
http_data_rom{http, not_found_404_html,
sizeof{not_found_404_html) - ł);
return;
case HTTP Version_Not_Supported_505:
http_data_rom(http, version_not_supported_505_html,
sizeof{version_not_supported_505_html) - 1);
return;
default:
http data_rom{http, internal_server_error_500_html,
sizeof{internal_server_error_500_html) - 1);
return;
!
if {q->len == q->tot_len)
break;
}
)
)
Funkcja h ttp _ e r r o r _ r e s p o n s e przygotow uje odpow iedź inform ującą o w ystąpieniu
błędu. Jej pierw szym argum entem je s t w skaźnik do struktury typu h tt p . Kom pletne
odpow iedzi serw era dla poszczególnych kodów statusu H TT P definiujem y jak o sta­
łe napisy - kom pilator um ieści je w pam ięci Flash. W ydaje się to m arnotraw stw em
pam ięci, bo w szystkie te odpow iedzi m ają w spólny w zorzec i m ożna by je genero­
wać dynam icznie. Pam iętajm y jed n ak , że fragm enty kodu obsługujące błędy pow in­
ny być m ożliw ie odporne na w ystąpienie kolejnych błędów, np. zw iązanych z alo­
kacją pam ięci. W ystąpienie problem u podczas obsługi sytuacji, która je st wynikiem
innego problem u, m oże doprow adzić do załam ania się aplikacji, a pam ięci Flash
m am y pod dostatkiem . D om yślną odpow iedzią jes.t^,5.00 Internal S erver E rror”, co
jest dość rozsądnym rozw iązaniem .
.
static void http_error_response(struct http *http) (
static const char bad_request_400_html(] =
"HTTP/1.1 400 Bad Request\r\n"
"Connection: ciose\r\n"
"Content-Type: Łext/html\r\n"
"\r\n"
"<html>"
"<headxtitle>Error</titłeX/head>"
"<bodyxhl>400 Bad..Request</hlx/body>" *
"</html>";
static conkt char not_found_404_html() =
"HTTP/1.1 404 Not Found\r\n"
"Connection: close\r\n"
271
i
}
10.2.4.
Plik httpjserver.c - obsługa połączenia TCP' '
W pliku http_server.c znajduje się im plem entacja funkcji HTTPserverStart, która
urucham ia serw er HTTP. Pisałem ju ż o niej w jednym z poprzednich podrozdzia­
łów. Pozostało om ów ienie funkcji zw rotnych obsługujących połączenie TCP. Ich
im plem entacja bazuje na funkcjach serw era TCP, który opisałem w przykładach 5a
i 5b. Funkcja zw rotna a ccept_callback je s t w yw ołana przez bibliotekę lw IP po
odebraniu połączenia TCP. Jej zadaniem je s t przydzielenie do tego połączenia no­
wej struktury typu http i ustaw ienie pozostałych funkcji zw rotnych. W artość stałej
P O M W p ę r | $EC O N D dobieram y tak, aby funkcja zw rotna tcp_poll była w yw ołana co
sekundę. |i*i
272
10.2. Przykład 10 - prosty serwis WWW
10. Serwis WWW
Sdefine POLL_PER_SECOND
273
if (http_timeout(http))
close_connection(http, pcb);
/* Można też wysyłać tu.
else
http_send(http, pcb);
2
static err_t accept_callback(void *arg, struct tcp_pcb *pcb,
err_t err) {
struct http *http;
*/
return ERR OK;
http = http__new();
if (http ==~NULL)
return ERR_MEM;
tcp_arg(pcb, http);
tcp_err(pcb, conn_err_callback)/
tcp_recv(pcb, recv_callback);
tcp_sent(pcb, sent_callback);
tc p j> o ll( p c b , poll_callbaek, POLL_PER_SECOND);
return ERR_OK;
i
Funkcja zw rotna c o n n _ e rr_ c a llb a c k je s t w yw ołana przez bibliotekę lwlP, gdy po­
łączenie T C P zostanie zam knięte aw aryjnie. Jej zadaniem jest zw olnienie pamięci
przydzielonej przez serw er do obsługi klienta. W tym celu w yw ołujem y funkcję
h tt p _ d e le t e .
static void conn_err_callback(void *http, err_t err) (
http_delete (http);
}
Funkcja zw rotna re c v _ c a lib a c k je s t w yw ołana przez bibliotekę lw lP po odebraniu
danych z połączenia T C P lub po zam knięciu tego połączenia. W celu przetw orzenia
odebranych danych w yw ołujem y funkcję h ttp _ e n g in e . W reakcji na zam knięcie
połączenia T C P przez klienta w yw ołujem y funkcję c lo s e _ c o n n e c tio n , którą opi­
suję na końcu tego podrozdziału.
}
P om ocnicza funkcja c lo s e _ c o n n e c tio n zw alnia w szystkie zasoby przydzielone
przez serw er do obsługi klienta i zam yka połączenie TCP.
static void close_connection(struct http *http,
struct tcp_pcb *pcb) {
tcp_recv(pcb, NULL);
tcp_sent(pcb, NULL);
tcp_polł(pcb, NULL, 0);
http_delete(http);
tcp_arg(pcb, NULL);
,
tcp_close(pcb);
’
static err_t recv_callback(void *http, struct tcp_pcb *pcb,
struct pbuf *p, err_t err) (
if (p) I
tcp_recved(pcb, p->tot__len);
http_engine(http, pcb, p);
pbuf_free(p);
)
1
else
close connection(http, pcb);
return ERR_OK;
.2.5.
Plik http_application.c
i
F unkcja zw rotna s e n t c a llb a c k jest w yw ołana przez bibliotekę lw lP po odebra­
niu potw ierdzenia dostarczenia danych. Z a pom ocą funkcji h tt p _ s e n t spraw dza­
my, czy cała odpow iedź została ju ż w ysłana. Jeśli w szystkie dane zostały wysłane,
kończym y połączenie TCP, w yw ołując funkcję c lo s e _ c o n n e c tio n . Jeśli pozostały
jak ieś dane do w ysłania, w yw ołujem y funkcję h ttp _ s e n d , która w ysyła kolejną ich
porcję.
Plik http_application.c zaw iera im plem entację logiki działania aplikacji WWW.
Przerobienie prezentow anego w tym rozdziale przykładu na potrzeby innego ser­
wisu W W W w ym aga tylko m odyfikacji tego pliku. Zaczynam y od zdefiniow ania
tablicy w skaźników r e s o u r c e _ tb l do napisów zaw ierających URI, które serw er ma
rozpoznaw ać. M usim y rów nież zdefiniow ać rozm iar r e s o u r c e _ tb l_ le n tej tablicy.
A by kod źródłow y był przejrzysty, definiujem y też za pom ocą dyrektyw S d efin e
identyfikatory indeksów w tej tablicy.
static err_t sent_callback(void *http, struct tcp_pcb *pcb,
ul6_t len) {
if (http_sent(http))
,
close_connection(http, pcb);
else
http_send(http, pcb);
return ERR_OK;
»define MAIN_PAGE
»define STM32_LOGO
»define DONE_PAGE
)
Funkcja zw rotna p o ll _ c a ll b a c k je s t w yw ołana cyklicznie przez bibliotekę lwlP.
Z a pom ocą funkcji h ttp _ tim e o u t zm niejszam y licznik czasu, który pozostał do
zakończenia obsługi klienta i jeśli czas ten ^ p ły n ą ł, zam ykam y połączenie TCP,
w yw ołując funkcję c lo s e jc o n n e c tio n . W funkcji p o ll _ c a ll b a c k m ożem y też w y­
w ołać funkcję h ttp _ s e n d , ale nie w ydaje się to potrzebne.
static err_t poll_callback(void *http, struct tcp_pcb *pcb) (
0
1
2
const char * const resource_tbl[] = {
*7",
"/stm32_1ogo.gi f ” ,
"/led"
i;
const int resource_tbl_ien =
sizeof(resource_tbl) / sizeof(resource_tbl[0]);
Jeśli używ am y form ularzy H TM L, m usim y zdefiniow ać tablicę w skaźników p a ra m e te p _ tb l do napisów zaw ierających param etry form ularzy oraz rozm iar pararaeteiW bl*|l<ąn tej tablicy. A by zw iększyć czytelność kodu źródłow ego, definiujem y
też za pom pcą dyrektyw lld e fin e identyfikatory indeksów w tej tablicy.
274
10. Serwis WWW
((define LED G
Idefine LED_R
10.2. Przykład 10 - prosty serwis WWW
O
ł
"Content-Type: text/html; charset=UTF-8\r\n”
"\r\n"
"<html>"
"<headxtitle>Przykładowy Serwer HTTP</titlex/head>"
"<body>"
"<center>"
" < p x i m g src=\"stm32__logo.gif\" altÄ\nSTM32 L0G0\" / x / p > "
"<pXf o n t size=\"6\">%u %02u:%02u:%02u.%03u</fontx/p>"
f'<hr />"
"<form acfcion=V71ed\" method=\"post\">"
"<p>"
"Czerwona dioda świecąca "
"<input type=\"checkbox\" name=V'LED\" value=\"R\" %s/>"
"</p>"
"<p>"
"Zielona dioda świecąca "
"<input type^'checkboxX" name=\"LED\" value=\"G\" %s/>"
"</p>"
" <pxinput type=\"submit\" value=X"Zmień\" /></p>"
"</form>"
"<hr />"
const char * const parameter_tbl{3 = {
"LE0=G",
"LED-R"
I;
const int parameter tbl_len =
sizeof (parameter__tbl) / sizeof (parameter_tbl(Oj);
Serw er w celu w ygenerow ania odpow iedzi w yw ołuje funkcję raake_http_answ er.
W funkcji tej najpierw w yw ołujem y funkcje parsera: h ttp _ p a rse r_ m e th o d i h tt p
p a r s e r re s o u rc e , aby poznać m etodę i URI, które znajdow ały się w żądaniu przy­
słanym przez klienta. N astępnie, zależnie od U RI i metody, w ygenerow anie odpo­
wiedzi delegujem y do w łaściw ej funkcji lub zw racam y status „404 N ot Found” .
status_t make_http_answer(struct http *http,
const struct http_parser *parser) {
method_t method;
int
idx;
method = http_parser_method(parser);
idx = http_parser resource(parser);
if (idx == MAIN_PAGE &6 method == GET_METHOD)
return http_main_page(http);
else if (idx == STM32_LOGO && method == GET__METHOD)
return http_stm32_logo(http);
else if (idx == D0NE_PAGE
method =»* P0ST_METH0D)
return http_done_page(http, parser);
else
return Not_Foundj304;
"<P>"
"lwIP/%u.%u.%u CMSIS/%x.%x "
"STM32F10x Standard Peripherals ŁibraryAu.%u.%u"
łifdef NEWLIB_VERSION
" newlib/" _NEWLIB_VERSION
lendif
"</p>"
"</center>"
"</body>"
"</html>";
static const size_t main_page_2en = sizeof (main__page_html) + 12;
,
i
O dpow iedź zaw ierającą głów ną stronę serw isu, przedstaw ioną na rysunku 10.1, ge­
nerujem y za pom ocą funkcji h ttp _ m ain _ p ag e. O pis strony tw orzym y dynam icznie.
Stały w zorzec całej odpow iedzi znajduje się w statycznej tablicy m ain_page_htm l.
Stała raain_page_len zaw iera rozm iar bufora, w którym m a być um ieszczona od­
pow iedź i który alokujem y za pom ocą funkcji h ttp _ d a ta _ n e w . R ozm iar bufora jest
nieco w iększy niż długość napisu raain_page_htral, gdyż trzeba zapew nić miejsce
na w staw iane w artości. S erw er m oże sym ultanicznie obsługiw ać w iele klientów.
D latego do form atow ania odpow iedzi używ am y funkcji s n p r i n t f r , która jest
w spółużyw alna. Z a pom ocą funkcji R edLED state i G reenL ED state odczytujem y
stan diod św iecących i ustaw iam y odpow iednio stan pól w yboru w form ularzu. Jeśli
nie pow iedzie się przydział bufora lub funkcja _ s n p r i n t f _ r zw róci błąd, to zw ra­
cam y status „500 Internal S erver E rror” . Po popraw nym sform atow aniu odpow iedzi
ustawiam y za pom ocą funkcji h ttp _ d a ta _ le n w łaściw ą długość odpow iedzi, bez
term inalnego zera, którego nie należy w ysyłać. Jeśli cala odpow iedź nie mieści się
w buforze (choć nie w idać do lego realnego pow odu), to w ysyłam y część, która się
zm ieściła, w nadziei żc je s t to lepsze rozw iązanie niż niew ysłanie żadnej odpow ie­
dzi. N a koniec, jeśli w sźystko poszło dobrze,^zw racam y status „200 O K ” .
static status_t httpjnairTpa'ge (struct http *http) (
static const char main_page_html{] =
"HTTP/1.1 200 0K\r\n"
"Connection: close\r\n"
int data_size;
unsigned d, h, m, s, ms;
char *data;
struct _reent reent;
H
data = http_data_new(http, main_page_len);
if (data == NULLT
return Internal_Server_Error_500;
GetLocalTime(&d, &h, &m, &s, &ms);
data_size = _snprintf_r(&reent, data,
main__page_len, main_page_html,
d, h, m, s, ms,
RedLEDstate() ? "checked "
GreenLEDstate() ? "checked " :
LWI PJfERS I0NJ4A JOR, LWI P_VERSI0N_MINOR,
LWIP~VERSION_REVISION,
CM3_CMS IS_VERSION_MAIN,
_CM3_CMSIS_VERSI0N_SUB,
_STM32F10X_STDPERIPH_VERSION_MAIN,
__STM32F1OX_STDPERIP h " v ERSION_SÜ01,
STM32 FI 0X__STDPERI PH_VERSION_SUB2} ;
if (data_size <= 0)
return Internal_Server_Error_500;
if Jl{size_t)data_size < main_page_len)
http_WtL_len (http, (size_t)data_size);
else
)'•
275
276
10.2. Przykład 10 - prosty serwis WWW
10. Serwis WWW
http_data_len(http, main_page_len - 1);
return OK_200;
danie z m etodą POST. O bsługą tego żądania zajm uje się funkcja http_done_page,
w której najpierw spraw dzam y za pom ocą funkcji h ttp _ p a rse r_ p a ra m , jakie pa­
ram etry zaw ierało to żądanie i stosow nie do tego w łączam y lub w yłączam y od­
pow iednią diodę św iecącą. N astępnie odsyłam y odpow iedź zaw artą w tablicy
done_page_htm l. D ługość odpow iedzi określa stała done__page_len. Po otrzym aniu
odpow iedzi przeglądarka w yśw ietla, przedstaw ioną na ry s u n k u 10.2, stronę infor­
m ującą o w ykonaniu zmiany. Po kliknięciu na tej stronie w odnośnik Powrót w ra­
cam y do głów nej strony serw isu WWW. Funkcja h ttp _ d o n e_ p ag e zawsze zw raca
status „200 O K ”.
I
Na głów nej stronie serw isu W W W osadzony jest obrazek z logo m ikrokontrole­
rów ST M 32 - zasób stm 3 2 J o g o .g if. G dy klient zażąda tego zasobu, w yw ołujem y
funkcję h ttp _ stm 3 2 _ lo g o . Sam obrazek oraz je g o rozm iar zdefiniow ane są w pliku
stm 32_logo.h, który opisuję w następnym podrozdziale. Funkcja http__stm32__logo
je st bardzo prosta, um ieszcza w łaściw e dane w strukturze typu h t t p za pom ocą
funkcji http_data__rom i kończy działanie, zw racając status „200 O K ”.
atatic status_t http_stm32_logo(struct http *http) (
łinclude <stm32_logo,h>
static status_t http_done_page(struct http *http,
const struct http_parser *parser) {
static const char done_page__html [] =
"HTTP/1.1 200 0K\r\n"
"Connection: close\r\n"
"Content-Type: text/html; charset=UTF-8\r\n"
"\r\n"
"<html>"
"<headxtitle>Przykładowy Serwer HTTP</titlex/head>"
"<body>"
"<center>"
"<font size=\M\">"
"<p>Wykonano</p>"
" < p x a href=\"/\">Powrót</ax/p>"
”</font>"
"</center>"
”
</body>"
"</html>";
static const size_t done_page_len = sizeof(done_page_html) - 1;
http_data_rom(http, stra32_Iogo_gif, atffl32_logo_gif_len) ;
return OK_200;
1
G łów na strona serw isu zaw iera też form ularz służący do sterow ania diodam i św ie­
cącym i. Po kliknięciu na przycisk Zm ień tego form ularza przeglądarka w ysyła żąI ' 5 P rz y k ła d o w y S e rw e r HTTP - M ic ro s o ft In t e r n e t E nplorer
File
Edit
Q üack
View
Favorites
-r ( J ) -
(W )
Tools
| S ‘| (;•,')
Help
'»i1’
J>.'> Search
S ^ - ' Favorites
| |V
m
J
Address j.jÿ | h ttp :// 192. 168.51 .89/led
Go
277
I Unta' » •
Wykonano
Powrôt
if (http_parser_param(parser, LED_G))
GreenLEDon () ;
else
GreenLEDoff();
if (http_parser_param(parser, LED_R)}
RedLEDon ();
else
RedLEDoff ();
http_data_rom(http, done_page_html, done_page_len);
return OK 200/
-
,Ti
10.2.6.
Plik stm 32Jogo.h
Plik stm 32_logo.h zaw iera kom pletną odpow iedź serw era na żądanie przesiania ob­
razka, który ma się w yśw ietlić na głów nej stronie serw isu. O dpow iedź znajduje się
w tablicy stm 3 2 _ lo g o _ g if. Stała stm 32_łogo_gif__len zaw iera długość odpow ie­
dzi. D efinicje te um ieściłem w osobnym pliku, a nie bezpośrednio w pliku http_application.c, gdyż zajm ują dużo m iejsca (poniżej je s t w ydrukowany tylko mały frag­
m ent pliku stm 32_logo.li), co bardzo zm niejszyłoby czytelność tekstu źródłowego.
>
|:y, '
■: I ® internet
Rys. 10.2. Strona WWW informująca o zmianie stanu diod świecących
U
static const char stm32_logo_gif(] =
"HTTP/ł.l 200 0K\r\n"
"(JcsuiectaJn: close\r\n"
"Conten^łype: image/gif\r\n"
"\r\n"
t‘
i
278
JO. Serwis WWW
"GIF89a\xfa\x00\xa0\xG0\xf7\xQ0\x00\xf4\xfb\xfe"
"\xe7\xf7\xf c:\xb6\xdl\x78\x6c\xb3\x91\xf c:\xc5\x31\x00\xa3\xba\xb6"
Konwersji pliku binarnego z obrazkiem do postaci akceptow anej przez kom pilator
C w ykonałem za pom ocą prościutkiego program u, którego tekst źródłow y je st w ar­
chiw um z przykładam i w pliku im age2c.c w katalogu ,/m ake/exlO _httpd.
Plik ex_htłpd.c
Plik ex_httpd.c zaw iera funkcję main przykładu. Jest ona bardzo podobna do funkcji
main z przykładu 5a.
int main{) (
static struct netif netif;
static struct ethnetif ethnetif = {PHY_ADDRESS);
uint8_t confBit/
,
Delay(1000000);
confBit = GetConfBit();
Al l P i n sDisableO;
LEDconfigure();
RedLEDon();
SET_IRQ_PROTECTION{);
error_resetable(CLKconfigure(), ł);
error_permanent(LocalTimeConfigure(), 2);
error_resetable(ETHconfigureMII{), 4);
netif.hwaddr[0] = 2;
netif.hwaddr[l] = (BOARDJTYPE » 8) & 0xff;
netif-hwaddr[2] = BOARDJTYPE & 0xff;
netif.hwaddr|31 = (ETH__BOARD » 8) 6 0xff;
netif.hwaddr[4J = ETH_BOARD & 0xff;
netif.hwaddr[5j = 1 + confBit;
if (iconfBit) {
IP4_ADDR(finetif.ip_addr, 192, 168, 51, 84);
IP4_ADDR(finetif.netmask, 255, 255, 255, 240);
IP4__ADDR (finetif .gw,
192, 168, 51, 81);
$ echo -en "GET / HTTP/1.l\r\n\r\n" | nc 192.168.51.89 80
HTTP/1.1 200 OK
Connection: close
Content-Type: text/html; charset=UTF-8
<html><headxtitle>Przykładowy Serwer HTTP</title></headxbody><cente
r X p X i m g src="stm32_logo.gif" alt="STM32 LOGO" / x / p x p x f o n t size="
6">0 01:37:22.610</fontx/p><hr / x f o r m action="/led" method="post"X
p>Czerwona dioda świecąca <input type="checkbox" name="LED" value="R"
checked / x / p X p > Z i e l o n a dioda świecąca cinput type="checkbox" name=
"LED" value="G" / x / p > < p x i n p u t type="subn\it" value="Zmień" / x / p x / f
o r m X h r /Xp>lwIP/1.3.2 CMSIS/1.30 STM32F10x Standard Peripherals Lib
rary/3.3.0 newlib/l.18.0</pX/center></bodyx/html>
S echo -en "POST /led HTTP/1.l\r\nContent-Length: 5\r\n\r\nLED=G" \
i nc 192.168.51.89 80
HTTP/1.1 200 OK
Connection: close
Content-Type: text/html; charset=UTF~8
<html><headxtitle>Przykladowy Serwer H T T P C / t i t l e X / h e a d x b o d y X c e n t e
r x f o n t size-"4"xp>Wykonano</p><p><a h r e f = " / " > P o w r ó t < / a x / p x / f o n t x
/centerx/body></html>
W ysłanie błędnego żądania.
$ echo -en "PET / HTTP/1.l\r\n\r\n" I nc 192.168.51.89 80
HTTP/1.1 400 Bad Request
Connection: close
Content-Type: text/html
<html><head><title>Error</titlex/headxbodyXhl>400 Bad Request</hl>
</bodyx/html>
-,»■*'
)
error_resetable(LWIPinterfacelnit(finetif, fiethnetif), 5);
LWIPtimersStart();
error_resetable(DHCPwait(finetif, 10, 4), 6);
error_resetable (HTTPserverStart (HTTP__PORT), 7) ;
RedLEDoff ();
for(;;);
5
>
10.2.8.
Ś ciągnięcie głów nej strony serw isu. Ze zw róconej odpow iedzi w ynika, że czerw ona
dioda św iecąca jest w łączona, a zielona w yłączona.
W yłączenie czerw onej diody św iecącej i w łączenie zielonej.
}
else {
IP4_ADDR(&netif,ip_addr, 0, 0, 0, 0);
IP4_ADDR(&netif.netmask, 0, 0, 0, 0);
IP4_ADDRffinetif.gw,
0, 0, 0, 0);
279
wad. W szczególności trudno je st w ten sposób w ysiać błędne żądanie. O dporność
serw era na różnego rodzaju błędy najlepiej testuje się za pom ocą program u netcat
lub telnet. Poniżej zam ieszczam kilka przykładow ych testów w ykonanych z konsoli
Linuksa. Podczas tych testów serw er używ ał adresu IP 192.168.51.89 uzyskanego
za pom ocą DHCP.
"\x5b\x03\x00\x0b\x78\xc0\x40\xl6\xf2\x90\xl7\xcc\xa6\x06\xd7\xl3"
"\x70\x01\x01\x00\x3b";
static const s iz e _ t stm 32_logo_gil_len = sizeof(stm32_logo__gif) - 1;
10.2.7.
10.2. Przykład 10 —prosty serwis WWW
Testowanie przykładu
Prezentow any w tym rozdziale przykład pow inien w spółpracow ać z dow olną prze­
glądarką internetową. Jednak nie w szystko da się za pom ocą przeglądarki przetesto-
Prośba o nieistniejący zasób.
$ echo -en "GET /abc HTTP/1.l\r\n\r\n" 1 nc 192.168.5-1.89 80
HTTP/1.1 404 Not Found
Connection: close
Content-Type: text/html
< h t m l x b e a d x t i t l e > E r r o r < / t i t l e x / h e a d x b o d y x h l > 4 0 4 Not Found</hl></
bodyx/html>
W ysłanie błędnej w ersji HTTP.
$ echo -en "GET / HTTP/2.0\r\n\r\n” | nc 192.168.51.89 80
HT’
iJldU.i 595 HTTP Version Not Supported
ConnectiJm (close •
Content-Typfii text/html
280
10. Serwis WWW
< h t m l x h e a d x t i t i e > E r r o r < / t i t l e x / h e a d x b o d y x h l > 5 G 5 HTTP Version Not
Supported</hlx/body></htmi>
Tesr przekroczenia czasu. Połączenie pow inno zostać zam knięte przez serw er po 10
sekundach.
$ telnet 192.168.51.89 80
Trying 192.168.51.89...
Connected to local-89.localdomain (192,168.51.89}.
Escape character is ,AJ*.
Connection closed by foreign host.
Narzędzia GNU
282
Dodatek. Narzędzia GNU
Dodatek. Narzędzia GNU
283
Przykłady um ieszczone w lej książce kom pilow ałem w środow isku system u ope­
racyjnego Linux za pom ocą darm ow ego zestaw u narzędzi (ang. toolchain) G NU
z w ykorzystaniem darm ow ej biblioteki N ew lib. W tym dodatku dokum entuję proces
instalow ania środow iska program istycznego i kom pilow ania przykładów. O pis ten
je st przeznaczony dla C zytelników , którzy ju ż m ają pew ne dośw iadczenie w uży­
w aniu narzędzi GNU.
M ikroprocesory A RM używ ają trzech zestaw ów instrukcji: ARM , Thum b
i Thum b-2. D la każdego z tych zestaw ów trzeba m ieć oddzielny zestaw biblio­
tek. U m ożliw ia to opcja —e n a b le - m u l ti li b . Opcji tej jed n ak nie trzeba podaw ać
podczas konfigurow ania zestaw u narzędzi, gdyż je st dom yślna. N atom iast w pliku
Jgcc/config/arm /t-arm -elf m usim y zdefiniow ać, jakie w ersje bibliotek m ają zostać
skom pilow ane. N ależy w yedytow ać w nim następujące wiersze:
Instalow anie środow iska program istycznego należy rozpocząć od pakietu Binutils.
Jego najnow szą w ersję m ożna znaleźć na stronie http://ftp.gnu.org/gnu/binutils.
W trakcie przygotow yw ania książki najnow sza w ersja tego pakietu m iała num er
2.20.1. Jej instalow anie przebiega następująco:
MULTILIB_OPTIONS
= mthumb mcpu=cortex-m3
MULTILIBJJIRNAMES
= thumb coi:tex-m3
MULTILIB_EXCEPTIONS = mcpu=cortex-m3
MULTILIB_MATCHES
tar -zxf binutils-2.20.1.tar.gz
cd binutils-2.20.1
mkdir build
cd build
../configure --target=arm-elf — prefix=/usr/iocal/arm
make
su
make install
exit
cd ../..
Instalujem y kom pilator skrośny (ang. cross com piler) - kom pilacja je st w ykony­
wana na kom puterze o innej architekturze niż architektura procesora, na której ma
być w ykonyw any skom pilow any program . Param etr — t a r g e t określa docelow ą ar­
chitekturę, na którą będą generow ane pliki w ynikow e. P aram etr - - p r e f i x określa
m iejsce, gdzie będą um ieszczane pliki w ykonyw alnę zestaw u narzędzi. A by mieć
do nich dostęp, trzeba ustaw ić ścieżkę poszukiw ania plików. N ajprościej m ożna to
zrobić w pliku .bash_profile (w niektórych dystrybujcach .profile), który znajduje
się w katalogu dom ow ym użytkow nika. Przykładow y w pis w tym pliku w ygląda
następująco:
PATI!=$PATH:$H0ME/bin:/usr/local/arm/bin:/usr/local/msptSO/bin
export PATH
N a czas instalow ania kolejnych składników środow iska program istycznego w ystar­
czy w ykonać polecenie:
export PATH=$PATH:/usr/local/arm/bin
Pamiętajmy o dodaniu we w szystkich ścieżkach podkatalogu /bin. Polecenie make
i n s t a l l pow inno w ykonyw ać się z upraw nienianii^ifdm inistratora, dlatego przed
jego w ykonaniem przełączam y się w tryb adm inistratora za pom ocą polecenia su,
a po jego wykonaniu w racam y do trybu użytkow nika za pom ocą polecenia e x it .
K olejnym pakietem , który trzeba zainstalow ać, je s t GCC. A dresy serw erów oferu­
jących G CC dostępne są na stronie http://gcc.gnu.org/m irrors.htm l. Ze względu na
w ystępujący w rdzeniach C ortex-M 3 drobny błąd w niektórych w ariantach instrukcji
ld r d , należy użyć wersji co najm niej 4.4.0. Od tej wersji dla C ortex-M 3 dom yślnie
je st ustaw iona opcja -m fix - c o rte x -m 3 - ld rd , która zapobiega używ aniu przez kom ­
pilator w adliw ie działających instrukcji. W trakcie przygotow yw ania książki najnow ­
sza w ersja G CC miała num er 4.4.3. Po ściągnięciu pakietu należy go rozpakow ać:
tar -zxf gcc-4.4.3.fcar.gz
cd gcc-4.4.3
Pow yższe param etry oznaczają, że w dom yślnym dla bibliotek katalogu znajdą się
w ersje bibliotek używ ające zestaw u instrukcji ARM , w jeg o podkatalogu thum b
- w ersje używ ające zestaw u T hum b, a w podkatalogu thum b/cortex-m 3 - w ersje
używ ające zestawu Thum b-2. K onsolidator będzie dołączał w łaściw e biblioteki na
podstaw ie argum entów podanych w linii poleceń (konsolidatora lub kom pilatora).
D om yślnie dołączane będą biblioteki używ ające zestaw u instrukcji ARM . O pcja
-mthumb będzie w ym uszać dołączanie bibliotek używ ających zestaw u instrukcji
Thum b. Z astosow anie łącznie opcji -mthumb oraz -m cpu=cortex-m 3 będzie pow o­
dow ać dołączanie bibliotek używ ających zestaw u instrukcji T hum b-2. N azw y opcji
kom pilatora (z pom inięciem początkow ego m yślnika) specyfikuje się za pom ocą
param etru M0LTILIB_OPTIONS. N azw y podkatalogów , w których m ają być um iesz­
czane odpow iadające im w ersje bibliotek, w ym ienia się w param etrze MULTILIB_
DIRNAMES. Param etr MULTILIB_EXCEPTIONS służy do opisania zabronionych kom ­
binacji opcji kom pilatora. G CC nie dopuszcza użycia sam ej opcji -m cpu= cortex-m3, bez opcji -mthumb. Po skonfigurow aniu w ersji bibliotek m ożem y przystąpić do
skom pilow ania kom pilatora skrośnego:
mkdir build
cd build
../configure — target=arm-elf — prefix=/usr/local/arm \
— enabie-languages=c,c++ — with-newlib — without-headers \
— disable-shared — with-mpfr=/usr/local
O pcja —e n a b łe -la n g u a g e s określa języki program ow ania, dla których mają zostać
zbudow ane kom pilatory. U staw ienie łącznie opcji —w ith -n e w lib i —w ith o u t-h e ­
a d e rs spraw ia, że biblioteka L IB G C C zostanie zbudow ana bez w sparcia jakichkol­
w iek plików nagłów kow ych, czyli nie będzie ona korzystać z żadnej innej biblio­
teki, natom iast pozostałe biblioteki będą m ogły korzystać z biblioteki N ew lib i jej
plików nagłów kow ych. Takie ustaw ienia są typow e; gdy buduje się kom pilator dla
system ów w budow anych. O pcja — d i s a b le - s h a r e d w yłącza używ anie bibliotek
dzielonych, ładow anych dynam icznie, co w przypadku m ikrokontrolerów nie m ia­
łoby po prostu sensu. O pcja —w ith - m p f r = /u s r /lo c a l okazała się konieczna, gdyż
konfigurator nie znalazł położenia biblioteki M PFR, potrzebnej do skom pilow ania
GCC. Za pom ocą tej opcji w skazuje się ścieżkę, gdzie ta biblioteka je st zainstalo­
w ana. W konkretnym środow isku opcja ta m oże być zbędna, ale m oże okazać się
potrzebne użycie innych opcji. Sam proces kom pilow ania przebiega następująco:
make instaljlrgcc
284
Dodatek. Narzędzia GNU
exit
cd ../..
Popraw ność dotychczasow ych etapów instalacji m ożna spraw dzić za pom ocą
dw óch poniższych poleceń. Polecenie a rm - e lf - g c c -v pow inno w ypisać coś na­
stępującego:
Using built-in specs.
Target: arm-elf
Configured with: ../configure — target=arm-eif
— prefi.x=/usr/local/ann — enable-languages=c, C++ — with-newlib
— without-headers — disable-shared — with-mpfr=/usr/local
Thread model: single
gcc version 4.4.3 (GCC)
Natomiast polecenie arm-elf-gcc -print-multi-lib powinno wypisać coś takiego:
thumb;Gmthumb
thumb/cortex-m3;@mthumb@mcpu=cortex-m3
W kolejnym kroku instalujem y biblioteki. Potrzebujem y standardow ej biblioteki
języ k a C. Jedną z najpow szechniej stosow anych dla system ów w budow anych jest
biblioteka N ewlib. M ożna ją ściągnąć z serw era ftp://sources.redhat.com /pub/new lib/index.htm l. W trakcie przygotow yw ania książki najnow sza w ersja m iała num er
1.18.0. Jej instalow anie przebiega następująco:
tar -zxf newiib-1.18.0.tar.gz
cd newlib-1.18.0
mkdir build
cd build
../configure — target=arm-elf — prefix=/usr/local/arm — disable-shared
make CFLAGS_FOR_TARGET= \
''-02 -ffunction-sections -fdata-sections -D BUFSIZ =256"
su
make install
exit
cd ../..
Param etr C FLAGS_FOR_TARGET polecenia make określa opcje, które m ają być uży­
te podczas kom pilow ania biblioteki. Pierw sze trzy spośród tych opcji w yjaśniłem
w rozdziale 1. N atom iast opcja -D B U FSIZ je st specyficzna dla biblioteki N ew lib
i określa dom yślny rozm iar bufora przydzielanego dla plików otw ieranych za p o ­
m ocą funkcji fopen.
Pozostało jeszcze dokończenie instalow ania G CC. W tym kroku instalujem y po­
m ocnicze biblioteki dostarczane w raz z G CC. N ajw ażniejszą z nich jest biblioteka
libgcc. Ich instalow anie w ygląda następująco:
cd gcc-4.4.3/build
make all CFLAGS_F0R_TARGET="-02 -ffunction-sections -fdata-sections"
su
make install
exit
„
cd ../..
>
Teraz m ożna w reszcie rozpakow ać archiw um z przykładam i. W tym archiw um
w katalogu ./m ake znajdują się podkatalogi dla poszczególnych przykładów : e x la _
led, exlb _ lcd , ex2_eth, ex3a_ip, ex3b_ip_nc, ex3c_ip_zc, ex5a_tcpd, ex5b_tcpd_
Dodatek. Narzędzia GNU
285
wdg, exóa_tcp_clnt, ex6b_tcp_clnt_bkp, ex7_udpd, ex8_udp jo in t, ex9a_send_bcast,
ex9b_recv_bcast, exIO JU tpd. Każdy z tych podkatalogów zaw iera plik m akefile
urucham iający kom pilow anie odpow iedniego przykładu. W pliku m akefile specyfikujem y tylko nazw y plików źródłow ych i w ynikow ych, a w celu uruchom ienia w ła­
ściwej kom pilacji w łączam y plik m akefile.in, który znajduje się w katalogu ./m ake/
scripts. Plik m akefile, in zaw iera polecenia w spólne dla w szystkich przykładów.
W katalogu Jm ake/scripts znajduje się też głów ny plik m akefile, który urucham ia
kom pilow anie w szystkich przykładów. Z m ienna TARGETS (patrz pliki J m a ke/ex*/
m akefile) determ inuje form at produkow anych plików w ynikow ych. Jeśli podam y
plik w ynikow y z rozszerzeniem elf, zostanie zw rócony plik w form acie ELF. Jeśli
podam y plik w ynikow y z rozszerzeniem bin, zostanie w ygenerow any plik z binar­
nym obrazem pam ięci Flash. Jeśli podam y plik w ynikow y z rozszerzeniem hex, zo­
stanie w yprodukow any plik w form acie Intel HEX. M ożna podać więcej niż jedną
nazw ę, każdą z innym rozszerzeniem . Pliki w ynikow e dla poszczególnych przykła­
dów są um ieszczane w odpow iednich katalogach ./m ake/ex*.
D om yślnie przykłady kom pilow ane są na zestaw ZL29A R M z m odułem ethernetow ym ZL3ETH , a nazw y plików w ynikow ych poprzedzane są prefiksem z.l29arm+z.l3eth, natom iast pliki pośrednie i biblioteczne są um ieszczane w katalogu ./
m ake/lib/zl29arm + zl3eth. Przykłady m ożna łatw o dostosow ać do różriyeh w arian­
tów sprzętu za pom ocą dyrektyw kom pilacji w arunkow ej. Steruje tym zm ienna h a r ­
dware w pliku m akefile.in, który znajduje się w katalogu ,/m ake/scripts. D om yślną
w artością zm iennej hardw are je s t z l2 9 arra+ zl3 eth . M ożna to zm ienić, podając inną
w artość tej zm iennej bezpośrednio jak o param etr polecenia make, na przykład:
make hardware=prototype
Z ostanie w tedy użyty plik nagłów kow y board_def.il z katalogu ./exam ples/include/
prototype, nazwy plików w ynikow ych zostaną poprzedzone prefiksem prototype,
a pliki pośrednie i biblioteczne będą um ieszczane w katalogu Jm ake/lib/prototype.
D la każdej wersji sprzętu trzeba zdefiniow ać odpow iedni podkatalog w katalogu
./exam ples/include, a w tym podkatalogu należy um ieścić odpow iedni plik board_
def.h. Ponadto należy zdefiniow ać odpow iednią sekcję w pliku makefile.in.
Na koniec pozostaje jeszcze zaprogram ow anie pam ięci m ikrokontrolera.
R óżnorodność program atorów i program ów do ich obsługi sprawia, że trudno jest
podać jak ąś zw ięzłą instrukcję. W archiw um z przykładam i w katalogu ./m ake/
scripts znajduje się skrypt fla sh .sh dla O penO C D . U rucham ia się go, podając jako
argum ent nazw ę pliku w form acie binarnym . Jeśli nie podam y argum entu, to w bie­
żącym katalogu poszukiw any je s t plik z rozszerzeniem bin i zaw artość tego pliku
jest używ ana do zaprogram ow ania pam ięci m ikrokontrolera.
Literatura
Literatura
[I]
12]
[3]
[4]
15}
|6 j
[7]
[8]
19]
[10]
[II]
[12]
[13]
[14]
[15]
Corner D.E., Sieci kom puterow e TCP/IP. Zasady, protokoły i architektura, tom 1, WNT,
W arszaw a 1997, 1998.
K ernighan B.W., R itchie D .M ., Język A N S I C, WNT, W arszawa 2002.
Spurgeon C h.E., E thernet - podręcznik adm inistratora, RM , W arszawa 2000.
A N 3000 A pplication note, C onfiguring the N icheLite™ T C P/IP stack for the
S T M 32F 107xx m icrocontroller, http://w w w .st. com /stonline/products/literature/an/15903.
pdfA N 3102 A pplication note, lw lP T C P /IP stack dem onstration for STM 32F107xx connec­
tivity line m icrocontrollers, http://w w w .st.com /stonline/products/literature/an/J6620.pdf,
http://w w w .st.com /stonline/products/support/m icro/fU es/an3I02.zip.
A R M -based 32-bit M CU ST M 32F10xxx standard peripheral library, w ersja 3.3.0, h ttp://
w w w .st.com /stonline/products/support/inicro/files/stm 32fl0x_stdperiph_lib.zip.
PM 0056 Program m ing m anual, ST M 32F10xxx C ortex-M 3 program m ing m anual, h ttp://
w w w .st.com /stonline/products/literature/pm /J5491.pdf.
RM 0008 R eference m anual, ST M 32F101xx, ST M 32F102xx, ST M 32F103xx,
ST M 32F105xx and STM 32F107xx advanced A RM -based 32-bit M C U s, http://w w w .
st. com /stonline/products/literature/rm /13902.pdf.
ST M 32F105xx, ST M 32F107xx, C onnectivity line, A RM -based 32-bit M CU with 64/256
KB Flash, USB O TG , Ethernet, 10 tim ers, 2 C A N s, 2 A DCs, 14 com m unication interfa­
ces, http://w w w .st. com /stonline/products/literature/ds/15274.pdf.
Postel J., U ser D atagram Protocol, STD 6, RFC 768, sierpień 1980, http://tools.ietf.org/
htm l/ifc768, http://w w w .rfc-editor.org/std/std6.txt.
Postel J., Internet Protocol, ST D 5, RFC 791, w rzesień 1981, http://tools.ietf.org/htm l/
rfc791, http://w w w . rfc-editor. org/std/std5. txt.
Postel J., Internet Control M essage Protocol, STD 5, RFC 792, w rzesień 1981 http://tools.ietf.org/htm l/rfc792, http://w w w .rfc-editor.org/std/std5.txt.
Postel J., Transmission C ontrol Protocol, STD 7, RFC 793, w rzesień 1981, h ttp M o o ls.
ietf.org/htm l/rfc793, http://w w w.rfc-editor.org/std/std7.txt .
Plum m er D., E thernet A ddress R esolution Protocol: O r Converting N etw ork Protocol
A ddresses to 48.bit E thernet A ddress f o r Transm ission on E thernet H ardware, STD 37,
RFC 826, listopad 1982, http://lools.ietforg/htm l/rfc8264 ^http://w w w .rfc-editor.org/std/
std37.txt.
M ockapetris P., D omain nam es - concepts a n d fa cilities, STD 13, RFC 1034, listopad
1987, http://tools.ietf.org/htm l/rfc10 3 4 , http://w w w .rfc-editor.org/std/stdJ3.txt.
116] M ockapetris P., Domain nam es - im plem entation a n d specification, STD 13, RFC 1035,
listopad 1987, http://tools.ietf.org/htm l/rfcl035, http://w w w .rfc-editor.org/std/stdJ3.txt.
[17] D rom s R., D ynam ic H ost C opfiguration Protocol, RFC 2131, m arzec 1997, http://tools.
ietf. org/htm l/rfc213 J.
>
[18] Fielding R., G etlys J., M ogul J., F rystyk H., M asinter L., Leach P., B erners-Lee T.,
H ypertext Transfer Protocol - H T T P /J .l, R FC 2616, czerw iec 1999, http://tools.ietf.org/
htm l/rfc2616.
287
[19] Paxson V., A llm an M ., Com puting T C P ’s R etransm ission Timer, RFC 2988, listopad
2000, http://tools.ietf.org/htm l/rfc2988.
[20] C heshire S., A boba B., G uttm an E., D ynam ic C onfiguration o f IP v4 Link-L ocal Addresses,
RFC 3927, maj 2005, http://tools.ietf.org/htm l/rfc3927.
[21] B erners-L ee T., Fielding R., M asinter L., U niform R esource Identifier (U RI): G eneric
Syntax, STD 66, R FC 3986, styczeń 2005, http://tools.ietf.org/htm l/rfc3986, http://www.
rfc-editor. org/std/std66. txt.
[22] M ills D., Sim ple N etw ork Time Protocol (SN TP ) Version 4 fo r IPv4, IP v6 and OSI, RFC
4330, styczeń 2006, http://tools.ietf.org/htm l/rfc4330.
Download
Study collections