Mostrando entradas con la etiqueta Ethernet. Mostrar todas las entradas
Mostrando entradas con la etiqueta Ethernet. Mostrar todas las entradas

lunes, 29 de abril de 2013

Servidor WEB en PIC24.

Desde que empecé a diseñar el servidor web que desarrollé en el blog hace un tiempo, había una placa de sure-electronics que me parecía muy interesante, la Ethernet Advanced Demo Board. En ese momento la placa tenía un precio bastante alto en eBay, pero hace dos semanas la volví a ver y había bajado de precio, así que me la compré. Es la primera vez que compro algo a la tienda sure-electronics, y la verdad es que he quedado bastante satisfecho. La presentación de la placa es impecable, nada que envidiar a las placas oficiales de Microchip.


La placa es muy completa e incluye comunicación RS232, una pantalla LCD, 8 leds de usuario, 3 pulsadores, ranura para tarjeta SD, USB HOST y un enc28j60 para realizar la comunicación ethernet, el mismo que utilizamos con el PIC18, solo que en este caso, el cerebro de la placa es un PIC24FJ256GB106, un PIC de 16 bits, con 256kB de memoria, lo que hace que metiendo el stack y una página web normalita apenas lleguemos al 25% de capacidad del microcontrolador, así que se acabaron los problemas de espacio!!


Cuando me llegó la placa a casa traía un programa de ejemplo que se puede descargar desde la página de sure-electronics, el cual metiendo una página web en un pen drive, y accediendo a la dirección IP que aparece en el display, podemos interactuar con la placa, tanto con el LCD, Leds, pulsadores y canal UART. Aunque en mi caso ese programa duró poco ya que empecé a adaptar uno de los ejemplos de que nos da Microchip para, a partir de este, crear un programa nuevo. Esta vez, en vez de la aplicación Demo APP que utilicé en el PIC18, he decidido empezar con esta placa con el ejemplo WebVend APP, que simula una máquina expendedora en la que conectándonos a ella podemos ver la cantidad de productos que quedan en ella, encender o apagar las luces de esta y modificar el texto que aparece en el display. Este ejemplo está realizado en MPLAB X y el compilador XC16, pero no está diseñado para el microcontrolador que lleva la placa, así que como en el caso del PIC18, debemos cambiar las configuraciones, los pines de SPI, y de una forma relativamente facil, tenemos funcionando el ejemplo en la placa de sure-electronics.


A partir de este ejemplo, y dejándolo con lo básico para funcionar, podremos empezar a trabajar con este. En principio no voy a detallar tanto los programas que haga ya que la mayoría del código de control y monitorización que hice en el PIC18 nos valdrá para este ejemplo. Empezamos de nuevo con otro servidor web!!

domingo, 9 de septiembre de 2012

Servidor WEB desde cero. Placa (V)

Hola a todos!! por fin después de bastante tiempo, puedo decir que mi pequeño servidor web esta listo, y comienza una nueva fase  que es la fase de experimentar con el. Si habéis seguido el blog, desde hace tiempo, en una serie de entradas que podéis encontrar con la etiqueta Servidor Web, he estado contando como he diseñado un servidor web desde cero, el cual, lleva un PIC18LF4685 como núcleo central. Este microcontrolador, es un micro de gama media-alta de 8 bits, el cual he elegido porque dispone de 96k de memoria de programa. En la primera de las entradas fijamos unos objetivos, de los cuales unos se han conseguido, pero otros no, y en las siguientes entradas os expliqué como diseñar la parte del firmware que llevará dentro nuestro microcontrolador. Todos estos avances, aunque no os lo he mostrado, los estaba verificando sobre una placa de board de prototipos, en la cual estaba montado el micro, y una break-board que contenía toda la circuitería del controlador Ethernet ENC28j60. Este tipo de montaje está muy bien para probar, pero no para experimentar a fondo, así que, si ya teníamos los materiales, y habíamos preparado el firmware del circuito lo único que nos faltaba es llevar nuestro proyecto a una PCB.
Evidentemente, ya que vamos a fabricar una placa, lo ideal sería que tanto la parte del microcontrolador, como la parte del controlador Ethernet estuvieran montados ahí. La parte del microcontrolador no entraña ninguna dificultad, es simplemente el micro, y algunas entradas y salidas, todo esto corriendo con un oscilador de 10MHz, la parte más complicada del diseño, y que tenia dudas de que funcionara es la parte del ENC. En la siguiente figura os muestro el esquema de conexión que podemos encontrar en su datasheet.
image
Como ya os dije, un elemento fundamental de nuestra placa es el conector Ethernet, y este , tal y como vemos en el esquema, necesitamos que disponga de transformadores de aislamiento, y así ha sido, por lo que nuestro trabajo d diseño, comienza desde los transformadores hacia la izquierda. lo primero que vemos es una bonina que viene nombrada como Ferrite Bread, que tal y como nos dice en la nota 3 sirve para eliminar interferencias. Como no encontré un valor claro por ningún sitio, y había leído que era un elemento prescindible, así he hecho, por lo que no la encontrareis en mi diseño. Si seguimos mirando hacia la izquierda, el otro elemento que llama la atención, son las resistencias de 49,9 con una tolerancia del 1%. Estas resistencias, aunque las encontré por internet, y puesto que no son más que resistencias de pull-up y pull-down, decidí sustituirlas por dos resistencias en serie, una de 10 y otra de 39, con lo que tengo unas resistencias de 49 ohms, eso si, con una tolerancia del 1%. Y si bajamos la vista un poco, vemos una resistencia de 2,32k, que al igual que las otras he sustituido por dos resistencias de 2k2 y 120 ohms, lo que hacen 2k32, que es lo que nos pide. Los leds, en mi caso, van incluidos en el conector, y las resistencias son de 220 ohms.  Por último, como estoy utilizando un PIC de la serie LF, y lo alimento con 3,3 voltios, el Level Shift Logic no es necesario.
Cualquiera podría pensar que, tomando todas esas suposiciones, es muy difícil que el proyecto funcione, y así pensaba yo también, aunque no siempre las cosas son como esperamos!! y para no haceros esperar más, a continuación teneis unas fotos de mi SERVIDOR WEB. En primer lugar teneis una foto de como quedó el PCB recién pasado por el ácido.
2012-09-08-525
Y a continuación, tenéis una foto del servidor completamente montado.
2012-09-08-527
Como veis, tenemos el PIC arriba, y perpendicular a este tenéis el ENC, ambos con encapsulado PDIP. Y por último un video de funcionamiento.
Bien, por último os quiero contar una serie de problemas que he tenido y como los he solucionado, en primer lugar, había un pequeño error en el esquema inicial, por lo que la fuente de alimentación de 3,3 voltios integrada no funciona bien, de hecho en el video veis una mini placa que hay con un regulador, ese problema en los archivos que os adjunto está solucionado, otra cosa que pasaba es que el servidor no funcionaba siempre, es decir, lo conectaba una vez y funcionaba, y a los 2 minutos los volvía a conectar y no funcionaba, esto, en principio, lo he achacado a que en un primer momento estaba habilitado el AUTO_IP, de forma que es mi PC es que le da la IP, al quitarlo, y dejar preasignada la IP, el problema se ha solucionado y ahora funciona siempre. Como veis, la página web que utilizo en el video es la que había programado ya antes, por lo que solo manejo un led, además que la lectura de la temperatura es completamente errónea, ya que no hay nada conectado a esta, más adelante crearé una página web exclusiva para esta placa, y os dejaré el firmware completo para que lo podáis descargar, por ahora os voy a dejar el esquema utilizado y el PCB para que, si queréis, podáis fabricaros uno vosotros.
Por último deciros que aquí acaba la primera fase, y ahora que tengo una herramienta sólida con la que trabajar podré realizar diseños más complejos. También quiero dar las Gracias a mi novia Elena que me ha estado aguantando estos últimos días dejándome que le mostrara cada avance que conseguía.
A continuación tenéis los archivos de descarga: Esquema, PCB, Componentes.

jueves, 26 de julio de 2012

Servidor WEB desde cero. Control (IV)

Hasta ahora, en las entradas en las que os he hablado del servidor web hemos hablado en primer lugar de los elementos que nos hacian falta para poder construirnos uno, en la siguiente entrada hablamos de como adaptar el Stack TCPIP para hacerlo funcionar en un PIC que no fuera de la familia 8722 y os expliqué como introducir una página web en el PIC , y lo último que vimos fué la monitorización, es decir, adaptar nuestra página web y nuestro firmware para poder visualizar modificar el valor de las variables dinámicas que aparecen en la página web desde el microcontrolador. En esta entrada vamos a ver la ultima parte que nos queda, que es el control mediante web, es decir, poder controlar salidas del micro mediante acciones realizadas en la página web. Para ello, al igual que pasaba con la monitorización necesitamos, en primer lugar modificar nuestro sitio web, en este caso añadiendo formularios, y después, habrá que modificar nuestro firmware para que el pic sea capaz de enlazar el valor de esos formularios, con las variables que queramos modificar, así pues, empecemos.
En primer lugar, como hicimos en el caso de la monitorización, vamos a ver que modificaciones tenemos que hacer en la página web. Como he dicho antes, lo que tenemos que hacer es añadir formularios. Los formularios son secciones de código html en los que podemos introducir controles como botones, checkboxes, radio_buttons e interactuar con ellos. La forma que la página web informa al servidor de la acción que ha ejecutado el usuario la podemos hacer de dos formas (métodos) diferentes. En primer lugar tenemos el método “get”, el cual plasma las acciones del usuario en la URL de la página web. Por ejemplo, si entramos en la página de google y tecleamos algo para que lo busque, cuando presionamos “buscar”, veremos que en la barra de dirección aparece una nueva dirección, por ejemplo, cuando buscamos “mips and chips”, vemos:
www.google.es/#hl=es&sclient=psy-ab&q=mips+and+chips&…
Si analizamos la dirección tenemos en primer lugar el nombre del servidor como es “www.google.es”, después tenemos los diferentes campos separados por el carácter “&”, y su valor, por ejemplo vemos que hay un campo llamado hl cuyo valor es es, otro campo es sclient cuyo valor es psy-ab, y el último que vemos es el campo q cuyo valor es mips+and+chips. La dirección realmente contiene muchos más campos que siguen la misma estructura. El otro método que existe es el método “post”, el cual la información se plasma en el mismo formulario. Este método es más complicado de utilizar, pero permite enviar muchos más datos. En esta entrada voy a trabajar tan solo en método get, ya que es lo suficientemente potente como para crear aplicaciones de una complejidad media alta.
Lo primero que debemos hacer para habilitar nuestra página para que de órdenes a nuestro micro es, como hemos dicho antes crear formularios, y dentro de estos, crear controles, por ejemplo, vamos a crear 2 radio_buttons que nos permitan poner un led en ON, o en OFF, y después un elemento del tipo submit que nos permita enviar ese comando al PIC.
<form method="get" action="index.htm">
 
    <fieldset>
 
    <span id="led">Estado de la entrada : ~led~<br>
 
    Estado de la salida : </span>&nbsp; 
 
    <input name="salida" type="radio" value="on" ~lights_chk(1)~ /> On
    <input name="salida" type="radio" value="off" ~lights_chk(0)~ /> Off
    
    &nbsp &nbsp <input type="submit" value="Enviar"/> 
    <br> Temperatura de la habitación:&nbsp ~temperatura~ ºC    
 
    </fieldset>
 
</form>
Hemos aprovechado y hemos metido también todas las variables de la monitorización para tenerlo todo más agrupado. Como se ve, los dos radio_buttons tienen el mismo parámetro “name”, de forma que los dos forman un único control y cuando uno está seleccionado el otro se deselecciona. El control submit es necesario para que se actualice la página y cambie la URL de la página de forma ue mandemos la orden al pic. En la página se verá algo como esto:
image
Lo siguiente es la modificación del firmware. El stack de microchip nos permite utilizar cualquiera de los dos métodos, y como en el caso de la monitorización, las funciones que realizan estas acciones se encentran en el archivo CustomHTTPAPP.c, donde encontramos el siguiente código:

HTTP_IO_RESULT HTTPExecuteGet(void)
{
// #### AQUÍ NUESTRO CÓDIGO GET
    return HTTP_IO_DONE;
}
 
#if defined(HTTP_USE_POST)
HTTP_IO_RESULT HTTPExecutePost(void)
{
    // #### AQUÍ NUESTRO CÓDIGO POST
    return HTTP_IO_DONE;
}
#endif
Tenemos 2 funciones, una para cada tipo, la HTTPExecuteGet se encarga de las llamadas de los formularios con método get, y la HTTPExecutePost que hace lo mismo para el método post. Como he dicho antes, nos vamos a centrar en el método get, ya que es más sencillo y es suficientemente potente. A continuación os pongo un ejemplo sencillo de código para la función HTTPExecuteGet:

HTTP_IO_RESULT HTTPExecuteGet(void)
{
    BYTE *ptr, name[20];
 
    // Obtenemos el nombre de archivo .htm
    MPFSGetFilename(curHTTP.file, name, 20);
    
    // Nos aseguramos que estamos en el .htm correcto
    if(strcmppgm2ram((char*)name, (ROM char*)"index.htm") != 0)
        return HTTP_IO_DONE;
    
    // Obtenemos el valor del control con el nombre "salida"
    ptr = HTTPGetROMArg(curHTTP.data, (ROM BYTE *)"salida");
    if(ptr)    
    {// Si el valor del control es on, ponemos LED1_IO = 1, si no, LED_IO = 0
        if(strcmppgm2ram((char*)ptr, (ROM char*)"on") == 0)
        {
            LED1_IO = 1;
        }
        else
        {
            LED1_IO = 0;
        }
    }    
    return HTTP_IO_DONE;
}
Lo primero que hacemos es comprobar que nos encontramos en la página correcta, para ello, una vez obtenido el nombre de la página, con la función strcmppgm2ram, comparamos la cadena obtenida, y el nombre correcto, si el resultado es 0, significa que son iguales, por tanto estamos en la página correcta, si no estamos en la página correcta salimos de la función. A continuación con la instrucción HTTPGetROMArg, obtenemos el valor del control con el nombre “salida”, y almacenamos su valor en la variable *ptr, y al igual que antes lo comparamos con la cadena “on”, y si es igual, ponemos el led a 1, si es diferente lo ponemos a cero.
Como veis no tiene mucha dificultad y es muy vistoso. Una vez hecho esto, ya podemos tanto monitorizar variables como controlar salidas del micro. Lo próximo es diseñar nuestro circuito y transferirlo a un PCB. Como ahora viene el mes de agosto, y tengo cosas que terminar, la fabricación de la placa la dejaré para más adelante, así que tened paciencia!!

