Construción Voilier según planos

[Hellmut1956]

Mil gracias Luis y lo mismo te deseo a tí y a los otros foristas del foro

[Hellmut1956]

Paso a Paso de mi Proyecto con el RaspBerry
Hola amigos, después de lo que a mí se me hizo una eternidad aparentemente ahora puedo empezar a dedicarme a lo concreto y a compartir mis esfuerzos, vaivenes consistiendo en logros y fallas.

Este hilo se va a dedicar a reportar paso-a-paso mis trabajos dentro del ámbito de mi sistema de control de escotas y de lograr una de los objetivos relacionados, el simular y verificar el control de escotas escribiendo este en el lenguaje de modelación "Modelica" usando como herramientas los productos "Mathematica y SystemModeler" de Wolfram. El Raspi es un sistema que la software de Wolfram apoya y hasta ofrece de forma gratuita para el Raspberry Pi, B+ o 2B su software Mathematica y su entorno y lengua de programación "Wolfram Language".

Para lograr este objetivo y limitándome al contexto de este hilo a temas relacionados al Raspi. Para ello, por un lado, tenía que avanzar mis trabajos relacionados a mi taller y en especial a mi laboratorio electrónico, cosa que describo en otro hilo.

En esta foto tomada esta noche pueden ver la placa del RaspBerry Pi B+ montada en una placa de madera que iré poblando con otras placas en el transcurso de este hilo. También me compré la nueva RaspBerry Pi 2B por ser tan económica, pero empiezo con esta por si la llego a destruir durante mi aprendizaje! A la derecha ven el dispositivo que me armé con la protoboard y no mas para mostrar una placa que permite junto con un cable especial que también tengo los 40 pines del Raspi con el protoboard! Así puedo armar circuitos usando el protoboard y mantener la placa Raspi distante. estoy considerando comprarme un empaque transparente para la placa para así tenerla mas protegida.

La instalación del sistema operacional Raspbian no la voy a describir en detalle pues la única posibilidad haciendo esto es hacerlo menos bien de la multitud de tutoriales disponibles en el Internet en general y en Youtube específicamente. Pero la instalación inicial que pueden apreciar en la pantalla usa la microSD NOOB de 8 GBytes, instalación que resulta en extremo sencilla. Raspbian se puede activar en uno de 2 modos, cada cual teniendo sus ventajas.

Aquella mas adecuada para la programación y los experimentos, al menos inicialmente es aquella no gráfica. Muestro aquí de como se ve esa interfaz pero usando ese modo dentro del ordenador y ejecutando la versión correspondiente de Python 3. Por eso en esta pantalla/ventana aparece la versión 3.5.1 de mi ordenador.

Con la instalación, partiendo de la microSD NOOB o descargando la imagen de NOOB del Internet, se instalan 2 versiones del lenguaje Python. Resulta que el lenguaje "Python" completamente compatible con el inmenso repertorio de software en el Internet es la vieja versión "2.x", siendo allí la versión actual instalada en la placa Raspi es la versión 2.7.3 y que ven en la vista "shell":

La misma versión de Python 2.7.3 pero en el entorno de Windows 7:

La nueva y más moderna versión 3.x y es en la cual me concentro en el ordenador bajo Windows 7 es la versión 3.5.1. Aquí una vez en la versión command line y en la versión IDLE:

Para el Raspi hice la actualización antes de decidirme por hacer este hilo por lo que solo puedo mostrar la versión ya actualizada 3.2.3 y que actualicé usando la siguiente sentencia en el raspi:

sudo apt-get install update Python3

En mi sistema algo no funcionó y tengo que entenderlo para saber que hacer. Sigo teniendo la version 3.2.3 y no la 3.3.

Otra cosa que he investigado es la posibilidad de escribir los códigos de mis programas en el ordenador y de tener ese entorno IDE dentro del ordenador, pero ejecutar los programas en la Raspi. Relacionado a esto está el deseo de también poder hacer el "debuging" dentro del entorno del PC pero el programa siendo ejecutado en la Raspi.

Buscando en el Internet y analizando para este propósito me encontré con el proveedor "Wingware" y me descargue la versión "Personal 5.1.9-1 (rev27910). hay que proceder como si se quisiera instalar la versión personal comprando la licencia y no la versión "Trial"! La versión descargada pinchando "Trial" me resulto en un archivo "zip" conteniendo un folder con todo y escribiendo que se pudiera sacar del "zip" a cualquier lugar en el disco duro y que no se requeriría una instalación. Pues bien, eso no funciona en el entorno de mi ordenador por la software de protección. Pero al iniciar la instalación de la versión "Personal" descargando como archivo "*.exe" permite activar el programa por 10 días de forma gratuita e indica la posibilidad de prolongar 2 veces para un total de 30 días! Vale la pena probarlo, pues el entorno del ordenador es bastante mas poderosa que lo que brinda la Raspi! ya iré contando mis experiencias!

[Hellmut1956]

Hola amigos, realmente creo que vale contar el estado actual! En general en mi proyecto de la construcción del modelo navegable de un velero siempre vuelve a confirmarse que un tema abre las puertas para ramificaciones!

En este caso finalmente mi entorno del taller y del laboratorio electrónico llego a un punto, lejos de haberlo completado, que puedo iniciar trabajos concretos. Así mis actividades en torno del uso de la placa Raspi, resultando que este entorno es apoyado por las herramientas de Wolfram Software que uso, ha vuelto a abrir un ramo de campos que tengo que investigar.

Como aficionado a la electrónica hacer parpadear un LED puro visto desde el aspecto de conectar a uno de los pines la LED y la resistencia es elemental. Gracias a las librerías disponibles para usar los pines del conector GPIO, que mi foco está en hacer ese ejercicio necesario para confirmar una base que funciona, combinándolo con el inicio de las actividades en torno al implementar un GUI!

También aquí vale mencionar que los materiales de información de como usar el "binding" llamado "tkinter", creo que la traducción apropiada del término inglés sería "conectar" objetos del GUI, llamados "widgets", como son Botones y elementos similares que en conjunto implementan el GUI, con las funciones o instancias de "objetos" del código escrito por ejemplo en el lenguaje "Python"!

Para aquellos de Ustedes no tan familiarizados con lo que son "widgets" y con la lengua de programación "Python, aquí una breve presentación:

"Widgets" son objetos como los "botones" que todos conocemos de las GUIs de Windows o Mac por ejemplo. Si con el ratón pinchamos uno de esos botones entonces el programa al que corresponden ejecuta una acción. Herramientas como "Tk", el cual está disponible en el entorno de desarrollo de Python, usa un programa que hace accesible la herramienta "Tk" al lenguaje de Python por medio de las funcionalidades de "Tkinter". Lo que se puede apreciar muy pronto, observando tutoriales en video disponibles en Youtube, Tkinter en combinación con "Tk" y Python conecta un elemento gráfico llamado widgets, aquí como ejemplo un "botón", con un módulo del programa escrito en Python. Así existen por ejemplo 3 parámetros que se pueden asociar a ese widget, "Button-1" = botón izquierdo del ratón, "Button-2" el botón céntrico del ratón y "Button-3", el botón derecho del ratón! Si ejecuto el botón izquierdo del ratón estando el cursor por encima de ese botón, entonces es ejecutado la función conectada a ese parámetro, "Botton-1".
Todo lo que normalmente exige una cantidad considerable de código como por ejemplo:
1.: Monitorear la posición del cursor en la pantalla y detectar que este se encuentra por encima del botón.
2.: Posicionar el botón en la pantalla aún si cambio las dimensiones físicas de la ventana.
3.: Detectar cuál botón del ratón se pincho, eso se denomina "evento".
4.: Habiendo detectado la acción del usuario de haber pinchado un cierto "widget" y por lo tanto haber sido confrontado con ese evento de haber pinchado uno de sus 3 botones el conectar este evento con cierta función de mi programa escrito en Python.
Todo esto ocurre de forma invisible para el programador con solo conector una función al evento correspondiente del "widget" que el usuario pincho!

Esto hace muy sencillo el sumar al código que usualmente hacemos como primer ejercicio, el parpadear de un LED un GUI!

Los problemas para mi en mi proyecto empiezan cuando pienso y considero la implementación de un GUI apropiado para los experimentos que tengo planeados! Yo quiero crear un GUI como los que conocemos de otras herramientas de software, donde es fácil usar y crear un panel instrumental. No mas hay que ver las funcionalidades en esto ofrecido por ejemplo de las herramientas de NI, "National Instruments"!

Lo primero que hice fue investigar las funcionalidades ofrecidas por Tk a través de Tkinter. Aquí existen 3 formas diferentes de implementar el diseño de un GUI. Pero realmente fuera de ofrecer métodos sencillos para definir la GUI se pueden usar los widgets posicionándolos usando un "grid". Grid es una estructura de tabla como lo conocemos por ejemplo de Excel. Los widgets disponibles de forma incluidas en tkinter según lo que mis investigaciones han dado al momento no incluyen un "instrumento" análogo a aquellos que se usan para indicar tensiones de forma análoga en un panel instrumental! Por otro lado widgets adicionales existen, pero identificar un paquete que incluya tales widgets no he sido capaz de encontrar. Adicionalmente se dificulta el asunto de una cantidad inmensa de paquetes para extender la funcionalidad puesta a disposición, pero que se subdivide en versiones que funcionan o solo con las versiones 2.x o de las 3.x de Python. Yo uso la versión 3.5.1

