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

lunes, 24 de febrero de 2014

Proyecto de colaboración con Itead Studio.

Hola! a principio de año os comenté que tenia acordadas unas colaboraciones con algunas tiendas online, y hoy por fin una de esas colaboraciones ha comenzado formalmente. La tienda de electrónica online IteadStudio me ha enviado unas muestras de sus productos para que realice un proyecto que, como ya les comenté cuando se lo propuse, es muy escalable, y muy útil en estos tiempos que corren, se trata de un MPPT (Maximum Power Point Tracking) solar para cargar una batería.  Esto se traduce en, una fuente conmutada la cual controlamos con un algoritmo sencillo. 
Además del control de la fuente conmutada, el equipo también gestiona una página web sencilla en la cual se pueden monitorizar las variables del sistema. Como procesador principal del sistema voy a utilizar una placa Iteaduino Due la cual lleva un procesador ARM Cortex M3 de la casa ATMEL pogramable con el entorno Arduino IDE 1.5.5. Desde la tienda me han mandado dos muestras


Para gestional la comunicación ethernet que maneja la página web, desde IteadStudio me han mandado la placa Itead W5100 Ethernet Shield, la cual monta el tipico chip de Wiznet W5100.


Para poder medir la potencia que estoy obteniendo con bastante precisión, en vez de utilizar el típico circuito con la resistencia shunt, desde la tienda me han mandado su placa Current Sensor Brick, el cual monta un sensor ACS712. ESte integrado es un sensor de efecto hall que saca una tensión de 187 mV / Amperio. Además de este sensor, me han mandado también unos sensores de iluminación, los cuales están formados por una resistencia LDR con un acondicionamiento de la señal, la placa es el Light Sensor Brick.
Todo esto es la parte que va a realizar el control, pero todavía queda mostrar la reina del proyecto, que es la etapa de potencia. Para este proyecto es común utilizar fuentes reductoras tipo Buck, pero últimamente están saliendo mas proyectos que utilizan fuentes elevadoras - reductoras. En mi caso voy a utilizar una fuente SEPIC, la cual es un Buck-Boost, con la diferencia de que la salida no tiene la tensión invertida. En mi caso me voy a basar en la AN1521 de Microchip, y para el diseño de la fuente SEPIC la AN1484 de Texas Instruments está muy bien explicada.
Como novedad, este proyecto va a estar íntegramente colgado en GitHub cuando esté terminado. La dirección del repositorio de GitHub es esta y desde ahí mismo podréis acceder a todos los proyectos que vaya colgando, librerías, y códigos en general. Espero que la gente de IteadStudio quede satisfecha y nuestra relación no se quede en una sola colaboración!

domingo, 26 de mayo de 2013

Servidor web con arduino.

Dicen que para poder vencer a tu enemigo, lo mejor es conocerlo a fondo. No quiero decir con esto que la plataforma Arduino sea un enemigo, pero como ya sabéis los que me conocéis, o los que habéis leído alguna entrada mía sobre la que hablaba de la plataforma, no es un producto que me entusiasme demasiado. No voy a entrar en las razones, ya que me harían falta 3 o 4 entradas, y no lo veo necesario. Todo esto no quiere decir que no sea una plataforma muy utilizada por aficionados a la electrónica, por tanto, tiene cabida en este blog, y mas aún cuando existe una forma muy sencilla de hacer un servidor web, reducido, en esta plataforma con solo un archivo de código y de forma muy rápida, además de barata. Hace tiempo que las placas arduino están cada vez más baratas, por lo que por unos 12 o 13 euros podemos hacernos con una placa Arduino UNO, con lo que ya tendriamos nuestra placa con el procesador, pero además nos hará falta la shield para conectarnos a internet, y para esto existen 2 principalmente. Una placa que monta un controlador W5100, el cual se maneja con 4 pines SPI, o existe otra que utiliza un ENC28J60. El precio de ambas es diferente, la primera la podemos encontrar por 6 o 7 euros, mientras que la segunda la encontramos por 15 o 16 euros. Como el código de ejemplo que nos proporciona la comunidad arduino está hecho para la primera, es esta la que he comprado, por lo que 12 euros de la placa, y 6 euros de la Ethernet Shield, con 18 euros podemos montar un servidor sencillito, que para muchisimas cosas nos puede servir perfectamente.


