2020-12-17 07:40 AM
Ok, so I decided to change from Arduino IDE (STM32F103) to STM32CubeIDE (STM32F334R8).
I can't get perfect timing.
My program just have to toogle my pin after x us (that is presented inside a vector)
Just to illustrate, here is my arduino code (I only get 1us of error):
// Function called when overflow count is detected
void Update_IT_callback(void){
// Tootlge pin
digitalWrite(pin, !digitalRead(pin));
// This loop is just because I need to repeat it
if (id_vector >= aux_signalsize){
id_vector = 0;
loop_count++;
if (loop_count >= size_loop){
MyTim->pause();
MyTim->refresh();
loop_count = 0;
}
}
// Set wait time in us to next toogle
MyTim->setOverflow(aux_signal[id_vector++], MICROSEC_FORMAT);
}
And here is my HAL code (I get 2.3us error).
void TIM1_UP_TIM16_IRQHandler(void)
{
/* USER CODE BEGIN TIM1_UP_TIM16_IRQn 0 */
HAL_GPIO_TogglePin(RF_Pin_GPIO_Port, RF_Pin_Pin);
if (vector_run == vector_max){
vector_run = 0;
if (repeat_id == repeat){
// Repetimos o sinal o suficiente
// Desabilitamos a contagem
HAL_TIM_Base_Stop(&htim16);
HAL_GPIO_WritePin(RF_Pin_GPIO_Port, RF_Pin_Pin, GPIO_PIN_RESET);
// Apagamos o sinal
for (int i = 0; i < vector_max; i++){
rf_sig[i] = 0;
}
// Apagamos o tamanho do vetor
vector_max = 0;
//vector_run = 0;
repeat_id = 0;
repeat = 0;
}else{
repeat_id++;
}
}
__HAL_TIM_SET_AUTORELOAD(&htim16, rf_sig[vector_run]-1);
vector_run++;
/* USER CODE END TIM1_UP_TIM16_IRQn 0 */
HAL_TIM_IRQHandler(&htim16);
/* USER CODE BEGIN TIM1_UP_TIM16_IRQn 1 */
/* USER CODE END TIM1_UP_TIM16_IRQn 1 */
}
Other important features:
htim16.Instance = TIM16;
htim16.Init.Prescaler = 64-1;
htim16.Init.CounterMode = TIM_COUNTERMODE_UP;
htim16.Init.Period = 10;
htim16.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
htim16.Init.RepetitionCounter = 0;
htim16.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE;
I've already decreased Prescaler, but the result is the same. I was hoping to get the complete opposite. More performance for HAL lib.
I'm clearly doing something wrong.
Solved! Go to Solution.
2020-12-18 05:18 PM
Any electronic part may fail.
CSS is hardware which checks whether HSE runs, and in the unlikely event when it does not (e.g. if the crystal mechanically breaks, which may happen for example if the device falls from some height to the ground), the internal RC oscillator takes over.
JW
2020-12-17 10:16 AM
What do you mean by error? What's the expected and what is the observed behaviour? What is the primary source of clock (HSE, HSI?) and how are clocks set up?
JW
2020-12-17 11:08 AM
Thanks JW,
When I address the word error I mean.
Expected time: 420us (this is what I thing I'm configuring)
Measured time: 422.3us (toogle pin)
Error: 2.3us (between configured and measured).
For RCC Mode and Configuration Iḿ using:
HSE (BYPASS Clock Source) - It's default for Nucleo board.
2020-12-18 03:24 PM
As it seems. HSI RC error is the problem. I changed to HSE and now is perfect. However, I'm worried. CSS means that HSE will fail? Will it recover itself?
2020-12-18 05:18 PM
Any electronic part may fail.
CSS is hardware which checks whether HSE runs, and in the unlikely event when it does not (e.g. if the crystal mechanically breaks, which may happen for example if the device falls from some height to the ground), the internal RC oscillator takes over.
JW
2020-12-19 05:50 AM
Thanks