Skip to main content
Graduate
July 31, 2024
Solved

STM32F4 Buzzer

  • July 31, 2024
  • 2 replies
  • 4406 views

Hello guys !

I am new at the embedded systems and I am trying figure it out ! 

I am using STM32F446VET7.

I connected my buzzer to an GPIO pin(PB12) which has no pwm speciliaties.

But my buzzer is not working when I connected to the DC signal source like 5V. So I need an PWM kinda source.

When I resarch I only found source codes for PWM Generation channels with Timer. My GPIO has no timer and I cannot change my design right now.

 

Can I do the same job with Systick timer or something like that. I just need a 1 second beep sound, nothing more.

Here is my design in hardware

testbenchmark_0-1722452246106.png

and the datasheet of my buzzer

testbenchmark_1-1722452306142.png

Do I need to generate a signal with 50% duty cycle at a frequency of 2048 Hz, if you can just give me an idea, I can research and learn how to do it. Thanks

    This topic has been closed for replies.
    Best answer by TDK

    Sound is vibration, so yes you need a square wave or other waveform to drive the buzzer.

    You can toggle the GPIO pin in an interrupt which is called at a regular rate. This will probably give fine results, although a dedicated timer PWM channel would be better.

    Set up a timer to interrupt at 2*2048Hz and toggle the pin in the PeriodElapsed callback.

     

    Another method would be to set up a DMA transfer triggered by a timer which toggles the pin at a regular rate by writing to the GPIOB->BSRR register. This will free up CPU resources, but is a bit more complicated to implement.

    2 replies

    TDKAnswer
    Super User
    July 31, 2024

    Sound is vibration, so yes you need a square wave or other waveform to drive the buzzer.

    You can toggle the GPIO pin in an interrupt which is called at a regular rate. This will probably give fine results, although a dedicated timer PWM channel would be better.

    Set up a timer to interrupt at 2*2048Hz and toggle the pin in the PeriodElapsed callback.

     

    Another method would be to set up a DMA transfer triggered by a timer which toggles the pin at a regular rate by writing to the GPIOB->BSRR register. This will free up CPU resources, but is a bit more complicated to implement.

    Graduate
    July 31, 2024

    Hi TDK.

    I use TİM2 for interrupt.

    testbenchmark_1-1722456757072.png

    testbenchmark_0-1722456723831.png

    and there is my codes : 

    testbenchmark_2-1722456801025.png

    testbenchmark_3-1722456820226.png

    and this is worked well. I can hear my beep sound now. Thank you.

    One last question : Does the timer counting and interrupt generation consume CPU cycles? Can I avoid this with HAL_TIM_Base_Stop_IT(&htim2); when buzzer not in use?

     

     

     

     

    Super User
    July 31, 2024

    @testbenchmark wrote:

     Does the timer counting and interrupt generation consume CPU cycles?


    The timer counting doesn't, and the generation of the interrupt doesn't, but the code that runs in your interrupt handler does.

    Just for driving a buzzer, you don't need any interrupt at all - the timer itself can drive an IO pin. That would consume no CPU cycles at all (apart from the initial configuration).

    Super User
    July 31, 2024

    @testbenchmark wrote:

    my buzzer is not working when I connected to the DC signal source like 5V. So I need an PWM kinda source


    You don't need PWM - you just just need an oscillating signal; ie, something which switches between low and high at a suitable frequency.

    You could do that in a simple loop, toggling a pin - just like blinking an LED, but at a much higher frequency (an audio frequency).

    Or a simple timer which gives a frequency output.

    PWM = Pulse Width Modulation; ie, varying the width of a pulse - you don't need that.

     

    EDIT:

     


    @testbenchmark wrote:

    Do I need to generate a signal with 50% duty cycle at a frequency of 2048 Hz, 


    No, you don't need to - those just happen to be the conditions for which they've stated the power consumption.

    The power consumption will vary with both frequency and duty cycle.

    However, as those are the conditions they've chosen to use as the basis of their specification, it likely that those are conditions under which the thing will work well !