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.