This is the mail archive of the
mailing list for the eCos project.
Re: timer functions for non-kernel
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.