LED Control: PWM, Servo y LED Dimmer

En el artículo de hoy vamos a poder ver varias aplicaciones reunidas para lograr un objetivo común. Un control PWM trabajando a 1Khz, un LED Blinker, un alerta sonoro (BEEP), un servo con el que posicionaremos un potente conjunto de 36 LEDs blancos y un LED Dimmer para ajustar a voluntad la intensidad de iluminación alcanzada por esta fuente luminosa. Este desarrollo es parte de un proyecto colaborativo y comprende la iluminación que llevará a bordo un cuadricóptero (Quad). Luces direccionales e inteligentes para volar durante la noche y asistir de este modo al sistema de transmisión de imágenes en tiempo real. ¿Te gusta la idea? Observa como lo hacemos, te invitamos a compartir el diseño de esta parte de una aeronave que verás volar aquí, en NeoTeo.

Entre los mil y un detalles que debemos tener en cuenta al momento de diseñar un cuadricóptero encontramos la posibilidad (a veces necesidad) de dotar al desarrollo de un sistema de iluminación para favorecer las posibilidades de realizar vuelos nocturnos o con bajas condiciones de luminosidad ambiente. Un escenario de estas características se puede presentar en el momento y lugar menos esperado y es bueno tomar recaudos antes de lamentar esta falencia en nuestra nave. Además, esta disponibilidad se transforma en obligatoria al momento de contabilizar el uso de un sistema de transmisión de imágenes en tiempo real montado sobre el artefacto. Pero debemos ser muy cautos y cuidadosos con todo lo interesante que le podamos agregar a nuestra plataforma aérea: cada tornillo que utilicemos significa “peso agregado” y eso se notará en los motores al momento de efectuar maniobras rápidas o bruscas. Si nos dejamos guiar por nuestro entusiasmo, y le agregamos todo lo que se nos cruza por la mente, es probable que nuestro cuadricóptero ni siquiera logre despegar del suelo.

Despegar y realizar el primer vuelo es todo un desafío

Para evitar cualquier dolor de cabeza durante los ensayos de vuelo, lo mejor será pensar antes de la construcción, la manera más práctica y efectiva de realizar las cosas. Por supuesto, la iluminación será en base a diodos LED que serán montados en placas de material fenólico. A pesar de entender que en fibra (FR4) las placas lucirían de manera más profesional hay que evaluar lo elemental que mencionamos al inicio: el peso total aumentaría demasiado por el simple hecho de mantener una estética constructiva. Un trabajo bien ideado será tan funcional y efectivo en un material de soporte o en otro. Lo mismo ocurre con el anclaje de las placas. Podríamos haber adoptado una placa de aluminio del tamaño de los PCBs que soportan los LEDs mientras que la elección se orientó hacia una pequeña vara de ese material liviano. Es decir, logramos la misma función de soporte con menos de la mitad del peso posible. Además, no esperamos lograr una estructura fuerte y resistente a los impactos porque no esperamos exactamente eso: los impactos. Por último, un servo de características comunes cierra este montaje junto a dos soportes en forma de “L”, también de aluminio. Observa la construcción que hemos adoptado en el siguiente video:

Podemos agregar, a lo que hemos observado en el video, que una mejor estructura puede resultar más sólida y confiable, pero no debemos olvidar que esa ventaja se nos vuelve en contra, en peso agregado. Vale recordar además, que la iluminación y el sistema de transmisión de imágenes en vivo no son partes fundamentales para el funcionamiento de un cuadricóptero. Podemos volar sin estos elementos o podemos construir un vehículo para todo terreno sin iluminación ni video, pero la experiencia de tener estos “adicionales” es única y apasionante. Por lo tanto, abandonando los preámbulos, y avanzando sobre el funcionamiento del sistema deseado, abordaremos en primer lugar el funcionamiento general del conjunto y luego finalizaremos explicando las funciones destacadas de cada sección en particular. El corazón del sistema descansa en un poderoso PIC 18F25K20 al cual haremos trabajar como esclavo I2C en el momento final, cuando todo esté terminado. Es por ese motivo que en el diagrama en bloques figura la conexión a ese bus. Aprovechando las posibilidades que nos ofrece el módulo MSSP, que ya hemos visto en el montaje de un display I2C, acoplaremos nuestro sistema “esclavo” al bus I2C del sistema principal de control de la nave. De este modo, podremos operar las luces y la cámara del cuadricóptero desde el mismo sistema que se utilizará para comandar la nave.

Esquema básico del montaje realizado

Utilizando el PIC como esclavo I2C será muy sencillo recibir instrucciones y actuar en consecuencia ejecutando un trabajo que estará determinado por los tiempos que pueda manejar el sistema de proceso principal. Por ahora, y antes de trabajar sobre el dron volador, utilizaremos sencillos pulsadores de toque suave hasta terminar de ensayar el comportamiento del desarrollo completo. Este diseño comprende, en la parte inicial que veremos hoy, el movimiento de un servomotor entre dos posiciones extremas y la operación de un MAX16805 utilizando un PWM, generado por el PIC, para controlar la intensidad lumínica de los LEDs principales. Cuando el servo alcance los extremos de recorrido o en los momentos en que el PWM provoque la mínima o máxima intensidad de luz un Beep! sonará acompañado del destello de un LED (hemos elegido uno de color amarillo por ahora). El sonido del Beep puede ser simple o doble según nuestro gusto y sólo se usará en esta etapa de ensayos. En el montaje final sólo quedará el LED indicador que se podrá observar a distancia ya que el sonido del Beep no será muy útil allí, arriba de la nave. Por lo tanto, al llegar a los extremos sonará el Beep y seguirá haciéndolo una vez cada 10 segundos, indicando que estamos trabajando en un extremo. Al salir de esta situación, el Beep se silencia y el LED no destellará más. Obsérvalo:

Como has observado, hasta un LCD 16X2 hemos colocado sobre el puerto B del PIC para hacer sencilla la tarea de programación inicial. Por supuesto que el código, que encontrarás al final del artículo, incluye al LCD para que a ti también te resulte fácil el trabajo (muy útil para controlar el valor de las variables utilizadas). De este modo, reunimos en un solo montaje muchos circuitos que ya hemos visto por separado en NeoTeo, pero que en este desarrollo todos forman un conjunto único y con un objetivo específico: iluminar en la medida que sea necesario, el viaje nocturno de nuestra nave de exploración. Recordemos entonces algunos conceptos fundamentales. El MAX16805, encargado de administrar la iluminación de los 36 LEDs blancos de 10 mm., recibirá la señal PWM a una frecuencia de 1Khz. y mediante la variación del ciclo de trabajo se ajustará la intensidad de iluminación. Para esto utilizamos el módulo ECCP que posee el 18F25K20 y conectaremos la salida del canal 1 de PWM (CCP1) ubicado en PORTC.2 llegamos a la entrada DIM del MAX16805 a través de un pequeño divisor resistivo como muestra el siguiente esquema. El resto de la conexión necesaria para activar el MAX16805 será el mismo que vimos en el artículo del Dimmer, con la Rsense de 1 Ohm y su alimentación principal de 12Volts.

Circuito utilizado en este ensayo

Para el movimiento de los paneles de LED, como ya anunciamos y vimos en los videos, utilizaremos un servomotor convencional (en nuestro caso, un Hitec HS-311) al que debemos alimentar con 5Volts. A estos 5Volts también los utilizaremos para el adaptador de impulsos que formamos para activar la señal de control del servo. Anécdota: durante el inicio de los ensayos observamos movimientos erráticos en el servo ante las instrucciones directas desde el PIC que se alimenta con 3,3Volts. A pesar que las especificaciones técnicas hablan de que el servo puede trabajar con impulsos a partir de los 3Volts de amplitud decidimos colocar un adaptador de niveles (de 3,3V a 5V). Luego de esto, la respuesta del servo fue siempre exacta y precisa.

Distribución de las alimentaciones al desarrollo ensayado

Estas alimentaciones de 12Volts y de 5Volts se completan con una de 3,3Volts que es destinada al PIC y el circuito es el que te mostramos en la imagen superior. Vale aclarar que por comodidad y por costumbre técnica, nos referimos a valores de tensión de 12Volts a lo largo de toda la explicación pero para ser más exactos debemos aclarar que las baterías utilizadas en radiocontrol son las de Litio – Polímero (Li-Po) de tres celdas que poseen una tensión nominal de trabajo de 11,1Volts. Para los efectos prácticos, la tensión entregada es tan efectiva como si estuviéramos trabajando con una batería Lead-Acid de 12Volts. Además, todos los ensayos se hicieron con este tipo de baterías y es por este motivo que en todo el texto y en los circuitos mostrados, la tensión de alimentación referida es de 12Volts. Es importante dejar en claro este tema para saber que a la hora de montar todo sobre la nave, la tensión disponible será la indicada de 11,1Volts.

El ensayo y sus partes fundamentales

El programa generado para el PIC es muy sencillo y se basa en generar un sistema de instrucciones condicionales que interrogan durante todo el tiempo el teclado. Por supuesto, cuando pasemos a trabajar en modo I2C esclavo esta situación cambiará de manera radical, pero mientras realizamos los ensayos, 4 pulsadores de toque suave hicieron el trabajo de activar la movilidad y luminosidad del sistema. Volviendo a las partes sobresalientes del programa del microcontrolador destacamos la atención permanente de lazo principal a la potencial acción sobre los pulsadores. En caso de detección, el programa ejecutaba las poderosas instrucciones que brinda Amicus para operar servomotores y salidas PWM. En el caso del servo, basta con indicar el pin de salida y la posición deseada. Este último valor oscila entre 500 y 2500 según el tipo de servo utilizado y el largo de carrera deseado. En nuestro caso, los valores límites fueron 975 y 2140. El manejo y la generación de PWM, es igual de simple a través de una instrucción única, como en el caso del servo, sólo hay que definir el ciclo de trabajo (Duty-Cycle) (PVVM) y la frecuencia de trabajo deseada (FPWM). Estos valores se obtienen en variables que, a cada toque de un pulsador, incrementa o decrementa una unidad a la variable empleada. Es decir, generar un PWM, controlar un servomotor y activar su trabajo desde cuatro pulsadores es una tarea que Amicus te permite resumirla en 20 líneas de programa. Así:

Lazo principal de interrogación de estado de los pulsadores

Otra parte interesante para observar es la generación del Beep. No debemos olvidar que este sonido estará acompañado por la actividad de un diodo LED (en este caso amarillo) y ambos indicarán que las variables para el servo y el PWM llegaron a su valor máximo o mínimo. ¿Porqué un LED amarillo? Porque el dron estará lleno de LEDs rojos y verdes indicadores de funcionamiento de diversas etapas, por lo tanto el LED amarillo se podrá diferenciar sin problemas y se notará sin esfuerzo el estado de funcionamiento del sistema de iluminación. Para generar el Beep entonces, sólo necesitamos una única instrucción sobre una sola línea de programa: FREQOUT. Luego, el encendido y apagado del LED completan el indicador “audio-visual”

La instrucción FREQOUT, útil para activar alertas sonoros

Por último, otra secuencia de instrucciones muy útiles y eficaces son las que se encargan de generar la entrega de un Beep cada 10 segundos cuando alguna de las variables llega a su valor extremo. Haciendo un código fácil, se implementa un retardo de 10 segundos, luego se enciende y apaga el LED, se emite el Beep, se controlan el teclado y se cierra el lazo de programa. Sin embargo, estaríamos 10 segundos retenidos en un retardo de tiempo “inútil” mientras que la situación puede requerir algún movimiento o variación de intensidad de luz antes de que se completen los 10 segundos. Para esto, un elemental lazo For-Next resuelve este escenario de estar atento a cada momento de la acción del teclado, aunque estemos dentro del tiempo de conteo de 10 segundos para el Beep. ¿El TMR0? No, de este modo:

Rutina útil para estar atento durante un tiempo de espera

Con el condicional de la línea 93 verifico la actividad de los pulsadores cada 2 milisegundos (el tiempo que dura el retardo) y si alguno se activa a GND, salgo del lazo For-Next y acudo a la instrucción que me requiere en ese momento. Las instrucciones “OR” equivalen a lo que conocemos como “o” en nuestra lengua castellana. Este “o” aquél. Hoy “o” mañana. Es decir, si alguna de todas las entradas controladas posee un estado lógico bajo, el programa direccionará las acciones hacia la parte del código donde se haya producido el cambio de estados. En este caso será la acción de pulsar un botón, en el desarrollo final será una instrucción recibida mediante el bus I2C. El resto del programa del PIC son declaraciones de variables, asignación de valores iniciales a las mencionadas variables y, con estos valores, determinar una posición inicial del conjunto mediante el servo y un nivel de iluminación, también inicial, a través del PWM al MAX16805.

De este modo se completa la etapa de desarrollo y ensayo inicial del módulo de iluminación del cuadricóptero. La próxima fase estará abocada a comenzar a trabajar con el bus I2C desde otro microcontrolador y establecer las bases de la comunicación y del funcionamiento del PIC 18F25K20 en modo esclavo. Una vez completado ese proceso, el desafío pasará por optimizar el consumo energético. Luego, la reducción de peso en una construcción de tamaño acotado dará lugar a la última etapa: montar la cámara en el mismo brazo que maneja los LEDs (¿o en otro conjunto de servos independientes?, ¿tú que opinas?) y el transmisor de TV que emitirá las imágenes en vivo de cada vuelo, de cada aventura. ¿Quieres ser parte de esta experiencia? Participa en el Foro de Electrónica de NeoTeo; colabora aportando opiniones, sugerencias e ideas a esta parte del desarrollo. ¿Lo harías de otro modo?, ¿cómo?, ¿porqué? Cuéntanos, tu opinión nos interesa.

Código fuente + circuito en tamaño grande Descargar

Fuente:
http://www.neoteo.com/led-control-pwm-servo-y-led-dimmer

Retroinformática: Apple II (1977)

Luego del éxito obtenido por su primer producto -el Apple I- los “Steves” querían conquistar el mundo. Pero para ello necesitaban un ordenador más potente, con un mejor aspecto y que fuese fácil de utilizar por la mayor cantidad posible de personas. Nuevamente le tocó a Wozniak sentarse en la mesa de diseño, y otra vez el resultado fue espectacular: impulsado por un MOS 6502 de 8 bits y con una carcasa plástica de color beige que ocultaba hasta 48KB de memoria RAM, nacía el primer integrante de la familia Apple II, cuyos miembros serían comercializados entre 1977 y 1993.

