Windows CE (II). Diferencias con un PC

Protección de Procesos
Quizá a simple vista pueda parecer un paso hacia atrás, a los tiempos del Windows 3.1, pero en Windows CE el sistema de protección entre tareas es muy débil, de modo que una aplicación puede, si no desestabilizar el sistema, sí detenerlo por completo.

No se trata de un fallo, sino de una limitación de los microprocesadores que se utilizan en entornos embebidos, de modo que, efectivamente, un proceso inestable puede llegar a hacer necesario un reinicio del dispositivo.

Pero debemos tener en cuenta el hecho de que el destino de estos aparatos no es el mismo que el de un PC, sino que el número de aplicaciones que van a ejecutar es conocido y está determinado en tiempo de desarrollo.

Habrá dispositivos que ejecuten como máquinas cerradas, por ejemplo un sistema de parking con la típica pantallita táctil; en este tipo de desarrollos dentro del dispositivo se va a ejecutar el sistema operativo y la aplicación, de forma que el comportamiento de ésta va a estar perfectamente prefijado desde un principio, por lo que en teoría cualquier problema, y sobre todo cualquier problema que bloqueen el equipo, va a estar solventado en origen.

Otros elementos serán más versátiles, como los puntos de información, o las máquinas de venta de productos variados, o incluso un videojuego; aquí el software entraña mayor complicación, por lo que se requieren más validaciones, pero al final se trata de lo mismo: un sistema completamente cerrado, por lo que el tema de protección de procesos pierde interés frente a una mayor seguridad del hardware o simplemente al coste del dispositivo…

Tamaño de la pantalla
Esta diferencia sí que puede ser rompedora a más no poder. En un dispositivo embebido no podemos asumir ni siquiera un rango de tamaños de pantalla… Podemos tener aparatos sin pantalla de ningún tipo -un router, una impresora-, otros con un simple display alfanumérico, y entre ellos desde uno de una línea de caracteres fijos hasta los de varias, o gráficos, o mixtos, o de 7 segmentos…

También podríamos disponer de una pequeña pantalla tipo PDA más o menos estándar, o una que no lo sea, de, por ejemplo, 1000×10 píxeles (un rótulo), o incluso varias pantallas, unas con chip 3D, otras con framebuffer, o con acelerador 2D… Incluso dispositivos a los que no se les haya incluído el soporte de vídeo dentro del CE pero que tengan pantalla con una biblioteca propia…

Por eso no se puede asumir nada sobre la salida de gráficos… Cada dispositivo tendrá sus características, y un aplicativo realizado para un modelo podría no servir para otro idéntico pero con diferente soporte de vídeo…

Periféricos extra, exóticos… o ninguno
Otra diferencia son los periféricos. Aquí tampoco podemos asumir nada. Habrá aparatos que lleven disco duro, o lectores de CD, otros quizás un sistema de lectura en Compact Flash, o Secure Digital, o simplemente una ROM en chip sin más.

Los habrá con USB, o con cinco o diez puertos serie, o SPI, con sonido o sin él, con una impresora típica o algo más extraño, como una térmica o incluso un elemento impresor de seguridad.

Podrían tener dispositivos para pagar dinero, o aceptarlo…

Incluso podrían tener una batería de relés o comutadores para comandar cualquier cosa…

Velocidad y rendimiento
Tampoco podemos asumir nada respecto al posible rendimiento. Habrá aplicaciones que apenas requieran recursos, y las habrá que necesiten uno o varios procesadores SIMD o MIMD asociados…

Por ello no debemos ser conscientes de la optimización y del consumo de memora y recursos. No estamos ante un PC, sino antes algo mucho más pequeño y más limitado, aunque a simple vista, por la forma de desarrollo, parezca que trabajamos con un PC. Y debemos ser enormemente cuidadosos a la hora de hacer nuestros programas, pues aparte de lo habitual, debemos poner especial cuidado en el optimizar el consumo de memoria y el tamaño de nuestro código.

