Совместная работа ардуино и линукс?

А если именно не веб интерфейс?

Eddy_Em количество чозанафиг в секунду при попытке реализовать что-то в современном браузере (особенно с графикой и динамикой) стремится к известной константе 100500. У QT хоть результат предсказуемый и переносимый, тем более, что приложение сразу получается событийно-управляемым.

Dorsal: если не веб-интерфейс, то нужно готовиться к заполнению памяти тонной совершенно ненужных знаний. Ну и помучиться с совершенно идиотскими методиками рисования GUI (если будет выбран Qt или GTK). Можно motif или Tk использовать, тогда будет легче.

Армянское Радио: ну, не сказал бы. У меня только проблема была на бажной версии огнелиса, когда я пытался вместо ненужных кук использовать более приличный localstorage. Пришлось патчить жабкоскрипт: добавлять куки, если localstorage не может отработать.
В остальном все без проблем. И 3D-графику через webGL делал, и псевдо-3D через SVG, и просто менюшки-кнопочки, видео, графики и т.п.
К Qt я однозначно отношусь: лучше бы этой дряни вообще не было. Она - как ардуйня. Портит мозг.

Eddy_Em на сегодняшний момент, QT - лучшее что произошло с пользовательскими интерфейсами. Я видел MFC(святые макросы из преисподней!), VCL(бууууэээээ),
GTK( :-| ) , wxWidgets (чур меня, чур!), черт возьми, я писал когда-то на голых CommonControls. Когда в процессе писания под них у меня сами собой написались сигналы/слоты, я пришел к выводу, что думаю с Trolltech (тогда Qt владели они) в одном направлении.
На QT приложения получаются относительно лаконичными, а логика - прозрачной. Ну и не жрут память как некоторые браузеры.

Eddy_Em, Dorsal: вот кстати пример, если поменять QProcess на QSerialPort, будет консолька для ардуины: https://github.com/BG4444/PingerExample

Армянское Радио: QSerialPort - очень надежный способ себе ногу отстрелить. ЕМНИП, пару-тройку раз натыкался на ЛОРе на проблемы с этой дрянью у любителей культей.
Есть нормальный open/read/write. Зачем эти культеизвраты?

А еще у культей есть другой гигантский недостаток: эта дрянь только с С++ работает. А С++ в 99.9% - лютый оверхед. Лично у меня нет ни одной задачи, где этот ЯП понадобился бы!

Eddy_Em: ну на C++ всегда можно откатиться на "стиль C" в потребном месте. Или действительно изучить STL, чтобы знать, откуда какой костыль там произрастает.

Последний раз когда я грешил на QSerialPort, глюк прекрасно воспроизвелся на read, и вообще выяснилось, что QSerialPort не приделах, а пакеты ворует STM32F3, которая иногда не вызывает прерывание по окончанию транзакции в CDC.

Армянское Радио: Нет, потому как всякие культи и т.п. используют классы. Здесь C не пройдет.
Мне пару раз для использования готовых библиотек приходилось писать прослойку, предоставляющую сишные интерфейсы, т.к. авторы на кой-то черт запилили "железячную" библиотеку на С++! Благо, таких извращенцев немного.
Ну, а эти культевые обертки я считаю коровьим седлом, которое так и просит бритвы Оккама!
Пакеты, кстати, не ворует микроконтроллер (сам недавно на подобное грешил, а потом разобрался): если поток слишком шустрый, то просто буфер переполняется со всякими неприятными последствиями.
Да, USB-библиотека от STM (которая в состав SPL входит) - жутчайший быдлокод, из того, что я видел. Советую opencm3, если вы ее еще не используете.
А SPL надо выкинуть подальше.

Eddy_Em: там было очень странное явление, больше похожее как раз на опустошение буфера - при частых чтениях прерывание проглатывалось, при увеличении интервала (и соответственно, большем наполнении буфера) - все работало четко, и под оффтопиком, и под линуксом.

Стандартная библиотека STM подлежит тотальному списанию в быдлокод - меня их километры макросов, которые вызывают макросы, обращающиеся к макросам добили.

Армянское Радио: да я сам поначалу ею пользовался и удивлялся, чего это ее ругают. Пока не познакомился с этим быдлокодом поближе: то один косяк появился, то другой... Патчил-патчил, потом плюнул и стал пользоваться opencm3. Правда, проблему с USB еще не решил (хочу на STM32F407 наладить одновременную работу обоих интерфейсов — и FS, и HS).
Ну, а задачи, требующие максимального приближения к realtime, вообще никаких библиотек не допускают - только регистры.

Eddy_Em: ну у меня целью было выжать теоретический максимум в 128 тысяч байт в секунду из USB CDC. И оно таки заработало (и на офтопике, и на линуксе, и на ведроиде), чему я несказанно рад.

Армянское Радио: ну, я скорость не замерял, но терминал у меня всегда на 150кбит/с работает, проблем не видел. Да и что значит "теоретический максимум в 128 тысяч"? Если это FS, то максимум - мегабита полтора. А если это HS, то вообще чуть ли не тактовая частота!

Eddy_Em: Прерывание "начало фрейма" инициируется мастером на частоте 1кГц, фрейм по длине - 128 байт. Я так рассуждал.

Армянское Радио: Eddy_Em: ничего вы тут тред резвернули:) "128 тысяч байт в секунду", "полтора мегабита", автор вопроса 99% хотел просто у ардуинки ножками подергать:)