Thread with callback

RE: Thread with callback

ActiTAG — Fri, 05 Mar 2021 08:51:00 GMT

Hello Mr. Richard,

I use an external programmer. The nRF Connect SDK version is 1.4.2 and the Thingy version 1.4.0.

Thanks a lot ! I remove CONFIG_DK_LIBRARY_INVERT_BUTTONS=n and it's working ! Thank you !

RE: Thread with callback

Carl Richard — Thu, 04 Mar 2021 15:34:58 GMT

Hi again!

I did some testing on my Thingy:91 and your project worked fine, though I had to remove CONFIG_DK_LIBRARY_INVERT_BUTTONS=n and add an extra configuration for the SPM. Can you try the attached hex file and see if that works for you?
devzone.nordicsemi.com/.../thingy91_5F00_threads.hex

In addition I'm wondering:
- are you programming the Thingy using MCUBoot or an external programmer?
- What version of the nRF Connect SDK are you using?
- Which version of the Thingy:91 do you have?

I've also attached the project I'm using, for your reference.

devzone.nordicsemi.com/.../thingy91_5F00_threads.zip

Best regards,
Carl Richard

RE: Thread with callback

ActiTAG — Thu, 04 Mar 2021 13:11:39 GMT

Hello, It's change nothing to build in non-secure. I don't find something to help me on this problem. 😞

RE: Thread with callback

Carl Richard — Mon, 01 Mar 2021 15:31:59 GMT

Hi again!

I was not aware that you were working with the Thingy:91. That may require some other configurations and approaches. However, I see that you are building for the thingy91_nrf9160 board. The nRF9160 is designed to have applications running on the non-secure partition, so could you try to build for thingy91_nrf9160ns instead and see if you application runs properly then?

I will get back to you on further considerations regarding the Thingy:91.

Best regards,
Carl Richard

RE: Thread with callback

ActiTAG — Mon, 01 Mar 2021 08:45:46 GMT

Yes with pleasure! Thank you devzone.nordicsemi.com/.../SENSORS.rar

RE: Thread with callback

Carl Richard — Mon, 01 Mar 2021 08:09:56 GMT

Understood. What is your prj.conf? Could you send archive and share your project directory here so that I can do some testing?

Best regards,
Carl Richard

RE: Thread with callback

ActiTAG — Mon, 01 Mar 2021 07:57:46 GMT

Hello, I don't see any mistake. The lib uses LOG but I can't find any trace of it.

RE: Thread with callback

Carl Richard — Fri, 26 Feb 2021 13:38:04 GMT

Good to hear! Does the logging give you any errors? I would also recommend trying to debug this using Segger Embedded Studio and see what the code actually does.

Best regards,
Carl Richard

RE: Thread with callback

ActiTAG — Fri, 26 Feb 2021 12:45:13 GMT

Oh ok thanks it's clearer! despite everything nothing happens when I press the button :x

RE: Thread with callback

Carl Richard — Fri, 26 Feb 2021 11:51:51 GMT

Hi again.

When using the DK buttons and LEDs library you must use the correct callback definition. The handles all the GPIO interaction so you don't need to address that directly. See the attached code, which is a modified version of what you posted earlier.

/*
 * Copyright (c) 2017 Linaro Limited
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr.h>
#include <device.h>
#include <devicetree.h>
#include <drivers/gpio.h>
#include <sys/util.h>
#include <sys/printk.h>
#include <inttypes.h>
#include <drivers/pwm.h>
#include <sys/__assert.h>
#include <string.h>
#include <dk_buttons_and_leds.h>

#include "buzzer.h"
/* size of stack area used by each thread */
#define STACKSIZE 1024

/* scheduling priority used by each thread */
#define PRIORITY 7

#define SLEEP_MS 500
/*alias*/
#define LED0_NODE DT_ALIAS(led2)
#define SW0_NODE DT_ALIAS(sw0)

/*FIFO*/
struct printk_data_t {
	void *fifo_reserved; /* 1st word reserved for use by fifo */
	uint32_t conp;
};

K_FIFO_DEFINE(printk_fifo);

void print(uint32_t id){
    struct printk_data_t tx_data = { .conp = id };
    size_t size = sizeof(struct printk_data_t);
    char *mem_ptr = k_malloc(size);
    __ASSERT_NO_MSG(mem_ptr != 0);

    memcpy(mem_ptr, &tx_data, size);

    k_fifo_put(&printk_fifo, mem_ptr);

    k_msleep(SLEEP_MS);
    
}


