• State Verified Answer
  • Replies 11 replies
  • Subscribers 87 subscribers
  • Views 882 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 349150
Options

DPPI_PRESENT functions in modules/hal/nordic/nrfx/hal/nrf_gpiote.h questions.

Burt

Hi, I have two concerns about the functions nrf_gpiote_subscribe_set, nrf_gpiote_subscribe_clear, nrf_gpiote_publish_set, and nrf_gpiote_publish_clear. The expression

 *((volatile uint32_t *) ((uint8_t *) p_reg + (uint32_t) event + 0x80uL))

Given pointer arithmetic, the 0x80uL is the same as numerically adding 0x200 to the other terms. However, the Product Spec shows an offset of 0x180, rather than 0x200. I am confused therefore why the number in the code is not 0x60uL. Am I missing something?

Also, I want to put together some code that will publish an event from a gpiote pin changing state, to be subscribed by a timer. In addition to my concern about the functions' correctness, I have not seen any examples of them being used in the SDK. I don't know if that means I am on the wrong track, or that this is something that has not been done frequently.

Thanks for help.

Regards,

Burt Silverman

Parents Reply Children
  • 0 in reply to Håkon Alseth

    Hi Hakon,

    Sorry I was not very sharp with my pointer arithmetic: now I see that p_reg is cast as a pointer to uint8_t so the offset of 0x80uL is obviously correct for the two subscribe functions. However, looking at the register list you pointed to, again, the PUBLISH_IN registers are at offset 0x180. But the offset in nrf_gpiote.h is shown as 0x80 for both the two subscribe functions and the two publish functions. Isn't that a bug in the publish function definitions? Maybe people are using other functions and that's why there hasn't been a problem? (I will find out as I try examples in the code you pointed me to.)

    I appreciate the link you sent GPIO event shall increment counter without CPU: that wil be tremendously useful.

  • 0 in reply to Burt

    Hi,

     

    Burt said:
    However, looking at the register list you pointed to, again, the PUBLISH_IN registers are at offset 0x180. But the offset in nrf_gpiote.h is shown as 0x80 for both the two subscribe functions and the two publish functions. Isn't that a bug in the publish function definitions?

    Not sure I understand. For nrf_gpiote_subscribe_ functions, you take in the type nrf_gpiote_task_t, which is a offsetof the TASKS_OUT/SET/CLR, which starts from 0. Add 0x80 to this, and you get the SUBSCRIBE_OUT/SET/CLR register.

    enum type nrf_gpiote_event_t is a offsetof() the EVENTS_IN[] events, so it will be 0x100 + 0x80 for the first entry, resulting in reading/writing to register PUBLISH_IN[].

      

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Sorry, Hakon, I need to work harder at reading carefully; I am embarrassed!

    Another question, is there any way you have time to update timed_signals_ncs240 for ncs302, or is that an exercise I need to do? It looks like the low level drivers change pretty quickly!

    Regards,

    Burt

  • 0 in reply to Burt

    Hello Hakon,

    I think I have done the job of updating ncs240 for ncs302. There was a small bump at v2.5 and a large one at v2.6, and then no changes were required to get code that at least builds on v3.0.2. I have not tested anything operationally, and I have a few ugly spots that I need to look at. I thought I would let you know what I have been up to.

    Regards,

    Burt

  • 0 in reply to Burt

    Hi Burt,

     

    Glad to hear that the porting is going along nicely. Let me know if you run into any issues or have any problems. I wish you a wonderful weekend!

     

    Kind regards,

    Håkon

Related
Terms of service