“Philippe Elskens” <firstname.lastname@example.org> wrote in message
Thanks David and Mario for your answers.
David > In fact the error come from timer_settime only and after a long
time, but the application is running 24 h/day. And that you describe is
really that I get.
Mario > Yes I can use a solution to detect silence on a counter value and
can configure my timer to run in “continue” mode rather than “one shot”
mode. But now I use a C++ wrapper on this function which throw an error
the function returns -1 =:o( .
Have the function do a retry if timer_settime return EAGAIN.
But note that if you only do it once when the program start you will most
probably never see that error
“Mario Charest” email@example.com a écrit dans le message de news:
cub5oi$f1m$> firstname.lastname@example.org> …
“David Gibbs” <> email@example.com> > wrote in message
news:cub47l$o4v$> firstname.lastname@example.org> …
Philippe Elskens <> email@example.com> > wrote:
I use a software timer to detect a silence on a serial line. Each time
byte or group of bytes is received, I restart my timer with
function. The timer is created during the inialisation phase of the
And some times ( rarely ) , I get an error (-1) with errno positionned
This errno is not documented in the timer_settime function
Any ideas appreciated .
I wouldn’t use timer_settime on every character, instead I would create
function that gets called at regular interval (interval is decided by the
required precision of you timer) and then I would manager a timer time
counter inside the handler.
Or you could use dev_read timeout capability if you don’t need timeout
then .1 seconds.
It is not clear, are you saying you sometimes get the error
at initialization time? Or sometimes, during the run of the
program you get the error from timer_settime() to restart the
If it is for timer_create(), this is a documented error – you’re
out of system timers. You can increase the number available with
the -t option to Proc32.
If it is at one of the (later) timer_settime() calls. Well,
it has been a while, ok a long while, since I looked at that code
inside Proc. If I recall correctly, there was a case where if the
message asking for a change was being handled and, during the middle
of it, the timer actually fired (driven by the timer interrupt) which
would also be updating the state of that timer, the user request would
get this error.
Is this a possibility? That is, when you’re seeing this, could the
reset be close to the expiry of the previous setting?
QNX Training Services
Please followup in this newsgroup if you have further questions.