Marc LE DOUARAIN wrote:
> "Nicolas BLANCHARD" <[EMAIL PROTECTED]> 23/02/07 15:55
>
>> Jan Kiszka <[EMAIL PROTECTED]> 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
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
