Re: proposal for a HAL specification change

[Nick Garnett <nickg at ecoscentric dot com>]

Bart Veer <bartv@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.
> 
> As a specification change it risks "breaking" existing ports. The
> synthetic target, sparc, sparclite, and v850 HALs do not define
> HAL_DELAY_US() at all. I am happy to provide an implementation for the
> synthetic target, but cannot really tackle the others. For other
> architectures HAL_DELAY_US() might not be available on all platforms,
> or when it is available it might not meet the new specification e.g.
> thread-safety.
> 
> However changing a specification does not affect existing code, so
> cannot break current applications.
> 
> Are there any objections to this change?

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


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts