This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: HAL_DELAY_US()
Øyvind Harboe wrote:
On 8/14/06, Gary Thomas <gary@mlbassoc.com> wrote:
Øyvind Harboe wrote:
> 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.
IMO, HAL_DELAY_US() should not be used if interrupts or thread switches
can cause a perturbation. It's *only* function is to provide very simple
timing when devices require it. It should not be used for arbitrary
delays,
certainly not in user/application code. For that, use
'cyg_thread_delay()'
Agreed.
However, e.g. i2c bitbang relies on it and I do believe that a
consensus was reached to make it compulsory.
IMO, a HAL should have no implementation or a correct implementation.
EB40a has a broken implementation and that implementation should be
deleted or replaced.
There is no way to do reliable sub-tick timing if interrupts are
enabled. If you need such things, then you need to have the interrupts
off and if the I2C routines work this way (I've not followed that development
closely), then I think *they* should be rethought.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss