TODOPIC

Otros Microcontroladores / Dispositivos programables => Microcontroladores ARM => Mensaje iniciado por: Picuino en 28 de Mayo de 2017, 13:10:04

Título: Primeros pasos con System Workbench
Publicado por: Picuino en 28 de Mayo de 2017, 13:10:04
Estoy comenzando con el System Workbench (Eclipse adaptado para STM32) en Windows y tengo algunas dudas.

No consigo compilar el proyecto. El compilador está instalado en Plugins, pero no lo reconoce. Puede que se deba a que sobreescribí el SystemWorkbench de 64bit sobre el antiguo de 32bit.

¿Cómo puedo añadir la ruta del compilador en Eclipse?

Lo he intentado con Help... Install new software... Add... Archive...
file:/D:/Bin/SystemWorkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.13.2.201703061525/

Pero no funciona.

Project... Properties...
Está desactivado, por lo que no puedo modificarlo.

Se me han acabado las ideas.
Título: Re:Primeros pasos con System Workbench
Publicado por: elgarbe en 28 de Mayo de 2017, 14:42:52
que sería no lo reconoce? que error te da al compilar?
Título: Re:Primeros pasos con System Workbench
Publicado por: Picuino en 28 de Mayo de 2017, 16:30:42
He vuelto a instalar SystemWorkbench. Al iniciar, ha vuelto a descargar el GNU ARM Toolchain y ya está integrado.

Ahora el problema está en las librerías. He descargado el archivo stm32CubeF4 pero no sé cómo integrarlo en Eclipse.
Me dan muchos errores al compilar por falta de librerías:
Citar
Description   Resource   Path   Location   Type
Field '__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1)' could not be resolved   main.c   /Project0/Src   line 176   Semantic Error

Un saludo.
Título: Re:Primeros pasos con System Workbench
Publicado por: Picuino en 28 de Mayo de 2017, 16:49:17
Ok. Ya he resuelto el problema. He tenido que ejecutar Project... Index... Rebuild.
También ha hecho falta seleccionar en las opciones de proyecto que genere su propio Makefile y al final ha compilado el proyecto sin errores.

Ahora quiero cargar el programa en la placa con el JLink. ¿Cómo se puede hacer desde Eclipse?
Título: Re:Primeros pasos con System Workbench
Publicado por: cristian_elect en 03 de Octubre de 2017, 23:56:18
Ya probé este compilador funciona pero consume mucha memoria flash yo uso micros con 16K y 32K se llena con poco código sobre todo si uso funciones de stdio.h. Seguiré con el Keil ya que es libre hasta los 32K.
Título: Re:Primeros pasos con System Workbench
Publicado por: juaperser1 en 04 de Octubre de 2017, 06:17:16
El compilador es el GCC, yo no veo que consuma mas memoria.

Ahora el systemworbench es mucho mas sencillo de instalar y viene todo configurado, solo hay que hacer algunos ajustes y bajarse algunas librerias hace un tiempo hice un video sobre como instalarlo y algunos mas sobre crear un proyecto base encendiendo un led con la discovery F4, cube y las hall:




Título: Re:Primeros pasos con System Workbench
Publicado por: tsk en 04 de Octubre de 2017, 13:51:44
Cita de: cristian_elect en 03 de Octubre de 2017, 23:56:18
Ya probé este compilador funciona pero consume mucha memoria flash yo uso micros con 16K y 32K se llena con poco código sobre todo si uso funciones de stdio.h. Seguiré con el Keil ya que es libre hasta los 32K.

¿Realmente ocupa mucha más FLASH? Hay que diferenciar entre el compilador y las librerías que usas.

De aquí

http://www2.keil.com/mdk5/compiler/6/

Comparan GCC 5.2 con O3, ARMCC 5.06 O3 y la versión del ARM Compiler 6.6

Citar
GCC 5u2 O3              10288
ARMCC 5.06 O3           10084
ARM Compiler 6.6 Ol     10168
ARM Compiler 6.6 Os     9608
ARM Compiler 6.6 Oz     9148
ARM Compiler 6.6 Oz LTO 7304
Bajo las siguientes condiciones

1.- RTOS (Keil RTX 5) con parpadeo de LED
2.- LPCXpresso5411 con LPCOPen.

Y supuestamente con el gcc con la más alta optimización enfocada en el tamaño.

Citar
The values for gcc were created using the highest optimization, with an emphasis on size

Lo cual es una reverenda mentira ya que, según el manual del GCC (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html)

-O2 Balance entre tamaño del binario contra la velocidad
-O3 Rendimiento a costo de incrementar el tamaño del binario.
-Os Tamaño del binario a costa de reducir la velocidad.

Y según la gráfica están usando -O3.

Si lo comparamos con lo que dice aquí

https://developer.arm.com/docs/dui1093/latest/using-common-compiler-options/selecting-optimization-options

Ellos mismos afirman que -O3 es para incrementar el rendimiento a costa de incrementar el tamaño del programa, aun en su compilador.

Así que el resultado que presentan puede ser no del todo correcto y un poco manipulado. No estoy diciendo que GCC produzca binarios más pequeños, pero probablemente sean algo más similares o al menos no tan separados como lo quieren mostrar, porque si tu eres un gerente de compras y te muestran una diferencia de un poco más del 40%, pues está claro con quien te vas a ir.

Pero eso es con la versión 5.2 de GCC, por lo que si nos vamos con la última versión del GCC probablemente realice un mejor trabajo.

Por lo menos una aplicación de ejemplo que tengo con FreeRTOS+CubeHAL+BlinkLED (para tener un ejemplo parecido) apenas usa 6412 bytes con -Os. Pero si uso -O3 este valor se incrementa a 7336 bytes, con -O2 6912 bytes y con -O1 7004 bytes. No veo que pase siquiera de los 7500 bytes aún usando -O3.

Pero lo mas seguro es que System Workbench esté usando la versión 5.X y no la última, por lo que tengo que determinar que la reducción considerable no sea por motivos de la versión que uso.

Tenía un ejemplo compilado con versión 5.X del GCC, y estos eran los resultados.

Código: [Seleccionar]
$ arm-none-eabi-size demo.elf
   text    data     bss     dec     hex filename
  18500     364    3716   22580    5834 demo.elf

La recompilé con la versión más reciente (6.3.1) que tengo instalada, y estos fueron los resultados.

Código: [Seleccionar]
Linking C executable demo.elf
   text    data     bss     dec     hex filename
  17936     364    3716   22016    5600 demo.elf

Son 564 bytes de diferencia, pero no explica la gran diferencia que muestran los resultados presentados por Keil, aunque hay que reconocer que la última versión de GCC realizan un mejor trabajo.

Vamos a ver con respecto al ejemplo que nos muestran aquí

https://developer.arm.com/docs/dui1093/latest/using-common-compiler-options/selecting-optimization-options

Donde con su compilador y usando -O1

Código: C
  1. int dummy()
  2. {
  3.     int x=10, y=20;
  4.     int z;
  5.     z=x+y;
  6.     return 0;
  7. }

obtienen

Código: ASM
  1. dummy:
  2.     .fnstart
  3.     movs r0, #0
  4.     bx lr

Si aplicamos lo mismo para GCC

Código: [Seleccionar]
arm-none-eabi-gcc -c file.c -O1
Código: ASM
  1. Disassembly of section .text:
  2.  
  3. 00000000 <dummy>:
  4.    0:   e3a00000        mov     r0, #0
  5.    4:   e12fff1e        bx      lr

En cierto sentido el resultado depende más de las librerías que estés usando, por lo que puedes tener un sistema que parpadee un LED por tan sólo unos cuantos bytes (100, 180 bytes) u otro que haga lo mismo con un consumo superior, no por el compilador, sino por las librerías.
Título: Re:Primeros pasos con System Workbench
Publicado por: cristian_elect en 07 de Octubre de 2017, 12:00:59
Uso las librerías que viene con el propio gcc. Me dan ejemplos de suma y resta eso son funciones simples prender led o sumas o restas; yo me refiero a stdio.h usando numeros flotantes o enteros grandes. Yo uso micros chicos se llena rápido no se si ustedes han usado los Cortex M0 16K flash con el keil entra bien y con Iar toma un poco mas de memoria.
Título: Re:Primeros pasos con System Workbench
Publicado por: tsk en 07 de Octubre de 2017, 15:33:06
Bueno el FreeRTOS no sólo es un ejemplo de sumas y restas, pero aún así esos ejemplos ayudan a entender que está mas relacionado con las librerías.

El problema es usar números flotantes en un sistema que no cuenta con el hardware es que el binario va incrementarse bastante. En un determinado caso podrías optar por enteros y puntos fijos.

Lo que no sé es porque del uso del stdio.h, cuales funciones estas usando. Para manejar cadenas uso string.h y las funciones sprintf y strlen pero sólo me aumenta alrededor de 2K,o un poco menos,el tamaño del binario.

Así por ejemplo, con -Os, agregando, UART, sprintf y  strlen

Código: C
  1. void StartDefaultTask(void const * argument)
  2. {
  3.  
  4.   /* USER CODE BEGIN StartDefaultTask */
  5.   /* Infinite loop */
  6.   for(;;)
  7.   {
  8.                 HAL_GPIO_TogglePin(GPIOC,GPIO_PIN_13);
  9.                 sprintf(data,"Hello World %d %s\n",strlen(data2),data2);
  10.                 HAL_UART_Transmit(&huart3,(uint8_t *) &data[0],strlen(data),100);
  11.     osDelay(1000);
  12.   }
  13.   /* USER CODE END StartDefaultTask */
  14. }

