в каком ЯП/тулките из коробки есть адекватная/хорошая/безглючная либа для работы с com-портами?

Qt Serial Port

интересует создание standalone-бинарников с минимальными зависимостями

если с минимальными зависимостями, то работай с портами напрямую, это несложно

standalone-бинарников с минимальными зависимостями.
Qt Serial Port

Там зависимостей на два DVD будет.

одного CD хватит :)

в tcl с рождения из коробки.

пример см http://wiki.tcl.tk/1108

для работы с line-oriented текстовыми протоколами идеально подходит expect

GLib. Кросслатформенно, удобно.

libc /thread

https://github.com/wjwwood/serial

Чистая сишечка. Поллинг на выбор: select (я так делаю), poll, epoll...

Один раз напишешь скелет и будешь все время пользоваться.

Да даже и select'a не надо: open(), tcgetattr()/tcsetattr() - и дальше read()/write() ...

я подозреваю, что ТСу на самом деле нужно CreateFile()/SetCommState()/WriteFile()/ReadFile() :)

Может быть :)

Тогда - гулять, так гулять: boost:asio !

http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio.html

Без поллинга будет блокирующее чтение, что нафиг не нужно. Разве что отдельный поток открывать.

socat

Qt умеет в статическую линковку. Будет бинарник на пару-тройку десятков мегабайт, но один и без зависимостей. Под офтопик пользователи к такому привыкли, а под онтопик есть пакетные менеджеры и о зависимостях париться не нужно.

http://sigrok.org/wiki/Libserialport

QSerialPort из qt сыроват (последний раз когда смотрел не работали скорости больше 115200)

УМВР (использовал скорость 460800). Возможно, дело в аппаратуре. Многие китайские USB-UART конвертеры начинают глючить на больших скоростях, FTDI честно держит любые скорости (разумеется, это не единственный такой чип, но про другие у меня нет достоверных данных). Да, предопределённых констант скоростей в QSerialPort нет для скоростей больше 115200, однако ничто не мешает передать произвольное число методу setBaudRate.

И да, если прямо таки нужна непрерывная передача данных на больших скоростях, а не короткие посылки, то надо выносить QSerialPort в отдельный поток.

QSerialPort из qt сыроват (последний раз когда смотрел не работали скорости больше 115200)

Что? Опять и опять этот бред? Или местным лоровцам (анонимусам) - лишь бы что-то брякнуть и ладно? :)

то надо выносить QSerialPort в отдельный поток.

В Qt 5.5 это уже не обязательно... хотя - смотреть по обстакановке.

https://hackage.haskell.org/package/serialport

на пару-тройку десятков мегабайт, но один и без зависимостей

Да ты шо. ~50 метров было когда-то давно, сейчас нужно более 100.

сейчас нужно более 100.

вот только сегодня скомпелял phantomjs 2.0 - 54 Mb - и это вместе с WebKit'ом. Так что не надо ля-ля.

в MUMPS.

http://doc.qt.io/qt-5/qtserialport-index.html = адекватная/хорошая/безглючная, и в статике собрать можно если чо

безглючная

не подходит

для ТС: идеальный вариант — писать на стандартном Linux API

и в статике собрать можно если чо

спасибо, поржал

Qt умеет в статическую линковку.

я тут полгода назад создавал, как-то, тему про статическую линковку qt-программ. как раз для серийного порта с дуру с куте связался. в общем, всем ЛОР-ом без шаманских плясок так и не осилили.

всем ЛОР-ом без шаманских плясок так и не осилили.

Нашёл кого в пример приводить. Так сказать «кинул ПК в вольер к обезьянам, а они не поняли как им пользоваться — значит, не нужно».

адекватная/хорошая/безглючная либа для работы с com-портами?

В Гну/Линуксе такой либы не может быть просто потому, что сама архитектура неадекватна, в силу чего, в отличие от некоторых проприетарных аналогов этой ОС, Гну/Линукс не позволяет пользователям использовать все возможности, предоставляемые аппаратным обеспечением вычислительной системы.

что сама архитектура неадекватна,

ну неправда (специально в сорцы ядра глянул): http://lxr.free-electrons.com/source/drivers/tty/serial/serial_core.c#L1630

там все зависит от флага «init_hw», который равен нулю при вызове uart_open().. так что ничего там (никакие RTS/DTR) не инициализируются, если не ошибаюсть

они (RTS/DTR) инициализируются только самим драйвером при рестарте системы / подгрузке драйвера, но ни при вызове open() ;)

они (RTS/DTR) инициализируются только самим драйвером при рестарте системы / подгрузке драйвера, но ни при вызове open() ;)

Бабушке своей расскажи. Вот cvv по ссылке описывает совершенно противоположное поведение, да и я лично, что уж там греха таить, тоже пытался как-то раз от нечего делать победить эту фигню. Поэтому я тебе не верю и считают тебя ламером. Тем более, что только абсолютно тупой ламер мог бы посчитать некривым поведением неконтролируемое подёргивание RTS-ом при рестарте системы / подгрузке драйвера как ты пишешь.

