Возможен ли real realtime в EMC2

[Alligator]

Сразу честно: вопрос для больших специалистов в Linux и EMC2 в частности. Возможно ли аппаратно (обработкой hardware interrupt) тактировать BASE_PERIOD? В документации EMC2 честно указано, что программный способ организации тактов имеет единственное преимущество - он бесплатный. Однако, если проект выходит за рамки LPT-порта, то почти все платы ввода-вывода имеют возможность активировать аппаратные прерывания для тактирования, что было бы намного точнее и надежнее. Неужели это нельзя реализовать в EMC2?

[Nick]

Не совсем понял, Вы хотите тактировать вывод на LPT/другой порт или заменить программный таймер EMC2 на внешний хардварный таймер?

[Alligator]

Заменить программный таймер EMC2 на внешний хардварный таймер

[Nick]

Интересный вопрос...

Решил разобраться в проблеме, но никак не могу найти описания модуля, в котором используется BASE_PERIOD.

Вроде есть stepgen, который генерирует команды для двигателей, но он ли это?

[Alligator]

Нет, это не он. Stepgen - это просто HAL-компонент реального времени (component), такие можно самому достаточно легко писать для добавления в систему новых функций. При первой своей загрузке через loadrt он регистрирует свою функцию .update, которая будет вызываться системой, чтобы этот модуль мог работать. Для периодических вызовов подобных функций существуют Потоки (threads), которых существует два - base и servo, а BASE_PERIOD это просто временная константа, определяющая, как часто будет возбуждаться поток base, который, в свою очередь, будет вызывать функции update присоединенных к нему Компонентов. Фактически, пользователь через BASE_PERIOD задает, как часто он хотел бы запускатьсфункции обновления всех компонентов реального времени, и через latency_test смотрит, насколько он далек от своих желаний Причина в том, что система ПРОГРАММНО рассчитывает временную задержку, тупо организует пустой программный цикл на рассчитанное число повторений и, когда он закончится, активизирует поток и всё по новой. (Так работали первые замедлители компьютеров, когда игрушки от 386 слишком быстро летали на 486 )

[Nick]

Да помню такие замедлители, еще они спасали от Error 200.

Я пошарил по исходникам, нашел там несколько упоминание base_periond и вроде даже цикл видел.
В принципе можно самим попробовать написать поддержку такой технологии.
Только как обычно все упирается в интерфейсы.

[Nick]

Хмммм... насколько я понял, потоками управляет тоже hal.
вот создание потока: hal_create_thread("base-thread", base_period_nsec, 0);

[Alligator]

Оффтоп: причина возникновения вопроса. Система реального времени обязана обеспечить реакцию на внешнее событие за фиксированный промежуток времени. При работе, например, в WindowsCE, перехватываешь аппаратное прерывание нужной частоты и в его обработчике выполняешь все свои задачи реального времени (опрос входов-выходов, критическую математику и так далее). Так устроены все промышленные устройства. А здесь что сделали - исключили любое ВНЕШНЕЕ воздействие, то есть: нет внешнего события, нет и задержки реакции на него Реалтаймнее реалтаймного, ёпт...

[Alligator]

Да помню такие замедлители, еще они спасали от Error 200.

Я пошарил по исходникам, нашел там несколько упоминание base_periond и вроде даже цикл видел.
В принципе можно самим попробовать написать поддержку такой технологии.
Только как обычно все упирается в интерфейсы.

Я уверен, что написать самому можно, но, я, например, Linux на своем компе имею первую неделю в жизни, все силы ушли на то, чтобы обновить свою версию emc2 до последней из исходников и написать и отладить драйвер для своей платы ввода-вывода (производства fastwel). Цель чисто практическая - получить готовую стойку ЧПУ. То есть, если настоящий реалтайм здесь получить невозможно, так пусть и останется, прогресс двигать у меня возможности нет

[Nick]

Если так посмотреть, то в emc реакция должна быть тоже за фиксированное время - base_period.
Вопрос в том, надо ли реагировать быстрее, чем раз в шаг принятия решения?

...нужно еще покапать исходники...

За на сколько я понял, для поставленной задачи не нужно делать внешний таймер, нужно только написать систему прерываний на внешнее событие.

[Alligator]

RTLinux was based on a lightweight virtual machine where the Linux "guest" was given a virtualized interrupt controller and timer - and all other hardware access was direct. From the point of view of the real-time "host", the Linux kernel is a thread. Interrupts needed for deterministic processing are processed by the real-time core, while other interrupts are forwarded to Linux, which runs at a lower priority than realtime threads. Linux drivers handle almost all I/O. First-In-First-Out pipes (FIFOs) or shared memory can be used to share data between the operating system and RTCore.

Изучение исходников emc2 точно не поможет, выше пресечение Ваших попыток (если нужно, могу дословно перевести) - если решение задачи будет, то только через изменение исходников реалтайного ядра, поскольку на уровне emc2 всё аппаратное уже отсечено

[Alligator]

То есть в исходниках emc2 выкидываем цикл, а вместо него вставляем ожидание некого мьютекса. А в исходниках реалтайм-ядра пишем перехватчик аппаратного прерывания, который будет это мьютекс выставлять. Наверняка есть механизм, чтобы реалтаймное ядро могло хоть один бит передавать своим подопечным процессам, одним из которых и является emc2. Но жизнь коротка...

[Nick]

"while other interrupts are forwarded to Linux"
Значит они где-то хранятся. Значит можно шариться по очереди этих прерываний. Правда тогда наверняка потеряем realtime, т.к. будет сложно спрогнозировать затраченное на просмотр очереди время.

Тогда действительно остается вариант с внешним таймером.
Но тогда нужно удостоверится, что нет процессов с уровнем realtime иначе наш hardware timer пойдет лесом.

Кстати, а как все это работает? Если во время работы постоянно генерируются задержки длинной в base_period, а генерируются они циклами с приоритетом realtime, то все остальное должно просто висеть до тех пор, пока не прекратится генерация шагов. А ведь не висит...
Значит, и прерывания обрабатываются... правда не в realtime .

[Alligator]

Не висит всё за счёт многозадачности - этого то я у этой системы не пытаюсь отнять Что есть, то есть, просто латентность великовата...

[Alligator]

http://www.cs.fsu.edu/~baker/realtime/r ... inux2.html

Вот тут можно порыться...

[Alligator]

rtapi_assign_interrupt_handler() в rtapi.h. и т. д. и т. п. Короче, поле непаханное...

[Alligator]

Хотя нет, не так всё мрачно. В функции thread_task() из hal_lib.c после вызова рабочих функций всех присоединённых компонентов стоит вызов rtapi_wait(), ожидающий следующего такта таймера. Это, собственно и есть ответ на Ваш вопрос, почему всё не виснет. А работа с внешними прерываниями подробно расписана в extint.c на живом примере аппаратного прерывания LPT-порта (типа, замыкаешь ножку порта принтера и там программный счётчик увеличивается для наглядности). Что же, шанс есть...

[Nick]

Эххх... только в час ночи до дома добрался... Завтра вечером посмотрю.

Итак, нужно будет создать обработчик прерывания и само прерывание с приоритетом realtime.

[Alligator]

Последний необходимый кусочек - когда один процесс (это должен быть обработчик прерывания) в заданный момент запускает другой спящий процесс посредством семафора - рассмотрен на примере rtapi/examples/semaphore через rtapi_sem_give() и rtapi_sem_take(). That's all

[Nick]

Хмммм... странно, что все эти примеры идут в исходниках EMC2 но в нем не используются...
Может там все таки есть прерывания на определенные пины LPT?