RTEMS behaviour when using rtems_clock_tick incorrectly?

[Joel Sherrill]

On 7/5/2012 5:06 AM, Sebastian Huber wrote:
> Hello,
>
> the rtems_clock_tick() function should be called only by the clock driver.  In
> the RTEMS configuration you specify the micro seconds per tick.  The clock
> driver will then normally setup a hardware timer which triggers in the
> configured interval.  The interrupt service routine corresponding to the
> hardware timer will call rtems_clock_tick().
As Sebastian mentions below the hardwire timer is  assumed to be a 
"square wave"
repeating interrupt at a constant rate. Emphasis here on CONSTANT. Task 
delays,
periods, timeouts, uptime, wall time, etc would all become weirdly 
inaccurate if
rtems_clock_tick() is not called at a regular rate.

I don't know what the 1553 to system clock synchronization requirements 
really are
and can't give you a solution. But calling clock tick on the sync signal 
is not good.


--joel


> On 07/05/2012 11:53 AM, Leonard Bise wrote:
>> Hello all,
>>
>> We're working on a project where we have a RTEMS application which uses the
>> rtems_clock_tick function to signal that a tick elapsed.
>> Now I just noticed that in some case the implementation is badly done and this
>> function can be called two successive times in a very short amount of time.
>>
>> This happens because the rtems_clock_tick is called from an IRQ which is
>> triggered when receiving a synch signal over the MIL-1553 bus. This IRQ in some
>> error cases can be trigged two times in the lapse of a few milliseconds.
>>
>> For debugging purposes and to better understand the problem we have, could
>> anyone shed some light on what could or would happen to RTEMS scheduling in
>> case the ticks are very close to each other instead of being called roughly
>> once per second?
> In case the interval between rtems_clock_tick() calls doesn't fit to the value
> specified in the configuration the time of day will be wrong (maybe only
> sometimes).  Also the timeouts may be wrong.  I would say this could lead to a
> pretty unpredictable behaviour.
>


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985