Haz una pregunta
  Foros de Electrónica » Diseño digital » Interfaces y Programación
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

14/01/2015 #1

Avatar de Hellmut1956

Protocolo adecuado entre PC y placa con ARM cortex Mx
Hola amigos, he visto investigando aquí en este subforo que probablemente encuentre quien me ayude.

El punto es que tengo pensado aplicar la metodología del diseño por modelación usando en el PC la Software Mathematica y SystemModeler der Wolfram con placas LPCXpresso. Wolfram desde la mas reciente versión del SystemModeler 4.01 ofrece una biblioteca llamada ModulPlug y el protocolo "Firmata". Debido a que el protocolo es un desarrollo basado en el protocolo "MIDI" este protocolo limita el número de funciones a que se puede acceder. Existe un reporte de un Chino que portó lo que actualmente Wolfram solo ha realizado para ciertos Arduinos a un LPC800 y narra de como lo hizo y con que limitaciones se encontró! Resulta que un compañero iberoamericano me ha respondido, trabaja para Wolfram, que otro protocolo en vez de Firmata recomendaría! Reflexionado tuve que realizar que con esta pregunta me encuentro en un entorno que no conozco, razón por la cual publico mi pregunta aquí!

Yo creo, empezando por el medio de transporte de datos que WIFI y/o Ethernet resultan mas adecuados que USB por 2 razones: Primero, ambos son capaces de ofrecer un volumen mayor y mas rápido que USB y segundo que siendo buses varias placas se podrían poner en diálogo con el SW en el PC al mismo tiempo!

De allí, y aquí me meto en terreno no realmente dominado, el protocolo de TCP/IP sería el encargado de transportar los datos y por encima de este al momento Wolfram ofrece solo Firmata y aquí un protocolo gratuito y adecuado para configurar hardware externa, para monitorearla y para manejar un flujo de datos sería lo deseable.

Tienen alguna recomendación?
16/01/2015 #2


Hola Hellmut, quiero entender que preguntas especificamente, sobre el protocolo de Hardware mas apropiado; para lograr un transporte de comunicación de "un protocolo de software utilizado en el diseño de modelacion" que pretendes establecer, entre la PC y LPCXpresso.

Si es así, hay LPCXpresso con interface ethernet (TCP/IP) incluidas. Ethernet, como bien consideras; seria quizás la mejor plataforma de hardware disponibles puesto que ya esta "todo hecho" bajo este protocolo, mas si se piensa en redes con lo que restaría enfocarse solo a la materia de transportar la información.

Por otro lado, no alcanzo a visualizar la aplicación final que buscas, quizás con un Mapa Conceptual de tu sistema y lo que pretendes, seria mas fácil armar los elementos que habrán de existir como conjunto y su posible interacción.

Si bien, como comentas, ya existe el trabajo sobre el transporte de información por medio de Frimata (que migraron desde lo que existe en arduino para usarlo en ARM) y que hablando de hardware es por USB/RS232, sé que existen trabajos de Frimata sobre TCP/IP y que obviamente dependen del Shield Ethernet para arduino; con lo que se tiene mas materia de estudio para intentar valorar las limitaciones que encontró Wolfram; y tratar de discernir si fueron del propio desempeño del hardware utilizado o de los alcances del protocolo de Frimata.

Te dejo un saludo y gracias por regalarme un poco de disertación. pero si, pienso que Ethernet (tcp/ip) es tu mejor opción por lo que tu mismo comentas y también porque sigue y seguirá vigente por muchas décadas mas.

22/01/2015 #3

Avatar de Hellmut1956

Mil gracias por tu competente respuesta. Perdona por haber escrito mal el nombre del protocolo. es "Firmata".

Permíteme presentar en que consiste mi objetivo para luego compartir lo que tengo hasta este momento! Tratando de explicar a terceros lo que se tiene en la cabeza es un proceso iterativo, pero muy valioso, pues lo obliga a uno de presentar algo de forma que se entienda y eso obliga a madurar y sistematizar lo que hasta entonces existía en mi mente!

Soy modelista naval y aficionado a la electrónica y los últimos casi 15 años no he vuelto a encontrar un trabajo como empleado, estando así obligado a generar ingresos de otras actividades y de desarrollar mis conocimientos y tener los días bien organizados y y mi mente activa. Así pues tome la decisión hace ya unos casi 10 años de construir el modelo de un velero, pero no para ir a navegarlo sino para usarlo como plataforma y línea roja que me pone en contacto con las mas diversas tecnologías y evidentemente así creando conceptos nuevos de como realizar cosas de otra forma que la actual.



