Programacion arduino visual

[jstony2000]

he encontrado esto para la gente que le pueda interesar, es un programa de programacion de arduino de manera visual.
Tutorial Minibloq
http://blog.bricogeek.com/noticias/arduino/minibloq-entorno-grafico-de-programacion-para-arduino/


* Corre completamente "offline" y es portable (puede ejecutarse desde un pendrive).
* Es rápido, ya que está hecho en C++.
* Genera código C/C++, lo compila y lo baja a la memoria flash de la placa (Arduino u otras).
* Es compatible con Wine e incluso está funcinando en la OLPC XO (hay videos en el sitio web). Así que en netbooks también camina...
* Es expandible.
* Tiene una interfaz de usuario moderna, con ventanas acoplables, zoom, navegación por teclado, etc..
Está hecho con herramientas de código abierto (básicamente wxWidgets, MinGW, Code::Blocks, Inkscape...)
* Una vez que termine la versión 1.0 voy a liberar todo el código (bajo una licencia estilo MIT con la única limitación de que no podrá utilizarse en proyectos militares).
*La página en español : http://es.wikipedia.org/wiki/Minibloq

esta es la paguina oficial:
 
http://blog.minibloq.org/

[joshagrady]

Si animo de menospreciar la contribución, ¿que ventaja tiene este entorno frente a otros más convencionales (e.g. Processing o C)?

Saludos,

[tio_gil]

Os digo la experiencia que hubo en la empresa para la que soy rep: Funesta.
Se propuso y se hizo un entorno de desarrollo para que p.ej., en vez de escribir el código necesario para encender/apagar un led (versión "hola mundo" a nivel micros), ya sea en C o en ensamblador,  se hiciese de manera visual: se pone un led y a este se le conectaba una caja que era un generador de frecuencia.etc,etc.
Resumen: código ineficiente y bastante largo. ¿Funcionaba? si, peeero...

El arduino (y esto es opinion personal) está muy bien como concepto y hay muuuucha gente que hace cosas incríbles con el. Pero si le quieres sacar el 110% de rendimiento, es mejor pillarse el micro a pelo, usar la plataforma hardware del arduino (que está muy bien pensada) y currarse las cosas
¿Que para el 95% de las cosas llega? pues si. pero ese 5% es donde se notan las cosas (esto es como intentar hacer procesos extremadamente rápidos en C: imposible. Hay que bajar a nivel de asembler)
Tamabién puede ser la deformación personal que tengo

[Valen]

Hola, yo diría lo siguiente:

El micro de 8 bits Atmega 328 que se emplea en la plataforma Ardunio es lo que pretende ser: Un micro relativamente sencillo de programar, con las cosas más estándares ya incluidas, que son suficientes para muchas aplicaciones.

Pero hoy en día el hardware no vale nada, es baratísimo, por eso, cuando se quiere más potencia o rapidez, lo más sencillo es migrar a un chip más potente (pero más complejo de programar).
Uno de los chips que más tirón tiene en estos momentos es el ARM Cortex M3, y toda la familia ARM en general, ya que prácticamente todos los móviles Android llevan este micro. Es un hardware de 32 bits muy potente, que llevan de todo incorporado de serie: Desde USB, a Bus CAN, etc. Y son muy baratos  (por ej. la familia de nxp, ARM Cortex M3 lpc 17xx, está entre 7 y 15 eur en RS Amidata... y algunos llegan a los 100 MHz...!)

Respecto a la programación, siempre he tenido bastantes programadores a mi cargo (y yo mismo lo hice, claro). Nuestra opción desde hace mucho, siempre es el C, por muy bajo nivel al que queramos llegar. La razón es que nos dejó de compensar el programar en ensamblador (hace 10 años sí que lo hacíamos).
Pensamos que ya no nos es útil porque los compiladores actuales tienen unas rutinas muy eficientes a la hora de generar el código objeto, y además no corres los riesgos de producir código con pequeños fallos, como es habitual en ensamblador. Esto se une a la potencia de cálculo del hardware actual, que nos hace innecesaria la pequeña optimización manual que aún podemos obtener retocando el ensamblador.

Esta es la experiencia que yo he tenido...... Lo que ha cambiado este mundo es la enorme potencia de cálculo del hardware actual, y su bajísimo coste.


También hay un cambio radical en el concepto que manejan las empresas sobre si compartir el conocimiento, o venderlo:
Los fundadores del entorno Arduino fueron unos de los precursores en el concepto de "hardware libre" (unido al "software libre") que se basa en compartir el conocimiento, mediante foros, librerías que publica la gente para la cosas más variopintas, etc.

Mientras esto ocurría, algunas empresas mantuvieron el concepto de vender el conocimiento a precios imposibles para la gente corriente... y fueron perdiendo una parte cada vez más importante de cuota de mercado.
Así le ocurrió a Texas Instruments, que era muy cara, tanto en su hardware, como en su software de desarrollo, pero ante el empuje de iniciativas como Android de Google, etc. todo ha cambiado, y ellos también han decidido un cambio de estrategia: Han abierto foros donde compartir el conocimiento, e incluso dan soporte gratuito con sus propios ingenieros... y ha bajado espectacularmente los precios.

En esta misma dirección, el fabricante de chips Atmel, que fabrica los ATMega 328 del entorno Arduino, también acaba de liberar un Entorno de Desarrollo para sus chips con arquitectura ARM Cortex, familia SAM3U, etc, llamado Atmel Studio 6.0, que incluye cientos de programas ejemplo, con librerías de terceros de libre uso no comercial, y que es un entorno totalmente gratuito.

El mundo del hardware/software está cambiando muy rápidamente, y los conceptos que hace 5 años eran válidos, hoy en día quedan cuestionados.... Yo creo que el camino que han tomado las cosas, es el correcto.

[salvachuan]

La verdad Valen que llevas toda la razón y aveces es hasta sorprendente los precios de algunas cosas por ejemplo:
http://es.rs-online.com/web/p/microcontroller-processor/7458434/?searchTerm=7458434 aunque esto para mi que no me dedico profesionalmente, se me queda muy grande(de momento seguimos en 8bit).

Hay plataformas de programación visual, pero no abiertas, para microcontroladores como Flow Code o Niple.
Yo solo he probado la primera un poco pero es como dice tio_gil

Resumen: código ineficiente y bastante largo. ¿Funcionaba? si, peeero...

pero muchas cosas se tiene que complementar con C.

[tio_gil]

Los compiladores de C cada vez hilan más fino. EL Keil para la familia xx51 es uno de los que más código eficiente he visto hacer (me he "jartao" a programar en asemmbler para los xx51 y visto el código generaod por Keil, hay que descubrirse)
Dicen las malas lenguas que los de HItahi (ahora Renesas), primero hicieron el compilador y luego el micro... bueno, cabe la posibilidad. Siempre los he programado en C, he iban bastante "finos"

El otro día me pregunta un cliente si se puede meter código ensamblador "in line" en un programa hecho en C para un Cortex M3. Como la documentación no estaba muy clara se lo pregunté a mis colegas americanos y tuve dos tipos de ocntestaciones: a) por supuesto... pero para que? y b) "si... y buena suerte". Hablando con el cliente me comentó que el problema era que estaba con un PID y los calculos había que ejecutarlos en menos de 55 us.
Para que veas que en casos "críticos", no queda otra que hechar mano del ensamblador

[Valen]

Pero precisamente para realizar esta tareas tan específicas, marcas como Texas Instruments tienen placas DSP  (procesador digital de señales) de última generación, en el que un segundo micro, de tipo ARM Cortex, se utiliza tan solo para las comunicaciones... El procesador principal es un monstruo, y la placa completa no cuesta más de 90-100 Eur.

Esta placa es uno de estos DSP de Texas Instruments (la que está en posición vertical). Comparando las dimensiones de la placa, con la de los componentes, se ve que es muy pequeña:



Por eso digo que no merece la pena romperse la cabeza con un hardware: Si uno no llega, te vas a otro superior, por muy poco dinero..... Al fin y al cabo, un PID son "cuatro líneas" de código, y si un micro no llega a ejecutarlo en 55 micro segundos, no es por haberlo compilado en C en vez de ensamblador (ya digo que la diferencia de eficiencia es muy pequeña), sino porque el hardware elegido no es suficientemente potente.

[MANOLOMARAVILLAS]

esta claro que yo estoy a años luz de muchas cosas ,, como todos  , aprender de programacion y de tantas cosas es imposible....   
asi que de momento yo estoy con  niple 5,6.
que de momento me ba muy muy perfecto, si genera codigo mas largo y ocupa mas espacio esta claro.
pero jamas lleno su memoria en ningun proyecto. y si quiero algo mas  largo siempre queda añadir  mas memoria externa  con las memorias externas por i2c  o de cualquier otra manera.
 esta claro que de momento estoy limitado a la familia  18f  de microchip... que de la manera que sea ,, para las cosas que yo tengo que hacer  me sobra mas de la mitad de chip.
el niple es un buen programa  , yo lo e puteado mucho y llevado a extremos ,,, y si siempre alguna cosa se escapa.
pero  en esta vida para  hobby y algunas cosas de trabajo  que no requieren tanto, merece la pena  cojerse a algo sin tanto quebradero de cabeza.
las cosas grandes ya las fabrican los grandes fabricantes.. ,,,  sobre lo del soporte android,,,,
tenemos en la familia  varios moviles  con microchips de estos ,, y valen te diria yo que son una mierda...
estos micros que dices tan potentes no los monto en una placa ni en plan risa,,,,  se queda mas pillado el movil,,,,  muchas veces te toca quitarles la bateria.... como tubiera que llevar una bomba atomica  este chip de  android ,,, creo que hace años   la tierra no existiria,,,,   
asi que de momento y pienso que  no vale la pena machacarse tanto la cabeza ,,, programacion simple.... niple apolla  muchisimas cosas y   cuesta 90 eur  en version profesional.  nada caro para el acometido,,,,  tiene calculos basicos y buenos y rapidos....
esta claro que para  sacar  ecuaciones y calculos con senos y cosenos ,,, no sirve ya que necesitas  c++    , pero  siempre en ensembler puedes incorporar cosas ,,,

[Valen]

jajaja Manolo,     pero bueno, en realidad, lo que se cuelga siempre es el software, no el micro...
Yo también tengo una Blackberry de gama alta, que a veces se cuelga, otra se queda con el reloj de arena dando vueltas durante 15 segundos, etc. pero siempre es el software el que da los problemas...
De hecho, los micros llevan un "watchdog" disponible a las aplicaciones, para que si al cabo de un tiempo determinado, el software no reacciona, el hardware toma el control por su cuenta, desde abajo, y resetea ese software....

[traca27]

por donde empiezo a trastear con este tipo de placas , programas y equipos, siempre estoy inventando y me parece bastante fácil en comparación a programar pics , de las cuales solo se que funcionas en lenguaje c,¿Basic? , vamos que me gustaría saber algo y hacer cosillas.

En cuanto a programación de automatas si que he hecho cosas,telemecanike, kloquen moeller, siemens ,el zelio de sneider,este ultimo es el que mas he usado , para muchas cosas.

Alguna orientación de que comprar ,sin que sea un fortunón,para hacer cositas?

[fleming]

Hola Traca,
Si quieres empezar desde cero, píllate esto:
¿Que tal el inglés? pásate por aquí....
http://arduino.cc/
o por su versión española... pero está un poco obsoleta.
http://arduino.cc/es/
Aunque este es un foro de mecanizado, lo suyo es que te pases por aquí para aprender
Se programa en C/C++... pero si ves que se te atasca el C.. pásate por el primer mensaje de este hilo de, jstony2000... que es realmente para lo que sirve... para gente que no entiende el C o se le atasca, o quiere empezar de forma sencilla... es un forma de empezar muy visual. Aprenderás que es un bucle, una sentencia condicional, una variable...
Evidentemente el Minibloq (como el Scratch) no están para conducir Rovers por la superficie de Marte... está pensado para gente que quiere empezar en programar, pueda hacerlo sin muchas barreras de entrada, o para introducir a niños de 9-14 años en este mundo...

[traca27]

este tipo de kits , que tal?
tienen mas cositas para hacer e inventar, mas que la placa sola.

http://www.ebay.com/itm/UNO-R3-Starter-Kit-Step-Motor-Servo-1602-LCD-Breadboard-LED-resistor-for-Arduino-/190882304604?pt=LH_DefaultDomain_0&hash=item2c7178d25c#ht_2563wt_932

[fleming]

Coño!!! no había pensado en esos Kits... pero vienen con multitud de cacharrada... y no tiene mlas precio.
Lo bueno es que tienes entretenimiento para rato..
Saludos.

[derethor]

Los compiladores de C cada vez hilan más fino. EL Keil para la familia xx51 es uno de los que más código eficiente he visto hacer (me he "jartao" a programar en asemmbler para los xx51 y visto el código generaod por Keil, hay que descubrirse)
Dicen las malas lenguas que los de HItahi (ahora Renesas), primero hicieron el compilador y luego el micro... bueno, cabe la posibilidad. Siempre los he programado en C, he iban bastante "finos"

El otro día me pregunta un cliente si se puede meter código ensamblador "in line" en un programa hecho en C para un Cortex M3. Como la documentación no estaba muy clara se lo pregunté a mis colegas americanos y tuve dos tipos de ocntestaciones: a) por supuesto... pero para que? y b) "si... y buena suerte". Hablando con el cliente me comentó que el problema era que estaba con un PID y los calculos había que ejecutarlos en menos de 55 us.
Para que veas que en casos "críticos", no queda otra que hechar mano del ensamblador

Es muy discutible eso de meter assembler, y que funcione mejor o mas rapido... Casi en todos los casos, eso no ocurre. No diugo que no sea mala idea, yo mismo he multiplicado bucles a casi 3x la velocidad de ejecucion, pero usando extensiones del micro (las nuevas instrucciones SSE4, por ejemplo) pero en casos muy concretos (yo hablo del entrono de la programacion gráfica). Meter asm en general, siempre acaba siendo un problema de rendimiento. Lo ideal es usar "intrinsics", o sea, macros que representan a las instrucciones que quieres utilizar. Ya que asi, el compilador puede analizar ese codigo.

Los compiladores usan varias pasadas para generar ensamblador. Primero pasan el C a un pseudo lenguaje universal, como un ensamblador generico, que entre otras cosas, tiene un numero infinito de registros.

Luego, hay una pasada que lo que hace es convertir esos registros virtuales a los registros reales, para conocer cuales están libres. Si no está libre, usa variables de memoria. Hay algoritmos para para optimizar el uso de los registros libres, minimizar el uso de memoria, etc.

Pues bien. En cuanto metes asm en linea, el compilador marca todo ese bloque como "no optimizable" (entiende que tu no quieres que se toque eso), y lo que hace el compilador es preparar los registros y todo para que eso que se va a ejecutar sea seguro. Asi, como normalmente no sabe lo que haces en ensablador, mete todo en memoria antes y despues de las llamadas. Y el calculo de registros libres se va al carajo.

Otro tema es el "alias". Puede que tu accedas de distintas formas a la misma region de memoria. Esto trae implicaciones para el compilador. Porque si no sabe esto, hay un gran numero de optimizaciones que no se pueden realizar. En concreto, cada vez que operes con una variable, tiene que meter una lectura a memoria, porque no sabe si la has modificado usando otro puntero antes, y no puede optimizar metiendo todas las operaciones en registros (por eso usas el keyword 'const' para decirle que eso es de solo lectura, y el compilador puede hacer todo en registros)

Pues bien, en el momento que metes asm en linea, todas las variables del bloque quedan marcadas como "alias". O sea, que no sabe si accedes a ellas por registro o por variable, ya que el compilador no analiza el asm que tu escribiste. Y luego, todo eso se convierte en lectoras de memoria.

Como digo antes, no quiero decir que meter asm en linea no sea beneficioso en algunos casos (me imagino, optimizando una interrupcion, etc), pero hay que saber que en cuanto metes asm en linea, el compilador pierde muchisima informacion.

[MANOLOMARAVILLAS]

existe niple en pic. y os aseguro que es un entorno impresionante...
os puedo poner la web
para quien quiera echar vistazo,, mis grandes proyectos estan echos con este entorno,
yo no tengo ni puta idea de c,
http://www.niplesoft.net/