Input pulse width extend using GPIOTE / PPI

RE: Input pulse width extend using GPIOTE / PPI

Dmitry — Thu, 03 Jun 2021 10:59:03 GMT

Yes, there are too much code executed in gpiote library before it calls your event handler. To make things faster, write your own high-priority interrupt handler instead of using library (though with running BLE stack you still get no guarantee that interrupt comes in time). Or you could configute pin as D0H1 and make a pulse with PWM hardware activated by GPIOTE event - I can't say for sure that it will work on the same pin but you can try.

RE: Input pulse width extend using GPIOTE / PPI

swisst — Wed, 02 Jun 2021 11:53:42 GMT

Both plots reflect pin state - original pulse ( high one on the plots ) and generated ( low one but not complete ) have delay between leading edges and that is exactly what I was trying to show on plots

The delay between leading edges ( ~25 us ) is time between GPIOTE edge detect event -> in_handler invocation -> series of pin commands ( pin_set and pin_cfg ) before nrf_delay_us()

The strong level you mentioned is caused because of delay when pin is not reconfigured to output - both plots describe leading edge ( despite of second one is too low to be high )

But I use commented code

#if( !_PROLONG_WITH_2_PINS)
    configure_txir_pin( false );
    nrf_drv_gpiote_out_set( TXIR_OUT_PIN );
    nrf_delay_us( get_txir_pulse_width_us() );
    configure_txir_pin( true );
#endif

I get next picture with the same schematic but with longer delay between leading edges

RE: Input pulse width extend using GPIOTE / PPI

Dmitry — Wed, 02 Jun 2021 11:24:18 GMT

I can't get how your signals are put together.. does pulse source have open-drain output?

At the end of pulse, you call nrf_gpio_pin_clear then configure_txir_pin - between them you have strong low level. You don't need to change pin state, only configuration. For predictable timings, it's probably better to use GPIOTE with NRF_GPIO_PIN_D0H1 output (not sure because I don't know your schematic).

RE: Input pulse width extend using GPIOTE / PPI

swisst — Wed, 02 Jun 2021 10:05:29 GMT

Hi,

thanks for reply - I did try to implement it in this way

devzone.nordicsemi.com/.../5684.pulse_5F00_width_5F00_extend.c

the problem is only in leading edge delay - there is profit but the problem is still exists. Now the output pin high level differs depending on how it is configured ( nrf_gpio_cfg() or nrf_drv_gpiote_out_init() )

sdk_config.h

#define GPIOTE_CONFIG_IRQ_PRIORITY 2

below best and worst cases

Sorry for delays - please take in account that it is a challenge for now to implement so main tasks may have influence

RE: Input pulse width extend using GPIOTE / PPI

Dmitry — Fri, 28 May 2021 09:37:42 GMT

Hi,

you don't need to unconfigure pin, just set output value to 1 and then use nrf_gpio_cfg() to switch direction from input to output and back.

RE: Input pulse width extend using GPIOTE / PPI

swisst — Thu, 27 May 2021 10:37:03 GMT

Hi Sigurd

Thanks for quick reply.

[quote userid="15146" url="~/f/nordic-q-a/75641/input-pulse-width-extend-using-gpiote-ppi/311746#311746"]You want to use 1 GPIO pin for both the input and the output?[/quote]

Exactly, I want to use one pin by re-configuring it on the fly

RE: Input pulse width extend using GPIOTE / PPI

Sigurd — Wed, 26 May 2021 11:23:34 GMT

Hi,

[quote userid="99142" url="~/f/nordic-q-a/75641/input-pulse-width-extend-using-gpiote-ppi"]

I plan to improve this implementation with hw timer + PPI to produce <time_us> delay with falling edge

[/quote]

Yes, that is the best approach. You might find the "second_count_ppi_rtc_timers.zip" example from this post useful: https://devzone.nordicsemi.com/f/nordic-q-a/34547/ppi-configuration-to-count-pulses/133136#133136

[quote userid="99142" url="~/f/nordic-q-a/75641/input-pulse-width-extend-using-gpiote-ppi"]The task is to detect input pulse ( trailing edge ) of original length 2 us and extend it for <time_us>[/quote][quote userid="99142" url="~/f/nordic-q-a/75641/input-pulse-width-extend-using-gpiote-ppi"]But the question is whether it is possible to implement this using only one pin ?[/quote]

You want to use 1 GPIO pin for both the input and the output?