El Apple I se había convertido en un “éxito de ventas”, a pesar de lo modesto que pueda parecer hoy (que se venden cientos de miles de iPads en las primeras horas de su lanzamiento) vender unas doscientas unidades de un producto a lo largo de toda su vida comercial. Lo que ocurre es que en esa época los ordenadores personales eran prácticamente desconocidos, su precio sumamente elevado, y la gente aún no terminaba de enterarse de que podía tener uno en casa. Cuando en la recién nacida Apple se dieron cuenta que diseñar y fabricar ordenadores podía convertirse en una verdadera mina de oro, se pusieron a trabajar en un nuevo ordenador destinado a reemplazar al Apple I. Esta vez sería un producto diseñado desde cero para ser comercializado, y dispondría de todo lo que un usuario hogareño podría necesitar. Steve Wozniack se encargó del diseño del nuevo ordenador, y puso en el todo lo que no había podido incluir en su primera maquina.

Publicidad del Apple II (Byte, Agosto de 1977)

El Apple I era una máquina construida a mano destinada básicamente a los aficionados que ya habían tenido algún contacto con los ordenadores. El Apple II, en cambio, fue un verdadero producto de producción masiva. Se convirtió en un ordenador extremadamente popular entre los usuarios hogareños pero -sobre todo a partir del lanzamiento de la hoja de cálculo VisiCalc- también se vendió muy bien entre los los hombres de negocios. Para lograr semejante revolución, Apple utilizó magistralmente las técnicas de marketing. Woz y Jobs se complementaban perfectamente. El excelente diseño del primero no hubiese sido más que una curiosidad si no hubiese contado con el empuje de Jobs, que junto a la agencia de publicidad Regis McKenna, que había diseñado para Apple el logotipo de la manzana mordida original (de color verde), se encargó de detalles completamente ajenos a la tecnología que había hecho posible el ordenador pero que impactaban visualmente en sus clientes. Así fue como insistió en resaltar la capacidad de mostrar colores del Apple II, colocándolo en un caja blanca en la que se destacaba una nueva versión de la manzanita, esta vez con los colores del arcoiris. Apple prestaría siempre mucha atención a estos detalles, algo que puede verse también en las primeras publicidades del Apple II aparecidas en las ediciones de 1977 de la revista Byte.

Era muy fácil acceder al interior del Apple II

¿Que hacia tan especial al Apple II? En primer lugar, ya no hacia falta que el usuario se procurase una carcasa y una fuente de alimentación para su ordenador. El Apple II era del tipo de “enchufar y usar”. Aún seguía siendo fácil retirar su tapa y acceder a su interior, pero no era un cacharro que desentonase en un hogar u oficina. Y en segundo lugar, su potencia -haciendo la comparación con otros ordenadores de la época- no era precisamente despreciable. Su placa base, en la que se encontraba el microprocesador MOS 6502 corriendo a 1 MHz, contaba con ocho ranuras de expansión y hasta 48 KB de memoria RAM. Pero lo que lo convertía en un verdadero objeto del deseo era su capacidad para desplegar colores y gráficos de alta resolución, su generador de sonidos y el lenguaje de programación BASIC (Integer BASIC) incluido. A diferencia de ordenadores como el Altair 8800, que estaban principalmente dirigidos a ingenieros y aficionados, el Apple II era un producto destinado a las masas.

Apple II Plus

A lo largo de unos 15 años de historia, Apple comercializó una gran cantidad de modelos diferentes de su “Apple II”. El original, puesto a la venta el 5 de junio de 1977, utilizaba el mencionado microprocesador 6502 de MOS Technology a 1 MHz, disponía de 4 Kilobytes de RAM, el lenguaje de programación Integer BASIC en sus 12 KB de ROM y un conector para utilizar un grabador de casetes de audio como dispositivo de almacenamiento de datos. En cuanto al vídeo, una de las características más sobresalientes de este ordenador, era capaz de mostrar 24 líneas de 40 columnas de texto en mayúsculas sobre un monitor o aparato de TV, gracias a un modulador de RF. El precio de lanzamiento para este modelo fue de 1.298 dólares, y la versión con 48KB de RAM podía conseguirse por 2.638 dólares, monto que sirve para darse una idea de lo que costaba la memoria por aquellos años. El éxito del Apple II atrajo como moscas a muchos fabricantes, que comenzaron a diseñar placas de expansión o software para mejorar aun más las características del ordenador. Así fue como aparecieron tarjetas para mostrar texto en 80 columnas, otros lenguajes de programación, juegos y aplicaciones. Apple también desarrolló muchos periféricos, como el Disk II -una unidad de disco flexible de 5¼ pulgadas externa más una tarjeta controladora- que evitaba la agonía de las esperas interminables que tenían lugar cuando se intentaba cargar un programa extenso desde un casete de audio. Diseñada también por Woz, la interfaz del Disk II es considerada una de los más interesantes diseños electrónicos de la historia.

VisiCalc, corriendo en un Apple II

Tal como ocurriría años más tarde con el IBM PC, el diseño abierto y la inclusión de conectores de expansión hicieron posible la aparición de cientos de dispositivos que ayudaron a popularizar el Apple II. Si uno se pone a ojear una revista informática de fines de la década de 1970, verá una gran cantidad de anuncios destacando las bondades de productos para este ordenador, como controladoras de comunicaciones seriales, primitivas tarjetas de red y, un poco más tarde, hasta unidades de disco duro. Algunos llegaron a construir tarjetas de expansión dotadas de un microprocesador Z80, lo que brindó al Apple II la posibilidad de ejecutar programas desarrollados para el -entonces- muy popular sistema operativo CP/M. Así fue como los usuarios de este ordenador accedieron a gestores de base de datos como el dBase II o el procesador de texto WordStar. A medida que fueron pasando los meses, el costo de los componentes utilizados en la construcción del Apple II fueron bajando de precio, a la vez que la competencia comenzaba a desarrollar productos que podrían desplazarlo del mercado. Esto hizo que Apple creara nuevas versiones de su ordenador, lo que originó una numerosa familia cuyo linaje se extendió hasta más o menos los primeros años de la década de 1990.

Apple IIc, el “portátil” de la familia

La primer revisión del Apple II tuvo lugar en 1979. Denominado “Apple II Plus”, incluía de serie el Applesoft BASIC -escrito por Microsoft- que hasta entonces solo se ofrecía como una mejora y que permitía entre otras cosas operar con números de coma flotante. La memoria RAM inicial era de 16KB (o 48KB, si estabas dispuesto a gastar un poco más) y podía ampliarse a 64KB. Este hardware hizo posible que la máquina de Apple pudiese correr los compiladores UCSD Pascal y FORTRAN 77, muy populares en aquella época. Durante tres años el “Plus” mantuvo a Apple entre los primeros puestos de ventas. Cuando su popularidad comenzó a declinar ligeramente se decidió bajar su precio, así fue como en 1982 se lanzó el modelo “IIe”, una versión que aprovechaba los nuevos chips disponibles en el mercado para reducir su número, el tamaño de la placa principal y -por supuesto- el costo final del ordenador. Este modelo, además de ser más barato, podía mostrar en la pantalla letras mayúsculas y minúsculas y disponía de 64 KB de RAM ampliables a 128 KB. El Apple IIe (“Enhanced A pple II”) fue el modelo más popular de la familia y es uno de los que más fácil se puede conseguir en la actualidad.

Apple IIGS, una verdadera belleza

En mayo de 1984 se puso a la venta el primer modelo portátil de la familia, el Apple IIc. Su corazón era el microprocesador 65C02, una versión mejorada en tecnología CMOS del “viejo” MOS 6502 utilizado en los modelos anteriores. Las mejoras no terminaban allí: el IIc, denominado “Lolly” durante su desarrollo, era capaz de mostrar 80 columnas de texto sin la ayuda de placas extras, conectarse con otros ordenadores mediante una la linea telefónica gracias a su modem interno, acceder a unidades de disquetes desde su controladora integrada y mucho más. Su diseño, más compacto que el de sus hermanos, limitaba bastante su expansión. En 1986 se presentó el que sería el miembro más poderoso de la familia Apple II. A pesar de que en 1894 la empresa había comenzado a comercializar el Macintosh -mucho más potente y dotado de una GUI- el éxito el Apple II no se había acabado. El Apple IIGS representó un cambio importante en la “familia”, ya que su microprocesador 65C816 contaba con registros de 16 bits y un bus de direcciones de de 24 bits. Corría a 2.8 MHz, tenía más memoria (256KB o 1024KB, expandibles a 8 MB), y una interfaz gráfica de usuario inspirada en la del Macintosh.

Apple IIc Plus , de 1988

La ultima “encarnación” del Apple II fue el Apple IIc Plus de 1988. No era demasiado diferente al IIc, pero contaba con una novedosa unidad de discos de 3.5 pulgadas, incluía una fuente de alimentación interna y su microprocesador 65C02 marchaba a 4 Mhz. Era, tal como venia de fábrica, el modelo más veloz. Sin embargo, algunas tarjetas de ampliación como la RocketChip o la ZipGS permitieron a diferentes modelos del Apple II correr a 10 o 12 MHz. Apple aún fabricaría y ofrecería soporte para esta familia hasta más o menos 1993. Sin embargo, los tiempos habían cambiado y un ordenador que tenia sus raíces profundamente enterradas en los 8 bits reinantes a fines de la década de 1970 no tenia mucho futuro frente a “monstruos” como el IBM PC, el Macintosh o los Amiga. Poco a poco los Apple II fueron desapareciendo de la escena, y a pesar de que se vendieron millones y que muchas empresas incluso fabricaron clones de ellos, hoy hay mucha gente que jamás oyó hablar de estos ordenadores. Sin embargo, fueron una parte muy importante de la historia de los ordenadores personales. ¡Hasta la próxima semana!

http://en.wikipedia.org/wiki/Apple_II_series

Fuente:
http://www.neoteo.com/apple-ii-1977

El virus informático cumple 40 años

Hoy su existencia ya se da por asumida. El combatirlos es una reacción natural en todo usuario. Sus consecuencias son bien conocidas, y evolucionan con cada día que pasa. A pesar de la fortaleza actual que tienen hoy los virus de ordenador en sus múltiples formatos y versiones (de allí el uso recurrente y general del término malware), incluso ellos tuvieron un comienzo, uno que está bien definido, y que fue mucho más inocuo de lo que podemos imaginar. El virus informático cumple cuatro décadas de edad. ¿Qué podemos decir que sea adecuado para la ocasión? ¿Feliz cumpleaños?

El año era 1971. El programa Apolo seguía con sus andanzas en la Luna, se nos iba Jim Morrison, se inauguraba el Walt Disney World, e Intel fabricaba el primer microprocesador disponible comercialmente, el 4004. Internet todavía no existía, pero su esencia básica sí: ARPANET llevaba unos dos años operando, y había aproximadamente dieciocho nodos conectados. Fue entonces que un tal Bob Thomas en BBN Technologies decidió demostrar el concepto de “aplicación móvil”. Y así fue como nació “Creeper”. La traducción de “creeper” tiene muchos significados, aunque una de los más conocidas se perfila con la idea de un “acechador”, alguien que hace cosas extrañas y perturbadoras como vigilar constantemente por una ventana u observar a una persona mientras duerme. La idea del virus informático aún no se había desarrollado, pero el comportamiento del Creeper era definitivamente como uno. Ingresaba al sistema remoto, publicaba el mensaje “Soy el Creeper, ¡atrápame si puedes!”, y luego saltaba a otro sistema. No se copiaba, sino que se trasladaba. Y con eso, quedó comprobado que una aplicación podía “moverse” entre sistemas.

El Creeper hacía de las suyas entre los PDP-10

Cuarenta años después estamos deseando que este señor Thomas jamás hubiese creado al Creeper. De hecho, fue necesario desarrollar al “Reaper” para borrar al Creeper, lo que en cierta forma le da a virus y antivirus el mismo año de nacimiento. Pero con deseos no hacemos nada, y la historia ciertamente no se termina ahí, sino que en realidad comienza. En estos días, un virus informático es interpretado por los usuarios de la misma forma que un resfriado: Uno puede defenderse lo mejor que puede, pero tarde o temprano, se lo debe enfrentar. Sin embargo, el perfil general de un virus era muy diferente hace unos años atrás. Quienes desarrollaban un virus, tenían como simple objetivo hacer una broma, demostrar sus habilidades, o en algunos casos, realizar una declaración política. Ahora, la raíz de la existencia del malware se basa en el lucro. Internet es grande, y hay demasiado terreno para cubrir, pero al mismo tiempo, se interpreta que hay mucho que “robar” de las terminales afectadas. Esto los hace más complejos, más elaborados, y mucho más peligrosos.

Creeper fue el primero, y otros le siguieron, al principio en ambientes controlados. Pero el primer virus que se considera “salvaje” y que operaba por fuera de su entorno original de desarrollo fue el “Elk Cloner”, creado por Rick Skrenta en el año 1982, con apenas quince años de edad. Afectaba a discos flexibles que se utilizaban en sistemas Apple II, y fue el primer virus en adoptar el modo de infección por sector de inicio. Cuando el ordenador se iniciaba con un disquete infectado, el virus se copiaba en la RAM e infectaba cada sector de inicio en cada nuevo disquete que se introdujera en la unidad, esparciéndose rápidamente. La inexistencia de un antivirus per se, hacía que el proceso de remoción del Elk Cloner fuera un poco rebuscado en ese entonces. Para Skrenta no fue más que “una tonta broma”, pero las infecciones por sector de inicio serían adoptadas por muchos otros virus en los años siguientes.

Con sus unidades duales, las Apple II eran caldo de cultivo para el Elk Cloner

Dos virus que tuvieron una atención especial durante la década de los ‘80 fueron el Jerusalem y el Stoned. Ambos compartieron el mismo año de nacimiento (1987), pero sus objetivos eran muy diferentes. En el caso del Jerusalem, el virus podía arruinar a todo archivo ejecutable en un sistema infectado cada viernes 13 del calendario, e incluso podía afectar negativamente el rendimiento del ordenador. Para muchos, se trató del primer virus “destructivo” que operó a gran escala, frase que tomamos con pinzas teniendo en cuenta la cantidad de ordenadores activos en 1987, pero justificada debido a su enorme cantidad de variantes. En lo que se refiere al Stoned, su mensaje característico “Your PC is now Stoned!” todavía es muy recordado, al igual que su petición para legalizar la marihuana. El Stoned tuvo su amplia cuota de variantes, una de ellas cambiando el mensaje clásico por una referencia al 4 de junio de 1989, una de las fechas de la Masacre de la Plaza Tiananmen en China.