esta imagen, por bonita que parezca, no implementa widgets como la imagen de un instrumento análogo, sino solo como mostrar o datos digitales y imágenes creadas a base de datos que son mostrados en la pantalla como curvas para lo que se usa un widget llamado "Canvas"en Tkinter por ejemplo. Un instrumento análogo debería permitir definir entre que valores puede cambiar el dato y después poner la aguja de acuerdo al valor de los datos.

Claro, existen programas donde es posible crear datos basándose en gráficas vectoriales, pero debe haber alguna herramienta que ofrezca tal funcionalidad!

Para no limitar mi punto de vista en estas investigaciones conscientemente investigo que otras herramientas existen para crear el GUI que ejecutaré en la Raspi finalmente. "Qt" es un ejemplo. Pero también veo la posibilidad de crear el GUI usando herramientas disponibles en javascript. Aquí se gana el acceso a herramientas usadas para el diseño de páginas en el Internet. Pero es posible conectar widgets creados en tal entorno a Python y finalmente al nivel físico de mi placa Raspi? Será posible instalar y ejecutar todo esto en el entorno de la Raspi? Cual camino es el mas sensato a seguir? Aquí estoy abierto y a la espera de consejos de ustedes mis lectores del hilo!

También aquí entra a jugar la posibilidad de usar "Crossplatform" herramientas! Programar en el entorno de Windows 7 en mi ordenador y ejecutar y analizar el comportamiento en la placa Raspi! Como funciona todo esto si me decido por un camino en conjunto en el entorno ofrecido por la herramienta "Wing" de wingware que me acabé comprando una licencia personal no comercial por su apoyo de hacer "crossplatform" desarrollo del PC a la placa Raspi con Python!

Leyendo toda la información que publico ahora el asunto suena apto de crear problemas que no puedo solucionar! Claro, que una vez que mi placa Raspi se comunique con el ordenador por Wifi, que aprenda y logre implementar la funcionalidad de "crossplatform" de mi herramienta "Wing" implementaré aquella solución con foco en simple, que me permita controlar el parpadeo del LED por un GUI y actualmente no veo problema alguno en lograr esto con Python y Tkinter/tk. Pero lo que aquí pongo como prerequisito me exige a mi, por mi decisión de hacerlo en tal forma", entender como Samba o "sh" funcionan y permiten e implementan la comunicación entre mi Raspi y la herramienta Wing por la cual ya me he decidido!

[Hellmut1956]

Tengo ya mas y mejores herramientas que pensado!
Investigando las posibilidades para poder hacer girar una imagen dando un ángulo específico como ocurriría si representa la parte de la brújula que giro, me parecía una opción interesante poder hacer girar una foro. Claro, hacerlo en el ordenador usando Photoshop por ejemplo la cosa es clara. Pero teniendo como objetivo el hacer girar tal imagen de forma integrada en el GUI ya es otra cosa.
Me encontré ayer con la posibilidad de copiar una imagen a una matriz y de realizar la multiplicación entre la matriz que contendría todos los pixel de la imagen y una matriz "4x4" con la cual se puede definir libremente el ángulo de giro de la imagen que resulta! Habiendo tenido noción de esa técnica esta noche en la cama me vino el punto a la mente que para la placa RaspBerry Pi B+ y 2B tambien existe integrado el lenguaje "Wolfram" usado en la software Mathematica. Teniendo no solo una licencia legal de Mathematica 10 en el PC, sino también en las placas Raspi fui al programa y me encontré que allí existen las sentencias requeridas:

1. Import ["file"]: Siendo file el "Path" al archivo en la memoria del disco del Raspi (tarjeta Flash o como tengo pensado hacer en un disco duro conectado por USB).

2. ImageDimensions: Que me da el tamaño de la imagen en pixels (2D)

3. ImageData: que me crea una matriz donde se graban los pixels individuales.

4. ImageTake: Que puede captar los datos provenientes de la cámara fotográfica del Raspi.

5. ImageRotate: Hace girar la foto alrededor del centro de la foto.

6. Ahora no encuentro el nombre de la sentencia, pero también existe una sentencia para hacer girar la foto alrededor de un punto cualquiera a definir.

7. Finalmente existe la posibilidad de manipular imágenes con todas las funciones imaginables e inimaginables usados por aquellos dedicados a trabajar en gráficas.

Se que había la forma de usar las funciones de Mathematica y el lenguaje Wolfram desde el lenguaje de programación Python!

Sigo reportando mis avances!

[Hellmut1956]

Desafortunadamente estar vigilando que no aparezcan promociones de los productos de algún proveedor es algo importante para mantener la credibilidad de un foro! Ahora el porque de mi foco en las herramientas de este proveedor, cosa que creía ya haber aclarado. Existen mínimo 4 candidatos de herramientas del tipo que necesito. Son de los proveedores Maple, Mathworks, Dassault con su producto Dymola y Wolfram, fuera de las herramientas que ofrece la misma institución que fomenta y desarrolla el lenguaje "Modelica"! maple es muy bueno y apoya lo que he decidido va a ser y es mi estrategia, pero prohibitivamente caro para la herramienta Maplesim, pero ahora tambien ofrece una licencia para uso no comercial de maple, que sería la equivalencia con Mathematica. Mathworks finalmente con sus productos Matlab, Simulink y un muy alto número de módulos ofreció su producto no comercial cuando ya había invertido en la licencia de Mathematica. Pero el lenguaje "Modelica" modela usando objetos acausales, donde la dirección y así lo que es "Input" y "Output" es implementado a la hora de compilar y de forma invisible para el usuario. eso permite reusar los objetos que se van desarrollando. Un buen ejemplo para comparar objetos causales, donde la dirección es imperativa a la hora de diseñar un modelo es un motor eléctrico:

Si le aplico la tensión a un motor DC aparee en la salida un torque físico. Si ahora uso ese mismo motor como generador, entonces como "Input" hay un "toque" físico que genera una "tensión" a la salida. la implementación de ambos casos en un lenguaje de modelación causal resulta en 2 modelos totalmente diferentes. En objetos acausales como los ofrece Modelica el modelo del motor DC queda siendo el mismo en ambos casos. Existen vídeos por ejemplo en el sitio de Maple donde se da el ejemplo que menciono.

Pero volvamos al tema de mi proyecto del diseño de mi sistema de control de escotas para el modelo de mi velero:

Quiero aplicar la técnica de diseño por modelación para diseñar una implementación de mi sistema eficiente y que entonces entenderé en un alto grado. De allí las herramientas en forma de los 2 productos de software que menciono se vuelven tal una herramienta de electrónica como lo es un soldador.

Ahora una componente esencial en el diseño de modelos es la verificación de los modelos comparando los resultados de la simulación de un modelo con los datos que se ganan de experimentos físicos. Los aspectos se pueden expresar usando 2 términos. HiL y SiL, o "Hardware-in-the-Loop" y "Software-in-the-Loop". No los explico ahora si no recibo la pregunta! Pero es de allí que mis experimentos físicos con el motor de paso y el sensor magnético angular, actor y sensor, son controlados y monitoreados por placas con controladores. Ya he presentado varias veces el diagrama de bloques de mi sistema de control de escotas y para no aburrirlos mas de la cuenta no lo repito aquí.
Para poder usar las placas y las herramientas de Wolfram tengo que aprender e investigar un cierto número de temas:

SystemModeler se comunica con hardware externa usando el protocola firmata. Cuando hacía mis estudios de como meterme en esta materia SystemModeler y la placa Teensy 3.1, un ARM Cortex M4 de Freescale si no mal recuerdo era el entorno en el cual se podía estudiar como eso se efectúa allí para aprender como puedo lograr comunicarme con las placas LPCXpresso1769 de NXP que utilizo.

Mathematica y el lenguaje de programación Wolfram Language son disponibles de forma gratuita como parte de la instalación de la distribución de Linux llamada Raspbian, nombre que combina Raspi y Debian! De allí mi decisión de adquirir la placa RaspBerry Pi B+ y posteriormente también la placa RaspBerry Pi 2B.

A razón de esto resultó que tenía que adquirir conocimientos de Linux y de la placa Raspi. En Raspi la lengua de programación mejor apoyada es Python que existe en las versiones 2.X y 3.x. de allí me embarqué en sendos cursos MOOC disponibles de forma gratuita de universidades gringas.

Finalmente estudiando Python para el Raspi para mi resultó evidente que sería un ejercicio que me gusta hacer el generar una GUI usando tkinter. Así se cierra el círculo de lo que presenté en mi última contribución, donde resultó que en la versión 3 de Python los elementos usuales para hacer girar una imagen no están disponibles en todas sus variantes. Investigando este tema fue donde realicé que mi herramienta Mathematica efectivamente ofrece las funcionalidades de forma súper sofisticadas. Como las interacciones con la software Mathematica con mi hardware son uno de los objetivos, así usando Mathematica para girar imagenes de fotos al mismo tiempo me permite empezar a familiarizarme con el tema de las interacciones de mis placas con la software Mathematica.

Ojalá comparten mi posición que no estoy promocionando los productos de un proveedor. Ojalá he podido explicar el porqué estas herramientas obligadamente tienen que ser parte de mi reporte en este hilo y de porque todos estos temas informáticos si son una parte de los trabajos electrónicos y así parte del tema de este foro y de allí concluyo mi justificación de mencionar y tratar estos productos en el contexto de mi reporte en este hilo!

