Re: [Xenomai-core] [PATCH-STACK] Synchronised timebases and more

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

Jan Kiszka wrote:
> ...
> The answer I found is to synchronise all time bases as good as possible.
> That means if one base changes its wall clock offset, all others need to
> be adjusted as well. At this chance, we would also implement
> synchronisation of the time bases on the system clock when they get
> started. Because skins may work with different type width to represent
> time, relative changes have to be applied, i.e. the core API changes
> from xntbase_set_time(new_time) to xntbase_adjust_time(relative_change).
> The patch (global-wallclock.patch) finally touches more parts than I was
> first hoping. Here is the full list:
> 
>  - synchronise slave time bases on the master on xntbase_start
>  - xntbase_set_time -> xntbase_adjust_time, fixing all time bases
>    currently registered
>  - make xnarch_start_timer return the nanos since the last host tick
>    (only ia64 affected, all others return 0 anyway, causing one tick
>    off when synchronising on system time -- but this fiddling becomes
>    pointless on the long term due to better clocksourses on all archs)
>  - adapt vrtx, vxworks, and psos+ skin to new scheme, fixing sc_sclock
>    at this chance
>  - make xnarch_get_sys_time internal, no skin should (need to) touch
>    this anymore

Forgot to mention two further aspects:

 - The semantic of XNTBSET was kept time base-local. But I wonder if
   this flag is still required. Unless it was introduced to emulated
   some special RTOS behaviour, we now have the time bases automatically
   set on startup. Comments welcome.

 - This patch is a nice foundation for the stuff I have in mind post 2.4
   release: an infrastructure to synchronise the Xenomai clock on
   arbitrary external sources like local ToD, RTCs, sync packets sent
   over CAN (CANopen...), Ethernet (RTnet, IEEE1588, ...), or whatever
   media (poor-man's nullmodem links...)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]