Re: proposal for a HAL specification change

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Nick" == Nick Garnett <nickg@ecoscentric.com> writes:

    >> Following recent discussions on ecos-discuss I propose a change
    >> to the specification of HAL_DELAY_US(), as per the patch below.
    >> This macro is used in various places in the system including
    >> bit-banged I2C and the quicc2 and lan91 ethernet drivers, yet
    >> currently it is defined as optional and issues such as
    >> thread-safety are not addressed.

    <snip>

    Nick> My only caveat is that application and driver code which
    Nick> expects to be called when interrupts are enabled should
    Nick> really be using CYGACC_CALL_IF_DELAY_US(), which is thread
    Nick> and interrupt safe and defaults to HAL_DELAY_US() in the
    Nick> absence of the kernel.

Since there wre no other objections I have now committed the change.

I am not convinced that CYGACC_CALL_IF_DELAY_US() is an acceptable
alternative. It will only be available on targets that support virtual
vectors. That rules out the synthetic target, and probably very small
systems which are debugged via jtag or bdm rather than via gdb stubs.

In fact, if HAL_DELAY_US() does the right thing then I see no real
need for CYGACC_CALL_IF_DELAY_US() at all. It just adds code size
overhead, especially since by default the application will override
the RedBoot version. I suppose there is a scenario where
HAL_DELAY_US() is implemented by monitoring a running clock rather
than a busy loop, and the clock runs at different frequencies in
RedBoot and the application. However I would expect such scenarios to
be uncommon and they could be handled by other means.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts