[kovalchuk_i_v 0]

Стоит задача управления устройством в реальном времени. Поскольку ОС uClinux - не реального времени, выход вижу только в том, что бы запрещать прерывания на время работы с устройством. Проблема в том, что время это довольно велико 100-300 мС.

Какие неприятности возникнут всвязи с этим, и как можно с ними бороться?

[akivas 0]

Стоит задача управления устройством в реальном времени. Поскольку ОС uClinux - не реального времени, выход вижу только в том, что бы запрещать прерывания на время работы с устройством. Проблема в том, что время это довольно велико 100-300 мС.

Какие неприятности возникнут всвязи с этим, и как можно с ними бороться?

1) По прерываниям работают, например, Ethernet и RS-232 драйверы. Если прерывания запрещены - могут пропадать Ethernet пакеты - важно ли это ?

2) Обычно Linux получает timer interrupt раз в 100 мС. Запрещение прерываний может помешать

scheduler"у - если нужно обеспечить, например, 300 мС между запусками thread"a, а прерывания запрещены, то inter activation время будет скакать.

[_artem_ 0]

А на Ваш проц есть RTAI? Может быть и не надо будет запрешать прерывания .

[kovalchuk_i_v 0]

Проц - lpc2468 (ядро ARM).

то что планировщик будет затыкаться - не страшно.

Проблемы с Ethernet - уже серьезнее, но на сколько я знаю протокол TCP/IP борется с потерей пакетов.

Не может ли начать глючить USB?

Подозреваю, что еще системные часы начнут отставать, но не ясно какие из-за этого могут быть подводные камни?

[NikolayZ 0]

Проблемы с Ethernet - уже серьезнее, но на сколько я знаю протокол TCP/IP борется с потерей пакетов.

Не может ли начать глючить USB?

Подозреваю, что еще системные часы начнут отставать, но не ясно какие из-за этого могут быть подводные камни?

 

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

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

 

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

 

HID-интерфейс мне не знаком...

[vshemm 0]

Попробуйте использовать для своей задачи RT приоритет (от 1 до 99) и соответствующую политику шедулинга (RR или FIFO). Тогда Вашу нить никто не сможет вытеснить, кроме обработчиков прерываний и softirq - tasklets. Сами обработчики довольно "легковесные" и задержки, создаваемые ими, проблемы представлять не должны (тут, конечно, все зависит от железа и временных требований при работе с устройством). А вот тасклеты и softirq могут быть "тяжелыми", например, бОльшая часть работы сетевой подсистемы делается именно там. Поэтому их скорее всего придется запрещать на время работы с устройством. Или работать с устройством в своем тасклете :) Так или иначе, этот вариант лучше, чем запрещение прерываний.

[akivas 0]

Попробуйте использовать для своей задачи RT приоритет (от 1 до 99) и соответствующую политику шедулинга (RR или FIFO). Тогда Вашу нить никто не сможет вытеснить, кроме обработчиков прерываний и softirq - tasklets. Сами обработчики довольно "легковесные" и задержки, создаваемые ими, проблемы представлять не должны (тут, конечно, все зависит от железа и временных требований при работе с устройством). А вот тасклеты и softirq могут быть "тяжелыми", например, бОльшая часть работы сетевой подсистемы делается именно там. Поэтому их скорее всего придется запрещать на время работы с устройством. Или работать с устройством в своем тасклете :) Так или иначе, этот вариант лучше, чем запрещение прерываний.

RT-приоритеты вещь хорошая, только вот uClinux зачастую построен вокруг кернел 2.4.х, где они не поддерживаются...