cnc-club.ru

UAVpilot писал(а):Так не надо пользовать драйвер от EMC, просто открывай /dev/ttyS0 и вперёд.

Это устройство использовать не получится.
Драйвера ЕМС загружаются по "loadrt" в реалтаймовое ядро. Кроме того в драйверах ЕМС описан экспорт пинов который потом можно привязать к ХАЛ.
Поэтому никакие стандартные драйвера устройств линукса с ЕМС не работают.

Полагал, что понимающим о чём речь понятно, что /dev/ttyS0 открывается не в RT-контексте. Вывод байтов в порт из RT надо делать например через SHM.
Да и вопросы наводящие задавал...

UAVpilot писал(а):Полагал, что понимающим о чём речь понятно, что /dev/ttyS0 открывается не в RT-контексте.

К сожалению, я не из "понимающих". Но подозревал, что тут могут быть проблемы. Потому и спросил.

UAVpilot писал(а):Полагал, что понимающим о чём речь понятно, что /dev/ttyS0 открывается не в RT-контексте. Вывод байтов в порт из RT надо делать например через SHM.

И мне не понятно как можно в реальном времени связать через общую память ввод-вывод ЕМС и линукс. Объясните.

Делаете буфер в SHM или MSG (ipc), в RT пихаете туда байтики, а процессом вне RT достаёте их оттуда и суёте в порт.

UAVpilot писал(а):Делаете буфер в SHM или MSG (ipc), в RT пихаете туда байтики, а процессом вне RT достаёте их оттуда и суёте в порт.

А как контролировать задержки? Ключевое слово в вопросе о реалтайме.

Только так: http://www.cnc-club.ru/forum/viewtopic. ... 690#p50690

Похоже, есть два варианта - каждый со своими недостатками:
1. Работаем в реалтайме на уровне физических регистров порта. Гарантирует своевременную доставку, но позволяет работать только с реальным портом - виртуальные USB-COM не прокатывают. А настоящих портов в современных компах почти не осталось,
2. Переваливаем данные в фоновый режим, работаем стандартными средствами Линукса, можем использовать любые порты, включая виртуальные, но имеем все "прелести" глубокой буферизации и задержек.

А чем ты хочешь таким образом управлять?

Nick писал(а):А чем ты хочешь таким образом управлять?

Станком, само собой
Если точнее, аппаратным формирователем сигнала Step для ШД

А на чем будешь его генерировать.
Думал сделать такую штуку для ардуинки, запихать все общение с ней в user-space и посмотреть насколько будет убегать... Но что-то ардуинка своими возможностями не впечатлила...

Serg-tmn писал(а):Похоже, есть два варианта - каждый со своими недостатками:

1. Не гарантирует, ибо передача асинхронная. Как-то гарантировать может разве что длительность сервоцикла, в несколько раз превышающая длительность передачи данных, для организации повторов случись что. Ну и переход на синхронную передачу тут поможет, например тот-же SPI.
2. Откуда сведения о "глубокой буферизации"?

Nick писал(а):А на чем будешь его генерировать.

Есть такие микроконтроллеры - SX28 и SX48, не очень распространенные, порядком устаревшие, но я на них "подсел" лет 13 назад и до сих пор слезть не могу, как ни пытаюсь
Тактовая частота - до 75МГц, на команду (кроме переходов) - 1 такт, фиксированная задержка обработки прерываний - в общем, для реалтайма самое то. Три канала один контроллер должен потянуть.

Serg-tmn писал(а):1. Работаем в реалтайме на уровне физических регистров порта. Гарантирует своевременную доставку, но позволяет работать только с реальным портом - виртуальные USB-COM не прокатывают. А настоящих портов в современных компах почти не осталось,

Я сделал распределенный контроллер с обменом через СОМ, но получилось только через физический и на скорости 921600.
Вот здесь я немного расписывал когда начинал.
http://www.cnc-club.ru/forum/viewtopic. ... t=40#p3762

UAVpilot писал(а):Не гарантирует, ибо передача асинхронная

Какая связь? Мы просто выбрасываем байты по TxD "в белый свет, как в копеечку". Забота о том, чтобы их все принять - на другом конце провода. Хэндшейкинг не предусматривается, повторы - тоже. Время передачи каждого байта при 8N1 - 10 тактов. При 115200 бод 5 байт будут передаваться 434 мкс - меньше половины стандартного сервоцикла.

UAVpilot писал(а):Откуда сведения о "глубокой буферизации"?

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

Impartial писал(а):http://www.cnc-club.ru/forum/viewtopic. ... t=40#p3762

Очень неплохо, но у меня задачи поскромнее.

Serg-tmn писал(а):Мы просто выбрасываем байты по TxD "в белый свет, как в копеечку". Забота о том, чтобы их все принять - на другом конце провода.

А если битик потерялся, то "хрен с этой заготовкой, главное успели"?
Эт какая-то электронная бюрократия получается.

Serg-tmn писал(а):Придется устраивать, чтобы избежать задержек передачи.

А откуда они возьмутся?

UAVpilot писал(а):А если битик потерялся, то "хрен с этой заготовкой, главное успели"?

Ну, можно еще байт на контроль отвести, и устраивать Estop, если что не так. С тем же успехом может ведь и на LPT импульс пропасть.

UAVpilot писал(а):А откуда они возьмутся?

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

Serg-tmn писал(а):С тем же успехом может ведь и на LPT импульс пропасть.

В результате пропажи одного импульса на LPT потеряется 1 шаг, а из-за пропажи одного импульса (бита) на последовательном порту может потерятся команда останова или смены напраления и испортится не только заготовка.

Serg-tmn писал(а):когда, скажем, системе приспичит проиндексировать диск.

Эта проблема решается проще всего - планированием конфигурации компа.

UAVpilot писал(а):В результате пропажи одного импульса на LPT потеряется 1 шаг, а из-за пропажи одного импульса (бита) на последовательном порту может потерятся команда останова или смены напраления и испортится не только заготовка.

Ну надо делать что-то типо сервы - команду получаем на положение в шагах (два-четыре байта). Обратно выдаем текущее положение - т.е. полноценный внешний stepgen. В итоге потеря одной команды приведет к маленькой горбинке, т.к. ось за 1 мс далеко с траектории не сойдет, а потом при следующей команде ось свое догонит.