Всем большой привет!

Собственно, сабж + его описание.

А если данной возможности не существует, какую ось взять?

Поясню. Заказчик хочет получить возможность пользоваться 4мя таймерами и отсчитывать интервалы от 1мС до сотен секунд. Насчёт таймеров Заказчик не конкретизирует, аппаратные они будут или программные.

Конфигурация системы: Cirrus Logic EP9315 (ARM920T, 200 МГц), 64Мб ОЗУ, 8 Мб flash. В процессоре есть 4 аппаратных таймера, один из которых, соответственно, используется как системный.

Попробовали реализовать через userspace с использованием select, не получилось выдержать даже 10 мС.
Подскажите пожалуйста , в какую сторону копать.

Заранее спасибо!

P.S. Сильно ногами не пинайте, с Linux начал разбираться недавно.

обычно есть два варианта:

soft realtime: preempt-rt kernel + POSIX sched priorities или hrtimers (avaliable only for 2.6.x kernels)
hard realtime: xenomai (based on adeos infrastructure)

Плотно работаю с последним вариантом, как наиболее предсказуемым и продуманным (в плане API) по сравнению с остальными существующими в природе RT фреймворками. Также приятно что оно есть под x86 и прочие архитектуры (ia64/x86_64/arm/powerpc/blackfin/arm/mips/sh-4), что позволяет потренироваться на кошках пока делают очередную железяку.

Ух ты! Уже надежду потерял, что кто-нибудь ответит, а тут... да ещё сам Harbour!
Как раз по первому пути решил сам пойти. В пятницу бодал Busybox 1.8.2 с nice на борту.
Попробовал запустить перебрасывание ноги на rt-kernel 2.6.23.9 - получилось около 700 нан за период, что порадовало, так как мне нужно уложиться в 1 мСек при... хм, вобщем, небольшой загрузке проца. Мацаю EP9315 с 64 Мб ОЗУ на 200МГц.

Хоть возможно и устроит меня первый способ, подскажите пожалуйста литературу по второму способу. Про hard realtime где-то в инете натыкался, но практически не щупал.

Маленькие задержки могут быть из-за недостаточных тестов на загрузку
Хотя на embedded платформах замечены весьма достойные цифры и для soft-rt - в основном из-за простой и предсказуемой архитектуры и связей CPU<->периферия. Но лучше задать борде какой-нить серьезный irq-storm
По второму варианту можно начать с www.xenomai.org , разделы FAQ, HowTo, Examples.

Спасибо.Да, конечно, 700 нан - это вообще без прикладных процессов.Пока пытаюсь хоть как-нибудь.
Попробовал select - он, как оказалось, отсчитывает с периодом 10мС
Посоветуйте плиз, как выдержать милисекунду

Дык, похоже система hires не держит. Проверить систему на наличие подходящих таймеров (предварительно включив в ядре CONFIG_HIGH_RES_TIMERS=y) можно сделав 'cat /proc/timers_list | grep resolution' - должно выдать список таймеров и разрешение для них в 1 nsec. Далее можно проверить разрешение posix подсистемы таймеров, с помощью например такой фигни :
........
#include <unistd.h>
#include <time.h>

int main()
{
struct timespec clock_resolution;
int stat = clock_getres(CLOCK_REALTIME, &clock_resolution);
return printf("Clock resolution is %d seconds, %ld nanoseconds\n",
clock_resolution.tv_sec, clock_resolution.tv_nsec);
}
........
Должна выдать :

Clock resolution is 0 seconds, 1 nanoseconds

См. например http://mia.ece.uic.edu/~papers/WWW/books/posix4/DOCU_007.HTM

P.S. Статус hrtimers для ARM (судя по http://elinux.org/High_Resolution_Timers) неизвестен. Но в любом случае удачно написанный драйвер какой-нибудь подсистемы может свести на нет усилия при soft-rt approach. Adeos этим не страдает