Como he dicho, para hacer mi servidor, he utilizado el ejemplo que encontramos en el mismo IDE de Arduino, que es realmente básico, ya que solo muestra texto con los valores de los canales analógicos, que en mi opinión es muy pobre, ya que apenas ocupa la mitad de la memoria de AVR, pero bueno, para mejorarlo estamos los ingenieros de verdad. A diferencia de si utilizamos un microcontrolador de microchip con el Stack, para arduino no he encontrado ningún programa que pase una página hecha en html a un codigo compilable en C, no digo que lo no haya, pero no lo he encontrado, por lo que la página debemos meterla por código en el microcontrolador, con lo que escribir una página se hace bastante tedioso. En mi caso he diseñado una página muy sencilla desde la cual monitorizamos la temperatura de la habitación y podemos encender o apagar un ventilador. El código de la página que se debe introducir en el microcontrolador es el siguiente,
client.println("HTTP/1.1 200 OK");
client.println("Content-Type: text/html");
client.println("Connection: close");  // the connection will be closed after completion of the response
client.println("Refresh: 5");  // refresh the page automatically every 5 sec
client.println("");
client.println("");
client.println("");
client.println("index.htm");
client.println("");
client.println("SERVIDOR WEB ARDUINO UNO");
client.println("================================");
client.println("Autor:   P.Trujillo");
client.println("mipsandchips.blogspot.com.es");
client.println("Fecha:   05/2013");
client.println("================================");
client.println("CONTROL DE TEMPERATURA DE UNA HABITACION");
client.println("La temperatura de la habitacion es ");
client.println(temp);
client.println(""); 
client.println("El ventilador esta ");
if(estado_vent)
       client.println("ENCENDIDO");
else
       client.println("APAGADO");
