Siguiendo una conversación muy interesante sobre Micro Framework y las dudas que surgen a la hora de implementar o desplegar aplicaciones, me complace compartir ciertas puntualizaciones sobre su arquitectura con el fin de clarificar e identificar cada uno de sus componentes.
Generalmente una de las principales confusiones es distinguir donde se encuentra ubicada cada una de sus capas. En ese sentido situaremos a nuestras aplicaciones y Visual Studio en el lado de ‘Código administrado’ y el resto representado a la parte de ‘Código Nativo’ que residirá en el chip. Deberemos diferenciar los cargadores o ‘TinyBooters’ del propio MicroFramework.
La implementación del ‘Codigo Nativo’ deberá realizarse en dos fases diferentes, en la primera transferiremos los cargadores y en la segunda el firmware de la electrónica.
Veamos su Arquitectura.
Para una mayor comprensión acerquémonos con un poco más detalle:
Finamente la síntesis de toda esta arquitectura se materializa e implementa a través de tres binarios, uno de ellos conocido como el TinyBooter, representa al cargador (es especifico para cada procesador) y dialoga con MFDeploy que será la herramienta del SDK encargada de ubicar los compilados (o sea el MicroFramework) en el chip, estos binarios obtenidos de ‘msbuild’ y los compiladores C son suministrados por el fabricante de la placa electrónica. Aunque no olvidéis que se puede personalizar para adecuarlo a otras necesidades especificas. Aunque en este caso se requiere disponer de los compiladores nativos en C para el procesador en cuestión.
Existe un Kit con el código fuente de base para. NET Micro Framework que puede usarse para crear/personalizar el firmware especifico de cada procesador.
Resumiendo:
TinyBooter es el gestor de arranque que permite a MFDeploy ‘flashear’ en tiempo de ejecución el firmware y/o aplicaciones de producción. El firmware está compuesto en la mayoría de los casos por dos archivos, uno de configuración y otro correspondiendo al binario en si mismo.
TinyBooterDecompressor es un archivo autoextraíble que se carga por el gestor de arranque (TinyBooter) en la memoria RAM y luego ejecuta el gestor real de arranque.
La aplicación descargada desde Visual Studio es código MSIL comprimido para mf net y luego es interpretado en tiempo de ejecución por el propio .net MicroFramework runtime.
Para cualquier cosa no dudéis en seguir esta conversación.
Saludos,
PepLluis,
(**) Las figuras anteriores pertenecen a las ‘Brochures’ y presentaciones técnicas del equipo de MicroFramework y por lo tanto son propiedad de MicroSoft.
