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

[samsam]

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

[ovrebekk]

Hi 

samsam said:

Thanks, will take a closer look at stackoverflow - good to know all issues when computer math doesn't follow standard math :)

It's integer math basically. When I started in Nordic we were still using 8-bit microcontrollers with only 16kB of code flash, and you didn't use float unless you really had no other choice. 

In the nRF52 you could easily just convert to float and do the calculations in a more intuitive way, but staying with integer operations exclusively is still a bit more efficient ;)

samsam said:

If you know for sure that such information for working with registers is available somewhere, could  you point it or at least give me a hint what to search for, because there are tons of tutorials there and is quite possible I could miss it?

I don't think there are any tutorials or guides for this as such. The intention behind the SDK is to provide drivers and abstractions so you don't have to access hardware directly, but I often find the hardware easier to deal with than some of the drivers ;)

What I can give you is a link to a repository full of hardware level examples, showing how you can use most of the peripherals in the nRF52 by accessing registers only. These examples should give you a good indication to what kind of registers are available, and how to access them:

https://github.com/andenore/NordicSnippets

Just open the "examples" folder for all the different examples. 

Best regards
Torbjørn

[samsam]

Hi Torbjørn,

I finally got some time to play with your example - it works perfect, unfortunately only standalone itself. As soon as I combined it with some my code that uses some  nrf_drv_gpiote* and the problems start:

 Those hardcoded SOUND_GPIOTE_CH 0 clashes with some of the  nrf_drv_gpiote* inits.

How can get/ allocate a free gpiote channel and use it instead of channel 0, but also to be safe that later eventual calls to nrf_drv_gpiote_*_init will not mess with this channel,

or

opposite approach: use nrf_drv_gpiote_out_init to allocate a gpiote channel, but than how can hook it to ppi as the channel that nrf_drv_gpiote_out_init  allocates is somehow hidden?

Also this timer NRF_TIMER1 that is hardcoded - is there any chance to interfere with something else? ( I have an SPI display that start behave weird after I add this code for driving a passive buzzer, but havent investigate yet if the problem is from the code or electrical noise that the buzzer spreads on the circuit 

Thanks

[ovrebekk]

Hi 

If you are using the nrf_drv_gpiote driver already I would recommend using this driver instead of accessing registers directly, like in my example. After you initialize an out channel using nrf_drv_gpiote_out_init you should be able to read out the channel index, which you can then reference in the code. 

You should be able to check in your other drivers if they use the TIMER1 module. Maybe you can change my code to use TIMER2 instead?

Best regards
Torbjørn

[samsam]

Hi Torbjørn,

Still struggle to find easy way to get gpiote channel index after  nrf_drv_gpiote_out_init (). The best I could do is from nrfx_gpiote_out_task_get(pinNo) to get the task enum and after compare swithc/case with all nrf_gpiote_tasks_t  enums to get the channel index (0-7). Any better idea?

Is there a way to check what timers are in use while at breakpoint in debugging? This to dig in the code for the timers seems have far more chances to miss some timer definition somewhere deep buried in the code?

Thanks

[ovrebekk]

Hi 

You should be able to initialize an out channel, and then just use the nrf_drv_gpiote_out_task_addr_get function to get the task address directly. Then there is no need to know the channel index. 

Just setup the PPI task endpoint with the task address provided. 

Regarding which timers are enabled it should be possible to check this in the sdk_config.h file, assuming the other libraries use the nrfx_timer library. 
It will have various defines on the form TIMERx_ENABLED or NRFX_TIMERx_ENABLED, showing which timers are enabled already. 

Please note that if you use a SoftDevice it will use TIMER0, even if this is not reflected in sdk_config.h. 

Best regards
Torbjørn