Delay setting RTEMS clock with TOD_Set.

[Rafael Morales]

Thank you for your responses.

I will play with different "CONFIGURE_MICROSECONDS_PER_TICK" values
configuring "CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER" and 
setting the clock.

I expect to find the right values.

Best regards.

> On 4/10/2013 8:21 AM, Gedare Bloom wrote:
>> You can control the tick resolution with the configuration option:
>> #define CONFIGURE_MICROSECONDS_PER_TICK 1000
>> Or some suitable number other than 1000. (The default is 10000.)
>> This option affects the granularity of timing and scheduling events.
> Your examples did not use any public APIs. What did you use to set the 
> clock?
> If rtems_clock_set(), then it is specified at a tick granularity. The 
> POSIX
> clock_settime() and clock_gettime() use struct timespec to specify the 
> time.
> Some commonly used POSIX time related methods are enabled even when
> --disable-posix is specified.
>
> If this is simply rounding based on the CONFIGURE_MICROSECONDS_PER_TICK,
> then you can configure with 
> CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
> and run various values through setting and getting the clock.
>
> The disable/enable dispatch will only have impact if there is a task
> readied as a side-effect of changing the time. And this leads to
> preemption of the currently executing task.
>
> --joel
>> -Gedare
>>
>> On Wed, Apr 10, 2013 at 9:16 AM, Gedare Bloom <gedare at rtems.org> wrote:
>>> I guess this is in the rtems_clock_set routine that the TOD_Set is 
>>> called? [1]
>>>
>>> My best guess is that the granularity of the time is quite coarse, so
>>> you are seeing some rounding errors based on when in the current
>>> "tick" the TOD_Set is called. For example, look at lines 51-53:
>>>
>>>      newtime.tv_sec = _TOD_To_seconds( time_buffer );
>>>      newtime.tv_nsec = time_buffer->ticks *
>>>        rtems_configuration_get_nanoseconds_per_tick();
>>>
>>> The fine-grained resolution of time (nanoseconds) is approximated by
>>> the number of ticks times the configured ns per tick. By default this
>>> is going to be about 10 milliseconds per tick, so you would expect on
>>> average about 5 ms difference between the actual time and the
>>> approximated time.
>>>
>>> [1] 
>>> http://git.rtems.org/rtems/tree/cpukit/rtems/src/clockset.c?id=4.10.2
>>>
>>> -Gedare
>>>
>>> On Wed, Apr 10, 2013 at 6:00 AM, Rafael Morales <rmorales at iaa.es> 
>>> wrote:
>>>> Dear all,
>>>>
>>>> We are using a development system based on Leon3 at 25MHz clock and 
>>>> RTEMS
>>>> 4.10 (Gaisler version 4.10.1.2.8).
>>>>
>>>> We are experiencing a big delay setting the clock time with TOD. The
>>>> sequence is:
>>>>
>>>>       struct timespec startTimeStamp;
>>>>      get_time_stamp(&startTimeStamp);
>>>>
>>>>      _Thread_Disable_dispatch();
>>>>      _TOD_Set( newtime );
>>>>      _Thread_Enable_dispatch();
>>>>
>>>>      struct timespec stopTimeStamp;
>>>>      get_time_stamp(&stopTimeStamp);
>>>>
>>>>
>>>> If we get the new time after the _TOD_Set, we see that current time 
>>>> as about
>>>> 1-5 milliseconds late. We have try to delete the 
>>>> _Thread_Disable_dispatch
>>>> and _Thread_Enable_dispatch with no results. It seems that the call 
>>>> _TOD_Set
>>>> is the responsible of the delay
>>>>
>>>> Any idea about how to manage this situation?
>>>>
>>>> Thanks in advance.
>>>>
>>>>> Hi,
>>>>>
>>>>> here is the proof for the patched hello world on the sis target 
>>>>> and the
>>>>> patch generated by git. I hope it's okay.
>>>>>
>>>>> I also got a first draft of the proposal, so the question is: Who 
>>>>> wants to
>>>>> read it?
>>>>>
>>>>> Regards,
>>>>> Philipp
>>>>>
>>>>>
>>>>> screenshot:
>>>>> https://wwwpub.zih.tu-dresden.de/~s8940405/gdb_hello_world.png
>>>>>
>>>>> patch:
>>>>>
>>>>> https://wwwpub.zih.tu-dresden.de/~s8940405/0001-hello-world-gsoc-2013-fix.patch 
>>>>>
>>>>> _______________________________________________
>>>>> rtems-users mailing list
>>>>> rtems-users at rtems.org
>>>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-users
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>
>