ncs zephyr example called 'nrfx'

RE: ncs zephyr example called 'nrfx'

Heidi — Thu, 01 Jul 2021 14:15:55 GMT

Hi! I just spoke to the developer and there does seem to be a small copy-paste error in this sample. There will be a fix soon.

And you are correct in your observation, there is no debouncing used here as the purpose of this sample is to show how to use the nrfx drivers in Zephyr, not how to handle buttons reliably.

We unfortunately don't support the debouncing feature in NCS yet.

RE: ncs zephyr example called 'nrfx'

NordicSwissTom — Wed, 30 Jun 2021 21:48:58 GMT

I wasted some more time on this example, then I found it only works exactly with all other 3 buttons/switches, BUT not with the 'Button 1' aka 'sw0'. The next observation was, with sw0 the 'button_handler()' function gets called TWICE per button press! (but only once for the 3 other buttons/switches). Thus I guess there is a zephyr config disaster.

RE: ncs zephyr example called 'nrfx'

NordicSwissTom — Wed, 30 Jun 2021 21:39:30 GMT

IMPORTANT: another bad point for this example: it is VERY prone to button bounce! (I think there was an app library in an [nrf5?] sdk exactly for this reason to provide debouncing). So this example (button to GPIOTE-in) has no serious use case. there should be a big red WARNING in the readme.

RE: ncs zephyr example called 'nrfx'

NordicSwissTom — Wed, 30 Jun 2021 21:31:29 GMT

C compilers do not check for enum type mismatch; In my case it is the additional CLang based verifier running.

I ask again, why should we code for an IN -event on a !OUTPUT! pin?
nrfx_gpiote_in_event_get (OUTPUT_PIN)

While looking at the nrfx implementation, I think it worked (for you) due pure coincidence as the offsets of the channels/registers are the same.

Another point on this line is the mixture of nrfx_* vs nrf_* calls,
I think it would be much better readable as:
nrfx_gppi_channel_endpoints_setup(channel,
nrfx_gpiote_in_event_addr_get(INPUT_PIN),
nrfx_gpiote_out_task_addr_get(OUTPUT_PIN) );

RE: ncs zephyr example called 'nrfx'

Heidi — Fri, 25 Jun 2021 13:07:46 GMT

When compiling with GNU 9.2.1, I do not get these warnings.

RE: ncs zephyr example called 'nrfx'

NordicSwissTom — Fri, 25 Jun 2021 09:46:33 GMT

Note, your toy SES compiler will not find this issue.

For the call nrfx_gppi_channel_endpoints_setup,
there is the second part defined as:
nrf_gpiote_task_address_get( NRF_GPIOTE_Type const * p_reg, nrf_gpiote_task_t task)

but for 'task' argument, your sample source is passing an 'event' kind per:
nrfx_gpiote_in_event_get(OUTPUT_PIN)

this gives (in a CLang based verifier)
Warning: implicit conversion
from enumeration type 'nrf_gpiote_event_t'
to different enumeration type 'nrf_gpiote_task_t'

RE: ncs zephyr example called 'nrfx'

Heidi — Wed, 16 Jun 2021 11:42:48 GMT

I just tested on my nRF9160 DK (0.8.2 layout, NCS 1.5.1) and it works. Could you paste the log output from the sample when you're testing it?

I also don't see any warnings when building the code. Could you show me the full log output when building?

RE: ncs zephyr example called 'nrfx'

NordicSwissTom — Mon, 14 Jun 2021 17:53:28 GMT

Hi Heidi, the 9160 DK (the v0.9 layout)

RE: ncs zephyr example called 'nrfx'

Heidi — Mon, 14 Jun 2021 12:35:00 GMT

Hi!

Which board are you building for?

Best regards,

Heidi