System Workbech y mis comienzos con ST

[elgarbe]

Movilizado por los excelentes post de planeta sobre la instalacion y configuracion de eclipse, la configuracion de Em::Block, el uso de Cube MX y metido en un proyecto en el que portaremos un proyecto de un dsPIC a un STM32F401 (u 411 en mi caso) es que decidí exponer las idas y vueltas de mis comienzos con ST.

Si bien no he hecho mucho con ARM, he podido hacer 3 o 4 proyectos, algunos de ellos con placa desarrollada por mi, siempre usando NXP. Desde que empecé a jugar cpn lpc1769 quedé encantado con NXP. Si bien en un principio no tenia IDE propio, tenía CodeRed que era gratuito con un limite de 256Kb, mas que suficiente para la mayoria de los proyectos con los que pensaba trabajar. Probé el 1347(M3 a 72MHz) y use el 11u67(M0+ a 50MHz). No hace mucho NXP compro parte de codered y lanzó su propio IDE, tambien con el límite de 256Kb. Lo bueno de este ide es que esta basado en eclipse, y al instalarlo se nos configura todo, absolutaente todo. Si bien al principio usaba las CMSIS como librerías, NXP no tardó en sacar su paquete LPCOpen. Si bien al principio habia muhos bugs, se fueron corrigiendo y hoy tiene un buen nivel de abstraccion. De lo único de que me puedo quejar de NXP es que no tiene, o yo no he visto muchas librerías de alto nivel, como implementacion de FatFS para todos los micros y otros. Pero tampoco he investigado demasiado el tema.

