CMSIS v2 emulation assumes ticks == milliseconds

[andyross]

ARM docs say that the timeout values used in CMSIS v2 are milliseconds, but our implementation (c.f. osDelay() in lib/cmsis_rtos_v2/kernel.c and other places) wants to treat these numbers as Zephyr ticks instead. Our test code seems to be using a mix of conventions.

I added a check to force the tick rate to 1000 when CMSIS is enabled as a workaround[1], but this needs to be cleaned up at some point.

[1] A fairly reasonable one. Ported CMSIS apps are obviously going to be OK with millisecond timing given that's what the API gave them to begin with.

[andyross]

Found while cleaning tests up for high tick rates in #16782

[nashif]

@jocelyn-li please assign

[rljordan-zz]

This is just code cleanup. Priority will be reduced to Low.

[andyross]

FWIW: this isn't cleanup. Code using CMSISv2 timing APIs only works correctly if CONFIG_SYS_CLOCK_TICKS_PER_SEC is equal to 1000. That's not high priority, and in fact this constraint is enforced by code, but it's a real bug.

[LeiW000]

@andyross , sorry, I misunderstood it. Anyway, Peng and I will try to fix it.

[carlescufi]

@nashif @chen-png any chance we can address this?

[andyross]

Actually this was a mistaken bug to begin with. While CMSIS version one used milliseconds as the native API, version two passes system ticks to the same functions with the same names. Our code was correct to begin with, though the naming was confusing in a few places (probably owing to cut-n-paste from the v1 original).

Regardless, this is all cleaned up in #24956, which uses our now-native support for tick-based timeouts.