LINUX.ORG.RU

Выбор метода решения реалтаймовой задачи.

 , ,


1

2

Hello, World.

Возникла задача оперативного чтения из com порта. Речь идёт о предсказуемом интервали чтения из serial port. где-то за 1-2 миллисекунды.

На винде получал переодические скачки скорости. На убунте всё запустилось стабильно. Скачки в 1 миллисекунды, что, я таки понимаю, соответствует тику системы. Думаю, мне нужно еще поднять частоту системного тика. Или вообще перехватить прерывания от com порта и как-то с ними поработать.

Я правильно понимаю, что, чтобы поднять частоту надо пересобирать ядро? Увы, я это не умею, и это неподъёмно, учитывая, что работать все должно было вчера.

Может есть уже разогнанные сборки? Или вообще, линух более подходящий под реалтайм.

И, в какую сторону посмотреть относительно перехвата прерываний?


Ответ на: комментарий от Mirmik

Видимо Linux kernel compiled with the realtime preemption patch - для Федоры - смотри http://ccrma.stanford.edu/planetccrma/software/ Это аудиофилы улучшают ядро.

для перехвата прерываний - это свой ядреный драйвер писать надо - читай Linux Device drivers http://lwn.net/Kernel/LDD3/.

sigurd ★★★★★
()
Последнее исправление: sigurd (всего исправлений: 3)

Скорость com порта 115200 бод. Его обслуживание в реальном времени сможет производить даже 10 МГц процессор.

rezedent12 ☆☆☆
()
Ответ на: комментарий от rezedent12

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

Драйвер писать - да. Я хотел узнать более детально. Подмена прерываний, обращение к регистрам процессора. Такие вещи. Или может-быть так глубоко не нужно?

Mirmik
() автор топика
Ответ на: комментарий от Mirmik

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

нет. Время обработки системного вызова зависит от того, что он делает.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от Mirmik

«уже разогнанные сборки» или «вообще, линух более подходящий под реалтайм».

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Так что конкретно мне взять и чем объясняется то, что прыжки по скорости приёма составляют ровно миллисекунду.

Mirmik
() автор топика
Ответ на: комментарий от Mirmik

ну что ты! возьми уже поставь этот пакет, перезагрузись в rt-ядро, запусти процесс, выставь приоритеты и scheduler при помощи chrt/schedtool и отпишись, как поведут себя величина и разброс твоих задержек. частота таймера там либо задрана, либо искоренена.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от Mirmik

Для некоторых задач можно порекомендовать другой метод. Если тебе нужна не реакция в реальном времени на события порта, а точное время прихода сигналов, то лучше использовать аппаратное решение. А именно взять небольшой чип с com-портом и соединяющийся с компьютером другим более скоростным портом. И передавать в компьютер не биты сами по себе, а время их принятия. Считать время можно дополнительной микросхемой точного времени, либо откалибровать считывающий цикл на постоянную продолжительность любой итерации.

цикл
начало
 счётчик = счётчик +1
 проверить готовность считывания
  если готовность есть
   сигнал = считать бит()
   передать счётчик и передать бит
  если готовности нет
   пауза на время типичного считывания и передачи
конец
rezedent12 ☆☆☆
()
Последнее исправление: rezedent12 (всего исправлений: 1)
Ответ на: комментарий от t184256

man реальное время. не так страшен процессор, как то, что на нем исполняется.

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

rezedent12 ☆☆☆
()
Ответ на: комментарий от rezedent12

rezedent12 нет. Мне нужна реакция на сигнал. Время я промеряю, чтобы убедиться в коректной скорости реакции. Но, возможно, с реакцией всё впорядке, а измерение времени мало точное.

Mirmik
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.