Portar proyecto de Arduino a Eclipse.

[Picuino]

Igual al final no es tan complicado portar el proyecto de Arduino a KDS o MCUXpresso.

Una vez hecho, seguro que te parece sencillo.

Probablemente tendrás que tocar todas las configuraciones de Eclipse para que este produzca un makefile igual.
Por eso prefiero en muchos casos trabajar diréctamente con un editor de textos, sin IDE. Es lo mejor por ejemplo para pasar a otra persona tu configuración. Simplemente le envías el makefile y listo.
En el libro Mastering STM32 los ejemplos de compilación los escribe directamente en línea de comandos. Por ejemplo en la página 6:

$ arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -fverbose-asm -save-temps -O0 -g -c file.c

Para hacer eso con Eclipse habría que mostrar en el libro unas cuantas imágenes de pantallas gráficas y configuraciones.

Por eso, trabajar con Eclipse es en muchos sentidos como trabajar con el IDE Arduino. Es más sencillo, pero te oculta muchas tareas que hace en la sombra.
Con la línea de comandos lo tienes todo a la vista. Esa es otra opción para empezar a portar desde Arduino y es la primera que yo voy a hacer.

Un saludo.

[Picuino]

A propósito ¿Que opción elegir KDS o MCUXpresso?

[elgarbe]

El LPCXpresso en su momento y las LPCOpen (librerías) eran lo máximo. Lamentablemente se quedaron y perdieron muuuucho terreno/tiempo. Yo habia arrancado con NXP y estaba muy contento. Pero no le dieron bola a los foros de consulta, no publicaron muchos aplication notes y ST los pasó por arriba.
Espero que se pongan en tono pronto porque tenía buenos micros, unque al ritmo que va ST no sé cuándo lo van a alcanzar.

Sds

[planeta9999]

A propósito ¿Que opción elegir KDS o MCUXpresso?

Precisamente ahora mismo acabo de conseguir, por fin, que el MK66 se pueda trabajar con Processor Expert en KDS. Menudo galimatías, estos de NXP han montado un pastel de mucho cuidado, yo todavía no entiendo muy bien todo este festival de KDS, SDK, IDE, ahora MCUXpresso, la configuración online en su web para crear los SDK, etc..., es de locos. Para cualquier mente medianamente organizada, todo esto no tiene ni pies ni cabeza, es como si lo hubieran hecho aprisa y corriendo, un sinsentido.

La gente de soporte de NXP me han echado un cable en el foro, y he podido descargar e instalar el KSDK 1.3 para que el KDS soporte los MK66, toda una odisea, pero ya funciona.

A ver, ahora entre MCUXpresso y KDS (Kinetis Design Studio), sin dudarlo KDS porque soporta el Processor Expert, este es el generador de código para poder configurar toda la periferia sin escribir una linea de código.  El Processor Expert es en Kinetis lo que el Cube en ST o el Harmony en Microchip, te ahorras un montón de tiempo.

Por ahora, MCUXpresso no soporta todavía el Processor Expert, ya por eso, yo de momento no lo utilizaría. Supongo que lo pondrán, parece que están en ello. Pero lo han hecho muy mal, han liberado un producto que está a medio acabar, por lo menos para los interesados en Kinetis. Supongo que para usarlo con LPC será distinto, porque han partido (creo) de LPCXpresso para crear MCUXpresso y fusionar LPC y Kinetis en un solo entorno de trabajo.

Ahora están metiendo los Kinetis en MCUXpresso a cabezazos, con soluciones cogidas por los pelos, como eso de tener que configurar un SDK para Kinetis desde su web para importarlo luego a MCUXpresso. Eso es una chapuza, que no te permite ligar automáticamente el código que generas con el SDK y tu código fuente, como si te hace el Cube de ST.

A ver si por lo menos se ponen las pilas, y van liberando pronto y rápido versiones decentes de MCUXpresso.

[planeta9999]

Por eso prefiero en muchos casos trabajar diréctamente con un editor de textos, sin IDE. Es lo mejor por ejemplo para pasar a otra persona tu configuración. Simplemente le envías el makefile y listo.

Ya, pero necesita hacer Debug, para eso Eclipse tiene que estar configurado, y eso a su vez supongo que genera su propio makefile que machacaría cualquier cosa que yo meta a mano en el fichero makefile generado por Eclipse.

