View DRM049_774431.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

motorola.com/semiconductors m68hc12 microcontrollers DRM049 rev. 0, 09/2003 internet connectivity designer reference design manual with hcs12 16-bit microcontroller using the acp reference f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola 3 internet connectivity with hcs12 16-bit microcontroller using the acp reference design designer reference manual ? rev 0 by: dr. gerald kupris, motorola sps, munich, germany. harald kreidl motorola sps munich, germany dirk lill steinbeis-transfer centre embedded design and networking university of cooperative education loerrach, germany prof. dr.-ing. axel sikora steinbeis-transfer centre embedded design and networking university of cooperative education loerrach, germany f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
designer reference manual DRM049 ? rev 0 4 motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola list of sections 5 designer reference manual ? DRM049 list of sections section 1. embetter ? a short o verview . . . . . . . . . . . . 15 section 2. connecting embedd ed applications to the internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 section 3. basics of implementati on. . . . . . . . . . . . . . . . 33 section 4. design techniques fo r embetter. . . . . . . . . . 43 section 5. overall implementati on of embetter . . . . . . . 49 section 6. layer implementation of embetter . . . . . . . . 63 section 7. test environment . . . . . . . . . . . . . . . . . . . . . 109 section 8. sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
list of sections designer reference manual DRM049 ? rev 0 6 list of sections motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola table of contents 7 designer reference manual ? DRM049 table of contents section 1. embetter ? a short overview 1.1 protocol suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 1.2 target platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 1.3 portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 1.4 modularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.5 scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 1.6 market positioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 section 2. connecting embedd ed applications to the internet 2.1 status and trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 2.2 system design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3 internet connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 section 3. basics of implementation 3.1 overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 3.2 packet switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3 layered protocol models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.4 client/server model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 3.5 ports and sockets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 section 4. design t echniques for embetter 4.1 overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
table of contents designer reference manual DRM049 ? rev 0 8 table of contents motorola 4.2 zero-copy approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3 unified protocol interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4 socket interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.5 callback functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.6 blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 section 5. overall implementation of embetter 5.1 overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 5.2 structure and interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 5.3 exception handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.4 buffer handling and data flow. . . . . . . . . . . . . . . . . . . . . . . . . 56 section 6. layer implem entation of embetter 6.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.2 modem communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.3 the point to point protocol (ppp) . . . . . . . . . . . . . . . . . . . . . . 72 6.4 the internet protocol (ip) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 6.5 the internet control me ssage protocol (icmp) . . . . . . . . . . . .83 6.6 socket interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.7 hypertext transfer protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .96 6.8 handling of web pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.9 simple mail transfer prot ocol. . . . . . . . . . . . . . . . . . . . . . . . . 102 6.10 udp applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 section 7. test environment 7.1 alarm control panel reference design . . . . . . . . . . . . . . . . .109 7.2 setup of the dem onstration and developm ent environment . 109 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
table of contents DRM049 ? rev 0 designer reference manual motorola table of contents 9 7.3 simulation environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 section 8. sources 8.1 web resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 8.2 literature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
table of contents designer reference manual DRM049 ? rev 0 10 table of contents motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola list of figures 11 designer reference manual ? DRM049 list of figures figure title page 1-1 embetter protocol suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2-1 architectures of inter net connectivity . . . . . . . . . . . . . . . . . . . . 22 2-2 direct connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 2-3 gateway-based connectivity wit h internal use of internet protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 2-4 gateway-based connectivity with internal use of non-internet protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 2-5 dialup to an internet se rvice provider . . . . . . . . . . . . . . . . . . .28 2-6 communication initiation of t he embetter implementation. .28 2-7 isp-based connectivity with a portal server . . . . . . . . . . . . . . 29 3-1 iso/osi communication layer protocol . . . . . . . . . . . . . . . . . 35 3-2 iso-osi reference model a nd tcp-ip refe rence model and protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 3-3 http packets via a serial link takes 51 bytes plus a variable http header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 3-4 the information flow in the layered model [9] . . . . . . . . . . . .38 3-5 client/server model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 3-6 ports and sockets for concurrent serv ers . . . . . . . . . . . . . . . .40 4-1 management of output buffers. . . . . . . . . . . . . . . . . . . . . . . . . 44 4-2 processing of received data link layer packet . . . . . . . . . . .47 5-1 folder structure of th e embetter protocol suite . . . . . . . . . . . . 50 5-2 the project structure of the embett er protocol suite. . . . . . . .51 5-3 declaration of api variables. . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5-4 main software interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5-5 main software interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5-6 example for exception handling. . . . . . . . . . . . . . . . . . . . . . . .56 5-7 call structure of functi on ppp_entry . . . . . . . . . . . . . . . . . . . .58 6-1 the modem initialization st rings. . . . . . . . . . . . . . . . . . . . . . . .65 6-2 the modem at commands . . . . . . . . . . . . . . . . . . . . . . . . . . .65 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
list of figures designer reference manual DRM049 ? rev 0 12 list of figures motorola 6-3 the modem state machine. . . . . . . . . . . . . . . . . . . . . . . . . . . .66 6-4 the states for modem i nput comparison. . . . . . . . . . . . . . . . .66 6-5 the simplified ppp state machine. . . . . . . . . . . . . . . . . . . . . .73 6-6 the supported lcp negotiation frames . . . . . . . . . . . . . . . . . 75 6-7 negotiation of ip addresses with lcpc . . . . . . . . . . . . . . . . . . 77 6-8 reading the pppbuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 6-9 embetter socket structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6-10 design of a sockaddr struct . . . . . . . . . . . . . . . . . . . . . . . . . . .86 6-11 udp data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 6-12 function calls to wh en sending udp datagrams . . . . . . . . . 88 6-13 the possible states for tcp sockets. . . . . . . . . . . . . . . . . . . . 90 6-14 tcp segment stored in st_buf[index]. cdata . . . . . . . . . . . . . . 93 6-15 function calls caused by soc_write() . . . . . . . . . . . . . . . . . . .94 6-16 html page providing static content . . . . . . . . . . . . . . . . . . . . 97 6-17 organization of html file name s and string pointers . . . . . .98 6-18 dynamic content in an html page . . . . . . . . . . . . . . . . . . . .100 6-19 http functions for dy namic content . . . . . . . . . . . . . . . . . .101 6-20 function template for generating dynamic co ntent . . . . . . .102 6-21 smtp communication between mail client and mail server.104 6-22 non-blocking implementation of smtp . . . . . . . . . . . . . . . . .105 6-23 proprietary udp client so ftware . . . . . . . . . . . . . . . . . . . . . . 107 7-1 test environment for the embetter su ite . . . . . . . . . . . . . . . . 110 7-2 information provided on debug interface . . . . . . . . . . . . . . . .111 7-3 settings for the terminal. . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 7-4 data in the command window . . . . . . . . . . . . . . . . . . . . . . . . 114 7-5 metrowerks inspector component . . . . . . . . . . . . . . . . . . . . . 115 7-6 profiler window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116 7-7 code coverage information . . . . . . . . . . . . . . . . . . . . . . . . . .117 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola list of tables 13 designer reference manual ? DRM049 list of tables table title page 2-1 swot analysis of direct c onnectivity wit hout internet protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 2-2 swot analysis of direct c onnectivity wit hout internet protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 2-3 swot analysis of gateway-bas ed connectivity wi th internal use of internet protocol and ethernet . . . . . . . . . . . . . . . . . . .26 2-4 swot analysis of gateway-bas ed connectivity wi th internal use of non-internet protocol s. . . . . . . . . . . . . . . . . . . . . . . . . . 27 2-5 swot analysis of isp- based connectivity with dialup. . . . . . 29 2-6 swot analysis of isp-bas ed connectivity with a portal server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4-1 bsd socket function implementation in embetter. . . . . . . . . .46 5-1 list of compilation units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52 5-2 overview of buffer variabl es . . . . . . . . . . . . . . . . . . . . . . . . . .57 5-3 overview of functions in buffer.c . . . . . . . . . . . . . . . . . . . . . . .59 5-4 header and data location for the di fferent protocols . . . . . . . 60 6-1 s12_sci.c functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 6-2 physical.c functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6-3 drv_modem.c functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 6-4 ppp functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6-5 constant values in ip h eader . . . . . . . . . . . . . . . . . . . . . . . . .82 6-6 header fields used for tcp segment processing . . . . . . . . . 89 6-7 socket values for tcp a nd ip header . . . . . . . . . . . . . . . . . . . 94 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
list of tables designer reference manual DRM049 ? rev 0 14 list of tables motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola embetter ? a short overview 15 designer reference manual ? DRM049 section 1. embetter ? a short overview 1.1 protocol suite the embetter protocol suite cont ains the following modules (see figure 1-1. embetter protocol suite ): application layer http-web server (also for dialup) tftp file server smtp mail client udp-client for por tal-based solutions transport layer transport control protocol (tcp) user datagram protocol (udp) network layer internet protocol (ip) internet control mess age protocol (icmp) net-to-host-layer point-to-point-protocol (ppp) generic modem drivers ethernet controller driv ers (for crystal cs8900) address resolution protocol (arp) f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
embetter ? a short overview designer reference manual DRM049 ? rev 0 16 embetter ? a short overview motorola figure 1-1. embetter protocol suite 1.2 target platforms the embetter protocol suite is optimized for use in 8- and 16-bit microcontrollers and is an efficient pl atform for internet connectivity in modular systems. the orig inal implementation wa s done for a motorola hcs12-microcontroller under me trowerks codewarrior v3.0. 1.3 portability the use of pure ansi-c and a minimum of external li brary functions make the embetter protoc ol suite extremely portabl e to a variety of other compilers and microcontro llers. the fitting to the hardware is performed in one c- and o ne header-file, leading to a smooth design flow. adaption to the different instruction sets of mo dems is being done in a single header file. the ppp parts of the protocol suite we re tested with the german internet service providers (isp) ar cor [w1] and freenet [w3]. the connectivity with telephone based dial-in was done with pcs running microsoft windows 98 and windows 2000. modem hardware ppp ethernet net-to-host layer interface arp ip icmp tcp http server udp socket interface smtp client tftp server proprietary udp client internet connectivity web and other services f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
embetter ? a short overview modularity DRM049 ? rev 0 designer reference manual motorola embetter ? a short overview 17 1.4 modularity the modules of the embett er protocol suite r un as independent as the protocol definition allow. the interf aces between the pr otocol layers follow the common winsock standard (init, open, cl ose, read, write). other physical layers, fo r example can or lin, can be supported. on the higher layers, additional protocols, such as do main name service or ipsec are under development. in case that a less per forming target hardware is being used, the protocol s and functions can be switched off before compilation. this holds true for add-in protocols, such as icmp or smtp. 1.5 scalability moreover, buffer and memory sizes can be scaled for optimal use of resources and full scalability. all param eters are described in the text files of the project. however, in the pre-defined version, the embetter protocol suite shows extremely small code and memory size at a reasonable performance. 1.6 market positioning in order to push its avail ability in the market, embe tter is distributed as an open-source product. however, this applies only for th e application in the alarm control panel reference design (acprd). for additional features and integration of customer 's application, support is performed by steinbeis tran sfer centre fo r embedded design and networking (stzedn) [w3], a design alliance partner of motorola inc. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
embetter ? a short overview designer reference manual DRM049 ? rev 0 18 embetter ? a short overview motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola connecting embedded applications to the internet 19 designer reference manual ? DRM049 section 2. connecting embedded applications to the internet 2.1 status and trends remote maintenance and control is already widely used in industrial automation and building automation and gains a cceptance for many other applications, for example sm art home applianc es, consumer electronics, networking devices. inter net- and web-based c onnectivity is playing a major part in unifying network infrastructure and company information flow. it is a main step ping stone on the way to ubiquitous computing [6]. where the internet may have been a dedicated networ k for computer data exchange in its infant years, today, more and more small, non-pc based, intelligent ?machines ? are connected to the network of networks. the prognosis is that by 2005, the amount of non-pc users on the internet will far exce ed the amount of pcs! for embedded internet connectivity, various tr ends can be observed: 2.1.1 maturing the products the market for embedded inte rnet is maturing rapidl y. being a research driven discipline for quite a while, internet prot ocol suites for embedded systems are widely available as st and-alone software packets or included in real-time operating system s. they are widely deployed and reliable. performance is incr eased and cost is reduced as semiconductor device dimensions continue to scale. 2.1.2 maturing the market the market for embedded in ternet is rapidly fo llowing the technical advances. maturity of the market can be identified by a broad variety of products and solutions, as well as by a fine different iation of market f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded app lications to the internet designer reference manual DRM049 ? rev 0 20 connecting embedded applications to the internet motorola players. however, this makes ma rkets more complicated and inter operability is at stake. 2.1.3 embedding and unifying inter net connectivity a nd web services internet-connectivity gives access to a ubiquitous net work of highest availability and reasonabl e performance at lowest cost. this especially holds true for target-oriented micr ocontroller-based embedded systems. however, connectivity infrastructure is only the starting point for inter operability and portability. a unified approach at application level (osi level 7) is the next step. its broad acceptanc e in the office and infotainment world, its flexible design and its effici ent implementation makes hypertext transfer protocol (http) the main contender for automation and control. 2.1.4 breaking the embedded isolation inter operability is even more questioned against the background of traditional dedication of embedded solutions, wh en optimized software hardware co-design and cost efficiency play a major role. however, embedded internet call s for open systems and comprehensive inter operability th rough all levels of communication models. a unified data flow from enterprise resour ce planning (erp) and management information systems (mis) to pr oduction planning systems (pps) and field control is envisaged. 2.1.5 leveraging security if security is of high value for de sktop computing, this holds true for embedded computing, where production facilities and other hardware equipment is at risk. therefore, se curity has to be at its maximum. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded applications to the internet system design DRM049 ? rev 0 designer reference manual motorola connecting embedded applications to the internet 21 2.2 system design a typical embedded internet device- may it be a highly integrated microcontroller (c) or a digital si gnal processor (dsp) - must handle at least two tasks. it has to control the system, it is embedded in. this functionality often requires real-time operation of the device. it has to provide the internet connectivity. theref ore, a tcp/ip protocol suite has to run on the device. this protocol usually requires a powerful processor, a complete operating system and a lar ge amount of memory to function. depending on the target hardware as well as the complexity of the problem, the developer has to decide whether to use an operating system. according to market analysis, more than 75 % of the embedded a pplications use operating system (os). thi s os may be proprietary , free or commercial. at the time being, onl y few os provide a tc p/ip protocol suite. however, an 8 or 16 bit microcont roller may not hav e enough resources for the implementation of an operating system. no os applications can be found in less complex applications often using small microcontrollers with strict hardware and runtime restrictions . the choice of writing standalone code is often made in order to optim ize memory usage, code size and run-time behavior. since it is written as target specific code it is often not portable to other targets. 2.3 internet connectivity 2.3.1 overview there is a good number of techniques, how to c onnect devices to the internet [7]. the pres ented solutions (see figure 1-1. embetter protocol suite ) concern the overall arch itecture at data link and networking layer, but do not consi der the physical layer. depending on the implementation, t he embedded device acts as client, who connects to a server when an event occurs, or it is a server that is called by remote f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded app lications to the internet designer reference manual DRM049 ? rev 0 22 connecting embedded applications to the internet motorola devices in order to read the data stored by the device or to change the settings of the device. figure 2-1. architectures of internet connectivity 2.3.2 direct connectivity figure 2-2. direct connectivity in this solution (case 1 in figure 2-1. architectures of internet connectivity and figure 2-2. direct connectivity ), both communication end-points are directly connected via a telephone line. in most cases, the microc ontroller acts as w eb server and the host computer dials to t he embedded device. there ar e only rare cases, where the embedded device dials to the remote se rver. however, client connections in the presented wa y are comfortable for debugging purpose, but for runtime c onditions, such a client is nearly not to be seen. direct connectivity internet protocol based via serial line (slip/pp p) embedded internet application non internet protocol based gateway connectivity via internet internal use of internet protocols internal use of non- internet protocols d isp-based connectivity via internet dial-up via portal server direct dial- up ch g f e without ip- masque- rading with ip- masque- rading f a f b modem c c modem pc remote host f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded applications to the internet internet connectivity DRM049 ? rev 0 designer reference manual motorola connecting embedded applications to the internet 23 in most cases of direct connecti vity, there is no advantage in using standardized internet protocols and mo st systems work with proprietary protocols with minimum overhead. so , in proper wordi ng, this is no internet connectivity ( table 2-1. swot anal ysis of direct connectivity without internet protocols ). however, the use of inter net protocol (case 2 in figure 2-1. architectures of in ternet connectivity ), brings standardization with it. this allows the use of internet based development and application tools. the simplest implement ation of internet connectivity is based on serial line protocols, such as slip [ref] or ppp [ref]. basic implementations are well possibl e with 8 bit microcontrollers ( table 2-2. swot analysis of direct connectivit y without internet protocols ). table 2-1. swot analysis of dir ect connectivity wi thout internet protocols strength weakness simple to implement and debug high security by unknown ?address? simple connection via cs sci alert function nearly impossible no simultaneous connections opportunity threat no costs for internet service provider no use of the internet only simultaneous technology transfer of the two hosts possible f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded app lications to the internet designer reference manual DRM049 ? rev 0 24 connecting embedded applications to the internet motorola 2.3.3 gateway-based c onnectivity via internet 2.3.3.1 overview internet connectivity using a gateway for the connection is very suitable for smaller devices, be cause a part of the functionality can be extended to this more powerful computer. do ing so allows t he step-by-step implementation of the necessary pr otocols on the embedded device up to the final releas e. there are two possibilities for internal networking, either ip-conformant or other protocols. 2.3.3.2 internal use of internet protocols the use of tcp/ip protocols on t he microcontroller side allows for highest flexibility and portability. ho wever, additional protocol overhead in the microcontroller is required. in most case s, ethernet is used as layer-2-protocol, because its interwor king with tcp/ip is proven, for example arp, and becau se frame sizes s how a good match. nevertheless, the use of other protocols, such as can for industrial automation or lin for hom e and facility automation, is well possible. table 2-2. swot analysis of dir ect connectivity wi thout internet protocols strength weakness simple to implement and debug high security by unknown ?address? simple connection via cs sci use of internet based development and application tools additional protocol overhead matching connection standards necessary alert function nearly impossible no simultaneous connections opportunity threat no costs for internet service provider no use of the internet, just the same tools only simultaneous technology transfer of the two hosts possible f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded applications to the internet internet connectivity DRM049 ? rev 0 designer reference manual motorola connecting embedded applications to the internet 25 figure 2-3. gateway-based connectiv ity with internal use of internet protocols the gateway itself may be pc with routing-software, a fully-fledged stand-alone router, or another emb edded device implementing a routing engine. however, the internal us e of internet protocols comes with two flavors: if the gateway is just doing the routing, the ip addresses of the microcontrollers are visible from the public internet. thus, embedded web-servers may easily be run. however, the devices are prone to attacks from the internet. in the second case, the gateway is a router, who runs network address translation (nat) or ip-masquerading. in most implementations, nat works only fo r clients behind the gateway. then, no servers may be accessib le from the outside. however, this is not a matter of principl e. ip-masquerading may saves costly internet addresses and leverage se curity, as it is only the gateway's ip-address, which is visible in the public internet. bus: can, lin, i2c... ethernet internet gateway c configuring computer c c f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded app lications to the internet designer reference manual DRM049 ? rev 0 26 connecting embedded applications to the internet motorola 2.3.3.3 internal use of non-internet protocols a good number of implementations le t the microcontroller communicate with a non-ip protocol. in many cases it is a simple serial protocol, and in very many cases it is propri etary. in those cases, the embedded devices can only communicate via inte rnet with the appropriate gateway. the gateway itself implem ents the server, but gat hers information from the embedded devices behind. the ma in advantage is that only the gateway has to implement internet protocols. all embedded devices behind the gateway may run an easier protocol. consequently, this solution is advantageous, when a significant number of low-end embedded devices have to be co nnected to the internet. table 2-3. swot analysis of gateway-based connectivity with internal use of inte rnet protocol and ethernet strength weakness known technology (cs 8900) fast data transfer compared to modem multiple access to microcontroller ethernet uncommon in home appliances dependence on gateway (single point of failure opportunity threat security options may be extended to more powerful gateway (firewall, ip-masquerading) independent from remote host's hardware prone to hacking, f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded applications to the internet internet connectivity DRM049 ? rev 0 designer reference manual motorola connecting embedded applications to the internet 27 figure 2-4. gateway-based connectiv ity with internal use of non-internet protocols 2.3.4 isp-based connectivity 2.3.4.1 overview internet service provider s play a major role in the architecture of the public internet. the do not only proved the access to dialup hosts, but also provide ip addre sses and dns-support. t hey may offer additional services, such as web-server capabilities. table 2-4. swot analysis of gateway-based connectivity with internal use of n on-internet protocols strength weakness cheap and easy access to microcontroller closed system of embedded device and gateway dependence on gateway (single point of failure opportunity threat web server functionality runs on powerful gateway security options may be extended to more powerful gateway (firewall, ip-masquerading) independent from remote host's hardware lack of portability proprietary protocol ethernet internet gateway c remote host c c f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded app lications to the internet designer reference manual DRM049 ? rev 0 28 connecting embedded applications to the internet motorola 2.3.4.2 dialup to an in ternet service provider figure 2-5. dialup to an in ternet service provider the dialup connection is most comm on for client applications, for example web-clients in t he home-office. in this case, the ip address is assigned by the isp. however, it is also possible to ru n a web-server via a dialup line and an isp. the main chal lenge is that the web-server has to dialup himself to the isp. the isp does not provide t he functionality to connect to one of its customers. additio nally, the web-server doe s not have a fixed ip address. the remote host shall be able to initiate the dialup process, and afterwards, the microcont roller has to communicate its ip address to a connecting host. the necessa ry steps are shown in figure 2-6. communication initiation of the embetter implementation . figure 2-6. communication initiati on of the embetter implementation there are two possibilities for the activation of the microcontroller ((1) of figure 2-6. communication in itiation of the embetter implementation ): ethernet internet modem c internet service provider c modem bank isp remote host (1) remote activation of the microcontroller (2) microcontroller connects to the isp (3) negotiation of the internet connection (4) sending of a memo to user containing ip (5) user clicks on the link in the memo (6) user connected to the microcontroller f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded applications to the internet internet connectivity DRM049 ? rev 0 designer reference manual motorola connecting embedded applications to the internet 29 it might be an incoming call on the m odem's extension. this call is not answered by the modem, but initiates the di alup to the predefined extension number of the isp. a signal on one of the microcontro ller's digital ports may serve as an alarm to initiate the dialup. 2.3.4.3 isp-based connectivity with a portal server figure 2-7. isp-based connectivit y with a portal server the use of a portal server can be understood as a dual server architecture. in figure 2-7. isp- based connectivity with a portal server , several embedded web servers ar e connected to the internet, table 2-5. swot analysis of is p-based connectivity with dialup strength weakness isp offers web services (mail-access?) microcontroller only online after dialup (security against hacking) isp has to assign a static ip (or further solution for telling address to host) opportunity threat alert function likely to be implemented independent from remote host's hardware independence from different isp isp might change dialup in times of heavy traffic, fail of connection possible internet modem c isp c modem bank isp remote host portal server f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded app lications to the internet designer reference manual DRM049 ? rev 0 30 connecting embedded applications to the internet motorola and controlled by an application server . the remote host connects to the application server, which presents a us er interface. the dynamic data for this interface are retrieved from the embedded devices. the use of a portal server gives highest flexib ility, best performance and highest portability. additionally , it might be the basis for a vpi-conformant architecture [w10]. all services be tween host computer and portal server and between portal server and embedded device s hould be run over http. 2.3.5 conclusion the swot-analyses in this chapter dem onstrates that there is no ideal general internet connec tivity for embedded dev ices. the best solution strongly depends on the actual circ umstances. this makes it an important challenge for a tcp/ip protocol suite such as embetter, to provide a set of module, which can be adapted to a maximum number of use cases. the released version 1.1 of embetter with acprd , corresponds to case 5 in figure 2-1. architectures of internet connectivity . however, table 2-6. swot analysis of is p-based connectivity with a portal server strength weakness web services from the isp microcontroller only online after dialup user interface on portal possible isp has to call back the microcontroller opportunity threat alert may be interpreted by portal independent from remote host's hardware host authentication performable by portal high availability through redundancy isp might change dialup dependence on portal server and isp, if not properly designed f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded applications to the internet internet connectivity DRM049 ? rev 0 designer reference manual motorola connecting embedded applications to the internet 31 additional modules are ava ilable at stzedn [w2] to cover other used cases. the inclusion of ethernet-m odule leads to case 4 in figure 2-1. architectures of in ternet connectivity . a vpi-compliant portal-server [w10] corresponds to case 6 in figure 2-1. architectures of internet connectivity . f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
connecting embedded app lications to the internet designer reference manual DRM049 ? rev 0 32 connecting embedded applications to the internet motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola basics of implementation 33 designer reference manual ? DRM049 section 3. basics of implementation 3.1 overview three overall paradigms influence the implementation of embedded internet connectivity: the distribution of information into separate packets which travel independently from so urce to destination is called packet switching. the modularity of a la yered protocol stack sets high requirements on the efficient realization of ea ch layer and the interfaces in between. the client/server model implies an asymmetric communication flow with the overall capability of being reached for servers. 3.2 packet switching an important side of the internet communication is the fact that the information does not travel in a cont inuous stream, but in the form of small data packets. a packet is an informat ion unit whose sour ce and destination are network-layer entities. a packet is composed of the network-layer header and possibly a trai ler and upper-layer data. the header and trailer contain control in formation intended for the network-layer entity in the destination system. data from upper-layer entit ies is encapsulated in the network-layer and tr ailer. the advantage of this packet technology is that every packet travel s independently from the ot hers. this makes the whole information transfer resistant against transmission failures. also, the system bandwidth is us ed very effectively. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
basics of implementation designer reference manual DRM049 ? rev 0 34 basics of implementation motorola a disadvantage of this technology is t he fact, that control information has to be added to each and every packe t. together with the layered protocol stack, being described bel ow, each protocol layer adds information to the data packet. therefore, it is not very ef ficient to submit just a small piece of information, because the overhead generated by the various protocols can be much larger than the transmitted data itself. 3.3 layered protocol models 3.3.1 the osi/iso reference mode l and the tcp/ip implementation the internet is a coll ection of individual networks, connected by intermediate networking devices, t hat functions as a single large network. the challenge when connecti ng various systems is to support communication between disparate tec hnologies. different sites, for example, may use different types of media, or they might operate at varying speeds. a network managem ent must provide centralized support and troubleshooting capabili ties. configuration, security, performance, and other issues must be adequately addr essed for the inter-network to function smoothly. the open systems interc onnect (osi) reference model which was introduced in the seventies an d released 1984 describes how information from a software applic ation in one node moves through a network medium to a software application in another node ( figure 3-1. iso/osi communi cation layer protocol ). f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
basics of implementation layered protocol models DRM049 ? rev 0 designer reference manual motorola basics of implementation 35 figure 3-1. iso/osi comm unication layer protocol the osi reference model is a conc eptual model com posed of seven layers, each specifying particular netwo rk functions. it is now considered the primary architectural model for inter-device communications. the osi model provides a conceptual framework for communications between computers, bu t the model itself is not a method of communication. actual communication is made possible by using communication protocols. the protocol is a formal se t of rules and conventions that governs how nodes exchange information over a network medium. used protocols in the internet are: the internet protocol (ip) with the internet control me ssage protocol (i cmp), the transfer control protocol (tcp) and the serial comm unications support slip (serial line internet protocol) and ppp (point-to-point protocol). the set of programmes used for internet communic ation is usually referred to as the ?internet protocol stack?. presentation application session transport network data link physical presentation application session transport network data link physical layer 1 host a host b definition of the services provided by the communication partner for each individual application program definition of the structures for user data with regard to formatting creation and removal of logical channels in physical transport systems control of data stream by providing error- free logical channels definition of a path from end-to-end; routing addressing ensuring correct data stream from point-to- point by definition of a data format for channel coding; medium access control definition of mechanical and electrical properties of the transport medium physical data flow logical data flow layer 2 layer 3 layer 4 layer 5 layer 6 layer 7 layer 1 layer 2 layer 3 layer 4 layer 5 layer 6 layer 7 user data user data f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
basics of implementation designer reference manual DRM049 ? rev 0 36 basics of implementation motorola tcp/ip was already established wh ile the iso netwo rking standards were evolving. nevertheless tcp/ip protocol can be described with the iso/osi model. the princi ple behind layering is each layer hides its implementation details fr om the layer below and the layer above. each layer on the transmitting node has a logical peer-t o-peer connection with the corresponding layer in the rece iving node. this is accomplished through the use of encapsulation. figure 3-2. iso-osi reference model and tcp-ip refer ence model and protocols shows the tcp/ip stack in terms of the osi layers. figure 3-2. iso-osi reference model and tcp-ip re ference model and protocols in figure 3-3. http packets via a serial link takes 51 bytes plus a variable http header , http data is transported via a serial line. each layer in a receiving machine gets re ceived data from the layer below, analyzes and removes t he appropriate header, and relays them to the layer above. similarly each layer in a sending node gets data from the layer above, builds and add s its header, and transmits the packet to the layer below. v.90 wireless lan (802.11) presentation application session transport network data link physical layer 1 layers in iso-osi reference model layer 2 layer 3 layer 4 layer 5 layer 6 layer 7 application transport internet network (host-to-net) layers in tcp/ip- reference model ftp pop3 telnet tcp udp ip arp ethernet (802.3) x.25 ppp icmp dhc p bootp snmp cvp http dns tftp smtp protocols in tcp/ip protocol stack f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
basics of implementation layered protocol models DRM049 ? rev 0 designer reference manual motorola basics of implementation 37 figure 3-3. http packets via a serial link takes 51 bytes plus a variable http header 3.3.2 communication flow 3.3.2.1 vertical communication in the protocol stack a layer is implemented to provide a service to the next upper layer. these services are located at servic e access points (sap), which are known by the protocols using this in terface. the data, which are sent or received at an interface, are sent as interface data units (idu) that contains interface contro l information (ici) as well as service data units (sdu). the sdu builds t he data unit for the co ncerned layer on the target system and data t hat were given by upper layer protocols. the ici control the interface concerning da ta unit length and fragmentation. as shown in figure 3-4. the information flow in the layered model [9] , this information is removed after t he evaluation in the current layer, whilst the sdu is transferred in t he protocol stack. the figure is to present the logical flow s that occur on sending an application data stream from system b to syst em a using an internet connection. ethernet udp tcp ip hdlc ppp slip http ftp dns 20 byte 20 byte n byte application data 5 byte 3 byte 3 byte arp f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
basics of implementation designer reference manual DRM049 ? rev 0 38 basics of implementation motorola figure 3-4. the information flow in the layered model [9] 3.3.2.2 horizontal communica tion of internet protocols the communication with the same la yer on the opposit e machine is implemented via service primitives. these primitives can be arranged in four classes as request, indi cation, response and confirmation. if the protocol utilized is reliable, all classes of serv ice primitives are adopted; non-reliable pr otocols only use the request and indication classes. the protocol layers below the concer ned layer ar e transparent to the protocol. in or der to achieve this tr ansparency, an encapsulation technique is adopted that provides a header for every layer passed. this header contains information about the destination protoc ol layer, the communication partners, and informatio n for data consistence. at the receiving side, these fields ar e analyzed and removed. if the header information is correct, the data insi de the packet are afterwards treated depending on link status and protocol informati on of the header. if the header information shows t hat the data are meant fo r the current layer, sap system a physical data link network transport application system b physical data link network transport application logical flow (data stream) segments datagrams frames physical flow idu ici sdu ici sdu f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
basics of implementation client/server model DRM049 ? rev 0 designer reference manual motorola basics of implementation 39 a reaction is prepared depend ing on the protocol stac k's settings and the packet's data, mostly combined with an answer generated. if the header indicates a higher layer to be responsible for the data, and if the current layer's link is establ ished, this layer is to be informed about the availability of new data. in all other ca ses, the data are discarded. this behavior allows a bi g inter operability of di fferent networking media because the packets may be re-packed for transport on different media. in figure 3-3. http packets via a serial link takes 51 bytes plus a variable http header , a part of a web page is shown, encapsulated in a hdlc frame. 3.4 client/server model the client/server model is basic for in ternet applications. a client forms a request, which is process ed and answered by the client ( figure 3-5. client/server model ). thus, the client/server model sets requirements for the servers, becaus e a server appl ication cannot be started on demand, but has to be available and accessible at any moment of time. for this, ip addr ess and tcp port have to be known. however, work-arounds for use in practical life are possible (see figure 2-6. communication initiation of the embetter implementation ) figure 3-5. cli ent/server model this model, sometimes calle d application-server-model [2], is one of the fundamental principles of the internet. it assume s, that a server being reachable via internet is waiting for cl ients to requests for a service. the server analyzes and executes an action depending on the request, mostly including an answe r to the request. after the action, the server returns into waiting state, expecting the next request. client client server server request response f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
basics of implementation designer reference manual DRM049 ? rev 0 40 basics of implementation motorola 3.5 ports and sockets two types of servers are commonly differentiated [8]: iterative servers cannot treat any other request as soon as they are responding to one r equest. this, of course , is not favorable, when it is likely that more than one client sends re quests at a time. a concurrent server, however, performs an additional step. when the request arrives, a second server is started to handle the entire procedure. the original server re mains free for further requests. thus, concurrent servers are advantageo us, as they can process more than one request at a time, leveraging performance and fl exibility of the system. however, the impl ementation of this conc urrent response poses additional challenges to the implem entation in an embedded system. in most cases, however, this concurr ency is realized with the help of the classical socket approach ( figure 3-6. ports and sockets for concurrent servers ). figure 3-6. ports and socket s for concurrent servers tcp manages the connection betwe en the communication channel and the application program in the hosts of both side s via ports. a port is defined as a 16 bit num ber representing a fiel d in the tcp header. in dependence of this destination port num ber, the receiving host passes the received data to the relevant application program. http client server host port 80 socket 1 socket 2 socket 3 passive active active active port 1043 port 1044 client host 1 ip address 193.196.182.232 http client http client port 1043 client host 2 ip address 193.196.182.233 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
basics of implementation ports and sockets DRM049 ? rev 0 designer reference manual motorola basics of implementation 41 in addition to t he concept of ports, the socket approach is of key importance for concurrent servers. a socket is a tcp communication end point, which is iden tified by the triple: ip address of the opposit e communication end point, tcp port number of the opposite communi cation end point, and tcp port number of the own communication end point. this triple allows the unique identifi cation of separate end points in the same and in differ ent client hosts. in this concept of concurrent se rvers, a generalized tcp server socket with dummy information of the opposite communication end point is always waiting for packets with a ma tching destination port number. this socket is called a passive, a demon or a server socket. when a matching packet is detected, a new socket is generated. this new active socket is copy of the original pa ssive socket with the info rmation of the opposite communication end point. this acti ve end point processes the communication. when the communication is finished, the active socket is deleted. when the passive socket detects a second packet with a matching destination port number, but different information of the opposite communication end point, it generat es a second active socket. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
basics of implementation designer reference manual DRM049 ? rev 0 42 basics of implementation motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola design techniques for embetter 43 designer reference manual ? DRM049 section 4. design t echniques for embetter 4.1 overview the implementation of t he tcp/ip based protoc ol on a microcontroller with limited resource s call some dedicated design techniques. this holds true for the memo ry management, the function interfaces and the blocking functions. 4.2 zero-copy approach the layered protocol model implie s two major disadvantages. each protocol layer adds its own control information in a header, leading to additional data to be transmitted. as the majority of these headers are standardized, one should not search alternative solutions. additionally, in most pc-oriented protocol stacks, one layer calls the next layer via a function call. the parame ters of this function include the data to be transmitted. this implies copying the va riables for most protocol stacks, which increases processing time an d memory space. however, a more sophisticated approach is possibly in dedicated solutions. in the implementation of embetter, the out buf fers are managed in a central buffer module ( figure 4-1. management of output buffers ). f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
design techniques for embetter designer reference manual DRM049 ? rev 0 44 design techniques for embetter motorola figure 4-1. management of output buffers in order to generate an outgoing buffer, the hi ghest layer protocol requests an output buffer. if there is an output buff er available, it gets back the handle for this buffer. if there is no buffer avail able at the time of the request, because all existing bu ffers are containing data still to be transmitted, the request will be repeated at a later time. after having received t he handle, the protocol head er is generated in the memory cells of each protocol laye r. after having done this for all relevant protocols, the ppp-modul e generates the frame checksum and puts it in the frame traile r. now, the frame is trans mitted byte-by-byte via the serial interface. af ter the transmission is successfully completed, the handle is released. this approach combines three advantages: no copying of the us er data is required. zero-length packets can easily be handled. the data transfer between the layers is modular. ppp_write can be replaced with ether_write . however, this concept is not feasible in all cases. when the data is to be transmitted via a companion chip fo r communication, for example an ethernet controller with separate output buffers, the frame has to be ppp h adresse l?nge ip adresse l?nge tcp adresse l?nge data adresse l?nge ppp t adresse l?nge handle protokolle sci ppp ip tcp data sende bytes handle handle soc_write buffer b u f _ g e t _ h a n d l e h a n d l e - n u m m e r f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
design techniques for embetter unified protocol interfaces DRM049 ? rev 0 designer reference manual motorola design techniques for embetter 45 copied from the microcontroller into the ethernet controller. this is commonly called a one-copy-approach. 4.3 unified protocol interfaces the layered protocol model a llows a platform independent communication with a strai ghtforward change of single protocols. in the embetter protocol stack, a protocol provides at least five functions to initialize the protocol, to open and close an instant iation of the protocol, and to read and write in t he instance of the prot ocol. this functionality may be called by the upper layer with five identi cal function calls. on the data link layer of the point to point protocol (ppp) those are: ? ppp_init() ppp_open() ppp_close() ppp_write() ppp_read() 4.4 socket interfaces tcp and udp are the top level protocols of t he communication portion of the internet stack. for that r eason a software inte rface needs to be implemented that permits user s to write applications for. neither does the specification fo r tcp defined in rfc793 nor the specification of udp in rfc 768 pr ovide a standard api. however rfc 793 only recommends the im plementation of ba sic functions [w11]. a widely used api for both udp a nd tcp communicati on is the socket interface used in the bsd unix operating system [2 ]. over the years it became a de facto standard for many internet stack implementations such as winsock. theref ore embetter provides an api similar to the f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
design techniques for embetter designer reference manual DRM049 ? rev 0 46 design techniques for embetter motorola bsd socket api with the so cket functions shown in table 4-1. bsd socket function implemen tation in embetter . 4.5 callback functions when a station receives a valid packet on the data li nk layer it is not yet clear, which upper protocols have to process this packet. this is defined within the packet on each layer. a protocol or type field carries the encoded information, wh ich is the next protocol to be called. figure 4-2. processing of recei ved data link layer packet gives an ethernet based example. table 4-1. bsd socket functi on implementation in embetter bsd socket api embetter socket api socket() soc_socket() open() soc_open() connect soc_connect() bind() soc_bind() close() soc_close() listen() soc_listen() accept() soc_accept() write() soc_write() read() soc_read() sento() soc_sento() recvfrom() soc_recvfrom() f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
design techniques for embetter blocking DRM049 ? rev 0 designer reference manual motorola design techniques for embetter 47 figure 4-2. processing of received data link layer packet the upper layer protocols are called via callback functions. callback functions are func tions, which are called with their memory address from the lower layer protocols. below t he ip-callback function in the ppp module is described. the initia lization of the ppp module sint8 ppp_init (void (*callbackip)(uint8), uint8 *cipaddr) requires two parameters: callbackip is the function pointer of the callback function of the higher layer, which is the function that has to be called when a valid ip packed is being received. cipaddr is the pointer where the ip address is to be stored. 4.6 blocking data packets of a random length build the communi cation via internet. an internet node does not know in advance, w hen it will receive a new data packet and how long this packet will be. thus, at first hand, the interrupt-based processing seems to be the appropriate method of handling incoming data. ho wever, due to the high complexity of processing internet protocol conforma nt data, the main application of the microcontroller might be blocked for a too long time. in order to keep interrupt service routines as short as possible, the embetter realization chooses a combined solution. only the individual bytes of a received packet are read-in with an interr upt service routine. after having ethernet header ip header tcp header 192.168.1.5 6 ip destination address protocol 00:90:96:1d:e9:99 0800 ethernet destination address protocol/type 80 tcp destination port number data (e.g. of application layer) ip tcp http f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
design techniques for embetter designer reference manual DRM049 ? rev 0 48 design techniques for embetter motorola received a complete frame - which is detected with the hdlc frame delimiter - the is_frame flag is set. this flag is polled within ppp_entry , which is called periodically by the main loop. complete frames are analyzed with the actual protocol and - if necessary - passed to higher layer protocols wit h callback functions (see 6.3 the point to point protocol (ppp) for details). if the data is addressed to the actual protocol, the answer is directly generated. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola overall implementation of embetter 49 designer reference manual ? DRM049 section 5. overall implementation of embetter 5.1 overview the embetter tcp/ip pr otocol stack is designed for use with 8 and 16 bit microcontrollers wit h limited resources that normally don't run an operating system. the stack was fi rst implemented on a motorola hcs12, a low-cost but highly integrated 16 bi t microcontroller. it is designed as a stand-alone st ack, but is modular and portable. however, it can also be used together with a small operating syst em, for example osek. 5.2 structure and interfaces 5.2.1 project structure the folder structure of the internet protocol stack is derived from the usual codewarrior stru cture. when creating a new project, in the ?sources? folder, there is a simple main proced ure and the start12 file. to include the internet connectivity, the embette r folder should be copied into this structure. when building the project using processor expert, the sources can also be placed in the code folder as well, as processor expert generates all user m odules in this folder. when using processor expert for the generation of hardware control functions, care should be taken that the system files are not modified by the user. else, a new generation of these file s might destroy the changes. figure 5-1. folder structure of th e embetter protocol suite shows the file structure of the alarm control panel reference design, designed like a common codewarrior project. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter designer reference manual DRM049 ? rev 0 50 overall implementation of embetter motorola figure 5-1. folder structure of the embetter protocol suite 5.2.2 module structure the implementations of the tcp/ip software suite, often referred to as tcp/ip stack, results in a complex code structur e. abstraction helps to create different compilation units that represents the f unctionality of a of the tcp/ip stack. a compilation unit comprise s a set of functions and option settings and is referred to as module. c does not especially support modular principles but provides the possib ility to create several compilation unit s within one software project. since the internet protocol suite is designed as layer model the modules in embetter are designed relating to the specific layers. as shown in table 6-3. drv_modem.c functions , some layers are consolidated in one module. however th e general idea of hav ing one layer being dependent on the other is reflect ed in the modules. each module depends on services of a nother module and provides functionality to one or multiple module as discussed in 3.3.2 communication flow . it follows a top-down strat egy, which means that t he services are defined in the lower layer's header file t hat is included by an upper layer. the f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter structure and interfaces DRM049 ? rev 0 designer reference manual motorola overall implementation of embetter 51 project itself consists of th e software modul es, shown in figure 5-1. folder structure of th e embetter protocol suite . figure 5-2. the project structure of the embetter protocol suite shows their internal rela tionship. the module out_buffer , timeout , and debug are not shown in this figure as they provide overall utility functions. figure 5-2. the project structure of the embetter protocol suite these modules are shortly described in table 5-3. overview of functions in buffer.c , for a complete discussion, see section 6. layer implementation of embetter . 5.2.3 software interfaces software interfaces are the ke y to data encapsul ation. data encapsulation means that data stored in certain memory spaces is only accessible through functi ons and not through direct memory access. as hardware sci modem phy interface handler ppp -tcp -udp -ip -icmp acprd_main.c socket.c ppp.c physical.c drv_modem.c s12_sci.c application layer transport layer host to network main application -smtp -http -html smtp.c http.c html.c internet f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter designer reference manual DRM049 ? rev 0 52 overall implementation of embetter motorola a result the format to pass on data is specified and not the way data is stored. in embetter, each module consists of a set of functions as well as module global variables. part of the functions and vari ables are intended to be used within the module whereas the rest are intended to be provided to other modules as software interface. global variables that are to be accessed by other modules are located in the module's header file. by having each module include it s own header file, the consistence of variables is raised . the example shown in figure 5-3. declaration of api variables extracted from the ppp so urce and header files show the declaration of api variables. before including the header, the declaration prefix (here: __decl_ppp_h__ ) is defined. when building the project, the preprocessor remove s the prefix for the ppp.c object file, in all other objects, the prefix is repl aced by ?extern? so th at the variable is only created once. but care must be taken that the prefix is only defined once in the project. table 5-1. list of compilation units module files description application application main.c main.h this module holds the code of the application, a task sharing loop to enable the network stack to operate, and the initialization of the hardware through functions that are provided. html project html.c html.h holds constant variables that represent html pages. web server http.c http.h implementation of a web server supporting http 1.0 according to rfc 2616 [ mail alerter smtp.c smtp.h implementation of a smtp client according to rfc 821 and rfc 822 network/transport internet protocols socket.c socket.h includes the implementation of the protocols needed for internet communications: ip according to rfc 791 icmp according to 792 udp according to rfc 768 tcp according to rfc 793 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter structure and interfaces DRM049 ? rev 0 designer reference manual motorola overall implementation of embetter 53 figure 5-3. declarat ion of api variables the function prototypes fo r local functions can be found at the beginning of the code module whereas function prototypes forming a software interface are defined in th e associated header file. software interfaces are used in embett er to implement the two important boundaries in the tcp/ip model [2 ]: high level protocol address boundary is called data link in terface and the operating system boundary is called socket interface. on the high level protocol address boundary datagrams and ip addresses are passed, on the operating data link ppp ppp.c ppp.h implementation of the point to point protocol according to rfc 1661 and rfc 1662 physical physical physical.c physical.h provides basic network interface functionality. includes modem handling and serial communication. modem drv_modem.c drv_modem.h set_modem.h routines to open and close a modem connection. modem commands that are specific to a particular type are defined in set_modem.h . this allows to adopt the modem driver easily to other modems. hardware sci_12.h sci_12.c hardware abstraction layer. provides a function that initializes serial communication interfaces, input and output ports. utility functions timers timeout.c timeout.h provides functions for timing pur poses. one hardware timer is being used to dynamically start and stop software timers. debug interface debug.c debug.h provides functions for debug information output. in this implementation debug information are sent to a serial interface. out buffer buffer.c buffer.h logical out buffer man agement utility functions. table 5-1. list of compilation units module files description f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter designer reference manual DRM049 ? rev 0 54 overall implementation of embetter motorola system boundary an application program interacts with an interface of the tcp/ip stack that is consi dered part of the operating system. figure 5-4. main software interfaces figure 5-4. main software interfaces shows the level of the two interfaces in the tcp/ ip reference model. furt her descriptions of the interfaces can be found in chapters 6.3.7 and 6.6. 5.2.4 integration of embe tter in an application embetter is specified to work without operating syst em. therefore the embetter software must be included in the main() loop of an application and it must be ensured that the entry function of embetter is called frequently. embetter is implemented in a non blo cking way, so that the cpu is occupied only fo r a short time slice. the initialization routine of embetter software has to be called before entering the main() loop. embetter occupies the serial comm unication interface (sci) interrupt service routine of the interface that the modem is connected to. an example implementation of the embetter softwar e into a main loop is shown in figure 5-5. main software interfaces . ip tcp udp socket interface data link interface http smtp ftp pop dns ? irda wlan ? icmp etherne t iee 802. 2 datalink physical media transport internet a pplication conceptual layer network interface tcp/ip stack serial line p rotocol s interface names f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter exception handling DRM049 ? rev 0 designer reference manual motorola overall implementation of embetter 55 figure 5-5. main software interfaces 5.3 exception handling most of the time an ex ception occurs it ca nnot be handled within the function itself but has to be passed on to the cal ling function. there are two basic principles used in embe tter for exception handling: firstly returning an error code as function return val ue or secondly setting the project global variable net_errno to a specific value. the values are defined as preprocessor defines in the corresponding header file. the second option was chosen for functions with a return value. in this case the method of setting a projec t global error vari able brings more flexibility to further enhancements than coding the error code in the return value of the function. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter designer reference manual DRM049 ? rev 0 56 overall implementation of embetter motorola figure 5-6. example fo r exception handling shows an example of the function soc_read() and how an exception handling can be realized. soc_read() returns the length of data r ead and sets the project global variable net_errno according to its result. figure 5-6. example fo r exception handling as further parallel sockets are available, the global variable net_errno is not sufficient for h andling all errors that ma y occur when writing to a socket. therefore, the struct soc_errno[] is introduced. it represents the current error state of the single sockets. the erro r codes of this struct are the same as for the net_errno variable. by this approach, parallel applications can send data over the socket interface without disturbing each other's communication. 5.4 buffer handling and data flow to understand the handling of buffers in embe tter it must be distinguished between the data flow of outgoing and incoming data. outgoing data is data of an application or process that needs to be transmitted by the networ k interface. incoming data is data that arrives uint16 inumbytes; inumbytes = soc_read (csock, &buffer, num_bytes); /* socket read call returns the number of bytes read */ if (inumbytes > 0) { /* everything ok, bytes were read */ } else { switch ( net_errno ) /* return value of 0 means an error occurred */ { case err_soc_badf: /* exception handling goes here */ break; case err_soc_notconn: break; case err_soc_connreset: break; case err_soc_again: break; } } f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter buffer handling and data flow DRM049 ? rev 0 designer reference manual motorola overall implementation of embetter 57 asynchronously at the serial comm unication interface and needs to be processed by different functi ons of the protocol stack. the aim of the buffer management is to provide common memory spaces for different functions in order to reduce t he amount of data copied between different la yers of the stack. fo r memory spaces that are accessed from different functions , the access must be verified in order to eliminate the risk of overwriting data. 5.4.1 overview of buffer variables two main buffer variables exist in embetter (see table 5-2. overview of buffer variables ): another buffer is defined as udoutbuf in buffer.c . it might lead to confusion that this variable is call ed buffer since it only contains of information about the memory location s of different pa rts of data to transmit. it is explai ned in more detail below. 5.4.2 incoming data the data communication interface is the serial port of the hc12. the serial port provides an interrupt s ource for incoming characters. this function is exploite d by the function ppp_receive() in module ppp.c . the aim of this function is to form frames in the memory variable pppbuffer [net_indata_size] of the incoming byte stream. the maximum size of this buffer is net_indata_size and is defined in netglobal.h . table 5-2. overview of buffer variables buffer name type purpose pppbuffer array of uint8 contains of received ppp frames until processed by all protocols st_buf[] array of struct snet_buf contains of incoming data for an application, tcp segments to send f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter designer reference manual DRM049 ? rev 0 58 overall implementation of embetter motorola after a complete frame is re ceived, the status variable cpppstatus is set to is_frame . as long as a frame is present in the buffer any incoming characters are discarded. the function ppp_entry() polls the flag is_frame and invokes a chain of function calls: figure 5-7. call struct ure of function ppp_entry the diamonds represented in figure 5-7. call str ucture of function ppp_entry indicate protocol multiplexing. to provide a highly compatible softw are interface the access to the frame stored in pppbuffer is provided thr ough the function ppp_read() . this function allows copy ing a number of bytes to a specified memory address. the buffer is read out sequentially. data that has been read by ppp_read() cannot be read a second time. however, the internal functions of the ppp.c module have direct access to the memory. these are ppp_handlelcp() ppp_handlepap() ppp_handleipcp() ppp_rejectprotocol() the function call structur e cannot be interrupted by other processes therefore it is not necessa ry to protect the function ppp_read() . ppp_entry ip_handler ppp_handleipcp ppp_handlepap ppp_handlelcp soc_handler icmp_handler udp_handler tcp_handler f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter buffer handling and data flow DRM049 ? rev 0 designer reference manual motorola overall implementation of embetter 59 all function calls in the structure must not be bl ocking; otherwise, no new frames can be received upon an error. the timing constraints duri ng the ppp negotiation ar e relatively strict regarding the low perfo rmance of low-cost microcontrollers. furthermore, the packets of a request and the ans wer to send are very similar, which allows building the outgoing packet directly in the ppp buffer to save calculating speed. for the same reasons, the function icmp_handler replies immediatel y to echo requests. incoming segments are hand led differently in udp and tcp (see also 6.5 the internet contro l message protocol (icmp) ). since data is not passed to an application immediately, it has to be latched. this is done in the buffers in the structure st_buf[soc_num_buf] . the constant soc_num_buf can be modified in the file netglobal.h . as a default, it is defined as twice the number of sockets. thi s perceives that the project is mainly based on tcp comm unication. for tcp, one buffer for incoming data, and one buffer for outgo ing data per socket is favorable. when embetter is used for a udp projec t, the number of buffer might be set independently. 5.4.3 outgoing data in order to keep memory usage low and the protec tion of one protocol overwriting another prot ocols data and header, eac h protocol has to provide memory space for its own head er instead of writing to a common memory space where outgoing data is being written to from each protocol. as discussed in 4.1 overview , a set of functi on is provided in buffer.c (see table 5-3. overview of functions in buffer.c ). the set of information for an outgoing packet is stored in the struct udoutbuf[buf_max_cnt] , where buf_max_cnt defines the maximum number of parallel outbuffers. building multiple packets at a time allows for example the par allel sending of a tcp packet and answering to an echo request. table 5-3. overview of functions in buffer.c function name description buf_init() initializes the module buffer.c f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter designer reference manual DRM049 ? rev 0 60 overall implementation of embetter motorola in order to write data one of the top level protocols, li ke http or smtp, tcp or udp prepares the data a nd the header to send and then calls first the function buf_gethandle() to retrieve the buffer handle. next it registers its dat a and header in the out buffer by calling buf_write() . afterwards it calls the write functi on of the lower la yer protocol and passes only the buffer handle. all protocols having written their information into the stru ct, ppp accesses the diff erent memory sections by calling buf_access . and sends the packe t over the physical interface. this concept allows the different prot ocols to store their data in a freely chosen address space. table 5-4. header and data locati on for the diff erent protocols lists the different protocol s and where each protocol stores its data and header to send: buf_gethandle() returns a handle and grants the right to call buffer functions with this handle buf_write() a protocol calls this function to register the address and the length of its data in the buffer structure buf_getprotcnt() returns the number of protocols already registered in the buffer structure buf_access() returns the address to a buffer element from a specific protocol buf_clear() sets all buffers to the initial value buf_gettotlen() returns the sum of all the lengths registered in the buffer structure table 5-4. header and data locatio n for the different protocols protocol description tcp header and data are copied to an st_buf[] element. udp the data location is advertised by the application through a pointer. udp builds its header on the stack. ip the header is stored in the module global variable stip_out_header table 5-3. overview of functions in buffer.c function name description f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter buffer handling and data flow DRM049 ? rev 0 designer reference manual motorola overall implementation of embetter 61 ppp the header is created on the stack icmp data and header are put on the stack table 5-4. header and data locatio n for the different protocols protocol description f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
overall implementation of embetter designer reference manual DRM049 ? rev 0 62 overall implementation of embetter motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 63 designer reference manual ? DRM049 section 6. layer implementation of embetter 6.1 introduction this chapter gives an overview of the implemented protocols. the modules, in which the different prot ocol layers are implemented, are described with their functional struct ure. beginning with the functions on the lowest layer of the osi refer ence model, the im plementation is depicted layer by layer. the most chal lenging step at th e integration of embetter into an application is the adaptation of the lower layer functionality to the user 's environment. adaptati on in higher layers is mostly intended to ra ise the performance of the protocol stack. 6.2 modem communication 6.2.1 overview modems are the predomi nant way to connect to the internet in the private environment, whic h is proved by a range of 79% of all internet connections in germany in 2001 [9]. but in the embedded environment, they are rarely utilized because of the wide range of different modem types in contrast to quasi-standard types of ethernet controllers. on the acp reference design (alarm control panel) [w5] there is implemented a socket mode m sc336h1 from multi-tech []. it is also possible to connect a serial gsm m odem to the rs232 interface of the acp to be independent from a phone line. 6.2.2 files enabling the modem communication in this implementation, the physical communicat ion is separated into different files. at the top, the module physical.c and its header file f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 64 layer implementation of embetter motorola physical.h present an abstraction la yer for the ppp module. it contains the api functi ons to handle the communi cation on the physical layer. changes in this m odule are only necessary if the way to connect to the internet changes , for example when using a null-modem-cable or an irda link. the most important changes during the adaptation to the user environmen t are the integration in to the user's serial communication interface control st ructure, and the implementation of new modem specific drivers. in embetter, the sci co mmunication is realized with an interrupt driven application in s12_sci.c . in case that the seco nd sci is already used in the user's application, the proc edures for sci cont rol of internet connectivity are preferentially to be im plemented in the user's module. in case, that only on sci is us ed, only the prescalers in s12_sci.h are to be set to match the transfer rate of the modem and the oscillator frequency. the modem driver is realized in the drv_modem.c module, which in most cases has not to be modified. to simplify the transfer to different modems, the modem dr iver has two differ ent header files. drv_modem.h contains the api-functi on prototypes which may be included in other files. set_modem.h is the file, in which modem-specific changes may adapt em better to the implementation environment. here, the informatio n about the telephone line connection is stored as well as the sp ecific modem commands. in figure 6-1. the modem initialization strings , the modem initializa tion strings as well as the respective modem answers are shown. the explanations for the expressions can be found in the modem manual. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter modem communication DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 65 figure 6-1. the modem initialization strings the several portions of t he strings are also defi ned for each modem in set_modem.h , of which a select ion is depicted in figure 6-2. the modem at commands . figure 6-2. the modem at commands 6.2.3 non-blocking modem driver normally, the modem comm unication is realized in a blocking way, by sending a string to the m odem and waiting for the answer. however, in the embedded environment, the microcontroller would not be available for other tasks, which is not allowed. therefore, t he state machine of the f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 66 layer implementation of embetter motorola modem communication is changed from the know n two-state machine (command and data mode) into the version outlined in figure 6-3. the modem state machine . the software sends strings to the modem via the serial communication interface. the answers are evaluated by interrupt service routines that control the transitions be tween the modem states. figure 6-3. the modem state machine the interrupt service routines depe nd on the state of the modem. incoming characters ar e always examined by modem_inpcomp() . the possible answer strings from the modem are stored in the eeprom before embetter at pr ogramming time. before setting the isr to modem_inpcomp() via sci_setcallback() , the pointer *pinpcompstr is directed to the answer string in the eeprom, which is expected from the modem. when an incoming character causes an interrupt, the function modem_inpcomp() compares it with the character at *pinpcompstr . if the conditions are met, the state variable cinpcompstate is changed. figure 6-4. the states for modem input comparison shows the possible valu es of this variable. figure 6-4. the states fo r modem input comparison mod_command mod_no_init mod_data mod_ connecting mod_dialing m o d e m _ i n i t f a ta l e r r o r ok dial isp carrier loss, dtr_off carrier detect or connect busy, no answer i n - c a l l w h e n a u t o - a n s w e r inpcmp_start impcmp_req inpcmp_invalid inpcmp_valid first character matches chars match, not end of string first char does not match chars match and end of string c h a r s d i f f e r e n t f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter modem communication DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 67 6.2.4 processing of incoming data in the initialization ph ase, sci-interrupts ca n be directed to the appropriate function because the possi ble answers to the strings sent are known. they can be concluded from the m odem command set [8] and its result codes. after the modem is initialized, the i sr is directed to modem_receive() , if either the remote acti vation or the connection of a remote host is allowed. modem_receive() checks for the first character of the expe cted string and calls modem_inpcomp() for the rest of the string. havi ng received the matching response, the modem is in data mode (see figure 6-3. the m odem state machine ). thus, it is transparent to the application. the callback function in physical.c is processed to redirect the interrupt service routine to upper layers and mark the physical link as established. 6.2.5 modes of modem operation as discussed in 2.3 internet connectivity , there are different techniques of how to connect to an embedded web server. the connection mode is chosen during th e modem initialization as the modem is instructed to r eact differently on inco ming calls. additionally, the interrupt service ro utine shall call differ ent functions depending on the initialization. 6.2.5.1 direct dialup (case 5) in this mode of oper ation, the embedded applic ation actively opens a connection to an internet service provid er. this case is similar to client program operations known from de sktop computers. the application asks the modem to connect to the isp by calling modem_open() . the modem dials the isp number and sends the corresponding answer strings depending on the conn ection state. as long as the timeout for the connection has not expired, the cmodstatus variable is in state mod_dialing . as soon as the connec tion is established, cmodstatus is changed to mod_data . now, the modem is transparent, and the application may negotiate their parameters. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 68 layer implementation of embetter motorola a connection to the isp can be establis hed in any mode of operation, for example for sending an alarm message to an smtp server . the settings for the connection, for ex ample the extension to dial, are described in netglobal.h . 6.2.5.2 direct internet -based connectivity (case 2) when the embedded application acts as a dial-in server, remote devices are allowed to connect. this mode of operation is activated by enabling the allow_dial_in option in netglobal.h . it is indicated with auto answer led on the mode m front panel after the initialization. when a remote client tries to connect to the embedded device, the two modems start negotiating the communicat ion parameters, for example concerning error control or communication speed. after the correct settings are found, the modem sends a ?1?-string to the microcontroller to notify that the carr ier is established. until that moment of ti me, the microcontroller is not in charge with the negotiation of communica tion parameters, whic h gives performance to other applications. modem_receive() calls the upper layer's callback function to inform that a connection is now active and that the incoming data are to be exami ned and answered by the upper layers. 6.2.5.3 remote activated mode this case (see figure 2-6. communication initiation of the embetter implementation ), contradicts the stri ct layered model (see 3.3 layered protocol models ). however, it allows a very cost-effective implementation of the intern et communication. when the remote_active directive is enabled, the microcontroller listens for incoming calls after the initializat ion. when a call is received, the connection is instantly inte rrupted and the global flag bconnect in netglobal.h is set. this flag must be polled by the main application. as soon as bconnect is true , the application ope ns a new connection via the isp. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter modem communication DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 69 6.2.6 functions related to the modem communication in this chapter, the functions on the lowest communication layer are listed up with their f unction calls and the va riables they access. table 6-1. s12_sci.c functions function name return value parameters functions called variables accessed description initsci0 void uint16 enevent, enuser, sci_hwendi serflag initialization of sci0 initsci1 void uint16 enevent, enuser, sci_hwendi serflag initialization of sci1 isr_sci0 void void sci_0_inttx_callb, sci_0_interr_callb, sci_0_intrx_callb interrupt service routine for sci0 isrerrorhandler void void channel default isr sci_0_interr_callb callbackfunc void _do_nothing callback function upon sci error sci_0_intrx_callb callbackfunc void _do_nothing callback function upon sci receipt sci_0_inttx_callb callbackfunc void _do_nothing callback function upon sci transmit sci_hwendi void uint8 enuser enables or disables the sci, depending on enuser sci_sendchar uint8 (uint8, uint8) enuser sends a character via the sci sci_setcallback void (void (*pfunction) (uint8), uint8) sci_0_intrx_callb, sci_0_inttx_callb, sci_0_interr_callb sets the callback function for interrupts to the specified function f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 70 layer implementation of embetter motorola table 6-2. physical.c functions function name return value parameters functions called variables accessed description phy_callback void void sci_setcallback pcbackhigherl, cphystatus sets physical status to phy_up and redirects sci isr to upper layer phy_close void void modem_close cphy status closes the physical layer phy_init uint8 callbackfunc modem_init cphystatus, phy_callback, pcbackhigherl initializes the physical layer, calls modem initialization phy_open uint8 void phy_init, modem_open, sci_setcallback cphystatus, net_errno, pcbackhigherl opens a connection, redirects sci isr to upper layer after completion phy_write void uint8 sci_sendchar writes a character via the sci to the remote host f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter modem communication DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 71 6.2.7 modem initialization modem operation is controlled by at and s register commands issued by the dte (acp) and with the si gnals dtr (data terminal ready) and dcd respectively cd (data carrier de tect). on the acp (alarm control panel) dtr signal is connected to port m pin 3 (pm3) and dcd is connected to port m pin 2 (pm2) on the mc9s12dp256 microcontroller. the /dtr (ttl active low) input is turned on (low) by the dte when the dte is ready to tr ansmit or receive data. /dtr on prepares the modem to be connected to the telephone line, and maintains the connection established by the dte (m anual answering) or internally table 6-3. drv_modem.c functions function name return value parameters functions called variables accessed description modem_close void void modem_hangup cmodstatus closes the modem modem_dial void void tot_delay, modem_write dialisp calls the isp modem_hangup void void tot_delay interrupts a connection modem_init uint8 (void (*pcallit)(void)) tot_init, modem_hangup, modem_inpcomp, sci_setcallback, tot_delay, modem_write pcbackphy, cmodstatus, cindex, initans, pinpcompstr, cinpcompstate, initseq initialization of the modem, stores the callback routine modem_inpcomp void (volatile uint8) cinpcompstate, cindex, cinpcompwrong, pinpcompstr compares strings sent by the modem with the expected answers modem_open uint8 void modem_inpcomp, sci_setcallback, tot_donothing, tot_settimeout, modem_dial, tot_getstatus, tot_resettimeout, modem_hangup cmodstatus, cdialansw, pinpcompstr, cinpcompstate, cdialtimeout, cinpcompwrong opens a connection to the isp, negotiates the connection parameters with the isp's modem modem_receive void (volatile uint8) sci_sendchar isr for incoming calls modem_write void (const uint8 *cdata) sci_sendchar sends a character via the sci modem_close void void modem_hangup cmodstatus interrupts a modem connection f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 72 layer implementation of embetter motorola (automatic answering). /dtr off places the m odem in the disconnect state under control of the at&dn and at&qn commands. the effect of /dtr on and /dtr off depends on the at&dn and at&qn commands. automatic answer is enabl ed when /dtr is on if the ?answer ringcount? selectable option is not set to 0. regardless of which device is driving /dtr, t he modem will respond to an incoming ring by going off-hook and beginn ing the handshake sequence. the response of the modem to the /dtr signal is very slow (up to 10 ms) to prevent noise from falsel y causing the modem to disconnect from the telephone line. when at&c0 command is no t in effect, /dcd ( ttl active low) output is on when a carrier is detected on the telephone line or off when carrier is not detect ed. /dcd can be str apped on using at&c0 command. the macros to contro l dtr and dcd from the software are in s12_sci.h : /************************************************************************/ /* data terminal ready signal (dtr) for the modem*/ /* data carrier detect (dcd) for the modem */ /* on socket modem sc336h1: dtr = pm3, dcd = pm2*/ #define dtr_outputddrm &= 0b11111011;ddrm |= 0b00001000 #define dtr_onptm &= 0b11110111/* reset port pin for dtr */ #define dtr_offptm |= 0b00001000/* set port pin for dtr*/ #define cd !(ptm & 4) /* returns true if cd is set*/ /************************************************************************/ 6.3 the point to point protocol (ppp) 6.3.1 overview in embetter, ppp is the interface between the in terrupt driven data flow from the sci, and a packet oriented data transfer of the internet protocol stack. when the physical co nnection is established (see 6.2 modem communication ), the interrupt service routine isr_sci0() is directed to ppp_receive() . ppp_receive() scans the incoming data for the start-flag; other characters are di scarded. after start is perceived, data is written into t he buffer for incoming data pppbuffer , until an end-flag is found. the start- and end-flags are not written into the f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter the point to point protocol (ppp) DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 73 buffer because they do not belong to ppp but the underlying hdlc. after the end-flag is f ound, the state variable cpppstatus is set to is_frame . is_frame is cyclically checked by the ppp_entry() function. having re ceived a new frame, the app ropriate function for the packet's layer information is called (see figure 5-7. call structure of function ppp_entry ). a detailed description of ppp can be found at [1]. for authenticati on, two general approaches can be distinguished, a two-way handshake protocol, such as password authentication protocol (pap), and a three-wa y handshake protocol, such as challenge authentication protocol (chap) in its various implementations. 6.3.2 ppp state machine the state machine envisaged for ppp in rfc1661 [11] contains five states. however, for the upper layers, su ch as ip, it is only relevant to know, whether a network connection is available or not. therefore, the ppp state machine of embetter contains only two states, network or no network (see figure 6-5. the simplifi ed ppp state machine ). the internal states of no network are realized within ppp_receive() . figure 6-5. the simplifi ed ppp state machine authenticate u p 5 x w r o n g opened establish dead terminate network f a i l dow n carrier lost ppp_close cauthok = true network no network f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 74 layer implementation of embetter motorola 6.3.3 negotiation of lcp options the link control protocol offers a bi g variety of options to be set. the most important opti ons are shown in figure 6-6. the supported lcp negotiation frames . these options are negot iated during link establishment phase. they include different compressi on algorithms for the communication phase, the pref erred authentication protocol, and further options r egulating the link establishment and maintenance. the function ppp_handlelcp() parses through the option fields of received ppp packets, as t heir length is variable. *poptionread points to the actual option to be evaluated. its type is cast depending on the option type. for the analysis of l cp options requested by the remote host, the following have to be distinguished: if the option is not kn own or forbidden (disabled), they are directly collected in pppbuffer for a reject answer. the remote host, who receives this reject packet, st ops negotiating the rejected options for the further process. the only exception is the case, where the remote host relies on th is option. for exampl e, if a encrypted password is required, but rejected from the microcontroller, the remote host will continue to ask for this option. in case, that the option is suppor ted but do not match the preferred value stored in the soptionstate array, are sent in a nak packet. if all requested options match a posi tive reaction is stored in the cvalid field of the nego tiated option in soptionstate . an ack answer is prepared, follow ed by a request of all options that have not been negot iated yet. packets for link termination and maintenance (code 05 to 0b), are directly answered. packets containi ng codes from 09 to 0b are rather unusual, but as they are necessarily to be implemented in order to fulfill the rfc, they are taken into ac count. their proce ssing is independent from the current link st ate, and it does not requi re further in vestigation. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter the point to point protocol (ppp) DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 75 figure 6-6. the supported lcp negotiation frames 6.3.4 authentication process embetter implements password authen tication protocol (pap) for ppp authentication, due to performance r easons. the authent ication process depends on the ki nd of connection in progress. if the microcontroller connects actively to an internet service provider, the remote host is taken as authenticated by the availability under the extension number. au thentication requests are positively answered, no ma tter which password and user information they contain. for authentication at the isp, the microcontroller transmits the user name and password specified for this connection in netglobal.h . if, however, a remote host opens a connection channel, embetter requests a valid aut hentication for this host. the transmitted password is compared with the predefined in_password (also in netglobal.h ). if this password matc hes, the negotiation of the ip address is set active. the negotiation of the ip addresses is not possible bef ore a successful authentication, as the remote host's ipcp and higher layers' packets are discarded. maximum receive unit asynchronous control character map authentication protocol magic number protocol field compression address and control field compression callback configure request : configure ack : configure nak : configure reject : terminate request : terminate ack : 0x.. c0 21 7e ff 03 hdlc-flag destination (broadcast) framing protocol identifier 16bit crc checksum 7e hdlc-flag code identifier length (high) length (low) option 1 id option 1 length option n id data n (var) 01 02 03 04 05 06 data 1 (var) option n length code reject : 07 protocol reject : 08 echo reqest : 09 echo reply : 0a discard request : 0b 01 02 03 05 07 08 0d 04 06 var 06 02 02 var f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 76 layer implementation of embetter motorola these technique guarantees a ce rtain security standard against intrusion. 6.3.5 ipcp negotiation the negotiation of the ip addre sses is handled as depicted in. the assignment of addresses is possibl e in multiple ways. the two most important are the following: predefined ip addresses are possible for debugging purpose and if the protocol stack is only to be contacted by a known, directly connected host. this case is shown on the left hand side of figure 6-7. negotiation of ip addresses with lcpc . if the microcontroller shall retrie ve its ip address from an internet service provider, t he right hand side of figure 6-7. negotiation of ip addresses with lcpc has to be used. here, the requesting host asks for a valid address with an empty req packet. the isp assigns an address from his ip a ddress pool. the cl ient sends a further request with his new ip address that is acknowledged by a final ack packet. for t he rest of this session, the client is now addressable through the inter net by the assigned address. if remote hosts are al lowed to connect to t he microcontroller (if allow_dial_in is enabled), the negotiation of the addresses is prone to errors, because in many cases, the ip addre ss settings of the dial-in computer are special and the errors difficult to find. the negotiation is processed depending on the settings of the remote host, here a few cases: if the remote host wants to retrie ve an ip address, the protocol stack assigns an address to it. if the host asks to have its fi x address negotiated, the stack tries to retrieve an address from this host as if it was an isp, as maybe, the host is configure to acc ept only a certai n range of ip addresses. if this does not work, a defaul t address, calculated via an offset from the remote host's address, is negotiated. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter the point to point protocol (ppp) DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 77 figure 6-7. negotiation of ip addresses with lcpc the negotiation of compression options is not implemented because of the low gain of transmi ssion speed in comparison to a high amount of additional computing. 6.3.6 ppp functions and global variables a b r e q 1 0 . 2 0 . 5 . 1 r e q 1 0 . 2 0 . 5 . 2 a c k 1 0 . 2 0 . 5 . 2 a c k 1 0 . 2 0 . 5 . 1 a b r e q 0 . 0 . 0 . 0 r e q 1 9 2 . 1 6 8 . 5 5 . 2 a c k 1 9 2 . 1 6 8 . 5 5 . 2 n a k 1 9 2 . 1 6 8 . 5 5 . 2 table 6-4. ppp functions return value function name parameters description (for details see function header in c-file) sbyte ppp_init void (*callbackip)(byte) byte *cipaddr initialize ppp call phy_init sbyte ppp_open none check phy_open open ppp void ppp_close none close phy-layer close ppp void ppp_write byte *cdata word len create ppp-header send packet word ppp_read none deliver 16bit of data set buffer ready to receive new packets word ppp_inbuf_cpyfrom byte *pdata word uilength copy a sequence of data to destination void ppp_entry none check for new packets direct packets to layers f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 78 layer implementation of embetter motorola 6.3.7 the data link interface 6.3.7.1 introduction the data link interface fo rms the interface between the internet layer and the data link laye r as described in 5.2.3 software interfaces . this interface should give access to diff erent types of hardware drivers. besides point to point connections a common way to connect to the internet is ethernet. for ethernet connectivi ty, the crystal cs8900 ethernet controller [12] is envisaged, as it is particular ly suitable for low cost ethernet connectivity in terms of availability , costs, and feature set. the interface consists of a routine t hat sequentially r eads out a buffer, containing a complete frame. in case of modem commun ication, this buffer is pppbuffer() on the microcontroller. in case of ethernet based comm unication, this buffer with a complete ethernet fr ame is on the external ethernet controller. 6.3.7.2 specification in consideration of t he facts mentioned above the interface was defined the way that: the data link layer provides a function to read data of incoming segments sequentially. no direct memory access to the buffer is provided. outgoing data is passed to the dat a link layer when a complete segment is ready to transmit. incoming segments are not ified through an event 6.3.7.3 implementation the data link interface provides the following functions that form the interface: ppp_init() ppp_open() f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter the point to point protocol (ppp) DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 79 ppp_close() ppp_write() ppp_read() these functions are descr ibed in detail in 6.3.6 ppp functions and global variables . in presence of a modem the function ppp_open() initiates the calling of an internet service provider . it returns immediately and repeated calli ng of the function ppp_open() returns true once the internet connection is established. ppp_write() expects as argument an out buffer handle. this handle gives access to the different memory locations where parts of the packet are stored (see figure 4-1. management of output buffers ). ppp_write() sends a complete datagram over the serial interface and builds around the ppp header and trailer. upon reception of a dat agram the function that is being called is the function passed on as an argument when calling ppp_init() . this is the event for the higher laye r to notify incoming data. ppp_read() reads data sequentially out of the out buffer (see figure 6-8. reading the pppbuffer ). the arguments passed are a pointer to a memory space to write data to and the number of bytes to be read. internally ppp_read() keeps track of a pointer , copies the amount of data and moves the internal pointer for the number of bytes read. this allows to sequentiall y read the ppp buffer. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 80 layer implementation of embetter motorola figure 6-8. reading the pppbuffer if there are more bytes reques ted then found in the buffer ppp_read() returns only the number of bytes read. if the pointer to the memory space is a null pointer then no data is copied, only th e internal counter is incremented for the numbe r of bytes specified. 6.4 the internet protocol (ip) 6.4.1 overview the internet protocol is t he major protocol to inte rconnect networks. it is the dominant la yer 3 protocol and provides the platfo rm for ubiquitous computing. its implementati on efficient may be very ef ficient, as it offers connectionless and unreliable communication. void func (void) { ppp_read(&data1, 2) . . . ppp_read(&data2, 8) . . . ppp_read(&data3, 4) . . . } pppbuffer [net_indata_size] bytes f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter the internet protocol (ip) DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 81 6.4.2 incoming datagrams ip starts to exploit the header of th e incoming datagram as soon as the function ip_handler() is being called. the datagrams is checked for formal requirements. if it does not meet the requirement s, it is being discarded by returning back to the calling function that is ppp_entry() . when the formal requirements are met the handler of the protocol according to the protocol identifier in the ip header is called. udp and tcp segments are both tr eated in the function soc_handler() , icmp datagrams are replied using the icmp_handler() the formal requirements th at are checked within ip_handler() are: version 4 ip datagram no options, header length 20 bytes destination address of the ip datagram equals the ip address assigned to the local adapter datagrams must not be fragmented. three values out of the ip header are needed for further processing and are put on the stack of this function: source ip address data length protocol identifier 6.4.3 outgoing data the function to send an ip datagram is called ip_write() . this function is called by upper layer protocols, such as tcp, which encapsulate data and headers in an ip datagram. as the internet protocol is connectionless, the up per layers have to provide the complete parameter set (destination ip address, buffer handle, calling function) for every new packet. the ip header is built and stored in the appropriate place in udoutbuf , as described in 5.4.3 outgoing data . f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 82 layer implementation of embetter motorola for performance reasons, the constant fields of the ip header are defined on module init ialization. their va lues are listed in table 6-5. constant va lues in ip header . ip_write() writes only the header fields that are different for each datagr am during the sending process, such as: ip length protocol type checksum destination address 6.4.4 restrictions regar ding the ip specification in embetter, ip serves only to re ceive and transmit datagrams. even though ip must theoretically be abl e to fragment data to meet the maximum transmit length of the data link layer, fragmentation is not supported, as it is assumed that t he maximum transmit length is known at all levels of the stac k. the attempt to transmit too long data packets must result in an exception. this implementation supports only one connected interface and therefore routing and gateway functionality is not required. this leads to major savings in te rms of performance and memory usage: no memory necessary for collecting fragments no forwarding of ip datagrams table 6-5. constant va lues in ip header header field value name value comments version ip_defh_version 4 this implementation supports only ip4 header length ip_defh_headlen 5 no options, header length 5x4bytes tos ip_defh_tos 0 default value identification ip_defh_id 0 no significance since no fr agmentation is supported fragment offset ip_defh_fragoff 0 no significance since no fr agmentation is supported time to live ip_ttl 0x20 a standard value; can be modified in socket.h f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter the internet control message protocol (icmp) DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 83 for performance re asons the header checksum of incoming datagrams is not verified and assumed to be corr ect. in a statistic [8] done on an ethernet network shows that as little as 14 out of 170.10 3 transmitted ip datagrams had a corrupt header. that is a probability of < 0,01? and therefor e the time consuming checking of the checksum is being left out. for version 1.2, ip header checksum verificati on will be included. 6.5 the internet contro l message protocol (icmp) embetter implements a basic versi on of icmp. as microcontrollers mostly do not possess a user interface, the protocol stack is not intended to send echo requests to remote host s. however, the ec ho reply function can be very useful for debugging purpose or for inspecti ng if the stored ip address for the micr ocontroller is right. to do so, the administrator sends a ?ping? request to the ip a ddress of the microcontroller. as a result, the round trip time can be analyzed on the administrating pc. modem activity can be checked with leds. icmp packets are directly processed and answered in the ip layer (see figure 1-1. embetter protocol suite ). therefore, multiple echo r equests are likely to block a system. to avoid this, two c ountermeasures are offered. icmp requests with dat a length bigger than icmp_max_datalen from socket.h are simply discarded. thi s should be suff icient for most cases, because attackers us ually use large packets in order to block a system. however, to achieve maximum se curity against a icmp based denial of service attack, the icmp functionality in netglobal.h can be switched off completely by setting prot_icmp to false . 6.6 socket interface 6.6.1 overview the classical socket api calls were defined as operati ng system apis for high-capacity computers. thus, the following re strictions had to be f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 84 layer implementation of embetter motorola applied in order to keep code and data size small and to be able to include it into a non-os application: exclusively non-blocking function calls no queuing of connection requests data transmit size at each soc_write() call is limited to the maximum transmit unit of a tcp ( tcp_tx_len ) segment or udp datagram ( udp_tx_len ) limited number of so ckets (defined by soc_num_socks in netglobal.h ). as embetter socket api is a user inte rface, each function call provides a designated exception handling. all function calls resu lt in a valid function return value or true and the global variable soc_errno[socket number] is set to err_soc_ok . in case of an error the return value might be invalid or set to false and the variable soc_errno[socket number] is set to the corresponding error. this allows the calling function to handle exce ptions differently. as mentioned above, embetter is implemented as non-blocking code. therefore, it is a widespread error sour ce that functions are not ready to accept new data, when there might be still data in the out buffer waiting to be acknowledged. in this case the function returns 0 as an indication that no bytes were trans mitted, yet. the erro r variable is set to err_soc_unack to indicate that there are still data in the socket's buffer and that this function has to be calle d again in order to transmit new data. 6.6.2 socket management embetter implements a simple socket api. basically, a socket is defined by a number that refers to a socket element in the array stsocket[soc_num_socks] . the constant soc_num_socks indicates the number of sockets allowed and can be set in socket.h . increasing the number of sockets resu lts in a higher dem and of ram, as one socket occupies 24 bytes of ram for saving the socket's information and a variable space for the in- and out buffers. the structure of a socket presents as following: f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter socket interface DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 85 figure 6-9. embetter socket structure the variable cstate has to be distinguished from cprotstate . whereas cstate keeps track of the overall stat us of the socket, such as soc_bind , whereas cprotstate stores actual stat us in the tcp state machine. embetter sockets may run udp or tcp. in both cases, they offer the following function call pattern: soc_socket() soc_bind() soc_listen (only for tcp) in case of tcp server sockets, or soc_socket() soc_connect() in case of tcp client sockets. the structure sockaddr presents as following: f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 86 layer implementation of embetter motorola figure 6-10. design of a sockaddr struct a socket can easily be accessed usi ng its array index. since a socket represents for tcp level a conn ection and for udp a communication end point, the destinati on ip address and port num ber and the local port number uniquely define it, as the client chooses for every new connection to a known port (for ex ample port 80 for www) a random or succeeding port number. a socket is considered unused when the variable cstate is set to sta_soc_free . 6.6.3 incoming data after ip evaluated the values of t he header of the in coming datagram the function soc_handler processes both, udp and tcp datagrams. in both cases, it is only possible to call the specific protocol handler, if there is an existing socket, to which the data can be assigned. to identify this socket, source ip address, source port and dest ination port are compared with the por t numbers and destination address of all active sockets, with the same protocol type. if there is no matc h or if the system is not able to accept a new connection on the ca lled port, the datagram is silently discarded. for details, see the soc_handler procedure in socket.c . in case of a match, the handler of the specified pr otocol is being called. for the different processing of tcp segments see chapter6.6.5 and udp segments see 6.6.4 user datagram protocol f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter socket interface DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 87 6.6.4 user datagram protocol 6.6.4.1 overview the udp protocol is implemented in socket.c and provides connectionless unreliable data tran smission. udp is a very easy protocol, which requires only marginal system re sources. therefore, it may be used for basic functionalit y and for network administration applications. 6.6.4.2 receiv ing udp segments udp_handler() retrieves an st_buf element and st ores the sender address and the data in this st_buf element. then the in buffer element is associated to the socke t through setting the value cdatain in the socket element to the index of the st_buf element. furthermore, the st_buf[x].csock variable points to the socket using that buffer. this redundancy of references hel ps to reduce overhea d in finding a socket related to a specific buffer and vice versa. figure 6-11. udp data storage shows how data is received and stored: figure 6-11. udp data storage csoc k idatlen k st _ buf[cinbuf] cdata struct sockaddr udp data socket number f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 88 layer implementation of embetter motorola as a result the maximum receive si ze for incoming udp segments is defined as: udp_rx_len = soc_buf_len - sizeof(struct sockaddr ) the macro udp_rx_len is defined in socket.h . 6.6.4.3 sending udp segments udp does not occupy an out buffer el ement to store th e outgoing data. therefore any data length ca n be accepted that is not superior of the maximum data length of the network interface. the network interface advertises its maximum trans mit length with the macro ppp_ip_tx_len . an application can send udp segment s by calling the socket function soc_sento . to send the udp data the following function calls are issued: figure 6-12. function calls to when sending udp datagrams in udp_write() a header is built on the st ack since after transmission of the udp segm ent, any data can be discarded. udp_write() calls also the function to build the ip he ader, since parts of the ip header can be used for the calculat ion of the pseudo header. the following fields are directly a ccessed to compute the checksum of the ip header: source ip address destination ip address protocol number soc_sento ip_buildheader buf_write ppp_write udp_write f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter socket interface DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 89 length of the udp segment after successful completion of ppp_write() , the function returns to back to the application. 6.6.5 transport control protocol 6.6.5.1 overview the tcp protocol is implemented in socket.c and provides connection oriented reliable data tran smission. the complexity of this protocol requires normally significant resour ces; therefore th is implementation tries to meet the most ba sic requirements of this protocol in order to keep the demand for resour ces such as rom, ra m, and cpu time low. the socket api uses tcp and assigns a socket to a tcp connection. therefore any tcp actions are bas ed on a member in the array of sockets stsocket[] defined in socket.c . 6.6.5.2 receiving tcp segments upon receipt of a tc p segment the function tcp_handler() is called. this handler needs to dist inguish between differ ent segment types and operations on the specifi ed socket are iss ued. the flags set distinguish the type of the segment. in a first step, t he values out of the tcp header (see table 6-6. header fields used for t cp segment processing ) that are needed for further processing are stored in t he following local variables: other fields and opt ions are ignored. table 6-6. header fields used for tcp segment processing header field variable name length/bit sequence number lseq 32 header length lack 32 tos stflags 16 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 90 layer implementation of embetter motorola there are two types of segments that are handled regardle ss of the state of the socket: a segment with the reset flag set (rst) sets a socket back regardless of the stat e of the socket. rel easing the buffers and setting cprotstate to sta_tcp_closed do this. server sockets, of which cstate is set to sta_soc_bind showing that they are expecting incoming connec tions are reset to sta_tcp_listen . after resetting the socke t the handler returns. if the acknowledge flag is set in an incoming tcp segment and there is a buffer with outgoing data associat ed to the buffer the buffer can be released since t he data was acknowledged of the connected peer. since the out buffer size is rela tively little it is assumed that the connected peer acknowledged all data. statistics show that most tcp advertise a window size of 8kb, 16kb or 32kb [13]. however, in the embedded worl d, the length of data does not r each these values. in any other case, t he operations depend on the current state of the socket. the state of the socket is registered in stsocket[].cprotstate . the states in em better defined in socket.c (see figure 6-13. the possible states for tcp sockets ) are compliant to the states of t he tcp state machi ne specified in 3.2 packet switching of rfc 793 [11]: figure 6-13. the possible states for tcp sockets f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter socket interface DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 91 the state sta_tcp_estab_data is an additional stat e indicating that the socket is establis hed and that incoming data is waiting to be examined by the application layer. the following tables follow the different states of the tcp state machine. the respective actions are briefly described. the states appear in the same order as implemented in tcp_handler() : sta_tcp_listen segment received: syn actions: retrieve a st_buf element stores information such as source address, source port, and sequence number in the st_buf element sets socket in sta_tcp_syn_recv state sta_tcp_syn_recv segment received: ack actions: verifies the acknowledgment number releases the associated buffer that holds the syn segment sets socket in sta_tcp_established state sta_tcp_syn_sent segment received: ack and sin actions: verifies the acknowledgment number sends an acknowledgement segment with incremented sequence number sets socket in sta_tcp_established state f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 92 layer implementation of embetter motorola sta_tcp_established segment received: no flags verified actions: verify if the segment contains data retrieve a st_buf element store incoming data send an acknowledgement segment for the received data by incrementing the acknowledgement number by the number of bytes received segment received: fin actions: send an acknowledgement to notify that the fin segment arrived set socket in sta_tcp_close_wait state sta_tcp_close_wait segment received: ack and fin actions: send an acknowledgement / fin segment sta_tcp_last_ack segment received: ack actions: reset the socket sta_tcp_fin_wait1 segment received: ack actions: set socket in sta_tcp_fin_wait2 state f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter socket interface DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 93 6.6.5.3 transmissi on of segments an application can transmi t data to a connected peer with the function call soc_write() only when the socket is in sta_tcp_established state and there is no data waiting to be acknowledg ed. the application data is copied into the data ar ray of the socket's out buffer ( st_buf[index].cdata ), before building th e tcp header. the tcp segments are stored in the out buffer as shown in figure 6-14. tcp segment stored in st_buf[index].cdata . figure 6-14. tcp segment stored in st_buf[index].cdata the variable idatalen stores the actual length of the tcp data, as the tcp header does not provi de such a field. the f unction calls are shown in figure 6-15. function ca lls caused by soc_write() . sta_tcp_fin_wait2 segment received: fin actions: send acknowledgement for the fin segment net_buf[].cdata ctoretr itoend tcphdr ctcpd numbers of remaining retransmissions retransmission trigger value tcp data length tcp data idatalen tcp header f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 94 layer implementation of embetter motorola figure 6-15. function ca lls caused by soc_write() the socket variable provides the values in table 6-3. drv_modem.c functions for both the tcp header and the ip header: after ip_buildheader is called, tcp may a ccess the following fields of the ip header that forms the tcp pseudo header to compute the checksum: source ip address destination ip address protocol identifier tcp length after passing the data to the data link layer the tcp segment remains in the st_buf element until it is being acknowledged. the tcp socket table 6-7. socket values for tcp and ip header socket variable field description stsocket[].sk.num ptcph->source source port number stsocket[].sk.dport ptcph->dest destination port number stsocket[].lack ptcp->stcph.seq the current expected acknowledge number is the actual sequence number stsocket[].sk.daddr stip_out_header.daddr destination ip address soc_write buf_write(tcp_h) ppp_write ip_buildheader tcp_write buf_write(data) f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter socket interface DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 95 keeps the index number of the ne t buffer element in the variable stsocket[].cdataout . the out buffers are statically connected to the socket, to give preferential treat ment to established connections' the outgoing traffic rather t han new connection requests. 6.6.5.4 retransmi ssion and timeouts an additional challenging aspect in tcp implement ation is the memory management. as a connec tion-oriented and reliable protocol, tcp includes the repeated transmi ssion of a segment, as long as there is no acknowledgement for this segment and as long as the timeout for this transmission has not elapsed. these re transmissions make it necessary to store the outgoing dat a as long as there is no acknowledgement. in order to ease sl iding window functionality of tcp, embetter sets the window size to ?1?. this means, th at the remote host has to send acknowledgements for ever y segment received. ea ch segment is kept in the memory and no new segm ent is transmitted, until the acknowledgement is received. retransmissions are triggered by a free running c ounter that is incremented every 10 ms. this free running counter in embetter ( tcp_tick() ) is linked to the isr of a hardware timer and increments the 16 bi t variable itcp_tmr . each socket provides the variable stsocket[index].itick that represents the number of increm ents before a segment must be retransmitted. this allows dynamic calculation of the retransmission timeout (rto). in embett er the rto is set to a default value of 1000 ticks. it is set by the preprocessor definition tcp_retr_ticks in socket.h . the central function of the socket module is soc_entry() . in this function all sockets with a valid reference to a st_buf element containing sent data are checked for retransmission timeouts. the retransmission timeout is reached when the retr ansmission trigger value itoend in the st_buf element (see figure 6-14. tcp segment stored in st_buf[index].cdata ) is smaller than th e value of the free running counter itcp_tmr . f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 96 layer implementation of embetter motorola if the free running coun ter passed the value in itoend the segment is resent by the function tcp_write() . to limit the number of retr ansmissions the variable ctoretr is decremented by one every time a retransmission occurred. after this value has reached zero it is assume d that the connect ed peer is not responding anymore and as a result the socket is being reset. 6.6.5.5 summary this tcp implementation covers onl y the basic features of the tcp specification. the restrictions appli ed to the full tcp implementation: no options allowed one out and one in buffer per socket checksum verification begi nning with version 1.2. basic transitions of the tcp state machine implemented urgent mode is not supported 6.7 hypertext transfer protocol 6.7.1 overview the embetter http server cove rs the following features: non-blocking implementation supports the http methods get and post dynamic generation of content possible supports multiple incoming connect ions at a time (defined by client_max_cnt in http.h ) possibility of storing files in a file system with directories http.c holds the implementat ion of the http se rver. the contents, such as html files or graphics, are placed in html.c . f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter hypertext transfer protocol DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 97 the http server must be called period ically out of the main application loop with the function http_entry . the non-blocking functionality is provided through state ma chines. the first state machine controls the http server function, if it is no t possible to open a socket and to listen on the default http po rt 80. the second stat e machine handles the acceptance of incomi ng requests and the phases of data exchange between the remote hosts and the different lo cal sockets. these two state machines are realized in http_entry() . further state machines, implemented in different procedures called by http_entry() , control the processing of incoming data and t he choice of the right web pages to transmit. 6.7.2 setup of the http server in this section the settings are ex plained that have to be modified to enable the http server to provi de the right objects upon request. as mentioned above, html pages or any object th at http controls are stored with their data a nd their filenames in html.c . the content of each file is assigned to a constant variable . this variable does not only contain the content of the file but also the http header. this eases the adaptation of the h ttp headers to diff erent file types. an example of a html file assi gned to a variable is shown in figure 6-16. html page providing static content . figure 6-16. html page pr oviding static content f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 98 layer implementation of embetter motorola the constant http_default_head is a very basic http header that can be used for plain html pages as well as pages with included graphics. the array pfilenames[] contains the f ilename strings that a remote user may request via hi s browser. in the structure html_files[] , data pointers to the several string constant s and the lengths of the strings are stored. to be compliant with comm on browser entries , the filenames have to start with a ?/? and end wi th zero. the stri ng pointers and the filenames have to be at the same po sition in both arrays. an example is shown in figure 6-17. organization of html file names and string pointers . figure 6-17. organization of html file names and string pointers figure 6-17. organization of html file names and string pointers shows the formal require ments to register a ht ml file in the http server. some additional settings are required. if the file represents a html p age, the information consists of ascii characters terminated by a ze ro character. in this case, the first value in the structure html_files can be set to zero. this indicates that the length of the file can be computed during initialization of the http server. if the file is a binary file, for example a gif-image, it might also contain zero values. therefore, the size that incl udes the http header and the data must be specified. the constant html_num_files defined in html.h represents the number of the files. in the example above, html_num_files is set to 6. same positions file names are zero terminated file names start with ?/? and can also contain paths f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter hypertext transfer protocol DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 99 the last file entry ?\r\n\r\n? in t he example must al ways be present to allow the server to send the http er ror 404 (file not found). in the case that a requested file ca nnot be found the server only finds the end of the header that is defined with ?\r\n\r\n? . the connected client is notified of the error with the common error page 404_html . the example shows that two filenames can be mapped to a same file. the files index.html and / are both mapped to index_html . on a browser requesting the def ault file by sending ? get / http/1.1 ?. ?, the index page is being sent. 6.7.3 receiving data through the post method as shown in figure 6-20. function templat e for generating dynamic content , a post method consist of two strings that need to be examined: the filename of t he originating file a string with field names and values the http server has to parse for the filenam e before exploiting the variables. furthermore, the end condi tion of the post object is the string ?refresh? that indicates t hat the originating file should be transmitted. there can be more than one end c ondition string specified in ppost_refresh . it must be assured that the correct number of end conditions is defined in http_num_refr . in the example implementation, the end c ondition is set to the string ?refresh? and the number of end conditions is set to 1 as only on e page containing post variables is realized. similar to the parsing of ht ml files, the fields to look for are defined in ppost_field and the corresponding functi on pointers are defined in ppost_fieldfunc . the name of the constant to indicate the number of fields is http_num_field . upon match of a fiel d name in the post string, the corresponding function is called. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 100 layer implementation of embetter motorola one restriction applies to this implementation: field names must be unique throughout the html project to allow parsing for the field variables. 6.8 handling of web pages the http server parses eac h file for the start tag dyn_pref and the end tag dyn_suff set in http.c . data between the tags is not being sent but examined for a valid function name. the tags can be modified but it must be ensured that they don' t match any tag defined in the html standard [w3schools, html tags, 2002] . in the current implementation the start tag is ??. if the server finds the start tag, it sends all data up to the tag and then tries to call the function that is defined between the tags. the following example shows html source code with a start and an end tag: figure 6-18. dynamic cont ent in an html page between the two tags, any name for a fu nction is allowed. but for finding out quickly the required function, the names s hould not be too long or similar. names are mapped to functions by two variables, dyn_func_names holding zero terminated strings and pdyn_func consisting of functi on pointers of the type uint8 ( *pdynfunc )( uint8 csock , uint8 *pstarttag , uint16 *pdynfuncsent ). the mapping of function names to functi ons is similar to the mapping of file names to file c onstants. function names are set in the string start tag dynamic function end tag function parameter f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter handling of web pages DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 101 dyn_func_names and must be at the same position as the corresponding function that has to be executed defi ned with a function pointer in pdyn_func . example: figure 6-19. http functi ons for dynamic content if the http server finds the function name, the function is being called as long the function returns http_dyns_progress . as soon as the function returns http_dyns_ok or the function name was not found the http server continues to transmit data after the end tag. if the function returns http_dyns_error the http server closes the connection and returns in the state to accept a new connection. a function that provides dynamic content receives three function parameters: csock : the socket of the http server that this function can use to send tcp segments pstarttag : a pointer to the start of the function name. this permits the dynamic function to exploit the values following the function name as function parameters pdynfuncsent : a pointer to a static variable that permits the function to statically store data, for exampl e its state, or the amount of data sent. this is necessary when the function generates content that requires t he sending of more than one tcp segment. a template of a function generating dy namic content presents as follows: same positions names not necessarily identical function names differ very much f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 102 layer implementation of embetter motorola figure 6-20. function template for generating dynamic content 6.9 simple mail transfer protocol 6.9.1 overview the simple mail transfer protocol (smtp) is th e protocol that handles the communication between mail serv ers and outgoing mails from a mail client to a mail server. as a client implementation, it provides an efficient means to trigger event s, alarm or alerts. 6.9.2 applications demonst rating the smtp functionality embetter implements the simple mail transport protocol in a pure client version. the reference design contains two exam ples to demonstrate the benefits of smtp: exception handling functionality to generate the content goes here data buffer for dynamic content write the generated data f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter simple mail transfer protocol DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 103 the e-mail alerter: when an o ccurrence causes an alert for embetter, the smtp cli ent is advised to conne ct to the internet service provider to send an e-ma il to the address stored as recipient for this occurrence. the ip address transmitter: it offe rs a service that allows dealing with an ip address, dynamically assigned by the isp. after connecting to the internet due to an incoming call or another event like a certain port level or ti meout, the embetter stack sends an e-mail containing a hyperlink to its current addr ess. depending on the recipient's mailbox and cell phone, this might be a short message as well. these are two provisional functi ons that have to be adapted or exchanged for new applications. howe ver, all basic ideas for using smtp for embedded devices are covered. 6.9.3 basic functi onality of the code as the smtp protocol is string ori entated, the data stream is be parsed for the beginning of the ex pected answer string re ceived from the server. having found this character, the pr ogram reads the following characters until the end of the expe cted string. after this, the socket data buffer is released and the next stri ng from the remote host can be stored at the starting address of this buffer. this helps to make the conversation more efficient. as there is only one posi tive response for every state of the implemented mail transmission, only the first num ber of an incoming string is evaluated. 6.9.4 sending an e-mail a standard conversation between t he implemented mail-client and a smtp-server is shown in figure 6-21. smtp communication between mail clie nt and mail server . f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 104 layer implementation of embetter motorola figure 6-21. smtp communication between mail client and mail server as most fields in the mail-header are optional, on ly the mail-subject, the sender and the receiver are introduc ed in order to reduce processing time. the timestamp of the mail can be included by the next smtp server. therefore, the time field is left empt y, as most microcontroller systems do not have a real time clock. 6.9.5 function calls when sending an electronic mail, the smtp-connection is not explicitly opened, but the smtp_write() function is called transmitting a pointer to the structure of the mail-information. this f unction checks the status of the internet conne ction, connects to a socket and calls the smtp_process() procedure when the connect ion to the smtp-server is established. this preserves t he application from implementing a further state machine to open or close the socket-connection. smtp_write() is called periodically and gives a negative response as long as the e-mail is not transmitted successfully. in order not to block the microcontroller, t he communication is realized in a multistage stat e machine, mapped in figure 6-22. non-blocking implementation of smtp . this finite automaton is separated into three state machines, of wh ich the first one ( smtp_stat_ ) shows the general > s: 220 abc.de smtp server ready > c: helo xyz.de. > s: 250 xyz.de., pleased to meet you > c: mail from: > s: 250 sender ok > c: rcpt to: > s: 250 recipient ok > c: rcpt to: > s: 250 recipient ok > c: data > s: 354 enter mail > c: hallo eva, hallo tom! > c: beispiel fr den mail-versand mit smtp. > c: adam > c: . > s: 250 mail accepted > c: quit > s: 221 abc.de delivering mail > s: 220 abc.de smtp server ready > c: helo xyz.de. > s: 250 xyz.de., pleased to meet you > c: mail from: > s: 250 sender ok > c: rcpt to: > s: 250 recipient ok > c: rcpt to: > s: 250 recipient ok > c: data > s: 354 enter mail > c: hallo eva, hallo tom! > c: beispiel fr den mail-versand mit smtp. > c: adam > c: . > s: 250 mail accepted > c: quit > s: 221 abc.de delivering mail f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter simple mail transfer protocol DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 105 communication state of t he smtp client. the sec ond one represents the receive states for the re ply message from the se rver, and the third one shows the particular position in the string to be transmitted. this is done because the outgoing strings are not combined before se nding, but they are sent as separate message s over the communication channel. figure 6-22. non-blocking implementation of smtp 6.9.6 number of strings sent during standard data tran smission, packets are transmitted from the client to the server. the last packet is finished wit h a single ?.? in a line. embetter smtp client transmits these packets by directly calling soc_write() . during the establishm ent, direct use of soc_write() would cause a significant overhead, as each string is composed of static cstringstate=string_stat_1 cstringstate=string_stat_2 cstringstate=string_stat_3 cstringstate=string_stat_4 cstringstate=string_stat_5 cstringstate=string_stat_6 cstringstate=string_stat_7 cstringstate=string_stat_8 rcv_stat_ idle valid ineol s e n d f i n i s h e d rcv start r c v e o l string_stat_4 string_stat_5 string_stat_6 string_stat_7 string_stat_0 string_stat_1 string_stat_2 string_stat_3 string_stat_8 string_stat_ receive 250 receive 221 header finished receive 354 dtcm head body quit disc send "data" send mail subject send mail content send quit close socket receive 250 receive 250 redy rcpt send "mail from: " send "rcpt to: " receive 220 socket connected conn1 socket successfully created sock clos create socket connect socket to smtp server communication established init reset attempt-counter idle open communication stack conn2 send "helo wait smtp_stat_ cstringstate=string_stat_0 receive 4xx receive 5xx f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 106 layer implementation of embetter motorola and dynamic contents, for exampl e ?rcpt to: eol?. therefore, smtp_send() is called in the application. smtp_send() collects the various string fragmen ts, until eol is detected or the minimum number of bytes smtp_min_len is reached. as a result, the number of tcp s egments for a complete mail is: 6.9.7 error handling in an e-mail application, the error handling is like ly to be implemented depending on the strings re ceived from the smtp server. if a ?4? is received as first value, t he client is asked to wait before trying again to transmit the string. on reception of a ?5?, the client stops the transmission. in embetter, a flag is set in order to send a standard memo to the recipient defined as smtp_rep_addr in the smtp header file. if the smtp server has accepted the me mo once, all further error reports generated on the way to t he final recipient are directed to the sender address. 6.10 udp applications low-cost microcontrollers or devices that are dime nsioned for their principal application do usually not provide the performance and memory to additionally run a complete tcp/ip protocol stack with all of its opportunities. especially saving the tcp segments for retransmissions and handling acknowledgements is often not possible caused by a lack of ram or cpu time restrictions . in these cases, the connectionless user datagr am protocol (udp) offe rs an opportunity to make use of t he internet infrastructure wit hout the need for a complete implementation of the re liable and thereby capaci ous tcp with all of its control structures. afte r a remote request for da ta, an answer datagram is sent and the datagra m information is discar ded. if the remote host tcp_tx_len subjectlen n maildatale 8 segments tcp + + = f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter udp applications DRM049 ? rev 0 designer reference manual motorola layer implementation of embetter 107 does not receive the answer, due to network problems or the microcontroller being ov erburden, he has to a sk again for the packet. thereby, all control of the communi cation is transfe rred from the low-performing microcontro ller to the by far more performing remote computer running the u dp application. this applicat ion has to check, if all required packets arrive, and it has to prepare the raw data for a suitable presentation. figure 6-23. proprietary udp client software f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
layer implementation of embetter designer reference manual DRM049 ? rev 0 108 layer implementation of embetter motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola test environment 109 designer reference manual ? DRM049 section 7. test environment 7.1 alarm control pa nel reference design together with motorola applicati on engineers, elektronikladen has developed a new alarm control panel reference design (acprd), which is based on a motorola hcs12 microc ontroller. the panel can read in a jog-dial input, 4 push but tons or 3 inputs for curr ent controlled circuits. outputs are realized fo r a sound module, for si rens or lights and for alarms. bidirectional communica tion can be handled via an rs232-interface, as well as with an interface for can- or lin-buses. the presented protocol suit e embetter realizes t he communication with the internet. therefore, a socket m odem (sc336h1 from multi-tech) is built-in, which makes the internet connectivity as easy as plugging the phone jack. the 240 x 64 pixel lc-display ea ses controlling and debugging. 7.2 setup of the demonstratio n and development environment the software was originally de veloped using a m68evb912dp256 and an external zyxel pc modem. in order to use the m68evb912dp256 in the demonstration and devel opment setup, some modifications have to be implemented in the orig inal evaluation board: the mc9s12dp256 provides two serial communication interfaces: sci0 and sci1. sci0 was used as modem in terface. since sci0 delivers only the tx data and rx data signals, port a wa s configured as general purpose i/o to receive t he signal cd respectively dcd (data carrier detect) and to drive the signal dtr (data terminal ready) for full communication to the m odem. an additional rs232 le vel shifter circuit was mounted on the eval uation board to drive sc i0 and provide a fully specified rs232 interface to the modem. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
test environment designer reference manual DRM049 ? rev 0 110 test environment motorola the second serial communication inte rface sci1 of t he mc9s12dp256 is used in conjunction with the rs 232 level shifter which is already mounted on the m68evb9 12dp256 evaluation boar d. on sci1 some debug information is delivered to a standard terminal. this additional debug information greatly simpli fies the process of software development. figure 7-1. test environment for the embetter suite furthermore, some smaller changes have to be made to the used software: the delay function has to be adapted to the clock of the evaluation board m68evb912dp256, f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
test environment setup of the demonstration and development environment DRM049 ? rev 0 designer reference manual motorola test environment 111 all interrupt vectors of the mc 9s12dp256 have to be pointed to a fix jumping table in ram so that the software could be loaded into ram and the flash rom need to be programmed only once, all modem settings and command s have to be adjusted to the zyxel standard [w8]. on the acp reference des ign board the m odem is already on the board. it is a socket modem sc336h1 from multi-tech. the socket modem is connected to the sci1 of the mc9s12dp256. port m pin 3 (pm3) is used as output for dtr and port m pin 2 is used as input for dcd. for debugging purposes, debug messages were extensively included in the source code. an example is shown in figure 7-2. information provided on debug interface . however, on the acprd sci1 is connected to a lin transce iver and is therefore no t available for a debug interface. figure 7-2. information provided on debug interface f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
test environment designer reference manual DRM049 ? rev 0 112 test environment motorola 7.3 simulation environment 7.3.1 overview the full chip simulation (fcs), in cluded in metrower ks codewarrior 3.0, is a high performi ng tool for developing and te sting software for the hcs12 cpu. it allows simulation the microcontroller as a whole including for example the pin signa ls and cpu cycles. the different components of the simu lator/debugger enable very detailed control, which would not be possible using an external microcontroller connected via a target interface. thi s chapter describes the se tup of the system with the embetter protocol suite for fcs. furthermore , some of the components included in metrowerks c odewarrior are presented with their use for debugging the internet connectivity. 7.3.2 settings for the embetter on the full chip simulation target running an internet protocol suite on a simulator does not seem to make much sense, as nobody wi ll have the time to simulate the whole internet with its services and transmission e rrors on his computer. therefore, the simulated microcontrolle r is to be connected to one of the computer's interfaces in order to communicate with real internet devices. in the codewarrior's simulator/ debugger for hc( s)08 and hc(s)12 microcontrollers, the terminal component does this by redirecting the simulated microcontrol ler's serial communica tion interface to the computer uart (see figure 7-3. settings for the terminal ). the external modem connected to the selected uart establishes a connection between the simulated microcontroller and the internet. to make the system wo rk properly, a few points are important: the terminal has to be open with the ?u se serial port? and ?redirect simulator sci0. ..? options selected ( figure 7-3. settings for the terminal ). f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
test environment simulation environment DRM049 ? rev 0 designer reference manual motorola test environment 113 the sci for the modem connectio n must be sci0. the uart of the simulating computer can fr eely be chosen. when the modem answers to the simulator, the acti vity can be checked by observing the leds of the modem . additionally the traf fic may be logged in the command window. the baud rates of the terminal and the simulated sci may not match due to a very high or ve ry low computer performance. running the system with different combinations should solve this problem. after checking the correc t modem initialization (see figure 7-4. data in the command window ), the ?show protocol? option should be turned of to preserve performance. the rs232 interface of an evalua tion board is usua lly meant to connect to a terminal. therefore, attaching a m odem requires a null modem cable. when simulating the micr ocontroller on a pc, the modem is linked with a usual serial cable. during the implementation of t he fcs, focus was laid upon cycle accuracy. as the simulation of parallel processe s can take an important amount of time on slow computers, the simulated cpu might be by far slower than r eal hardware. this can lead to problems during the ppp negotiation, as the provided characters may not be recognized correctly. further on, when sending a web page to a connected client, the br owser can stop communicating, assuming the connection to be interrupted. th erefore, the simulating computer should pr ovide sufficie nt resources (frequency of about 2ghz, memory of at least 256mb) and should not run many parallel processes. 7.3.3 useful debugging components 7.3.3.1 terminal during the simulation of the embetter protocol suite, the terminal connects the simulated microcontrolle r with the external modem. having enabled the ?show protocol? option, the characters received and transmitted can be observed in the command window. this can f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
test environment designer reference manual DRM049 ? rev 0 114 test environment motorola obviously not replace a t ool for inspecting internet packets, but as these tools commonly do not pr ovide information about raw sci data, the terminal can fill this gap as already the modem initialization strings can be checked for the modem's answers ( figure 7-4. data in the command window ). figure 7-3. settings for the terminal figure 7-4. data in the command window 7.3.3.2 inspector the inspector window (see figure 7-5. metrowerks inspector component ) informs about the current st ate of the micr ocontroller, f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
test environment simulation environment DRM049 ? rev 0 designer reference manual motorola test environment 115 including pin values, stack informati on, pending interrupts, and events. this tool can be of great value if due to a programming error different microcontroller modules try to c ontrol the same pin or expected interrupts do not occur. furthermore , a stack overflow may be detected or pointers with wrong addresses. figure 7-5. metrower ks inspector component 7.3.3.3 profiler the profiler is very useful when mult iple applications run in parallel on a microcontroller with unexpected beha vior. this tool informs about the percentage of cpu usage for the different modu les and functions. this allows observing, if certain procedur es block the cpu or if an interrupt service routine is entered exce ssively often or not at all. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
test environment designer reference manual DRM049 ? rev 0 116 test environment motorola figure 7-6. profiler window 7.3.3.4 coverage the coverage component (see figure 7-7. code coverage information ) informs about the lines in the source code that have been executed. additionally to the ?marks? in the so urce window showing, which lines are not compiled at all, this gives hints about programmed branches that have not been taken or functions not called up to a moment. f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
test environment simulation environment DRM049 ? rev 0 designer reference manual motorola test environment 117 figure 7-7. code coverage information f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
test environment designer reference manual DRM049 ? rev 0 118 test environment motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
DRM049 ? rev 0 designer reference manual motorola sources 119 designer reference manual ? DRM049 section 8. sources 8.1 web resources [w1] http://www.arcor.de [w2] http://www.ba- loerrach.de/stzedn [w3] http://www.freenet.de [w4] information a bout codewarriortm, updates, demo keys and demo downloads: http://www.metrowerks.com [w5] motorola micr ocontroller home page: http://www.motorola.com/mcu [w6] http://germany.m otorola.com/pressetool/presse.asp?details =true&all=true&msgid={4ae2d feb-43f0-4a3b-9cc6-ac2e7b 5d2925} [w7] http://www.elektronikladen.de [w8] zyxel inc., ?zyx el u-1496 series modems user's manual?, zyxel communications corp., 2001, ftp://ftp.europe.zyxel.com /u1496s/document/u1496s_v1 _usersguide.pdf. [w9] statistisches bundesamt: b udget and equipment of households, federal www.destatis.de/basis/e/evs/ budgtab2.htm, 9/26/2003 [w10] http://www.vpi-initiative.com [w11] rfcs of ietf, available at many sites, for example http://www.ietf.org/rfc [w12] crystal cs8900; f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
sources designer reference manual DRM049 ? rev 0 120 sources motorola [w13] tlc networks, plotted graphs on advertised window sizes 2001, http://tstat.tlc.polito.it /tsol/main.php, 26/09/2003 8.2 literature [1] carlson, j. ?ppp desi gn, implementation, and debugging?, addison-we sley 2000, isbn 0 201-70053-0. [2] comer, d., ?interne tworking with tcp/ip vol. 1: principles, protocols, and architec ture?, 4. auflage, pr entice hall 2000, isbn 0-13-018380-6. [3] kreidl, h., kupris, g., thamm, o., ?microcontroller-design - hardware- und software-entwi cklung mit dem 68hc12/hcs12?, carl hanser verlag mnchen wien 2003, isbn 3-446-21775-4. [4] kupris, g., kreidl, h., lill, d., sikora, a ., ?implementierung von internetdiensten auf ei nem mikrocontroller am beispiel eines hcs12 in einer hausberwac hungszentrale?, embedded world 2003 conference, 18.-20.2.2 003, nrnberg, s. 805-813. [5] kupris, g., kreidl , h., gutknecht, n., lill, d., braun, n., ?implementation of a u dp/ip (user datagram protocol / internet protocol) stack on hcs12 mikr ocontrollers?, motorola application note an2304/d 7/2002. [6] sikora, a., brgger, p., ?virtual private infrastructure - an industry initiative for unifi ed and secure web control with embedded devices?, 9th ieee international conference on emerging technologies and facto ry automation (etfa 2003), lisbon, portugal, 16- 19 september 2003. [7] sikora, a., ?embedded applik ationen im internet?, teil 1: ?bersicht ber vor- und na chteile von vernetzten anwendungen?, elektronik 22/ 2000, s.90 - 102, teil 2: ?implementierungen?, elektr onik 23/2000, s.164 - 169. [8] stevens, w.r. ?tcp/ip illust rated volume 1 - the protocols?, addison-wesley, 1994, isbn 0-201-63346-9; stev ens, w.r., wright, g.r., ?tcp/ip illustrate d volume 2 - the implementation?, f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
sources literature DRM049 ? rev 0 designer reference manual motorola sources 121 addison-wesley, 1995, isbn 0-201-63354-x; stevens, w.r. ?tcp/ip illustrated volume 3 - tcp for transactions, http, nntp? [9] tanenbaum, a., ?com puternetzwerke?, 3rd ed., pearson studium, 2000, isbn 3-8273-7011-6 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
sources designer reference manual DRM049 ? rev 0 122 sources motorola f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .
how to reach us: usa/europe/locations not listed: motorola literature distribution; p.o. box 5405, denver, colorado 80217 1-303-675-2140 or 1-800-441-2447 japan: motorola japan ltd.; sps, technical information center, 3-20-1, minami-azabu minato-ku, tokyo 106-8573 japan 81-3-3440-3569 asia/pacific: motorola semiconductors h.k. ltd.; silicon harbour centre, 2 dai king street, tai po industrial estate, tai po, n.t., hong kong 852-26668334 technical information center: 1-800-521-6274 home page: http://motorola.com/semiconductors information in this document is provided solely to enable system and software implementers to use motorola products. there are no express or implied copyright licenses granted hereunder to design or fabricate any integrated circuits or integrated circuits based on the information in this document. motorola reserves the right to make changes without further notice to any products herein. motorola makes no warranty, representation or guarantee regarding the suitability of its products for any particular purpose, nor does motorola assume any liability arising out of the app lication or use of any product or circuit, and specifically disclaims any and all liability, including withou t limitation consequential or incidental damages. ?typical? parameters which may be provided in motorola data sheets and/or specifications can and do vary in different applications and actual performance may vary over time. all operating parameters, including ?typicals? must be validated for each customer application by customer?s technical experts. motorola does not convey any license under its patent rights nor the rights of others. motorola products are not desig ned, intended, or authorized for use as components in systems intended for surgical implant into the body, or other applications intended to support or sustain life, or for any other application in which the failure of the motorola product could create a situation where personal injury or death may occur. should buyer purchase or use motorola products for any such unintended or unauthorized application, buyer shall indemnify and hold motorola and its officers, employees, subsidiaries, affiliates, and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges that motorola was negligent regarding the design or manufacture of the part. motorola and the stylized m logo are registered in the u.s. patent and trademark office. digital dna is a trademark of motorola, inc. all other product or service names are the property of their respective owners. motorola, inc. is an equal opportunity/affirmative action employer. ? motorola, inc. 2003 DRM049 f r e e s c a l e s e m i c o n d u c t o r , i freescale semiconductor, inc. f o r m o r e i n f o r m a t i o n o n t h i s p r o d u c t , g o t o : w w w . f r e e s c a l e . c o m n c . . .

▲Up To Search▲

Price & Availability of DRM049

	To Download DRM049 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .