Trabajando con microcontroladores de Microchip en GNU/Linux y Windows

Microcontroladores PIC de Microchip

Debido a su precio y disponibilidad, los microcontroladores PIC de Microchip son muy populares. Con estos microcontroladores es posible atender todas las aplicaciones de electrónica para consumo imaginables, desde equipos para al automotor, automatizaciones industriales, juguetes, instrumentos para laboratorio y hasta equipos usados en medicina.

Herramientas multiplataforma para la programación de PICs

Para programar un PIC necesitamos de 2 herramientas de software y una herramienta de hardware:

• Un lenguaje ensamblador, que convertirá nuestro código fuente de ensamblador a código máquina de PIC. Además del lenguaje ensamblador, existen lenguajes de alto nivel basados en C, Basic y Pascal que permiten reducir el tiempo de desarrollo de software para PICs.
• Un software programador, o software para transferir el programa en código máquina desde la PC hasta el PIC
• Un programador de PIC. Este es el hardware encargado de vincular la PC con el PIC al momento de transferir el programa desde la PC al PIC. Algunos modelos de programadores permiten monitorear el estado del PIC en cada instrucción.

Lenguajes ensambladores

El mejor lenguaje ensamblador para PIC, desde el punto de vista técnico y por su licencia de uso, es el ensamblador gpasm, incluído en la suite GPUTILS. Esta suite de software contiene todo lo necesario para escribir software en lenguaje ensamblador. Funciona en Unix (incluído GNU/Linux), Mac OS X y Windows.

Lenguajes de alto nivel

Un lenguaje de alto nivel muy bueno, ya que permite extender las funcionalidades del lenguaje a nuevos modelos de PIC, es el compilador Jal v2. Entre otras cosas, este lenguaje permite realizar operaciones aritméticas de 16 bits, algo engorroso de lograr en lenguaje ensamblador. Está basado en Pascal, pero en su estructura pueden reconocerse elementos de C y de Basic. Cuenta con versiones para GNU/Linux (x86) y Windows.

Software programador

Por su licencia y su disponibilidad en GNU/Linux y Windows, el mejor software para programación es el pp06. Funciona con la mayoría de los circuitos programadores.

Hardware de programación, circuito programador, o simplemente programador de PIC

El circuito más común es el de David Tait. Debido a su simpleza, y a que es posible adaptar el programador a los nuevos modelos de PIC, en internet se encuentran muchas variantes de este programador. Recomiendo esta versión.

Simuladores de PIC

Si bien Microchip provee de una herramienta gratuita para la simulación de PICs, el MPLAB, este no funciona en GNU/Linux. Por esto, el mejor simulador de PICs multiplataforma es el gpsim.

Otros recursos

Para explorar otras herramientas de software y hardware, visitar GNUPIC.

Particiones swap en sistemas virtualizados

El tamaño de la partición "swap"

Una de las preguntas más comunes en los foros sobre GNU/linux es ¿qué tamaño tiene que tener la partición swap?. No hay una respuesta clara a esa pregunta, porque el tamaño de la partición swap depende exclusivamente del uso que se le dé a la computadora.

Como regla general, para una computadora que se vá a usar en un oficina, 512Mb de RAM real y una partición swap de 1Gb cubren todas las necesidades corrientes. Si se tiene 1Gb de RAM, 512 de swap harán el trabajo. Si se tiene más de 1Gb de RAM es poco probable que se utilice el área swap.

Programas que realizan cálculos usarán más RAM según el volúmen de datos y cálculos que se realicen. En este caso, conviene consultar exhaustivamente los manuales del programa para estimar la cantidad de RAM a usar, ya que sí es posible estimar previamente el volúmen de datos involucrados en el proceso.

Cada vez es más común encontrar ambientes en donde la mayoría de los sistemas operativos que componen la infraestructura informática no corren sobre hardware real, sino sobre hardware virtualizado. Esto complica las decisiones acerca del tamaño de las particiones swap.

En sistemas virtualizados, tenemos que el sistema HOST (aquél que alberga el software de virtualización) posee una RAM real y un área de intercambio. Los sistemas operativos GUEST (aquellos que están siendo virtualizados en el sistema HOST) cuentan con una RAM "real" (virtualizada por el HOST) y una partición swap (también virtualizada por el HOST).


El tamaño de la partición swap en sistemas virtualizados


Para hechar luz sobre criterios de decisión acerca del tamaño del área de intercambio (swap) de los sistemas virtualizados, realicé el siguiente experimento:

Sistema HOST:
Debian GNU/linux 4.0 i386, sobre P3 733Mhz, 390Mb de RAM, 1Gb swap

Sistema GUEST:
Debian GNU/linux 4.0 i386, 640Mb de RAM, 96Mb swap

Software de virtualización: VirtualBox 2.0.2

Como se vé, el sistema GUEST tiene asignada más RAM real de la que el sistema HOST posee. Esto provocó que el sistema HOST utilice totalmente la memoria real y parte de la memoria de intercambio.

Hasta aquí la respuesta del sistema no trae sorpresas. Lo que sí resultó inesperado (al menos para mí) es que una vez que apagué el sistema GUEST, y con el servidor de virtualización aún corriendo, no se liberó la memoria que se había solicitado al sistema HOST. Pensándolo bien, esto no es tan inesperado. Tiene sentido, ya que los sistemas GUEST pueden volver a encenderse en cualquier momento de manera no determinista (mediante scripts activados remotamente, por ejemplo).

Si hubiera empezado a correr otras aplicaciones en el sistema HOST sin apagar el servidor de virtualización, el rendimiento de la máquina real hubiera sufrido de esta falta de memoria real, ya que los procesos de intercambio se hubieran incrementado en frecuencia y en tamaño de memoria intercambiada. Otros sistemas virtualizados en la misma máquina hubieran sufrido severamente esta falta de memoria real en el sistema HOST.

Conclusiones

Si se ván a virtualizar varios sistemas GUEST simultáneamente, conviene delegar a cada sistema virtualizado la administración de su propio espacio de intercambio. Esto es, debe asignársele a cada sistema GUEST una swap de tamaño suficiente e independiente. Si bien esto provoca lesiones en el rendimiento, ya que los accesos a disco para leer y escribir del swap es más lento que leer de la RAM real, el sistema HOST no sacrificará su propia swap para mantener la demanda de los sistemas GUEST.

Para optimizar aún más el rendimiento de las máquinas virtuales (y en consecuencia el rendimiento de la máquina real), convendría además asignar un disco virtual de tamaño fijo exclusivamente para swap en cada máquina virtual. Si se usara un disco virtual de tamaño dinámico (método corriente) para que el sistema GUEST aloje sus particiones de sistema y swap, el rendimiento sería mucho menor, ya que se usarían muchos recurso del HOST solo en redimensionar dinámicamente la partición del GUEST. Yendo más lejos en las optimizaciones, podrían usarse discos reales exclusivamente para uso como área de intercambio de los sistemas GUEST.

Como se dijo antes, solo el uso indica cuáles son los tamaños ideales para el área de intercambio.

Desarrollo de software multiplataforma II

(Esta es una continuación de la discusión iniciada en la entrada "Desarrollo de software multiplataforma")

Las técnicas de programación multiplataforma se conocen desde hace 40 años. ¿Por qué la industria de la computación dejó de lado todo ese conocimiento, y los programadores redescubren hoy la programación multiplataforma como una novedad?

La IBM PC trajo consigo a las computadoras genéricas, clones, o IBM PC compatibles. Los programadores de aplicaciones para el IBM PC y para el sistema operativo DOS no necesitaban conocer nada acerca de los fundamentos teóricos y los elementos esenciales de los sistemas operativos multitarea/multiusuario desarrollados desde los 60, tales como

• Procesos, bifurcaciones, procesos hijos, hilos. El DOS no provee funcionalidad para ninguno de estos conceptos de software, fundamentales para la multitarea
  
• Pipes, filtros. DOS posee mecanismos rudimentarios de pipes y filtros
  
• IPC o Intercomunicación entre procesos. Como DOS no estaba diseñado para multitarea, la intercomunicación entre procesos es un concepto sin sentido
  
• FIlesystem o sistema de archivo. En DOS la organización de archivos está programada estáticamente en el sistema operativo y no se puede cambiar. En sistemas tipo Unix el gestor de sistemas de archivos es un simple driver que se puede cambiar dinámicamente, incluso en funcionamiento
• Lock o cierres de exclusión mutua. Este es un concepto MUY asociado a sistemas multitarea. Permiten bloquear el uso de algún recurso de la computadora por parte de un proceso, para que otros procesos no usen en ese momento el mismo recurso. En DOS no existe este concepto, aunque los programadores encontraron formas rebuscadas de simular locks, como por ejemplo en los programas antivirus "residentes" que podian acceder a los discos al mismo tiempo que los programas (si bien los antivirus son un ejemplo de programas funcionando en multitarea, a esta funcionalidad no la provee el sistema operativo, ya que depende de un método propio del DOS, que es la utilización de programas residentes. Los virus para DOS usaron este mecanismo antes que los antivirus).
  

Ya que no hacía falta concentrarse en todos estos conceptos y problemas de diseño asociados a los sistemas multitarea/multiusuario, los compiladores para DOS proliferaron, y por lo tanto la industria de software para DOS floreció a un ritmo nunca antes visto, alejando irreversiblemente a los programadores de la Ciencias de la Computación .

Conclusiones

A mi entender, estas son las razones por las que los programadores se alejaron de la programación multiplataforma y de las bases científicas/matemáticas de la computación.

La arquitectura IBM PC+DOS logró retroceder el desarrollo de la computación en 20 años, volviéndola más primitiva de lo que los teóricos de los primeros sistemas operativos multitarea/multiusuario podrían tolerar.

Hoy en día, con computadores que contienen múltiples CPUs, y dado que la construcción de clústeres y sistemas distribuídos es moneda corriente, el ingeniero de software no puede ignorar ni eludir los conceptos y arquitecturas desarrolladas en los sistemas operativos tipo Unix.

Desarrollo de software multiplataforma

El Software Multiplataforma

Desde el advenimiento de los sistemas operativos basados en GNU/Linux, los programadores se han dado cuenta que programar para un sistema operativo específico es una pérdida de tiempo. Considerando que los sistemas operativos tipo Unix son cada vez más populares, tales como GNU/Linux, Macintosh y otros, es mejor para un programador dominar aquellas herramientas de programación que le permitan portar sus programas entre varias plataformas sin tener que invertir mucho tiempo en reescribir el programa.
Se entiende por software multiplataforma a aquel software que tiene versiones para varios sistemas operativos y arquitecturas de hardware. Una definición más extensa se puede leer en la wikipedia, en http://es.wikipedia.org/wiki/Multiplataforma .

Para los usuarios no relacionados a la actividad informática las computadoras solo funcionan con Windows y los procesadores son Intel o AMD. Los usuarios que por su trabajo necesitan usar otros sistemas operativos y arquitecturas saben que exiten sistemas operativos como Unix, Linux, Mac OS, y que estos pueden funcionar hasta en otra clase de procesadores.

Aunque parezca sorprendente, muchos desarrolladores de programas también desconocen la existencia de otros sistemas operativos y de otras plataformas de hardware. Solo desarrollan programas para Windows, y conocen solo las herramientas de desarrollo de Microsoft.

Este desconocimiento por parte de usuarios y desarrolladores de la existencia de otros tipos de computadoras y programas es causa y consecuencia del predominio de Windows en el mercado de computadoras.

Sin embargo, y acompañando el auge de los sistemas operativos basados en GNU/Linux, el desarrollo de software orientado a múltiples plataformas se revela como criterio de diseño fundamental en la ingeniería de software, aún cuando la plataforma principal no sea GNU/Linux.

Compiladores multiplataforma

La herramienta "primera" para crear programas de computadoras son los compiladores. Estos programas son los que permiten crear otros programas. Sin ellos, programar sería un proceso muy lento e ineficiente. Sugiero al lector interesado visitar http://es.wikipedia.org/wiki/Compiladores para una descripción más extensa de lo que son los compiladores.

