All Embedded

EG3

Arm

Atmel

Microchip

Embedded Programmer

Electronic Consultant

Electronic Engineer

Requesting A File From A HTTP Server

Call the start_http_client_request function:

CONSTANT BYTE REMOTE_HTTP_SERVER_STRING[] = {"www.somedomain.com"};
CONSTANT BYTE REMOTE_HTTP_FILENAME_STRING[] = {"devices/file01.html"};

	if (start_http_client_request(REMOTE_HTTP_SERVER_STRING, REMOTE_HTTP_FILENAME_STRING))
	{
		//The request was started.
		//The HTTP_CLIENT_REQUEST_RECEIVE_FUNCTION function will deal with receiving the response if sucessful
	}

Processing Received HTTP Files

Define this with your applications function that will receive the files from the http server:

HTTP_CLIENT_REQUEST_RECEIVE_FUNCTION

Your function definition needs to be:

void my_function_name (BYTE op_code, DWORD content_length, BYTE *requested_host_url, BYTE *requested_filename)

op_code

0 = error – http client failed.

1 = OK.  First section of TCP file data ready to be read.  Function should use the tcp_read_next_rx_byte or tcp_read_rx_array functions to read all of the data from this TCP packet before returning.

2 = Next section of TCP file data ready to be read.  Function should use the tcp_read_next_rx_byte or tcp_read_rx_array functions to read all of the data from this TCP packet before returning.

