Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Запрет прерываний на длительное время в uClinux
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Программирование
Ivan_Kov
Стоит задача управления устройством в реальном времени. Поскольку ОС uClinux - не реального времени, выход вижу только в том, что бы запрещать прерывания на время работы с устройством. Проблема в том, что время это довольно велико 100-300 мС.
Какие неприятности возникнут всвязи с этим, и как можно с ними бороться?
KirillS
Цитата(Ivan_Kov @ Jul 18 2007, 10:16) *
Стоит задача управления устройством в реальном времени. Поскольку ОС uClinux - не реального времени, выход вижу только в том, что бы запрещать прерывания на время работы с устройством. Проблема в том, что время это довольно велико 100-300 мС.
Какие неприятности возникнут всвязи с этим, и как можно с ними бороться?

1) По прерываниям работают, например, Ethernet и RS-232 драйверы. Если прерывания запрещены - могут пропадать Ethernet пакеты - важно ли это ?
2) Обычно Linux получает timer interrupt раз в 100 мС. Запрещение прерываний может помешать
scheduler"у - если нужно обеспечить, например, 300 мС между запусками thread"a, а прерывания запрещены, то inter activation время будет скакать.
_artem_
А на Ваш проц есть RTAI? Может быть и не надо будет запрешать прерывания .
Ivan_Kov
Проц - lpc2468 (ядро ARM).
то что планировщик будет затыкаться - не страшно.
Проблемы с Ethernet - уже серьезнее, но на сколько я знаю протокол TCP/IP борется с потерей пакетов.
Не может ли начать глючить USB?
Подозреваю, что еще системные часы начнут отставать, но не ясно какие из-за этого могут быть подводные камни?
Николай Z
Цитата(Ivan_Kov @ Jul 30 2007, 16:46) *
Проблемы с Ethernet - уже серьезнее, но на сколько я знаю протокол TCP/IP борется с потерей пакетов.
Не может ли начать глючить USB?
Подозреваю, что еще системные часы начнут отставать, но не ясно какие из-за этого могут быть подводные камни?


USB - при работе с bulk-операциями - глючить при задержках 200-300 мсек не должнен...
Это протокол с гарантированной доставкой, но он будет ждать - при правильной реализации до нескольких секунд - точно не помню...

Естественно потоковые протоколы - типа передачи звука в звуковые колонки - собьются, все начнет хрипеть и хрюкать... В видео через USB - будут какие-нить дерганья и замирания или разрушение картинки - не знаю...

HID-интерфейс мне не знаком...
vshemm
Попробуйте использовать для своей задачи RT приоритет (от 1 до 99) и соответствующую политику шедулинга (RR или FIFO). Тогда Вашу нить никто не сможет вытеснить, кроме обработчиков прерываний и softirq - tasklets. Сами обработчики довольно "легковесные" и задержки, создаваемые ими, проблемы представлять не должны (тут, конечно, все зависит от железа и временных требований при работе с устройством). А вот тасклеты и softirq могут быть "тяжелыми", например, бОльшая часть работы сетевой подсистемы делается именно там. Поэтому их скорее всего придется запрещать на время работы с устройством. Или работать с устройством в своем тасклете smile.gif Так или иначе, этот вариант лучше, чем запрещение прерываний.
KirillS
Цитата(vshemm @ Oct 20 2007, 16:10) *
Попробуйте использовать для своей задачи RT приоритет (от 1 до 99) и соответствующую политику шедулинга (RR или FIFO). Тогда Вашу нить никто не сможет вытеснить, кроме обработчиков прерываний и softirq - tasklets. Сами обработчики довольно "легковесные" и задержки, создаваемые ими, проблемы представлять не должны (тут, конечно, все зависит от железа и временных требований при работе с устройством). А вот тасклеты и softirq могут быть "тяжелыми", например, бОльшая часть работы сетевой подсистемы делается именно там. Поэтому их скорее всего придется запрещать на время работы с устройством. Или работать с устройством в своем тасклете smile.gif Так или иначе, этот вариант лучше, чем запрещение прерываний.

RT-приоритеты вещь хорошая, только вот uClinux зачастую построен вокруг кернел 2.4.х, где они не поддерживаются...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.