Tenemos que el tamaño del binario es de
text  9304 bytes
data   128 bytes
Total 9432 bytes

Nota: Recuerda que estoy usando las HAL y no las LL

Ahora declaro un float con el valor de pi y lo mando a imprimir a la consola

Código: C
  1. void StartDefaultTask(void const * argument)
  2. {
  3.  
  4.   /* USER CODE BEGIN StartDefaultTask */
  5.   /* Infinite loop */
  6.   for(;;)
  7.   {
  8.                 HAL_GPIO_TogglePin(GPIOC,GPIO_PIN_13);
  9.                 sprintf(data,"Hello World float %f %d %s\n",pi,strlen(data2),data2);
  10.                 HAL_UART_Transmit(&huart3,(uint8_t *) &data[0],strlen(data),100);
  11.     osDelay(1000);
  12.   }
  13.   /* USER CODE END StartDefaultTask */
  14. }

text  10224
data    132
Total 10356 bytes

Si ya comienzas a hacer algo más complejo que imprimir esto puede incrementarse dependiendo de las funciones que usemos.

Código: C
  1. pi2 = 2.0*pi;
  2. sprintf(data,"Hello World float %f %d %s\n",pi2,strlen(data2),data2);

text 10784
data 132

Código: C
  1. pi2 = 2.0*pi;
  2. pi2 = pi2 + 3.16;

text 10976
data 132

Y en definitiva la división es lo que ocupa más

Código: C
  1. pi2 = 2.0*pi;
  2. pi2 = pi2 + 3.16;
  3. pi2 /= 10.45678;
text 12064
data 132

Entonces ahí viene el hecho de que todo se puede optimizar, por ejemplo que pasaría si cambio

Código: C
  1. HAL_GPIO_TogglePin(GPIOC,GPIO_PIN_13);

Por

Código: C
  1. GPIOC->ODR ^= GPIO_PIN_13;

text 12056
data   132

Así de pronto ya te quitaste 8 bytes de encima.

Otro más

Código: C
  1. pi2 = 3.16 + 2.0*pi;
  2. pi2 /= 10.45678;
text 11512
data 132

Código: C
  1. float pi=3.141592;
  2. #define p2 3.16
  3. #define p3 2.0
  4. #define p4 10.45678
  5.  
  6. pi2 = (p2 + p3*pi)/p4;
text 11512
data 132

Código: C
  1. #define pi 3.141592
  2. #define p2 3.16
  3. #define p3 2.0
  4. #define p4 10.4567890123456789

text 9352
data  128

Código: C
  1. #define pi 3.141592
  2. #define p2 3.16
  3. float p3 = 2.0;
  4. float p4= 10.4567890123456789;
  5. float pi2;

text 11528
data   136

Código: C
  1. p3 += 1.0;
  2. p4 -= 0.001;
  3. pi2 = (p2 + p3*pi)/p4;
text 12120
data   136

Código: C
  1. p3 += 1.0;
  2. p4 -= 0.001 * pi2;
  3. pi2 = (p2 + p3*pi)/p4;
text 12136
data   136

Probablemente parezca sencillo el ejemplo, pero aún no he pasado de los 16K y existe la posibilidad de usar calcular funciones más complejas.

Me dirás, bueno no has agregado el ADC (ADC1 - IN0, IN1, IN2, Temperature), CRC, DMA para el ADC, Timer 1.

Con tan sólo agregarlos (todavía no usarlos)

text 14960
data 136

Esto usando las HAL no las LL que está disponibles para el M0 y esto me dice que es enteramente posible generar una aplicación relativamente compleja que entre en estos MCUs usando GCC.

Recuerda que se esta usando FreeRTOS, pero no creo que lo estés usando, por lo que podrías remover alrededor de 2 a 3K del binario, quedando la aplicación de arriba en unos 11K, pero si usas las LL en lugar de las HAL, este valor todavía puede caer por debajo de los los 10 o incluso de los 9K. Con lo que todavía se le puede meter bastantes operaciones más.

Así por ejemplo, con las características de tener ADC, CRC, DMA, UART y Timer 1, con las LL el peso del binario inicial sería

text  2736 bytes
data    12 bytes
Total 2748 bytes

si añadimos string.h, probablemente aumente entre 4 a 5K
si añadimos operaciones de punto flotante que incluyan suma, resta, multiplicación y división le agregamos otros 2.5K, por lo cual el binario estaría rondando entre los 6 a 7K e incluso podría estar rozando los 8K, todavía sin hacer uso de las funciones del ADC, CRC, UART, etc., pero aún así calculo que no pasaría de los 10K en estas condiciones.
Título: Re:Primeros pasos con System Workbench
Publicado por: cristian_elect en 07 de Octubre de 2017, 19:30:45
Con keil logre meter funciones stdio.h con operaciones con números flotantes mas la librería de display 128*128 de color mas con lectura de varios adc, interrupción de timers toma 10K  aproximado incluyendo funciones de control. El System Workbench lo borre por problema que no podía actualizarlo siempre me salía error, pero mucho antes si normal actualizaba. Con el ggc me sale este error " undefined reference to `_sbrk' " sera memoria llena.
Título: Re:Primeros pasos con System Workbench
Publicado por: tsk en 07 de Octubre de 2017, 23:25:35
Lo del _sbrk está relacionado cuando direccionas el printf a una terminal como UART o SWO, no es por falta de memoria, es más porque faltan los archivos que implementan las funciones.

Esto se hace para que en lugar de tener

HAL_UART_Transmit(&huart1, ...

lo hagas con

printf(...

Pero en cierto sentido no es recomendable usar printf. Con s(n)printf puedes obtener al mismo tiempo el tamaño del string resultante

len = sprintf(buff,"format",...);

Por otro lado comparar se hace en las mismas condiciones.

Y aquí está una comparación entre el gcc y armcc (armclang ni siquiera pudo compilar el FreeRTOS)

arm-none-eabi-gcc
.text 14960
.data   136
Total 15096

Code  13396
RO-data 324
RW-data 140
Total 13860

Lo que representa un 8.9% de diferencia, y esto es bajo las mismas condiciones.

Así que si generas el código inicial con CubeMX, esta es la diferencia que podrías esperar, entre un programa compilado con armcc y arm gcc, bajo las mismas condiciones. Con la versión de arm gcc 5.X la diferencia se estimaba entre 10 a 20%. Así que si tu programa ocupa 10K dale un margen del 10% para lo mismo generado por el arm gcc, lo que sería aproximadamente 11K, aunque si te quieres ir a lo seguro y pensar en el peor de los casos (20%) el resultado sería de 12K.

En si no requieres contar con el System Work Bench ya que CubeMX puede generar un Makefile, en determinado momento podrías probar con la última versión que puedes descargar de aquí

https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

O la versión 7.2 de

http://www.freddiechopin.info/pl/download/category/11-bleeding-edge-toolchain
Título: Re:Primeros pasos con System Workbench
Publicado por: cristian_elect en 08 de Octubre de 2017, 00:28:34
Bueno probare esta ultima vercion AC6 ya que la anterior no la pude actualizar por problemas del mismo software y lo deje de usar. Los clones chinos de stm32f103c8t6 bienen con 128K de flash y probe que si se puede usar toda la memoria no se si estos micros son confiables para usarlos en unos trabajos.
Título: Re:Primeros pasos con System Workbench
Publicado por: cristian_elect en 08 de Octubre de 2017, 16:19:17
Tengo problemas con el Stm32cube con el stm32f103c6 no lo genera el codigo para sw4stm32 sale error, le cambio a stm32f103c8 y lo genera pero hay un problema a la hora compilar sale error no reconoce "uint32_t, uint16_t ...etc." en stdint.h no hay esas typedef, pero en cortex m0 no tengo problemas.
Título: Re:Primeros pasos con System Workbench
Publicado por: tsk en 08 de Octubre de 2017, 18:12:40
Por lo general evito usar los IDEs, ya que los considero algo pesados, pero probé con la instalación que tengo del System Work Bench y compiló sin problemas, pero es bajo Linux. En un rato pruebo con en un Windows para ver si pasa lo mismo.

Otra opción es que generes lo generes con el Makefile

Descargas el toolchain de
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

Lo instalas y editas el archivo Makefile para modificar la línea

BINPATH =

por

BINPATH = "C:\Program Files\GNU Tools ARM Embedded\6 2017-q2-update\bin"

Y para disminuir el tamaño del código cambias

OPT = -Og

por

OPT = -Os

Después descargas el Cygwin de

http://www.cygwin.com/

Y lo instalas seleccionando la utilidad make

(https://i.imgur.com/13Ql3wZl.png)

En el escritorio vas a tener un ícono con el nombre Cygwin Terminal.

Lo abres y navegas al directorio del proyecto

Por ejemplo si está en el estritorio

Código: [Seleccionar]
cd ../../cygdrive/c/Users/alex/Desktop/proyectoPrueba
Y ya con el Makefile modificado procedes a ejecutar

Código: [Seleccionar]
make
(https://i.imgur.com/wjWv3ehl.png)