Problem
SolidSyslogFreeRtos_GetSysUpTime scales the FreeRTOS tick count to hundredths
of a second. On a 32-bit TickType_t whose configTICK_RATE_HZ does not divide
100, the tick counter reaches its own rollover before 2^32 hundredths do, and
the reported uptime returns to zero early — at 1000 Hz, after about 50 days
rather than the 497 that RFC 3418 TimeTicks calls for.
1000 Hz is FreeRTOS's default tick rate, so this is the configuration most
integrators will arrive with.
#725 removed the compile-time guard that refused to build outside the exact
envelope. Costing an integrator the whole FreeRTOS pack — the mutex included —
was the wrong price for a fidelity limit, so the adapter now builds everywhere
and states where it wraps early. This issue is the commitment to remove the
limit rather than document it.
Approach
The tick count alone cannot say how many times it has rolled over, so the
conversion needs to carry the phase across in state of its own. That is what
#725 put out of scope: it adds shared state to what is currently a pure
function, and the state needs a concurrency answer, since the callback runs
wherever a message is formatted and that may be more than one task.
The answer should not assume a lock. The library already injects
SolidSyslog_SetConfigLock for pool slot walks, and an AtomicCounter role
exists; which of those fits, or whether a lock-free read of a monotonic tick
source suffices, is the design question to settle first.
Acceptance criteria
Problem
SolidSyslogFreeRtos_GetSysUpTimescales the FreeRTOS tick count to hundredthsof a second. On a 32-bit
TickType_twhoseconfigTICK_RATE_HZdoes not divide100, the tick counter reaches its own rollover before 2^32 hundredths do, and
the reported uptime returns to zero early — at 1000 Hz, after about 50 days
rather than the 497 that RFC 3418 TimeTicks calls for.
1000 Hz is FreeRTOS's default tick rate, so this is the configuration most
integrators will arrive with.
#725 removed the compile-time guard that refused to build outside the exact
envelope. Costing an integrator the whole FreeRTOS pack — the mutex included —
was the wrong price for a fidelity limit, so the adapter now builds everywhere
and states where it wraps early. This issue is the commitment to remove the
limit rather than document it.
Approach
The tick count alone cannot say how many times it has rolled over, so the
conversion needs to carry the phase across in state of its own. That is what
#725 put out of scope: it adds shared state to what is currently a pure
function, and the state needs a concurrency answer, since the callback runs
wherever a message is formatted and that may be more than one task.
The answer should not assume a lock. The library already injects
SolidSyslog_SetConfigLockfor pool slot walks, and an AtomicCounter roleexists; which of those fits, or whether a lock-free read of a monotonic tick
source suffices, is the design question to settle first.
Acceptance criteria
TickType_tat 1000 Hz, the reported value is monotonicacross a tick-counter rollover and wraps only at 2^32 hundredths.
the integrator must guarantee, if anything, when more than one task
formats messages.
100 Hz tests stay green.
Platform/FreeRtos/Interface/SolidSyslogFreeRtosSysUpTime.hand
docs/platforms/freertos/index.md, and the link to this issue with it.