Re: [ECOS] HAL_DELAY_US() default implementation

[Bart Veer <bartv@ecoscentric.com>]

>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind?= Harboe <ISO-8859-1> writes:

    Oyvind> Ref
    Oyvind> http://ecos.sourceware.org/ml/ecos-patches/2005-06/msg00033.html

    Oyvind> Looks good.

    Oyvind> Thoughts on a default implementation:

    Oyvind> - Add calibration by default on startup. There are so many
    Oyvind> things affecting the performance: type of ram/flash,
    Oyvind> caches, off-frequency crystals(e.g. 64MHz instead of 66
    Oyvind> MHz crystal), etc. I'm not entirely convinced that the
    Oyvind> calibration number can be put in the source and committed
    Oyvind> to CVS. E.g. for the AT91 there are 5 HALs X 3 types of
    Oyvind> code memory(internal, external & flash) 15 calibration
    Oyvind> numbers. The number of combinations for all the eCos HAL's
    Oyvind> could easy reach thousands.
    Oyvind> - Calibration can be disabled by specifying the number in
    Oyvind> a CDL option. This number is extracted by running the app
    Oyvind> in the debugger and setting a breakpoint at the end of the
    Oyvind> calibration loop.
    Oyvind> - The calibration algorithm must have some sort of way to
    Oyvind> estimating the accuracy to determine when the calibration
    Oyvind> should terminate. Integer math.

For most platforms I do not think this level of complexity is
necessary. Usually the memory speed will be irrelevant because the
busy loop will run entirely out of icache. Off-frequency crystals are
a possibility, but the difference between 64MHz and 66MHz is just
three percent. For the purposes of HAL_DELAY_US() i.e. interacting
with hardware, as long as the code assumes the faster speed the
difference may not be worth worrying about.

If complicated calibration really is needed then this can be done by
individual HALs. I would much prefer not to see an expensive
calibration loop in any generic code. When porting eCos it is far too
easy to just quickly use some existing suboptimal code instead of
doing the job properly, leading to problems down the road.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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