Ahora con ST he adquirido una STM32F411 NUCLEO (http://www.st.com/web/en/catalog/tools/PF260320). Esta placa tiene los conectores como arduino, lo cual permite utilizar los miles de shield existentes.

Para la programacion de la placa me he decidido ir por lo que creo es lo ultimo en ST, el System Workbench, obteniéndolo de OpenSTM32. Creo que esa página es la mejor fuente de informacion para instalar y usar este IDE. Viendo esto he decidido seguir esta guía

Entonces, comencemos.

El instalador offline lo pueden bajar de acá: http://www.ac6-tools.com/downloads/SW4STM32/install_sw4stm32_win_32bits-latest.exe
como ven, el instalador esta en ac6, ya que es algo así como la empresa encargada de desarrollar el system workbench.

En esta primer imagen de la instalacion podemos ver que este paquete instala todo lo necesario para desarrollar, programar y hacer debug con los micros ST:



aceptamos el acuerdo de licencia



elegimos el directorio de instalacion, el cual siempre combiene sea cercano al C: para evitar problemas



aceptamos los paquetes a instalar



aceptamos los Accesos Directos



y comenzamos con la instalacion



el segundo paso de la instalacion son los driver de la ST-Link





finalizada la instalacion




El siguiente paso es arrancar el SW y hacer un update para verificar que tengamos los ultimos paquetes de todo.
Al arrancar el SW nos pide que elijamos una carpeta que se utilizará como WorkSpace. Tambien combiene que este cerca del C: y sin espacios.



Cuando estamos ya en el SW buscaremos las actualizaciones:



esperamos un buen rato hasta que descarga todas las listas de sw actualizable:



y despues de dar un para de "Siguiente" empieza la actualizacion.



Una vez finalizado ya tenemos el SW listo para empezar atrabajar.
En el proximo post veremos como empezar con programas simples.

Saludos!

[xiran]

Q excelente post! Vine con la recomendacion de Carl47D, y es q estoy un poco liado con esto de arm, y sus variaciones, jeje. Quedo a la espera de los "hola mundo", ya q aun no he hecho conexion con arm, concretamente voy sobre stm32fx, de la gama mas barata, q es la f0. He de decirte q yo tb estoy interesado en desarrollar placas propias, con el fin de empaparme mas. Gracias de antemano!!!

[elgarbe]

El primer punto, que para mi es crucial, con los ARM es elegir que juego de librerías vamos a utilizar para programar nuestro micro. La inicializacion de un ARM no es como la de un PIC, hay mucho trabajo por hacer y por lo que he visto es bastante complicado. Es por ello que existen librerías y paquetes de software que trae sus rutinas de inicializacion así como funciones para usar los periféricos y demás.
ST va por el lado de STM32Fx Cube:

http://www.st.com/st-web-ui/active/en/catalog/tools/PF259243

por lo tanto este será nuestro punto de partida y es este paquete el que deberemos estudiar para comenzar. La idea es no caer de lleno a Cube MX (el entorno gráfico para la inicializacion del micro) sino tratar de hacer las cosas a mano y cuando se ponga dificil pues ahí recien ver el MX. Tener en cuenta que la mayoría empezamos con placas como la Discovery o las Nucleo y estos paquetes de software ya traen la inicializacion para esas placas, por lo que cosas como configurar el oscillador, habilitar la flash y demás están ya programadas. Ya tendremos un main listo para poner nuestro código.

Lo que sí hay que saber es que no es la única opcion y quizás en algún momento podamos ver alguna otra opcion de las que anda dando vueltas.

Este documento sera nuestra primer guía de estudio para entender como esta pensado el software STM32Fx Cube. A leer y seguimos en mas tarde!

sds.

[elgarbe]

Agrego este documento el cual es la descripcion de las funciones del HAL para los STM32Fx, ahí encontraremos todas las funciones y como usarlas.
Ese documento, junto al user manual del uC que estemos usando serán manuales de cabecera para desarrollar, por lo que deberían ser impresos y estar siempre a mano.

Sds.

[elgarbe]

Un pequeño intercambio de ideas acerca de usar el STM32Cube con sus HAL o ir directamente a escribir registros a mano.
http://www.eevblog.com/forum/microcontrollers/stm32f4xx-hal-drivers/

Como para ir ubicándose, programar con usando STM32Cube es como usar las librerías que vienen de microchip. Si bien en ARM son un poco más necesarias, tambien esta la posibilidad de no usarlas y escribir los registros directamente a mano. Estoy preparando unos ejemplos de cada uso para que se vea la diferencia.

Sds.

[planeta9999]

Lo más básico para empezar, sin usar Cube, es aprender a configurar el oscilador, tipo, frecuencia, PLL, multiplicadores y divisores, oscilador secundario.

En cuanto a usar HAL, por supuesto que si, si ya te lo dan todo bien definido para cada periférico, no tiene sentido perder el tiempo reescribiéndolo todo de nuevo. En cuanto a lo que dicen en ese foro, sobre la falta de documentación, puede que tengan razón, pero eso está paliado con Cube, que si te documenta bastante bien en el main las llamadas a todas las funciones de las librerías que has incluido.

[elgarbe]

Lo más básico para empezar, sin usar Cube, es aprender a configurar el oscilador, tipo, frecuencia, PLL, multiplicadores y divisores, oscilador secundario.

En cuanto a usar HAL, por supuesto que si, si ya te lo dan todo bien definido para cada periférico, no tiene sentido perder el tiempo reescribiéndolo todo de nuevo. En cuanto a lo que dicen en ese foro, sobre la falta de documentación, puede que tengan razón, pero eso está paliado con Cube, que si te documenta bastante bien en el main las llamadas a todas las funciones de las librerías que has incluido.

La idea es ir sacando nuestras propias conclusiones siendo lo mas objetivo posibles. No hay que dejarse llevar por nuestros gustos. Si es buena documentacion o no la del HAL lo veremos al usarla, lo que se habla en EEVBlog es solo un ejemplo, para los que no estan familiarizados con ARM y quieren arrancar, sepan cuales son las alternativas y distintas opiniones de distintos usuarios que alguna vez estuvieron en el lugar de "Recien arranco"

Tambien debo decir que hay veces donde sí es conveniente reescrivir cosas. Me imagino que si necesito una funcion que escriba 1 byte en un puerto y active una señal tipo WR y eso se debe hacer rápido porque esa fucion es llamada muchas veces, pues no creo que usaría HAL_SetPin para eso. Estoy seguro que escriviría los registros a mano y me ahorraría algunos ciclos de la implementacion genérica de la funcion SetPin (o como se llame).

Como dije, la idea es hacer nuestra propia experiencia y tratar de explotar al máximo lo que cada herramienta nos da, pero nunca casarnos con una y desconocer el resto. No te olvides que ST tenía la StandarPeripheralLibrary y de buenas a primera pasaron a HAL. Muchos usuarios estan muy molestos por eso. Y eso pasa en la mayoría de las marcas. NXP hacia uso unicamente de las CMSIS y tenía algunas librerías propias hasta que sacó su LPCOpen. Ni bien salio estaba llena de bugs y nadie quería usarlas. Tardaron un buen tiempo en aceptarlas y los programadores mas experimentados no harán uso de ella.

En el link que me pasaste (http://stm32f4-discovery.com/) hay un claro ejemplo de un usuario que prefiere hacer sus propias librerías, basadas en CMSIS y las STD periph drivers . En el primer ejemplo ya habla de usar las funciones del CMSIS:
http://stm32f4-discovery.com/2014/04/stm32f429-discovery-gpio-tutorial-with-onboard-leds-and-button/

y tambien mensiona en sus ultimos trabajos el problema que se presenta con el cambio de st hacia HAL

http://stm32f4-discovery.com/2015/03/library-53-gpio-for-stm32f4/

En fin, cada forma de trabajar tiene sus pros y contras. Tomar una y desconocer el resto no es lo mejor para el que recien empieza, por eso trataremos de mostrar un poco de todo.

Saludos!

[planeta9999]

Llegado el caso podríamos abrir una web en español y cuenta en Facebook, dedicada a los STM32 o incluso en general a los ARM incluidos la RPY y la BBB, con toda la documentación, librerías, ejemplos y tutoriales en español.

Tengo un server dedicado, puedo colgar una web hecha en Joomla, con blog, noticiero, entorno social y zona de descargas para librerías, ejemplos y tutoriales. En el tema del dominio tengo algunos registrados o se puede registrar uno concreto, de los dominios que tengo, www.tecnoocio.com le pega con cualquier temática técnica.

[cristian_elect]

Un pequeño intercambio de ideas acerca de usar el STM32Cube con sus HAL o ir directamente a escribir registros a mano.
http://www.eevblog.com/forum/microcontrollers/stm32f4xx-hal-drivers/

Como para ir ubicándose, programar con usando STM32Cube es como usar las librerías que vienen de microchip. Si bien en ARM son un poco más necesarias, tambien esta la posibilidad de no usarlas y escribir los registros directamente a mano. Estoy preparando unos ejemplos de cada uso para que se vea la diferencia.

Sds.

De eso de reducir el codigo yo lo hago algo mas pequeño claro viendo el pdf del micro para hacerlo.
Definiendo punteros de memoria.
Un ejemplo.

#define PORT_LCD   (*((volatile unsigned long *)0x48000014)) //PortA ODR cortex m0

Así puedo adaptar mi codigo lcd de un micro a otro de diferente fabricante.
También defino para configurar el puerto y activarlo para que solo llamar iniciar lcd_init() ya este configurado todo el puerto.
Si tienes tiempo defines los bits mas usados de una formula de direcionamiento que esta en el manual de ARM cortex m.
Para los que quieren mas optimizacion.
Bajen el pdf "igs-stm32-v18d-scr.pdf" en internet en la pagina 19 y 20 hay formulas para controlar bits y así reducen código.

[elgarbe]

Llegado el caso podríamos abrir una web en español y cuenta en Facebook, dedicada a los STM32 o incluso en general a los ARM incluidos la RPY y la BBB, con toda la documentación, librerías, ejemplos y tutoriales en español.

Tengo un server dedicado, puedo colgar una web hecha en Joomla, con blog, noticiero, entorno social y zona de descargas para librerías, ejemplos y tutoriales. En el tema del dominio tengo algunos registrados o se puede registrar uno concreto, de los dominios que tengo, www.tecnoocio.com le pega con cualquier temática técnica.

si bien tiempo no me sobra, pues es muy interesante la idea y es una muy buena forma de aprender... cuenta conmigo...

sds.

[juaperser1]

alguien esta probando todo esto en linux? he oido que también esta para linux no? si alguien lo ha probado me gustaría mucho saber sus impresiones.

muchas gracias y saludos.

[elgarbe]

alguien esta probando todo esto en linux? he oido que también esta para linux no? si alguien lo ha probado me gustaría mucho saber sus impresiones.

muchas gracias y saludos.

No, mirá acá:

http://www.openstm32.org/Downloading+the+System+Workbench+for+STM32+installer

especificamente:

"Linux

To be able to download and test System Workbench for STM32 on Linux, you should request access to System Workbench as beta tester by sending a mail to the webmaster explaining why you would like to became a beta tester. "

saludos

[juaperser1]

No, mirá acá:

http://www.openstm32.org/Downloading+the+System+Workbench+for+STM32+installer

especificamente:

"Linux

To be able to download and test System Workbench for STM32 on Linux, you should request access to System Workbench as beta tester by sending a mail to the webmaster explaining why you would like to became a beta tester. "

saludos

vaya por dios mi gozo en un pozo xd.

la mayoria de sistemas embebidos y compiladores estan realizados con ayuda de sistemas opensource incluido gcc, la mayoria a tomado eclipse y gcc y ala mira he hecho un IDE para esto...en fin, a ver si empiezan las compañias a agradecer todo lo que deben a los sistemas linux y de opensource

[elgarbe]

vaya por dios mi gozo en un pozo

NT: "Se usa este dicho para significar que ha fracasado algo en lo que se habían puesto muchas esperanzas de éxito o que algo no ha resultado como se esperaba. <<Todos creíamos que estos días iba a salir el sol y podríamos salir al campo, pero nada, nuestro gozo en un pozo, porque no ha parado de llover ni un instante>>."

 

[juaperser1]

NT: "Se usa este dicho para significar que ha fracasado algo en lo que se habían puesto muchas esperanzas de éxito o que algo no ha resultado como se esperaba. <<Todos creíamos que estos días iba a salir el sol y podríamos salir al campo, pero nada, nuestro gozo en un pozo, porque no ha parado de llover ni un instante>>."

Pues eso mismo: yo creia que ya estaba disponible para linux = todos creiamos que estos dias iba a salir el sol y podriamos salir al campo

por lo tanto mi gozo en un pozo jaja