client.println(""); 
client.println("Forzar el ventilador a un estado");
client.println("
"); client.println(""); client.println("
"); client.println("");
A continuación os pongo un vídeo del funcionamiento del sistema:

Como veis es muy sencillo implementar un pequeño servidor web en una placa Arduino UNO, aunque se hace muy pesado introducir páginas relativamente complejas en el. Existe una opción para meter la página en una tarjeta SD, pero si lo comparamos con el servidor web que estoy haciendo con PIC, en el que no utilizo sistema de almacenamiento externo, creo que este ultimo gana por goleada, en primer lugar por facilidad de introducir la página web, en segundo lugar por orden en la programación, cada cosa tiene su archivo diferente, uno para los callbacks y las variables dinámicas de la página web, otro archivo para el código principal, podemos elegir para cada aplicación un procesador adecuado... En cuanto a facilidad de programación, está claro que gana Arduino, aunque si el servidor web de Microchip solo funcionara en un micro, y todos lo hicieran igual, quizás sería más sencillo, en definitiva, ha sido una buena experiencia, y muy válida para realizar algo sencillo y muy rápidamente, en apenas 1 hora tenia funcionando el sistema, mientras que la primera vez que me puse con la pila TCPIP necesité una semana, a ratos, para hacerlo funcionar.

miércoles, 16 de enero de 2013

Primeros pasos Robot.

Después de bastante tiempo sin escribir nada he vuelto!! la verdad que ahora ando bastante liado entre el trabajo y las pruebas del proyecto de final de carrera, pero bueno, hay tiempo para todo. También he estado ocupado intentando hacer funcionar un par de proyectos en MPLABX, sin éxito de momento, por lo que pospondré su publicación a más adelante. En esta entrada os voy a comentar ese proyecto que quería empezar de un robot equilibrista. Lo primero que hice, como ya os comenté fue pedir unos motores competentes, y una vez me llegaron monté el que sería el primer piso de mi robot. Esta parte del robot va a ser donde va a ir alojado todo el módulo de alimentación de 12, 5 y 3,3 voltios, y la parte del control del motor, que como os comenté va a ser un L293D.


  El robot en principio está siendo alimentado con 12 voltios de una fuente de alimentación, la idea es que sea alimentado con una batería. Las tensiones que se obtienen son de 12 voltios (de la entrada), para la alimentación de los motores, 5 voltios por si acaso… y 3,3 voltios para el microcontrolador, que finalmente no será un PIC32, ya que la mini placa que iba a utilizar sufrió un pequeño accidente, por lo que el control lo voy a hacer con un DSPIC33FJ, que como ya sabéis funciona a 40MIPS, más que suficiente para nuestra aplicación. Además una ventaja enorme es que se encuentra en encapsulado PDIP, lo que facilita enormemente el prototipado.
En la parte superior del robot, además del microcontrolador, también encontraremos el acelerómetro, en un futuro supongo que un giroscopio, y un módulo bluetooth para comunicarnos con el robot.
No se si se aprecia en la imagen, pero he tenido que añadir a la alimentación un condensador bastante grande, además de separar las masas de la parte del motor y la parte del DSPIC mediante una bobina ya que, cuando el motor arrancaba, el microcontrolador se reseteaba. Bien  pues esto es lo que tengo hasta ahora, lo próximo es probar un control proporcional sencillo a ver como responde el robot, aunque seguramente con ese control no pueda mantenerlo en pié, pero  por algo empezaremos!!!

sábado, 17 de noviembre de 2012

Servidor Web desde cero. Archivos

Ya hace mas de un mes que terminé de diseñar y fabricar el servidor web que empecé a hacer aquí en el blog. En la última entrada, os conté como había hecho la placa y puse un vídeo del servidor funcionando. Hoy, para cerrar definitivamente esa fase, voy a poner todos lo archivos necesarios para que podáis hacer vuestro servidor. Los archivos son los que he utilizado yo, por lo que estan hechos para las características de mi servidor, un PIC18f4685 funcionando con un oscilador a 20MHz, leds conectados al puerto E del PIC, ..., aunque supongo que no tendréis mayores problemas para poder adecuarlos a vuestros sistemas.
Algunos de los códigos que hay en el proyecto ya los habéis ido viendo a lo largo de las entradas en las que he hablado del servidor, aunque quizás han sufrido alguna modificación de ultima hora. Los archivos que pongo son totalmente funcionales, y deberían compilar sin mayor problema, una vez le hayamos dicho a nuestro compilador donde encontrar los archivos que necesita. Espero que los disfrutéis.

Proyecto:                                                                 ServidorWEB_P_Trujillo_MIPSANDCHIPS.rar

Placa Componentes:
 

Placa PCB:


Esquema:

Si tenéis algún problema con alguno de los archivos, dejad un comentario e intentaré solucionarlo.

viernes, 9 de noviembre de 2012

Primeras pruebas SMPS.

Esta semana por fin me llegaron a casa las bobinas que me hacían falta para construir el primer prototipo de la fuente conmutada elevadora. Esa misma noche hice el montaje en una protoboard. En la entrada anterior comenté que quería hacer el control en bucle abierto con un 555, pero después de estar mirando varios esquemas vi que la cantidad de componentes externos era bastante alta, por lo que decidí utilizar un microcontrolador 12f683. El hecho de utilizar el microcontrolador tiene sus ventajas, y desventajas. La principal ventaja es que solo hace falta un integrado para que obtengamos una señal PWM, por otro lado, si queremos reducir el número de componentes, lo ideal es utilizar el oscilador interno, por lo que la frecuencia de trabajo se reduce a 8 MHz, lo que son 2 MIPS, y las frecuencias que podemos obtener a la salida, sin sacrificar la resolución del PWM no son demasiado altas, teniendo en nuestro caso una frecuencia de salida de alrededor de 77 kHz, lo que a simple vista parece bastante alto, pero hay que recordar que las fuentes conmutadas funcionan a unos 100kHz. Otra desventaja, y que se enfrenta bastante con la ventaja de la solución monochip, es que, así como el 555 ofrece una salida con capacidad de suministrar bastante corriente, no es así con el PIC, por lo que hay que añadir otro integrado que suministre la corriente necesaria para el disparo del mosfet. Así que en nuestro montaje se encuentra el PIC12F683, y además un driver para mosfets, el TC4424. A continuación veis una foto del montaje.

BOOST

La siguiente es una foto del sistema funcionando.

BOOST_COMPLETO

Como veis, la fuente funciona correctamente, ya que, con una entrada de 5 voltios, estamos obteniendo a la salida 10,03 voltios. En el osciloscopio se puede ver que el ciclo de trabajo es mayor al 50%, esto es debido a las perdidas tanto en el transistor, como en el diodo que, evidentemente no son ideales. Como comenté, el objetivo de esta fuente es alimentar 3 o 4 leds, con lo que necesitare una tensión entre 10,8 y 14,4 voltios, tensiones que espero alcanzar sin problemas. En este caso, limitando el ciclo de trabajo al 80% la tensión máxima que he obtenido es de 13,19 voltios, el problema es que a ciclos de trabajo mayores, la tensión caía hasta 12 voltios. Puede que la razón sea que la bobina se satura, por lo que si trabajo a frecuencias mayores podre evitarlo, cosa que es posible hacer con un pic32 o un dsp. (Si en este punto estoy equivocado decídmelo!)

image

Bueno, el próximo paso es diseñar y fabricar la placa, para que tenga la opción de poder hacer el control mediante microcontroladores más potentes. En la próxima entrada ya os pondré el firmware del PIC12F, en el que por primera vez he utilizado MPLAB X con el compilador XC8.

jueves, 1 de noviembre de 2012

Nuevos proyectos.

Hola a todos!! bueno después de varios días sin escribir debido a que he empezado a trabajar en la universidad, y además estoy con los últimos retoques de mi proyecto de final de carrera, he tenido tiempo de soñar pensar en nuevos proyectos, y he empezado a recolectar o comprar los elementos que me hacen falta. En principio tengo ensados 3 proyectos de diferentes magnitudes.
El primero de ellos es el más sencillo, y es una fuente conmutada boost de baja potencia. En principio la fuente estará gobernada seguramente por un 555, pero la quiero hacer para que se pueda gobernar bien desde un pic32, o bien desde un DSP de texas que empecé a comentaros en la entrada anterior. Para este proyecto tengo unos condensadores de 100uF que me van a asegurar al 100% la estabilidad de la salida, a parte he comprado 3 de bobinas 330uH en ebay por 1,5 euros. Como interruptores voy a utilizar un mosfet, el IRF640, que hace tiempo compré 20 por ebay para un control de motores y creo recordar que los 20 me costaron 3 o 4 euros, y un diodo schottky 1N5819. La idea es que le entre una tensión de 5 voltios, y obtengamos a la salida una tensión de al menos 10 voltios, con una corriente de unos 20 o 40mA. De esta forma, con una fuente de 5 voltios podemos alimentar hasta 6 leds blancos, poniendo 3 y 3 en paralelo. No lo considero un proyecto muy ambicioso ya que no tiene mucha dificultad en principio, y digo en principio porque el control digital de fuentes tipo elevadoras no es el más sencillo.
Los otros dos proyectos que tengo en mente son mas ambiciosos pero o por ello no los voy a poder construir. En primer lugar quiero que veais esto:
Lo que veis es un robot balancín, equilibrista… tiene muchos nombres, pero básicamente es un robot que mantiene el equilibrio con tan solo 2 ruedas. Para que el procesador sepa si el robot está en posición recta o está cayendo se utilizan dos tipos de sensores, un acelerómetro, que mide el giro debido a la aceleración de la gravedad, y un giroscopio, que mide el Angulo de giro sin basarse en las aceleraciones. Como habréis supuesto, las aceleraciones que sufre un robot no son solo debidas a la gravedad, ya que este puede acelerar, frenar y girar, por lo que el acelerómetro por si solo no es una buena opción, aunque la es, por otra parte el giroscopio tiene el problema de que las lecturas tienen error, por lo que la mejor opción es utilizar ambos. En mi caso, por ahora solo dispongo de un acelerómetro, por lo que en principio solo dispondré de este. Para este proyecto, la parte fundamental son las ruedas, por lo que la semana pasada compré por ebay un kit de 2 ruedas, con dos motores de 12V, con los adaptadores motor-rueda y todo.
Photobucket
El kit completo me costó 23 euros, no es barato, pero los motores son bastante buenos y tiene un par de 6 Kg/cm^2 con una corriente de 0,8A. La otra opción que pensé era en adquirir dos motores de Lego, el mediano, y dos ruedas de lego también, pero el precio era mayor así que me decidí por estos. Para el manejo de estos motores no se todavía lo que voy a utilizar,podría utilizar un L293, que soporta una corriente de hasta 600mA, con 1 amperio de pico, o bien unos controladores de texas que son smd y soportan 2A nominales, aunque supongo que cogeré la primera opción. En cuanto al control, como en el caso anterior podré utilizar un pic32, o un dsp de texas. Me gustaría hacerlo con ambos y ver las diferencias.
Y por ultimo, el tercer proyecto y más ambicioso es un osciloscopio USB. Este es el proyecto, creo, más complicado de los 3 aunque tampoco lo es tanto. Como cerebro del osciloscopio estará una FPGA Cyclone II trabajando a 50MHz, así que por la parte de la adquisición no tendré ningún problema, el problema vendrá cuando tengamos todos los valores y tengamos que mandarlos al PC, para ello he pensado en emular una comunicación RS232 con la FPGA, y después, mediante un MCP2200 pasarla a USB con el protocolo CDC, por lo que desde el PC será sencillo de manejar. Después con un programita en Visual Basic representar la forma de onda.
El conversor analógico – digital que voy a utilizar es un ADS801 de texas, que alcanza una velocidad de lectura de 25 Msps, aunque en mi caso no voy a necesitar tanto, por lo que para mi osciloscopio haré que funcione a una velocidad menor. Yo creo que trabajando a unos 10Msps podré ver perfectamente señales de hasta 1MHz, incluso más. Este ADC, aunque es bastante caro, se puede pedir como muestra a TI, por lo que su precio es 0. La FPGA es la parte más cara de este proyecto, en mi caso, la FPGA con el adaptador JTAG me costaron unos 25 euros hace ya tiempo, de forma que por unos 30 euros espero poder tener un sistema funcional.
Bueno esto es lo que quiero hacer, ahora viene la parte más complicada que es el diseño. El primero que espero ver funcionar es la fuente de alimentación, y servirá de calentamiento para los demás proyectos. Si tenéis alguna sugerencia la podéis dejar en los comentarios.

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.