viernes, 6 de septiembre de 2013

Domótica.

Fig 1.
 “La tecnología aplicada al hogar”(Fig 1), conocida como Domótica, integra  automatización, informática y nuevas tecnologías de comunicación; todas ellas dirigidas a mejorar la comodidad, la seguridad y, en definitiva, el bienestar dentro de los hogares. Esta contribuye principalmente  en aspectos cotidianos como: iluminación, climatización, seguridad, comunicación, etc.




Tal vez por error, es usual que algunas personas usen indistintamente otros términos en lugar de Domótica, ejemplos de esto son; “Hogar Inteligente” (término que se empleaba antes de surgir la Domótica, el término “Hogar Inteligente” suele ser más interpretado por las personas como la soluciones futuristas que como las novedades tecnológicas del momento), “Hogar Digital” (ya que es, gracias a la digitalización, que son posibles los nuevos equipos y/o servicios, aunque este está más estrechamente relacionado con las telecomunicaciones), “Inmótica”(que hace referencia a la coordinación y gestión de las instalaciones con que se equipan las edificaciones, así  como a su capacidad de comunicación, regulación y control, aunque “Inmótica” es de uso común, todavía no ha sido recogido por el diccionario de la Real Academia. Mientras la palabra Domótica se aplica al hogar, por Inmótica se entiende la incorporación de sistemas de gestión técnica automatizada a las instalaciones del sector terciario como son plantas industriales, hoteles, hospitales, aeropuertos, edificios de oficinas, parques tecnológicos, grandes superficies, universidades, instalaciones comunitarias en edificios de viviendas, etc. En realidad, los sistemas y aplicaciones Inmóticas son muy similares a los de la Domótica y, por ello, a menudo se emplea el concepto de sistemas Domóticos referidos también a este sector). La palabra Domótica tiene varios significados, según el diccionario de la Real Academia es “el conjunto de sistemas que automatizan las diferentes instalaciones de una vivienda”, pero se debe tener en cuenta que esto está en continuo cambio y bajo constantes discuciones y aunque todos estos son términos diferentes se encuentran estrechamente relacionados. Además, la Domótica no es aplicada solo a los hogares, también puede aplicarse a una oficina por citar un ejemplo.
Ya presentadas las diferencias entre cada uno de cada uno de estos términos tomaremos todo esto como una sola idea y lo trataremos más apmpliamente usando solo la palabra Domótica. Hoy no concebimos una vivienda que no tenga a gua corriente o electricidad, así mismo tal vez algún “día” podriamos no concebir una vivienda que no esté aunque sea minimamente “Domotizada”, el principal problema que ha afrontado la Domótica es que muy pocas personas han estado de acuerdo con incurrir en los costes adicionales pero el abaratamiento de las tecnologias ha hecho que ese “día” se parezca cada vez más al de hoy. En los últimos años el desarrollo vertiginoso de la ciencia y tecnología a traido con sigo un impacto directo en toda nuestra vida cotidiana, ya sea donde recidimos, donde trabajamos, o donde nos recreamos, de una forma u otra donde quiera que estés coincidirás en esto, te encontrarás con que la Domótica es algo de futuro pero en algún grado ya está presente en nuetra vida diaria. La aplicacion de la Domótica depende de las necesidades particulares de cada usuario final, pero de manera general el interés por la Domótica es una realidad palpable en la sociedad. Según los expertos, la infraestructura básica para domotizar una vivienda, sólo encarece el precio entre un 1-2 % de media; algo ínfimo si se pondera lo mucho que mejora el atractivo de cara al público.
Pero… ¿Qué significa vivir en un hogar digital y conectado?:
Algunas de las ventajas de vivir en un hogar digital y conectado, se ven en la siguiente imagen (Fig 2).

Fig 2. Aplicaciones de la Domótica.
Fig 3. Terminal de monitoreo/control
La terminal central(en caso de los sistemas con arquitectura centralizada según su tipología ver Fig 5 y el libro que aparece al final en “NOTA:” para más detalles) de supervición/control puede estar fija en un lugar de la casa(Fig 3-5), en una PC del propietario de la casa, en un servidor remoto accesible via internet, en un teléfono movil, en una agencia privada de seguridad(Fig 4), etc.

Fig 4. Agencia privada de seguridad.
Fig . Sistema de supervivió/control centralizado.
Como es de suponer en todo este sistema intervienen una serie de sensores(de radioondas, vibraciones, temperatura, presión, etc), actuadores (acciones de control para cierre de válvulas, desconección de equipos, activación de alarmas, etc), y equipos de uso domésticos que necesitan comunicarse entre ellos y con el exterior. La siquiente imagen muestra una red de Domótica cuyo componente principal (para esta topología) es la pasarela residencial que es la que media en la comunicación entre todos los equipos y el exterior.
Fig 6. HAN (Home Area Network).


Bibliografía:
Domótica. Edificios inteligentes. Ediciones Copyright. Madrid.(2004)
Domótica y hogar digital. Editorial Thomson-Paraninfo. Madrid.(2004)
Domótica e inmótica. Edificios inteligentes. Editorial Ra-Ma. Madrid.(2005)

NOTA:

Este post se basa (intenta ser un resumen de los conceptos más básicos) en una exelente publicación lanzada en España (La Domótica como Solución de Futuro. Guía descargable en formato pdf desde la sección de publicaciones de la página web), guía, en cuya elaboración han intervenido profesionales con una amplia experiencia en este campo, se abordan distintos temas, de una manera sencilla pero a la vez rigurosa, en algunos casos con ejemplos prácticos de cómo se puede llevar a la práctica las soluciones que se van comentando. Además la bibliografía mencionada aparce en esta y ha sido consultada ligeramente.

sábado, 31 de agosto de 2013

El mito de la desconexión

En los últimos años, el florecimiento de las comunicaciones ha creado una cultura “on-line” en la que miles de personas trabajan, viven, se comunican y relacionan entre sí. Redes sociales como Facebook borran la barrera de las fronteras permitiendo que seres humanos de distintas latitudes se conozcan, se enamoren, etc.
Junto a esto a surgido la llamada “cultura de la desconexión”.  Personas que abogan por lo “ficticio” de ese mundo “online” y se niegan a reconocer como “verdadero” todo lo que ocurre en el, catalogando de adictos , enfermos y enajenados a todos los que digan lo contrario.
Pero, ¿quien tiene la razón? ¿Acaso existe la llamada realidad 2.0?.  Cada facción, grupo o person tiene su conjunto de opiniones al respecto. Aquí van las mías.

Qué es reál y que no lo es.

La alegoría de la caverna (de el filósofo griego Platón)  nos cuenta de  un espacio cavernoso que alberga un grupo prisioneros, sujetados desde su nacimiento por el cuello y las piernas mediante cadenas de forma que únicamente pueden mirar hacia la pared del fondo de la caverna sin poder nunca girar la cabeza. Detrás de ellos, se encuentra un muro con un pasillo y, seguidamente y por orden de cercanía respecto de los hombres, una hoguera y la entrada de la cueva que da al exterior. Por el pasillo del muro circulan hombres portando todo tipo de objetos cuyas sombras, gracias a  la hoguera, se proyectan en la pared que los prisioneros pueden ver.
Estos hombres encadenados consideran como reales las sombras de los objetos. Debido a las características de su prisión toman unicamente por ciertas las proyecciones de las personas que cruzan sobre el muro. Esto constituye su realidad.
Se plantea entonces la hipótesis. ¿Qué pasaría si uno de estos prisioneros fuese liberado y obligado a volverse hacia la hoguera,  contemplando, de este modo, una nueva realidad?  Una realidad más ricay completa donde ya no solo contempla las sombras, sino su origen y comprende que todo lo que conocía estaba limitado por su percepción. Pero no se detienen ahí, de nuevo el ex-prisionero es obligado a salir de su entorno habitual y marchar  fuera de la caverna apreciando una nueva realidad exterior (hombres, montañas, lagos, astros, etc. identificados con el mundo inteligible), conociendo nuevas formas, aumentando su concepto de lo real.
La alegoría acaba cuando el prisionero regresa de nuevo a la caverna para “liberar” a sus antiguos compañeros de cadenas y estos se burlan de él, le dicen que  sus ojos se han estropeado, que ha perdido la razón. Al tratar de liberarlos, sus compañeros se resisten y eventualmente terminan por asesinarlo y quedarse en la caverna, rechazando la nueva realidad.
Otros escritores y filósofos han planteado situaciones parecidas. Asimov en su cuento “Las Estrellas”, crea un planeta que orbita alrededor de un sistema binario  y que tiene la particularidad que solo oscurece cada miles de años. Las sociedades que florecen en el período “diurno” de la historia del planeta, toman a “Las Estrellas” como un mito y al llegar el período nocturno enloquecen al no poder aceptar su existencia y destrullen la sociedad, dejando para de nuevo escritos acerca de las terribles luces que aparecen en el cielo para acabar con la humanidad.
Entonces, ¿quien decide que es lo real y que no?. ¿Es la realidad lo que podemos experimentar con todos nuestros sentidos?. ¿Y las personas con discapacidad sensorial, no experimentan lo real? ¿Y los que sufren de algún tipo de alteración de la percepción como sinestesia, daltonismo, etc?

..todo es mejor si es cara a cara.

Desde aquellos tiempos en que el hombre de Cromagnon, decidió que eso pelirrojo que caminaba frente a su guarida (un Neanderthal) no le caía bien y se dió cuenta de que uno a uno no podía machacarle la cabeza así que reunió a la tribu y entre gestos y alaridos logro que le prestaran ayuda (aquí también empezaron las pandillas pero eso es para otro post), los seres humanos hemos establecido la comunicación personal como paradigma. Pero: ¿eso significa que es mejor que el resto? ¿Qué hay de las maravillosas cartas que se han escrito entre sí cientos de personajes históricos? ¿De la capacidad que le brindó hace miles de años la palabra escrita a un señor desconocido en Asia Menor para hacerme llegar a través del tiempo y el espacio las historias del rey Nabucodonosor o la epopeya de Gilgamesh?. En algún momento de la historia los seres humanos sobrepasamos la necesidad de comunicarnos y comenzamos a tener la de informarnos y poder expresar nuestra opinión más allá de nuestro círculo cercano de conocidos (también conocido como tribu) por lo que primero caminamos hasta el foro en Atenas, después escribimos extensas cartas y cuando Guttemberg invento la imprenta empezamos a hacer periódicos… así hasta la televisión y ahora internet (gracias a lo cual están ustedes se están enajenando en este blog).
¿Alcanza entonces la palabra hablada para comunicar todo lo que sentimos?. ¿Una sesión privada de IRC cuenta como conversación personal? ¿Un videochat cuenta?

Quiero hablarte en este momento

El telégrafo, el teléfono, Internet, la telefonía móvil, los SMS. La comunicación instantánea ha sido perseguida de muchas modos y a llegado incluso a sustituir a las formas anteriores, ha ido evolucionando de letras impersonales a su propio l3nguaje k h4ce + fcil a akllos k lo practican entenderse, unirse, convertirse en una cultura universal guiada solo por la necesidad de conversar. Si el lenguaje es base para la cultura y la sociedad, ¿puede alguien decir que no estamos experimentando el nacimiento de un nuevo tipo de sociedad?

Terminando

Queda mucho por decir, aún no he hablado de la realidad aumentada, de Youtube, de la Wikipedia, de la cultura de IRC, pero creo que ya he cumplido el propósito de plantear preguntas donde otros ven solo respuestas. ¿Estamos frente a la muerte de la palabra hablada? ¿Es la desconexión una necesidad o una aberración? ¿Es enajenación o evolución lo que sufrimos?. Respóndanse ustedes mismos.
Saludos.



Tomado de: CodeNinja (un blog en una subred privada) .

sábado, 15 de junio de 2013

firmware-stm3210fx3 "SEE" Un proyecto plantilla en autotools para STM32EVAL10X

Con esta plantilla tienes la oportunidad de trabajar con la biblioteca de periféricos STM32F10x_StdPeriph_Lib y el kernel FreeRTOS.

 git clone https://github.com/denisacostaq/firmware-stm3210fx3.git

firmware-stm3210fx2 "SEE" Un proyecto plantilla en autotools para STM32EVAL10X

Con esta plantilla tienes la oportunidad de trabajar con la biblioteca de periféricos STM32F10x_StdPeriph_Lib.

git clone https://github.com/denisacostaq/firmware-stm3210fx2.git

firmware-stm3210fx1 "SEE" Un proyecto plantilla en autotools para STM32EVAL10X

Esta plantilla es la más básica de todas, solo te garantizo que compila pero el resto deberás agregarlo tú.

git clone https://github.com/denisacostaq/firmware-stm3210fx1.git

Un proyecto plantilla en autotools para STM32EVAL10X.

Bueno, bueno, ya con el título tienen “el gran trabajo” en este post, simplemente una plantilla que me cansé de escribir por decenas de veces que lo había hecho. El tema consiste en que por acá usamos las normas de gnu para el desarrollo de aplicaciones y esto incluye la configuración del proyecto por su puesto(see GNU Coding Standards). Como IDE puedes usar el de tu preferencia (el que tenga soporte para autotools o sea casi todos), como compilador usas igual el que quieras lo que tendrías que realizar cambios menores en la configuración del proyecto(AC_PROG_CC([arm-none-eabi-gcc]) ;) ). Bueno si este post forma parte de tus intereses para el trabajo que estás realizando te dejo algunos detalles de como usar las plantillas; si no manejas la herramientas autotools probablemente no te sea útil.
Primero que todo veamos como compilar y “flashar” en memoria estas plantillas que no hacen nada pero bueno por lo menos se ejecutan jeje.
  1. tar -xvzf firmware-stm3210fx#.tar.gz
  2. cd firmware-stm3210fx#-0.0.0
  3. export PATH=$PATH:/path/a/tu/toolchain
  4. ./configure –host=arm-none-eabi
  5. make
  6. make flash_firmware
Fácil verdad!,  ahora veamos algunos truquillos incluidos que te pueden facilitar la vida…
  1. doc: make doxygen-doc Te construye la documentación basada en el código si escribistes para doxygen además.
  2. “browse”: ./show_sources.sh Cada vez que en tu proyecto incluyas un nuevo archivo deberás hacerlo también en la configuración de autotool, si es un archivo de código propio lo harías en las variables “SOURCE” y “HEADER” respectivamente además por organización sería bueno que lo mantuvieras bajo “$(top_builddir)/src/Source” solo por organización, en realidad puedes ponerlo donde quieras, el otro caso sería el que incluyas código freeRTOS, lwIP, STM32Peripheral, o el que sea que incluyas con el scrip mencionado puedes tener una vista inmediata de donde se encuentra exactamente para agregarlo a su correspondiente variable (FREERTOS_SOURCE, ST_LIB_SOURCE, …), y tener en cuenta que si el compilador no está buscando cabeceras en el directorio recién incluido, incluirlo! en la variable AM_CPPFLAGS.
  3. Flashar: make flash_firmware Flashea la memoria usando una interfaz JTAG y openocd.
  4. Tablas de símbolos: cd src ; make log ; cd ../ , en src estarán los ficheros (*.txt) con tablas de símbolo, espacio de memoria, … que tal vez en algún momento necesites mirar.
  5. Detalles de compilación: make details Esto te muestra la compilación que estás realizando, para este caso específico la salida sería; Building from:
    build_cpu = i686, build_os = linux-gnu, build_vendor = pc
    To:
    host_cpu = arm, host_os = eabi, host_vendor = none
  6. Por último ten en cuenta que de una manera u otra terminarás modificando las reglas de compilación por lo que he copiado en doc/file.txt algunos de los parámetros utilizados, por ejemplo el proyecto está configurado en modo debug (-g), cuando hagas liberación esta bandera debería ser deshabilitada. Más información al respecto la buscas en la especificación de tu compilador.
Espero te sea de ayuda y si bien no sirve para cualquier proyecto, tengas una buena idea de como usar autotools :)

Ver además:
firmware-stm3210fx1
firmware-stm3210fx2
firmware-stm3210fx3

martes, 4 de junio de 2013

Invitación - Defensa de tesis de grado sobre Diseño de una Computadora de Vuelo para UAVs - Martes 11/6 19hs

Invitación a la defensa de la tesis de grado del Sr. Alan Kharsansky, sobre "Diseño e implementación de un sistema embebido de control de actitud para aeronaves no tripuladas", que tendrá lugar el día martes 11/6 a las 19hs en el aula 211-A del segundo piso de la Facultad de Ingeniería de la UBA, Av. Paseo Colón 850, Buenos Aires, Argentina.
El trabajo incluye el diseño, implementación y validación de una computadora de vuelo para un cuadricóptero basada en el LPC1769 (Cortex-M3) y el FreeRTOS, y todo el proceso de modelado, identificación y diseño a partir del cual mediante un conjunto de controladores PID elementales se logra el control en vuelo libre de la aeronave. Para ver un vídeo del Quad en vuelo y obtener más información, así como para acceder a una memoria de la tesis, visitar la página web:

lunes, 27 de mayo de 2013

Compilar linux-2.6.37 para Intel + parche

Tuve la necesidad de usar el “viejo” linux 2.6 y además compilándomelo para reducir su tamaño al mínimo, he pasado varias horas buscando en la web por algunos errores de compilación que me daba. Con lo que ha “llovido” desde entonces  probablemente esto ya esté parcheado para esta versión y resuelto nativamente para las posteriores (esto si me consta) así que simplemente considero incrementar tus probabilidades de dar con la solución que yo no pude econtrar. El primer error se refiere a una inconsistencia en la declaración de dos funciones:
extern long syscall_trace_enter(struct pt_regs *);
extern void syscall_trace_leave(struct pt_regs *);
en el archivo “./linux-2.6.37/arch/x86/include/asm/ptrace.h“. Se trata de un atributo especificado a las funciones en la implementación(“./linux-2.6.37/arch/x86/kernel/ptrace.c“) de la función y no así en la declaración. Esto se expresaba con “asmregparm” como una macro (” #define asmregparm __attribute__((regparm(3))”) del archivo (“./linux-2.6.37/arch/x86/include/asm/linkage.h“) la sustitución llevada a cabo por el preprocesador especificaba a la función el atributo __attribute__((regparm(x))) como antes mencionaba.
__attribute__((regparm(number))):
Este puede ser utilizado solo para arquitectura intel(i386 y x86-64) y se refiere a que el paso de parámetros se hará de manera directa mediante registros( EAX, EDX,y ECX) si estos son de tipo entero y no por el stack en memoria como suele ser, son pasados los que numeran entre el primero y “number”, los que siguen después de la cantidad “number” serán pasados por el stack de forma común y ello se aplica también para las funciones que reciben un número de argumentos variable. Más documentación al respecto la puedes obtener en la especificación de tu compilador, yo me he referido a gcc que es el que uso y según tengo entendido agrega esta característica desde su versión 3.4.0 para linux (i686-pc-linux-gnu). Además agregar que cuando he usado atributos para las funciones lo he puesto en la declaración de esta, no en la implementación y al final, no al inicio, no me queda claro que esto sea relevante pero lo he visto en algún libro sobre herramientas GNU que ahora no recuerdo el título.
El segundo error se debe a una variable duplicada (expeculando, la impresión que me dio fue que escribieron el cuerpo del struct en dos momentos diferentes  dejando pasar por alto este pequeño detalle) en el strcut igbvf_buffer del archivo ./linux-2.6.37/drivers/net/igbvf/igbvf.h En la documentación de gcc podemos ver en un topic(“Unnamed struct/union fields within structs/unions”) dedicado a estructuras/uniones anónimas que según lo establecido por la norma ISO C1X y por compatibilidad con otros compiladores se permite definir estructuras y uniones que contienen como alguno/os de su/us campo/os estructuras y/o uniones sin nombre. Pero nunca se deberán crear estas estructuras de manera que cause definición de campos ambiguos como en este caso(y el caso del error en el código linux):
struct {
int a;
struct {
int a;
};
} foo;
Sin más te dejo el parche );. Tal vez te sea de ayuda un post para cómo aplicarlo.
git clone https://github.com/denisacostaq/intel_asmregparm-page_anonymous_struct-2.6.37.patch.git

