You may recognize the title because this article is a sequel to ‘Wi-Fi Orb Sees All
’ that I wrote for TechZone last year. Then, I used a Parallax Propeller MCU
and WIZnet WizFi210 Wi-Fi interface to make an ‘Orb’ that monitors the stock market and summarizes what is going on with a simple ‘ambient’ display on red and green LEDs. Sure you can check the Dow Jones average on your PC, tablet or smartphone. However, if you are like me, it is all too easy to get sucked into the web and next thing you know you’re watching dancing kittens.
Parallax and WIZnet continue to enhance the combination of the formers Propeller MCUs with the latter’s smart network chips. The latest development is a new software package that enables very small and low-cost Ethernet capable devices, just the ‘thing’ for the ‘Internet of Things’.
is the creation of networking expert Mike Gebhard
, building on his earlier work with the WIZnet W5100
chip. The latest version also works with the new WIZnet W5200
chip which features 10/100 Ethernet interface (MAC and PHY), eight hardware TCP/IP sockets, 32 KB socket buffer RAM and a fast SPI interface.
Supported platforms include the original W5100 Spinneret
and a new W5200 ‘Quickstart’ board
(Figure 1). In addition to the RJ-45 magjack and 3.3 V single supply operation, these feature a micro-SD card slot for PC-compatible mass storage and a supercapacitor-backed Real-Time Clock (RTC).
Figure 1: Parallax W5100 Spinneret and W5200 QuickStart boards. (photo courtesy Parallax Inc.)
Another option is to use the WIZnet Wiz820io
module, which combines the W5200 and RJ45 magjack in a single module (Figure 2). With a simple SPI interface, single 3.3 V power-supply operation and DIP-style footprint, the Wiz820io is an easy add-on for Propeller boards like the Board of Education (BoE) I used in the earlier article.
Figure 2: The Wiz820io is an easy add-on with single, 3.3 V power supply and simple SPI interface.
I decided that porting the original Wi-Fi ‘Orb’ application to the W5200 would be a quick and easy way to kick the tires. Let’s start by reviewing the application and taking a closer look at the new software.
As in the earlier article, we will be accessing www.google.com for the financial data. As an example, if you type http://www.google.com/ig/api?stock=.dji into your browser, you will see the page containing the Dow Jones Industrial average and related data (Figure 3).
Figure 3: Financial data provided by Google.
If you are interested in monitoring a different stock, just change the symbol in the query accordingly. For example, to see the information for Apple Computer, just replace ‘.dji’ with ‘aapl’.
The new software uses the ‘stack’ approach typical of network applications. Let’s take a look from the bottom up (Figure 4).
Figure 4: W5100/5200 network software.
The lowest layer is the WIZnet chip itself, which handles the Ethernet and most aspects of the TCP/IP protocol in hardware. This ‘offloading’ of the low level network functions makes the WIZnet chips uniquely well-suited for interfacing small MCUs to the net with minimal software overhead.
Next up is an SPI driver that provides access to the WIZnet chip for higher layers. Since everything is funneled through the SPI driver, its performance is important. That is potentially a challenge for an MCU that, like the Propeller, does not have a hardware SPI interface and must use a bit-banged driver. A typical SPI driver for the Propeller is capable of decent performance (ex: 5 MHz) but the new software kicks it up a notch. By using an MCU timer to clock the data, the SPI driver achieves data rates of 10 MHz from, and 20 MHz to, the WIZnet chip.
On top of the SPI driver is a WIZnet chip-specific (i.e. W5100 or W5200) driver, a set of routines that provide access to the chips registers and functions. For example, to configure network parameters, you would use functions like SetMac, SetIp, SetSubnetMask, etc.
Above the chip layer are TCP socket services that map to the WIZnet hardware sockets, with functions to Open, Connect, Disconnect and Close a socket and Send and Receive data.
The icing on top is network services such as DHCP (Dynamic Host Control Protocol), DNS (Domain Name Service), SMTP (Simple Mail Transport Protocol) and others. You need only include the specific services required, leaving out others to minimize your applications memory footprint.
Let’s take a look at some of the new aspects of the W5200 Orb program. In the interest of brevity, I will not go into code that is the same as the earlier Wi-Fi version. The entire project is posted online if you want to take a closer look (see the ‘Ethernet Orb’ post in the ‘Projects’ forum
After some power-up housekeeping (ex: setting the MCU clock rate), the Orb application starts by including the aforementioned network objects, i.e. the SPI driver, WIZnet chip and socket interface and higher level services, in this case DHCP and DNS (Figure 5).
Next comes our application data definition including variables, the website address (www.google.com) and GET statement, ‘keys’ which define the xml data to be retrieved, and a place to store that data along with a timestamp.
Finally, to establish a platform specific connection, a set of constants define which MCU pins are connected to the WIZnet chip and LEDs.
Figure 5: Ethernet Orb application prologue.
A network application just has to do two things to get started (Figure 6). First is to initialize the SPI driver, letting it know which MCU pins to use to communicate with the W5200 chip. Then, with the SPI interface established, the next step is to initialize the W5200 MAC address that gives it a globally unique ID.
After initialization the program enters the main (infinite) loop, which collects the Dow Jones average (symbol .dji) from Google, stores the data along with a timestamp, monitors network activity on the debug terminal and finally ‘ambientizes’ the data by lighting the appropriate LEDs.
Figure 6: Network initialization.
Now let’s get into application specifics. First, the program uses the DHCP service to get an IP address assigned automatically (Figure 7). Behind the scenes, the DHCP service also collects other key information such as the DHCP lease time and IP addresses for the gateway and DNS server.
Figure 7: Using DHCP to get an IP address.
In principle, the IP lease only needs to be renewed infrequently (on my network the lease time is 86,400 seconds or 24 hours). MCU timing functions or an RTC could be used to schedule renewal, but there is nothing wrong with getting an IP address more frequently, so I just do it each pass.
Next, I use the DNS service to find the current IP address for www.google.com (Figure 8). The IP address does change frequently, though my experience is previously returned addresses continue to work for some time. An option would be to just call DNS if there’s a problem, i.e. ‘404 – Page Not Found’ but, as with DHCP, it is easier just to look up the current address each pass.
Figure 8: Using DNS to lookup the IP address for www.google.com.
Now it is time to open a TCP socket and connect to the Google web server (i.e. Port 80 at the IP address returned by DNS – Figure 9). Once connected, I send the GET request and wait for the reply (i.e. HTTP response header and the webpage) from the server.
Figure 9: Establish TCP connection to the webserver, issue GET request, and receive data.
The program searches the incoming webpage to find and capture the desired data (i.e. .dji percentage change) and update the LEDs. I wrote a GetNextByte routine (Figure 10) to mimic the ‘device server’ operation of the previous Wi-Fi module, so the rest of the code that searches the webpage and displays the data (Figure 11) is virtually unchanged from before.
Figure 10: GetNextByte mimics the bytestream of a traditional device server.
Figure 11: Ethernet Orb in action.
Small is beautiful
A conventional ‘network stack’ with features like DHCP and DNS consumes many tens of kilobytes of code, maybe even triple digits. But, thanks to the efficiency of the Propeller, optimized network code and the W5200 hardware TCP/IP capability, the entire Ethernet Orb application requires just 10.5 KB, less than a third of the Propeller’s 32 KB RAM.
The Propeller has eight processor cores but the Orb application only uses three of them; one for the application and network code, one for the SPI driver, and one for the debug terminal. Removing the debug terminal and associated code would free up the core it uses and reduce code size even further.
The bottom line is that the networking features consume just a fraction of the MCU resources. Even webserver applications, normally the province of ‘computers’ (ex: embedded Linux®, RTOS), are possible (Figure 12). You can front your application with a website (stored on micro-SD card) so it can be monitored and controlled using the web browser on a PC, tablet, or smartphone.
Figure 12: Webserver demo including homepage, SNTP/RTC time sync and interactive touchpad monitor.