Miraré de poner todos los parámetros del makefile de Teensy en Eclipse. Hay cosas que si que se por donde andan, como los parámetros de la optimización, indicarle que es un Cortex M4, todo el tema de los path de librerías.

[Picuino]

Por eso a la gente le gusta tanto Arduino. Es pinchar y listo.
Y para hacer debug, configuraré un DMA para que envíe un buffer de memoria por la UART y listo. Casi no consume pines ni tiempo de procesador. En el lado del PC recojo los valores y los presento en pantalla actualizados.

Si tengo que poner un breakpoint, añado una función que espere a un pin con pullup que se ponga a masa o que espere recepción de un dato por UART.
Un poco rústico, pero funciona.

Si veo que te da resultados los IDEs de NXP, pensaré en pasarme a ellos.

A propósito ¿Qué tipo debug necesitas hacer para que Arduino se quede corto?
Saludos.

[planeta9999]

A propósito ¿Qué tipo debug necesitas hacer para que Arduino se quede corto?
Saludos.

Uso siempre el Debug del entorno, en los ST y los Kinetis el GDB y OpenOCD. No suelo utilizar eso de encender leds y cosas por el estilo.

Lo que si estoy mirando ahora es a enlazar con Processing una placa que tiene un acelerómetro, para poder ver en tiempo real y de manera gráfica si se calculan bien los ángulos con la fórmula de los cuaterniones. Y de paso hacerle una presentación chula al cliente.

Y hace un momento, mirando la nueva versión que acaba de salir del libro Mastering STM32, me he encontrado con STMStudio, esto no lo conocía. Es una utilidad gratuita que permite por SWD ver en gráficos y en tiempo real el estado de cualquier variable. La ventaja es que no hay que habilitar ningún puerto especial para sacar los datos, todo se hace con el STLInk por SWD en tiempo de Debug.

[Picuino]

Eso gana a cualquier otro debug primitivo.
Lo que no sé es si realmente merece la pena el trabajo de pasarse a Eclipse para tener ese tipo de debug.
Si fuese algo sencillo del tipo pinchar y listo, no habría problema para elegir.

Un saludo.

[Carl47D]

¿Esto sirve para iniciar el debug?modifying-the-teensy-3-5-and-3-6-for-arm-swd-debugging, la persona del blog utiliza el KDS (no siempre hay que usar lo más actual o lo último que sacan los fabricantes), tuvo que añadir un header al footprint del header del SWD y remover el micro que graba el micro target de la teensy.

Si tienes el ejecutable puedes usar OpenOCD + arm-none-eabi-gdb + el ejecutable para depurar, eso si, todo desde la consola y no con la UI de Eclipse.

Saludos

[Picuino]

Estropean la pobre placa y la llenan de parches para poder hacer debug.

Definitivamente ese no es el camino.

[planeta9999]

¿Esto sirve para iniciar el debug?modifying-the-teensy-3-5-and-3-6-for-arm-swd-debugging, la persona del blog utiliza el KDS (no siempre hay que usar lo más actual o lo último que sacan los fabricantes), tuvo que añadir un header al footprint del header del SWD y remover el micro que graba el micro target de la teensy.

Si, ha quitado el Kinetis MKL02 que actúa de puente para cargar el ejecutable al MK64/66, y le ataca por SWD. Antes ha intentado anular ese chip, pero no lo ha conseguido porque le interfiere con las señales del SWD, al final a lo bestia, se carga el chip y a correr.

En mi caso no voy a hacer esos cambios, porque ya tengo una placa de diseño propio con un MK66, para el producto que estoy diseñando. En mi placa el bootloader, va por software y solo servirá para cargar actualizaciones de firmware, además va encriptado.

Los Teensy, los guardo tal cual, para pruebas, si alguien quiere poder hacer debug por JTAG o SWD mejor hacerse una plaquita propia y soldarle un micro nuevo. Comprarse un Teensy para reventarlo así, es innecesario.

[planeta9999]

Eso gana a cualquier otro debug primitivo.
Lo que no sé es si realmente merece la pena el trabajo de pasarse a Eclipse para tener ese tipo de debug.
Si fuese algo sencillo del tipo pinchar y listo, no habría problema para elegir.