0xff = The remote server has closed the connection (this will mark the end of the file if content-length was not provided by the server.

content_length

The file length specified by the server at the start of the response.  Note that the server is not requried to specify this (and many don’t) and in this instance the value will be 0xffffffff;

requested_host_url

Pointer to a null terminated string containing the host url that was originally requested

requested_filename

Pointer to a null terminated string containing the filename that was originally requested

Read each data byte in the packet using:

    while (tcp_read_next_rx_byte(&my_byte_variable))
    {

This function is always called after a request, either to either indicate the request failed, or with 1 or more packets of file data. If the request was sucessful the file data packets will be received in the correct order and the tcp data may simply be stored as it is read. The HTTP Client get request headers specify that no encoding may be used by the remote server so the file will be received exactly as it is stored on the server.

An example function

//*************************************************
//*************************************************
//********** PROCESS HTTP CLIENT REQUEST **********
//*************************************************
//*************************************************
void process_http_client_request (BYTE op_code, DWORD content_length, BYTE *requested_host_url, BYTE *requested_filename)
{
	static DWORD byte_id;
	BYTE data;

	if (op_code == 0)
	{
		//--------------------------
		//----- REQUEST FAILED -----
		//--------------------------

		return;
	}
	else if (op_code == 0xff)
	{
		//-----------------------------------------------
		//----- REMOTE SERVER HAS CLOSED CONNECTION -----
		//-----------------------------------------------
		//(This will mark the end of the file if content-length was not provided by the server)

		return;
	}
	else if (op_code == 1)
	{
		//-------------------------------------
		//----- FIRST PACKET OF FILE DATA -----
		//-------------------------------------
		byte_id = 0;		

	}

	//-------------------------
	//----- READ THE DATA -----
	//-------------------------
	while (tcp_read_next_rx_byte(&data))
	{
		//----- GOT NEXT BYTE -----
		//data has the next byte

		byte_id++;
		if (byte_id >= content_length)
		{
			//----- WE HAVE READ ALL OF THE FILE DATA -----

		}
	}
}

‘Signal Noise Issues With MMC & SD Memory Cards (& Clocked Devices In General)’

page in the resources area of our web site for details of a common signal noise problem experienced when using clocked devices such as network interface controllers.

Many of the PIC microcontrollers have silicon bug issues that are detailed in the Microchip errata sheets. If you are experiencing problems with a PIC microcontroller and its nic access check the errata sheet for the device you are using.

First released version.

V1.01

CrossWorks ARM compiler with NXP LPC2000 series 32bit ARM microcontroller support added.

V1.02

No changes

V1.03

No changes

First released version.

V1.01

ARP handling minor error fix

In eth-arp.c file, arp_process_rx function

All of the initial if(! checks should return ‘1’. Previously 2 off returned ‘0’.

In eth-main.c, tcp_ip_process_stack function.

Locate case SM_ETH_STACK_ARP:

And add this before the break; statement:

nic_rx_dump_packet(); //Ensure packet has been dumped

NetBIOS handling bad initialisation fix

In eth-netbios.c, process_netbios_nameservice function

Change the following line:

static BYTE our_udp_socket;

to this:

static BYTE our_udp_socket = UDP_INVALID_SOCKET;

All sizeof() references to struct definitions changed to use a defined length constant. All array read and writes from and to struct’s changed to individual read and writes to the struct members. This is to deal with 32bit compilers which may add pad bytes within a struct (for instance sizeof(MAC_ADDR_LENGTH) will often be 8 not 6 due to the addition of pad bytes).

DHCP timeouts (DHCP_DISCOVER_TIMEOUT and DHCP_REQUEST_TIMEOUT) changed from 4 seconds to 10 seconds to deal with routers / DHCP servers that may be too busy to respond immediately.

CrossWorks ARM compiler with NXP LPC2000 series 32bit ARM microcontroller support added.

V1.02

Added HTTP client functionality.

Added PIC32 built in Ethernet peripheral support.

At the end of the six email_return_smtp_ functions in eth-smtp.c and three email_return_pop3_ functions in eth-pop3.c changed the end of the do loop from:

    while (p_source_string++ != 0x00);

to

    while (*p_source_string++ != 0x00);

Correction for NXP LPC2000 nic.c driver file.  The interrupt line from the KSZ8001 phy used in the sample project would not be cleared.  Corrected in nic_check_for_rx() by replacing the following line:

    nic_write_phy_register(NIC_PHY_IRQ_CTRL_STATUS_REG, (NIC_PHY_IRQ_CTRL_STATUS_VALUE | 0x00ff));

with

    data = nic_read_phy_register (NIC_PHY_IRQ_CTRL_STATUS_REG);

In process_http() added check for a client disconnecting a socket part way through downloading a file (sometimes a browser may close a socket to stop downloading any further data).

Change this:

		//----- PROCESS EACH SOCKET -----
		switch (http_socket[socket_number].sm_http_state)

To this:

		//----- PROCESS EACH SOCKET -----
		if(!tcp_is_socket_connected(http_socket[socket_number].tcp_socket_id))			//If a socket has disconnected during a transfer reset its state
			http_socket[socket_number].sm_http_state = HTTP_WAITING_FOR_CONNECTION;

		switch (http_socket[socket_number].sm_http_state)

Minor improvements to the DNS functions.

Fixed TCP issue whereby if server sends FIN ACK with data the TCP stack was not dealing with the FIN. It now closes the connection as it should.

Added check for LPC2000 driver KSZ8001 PHY link is down when link status changes to avoid long delay before checks timeout when cable is disconnected.

Changed all .val to .Val to provide easier compatibility with Microchip C32 compiler which now clashes with .val

http_transmit_next_response_packet() function updated with new file_offfset variable to fix bug when using HTTP_USING_BINARY_FILES or HTTP_USING_FILING_SYSTEM defines.

V1.03

Minor correction of “.val” usage to “.Val”

V1.04

In eth-http.c corrected issue where http_setup_response would be called twice by modifying this:

		if (http_post_content_bytes_remaining)
		{
			//------------------------------------------------------------------------------------------------
			//----- THERE IS MORE CONTENT TO BE RECEIVED FOR THIS POST REQUEST IN SUBSEQUENT TCP PACKETS -----
			//------------------------------------------------------------------------------------------------
			//Exit now and flag new socket state as still receiving a post request (this will also block other post requests until its complete)
			http_socket[socket_number].sm_http_state = HTTP_PROCESSING_POST;
			tcp_dump_rx_packet();
			return;
		}			

	}
#endif

to this:

		if (http_post_content_bytes_remaining)
		{
			//------------------------------------------------------------------------------------------------
			//----- THERE IS MORE CONTENT TO BE RECEIVED FOR THIS POST REQUEST IN SUBSEQUENT TCP PACKETS -----
			//------------------------------------------------------------------------------------------------
			//Exit now and flag new socket state as still receiving a post request (this will also block other post requests until its complete)
			http_socket[socket_number].sm_http_state = HTTP_PROCESSING_POST;
			tcp_dump_rx_packet();
		}
		return;
	}
#endif

Fixed tcp client issue in eth-http-client.c

Customer provided driver for the Stellaris LM3S6965 NIC added.

If you do encounter issues using the driver with other compilers or devices and are able to give us details of the issue you encountered we will try and include changes or notes across our range of drivers to help other programmers avoid similar issues in the future. Please use the contact us page of our web site to report any such issues discovered.

Double check the IO pin definitions in the drivers nic.h header file are correct

Verify with a scope that all of the control and data pins to the nic are working correctly.

Check that no other device on a serial or parallel data bus to the network interface controller IC is outputting while the driver is trying to communicate with the nic.

Check that your microcontroller is not resetting due to a watchdog timer timeout.

See the:

‘Signal Noise Issues With MMC & SD Memory Cards (& Clocked Devices In General)’

page in the resources area of our web site for details of a common signal noise problem experienced when using clocked devices such as network interface controllers.

If you are using a 32bit device ensure that for the driver files WORD = 16 bits and DWORD = 32 bits.

If you suddenly find that you don’t get a response from a remote server or router, for instance when trying to log onto a POP3 or SMTP server or requesting a DNS response from your networks router, bear in mind that you may deliberately not be getting a response. While debugging you can easily upset servers by, for instance, break pointing code and not letting a TCP connection be properly closed at the end of an operation. Alternatively your router may have built in protection mechanisms enabled to protect against denial of service (DOS) attacks which cause it to start ignoring repeated requests for the same thing. Typically waiting a little while will solve the problem as these types of protection mechanisms are automatically reset by a timer. Alternatively you could try hard resetting your router or temporarily using an alternative POP3 or SMTP server.

The response from a SNTP / NTP server is a 32 bit value which is the number of seconds since 00:00:00 on 1 January 1900. This value can then be used by the application and a typical example of usage is given in the ‘Adding SNTP Functionality’ section earlier in this manual.

To send a SNTP request the user application simply needs to call the sntp_get_time() function. The SNTP driver will then automatically use DNS to lookup the IP address of the SNTP server. If you are using a NTP service such as pool.ntp.org DNS will often retrieve a different IP address on successive calls, as these public NTP services typically distribute requests around a pool of NTP servers. Once the IP address is retrieved the driver will send an ARP request to obtain the MAC address for the server, which will typically return the MAC address of the local network gateway device that will forward the communications on to the actual SNTP server.

The driver then opens a UDP socket and transmits a SNTP request packet, followed by an immediate call of the user application function defined by SNTP_USER_AP_FUNCTION in eth-sntp.h. This marks the exact moment the request is sent to the SNTP server and allows the user application to start a timeout timer if desired so that should the response not be received quickly enough, due to internet delays, it can determine this. The driver then waits for the response and as soon as it is received it again calls the SNTP_USER_AP_FUNCTION function with the received time value.

The SNTP driver incorporates timeout timers for each of the steps of the SNTP process and the user application function is notified if a timeout should occur and the SNTP driver has given up.

If higher accuracy timing is required then it is a good idea to select a SNTP / NTP server to send the request to based on geographical location, so that less time is taken for the request and response to travel across the internet.