NRF52 interrupt logic level event handler

RE: NRF52 interrupt logic level event handler

devops — Fri, 17 Aug 2018 17:53:48 GMT

Thank you for such a constructive and towards solution leading reply. I will follow your instructions!

RE: NRF52 interrupt logic level event handler

Edvin — Fri, 17 Aug 2018 09:19:30 GMT

Hello,

The BSP library (without modifications) looks like it is only meant for simple button handling. To be honest, it is a bit confusing, and difficult to understand how it works.

If you want to use a button library, I suggest that you use the app_button.c/h directly library instead. This is also used by the bsp library, but the bsp library strips away an awful lot in the actual event. You will only get the button number in the bsp event, and you can't trigger the event on both push and pull.

Look into the app_button instead.

The app_button library is good if you intend to use it for physical buttons, because it has a debounce filter functionality. If you intend to control the GPIOs by wires (and don't need debounce), I don't see a reason why not to use the pin_int_change implementation.

Best regards,

Edvin

RE: NRF52 interrupt logic level event handler

devops — Thu, 16 Aug 2018 12:16:57 GMT

Thank you for replying. I do not want to have the flush in the handler. This was just for testing and due to my lack of knowledge I tried out many things which were not working. I wanted to add the logging feature to the application in Segger Studio but did not get it to work even though I added the header files in main.c and CMSIS had the necessary defines enabled.

Right now I have moved a bit on from the initial problem as I was not able to do my function how I want, which is an event handler in bsp_event_handler and where I could sense if the pin has went from high to low or vice versa. I am using right now the pin_int_change which obviously works but my goal is to get the same function to work in bsp. I feel that I need to learn a bit more pointers, callbacks and events - I was trying to trace down how the bsp_event_handler gets called and how to assign events to custom pins on the board but got confused in the process... If you have any thoughts, feel free to share them and I will try them out.

RE: NRF52 interrupt logic level event handler

Edvin — Thu, 16 Aug 2018 09:17:56 GMT

Hello,

I suspect that you have some IRQ priority issues, when you move the flush function to your event handler. It is trying to run the event handler, but is not allowed, since the event has a higher priority, so you are stuck in a deadlock. You can try to lower your interrupt priority, but is there a reason for why you need to move the flushing to the event handler? You can still call NRF_LOG_INFO(); from your events.

Best regards,

Edvin

RE: NRF52 interrupt logic level event handler

devops — Wed, 15 Aug 2018 06:08:54 GMT

Good morning. Thank you for your answer. Something like that is the easiest approach indeed and I had an example working like that.

What I would like is:

void event handler(event){

    switch(event){
    
        case interrupt_high: //**// break;
        
        case interrupt_low: //**// break;
        
        case reset_button_toggle: //**// break;
        
        case another_button_long_press: //**// break;
        
        default: break;

}}

I think that this would be a better approach for multiple events that may happen further along as the system evolves and new peripherals are added and the clear example is bsp_event_handler(bsp_event_t event). I will start experimenting again and appreciate any instructions.

EDIT: Have not got anything to work... I tried to make a event handler again but without luck. Now I tried again with the simpler example and having problems as well. When I log the text to console, while having NRF_LOG_FLUSH in the while loop in main, then it works. If I flush logs inside the handler, then the handler ceases to work (doesnt detect pin changes anymore). If I want to get the temperature from SPI and print it inside the handler, it does not print anything and ceases to function.

This seems really complicated to implement... does anybody have some good suggestions?

I would like to:

Detect interrupts from sensor (active/inactive)
Then based on that, set the state of the machine (machine is working, not working etc.)
If the machine would be working, then get data from sensor with SPI and update advertising package with the data

I have a separate file where the SPI connection works and in another file where I can send test BLE data in manufacturer data. I want to have a low-power communication where I just send sensor data through BLE to phone when machine is working and I am trying to implement features step by step - in the hopes of combining smaller functions in the end.

void in_pin_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
    if(nrf_gpio_pin_read(INT_2) == 0){
        NRF_LOG_INFO("Machine active");
        //float temperature = read_temperature();
        //NRF_LOG_INFO("Temperature is: " NRF_LOG_FLOAT_MARKER "\r\n", NRF_LOG_FLOAT(temperature));
        //NRF_LOG_FLUSH();
    }
    else if(nrf_gpio_pin_read(INT_2) == 1){
        NRF_LOG_INFO("Machine inactive");
        //NRF_LOG_FLUSH();
    }
}

RE: NRF52 interrupt logic level event handler

Edvin — Tue, 14 Aug 2018 12:43:49 GMT

Hello,

If I understand you correctly, you want an interrupt whenever a pin changes state, and you want to do an action depending on what state the pin is in.

so something like:

pin_interrupt_callback()
{
    if (pin_is_pressed)
    {
        //do something
    }
    else if(pin_is_not_pressed)
    {
        //do something else
    }
}

Is that correct?

A very simple approach is using the pin_int_change example, and adding something in the handler to read the state of the pin. You can e.g. use nrf_gpio_pin_read(uint32_t pin_number);

If you take the SDK15\examples\peripheral\pin_int_change, and replace the main file with the attached main file, it should toggle one of the LEDs when you push the button down, and another when you release it.

devzone.nordicsemi.com/.../main.c

Best regards,

Edvinn