This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

HAL_DELAY_US()


Going through my changes to eCos, I ran into HAL_DELAY_US().

Does this function belong in the application or eCos?

If it can be implemented in a correct manner that does not require any
configuration, then I believe it belongs in the HAL.

If it needs to be tuned to the hardware in question, then I believe it
belongs in the application space.

The implementation in EB40a is busted because it is not
multithreading/interrupt safe.


Ref. earlier discussions HAL_DELAY_US() should take *at least* that many us, there is no upper limit or requirement on precision as such.

The implementation below could, with a CDL parameter that the user
must configure for his application, work for EB40a & similar HALs.


/* this fn takes at least 0.000001342194658704 seconds * to execute one iteration. * * 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)); }



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




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]