Navigation bar
  Start Previous page  4 of 35  Next page End Home  1 2 3 4 5 6 7 8 9 10 11 12 13 14  

Embedded Web Server for the CR16
National Semiconductor
Jeff Wright
The decision as to which strategy to adopt will generally lie along the vector sum of the two
orthogonal vectors of price and performance.  That is, increasing levels of Internet
“interoperability” will generally come with increased cost.  Simply put, what Internet communication
capabilities must your application possess - and just how much are you willing to pay for it.   
At one end of the scale lay both the full-featured stacks offered by many RTOS vendors and the
all-inclusive devices offered by the likes of NETsilicon and Seiko.  Applications requiring a fully
RFC-compliant implementation, or those needing an “industry standard” API (whatever that means),
may opt for either of these solutions.  If your application’s resources (i.e. RAM, ROM, and HP -
horsepower) are limitless (or thereabouts), licensing networking software from a third party is an
excellent choice.  On the other hand, if your microcontroller’s resources preclude using one of
these third party stacks, but you nonetheless need a high level of Internet interoperability,
external TCP/IP devices like Seiko’s S-7600A or NETsilicon’s Net+ARM are attractive solutions. 
Both of these options offload the engineer the onerous task of becoming intimately familiar with
the multifaceted and sundry networking issues he or she would otherwise be required to master.  
However, there are a couple of issues you may need to consider when evaluating either of these
Often, many of the features included in these stacks to ensure full compliance with the
RFCs - are simply not required in a typical embedded environment.  It is this fact that
renders many of these prohibitively large for the typical embedded application.  While
understandably seeking to closely comply with the spirit of the RFCs, this usually results in
an implementation whose size and appetite for RAM is excessive. 
A close examination of the capabilities of some of the external devices, Seiko’s S-7600A
TCP/IP device for example, reveals many areas on noncompliance with the specifications. 
For example, despite the fact that all IP’s are required to support fragmented datagrams,
Seiko’s device does not do so.  But once again, this feature is almost never required in an
embedded application.
Conversely, at the bottom end of this scale lay the many applications lacking the resources, budget,
or the need to speak TCP, but nonetheless need some limited form of connectivity.  These
applications would be well served by options 3 or 4 – either writing your own functional subset of
TCP/IP, or adopting an integrated, proprietary, “lightweight”, non-TCP protocol.  EmWare offers
such a solution.  EmWare’s approach is at once adequate and appropriate for many of these low-end
applications. The only real drawbacks to such an approach are:
Similar to the full-blown stacks, you must license the non-standard, proprietary
communication kernel…
Direct Internet connectivity is not possible.  Your application accesses the Internet via a
Gateway device (PC).
Nevertheless, for many low-end applications these objections may not be relevant.  Often a low-end
application requires only the intermittent transfer of small amounts of control data and has no need
to speak directly with an Internet client or server.  In these cases, it makes perfect sense to adopt
an EmWare strategy.  (Actually, the User Datagram Protocol (UDP) was developed for just this White Papers Previous page Top Next page