threadx.git/common/inc, branch dev

Updated ThreadX version constants and port strings to 6.5.2.202603 (#781)

2026-09-28T18:36:10Z

ThreadX still declares 6.5.1.202602 with hotfix 'a', which is the previous release rather than the one being cut. prepare_release.sh updated the five version constants in tx_api.h and the version string in 211 port headers across ports, ports_smp, ports_arch and ports_module. The hotfix letter is cleared, since the target has none. Nothing else changed: every line in the port commit carries a version, and no file outside an inc/tx_port.h was touched. The port consistency checks passed before the branch was cut, which is what the script gates on. Host regression 113/113 with zero warnings, and the AI disclosure check passes. Assisted-by: Claude Code (Opus 5)

Made ThreadX object names const-qualifiable behind an option (#761)

2026-09-28T18:08:13Z

Fixes #61 Object names are exposed as writable pointers throughout the kernel API, which rejects string literals in C++ and lets a caller modify a name an object still holds. Information services return those names through writable double pointers. Create services, control blocks, information services, the module manager and trace registration now preserve const qualification, behind TX_ENABLE_CONST_NAMES. The option defaults to off, so a build that says nothing gets exactly the types it got before. It is opt-in rather than opt-out because it changes the type of a public struct field: application code that copies a name into a writable CHAR * stops compiling, which is a reasonable thing to ask of a minor release and not of a patch one. Issue #780 tracks making it the default in 6.6. Two things the option reaches that its own call sites do not. TX_CHAR_TO_UCHAR_POINTER_CONVERT has exactly two users, both of them reading an object name in _tx_trace_object_register, and every form of that macro but the MISRA one casts the qualifier away without saying so; the conversion is now const in and const out, so nothing launders const to make the build pass. The FreeRTOS adapter holds the name pcTaskGetName retrieves in a TX_NAME_CONST pointer so that it tracks whichever declaration tx_thread_info_get has, and keeps its writable return type through an explicit MISRA C:2012 Rule 11.8 cast, because that signature is part of the FreeRTOS API. Default build: all seven host configurations and all five SMP configurations build with zero warnings and pass -- 113/113 on five host configurations, 100/100 on the two MISRA builds, 118/118 on SMP, 3/3 FreeRTOS. With TX_ENABLE_CONST_NAMES set, the host default and both MISRA configurations, the SMP trace configuration and the FreeRTOS adapter build with zero warnings and pass. Co-authored-by: Tilen Majerle Assisted-by: Codex (gpt-6-astra) Assisted-by: Claude Code (Opus 5)

Fixed the build of tx_misra.c with MISRA and event trace enabled (#746)

2026-09-16T03:08:23Z

tx_misra.c defines five pointer conversions for the trace component, and their prototypes sit in tx_trace.h behind TX_SOURCE_CODE. tx_misra.c is the one kernel source that does not define that macro, so it defines all five with no previous declaration. Under -Wmissing-declarations -Werror, which the kernel target is built with, the file does not compile at all, so TX_MISRA_ENABLE and TX_ENABLE_EVENT_TRACE cannot be enabled together. No build configuration defines both, which is why this has never surfaced. The five prototypes move out of the TX_SOURCE_CODE guard into their own block, next to where tx_api.h already declares _tx_misra_trace_event_insert - the sixth function of the same region, which escapes the problem for exactly that reason. Declarations only; no definition moves and no macro changes meaning. All 185 files in common/src now compile clean under all four combinations of the two macros with -Wall -Wextra -Wmissing-declarations -Werror, against five errors in tx_misra.c for the both-enabled case before. Object code is byte identical for the three combinations that already built: 0 of 185 files differ in each. Assisted-by: Claude Code (Opus 5)

Made the stack analyze binary search require several consecutive fill words, so unwritten holes in a used stack no longer cause the highest stack pointer to be under-reported (#720)

2026-09-10T15:02:42Z

The binary search in _tx_thread_stack_analyze() accepted a probe location as unused as soon as a single word still held TX_STACK_FILL. A word inside an otherwise used region that simply was never written - the padding of a partially initialized local array, for example - therefore made the search move away from the real boundary and report far less stack usage than the thread had actually consumed, which in turn kept the stack guard from firing. The probe now walks down from the candidate location and requires TX_THREAD_STACK_ANALYZE_FILL_WORDS consecutive fill words before it treats the location as unused, stopping early at the lowest location already known to hold the fill pattern. The new macro defaults to eight words and can be overridden in tx_port.h; setting it to one restores the previous behavior. Holes shorter than the configured run no longer mislead the search, and the result is unchanged for stacks that contain no such holes. Assisted-by: Copilot (Opus 5)

Release 6.5.1.202602a preparation (#547)

2026-06-08T14:59:04Z

* Updated version number constants * Updated port version strings --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Release 6.5.1.202602 preparation (#543)

2026-06-03T20:55:01Z

* Updated version number constants * Updated port version strings --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Fix default TX_TIMER_TICKS_PER_SECOND default value in tx_user_sample.h

2026-04-12T14:17:10Z

Changed default value to TX_16_ULONG.

Updated copyright headers and version number constants (#509)

2026-03-05T09:46:30Z

* Updated version number constants * Removed revision history from all files * Added Eclipse ThreadX contributors' copyright header

Updated the version number

2026-01-09T14:31:57Z

Updated version number and added build and hotfix.

2025-09-28T22:19:17Z