Post on 19-Sep-2018
Medidor de Consumo
Proyecto final de Sistemas Embebidos en Tiempo Real
Ismael Schinca – Claudia Guastavino – Natalia Botto
Tutor: Leonardo Steinfeld
Documentación Medidor de Consumo Guastavino – Schinca – Botto
2
Tabla de contenidos
Resumen........................................................................................................................................3
Descripción del problema..............................................................................................................4
Antecedentes.................................................................................................................................4
Objetivos........................................................................................................................................4
Alcance ..........................................................................................................................................5
Diseño............................................................................................................................................6
Hardware ...................................................................................................................................6
Software ....................................................................................................................................7
Implementación...........................................................................................................................11
Descripción de la implementación en hardware.....................................................................11
Esquemático ............................................................................................................................13
Descripción de la implementación en software......................................................................14
Pruebas ........................................................................................................................................18
Conclusiones................................................................................................................................19
Anexo...........................................................................................................................................20
Mejoras a futuro......................................................................................................................20
Cronograma actualizado..........................................................................................................20
Dedicación horaria...................................................................................................................21
Documentación Medidor de Consumo Guastavino – Schinca – Botto
3
Resumen
Este proyecto trata del diseño y la implementación de un dispositivo que permita la
recolección de datos de consumo de corriente y de voltaje de algún otro tipo de dispositivo de
forma instantánea o a lo largo del tiempo, proporcionando distintas funciones para el
procesamiento de esta información. Para ello fue necesario resolver tanto el hardware como
el software de la solución, esto llevó al armado de una placa con todos los componentes y la
programación del software que permite tomar las medidas y realizar los cálculos necesarios.
Para tomar las medidas de corriente se utilizó el integrado Maxim DS2740, el cual es un
medidor de coulomb de alta precisión. Este dispositivo utiliza el protocolo de comunicación 1-
Wire para la comunicación con el micro, por lo que fue necesario resolverlo tanto en la
implementación del hardware como para el software.
Trabajamos con el microprocesador Atmega32 de Atmel, para la implementación del software
se utilizó el entorno de desarrollo IAR Embedded Workbench. El hardware se diseñó utilizando
EAGLE Layout Editor.
Documentación Medidor de Consumo Guastavino – Schinca – Botto
4
Descripción del problema
Implementar un diseño que permita la medida de la corriente utilizando el integrado DS2740.
Además de la corriente, se pretende medir el voltaje utilizando uno de los ADC del
microcontrolador Atmega32.
Para el procesamiento de los datos se utiliza el microcontrolador Atmega32 de Atmel, el cual
realiza el manejo de las funciones del medidor y comunicación con otros dispositivos. El
protocolo de comunicación entre el integrado y el microcontrolador es 1-Wire ®.
Se plantea implementar una comunicación serie RS232 hacia fuera para conectarse a un PC
para descarga de datos, configuración de parámetros y funciones del dispositivo a construir.
Originalmente se pretendía que el dispositivo fuera capaz de integrarse a un MOTE por lo que
debía prever el protocolo de comunicación del mismo con el micro. Se generó un interés por
conocer el consumo del MOTE en tareas especificas, como ser el consumo al despertar, al
transmitir, etc. Luego de investigar el funcionamiento del integrado DS2740, se notó que esto
no era viable ya que el integrado obtiene un valor de corriente aproximadamente cada 3.5 s,
siendo esto muy lento para la frecuencia con las que se querían recoger dicha información.
Antecedentes
Contamos con la especificación del protocolo 1-Wire® que es utilizado por el integrado DS2740
para la interconexión con otros dispositivos. A su vez accedimos a una nota de aplicación de
Atmel para implementar este protocolo para la familia de microcontroladores de 8 bits al cual
pertenece el micro a utilizar.
Se reutilizó código generado en el transcurso de la asignatura, tanto lo realizado para los
laboratorios como ejercicios, para los siguientes módulos
� Timer
� Uart
� Cola de datos
Objetivos
Con este proyecto se pretende adquirir los siguientes conocimientos para el curso
� Desarrollar código utilizando lenguaje C para sistemas embebidos
� Aprender a manejar con soltura alguno de los entornos de desarrollo propuestos, en
nuestro caso particular utilizamos el entorno IAR Embedded Workbench. (Debugging)
� Familiarizarse con los problemas asociados al desarrollo en sistemas embebidos (datos
compartidos, tamaño de memoria, etc).
Documentación Medidor de Consumo Guastavino – Schinca – Botto
5
� Utilizando los conocimientos dados durante el curso, frente al planteo de un problema
de sistemas embebidos, realizar un diseño en software eligiendo la mejor arquitectura
y realizar toda la implementación del código. También testear dicho código con el
hardware que realizamos.
Alcance
� El proyecto implica el desarrollo de una placa con todos los componentes para realizar
las medidas. Este diseño es un primer prototipo el cual luego se lo puede mejorar
� Se utilizó el micro Atmega32 para todos los procesos, para la medida de corriente el chip
DS2740, y para la medida de voltaje uno de los ADC del Atmega
� A la hora de medir la corriente, el diseño exige una resistencia de alrededor de 20
mOhm, que es la que determina la resolución de la medida. En nuestro diseño no se
utilizó dicho valor de resistencia por no encontrarse en mercado. En su lugar se
colocaron resistencias de 100 mOhm en paralelo
� A pesar de que la idea era resolver toda la comunicación, para el alcance del curso el
principal objetivo era resolver el procesamiento de la medida de corriente leída en un
registro determinado, independiente de si el mismo se obtuvo a partir del sensado del
chip
� A nivel de software se realizó todo el código para tomar y procesar medidas de voltaje y
corriente
� No se realizan medidas de potencia
Documentación Medidor de Consumo Guastavino – Schinca – Botto
6
Diseño
La figura a continuación es un esquema visual del sistema completo que se tomó como
referencia a la hora de encarar el diseño
� Todos los componentes recuadrados en naranja son parte de nuestro dispositivo y las
flechas en celeste son internas al dispositivo
� DISP recuadrado en azul representa el dispositivo al cual se le quiere medir el consumo
� Las flechas en violeta representan las señales de comunicación con el exterior
• Señales de DISP - sensado de corriente y voltaje (I, V) y las señales de control
• Comunicación serial con PC
Hardware
Para el diseño en hardware partimos del circuito de referencia proporcionado por Dallas para
el DS2740
y lo adaptamos para las necesidades de nuestro diseño (ver fig. siguiente) siendo el CPU a
Documentación Medidor de Consumo Guastavino – Schinca – Botto
7
utilizar el ATmega32.
La comunicación entre el CPU y el DS2740 se implementa mediante la nota de Aplicación de
Atmel utilizando la UART con interrupciones. Adicionalmente implementamos la comunicación
del CPU con un PC mediante comunicación serial. Dado que para la comunicación con el PC
utilizaremos también la UART y que el ATmega32 solo dispone de una, fue necesario diseñar
una manera para que la misma pueda dialogar con ambas partes. Para esto se agregó un
MUX/DEMUX al diseño controlado por uno de los pines del CPU.
Para medir el voltaje, se utilizó uno de los conversores analógico digitales del Atmega32. En
una primera instancia se pensaba alimentar el circuito de la misma fuente que el dispositivo a
medir. Debido a que el ADC por defecto toma como referencia la alimentación del CPU se
generó un inconveniente dado que es el mismo que queremos medir, y nosotros precisamos
una referencia fija para poder obtener las variaciones en voltaje. Para solucionar esto,
configuramos el CPU para tomar como referencia un voltaje interno disponible a estos efectos,
que tiene un valor constante independiente de la alimentación (dentro de los rangos válidos
de la misma) de 2.56V. Esto nos proporciona una referencia fija pero de un valor seguramente
inferior al que deseamos medir. Para evitar esto agregamos un puente resistivo que divide en
dos el valor que deseamos medir para la entrada del ADC, pasando a ser el máximo valor
permitido dos veces el valor de referencia. Si es necesario medir voltajes mayores se deben
cambiar las resistencias para que el divisor resistivo de un valor dentro del rango permitido.
Posteriormente se decidió separar la alimentación del circuito a medir de la de nuestro diseño
para que el consumo del mismo no afecte la medida.
Software
Para el diseño del software se decidió utilizar una arquitectura Round-Robin con
interrupciones, ya que consideramos que es la que mejor se adapta a nuestro caso.
Para controlar el loop del Round-Robin se utilizan banderas que habilitan los distintos eventos.
Los diferentes bloques se estructuraron en carpetas según sus funcionalidades, lo que hace su
Documentación Medidor de Consumo Guastavino – Schinca – Botto
8
lectura más sencilla. Para cada archivo .c se agregó un archivo .h en el que se publican las
funciones y-o variables a utilizar en los otros archivos. En particular se crearon una serie de
archivos donde se pueden encontrar las constantes y las variables globales a utilizar en todo el
sistema.
Para los archivos que realizan la comunicación 1-wire se tomaron los proporcionados en la
nota de aplicación de Atmel, sin embargo sufrieron grandes modificaciones ya que no
funcionaba como se esperaba.
1-wire
Uno de los objetivos de este proyecto era implementar la comunicación entre el CPU
ATmega32 y el integrado DS2740 de Dallas mediante el protocolo 1-wire®. La idea era partir de
una nota de aplicación de ATmel para lograr esta comunicación y hacer los ajustes necesarios
en la misma para una implementación exitosa en nuestra situación en particular.
Breve descripción del protocolo 1-wire
Es un protocolo propietario del fabricante Dallas que implementa una comunicación
bidireccional en un solo pin. La comunicación es asíncrona y funciona en half-duplex en modo
maestro-esclavo estricto. Esto quiere decir que para la transmisión o recepción de cada bit por
parte del esclavo debe existir una habilitación del maestro. Si bien el protocolo permite que se
conecten varios dispositivos esclavos a un solo maestro, en nuestro caso tendremos un solo
dispositivo, el DS2740.
Sin entrar en profundidad en el protocolo, destacaremos las siguientes características del
mismo y luego describiremos un poco la implementación mediante la utilización de la UART
del ATmega32:
• El bus es activo por bajo, por lo que debe existir un resistor de pull-up en la línea
• Los bits se transmiten en time-slots de 60us, un bit por slot.
• El maestro siempre debe habilitar la transmisión de cada bit, independientemente de la dirección del mismo.
• El protocolo es bastante laxo en cuanto a los requerimientos de timing por parte de los dispositivos esclavos.
• Los comandos básicos de comunicación son: “Escribir 1”, “Escribir 0”, “Leer”, “Reset” y “Presencia”
La implementación del protocolo mediante una UART es relativamente sencilla. Para generar
las señales correctamente se debe trabajar con la UART a 115200bps, por lo que para empezar
hay que asegurarse que la UART trabaje correctamente a esta frecuencia.
La idea es que se conectan tanto el Tx y el Rx a la línea del 1-wire (utilizando el circuito de la
Fig. 1) y para cualquier función la UART envía un byte. Si no hubiera ningún dispositivo en la
línea, el mismo byte se recibiría tal cual en el Rx de la UART. Con la presencia de un dispositivo,
el mismo modificará el byte enviado, y analizando el resultado se ve a que mensaje
corresponde (bit 0, bit 1, presencia, etc.)
Documentación Medidor de Consumo Guastavino – Schinca – Botto
9
La secuencia de comunicación en un bus 1-wire sigue los siguientes pasos:
1) Inicialización 2) Comando Net Address 3) Comandos de funciones (en nuestro caso, correspondientes al DS2740) 4) Transacción/Datos
1) En esta etapa, el Master genera un pulso de Reset para inicializar la comunicación en un
estado conocido, interrumpiendo todas las transacciones que se estén ejecutando. Los
dispositivos esclavos en el bus responden a este Reset con un pulso de Presencia, indicando
que hay uno o más dispositivos activos en la línea. El pulso de Reset se genera con la UART
trabajando a 9600bps (fig. siguiente)
Documentación Medidor de Consumo Guastavino – Schinca – Botto
10
2) Estos comandos se utilizan para que el Master indique el dispositivo con el cual se quiere
comunicar. Si se sabe de antemano que solo existirá un dispositivo en la línea, simplemente se
envía un comando para saltearse esta etapa (comando: 0xCC).
En las figuras veremos las formas de onda para la transmisión y recepción de 1’s y 0’s desde el
Master. Read es para leer datos enviados desde el Esclavo y Write es para enviar datos al
Esclavo. Recordemos que por la forma de implementación, así se escriban o lean datos, en la
UART siempre se enviará y recibirá un byte para cada una de estas acciones:
Documentación Medidor de Consumo Guastavino – Schinca – Botto
11
3) Se envían comandos específicos al Esclavo con el que desea comunicarse. En el caso del
DS2740 los comandos disponibles son:
- Read Data (0x69, 0xXX): Al recibir este comando el integrado comienza a transmitir datos a
partir de la dirección XX de su memoria. Cuando llega a la dirección 0xFF vuelve a transmitir el
contenido de la dirección 0x00 (1 byte en cada dirección). Para interrumpir la transmisión se
debe enviar un pulso de Reset
- Write Data (0x6C, 0xXX): Este comando escribe los bytes recibidos a continuación por el
esclavo en su memoria a partir de la dirección XX. En nuestro caso se podría utilizar para
escribir alguna configuración en los registros específicos para esto del chip.
4) En esta etapa se recibirían o enviarían los datos correspondientes a los registros a leer o
escribir del DS2740
Implementación
Descripción de la implementación en hardware
Para la implementación del hardware se utilizó el software EAGLE Layout Editor v5.0.0 para
realizar el esquemático y circuito impreso.
El integrado DS2740 que se encarga de medir la corriente, debe tener una resistencia de
sensado entre los 10 -20mOhm, mediante la cual se determina la resolución en la medida.
Dado que este valor no es posible conseguirlo en plaza tuvimos que encontrar otra solución.
Documentación Medidor de Consumo Guastavino – Schinca – Botto
12
Luego de buscar en el mercado local que había disponible, lo mejor que encontramos fueron
resistencias de 100 mOhm, por lo que tuvimos que colocar 6 en paralelo en la placa. El cobre
extra que implica interconectarlas sumando al valor del paralelo en sí, generó problemas para
que el valor fuera el requerido, dificultando aparentemente el correcto funcionamiento del
circuito.
Al realizar nosotros el circuito impreso, disponíamos solo de placas de una sola capa de cobre y
dado que el empaque del DS2740 era SMD, fue necesario realizar una placa de adaptación a
PTH para que la misma se pudiera integrar al resto del circuito. Esta placa fue la que presentó
el mayor reto ya que no resultaba tarea menor soldar el integrado que tiene un empaque con
un pitch muy pequeño, aproximadamente de 0.2mm de distancia entre patas.
Una vez con la placa pronta, realizamos pruebas con las señales de control, las cuales debían
desencadenar una interrupción al generarse un cambio de nivel en las mismas. Nos topamos
con la necesidad de agregar unas resistencias de pull-down a las patas del CPU INT0 y INT1
para que las mismas se comportaran como era deseado.
A continuación se detalla la lista de componentes utilizados y el esquemático.
Lista de componentes
Componente Nombre en PCB Descripción/ Valor
Resistencia R1, R5, R6, R7, R8, R9 100mΩ
Resistencia R2 4.7kΩ
Resistencia R3 100kΩ
Resistencia R4, R10, R11, R12, R13 10kΩ
Capacitor C1, C2, C3, C4,
C5, C6, C7, C8 100nF
NPN Transistor T1, T2 BC547
Cristal X1 32,768 kHz
Circuito Integrado IC1 Microprocesador Atmega32
Circuito Integrado IC2 MAX232
Circuito Integrado DS2740 High-Precision Coulomb Counter
Circuito Integrado IC3 Mux/Demux 4052
Conector DB9 Conector DB9
Conector JTAG Conector de programación
Conector SV1 Conector – Alimentación
Conector SV2 Conector- Señales de control
Conector SV3 Conector- Interfaz de sensado
Documentación Medidor de Consumo Guastavino – Schinca – Botto
13
Esquemático
Documentación Medidor de Consumo Guastavino – Schinca – Botto
14
Descripción de la implementación en software
Para implementar el software se utilizó el IAR Embedded Workbench, v5.11. La declaración
detallada de cada una de las funciones se puede consultar en el doxygen.
Detalle de las funciones implementadas
� Función 1
� Se recolectan y almacenan los datos de voltaje y corriente continuamente
� Cuando se llena el buffer de almacenamiento (n datos) se calcula el
promedio, máximo y mínimo de estos datos y se almacenan estos valores
en sus respectivos buffers
� Cuando estos buffers se llenan se sobrescribe el valor mas antiguo
� Cuando se recibe el comando SD desde el PC se transmiten los valores
almacenados de promedio, máximo y mínimo almacenados hasta el
momento
Documentación Medidor de Consumo Guastavino – Schinca – Botto
15
� Función 2
� Funcionamiento similar a Función 1
� Diferencia: Cada vez que INT cambia de estado se transmiten los datos de
promedio, máximo y mínimo almacenados hasta el momento y se vacían
todos los buffers
� Si dentro de Función 2 se recibe el comando Px
� Funcionamiento igual a Función 1 solo que los datos se toman y
almacenan solo si INT está en la condición x
� Función 3
� Función por defecto
� Se toman los datos constantemente y cada vez que se tiene un dato nuevo
se transmiten directamente a la PC los valores de corriente, voltaje y
tiempo de muestreo
� No se almacena ni se realiza ningún procesamiento con estos datos
Estructura básica del loop round-robin y ejemplo de funcionamiento con Función 1
Loop Round-Robin. Las distintas funciones se ejecutan según si la bandera correspondiente se
encuentra habilitada.
Documentación Medidor de Consumo Guastavino – Schinca – Botto
16
Ejemplo de funcionamiento Función 1:
• Cada 250 ms se genera una interrupción del timer. Al llegar a 3.5ms en la siguiente
interrupción se habilita a que se tome una nueva medida de corriente y voltaje,
habilitando las banderas de ADC y OneWire.
• Cuando se tomaron ambas medidas se habilita almacenarDatos para guardar los
mismos en sus buffers correspondientes.
• Función 1 verifica y cuando estos buffers se llenan se realiza el cálculo de máximo,
mínimo y promedio.
• Cada vez que se recibe un byte desde el PC la UART verifica que sean caracteres
válidos y cuando se recibe un código de dos caracteres de los posibles se habilita el
analizadorPalabra, que estudia el comando recibido y habilita las funciones
correspondientes.
• Si se recibe el comando SD, se habilita el transmisor, que envía los datos recolectados
al PC según corresponda
Descripción de comandos
F1 Función 1
F2 Función 2
F3 Función 3
SD Send Data
RT Soft Reset
Px Para x=0x00, 0x01 , 0x02 , 0x03
� RT (Soft Reset) : Reinicia el timer, inicializa las banderas y resetea las colas. Mantiene la
función que se esté ejecutando
� SD: Envía los datos acumulados si la función seleccionada es F1 o Px
� Px: Dentro de F2, habilita modo alternativo tal como se describe en las funciones
Detalle del formato de datos utilizado
Medida del ADC: Entero. Voltaje medido en Volts multiplicado por 100. El voltaje
medido es la mitad del valor del voltaje que deseamos medir debido al
puente resistivo implementado.
Medida de corriente: Entero. Valor del registro del DS2740 (15 bits+signo) x 1.5625µV . Esto
nos da el valor del voltaje. Esto lo dividimos por la resistencia de
medida, considerando 20mA. Al valor obtenido (en mA) lo
multiplicamos por 100 y este es el entero que conservamos.
Timestamps(solo en Función 3): HH:MM:SS
Documentación Medidor de Consumo Guastavino – Schinca – Botto
17
A continuación se detallarán algunas de las dificultades que nos encontramos al desarrollar el
software, dejando de lado el 1-wire el cual lleva un capítulo aparte.
� Primero nos encontramos con que al mover el mux para poder cambiar la
comunicación de la UART entre el CPU y el integrado, en ocasiones aparecían
datos basura. Esto lo solucionamos ajustando para que la función solamente
procese los comandos que pretende recibir
� Por limitaciones en la capacidad de memoria disponible no era posible trabajar con
floats para guardar los valores de corriente y voltaje medidos. Lo que se hizo fue
utilizar enteros teniendo en cuenta que el valor guardado es el valor medido
multiplicado por un factor, permitiéndonos guardar la cantidad de decimales que
consideramos conveniente.
� Se tuvo cuidado al modificar las variables globales del sistema para evitar
problemas de datos compartidos, evitando modificar éstas en las rutinas de
atención a las interrupciones, o desactivando las interrupciones cuando
correspondía.
� Al recibir los datos muchas veces recibíamos datos basura, si bien el buffer de
transmisión tenia los datos correctos. Investigando encontramos que al devolver la
UART al PC cambiando el MUX este generaba ruido que era recibido por el PC
junto con lo que se transmitia desde el CPU, por lo que se debió agregar un tiempo
de espera luego de cambiar el MUX y antes de habilitar la UART del ATmega32 y
así evitar esta transición.
Descripción de la implementación en software de la comunicación mediante protocolo 1-wire
La aplicación se adaptó a partir de la propuesta en la nota de aplicación de Atmel. Funciona
como una máquina de estados que se va recorriendo para cumplir las distintas etapas de
comunicación del protocolo. Las funciones implementadas dependen principalmente de
rutinas de atención a interrupciones.
Resumen del trabajo realizado sobre el código para lograr una implementación exitosa
Para empezar debíamos verificar que la UART funcionara correctamente a 115200 bps. De la
hoja de datos del procesador sabemos que la configuración de los bps de la UART se hace
mediante una cuenta utilizando el registro UBBR de la UART, el cual es configurable. De la hoja
de datos vimos que para la enorme mayoría de configuraciones a las frecuencias disponibles el
error en el baud rate era de 8.5%. Realizando pruebas con este porcentaje de error vimos que
no se podía lograr una transmisión satisfactoria.
La única opción que se acercaba mas, logrando un error de -3.5% era trabajando con el procesador a 8MHz y configurando la UART en modo U2X (trabaja al doble de velocidad, pero el timing puede volverse mas delicado). Se probó de este modo y se verificó que se lograba una comunicación exitosa, por lo que de aquí en mas se trabajó con el CPU configurado mediante Fuses a 8MHz.
Documentación Medidor de Consumo Guastavino – Schinca – Botto
18
Mas allá de los errores que encontramos en el código de la nota de aplicación que impedía la
compilación (nombres de registros, bits, etc.) uno de los primeros problemas que encontramos
es que se definía innecesariamente el cambio de velocidad de la UART (de 9600 a 115200
según si se enviaba RESET u otro comando) en varios puntos del código, lo que ocasionaba que
a veces se quisieran enviar o recibir datos sin haberse terminado de configurar correctamente
la UART. Se ajustó el código para que el cambio se hiciera solo cuando fuera necesario.
Otro inconveniente fue que no se manejaban correctamente los tiempos para una correcta interacción entre la máquina de estados, las funciones y las ISRs. Para ajustar esto fue necesario un estudio detallado del código, añadiendo una variable “espero” que dejara al sistema en espera en el punto correspondiente para permitir un correcto funcionamiento. La aplicación se manejaba con un solo buffer para el envío y recepción de datos. Esto
teóricamente tendría que funcionar bien, ya que luego que se envía un dato no se precisa mas
y se podría utilizar es lugar para almacenar el dato recibido. Sin embargo la implementación de
esta forma daba errores. Definiendo dos buffers separados para envío y recepción se
solucionaban los problemas encontrados. De todos modos teóricamente sería posible lograr la
operación con un solo buffer, sería necesario mas análisis y testeo para encontrar donde se
produce la colisión de datos.
Pruebas
• Para testear el código del 1-wire se realizó un proyecto aparte donde se realizaron
todas las pruebas. Cuando efectivamente estaba funcionando se integró al sistema
completo. Antes de integrarlo al sistema se realizó un testeo en el hardware, para ver
las señales que se estaban enviando a través de la UART hacia el MUX y luego al 1-
wire, ‘colgamos’ un especie de sniffer que esencialmente era un MAX232 conectado al
puerto serie del PC que permitía obtener los mensajes intercambiados.
• Se utilizó el Terminal de Bray++ para probar el analizador de palabra, enviándole las
palabras que se esperan y debuggueando se vieron las salidas correspondientes.
También se enviaron mensajes erróneos y se verifico que los mismos eran ignorados.
• Al generarse un cambio de nivel en las señales de control, las mismas debían
desencadenar una interrupción. Realizando pruebas con las mismas, nos percatamos
que se generaba un comportamiento erróneo, las mismas interrumpían de forma
totalmente aleatoria y continuamente debido al ruido. Esto nos llevo a darnos cuenta
que precisábamos resistencias de pull-down para estabilizar las señales, una vez
agregadas las mismas se verificó el correcto funcionamiento.
Documentación Medidor de Consumo Guastavino – Schinca – Botto
19
Conclusiones
Se logró implementar el software deseado, alcanzando los objetivos que se pretendían lograr
con el proyecto en este curso.
Se consiguió un diseño de hardware que permitió todas las comunicaciones y recolección de
datos buscada.
No fue posible conseguir valores reales de corriente, posiblemente por problemas en el
hardware que no han sido completamente identificados.
Estimamos que el proyecto insumió un total aprox. de 160h lo cual supera la carga horaria
asignada originalmente. Este tiempo extra se invirtió principalmente en el diseño y la
construcción del hardware necesario, que fue una tarea más compleja a la esperada y en
lograr la implementación exitosa del protocolo de comunicación 1-wire. Por otro lado más allá
de las horas extra también se prolongó en el tiempo debido a las dificultades encontradas
inicialmente para la especificación completa del problema.
Documentación Medidor de Consumo Guastavino – Schinca – Botto
20
Anexo
Mejoras a futuro
• Corregir los problemas que impiden obtener un valor correcto de corriente.
Posiblemente implique una mejor construcción de la resistencia de 20 mOhm o
una revisión del circuito implementado.
• Calibración
� Al ser el valor de resistencia de sensado tan pequeño, resulta necesario
hacer una calibración para conocer su valor real. Para realizar esto se
puede conectar al sistema como dispositivo a medir una fuente de
corriente de valor conocido y a partir del valor obtenido en el registro del
DS2740 estimar el valor de la resistencia, guardando este valor para el
cálculo de la corriente de medidor de consumo.
• Seguir depurando el código para hacerlo más eficiente.
Cronograma actualizado
• Hitos
o 23 de abril
• Presentación de proyecto
o 14 de mayo
• Presentación de avance del proyecto 1
o Estudio de especificación 1-Wire y nota de aplicación
o Toma de datos cada 3.5 s
o Especificación definitiva del proyecto en base a la nueva
información disponible (tiempo muestreo, etc.)
o 28 de mayo
• Presentación de avance del proyecto 2
o Comunicación con el integrado mediante protocolo 1-
Wire, incluyendo lectura de registros del DS2740 y envío
de parámetros al mismo…. Se empezó a corregir el código
de la nota de aplicación de atmel (compilaba)
o Definición de arquitectura de software y diseño de la
estructura principal del programa y funciones
Documentación Medidor de Consumo Guastavino – Schinca – Botto
21
o 11 de junio
• Presentación de avance del proyecto 3
o Armado de la placa
o Código de los módulos principales testeados hasta donde
era posible mediante simulación
o Obtención de parámetros y resultados desde un PC,
transmisión de parámetros desde el PC (si corresponde)
o 25 de junio
• Entrega final NO
o Testeo de la placa, mini errores en la placa (señales Tx y Rx
estaban al revés), prueba de 1-wire (problemas para
transmitir, espero…, mejoras en el código)… hojas de
datos ambigua (problemas para saber bien como
funcionaba el protocolo, la recepción del E0, adjuntar hoja
de datos)… esto generó atraso en el desarrollo de las
funciones…
o Código funcional excepto comunicación con 1-wire. Falta
implementar INT y pulir la implementación de las
funciones
o Placa corregida a partir de los errores detectados durante
el proceso de testing
• Replanificación
o Semana del 29/06 al 12/07 – Se prosiguió el estudio del código de la nota de aplicación y se descubrieron finalmente los inconvenientes que impedían el correcto funcionamiento. Se logró hacer funcionar el protocolo y se hicieron los testeos correspondientes
o Semana del 13/07 al 26/07 – Se generó el código para manejar las interrupciones y se ajustaron detalles del funcionamiento de las demás funciones y se realizaron testeos del sistema completo
o Semana del 27/07 al 08/08 – Semana de buffer por posibles ajustes en el cronograma anterior por fechas de exámenes, etc.
o Semana del 09/08 al 19/08 – Últimos retoques al código, incluyendo el doxygen. Generación de documentación y preparación de presentación
Dedicación horaria
• Aprox 160 h para un proyecto de 120 h