cnc-club.ru

UAVpilot писал(а):Зачем? Он может сразу всё расчитать и результат положить в некий буфер, из которого в каждый сервоцикл будет передаваться генераторам данные по перемещениям, которые нужно сделать в очередном сервоцикле. Именно тут только и начинается RT. Вот хорошая картинка, поглядывайте на неё: http://linuxcnc.org/docs/devel/html/cod ... e_overview

Из картинки вроде как следует ,что результат интерпретации gcode кладется в буфер.Но он вроде преобразует gcode в какие-то более простые(для расшифровки) команды,а потом уже их обрабатывает в реальном времени.Интерполятор же должен включаться уже при обработке непосредственно движения ,а не преобразовывать gcode.

UAVpilot писал(а):G-код незачем "парсить" с точностью до каждого шага (микрона), на его выходе (точнее на выходе планировщика) достаточно получать команды/данные типа "сделать в ту сторону N шагов со скоростью S", а превратить такое задание в массив состояний пинов сможет сам генератор.

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

sidor094 писал(а):Драйвера для ARM?

те, которые в составе ядра.

UAVpilot писал(а):Интерпретатор G-кода?

в смысле "читатель и исполнитель", а не только парсер и анализатор.

arkhnchul писал(а):те, которые в составе ядра.

Для свистулек WIFI драйвера идут в основном под процессоры INTEL .Не важно LINUX или WINDOWS но только под INTEL .А здесь CORTEX(ARM).

arkhnchul писал(а):в смысле "читатель и исполнитель", а не только парсер и анализатор

Интерпретатор преобразует текстовые данные в числовые величины(float,int) координат(x,y z)и тип движения (g0 g1 g2 g3).

Сергей Саныч писал(а):Если какое-то устройство способно захватить память монопольно и надолго, то есть на неограниченное количество циклов доступа к памяти (я не в курсе, возможно ли такое в процессоре, который в Orange), то да.

Процессор - это отдельное от DMA устройство и он не может запретить каким-либо устройствам пользоваться DMA.
Разрешить/запретить может ядро ОС, а в Linux оно разрешает.

Сергей Саныч писал(а):Если же суммарное время захвата памяти помянутыми (и непомянутыми) узлами не превышает нескольких циклов доступа, то с таким "джиттером" мириться можно.

Может не превышать, а может и превышать - в не-RT ОС всё это возможно. Уже 100500 раз говорил, что RT - это не быстродействие, а гарантированное время отклика на события.

sidor094 писал(а):Из картинки вроде как следует ,что результат интерпретации gcode кладется в буфер.Но он вроде преобразует gcode в какие-то более простые(для расшифровки) команды,а потом уже их обрабатывает в реальном времени.Интерполятор же должен включаться уже при обработке непосредственно движения ,а не преобразовывать gcode.

Да, там простые задания типа "в течении времети T осью Х ехать в ту сторону со скоростью Sx, а осью Y в эту сторону со скоростью Sy". Интерполятор - это часть планировщика, который в том числе занимается и расчётом синхронного движения осей. Для этих расчётов RT не нужно.

sidor094 писал(а):Для свистулек WIFI драйвера идут в основном под процессоры INTEL .Не важно LINUX или WINDOWS но только под INTEL .А здесь CORTEX(ARM).

Процессор тут значения не имеет. В ядре для ARM полностью реализованы USB стек и WiFi стек. Драйвер свистульки - это мостик между этими стеками, он написан на стандартном C и совершенно спокойно компилится под любую платформу. Можно скачить исходники ядра Linux и самостоятельно убедиться в этом - исхоники драйверов даже расположены в общей части, а не в платформозависимой.

sidor094 писал(а):Для свистулек WIFI драйвера идут в основном под процессоры INTEL

arkhnchul писал(а):те, которые в составе ядра

Со сборкой ядра с RT патчем стало всё боль мень понятно. Но есть загвоздка. При установке в систему, идёт доп. компиляция. А т.к. система работает на плохой китайской MicroSD карте, этот процесс растягивается на вечность.

Вощем, придётся полностью образ для MicroSD карты собирать, а не только ядро..

UAVpilot писал(а): Интерполятор - это часть планировщика, который в том числе занимается и расчётом синхронного движения осей. Для этих расчётов RT не нужно.

sidor094 писал(а):

Однако на картинке планировщик находится в РТ части.

UAVpilot писал(а):Драйвер свистульки - это мостик между этими стеками, он написан на стандартном C и совершенно спокойно компилится под любую платформу. Можно скачить исходники ядра Linux и самостоятельно убедиться в этом - исхоники драйверов даже расположены в общей части, а не в платформозависимой.

В LINUX не силен,но на каждую свистульку свой драйвер,и не видел ,чтобы с исходниками

sidor094 писал(а):Однако на картинке планировщик находится в РТ части.

В LinuxCNC это именно так. Я-же говорю, что планировщик в принципе можно вынести из RT (развивая мысль ТС), но совсем без RT не обойтись.

sidor094 писал(а):В LINUX не силен,но на каждую свистульку свой драйвер,и не видел ,чтобы с исходниками

Смотри на здоровье, совершенно бесплатно: https://github.com/torvalds/linux/tree/ ... k/rtl8xxxu
Обрати внимание на имена файлов - они означают, что один драйвер поддерживает не конкретную модель "свистульки", а сразу десятка два подобных устройств.
Это в винде один и тот-же драйвер не походит к однотивным устройствам, отличающимся лишь парой VID:PID...

Спасибо.Понял.Буду разбираться.Надо читать по Линуксу .

Собрал образ системы с RT патчем, установил всё также как в системе без RT патча.
4-е ядро изолировано и там, и там (isolcpus=3).

Запускал cyclictest на двух системах. Результаты ниже.
Белый - без RT, чёрный - с RT патчем.
Что-то не заметно больших различий. ~3500 мкс и там, и там.
Может, кто подскажет в чём может быть дело?
И как правильно протестировать RT систему?

просто накатили патч и собрали? preemption mode в конфиге ядра не забыли случаем выбрать?
https://wiki.linuxfoundation.org/realti ... ion_models

Вопрос: А почему время выполнения программы должно было измениться?

arkhnchul писал(а):просто накатили патч и собрали? preemption mode в конфиге ядра не забыли случаем выбрать?
https://wiki.linuxfoundation.org/realti ... ion_models

указал Preemptible Kernel (Basic RT), а вот с Fully Preemptible Kernel (RT) не собирается

Сергей Саныч писал(а):Вопрос: А почему время выполнения программы должно было измениться?

А где там время выполнения программы?

Сергей Саныч писал(а):А почему время выполнения программы должно было измениться?

измениться по идее должны были значения в последнем столбце, max latency

Вот и тут внизу пишет человек https://github.com/ScotSalmon/rt-tests , что последнее правое значение (MAX) это и есть max latency

Вопрос снят. я посчитал, что это время выполнения тестовой программы из предыдущих постов.

MX_Master писал(а):Что-то не заметно больших различий. ~3500 мкс и там, и там.
Может, кто подскажет в чём может быть дело?

Basic RT model is mainly for debugging of RT, use RT instead. RT aims to minimize parts of the kernel where preemption is explicitly disabled.

ясно, пойду смотреть логи сборки ядра полным RT.. как минимум, придётся руками многие места подправить..

UPDATE:
С небольшим костыльком в коде, собрал, всё-таки, ядро с RT патчем и опцией FULL_RT (5).
Всё установлено точь также как и в предыдущих образах. 4-е ядро проца изолировано (isolcpus=3).
Результат cyclictest'a на удивление похож на все предыдущие:
Даже и не знаю, что думать. Сергей (UAVpilot), подскажите пожалуйста дальнейшее направление.
Если кто-то знает в чём может быть дело, буду очень рад.

Затусуйся на форуме 4pda, там есть очень умные дядьки.