Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

PWM library simpler way for on/off (enable/disable) than the example with SDK?

Is there a way to set duty cycle before app_pwm_enable(&PWM1) call ?

Or some other simple way to switch on and off a passive buzzer signal without every time at off/on cycle to go with complex sequence for setting duty value as per pwm_library example?

Let say some app like Morse Code where the frequency will be resonance of the buzzer and duty cycle will be constant 50 (or less).

Thanks

Parents
  • Hi 

    You mean you only want to turn on/off a simple square wave where the frequency and duty cycle will always be the same?

    If this is the case it might be easier just to use a timer to generate events, and connect them to  a GPIO through the GPIOTE and PPI peripherals. 

    Then you can set the frequency simply by changing the compare value in the timer. 

    Best regards
    Torbjørn

Reply
  • Hi 

    You mean you only want to turn on/off a simple square wave where the frequency and duty cycle will always be the same?

    If this is the case it might be easier just to use a timer to generate events, and connect them to  a GPIO through the GPIOTE and PPI peripherals. 

    Then you can set the frequency simply by changing the compare value in the timer. 

    Best regards
    Torbjørn

Children
  • Ok, I tried the gpiote example and browse documentation. But still cant find what is(are) the way once I start the square wave, to stop it , then to restart it (with minimum operations)?

    While in stopped/idle mode – is there any of those components involved:  timer, gpiote, ppi  that would consumes excessive power (in a scale for a battery operated devices) that I have to be worry about?

    Thanks

  • Hi 

    A running timer will increase the sleep current considerably, yes, so I would recommend stopping it whenever the square wave is not needed. 

    The best way to do this is to activate the SHUTDOWN task in the timer, which disables it completely. 

    Having a PPI channel or a GPIOTE OUT channel enabled should not affect the sleep current significantly, but I will have to double check this to be sure and get back to you. 

    Best regards
    Torbjørn

  • Ok, but timers SHUTDOWN task is marked in documentation as “Deprecated”?

    Your idea for using timer to generate the basic frequency (I need 2730 Hz) is very good, I only struggle to find documentation or example how best to switch on /off this square wave with GPIOTE as I will use it for audio markers 1 to 4 beeps: let say 1 beep immediately after a button is pressed, 2 for long press, 3 , 4. Also beeps(and pauses between) could   be short or long etc.

    I anyway will use 1MHz(or less) timer source, so will spend less power at those frequencies, but looking to find optimal solution to switch off/on the 2730 burst in between beeps of a single audio prompt, then move timer and all other involved components (GPIOTE, PPI or whatever will use) in idle position waiting to start new audio prompt with minimum reinitializations.

    Thank you and best regards

  • Hi 

    It is true that the SHUTDOWN task is marked as deprecated, but for devices affected by Errata 78 it is necessary to use this task to achieve low current consumption in sleep mode. 

    In future devices where this issue is fixed you would have to replace the SHUTDOWN task with the STOP task. 

    If you want to stop and start the timer at a slower rate you can use the app_timer to schedule this. 

    I made a small example based on ble_app_uart to show how you can configure the TIMER, PPI and GPIOTE peripherals, and use the app_timer to start and stop the timer repeatedly:

    1715.ble_app_uart_timer_freq.zip

    Best regards
    Torbjørn

  • Hi Torbjørn,

    Really appreciate the time you spent to prepare so long example. I definitely get far more useful information from your code than from the infocenter. I just spend only about an hour and not sure I’ve got right all the operations, not tried yet on the DK. The only part of the code I have certain concerns is

        SOUND_TIMER->TASKS_SHUTDOWN = 1;

        NRF_GPIOTE->TASKS_CLR[SOUND_GPIOTE_CH] = 1;

    I read in the specs that timer tasks have delays: for CLEAR, START and STOP it says is “one clock cycle of the PCLK16M”, but doesn’t says nothing about TASKS_SHUTDOWN and PCLK1M. So I’l have to test somehow not to happened situation when NRF_GPIOTE->TASKS_CLR happened before actual SOUND_TIMER shutdown, because then there is a chance SOUND_TIMER to be shut down while the output is in high level, and then buzzer will not buzz, but will spend 100mA …  I currently work on some other part of the project, but as soon as I finish this one will return back to buzzer story.

    As you said some nRF52840 chips have some bug, how can get from code chip version? Because by the time I finish this project maybe those old versions will be gone and maybe worth to check in code if the chip is affected by this bug and if so to use TASKS_SHUTDOWN else TASKS_STOP?

    Thank you, very much and best regards

    P.S. If I have to start from scratch such code that you wrote - how could find all those 'defines' for registers, values, positions etc. that you used like GPIOTE_CONFIG_MODE_Task, GPIOTE_CONFIG_OUTINIT_Low ... 

    Is there any documentation, manual, tutorial, etc? Let say register names are same what is in the spec sheet for the particular device, but all the rest - no clue. I can trace the source from your code, but if I start from scratch I would be as a new world explorer :(

Related