I continued where I left off from last week; setting up the physical layer for Ethernet connection. After taking a good look at the documentation available, I realized that there were a minimum of 3 commands required to get the line up and running. These commands were, including TCPIP.h header file, initializing the stack by calling “StackInit”, and looping the “StackTask” and “StackApplications” commands. After programming the code the port LED’s lit up indicating the successful connection from the PIC to the network.
Following the physical layer is the data link layer. To set this up I wanted to send DHCP (Dynamic Host Configuration Protocol) commands to connect to the network and ping the device to test the connection. In order to do this a MAC addressing system had to be set by the user using AppConfig. This is done by inserting the necessary commands as shown below :
// Declare AppConfig structure
APP_CONFIG AppConfig;
static ROM BYTE SerializedMACAddress[6] = {MY_DEFAULT_MAC_BYTE1, MY_DEFAULT_MAC_BYTE2, MY_DEFAULT_MAC_BYTE3, MY_DEFAULT_MAC_BYTE4, MY_DEFAULT_MAC_BYTE5, MY_DEFAULT_MAC_BYTE6};
void main (void){
memset((void*)&AppConfig, 0x00, sizeof(AppConfig));
AppConfig.Flags.bIsDHCPEnabled = TRUE;
memcpypgm2ram((void*)&AppConfig.MyMACAddr,
(ROM void*)SerializedMACAddress,sizeof(AppConfig.MyMACAddr));
}
It is also necessary to define STACK_USE_DHCP_CLIENT and this can be done by uncommenting the line in TCPIP ETH97.h. The program was then written to the PIC and tested. However the ping was not continuously received and tended to stop after some time, giving the error that the device was not found. This indicated that the device was not properly connected to the network and keeps losing its IP address. Continuous testing of the same code gave different results each time. At this time I used Wireshark, an application that is a network protocol analyzer, to check out the packets being transferred. After filtering out the necessary DHCP packets it showed that the device sends out DHCP offer, request and ACK packets. Moreover sometimes the transaction stops at request. Hence I consulted the available demo application and found that the interrupts had to enabled for pinging accurately since the program uses Tick header files which makes uses of interrupts. Enabling interrupts and testing out the program gave ideal results and the ping program worked perfectly. This prompted the checking of whether both the high and low interrupts were required for the application and the results of this test showed that both interrupts were necessary.
Continuing on the work, I then moved on to testing the TCP Performance. Microchip TCPIP stack already had an integrated function for the test and can be called in StackApplications. In order to do this STACK_USE_TCP_PERFORMANCE_TEST has to be defined and is uncommented at TCPIP ETH97.h. The test of the program showed that the transmission test from port 9762 works perfectly, however the recive performance at port 9763 was not operating correctly. Looking through the application codes showed that the TCP_PURPOSE_TCP_PERFROMANCE_RX socket was not created and hence after referring to TCPIP stack help it was found that the socket is disabled at first to save memory space and was defined at TCPSocketInitializer in TCPIP ETH97.h. Enabling this socket and testing out the program yielded favorable results. Furthermore I came upon an interesting test result, when “TCPPerfromanceTask()” is called through StackApplications the performance is less compared to when the function is called on its own outside of StackApplications.
0 Comments