Aquí una vista ya bastante vieja de como se verá ese velero. Debido a limitaciones de las tecnicas actuales existentes en el modelismo naval para el control de las escotas, son esas cuerdas que determinan cuanto la vela puede girar, yo quiero implementar el sistema tal cual era usual en los veleros originales de principios del siglo 20.



Si se asume que el radio de giro de 1 metro es la distancia entre el mástil, donde está en eje vertical alrededor del cual el palo de la vela gira y que este palo puede girar entre +90° y -90°, el ángulo siendo el de la línea central del casco y el palo de la vela, podemos asumir un triángulo orthogonal donde la hipotenusa, la distancia que tiene que ser cubierta por la escota es la raíz cuadrada de 2 lo que nos da 1.4 metros de largo. Vemos en la foto el recorrido de las escotas del velero "Endeavour" es de 6 veces entre el palo de la vela y la cubierta, de lo que resulta: 6 x 1.4 m = 8.4 metros que el largo de la escota puede variar, aproximadamente!



Este gráfico para ilustrar el asunto. Mi sistema de control de escotas registra el ángulo entre el palo y el eje central del casco usando sensores angulares magnéticos. Así mi sistema solo pone tal largo de escota disponible como el palo de la vela requiere en relación a la posición actual del palo de la vela, evitando así que la escota se puede trabar con lago sobre la cubierta. El largo de la escota lo controlo usando un motor de paso, mi tutorial sobre motores de paso aquí en el foro refleja lo que había aprendido hasta entonces, me siento muy halagado que este tutorial sea destacado.



Con estas informaciones preliminares creo que será posible comprender el sistema y entender mis explicaciones de porqué el uso de la metodología del diseño por modelación puede ser adecuado y entender las razones que expongo y que me llevaron a hacer las compras que deseo presentarles.

En el sistema de control de escotas real los comandos del operador en la emisora del radio control indica con su accionamiento de los controles de la emisora hasta que punto desea permitir que la vela se abra. Que punto significa hasta que valor del ángulo! esta información la da la receptora del radio control en forma de un PWM cuyo largo es medido con un timer del LPC1769 de la placa LPCXpresso1769. de una tabla saca el dato hasta que ángulo máximo la vela tiene permitida abrirse. Cuando este límite es alcanzado el motor de paso deja de continuar alargando la escota limitando así el seguir abriéndose de la vela. Tal cual se acostumbra. Si la vela oscila entre el ángulo máximo a uno u otro lado del casco la segunda placa LPCXpresso1769, Control Winche, recibe este dato del sensor angular y adapta la posición del motor de paso para que el largo de la escota sea adaptado a la posición actual de la vela. Un segundo sensor angular monitorea el giro y la posición del tambor de escota verificando así que el valor de posición de la variable corresponda con la posición dada por ese segundo sensor angular magnético. La placa "stepRocker", que controla el motor de paso, ver tutorial sobre motor de paso aquí en el foro contiene un controlador ARM Cortex M0 con la periferia del codificador de cuadratura requerido!

Cuando mas reflexiono sobre este sistema mas aspectos relevantes encuentro y como el objetivo es lograr un sistema que no solo cumpla con su función, sino que también debe tener un máximo de eficiencia energética muchos detalles tienen un mayor impacto en la eficiencia energética. Un óptimo no se encuentra de forma experimental e iterativa por la multitud de parámetros que impactan este objetivo y pudiendo modelar el sistema usando las herramientas "Mathematica" y "SystemModeler" de Wolfram, pudiendo simular el sistema para buscar valores óptimos de los diversos parámetros involucrados, pudiendo verificar la calidad de la modelación y la calidad de la simulación y sus resultados usando "Hardware-in-the-Loop" y "Software-in-the Loop" para comparar el sistema real y sus resultados con aquellos como resultado de las simulaciones será de mucho valor. Pero también espero que una descripción exacta y correcta de ciertos aspectos podría ser difícil de alcanzar. El uso de "solvers" dentro del ámbito de "Mathematica" hará posible usar estos para encontrar ecuaciones cuyo resultado de la calidad de aproximación deseada.
22/01/2015 #4

Avatar de Hellmut1956

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.
26/01/2015 #5


Modulo WI-FI ESP8266
Mi Muy estimado Hellmut1965, muy descriptivo el quehacer que te ocupa y agradezco el lujo de detalle que compartes, yo también soy modelista por entretenimiento aunque me decanto por ferromodelismo y aeromodelismo, profesionalmente me he desarrollado por el lado de la cibernetica con lo que para mi el modelismo es un escaparate ideal para intentar mis automatas.

Por mas de treinta y cinco años el gran cerco entre mis modelos y la "inteligencia" de quien los comanda es la parte correspondiente a la Telemetria y aunque al parecer, hoy toda este tema esta resuelto, la realidad es que no es cierto, puesto que no es nada barato si requieres de varios kilometros de cobertura.

Tomando como tema neuralgico la pregunta con la que abres el tema sobre el protocolo adecuado para comunicar un PC y un Microcontrolador y que considero quedo establecido que es el protocolo TCP/IP. Ahora el tema es como transportarlo (telemetria) y a eso me referia yo en mi comentario anterior al solicitar un “mapa conceptual” del sistema general.

Siendo un poco mas especifico. Tengo estas preguntas basicas:

¿Qué distancia se desea cubrir entre la pc y el microcontrolador?

¿Qué velocidad en baudios se requieren como minimo?

¿se requiere la comunicación establecida siempre, o solo en ciertos lapsos?

Yo actualmente estoy aprovechando las facilidades de un modulo WI-FI que se ha vuelto muy popular conocido como ESP8266 y que me permite tener una comunicación tcp/ip WI-FI y que cubre unos trecientos metros en campo abierto y dependiendo de la arquitectura del lugar entre 60 y 100 metros dentro de mi casa. Mas particular es especificar que dentro de TCP/IP aprovecho el protocolo UDP como comunicación entre PC ,el Modulo ESP8266 y un microcontrolador.

Derivado de la experiencia propia, he visto que un microcontrolador de 8 o 16 bits no tiene el poder de CPU para los calculos matematicos deseados en la “Modelacion Matematica” y por otro lado estar cubriendo los temas de actuadores, sensores y la propia comunicación. Por estas razones al igual que tu, he venido experimentando que el Modelado matematico se resuelva en “Tierra” (una Computadora personal) que en base a los datos recibios por la telemetria, se solucionen y las acciones a tomar se transmitan al automata en funcion.

Por el momento el modulo ESP8266 es para mi un modulo extremadamente barato, en México se consigue por unos 7 dolares americanos y he podido utilizarlo para comunicar por UDP mi PC con varios microcontroladores de una forma muy sencilla y eficaz aunque como ya comente; su limite de cobertura esta en el propio especificado por el estandar del WI-FI.

Les dejo un saludo
26/01/2015 #6

Avatar de Hellmut1956

Hola miborbolla

Conozco los retos de la comunicación inalámbrica entre los aereomodelos y una emisora adecuada. Hace algunos años empecé a reflexionarlo, en especial viendo como con excepción de los chinos los proveedores toman precios para equipos de telemetría dentro del ámbito del uso de la técnica de 2.4 GHz. También me da bronca el ver como los proveedores siguen hablando del número de canales de emisora y receptor, cuando allí se trata de una comunicación serial bidireccional.

En ese contexto se ignora totalmente que una emisora, término que no es realmente adecuado porque tanto el módulo en el modelo, como aquel en la emisora son bidireccionales! Una estación en manos del operador sería mucho mas adecuada si los controles mecánicos, como las 2 palancas que se encuentran en cada emisora y algunos switches y controles rotativos estuvieran alrededor de una pantalla de 10 pulgadas como las que tienen las Pads. Eso requiere cambiar el diseño totalmente.

Pero volvamos al tema del hilo. TCP/IP en el modelo OSI que presento como gráfico arriba solo son los niveles 3 al 5. Mi pregunta va en dirección al protocolo del nivel 2.
En lo que a los niveles 1 y 2 se refiere estaré usando USB, ya que se trata de modelaciones y simulaciones en el laboratorio con los cuales deseo lograr un diseño lo mas óptimo posible. Pero también he adquirido el módulo de WIFI como alternativa de los niveles 1 y 2, pero inalámbricos. la razón realmente es solo el reducir el número de cables sobre la mesa de mi laboratorio electrónico. Eso sí, el protocolo TCP/IP para los niveles correspondiente sigue válido.
Respuesta
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Buscar más temas sobre:
Lupa Interfaces y Programación

Lenguajes de programación, gestión y manejo de puertos

Cerrar
Foros de Electrónica » Diseño digital » Interfaces y Programación

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.