Re: timer functions for non-kernel

[Jani Monoses <jani at iv dot ro>]

>     Jani> these functions just like the others in drv_api are part of
>     Jani> an optional API. cyg_drv_interrupt , cond_vars , mutexes etc
>     Jani> imply interrupts don't they? what are the disadvantages of
>     Jani> adding these functions? Redboot does not use them so it
>     Jani> cannot be affected.
>
> It is not RedBoot itself, it is device drivers (especially ethernet
> drivers) that may be used by either RedBoot or by an eCos application
> - hence the term driver API. The various functions in the current
> driver API will do the right thing irrespective of whether the system
> is running with interrupts enabled or disabled. Your proposed timer

those that deal with interrupts are surely not meant for working with ints disabled?
The eth drivers do not use those functions in redboot, but other code could.
We use AT91 serial in interrupt mode with redboot to be able to dowload at 115200 bps
with no problems.
Also redboot syscall.c uses interrupts - the same kind of timer interrupt I used to 
support GNUPro BSPs.

> functions will only work correctly if the system is running with
> interrupts enabled, otherwise your cyg_current_time() would return
> misleading data and your cyg_thread_delay() will block forever. The
> distinction seems pretty clear to me.

Does using polling on some devices, imply that interrupts must be disabled-system wide?
Can't redboot use eth drivers in polled mode while a timer interrupt ticks?

From what I see the kernel API vs. drv API distinction is this: use threads or don't.
Kernel requires at least the timer interrupt for scheduling the threads, but drv_api does 
not imply lack of interrupts, just lack of threads.


Jani