[ECOS] HAL_DELAY_US() default implementation

[ECOS] HAL_DELAY_US() default implementation

[Øyvind Harboe]

Ref

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

Looks good.

Thoughts on a default implementation:

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


Some code:

/* this fn takes at least 0.000001342194658704 seconds 
 * to execute one iteration (EB40a running out of flash).
 * 
 * A number of factors affect this number:
 * 
 * - Is the code in ram/rom, wait states
 * - Iterrupts/task switches can slow it down
 */
 

static void busy(int j)
{
	__asm volatile (
	
	".L1: nop\n" 
	"sub %0,%0,#1\n" 
	"cmp %0,#0\n"
	"bne .L1\n"
	
	: "+r" (j));
}

/* times the busy() function */
void timeIt() 
{
	for (int j=1000; j<10000000; j=((j*110)/100))
	{
		// time it.
		cyg_tick_count_t lastTime=cyg_current_time();
		busy(j);
		cyg_tick_count_t current=cyg_current_time();
		diag_printf("%d %d\n", j, (int)(current-lastTime));
	}
}


/* Waits at least this many us.
 * 
 * Does not require kernel to be running.
 */
void waitus(int us)
{
	float oneIteration=0.000001342194658704;
	int iterations;
	iterations=(int)(us*1000000*oneIteration);
	busy(iterations);
}

Example run:

loops   ticks   time/seconds
1395411	187	0,000001340106964901
1534952	206	0,000001342061510718
1688447	227	0,000001344430710588
1857291	249	0,000001340662287170
2043020	274	0,000001341151824260
2247322	301	0,000001339371928010
2472054	331	0,000001338967514464
2719259	365	0,000001342277436610
2991184	401	0,000001340606261601
3290302	441	0,000001340302501108
3619332	486	0,000001342789221879
3981265	535	0,000001343793995125
4379391	588	0,000001342652437291
4817330	647	0,000001343067632900
5299063	711	0,000001341746644643
5828969	782	0,000001341575156773
6411865	861	0,000001342823031988
7053051	947	0,000001342681344570
7758356	1042	0,000001343068041735
8534191	1145	0,000001341662027485
9387610	1260	0,000001342194658704


-- 
Øyvind Harboe
http://www.zylin.com


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

Re: [ECOS] HAL_DELAY_US() default implementation

[Bart Veer]

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

Re: [ECOS] HAL_DELAY_US() default implementation

[Øyvind Harboe]

Getting rid of calibration is not easy.

Take the AT91 HAL variants specifically. There are 5'ish different
sub-hals * 3 types of memory(flash + internal/external RAM). Thats
15'ish combinations.

How about this approach?

- No automatic calibration
- Add a machine code busy loop/CPU type. Machine code is
  used to make the busy loop independent of compiler optimisations
- Some(many?) HAL's have a HAL_DELAY_US() that works out
  of the box according to the newest HAL_DELAY_US() specification and 
  hence won't need any calibration.
- If the user provides a CDL parameter which calibrates the busy loop
  he gets HAL_DELAY_US(), otherwise he doesn't. It is better with a
  compile time error than a broken HAL_DELAY_US().
- If a HAL knows that it can accuratly estimate this parameter in all
  cases, it can provide a default value and HAL_DELAY_US() works out of
  the box.


-- 
Øyvind Harboe
http://www.zylin.com


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