Блабла.

Исходный код не врет: http://lxr.free-electrons.com/source/drivers/tty/serial/serial_core.c#L1205

И я даже погорячился. В реале оно вообще ничего не дергает, а RTS/DTR устанавливает только при вызове ioctl с флагами TIOCSSERIAL или TIOCSERCONFIG.

Поэтому я тебе не верю и считают тебя ламером

Иди ка ты в дучко, «друг» сердешный.

Qt5, QtSerialPort

Но это если оправдано будет применение такого жирного фреймворка.

Эта тема что ли? Qt 5.3 уменьшить размер бинарника консольного приложения тебе там намекнули на upx и strip (ты, к слову, даже не знал, что такое strip). Уж больно много ты хочешь: кросс-платформенного решения, которое работало бы на всех доступных платформах и весило всего несколько килобайт. Некоторые, вон JDK с собой тянут и не стесняются, а тут надо же, целых 6MB.

cvv по приведённой ссылке вполне доступно разъяснил почему происходит не так как ты думаешь. Хотя это, по всей видимости, твой нормальный стиль общения - вместо работающего пруфа бегать и вопить по всему ЛОРу: "упорот здесь совсем не Я", "опыт работы с железками и выполнения проектов» 10 лет, устроит". Сынок, если бы ты попытался проверить свои заблуждения, написав например какой-нибудь простенький код, открывающий последовательное устройство для чтения и записи не дёргая RTS, то у тебя хотя бы был бы шанс не позориться тут с такими заявлениями, к тому же тыкая наобум в произвольные места файла serial_core.c

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

вместо работающего пруфа бегать и вопить по всему ЛОРу

Ай молодца, умеешь-таки серфить - проффессионал!!! Только все - мимо и сходи уже куда я предложил выше.

Сынок

Анонимусы - они такие, да (грустно)..

к тому же тыкая наобум в произвольные места файла serial_core.c

Ты же умеешь серфить (мои же мессаги нашел, троллить не влом было?)? А вот, пробежаться по тем вызовам в serial_core.c и посмотреть что и где дергается - не судьба?

Я уверен, не всё потеряно и у тебя ещё есть шанс научиться работать с ком-портом.

Угу, как скажешь...

Ты же умеешь серфить (мои же мессаги нашел, троллить не влом было?)? А вот, пробежаться по тем вызовам в serial_core.c и посмотреть что и где дергается - не судьба?

Просто пойди в serial_core.c сам, найди там строчки, о которых пишет cvv в треде, на который я ссылался и прочитай комментарии к функции, в которой эти строчки нашёл :)

Ну и работающий минимальный код, не дёргающий RTS при открытии порта попробуй написать, LoL )))

Иди ка ты в дучко

Надо же, оказывается такое слово существует! Меня поражает богатство вашего лексикона.

неконтролируемое подёргивание RTS-ом при рестарте системы / подгрузке драйвера

специально проверил

static int uart_port_startup(struct tty_struct *tty, struct uart_state *state,
		int init_hw)
{
	struct uart_port *uport = state->uart_port;
	struct tty_port *port = &state->port;
	unsigned long page;
	int retval = 0;

>>>>>>>	printk("%s %s ENTER\n", tty->name, __func__); [/b]

	if (uport->type == PORT_UNKNOWN)
		return 1;

	/*
	 * Initialise and allocate the transmit and temporary
	 * buffer.
	 */
	if (!state->xmit.buf) {
		/* This is protected by the per port mutex */
		page = get_zeroed_page(GFP_KERNEL);
		if (!page)
			return -ENOMEM;

		state->xmit.buf = (unsigned char *) page;
		uart_circ_clear(&state->xmit);
	}

	retval = uport->ops->startup(uport);
	if (retval == 0) {
		if (uart_console(uport) && uport->cons->cflag) {
			tty->termios.c_cflag = uport->cons->cflag;
			uport->cons->cflag = 0;
		}
		/*
		 * Initialise the hardware port settings.
		 */
		uart_change_speed(tty, state, NULL);

		if (init_hw) {
			/*
			 * Setup the RTS and DTR signals once the
			 * port is open and ready to respond.
			 */
			if (tty->termios.c_cflag & CBAUD) {
				uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
>>>>>>>				printk("%s %s  SET TIOCM_RTS | TIOCM_DTR\n", tty->name, __func__); [/b]
			}
		}

в общем ты бредишь

# dmesg | grep uart_port_startup
ttymxc0 uart_port_startup ENTER
# tty
/dev/ttymxc0
# uname -r
3.14.28

Для чистоты эксперимента проверил на втором уарте - на нем нет консоли

# echo «hello LOR» > /dev/ttymxc1 ttymxc1 uart_port_startup ENTER # dmesg | grep uart_port_startup ttymxc0 uart_port_startup ENTER ttymxc1 uart_port_startup ENTER

функция

uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);

как видишь ни разу не была вызвана