viernes, 13 de julio de 2012

Servidor WEB desde cero. Monitorización(III)

Aunque pensaba que en una sola entrada podría explicar todo lo referente al firmware del servidor web, me he dado cuenta que si quiero explicarlo bien deberé hacerlo en varias entradas. En las entradas anteriores he hablado de, en primer lugar de los materiales que vamos a utilizar, y en segundo lugar os hablé de como modificar el stack para utilizar un PIC de una familia diferente a la familia por defecto, y como introducir una página web en nuestro micro. El siguiente paso es la monitorización, es decir, poder observar variables del microcontrolador desde la interfaz web. Para ello tenemos que hacer dos cosas, en primer lugar modificar nuestra página web para que incluya variables dinámicas, y en segundo lugar, modificar el firmware para que el micro de valor a esas variables dinámicas.
Lo primero que vamos a hacer es modificar nuestra página web para introducir en ella variables dinámicas. Estas variables, cuando se cargue la página, esta le pedirán al micro el valor de esas variables, este se las devolverá y aparecerán en la página web. Incluir variables dinámicas en páginas web es tan fácil como poner el nombre de la variable de esta forma: ~nombre_variable~, por ejemplo:
<span>Estado de la entrada : ~led~</span>
De esta forma, cuando el micro llegue a esta línea, sustituirá el texto ~led~, por lo que nosotros queramos. La página quedará de la siguiente manera.

image
Bien, una vez preparada la página web, tenemos que modificar el firmware del micro para que sea capaz de sustituir el nombre de esas variables, por su valor. Para ello tenemos que modificar el archivo CustomHTTPApp.c. En archivo se encuentran las callback, las cuales son llamadas a funciones que darán valor a las variables dinámicas. Las Callback tienen la siguiente forma:

void HTTPPrint_NombreVariable(void)
{    
TCPPutROMString(sktHTTP, [valor asignado]);
}
Hay que tener en cuenta que por ethernet solo podemos enviar strings, por lo que utilizaremos bastantes las sentencias del tipo itoa. Por ejemplo, si queremos que la variable led valga “on” cuando el led1 este encendido, y valga “off” cuando el led1 esté apagado, sería algo así.

void HTTPPrint_led(void)
{    
TCPPutROMString(sktHTTP, (LED1_IO?"ON":"OFF"));
}
y si queremos, por ejemplo mostrar una temperatura que adquirimos desde un sensor analógico sería algo así:

void HTTPPrint_temperatura(void)
{    
    BYTE AN0String[8];    
    unsigned int ADval;    
    WORD ADval_ch;    
    ADCON0 = 0x02;    
    while(ADCON0bits.GO);        
    ADval = ADRESH;    
    ADval = ADval * 330;    
    ADval = ADval / 255;   
    ADval = ADval - 50;    
    ADval_ch = (WORD)ADval;    
    uitoa(ADval_ch, AN0String);       
    TCPPutString(sktHTTP, AN0String);
}
De forma que nuestra página quedará se verá de la siguiente forma:
image
En la próxima entrada os explicaré el tema de control mediante WEB, que aunque es sencillo también, lleva más tiempo que la monitorización.

lunes, 9 de julio de 2012

Servidor WEB desde cero. (II)

Voy a seguir con esta pequeña aventura que he empezado y que por ahora parece que va viento en popa. En la entrada Servidor WEB desde cero. (I), fue donde os puse todos los materiales que había comprado para fabricar mi propio servidor, en esta entrada vamos a empezar crear el firmware que irá dentro del micro con el que vamos a hacer que nuestro servidor funcione. Os dije que quería utilizar un PIC18LF4685, pues ese es el que voy a utilizar y ahora os voy a comentar los cambios que hay que hacer en el firmware.
Como dije en la entrada anterior, vamos a partir del la aplicación Demo App que se instala junto a las Microchip aplication libraries que podéis descargar de aquí. El primer archivo que vamos a modificar para hacerlo funcionar en el PIC18f4685 es el Hardware Profile, que en el proyecto se llama HWP PIC18EX_ENC28.h. 
#ifndef HARDWARE_PROFILE_H
#define HARDWARE_PROFILE_H
 
#include "Compiler.h"
 
// Define a macro describing this hardware set up (used in other files)
#define PIC18_EXPLORER
 
// Set configuration fuses (but only in MainDemo.c where THIS_IS_STACK_APPLICATION is defined)
#if defined(THIS_IS_STACK_APPLICATION)
 
//CONFIGURACIÓN PARA PIC18F4685
        #pragma config OSC = HSPLL, FCMEN = OFF, IESO = OFF, WDT=OFF, LVP=OFF
 
    // Automatically set Extended Instruction Set fuse based on compiler setting
    #if defined(__EXTENDED18__)
        #pragma config XINST=ON
    #else
        #pragma config XINST=OFF
    #endif
#endif
 
 
// Clock frequency values
#define GetSystemClock()    (40000000ul)
 
#define GetInstructionClock()    (GetSystemClock()/4)    // Should be GetSystemClock()/4 for PIC18
#define GetPeripheralClock()    (GetSystemClock()/4)    // Should be GetSystemClock()/4 for PIC18
 
 
// Hardware I/O pin mappings
 
// LEDs
#define LED0_TRIS            (TRISDbits.TRISD0)    // Ref D1
#define LED0_IO                (LATDbits.LATD0)
#define LED1_TRIS            (TRISDbits.TRISD1)    // Ref D2
#define LED1_IO                (LATDbits.LATD1)
#define LED2_TRIS            (TRISDbits.TRISD2)    // Ref D3
#define LED2_IO                (LATDbits.LATD2)
#define LED3_TRIS            (TRISDbits.TRISD3)    // Ref D4
#define LED3_IO                (LATDbits.LATD3)
#define LED4_TRIS            (TRISDbits.TRISD4)    // Ref D5
#define LED4_IO                (LATDbits.LATD4)
#define LED5_TRIS            (TRISDbits.TRISD5)    // Ref D6
#define LED5_IO                (LATDbits.LATD5)
#define LED6_TRIS            (TRISDbits.TRISD6)    // Ref D7
#define LED6_IO                (LATDbits.LATD6)
#define LED7_TRIS            (TRISDbits.TRISD7)    // Ref D8
#define LED7_IO                (LATDbits.LATD7)
#define LED_GET()            (LATD)
#define LED_PUT(a)            (LATD = (a))
 
// Momentary push buttons
#define BUTTON0_TRIS        (TRISAbits.TRISA5)
#define    BUTTON0_IO            (PORTAbits.RA5)
#define BUTTON1_TRIS        (TRISBbits.TRISB0)
#define    BUTTON1_IO            (PORTBbits.RB0)
#define BUTTON2_TRIS        (TRISBbits.TRISB0)    // No Button2 on this board
#define    BUTTON2_IO            (1u)
#define BUTTON3_TRIS        (TRISBbits.TRISB0)    // No Button3 on this board
#define    BUTTON3_IO            (1u)
 