[Hellmut1956]

Aquí las images tomadas de mi pantalla e utilizando Mathematica.

Primero importo la imagen con la sentencia:

data4 = Import["C:\\Users\\Hellmut Kohlsdorf\\Pictures\\foto Carina con Velas.jpg"]

El resultado en la foto:



La próxima foto muestra esta girada por 10 grados:



Existen además opciones para la sentencia del lenguaje "Wolfram Language" con el atributo "crop" se puede borrar el fondo por ejemplo dejando solo la imagen girada.

Así ya he podido verificar que el lenguaje disponible en la placa raspi con la software gratuita "Wolfram Language" tener la funcionalidad sin crear los "huecos"! Claro, tengo que poner el esfuerzo de aprender eso del "crop". Pero me he decidido por hacerlo en el entorno de la placa Raspi cuando haya echo los trabajos para poner mi entorno. Pero si por ejemplo en el caso de la brújula consideran que la parte del centro que gira es circular ya esos bordes no ocurren, al menos eso pienso que lo podré lograr.

Ya me empiezan a ocurrir usos de esto! Imagínense si monto una placa raspi con una pantalla en mi emisora de R/C, claro protegido de la intemperie, entonces podría ser posible ver la imagen de la brújula actualizada por los datos recibidos por ejemplo por WiFi desde el modelo mientras este navega!

[Hellmut1956]

Me encontré con otro reto, cosa que tiene como efecto lateral, me mas aún me meto en lo de Linux y en ciertos detalles de la hardware!

Mi configuración de la hardware es la placa Raspberry Pi B+, una microSD de 8 GB y un disco duro de 1 TB conectado al Raspi por USB.

El problema resulta cuando quiero expandir la partición de datos, ahora en el disco duro. Se suma a ello que quiero hacer esto con la versión actual de Raspbian, la versión Jessi.

No tuve problemas al instalar en el pasado la versión Wheezy del Raspbian 100% en un microSd de 32 GB. Efectivamente el programa de configuración, raspi-config, ofrece esta funcionalidad expandiendo la partition de datos, por lo general la partición 2 para usar el total restante de la microSD.

Tampoco tuve problemas copiando la imagen de Raspbian Jessie al disco duro formateado con FAT32. Luego hay que copiar ciertos archivos a la boot partition de la microSD y modificar el texto en un archivo para registrar que el Raspbian encuentra el resto de los datos en el HDD conectado al USB. La rutina de inicialización del Raspi exige encontrar ciertos archivos en la boot partition de la microSD. Después recibe la información para seguir la inicialización del Raspbian con los datos que encuentra en un archivo que se tiene que copiar del HDD a la boot partición de la microSD. Como modifique la dirección todo funciona perfecto.

Mi Raspi con la versión del Raspbian Jessie es iniciado y aparece la nueva GUI, bastante mas sofisticada que la de la versión Wheezy! El problema ocurrió al querer expandir la partición de datos para incluir el resto del disco duro de 1 TB! Para hacer esto, lo que no funciona con la rutina que se utiliza para la microSD, en el Internet y en 2 libros que tengo se encuentra la forma de hacerlo. El problema es que tanto mis libros, como en el Internet no se encuentran tutoriales para expandir la partición de datos usando el Raspbian Jessie! Lo que me pasó, es que mi Raspi es inicializado y cuando debería aparecer la GUI en la pantalla, esta queda en negro y solo en la esquina superior izquierda de la pantalla aparece la imagen del cursor bölinqueando de forma irregular.

Mis investigaciones me llevaron a descubrir que existen 2 tipos de tablas de partición. La antigua "MBR" para la cual se utilizan ciertas sentencias y la mas moderna llamada "GUID". Ambas tablas son definidas por Microsoft y la GUID entre otras permite usar discos duros mas grandes. Las preguntas ante las cuales me encuentro son:

1. Como reconozco si la partición en un disco duro es MBR o GUID? Ya he encontrado que tambien en la versión GUID existe una tabla MBR especial que tiene como objetivo permitir entornos viejos adaptarse al uso de la tabla GUID. También he encontrado informaciones de como poder identificar la tabla conectando el disco pre-formateado al ordenador con Windows.

2. Si una MBR o una GUID es usada, esto lo determina el sistema operacional o esta definido por el formateado del disco duro?

3. El listado de como expandir la partición de datos en el disco duro o flash stick es adecuado cambiando las sentencias como por ejemplo "fdisk" or "gdisk" y de la misma forma las otras?

4. Alguien ya tiene experiencia en este campo?

Un cordial saludo

[Hellmut1956]

Sigo reportando de mis investigaciones. Desafortunadamente mi salud los últimos días a impactado tanto mi habilidad de investigar y estudiar como el experimentar las cosas que voy descubriendo. Como siempre una situación como esta resulta en mi deseo de estudiar mas a fondo nuevos campos de conocimientos. Así ahora voy por aquí:

1. El desarrollo de las tablas de particiones por un lado resulta por la limitación que resulta de solo tener 32 bits para poner la dirección de un bloque en el medio de almacenamiento que da la bien sabida limitación de 2 TB para el tamaño del medio de almacenamiento de datos, sea una SD o microSD, sea un stick de memoria USB o sea un disco duro.

Las tablas de partición según el concepto MBR, "Master Boot Record", es el sistema que data desde los tiempos del DOS.
Las tablas de particiones GPT, "GUID Partition Tables", "Global Unique Identifier" fue adoptado primero por Apple en sus productos en 2005 y el PC dio ese paso en otoño del 2012 con Windows 8. Sin embargo también hay PCs mas antiguos que eran GPT compatibles. Para capacitar la compatibilidad con sistemas que se esperan una tabla de particiones MBR la tabla GPT empieza conteniendo los datos de partición de acuerdo al sistema MBR. Junto con ese cambio tambien se hizo la migración de los BIOS tradicionales al sistema nuevo llamado EFI. Así las tablas de particiones GPT pueden ser utilizada en sistemas con un BIOS tradicional. EFI esta para "Extensible Firmware Interface" y UEFI para "Unified Extensible Firmware Interface".

Esto según lo entiendo es de importancia, a pesar que el objetivo es usar Raspbian Jessie en la placa Raspi, porque para inicializar las memorias del Raspi se necesita otro ordenador, preferiblemente Windows. Mi ordenador ya es bastante viejo, tiene un BIOS del 2009, pero aparentemente es capaz de reconocer y usar discos duros con tabla de particiones GPT.

Otro aspecto que he estado aprendiendo se refiere al formato de formación del disco duro. El formato nativo de Linux aparentemente se llama ext4, pero requiere de un sector con formato FAT32. Si se forma la partición del disco duro y se desea que se pueda tener acceso a ella desde Windows lo normal es formatear esa partición 2, la partición de datos también usando FAT32.

El formato "ext4" de Linux, similar a las propiedades del formato NTFS, permite grabar datos adicionales que capacitan al sistema operacional una mayor seguridad del medio, fuera de lo de los límites de tamaño. He encontrado referencia que es posible capacitar Linux y Raspbian en especial aquí, para también poder utilizar particiones formateadas con NTFS.

Estas informaciones y mi estudio a largo trecho de ser completado de forma inicial de mis libros sobre Linux y el Raspi me están haciendo reflexionar sobre como sería la configuración de particiones y de su formato mas sofisticada y en consecuencia útil para mí. Recuerden que mi disco duro tiene 1 TB de capacidad y que el tamaño de la partición de boot en ese disco duro es de unos 100 a 200 MB.

No sería sensato formatear la partición de datos en ese disco usando "ext4" como formato nativo de Linux, tener una partición formateada en "NTFS" para poder intercambiar datos con el PC bajo Windows?

Otro idea que se está cristalizando en mi mente es la de hacer la instalación del Raspbian Jessie para la Raspi con varios pasos intermedios, pudiendo así verificar que he comprendido y puedo aplicar los conocimientos sobre Linux? La idea sería empezar instalando el Raspbian Jessie exclusivamente en mi microSD de 32 GB. Luego desde el entorno del Raspbian en la placa Raspi crear las particiones y formatear estas de acuerdo a las ideas que presenté arriba usando por ejemplo Firefox o Chromium como web browser para bajar del Internet las herramientas requeridas. Me parece que el entorno de Raspbian me permitiría usar las reconocidas capacidades de las herramientas disponibles allí.

Lo que tendría que analizar adicionalmente es el impacto que esto tendría en usar la IDE de WingWare, Wing, para programar y hacer los "debug" desde el entorno del PC.

[Hellmut1956]

Me encuentro en el proceso de aprender como logro el objetivo que me he puesto y que presento ahora aquí:

Quiero desarrollar los programas para el Raspi en el PC y de ejecutar y "debug", búsqueda de errores y su corrección , usando una IDE en el ordenador. 2 IDEs se encuentran actualmente en el PC mio y los estoy estudiando:

1. Wing de Wingware
2. PyCharm de Jetbrains

