Increasing tick resolution without affecting delay functions

[charlesrwest]

Hello,

I was hoping increase the tick frequency of my ChibiOS frequency by increasing CH_CFG_ST_FREQUENCY, but I've noticed that my calls to chThdSleepMicroseconds seem to be returning sooner when I increase that value. If I may ask, what is the best way to increase tick resolution (primarily so the temporal resolution of chVTGetSystemTimeX is increased) without effecting the timing of delay functions?

Thanks!
Charlie

[Giovanni]

Hi,

Increasing resolution should not affect delay functions. chThdSleepMicroseconds() approximates the parameter to the tick resolution, so increasing the tick frequency may appear as a shorter delay.

Try enabling assertions and state checker, may be you are hitting some limit, if so then you should try increasing the "delta" parameter.

Giovanni

[charlesrwest]

I apologize, but I am not sure how to do that. I've replicated the error with a minimal length program (below). In testing, I noticed that the (currently commented out) chThdSleepMilliseconds function performs as expected (same frequency despite resolution changes) while the microseconds delay function experiences changes as the resolution changes. Changing CH_CFG_ST_FREQUENCY from 1000 to 10000 significantly increases the blink frequency. The test was done with an STM32F072 using a fresh git pull from master.

Further testing makes it look like it might be an overflow issue? I did a test using the MS2ST and US2ST functions (shown below the example program) and got the following results:

Millisecond ticks: 5000
Microsecond ticks: 706

I suppose that I should just make sure I only use chThdSleepMicroseconds with small values? If I may ask, what do you think?

Code: Select all

#include "ch.h"
#include "hal.h"

int main(void)
{
//Initialize HAL and Kernel
halInit();
chSysInit();

//Enable LED
palSetPadMode(GPIOB, 6, PAL_MODE_OUTPUT_PUSHPULL);
palClearPad(GPIOB, 6);

while(true)
{
palTogglePad(GPIOB, 6); //Toggle

chThdSleepMicroseconds(500000);
//chThdSleepMilliseconds(500);
}

}


Code: Select all

uint32_t CH_CFG_ST_FREQUENCY = 10000UL;

printf("Millisecond ticks: %u\n", ((uint32_t)(((((uint32_t)(500)) *((uint32_t)CH_CFG_ST_FREQUENCY)) + 999UL) / 1000UL)));

printf("Microsecond ticks: %u\n", ((uint32_t)(((((uint32_t)(500000)) * ((uint32_t)CH_CFG_ST_FREQUENCY)) + 999999UL) / 1000000UL)));


[Giovanni]

Hi,

There are two possible issues with chthdSleepMicroseconds():

1) The specified time is rounded up to tick resolution so chthdSleepMicroseconds(1) is equal to chthdSleepMicroseconds(100) if the system tick is set to 10000Hz. Note that there is always an -1...0 ticks uncertainty in timings so chThdSleepMicroseconds(200) can be anything between 101 and 200 uS with a 10000Hz tick.

2) It is a macro that performs integer calculations, if the specified time is too large then truncation may occur and the result is wrong. This is known, we don't want to use 64 bits math in the system.

Giovanni

[charlesrwest]

Thanks for the detailed response! I will check for overflow when using that macro and reimplement my LED object to use millisecond delay to reduce the likelihood of trouble.

Thanks again,
Charlie