// ENC28J60 I/O pins
#define ENC_RST_TRIS        (TRISBbits.TRISB5)
#define ENC_RST_IO            (LATBbits.LATB5)
#define ENC_CS_TRIS            (TRISBbits.TRISB3)
#define ENC_CS_IO            (LATBbits.LATB3)
#define ENC_SCK_TRIS        (TRISCbits.TRISC3)
#define ENC_SDI_TRIS        (TRISCbits.TRISC4)
#define ENC_SDO_TRIS        (TRISCbits.TRISC5)
#define ENC_SPI_IF            (PIR1bits.SSPIF)
#define ENC_SSPBUF            (SSPBUF)
#define ENC_SPISTAT            (SSPSTAT)
#define ENC_SPISTATbits        (SSPSTATbits)
#define ENC_SPICON1            (SSPCON1)
#define ENC_SPICON1bits        (SSPCON1bits)
#define ENC_SPICON2            (SSPCON2)
 
// LCD I/O pins
// TODO: Need to add support for LCD behind MCP23S17 I/O expander.  This 
// requires code that isn't in the TCP/IP stack, not just a hardware 
// profile change.
 
// UART mapping functions for consistent API names across 8-bit and 16 or 
// 32 bit compilers.  For simplicity, everything will use "UART" instead 
// of USART/EUSART/etc.
#define BusyUART()            BusyUSART()
#define CloseUART()            CloseUSART()
#define ConfigIntUART(a)    ConfigIntUSART(a)
#define DataRdyUART()        DataRdyUSART()
#define OpenUART(a,b,c)        OpenUSART(a,b,c)
#define ReadUART()            ReadUSART()
#define WriteUART(a)        WriteUSART(a)
#define getsUART(a,b,c)        getsUSART(b,a)
#define putsUART(a)            putsUSART(a)
#define getcUART()            ReadUSART()
#define putcUART(a)            WriteUSART(a)
#define putrsUART(a)        putrsUSART((far rom char*)a)
 
#endif // #ifndef HARDWARE_PROFILE_H
Lo principal que hemos modificado en este archivo son las configuraciones del micro, utilizando los pragma configs correspondientes para cada PIC. A partir de como lo hayamos configurado, debemos también cambiar el #define GetSystemClock() por la frecuencia a la que va a funciona nuestro micro, en mi caso, utilizo un cristal de 10Mz, y he configurado el PLL para que multiplique por 4 esta frecuencia por lo que tengo una frecuencia de 40MHz. Otra cosa que debéis modificar según el micro que utilicéis es la posición de los pines de comunicación SPI que son SCK, SDI y SDO. Los pines CS y RST los podéis configurar en el pin que queráis.
El siguiente archivo que vamos a modificar es el MainDemo.c. Este es el programa principal, y básicamente lo que he hecho ha sido eliminar todo lo que no voy a utilizar como memoria, wifi, uart o lcd y me ha quedado así.

#define THIS_IS_STACK_APPLICATION
 
// Include all headers for any enabled TCPIP Stack functions
#include "TCPIP Stack/TCPIP.h"
 
#if defined(STACK_USE_ZEROCONF_LINK_LOCAL)
#include "TCPIP Stack/ZeroconfLinkLocal.h"
#endif
#if defined(STACK_USE_ZEROCONF_MDNS_SD)
#include "TCPIP Stack/ZeroconfMulticastDNS.h"
#endif
 
#include "MainDemo.h"
 
// Declare AppConfig structure and some other supporting stack variables
APP_CONFIG AppConfig;
static unsigned short wOriginalAppConfigChecksum;    // Checksum of the ROM defaults for AppConfig
 
static void InitAppConfig(void);
static void InitializeBoard(void);
static void ProcessIO(void);
 
    #pragma interruptlow LowISR    // Interrupciones de baja prioridad
    void LowISR(void)
    {
        TickUpdate();
    }
    
 
    #pragma interruptlow HighISR // Interrupciones de alta prioridad
    void HighISR(void)
    {
 
    }
 
 
    #pragma code lowVector=0x18
    void LowVector(void){_asm goto LowISR _endasm}
    #pragma code highVector=0x8
    void HighVector(void){_asm goto HighISR _endasm}
    #pragma code // Return to default code section
 
//
// Main application entry point.
//
 
void main(void)
{
    static DWORD t = 0;
    static DWORD dwLastIP = 0;
 
    // Inicializamos la placa
    InitializeBoard();
 
    //Inicializamos la rutina que hace que parpadee el led.
    //Utiliza el TMR1, por lo que este queda inutilizado. (tick.c)
    TickInit();
    
    // Inicializamos los archivos del STACK.
    MPFSInit();
    InitAppConfig();
    StackInit();
 
    
    while(1)
    {
        // Invierte la señal del led cada segundo
        if(TickGet() - t >= TICK_SECOND/2ul)
        {
            t = TickGet();
            LED0_IO ^= 1;
        }
        
        // Tareas delk STACK
        StackTask();
        StackApplications();
        
        PingDemo(); //esta aplicación permite al STACK responder a PINGs
 
        ProcessIO();
 
        // Comprobamos si la dirección IP ha cambiado, si es así mostramos la nueva direccion IP.
        if(dwLastIP != AppConfig.MyIPAddr.Val)
        {
            dwLastIP = AppConfig.MyIPAddr.Val;
            
            DisplayIPValue(AppConfig.MyIPAddr);
 
        }
    }
}
 
// Mostramos la direccion IP en el LCD
void DisplayIPValue(IP_ADDR IPVal)
{
    //#####################################################
    // Lo dejamos en blanco de momento,luego crearemos un #
    //programa que haga que la placa muestre la IP en un  #
    // LCD de 16x2 ########################################
    //#####################################################
}
 
static void ProcessIO(void)
{    
    //#####################################################
    // AQUÍ VA NUESTRO CÓDIGO #############################
    //#####################################################
}
 
/****************************************************************
    Función: InitializeBoard(void)
Esta función se encarga de inicializar la placa se´gun el hardware 
que tengamos conectado, lo utilizaremos tambien más tarde para 
incializar el LCD, o la comunicación UART si la implementamos
*****************************************************************/
static void InitializeBoard(void)
{    
    // LEDs
    LED0_TRIS = 0;
    LED1_TRIS = 0;
    LED2_TRIS = 0;
    LED3_TRIS = 0;
    LED4_TRIS = 0;
    LED5_TRIS = 0;
    LED6_TRIS = 0;
    LED7_TRIS = 0;
    LED_PUT(0x00);
 
    // Enable internal PORTB pull-ups
    INTCON2bits.RBPU = 0;
 
    // Enable Interrupts
    RCONbits.IPEN = 1;        // Enable interrupt priorities
    INTCONbits.GIEH = 1;
    INTCONbits.GIEL = 1;
 
    //INICIALIZACION DEL PIN CHIP SELECT DEL ENC
    ENC_CS_IO = 1;
    ENC_CS_TRIS = 0;
 
    
}
 
