Differences

This shows you the differences between two versions of the page.

--- en:edu:zmitac:s2:aih:lab:nrf52threads2 [2023/11/23 18:21] – ktokarz
+++ en:edu:zmitac:s2:aih:lab:nrf52threads2 [2023/12/03 13:25] (current) – ktokarz
@@ Line 1: / Line 1: @@
-====== Zephyr threads ======
+====== Zephyr threads communication and synchronization ======
 In this part, we will show methods of exchanging data between threads. In the example from the previous part, threads were defined using K_THREAD_DEFINE()macro.
 <code>
@@ Line 13: / Line 13: @@
   * thread options (here 0)
   * delay to start the thread (0 meaning no delay)
-As we can see every thread has its own stack, which means that if there is a need to exchange data between threads we have to use some shared variable visible for all threads interested in using it. In multitasking environments, especially running on a multi-core processor, there is a need to synchronise the access to shared resources. Zephyr offers some mechanisms for inter-thread data exchange and synchronisation.
+As we can see every thread has its own stack, which means that if there is a need to exchange data between threads we have to use some shared variable visible for all threads interested in using it. In multitasking environments, especially running on a multi-core processor, there is a need to synchronise the access to shared resources. Zephyr offers some mechanisms for inter-thread data exchange and synchronisation. They include three that we present in this laboratory:
+  * FIFO queue
+  * Semaphores
+  * Mutexes
+===== FIFO queue =====
+In the example available in the Zephyr framework the FIFO queue is used to pass data from two threads (blink0, blink1) which are used to blink two LEDs to the uart_out thread which displays received data in the terminal.
+The FIFO queue can be defined with the macro K_FIFO_DEFINE. In our example, it defines the FIFO queue and gives it the name "printk_fifo".
+<code>
+K_FIFO_DEFINE(printk_fifo);
+</code>
+The Blink0 thread as well as Blink1 calls the same function blink() passing three parameters:
+  - address of the structure that represents LED (&led0 or &led1 respectively)
+  - number of milliseconds the function goes to sleep between iterations
+  - id of LED (0 or 1)
+Notice that blink() is called only once from thread Blink0 and once from thread Blink1. After the initialisation of LED, it jumps into infinite while(1) loop. Every iteration toggles the LED using the least significant bit of the cnt variable
+<code>
+gpio_pin_set(spec->port, spec->pin, cnt % 2);
+</code>
+and inserts the content of the object tx_data into the printk_fifo using the dynamically allocated memory region of the size equal to printk_data_t size.
+<code>
+k_fifo_put(&printk_fifo, mem_ptr);
+</code>
+The uart_out thread gets the element from the thread with the function k_fifo_get
+<code>
+struct printk_data_t *rx_data = k_fifo_get(&printk_fifo, K_FOREVER);
+</code>
+After successful reading, prints the LED number and counter value (cnt) to the console, and releases the memory allocated by blink.
+The full code looks as follows. If you face problems with compilation add the following line to the prj.conf file
+<code>
+CONFIG_HEAP_MEM_POOL_SIZE=1024
+</code>
 <code>
 /*
@@ Line 133: / Line 166: @@
 		PRIORITY, 0, 0);
 </code>
+Note that there is no main() function in this code, everything happens in thread functions.
+===== Semaphores =====
+Semaphore is the variable that presents the state of the shared resource. This variable must be available for all the threads interested in using the resource. The common way to implement the semaphore is the global variable. Still, Zephyr OS has the semaphore mechanism built in which has some additional features like controlling the limit value of the semaphore, preventing blocking the ISR handlers.
+At initialization, there is the possibility to specify an initial state of the semaphore (must be greater than 0) and a maximum limit.
+Function “Give” will increment the semaphore value up to the maximum limit, in which case the semaphore will not be modified. “Give” can be called from any thread or ISR because it does not stop program execution in any case.
+Function “Take” will decrement the semaphore count down to zero (the semaphore is unavailable). “Take” can be called only from threads but not from ISR, because if a thread is trying to "Take" an unavailable semaphore must wait until some other thread makes it available (ISRs can't be blocked anytime). Thus such a thread waits until another thread calls "Give" for the same semaphore.
+To create the semaphore with the name "my_semaphore", initial value "0", and limit "1", you can use the following macro
+<code>
+K_SEM_DEFINE(my_semaphore, 0, 1);
+</code>
+Or create the k_sem structure and call the initialization function.
+<code>struct k_sem my_semaphore;
+k_sem_init(&my_semaphore, 0, 1);
+</code>
+Giving semaphore can be done with the function:
+<code>
+k_sem_give(&my_semaphore);
+</code>
+and taking the semaphore with the code as follows:
+<code>
+if (k_sem_take(&my_semaphore, K_MSEC(50)) != 0) {
+   printk("Semaphore not available!");
+} else {
+   /* semaphore availabe, execute the code here */
+}
+</code>
+As you can see the k_sem_take() function has a timeout that can prevent the thread from hanging. This argument can also be K_NO_WAIT (returns immediately) and K_FOREVER (blocks the thread).\\
+===== Mutexes =====
+Mutexes are similar to the semaphores but present two values only: locked and unlocked. Despite this, they are implemented also as the counter in which zero value means that the resource is unlocked, and any other value means that the resource is locked. If the mutex is locked three times it also must be unlocked three times to make it unlocked. Another feature that differs between mutexes and semaphores is that the mutex can be unlocked only by the same thread which locks it. Mutexes are mainly used to synchronize the critical shared code that can be executed from many threads.
+To create the mutex you can use the macro
+<code>
+K_MUTEX_DEFINE(my_mutex);
+</code>
+or the k_mutex structure definition and initialization as for the semaphores:
+<code>
+struct k_mutex my_mutex;
+k_mutex_init(&my_mutex);
+</code>
+Locking the mutex is done with the function:
+<code>
+if (k_mutex_lock(&my_mutex, K_MSEC(100)) == 0) {
+    /* mutex successfully locked */
+} else {
+    printk("Can't lock mutex\n");
+}
+</code>
+Here the timeout can be also K_NO_WAIT and K_FOREVER.\\
+Unlocking the mutex can be done with the function:
+<code>
+k_mutex_unlock(&my_mutex);
+</code>
+===== Tasks for the laboratory =====
+  - Write the program that blinks the LED as many times as it is set in the semaphore (decrementing semaphore with every blink). The semaphore can be given (incremented) by pressing the button. Thus if you press the button three times the LED will blink three times.