LinuxCNC + realtime LPT

[yurial]

Привет, я у вас новенький.
Почитал я про LinuxCNC - все мучаются с таймингами, пробуют RTAI, RT PREEMT, но все-равно результаты оставляют желать лучшего.
Если посмотреть как решается проблема в уже существующих устройствах, критичных ко времени, то можно заметить примерно один и тот же подход: генерация данных происходит достаточно большими пачками, буферы отправляются во внутреннюю память устройства, само устройство берет данные из внутреннего буфера. (Подобным образом, например, работает звуковая карта).
Если попробовать данный подход применить к управлению станком, то должно выглядеть примерно так: LinuxCNC генерирует управляющую последовательность состоящую из команд управления и задержек, буферезирует, и отправляет в некое устройство вывода, которое способно обеспечить нужные тайминги.
Самый простой и распространенный вариант устройства вывода - LPT порт. Нужные тайминги можно обеспечить путем использования потока ядра (kernel) выполняющегося на изолированном ядре (core). Управляющая последовательность состоит из 2х команд:
а) задержка (timeout);
б) состояние выходов LPT порта.
Реализовать команды можно как 32bit числа. Если старший бит == 1, то оставшиеся 31 бит интерпретируются как timeout, иначе данные выводятся в LPT порт. Модуль ядра имеет внутренний буфер (например, кольцевой) и вычитывает управляющую последовательность из него. Общение с модулем происходит через псевдоустройство, поддерживающее запись данных в буфер, и минимальные управляющие команды

Такой подход подойдет для любых систем имеющих несколько ядер (core) любого ядра linux (kernel) поддерживающего isolcpus (доступно даже на 2.6 ядрах). Модуль ядра должен быть достаточно прост и подходить для любой версии ядра.

Кажется, что все просто и легко, и потому не понятно, что именно я не учел, почему так не сделано? Всем спасибо.

[MX_Master]

Нужные тайминги можно обеспечить путем использования потока ядра (kernel) выполняющегося на изолированном ядре (core)

На изолированном ядре процессора ядро системы всё равно проводит хозяйственные операции хотя бы раз в секунду. Длятся они как минимум 10-20 мкс. Поэтому хотя бы раз в секунду, промеж хороших таймингов, будет проскакивать нехорошая пауза. Для частот ниже 30 КГц эта пауза некритична. Для всего остального - будет заметна. Поэтому никто такой способ и не применяет.

Чтобы дёргать пины без пауз, нужно полностью спрятать дополнительные ядра и сопроцессоры от ядра системы. На полностью спрятанном ядре (или сопроцессоре) надо выполнять простейшую bare-metal программку, которая монопольно дёргает регистры порта вывода и не лезет в общую шину памяти с другими ядрами. Как-то так

[Serg]

Проблема в том, что даже имея 100500 ядер мы всё равно столкнёмся с тем, что шина доступа к памяти/периферии одна на всех и пока она будет занята одним из 100500 ядер все остальные 100499 будут ждать её освобождения.

Сия проблема хорошо решается тем фактом, что аппаратный контроллер нынче стоит менее $100, что как правило составляет не более 2% от стоимости станка.

[MX_Master]

Причём, на разных процессорах эти пути к памяти/периферии неисповедимы (:

[yurial]

Нужные тайминги можно обеспечить путем использования потока ядра (kernel) выполняющегося на изолированном ядре (core)

На изолированном ядре процессора ядро системы всё равно проводит хозяйственные операции хотя бы раз в секунду. Длятся они как минимум 10-20 мкс.

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

[MX_Master]

Если ядра изолированы с помощью isolcpus, на них всё равно пашут в фоне собственные процессы ядра системы. Для убеждения в оном достаточно в htop поставить галку для показа процессов ядра. К тому же, каждая версия ядра системы нагружает свои хозяйственные процессы по-разному. В старых версиях - меньше, в новых - больше.

Немного пруфов - здесь

[yurial]

Немного пруфов - здесь

Спасибо. Очень интересный тред.