La década de los ‘90 fue testigo de un incremento importante en la cantidad de virus, pero en lo personal recuerdo a dos que supieron dejar una huella propia en esos años. El Michelangelo fue todo un caso. La primera vez que se lo detectó fue en 1991, y se esperaba que fuera el causante de una especie de “día del juicio digital”, borrando la información de millones de ordenadores alrededor del mundo. El virus se activaba el 6 de marzo, día del nacimiento de Miguel Ángel, sobreescribiendo sectores en disquetes y discos duros. Los medios realizaron una cobertura extensa, incluyendo por supuesto la inevitable pizca de paranoia que se le agrega a esta clase de noticias. Finalmente, los casos de pérdida de información fueron apenas una mínima fracción de los supuestos millones que vaticinaban los noticieros, y el Michelangelo rápidamente pasó al olvido. En un aspecto mucho más preocupante, a mediados de 1998 hizo acto de presencia el virus CIH, cuya primera versión se activaría el 26 de abril de 1999, coincidiendo con la fecha de la catástrofe nuclear en Chernobyl. En el peor de los casos, el CIH podía llenar el primer megabyte del disco de inicio con ceros, e incluso modificar el BIOS del ordenador, inutilizándolo por completo de forma efectiva. Si bien era posible restaurar a un ordenador tras un ataque de este virus, no era un proceso agradable.

Finalmente llegamos al siglo XXI, y con él llegó la “Era del Caos”, ya que la definición clásica de virus informático pasó a ser mucho más compleja de aplicar. El gusano ILOVEYOU dejó en evidencia qué tan eficiente podía ser un e-mail para esparcir un virus. En 2003, Windows 2000 y Windows XP fueron puestos en jaque por la aparición del archifamoso gusano Blaster, que podía incluso apagar el ordenador sin intervención del usuario. Esto llevó a cambios profundos en los sistemas de Microsoft, y a una mayor consciencia en relación con los firewalls como medida de seguridad. El Welchia era un gusano por definición, pero en realidad lo que hacía era quitar al Blaster del sistema y actualizar Windows, razón número uno por la cual el Blaster pegó tan duro. En 2004 la masacre siguió con el Sasser y el MyDoom. Zotob marcó el inicio del “malware por lucro” en 2005, y la introducción de las botnets como plataformas de malware.

¿Recuerdan esto? Estoy seguro que sí...

En el primer mes de 2007, el gusano Storm era responsable por el ocho por ciento del malware a nivel mundial. Un año después nos resultó imposible olvidar al Conficker, que generó pérdidas millonarias alrededor del globo, y resultó ser un hueso extremadamente duro de roer. Ahora, somos testigos de los primeros indicios de guerra digital. El troyano conocido como Stuxnet tenía como blanco específico los sistemas de Control de Supervisión y Adquisición de Datos de Siemens, utilizados en territorio iraní en desafío al embargo impuesto a ese país en 2006 debido a su programa de enriquecimiento de uranio. El 60 por ciento de las infecciones causadas por Stuxnet se localizaron en Irán, y provocó retrasos en la capacidad operativa de varias centrifugadoras de gas.

El Stuxnet se concentró sobre componentes Siemens de forma muy precisa

Estamos en camino de abrir el cuarto mes del año 2011. ¿Que es lo que tienen preparados para nosotros los virus? Los expertos coinciden en que habrá una aceleración en las infecciones de malware sobre dispositivos móviles como tablets y teléfonos inteligentes, al mismo tiempo que buscarán aprovechar vulnerabilidades presentes en diferentes redes sociales. Y el número seguirá creciendo. A principios de la década de los ‘90, los virus registrados no excedían los mil cuatrocientos ejemplares. Hoy, tenemos más de 200 millones de variantes, y se está haciendo cada vez más difícil deshacerse de ellas. Y todo, con aquel pequeño Creeper saltarín como punto de origen. Si los virus quieren tener un feliz cumpleaños, que lo tengan, pero si se ahogan con el pastel, nos harán a todos un gran favor.

Fuente:
http://www.neoteo.com/el-virus-informatico-cumple-40-anos

Retroinformática: MOS KIM-1 (1976)

MOS Technology Inc, obligada por una demanda legal impuesta por Motorola, debió modificar la distribución de pines de su producto estrella, convirtiéndolo en un trozo de plástico, metal y silicio incompatible con los ordenadores que utilizaban el Motorola 6800. Así fue como nació el “Keyboard Input Monitor” o KIM-1, un pequeño ordenador de una sola placa destinado a servir como entrenador a los diseñadores de hardware. Inesperadamente, KIM-1 fue muy bien acogido por los entusiastas y se convirtió en un éxito. Hoy te contamos la historia del bisabuelo del Commodore 64.

La semana anterior te contamos como Woz, con la ayuda de Jobs, convirtió un montón de chips sueltos en el Apple I, creando además una de las empresas del sector informático mas importantes e influyentes del mundo. Pero antes de seguir avanzando y presentando modelos de ordenadores similares al de Apple, le vamos a dedicar un poco de tiempo a una clase de microcomputador que tecnológicamente puede situarse entre los del tipo del Altair 8800 o el IMSAI 8080 y los que siguieron al Apple I. Pensados como “kits de desarrollo”, estos pequeños sistemas eran muchas veces producidos por los mismos fabricantes de chips, como una herramienta para que los ingenieros pudiesen evaluar y probar sus productos. Pero la sed de conocimientos y el entusiasmo de los usuarios de la época convirtieron a muchos de esos kits en verdaderos éxitos comerciales. El caso más emblemático es el del MOS KIM-1.

KIM-1, creado en 1975 y presentado en las tiendas en 1976. (Vern Graner )

En los primeros años de la década de 1970, la empresa MOS Technology recibió con agrado la incorporación a su plantilla de personal de un grupo de ingenieros que había abandonado a su competidor Motorola. Este grupo de especialistas, encabezados por Chuck Peddle, habían sido los responsables de crear el famoso microprocesador Motorola 6800. Una vez instalados en MOS, pusieron manos a la obra y en pocos meses repitieron el trabajo creando un clon del 6800 llamado MOS 6801. El chip era indistinguible del fabricado por Motorola -al fin y al cabo, habia sido creado prácticamente por el mismo equipo de trabajo- y era 100% compatible con aquel, pero un poco más barato. Esto le permitió a MOS ganar buena parte del mercado, ya que su producto podía ser directamente enchufado en una placa madre diseñada para el chip de Motorola. Obviamente, esta situación le gustó muy poco a los abogados de la creadora del 6800, que empapeló a MOS Technology con una serie de demandas legales.

Tarjeta de ampliación del KIM-1. (Vern Graner )

Como suele ocurrir en estos casos, la justicia tuvo un comportamientos más bien extraño, y permitió a MOS salir del embrollo en que se había metido simplemente modificando la distribución de los pines de su chip. El nuevo modelo, llamado MOS 6502, seguía siendo un “6800”, pero las patitas metálicas del microprocesador se ordenaban de una forma diferente. Esto provocó que ya no fuese posible el reemplazo directo entre chips, y las ventas de MOS comenzaron a resentirse. Era necesario convencer a los desarrolladores de que el MOS 6502 era un micro útil, y para ello hacia falta proporcionarles una plataforma económica y flexible con la que pudiesen “jugar” hasta familiarizarse con el producto. Así fue como el mismo Chuck Peddle tuvo a su cargo el desarrollo de un kit destinado a suplir esta demanda. El resultado fue el “Keyboard Input Monitor” o KIM-1, creado en 1975 y presentado en las tiendas en 1976.