domingo, 26 de mayo de 2013

Crear/aplicar un parche usando Git

Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando estas tienen un gran número de archivos de código fuente
Antes de comenzar con los pasos señalar que si el parche que deseas hacer es para corregir un bug o agregar una nueva funcionalidad deberías hacer esto en una nueva rama dedicada solo a ello, en base a esto el parche que contruiremos en este post se creará a partir de las diferencias entre dos ramas aunque también se puede crear entre versiones, fechas, marcas, …
  1. Crear un directorio donde estará nuestro “gran proyecto” (mkdir test-git).
  2. Entrar e inicializar un repositorio vacio. (cd test-git/ ; git init)
  3. Crear algún archivo y editarlo(nano main.c):
    #include <stdio.h>
    int main (int argv, char *argvv[])
    {
         printf ("hello git\n");
         return 0;
    }
  4. Agregar a git el directorio actual(que en el se encuentra el archivo de interés) y hacer nuestro primer commit lo que además abilitará la rama master.(git add . ; git commit -m “the first commit”)
  5. Ya podemos listar las ramas y ver que se encuentra activa la master(git branch).
  6. Creamos una nueva rama “en la que escribiremos los cambio al proyecto”(git branch crpatch).
  7. Nos movemos a la nueva rama y verificamos que sea la activa (git checkout crpatch ; git branch).
  8. Efectuamos los cambio al proyecto:       
  9. Crear algún archivo y editarlo(nano main.c):
    #include <stdio.h>
    int main (int argv, char *argvv[])
    {
         printf ("
    hello git, this program become from a patch\n");
         return 0;
    }
  10. Agregar los cambios (git add . ; git commit -m “commit for the patch”).
  11. Ya podemos ir chequeando las diferencias que ha tomado el proyecto con repecto a la rama master (git diff master).
  12. Por útimo crear el parche… (git format-patch master --stdout > crpatch.patch).
Ya tenemos el parche, ahora veremos como aplicarlo:
  1. Nos movemos a la rama master y eliminamos la rama “crpatch” con lo que perderiamos todos los cambios efectuados si no fuese porque contamos con el parche(git checkout master ; git branch -D crpatch).
  2. Revisamos los cambios que presumpondría el aplicar el parche(git apply --stat crpatch.patch).
  3. Revisamos si el aplicar el parche nos pudiese taer algún error (git apply --check crpatch.patch). Si no obtienes nada en la salida es porque puedes aplicar el pache satisfactoriamente.
  4. Por último aplicamos el parche revisando antes y después el contenido para comprobar y entender el trabajo(cat main.c ; git apply crpatch.patch ; cat main.c).
Listo!!!, espero que estés preparado lo mismo para “escribir” un parche y enviarlo a los desarrolladores con los cuales quieras colaborar que para parchear algún programa con un parche que tengas para ello.

martes, 23 de abril de 2013

Integración de Proteus VSM(Virtual System Modeling) y el compilador C de Custom Computer Services Incorporated(CCS)

Resumen:
El programa “PROTEUS” de Lab Center Electronics es una herramienta para el diseño asistido por computador (CAD del inglés Computer-Aided Design ) que cuenta con tres módulos principales:
1- “Sistema de Enrutado de Esquemas Inteligente” (ISIS del inglés Intelligent Schematic Input System ) es el módulo de captura de esquemas.
2- “Sistema de Simulado Virtual” (VSM del inglés Virtual System Modelling) es el módulo de simulación, agregando a PROSPICE.
3- “Enrutamiento Avanzado Modelado” (ARES del inglés Advanced Routing Modelling) es el módulo para la realización de circuitos impresos.
Por otra parte se cuenta con el compilador C de CCS. Este post se centra en el empleo de ISIS que permite el diseño de planos electrónicos los cuales se pueden emular mediante el módulo VSM que está asociado directamente con ISIS. Para la definición del comportamiento de los componentes electrónicos se puede hacer uso del compilador C de CCS. Este post trata de la manera más “clara” posible los principales aspectos de uso, facilidades, así como una guía para elaborar un ejemplo funcional completo. Una vez comprendida la esencia del trabajo el/la lector/a se encontrará en condiciones de enfrentarse al estudio de los disímiles ejemplos con que cuentan las propias herramientas y de una vez realizar un proyecto propio más funcional que el que aquí se presenta.

Introducción
Con el desarrollo de la Electrónica Digital se crea la necesidad del diseño de sus componentes y además la definición de su comportamiento, lo cual se hace en la mayoría de los casos mediante el software (los componentes electrónicos que fueron creados con este fin y por ende cuentan con una memoria EPROM, EEPROM, AEPROM, o una flash programable de manera general). La experiencia de un desarrollador por pequeña que sea, conoce que al cometer un error, se resuelve borrando los últimos avances en el proyecto y rehaciéndolo de nuevo, implicando “solo” la perdida de horas de trabajo o para errores menores corrigiendo el problema en la medida de lo posible sin cambios mayores. Haciendo un análisis un poco estratificado, ¿qué sucedería si al escribir en un dispositivo de almacenamiento no se pudiese borrar la información? siendo cada vez mayor el espacio ocupado hasta agotar su capacidad, o mejor, asocie reinstalar una computadora, con deshacerse de ella y sustituirla por otra nueva recién instalada. Si bien parece algo un poco ridículo, en la actualidad algo similar pasa a menudo en el campo de la automática y la electrónica, por ejemplo en una mala conexión eléctrica si se produce un corto circuito probablemente tenga que contactar con su proveedor y repetirle el pedido por completo. En otro caso: un mal “cálculo” a la hora de elegir un micro-controlador y que no le baste la potencia de trabajo en su funcionamiento (probablemente tenga que adquirir uno más potente, desechando el anterior o guardándoselo para otro tipo de trabajo… contactar con el proveedor). Más específicamente, mi caso; actualmente trabajo en un proyecto el cual no cuenta con un cliente bien definido, o por lo menos no con uno que asuma las inversiones necesarias, siendo imprescindible la implementación de aplicaciones que se ejecuten en microcontroladores de gama baja y media; los diseñadores de hardware muchas veces plantean: …no hay lugar para el error, se debe tener información exacta de los componentes de hardware que se necesitan, así como de sus características técnicas detalladas ya que una mala elección implicaría tener que desechar toda una inversión en dispositivos electrónicos lo cual es inadmisible… Este post presupone brindar la “mejor” solución a problemas anteriormente planteados y otros.
ISIS.
El primer entorno presentado es ISIS, donde se muestran las principales opciones y menús, sin embargo se debe tener en cuenta que no todas las funcionalidades son accesibles desde aquí, en algunos casos la única opción es acceder desde la barra de herramientas con los correspondientes iconos. Sin embargo sí es cierto que se pueden usar varias vías para acceder a una misma funcionalidad ya sea con el teclado, el mouse usando menús, la barra de herramientas o clic derecho sobre el área de trabajo pero estos detalles son habilidades que se van adquiriendo con el uso de las propias herramientas.
 Figura 1: Vista del entorno de trabajo de ISIS.
 C CCS
El compilador utilizado es un cross-compiler(en español compilador cruzada) se le llama así ya que es uno de los compiladores en los que el target (dispositivo en que se ejecutara el archivo binario) no coincide con el host (sistema en el cual se encuentra trabajando y por tanto realizara la compilación), en este caso el “host” es la plataforma Windows XP Profesional Servicie Pack 3, con un procesador Intel(R) Core(TM)2 Duo CPU E4500 a 2.2 GHz y para este caso el target es el PIC (controlador de interfaz programable del inglés Programable Interface Controller)
PIC16F876. Este compilador genera varios ficheros de salida, pero en esencia los más importantes son el *.hex y *.cof, el primero es el fichero estándar para la programación del PIC y en segundo es un archivo binario pero que además incluye símbolos de depuración, este segundo fichero se cargara en el PIC emulado en ISIS, que tiene varias opciones avanzadas para el depurado de programas (lo cual no se trata en este post).
Figura 2: Vista del entorno de trabajo del compilador C de CCS.
Creación del circuito electrónico mediante ISIS.
Par simplificar el proceso ni siquiera se crea un “nuevo proyecto”, simplemente se comienza por insertar los componentes en el área de trabajo, se conectan, se ajustan los detalles y por último listo…, guardar. Los componentes que se utilizan son: un micro-controlador PIC de la familia 16 (PIC16F876), fuente (Vcc), 1 resistencia (R1), 1 diodo led azul (D1), 1 interruptor (SW1), conexión GND (Tierra). La puesta a punto del circuito debe ser como se muestra en la Figura 3, solo aclarar la frecuencia del reloj del PIC está a 4MHz.
Figura 3: Puesta a punto del circuito.
Generación de código para su posterior compilación.
El primer paso es la creación de un “nuevo proyecto”, seleccionamos el menú Project y dentro de este el submenú PIC Wizard, se selecciona el PIC (PIC16F876), una vez visualizado el cuadro de diálogo cambiaremos solo la frecuencia del reloj a 4MHz (la herramienta admite además muchas más opciones que pudiese seleccionar un usuario avanzado), se hará solo para enfatizar en que debe ser la misma que se ha puesto en el ISIS. A continuación se escribe el código de la Figura 4 que se explica enseguida.
Figura 4: Código fuente del programa.
La función bit_clear pone a cero el bit especificado como segundo parámetro en el puerto especificado en el primer parámetro, bit_set funciona igual solo que pone el bit a 1 lógico, por ejemplo: bit_set (TRISB, 1); pone a 1 el 1er bit del puerto TRISB que está definido como 0×86, en el PIC esto sería poner un positivo (corriente) en el pin 22. A la función bit_test se le especifica un puerto y un bit y te devuelve el estado en que se encuentra. Con el registro TRISx podemos especificar si un pin será de entrada o de salida, un 0 indica que es de salida y un 1 indica que es de entrada, el bus de datos se manipula directamente a través de PORTx. El puerto B tiene resistencias internas pull-up que son utilizadas para prevenir que se le pase una tensión mayor al micro de la que puede manejar, estas pueden ser habilitadas poniendo a cero el séptimo bit de del puerto 0×81 y esto solo se aplica a los pines que estén configurados como entrada. Con esta base y conocimientos básicos de C ya está listo/a para leer el código y predecir que hace: “un ciclo infinito con espera de 1 segundo en cada iteración, si el interruptor está abierto se mantiene el led apagado, si está cerrado se enciende y se apaga de manera alterna con 1Hz de frecuencia, siendo este el resultado observado:”
Nota: Por supuesto este brincoteo que parece un corazón es una muestra de lo “bueno” que puedo llegar a ser haciendo un gif gggggg. “La herramienta no se comporta así…”
 Figura 5: Emulado
NOTAS ADICIONALES
En el menú Help se podrá seleccionar la categoría Samples donde se encuentra una gran cantidad de ejemplos realizados los cuales pueden ser un buen material de estudio, de hecho es recomendable abrir cada uno de los ejemplos y correrlos, con esto quedará impactado, con ver la potencia con que cuenta este simulador, por ejemplo una de las características impactantes en este sentido es el hecho de que se puede emular un puerto serie RS232 y conectarlo “físicamente” al puerto serie de la estación de trabajo (si la PC cuenta con el RS-232), entonces se tendrá comunicación con el “exterior”(otras aplicaciones y dispositivos) vía RS-232. Además agregar que todo lo aquí expuesto se he hecho bajo Proteus 7, ya está disponible el 8, aquí se muestran algunas de las principales novedades que este trae tomadas textualmente de la página oficial:
Welcome to Proteus Design Suite Version 8
Proteus 8 is the result of over three years development with a consistent focus on product integration. It includes:
• A new application framework lets you view modules of Proteus as tabs in a single window or, via drag and drop, as separate windows for a side-by-side view
• A new common parts database enables sharing of information between schematic and PCB so that changes to data are instantly reflected across the software.
• A new live netlist means changes to connectivity in the schematic can be instantly reflected in the PCB, the Bill of Materials and the Design Explorer.
• The new integrated VSMStudio IDE binds your firmware project to your schematic design and Active Popups bring the schematic into your VSMStudio debug session.

Recursos adicionales: