There are two aspects to the project: the code that runs on the chipKIT board and
the Content directory that contains Web content that you must copy onto the
SD card. In the MPIDE file structure, you have a directory where all of your sketches
are saved (you can see what this directory is by opening the preferences and looking at
the “Sketchbook location”). You need to place this WebServer sketch in this
directory (together with the accompanying files). This HTTPServer can be downloaded
via HTTPServer.zip. The HTTPServer also relies on the Digilent
DNETcK and DWIFIcK network libraries, and they must also be installed in the MPIDE
libraries subdirectory. A copy of the Digilent network libraries can be downloaded
from DNETck/DWIFIcK. Finally, in the WebServer sketch directory there is
a “Content ” subdirectory. This directory contains the sample
content to be copied to the root of your SD card (the files in this directory are not
compiled with the sketch).
Supported Hardware:
- Most boards that have an Uno32 form-factor with a WiFiShield (with either an
MRF24WG0MA or MRF24WB0MA WiFi radio and SD card reader).
- Uno32, uC32, Max32.
(Please note that the Max32 stacked with a NetworkShield and a WiFiShield will not
work, as the NetworkShield does not carry the required J13 SPI signals through to
the WiFiShield. Attempting to stack the WiFiShield first will not carry through
many required NetworkShield signals.)
- The WF32, which has both an SD card reader and an MRF24WG0MA WiFi radio.
- A Cerebot MX7cK with a PmodSD card read on JPF.
Step 1
Open the WebServer sketch in MPIDE. There are multiple files but only
three are of particular interest:
WebServer.pde :
This is the primary sketch file.
HTPServerConfig.h :
A file containing your specific network parameters, such as IP address and
WiFi Keys or passphrase.
HTMLSample.cpp :
An example dynamically created HTML page. This is not a required source
for the HTTPServer, but it is there to illustrate how to create a simple
dynamically generated page (so, for example, you could report the current settings
of switches on an I/O shield).
Step 2
Modify WebServer.pde to specify the hardware you have:
- You must specify the network hardware you are using. Typically this will be one
of the following:
WiFiShieldOrPmodWiFi_G.h :
Use this if you have an MRF24WG0MA WiFi radio.
WiFiShieldOrPmodWiFi.h :
Use this if you have an MRF24WB0MA WiFi radio.
NetworkShield.h :
Use this if you are using the MX7cK with the onboard
internal MAC and PHY; that is the wired LAN connector.
- For all but the MX7cK, you must included DWIFIcK. However, you must comment out
the directive
#include DWIFIcK if you are using the MX7cK, as it does
not use the WiFi.
Step 3
Modify HTTPServerConfig.h to provide the network parameters as
follows.
Provide the LAN Setup:
This is a server, and for clients to connect to a server, the IP address needs to be
well known. The easiest thing to do is to assign a static IP address to the server.
Instead of using a static IP address, DHCP offers many advantage, as it will
automatically assign your subnet mask, gateway, and DNS servers, all of which are
valuable network parameters. The HTTPServer is designed so that you can assign a
static IP and all of the network addresses manually, or use DHCP to automatically get
your network parameters, as well as get an IP assignment. Or (and this is probably
the most useful option), do a combination of both. The HTTPServer has the ability to
do a two-pass start up, where in the first pass DHCP is used to obtain all of your
network addresses, including an IP address. Then the HTTPServer saves these values
and restarts the network stack using a static IP that you assign while maintaining
the other automatically obtained addresses. However, you don't assign the whole
static IP, only the last octet of the IP, as typically the first three octets are
your subnet, and you typically don't know what those are until DHCP tells you. By
limiting your static assignment to only the last octet of the IP address, you can
usually pick a value that will work on most networks seamlessly no matter what the
subnet is. This isn't perfect, as subnets don't have to be three octets long, but as
a general rule, with most commonly available routers, this works very well out of the
box.
In the file HTTPServerConfig.h , there is a section for your network
values. The following describes how to set them:
ipMyStatic :
ipMyStatic is a structure with four members. If all the members
are set to zero, as would be accomplished with the following statement
ipMyStatic = {0,0,0,0};
then DHCP will be used to obtain your network parameters. If any of the
members are nonzero, this will be the static IP and you must set all of
your other network parameters manually; that is, you must
set ipGateway , subnetMask ,
ipDns1 , and ipDns2 .
localStaticIP :
This value only has meaning if ipMyStatic == {0,0,0,0} ; that
is, you are using DHCP to obtain your network parameters.
If localStaticIP is nonzero (i.e., if localStaticIP !=
0 ), it will become the last octet in your IP address, the first three
octets having been obtained from DHCP. Specifically, the first three octets
of ipGateway are used. So, if your
ipGateway address comes back as 192.168.2.1, and you
specified localStaticIP = 200 , your static IP address will be
192.168.2.200. If, however, you specify localStaticIP = 0 , then
your IP address will be that assigned by DHCP. localStaticIP must
be in the range of 0 to 255.
listeningPort :
This is the port on which HTTPServer will listen. Typically, HTTP servers
listen on port 80, and that would be the most likely port to pick—except,
especially in cases where you want to port forward through a gateway, you may
wish to use another port number. Of course, if you use a port number other
than 80, the browser wishing to access the HTTPServer may require you to
specify the protocol (http: ) as well as the port number. For
example, if you decide to use port 44000 and your IP address is 192.168.2.200,
a browser wishing to access the HTTPServer may require the fully specified
URL, http://192.168.2.200:44000 . Because the port is not the
default http port, the browser may not know what protocol to use and thus must
be provided with this information. Obviously, your IP address may exist in a
DNS server somewhere and the IP address can be replaced with a DNS name, but
you may still have to specify the protocol and port
(e.g., http://myserver.http.com:44000 ).
If you decide to pick a port number other than 80, you need to pick wisely, as
you don't want to conflict with predefined ports like port 23 (Telnet). We
won't discuss the many ports that are assigned number by the Internet Assigned
Numbers Authority (IANA). Suffice it to say that ports in the range between
44000 to 47000 are mostly unassigned ports, so pick one in that range. Valid
ports are from 1 to 65535.
cMaxSocketsToListen :
This is the number of sockets, or connections, you can handle
concurrently. As a practical matter you can only have as many listening
sockets as DNETcK supports on the board. DNETcK supports 4 sockets on
low-memory boards like the Uno32 and up to 8 sockets on larger boards like the
Max32. You can limit the number of sockets assigned to the HTTPServer if you
wish to reserve some for other DNETcK usage outside of the HTTPServer, or you
can specify 8 and dedicate all the sockets to the HTTPServer. This parameter
can be larger than the actual number of sockets available on the board, but you
will only get what the board supports. On the other hand, if you make it
smaller than what the board supports, it will limit the number of sockets used
by HTTPServer. It is not unusual for a single browser session to use more than
one socket, so a good number to use is between six and eight. Clearly, a
Max32, WF32, or MX7cK will handle a larger load than an Uno32, since an Uno32
only has four total sockets available. Fortunately, most browsers are very
tolerant in that they open connections for each URL needed to render the page,
such as .jpg s, but if the connection fails, it will keep trying
until other connections are free. How this works varies from browser to
browser, and you may only need one socket to work, but we would
suggest having at least three sockets available for each browser session. An
interesting thing to do is look at the serial monitor as your page is rendered
so that you can watch the sockets connect and disconnect; it can be very
surprising to see the number of sockets consumed to render one page, be it
serially or concurrently.
-
ipGateway , subnetMask , ipDns1 ,
ipDns2 :
One way or another, these must be set correctly. If you
specify ipMyStatic == {0,0,0,0} , DHCP will set them.
If ipMyStatic != {0,0,0,0} , you must manually set these values.
If you set them manually, make sure they are correct, or the HTTPServer will
appear to hang, as it probably can't succeed at some or all network operations.
Some good DNS servers to know about are the Google Public DNS servers at
8.8.8.8 and 8.8.4.4; they are free and they work well.
Provide the WiFi Security Information:
Since the HTTPServer requires an SD card reader and a network connection, the easiest
hardware configuration to use is the WiFiShield, which offers both on one shield.
Another really great choice is the WF32. These are both WiFi products. The only
non-WiFi (hard-wired) supported board is the MX7cK with a PmodSD. (If you are not
using WiFi, you don't need to be concerned with this section: leave it as it is.)
SSID : Service set identifier: this is the name of the WiFi
network. It is a name up to 32 characters long. You can use the DWIFIcK
WiFiScan example to sniff the air to see what networks are available; or more
typically, you would just ask whoever set up the WiFi router for its name.
- WiFi security mode. Uncomment only one or none of the
#defined
security modes and fill in the related security information for the mode
selected:
USE_WPA2_PASSPRASE :
Select this if you are using WPA passphrase security. This is
probably the most likely security to be in use. You will need to ask
whoever set up the WiFi router for the passphrase. The passphrase can be
up to 64 characters long. Understand that using a passphrase will be
very slow to connect (up to 40 seconds), as the MRF24W(B/G)0MA radio must
calculate the PSK (pre-shared key) key, which is very
time-consuming.
USE_WPA2_KEY
This is the PSK key which you can enter directly instead of having
the radio calculate it. Using the key will greatly reduce the connect
time. If you start with a passphrase, allow the HTTPServer to connect
and allow the radio to calculated the PSK key for you. Then, if you have
the serial monitor open, you can see the printout of the calculated key.
For example, you would see something such as the following:
Key Type: 5
Key Length: 32
Key Value: 27:2C:89:CC:E9:56:31:1E:3B:AD:79:F7:1D:C4:B9:05:7A:34:4C:3E:B5:FA:38:C2:0F:0A:B0:90:DC:62:AD:58
You can grab that key and fill in the key structure, using this setting
instead of the slower passphrase setting. The key in this particular
example is what pertains when the SSID is
chipKIT and the passphrase is Digilent ; by
taking the calculated value as printed in the serial monitor
using USE_WPA2_PASSPRASE , you can fill in
the USE_WPA2_KEY key structure as follows:
DWIFIcK::WPA2KEY key = { 0x27, 0x2C, 0x89, 0xCC, 0xE9, 0x56, 0x31, 0x1E,
0x3B, 0xAD, 0x79, 0xF7, 0x1D, 0xC4, 0xB9, 0x05,
0x7A, 0x34, 0x4C, 0x3E, 0xB5, 0xFA, 0x38, 0xC2,
0x0F, 0x0A, 0xB0, 0x90, 0xDC, 0x62, 0xAD, 0x58 };
USE_WEP40 , USE_WEP104 :
We do not recommend using WEP. However, if you must, you can
specify your key and key index in these structures.
- To connect to an open network, comment out all of the security
modes; no additional information is needed beyond the SSID.
Step 4
Copy your content to the SD card.
The SD card should be formatted as FAT32.
Only 8.3
filenames are supported, so no long filenames! Each file should have a
three-letter extension that represents the type of file it is. For example, this
would be “.htm ” for an HTML file or
“.jpg ” for a JPEG file. Load your SD card on to your PC and
erase the SD card. Then, copy the files from the content directory onto the root of
the SD card. HomePage.htm must exist, and must exist at the root. When
done copying, make sure to eject the SD card before pulling it from the PC; you want
to ensure that all files were flushed to the card before removing it. Then stick
your SD card into the reader on your chipKIT board. With a 16 GB SD card there is
lots of room for content!
Step 5
Build and run the server.
Connect your chipKIT board to your PC. Assuming you have already started MPIDE and
have the WebServer sketch open, select the appropriate board and COM
port, build, and upload the sketch. Once uploaded, start the serial monitor at 9600
baud and you will see a bunch of useful/interesting diagnostic messages. When the
server is up and running, it will print the IP and port it is listening on. Go to a
browser and connect to the WebServer. In the example below, use the address line
of http://192.168.1.224 (port 80 is implied by the use of the http
protocol without a port specification).
Dynamic begin
Network Initialized
Static begin
Network Initialized
UTC: Jul 26, 2013 @ 22:31:39
My IP: 192.168.1.224
Gateway IP: 192.168.1.129
Subnet mask: 255.255.255.128
Dns1 IP: 192. 168.1.129
Dns2 IP: 24.113.32.29
My MAC: 00:1E:C0:0E:72:17
Listening on IP: 192.168.1.224:80
|