El usuario disponía de un teclado compuesto por 24 teclas

El KIM-1 era un pequeño microcomputador cuyos componentes se alojaban en una sola tarjeta de circuito impreso. Resultaba muy fácil de montar, ya que a diferencia de otros kits anteriores solo empleaba unos pocos chips. El usuario disponía de un teclado compuesto por 24 teclas -10 dígitos, letras de “A” a “F” y algunas teclas de control- y una “pantalla” formada por 6 digitos LED de 7 segmentos. A pesar de lo rudimentario que esto pueda parecer, era infinitamente mejor que el sistema de llaves y LEDs utilizados por MITS o IMSAI. Pero lo que más gustó a los interesados en los ordenadores en forma de KIT fue su precio: 245 dólares. Por ese dinero, el comprador se llevaba a su casa un computador funcional (o al menos, “funcional” luego de haberlo ensamblado) con 1KB de RAM completo. Para tener una idea del valor que tenia para un programador esa “enorme cantidad” de memoria, basta con recordar que para llegar a ese monto, MOS empleó 8 chips MOS 6102, cada uno con 1024 bits.

No era muy difícil copiar este PCB. (Vern Graner )

Una de las características más interesantes del KIM-1 era su posibilidad de expansión. Peddle había utilizado dos chips MCS6530 “Peripheral Interface/Memory Device”, capaces de gestionar más memoria o periféricos. Dos conectores situados en el borde izquierdo de la placa permitían agregar dispositivos al sistema, y rápidamente la comunidad comenzó a desarrollar interfaces para grabadores de cassettes, terminales de vídeo, ampliaciones de memoria y mucho más. El mercado rápidamente se inundó de libros dedicados al KIM-1. En ellos se podia encontrar información indispensable sobre su hardware, pequeños ejemplos de software, y guías para escribir programas utilizando el lenguaje ensamblador del 6502. Entre los agregados más comunes se encontraba uno con un pequeño altavoz, que gracias a un programa permitía al KIM-1 generar sonidos y melodías. Una versión de BASIC, el Tiny BASIC, también fue adoptada por muchos usuarios, a pesar de que requería de 4BK de RAM adicionales. Leer esos 4KB desde una cinta de cassette demoraba aproximadamente 15 minutos.

Compleja tarjeta de expansión, de 1979. (Vern Graner )

Cuando el KIM-1 ganó cierta popularidad, ocurrió lo inevitable: surgieron los clones. Irónicamente, la empresa que había sido obligada a rediseñar su producto por ser la copia de otro, comenzó a ser copiada más o menos descaradamente. La sencillez del KIM-1 permitía que prácticamente cualquier aficionado realizase un proceso de “ingeniería inversa” sobre la placa de circuito impreso de dos caras, obtuviese un volcado de la ROM y -en pocos días- tuviese un nuevo ordenador. Muchos lo hicieron, y algunos -como el KIN-1, de KIN Computers- fueron utilizados como “ordenadores de vestir”, disimulados bajo la ropa y utilizados en los casinos para “contar cartas” en las mesas de juego. Pero la competencia más fuerte surgiría de Rockwell International y Synertek.

Rockwel AIM 65, algo más completo que el original. (oldcomputers.net)

Rockwell International, un fabricante de semiconductores, disponía de una licencia para comercializar su propia versión del microprocesador 6502, y sus responsables viendo el éxito que estaba teniendo el KIM-1, no dudaron en crear su propia “tarjeta de evaluación”. Así fue como en 1976 nació el Rockwel AIM 65, un microcomputador dotado de un teclado ASCII completo, una pantalla compuesta por 20 caracteres LED alfanuméricos de 14 segmentos y una pequeña impresora. Era mucho más atractivo que el KIM-1, y los chips opcionales de ROM conteniendo un programa ensamblador o un intérprete BASIC de Microsoft ofrecidos por Rockwel lo convirtieron en el favorito de muchos usuarios.

ynertek apostó por su SYM-1. (oldcomputers.net)

Synertek tampoco quería quedar fuera del negocio, por lo que puso a sus ingenieros a trabajar contra reloj, y pocas semanas despues presentó el SYM-1, un sistema algo mejor que el KIM-1 pero no tan completo como el AIM 65. Disponía de una pantalla como la del primero, pero un teclado -de membrana- con 29 teclas bastante más completo que el original de MOS. Sus desarrolladores lo dotaron de los mismos conectores de expansión que el original, por lo que las placas diseñadas para el KIM-1 podían utilizarse sin cambios en el producto de Synertek. En la placa madre también había una interfase RS-232 “de verdad” (es decir, con los voltajes exactos requeridos por la norma), lo que decidió a muchos usuarios a elegir este modelo y no otro. Pero la historia del KIM-1 estaba lejos de terminar.

El “KIM-2” se convirtió en el “Commodore PET 2001” (Bill Bertram)

MOS Technology fue comprada por la ascendente Commodore International, una empresa propiedad de Jack Tramiel que comenzó fabricando máquinas de escribir, más tarde había incursionado (con mucho éxito) en el mercado de las calculadoras electrónicas y que había decidido probar suerte con la venta de ordenadores personales. Commodore comercializó durante algún tiempo el KIM-1 con su marca, pero puso a Chuck Peddle a trabajar en una versión ampliada del sistema. El nuevo KIM debía contar con un teclado QWERTY completo (como el que tenían las máquinas de escribir), un grabador de cassette, un BASIC en ROM listo para utilizarse ni bien se encendiese el ordenador, y una pantalla de vídeo. Para entrar con fuerza en el mercado de los ordenadores, Commodore necesitaba algo de la talla del Apple I, y Peddle era el indicado para proporcionárselo. Cuando el producto estuvo listo, en 1977, fue comercializado como “Commodore PET 2001”, antecesor del Commodore VIC20 y -por lo tanto- “abuelo” del Commodore 64, ordenadores a los que sin duda dedicaremos un artículo en las próximas semanas.

http://en.wikipedia.org/wiki/KIM-1

Fuente:
http://www.neoteo.com/retroinformatica-mos-kim-1-1976

LM92: Termómetro I2C de 12Bits

LM92 es un sensor de temperatura digital que posee conectividad I2C, una exactitud de hasta 0,33°C en la medición y 12 bits de resolución. Esto representa variaciones de temperatura de tan solo 0,0625°C. Estas cualidades lo transforman en un termómetro ideal para sistemas de alta precisión donde la temperatura es un factor crítico a monitorear. Junto a un sistema de “ventana” de comparación térmica, posee alarmas por baja temperatura, alta y hasta por temperatura crítica. Los ajustes de estos valores son programables de manera muy sencilla y creemos que ya no podemos seguir contándote las bondades de este dispositivo; es momento de que ingreses al artículo y te asombres con este montaje didáctico, sencillo y profesional.

