AEMB has just been updated last week. The fix will prevent the tasks from breaking out of their loop. This solves the problem I faced last time where the tasks run and goes into the main function. Therefore, the new AEMB will need to be tested again to check for any more problems. Here is the new output with 2 tasks running with same priority 1.
As the output shows, the tasks are both running continuously. However, as there are no mutual exclusion between the two tasks printing messages, there are a clash of text in the output. So, the tasks should now be written with usage of mutex to prevent the clash of text.
Since there are modification needed to be made in FreeRTOS port, the API of mutex in FreeRTOS cannot be used. Instead, hardware mutex is used with assembly coding. The coding for hardware mutex is written as below. The assembly coding are the mutex coding while the tasks are only printing the messages with iprintf function.
The output of the tasks with mutex is as shown.
They still have the same output. This means the mutex is not functioning somehow. The waveform output will be needed to investigate what was happening during the running of FreeRTOS. However, the coding for iprintf will be identified before checking on the wave output. The flowchart is as shown.
In the flowchart, the iprintf function will go through many different functions such as memchr and memmove which will load the characters. Also, the outbyte function is where the message is displayed on the screen. By using the assembly code number of outbyte, we can determine the waveform characteristic for the mutex output. Ideally, no two outbyte should run at the same time from task 1 and task 2. When the outbyte of task 1 runs, the outbyte of the task 2 should not run.
The lines form the outbyte of the messages. Each group of eight lines form a message. At some sections, the group of outbytes are close to each other. This should not happen as when one iprintf function finishes, the next iprintf should go through many functions before outbyte as controlled by the mutex bit. Going through the MSR bits, it was found that the interrupt handler clear the mutex bit which is not supposed to. The interrupt handler saves all MSR bits and restored them, meaning that the mutex bit will be changed. This can be proven with the mts function used during the ISR. This needs to be modified so that the mutex bit is not affected.
In this modification, I decided to only restore the carry bit and interrupt enable bit. For future purposes, the other bits can be restored with the same method. All I did was check the previous MSR bits from the stack. By checking the carry bit and interrupt enable bit, I choose to restore them both with msrset/msrclr functions before finishing the ISR.
The output shows mutex is working properly. From the wave output, during a mutex, only one group of outbyte functions run. The mutex bit is only affected by the mutex code itself, and not by other functions.
0 Comments