Clock freq Sparc

[Joel Sherrill]

Aaron J. Grier wrote:
> On Thu, May 15, 2008 at 02:54:07PM +0100, Neil Mayes wrote:
>   
>> I have got a board with a clock frequency of 7.372800 MHz, which means
>> the way the ERC32 BSP handles the clock and timer will introduce
>> errors.  I am suspecting most people pick whole MHz for their boards?
>>
>> Has anybody used something more general for the scalar/counter when
>> the frequency is not a complete MHz?
>>
>> Should I accept the loss in granularity, any thoughts really? I am not
>> fussed about long term drift since it is correct frequently via GPS.
>>     
>
> we have a 68k system running at 24.117MHz (23MiHz) PLLd up from a 32kHz
> crystal.  I was concerned about system time drift since the tick lengths
> were odd, and made some modifications to RTEMS' time of day routines to
> keep a microsecond overflow counter, and use that to adjust the clock
> watchdog timer.  this doesn't affect the tick length or the scheduling
> quantum -- only the system time-of-date and associated calls such as
> rtems_task_wake_when().
>
> I've attached my original patch for 4.5.0.  I have applied it to our
> local 4.6.6 branch, but it has not gone through any sort of testing
> there, and doesn't appear to have been integrated back into the master
> OAR repository.  (it would need to be updated for the conversion to
> timespec.)
>
>   
One of my long term projects which could become short
term if someone decided to fund me to do it ... <hint>

Currently the SuperCore has delta chains sorted by
ticks and seconds.  I would like to change this to two
chains sorted by "timestamps".  The timestamps would
either be based upon "absolute/monotonic" time or
walltime. 

This would let us transition from a fixed clock tick to
the possibility of a variable one.  You could call
clock_tick() with the number of nanoseconds since
the last tick and let it update accordingly.

In theory, you could avoid a repeating clock tick and
reprogram it to be variable based upon the next
time event to occur.

Aaron.. in your case, you would either periodically
call a "variable clock tick" with the fudge or call it
every tick with the real time basis.

One potential downside in your case is that if your
tick were 9.8 milliseconds and someone slept for 10
milliseconds, they would probably sleep for two ticks.

But a variable clock tick seems like a nice feature
for the future.
> --
>   Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron at frye.com
>   


-- 
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