Rép. : Re: [Xenomai-core] rtdm, rtc and printk driver.

Rép. : Re: [Xenomai-core] rtdm, rtc and printk driver.

[Marc LE DOUARAIN]

>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 23/02/07 15:55
>>>

>>>>> Jan Kiszka <jan.kiszka@domain.hid> 23.02 14:47 >>>
>>>Nicolas BLANCHARD wrote:
>>> Hello,
>>>  
>>> I've write a little rtdm driver to r/w RealTimeClock on rtc146818
>>> chipset.
>>
>>/me not having done much with rtc (hmm, a lot of years back on PCs, I
>>think): can this chip be found in normal PC hardware? Or is it only
on
>>specific embedded boards? (Means: can I actually play with your
driver? :) )
 
>Motorola 146818 circuit is a 6800 peripheral CMOS device,
>it's often used with processors 6800 and 8085.
>I think it's used on a lot of x86 board.

First nice work Nicolas ! (he is my coworker)
Time usage for us is really important in our field activity, and more
important without too much drift. And this real-time driver let us to
have direct access to the RTC values instead of the Linux system one
that generally drift a lot per day...(it was already the same problem
under RTLinux) And without a secondary mode switch...

Nowadays, you will generally not find directly a 146818 chip or
compatible (like the Dallas ones). Many CPUs (for example the SIS
Vortex86 we use on our embedded cards) have integrated in themself, on a
single chip, many antique PC peripherals like this RTC compatible
146818, a 8254 system timer, the dual 8259 interrupt controller. Also
sometimes the serials 16550 UART are included !!!

So yes, for sure on many computers you will be able to use it !


>>> I also use this driver to write kernel message from user-space
>>> (printk).
>>>  
>>> In attachment you can find an archive with the driver and an example
of
>>> use (just code).
>>> to compil, you must change kernel sources directory
(KERNELSOURCEDIR
>> flag).
>>>  
>>> It Based on code of Jan Kiszka found in http://www.captain.at/ 
>>>  
>>> I hope it could be interesting.
>>> All feedback are welcome.
>>>  
>>
>>You will get it. Thanks for sharing your code!
>>

It seems normal to us to share some possible usefull stuff like this
one, keeping the free software spirit!

Re: Rép. : Re: [Xenomai-core] rtdm, rtc and printk driver.

[Jan Kiszka]

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

Marc LE DOUARAIN wrote:
>>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 23/02/07 15:55
> 
>>>>>> Jan Kiszka <jan.kiszka@domain.hid> 23.02 14:47 >>>
>>>> Nicolas BLANCHARD wrote:
>>>> Hello,
>>>>  
>>>> I've write a little rtdm driver to r/w RealTimeClock on rtc146818
>>>> chipset.
>>> /me not having done much with rtc (hmm, a lot of years back on PCs, I
>>> think): can this chip be found in normal PC hardware? Or is it only
> on
>>> specific embedded boards? (Means: can I actually play with your
> driver? :) )
>  
>> Motorola 146818 circuit is a 6800 peripheral CMOS device,
>> it's often used with processors 6800 and 8085.
>> I think it's used on a lot of x86 board.
> 
> First nice work Nicolas ! (he is my coworker)
> Time usage for us is really important in our field activity, and more
> important without too much drift. And this real-time driver let us to
> have direct access to the RTC values instead of the Linux system one
> that generally drift a lot per day...(it was already the same problem
> under RTLinux) And without a secondary mode switch...

So you need such an interface for time-stamping, or also for scheduling
events based on a RTC-provided date? I had a short look at the driver,
and it seems that there exist ideas to register an interrupt on the RTC
(it's currently freed but never acquired).

The long-term question for me is if there is a need to synchronise the
system clock (or some skin timebase in future Xenomai versions) on an
external sources like the RTC here. Not that I'm desperately locking for
work, it's just good to know user requirements whenever further design
decisions [on the time subsystem] have to be made.

> 
> Nowadays, you will generally not find directly a 146818 chip or
> compatible (like the Dallas ones). Many CPUs (for example the SIS
> Vortex86 we use on our embedded cards) have integrated in themself, on a
> single chip, many antique PC peripherals like this RTC compatible
> 146818, a 8254 system timer, the dual 8259 interrupt controller. Also
> sometimes the serials 16550 UART are included !!!
> 
> So yes, for sure on many computers you will be able to use it !
> 

OK, thanks.

> 
>>>> I also use this driver to write kernel message from user-space
>>>> (printk).
>>>>  
>>>> In attachment you can find an archive with the driver and an example
> of
>>>> use (just code).
>>>> to compil, you must change kernel sources directory
> (KERNELSOURCEDIR
>>> flag).
>>>>  
>>>> It Based on code of Jan Kiszka found in http://www.captain.at/ 
>>>>  
>>>> I hope it could be interesting.
>>>> All feedback are welcome.
>>>>  
>>> You will get it. Thanks for sharing your code!
>>>
> 
> It seems normal to us to share some possible usefull stuff like this
> one, keeping the free software spirit!
> 

Then you shall benefit from this: :)

You may have a locking problem. Calling CMOS_READ/WRITE is not safe from
Xenomai context (I wish we had that domain violation debugging feature
already - classic scenario here). There is a locking mechanism embedded
which is based on the assumption that it can protect itself from
preemption via local_irq_save - an assumption that is not true from the
Xenomai perspective.

If there are no further RTC users in your running system, you should
just do direct hardware access and your own locking around it. But
CMOS_READ [1], e.g., is used in quite a few places in the kernel, one
would have to check under which conditions to really play safe.

Jan

[1] http://lxr.free-electrons.com/ident?i=CMOS_READ


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

Re: Rép. : Re: [Xenomai-core] rtdm, rtc and printk driver.

[Jeff Webb]

Jan Kiszka wrote:

> The long-term question for me is if there is a need to synchronise the
> system clock (or some skin timebase in future Xenomai versions) on an
> external sources like the RTC here. Not that I'm desperately locking for
> work, it's just good to know user requirements whenever further design
> decisions [on the time subsystem] have to be made.

Our real-time simulation requires synchronization with an external time base.  The external timing source generates a one-pulse-per-second signal that is connected to an interrupt line on the real-time PC.  We use this  one-PPS interrupt to calibrate the task execution period and remove any accumulated clock skew to keep our simulation outputs in-sync with other parts of the simulation.

I am satisfied with the current implementation, but thought I would respond, since you were asking for input.  I hadn't thought about the possibility of some sort of built-in timebase synchronization functionality, but I imagine this sort of thing is fairly common, and it may prove useful to include it in Xenomai.

-Jeff