Con las contribuciones anteriores creo que ustedes mis apreciados lectores del hilo podrán haber entendido y yo haberme podido explicar que objetivos tengo y porqué. me sorprendería que hubiera logrado explicarme y explicar el sistema de forma adecuada, por lo cual preguntas son bienvenidas!
El lograr los objetivos presentados arriba para mi sistema de control de escotas requiere como lo había escrito mas arriba, actualizar y avanzar mis conocimientos matemáticos por lo cual estoy estudiando matemáticas con el objetivo de adquirir los conocimientos requeridos. Los cursos ofrecidos para el bachelor de matemáticas del instituto de matemáticas de la universidad técnica de Munich, en breve TUM y de la segunda universidad prestigiosa aquí en Munich, Ludwig Maximilian Universität München, en breve LMU, en parte son complementarios. Así estoy estudiando con el objetivo de adquirir tales conocimientos. Escribí en otro lado que cuando mas se mira en detalle cursos universitarios sin sólidos conocimientos matemáticos que al menos ya soy capaz de ver como elementos básicos de las matemáticas me siento como "analfabeto matemático y legasténico matemático"! Gracias a que los cursos existen de las mas diversas fuentes como videos de las lecturas universitarias, para los cuales hay archivos con las notas que acompañan tales lecturas, igualmente hojas de los ejercicios con y sin las soluciones y de ciertos cursos hasta videos de las clases de práctica en resolver los ejercicios es mas facil estudiar a base de esos datos que el estar presente durante las lecturas de un profesor. El profesor en esos videos está presente las 24 horas del día, los 7 días de las semana y todo eso gratuito. además también se encuentran gratuitos o muy económicos los libros en relación a tales cursos. Pero para mi sistema de control de escotas las matemáticas son una competencia fundamental para poder usar efectivamente las herramientas de wolfram, pero también son indispensables para poder adquirir los conocimientos de física teórica y experimental, dicho los cursos que se ofrecen para el bachelor de física. Lo mismo rige para el bachelor de electrónica que me ayuda a poner mis conocimientos adquiridos durante las últimas décadas en un contexto sistemático. Siguiendo estas actividades n el ámbito de la electrónica me he creado un flamante y bastante completo laboratorio electrónico.
En el modelismo naval somos perseverantes y así hemos desarrollado la capacidad de ir cambiando de tema cuando el ánimo en uno de los campos disminuye.
Así me compre la placa Raspberry Pi B+ como bundle con la tarjeta de memoria SD y los sistemas operacionales bajo el nombre de NOOB, siendo Raspberian una distribución de Linux para la cual wolfram ha hecho disponible de forma gratuita su software "Mathematica" y "Wolfram Language". Ya por tal razón tengo el módulo disponible para el RaspBerry Pi B+ de WIFI para que así mi placa Raspberry Pi B+ pueda acceder el Internet y así el "Wolfram Language" pueda acceder a los recursos disponibles allí!
Las razones para comprar tal placa son:
1. Aprender a usar Linux, no solo como sistema operacional general, sinó tambien como tal en el ámbito de sistemas embebidos.
2. Aprender a usar la Software "Mathematica" andando de forma local en el sistema embebido para empezar haciendo el "Hola Mundo" del sistema embedido, el blinquar de un LED. En aproximadamente mes y medio tendré los pesitos disponibles para adquirir la licencia no comercial de "Mathematica" para usa no comercial y así quier lograr ese "Hola Mundo" cambiando el valor de una variable lógica en el entorno de "Mathematica" en el ordenador bajo Windows 7 Ultimate 64 bit de "True" a "False" y viceversa ylograr que el LED blinqué.
Asi lograré aprender y experimentar con Mathematica en el entorno e ir expandiendo para poder dialogar con las placas LPCXpresso1769. A ver también si es posible ejecutar "Mathematica" también en la placa LPCXpresso1769?
La segunda placa que compré se llama "Teensy 3.1." Wolfram apoya para su uso en conjunto con su software "SystemModeler" y el formato "Firmata". Firmata por lo tanto existe y se usa por SystemModeler para comunicarse con la placa "Teensy 3.1" para la cual también existe "Firmata". Los pesitos para la compra de la licencia de SystemModeler me va obligar a ahorrar otros 3 meses. seguro que estos procesos de aprendizaje van a tomar bastante mas tiempo. Mientras tanto puedo estudiar el entorno de desarrollo llamado "Teenduino"y que es una variante del IDE de Arduino para las placas "Teensy". Esta placa Teensy 3.1 usa un controlador ARM Cortex M4 de Freescale y así quiero estudiar el protocolo Firmata dentro del contexto de Linux en un controlador del tipo ARM Cortex Mx. desafortunadamente el "experto", un tal Paul, que desarrolla el software para las placas Teensy tiene los 2 objetivos de concentrarse en todo lo que fomente las ventas de Teensy y de seguir las lineas del entorno Arduino con el objetivo de mantener todo sencillo para la clientela de principiantes y universitarios. así yo y otros han tenido que realizar que no habra apoyo adecuado del proveedor de Teensy y de su apoyo técnico para los requerimientos mas avanzados. Copiaré en la siguiente contribución texto con gráficos que ilustran el tema y que todo esto en conjunto contribuya a dar por ejemplo a miborbolla los datos requeridos.
Aquí un gráfico del modelo OSI de 7 capas:
Como pueden ver ser trata de un modelo que refleja de forma sistemática la comunicación de 2 ordenadores por sobre una red. Este modelo permite de forma sistemática representar las propiedades de tal comunicación. No siempre las implementaciones se hacen estrictamente en concordancia con este modelo, pero siempre es posible reflejar cualquier entorno sobre ese modelo, haciendo así posible el poner implementaciones en relación a tal entorno!
Este gráfico muestra diferentes entornos y los mapea en el modelo OSI. Vemos por ejemplo que el bien conocido Ethernet representa las capas 6 y 7, WIFI, USB y otros encajan aquí. Vemos que en la capa 5 y en parte de la 4 se encuentra el protocolo IP, Internet Protocol que en combinación de las capas 3 y 4 representa el protocolo de comunicación del Internet, TCP/IP. Las capas 1 y 2 en este gráfico muestran ejemplos como del "FTP" que se usa mucho para transferir archivos por ejemplo de un servidor a un ordenador. Pero para explicar el entorno dentro del cual usando los programas de "Wolfram" presentados anteriormente, "Mathematica" y "Wolfram Language", aplicaciones que andan en el ordenador o por ejemplo en la placa "Teensy". Estos programas se ejecutan en la capa "1", pero el protocolo "Firmata" se ejecuta en la capa "2". El nombre de la capa "2", "Presentación", muy bien describe su función y así me permite explicar lo que tengo pensado estudiar, aprender y modificar para realizar mi objetivo del sistema de control de escotas y para explicar la razón por la cual me compré la placa "Teensy 3.1"!
Voy, con este propósito introducir otro elemento, llamado "biblioteca". La función de una biblioteca en la programación es la de proveer una interfaz para funciones adicionales requeridas. Aquí pues empiezo presentando la biblioteca "CMSIS". Esta biblioteca, que de acuerdo a la licencia que empresas que crean controladores basados en "ARM Cortex Mx", cada empresa que crea un controlador basado en esta licencia está obligado a proveer.
El objetivo final es tener tal entorno que pueda relacionar toda función, todo registro en una placa y/o dentro de un controlador, a una variable simbólica dentro del entorno del programa "Mathematica" y usar esasa mismas variables simbólicas dentro de los bloques que creo dentro del entorno del programa SystemModeler en los objetos que diseño usando el lenguaje Modelica introducido anteriormente. Allí entra a jugar la capa 6 del modelo OSI! Tengo que crear un entorno que "represente" los registros y funciones dentro de la placa que uso y que tenga una definición de como se puede acceder a tal elemento. Eso se denomina "Application Programming Interface, en breve API. El protocolo tiene la función de crear el enlace entre los APIs disponibles para cierta placa y/o componente electrónica. Otro nombre para esto es "Hardware Abstraction Layer", en breve "HAL" y expresa que a razón de la suma de APIs se representa la hardware de forma abstracta o modelizada. Como podemos ver mas adelante la complejidad de controladores como el aquí usado sobrepasa las capacidades del protocolo "Firmata" simplemente por existir un número de elementos mayor al que se puede representar dentro del formato de protocolo "Firmata". he llevado algunas discusiones e intercambios en el foro relacionado a la placa "Teensy", donde un tal Paul expresó de forma muy clara que las prioridades de sus trabajos estan en fomentar el uso de las placa Teensy, de moverse dentro del entorno "Arduino" y de su sistema de programación, IDE y de la variante que exoiste explícitamente para el Tennsy, Teensyduino. Mi interés está en aplicar un protocolo lo suficientemente potente para poder aplicarlo a cualquier controlador del tipo ARM Cortex Mx y de hacerlo de tal forma que pueda así encontrar el "perfil" de funcionalidades disponible para cierto controlador ARM Cortex Mx de cierto proveedor. Pues bien la biblioteca CMSIS que existe para cada instancia de un controlador ARM Cortex Mx contiene la definición, el API y/o HAL correspondiente a ese controlador específico y detrás de esos APIs la implementación de los "drivers", la software que efectivamente realiza el accesso a un elemento como un registro.
Como podemos ver en el gráfico que representa la estructura los bloques azules abajo en el diagrama del CMSIS nos dan exactamente eso. Tomando los archivo "*.h", que dentro del entorno del lenguaje "C" por ejemplo dan un nombre simbólico a un registro que se encuentra en cierto punto, definido por una dirección de memoria. Si ahora cambio de un controlador "A" a otro "B", ese mismo registro, y con eso me refiero a tal registro que cumple la misma función dentro del controlador "B", el archivo "B.h" asigna otra dirección, correspondiente al sitio donde se encuentra ese registro en el controlador B. Pero como en mi programa accedo a ese registro por su nombre simbólico sigo accediendo el registro de la misma función. De allí el término "HAL, que expresa la abstracción lograda usando no la dirección física de cierto registro, sino su nombre simbólico. Al momento de crear el programa ejecutable en el controlador para el controlador "A" del IDE reemplaza el nombre simbólico por la dirección física correspondiente. Si creo el ejecutable para el controlador "B" entonces la IDE reemplazará el mismo término simbólico por la dirección física en el controlador "A" que probablemente será diferente a la del controlador "B". Así la biblioteca CMSIS permite generar programas que pueden ser portados a cualquier controlador ARM Cortex Mx que contenga mínimo las mismas funcionalidades y por lo tanto por ejemplo ese mismo registro. No hay que menospreciar la ventaja que CMSIS crea para usuarios de sistemas embebidos a base de controladores ARM Cortex Mx. Si el día de mañana por cualquier razón quiera cambiar de controlador, sea de otro proveedor o otro del mismo proveedor, incluyendo la biblioteca CMSIS del nuevo controlador y reemplazando el "viejo CMSIS" el esfuerzo para portar el software será mínimo. Pero eso mismo tiene como consecuencia que si los clientes del proveedor "A" tienen que escoger un controlador para un nuevo proyecto todo proveedor tiene que poner máximo esfuerzo en lograr un máximo de eficiencia, de calidad de sus implementaciones de la biblioteca CMSIS para sus productos. Si no lo hace, entonces está regalando los esfuerzos que puso en el diseño de su hardware y así desprestigiando su implementación del controlador.
Por encima de los bloques azules aparecen inmediatamente bloques verdes y por encima de estos vemos un bloque violeta llamada HAL. Los bloque verdes no son mas que la agrupación lógica de los bloques azules a los bloques físicos de los que consiste un controlador. El bloque llamada "CMSIS-CORE" representa aquella parte física del controlador que implementa aquellas funciones que definen si se trata de un ARM Cortex "M0", "M0+", "M3", "M4" o "M7" y la descripción de esa parte del controlador es idéntica a la especificación del tipo de controlador tal cual lo define la documentación disponible para tal tipo de controlador de la empresa "ARM". Así pues esos "API"s serán idénticos para todos los controladores "ARM Cortex M" y se suma lo específico para cada variante de esos controladores "ARM Cortex Mx" que nombre arriba.No entro en detalles de describir los otros bloques verdes y el del "Debug", pero vemos que al nivel del bloque violeta "Device HAL" existe un segundo bloque violeta llamado "RTOS" y el cual usaré que es disponible de forma gratuita llamado "FreeRTOS".Algo muy util para lograr coordinar las diversas labores que ocurren de forma aparentemente paralela en el controlador. El bloque color violeta claro arriba en ese gráfico es donde entra a jugar la capa "6" del modelo OSI. En esta capa llamada "Presentation Layer" pongo a disposición el protocolo, como es el caso de "Firmata". Firmata no esta hecho para aprovechar las posibilidades que brinda el "CMSIS" también debido a que muchos usuarios de la placa Teensy 3.1 por ejemplo son principiantes y como tal Paul correctamente expone ese grupo es el principal mercado de tal placa. Implementando algo que se aprovecha del CMSIS y de tal forma también de un RTOS como el FreeRTOS, en especial tengo el foco en la variante "FreeRTOS-MPU", hace su uso mas complejo.
Estos 2 gráficos me acaban de llegar con la placa Teensy 3.1 y aquí los comparto con ustedes. vemos en estos gráficos básicamente a razón de la descripción de las funcionalidades de los pines que periferias son accesibles físicamente usando esos pines y configurando el controlador de forma correspondiente. aquí es donde el CMSIS junto con un protocolo como el Firmata permiten de forma común a todos los controladores ARM Cortex Mx configurarlos para usarlos.
Finalmente este último gráfico nos da una visión de las funcionalidades disponibles dentro de la familia de controladores ARM Cortex M4 de Freescale llamada Kinetis y donde dentro de la documentación disponible vemos que de ellas es disponible dentro del controlador usado en el Teensy 3.1!
Como el SystemModeler de wolfram ya apoyo el uso de ese formato Firmata puedo así en su momento no solo estudiar el como está realizado el protocolo Firmata, la versión 2.3 es apoyada de acuerdo a un ingeniero del apoyo de SystemModeler. Trato por un lado de aprender la implementación de lo existente y fomentar que Wolfram vaya por un camino mas apropiado, por otro lado quiero entender si es posible y si si como, o modificar el formato Firmata a crear algo que se beneficie del CMSIS, ya no para el de la placa Teensy 3.1, sino de la placa LPCXpresso1769 de NXP que usaré dentro de mi sistema de control de escotas.