Empecé usando Wing no mas familiarizándome con al herramienta y ahora lo interrumpí para estudiar PyCharm con la versión profesional en tiempo de 30 días disponible. La razón para esto es por un lado que para realmente entender el de como ejecutar programas escritos en Python 3 en un editor, parte de la IDE en el ordenador, dejando la ejecución del programa Python ser hecho por el interpretador Python en la Raspi. PyCharm hace esto realmente ejecutando el programa no en el PC, sino realmente con el interpretador de la Raspi en la Raspi. Para ello, al iniciar un proyecto se define que el interpretador a usar es el que se escoge libremente, sea en el PC, máquina local, o remoto. Allí se define en mi caso que quiero usar el interpretador en la Raspi. Para ello es necesario establecer el enlace entre la IDE PyCharm en el PC con el interpretador en la Raspi. El medio a usar es "ssh" y "SCP". Me varé estos últimos 2 días por falta de conocimiento tanto de "ssh", como del uso de "llaves" privada y pública.

Así por un lado me puse a estudiar la literatura que tengo tanto sobre Raspi Raspbian y sobre Linux. Durante estas investigaciones aprendí que una vez que la Raspi sea accesible desde el Internet hay que dedicar esfuerzo para evitar abrir puertas a ataques desde el exterior y que pudieran utilizar esto para acceder nuestra red en la casa y sus PCs!

Pues bien, actualmente he aprendido como, de forma relativamente sencilla se generan las llaves privadas y públicas en el Raspi bajo el os Raspbian. Por otro lado acabo de descubrir para mi el como crear las llaves en el PC y de ponerlas en un lugar definido por mi.

El paso que tomaré después de lograr que la IDE PyCharm en el PC pueda ser configurada a usar el interpretador Python 3.4 del Raspi, dedicaré mis estudios a entender como hacer que la comunicación tengan lugar dentro de un "túnel" "VNC", Virtual Network Computing", conexión virtual de redes. Me explico. existe en el Internet la posibilidad de conectar 2 o más PCs y/o redes de PCs como si estos estuvieran físicamente en el mismo cuarto, creando un túnel VNC entre las redes o PCs y que las comunicaciones tengan lugar atravesando ese túnel estando así protegidas de ataques.

Sigo ahora primero estudiando como se reparten las llaves, privada y pública entre la Raspi y mi PC con Windows 7 Ultimate. Luego ya entendiendo esto seguiré con mis intentos de relacionar la IDE de PyCharm al interpretador del raspi! Aquellos de Ustedes que ya saben de esto, perdonen por presentar lo obvio. Pero es que yo no sé eso y me puedo imaginar que alguno de mis lectores de este hilo son tan sabios como yo!

Una vez que haya entendido esto lo presentaré aquí con fotos. Pero es que hay gran trecho entre "lograr" un objetivo como el aquí presentado y el "entenderlo tan bien" que yo pueda presentarlo aquí!

[Hellmut1956]

Vuelto a tener que enfrentarme a problemas o asuntos aún no entendidos! Resulta que de pronto mi WiFi del Raspi dejo de funcionar. Como si fuera poco en los trabajos relacionados a los objetivos mencionados en mi contribución anterior me encontré que mi Raspi seguía usando la microSD como base del Raspbian y no como había pensado el disco duro USB! Así entre estudiar e investigar los asuntos de pronto mi Raspi dejo de reconocer el disco duro USB, a pesar que estaba utilizando una microSD que generé completamente nueva y usando el Raspbian Jessie! No fue de sorprenderse que al intentar arrancar mi Raspi usando la microSD conteniendo bajo "/" el contenido del directorio de "boot" del disco duro USB al que pasé la imagen del Raspbian Jessie y habiendo cambiado la referencia de "root=..." a "root=/dev/sda2" en el archivo "cmdline.txt"!

Bueno, me sentía en un estado de salud aceptable y me metí de forma metódica a estudiar el asunto entre la lectura de mis libros sobre "Linux", "RaspBerry PI", "Computer-Networks" y "Referencia de comandos de Linux". Adicionalmente investigaba en el Internet!

Resulta que parte del reto consiste en saber como o que preguntar en "google"! Para eso hay que avanzar tanto en la materia como en la terminología!

Pues bien, finalmente pude averiguar que en Linux existe la posibilidad motivada para economizar el consumo de energía, que Linux desactive el Wifi! Eso no me paso con Raspbian Wheezy pero si con el Raspbian Jessie! Lo malo es que a la larga es para mi casi imposible determinar si el responsable soy yo y lo que hice con el Raspi y Linux o si se debe a funcionalidades del Raspbian Jessie! Así me puse a investigar en el Internet sobre este asunto haciendo la pregunta: "How to manually activate Wifi". Me encontré con un sitio que me permitía investigar si el módulo de Wifi había sido reconocido, si los drivers requeridos estaban cargados y una cantidad de información interesante sobre como analizar este tipo de cosas, en que archivos mirar y encontré instrucciones de como reactivar mi Wifi! Desafortunadamente allí mi salud, mi mente se despidió forzándome a descansar e interrumpir estas labores! Mañana seguiré y les promete dar informaciones mas detalladas tanto de las fuentes de información, los archivos y blocks y si y como resolví primero mi problema con el Wifi, luego también lo de porqué de pronto el disco duro no aparece en el listado de la sentencia de Linux: "lsblk".
Si ya puedo compartir otro error, como de costumbre estúpido por mi parte de porqué el Raspi y su Raspbian no funcionaban. reporte incompleto por ser acción en vivo!
Me deje influenciar de las posibilidades de la herramienta "Mini Tools Partition Wizard"! Así me descuidé de hacerme consciente que el Win32DiskImager encargado de grabar la imagen del Raspbian en el disco duro USB no copia de forma normal el archivo del raspbian al disco o microSD, sinó que copia bloque por bloque el contenido del archivo Raspbian.img a los bloques correspondientes del microSD o disco Duro USB! Claro que entonces mi placa Raspi al iniciarse ejecutando las instrucciones del archivo "cmdline.txt" y los otros archivos del directorio "boot" no era capaz de montar el árbol de archivos del SDA2 y por lo tanto se colgaba! Cuando finalmente reconocí ese mi error, es cuando me encontré que de pronto la sentencia "lsblk" ya no veía el disco duro sda y por lo tanto se varaba!
Ojalá no los aburran esta descripción! Pero egoístamente confieso que leyendo contribuciones mías en algunos temas hace ya muchos años gozo recordando esos vaivenes, por lo que sigo documentándolos también para mi!

[Hellmut1956]

Hola amigos, quiero informarles que estoy progresando a buen paso, aunque mas lento de lo que me esperaba! Lo que me frena de compartir con Ustedes mis avances es mi dificultad en presentar un punto de vista de estos trabajos y estudios que me parezca adecuado para el tema del modelismo naval de este foro. ya he explicado antes, que progresando como lo estoy haciendo por una década en mi Proyecto del modelo del velero Carina y en paralelo a ello mis trabajos en mi taller muchos tópicos están muy relacionados a temas alrededor de la programación. Me refiero con esto de forma muy general a temas que usualmente tienen su auditorio en foros informáticos. Otro conglomerado de temas se dedica a la electrónica, al tema de armar circuitos y entornos de experimentación. Este área es mas fácil de presentar en el entorno de este hilo dedicado a mi taller. Y adicionalmente por no atreverme a escribir finalmente están los temas alrededor de las herramientas que se requieren.

Cada uno de estos áreas en el contexto de mi proyecto del Carina presenta un gran número proyectos parciales en el conjunto de proyectos del Carina y las posibilidades que se abren en mi propósito dedicado al modelismo naval son para mi fascinantes y me permiten reflexionar sobre estas posibilidades y de como aplicarlas a mi proyecto de modelismo naval. Si les presento todo esto justificadamente me podrían criticar. Así me he decido desde algún tiempo compartir parte de estos temas en foros mas adecuados como el forosdeelelectronica.com y en foros dedicados mas al tema de la informática. Sin embargo mi motivación para seguir con estos numerosos estudios y los largos tiempos de estudio y experimentación es el de aplicar esto a mi proyecto de modelismo naval.

Permítanme compartir con Ustedes que los temas que toco en el contexto de mis proyectos estos se benefician muchísimo de los rasantes avances de tecnología, por lo que mi lento paso en estas actividades se beneficia de ello. Pero finalmente ahora mis trabajos del taller, lejos aún de ser completados, han avanzado al punto que hoy mi taller ya brinda la plataforma donde puedo trabajar y experimentar. Hoy no mas he vuelto a hacer una compra por Internet de accesorios para mi laboratorio electrónico que ya tienen como objetivo el establecer el entorno concreto de experimentos!



Esta foto muestra una vista sobre la mesa de trabajo de mi laboratorio y que habiéndolo alcanzado me capacitaba para avanzar en trabajos concretos relacionados a los experimentos que tengo planeados para investigar mi sistema de control de escotas.



Esta foto muestra una vista sobre el escritorio de oficina dentro de mi taller. Aunque el caos continúa reinándo en mi taller estas 2 fotos muestran como ya he logrado un cierto orden en ciertas áreas de mi taller. Igualmente las superficies de mis 2 bancos de trabajo ya empiezan a deslumbrar debajo de la multitud de cosas aún no organizadas.

Mi intención actual es controlar mis experimentos y las placas de controladores desde mi PC que "solo" tiene 2 pantallas, ahora una tercera ya me sería útil pero fuera de mis posibilidades económicas! Trato de explicarlo en conjunto con al menos la próxima foto:



Esta foto muestra como estoy trabajando en definir e implementar módulos que me permitan combinando estos módulos ir armando los diversos entornos requeridos para mis primeros experimentos!

A la derecha aparece el módulo con el tal llamado "protoboard" que permite establecer circuitos sin la necesidad de crear placas implementando las pistas usando cables como el que ven sobre el protoboard. las 2 placas que ven insertadas en el protoboard son placas que me permiten tener acceso a los 40 pines de mis 2 placas "RaspBerry Pi"! Compré 2 porque cuando compré las mas avanzada entonces, la RaspBerry Pi B+, al poco tiempo salió la placa "RaspBerry Pi 2B". Debido al bajo costo de estas placas pude encontrar los fondos para la compra de la segunda en corto Raspi2. En la primera foto de esta configuración solo había una raspi , en esta foto 2. El cable enchufado a la izquierda de la placa a la derecha es la que conecta la pantalla por HDMI al raspi!

Como todos tenemos sufridas experiencias en nuestros PCs, cuando sale una nueva versión de Windows resultan problemas a resolver antes de poder seguir donde ya se estaba. Pues bien, las raspi, al igual que los PCs usa un sistema operacional. No es Windows, sino una variante, se denomina "distribución" de Linux y se llama Raspbian, combinando Raspi y Debian en su nombre para indicar que es para el uso con las raspi. Pues bien, la versión con que arranque se llamaba "Wheezy" y la nueva se llama "Jessie"! debido al rasante paso de los avances tecnológicos en los campos donde se usa las Raspi es justificable el usar la versión mas moderna. El problemita con el que me encontré fue que de pronto la placa Raspi no activaba la interfaz "WiFi"" WiFi, la conexión inalámbrica a la red de mi casa es la forma moderna de comunicación entre placas electrónicas cuando cables de LAN u otros eran la única opción disponible anteriormente. Reflexionen el impacto que esto tiene en nuestra afición! Si puedo establecer comunicación inalámbrica entre mis placas y mi PC, no sería posible lo mismo con un teléfono y una tableta? No sería posible como lo es con las tabletas y teléfonos tener las opciones de mantener la comunicación con una placa por telefonía de datos, WiFi instalada en nuestros modelos? Pero volviendo:

Cada una de las 2 placas raspi de mi entorno viene con su propia dirección "IP", algo como 168.0.0.20. Pues he aprendido como modificar las iniciaciones de mis placas raspi con el so Jessie para asegurar que la conexión Wifi sea activada! No es difícil, solo hay que saber como y donde. No creo que presentar esto sea lugar adecuado este hilo! Las placas raspi reciben la alimentación eléctrica usando un enchufe del tipo micro-USB, tipo B. Es usado exclusivamente para alimentar la placa raspi, no para intercambio de datos. Para ello mis placas vienen con 4 interfaces USB. Por lo general lo razonable es usar un enchufe de alimentación eléctrica que de 5 VDC y hasta 2 A. he empezado mis estudios de la placa raspi usando uno así. Pero la foto muestra que sin organizar de forma adecuada los muchos cables resultan en un entorno de experimentos caótico y por lo tanto propenso a cometer errores que pueden dañar las placas y circuitos. He puesto de forma provisional y investigativa otras placas con controladores que serán usados en mis experimentos. A la izquierda arriba esta el kit de evaluación moderno que reemplaza la placa "stepRocker" que usé en mi tutorial avanzado sobre motores de paso. De las 3 placas que consiste el kit la de arriba en esta foto es la placa con la componente controladora de los motores de paso de la empresa Trinamic. Tiene el tamaño casi igual que la vieja placa stepRocker o la intermedia que usé, motionCookie. La inferior es la placa con el controlador ARM Cortex M4 de la antigua Freescale, hoy parte de NXP! La placa en el medio pasa todas las pistas entre el controlador ARM y el Trinamic haciendo posible así tener acceso a todas estas pistas. Cada pista es accesible por 2 pines hembra, similares a aquellas de la protoboard.

A la derecha del kit puse arriba una placa de la segunda versión de las placas LPCXpresso, en este caso uso la placa LPCXpresso que me regalaron hace un año en la feria en Nuremberg. debajo ven 2 placas que en conjunto representan la primera versión de la placas LPCXpresso, aquí la LPCXpresso1769 que quiero utilizar en mi modelo! La placa arriba de las 2 con interfaz USB es el tal llamado "Link" que permite que el entorno integrado de programación de las LPCXpresso, en corto IDE, se comunique con la placa usando la interfaz "JTAG" que permite de forma muy potente programar e identificar errores, el tal llamado "debug", mientras que son ejecutados, no en un simulador como es el caso en IDEs mas antiguas y menos potentes. Yo he separado las 2 partes logrando así "ver" el tamaño real de la placa que será usada en el modelo Carina. la versión 2 arriba, como se puede ver es mas grande, pero al igual quel las placas de kit de Trinamic es mas útil en la fase de diseño y experimentación por permitir el acceso a todos los pines.

Actualmente estoy llegando a la conclusión que el combinar las placas LPCXpresso y las raspi en un módulo como el aquí mostrado es mejor solución. El kit en combinación con otro kit que tengo para el sensor magnético angular los combinaré en otro módulo! Conexiones físicas entre estas placas tendrá lugar en el protoboard en lo posible!

Aquí llego a presentar otro aspecto que requiere saber lo anteriormente escrito hoy y tener en mente el gráfico de bloques que de forma muy abstracta muestra de que componentes mi sistema de control de escotas se compone.

En vez de la pantalla que tengo conectada al raspi en la derecha de la foto con el cable HDMI, es el cable debajo del cable de alimentación eléctrica por el enchufe micro-USB-B usaré la comunicación Wifi desde el PC tanto para presentar en una ventano del entorno Windows de mi PC. Tendré una ventana para cada una de las 2 placas Raspi. Igualmente no tendré que conectar mi teclado y ratón a las placas Raspi, pues teclado y ratón del PC cumplirán estas funciones dentro de las ventanas en el entorno del PC.

El resultado de esto será, como lo vemos en la segunda placa raspi a la izquierda. esa cosita color latón y negra que ven insertada en el conector USB inferior a la izquierda del raspi es el módulo WiFi que conecta la Raspi a mi red local. Queda por solucionar el asunto de las alimentaciones eléctricas del entorno experimental! El conectar una fuente por un cable a un raspi es inevitable. El usar una fuente individual que me obliga a sacar del enchufe la fuente para desconectar y apagar la placa raspi por lado hace que la mecánica de los enchufes sufra, hay que tener 2 fuentes, uno para cada rasp mas fuentes adicionales requeridas en el entorno experimental!



Empecé comprando enchufes hembra micro-USB-B como el que ven en la foto. Tuve algunos problemas en encontrar en el Internet a cuales de los pines del lado donde va el cable debo conectar los polos positivo y negativo. Resulta que de los pines machos, son 5 en 2 niveles, 2 y 3 los 2 externos de los 3 son los correctos. Al momento todavía ando indeciso de donde y como conectar los cables de alimentación eléctrica. Por un lado, las raspi requieren ser alimentadas con 5 VDC, pero los pines de la placa no resisten 5 VDC, solo 3.3 V! Las placas LPCXpresso tambien requieren de 3.3 VDC. De allí resulta que circuitos que armo usando estas placas requieren de 5 VDc y de 3.3 VDC pero si confundo las fuentes me daño las componentes. la famosa y tenebra ley de "Murphy" dice que un evento es mas probable cuando mas sea el daño que ocasione y que daños siempre ocurren en partes para las que no se tienen repuestos, o sean mas difíciles de conseguir o cuesten mas!

De allí resulta que tengo que definir una solución que reduzca la posibilidad de cometer errores, que evite el caos de cableado que muy pronto ocurre. Imagínense no mas el módulo con las placas que mostré arriba. Cada una conectada a su fuente de alimentación eléctrica, cableado de implementar un circuito y demás. Eso acaba siendo un caos tal que la probabilidad de errores aumenta.

Completo mi reporte de hoy presentando las 2 herramientas que tengo disponible para monitorear, decodificar y analizar los datos que fluirán por los circuitos de un entorno experimental.



Analog Discovery es una herramienta que me compré para los experimentos en conjunto con el curso de electrónica análoga. esta herramienta multifuncional tambien ofrece entre muchas otras funcionalidades la de analizador lógico. La segunda herramienta que tengo como analizador lógico es la "Open Bench Electronic Sniffer":







Cada uno de estos analizadores lógicos ofrece la función de poder grabar el flujo de señales digitales de hasta 16 pistas y además es capaz de decodificar los protocolos de de buses de comunicación como del RS232, del I2C, del ISP y muchos otros, permitiendo así ver de forma legible por humanos los datos transportados usando esos protocolos. Así puedo por ejemplo analizar que comunicaciones tienen lugar entre el controlador y la componente de control de motores de paso, al igual que del flujo de datos dentro de un entorno de mis experimentos.

Esto es de gran ayuda para encontrar las causas de posibles malfunciones y de corregirlas, al igual de entender como ciertas funciones son implementadas, para así poder replicarlas. Paro aquí por hoy para decirles que apenas me lleguen las partes compradas en el Internet hoy me lleguen e implemente por ejemplo la alimentación eléctrica de mis entornos experimentales.

