Datalogger: Adquisición de datos con 18F2550 | ||||
Un “datalogger” es un equipo electrónico encargado de obtener mediciones de magnitudes diversas ordenadas en el tiempo. La toma o adquisición de datos puede realizarse desde diversas fuentes de información o sensores. Dichos datos son almacenados en memorias para luego ser estudiados en forma textual o estadística mediante cartas gráficas. Los campos de aplicación de un datalogger son ilimitados en procesos de monitoreo de variables ya sea en el ámbito industrial, doméstico o como simple ensayo de laboratorio a nivel educacional. Si existe una magnitud que experimenta cambios en el tiempo y deseamos estudiar las características de esa variación, necesitamos un registrador y acumulador de datos: un datalogger. |
|
|||
Un sistema de adquisición de datos puede recibir información desde los más diversos tipos de sensores: de temperatura, de humedad, de tensión, de corriente, de peso, de aceleración, de velocidad, de caudal de líquidos, de fuerzas mecánicas, de movimientos y un etcétera interminable. En nuestra aplicación utilizaremos una única información de entrada, un único tipo de datos ya que no estaremos desarrollando un producto comercial o un equipo dedicado a una aplicación específica. Bastará con un ejemplo para que puedas comprender el funcionamiento de este tipo de equipos y luego adaptarlo al uso que tú necesites. Sería inútil construir un sistema cerrado, sin posibilidades de ampliación. |
||||
Si así fuera, sólo estaríamos mostrándote un desarrollo propio que te sería de muy poca utilidad en el futuro y aquí lo que se trata de lograr es que obtengas el concepto para luego aplicarlo a tus desarrollos y expandirlos hasta donde las necesidades te lo exijan. |
||||
Un datalogger comercial puede costar muchos billetes. Anímate y constrúyelo tú mismo. |
||||
El instrumento que veremos en este artículo es “un instrumento de campo” capaz de almacenar los valores que adquiera la variable elegida y almacenar en una memoria la mayor cantidad de “muestras” como le sea posible para facilitarnos un posterior estudio y análisis de la evolución de la mencionada variable. En nuestro diseño utilizaremos un medidor de temperaturas que ya hemos visto en otro artículo anterior: el STCN75. Este sensor nos brinda la facilidad de trabajo a la que el bus I2C ya nos tiene acostumbrados y nos ayuda a trazar una línea de diseño a partir de sensores de diversos tipos, todos “colgados” del mismo bus de datos. Si por el contrario decides agregar canales de entradas analógicos, la placa de Microingenia o nuestra entrenadora NeoTeo con su PIC 18F2550 (el corazón de este instrumento) te permitirán trabajar con múltiples convertidores analógico – digitales para monitorear y controlar a lo largo del tiempo variables de naturaleza analógica. |
||||
Diagrama en bloques del datalogger de temperatura |
||||
En la imagen superior podemos ver el diagrama en bloques de lo que pretende ser un datalogger a partir del hardware inicial que disponemos. En la misma placa en la que se encuentra ubicado el DS1307, si recuerdan, habíamos dejado un espacio reservado a una memoria EEPROM. El DS1307 nos entregará los datos del horario y la fecha en que se produzcan los eventos que deseamos controlar y monitorear, mientras que las variables obtenidas se almacenarán en la memoria EEPROM que el PCB comparte con el RTC. Estos dos dispositivos que se conectan de manera muy sencilla al 18F2550 comparten, además, el mismo bus de datos para conectar el sensor de temperatura que utilizaremos. La memoria que utilizamos en este ejemplo es una EEPROM 24C64 y en ella podemos almacenar hasta 8192 Bytes de información. Obteniendo una muestra de temperatura cada 15 minutos, podremos almacenar cuatro mediciones en una hora. Si grabamos la hora y los minutos del evento, el día, el mes y los grados de temperatura (en números enteros), debemos considerar 6 bytes por medición si además decidimos tener en cuenta las mediciones de temperatura bajo cero (signo negativo, otro byte). |
||||
|
||||
Entonces, si en una hora tenemos 4 mediciones, almacenaremos 24 Bytes. En un día serán 576 Bytes, por lo tanto para “llenar” una memoria 24C64 harán falta 14 días de mediciones. Esta cifra es muy buena si deseamos evaluar o estudiar las temperaturas de ámbitos muy específicos como pueden ser incubadoras de aves, viveros cubiertos (invernaderos), habitaciones donde deben conservarse materias primas muy específicas o donde se realicen procesos puntuales, por ejemplo, la sala donde se pone a leudar la masa con que se hará el pan del día. Por supuesto, podríamos agregar otras mediciones de diversas variables como puede ser la humedad, la luz ambiente o la tensión de línea, pero necesitaremos más espacio de memoria por cada medición almacenada y eso reducirá la cantidad de días que podremos acumular muestras para nuestros estudios. De todos modos, existen memorias EEPROM de hasta 1MBit en las cuales dispondremos de hasta 131.072 bytes de capacidad y nos ayudarán a optimizar la relación “cantidad de datos / días de almacenamiento”. Por ejemplo, si utilizáramos esa memoria en nuestro ejemplo, podríamos almacenar datos durante 227,55 días, algo así como 7 meses, realmente una cantidad de días innecesaria para un equipo de entrenamiento y aprendizaje. |
||||
|
El sensor de temperatura STCN75 instalado y conectado al bus I2C |
|||
La rutina de funcionamiento del instrumento que hoy nos convoca se sustenta en la combinación de varios de los programas y montajes que ya hemos realizado aquí en NeoTeo. Utilizaremos un display LCD de dos renglones por 16 caracteres donde mostraremos la hora de manera constante, junto a la fecha (día de la semana y fecha del calendario) y, como función adicional, el equipo tendrá un pulsador para visualizar en forma inmediata la temperatura. De todos modos, este es un valor que, de acuerdo al firmware grabado en el 18F2550, aparece en el LCD cada 30 segundos, pero si deseamos verlo en forma inmediata bastará con pulsar el botón de referencia. Vale aclarar que es el mismo pulsador utilizado para ingresar en modo bootloader al insertar el conector USB en el ordenador. Por lo tanto, este botón cumple una doble función. Si en cambio no deseas utilizar el sistema de carga de archivos conocido como “bootloader”, puedes introducir el firmware en el PIC mediante el conector ICSP de la controladora que quieras utilizar para el montaje. |
||||
|
Si no deseas utilizar el sistema de carga "bootloader", puedes programar el PIC mediante el conector ICSP |
|||
El protocolo de funcionamiento del firmware es muy sencillo y sigue una continuidad de acciones muy elementales y fáciles de comprender. Luego de inicializar el PIC con las variables y declaraciones habituales (tal como se hace en cualquier lenguaje de programación), leemos el RTC (DS1307) y mostramos la hora. Luego, leemos los datos que nos envía el sensor de temperatura y armamos el código para que pueda verse cada 30 segundos de manera automática o mediante el pulsador utilizado para la carga del firmware (bootloader). Vale aclarar que antes de leer el dato horario, hemos dejado en el código (comentados) los fragmentos necesarios para grabar, corregir o ajustar el DS1307 en aquellos casos que fuese necesario. Más adelante, luego de leer y mostrar la hora, la fecha y la temperatura, procedemos a grabar los datos necesarios en la memoria EEPROM. Para esto, transformamos toda la información en bytes útiles para ser grabados y almacenados dentro de la EEPROM. Este tipo de memorias (las que superan los 16Kbits – 24C16) poseen un sistema de escritura que en BASIC se puede realizar de manera muy sencilla. |
||||
|
El conector USB se utiliza para programar el PIC y para suministrar alimentación al sistema |
|||
Se abre el bus de datos, se graba en la memoria la dirección a la que se quiere acceder y luego se graban los datos. Suponiendo que seleccionamos la posición 158 de memoria y cargamos 6 datos, grabaremos en los lugares 158, 159, 160, 161, 162 y 163 los bytes que aparezcan, producto de la lectura y toma de datos. Lo mismo sucederá con la posición 6336 (por mencionar una posición al azar). Grabaremos en las posiciones 6336, 6337, 6338, 6339, 6340 y 6341. Debes observar que al escribir la dirección de memoria donde escribirás / leerás el byte que desees, no debes preocuparte por la paginación. Debes imaginar a la memoria como un registro “lineal” al que debes indicarle la posición y nada más. En realidad, está dividida en 256 páginas de 32 bytes, pero a los efectos prácticos escribes la dirección en forma directa dentro de los dos bytes que le siguen al byte de control (address high byte y address low byte) y accedes a cualquier punto dentro de la estructura de la memoria. |
||||
Direccionamiento de la memoria EEPROM 24C64 |
||||
|
Para leer este tipo de memoria, no se envía una instrucción de lectura apenas abierto el bus como hacíamos en memorias pequeñas como la 24C02. En este caso, se abre el bus (BSTART), se graba en la memoria la dirección que se quiere leer (BUSOUT), luego se reabre el bus (BRESTART) y allí entonces se envía el comando de lectura habitual (BUSIN). Finalmente se cierra el bus (BSTOP) y los datos se muestran en el LCD. Realizar una lectura luego de la grabación de los datos en la EEPROM es muy importante. No todos realizamos el hardware con los mismos conceptos técnicos. No todos tenemos el mismo criterio al momento de distribuir los componentes sobre un PCB y hasta hay oportunidades en las que el mismo hardware nos define las posiciones de los componentes “secundarios” dentro de una placa. Esto quiere decir que realizando el proceso de lectura luego de la grabación, estaremos verificando que los datos se hayan grabado de manera correcta. Los tiempos entre instrucciones, los retardos luego de los comandos de grabación y las capacidades parásitas dentro del bus I2C nunca se repetirán entre un diseño y otro. Por este motivo, controlar y verificar (imprimiendo en el LCD) el resultado de la grabación nos permitirá ajustar los tiempos y optimizar el código hasta lograr un firmware libre de errores “sorpresivos, imprevistos e inexplicables”. |
|||
Fragmento del firmware donde se verifica que los datos grabados en memoria sean correctos |
||||
El hardware utilizado es el mismo que usamos en el desarrollo del RTC DS1307, con el agregado del sensor de temperatura al bus I2C. Las conexiones al PIC 18F2550 son las mismas que traemos desde la entrenadora NeoTeo. El LCD en RB2-RB7; el bus I2C en RB0 y RB1; el pulsador para el sistema bootloader en RC0 y el LED en RC1 (estas dos últimas conexiones varían según la entrenadora utilizada); la conexión al bus USB es siempre igual y no admite errores en el 18F2550; y por último la alimentación de 5 Volts con los capacitores electrolíticos y de desacople correspondientes. Es decir, el mismo circuito de siempre. Si no lo recuerdas de memoria, busca hacia atrás en los artículos donde utilizamos este PIC y verás que la estructura es siempre la misma. |
||||
Por otro lado, vale aclarar que por ahora al bus USB lo utilizaremos para cargar el firmware mediante el bootloader y para alimentar el equipo. En la próxima entrega desarrollaremos una aplicación para el ordenador con la que podremos extraer la información que se graba en la memoria EEPROM y que además permitirá graficar las curvas estadísticas del comportamiento de los valores almacenados. En esta primera entrega, te dejamos el hardware y el firmware como para que puedas ver funcionar tu datalogger de temperatura. No desesperes, tienes esta semana para armar el hardware, ensayar y poner a punto el firmware, comprender todo el montaje y hasta ampliar el sistema con más sensores. No lo olvides, el próximo sábado descargamos los datos almacenados en la EEPROM y veremos en un gráfico cómo estuvo la temperatura durante estos días. El datalogger ya está en marcha, no te bajes ahora.
|
||||
Indice de montajes | ||||
|
||||