 Hello, let's continue with exercises on Qs. This time we will practice sending the structure over the Q. Till now we were considering Qs transmitting simple data. Qs allow to define type of data which would be passed over the Q, it can be with different variables set or structures or even pointers. So now in this example we will check how to use different data type than a simple type. Let's start from stm32cubemix or stm32cubedie with an 3-year TOS configuration. We can reuse previous lab with two senders and one receiver. All of those tasks should have the same priority, for example OSPriorityNormal. With Q1 item size please put a structure called data instead of existing unsigned int 8-bit. Please keep Q size at 8 components like before. After this please generate a project and open main.cfile. When main.cfile we need to define data structure. I propose to keep there one 16-bit variable called value and one 8-bit variable called source. Then we will define two variables of data type which would be used by sender tasks. Data to send 1 with value set to a and source set to 1. This would be managed by sender1 and data to send 2 with value set to b and source set to 2. This would be managed by sender2. Please remember to define all of those within user code sections before main function. Our next step should be modification of the code within sender tasks entry functions. Let's start with start sender1 function. Within its endless loop we will perform the following operations. Using small s over swo using task underscore action function. Sending data to send 1 into the queue with 200 milliseconds timeout. Wait 2 seconds in blocked state by calling osdelay function. Similar code we need to prepare within start sender2 function but we should send big s over swo interface and send data to send 2 over the queue with the same timeout. So 200 milliseconds. Then we need to prepare the code of the receiver. Within start receiver function we will perform the following actions. Within its initialization part we will declare the locker variable of data type. It will be called red value and it will be used to store data taken from the queue. Then within the endless loop of this function we will send big r over swo interface using itm underscore send char function. The same which is proposed within task underscore action code. Then we will try to get the data from the queue and store it into the local variable red value. We will use here os wait forever timeout and the third action within this endless loop would be to analyze the received data and based on the source value we will either turn off or turn off the LED. In this case you can see that we are using some labels as we are using the nuclear board under those LED green pin and LED green port there is GPIOA and pin 5. At the end we will send our value part of the data structure which we just received from the queue. So we will send this value part over swo interface using task underscore action function. After those code modifications please compile the project. Start debug session, open switm console and run the application. What should be the result? Let's focus on selected area. Sender 1 is selected as first one so it sends big s over swo and then data to send 2 into the queue. Its source field is 2 and value field is b. Then it is going to blocked state for 2 seconds. After this sender 1 is selected as active task so it sends small s over swo and then it is sending data to send 1 into the queue. Its source field is 1 and value field is a. Then it is going to blocked state for 2 seconds as well. After this receiver task is taking runtime and it has no OS delay so it can execute its endless loop till it will read all the data from the queue. As within CMC's OS V2 we are working with the queue type 5 also first in first out. The first object read by receiver is data to send 2 as it has been sent as a first one into the queue. So we can see r, b and led should be turned off. In receiver second iteration it treats data to send 1 so we see r, a on swv console and led should be turned on. Then receiver third iteration it manages to send r over swo interface and then the queue is empty so receiver task is sent to blocked state. After a while all of 3 tasks are in a blocked state so sender 1 and sender 2 due to OS delay and receiver due to not available data on the queue. Sender 2 is woken up as a first one so we can see big s on swv console. Then sender 1 is woken up so we see small s on the console. After those 2 actions queue contains 2 new components and receiver can continue its operations. Please notice that during its operations receiver continues from the point it has been blocked last time. As it managed to send big r over swo it displays now small b as a result of read from the queue.