Back in the 1970s and 1980s, when the RS-232 serial protocol was being adapted to the address the demands of electronic terminals and personal computers, few could have imagined that it would become such a standard feature. Thousands of industrial devices were developed based on the RS-232 interface. But for electronic communications, the evolutionary process was already kicking into a higher gear.
Today, Ethernet is a well-defined standard for local and wide-area networks. Countless devices access the Internet using TCP/IP over Ethernet. Despite the presence of other physical-layer implementations, Ethernet is here to stay for many years until, of course, electronic communications evolves into something else and faster, more advanced protocols are required.
Myriad new designs continue to use Ethernet as the primary network standard. Others may implement different physical interfaces but still use TCP/IP to access networks, such as the Internet. In fact, the wide acceptance of TCP/IP over Ethernet is a primary reason behind the Internet’s rapid expansion over the last couple of decades. But what happened to RS-232?
SUSTAINABLE EVOLUTION
Millions of electronic products still use RS-232 as a serial
interface. This is particularly true in developing countries, where
developers may lack the budgets to leapfrog from legacy systems
to new technology. Therefore, some form of sustainable evolution
must be considered.
A cost-effective way to operate in this new environment is the RS-232 serial-to-Ethernet adapter, the “missing link” in the evolutionary chain that brings legacy systems into a whole new panorama of networking applications. When evaluating a serialto- Ethernet bridge, developers should consider:
• Small size: An optimized printed-circuit-board (PCB) design, with fewer highly integrated components, reduces the project’s footprint and its cost.
• Operating voltage: This should be compatible with common serial communications standards, such as RS-232 and RS-485.
• Adaptability: Customizable and layered software along with flexible hardware designs are highly recommended to make the bridge more adaptable to different applications.
• Usability: Simple interfaces for configuration and monitoring, such as GUIs and LED indicators, improve ease of use.
• Performance: The bridge should be able to convert RS-232 and/ or RS-485 to Ethernet without any user inconveniences. Using a microcontroller with a serial communications interface and an Ethernet media access controller (MAC) is recommended. The device should have just enough performance for the required application to keep costs down.
• System cost: Developers should strive to keep system costs as low as possible.
COST-EFFECTIVE, PLEASE
What is cost-effective when you are trying to link the old with
the new? The software must be complementary, and hardware
costs should be minimized. As such, a cost-free but still robust and
customizable software approach is strongly recommended.
Ready-to-use operating systems and stacks can ease this task. Thus, it takes minimal effort to add, modify, or remove software modules compared to developing your own task scheduler, Ethernet TCP/IP stack, or application from scratch. Today, you can find a wide variety of royalty-free and open-source stacks and operating systems. Choose wisely, though, since they will be closely tied to hardware and community support.
You might have an amazing application that fulfills the serial-to- Ethernet bridge functionality. But if the chosen processing device (microprocessor or microcontroller) exceeds the performance requirements, the cost will be too high. If the performance is inadequate, then the functionality of the final product will fall short of application requirements.
Microprocessors can easily fulfill this task. However, microcontrollers have evolved to the point where they can run operating systems while providing Ethernet connectivity at a much lower price. A serial-to-Ethernet bridge can be implemented easily using a low-end 32-bit microcontroller with low SRAM and flash size.
MAKE DESIGN AND CUSTOMIZATION EASY
Even when you have found the right costeffective
microcontroller with the required
performance and peripherals, along with
enough SRAM and flash to run a reduced
operating system and basic Ethernet stack,
you still have to assemble all of these software
and hardware blocks. Engineering
time impacts system cost, so how do you
simplify development?
A layered software architecture is recommended. All of the different blocks can be put together to create a software environment that will organize the development process. This can directly impact engineering time and later customization of serialto- Ethernet bridges.
Such a layered software model is based in splitting several main software blocks into layers and essentially making an abstraction of the hardware used. The hardware abstraction layer (HAL) is defined as the collection of software components that make direct access to the hardware resources, including peripherals, configuration registers, optimized assembler routines (with their appropriate prototypes), pre-compiled object code libraries, or any other hardware dependent resource, through the HAL/HW interface.
Continue to page 2
This way, if the software design requires later modification, it can be ported to higher-end microcontrollers and different hardware platforms. The software can easily “evolve” and allow a smooth transition when adding new peripherals or even changing protocols and hardware, making more of the software reusable for future design enhancements.
PUTTING IT ALL TOGETHER
Figure 1 details a typical layered software architecture. The
application software runs over the operating system (FreeRTOS),
which handles the Ethernet stack (LwIP) and microcontroller
peripherals (see the table). The hardware consists of Freescale’s
32-bit MCF51CN128 microcontroller with minimum external
components.
The FreeRTOS open-source software provides enough features to be used in commercial serial-to-Ethernet bridge applications. It handles semaphores, multiplexers, interrupts, RAM management, preemptive tasks, stack space, and task priorities, among other functions. The forum support is good, since this well-known piece of software within the embedded microcontroller industry has been ported to at least 19 architectures. One key advantage is its small footprint.
The chosen open-source TCP/IP stack handles all Ethernet transactions. It’s highly recommended for a serial-to-Ethernet bridge due to its balance between functionality and low RAM/flash requirements. LwIP takes 12.15 kbytes from RAM at compile time to start all of the TCP/IP services needed by the serial bridge.
At runtime, the stack allocates and releases some buffers and takes whatever RAM is needed from the heap. It uses a very limited set of network buffers to send and receive information from the application’s higher layers. Support includes TCP/IP, ICMP, UDP, specialized Raw API (used for this serial bridge), optional socket API, DHCP, PPP, and ARP, among others.
The 32-bit MCF51CN128 microcontroller contains 128 kbytes of flash and 24 kbytes of SRAM. This on-chip memory is sufficient to run the serial-to-Ethernet bridge application along with the operating system and the Ethernet stack.
The microcontroller runs at a maximum rate of 50 MHz, delivering the required performance. It integrates a fast Ethernet controller (FEC) and serial interfaces such as UART (SCI), SPI, and I2C. The remaining general-purpose I/O (GPIO) pins enable additional tasks, for instance, driving LEDs for status verification. The silicon fits the application and keeps the bill-of-materials (BOM) costs low.
SERIAL-TO-ETHERNET BRIDGE IMPLEMENTATION
A reference design was created as a turnkey solution for simple
serial-to-Ethernet bridges with Web server, FTP service, e-mail
client, SD-CARD support, and other compelling features. To keep
the design simple and maximize layout recycling for designing
different products, the system was divided into two main hardware
blocks: minimal and demo (Fig. 2).
The minimal system includes all of the hardware needed for Ethernet functionality. This is the smallest hardware block, measuring just 1.15 by 1.55 in. By providing an unregulated power source, from 5.5 to 3.7 V, no additional components are needed for a minimal implementation with Ethernet functionality.
Additional features, such as a uSD card socket, pushbuttons, and an LED, are available in the demo system. Zero-ohm resistors that isolate both systems are visible at the top and bottom layers (Fig. 3). Disconnecting them isolates the minimal system from the demo system.
For this particular implementation, the Ethernet interface can power the reference design board by using the two unused pairs of Ethernet cables. Note that this isn’t the power over Ethernet (PoE) standard, though. The UART pin (+5.5 V), a power jack connector, and the regulated 3.3-V jack connector also power and enable specific system functionalities (Fig. 2, again). All of these options can be enabled using the board’s cut-traces.
This serial bridge can work in configuration mode through a set of commands where UART (SCI) or SPI is used to configure functionality. A wide variety of options can be changed in configuration mode, including MAC, IP, mask, gateway, and server addresses.
The use of static or dynamic addresses can be specified, and TCP parameters, such as which port to connect and the client/ server implementation address, also are configurable. Modifiable UART parameters include port, baud rate, parity, number of bits, stop bits, and flow control (hardware or software). Finally, the SPI can be configured for port, baud rate, polarity, phase, master/ slave, and polling/interrupt handling.
When the reference design works in bridge mode, characters received at the serial interface are sent to Ethernet and vice versa. A serial-to-Ethernet bridge works between two interfaces, and its purpose is to enable rapid data transfer between the interfaces.
INTERFACING SERIAL AND ETHERNET
The Fast Ethernet controller (FEC) is Freescale’s implementation
of the MAC. The FEC stores the RX and TX packets in a
buffer descriptor scheme. The buffer descriptor consists mostly of
buffer descriptor status and control flags, buffer length of received
data or data to be transmitted, and buffer pointers associated with
reception or transmission.
When a high-speed interface such as Ethernet tries to connect to low-speed interfaces like UART or SPI, a flow-control protocol must be implemented as a speed adapter. Ethernet doesn’t feature flow control, unlike TCP/IP. The UART features software and hardware flow control.
Continue to page 3
As the application is exposed to continuous transfers, data can quickly fill the UART software buffer if it’s not processed by the serial bridge application at the same rate. Extra focus is required when determining operating baud rate and UART buffer size, since they will impact the execution of running tasks and their priorities when using a real-time operating system (RTOS).
The SPI communication has no flow control. Its software driver should not be changed to add extra headers in the communication. The flow control should be implemented in the application layer by using acknowledges or another customized flow-control protocol.
Communication can be stopped very easily with a flow-control protocol. If that happens often enough, though, communication performance will degrade, especially for serial protocols such as UART and SPI. This performance issue can be solved with UART or SPI hardware buffers, which are usually 1- to 4-byte buffer lengths. To minimize delays, use an interrupt to signal the application bridge that a character can be sent.
However, the delay between the interrupt request for free space on the UART hardware buffer and the buffer’s response must be considered. This delay can be decreased by using a software buffer between the bridge application and the UART controller. This way, the application bridge can fill the software buffer, and the UART ISR will take it character by character until it’s emptied. This technique reduces the number of times flow control stops communication, improving the overall performance rate. For the UART RX case, a software buffer is important for storing all characters that can be received.
An Ethernet packet is formed by data and protocol headers. For the serial-to-Ethernet bridge application, efficient Ethernet packets are formed by using as many bytes as possible for the data section. This will reduce the overhead caused by the required header section.
The application layer (serial bridge) solves this problem by using a software buffer, such as a FIFO, to queue and un-queue data. Independent buffers for serial reception (RX) and transmission (TX) can be used as a way to store all of the information that the application can’t process at once.
WRAPPING IT UP
Serial-based interfaces (RS-232, RS-485, and SPI) built into
thousands of devices fail to provide the extended connectivity
accomplished by a protocol like Ethernet. One cost-effective solution
is a serial-to-Ethernet bridge. When designing the bridge,
structured and layered software must be combined with cost-effective
hardware to meet the functional needs of the application. Free-
RTOS, LightweightIP (Ethernet-TCP/IP stack), and Freescale’s
MCF51CN128 embedded controller have been used to create a
specific reference design for a simple serial-to-Ethernet bridge.