ENC28J60 Ethernet Chip Driver Module
This module is composed of exactly two header files and a source file. The purpose of this module is to define
and implement all of the driver functions that are necessary to transmit and receive data packets from the local
area network. The enc28j60.h header file defines different pin configurations for the board where the chip is
located.The driver abstracts away all of the complicated SPI communication between the MCU
and the ENC28J60 board from other components that make up PowerManager.
This makes writing and receiving packets into a matter of a few simple function calls. The enc28j60def.h header file
defines all of the memory locations for the different bank registers, register bits, and SPI operation codes for
the ethernet controller. The header file also defines where the in memory the start and stop address should be for its
incoming/outgoing packet buffers. Most of this information is available in the official ENC28J60 design documentation.
Network Interface Card (NIC) Module
This module further simplifies the process of sending and receiving packets by abstracting away the ethernet driver
details. Basically the NIC defines functions to initialize itself, send packets, and to poll the network for any new packets.
We input packets by polling (through SPI) the chip's packet buffers for available information. The system's method
handles the situation of importing packets that are too big for its buffer by simply dropping it. Once the packet
has been received it stores it in a buffer for the uIP module to break up and process.
Dynamic host configuration protocol (DHCP) is a networking standard responsible for resolving host or domain names from IP addresses.
IP addresses are generally difficult to remember and constantly changing. This makes host names extremely useful because they are able
to map to a device's current IP address. A DHCP server (usually located on the LAN router) is responsible for resolving host name
conflicts and is also responsible for updating every connected device's DHCP cache. This way IP addresses can change and the host
mapping to it can remain persistent throughout its operation. The DHCPC module is responsible for checking if DHCP is available on
the LAN. If so, it provides functions to handle DHCP initialization, requests, application calls, and configurations. This is all
unnecessary if the user doesn't have a DHCP server available on their router or LAN. If this is the case then the user must manually
assign a static hostname that doesn't conflict with other hostnames on the LAN.
The uIP module is a TCP/IP protocol stack designed to be as compact as possible for embedded devices like the ATMEGA644 MCU. It handles
all of the mid level networking protocols as defined in the open systems interconnection model (OSI). To simplify communication in a
network, the OSI standard hierarchically abstracts communication functions into logical layers. These layers help provide naming and
routing information for a device to be able to send its packets to its correct destination.
HTTPD Module and Website CGI
PowerManager runs an HTTP web server over its TCP/IP stack. It is able to listen to HTTP requests and respond with an HTML web page. The HTTP web server lies on the application layer of the OSI model. When an HTTP request is received, the requested page is loaded from program memory. This page contains calls to Common Gateway Interface (CGI) functions; each CGI function call spawns a new protothread to run the function. In fact, the initial HTTP request is abstracted as its own CGI function call; the request loads a protothread which loads the page from memory and outputs it on an HTTP response buffer. Additional CGI function calls are made at this time and add to the HTTP response buffer. Once all CGI calls are made, the HTTP response buffer is sent to the client and displayed on their browser.
The PowerManager system contains three web pages: index.shtml, action.shtml, and 404.shtml. These web pages provide a GUI to view the current state of power flow in the power box and to control the state of power flow. The 404 page is displayed on default when a page that doesn't exist is requested. The index page displays the current state of power, and a button to toggle the power. The button makes a request to action.shtml with the requested action. If the action is "on", then HIGH is outputted on pin A7 to turn the relay on; if the action is "off" a LOW is outputted to turn the relay off. These actions guarantee that power will be at the requested state despite the initial state. As soon as the action is performed, an HTTP redirect is issued to return the user back to the index.shtml page to display the new state. A picture of the index.shtml page can be seen below in Figure 13.
Figure 13 : PowerManager GUI
These consist of the modules that we leveraged from other sources but didn't touch. This includes the modules that support
protothreads, protosockets, timers, clocks, and local continuations. Protothreads are stack less threads that were designed for
memory constrained embedded systems such as the ATMEGA644 MCU. Protosockets work with protothreads to help provide sockets for
TCP to work. A socket is an abstraction that encapsulates a connection between a client and a server. It is used with the uIP
module to provide a means for TCP to make reliable connections. The timer and clock modules serve to periodically signal PowerManager
to perform its list of required tasks (e.g. ARP broadcasts and incoming packet buffer polling). The clock and timer modules are
fundamental to PowerManager because events are handled synchronously using polling methods. They are also important because
different tasks need to be performed in different time intervals. ARP broadcasts don't have to be done on every clock cycle because
IP addresses don't generally change that frequently within networks. NIC polling on the other hand needs to be done more frequently
because packets come in all the time. These different tasks must be managed and performed and different rates to ensure that everything
goes smoothly. The local continuations module provide support for local continuations which are fundamental protothreads.