Un medidor de temperatura sencillo puede admitir errores de acuerdo al ámbito donde se utilice y según las necesidades que la aplicación requiera. No será lo mismo un sensor de temperatura para un termómetro domiciliario que para un equipo médico, por ejemplo, una incubadora de bebés. Tampoco será igual el empleado en el letrero luminoso de una esquina de la ciudad que el utilizado en un invernadero, es decir, para cada aplicación las exigencias pueden cambiar de manera radical. National Semiconductor nos ofrece, en el LM92, un producto de la más alta calidad para desarrollos donde las exigencias sean rigurosas, donde los rangos de temperaturas a medir tengan una extensión considerable (-55°C a +150°C) y cuando debamos obtener un desempeño destacado. Muchas características te hemos adelantado en el encabezado del artículo, pero en el desarrollo de este texto podrás comprobar lo sencillo que es acceder a un sistema de control térmico de calidad profesional.

Termómetros de toda clase y calidad

El LM92, como comentamos antes, brinda la posibilidad de trabajar con lo que se llama una “ventana térmica”. El circuito integrado posee un registro (programable) que almacena un valor mínimo de temperatura por debajo del cual, una alarma se activa. Es decir, podemos programar el registro mencionado para que haga sonar una alarma si la temperatura del criadero de aves descendió de una determinada temperatura y los animales corren riesgo. Así, el sistema avisará con un alerta que la temperatura ha descendido por debajo de un nivel prefijado. A este registro se lo conoce como T_LOW y por supuesto, también existe otro registro similar que ofrecerá un aviso al superar un nivel alto de temperatura: el registro T_HIGH. De este modo, por debajo de un valor térmico programable y por encima de otro, las alarmas se activan. Eso es la “ventana térmica”: los valores que quedan comprendidos entre T_LOW y T_HIGH. Asociado a estos niveles existe un tercero que es la lógica histéresis que debe tener la activación o no de las alarmas para evitar situaciones confusas o disparos intermitentes.

Diagrama en bloques del LM92

Las salidas de estas alarmas se presentan al usuario en un mismo pin (5) con el nombre INT. Esto es lógico debido a que la alarma avisará cuando la temperatura esté fuera de los valores de “ventana”. La salida es Open Drain y en consecuencia su habilitación producirá un estado lógico bajo en el mencionado pin del dispositivo. Recordemos que Open Drain es la analogía al Open Colector (Colector Abierto) pero realizado con transistores MOSFET tal como se puede ver en el diagrama superior. Allí se puede observar también que existe un cuarto registro que activa una alarma cuando ya las lecturas térmicas superan un valor crítico. El registro T_CRIT también programable y de manera habitual se ajusta con la finalidad de preservar estructuras físicas, evitar daños al propio sistema electrónico y, como decíamos, se suele ajustar a valores altos de lectura. De todos modos, puedes moverte dentro de lo que el rango de medición que el LM92 te permite. Esto es, puedes ubicar la temperatura crítica por debajo de la ventana térmica y disparar una alarma cuando la temperatura descienda a niveles demasiados peligrosos (congelación). Es importante que tengas en claro este concepto. La temperatura crítica no sólo es aplicable a valores altos sino que también puede actuar a niveles muy bajos. Mientras ubiques ese valor fuera de la ventana térmica, el trabajo de esta alarma tendrá sentido y del mismo modo que la anterior, se presenta como Open Drain en el pin 3.

Vista ejemplo de cómo una variación de temperatura atraviesa los límites establecidos por los registros

Los valores que adopta el dispositivo al iniciar su trabajo cada vez que se le aplica energía es el siguiente:

• Histéresis de temperatura (T_HYST) = 2°C
• Temperatura Baja (T_LOW) = 10°C
• Temperatura Alta (T_HIGH) = 64°C
• Temperatura Crítica (T_CRIT) = 80°C

Luego, estos valores pueden ser cambiados al inicializar el funcionamiento mediante el programa del microcontrolador. De este modo, el LM92 ahorra muchas líneas de código al programador evitando tener que utilizar pines del microcontrolador para las alarmas o para organizar la secuencia de trabajo de la ventana térmica, la temperatura crítica y la histéresis de activación/desactivación. El ahorro del tiempo de programación, al igual que los recursos de hardware han sido muy bien pensados y ejecutados por la gente de National Semiconductor en el diseño del LM92. Eso nos permite utilizar estructuras básicas para trabajar. Por ejemplo, en nuestro caso hemos utilizado nuestro clásico hardware Amicus para llevar a cabo el montaje. Aprovechando el mismo diseño base que hemos empleado para otros montajes, nos apoyamos en el PIC 18F25K20 que es un procesador muy versátil y confiable, ideal para este tipo de desarrollos. El circuito adoptado, por lo tanto, es el siguiente:

Circuito propuesto con el PIC18F25K20 y el LM92

Gracias a que el LM92 permite una alimentación que puede ser de 3,3Volts o de 5Volts (2,7V a 5,5V) aprovecharemos la misma alimentación que el PIC para realizar el trabajo. Las líneas SDA y SCL utilizan resistencias “pull-up” de 1K y las salidas Drain abierto de las alarmas se conectan de manera muy sencilla con un LED y una resistencia limitadora a la línea de tensión de 3,3Volts. El LED amarillo que se observa en el diagrama está colocado para ayudarnos en el trabajo de programación. La idea básica de su uso es hacerlo encender al principio de alguna rutina “importante” y apagarlo al final de la misma. Es una de las mil formas que puedes tener para ayudarte en la programación. Si el LED destella es porque el ciclo de programa se completa, si no lo hace es porque se interrumpe en algún sitio y de acuerdo al estado puedes descubrir donde se detiene la ejecución del programa. En nuestro ejemplo, su funcionamiento se encuentra antes de la toma de datos y al finalizar la presentación en el LCD siguiendo un orden muy sencillo de programa:

• Declaro las variables a utilizar.
• Escribo los registros de temperaturas a los valores que voy a utilizar.
• Comienzo un lazo infinito y enciendo el LED.
• Leo por Bus I2C el registro de temperatura.
• Realizo el proceso sobre la información obtenida y la presento en el LCD.
• Apago el LED y espero un tiempo hasta volver a iniciar el lazo.

Eso es todo el programa necesario para hacer funcionar al LM92 y aprovecharlo en sus funciones más importantes. Luego de observar este video donde hacemos una introducción al funcionamiento de nuestro desarrollo veremos la forma en que se organiza la estructura de los registros y cómo podemos trabajar con ellos.

Como todo dispositivo I2C, el LM92 posee un protocolo de comunicaciones que, mediante una estructura determinada, se comunica con el PIC intercambiando todos los datos necesarios para un funcionamiento apropiado. En este caso, la estructura está explicada en la hoja de datos del LM92 (Pág. 13, Fig.6) y haremos un pequeño repaso de cómo es el funcionamiento que hemos utilizado para ayudarte a que comprendas de manera más rápida los pasos a seguir y no pierdas el tiempo valioso que puedes emplear en el desarrollo del resto de la aplicación. Comenzamos entonces con “abrir” el bus I2C mediante la instrucción HBSTART. En Amicus, este formato de instrucción indica que utilizaremos el módulo MSSP del PIC para realizar la comunicación. Dicho de otro modo, usaremos los pines dedicados por hardware para facilitar el trabajo del PIC. Luego de abrir el canal de diálogo, nos abocaremos a escribir los registros internos del LM92, si es que deseamos cambiar los límites de trabajo de las alarmas respecto a los valores que el dispositivo trae programado por defecto al momento de inicializar su funcionamiento. Por este motivo, si deseamos trabajar con valores diferentes a los que trae el LM92 por “default”, dentro de la estructura de nuestro programa en el PIC, debemos escribir nuestros valores de trabajo.

