public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: David Fernandez <dfernandez@cct.co.uk>
To: Gary Thomas <gary@mlbassoc.com>
Cc: birahim.fall@elsys-design.com, ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Re: RE : [ECOS] Understanding CYGNUM_HAL_RTC_PERIOD 	NUMERATOR DENOMINATOR
Date: Thu, 22 Jun 2006 13:43:00 -0000	[thread overview]
Message-ID: <1150983812.29450.27.camel@software.cct.co.uk> (raw)
In-Reply-To: <449A9855.3060009@mlbassoc.com>

On Thu, 2006-06-22 at 07:17 -0600, Gary Thomas wrote:
> David Fernandez wrote:
> > On Thu, 2006-06-22 at 13:56 +0100, David Fernandez wrote:
> >   
> >> On Wed, 2006-06-21 at 09:19 +0200, FALL wrote:
> >>     
> >>> Good Day, I have successfully compiled and ran ecos on an oki platform.
> >>> I am however not understanding how to setup the NUMERATOR DENOMINATOR
> >>> RTC_PERIOD per my platform specs. I have read the documentation but I am
> >>> still not clear on what values I should use.  Specifically, my processor
> >>> is runningat 33Mhz, when the hal_clock_initialize is called, what is the
> >>> relationship between that and the above mentioned values.
> >>>
> >>> Moussa
> >>> hi Moussa try this config:
> >>> cdl_component CYGNUM_HAL_CPUCLOCK {
> >>>         display       "cpu clock"
> >>>       
> >>           display       "cpu clock (Mhz.)"
> >>     
> >>>         flavor        data
> >>>         calculated 33000000
> >>> 	no_define
> >>> 	define -file system.h CYGNUM_HAL_CPUCLOCK
> >>>         description   "Frequency of cpu clock in Hz."
> >>>     }
> >>> ....
> >>> # Real-time clock/counter specifics
> >>>     cdl_component CYGNUM_HAL_RTC_CONSTANTS {
> >>>         display       "Real-time clock constants"
> >>>         flavor        none
> >>>
> >>>         cdl_option CYGNUM_HAL_RTC_NUMERATOR {
> >>>             display       "Real-time clock numerator"
> >>>       
> >>               display       "Real-time clock numerator (nanoseconds per second)"
> >>     
> >>>             flavor        data
> >>>             default_value 1000000000
> >>>         }
> >>>         cdl_option CYGNUM_HAL_RTC_DENOMINATOR {
> >>>             display       "Real-time clock denominator"
> >>>       
> >>               display       "Real-time clock denominator (wraps per second)"
> >>     
> >>>             flavor        data
> >>>             default_value 100
> >>>         }
> >>>         cdl_option CYGNUM_HAL_RTC_PERIOD {
> >>>             display       "Real-time clock period"
> >>>       
> >>               display       "Real-time clock period (ticks per wrap)"
> >>     
> >>>             flavor        data
> >>>             default_value (CYGNUM_HAL_CPUCLOCK/CYGNUM_HAL_RTC_DENOMINATOR) -1
> >>>         }
> >>>     }
> >>>       
> >> The way I see that in my intel platform is as modified above.
> >>
> >> The DENOMINATOR allows you to calculate ticks and specifies the OS timer
> >> "tick" (usually 10 milliseconds)
> >>
> >> The NUMERATOR allows you to convert periods into frequencies and
> >> viceversa (periods in nanoseconds to/from frequencies in Mhz.)
> >>
> >> The only reason you want to change DENOMINATOR is to get a different
> >> time granularity in the OS.
> >>
> >> The only reason you want to change the NUMERATOR is if you need to use
> >> different units of periods or frequencies becuase may be that the
> >> calculi you need to do exceeds the numerical capacity of your scalar
> >> types.
> >>
> >> David.
> >>     
> >
> > WARNING: The NUMERATOR value is used when programing some hardware
> > timer... but hardware could impose limitations on this value that should
> > be noted in the cdl legal_values..., lets say for example, that if your
> > CPU/Timer frequency is very high, and your hardware timer counter
> > register is small (16 bit for example), you can't get good values for
> > small PERIODs, because won't fit in 0-65535 range.
> >
> >
> >   
> This isn't strictly correct.
> 
> CYGNUM_HAL_RTC_NUMERATOR describes the granularity of the timer values.  
> The default specifies nano-seconds.
OK, you mean the granularity or precision for hardware tick times,
right?
I agree with that definition, just seem good to me to give the practical
usage for that granularity description.
> 
> CYGNUM_HAL_RTC_DENOMINATOR is how many times the system clock interrupts 
> per second.  This is simply
> information to the kernel to know how to interpret time when it gets an 
> RTC interrupt.
I meant that when I said wraps per second... may be wrap wasn't the
right word...
> 
> CYGNUM_HAL_RTC_PERIOD is the value which is programmed into your 
> hardware "clock".  It needs to be adjusted
> so that the clock will generate interrupts at 
> CYGNUM_HAL_RTC_DENOMINATOR/second.
Agreed.
> 
> Typically, one only needs to adjust CYGNUM_HAL_RTC_PERIOD based on the 
> hardware.  If you want the system 'tick'
> to be faster than the default 10ms, then adjust 
> CYGNUM_HAL_RTC_DENOMINATOR (and make sure that the value of
> CYGNUM_HAL_RTC_PERIOD tracks)
> 
> 
> 
I meant that too, I just call that the granularity of OS "software"
timer...
And as mentioned in my last email, sometimes the hardware doesn't allow
any PERIOD value...
Don't you think could be good to put a platform specific legal_values
somewhere to avoid wrong combinations of NUMERATOR/DENOMINATOR?

David.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  reply	other threads:[~2006-06-22 13:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-21  7:19 [ECOS] " FALL
2006-06-22 12:56 ` [ECOS] " David Fernandez
2006-06-22 13:05   ` David Fernandez
2006-06-22 13:17     ` Gary Thomas
2006-06-22 13:43       ` David Fernandez [this message]
2006-06-22 14:12         ` Moussa Ba
2006-06-22 14:35           ` David Fernandez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1150983812.29450.27.camel@software.cct.co.uk \
    --to=dfernandez@cct.co.uk \
    --cc=birahim.fall@elsys-design.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=gary@mlbassoc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).