Depuración remota
Generalmente, y salvo que estemos trabajando con los emuladores, el proceso de depuración suele diferir algo respecto al tradicional. Quzás la mayor diferencia sea que ahora la máquina sobre la que ejecutamos nuestro programa es diferente a la que compila y contiene el entorno de desarrollo, y generalmente se trata de arquitecturas diferentes. Pero MIcrosoft soluciona todo eso de forma elegante y casi transparente para el programador.

Lo más difícil de todo es que tengamos que preparar nosotros todo el sistema de desarrollo, incluyendo en el Platform Builder los elementos necesarios para generar nuestro sistema operativo. A veces la tarea puede ser bastante dificultosa, sobre todo si vamos a desarrollar con el Visual Studio 2005 y con una plataforma construida con el Platform Builder 5. Pero si utilizamos el sistema tradicional, el asunto es trivial.

Generalmente será el proveedor de la placa de evaluación o el que suministre el kit quien monte y prepare todo eso. A no ser que seas tu el proveedor, y entonces te tengas que currar todo, que es mi caso.

El proceso para lanzar un ejecutable es bastante sencillo. Desde el IDE, previa conexión con la placa («Tools» -> «Connect to Device», aunque esto a veces es automático), tu programa se compila y genera el ejecutable válido para el ordenador remoto. Cuando lances la depuración, el IDE enviará el ejecutable junto a todo lo necesario a la placa destino, y lanzará la aplicación allí.

Cuando pongas un punto de interrupción, o detengas la ejecución, verás el resultado y la parada del programa en la ventana de tu IDE, pero todo lo demás -salida de video, acciones, etcétera-, se ejecutará en el dispositivo. Como es una conexión remota, todo esto es bastante más lento que programando directamente con el PC, aparte de que la aplicación se ejecutará en destino bastante más lenta de lo que lo haría si no estuviera el depurador anexado.

Formas de conectar hay muchas, desde el ActiveSync por canal serie o USB, hasta una conexión Ethernet, que suele ser la más rápida. Depurar a través de un puerto RS-232 puede ser una tarea desesperante, sobre todo si el programa es grande.

Generalmente dispondremos de un canal de comunicación unidireccional desde el dispositivo hacia el Visual Studio, que aparecerá en la ventana de registro correspondiente. Estas llamadas se suelen hacer mediante la macro RETAILMSG, que se encuentra ampliamente documentada.

Pero no estamos limitados al Visual Studio. Podremos ver el sistema de ficheros remoto, así como el registro, o la lista de procesos. Tenemos hasta un medidor de rendimiento. Todo ello se puede ejecutar desde el menú «Microsoft Visual Studio 2005» -> «Microsoft Visual Studio 2005 Remote Tools». La idea es la misma que con el IDE, en tu ordenador verás lo que hay en el remoto, previa conexión con el dispositivo.

Limitación de APIs
Quizás lo que más moleste a un programador hecho y derecho que se acerque al mundo embebido, o que tenga que desarrollar tanto para PC como para éste, es el hecho de la limitación de las APIs.

La de Win32 no está muy capada, y casi se permiten las mismas cosas, lo único que por lo general sólo hay un camino viable, y lo que se ha eliminado es porque no tiene mucho sentido dentro del mundo embebido, pero otras limitaciones pueden llegar a ser algo desesperantes.

Y este es el caso del .NET. Mientras que para el PC cuenta con un richo conjunto de elementos, el Compact .NET se encuentra bastante -por no decir mucho- limitado, por lo que hay que tener un cuidado exquisito a la hora de diseñar nuestra aplicación, porque seguro que muchas cosas con las que contábamos como evidentes, no están disponibles y te toca o hacer interop al mundo nativo o buscarle tres pies al gato o, simplemente, no hacerlas.

Y una cosa que personalmente me repatea es que no haya C++/CLI para dispositivos embebidos.