This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: HAL_DELAY_US() default implementation
- From: Bart Veer <bartv at ecoscentric dot com>
- To: oyvind dot harboe at zylin dot com
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Sun, 26 Jun 2005 15:26:47 +0100 (BST)
- Subject: Re: [ECOS] HAL_DELAY_US() default implementation
- References: <1119425206.20805.21.camel@localhost.localdomain>
>>>>> "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