Incorrect PIT value inititalization

[Leon Pollak]

Tom,

It seems to me like a good solution, although parameterizing the function in
such a manner using the rtems_cpu_configuration_get_clicks_per_usec()
function means in fact setting the underlying Cpu_table.clicks_per_usec
member, and this means that wherever this member is used it will be used
incorrectly in the first (=0) and third (<0) cases (below). Personally I
found it being used in the macro rtems_bsp_delay, which in turn is used
in several locations throughout the code, I might however be wrong,
since it is very difficult for me to trace which files are used where.

Thanks.
Leon

On Wed, 2004-10-20 at 10:54, Thomas Doerfler wrote:
> Hello leon,
> 
> I have hit this issue during my RTEMS class preparations. I have
> two different types ob MBX boards here, some of them use a
> 4(!)MHz external crystal, some use a 32768Hz crystal. Some are
> equipped with a 40MHz system clock oscillator, some with a
> 50MHz.
> 
> My first attempt also was, that the PIT will be fed from the
> system clock input (the actual input frequency computed out of
> the CPU clock definition and the PLL settings). But
> unfortunately, on some boards the PIT simply does not count when
> fed by such ahigh frequency. I think this was a known bug on
> these chips.
> 
> So now I have a solution which can be parametrized rather
> flexible.
> 
> If rtems_cpu_configuration_get_clicks_per_usec is 0, the PIT is
> clocked with the EXTCLK signal (the freqeuncy of which is
> determined by CPU clock definitions and PLL settings).
> 
> If rtems_cpu_configuration_get_clicks_per_usec is >0, the PIT is
> clocked with the OSCCLK signal (as it was in the current code).
> 
> If rtems_cpu_configuration_get_clicks_per_usec is <0, the PIT is
> clocked with the OSCCLK signal, assuming an external 32768Hz
> clock. This third solution was needed, because the traditional
> RTEMS timer clock definition "clocks_per_usec" is not suitable
> to specify such a low frequency.
> 
> I am still not quite happy with this, because at least some of
> the solutions will provide a somewhat strange timer tick.
> Therefore I have not yet submitted the code.
> 
> Any comments?
> 
> wkr,
> Thomas.
> 
> 
> 
> 
> either uses the crystal attached to the OSCCLK, or
> 
> > Hello, all.
> >         We have some problem with the PIT initialization code for MPC860.
> > As it
> > resides in the common directory, we think that it is worth asking the
> > question here.
> >         Our board has the 5MHz XTAL clock. The file
> > /opt/rtems/rtems-src/c/src/lib/libcpu/powerpc/mpc8xx/clock/clock.c:72
> >
> > in function ClockOn the code that initializes the PIT value (see below)
> > seems to be incorrect in case of a slower XTAL (not 50MHz as mbx860 has),
> > yielding float values for clicks_per_usec.
> > For example a 5MHz XTAL divided by 4 produces a 1.25MHz frequency, which
> > means that clicks_per_usec = 1.25. When it is assigned to an unsigned32
> > member it is truncated to 1, and the resulting value is only a rough
> > estimate of the value actually desired.
> >
> > Original code:
> > pit_value = (rtems_configuration_get_microseconds_per_tick() *
> >                rtems_cpu_configuration_get_clicks_per_usec()) - 1 ;
> >
> > We suggest the following modification:
> >
> > /* PIRTCLCK is XTAL / 4. XTAL is computed from the clock speed and
> > PLPRCR. */
> > unsigned long pitrtclk = (Cpu_table.clock_speed / ((m8xx.plprcr >> 20) +
> > 1)) >> 2;
> > pit_value = pitrtclk / 1000 *
> > rtems_configuration_get_milliseconds_per_tick() - 1;
> >
> >
> > Do MPC8xx gurus agree?
> >
> > Thanks
> > Leon Pollak
> 
> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available at: http://www.imd-
> systems.de/pgp_keys.htm