LinuxCNC + Orange Pi (allwincnc)

[donvictorio]

так пока дрово на видеочип не интегрировано всё равно графику цп рисует.

[svb]

так пока дрово на видеочип не интегрировано всё равно графику цп рисует.

Может тогда не заморачиваться всякими аксисами, гмоккапи, а просто пойти сюда

[Serg]

То есть надо понимать так, что софтовый рендеринг это не костыли. У нас и так не самый мощный проц, и как раз таки задача уйти от отрисовки средствами софтовыми и переложить эту задачу на GPU.

Нет. При попытке понять асппекты клиент-серверной парадигмы X Window System некоторым трудно преодолеть привычные шаблоны...
Попробую пояснить: В X Window System клиент - это тот, кто просит что-то сделать, в даннмо случае например что-то нарисовать на экране. Сервер - это тот, кто выполняет запросы клиентов, т.е. что-то рисует на экране. Таким образом программа LinuxCNC является клиентом с точки зрения X Window System, а комп за которым вы сидите - сервером.
Теперь касательно OpenGL (MesaGL): клиент (LinuxCNC) с помощью API OpenGL решает нарисовать на экране например прямоугольник. Если в качестве OpenGL используется MesaGL с прямым доступом к видеокарте (видеокарте компа на котором работает LinuxCNC, а не за которым вы сидите!), то она (MesaGL) ничего не может сделать - у неё нет доступа к экрану компа, на котором запущена LinuxCNC, на том компе и самого экрана-то может не быть. Поэтому вы получаете ошибку. Если же используется MesaGL-sw, то она ничего не пытается рисовать (то, что умеет рисовать Xserver), а просто передаёт команду клиента серверу. А вот на сервере может стоять MesaGL с прямым доступом к видеокарте (компа за которым вы сидите), которая уже отрисовывает задание в меру своих возможностей. Т.е. происходит "аппаратный рендеринг" но на компе с Xserver'ом, а не там, где стоит MesaGL-sw.
Для справки: современные Xserver'ы умеют самостоятельно выполнять такие граф. примитивы как линии, многоугольники/окружности, всякоразные заливки, текстуры, шрифты, ... Т.е. для отрисовки красного прямоугольника не передаётся каждый пиксель этого прямоуголника, передаётся лишь координаты 4-х точек и цвет заливки.

А вот всякие VNC и Teamviewer передают каждый пиксель экрана/видеопамяти. Правда для экономии трафика передают только изменившиеся пиксели, но т.к. для этого используется UDP, некотрые пиксели теряются и на экране остаются куски закрытых окон и непрорисованные участки - приходится часто жать refresh. Иногда приходится пользовать Teamviewer по мобильной сети - отрисовка экрана экрана может растягиватьтся на неск. секунд.

[svb]

Нет. При попытке понять асппекты клиент-серверной парадигмы X Window System некоторым трудно преодолеть привычные шаблоны...

Ну почему же.... очень даже нетрудно.
DISPLAY=user.host.ru:diplaynum linuxcnc machine_config.ini.

[MX_Master]

Честно говоря, не вижу смысла.....
Исходники и так на гитхабе лежат, а толстые файлы типа образов разумнее в какое-нибудь облако закидывать.
Да и вообще уже пора свой сайт пилить Типа orangecnc.ru

Там можно будет и вики запилить....

Как я и говорил ранее, мы (русско-говоряще-думающие) так устроены. Сколько будет участников, столько будет и версий проекта. Извините, ребята, но заниматься перетягиванием одеял мне некогда. Занавес.

[neller]

Да простит меня всесведущий All, но я слабо представляю, как рулить станком через RDP.
Одни задержки передачи чего стоят.

не очень удобно перевтыкать монитор, вот я и прикинул, что можно по RDP, тем более, что тут эта инфа где-то проскакивала.
как оказалось, помимо интерфейсов машинокита ещё и буфер обмена общий не работает, проблемы с переключением языка и тд. короче фтопку RDP

А зачем такие извращения? Если в том же Machinekit есть пачка удаленных интерфейсов, которые успешно позволяют управлять станком хоть с другого компа, хоть с планшета. Я вообще в OPi GUI убил и работаю удаленно, через ssh и Cetus.
https://github.com/machinekit/Cetus

[donvictorio]

Как я и говорил ранее, мы (русско-говоряще-думающие) так устроены. Сколько будет участников, столько будет и версий проекта. Извините, ребята, но заниматься перетягиванием одеял мне некогда. Занавес.

так одеяло то по сути пока только у тебя. так шо все норм.
я бы мог написать инструкцию для конечного пользователя совсем без опыта (коим и являюсь), но в lcnc пока не шарю, так что мало чем помогу.

[Olej]