Releyendo mi contribución de hoy veo confirmada mi justificación de limitar mi apoyo a aquellos que quieren hacer el curso de la tarjeta experimental a resolver sus dudas y problemas, pero de no querer dedicarme a ofrecer soluciones que pudieran ser utilizadas directamente en nuestros modelos. Ayudo para aprender y así poder hacer las cosas uno mismo, pero no para replicar la milésima solución de alguna función ya disponible en el Internet. En esta década desde que fui atacado de forma personal y ofensiva por ciertos sujetos del foro español de modelismo naval a hoy veo mi justificación de querer seguir aprendiendo y no de replicar cosas. Les aseguro que al empezar el proyecto de modelismo naval hace década y media ni de cerca me pudiera haber imaginado con que cosas me ocupo hoy! Y para volver a repetir de lo que estoy absolutamente cierto! por la forma como investigo, experimento y me dedico a nuestra afición siempre quedaré siendo un aprendiz y como tal ni de lejos me considero superior u otros modelistas navales como inferiores! Mi respeto y admiración vale tanto para las personas y los trabajos de los verdaderos maestros y expertos, como también para modelistas como este joven cuya foto su padre me ha permitido usar:



Así es como nacen los futuros modelistas navales y como la juventud puede aprender a dedicarse a una afición sana que le enseña perseverancia y dedicación! Este muchacho, ya han pasado casi 5 años y medio orgullosamente me presento su modelo construido usando cajetillas de cigarrillos!

[Hellmut1956]

Hola amigos. Con mi usual práctica de ser "exagerado" de como hago las cosas, ahora me he dedicado a reformar aquella parte de mi laboratorio electrónico dedicado a proveerme de las diversas tensiones que requiero para mis experimentos.



Todo parte del listón de tensiones que hice para mi laboratorio. Resulta que usando cables con enchufes de banana la mesa del laboratorio queda cubierta de una red de cables. Por un lado esto es algo que visualmente no quiero (efecto lateral de mis esfuerzos de poner orden en mi taller), por otro lado esto fomenta la probabilidad de conexiones equivocadas lo que acaba dañando placas y componentes. Se suma a esto que para las placas requiero de enchufes microUSB. Tengo una fuente de 2 A, 5 VDC para alimentar las placas RaspBerry Pi y como tengo 2 o tendría que comprar otra igual. Para los circuitos controlados por las Raspi requiero 3.3 VDC y para el motor de paso por ejemplo 24 VDC o alimentando desde mis baterías 40 VDC. Ademas dependiendo de donde sobre la mesa de trabajo pongo las placas y los circuitos o uso cables del máximo largo requerido, lo que aumenta el caos sobre la mesa o requiero de cables de diferentes largos!



Por eso me armé hace algún tiempo un módulo que aparece en esta foto. Aquí ya le agregue la posibilidad de usar hasta 4 tensiones diferentes y gracias a los interruptores la posibilidad de "apagar" las 4 tensiones de forma independiente. Ademas tengo 5 tomas para cada una de las 4 tensiones y que también pueden ser apagadas con ese interruptor. A la izquierda de este módulo tengo la posibilidad de conectar cargadores de batería que vienen con esas "pinzas" para conectas a baterías de plomo. Uso 2 tornillos M10.



En esta foto se ve a la izquierda debajo de la pantalla como atornillé el módulo anterior a la pared lateral izquierda quedando así las tomas para atornillar cables sobre el lado superior del módulo y así despejando un poco la mesa de trabajo. Cuán simpática me resultó esa solución ahora mostró sus deficiencias! Tengo que usar cables con enchufes macho banana en ambos cabos para definir que tensión conecto a las 4 tomas independientes. Así esto se suma a la "red de cables sobre mi mesa de trabajo! El otro aspecto que resulto limitante es que si quiero, por ejemplo solo alimentar una de las placas Raspi en el módulo de placas con controlador que mostré en mi aportación anterior, que requiero de cables con enchufe microUSB en un cabo y almas al descubierto para atornillar a las tomas.



Aquí pueden ver el módulo que reemplazará aquel que aparece en una foto anterior con solo 4 tomas. El nuevo móduölo tiene 8 tomas con enchufes hembra banana con sus sendos interruptores!



Pero yo no sería yo si no me lo hago complicado! Pero mucho tiempo reflexionando y experimentando con diversas configuraciones y pidiendo a mi hija ir a la tienda de Conrad y comprar componentes esto ha sumado a demorar las cosas. La razón es que recién experimentando configuraciones diferentes se me hacía claro que otro tipo de componente requiero y cuantas!

Empecé usando una placa de color negro que tenía de hace décadas y cortandola en 2 tenia la superficie del "panel". Luego hice los huecos para los enchufes banana hembra y para los interruptores que en la segunda foto pueden ver el lado inferior del panel. la otra cosa que traté de encontrarle solución es dar un color independiente para cada una de las 7 tensiones que aplicaré al panel y que podré controlar con el. No existe tal número de colores diferentes para los bujes y los enchufes banana y de sus cables. Así pienso usar pintura "Revell" para colorear aquellos bujes que resultarían dobles.

La vista del panel de abajo revierte el orden, arriba en esta foto corresponde abajo en la foto del panel visto de enfrente. Aquí pueden ver como usé un tipo de "conector" macho en ambos bujes a la derecha. El enchufe color "platón" es el tipo de enchufe que tendrán los cables que vienen de la fuente de alimentación eléctrica de PC modificada. Tengo que hacer las tomas para la alimentación del panel allí, pues no me es posible, sin desarmar todo mi laboratorio electrónico, conectar cables a las tensiones. Esas conexiones por cable, solo el polo positivo en las tensiones positivas (40 VDC, 24 VDC, 12 VDC, 5 VDC y 3.3 VDC), en las tensiones negativas (-12 VDC, -5 VDC) el polo negativo. La tierra (0 VDC) sigue siendo la misma de la tierra o polos negativos de las tensiones positivas! Así cada uno de los bujes en la segunda foto arriba, estará conectado fijamente y los cables los llevo de forma oculta. De allí resulta que los bujes de abajo, la primera foto, siempre estarán conectados y activos mientras tenga mi fuente de alimentación de PC modificada activa.

Pero armando tentativamente los conectores a los bujes noté que el uso del dispositivo requiere de 2 conectores machos y no solo de uno cual lo muestra la foto! la razón es muy sencilla. Tengo que conectar la tensión aplicada al buje a una de los conectores macho del interruptor.



Esta foto muestra 4 tipos diferentes de conectores! El superior a la izquierda es el que aparece usado en la foto, el conector abajo a la derecha es el correspondiente de 2 conectores. Así a una de las conexiones conecto el cable que viene de la alimentación eléctrica, al otro el enchufe del cablecito que unirá el buje y el conector macho que aparece abajo del interruptor.

Pero resulta que requiero del mismo tipo de conector doble para el buje de arriba! Uno lo uso para el segundo cablecito que conecta el buje arriba al interruptor, el segundo conector lo requiero para conector a las 5 tomas atornillables asociadas con el buje y que aparecen como fila de tomas sobre el lado superior del módulo completo. Allí puedo conectar cables atornillándolos. Sigue una foto mostrándolos:



Pasemos a mirar otro vez la primera foto del panel. Pinchando el interruptor al lado de la "raya" conecta el buje inferior al superior así activando la tensión y surtiendo las placas o componentes alimentadas. De allí resulta la segunda razón que requiere la componente de 2 pines machos. Al lado derecho del interruptor pondré una LED. Activando el enchufe pinchando el interruptor la LED con una resistencia soldada en serie entonces tiene un lado sometido a la tensión relacionada al buje, para eso el segundo pin. El otro lado de la LED y la resistencia en serie estará conectada fija a tierra! Así activando el buje pinchando el enchufe una corriente fluirá por sobre la LED y la resistencia en serie haciendo que la LED se encienda y dando así la información visual al usuario, a mi, que la tensión esta activa y es capaz de alimentar circuitos conectados a ella. El hueco en el panel al que pego la LED de tal forma que las conexiones queden ocultas y solo se vea la parte del LED que se ilumina no lo he hecho aún pues quiero estar preparado por si alguna modificación de mi panel resulte que la LED tiene que ser puesta en otro lado.

Así habrá 8 LEDS junto a la derecha de los 8 interruptores que confirmen visualmente el estado de activo o no activo del buje dependiendo del estado del interruptor. Mi señora a la cual le he ido mostrando mi panel me preguntó porque no uso LEDs del color asociado a la toma. Esa idea me parece muy buena, pero LEDs multicolor son bastante mas caras. El definir el color como resultado de diferentes intensidades de los 3 colores básicos, RGB, también requiere usar 2 a 3 resistencias con valores tales que resulte el color deseado.

Reflexionando y releyendo esta aportación me decidí por mirar si en ebay se ofrecían LED RGB y me compre por casi 6 Euros 50 tales LCDs! Haber cuando llegan de la China!

[Hellmut1956]

Hola amigos, finalmente llegaron los primeros 4 tipos de parte que compré en Conrad. He estado pensando en que orden presentar las fotos y las explicaciones. Me he decidido empezar por el final, el estado actual de cosas:









La primera foto muestra el panel con los 2 conectores machos soldados a las bujías. La intención, como le escribí la última vez es poder conectar 2 cables con enchufes hembra. Para poder soldar esos conectores al alma de las bujías taladré un hueco en un madero de tal forma que me sea posible depositar el conector como lo muestra la próxima foto. Me costo varios intentos realmente taladrar a ese punto, me pasaba. Así al soldar el conector primero puse el soldador sobre la punta de la bujía aplicando un poco de estaño al soldador. Así, cuando el estaño se escurre sobre el alma de la bujía esta es lo suficientemente caliente para aceptar el estaño y hacer una conexión eléctrica buena. Cuando el alma de la bujía, siendo grande en comparación al conector no es calentado lo suficiente entonces el estaño queda formando una gota, en el otro caso se escurre limpiamente como se ve en la primera foto creando una conexión eléctrica de buena calidad. El termino para el mal estado es una soldadura fria, al menos traduciendo literalmente!

