lkcxa@192 ~/PRG/mcu805ide $ stcgal -p /dev/ttyUSB0 -b 9600 -P stc89 test_1.hex
Serial port error: [Errno 13] could not open port /dev/ttyUSB0: [Errno 13] Permission denied: '/dev/ttyUSB0'
lkcxa@192 ~/PRG/mcu805ide $ sudo usermod -a -G dialout lkcxa
[sudo] пароль для lkcxa:
lkcxa@192 ~/PRG/mcu805ide $
Ещё пробовал так. При этом должна отправлятся строка, и это видно лог. анализатором, или на другом компе в UART терминале. Ну тут ничего не происходит.
Операционная система: ROSA Fresh Desktop 2021.1
Версия KDE Plasma: 5.27.4
Версия KDE Frameworks: 5.105.0
Версия Qt: 5.15.5
Версия ядра: 5.10.184-generic-1rosa2021.1-x86_64 (64-бита)
Графическая платформа: X11
Процессоры: 4 × AMD A8-5600K APU with Radeon(tm) HD Graphics
Память: 7,0 ГиБ ОЗУ
Графический процессор: AMD ARUBA
Производитель: Gigabyte Technology Co., Ltd.
ln -s /dev/ttyS0 ~/wineprefix/dosdevices/com1
sudo chmod 666 ~/wineprefix/dosdevices/com1 - на случай, если ПО удаляет (!) симлинк перед попыткой подключения.
Но работает это только при поддержке ком-порта. Не важно, через RS-232 подключение или через USB.
При взаимодействии по USB это НЕ работает.
Я пробовал сделать так, чтобы это работало и с USB, но похоже, на разные устройства требуются разные драйвера.
В современных Linux за права доступа к USB и USB-to-Serial устройствам отвечает systemd,
а именно udev (команда udevadm). Доступ основан на правилах и группах пользователей.
1) Найдём своё устройство. При подключении в USB порт udev автоматически создаёт ссылку на псевдофайл:
dialout - для USB-to-Serial устройств. Создаёт /dev/ttyACM*
uucp - для USB устройств. Создаёт /dev/ttyUSB*
группы типа tty, serial устаревшие - не используйте их.
Т.е. нужно добавить себя в две стандартные группы (и перезагрузить права). Можно сделать через GUI "Настройки системы",
управление пользователями -> редактировать, вкладка Стандартные Группы. Но перед этим:
2) Блокировка доступа.
Историческая проблема, что невозможно заблокировать одновременный доступ нескольких программ к одному Serial порту, т.е. к /dev/ttyACM0.
Для этого был придуман механизм Lock-файлов на устройства. Идея в том, что программа с привилегиями root может создать файл:
в зависимости от задач настройки. Либо в своём программном обеспечении всегда указывать код выключения Lock-механизма.
Нужно понимать, что независимо о вхождении в эту группу, для создания lock-файла понадобится root или sudo.
Посмотрите права куда ссылается /var/lock
Если вы запускаете чужую программу, а в коде используется lock-механизм, то без sudo она не запустится. Т.к. перед подключением к Serial порту ей нужно создать файл в lock-директории.
Это по-другому в Windows, поэтому важно понимать эту специфику при кросс-платформенной разработке.
Важно понимать также, что удаление файла блокировки - обязанность программы клиента (как и в win). Если программа зависла или была прибита, то файл может остаться. А тогда вы не сможете подключиться к этому порту никак. Удалите lock-файл руками. Часто именно в нём проблемы с подключением.
3) Как правильно настроить права.
Идеология простая: USB устройства приписываются группам. Пользователи добавленные в группы автоматически получают доступ.
Но правила позволяют добавить не только в стандартные группы (dialout) для всех пользователей, но и исключительно для себя,
или для всех, или только для root.
Чтобы создать правила для устройства создайте файл(под root) в:
# USB link on with Klipper firmware
#
SUBSYSTEMS=="usb", ATTRS{manufacturer}=="Klipper", \
GROUP:="dialout", \
MODE:="0660", \
SYMLINK+="klipper%n klipper"
Такое правило срабатывает для устройств которые сообщат параметр о себе manufacturer = "Klipper" (см. udevadm info /dev/ttyACM0).
Файл устройства "/dev/ttyACM*" будет добавлен в группу dialout с правом писать для группы.
Т.е. доступ получат все пользователи системы, которые добавлены в эту стандартную группу.
Так же будут созданны две ссылки "/dev/klipper" и "/dev/klipper0". Если устройств несколько, то совпадающая ссылка будет перезаписана последним устройством. А ссылки с %n это порядковый номер, как в ttyACM%n
Вот пример для адаптера ST-Link (на git открытый проект):
# STM32 nucleo boards, with onboard st/linkv2-1
# ie, STM32F0, STM32F4.
# STM32VL has st/linkv1, which is quite different
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374a", \
MODE:="0666", \
SYMLINK+="stlinkv2-1_%n stlink"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", \
MODE:="0666", \
SYMLINK+="stlinkv2-1_%n stlink"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3752", \
MODE:="0666", \
SYMLINK+="stlinkv2-1_%n stlink"
# If you share your linux system with other users, or just don't like the
# idea of write permission for everybody, you can replace MODE:="0666" with
# OWNER:="yourusername" to create the device owned by you, or with
# GROUP:="somegroupname" and mange access using standard unix groups.
Здесь используются широко известные VID/PID из данных USB-устройства. У некоторых UART адаптеров можно перепрошить VID/PID,
чтобы использовать его как часть своего устройства. Позволит не писать драйвер и сделать автоопределение (см. https://playground.arduino.cc/Linux/Udev/).
Итого:
а) добавить пользователя в три группы (+перезагрузить права!)
б) проверяйте подвисшие lock-файлы
в) настройте один раз нормально правило для устройства.
*) определитесь, нужно ли запускать вашу программу с sudo правами, т.е. использует ли она Lock-механизм.
Советы изменить просто права chmod на файл не будут работать, т.к. udev удалит файл устройства при его вынимании из порта. И создаст новый при подключении соответственно. Это всё припарки.
P.S. HID-устройства типа мышь и клавиатура в /dev/input/
Ну ОК.
Вот понадобится мне прошить программатором вундерчип программой через wine.
Во времена rosa2016.1 systemd был тоже.
Я бы сделал единожды (если это новый /home)
ln -s /dev/ttyS0 ~/wineprefix/dosdevices/com1
sudo chmod 666 ~/wineprefix/dosdevices/com1
И прошил.
Что набрать в качестве альтернативы этому? Текста много. В выводе команд никаких совсем.
Советы изменить просто права chmod на файл не будут работать, т.к. udev удалит файл устройства при его вынимании из порта. И создаст новый при подключении соответственно. Это всё припарки.
Подчеркну, что симлинк chmod применяется к файлу в префиксе, по сути, в конфиге пользователя. Udev его не удалит.
Я бы сделал единожды (если это новый /home)
ln -s /dev/ttyS0 ~/wineprefix/dosdevices/com1
sudo chmod 666 ~/wineprefix/dosdevices/com1
И прошил.
Можно использовать любой костыль, на то он и Linux
Но, если речь о Wine, то это просто не нужно. Указываем название устройства так же, как в Linux. Т.е. при подключении вместо COM1 прямо вписываем /dev/ttyS0 и всё должно подключиться. Wine внутри себя имена должен преобразовывать. Правда, сейчас попробовал своей программой в Wine8.12 к своему МК подключиться... оно подключилось, но данные не пошли почему-то (Lazarus/SynaSer).
Должно работать без всяких консолей и ln, просто тыкаем мышкой в GUI и добавляем юзера в три группы, и указываем устройство явно при подключении.
Если память не изменяет, то установлено жёсткое соответствие COM1=/dev/ttyS0, COM2=/dev/ttyS1, и т.д. И, даже можно просто по номеру 0,1,2... без COM.
Но это для железных устройств! /dev/ttyS0 получит встроенный в мат.плату COM-порт или подключенный в PCI слот. Воткнутое в USB USB-to-Serial устройство получит /dev/ttyACM0, а у него нет синонима в COM*.
Подчеркну, что симлинк chmod применяется к файлу в префиксе, по сути, в конфиге пользователя. Udev его не удалит.
Проблемы начинаются, когда у вас постоянно подключаемое N-ое количество устройств. Они будут получать разные имена в зависимости от порядка обнаружения. Это когда один железный COM-порт он всегда №0 - COM1 - /dev/ttyS0, а когда USB, то номера по порядку подключения/втыкания.
И в итоге ваша ссылка будет на разные устройства указывать. Даже для железных устройств НЕТ гарантии порядка нумерации. После очередной фазы луны, при перезагрузке, ваш ttyS0 станет ttyS1. И хорошо, если это не ИБП на атомной станции
Что набрать в качестве альтернативы этому? Текста много. В выводе команд никаких совсем.
О том и весь текст. Если не "дуть против ветра", можно вообще консоль не открывать. Совсем. Добавь себя в три группы (+удали лок-файл) прямо мышкой из интерфейса, и всё. Навсегда. Без процентов и переплат(с)
Понимание работы механизма спасёт от лютых проблем.
Например, самый распространённый/бюдежтный программатор ST-LINK с открытым драйвером и утилитами: https://github.com/stlink-org/stlink
Как это устроено?
Это USB устройство. Оно не является стандартным USB-to-Serial или USB-HID, поэтому драйвера/модуля для него в системе нет.
После установки rpm, установится драйвер и те самые правила udev.
Таким образом, при втыкании программатора, udev назначит ему драйвер, создаст псевдофайлы (/dev/*) согласно правилам и постоянные ссылки.
И тут начинается магия! Если вы добавили себя в группы, как положено, то у вас доступ автоматически заработает! Просто мышкой тыкнули в rpm, всё установится и утилитами из комплекта будет подключаться.
А потом вы установите второй программатор STLINK, новой версии. И у вас опять всё само заработает. Без консолей. Без гуглюжа.
И ссылка /dev/stlink всегда будет указывать именно на программатор. И даже для всех пользователей, сервисов/демонов.
А потом вы начнёте добавлять свои устройства, отлаживать целый зоопарк, а ссылки будут правильные даже при 10 занятых USB и парочке PCI-плат.
P.S. я прочитал много старых неверных советов, поэтому решил расписать как правильно. В своё время, мне бы месяц жизни пара таких постов сэкономило.
И у меня прекрасно работает. Просто забыл, что постоянную ссылку делал на USB устройство, а мне нужно было Serial - оно вторым определяется.
Подытожу по поводу Wine и Serial-port:
1. В Wine можно/нужно использовать устройства именованные в UNIX-стиле. Прямо пишем /dev/ttyACM0 вместо COM*,
или заданную нами постоянную ссылку /dev/klipper0
из моего примера udev rule выше, ссылки
/dev/klipper - указывает на USB устройство, а
/dev/klipper0 - само Serial устройство, т.е. /dev/ttyACM0
т.е. для подключения по Serial нужно использовать именно то, которое указывает на tty,
а для работы с USB-стеком, которое указывает на bus/usb/*
создаются АВТОМАТИЧЕСКИ после запуска wine! Проверил wine8.12. В моём случае для /dev/ttyACM0 автоматически создалась ссылка com33
Как я уже попинял, делать это в ручную "совет из прошлого века". Нужно просто заглянуть в папку, если надо.
У меня, например, прошивка умеет выполнять Сброс себя. Тогда требуется переподключиться к порту, а адрес в Linux будет уже другой /dev/ttyACM1 (/dev/klipper1).
Под виндой - адрес будет выдан тот же COM*. Так что иногда без правильной настройки правила с постоянной ссылкой никак.
И для моего примера выше нужно дополнять правило, чтобы получать постоянку и на само Serial устройство.
P.S. а можно ещё из wine запускать linux программу и получить её вывод назад в свою win программу, искать по:
wineconsole start \unix "/opt/myapp -port /dev/ttyACM0"
и смотреть параметры команды start. "--backend=user" больше не нужен, к мамонтам.
пример
wineconsole start \unix /usr/bin/konsole
P.P.S. Для Lazarus/FreePascal библиотека SynaSer работает на win/linux/wine кроссплатформенно.