Un saludo.

Todo eso te lo configura automáticamente Eclipse, no hay que hacer nada. Compilas para Debug, le das al botoncito de la "cucaracha" en la barra de herramientas y entras en Debug de inmediato.

Ahí lo tienes todo, el Debug de toda la vida, puedes añadir puntos de ruptura, avanzar paso a paso, ver el estado de cualquier variable simplemente pasando el puntero del ratón por encima, y unas cuantas cosas más.

Y con el STMStudio ves cualquier variable en tiempo real en modo gráfico, sin necesidad de crear ningún puerto físico para sacar los datos, esto lo tengo que probar, no lo había visto antes.

[Picuino]

Acabo de encontrarme con esto:
Teensy for Microsoft Visual Studio and Atmel Studio
http://www.visualmicro.com/page/Teensy-for-Microsoft-Visual-Studio.aspx

[planeta9999]

Acabo de encontrarme con esto:
Teensy for Microsoft Visual Studio and Atmel Studio
http://www.visualmicro.com/page/Teensy-for-Microsoft-Visual-Studio.aspx

Interesante, he probado con Visual Studio y funciona perfecto, eso si que es un señor entorno para gestionar un proyecto, si siguiera con Kinetis sería una solución perfecta.

Pero como he decidido portarlo a un Atmel SAM S70, se me complica la cosa, los fuentes del proyecto a portar son para Teensy, osea Kinetis, y el nuevo proyecto es para un ARM de Atmel, directamente no lo puedo pasar a Atmel Studio. Ya veré como me lo llevo, tendrá que ser a mano, pero ya tengo más o menos todo bien ubicado, no creo que me cueste mucho.

Al final todo queda en el mundo ARM, no puede ser tan difícil portar entre fabricantes. El compilador es el mismo, y la configuración de los entornos muy similar, básicamente definir bien los path a las librerías y configurar los parámetros del compilador/enlazador, de Cortex-M4 a Cortex-M7.

Saludos.

[planeta9999]

.

He estado mirando, de manera superficial todavía, como portar un proyecto Teensy/Kinetis/Arduino a SAM S70, usando Atmel Studio. Resulta algo complicado averiguar todo lo que esconde Arduino del proyecto, pero poco a poco me voy haciendo una idea.

Toda la parametrización del microcontrolador para el compilador está en el fichero C:\ARDUINO\hardware\teensy\avr\boards.txt.

La cascada de includes que llevan a la definición y asignación de puertos y demás del MK66 en Arduino, es la siguiente, partiendo de la aplicación a portar:  Arduino.h --> Wprogram.h --> wiring.h --> core_pins.h --> kinetis.h

Los archivos que marco en rojo, son la madre del cordero, los que definen el hardware del micro Kinetis MK66 del Teensy 3.6, para integrarlo en Arduino. Esos y otros ficheros están dentro del directorio C:\ARDUINO\hardware\teensy\avr\cores\teensy3\ de Arduino.

Ahora se trata de reemplazar esos archivos, con mi propio core que defina e integre el SAM S70 dentro de Arduino.

El proyecto lo estoy creando en Atmel Studio, que me permite trabajar tanto en modo nativo, como abriendo el proyecto original de Arduino (con un plugin). Si lo sigo trabajando como un proyecto Arduino, aún desde Atmel Studio, puedo introducir toda la parametrización del SAM S70 dentro del archivo boards.txt de Arduino, para que aparezca como una placa más.

Ahora lo complicado es definir los archivos core_pins.h y reemplazar el kinetis.h, por algo como sam.h. El fichero sam.h lo genera Atmel Studio cuando se crea un proyecto nativo para el SAM S70, falta ver si todas las definiciones de ese fichero tiene algo que ver con lo que necesita el core de Arduino.

El problema, para hacer el proyecto como nativo en Atmel Studio, es que el código fuente del que parto hace uso de la librería SmartMatrix, diseñada expresamente para Teensy/Arduino. Lo tengo que estudiar, si no lo veo muy complicado la idea es sacarlo todo del entorno Arduino. Si conociese al detalle las entrañas de Arduino, iría bastante rápido, así lo voy viendo sobre la marcha.