NVM OTP NeoBit in Maxchip (180nm, 160nm, 150nm, 110nm, 90nm, 80nm)
Microcontroller Applications -> Net-linking MCUs requires trade-offs
Net-linking MCUs requires trade-offs
By Rene Trenado, Applications Engineer, Motorola Semiconductor, Tijuana, Mexico, EE Times
May 21, 2001 (2:16 p.m. EST)
URL: http://www.eetimes.com/story/OEG20010521S0062
The Internet is entering a new era. It is going to become a part of our everyday life through the ordinary, previously unconnected devices that surround us at home, at work or in our automobiles.
Unfortunately, for most electronic devices, implementing the technology to achieve this ubiquitous connectivity based on open Internet standards doesn't come easily. For instance, most household appliances are based on very-low-cost 8-bit microcontroller technology and chances are that the host microcontroller includes neither a network port nor the hardware resources to support TCP/IP and other Internet protocols without disrupting their primary function.
Implementing an entire Internet communications stack requires significant memory and processing resources from the microcontroller-based system. In most cases, adding those resources to the system surpasses the cost and viability of the main reason why the system was conceived.
However , different techniques to Web-enable devices have come to life recently: from implementations of limited TCP/IP functionality in resource-constrained systems, to single-chip stacks, to device object servers. Each method has its own advantages and disadvantages.
Our experience is that even a small resource-constrained 8-bit microcontroller can be connected to the Internet and achieve full connectivity with no more memory than is available on a microcontroller such as the MC68-HC908GP32. With the right mix of C-friendly instructions and peripheral functions, it is possible with such a controller to implement one of the most popular and accepted Internet protocols-the point-to-point protocol (PPP)-and use it to exchange UDP/IP (User Datagram Protocol/Internet Protocol) data with other hosts on the Internet in no more than 6,310 bytes of C code, 230 bytes in RAM and 6,080 bytes on ROM.
In our implementation, the program has been divided into a series of C modules. The main C modules include Main .C, CommDrv.C, ModemDrv.C, PPP.C, SLIP.C, IP.C, UDP.C and ICMP.C. There's also one miscellaneous C module designated Delay.C.
Code reuse, borrowing and expandability are the main intention for such modularity, so M68HC08 programmers can borrow or modify the source code or both to meet specific application needs for other members of the M68HC08 family of microcontrollers. Or they can build a set of libraries and features to be integrated in future applications in the form of object code to be linked during the development process.
Datagram packets
Contained in IP.C, the Internet Protocol defines datagram packets or blocks of data plus an IP header added that conforms the fundamental units of Internet communication. The header contains the numerical address of both the source and destination devices connected to the Internet, types of addresses that are often referred to as IP addresses. Such addresses uniquely identify each host on the Internet and are used by routers to direct the datagrams to their destinations. Often, routers do not care about the payload inside the datagram since their job is to route the datagram to its destination as fast as possible.
A complete IP implementation should normally include features to support fragmentation and reassembly. However, implementation of such features requires more CPU bandwidth and more memory resources in RAM and ROM than are possible in an 8-bit microcontroller, not to mention the complexity it adds to the software implementation. That's why we did not implement either function in our software stack. If for any reason the remote computer sends a fragmented packet to the M68HC08, the PPP will reject it and ignore it.
The IP protocol implements a mechanism to remove old datagrams from the network. On each header of an IP packet, an 8-bit-long time-to-live field indicates the maximum number of routers that this packet must travel on to reach its destination before it is discarded. This is because unroutable packets cou ld be bouncing all over the Internet, forever eating valuable bandwidth.
Contained in the UDP.C module is the code for the User Datagram Protocol, which can be thought of as an application interface to IP since applications never use IP directly. The UDP layer can be regarded as extremely thin, with 8 bytes of header. Consequently, it has low overhead. But it requires the application layer to take responsibility for error recovery and so on.
In the ICMP.C module, the Internet Control Message Protocol is used to provide mechanisms to tell whether the part of the Internet we are sending datagrams to or want to access is active.
The PPP.C module contains the Point-to-Point Protocol, the predominant connection type used today for serial links. PPP is a complete suite of standard protocols widely adopted by the industry that allows two hosts to interoperate in a multivendor network using a serial link such as RS-232.
In a PPP session, there is no distinction between peers as to whi ch is the server and which is the client; both end points can carry on a negotiation equally. However, for practical purposes, in a microcontroller environment a PPP server can be defined as the end point located and handled by the ISP, and a PPP client as the end point that initiates the connection.
The SLIP.C module implements the Serial Line Internet Protocol (Slip) to communicate directly with hosts acting as routers or gateways. The Slip specifies a way to encapsulate raw IP datagrams over a regular serial communication line.
The CommDrv.C module is responsible for the appropriate operation of the serial communications of the system. It implements a pseudo-standard method of accessing the serial port hardware. To the application, the serial port can be seen as a set of API-like routines that perform straight and logical operations, such as OpenComm(), CloseComm(), WriteComm() and so on.
The ModemDrv.C module code assumes the use of a standard Hayes-compatible external modem. S o far as the M68HC08-based system is concerned, the external modem is just a serial device connected to it. From a software point of view, the modem runs on top of the serial port driver. In other words, it relies on services provided by the CommDrv.C module. The wire connections made from the modem to the microcontroller include signal ground, transmitter and receiver pins.
In a typical UDP/IP connection between the embedded application and an external server, gateway or PC-based browser, the program directs the MC68HC908-GP32 to act as a message initiator. It waits until program-defined conditions are meet. A predefined condition could be a security system signaling that it has been triggered, an air-conditioner that has reached a predefined threshold, a doorbell, etc. The system will first dial an Internet service provider to establish a PPP link. The ISP will authenticate the system and assign a unique IP address. After that, the MC68HC908GP32 will be ready to send a notification to the Internet via PPP/UDP/IP. Once on the Internet, a message could travel to virtually everywhere in the planet. With little effort, a program running at the destination host could publicize the UDP datagram.
The UDP/IP software stack that runs on the microcontroller consists of a main routine-the standard C main() function-that is divided into two in-line portions of code. The first portion initializes the communications port and all the other software modules of the system. The second portion is an infinite loop that calls ModemEntry() and PPPEntry() functions. This is needed to perform modem handshake and PPP negotiations, respectively.
The CommDrv.C module defines the interrupt service routine (ISR) code for the interrupt generated each time a byte character is received. However, this ISR is compiled to generate the object code that the linker will realize and put it in flash ROM. That means that the source code of the ISR is installed at link time, not at run-time. Since the serial port of the microc ontroller will be shared among modules to perform different tasks at run-time, a way must be found to share that ISR with different modules.
Dialing an ISP
For instance, the MCU must dial an ISP by using a modem; after the ISP answers, Slip scripts or PPP negotiations need to be executed. Modem.C and PPP.C must rely on the CommDrv.C ISR.
One way to achieve the flexibility needed is to forward the ISR to a location in RAM that points to the ultimate interrupt service handler-in other words, a pointer to an ISR that turns out to be a pointer to a function. By using this approach, the programmer has control of the incoming flow of characters through the serial port.
Related Articles
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
E-mail This Article | Printer-Friendly Page |