Por su naturaleza, cada compilador está íntimamente ligado al tipo de hardware y al sistema operativo para el que está diseñado. Por lo tanto, escribir compiladores multiplataforma es la tarea más difícil en la ingeniería de software, ya que el compilador debe resolver de una manera autoconsistente y correcta todas las diferencias entre plataformas, de manera que al programador le queden ocultas todas estas diferencias.

Pese a la cantidad de sistemas operativos y arquitecturas de hardware vigentes, existe un compilador, o más bien una suite de compiladores, que ha tenido éxito en una gran cantidad de hardware y sistemas operativos. De hecho, debe ser el compilador más exitoso en la historia de la computación. Se trata de la suite GCC, desarrollado por la Free Software Foundation como primer paso para la creación del sistema GNU. Más información en http://es.wikipedia.org/wiki/Colecci%C3%B3n_de_compiladores_GNU .

La suite GCC es usada por la mayoría de los sistemas operativos tipo Unix, y puede crear programas para más de 40 tipos de CPU, incluídos microcontroladores. Tambien funciona en Windows, y es capáz de crear aplicaciones para Windows desde otras plataformas. Esto dá cuenta del éxito del diseño multiplataforma de GCC.

Escribir una vez, compilar en cualquier lado

La ventaja principal de usar compiladores multiplataforma es que el programador debe escribir el programa una sola vez. Cada vez que necesite una versión para una plataforma en particular, solo deberá recompilarlo usando la versión de compilador específica para esa plataforma a partir del mismo código fuente.

Llevando el diseño multiplataforma al extremo, algunos compiladores están desarrollados a tal punto que es posible compilar un programa destinado a una plataforma desde otra plataforma muy distinta. Por ejemplo, aplicaciones como Firefox pueden ser compiladas desde Linux para generar una versión que funciona en Windows. Este proceso se llama crosscompiling. Se puede aprender sobre el tema en la wikipedia, en http://en.wikipedia.org/wiki/Cross_compiler .

En contraste, los programadores de Visual Basic (o Visual Studio) encuentran imposible crear aplicaciones para Linux, Macintosh, u otro sistema operativo usando el mismo código fuente, ya que las herramientas que usan solo compilan programas para los sistemas operativos Windows.

Diferencias entre plataformas

Si bien los compiladores se encargan de abstraer la mayoría de los detalles internos del sistema operativo para el que se escribe, algunas veces es necesario que el programador haga llamadas al sistema que no están contempladas en el compilador. Esto es común, pero solo en casos de relativa importancia, tales como consultas sobre localización de los directorios para archivos temporales, directorios del usuario, etc.

Windows, siempre windows

De los sistemas operativos de uso más común, el único que no cumple con lineamientos estándares es el sistema operativo Windows. En todas sus versiones, está diseñado deliberadamente para excluír o al menos dificultar la aplicación y el uso de estándares y herramientas de desarrollo multiplataforma. De hecho, desde los tiempos de DOS Microsoft incluye en sus sistemas funcionalidades no documentadas, con el único propósito de otorgar ventaja a sus propios productos de software frente a productos de desarrolladores independientes. Aún cuando los programadores siempre supieron esto y hasta documentaron extraoficialmente las funcionalidades ocultas, es ilegal hacer uso de ellas. Un sitio aquí dá cuenta de ello.

Sin embargo, los desarrolladores de compiladores han sido ingeniosos y han logrados sortear los obstáculos técnicos y campos minados legales inherentes a la arquitectura de los sistemas operativos WIndows.

Interfaces gráficas

Para el usuario de las herramientas de desarrollo de Microsoft, no existe una división entre el sistema operativo y la interfaz gráfica. Este deliberado error de concepto funciona como obstáculo para la migración de programas desde Windows a otros sistemas operativos.

En sistemas tipo Unix (GNU/Linux, Mac OS, BSD) la separación entre sistema operativo e interfaz gráfica es fundamental. Este aspecto de modularidad de Unix devino en el desarrollo de múltiples herramientas de software para la implementación de interfaces gráficas. Si bien esta diversidad resultó ser una desventaja en los comienzos del desarrollo de Unix como estación de trabajo, hoy en día muchas de esas tecnologías convergen en lo que hoy conocemos como Servidor X, http://es.wikipedia.org/wiki/Sistema_X_Window en la wikipedia.

Con el Servidor X quedaron resueltos los problemas de estandarización de los mecanismo para programar aplicaciones gráficas. Pero todavía queda una capa de software a resolver: los widgets, u objetos de control gráficos.

Los widgets u objetos de control gráficos

Al decir widget, nos referimos a los elementos gráficos de un programa tales como botones, barras de scroll, contenedores de texto, menúes, etc.

Como es de esperar en la tradición del desarrollo del software libre, existen muchas implementaciones de widgets. Las más populares son las que proveen las bibliotecas Gtk y las bibliotecas Qt. Como toda buena herramienta de programación, las bibliotecas Gtk y Qt son multiplataforma.

En cuanto a widgets, Windows no deja de ser una excepción. Posee su propia colección de widgets, exclusiva de Windows. En contraste, las bibliotecas Gtk y Qt están escritas de manera que ocultan al desarrollador la plataforma final. Incluso al crear una aplicación para Windows, todas las llamadas e interacciones con widgets Gtk o Qt hacen una traducción en tiempo de ejecución para conectarse y usar los widgets de Windows.

Crear aplicaciones que usan Gtk o Qt es crear aplicaciones multiplataforma que además pueden ser compiladas para Windows.

Para conocer más sobre Gtk y Qt, leer http://es.wikipedia.org/wiki/GTK%2B y http://es.wikipedia.org/wiki/Qt_(biblioteca) .

Manos a la obra

Resumiendo lo dicho en párrafos anteriores, lo que necesitamos para crear una aplicación multiplataforma es:

• Un compilador multiplataforma
• Una colección de widgets multiplataforma
• Un entorno de desarrollo
  

Mi compilador y colección de widgets favoritos

Hasta ahora solo he mencionado a GCC como herramienta para la creación de programas multiplataforma. Si bien el lenguaje C es el más difundido para la creación de sistemas operativos, existen alternativas tan útiles y efectivas como la suite GCC para la creación de aplicaciones gráficas.

¿Es posible encontrar una herramienta que reúna al mismo tiempo un compilador y una biblioteca de widgets para la creación de software multiplataforma? Si, y se llama Freepascal.

En rigor, Freepascal no provee de una biblioteca de widgets, pero ofrece todas las herramientas y artefactos de computación necesarios para la creación de conjuntos de widgets usando el compilador, sin necesidad de bibliotecas externas.

La biblioteca de widgets más popular escrita para usar el compilador Freepascal, es la herramienta Lazarus. Lazarus provee, al mismo tiempo, una biblioteca de widgets y un entorno de desarrollo.

Para conocer más sobre Freepascal y Lazarus, leer en http://es.wikipedia.org/wiki/Free_Pascal y http://es.wikipedia.org/wiki/Lazarus .

Freepascal y Lazarus permiten desarrollar aplicaciones del tipo :

• Drivers, daemons y otros programas de sistema
• Aplicaciones de consola
• Aplicaciones gráficas. Lazarus puede conectarse a Gtk, Qt y a otros widgets multiplataforma. De hecho, Lazarus recurre a estas bibliotecas para la creación de los widgets. De esta forma es posible elegir el widget final en tiempo de compilación.
  
• Aplicaciones web. Freepascal provee de herramientas para la creación de aplicaciones CGI.
• Aplicaciones CGI en la forma de módulos Apache
  
• Conexión a bases de datos locales y externas, embebidas o de la forma cliente-servidor. Como provee de un conector ODBC, Freepascal puede conectarse virtualmente a casi todas las bases de datos.
• Aplicaciones cliente-servidor mediante conexiones de red UDP.

Conclusión

Solo hay una forma de escribir código fuente: orientado a múltiples plataformas.



Adenda

Las técnicas de programación multiplataforma se conocen desde hace 40 años. ¿Por qué la computación dejó de lado todo ese conocimiento? ¿Por qué los programadores redescubren hoy la programación multiplataforma? La respuesta a estas preguntas se exploran en este blog, en la entrada "Desarrollo de Software Multiplataforma II".