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