/****************************************************************
    Función: InitAppCondig(void)
Esta función inicializa variables del stack, hemos eliminado 
toda la inicialización referente a memorias y WIFI.
*****************************************************************/
 
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};
 
 
static void InitAppConfig(void)
{
    while(1)
    {
        // Start out zeroing all AppConfig bytes to ensure all fields are 
        // deterministic for checksum generation
        memset((void*)&AppConfig, 0x00, sizeof(AppConfig));
        
        AppConfig.Flags.bIsDHCPEnabled = TRUE;
        AppConfig.Flags.bInConfigMode = TRUE;
        memcpypgm2ram((void*)&AppConfig.MyMACAddr, (ROM void*)SerializedMACAddress, sizeof(AppConfig.MyMACAddr));
//        {
//            _prog_addressT MACAddressAddress;
//            MACAddressAddress.next = 0x157F8;
//            _memcpy_p2d24((char*)&AppConfig.MyMACAddr, MACAddressAddress, sizeof(AppConfig.MyMACAddr));
//        }
        AppConfig.MyIPAddr.Val = MY_DEFAULT_IP_ADDR_BYTE1 | MY_DEFAULT_IP_ADDR_BYTE2<<8ul | MY_DEFAULT_IP_ADDR_BYTE3<<16ul | MY_DEFAULT_IP_ADDR_BYTE4<<24ul;
        AppConfig.DefaultIPAddr.Val = AppConfig.MyIPAddr.Val;
        AppConfig.MyMask.Val = MY_DEFAULT_MASK_BYTE1 | MY_DEFAULT_MASK_BYTE2<<8ul | MY_DEFAULT_MASK_BYTE3<<16ul | MY_DEFAULT_MASK_BYTE4<<24ul;
        AppConfig.DefaultMask.Val = AppConfig.MyMask.Val;
        AppConfig.MyGateway.Val = MY_DEFAULT_GATE_BYTE1 | MY_DEFAULT_GATE_BYTE2<<8ul | MY_DEFAULT_GATE_BYTE3<<16ul | MY_DEFAULT_GATE_BYTE4<<24ul;
        AppConfig.PrimaryDNSServer.Val = MY_DEFAULT_PRIMARY_DNS_BYTE1 | MY_DEFAULT_PRIMARY_DNS_BYTE2<<8ul  | MY_DEFAULT_PRIMARY_DNS_BYTE3<<16ul  | MY_DEFAULT_PRIMARY_DNS_BYTE4<<24ul;
        AppConfig.SecondaryDNSServer.Val = MY_DEFAULT_SECONDARY_DNS_BYTE1 | MY_DEFAULT_SECONDARY_DNS_BYTE2<<8ul  | MY_DEFAULT_SECONDARY_DNS_BYTE3<<16ul  | MY_DEFAULT_SECONDARY_DNS_BYTE4<<24ul;
    
    
        // Load the default NetBIOS Host Name
        memcpypgm2ram(AppConfig.NetBIOSName, (ROM void*)MY_DEFAULT_HOST_NAME, 16);
        FormatNetBIOSName(AppConfig.NetBIOSName);
    
        // Compute the checksum of the AppConfig defaults as loaded from ROM
        wOriginalAppConfigChecksum = CalcIPChecksum((BYTE*)&AppConfig, sizeof(AppConfig));
 
        break;
    }
}
 
He dejado el archivo main muy reducido de forma que se entienda todo lo que hay en el. Hay funciones que no he implementado todavía como DisplayIp(IPAddres), ya que en un principio dije que no iba a poner LCD pero he estado revisando los pines y quizás tenga suficientes, así que lo dejo preparado por si luego quisiera. La otra función que está vacía es ProcessIO(), ya que en la aplicación que he preparado, no ha hecho falta poner nada aquí, pero si nuestra aplicación debe hacer cosas a parte de su función como servidor, irá aquí.
Por último el archivo que debemos modificar es el TCPIPConfig.h, en este, como ya comenté le decimos al STACK que funciones vamos a utilizar y que funciones no, a parte de la dirección IP por defecto, o el nombre del HOST. Queda así.

#ifndef __TCPIPCONFIG_H
#define __TCPIPCONFIG_H
 
#include "GenericTypeDefs.h"
#include "Compiler.h"
#define GENERATED_BY_TCPIPCONFIG "Version 1.0.4168.28618"
 
// =======================================================================
//   Application Options
// =======================================================================
 
/* Application Level Module Selection
 *   Uncomment or comment the following lines to enable or
 *   disabled the following high-level application modules.
 */
//#define STACK_USE_UART                    // Application demo using UART for IP address display and stack configuration
//#define STACK_USE_UART2TCP_BRIDGE        // UART to TCP Bridge application example
//#define STACK_USE_IP_GLEANING
#define STACK_USE_ICMP_SERVER            // Ping query and response capability
#define STACK_USE_ICMP_CLIENT            // Ping transmission capability
#define STACK_USE_HTTP2_SERVER            // New HTTP server with POST, Cookies, Authentication, etc.
//#define STACK_USE_SSL_SERVER            // SSL server socket support (Requires SW300052)
//#define STACK_USE_SSL_CLIENT            // SSL client socket support (Requires SW300052)
//#define STACK_USE_AUTO_IP               // Dynamic link-layer IP address automatic configuration protocol
//#define STACK_USE_DHCP_CLIENT            // Dynamic Host Configuration Protocol client for obtaining IP address and other parameters
//#define STACK_USE_DHCP_SERVER            // Single host DHCP server
//#define STACK_USE_FTP_SERVER            // File Transfer Protocol (old)
//#define STACK_USE_SMTP_CLIENT            // Simple Mail Transfer Protocol for sending email
//#define STACK_USE_SNMP_SERVER            // Simple Network Management Protocol v2C Community Agent
//#define STACK_USE_SNMPV3_SERVER            // Simple Network Management Protocol v3 Agent
//#define STACK_USE_TFTP_CLIENT            // Trivial File Transfer Protocol client
//#define STACK_USE_GENERIC_TCP_CLIENT_EXAMPLE    // HTTP Client example in GenericTCPClient.c
//#define STACK_USE_GENERIC_TCP_SERVER_EXAMPLE    // ToUpper server example in GenericTCPServer.c
//#define STACK_USE_TELNET_SERVER            // Telnet server
#define STACK_USE_ANNOUNCE                // Microchip Embedded Ethernet Device Discoverer server/client
#define STACK_USE_DNS                    // Domain Name Service Client for resolving hostname strings to IP addresses
//#define STACK_USE_DNS_SERVER            // Domain Name Service Server for redirection to the local device
#define STACK_USE_NBNS                    // NetBIOS Name Service Server for repsonding to NBNS hostname broadcast queries
#define STACK_USE_REBOOT_SERVER            // Module for resetting this PIC remotely.  Primarily useful for a Bootloader.
#define STACK_USE_SNTP_CLIENT            // Simple Network Time Protocol for obtaining current date/time from Internet
//#define STACK_USE_UDP_PERFORMANCE_TEST    // Module for testing UDP TX performance characteristics.  NOTE: Enabling this will cause a huge amount of UDP broadcast packets to flood your network on the discard port.  Use care when enabling this on production networks, especially with VPNs (could tunnel broadcast traffic across a limited bandwidth connection).
//#define STACK_USE_TCP_PERFORMANCE_TEST    // Module for testing TCP TX performance characteristics
//#define STACK_USE_DYNAMICDNS_CLIENT        // Dynamic DNS client updater module
//#define STACK_USE_BERKELEY_API            // Berekely Sockets APIs are available
//#define STACK_USE_ZEROCONF_LINK_LOCAL    // Zeroconf IPv4 Link-Local Addressing
//#define STACK_USE_ZEROCONF_MDNS_SD        // Zeroconf mDNS and mDNS service discovery
 
 
// =======================================================================
//   Data Storage Options
// =======================================================================
 
