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:


viernes, 19 de abril de 2013

Llamada a procedimientos remotos(RPC) usando rpcgen.

En ocasiones(casi siempre) resulta que los estudiantes recién llegados de docencia, tienen el “miedo escénico” de realizar una aplicación de determinado tipo cuando lo que cuenta no es la evaluación sino que funcione la aplicación propiamente dicho. Uno de los ejemplos más comunes son las aplicaciones que se comunican por la red. Este ejemplo muestra cómo utilizar rpcgen para autogenerar casi por completo un programa cliente y uno servidor.
Sobre rpc se pudiese decir mucho, de manera general es usado para realizar cómputo distribuido, por ejemplo un servidor capaz de resolver complejas ecuaciones matemáticas “caras” en procesamiento; a este se pasarían los datos en una llamada procedimiento remoto, y se tendría como resultado el/los dato/s para cualquiera de los clientes que generalmente tienen procesadores más modestos.
Sobre cliente-servidor mencionar que el servidor “siempre” debe estar listo para atender a los clientes, que este tiene un comportamiento pasivo (o sea, son los clientes quienes comienzan el diálogo).
El uso de rpcgen se basa en editar una archivo extensión “.x” (sintaxis RPC Language casi ANSI C) para la definición del programa, así como de sus funciones principales:
program  nombre {
version nombre_versión {
tipo nombre (parametro) = id;//funCion
} = ID;
} = identificador;
Para esta estructura tomamos a nombre como el nombre que tendrá el programa, identificador, la versión del mismo(un cliente puede especificar que versión del programa servidor usar en caso de contar con varias), en el ámbito nombre_versión van las  funciones proveídas, funCion sería una o varias funciones que serían reconocidas mediante id, reciben un solo parámetro, en caso  que se necesite más de uno se pasan mediante una estructura. Aquí tomemos un ejemplo para realizar multiplicaciones en el servidor bajo la demanda de los clientes, guardamos el siguiente código en un archivo MULT.x:
struct factores
{
int factor_a;
int factor_b;
};
program multiplicador {
version v_multiplicador {
int multiply (factores) = 01;
} = 01;
} = 0×01;
Una vez que ejecutemos rpcgen -a MULT.x para dejar el programa funcional se necesitan realizar algunos cambios menores, ya que con la opción -a le hemos dicho a rpcgen que genere todos los archivos, incluido el código de ejemplo para un cliente y un servidor. Editamos el archivo MULT_server.c y donde dice:
/*
* insert server code here :-D
*/
ponemos el códgo que queremos sea ejecutado en la llamada a este procedimiento, para este caso:
printf (“Received %d and %d\n”, argp->factor_a, argp->factor_b);
result = argp->factor_a * argp->factor_b;
printf (“Sent %d\n”, result);
En el cliente modificamos el código en aras de mostrar por la salida estándar el resultado de la operación. Vamos al archivo MULT_client.c y en la función void
multiplicador_01(char *host) hacemos los siguientes cambios:
//remplazas factores  multiply_01_arg;
por:
factores  multiply_01_arg = {100, 25};
printf (“Sent %d and %d\n”, multiply_01_arg.factor_a,
multiply_01_arg.factor_b);
if (result_1 == (int *) NULL) {
clnt_perror (clnt, “call failed”);
}//se remplaza por
if (result_1 == (int *) NULL) {
clnt_perror (clnt, “call failed”);
}else {
printf (“Received %d\n”, *result_1);
}
Luego compilamos con make -f Makefile.MULT, el servidor lo corremos como root, y al cliente le pasamos por parámetro la dirección IP donde se encuentra el servidor. Cabe señalar que para leerse el código del programa que aquí se muestra tan “trivial” requiere un poco de estudio extra, pero bueno ;-) ya sabes por dónde comenzar…
NOTA:
Con la opción -f nombre le decimos a make que lo estamos forzando a seguir las reglas de compilación en un archivo no llamado Makefile.