I'm trying the tickless mode on the F0 right now and it seems to stop when the timer wraps.
Using a 32bit counter it's not visible since it takes a long time to complete, but on a 16bit timer scheduling stops for about 1-2 seconds every 1-2 seconds...
I'm using TIM14 but it's the same with any 16bit timer.
Tick-less mode support for NilRTOS
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Tick-less mode support for NilRTOS
Is the systime_t type 16 bits as well or still 32bits? there is an assumption that the type size is equal to the counter size.
Giovanni
Giovanni
-
- Posts: 483
- Joined: Sat Nov 19, 2011 6:47 pm
- Location: Le Mans, France
- Has thanked: 21 times
- Been thanked: 30 times
Re: Tick-less mode support for NilRTOS
Giovanni wrote:Is the systime_t type 16 bits as well or still 32bits? there is an assumption that the type size is equal to the counter size.
Giovanni
I didn't change the typedef so that's probably the problem.
Thanks a lot
-
- Posts: 483
- Joined: Sat Nov 19, 2011 6:47 pm
- Location: Le Mans, France
- Has thanked: 21 times
- Been thanked: 30 times
Re: Tick-less mode support for NilRTOS
That was indeed the problem
I had to tweak the frequency for nilThdSleep to works, it it's still not really stable. (sometimes hangs a thread)
I checked that the delay value is lower than the counter max time.
Maybe I did something wrong, I'll check later.
I had to tweak the frequency for nilThdSleep to works, it it's still not really stable. (sometimes hangs a thread)
I checked that the delay value is lower than the counter max time.
Maybe I did something wrong, I'll check later.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Tick-less mode support for NilRTOS
Please let me know, it is very experimental.
Note that you can have issue while debugging because the HW counter does not stop.
Giovanni
Note that you can have issue while debugging because the HW counter does not stop.
Giovanni
-
- Posts: 483
- Joined: Sat Nov 19, 2011 6:47 pm
- Location: Le Mans, France
- Has thanked: 21 times
- Been thanked: 30 times
Re: Tick-less mode support for NilRTOS
ah indeed.
I need to do DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_TIM14_STOP;
This will prevent my systick counter to run during debug.
Thanks!
I need to do DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_TIM14_STOP;
This will prevent my systick counter to run during debug.
Thanks!
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
-
- Posts: 483
- Joined: Sat Nov 19, 2011 6:47 pm
- Location: Le Mans, France
- Has thanked: 21 times
- Been thanked: 30 times
Re: Tick-less mode support for NilRTOS
Yes I read in the datasheets, that the counters could be stopped during debug
Here are my niltimer files:
https://github.com/mobyfab/OpenTCS/blob ... niltimer.h
https://github.com/mobyfab/OpenTCS/blob ... niltimer.c
In case that's useful for anyone.
Here are my niltimer files:
https://github.com/mobyfab/OpenTCS/blob ... niltimer.h
https://github.com/mobyfab/OpenTCS/blob ... niltimer.c
In case that's useful for anyone.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Tick-less mode support for NilRTOS
In the ChibiOS 3.0 branch the new HAL can work with both RT and Nil kernels (and potentially others) through an OS abstraction layer (named without much fantasy OSAL).
In the new HAL there is a specific driver now (ST, systick) that implements the function of niltimer.x for the host OS, I'll try to reuse that code there.
Giovanni
In the new HAL there is a specific driver now (ST, systick) that implements the function of niltimer.x for the host OS, I'll try to reuse that code there.
Giovanni
Re: Tick-less mode support for NilRTOS
Giovanni,
I have run into an issue with Nil (V3.0) tickless mode which has me a bit baffled. Demo code works fine in RT, both tickless and with ticks, and Nil with ticks.
I am using an STM32F103. Have the following set in nilconf.h
Compller gcc-arm-none-eabi-4_7-2013q3
In the following code fron nil.c, [ if (tp->timeout <= next - 1)] is always false and next is always 0, which of cource hangs everything eventually. The results are very dependant on thread wait times and the number of threads.
If I change the code for the case where a thread is not woken as follows this part runs fine.
Now I thought it may have been that tp->timeout was being somehow declared as a uint32_t instead of uint16_t (systime_t), but I even commented out the uint32_t systime_t declaration in nilcore.h to prevent this.
My understanding of your code is that it should do the correct operation (next - 1 should equal 65536) and set next to smallest wating thread time delay, but that is not what it is doing.
This happens with compiler options -O2 and -O0.
A very similar thing happens chSchGoSleepTimeoutS in the test before nil.nexttime is set and splitting the code into three lines fixes the problem.
I know you are away. There is no hurry, unless you have any bright ideas or I'm completely mistaken. I will have a look at the generated assembler code tomorrow and see if I can work it out.
Regards
Saraben
I have run into an issue with Nil (V3.0) tickless mode which has me a bit baffled. Demo code works fine in RT, both tickless and with ticks, and Nil with ticks.
I am using an STM32F103. Have the following set in nilconf.h
Code: Select all
#define NIL_CFG_ST_RESOLUTION 16
#define NIL_CFG_ST_FREQUENCY 10000
#define NIL_CFG_ST_TIMEDELTA 2
Compller gcc-arm-none-eabi-4_7-2013q3
In the following code fron nil.c, [ if (tp->timeout <= next - 1)] is always false and next is always 0, which of cource hangs everything eventually. The results are very dependant on thread wait times and the number of threads.
Code: Select all
void chSysTimerHandlerI(void) {
#if NIL_CFG_ST_TIMEDELTA == 0
...TICK PART...
#else
thread_t *tp = &nil.threads[0];
systime_t next = 0;
chDbgAssert(nil.nexttime == port_timer_get_alarm(), "time mismatch");
do {
/* Is the thread in a wait state with timeout?.*/
if (tp->timeout > 0) {
chDbgAssert(!NIL_THD_IS_READY(tp), "is ready");
chDbgAssert(tp->timeout >= nil.nexttime - nil.lasttime, "skipped one");
tp->timeout -= nil.nexttime - nil.lasttime;
if (tp->timeout == 0) {
/* Timeout on semaphores requires a special handling because the
semaphore counter must be incremented.*/
if (NIL_THD_IS_WTSEM(tp))
tp->u1.semp->cnt++;
else if (NIL_THD_IS_SUSP(tp))
*tp->u1.trp = NULL;
chSchReadyI(tp, MSG_TIMEOUT);
}
else {
if (tp->timeout <= next - 1)
next = tp->timeout;
}
}
/* Lock released in order to give a preemption chance on those
architectures supporting IRQ preemption.*/
chSysUnlockFromISR();
tp++;
chSysLockFromISR();
} while (tp < &nil.threads[NIL_CFG_NUM_THREADS]);
nil.lasttime = nil.nexttime;
if (next > 0) {
nil.nexttime += next;
port_timer_set_alarm(nil.nexttime);
}
else {
/* No tick event needed.*/
port_timer_stop_alarm();
}
}
If I change the code for the case where a thread is not woken as follows this part runs fine.
Code: Select all
systime_t next = - 1;
.......
else {
if (tp->timeout <= next)
next = tp->timeout;
}
Now I thought it may have been that tp->timeout was being somehow declared as a uint32_t instead of uint16_t (systime_t), but I even commented out the uint32_t systime_t declaration in nilcore.h to prevent this.
My understanding of your code is that it should do the correct operation (next - 1 should equal 65536) and set next to smallest wating thread time delay, but that is not what it is doing.
This happens with compiler options -O2 and -O0.
A very similar thing happens chSchGoSleepTimeoutS in the test before nil.nexttime is set and splitting the code into three lines fixes the problem.
I know you are away. There is no hurry, unless you have any bright ideas or I'm completely mistaken. I will have a look at the generated assembler code tomorrow and see if I can work it out.
Regards
Saraben
Who is online
Users browsing this forum: No registered users and 9 guests