La otra foto muestra el conector antes de ser soldado!

Me quedaba la impresión de no haber reflexionado totalmente para definir la solución! Las LEDs RGB, capaces de generar cualquier color, no llegarán antes de unas semanas. También las soldaduras usando estaño no son capaces de resistir estrés mecánico como ocurre aplicando y removiendo los conectores hembra que irán conectadas a los 2 conectores macho de cada bujía. Por lo tanto requiero trabajar de tal forma y secuencia que en lo posible no tenga que desconectar los enchufes para no dañar la soldadura! Por otro lado quiero usar el panel antes de que lleguen las LEDs. Pero si conecto los cables que vienen del listón de tensiones, o no puedo volver a poner el panel sobre mi mesa de trabajo para la instalación de las LEDs y quien sabe que otras cosas se me ocurran. Recuerden que esto ya es el panel versión 2!

El problema no es el como implementar soluciones, lo que consume mucho tiempo, al menos así me ocurre a mi, es identificar posibles problemas! Así lo que he decidido es que voy a hacer una caja de distribución en tal punto cercano al módulo del panel que pueda desatornillar los cables que vienen del panel, dejando aquellos que vienen de la fuente atornillados.

También he decidido que le pondré al panel bujes con tierra adicionales para tener disponibles bujes banana por si os requiero. Además voy a poner una LED roja que indique si el panel está siendo alimentado del listón de tensiones. La razón es que quiero economizar el consumo de energía eléctrica solo encendiendo la fuente de PC modificada cuando la necesite. Entonces y solo entonces esa LED roja estará iluminada indicándolo!

[Hellmut1956]

Para autoanimarme aquí mis últimas acciones:



Sigo con mucha falta de auto motivación trabajando en el cableado del panel. En esta foto pueden ver el cable con el cual conecto los 5 enchufes atornillables al buje que está después del interruptor. Es un trabajo muy tedioso pues tengo que ir poniendo el alma del cables al aire, sin el aislamiento, para cada uno de los 5 enchufes. El primero es sencillo, solo dejar libre 1 cm y aplicarle estaño. Para los próximos 4 enchufes requiero 1 cm del cable aislado, luego 2 cm para crear una "punta" de 1 de largo y aplicarle estaño para poder fijarlo en su enchufe y al otro cabo del cable de 25 cm de largo otro trecho de 1 cm de largo con estaño al que aplico el enchufe hembra para conectarlo al buje banana. uso el tipo de enchufe que ofrece un enchufe macho adicional, como el que pueden ver en una foto de mi contribución anterior.

Así no solo tengo la "toma" para conectar la LED RGB, sino adicionalmente la posibilidad de ampliar el panel con bujes banana hembra adicionales.



Esta foto muestra el cable que usaré para los +5 VDC antes de aplicarle el estaño.



Esta foto muestra el cableado completado para los "-12 VDC" y los "-5 VDC". Si miran con exactitud pueden ver los retos. Si miramos con detalle el cable blanco que suministra los "-5 VDC" a los bujes atornillables y conecta con el enchufe "macho" izquierdo se alcanza a ver el enchufe macho que toca el aislamiento color negro del cableado azul a su izquierda. Para evitar cortos accidentales pongo un enchufe hembra y su "capa" aisladora sobre el enchufe, se podría ver mirando con detalle el cableado verde a la derecha. La próxima foto muestra a que me refiero.



Así evito cortos accidentales y cuando quiera expandir mi panel con bujes banana hembra adicionales usaré este puesto para acceder a la tensión.

No había aún mencionado que otro lugar para cortos accidentales está en el punto donde hay 2 enchufes hembra atornillables vecinos de diferentes tensiones! Allí tendré que poner alguna barrera no conductible que haga imposible tal corto. Miren donde los bujes conectados al cable verde avecinan con aquel conectado al cable blanco! Un resultado de reflexiones sobre este tema me ha convencido que debo usar fusibles para proteger mi laboratorio en caso de corto. Un fusible en cada una de las 8 tensiones! Estoy aún reflexionando sobre mis requerimientos para tal fusible! No solo es definir a que amperaje debe interrumpir el flujo de corriente, sino también si debe ser de reacción rápida, mediana o lenta! Ideal sería usar fusibles que pudieran ser reactivados como aquellos usados en el sistema eléctrico de mi casa! Verdad que soy extremo en esto!

[Hellmut1956]

Otro frente de mis actividades:

Hablando del panel y anteriormente sobre el uso de la placa RaspBerry Pi para poder controlar la funcionalidad relativamente sencilla relacionada con el panel y sus LEDs RGB, mencioné que mi falta de conocimientos sobre el sistema operacional de la placa RaspBerry Pi, Linux. Linux es lo equivalente a Windows de Microsoft que conocemos de nuestros ordenadores. Así empecé mis estudios sobre Linux y de como hacer posible hacer los trabajos de desarrollo usando las amplias facultades del ordenador.

Estos estudios y experimentos los interrumpí para construir mi panel. Ahora estoy convencido que dejando estas actividades en el estado que estaban ha abierto una "puerta" para la infiltración ilegal. Después de arrancar mi ordenador y pasar un poco de tiempo de pronto mi ordenador empieza a hacer actividades extrañas que resultan en hacer casi imposible el uso del ordenador. Al cabo de varias horas estas actividades acaban y el ordenador vuelve a estar funcionando normalmente.

Analizando con mucha paciencia por lo lento de la ejecución pude ver que un número enorme de processos relacionados con "conhost.exe" y "reg.exe *32" estaban presentes y todos relacionados con mi persona como usuario! la razón creo que se debe al estado en que deje el "servidor ssh" que uso para establecer la comunicación entre la placa raspi y el ordenador y viceversa. Algo o alguien usa ese camino para inicializar esas actividades, que gracias a los otros mecanismos de protección que tengo en mi ordenador no han tenido mas consecuencias que yo sepa!

Como debido a mis problemas que resultan de mis estado de salud no se como hacer los cambios requeridos, pero si creo que se en que punto debo hacer ciertas actividades. Trataré de hacer esto lo antes posible. El Internet es un entorno hostil!

Pero vuelvo a los objetivos relacionados con mi proyecto del velero Carina. Estudiando ciertos capítulos del libro sobre el Raspi, el otro sobre Linux y el tercero sobre redes me encontré con el término de "Embedded Linux". Debido a los cada vez mas poderosos controladores, ver como ejemplo el SoC, Sistema en el Silicio", usado en las placas Raspi, el BCM2835 en las primeras generaciones, con un solo "core" o controlador en el raspi Zero, con 2 en el raspi B+ y Raspi B2 y 4 en el Raspi B3 y usando cada vez variantes del controlador ARM mas avanzadas, también las estrategias para su uso en aplicaciones embebidas han cambiado. Me explico:

1. El número de "cores" significa que dentro de una pieza de silicio cada core es un controlador mas o menos independiente que puede ejecutar programas sin compartir su ejecución con otros otros programas.

2. El tipo de variante del controlador ARM integrado es cada vez mas avanzado. La mejor equivalencia que se me ocurre por analogía sería comprar procesadores del tipo 8086 que se usaban en los primeros ordenadores, luego del tipo Pentium y hoy en día tipos aún mas avanzados. En cierto modo es análogo con los controladores en las placas raspi!

3. Las otras funciones periféricas integradas con el o los "cores" y sobre la misma placa raspi:
* Memoria RAM adicional, antes 512 MByte, luego 1024 megabytes lo que equivale a 1 GByte!
* El nuevo Raspi 3B ya tiene integrado Bluetooth y WiFi

Cuando analizaba la posibilidad de usar una placa Raspi para mi panel empecé pensando en usar o mi placa Raspi B+ o la placa Zero. El mayor reto consiste en poder crear los PWM que controlan la intensidad lumínica de los 3 LEds integrados en el LED RGB, rojo, verde y azul. Mezclando estos 3 colores en intensidades variables se puede lograr que nuestros ojos perciban toda la gama de colores. Muestra estas imágenes como ejemplo:



Si miran esos cubos pueden ver los 3 colores en tres esquinas. Si la única que ilumina es o la roja, o verde o azul, entonces el resultado percibido es el color de esa LEd, las otras estan apagadas. Si se mueven por los lados del cubo pueden ver que colores van resultando. Si las 3 LEDs iluminan con igual intensidad, entonces nuestros ojos lo perciben como color blanco! Lo pueden ver en el cubo central. la otra forma mas usual de mostrar eso de los colores es esta:



Finalmente por lo sencillo del mensaje de la imagen, esta:



La intensidad de la luminosidad la controlo por PWM:



Dependiendo de la relación de tiempo donde la señal deja correr la corriente, aquí como ejemplo 25%, 50% y 75%, la intensidad lumínica percibida varía. Si nuestros ojos no fueran tan lentos lo que veríamos es que hay tiempos donde la LED está encendida y otros donde está apagada. sabemos por ejemplo de las pantallas de nuestros televisores caseros son mas agradables a la vista si repiten la imagen 100 veces por segundo, 100 Hz, que si lo hacen solo 75 veces por segundo, 75 Hz. Para los circuitos que generan la señal PWM para LEDs se dice que mínimo 100 veces por segundo un PWM de 25% debe permitir el flujo de corriente la cuarta parte del tiempo y dejar la LED apagada los restantes 3/4 del tiempo. Si esa frecuencia es menor a los 100 Hz dependiendo de la edad del humano este percibe el blinqueo de los LEDs! Eso obviamente ocurre antes cuando el porcentaje es reducido por ejemplo a 5%.

Así requiero que una placa Raspi pueda crear PWM en frecuencias de mínimo 100 Hz. Como hablo de 8 LEDs RGB para el control necesito 3 PWM por LED RGB por 8 LEDs igual 3 * 8 = 24 PWMs. Miremos con mayor detalle que significan esas frecuencias en segundos:

Empezamos por hacernos conscientes que la milésima de 1 segundo se llama milisegundo, o ms. 100 Hz por lo tanto significa que para cada uno de los 100 pulsos por segundo el largo es de 10 ms! 10 ms * 100 = 1000 ms = 1 segundo.

Pasando esto a mi objetivo de controlar 8 LEDs RGB. Cada 10 ms el Raspi tiene que encender y apagar la corriente que fluye por las LED RGB de 8 LEDs RGB! Miremos un ciclo con mayor detalle:

Tomemos como ejemplo la imagen del PWM de 25%:
a. 1 ciclo empieza con encender el LED
b. Después de la cuarta parte de un ciclo que es de 10 ms, 100 Hz, 2,5 ms, apaga el LED
c. Después de 3/4 partes del ciclo llega al punto "a."!

Si quiero poder controlar el tiempo de encendido, la intensidad lumínica entre "0", nunca enciende y "100" nunca apaga en incrementos de "1" y así poder especificar la intensidad lumínica en 100 pasos, entonces mi controlador tiene que tener la posibilidad de decidir 100 veces durante un ciclo lo que debe hacer! 100 veces dentro de los 10 ms de una frecuencia de blinqueo de 100 Hz, nos da 0.1 ms donde debo poder encender o apagar mi LED!

La milésima parte de un ms se llama "microsegundo" o "µs". Así 0.1 ms = 100 µs! No los cargo con mas detalles, pero el hacer esa decisión cada 100µs equivale a una frecuencia de 10 kHz! El controlador debe poder ejecutar los códigosa requeridos para cada decisión teniendo solo 100 µs! Todo esto es solo un LED de los 3 en un LED RGB y de estos tengo que controlar 8.

3 * 8 = 24, para facilitar el cálculo digamos que 25! Significa que para controlar bajo control de un programa cada PWM realizado en solo software tiene 100µs / 25 = 4 µs para ejecutar el código! expresado como frecuencia: 25 * 10 kHz = 250 kHz. 250 kHz es 1/4 de 1 MHz. Si el controlador tiene un reloj de 1 MHz y ejecuta una sentencia por "tic" solo puede ejecutar 4 sentencias máximo.

Doy estas estimaciones solo para darles una corta mirada sobre lo que considero mientras analizo si la placa Raspi es adecuada, cual de las diversas placas es capaz de esta labor. Todo aquel que sabe aunque sea un poco sobre electrónica y microelectrónica sabe que los controladores modernos tienen periferias realizadas en circuitos que permiten crear señales PWM sin que el controlador tenga que hacer esta actividad y que sus acciones se limitan a cambiar parámetros para adaptar el porcentaje! El problema para mi está en que cualquier controlador solo tiene un número limitado de estos tal llamados "hardware PWM" y que estos a su vez solo tienen un limitado número de tal llamados "canales PWM" y que solo un número limitado de pines del controlador permite pasar estos PWM al entorno!

Así me puse a pensar como sería usar controladores mega8 como generadores PWM y de controlar estos µCtrl con la placa Raspi. Cada mega8 tiene 3 canales PWM. De allí resulta que 8 mega8 bajo control de la placa Raspi podrían solucionar el trabajo! La placa Raspi se comunicaría con el mega8 correspondiente usando el "bus I2C" y cada mega8 solo cuesta 2 Euros! para recordar. La placa Raspi me permite controlarla desde mi ordenador comunicándose por WiFi!

Con todas estos estudios me encontré que existe la posibilidad de realizar una implementación del sistema operacional Linux para sistemas embebidos y en especial para sistemas de tiempo real! Sistemas de tiempo real se llaman sistemas donde los tiempos de ejecución siempre serán idénticos, cosa que el Linux "normal" no es capaz de hacer. En especial si requiero tal precisión de tiempo e intervalos tan cortos como los que presenté arriba! Tradicionalmente lo que se acostumbraba hacer era aplicar un tal "patch" a Linux lográndose una precisión en el orden de 1 ms! ahora, debido a los avances tecnológicos, el raspi 3B tiene 4 "cores", el B+ tiene 2 "cores", es posible dejar la ejecución del Linux "normal en uno de los "core" y ejecutar algo dedicado en otro de los "cores". este segundo código que se ejecutaría en otro core independiente lo llaman por ejemplo "cobalt"!

Hasta hace muy pocos días la actividad para realizar algo así la hubiera considerado totalmente fuera de mis posibilidades. El número de factores a considerar, la gama de conocimientos requeridos hubieran sido como si me decidiera a armar un dispositivo para viajar a Marte!

Pues bién. hace 2 semanas me encontré con un libro de un profesor universitario alemán llamado "Jürgen Quade" que es el jefe de un instituto de una universidad en el noroccidente alemán sobre sistemas embebidos de tiempo real. En el, como literatura para sus estudiantes, desarrolla la implementación de una versión de Linux minimalista en la placa Raspi y luego enseña a implementar los drivers, software que habilita el comunicarse y usar del sistema operacional de periferias. Estudiando material disponible de forma gratuita y de reflexionar sobre esto algún tiempo, me decidí comprar 2 libros de este autor. 1 sobre su curso de linux de sistemas de tiempo real usando la placa Raspi y la otra en la que basan sus lecturas universitarias sobre sistemas de tiempo real.

Tomé la decisión de tratar de meterme en esta temática debido a que tratando de implementar una instalación de la placa Raspi no usual y de tener que meterme en cosas de redes y de sistemas de autorización quedé sumamente fascinado empecé a ganar impresiones de lo que significaría meterme en esto!

Para cerrar el círculo de esta contribución y de poner el contexto del proyecto de mi velero Carina. Los objetivos por los cuales persigo la técnica del diseño por modelación para estudiar y realizar mi sistema de control de escotas me llevaron a las placas Raspi. Conocimientos como aquellos que aprendí en su tiempo con el curso original en alemán de la tarjeta experimental hoy me capacitan, por tener comparativamente sólidos conocimientos fundamentales de la electrónica digital relacionada a microcontroladores, hoy puedo aventurarme por las rutas que aquí presento.

La agresividad y los ataques personales entonces por ciertos miembros de este foro por no querer apoyar la implementación de soluciones concretas, sino querer dar tales conocimientos iniciales para realmente poder aventurarse por el rico ecosistema de la electrónica para nuestro afición, solo me ha dejado pena por aquellos individuos, que aún siguen regando el chisme que dizque me siento superior a otros foristas! Yo estimaba un rico y amplio y diverso mundo que se abre al modelismo naval si le perdemos el miedo y nos sobreponemos a la intimidación que este campo tiene en nosotros! En especial el gigantesco auge tecnológico que proviene de las investigaciones sobre el Internet de las cosas, IoT, Internet of Things, abre increíbles posibilidades. Si hace ya una eternidad había considerado el uso de módulos de 2.4 GHz como "radio control digital", hoy WiFi y la telefonía móvil y placas económicas como las Raspi abren oportunidades mucho mas adecuadas. Porque no usar el "smartphone" o la "tableta" para comunicarse con el modelo por WiFi y si la comunicación queda interrumpida por la comunicación de datos en las redes de los celulares? Yo pago 1 Euro por mes por un chip para la telefonía por mes y tengo 100 Mbyte de volumen de datos. eso es una capacidad infinita para controlar un modelo. Existen ofertas para flat rates válidas para un solo día. En el taller no necesitamos mas que WiFi, cosa que la Raspi ofrece sin meterse en materias exóticas!

Si yo ya estuviera en la fase de experimentación usando el control remoto para implementar las funciones y verificarlas, el costo es nulo por usar WiFi. si me decido ir a un lago y controlar mi modelo usando una cámara video abordo sin limite de distancia. Pago un flat rate válido solo ese día por una suma ínfima! No sin razón las instituciones estatales han realizado los peligros provenientes de los cuadricoptero empezando a establecer leyes que obligan a registrarse como dueño de tal modelo. Con lo que aquí presento esto es casi que arqueológico por lo caducado. Las posibilidades tecnológicas para nuestra afición no solo ofrecen una infinita gama de posibilidades para nosotros los modelistas navales, sino que las posibilidades ya tocan la seguridad de nuestro entorno social.

Estando consciente de esto, con el aumento de las posibilidades de la tecnología para nuestra afición, afortunadamente soy demasiado viejo y enfermo para tener que vivir en ese mundo que esta por desarrollarse! Siempre hay una válida y totalmente respetable justificación para limitarse en nuestra afición a las técnicas tradicionales. Pero en combinación con esas técnicas tradicionales la tecnología ofrece un mundo casi infinito de posibilidades nuevas.