Частота прерываний под Linux'ом, реально достижимая Опции

[Alexashka]

Господа-товарищи программисты, если у кого опыт, поделитесь пожалуйста с какой максимальной частотой реально можно обрабатывать прерывания под Линухом? Скажем частота 100кГц. Это много? Процессор AT91SAM9G45, тактовая 400МГц, память DDR2 (платка SK-AT91SAM9G45SK-AT91SAM9G45 от Starterkita)

[Lyubimov]

Зависит от времени переключения контекста. Можете попробовать замерить его обрабатывая прерывания от аппаратного таймера. Чем меньше время переключения, тем более частые прерывания можно обрабатывать. Но система будет скорее всего виснуть.
100 КГц это примерно каждые 10 мкс, а ваш процессор выполняет максимум 400 инструкций за 1 мкс, тоесть у вас между прерываниями будет выполнено максимум 4000 инструкций.
А вообще Линукс как-то не очень предназначен для работы в жёстком реальном времени с чётко определённым временем реакции. Для этой задачи лучше использовать отдельный процессор или ПЛИС.

Сообщение отредактировал Lyubimov - Jul 31 2012, 12:57

[Alexashka]

А вообще Линукс как-то не очень предназначен для работы в жёстком реальном времени с чётко определённым временем реакции.

Вообщем, да Я то думал, там карусель для простых задач, а прерывания выполняются с минимальными задержками, но выходит не совсем так. Макс.частота с которой удалось отрабатывать прерывания в Linux - 16кГц, без оного - 820кГц. Фигня какаято

[rudy_b]

...Фигня какаято

Ага, именно оно. Я неоднократно хотел попробовать все эти широкорекламируемые ARMы, и каждый раз убеждался, что с точки зрения real-time обработки это полное г... Кроме красивых слов ничего не могет. Нормально может работать только с потоками, если кто-то удосужился их сформировать, сбуферировать и т.д.

На мой взгляд, из современных процов, кроме редковстречающейся экзотики, единственная приличная вещь это атмелошная AVR32 - у нее 4 переключаемых регистровых банка что позволяет перейти к обработке прерывания за 1 такт. Но ее errata сильно впечатляет, да и дороговато... Были и до нее процы с несколькими регистровыми банками, но сейчас что-то их не наблюдаю, но может плохо искал...

Если стоит операционка - то, практически, реал тайму финиш, даже если про нее прописано, что она реалтайм. Пока она разберется что, куда, откуда - все уже успеют умереть. Т.е. реалтаймовский кусок можно писать только на уровне драйвера, да и то помрешь.

А дальше идет язык программирования. Если пишется на С - то переход в прерывание - порядка 10-20 команд. Основное - запихнуть используемые этим куском регистры в стек. Правда, по крайней мере в IARe, это неплохо оптимизировано, особо лишнего не делает, но на asm-e, особенно в критических местах, можно довольно сильно сэкономить. Проблема с asm-oвскими вставками - адреса переменных туда плохо впихиваются, приходится извращаться, а писать все на asm-е - лениво. Кстати. может кто подскажет как это можно удобно делать? Но именно для int-ов, со стандартными функциями понятно.

В общем, мне кажется, что преход на 32 битовые ARMы - это не то, что нужно для простых вещей. Реалтайм процессы должны обрабатывать хардовые куски. Это, собственно, частично сделано, встроенные интерфейсы типа USART, SPI, 2-wire, USB, всякие карты памяти, флешки и т.п. имеют встроенные хардовые части, правда часто криво реализованные. Но вот как только нужно что-то нестандартное... Часто проще поставить отдельный мелкий проц, чтобы обработать и преобразовать в стандартный поток. Ну или использовать встроенные FPGA, такое тоже бывает, но это уже спецуха немерянной кривизны.

На самом деле, хочется 16 -битовый проц (что-то типа AtMega, но 16 бит). Единственное, что сильно
мешает в Меге (кроме малой разрядности, которая, кстати, мешает не слишком сильно, и слабоватой косвенной адресации) - это отсутствие FIFO (на 4-16 слов) на стандартных интерфейсах, ну и некоторая кривизна аппаратной реализации TWI.

Это, ессно, не более чем ИМХО. Посему просьба - не бить ногами не подумавши, желательно делать это более конструктивно.

[Ruslan1]

Ага, именно оно. Я неоднократно хотел попробовать все эти широкорекламируемые ARMы, и каждый раз убеждался, что с точки зрения real-time обработки это полное г... Кроме красивых слов ничего не могет. Нормально может работать только с потоками, если кто-то удосужился их сформировать, сбуферировать и т.д.
.....
Если стоит операционка - то, практически, реал тайму финиш, даже если про нее прописано, что она реалтайм. Пока она разберется что, куда, откуда - все уже успеют умереть. Т.е. реалтаймовский кусок можно писать только на уровне драйвера, да и то помрешь.

Укажите, пожалуйста, на каком арме и какой RTOS Вы все это проверяли?