/**@brief Callback for button events from the DK buttons and LEDs library. */
static void button_handler(uint32_t button_states, uint32_t has_changed) {
        print(1);
        ui_buzzer_set_frequency(100, 20);
        k_msleep(SLEEP_MS);
        ui_buzzer_set_frequency(0, 0);
        
	if (has_changed & button_states & DK_BTN1_MSK) {
		printk("DEV_DBG: button 1 pressed\n");
	}

	else if (has_changed & button_states & DK_BTN2_MSK) {
		printk("DEV_DBG: button 2 pressed\n");
	}        
}

void blink()
{
	int cnt = 0;
	int ret;
        
    /*led*/
	int err;

	err = dk_leds_init();
	if (err) {
		printk("Could not initialize leds, err code: %d\n", err);
	}

	err = dk_set_leds_state(1, DK_ALL_LEDS_MSK);
	if (err) {
		printk("Could not set leds state, err code: %d\n", err);
	}

	err = dk_buttons_init(button_handler);
	if (err) {
		printk("Could not initialize leds, err code: %d\n", err);
	}

    /*buzzer*/
    err = ui_buzzer_init();
	if (err) {
		printk("Could not enable buzzer, err code: %d\n", err);
		return err;
	}

	while (1) {
		err = dk_set_leds_state(cnt % 2, DK_ALL_LEDS_MSK);
                if (err) {
                        printk("Could not set leds state, err code: %d\n", err);
                }
                if (cnt % 2) {
                         print(0);
                }
                k_msleep(SLEEP_MS);
                cnt++;              
	}
}


void uart_out(void)
{
	while (1) {
		struct printk_data_t *rx_data = k_fifo_get(&printk_fifo,
							   K_FOREVER);
		printk("[Info] conponent %d turn on \n",
		       rx_data->conp);
		k_free(rx_data);
	}
}



K_THREAD_DEFINE(blink_id, STACKSIZE, blink, NULL, NULL, NULL,
		PRIORITY, 0, 0);
K_THREAD_DEFINE(uart_out_id, STACKSIZE, uart_out, NULL, NULL, NULL,
		PRIORITY, 0, 0);

Notice two important changes in the code.

1. The button handler callback is changed to the following:

/**@brief Callback for button events from the DK buttons and LEDs library. */
static void button_handler(uint32_t button_states, uint32_t has_changed) {
        print(1);
        ui_buzzer_set_frequency(100, 20);
        k_msleep(SLEEP_MS);
        ui_buzzer_set_frequency(0, 0);
        
	if (has_changed & button_states & DK_BTN1_MSK) {
		printk("DEV_DBG: button 1 pressed\n");
	}

	else if (has_changed & button_states & DK_BTN2_MSK) {
		printk("DEV_DBG: button 2 pressed\n");
	}        
}

2. The buttons are initialized directly with the callback function as a parameter:

err = dk_buttons_init(button_handler);
if (err) {
    printk("Could not initialize leds, err code: %d\n", err);
}

I hope this is more clear to you now.

Best regards,
Carl Richard

RE: Thread with callback

ActiTAG — Wed, 24 Feb 2021 11:06:09 GMT

Hello Mr Richard,

I've tried it by myself but I must admit that I have trouble understanding the structure to pass for the button to work. Do you have any advice to help me please?

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

RE: Thread with callback

Carl Richard — Mon, 22 Feb 2021 14:44:31 GMT

Great. I will try to come up with an example for you tomorrow. In the meantime I believe you will find the relevant information in the source code of the library I spoke of earlier. Here the buttons are tied to a callback called button_pressed, when that callback is triggered it does two things:
1. Calls k_spin_lock() to prevent further interrupts
2. Disables further callbacks calling the callback_ctrl function

After this it handles the actual button press before unlocking the spinlock and enables the callbacks again. If you do this for your single button it should work properly. I suggest that you define the button device globally so it can be accessed from the callback and callback_ctrl.

Best regards,
Carl Richard

RE: Thread with callback

ActiTAG — Mon, 22 Feb 2021 14:10:22 GMT

Thank you for your response. I followed your first advice to put the button in the same thread as the led. But for your 2. I don't see how to do it, would you have some explanation and an example please ?

RE: Thread with callback

Carl Richard — Mon, 22 Feb 2021 11:32:03 GMT

Hi!

Thanks for reaching out. I suggest that you look into how buttons are handled in the DK Buttons and LEDs library. Note especially that:
1. Buttons don't need a thread per say, as they work through interrupts and callbacks.
2. When a button is pressed the interrupt should be disabled while the callback is handled. Otherwise you will get an assert like this: ASSERTION FAIL [!arch_is_in_isr()] @ WEST_TOPDIR/zephyr/kernel/sched.c:1306

As for the LED thread not working the eternal while loop at the end of your button thread holds the CPU hostage from running the other threads. The button and callback is initialized anyway, so you don't need to have the "while" there.

Hope this helps you on your way!

Best regards,
Carl Richard