Что касается РТ, тесты показывают, что с РТ патчем и ядром v4.14.y латенси тест на процессорах Н3,Н5 ~ 150-450
(не патченные cyclictest показывает 1500 и больше).
Можно кончно побороться и немного улучшить, но.
Такую задержку показывают устаревшие оригинальные ядра без всяких патчей, а птченные ~50-80.
Это неудовлетворительный результат. По моим оценкам, читая буквари Allwiner, эти процессоры спокойно должны обеспечить ~10-15.
Поэтому я начал искать другой путь. И нашёл - это XENOMAI.
Провёл тест на ноутбуке (хотя х86 архитектура). С РТ патчем лучше чем 70-80 не получилось,
а XENOMAI сразу, без особых настроек, показал 15-25.

Никакие патчи ядра Linux (PREEMPT_RT) и никакие LinuxCNC не могут обеспечить настоящий, hard realtime в принципе.

Выше я приводил тест с непатченным ядром v4.17.2 который оказался близким к оригинальным ядрам,
поэтом перешёл на эту версию, портировал XENOMAI IPIPE для этой версии ядра. Сегодня приступаю к процессу сборки.

Здесь результаты сравнительных тестов:
How fast is fast enough? Choosing between Xenomai and Linux for real-time applications
Это Кембриджкий университет, 17 стр., с картинками и графиками.
И это очень похоже на правду.
И это результаты не уступающие хвалёной OS QNX.
Там же - сравнения с более традиционным RTLinux с CONFIG_PREEMPT_RT - который не идёт ни в какое сравнение.

[Olej]

Вопрос в догонку, почему на линуске не любят использовать TeamViewer или тотже Anydesk ? оба работают исправно (по крайней мере на штатном образе linuxcnc).

Хотя бы просто потому, что TeamViewer для Linux - это выньдоузный .exe обёрнутый "online" в Wine ... т.е. костыли-костылями.

[donvictorio]

Там же - сравнения с более традиционным RTLinux с CONFIG_PREEMPT_RT - который не идёт ни в какое сравнение.

это, конечно, прекрасно, а делать то что надо, чтобы это дело получить?

[Olej]

собирается для ARM на buildroot

Спасибо за ссылку, но armbian-build круче, если в ней разобраться.
Работает более чисто, чем buildroot и развивается очень быстро.

Armbian - это дистрибутивная сборка (Debian обычно), а BuildRoot позволяет собирать минимальные образы Linux для конкретных встраиваемых применений.
Это совершенно разные вещи для совершенно разных целей.
Размер Armbian образа - 1-2Gb (это если без графики), размер образов, собранных BuildRoot - 75-150Mb.
В системе сборки Armbian можно использовать только фиксированную (последнюю) версию ядра, и нельзя использовать патченные ядра. Поэтому в системе сборки Armbian вы не сможете собрать систему с Xenomai Cobalt.

[Olej]

Там же - сравнения с более традиционным RTLinux с CONFIG_PREEMPT_RT - который не идёт ни в какое сравнение.

это, конечно, прекрасно, а делать то что надо, чтобы это дело получить?

Работать надо, работать

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

К счастью, на "попробовать" есть готовые публично доступные образы системы, от одного из голландских университетов, которые они используют в учебном спецкурсе по embedded системам:
- образ SD-карты для Rapsberry Pi: Raspberry Pi image for the Pi zero,1,2,3 with Xenomai 3.0.5 on Raspbian linux 4.1.y Debian 8 jessie
- образ виртуальной машины под VirtualBox: VirtualBox Images for Xenomai 3.0 and Xenomai 2.4
И тот, и другой вариант мной проверен на работоспособность и адекватность.

[Olej]

а делать то что надо, чтобы это дело получить?

1. Нужен патч ipipe исходников майнлайнового ядра (с kernel.org), патч проекта .
Берётся здесь - Index of /downloads/ipipe/v4.x, под свою процессорную архитектуру:

Код: Выделить всё

[DIR] arm/					12-Jun-2018 19:15	-   
[DIR] arm64/				  08-Apr-2018 16:47	-   
[DIR] blackfin/			   26-Mar-2018 09:31	-   
[DIR] powerpc/				26-Mar-2018 09:31	-   
[DIR] x86/					26-Mar-2018 17:54	-

Это патчи проекта Adeos (Adaptive Domain Environment for Operating Systems) (это любопытно почитать).
Патчи изготавливаются далеко не под все версии ядра, например для ARM:

Код: Выделить всё

[TXT] ipipe-core-4.14.36-arm-1.patch 12-Jun-2018 19:12  587K  
[TXT] ipipe-core-4.4.71-arm-9.patch  03-Oct-2017 12:35  672K  
[TXT] ipipe-core-4.9.51-arm-4.patch  26-Mar-2018 09:16  700K  
[DIR] older/						 12-Jun-2018 19:13	-

2. Собрать новое ядро и установить в системе Linux...

3. Скачать Xenomai real-time core, собрать из исходников и установить...

4. Писать свои realtime task в Posix-нотации (это новинка в Xenomai, они называют это skin-ы), но компилировать специфичным Makefile:

Код: Выделить всё

XENO_DIR = /usr/xenomai
XENO_CONFIG := $(XENO_DIR)/bin/xeno-config
CFLAGS  := `$(XENO_CONFIG) --posix --cflags`
LDFLAGS := `$(XENO_CONFIG) --posix --ldflags`
CC := `$(XENO_CONFIG) --cc`

all: main_posix lb1

main_posix: main_posix.c
		$(CC) -Wall $(CFLAGS) $< $(LDFLAGS) -o $@ -lanalogy -ltrank -lmodechk -lcopperplate
...

И запускать потоки с realtime диспетчированием Linux (естественно, это потребует root):

Код: Выделить всё

...
  struct sched_param sparam;
   sparam.sched_priority = 99;
   rc = pthread_create( &thread, NULL, TaskCode, NULL );
   assert( 0 == rc );
   rc = pthread_setschedparam( thread, SCHED_FIFO, &sparam );
...

Т.е. любая realtime ОС - это не "серебрянная пуля", когда все стандартные программы начинают бегать "в лёт".
Для realtime ОС нужно писать свои собственные программы, чтобы они использовали realtime.
И realtime OS не быстрее обычных (GPOS), а чаще всего медленнее, но в ней задержки детерминированные - они никогда не могут превышать какой-то разумной величины ... а в Linux могут быть, хоть и изредка, сколь угодно длинными ... а про Windows я даже не говорю - "я скорблю вместе с вами"

[Olej]

Выше я приводил тест с непатченным ядром v4.17.2 который оказался близким к оригинальным ядрам,
поэтом перешёл на эту версию, портировал XENOMAI IPIPE для этой версии ядра. Сегодня приступаю к процессу сборки.

Напишите в 2 слова: как портировали патч ipipe проекта Adeos, и, самое главное, из каких источников (URL) брались исходные коды для портирования.

[going]

Размер Armbian образа - 1-2Gb (это если без графики), размер образов, собранных BuildRoot - 75-150Mb.
В системе сборки Armbian можно использовать только фиксированную (последнюю) версию ядра, и нельзя использовать патченные ядра. Поэтому в системе сборки Armbian вы не сможете собрать систему с Xenomai Cobalt.

1) Armbian может собрать и 64 Мб образ для размещения в NOR
2) Версия ядра может быть такой какой скажешь системе сборки
3) "Использовать патчаные ядра" - а зачем? Если система сборки сама все патчи применит, если ей их дать (положить в нужное место)
4) Уже собираю Xenomai Cobalt.

Пожалуйста почитайте документацию Armbian

Напишите в 2 слова: как портировали патч ipipe проекта Adeos, и, самое главное, из каких источников (URL) брались исходные коды для портирования.

Два слова, источники одни, Вы их привели здесь.

[going]

Здесь результаты сравнительных тестов:
How fast is fast enough? Choosing between Xenomai and Linux for real-time applications

Согласен. Очень даже правда.

[Olej]

Если ОЗУха действительно не выдержит нашей комфортной работы то мы смело возьмём Orange Pi PC (1Гб ОЗУ) вместо Orange Pi One. Как известно, One - это урезанная версия PC. Но начинать мы будем всё равно с меньшего.

По спецификациям OPi One (и идентичная OPi Zero) - не "урезанная версия" OPi PC, а просто младшие модели в семействе SoC на H3.
Но OPi One для некоторых применений (типа embedded автоматики, управления всякими железками) может иметь и преимущества перед OPi PC: а). отсутствие лишних чипов, всяких свистелок-перделок типа аудио и пр. б). а это ток потребления в). а это тепло и охлаждение ... а кроме того, как выяснилось (этого нет нигде в даташитах) OPi One можно питать через USB (на который и клавиатуру с мышей повесить), что упрощает отработку, и чего нельзя делать во всех старших моделях OPi.

[going]

Никакие патчи ядра Linux (PREEMPT_RT) и никакие LinuxCNC не могут обеспечить настоящий, hard realtime в принципе.

А собственно да. Это так.

[going]

(этого нет нигде в даташитах)

А схему посмотреть?

[Olej]

3) "Использовать патчаные ядра" - а зачем? Если система сборки сама все патчи применит, если ей их дать (положить в нужное место)
4) Уже собираю Xenomai Cobalt.

А вот когда соберёте - тогда и обсудим ... я уже это делал раз 10 и знаю какие там проблемы...
Патч ipipe применяется не стандартным образом, а выполнением скрипта из исходников Xenomai.

Пожалуйста почитайте документацию Armbian

Уже давно это сделал, и собирал ядро новое и обновлял ним существующий образ (SD) Armbian.

Напишите в 2 слова: как портировали патч ipipe проекта Adeos, и, самое главное, из каких источников (URL) брались исходные коды для портирования.

Два слова, источники одни, Вы их привели здесь.

[/quote]
Там нет исходников. Там есть готовые патчи, которые готовят сами Xenomai. И в руководствах Xenomai рекомендуют использовать именно их, и нет ни слова о том, откуда и как собрать патч.