MCUXpresso_MIMXRT1021xxxxx/boards/evkmimxrt1020/rtos_examples/freertos_mutex
imi415 d983b267f0
Initial SDK v2.12.0
2022-08-23 23:00:33 +08:00
..
armgcc Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
FreeRTOSConfig.h Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
board.c Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
board.h Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
clock_config.c Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
clock_config.h Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
dcd.c Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
dcd.h Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
evkmimxrt1020_sdram_init.jlinkscript Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
freertos_mutex.c Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
freertos_mutex_v3_10.xml Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
pin_mux.c Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
pin_mux.h Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00
readme.txt Initial SDK v2.12.0 2022-08-23 23:00:33 +08:00

readme.txt

Overview
========
This document explains the freertos_mutex example. It shows how mutex manage access to common
resource (terminal output).

The example application creates two identical instances of write_task. Each task will lock the mutex
before printing and unlock it after printing to ensure that the outputs from tasks are not mixed
together.

The test_task accept output message during creation as function parameter. Output message have two
parts. If xMutex is unlocked, the write_task_1 acquire xMutex and print first part of message. Then
rescheduling is performed. In this moment scheduler check if some other task could run, but second
task write_task+_2 is blocked because xMutex is already locked by first write task. The first
write_task_1 continue from last point by printing of second message part. Finaly the xMutex is
unlocked and second instance of write_task_2 is executed.




Toolchain supported
===================
- IAR embedded Workbench  9.30.1
- Keil MDK  5.37
- GCC ARM Embedded  10.3.1
- MCUXpresso  11.6.0

Hardware requirements
=====================
- Mini/micro USB cable
- EVK-MIMXRT1020 board
- Personal Computer

Board settings
==============
No special settings are required.

Prepare the Demo
================
1.  Connect a USB cable between the host PC and the OpenSDA USB port on the target board. 
2.  Open a serial terminal with the following settings:
    - 115200 baud rate
    - 8 data bits
    - No parity
    - One stop bit
    - No flow control
3.  Download the program to the target board.
4.  Either press the reset button on your board or launch the debugger in your IDE to begin running the demo.

Note:
To debug in qspiflash, following steps are needed:
1. Select the flash target and compile.
2. Set the SW8: 1 off 2 off 3 on 4 off, then power on the board and connect USB cable to J23.
3. Start debugging in IDE.
   - Keil: Click "Download (F8)" to program the image to qspiflash first then clicking "Start/Stop Debug Session (Ctrl+F5)" to start debugging.
Running the demo
================
After the board is flashed the Tera Term will start periodically printing strings synchronized by
mutex.

Example output:
"ABCD | EFGH"
"1234 | 5678"
"ABCD | EFGH"
"1234 | 5678"