Using standard STM32 calls for TIm1, Tim2 and interrupts?

cricketbee · August 25, 2023, 8:39pm

I am trying to figure out a lot of different things as I am making the shift to daisy and one of the things that is confusing me is whether or not I can still use things I learned from CubeIDE and books like Mastering STM32.

I know that there are a lot of things hidden away in the Daisy so you do not have to deal with the Hal Libraries BUT if I want to be able to access interrupts and timers and us functions like
__HAL_TIM_GetCompare(), is that even possible with the Daisy or do I have to do everything through the layers the Daisy team created?

I saw in the files somewhere that TIM1 has not been implemented etc. I am not sure if maybe that is something I could do by Opening up a STM Cube file and enabling certain things or if that would then break the Daisy libs.

Obviously one advantage to the Hal code is there is just more online about how to use it and interact with it. There are very few guides for the daisy library support files unless you are trying to use the audio callback etc.

THIS THREAD

is a good example of what I am talking about. THE original poster talks about a solution he found but then he is not sure if it will even work with the current daisy setup.

thanks for any clarity here

Takumi_Ogata · August 28, 2023, 7:33pm

In your recent posts, it sounds like this PR (Feature: Hardware PWM by stephenhensley · Pull Request #568 · electro-smith/libDaisy · GitHub) answered questions that you were wondering about. Let us know if you have any specific questions.

By the way, here’s a documentation on software timer: libDaisy: daisy::TimerHandle Class Reference

And the Aurora-SDK header file includes an example of how to set up a “low priority callback” at a specific frequency.

github.com

Qu-Bit-Electronix/Aurora-SDK/blob/main/include/aurora.h#L235-L251


      
          void StartLowPriorityCallback(daisy::TimerHandle::PeriodElapsedCallback cb,
                                        uint32_t target_freq,
                                        void    *data = nullptr)
          {
              daisy::TimerHandle::Config timcfg;
              timcfg.periph        = daisy::TimerHandle::Config::Peripheral::TIM_5;
              timcfg.dir           = daisy::TimerHandle::Config::CounterDir::UP;
              auto tim_base_freq   = daisy::System::GetPClk2Freq();
              auto tim_target_freq = target_freq;
              auto tim_period      = tim_base_freq / tim_target_freq;
              timcfg.period        = tim_period;
              timcfg.enable_irq    = true;
              tim5_handle.Init(timcfg);
              tim5_handle.SetCallback(cb, data);
              /** Start Audio */
              tim5_handle.Start();
          }

cricketbee · August 29, 2023, 8:25pm

Ahh yes thanks so much. I forgot that you answered a large part of my question in the other thread as that has more of the Hal code within that PR.

thanks again and thanks for this Aurora Callback code

KnightHill · January 9, 2024, 7:12pm

I was looking at libDaisy’s timer implementation and noticed that there is no SetFreq() function. The only way to change the timer’s period once it is started seems to be via SetPeriod/SetPrescaler.

Is there any specific reason not to change timer’s period while it is running?
Was SetFreq() not implemented on purpose and why?

Thanks

Corvus_Prudens · January 16, 2024, 7:14pm

Maybe I’m hung up on “once it’s started,” but this is also true during configuration. The only way to set the frequency either during configuration or while it’s running is to set the prescaler and period.

It’s kinda like finding a note on a guitar – there are multiple ways to achieve a particular frequency with combinations of the prescaler and period values. That’s not to say it’s impossible, but it looks like it was tricky enough that it just wasn’t prioritized at the time.

Changing the period and prescaler while it’s running should be totally okay.