буфера COM порта

#1

В винде есть такая настройка порта

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

#2

WWolf писал(а): ↑
09 апр 2018, 14:40
В винде есть такая настройка порта

?
Вот тут посмотри.
...
И посмотри "Настройка minicom в Debian"

#3

x230, нее, тут только базовые настройки порта.
уже и через setserial пробовал менять тип uart - без толку...
при этом в мане есть инфа по flow_off, но отчего-то инвалид флаг при попытке применить...

#4

WWolf, Вот что откопал, может поможет
UPD: еще вот
Не знаю видел ты это или нет, но очень занятно почитать

#5

darkfenix, неее, не то

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

поясню суть более развёрнуто тогда

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

#6

WWolf, тут возможно проблема реализации этого дела в wine. Не особо оно предназначено для такого рода деятельности. Больше для простого запуска программ, а не для работы с железом. Так или писать загрузчик для линукса, или шить из винды(хоть из виртуалки, если шьет)

#7

WWolf писал(а): ↑
09 апр 2018, 18:51
если эту же программу запускаю под Wine, то тут чудеса чудесатые - ошибки на страницы сыпятся как из рога изобилия

Я вообще сильно удивлен, что оно в такой конфигурации хоть как-то работает. wine - ну совершенно не для этого.
Правильно вам говорят - ставьте полноценную виртуалку. У wine нет нормальной связи с железом, а com соединение очень к этому чувствительно, и даже не в буферах дело. Чтоб com-линк работал устойчиво, надо чтобы тайминги посылки/приема бит выдавались очень точно и в синхронизации с второй стороной. А через wine - точность будет плюс-минус лапоть с негарантированной задержкой (т.к. пользовательский процесс, а не уровень ядра). Отсюда и косяки.

#8

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

опять же смотря на виртуалку - она ж снимает как то эту буферизацию...

#9

WWolf писал(а): ↑
09 апр 2018, 22:26
slant, ну как бы и посложнее вещи в вайн крутятся, не говоря уже о компортах...

Вот тут я бы поспорил. Суть не в том, что нужна просто вычислительная мощность. Тут нужна точность оперирования железом привязанная к реальному времени. А это в линуксе может делать только процесс уровня ядра. wine же по определению в ядро не допускается, потому любые операции с железом выполняются через третьи руки. Получается как-то так: "Скажите Васе, чтобы он пнул Петю, чтобы Ваня таки ответил - сколько сейчас точного времени?"

Разумеется точность ответа в этом случае будет очень посредственная. А для ком-линка это критично.

WWolf писал(а): ↑
09 апр 2018, 22:26
опять же смотря на виртуалку - она ж снимает как то эту буферизацию...

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

#10

slant писал(а): ↑
09 апр 2018, 22:45
Тут нужна точность оперирования железом привязанная к реальному времени.

танки значит крутить на 60-115 фпс у нас хватает риалтайма, а плёвый 115200 не хватает

я ж не про нестабильный 921600 говорю...

хотя натолкнуло на мыслю поиграться с dll, завтра проверю...

#11

slant писал(а): ↑
09 апр 2018, 22:45
выполняются через третьи руки.

ну как бы не так
ln -s /dev/ttyS0 ~/,wine/dosdevices/com1
то есть линк у него прямой на порт, а вот где в вайне эту буферизацию отрубить надо подумать..
надеюсь хардовую ветку реестра, касающуюся фифо, они поддерживают

#12

WWolf писал(а): ↑
09 апр 2018, 22:55
танки значит крутить на 60-115 фпс у нас хватает риалтайма

А это совсем не задача реалтайма. А если бы и была таковой - ключевое здесь - 60-115. Т.е. особая точность как-бы и не нужна. Тут же задача, образно говоря, стоит так: выдерживать ровно 67.038 fps, с допустимым отклонением 0.05 туда-сюда. Причем учтите момент: у видеокарты свои мозги, память, и таймер реального времени для синхронизации. Образно говоря - процессор ей скармливает данные в те моменты когда хочет/может, а кадры (задачи реального времени) рендерятся независимо. У сом-порта - нифига подобного нету. Его процессор обслуживает. Т.е. в те момент, когда надо обслужить передачу или прием очередного бита - процессор должен быть свободен. Если это процесс уровня ядра - он может прерывание затребовать под это дело с высшим приоритетом. А у пользовательского процесса такой возможности нет - ядро системы само решает: дать ему процессорное время в данный такт, или пока обойдется. А ком-линк ждать не может.

WWolf писал(а): ↑
09 апр 2018, 22:58
ну как бы не так

Это оно и есть. Файл устройства - это интерфейс вида "Пните Петю" ("Вася" - сам транслятор api wine). Если вы от имени обычного юзера что-то хотите отправить/получить от /dev/ttyS0 - именно так примерно все и будет происходить. В порядке очереди приоритетов, в моменты, когда ресурсы доступны этому процессу - а моменты назначаются ядром.

WWolf писал(а): ↑
09 апр 2018, 22:58
надеюсь хардовую ветку реестра, касающуюся фифо, они поддерживают

Разумеется нет. wine НЕ работает с железом напрямую. Т.е. сама ветка скорее всего есть полностью ради совместимости, но реально она мало на что влияет.

#13

Ну что-то уже совсем из области 8086... У компорта, как и у большинства другой периферии уже давно собственные контроллеры с доступом dma и своими обработчиками прерываний не завязанными на проц как таковой... I/O apic уже давно может работать не дергая проц по каждому байту в порт...

#14

slant писал(а): ↑
10 апр 2018, 00:05
wine НЕ работает с железом напрямую

Ну с таким подходом ничто кроме ядра не работает напрямую

И то с оговорками ;)

#15

WWolf писал(а): ↑
10 апр 2018, 00:21
Ну с таким подходом ничто кроме ядра не работает напрямую

Вы не поверите...

WWolf писал(а): ↑
10 апр 2018, 00:16
У компорта, как и у большинства другой периферии уже давно собственные контроллеры с доступом dma и своими обработчиками прерываний не завязанными на проц как таковой...

... и все это богатство доступно только компонентам системы, которые напрямую с железом работают. Т.е. драйверам и процессам уровня ядра. Но не пользовательскому уровню, на котором wine живет.

#16

slant, конечно не поверю, потому как прямую запись в адреса портов com и lpt никто не закрывал... Как и в новые EC ;-)

#17

Короче заканчиваем меряться знанием железа и доступом к нему... Появилось 3 идеи, две из которым банальные... Завтра проверю и если выйдет, то отпишусь...

#18

WWolf писал(а): ↑
10 апр 2018, 00:49
Завтра проверю и если выйдет, то отпишусь

Ждем новостей

#19

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

прямая запись в BASEPORT+2 нуля для отключения фифо тоже не прокатывает, так как видимо при переоткрытии порта он опять в дефолтовое значение ставится...

короче переписывать надо, но загадка почему на 2,5Кб файле всё прокатывает, а на 20Кб затык прям с порога для меня открыт...

#20

WWolf писал(а): ↑
10 апр 2018, 12:30
но загадка почему на 2,5Кб файле всё прокатывает, а на 20Кб затык прям с порога

Одним словом wine

Кто сейчас на конференции