Cuando uno googlea "Satelite Miranda" puede encontrar toda clase de información referente a éste satelite, a diferencia del Simon Bolivar, Miranda se mueve, es un Satélite de órbita baja, el Simon Bolivar es GeoSincrono es decir desde la tierra aparenta no moverse.
Los satélites de órbita baja como su nombre lo indica, giran muy cerca de la tierra, ésto facilita las labores de observación; en el caso del Miranda su objetivo es tomar fotografias con fines pacíficos ya sean desastres naturales, plantaciones, uso de la tierra, minería, entre otros.
Gracias al avance de las tecnologías de los navegadores de Internet, específicamente a lo referente a la visualización 3d quize desarrollar un programa que corra en una página web que nos permita ver por donde anda el Miranda.
Aprovecho la ocasion para hacerle publicidad a mi nuevo sitio web donde voy a colocar los experimentos de laboratorio, en enlace directo al visualizador del satélite miranda es el siguiente:
Una vez carge la página hay que esperar que se visualize el planeta tierra, la fotos las tomo de bing, y por último se debe presionar el botón de inicio para ejecutar el experimento. Algunos usuarios reportan fallas por la versión del navegador, debe estar actualizado funciona con Chrome y Firefox.
Ahora vamos con el crosscompiling y crossdebugging en Intel Edison.
El Edison puede ser programado básicamente de dos maneras; usando la IDE estilo Arduino y la otra forma es compilando directamente para su microprocesador.
En este caso compartiremos la experiencia que hemos tenido en éste aspecto; tiempo atras habíamos dicho que la distribución por defecto del Edison es Yocto, en esta primera etapa nos estamos encargando de probar bien ésta distribución con el objeto de ver sus fortalezas y debilidades que siempre hay que tener muy en cuenta.
Lo primero que hay que hacer es buscar la pagina de descarga y bajar el SDK de nuestro sistema operativo en este link.
Buscamos en la sección Source files, Image and SDK's ....
Personalmente recomiendo trabajar el Edison con Ubuntu, ustedes se habrán dado cuenta por mis capturas de pantallas que uso MacOSX; el hecho de que recomiende linux es simplemente porque los gallos de Intel no incluyeron el gdb crosscompilado para Mac, no se si es a proposito o simplemente un olvido, osea que en la Macbook Pro por los momentos sólo podré compilar mas no depurar, me va a tocar generar el SDK más adelante a mano.
Lo bueno del SDK de linux es que cuando uno lo descomprime se desprende un unico archivo .sh de instalación que funciona a la perfección.
el archivo es el que está en letras verdes, lo ejecutan
pero ésto no le gusta a CodeBlocks, él necesita que al final esté en bin, asi que lo que hice fué duplicar la carpeta i586-poky-linux con el nombre de bin como se ve en la captura anterior.Tal vez quedo un poco feo ../bin/bin pero bueno funciona.
Ahora que ya está el toolchain instalado vamos con el Codeblock.
Obviamente el perfil del compilador para Edison no esta predefinido en el Codeblocks, por lo tanto hay que hacerlo, básicamente lo que podemos hacer es duplicar el de GNU GCC compiler.
Primero vamos a Setting/Compiler and debugger
En Selected compiler está el GNU GCC Compiler presionamos Copy
y le ponemos iEdison Compiler presionamos OK.
Ahora nos vamos a la pestaña de Toolchain y la colocamos como en la captura de pantalla anterior.
En Debugger Setting preferiblemente deberiamos tener seleccionada la opción de Evaluate expression under cursor, y muy importante debe estar seleccionado en el combobox Custom(specify instruction-set:)
Le dedimos que genere los simbolos de depuración. En Debugger Setting
Ahora desde el Edison vamos a iniciar el gdbserver.
Como se puede ver en la figura nos ubicamos donde está nuestro programa a depurar y le decimos gdbserver *:1234 holamundo 1234 es por supuesto el puerto TCP de depuración, aqui puede ir cualquier número de puerto siempre y cuando esté libre. Volvemos a nuestro PC en linux nos vamos a propiedades
y le decimos como va a depurar el programa.
observen que la conexión es de tipo TCP la dirección la que tiene el Edison y el puerto que colocamos en gdbserver 1234. Ésto va permitir que cada vez que le demos a Debug busque el Edison por la Red en el puerto indicado para depurar.
Vemos según la pantalla anterior que todo funciona a la perfección. Hay que recordar que cada vez que se vaya a depurar hay que ejecutar del lado del Edison el gdbserver.
No siempre el Arduino es la mejor opción para realizar un proyecto embebido, en éste artículo expondremos un caso donde el microframework nos permitirá ahorrar algún dinero, espacio físico y tiempo de desarrollo.
Vayamos al grano...
Supongamos que necesitamos desarrollar una solución de hardware donde se requiera almacenamiento en una microsd y una conexión de red.
Para éste ejemplo haremos la comparación entre el clásico Arduino Uno y el NetduinoPlus2 que es una implementación de microframework OpenSource con el factor de forma del Arduino. Para ser más justos utilizaremos todos los precios de un solo distribuidor en este caso Sparkfun.
vayamos directo al grano con la siguiente gráfica.
Si nos vamos por la opción del Arduino tendríamos las siguiente limitantes: 1) Hay que usar 2 (dos) tarjetas, eso implica que se ocupa el doble de espacio que el NetduinoPlus2 2) No crean que siguen disponiendo de 32k para el programa, la librería Ethernet de Arduino usa 1532 bytes. 3) Al estar usando una tarjeta SPI de hecho ya están usando un pin dedicado a la tarjeta Ethernet y microSD. 4) Poca memoria RAM sólo 2k. 5) Están gastando mucha plata 24.95 + 45,95 = 70,9 dólares. Ahora bien veamos que nos da el NetduinoPlus2 1) Menos espacio, una sola tarjeta. 2) 384Kb que no se ven afectados por uso de la Ethernet puesto que ya está descontado éste espacio. 3) Los puertos SPI están libres. 4) El microprocesador es de 32bits vs 8 bits del Arduino.
5) Al ser microframework el nivel de abstracción es demasiado elevado, imaginense poder usar el poderoso framework .NET sin tantas complicaciones (manejos de hilos, complejos programas que serían muy difícil de implementar en C++).
6) Solo hay que gastar 59.95 dólares. Aquí aplica bien el dicho de las ofertas "Más por Menos".
Ahora bien el Microframework no es la perfección, por ejemplo aquí no puedes tener SoftwareSerial algo que para el Arduino es algo sencillo de hacer; si queremos sacar el MCU del Arduino no hay problema, el hardware nos sale mas barato, con el Netduino no es algo tan trivial; no hay que dejarse engañar de la frecuencia del NetduinoPlus2, aún cuando es 10 veces superior a la del Arduino recuerden que ejecuta un código intermedio, si borramos el microframework del NetduinoPlus2 y trabajamos directamente en el STM32 si veríamos un enorme rendimiento pero sólo en C/C++ o sea sin .NET.
Iniciamos este nuevo año con una publicación sobre la interfaz gráfica uLCD-32PTU de la empresa australiana 4dSystems. Si hacen clic en el link del producto podrán ver todas las bondades.
El modelo 32PTU se maneja a través del puerto serial, eso nos permite desarrollar una interfaz gráfica prácticamente en todos los tipos de microprocesadores que hay en el mercado incluyendo por supuesto en nuestro apreciado IntelEdison, claro hay que aclarar que no estaríamos ejecutando Gnome ni KDE ni nada que se le parezca solamente algo mas sencillo que nos permita interactuar con el usuario.
El módulo es muy completo prácticamente se puede hacer de todo, uno puede trabajar en bajo nivel con un lenguaje script que se llama 4dgl y también se puede usar el modo ViSi que posee un conjunto de controles gráficos preconstruidos.
El detalle que le veo a este modulo en particular es que sólo está soportado para Arduino y Raspberry; en realidad cuando uno trabaja con estas librerías ellas se encargan de ocultar el protocolo del fabricante para que el desarrollador se enfoque en lo que desea mostrar en la pantalla.
El esquema de la libreria a primera vista suele ser un poco incómodo uno no está acostumbrado a trabajar de la manera en que están construidas, uno quisiera al menos que se parezca a trabajar con Qt. Aunado al hecho de que últimamente he estado trabajando con microframework específicamente con el NetduinoPlus decidí iniciar la construcción de una librería en C#.
Si ustedes tienen la oportunidad de trabajar con Arduino y desean manejar muchas pantallas el código se va tornando inmanejable; debido a eso empecé a desarrollar una implementación de WinForm para Microframework utilizando el protocolo de ViSi y le puse como nombre VisiForm.
Estoy muy conforme con la implantación que estoy haciendo ya que prácticamente uno cree que está trabajando con C# en Windows y resulta que es Netduino con la pantalla de 4DSystems.
Si ustedes han desarrollado en C# en Windows verán que la librería VisiForm prácticamente está quedando igual:
Se puede observar que la ventana MessageBox hereda de Form igual que Windows, VisiForm.Form contiene el manejo de mensajes del protocolo VisiGenie codificado en microframework permitiendo que el programador se centre en su código C# como si trabajara para una ventana de Windows, por otra parte quise respetar el nombre de los controles de Visi por que no son exactamente iguales a los de WinForm, por ejemplo hay 11 tipos de botones frente a 1 en Windows, si quieres más tipos de botones en Windows tienes que hacerlos o comprarlos a un tercero. El control Strings que se ve en el código fuente anterior es equivalente al Label de Windows, ViSi también tiene un label pero es solo lectura así que preferí dejar el nombre del control original. Ahora veamos el punto de entrada, se puede observar que es muy parecido al de WinForm.
Créanme que trabajar un sistema con muchas ventanas en Arduino o Raspberry con esta pantalla es algo difícil de mantener, con la implantación que estoy desarrollando VisiForm es súper sencillo ya que todo el protocolo ViSi está codificado en C# al estilo de manejo de mensajes de Windows, me tocó recordar mis viejos tiempo cuando desarrollaba en Windows 3.1 con Lenguaje C, jejeje.
La libreria VisiForm aún esta en desarrollo, es un poco grande también pienso hacer un VisiForm para C++ aunque creo que solo para Raspberry no estoy muy seguro de que el Arduino tenga suficiente memoria para soportarla de todas maneras haré el intento.
A continuación un pequeño video de un sistema biométrico con Netduino y la pantalla de 4dSystems
%2B14.59.32.png)
%2B21.37.24.png)
%2B21.21.05.png)
%2B21.36.53.png)
%2B06.49.34.png)
%2B15.42.48.png)