main_page.h

00001 /**
00002  * @defgroup lwip lwIP
00003  *
00004  * @defgroup infrastructure Infrastructure
00005  * 
00006  * @defgroup api APIs
00007  * lwIP provides three Application Program's Interfaces (APIs) for programs
00008  * to use for communication with the TCP/IP code:
00009  * - low-level "core" / "callback" or @ref callbackstyle_api.
00010  * - higher-level @ref sequential_api.
00011  * - BSD-style @ref socket.
00012  * 
00013  * The raw TCP/IP interface allows the application program to integrate
00014  * better with the TCP/IP code. Program execution is event based by
00015  * having callback functions being called from within the TCP/IP
00016  * code. The TCP/IP code and the application program both run in the same
00017  * thread. The sequential API has a much higher overhead and is not very
00018  * well suited for small systems since it forces a multithreaded paradigm
00019  * on the application.
00020  * 
00021  * The raw TCP/IP interface is not only faster in terms of code execution
00022  * time but is also less memory intensive. The drawback is that program
00023  * development is somewhat harder and application programs written for
00024  * the raw TCP/IP interface are more difficult to understand. Still, this
00025  * is the preferred way of writing applications that should be small in
00026  * code size and memory usage.
00027  * 
00028  * All APIs can be used simultaneously by different application
00029  * programs. In fact, the sequential API is implemented as an application
00030  * program using the raw TCP/IP interface.
00031  * 
00032  * Do not confuse the lwIP raw API with raw Ethernet or IP sockets.
00033  * The former is a way of interfacing the lwIP network stack (including
00034  * TCP and UDP), the latter refers to processing raw Ethernet or IP data
00035  * instead of TCP connections or UDP packets.
00036  * 
00037  * Raw API applications may never block since all packet processing
00038  * (input and output) as well as timer processing (TCP mainly) is done
00039  * in a single execution context.
00040  *
00041  * @defgroup callbackstyle_api "raw" APIs
00042  * @ingroup api
00043  * Non thread-safe APIs, callback style for maximum performance and minimum
00044  * memory footprint.
00045  * Program execution is driven by callbacks functions, which are then
00046  * invoked by the lwIP core when activity related to that application
00047  * occurs. A particular application may register to be notified via a
00048  * callback function for events such as incoming data available, outgoing
00049  * data sent, error notifications, poll timer expiration, connection
00050  * closed, etc. An application can provide a callback function to perform
00051  * processing for any or all of these events. Each callback is an ordinary
00052  * C function that is called from within the TCP/IP code. Every callback
00053  * function is passed the current TCP or UDP connection state as an
00054  * argument. Also, in order to be able to keep program specific state,
00055  * the callback functions are called with a program specified argument
00056  * that is independent of the TCP/IP state.
00057  * The raw API (sometimes called native API) is an event-driven API designed
00058  * to be used without an operating system that implements zero-copy send and
00059  * receive. This API is also used by the core stack for interaction between
00060  * the various protocols. It is the only API available when running lwIP
00061  * without an operating system.
00062  * 
00063  * @defgroup sequential_api Sequential-style APIs
00064  * @ingroup api
00065  * Sequential-style APIs, blocking functions. More overhead, but can be called
00066  * from any thread except TCPIP thread.
00067  * The sequential API provides a way for ordinary, sequential, programs
00068  * to use the lwIP stack. It is quite similar to the BSD socket API. The
00069  * model of execution is based on the blocking open-read-write-close
00070  * paradigm. Since the TCP/IP stack is event based by nature, the TCP/IP
00071  * code and the application program must reside in different execution
00072  * contexts (threads).
00073  * 
00074  * @defgroup socket Socket API
00075  * @ingroup api
00076  * BSD-style socket API.\n
00077  * Thread-safe, to be called from non-TCPIP threads only.\n
00078  * Can be activated by defining @ref LWIP_SOCKET to 1.\n
00079  * Header is in posix/sys/socket.h\n
00080  * The socket API is a compatibility API for existing applications,
00081  * currently it is built on top of the sequential API. It is meant to
00082  * provide all functions needed to run socket API applications running
00083  * on other platforms (e.g. unix / windows etc.). However, due to limitations
00084  * in the specification of this API, there might be incompatibilities
00085  * that require small modifications of existing programs.
00086  * 
00087  * @defgroup netifs NETIFs
00088  * 
00089  * @defgroup apps Applications
00090  */
00091 
00092 /**
00093  * @mainpage Overview
00094  * @verbinclude "README"
00095  */
00096 
00097 /**
00098  * @page upgrading Upgrading
00099  * @verbinclude "UPGRADING"
00100  */
00101 
00102 /**
00103  * @page changelog Changelog
00104  *
00105  * 2.1.0
00106  * -----
00107  * * Support TLS via new @ref altcp_api connection API (https, smtps, mqtt over TLS)
00108  * * Switch to cmake as the main build system (Makefile file lists are still
00109  *   maintained for now)
00110  * * Improve IPv6 support: support address scopes, support stateless DHCPv6, bugfixes
00111  * * Add debug helper asserts to ensure threading/locking requirements are met
00112  * * Add sys_mbox_trypost_fromisr() and tcpip_callbackmsg_trycallback_fromisr()
00113  *   (for FreeRTOS, mainly)
00114  * * socket API: support poll(), sendmsg() and recvmsg(); fix problems on close
00115  * 
00116  * Detailed Changelog
00117  * ------------------
00118  * @verbinclude "CHANGELOG"
00119  */
00120 
00121 /**
00122  * @page contrib How to contribute to lwIP
00123  * @verbinclude "contrib.txt"
00124  */
00125 
00126 /**
00127  * @page pitfalls Common pitfalls
00128  *
00129  * Multiple Execution Contexts in lwIP code
00130  * ========================================
00131  *
00132  * The most common source of lwIP problems is to have multiple execution contexts
00133  * inside the lwIP code.
00134  * 
00135  * lwIP can be used in two basic modes: @ref lwip_nosys (no OS/RTOS 
00136  * running on target system) or @ref lwip_os (there is an OS running
00137  * on the target system).
00138  * 
00139  * See also: @ref multithreading (especially the part about @ref LWIP_ASSERT_CORE_LOCKED()!)
00140  *
00141  * Mainloop Mode
00142  * -------------
00143  * In mainloop mode, only @ref callbackstyle_api can be used.
00144  * The user has two possibilities to ensure there is only one 
00145  * exection context at a time in lwIP:
00146  *
00147  * 1) Deliver RX ethernet packets directly in interrupt context to lwIP
00148  *    by calling netif->input directly in interrupt. This implies all lwIP 
00149  *    callback functions are called in IRQ context, which may cause further
00150  *    problems in application code: IRQ is blocked for a long time, multiple
00151  *    execution contexts in application code etc. When the application wants
00152  *    to call lwIP, it only needs to disable interrupts during the call.
00153  *    If timers are involved, even more locking code is needed to lock out
00154  *    timer IRQ and ethernet IRQ from each other, assuming these may be nested.
00155  *
00156  * 2) Run lwIP in a mainloop. There is example code here: @ref lwip_nosys.
00157  *    lwIP is _ONLY_ called from mainloop callstacks here. The ethernet IRQ
00158  *    has to put received telegrams into a queue which is polled in the
00159  *    mainloop. Ensure lwIP is _NEVER_ called from an interrupt, e.g.
00160  *    some SPI IRQ wants to forward data to udp_send() or tcp_write()!
00161  *
00162  * OS Mode
00163  * -------
00164  * In OS mode, @ref callbackstyle_api AND @ref sequential_api can be used.
00165  * @ref sequential_api are designed to be called from threads other than
00166  * the TCPIP thread, so there is nothing to consider here.
00167  * But @ref callbackstyle_api functions must _ONLY_ be called from
00168  * TCPIP thread. It is a common error to call these from other threads
00169  * or from IRQ contexts. ​Ethernet RX needs to deliver incoming packets
00170  * in the correct way by sending a message to TCPIP thread, this is
00171  * implemented in tcpip_input().​​
00172  * Again, ensure lwIP is _NEVER_ called from an interrupt, e.g.
00173  * some SPI IRQ wants to forward data to udp_send() or tcp_write()!
00174  * 
00175  * 1) tcpip_callback() can be used get called back from TCPIP thread,
00176  *    it is safe to call any @ref callbackstyle_api from there.
00177  *
00178  * 2) Use @ref LWIP_TCPIP_CORE_LOCKING. All @ref callbackstyle_api
00179  *    functions can be called when lwIP core lock is aquired, see
00180  *    @ref LOCK_TCPIP_CORE() and @ref UNLOCK_TCPIP_CORE().
00181  *    These macros cannot be used in an interrupt context!
00182  *    Note the OS must correctly handle priority inversion for this.
00183  *
00184  * Cache / DMA issues
00185  * ==================
00186  *
00187  * DMA-capable ethernet hardware and zero-copy RX
00188  * ----------------------------------------------
00189  * 
00190  * lwIP changes the content of RECEIVED pbufs in the TCP code path.
00191  * This implies one or more cacheline(s) of the RX pbuf become dirty
00192  * and need to be flushed before the memory is handed over to the
00193  * DMA ethernet hardware for the next telegram to be received.
00194  * See http://lists.nongnu.org/archive/html/lwip-devel/2017-12/msg00070.html
00195  * for a more detailed explanation.
00196  * Also keep in mind the user application may also write into pbufs,
00197  * so it is generally a bug not to flush the data cache before handing
00198  * a buffer to DMA hardware.
00199  *
00200  * DMA-capable ethernet hardware and cacheline alignment
00201  * -----------------------------------------------------
00202  * Nice description about DMA capable hardware and buffer handling:
00203  * http://www.pebblebay.com/a-guide-to-using-direct-memory-access-in-embedded-systems-part-two/
00204  * Read especially sections "Cache coherency" and "Buffer alignment".
00205  */
00206 
00207 /**
00208  * @page bugs Reporting bugs
00209  * Please report bugs in the lwIP bug tracker at savannah.\n
00210  * BEFORE submitting, please check if the bug has already been reported!\n
00211  * https://savannah.nongnu.org/bugs/?group=lwip
00212  */
00213 
00214 /**
00215  * @page zerocopyrx Zero-copy RX
00216  * The following code is an example for zero-copy RX ethernet driver:
00217  * @include ZeroCopyRx.c
00218  */
00219 
00220 /**
00221  * @defgroup lwip_nosys Mainloop mode ("NO_SYS")
00222  * @ingroup lwip
00223  * Use this mode if you do not run an OS on your system. \#define NO_SYS to 1.
00224  * Feed incoming packets to netif->input(pbuf, netif) function from mainloop,
00225  * *not* *from* *interrupt* *context*. You can allocate a @ref pbuf in interrupt
00226  * context and put them into a queue which is processed from mainloop.\n
00227  * Call sys_check_timeouts() periodically in the mainloop.\n
00228  * Porting: implement all functions in @ref sys_time, @ref sys_prot and 
00229  * @ref compiler_abstraction.\n
00230  * You can only use @ref callbackstyle_api in this mode.\n
00231  * Sample code:\n
00232  * @include NO_SYS_SampleCode.c
00233  */
00234 
00235 /**
00236  * @defgroup lwip_os OS mode (TCPIP thread)
00237  * @ingroup lwip
00238  * Use this mode if you run an OS on your system. It is recommended to
00239  * use an RTOS that correctly handles priority inversion and
00240  * to use @ref LWIP_TCPIP_CORE_LOCKING.\n
00241  * Porting: implement all functions in @ref sys_layer.\n
00242  * You can use @ref callbackstyle_api together with @ref tcpip_callback,
00243  * and all @ref sequential_api.
00244  */
00245 
00246 /**
00247  * @page sys_init System initalization
00248 A truly complete and generic sequence for initializing the lwIP stack
00249 cannot be given because it depends on additional initializations for
00250 your runtime environment (e.g. timers).
00251 
00252 We can give you some idea on how to proceed when using the raw API.
00253 We assume a configuration using a single Ethernet netif and the
00254 UDP and TCP transport layers, IPv4 and the DHCP client.
00255 
00256 Call these functions in the order of appearance:
00257 
00258 - lwip_init(): Initialize the lwIP stack and all of its subsystems.
00259 
00260 - netif_add(struct netif *netif, ...):
00261   Adds your network interface to the netif_list. Allocate a struct
00262   netif and pass a pointer to this structure as the first argument.
00263   Give pointers to cleared ip_addr structures when using DHCP,
00264   or fill them with sane numbers otherwise. The state pointer may be NULL.
00265 
00266   The init function pointer must point to a initialization function for
00267   your Ethernet netif interface. The following code illustrates its use.
00268   
00269 @code{.c}
00270   err_t netif_if_init(struct netif *netif)
00271   {
00272     u8_t i;
00273     
00274     for (i = 0; i < ETHARP_HWADDR_LEN; i++) {
00275       netif->hwaddr[i] = some_eth_addr[i];
00276     }
00277     init_my_eth_device();
00278     return ERR_OK;
00279   }
00280 @endcode
00281   
00282   For Ethernet drivers, the input function pointer must point to the lwIP
00283   function ethernet_input() declared in "netif/etharp.h". Other drivers
00284   must use ip_input() declared in "lwip/ip.h".
00285   
00286 - netif_set_default(struct netif *netif)
00287   Registers the default network interface.
00288 
00289 - netif_set_link_up(struct netif *netif)
00290   This is the hardware link state; e.g. whether cable is plugged for wired
00291   Ethernet interface. This function must be called even if you don't know
00292   the current state. Having link up and link down events is optional but
00293   DHCP and IPv6 discover benefit well from those events.
00294 
00295 - netif_set_up(struct netif *netif)
00296   This is the administrative (= software) state of the netif, when the
00297   netif is fully configured this function must be called.
00298 
00299 - dhcp_start(struct netif *netif)
00300   Creates a new DHCP client for this interface on the first call.
00301   You can peek in the netif->dhcp struct for the actual DHCP status.
00302 
00303 - sys_check_timeouts()
00304   When the system is running, you have to periodically call
00305   sys_check_timeouts() which will handle all timers for all protocols in
00306   the stack; add this to your main loop or equivalent.
00307  */
00308 
00309 /**
00310  * @page multithreading Multithreading
00311  * lwIP started targeting single-threaded environments. When adding multi-
00312  * threading support, instead of making the core thread-safe, another
00313  * approach was chosen: there is one main thread running the lwIP core
00314  * (also known as the "tcpip_thread"). When running in a multithreaded
00315  * environment, raw API functions MUST only be called from the core thread
00316  * since raw API functions are not protected from concurrent access (aside
00317  * from pbuf- and memory management functions). Application threads using
00318  * the sequential- or socket API communicate with this main thread through
00319  * message passing.
00320  * 
00321  * As such, the list of functions that may be called from
00322  * other threads or an ISR is very limited! Only functions
00323  * from these API header files are thread-safe:
00324  * - api.h
00325  * - netbuf.h
00326  * - netdb.h
00327  * - netifapi.h
00328  * - pppapi.h
00329  * - sockets.h
00330  * - sys.h
00331  * 
00332  * Additionaly, memory (de-)allocation functions may be
00333  * called from multiple threads (not ISR!) with NO_SYS=0
00334  * since they are protected by @ref SYS_LIGHTWEIGHT_PROT and/or
00335  * semaphores.
00336  * 
00337  * Netconn or Socket API functions are thread safe against the
00338  * core thread but they are not reentrant at the control block
00339  * granularity level. That is, a UDP or TCP control block must
00340  * not be shared among multiple threads without proper locking.
00341  * 
00342  * If @ref SYS_LIGHTWEIGHT_PROT is set to 1 and
00343  * @ref LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT is set to 1,
00344  * pbuf_free() may also be called from another thread or
00345  * an ISR (since only then, mem_free - for PBUF_RAM - may
00346  * be called from an ISR: otherwise, the HEAP is only
00347  * protected by semaphores).
00348  * 
00349  * How to get threading done right
00350  * -------------------------------
00351  * 
00352  * It is strongly recommended to implement the LWIP_ASSERT_CORE_LOCKED()
00353  * macro in an application that uses multithreading. lwIP code has
00354  * several places where a check for a correct thread context is
00355  * implemented which greatly helps the user to get threading done right.
00356  * See the example sys_arch.c files in unix and Win32 port 
00357  * in the contrib repository.
00358  * 
00359  * In short: Copy the functions sys_mark_tcpip_thread() and 
00360  * sys_check_core_locking() to your port and modify them to work with your OS.
00361  * Then let @ref LWIP_ASSERT_CORE_LOCKED() and @ref LWIP_MARK_TCPIP_THREAD()
00362  * point to these functions.
00363  * 
00364  * If you use @ref LWIP_TCPIP_CORE_LOCKING, you also need to copy and adapt
00365  * the functions sys_lock_tcpip_core() and sys_unlock_tcpip_core().
00366  * Let @ref LOCK_TCPIP_CORE() and @ref UNLOCK_TCPIP_CORE() point 
00367  * to these functions. 
00368  */
00369 
00370 /**
00371  * @page optimization Optimization hints
00372 The first thing you want to optimize is the lwip_standard_checksum()
00373 routine from src/core/inet.c. You can override this standard
00374 function with the \#define LWIP_CHKSUM your_checksum_routine().
00375 
00376 There are C examples given in inet.c or you might want to
00377 craft an assembly function for this. RFC1071 is a good
00378 introduction to this subject.
00379 
00380 Other significant improvements can be made by supplying
00381 assembly or inline replacements for htons() and htonl()
00382 if you're using a little-endian architecture.
00383 \#define lwip_htons(x) your_htons()
00384 \#define lwip_htonl(x) your_htonl()
00385 If you \#define them to htons() and htonl(), you should
00386 \#define LWIP_DONT_PROVIDE_BYTEORDER_FUNCTIONS to prevent lwIP from
00387 defining htonx / ntohx compatibility macros.
00388 
00389 Check your network interface driver if it reads at
00390 a higher speed than the maximum wire-speed. If the
00391 hardware isn't serviced frequently and fast enough
00392 buffer overflows are likely to occur.
00393 
00394 E.g. when using the cs8900 driver, call cs8900if_service(ethif)
00395 as frequently as possible. When using an RTOS let the cs8900 interrupt
00396 wake a high priority task that services your driver using a binary
00397 semaphore or event flag. Some drivers might allow additional tuning
00398 to match your application and network.
00399 
00400 For a production release it is recommended to set LWIP_STATS to 0.
00401 Note that speed performance isn't influenced much by simply setting
00402 high values to the memory options.
00403  */