реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> Запрет прерываний на длительное время в uClinux, какие последствия?
Ivan_Kov
сообщение Jul 18 2007, 08:16
Сообщение #1


Частый гость
**

Группа: Свой
Сообщений: 174
Регистрация: 30-10-06
Из: г. Курск
Пользователь №: 21 787



Стоит задача управления устройством в реальном времени. Поскольку ОС uClinux - не реального времени, выход вижу только в том, что бы запрещать прерывания на время работы с устройством. Проблема в том, что время это довольно велико 100-300 мС.
Какие неприятности возникнут всвязи с этим, и как можно с ними бороться?
Go to the top of the page
 
+Quote Post
KirillS
сообщение Jul 27 2007, 13:10
Сообщение #2


Участник
*

Группа: Новичок
Сообщений: 44
Регистрация: 10-10-06
Пользователь №: 21 161



Цитата(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 время будет скакать.


--------------------
Some days you eat the bear. Some days the bear eats you.
Go to the top of the page
 
+Quote Post
_artem_
сообщение Jul 28 2007, 20:30
Сообщение #3


учащийся
*****

Группа: Свой
Сообщений: 1 065
Регистрация: 29-10-05
Из: города контрастов
Пользователь №: 10 249



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


--------------------
Зачем лаять на караван , когда на него можно плюнуть?

Go to the top of the page
 
+Quote Post
Ivan_Kov
сообщение Jul 30 2007, 12:46
Сообщение #4


Частый гость
**

Группа: Свой
Сообщений: 174
Регистрация: 30-10-06
Из: г. Курск
Пользователь №: 21 787



Проц - lpc2468 (ядро ARM).
то что планировщик будет затыкаться - не страшно.
Проблемы с Ethernet - уже серьезнее, но на сколько я знаю протокол TCP/IP борется с потерей пакетов.
Не может ли начать глючить USB?
Подозреваю, что еще системные часы начнут отставать, но не ясно какие из-за этого могут быть подводные камни?
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Oct 19 2007, 13:07
Сообщение #5


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(Ivan_Kov @ Jul 30 2007, 16:46) *
Проблемы с Ethernet - уже серьезнее, но на сколько я знаю протокол TCP/IP борется с потерей пакетов.
Не может ли начать глючить USB?
Подозреваю, что еще системные часы начнут отставать, но не ясно какие из-за этого могут быть подводные камни?


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

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

HID-интерфейс мне не знаком...
Go to the top of the page
 
+Quote Post
vshemm
сообщение Oct 20 2007, 14:10
Сообщение #6


Частый гость
**

Группа: Участник
Сообщений: 167
Регистрация: 15-08-07
Пользователь №: 29 803



Попробуйте использовать для своей задачи RT приоритет (от 1 до 99) и соответствующую политику шедулинга (RR или FIFO). Тогда Вашу нить никто не сможет вытеснить, кроме обработчиков прерываний и softirq - tasklets. Сами обработчики довольно "легковесные" и задержки, создаваемые ими, проблемы представлять не должны (тут, конечно, все зависит от железа и временных требований при работе с устройством). А вот тасклеты и softirq могут быть "тяжелыми", например, бОльшая часть работы сетевой подсистемы делается именно там. Поэтому их скорее всего придется запрещать на время работы с устройством. Или работать с устройством в своем тасклете smile.gif Так или иначе, этот вариант лучше, чем запрещение прерываний.
Go to the top of the page
 
+Quote Post
KirillS
сообщение Nov 1 2007, 16:59
Сообщение #7


Участник
*

Группа: Новичок
Сообщений: 44
Регистрация: 10-10-06
Пользователь №: 21 161



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

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


--------------------
Some days you eat the bear. Some days the bear eats you.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 18th July 2025 - 01:36
Рейтинг@Mail.ru


Страница сгенерированна за 0.01365 секунд с 7
ELECTRONIX ©2004-2016