/* MPFS Configuration
 *   MPFS is automatically included when required for other
 *   applications.  If your custom application requires it
 *   otherwise, uncomment the appropriate selection.
 */
#define STACK_USE_MPFS2
 
/* MPFS Storage Location
 *   If html pages are stored in internal program memory,
 *   comment both MPFS_USE_EEPROM and MPFS_USE_SPI_FLASH, then
 *   include an MPFS image (.c or .s file) in the project.
 *   If html pages are stored in external memory, uncomment the
 *   appropriate definition.
 *
 *   Supported serial flash parts include the SST25VFxxxB series.
 */
//#define MPFS_USE_EEPROM
//#define MPFS_USE_SPI_FLASH
 
/* EEPROM Addressing Selection
 *   If using the 1Mbit EEPROM, uncomment this line
 */
//#define USE_EEPROM_25LC1024
 
/* EEPROM Reserved Area
 *   Number of EEPROM bytes to be reserved before MPFS storage starts.
 *   These bytes host application configurations such as IP Address,
 *   MAC Address, and any other required variables.
 *
 *   For MPFS Classic, this setting must match the Reserved setting
 *     on the Advanced Settings page of the MPFS2 Utility.
 */
#define MPFS_RESERVE_BLOCK                (137ul)
 
/* MPFS File Handles
 *   Maximum number of simultaneously open MPFS2 files.
 *   For MPFS Classic, this has no effect.
 */
#define MAX_MPFS_HANDLES                (7ul)
 
 
// =======================================================================
//   Network Addressing Options
// =======================================================================
 
/* Default Network Configuration
 *   These settings are only used if data is not found in EEPROM.
 *   To clear EEPROM, hold BUTTON0, reset the board, and continue
 *   holding until the LEDs flash.  Release, and reset again.
 */
//#define MY_DEFAULT_HOST_NAME            "MCHPBOARD"
#define MY_DEFAULT_HOST_NAME            "MIPSBOARD"
 
#define MY_DEFAULT_MAC_BYTE1            (0x00)    // Use the default of 00-04-A3-00-00-00
#define MY_DEFAULT_MAC_BYTE2            (0x04)    // if using an ENCX24J600, MRF24WB0M, or
#define MY_DEFAULT_MAC_BYTE3            (0xA3)    // PIC32MX6XX/7XX internal Ethernet 
#define MY_DEFAULT_MAC_BYTE4            (0x00)    // controller and wish to use the 
#define MY_DEFAULT_MAC_BYTE5            (0x00)    // internal factory programmed MAC
#define MY_DEFAULT_MAC_BYTE6            (0x00)    // address instead.
 
#define MY_DEFAULT_IP_ADDR_BYTE1        (169ul)
#define MY_DEFAULT_IP_ADDR_BYTE2        (254ul)
#define MY_DEFAULT_IP_ADDR_BYTE3        (1ul)
#define MY_DEFAULT_IP_ADDR_BYTE4        (1ul)
 
#define MY_DEFAULT_MASK_BYTE1           (255ul)
#define MY_DEFAULT_MASK_BYTE2           (255ul)
#define MY_DEFAULT_MASK_BYTE3           (0ul)
#define MY_DEFAULT_MASK_BYTE4           (0ul)
 
#define MY_DEFAULT_GATE_BYTE1           (169ul)
#define MY_DEFAULT_GATE_BYTE2           (254ul)
#define MY_DEFAULT_GATE_BYTE3           (1ul)
#define MY_DEFAULT_GATE_BYTE4           (1ul)
 
#define MY_DEFAULT_PRIMARY_DNS_BYTE1    (169ul)
#define MY_DEFAULT_PRIMARY_DNS_BYTE2    (254ul)
#define MY_DEFAULT_PRIMARY_DNS_BYTE3    (1ul)
#define MY_DEFAULT_PRIMARY_DNS_BYTE4    (1ul)
 
#define MY_DEFAULT_SECONDARY_DNS_BYTE1    (0ul)
#define MY_DEFAULT_SECONDARY_DNS_BYTE2    (0ul)
#define MY_DEFAULT_SECONDARY_DNS_BYTE3    (0ul)
#define MY_DEFAULT_SECONDARY_DNS_BYTE4    (0ul)
 
// =======================================================================
//   PIC32MX7XX/6XX MAC Layer Options
//   If not using a PIC32MX7XX/6XX device, ignore this section.
// =======================================================================
#define    ETH_CFG_LINK            0        // set to 1 if you need to config the link to specific following parameters
                                        // otherwise the default connection will be attempted
                                        // depending on the selected PHY
    #define    ETH_CFG_AUTO        1        // use auto negotiation
    #define    ETH_CFG_10            1        // use/advertise 10 Mbps capability
    #define    ETH_CFG_100            1        // use/advertise 100 Mbps capability
    #define    ETH_CFG_HDUPLEX        1        // use/advertise half duplex capability
    #define    ETH_CFG_FDUPLEX        1        // use/advertise full duplex capability
    #define    ETH_CFG_AUTO_MDIX    1        // use/advertise auto MDIX capability
    #define    ETH_CFG_SWAP_MDIX    1        // use swapped MDIX. else normal MDIX
 
#define EMAC_TX_DESCRIPTORS        2        // number of the TX descriptors to be created
#define EMAC_RX_DESCRIPTORS        8        // number of the RX descriptors and RX buffers to be created
 
#define    EMAC_RX_BUFF_SIZE        1536    // size of a RX buffer. should be multiple of 16
                                        // this is the size of all receive buffers processed by the ETHC
                                        // The size should be enough to accomodate any network received packet
                                        // If the packets are larger, they will have to take multiple RX buffers
                                        // The current implementation does not handle this situation right now and the packet is discarded.
 
 
// =======================================================================
//   Transport Layer Options
// =======================================================================
 
/* Transport Layer Configuration
 *   The following low level modules are automatically enabled
 *   based on module selections above.  If your custom module
 *   requires them otherwise, enable them here.
 */
//#define STACK_USE_TCP
//#define STACK_USE_UDP
 
/* Client Mode Configuration
 *   Uncomment following line if this stack will be used in CLIENT
 *   mode.  In CLIENT mode, some functions specific to client operation
 *   are enabled.
 */
#define STACK_CLIENT_MODE
 
/* TCP Socket Memory Allocation
 *   TCP needs memory to buffer incoming and outgoing data.  The
 *   amount and medium of storage can be allocated on a per-socket
 *   basis using the example below as a guide.
 */
    // Allocate how much total RAM (in bytes) you want to allocate
    // for use by your TCP TCBs, RX FIFOs, and TX FIFOs.
    #define TCP_ETH_RAM_SIZE                    (1238ul)
    #define TCP_PIC_RAM_SIZE                    (0ul)
    #define TCP_SPI_RAM_SIZE                    (0ul)
    #define TCP_SPI_RAM_BASE_ADDRESS            (0x00)
 
    // Define names of socket types
    #define TCP_SOCKET_TYPES
        #define TCP_PURPOSE_GENERIC_TCP_CLIENT 0
        #define TCP_PURPOSE_GENERIC_TCP_SERVER 1
        #define TCP_PURPOSE_TELNET 2
        #define TCP_PURPOSE_FTP_COMMAND 3
        #define TCP_PURPOSE_FTP_DATA 4
        #define TCP_PURPOSE_TCP_PERFORMANCE_TX 5
        #define TCP_PURPOSE_TCP_PERFORMANCE_RX 6
        #define TCP_PURPOSE_UART_2_TCP_BRIDGE 7
        #define TCP_PURPOSE_HTTP_SERVER 8
        #define TCP_PURPOSE_DEFAULT 9
        #define TCP_PURPOSE_BERKELEY_SERVER 10
        #define TCP_PURPOSE_BERKELEY_CLIENT 11
    #define END_OF_TCP_SOCKET_TYPES
 
    #if defined(__TCP_C)
        // Define what types of sockets are needed, how many of
        // each to include, where their TCB, TX FIFO, and RX FIFO
        // should be stored, and how big the RX and TX FIFOs should
        // be.  Making this initializer bigger or smaller defines
        // how many total TCP sockets are available.
        //
        // Each socket requires up to 56 bytes of PIC RAM and
        // 48+(TX FIFO size)+(RX FIFO size) bytes of TCP_*_RAM each.
        //
        // Note: The RX FIFO must be at least 1 byte in order to
        // receive SYN and FIN messages required by TCP.  The TX
        // FIFO can be zero if desired.
        #define TCP_CONFIGURATION
        ROM struct
        {
            BYTE vSocketPurpose;
            BYTE vMemoryMedium;
            WORD wTXBufferSize;
            WORD wRXBufferSize;
        } TCPSocketInitializer[] = 
        {
            //{TCP_PURPOSE_GENERIC_TCP_CLIENT, TCP_ETH_RAM, 125, 100},
            //{TCP_PURPOSE_GENERIC_TCP_SERVER, TCP_ETH_RAM, 20, 20},
            //{TCP_PURPOSE_TELNET, TCP_ETH_RAM, 200, 150},
            //{TCP_PURPOSE_TELNET, TCP_ETH_RAM, 200, 150},
            //{TCP_PURPOSE_TELNET, TCP_ETH_RAM, 200, 150},
            //{TCP_PURPOSE_FTP_COMMAND, TCP_ETH_RAM, 100, 40},
            //{TCP_PURPOSE_FTP_DATA, TCP_ETH_RAM, 0, 128},
            {TCP_PURPOSE_TCP_PERFORMANCE_TX, TCP_ETH_RAM, 200, 1},
            //{TCP_PURPOSE_TCP_PERFORMANCE_RX, TCP_ETH_RAM, 40, 1500},
            //{TCP_PURPOSE_UART_2_TCP_BRIDGE, TCP_ETH_RAM, 256, 256},
            {TCP_PURPOSE_HTTP_SERVER, TCP_ETH_RAM, 200, 200},
            {TCP_PURPOSE_HTTP_SERVER, TCP_ETH_RAM, 200, 200},
            //{TCP_PURPOSE_DEFAULT, TCP_ETH_RAM, 200, 200},
            {TCP_PURPOSE_BERKELEY_SERVER, TCP_ETH_RAM, 25, 20},
            //{TCP_PURPOSE_BERKELEY_SERVER, TCP_ETH_RAM, 25, 20},
            //{TCP_PURPOSE_BERKELEY_SERVER, TCP_ETH_RAM, 25, 20},
            //{TCP_PURPOSE_BERKELEY_CLIENT, TCP_ETH_RAM, 125, 100},
        };
        #define END_OF_TCP_CONFIGURATION
    #endif
 
/* UDP Socket Configuration
 *   Define the maximum number of available UDP Sockets, and whether
 *   or not to include a checksum on packets being transmitted.
 */
#define MAX_UDP_SOCKETS     (8u)
#define UDP_USE_TX_CHECKSUM        // This slows UDP TX performance by nearly 50%, except when using the ENCX24J600 or PIC32MX6XX/7XX, which have a super fast DMA and incurs virtually no speed pentalty.
 
 
/* Berkeley API Sockets Configuration
 *   Note that each Berkeley socket internally uses one TCP or UDP socket
 *   defined by MAX_UDP_SOCKETS and the TCPSocketInitializer[] array.
 *   Therefore, this number MUST be less than or equal to MAX_UDP_SOCKETS + the
 *   number of TCP sockets defined by the TCPSocketInitializer[] array
 *   (i.e. sizeof(TCPSocketInitializer)/sizeof(TCPSocketInitializer[0])).
 *   This define has no effect if STACK_USE_BERKELEY_API is not defined and
 *   Berkeley Sockets are disabled.  Set this value as low as your application
 *   requires to avoid waisting RAM.
 */
#define BSD_SOCKET_COUNT (5u)
 
 
// =======================================================================
//   Application-Specific Options
// =======================================================================
 
// -- HTTP2 Server options -----------------------------------------------
 
    // Maximum numbers of simultaneous HTTP connections allowed.
    // Each connection consumes 2 bytes of RAM and a TCP socket
    #define MAX_HTTP_CONNECTIONS    (2u)
 
    // Optional setting to use PIC RAM instead of Ethernet/Wi-Fi RAM for
    // storing HTTP Connection Context variables (HTTP_CONN structure for each 
    // HTTP connection).  Undefining this macro results in the Ethernet/Wi-Fi 
    // RAM being used (minimum PIC RAM usage, lower performance).  Defining 
    // this macro results in PIC RAM getting used (higher performance, but uses 
    // PIC RAM).  This option should not be enabled on PIC18 devices.  The 
    // performance increase of having this option defined is only apparent when 
    // the HTTP server is servicing multiple connections simultaneously.
    //#define HTTP_SAVE_CONTEXT_IN_PIC_RAM
 
    // Indicate what file to serve when no specific one is requested
    #define HTTP_DEFAULT_FILE        "index.htm"
    #define HTTPS_DEFAULT_FILE        "index.htm"
    #define HTTP_DEFAULT_LEN        (10u)        // For buffer overrun protection.
                                                // Set to longest length of above two strings.
 
    // Configure MPFS over HTTP updating
    // Comment this line to disable updating via HTTP
    #define HTTP_MPFS_UPLOAD        "mpfsupload"
    //#define HTTP_MPFS_UPLOAD_REQUIRES_AUTH    // Require password for MPFS uploads
        // Certain firewall and router combinations cause the MPFS2 Utility to fail
        // when uploading.  If this happens, comment out this definition.
 
    // Define which HTTP modules to use
    // If not using a specific module, comment it to save resources
    #define HTTP_USE_POST                    // Enable POST support
    #define HTTP_USE_COOKIES                // Enable cookie support
//    #define HTTP_USE_AUTHENTICATION            // Enable basic authentication support
 
    //#define HTTP_NO_AUTH_WITHOUT_SSL        // Uncomment to require SSL before requesting a password
 
    // Define the listening port for the HTTP server
      #define HTTP_PORT               (80u)
    
    // Define the listening port for the HTTPS server (if STACK_USE_SSL_SERVER is enabled)
    #define HTTPS_PORT                (443u)
    
    // Define the maximum data length for reading cookie and GET/POST arguments (bytes)
    #define HTTP_MAX_DATA_LEN        (100u)
    
    // Define the minimum number of bytes free in the TX FIFO before executing callbacks
    #define HTTP_MIN_CALLBACK_FREE    (16u)
 
    #define STACK_USE_HTTP_APP_RECONFIG        // Use the AppConfig web page in the Demo App (~2.5kb ROM, ~0b RAM)
    //#define STACK_USE_HTTP_MD5_DEMO            // Use the MD5 Demo web page (~5kb ROM, ~160b RAM)
    //#define STACK_USE_HTTP_EMAIL_DEMO        // Use the e-mail demo web page
 
// -- SSL Options --------------------------------------------------------
 
    #define MAX_SSL_CONNECTIONS        (2ul)    // Maximum connections via SSL
    #define MAX_SSL_SESSIONS        (2ul)    // Max # of cached SSL sessions
    #define MAX_SSL_BUFFERS            (4ul)    // Max # of SSL buffers (2 per socket)
    #define MAX_SSL_HASHES            (5ul)    // Max # of SSL hashes  (2 per, plus 1 to avoid deadlock)
 
    // Bits in SSL RSA key.  This parameter is used for SSL sever
    // connections only.  The only valid value is 512 bits (768 and 1024
    // bits do not work at this time).  Note, however, that SSL client
    // operations do currently work up to 1024 bit RSA key length.
    #define SSL_RSA_KEY_SIZE        (512ul)
 
 
// -- Telnet Options -----------------------------------------------------
 
    // Number of simultaneously allowed Telnet sessions.  Note that you
    // must have an equal number of TCP_PURPOSE_TELNET type TCP sockets
    // declared in the TCPSocketInitializer[] array above for multiple
    // connections to work.  If fewer sockets are available than this
    // definition, then the the lesser of the two quantities will be the
    // actual limit.
    #define MAX_TELNET_CONNECTIONS    (1u)
 
    // Default local listening port for the Telnet server.  Port 23 is the
    // protocol default.
    #define TELNET_PORT                (23u)
 
    // Default local listening port for the Telnet server when SSL secured.
    // Port 992 is the telnets protocol default.
    #define TELNETS_PORT            (992u)
 
    // Force all connecting clients to be SSL secured and connected via
    // TELNETS_PORT.  Connections on port TELNET_PORT will be ignored.  If
    // STACK_USE_SSL_SERVER is undefined, this entire setting is ignored
    // (server will accept unsecured connections on TELNET_PORT and won't even
    // listen on TELNETS_PORT).
    //#define TELNET_REJECT_UNSECURED
 
    // Default username and password required to login to the Telnet server.
    #define TELNET_USERNAME            "admin"
    #define TELNET_PASSWORD            "microchip"
 
 
// -- SNMP Options -------------------------------------------------------
 
    // Comment following line if SNMP TRAP support is needed
    //#define SNMP_TRAP_DISABLED
 
    //#define SNMP_STACK_USE_V2_TRAP
    #if defined(STACK_USE_SNMPV3_SERVER)
        #define SNMP_V1_V2_TRAP_WITH_SNMPV3
    #endif
 
    // This is the maximum length for community string.
    // Application must ensure that this length is observed.
    // SNMP module adds one byte extra after SNMP_COMMUNITY_MAX_LEN
    // for adding '\0' NULL character.
    #define SNMP_COMMUNITY_MAX_LEN      (8u)
    #define SNMP_MAX_COMMUNITY_SUPPORT    (3u)
    #define NOTIFY_COMMUNITY_LEN        (SNMP_COMMUNITY_MAX_LEN)
 
    // Default SNMPv2C community names.  These can be overridden at run time if
    // alternate strings are present in external EEPROM or Flash (actual
    // strings are stored in AppConfig.readCommunity[] and
    // AppConfig.writeCommunity[] arrays).  These strings are case sensitive.
    // An empty string means disabled (not matchable).
    // For application security, these default community names should not be
    // used, but should all be disabled to force the end user to select unique
    // community names.  These defaults are provided only to make it easier to
    // start development.  Specifying more strings than
    // SNMP_MAX_COMMUNITY_SUPPORT will result in the later strings being
    // ignored (but still wasting program memory).  Specifying fewer strings is
    // legal, as long as at least one is present.  A string larger than
    // SNMP_COMMUNITY_MAX_LEN bytes will be ignored.
    #define SNMP_READ_COMMUNITIES        {"public", "read", ""}
    #define END_OF_SNMP_READ_COMMUNITIES
    #define SNMP_WRITE_COMMUNITIES        {"private", "write", "public"}
    #define END_OF_SNMP_WRITE_COMMUNITIES
#endif
 
 
//#define MPFS_USE_FAT        
 
#define MDD_ROOT_DIR_PATH        "\\"
De este archivo no he eliminado nada ya que luego puede que me sea útil, además que la mayoría de las modificaciones no las realizo yo, sino la aplicación que os mostré en la entrada anterior. He cambiado el nombre de la placa a MIPSBOARD/ de forma que poniendo esto en el navegador, no es necesario saber la dirección IP que se le ha asignado.
Una vez tenemos configurado todo el firmware del micro, debemos crear una página web, para ello debemos crear un directorio en el que pongamos todos los archivos de la página web, y llamar al archivo principal index.htm, o si no queremos llamarlo así debemos cambiarlo en el TCPIPConfig.h. Podemos crear una página web sencilla para probar. Una vez creada la página y todos los archivos que la componen vamos a utilizar otra de las aplicaciones que se instalan junto con las Microchip Aplication Libraries, que es la aplicación MPFS2.

image
Microchip utiliza un formato especial para introducir las páginas web en el microcontrolador, ese formato es el MPFS. Esta aplicación convierte una página web completa, imágenes, textos, enlaces… a un archivo cuyo formato dependerá de lo que nosotros queramos. En la parte superior de la ventana debemos seleccionar la carpeta donde se encuentra la página web, y es en el punto 2 donde le decimos que formato queremos. Como no utilizamos memoria exterior, debemos crear un archivo .c y agregarlo al proyecto, por lo que escogeremos la opción C18/C32 Image. Una vez hecho esto, seleccionamos un nombre para la imagen y le damos a Generate. La imagen se crea en el directorio del proyecto que le hemos dicho en el espacio Project Directory. Luego solo queda agregar el archivo de imagen al proyecto y volver a compilarlo y ya estamos listos para arrancar nuestro servidor web.
Como esta entrada ha quedado bastante larga, dejo para la próxima todo lo referente a monitorización y control de la página. En las próximas entradas también os podré todos los archivos para que los veáis y un vídeo demostrativo.