Estructura de cómo se lee o escribe utilizando el "puntero" y los bytes de datos

La escritura es muy sencilla y se divide en dos partes. Primero se le indica al “puntero” (Pointer) del LM92 el registro sobre el cual vamos a trabajar. Este trabajo se realiza “escribiendo” con la instrucción HBUSOUT seguida de la dirección (Address Byte) del LM92 dentro del bus y posteriormente del número de registro. Por ejemplo: para indicarle al puntero que trabajaremos sobre el registro T_LOW, escribiremos una instrucción {HBUSOUT Address Byte, [N° de Registro]}. De este modo, el LM92 se prepara para recibir una actividad en ese registro que puede ser de escritura o de lectura. En este caso será de escritura, pero del mismo modo podemos proceder para tomar lectura del valor almacenado en el registro cuando realicemos desarrollos más complejos con ventanas dinámicas de trabajo. Es decir, cuando el sistema se encargue de adecuar en forma automática los valores de la “ventana térmica” en función de las necesidades del diseño y del desarrollo del programa ejecutado por el PIC.

Fragmento donde se programan los registros

Luego, escribimos el valor adecuado con el siguiente formato: {HBUSOUT Address Byte, N° de Registro, [Dato a escribir]}. De este modo, y como puedes ver en la imagen superior, se modifican los registros internos del LM92. Al descargar y leer el listado que forma el programa observarás que donde dice “Escribo” en la imagen superior significa que el programa está indicando la dirección del LM92 dentro del Bus con el último bit (R/W) en cero para indicar escritura. Luego, cuando realicemos una lectura este bit cambiará a un uno lógico y la etiqueta cambiará de nombre. Por último, cuando todos los registros sean escritos, según nuestro criterio, cerraremos la comunicación I2C mediante la instrucción HBSTOP. De este modo, ya estamos en condiciones de comenzar a leer la temperatura obtenida mediante el LM92 y presentarla en un LCD o procesarla de acuerdo a las necesidades del hardware que estamos desarrollando. Este trabajo es tan sencillo como el anterior. La estructura es la misma y pasamos a leer el registro donde se almacena el valor obtenido mediante la instrucción HBUSIN. En el ejemplo mostrado abajo, “LEO” es la dirección (Address Byte) con el último bit habilitando el proceso de lectura.

Así de sencillo es el protocolo I2C para leer el LM92

Veamos ahora como se organizan los dos bytes de datos y cómo haremos para extraer la información de temperatura o, en el proceso inverso, como hacemos para escribir un valor útil en cualquiera de los registros. Los datos vienen organizados en una palabra de dos bytes que vistos en forma lineal se presentan de la siguiente manera:

La palabra de dos Bytes que contienen la información intercambiada entre el 18F25K20 y el LM92

En cualquiera de los registros encontramos que el bit de la posición D15 nos indicará el signo de la temperatura observada. Es decir, si es sobre cero D15 tendrá un valor bajo y si es bajo cero el LM92 nos devolverá en esa posición un uno lógico. Por otro lado, las posiciones D0, D1 y D2 nos devuelven el estado (Status) de las alarmas al momento de la lectura mientras que no intervienen al momento de la escritura de cualquiera de los demás registros. Luego de utilizar y descartar estos tres bits iniciales observamos que los bits útiles nos quedan comprendidos entre D3 (Bit 0) y D14 (Bit 11) y de esta manera queda alojada en 12 Bits la información de temperatura. Dentro de esta estructura, los cuatro bits de menos peso (LSB) se procesan de manera separada obteniendo de ellos los decimales de la medición. Recordemos que el LM92 ofrece “pasos” de 0,0625°C y por este motivo 15 pasos (4 bits) significarán 0,9375°C. Esto te permite apreciar la calidad de medición que nos ofrece el LM92. Finalmente, sobreviven las posiciones D7-D14 las que se tratan como un byte convencional y su valor expresado en decimal será el valor entero de la temperatura. Combinando la parte decimal con la entera llegamos al resultado final que mostramos en el LCD.

Manejo de los datos obtenidos para leer un valor útili en el LCD

Los términos TEMP, T6, T3, T1, T4 y T5 son las variables usadas para cargar los valores que el programa necesita y se declaran al inicio del mismo. Observando la imagen encontramos que existe un condicional IF que se encarga de determinar el valor que toma D15 (el bit del signo). Por su peso, D15 equivale a un decimal igual a 256, por lo tanto, si la variable supera el valor 255 será indicación de que el LM92 está registrando temperaturas bajo cero. Recuerda: si D15 adopta un valor igual a uno, la temperatura es bajo cero. A partir de esto, la presentación se transforma a lo que se conoce como “complemento a dos”. Al ver la hoja de datos puede parecer que todo el sistema enloquece y hay que reprogramar todo de diferente manera, sin embargo, la forma de manejar un “complemento a dos” es invirtiendo el valor obtenido y sumándole una unidad. Por ejemplo, si el byte 11100111 está expresado en “complemento a dos”, debemos invertirlo (00011000) y sumarle una unidad obteniendo el número 00011001. En lenguaje BASIC esto es muy sencillo de realizar con una única instrucción (T6 = ~T6 + 1). De este modo entonces, el LM92 nos ofrece los valores de temperatura bajo cero.

La temperatura "bajo cero" se ofrece en formato "complemento a dos"

Esta es la manera en que podemos escribir y leer los registros en el LM92. Sólo debemos comprender y aprovechar el uso de las herramientas que nos ofrece el lenguaje de programación utilizado y de este modo, sacaremos el mejor provecho del sistema. La última aclaración que vale indicar, y que es importante a la hora de realizar un proyecto con este dispositivo es saber que, mientras el microcontrolador “lee” el registro de temperatura, los indicadores de alarmas dejan de funcionar. Por más rápido que sea el bus I2C, o el lenguaje compilador utilizado, existe un vacío de indicación durante la adquisición del dato de temperatura. Para evidenciar este fenómeno, en nuestro programa de ejemplo, asignamos al LED amarillo una duración de encendido/apagado para que, contrastándola con la duración de la interrupción en la indicación de la/las alarma/s del LM92, se note la diferencia. Es decir, se observe este proceso de manera clara y se interprete mejor el funcionamiento. De este modo llegamos al fin al video donde te mostramos al LM92 en acción activando todas las alarmas y haciendo gala de sus características. No te lo pierdas:

Existen muchos circuitos integrados en el mercado que ofrecen la posibilidad de brindarnos su funcionamiento como medidores de temperatura, pero muy pocos ofrecen tantas funciones en un mismo encapsulado como lo hace el LM92. Un dispositivo muy útil para infinitas aplicaciones donde la precisión, exactitud y el control estricto de la temperatura deben ser los factores fundamentales del diseño. Te esperamos en el Foro de Electrónica de NeoTeo para que nos cuentes tus experiencias con el LM92. ¡Visítanos!

Enlaces

Hoja de datos: LM92

Código fuente de ejemplo: LM92

Fuente:
http://www.neoteo.com/-21786-lm92-termometro-i2c-de-12bits.neo