Dudas STM32CubeMX

[KILLERJC]

Pero de todas formas ese no es el problema, el problema es que segun el codigo auto-generado por el CubeMx, Deberia ser 168Mhz, y no 16.
Es como si en tu codigo pusiera que el SystemCoreClock, fuera de 8Mhz.

Esa es su duda.

[planeta9999]

 
Lo que Cubemx genera, está siempre bien, no tiene sentido ponerse a urgar en el fuente. Además el Systick, que viene a ser como el millis() en Arduino, se utiliza para medir tiempos entre eventos, y da igual cual sea su frecuencia base.

Una cosa es querer entender el contenido del fuente que genera Cubemx, y otra cuestionarlo, estar bien, esta bien seguro.

En mi programa que tiene activado el oscilador a cuarzo de 8Mhz, con el PLL para sacar 168Mhz, tiene eso mismo puesto en el fuente, pero si miramos más abajo en el mismo fuente, SystemCoreClock se carga con el valor de HSI_VALUE o HSE_VALUE, según hayamos elegido el oscilador a cuarzo o RC, y el PLL.

Código: C

1. switch (tmp)
2.   {
3.     case 0x00:  /* HSI used as system clock source */
4.       SystemCoreClock = HSI_VALUE;
5.       break;
6.     case 0x04:  /* HSE used as system clock source */
7.       SystemCoreClock = HSE_VALUE;
8.       break;
9.     case 0x08:  /* PLL used as system clock source */
10.  
11.       /* PLL_VCO = (HSE_VALUE or HSI_VALUE / PLL_M) * PLL_N
12.          SYSCLK = PLL_VCO / PLL_P
13.          */    
14.       pllsource = (RCC->PLLCFGR & RCC_PLLCFGR_PLLSRC) >> 22;
15.       pllm = RCC->PLLCFGR & RCC_PLLCFGR_PLLM;
16.      
17.       if (pllsource != 0)
18.       {
19.         /* HSE used as PLL clock source */
20.         pllvco = (HSE_VALUE / pllm) * ((RCC->PLLCFGR & RCC_PLLCFGR_PLLN) >> 6);
21.       }
22.       else
23.       {
24.         /* HSI used as PLL clock source */
25.         pllvco = (HSI_VALUE / pllm) * ((RCC->PLLCFGR & RCC_PLLCFGR_PLLN) >> 6);
26.       }
27.  
28.       pllp = (((RCC->PLLCFGR & RCC_PLLCFGR_PLLP) >>16) + 1 ) *2;
29.       SystemCoreClock = pllvco/pllp;
30.       break;
31.     default:
32.       SystemCoreClock = HSI_VALUE;
33.       break;
34.   }

Yo no perdería el tiempo con esas cosas, lo que hace Cubemx, siempre está bien. Lo que no se aún cual es el problema, si es que hay algún problema, querer tocar la frecuencia de base que usa Systick, no sirve para nada.

Además si leemos las notas que aparencen en el fuente, lo aclaran mejor:
If SYSCLK source is PLL, SystemCoreClock will contain the HSE_VALUE(**) or HSI_VALUE(*) multiplied/divided by the PLL factors.

Código: C

1. Each time the core clock (HCLK) changes, this function must be called
2.   *         to update SystemCoreClock variable value. Otherwise, any configuration
3.   *         based on this variable will be incorrect.        
4.   *    
5.   * @note   - The system frequency computed by this function is not the real
6.   *           frequency in the chip. It is calculated based on the predefined
7.   *           constant and the selected clock source:
8.   *            
9.   *           - If SYSCLK source is HSI, SystemCoreClock will contain the HSI_VALUE(*)
10.   *                                              
11.   *           - If SYSCLK source is HSE, SystemCoreClock will contain the HSE_VALUE(**)
12.   *                          
13.   *           - If SYSCLK source is PLL, SystemCoreClock will contain the HSE_VALUE(**)
14.   *             or HSI_VALUE(*) multiplied/divided by the PLL factors.
15.   *        
16.   *         (*) HSI_VALUE is a constant defined in stm32f4xx_hal_conf.h file (default value
17.   *             16 MHz) but the real value may vary depending on the variations
18.   *             in voltage and temperature.  
19.   *    
20.   *         (**) HSE_VALUE is a constant defined in stm32f4xx_hal_conf.h file (its value
21.   *              depends on the application requirements), user has to ensure that HSE_VALUE
22.   *              is same as the real frequency of the crystal used. Otherwise, this function
23.   *              may have wrong result.

[Thulsa Doom]

El problema es que me gusta saber lo que se está haciendo y entender un poco el código fuente, mi idea es usar ese systick para eso mismo que comentas, para lo mismo que el mills en arduino o el tick en pic, y ponerme a practicar encendiendo un led a diferentes velocidades, en definitiva cacharrear un poco, por eso me puse a investigar de donde viene cada cosa y vi que en esa línea no cambiaba la frecuencia del cristal al cambiarla en el Cube, por eso pregunté por que al igual o yo estaba haciendo algo mal en el Cube o no instalé bien el software o algo

[planeta9999]

 
No cambia en el valor por omisión que le da a la variable, al declararla. Pero si miras más abajo en el fuente, si que le asigna un valor, según el tipo de oscilador que hayas configurado, RC o a cuarzo, y también si activaste el PLL.

Yo el chequeo de tiempos entre eventos, lo estoy usando con Kinetis, y aunque también es un ARM y usa el mismo compilador, al estar bajo el entorno de Arduino, le han creado la función millis() y micros(), para medir el tiempo que ha pasado en milisegundos y microsegundos. Seguro que estás funciones hacen la lectura del Systick.

En los STM32 no he tenido necesidad de usarla, pero algo leí hace tiempo, porque buscaba el millis() y no lo encontraba por ninguna parte. Al final el Systick es lo mismo, y si estas acostumbrado a usar el millis() de Arduino, puedes crearte tu propia función millis() y meterle allí el Systick.

Por Google anda como crear tu millis() para STM32

Código: C

1. volatile uint32_t ticks;
2. extern "C" void SysTick_Handler (void)
3.  {
4.    ticks++;
5.  }
6.  
7.  
8. // return the system clock as milliseconds
9. inline uint32_t millis (void)
10. {
11.    return ticks;
12. }

[Thulsa Doom]

Siento ser cabezota pero si no entiendo el código fuente no me encuentro ni seguro de lo que estoy haciendo ni agusto prorgamando, ya he tenido problemas en el pasado intentando usar la librería TCP/IP de microchip, intenté controlar periféricos externos y se me hizo un lío por que no podría poner el código en cualquier parte, tuve que estudiar la librería para integrar mis modificaciones y que no generara conflicto, me supuso un curro tremendo, me tuve que sentar con una hoja de papel y un lápiz y hacerme un esquema de flujo para poder entenderla  , si lo sé, ya se que van a decir.. que soy un bruto pero que quieren que les diga... pues si jajajaja.

A lo que voy, más o menos te he entendido, lo que tengo dudas, se supone que la función:

Código: [Seleccionar]

void SystemCoreClockUpdate(void) es la encargada de actualizar el valor del reloj del sistema, ¿no?.
Entonces siguiendo el flujo del sistema veo algo que no me cuadra y es que en ningún momento veo que se llame a a esa función para actualizar el reloj. si nos fijamos en el archivo main.c vemos las funciones de configuración de puertos, reloj, periféricos y demás.



Pues en la función

Código: [Seleccionar]

HAL_Init(); se supone que se configura la base de tiempos de 1ms


Pues si nos vamos a esa función se ve como se configura o se ajusta el tiempo de 1ms a la velocidad del cristal que no coincide con lo que hemos seleccionado, en mi caso cristal externo de 8MHz



Entonces si nos llevamos por eso ¿lo propio no sería decirle al sistema que actualice el la velocidad del cristal con la función

Código: [Seleccionar]

SystemCoreClockUpdate() antes de las configuraciones generales, de esta manera?



Al igual estoy equivocado por que soy un simple aficinado y esto se hace automáticamente de otra manera que no lo veo, en fin no sé.

Todo esto es porque estoy implementando la librería tick de micro chip y estoy a ver que me hace falta y lo que no, ósea lo que se está ya ejecutando y lo que no para eliminarlo o añadirlo ya que la librería tick se vasa en la velocidad de preescales para ajustar los tiempos a 1sg, 1 minuto y una hora, tengo hecho algo pero me falta lo que comento para ajustarlo bien.

.

Pero al igual es un disparate lo que hago 

[KILLERJC]

En la funcion:

Código: C

1. void SystemClock_Config(void)

Se llama a la funcion:

Código: C

1. HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

la funcion HAL_RCC_GetHCLKFreq actualiza el SystemCoreClock (con los preescalers) y devuelve su valor:

Código: C

1. SystemCoreClock = HAL_RCC_GetSysClockFreq() >> AHBPrescTable[(RCC->CFGR & RCC_CFGR_HPRE)>> POSITION_VAL(RCC_CFGR_HPRE)];
2.   return SystemCoreClock;

[Thulsa Doom]

Me van a perdonar pero sigo sin verlo.   

[KILLERJC]

Perdona, por no tener las fuentes utilice lo que encontre en internet, que son las fuentes colgadas por mbed.

Ahora en casa, con la ultima versiona de las HAL para F4 tengo que dentro de SystemConfig_Clock tenes esto:

Código: C

1. if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5) != HAL_OK)
2.   {
3.     _Error_Handler(__FILE__, __LINE__);
4.   }

Dentro de la funcion HAL_RCC_ClockConfig, tenes:

Código: C

1. /* Update the SystemCoreClock global variable */
2.   SystemCoreClock = HAL_RCC_GetSysClockFreq() >> AHBPrescTable[(RCC->CFGR & RCC_CFGR_HPRE)>> RCC_CFGR_HPRE_Pos];

Ta ves con la version cambio... Pero ahi se actualiza esa variable global.

[Thulsa Doom]

Bueno, sea como sea voy a tener que sentarme y hacer el diagrama de flujo.
Gracias por la ayuda 

[KILLERJC]

Bueno, sea como sea voy a tener que sentarme y hacer el diagrama de flujo.
Gracias por la ayuda 

Como consejo... no te pongas a revolver las HAL, a no ser que simplemente quieras entender como es que estan escritas. Pienso que vas a perder demasiado tiempo intentando entender todo. Y que luego vas a estar igual que antes.

Las HAL o Hardware Abstraction Layer, es justamente para eso, aislar al programador de todo lo demás, es aprender  que funciones hay, para que sirven, y usarlas. Y en caso de que no funcionen como vos queres ahí si podes investigar o crear la tuya a tu gusto.

[Thulsa Doom]

Vale, entendido, me lo tomaré con más calma  , gracias por la ayuda