portable: optimize BaseType_t access for GCC ARM_CM3

[ys160-boop]

Description

Define portBASE_TYPE_ENTER_CRITICAL() and portBASE_TYPE_EXIT_CRITICAL() as no-ops for the single-core GCC ARM_CM3 port.

BaseType_t and UBaseType_t are 32-bit for this port, and the timer status field accessed by the affected APIs is 8-bit. These accesses can be performed atomically on Cortex-M3, so the affected query APIs do not need to enter a critical section.

This removes unnecessary critical-section overhead from the affected queue, task, and timer query APIs while leaving the normal portENTER_CRITICAL() and portEXIT_CRITICAL() behavior unchanged.

Test Steps

• Cross-compiled queue.c, tasks.c, and timers.c for Cortex-M3 using arm-none-eabi-gcc with -mcpu=cortex-m3 -mthumb -O2.
• Disassembled the following APIs:
  • uxQueueMessagesWaiting()
  • uxQueueSpacesAvailable()
  • uxTaskPriorityGet()
  • uxTaskBasePriorityGet()
  • xTimerGetReloadMode()
  • xTimerIsTimerActive()
• Verified that the normal execution paths no longer contain calls to vPortEnterCritical() or vPortExitCritical().
• Verified that the expected loads and timer status-bit checks remain in the generated Cortex-M3 instructions.
• Ran git diff --check with no errors.

Checklist:

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

Contributes to #1059.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud