задержка в Serial Port

Eddy_Em писал(а):Делаешь тупые блокирующие read что ли?

Ну типа того

readByte - я выше об этом писал

RT - "real time"
поллинг - polling - "опрос"
с "говнокодом" - соглашусь - это мой первый высоко-уровневый код
больше нихера не понял

Eddy_Em писал(а):

Тогда зачем вообще взялся что-то программировать?

Захотелось

А есть пример ПРАВИЛЬНОГО_КОДА ? - посмотреть как должно быть...

Последний раз редактировалось uwrtey Вс мар 06, 2022 22:01:57, всего редактировалось 1 раз.

Eddy_Em перфекционист и грубиян. Но в данном случае отбрось его наезд и разберись с тем, что он тебе сказал. Уверяю, после этого СОМ-порт у тебя заработает так, как тебе нужно. Ибо тут я согласен с ним.

uwrtey писал(а):Но программа рассчитана на использование на современном железе.
На каком нибудь микрокомпьютере.

Микрокомп это типа малина или банан?
Не тянут они на современное железо, но по производительности ни по другим параметрам.

uwrtey писал(а):Да я в курсе, но видел собственными глазами как некоторая периферия работает в реальном времени. Джойстики например.

Вы напрямую работаете с джойстиком или через систему? Система работает с ним из ядра где доступны прерывания, DMA и др. средства позволяющие обойти ограничения ОС не реального времени.

uwrtey писал(а):класс SerialPort относится к WinAPI, на сколько я знаю...

Он относится к .NET, а не WinAPI. Как в .NET реализовано неизвестно. Кроме того неизвестно какие особенности добавляет игровой движок. Уже просто столько времени что могли написать на другом ЯП dll работающую с портом и подключить в проекту. Возможно это полностью решило бы проблему.

uwrtey писал(а):2) Юнити выбрал потому как для ПК ни разу не прогал ( до этого AVR на асме ) а тут нужно стало визуализировать входящие данные.

В любом приличном ЯП можно найти графическую библиотеку (порой их несколько использующих GDI, GDI+, DX, OpenGL и др.). Зачем для этих целей нужен игровой 3D движок непонятно.

uwrtey писал(а):Хуже всего, что планировал запустить софтину на андроиде

На Java пишите под андроид.

uwrtey писал(а):Где я выставляю задержку????

Какой размер буфера приема и передачи и какие тайминги порта.
Как осуществляется прием и передача?

uwrtey писал(а):А есть пример ПРАВИЛЬНОГО_КОДА ? - посмотреть как должно быть...

Примеры есть, но не для игрового движка. Мало кто использует игровой 3D движок для работы с COM портом. Это все равно что на самолете летать в булочную находящуюся в соседнем квартале.

tonyk писал(а):

Eddy_Em перфекционист и грубиян.
Но в данном случае отбрось его наезд и разберись с тем, что он тебе сказал.
Уверяю, после этого СОМ-порт у тебя заработает так, как тебе нужно.
Ибо тут я согласен с ним.

Да, сижу вот разбираюсь..

Мурик писал(а):икрокомп это типа малина или банан?

Ни как нет. Малина не потянет... Я выше примеры привел - под спойлером.

Мурик писал(а):Система работает с ним из ядра где доступны прерывания, DMA и др.

Ясно..

Мурик писал(а):Он относится к .NET, а не WinAPI

Вы правы! Чёт затупил...

Мурик писал(а):Уже просто столько времени что могли написать на другом ЯП dll работающую с портом и подключить в проекту. Возможно это полностью решило бы проблему.

Тут я еще не понимаю ничего..

Мурик писал(а):Зачем для этих целей нужен игровой 3D движок непонятно

Ну я выше объяснил почему выбор пал на юнити... От незнания..

Мурик писал(а):На Java пишите под андроид.

Ну да, андроид студио.. Начинал было изучать.. Но так лень переделывать то, что уже сделано в юнити... Эмоционально сложно.. Если бы новый проект, то другое дело....

Мурик писал(а):Какой размер буфера приема и передачи и какие тайминги порта.
Как осуществляется прием и передача?

Все просто.
С микроконтроллера сыпется поток на скорости 57600 бод.
Поток представляет из себя пакеты, которые можно разделить по заголовочному байту.
Пакеты разного размера ( по второму заголовочному байту определяю что за пакет и сколько байт он содержит )
Пакеты оканчиваются контрольной суммой...
Перенос строки и возврат каретки CR+LF ( 0x0D и 0x0A ) отсутсвуют.
В принципе могу их допилить в свой поток, но мне бы не хотелось этого делать...

В коде C# я использую функцию ReadByte - то есть считываю по одному байту.
И прям по ходу приема определяю заголовочный байт.
Собираю пакет, проверяю контрольную сумму и отрисовываю то, что принял.
Пакеты прилетают разные ( сейчас их три, затем будет больше - это информация с датчиков )

Чтобы буфер не подвисал регулярно его чищу, размер его я не устанавливал.
Какой установлен по умолчанию тот и используется.
Буфер в драйвере TTL конвертера установлен 4069, но даже если его уменьшить до минимума - программа работает без изменений.

Мурик писал(а):Это все равно что на самолете летать в булочную находящуюся в соседнем квартале

Добавлено after 18 minutes 55 seconds:

Eddy_Em писал(а):Если так критично, используй select вместо poll: там можно микросекундами оперировать.

Ктонибудь может по этому хоть что то подсказать?

****

Вот тут еще нашел пример https://medium.com/@c824751/unity-ardui ... 40247e5d36
Пытаюсь его реализовать.
Остановите пожалуйста меня сразу, если это бессмысленно

uwrtey, Л - Lazarus))
а вообще стоило бы код показать
поллинг - опрос буфера по таймеру а не по прерыванию - не самая лучшая в плане стабильности техника

зы подкинь для теста какой нибудь терминал к порту

uwrtey писал(а):Малина не потянет

У меня четвертая малина много чего тянет в том числе примеры с 3D. 60 FPS без тормозов и подвисаний. Не думаю что перечисленные вами микрокомпы сильно мощнее, а стоят дороже.

uwrtey писал(а):Все просто. С микроконтроллера сыпется поток на скорости 57600 бод.

Я не об этом спрашивал. При открытии COM порта какие вы задали размеры буфера приема и передачи, а также какие тайминги порта?

uwrtey писал(а):В коде C# я использую функцию ReadByte - то есть считываю по одному байту.

Почему побайтно, а не все принятые данные сразу?
У порта есть промежуточный буфер (про который писал выше). В него помещаются данные принятые, но еще не прочитанные приложением. Если вовремя не считывать данные, буфер переполнится и произойдет потеря данных.
Читайте сразу все что есть в буфере, а после анализируйте.

uwrtey писал(а):Чтобы буфер не подвисал регулярно его чищу

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

uwrtey писал(а):Вот тут еще нашел пример

Китайский хорошо знаете? :)))

В коде создается поток (параллельный поток, кто не понял) и в нем непрерывно опрашивается порт на наличие новых данных. Если пришли, считываются и отправляются в консоль. Но такой метод загрузит ядро процессора на 100%. :dont_know:

nds писал(а):Л - Lazarus))

А может лыжи или ложка? :)))

nds писал(а):поллинг - опрос буфера по таймеру а не по прерыванию - не самая лучшая в плане стабильности техника

Ну почему же? Если обеспечить наличие промежуточного буфера с большим объемом чем может поступить данных между срабатываниями таймера, то даст высокую гарантию стабильной работы.

Простой пример чтения из порта с использованием select. Могу еще пример с poll привести, но его таки лучше для сокетов использовать.
Про чтение по прерыванию - это, конечно, хорошо, но работает лишь с аппаратными USART, а много у вас аппаратных портов используется? Если же USB, то только поллинг.

Не, ну можно, конечно, свой особый модуль ядра с огромным буфером написать, но нафига? Ведь в user space намного удобней работать, чем в kernel space!

Мурик писал(а):При открытии COM порта какие вы задали размеры буфера приема и передачи, а также какие тайминги порта?

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

Мурик писал(а):Почему побайтно, а не все принятые данные сразу?

ну говорю же либа в юнити - кастрат это раз.
А пример, который я юзал, подразумевает наличие CR+LF, коих у меня в потоке нет.
Вот и решил такую конструкцию соорудить...

Мурик писал(а):Китайский хорошо знаете?

есть же переводчик.
Да я знаю, что это для создания отдельного потока.
про загрузку ЦП не знал - спасибо

Мурик писал(а):Ну почему же? Если обеспечить наличие промежуточного буфера с большим объемом чем может поступить данных между срабатываниями таймера, то даст высокую гарантию стабильной работы.

Чувствую себя своей женой в разговоре с со мной :)))

))

Однако спасибо...

Eddy_Em писал(а):Простой пример чтения из порта с использованием select. Могу еще пример с poll привести, но его таки лучше для сокетов использовать.

Спасибо, гляну

Eddy_Em писал(а):Про чтение по прерыванию - это, конечно, хорошо, но работает лишь с аппаратными USART, а много у вас аппаратных портов используется? Если же USB, то только поллинг.

Да, будет через USB. Аппаратный на микрокомпах не выведен вроде...

ПС: глянул код автора, который юзаю как пример работы, а он в этом году изменнился.
Теперь он юзает многопоточность.
Попробовал заюзать его код - пока не получилось..
https://github.com/dyadica ( тут уже новый код )

Добавлено after 4 hours 43 minutes 58 seconds: Пишу с работы. Данных под рукой не имею.

22.02.22: Добавлены опции чтения данных (ReadLine и ReadTo)

"ReadTo" будет как раз кстати.
можно избавится от побайтного чтения и читать целиком строку от заголовка одного пакета, до заголовка следующего.

"readLine" до какого значения опредеояет строку?
до Флага переноса строки ( cr или lf или оба вместе )

по моему readLine и readString были реализованы и в прошлый раз.

nds писал(а):

uwrtey, Л - Lazarus))
а вообще стоило бы код показать
поллинг - опрос буфера по таймеру а не по прерыванию - не самая лучшая в плане стабильности техника

зы подкинь для теста какой нибудь терминал к порту

я бы вместо лазаруса порекомендовал бы Тифон...

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

это Вы про свою терминалку?

uwrtey писал(а):можно избавится от побайтного чтения и читать целиком строку от заголовка одного пакета, до заголовка следующего.

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

uwrtey писал(а):"readLine" до какого значения опредеояет строку?

У автора спрашивайте. Ищите документацию. Кто же знает как это сделали в игровом движке.
По идее должно читать всю строку. Но как функция себя ведет если принята строка не целиком (без CR+LF) неизвестно. Для этого должна быть документация в которой написано что и как работает.

uwrtey писал(а):

это Вы про свою терминалку?

угу

Мурик писал(а):Я не об этом спрашивал. При открытии COM порта какие вы задали размеры буфера приема и передачи, а также какие тайминги порта?

в панели "размер" отображается как "2"

size.jpg: (18.32 KiB) Скачиваний: 86

Это вероятно 2 порта (COM1 и COM5), а не размер буфера.

uwrtey писал(а):ПС: глянул код автора, который юзаю как пример работы, а он в этом году изменнился.
Теперь он юзает многопоточность.
Попробовал заюзать его код - пока не получилось..
https://github.com/dyadica ( тут уже новый код )

разобрался, запустил, задержка минимальная - меня устраивает.
Всем спасибо!

ПС:
1) не пришлось переделывать побайтное чтение - код оставил как есть, что меня радует..
2) Теперь даже буфер не приходится очищать - и так работает.

Новая проблема.
Не буду новую тему сосздавать - озвучу здесь же.
Сделал многопоточность.
Все заработало как надо. ( в винде работает как надо, а в Юнити не все шкалы работают/ либо работают с большой задержкой )
Работает несколько минут ( минуты 3, если от имени Админа то может и 20 проработать )
А потом картинка ( шкалы нарисованы ) замирает, хотя буквенно-числовые значения продолжают отображать действительные значения.
Куда копать? Ума не приложу..
Поди конфликт какой то в многопоточности?

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

Думаю конфликт какой то возникает?
Попинайте плиз в нужном направлении..

uwrtey писал(а):Куда копать?

В сторону отладчика. Надеюсь он есть для игрового движка.

uwrtey писал(а):Поди конфликт какой то в многопоточности?

Мьютексы, семофоры используйте? Гонки нет? https://ru.wikipedia.org/wiki/Состояние_гонки
Тоже касается блокировки. https://ru.wikipedia.org/wiki/Взаимная_блокировка

uwrtey писал(а):Попинайте плиз в нужном направлении

Правильно проектируйте многопоточноную программу. Доступ к общим данным должен быть в один и тот же момент только у одного потока.

Мурик писал(а):В сторону отладчика. Надеюсь он есть для игрового движка.

Наверняка должен быть.
Говорю же впервые пишу под винду

да к тому же многопоточное...
Почитал по ссылкам - круто.
Щас поразбираюсь что к чему...
Но сдается мне в Юнити это будет сложно сделать...

Автор "рыбы" скрипта пишет ( в 2013 году)

Кроме того, в дополнение к включению триггеров событий я также удалил все следы метода потокового обновления.
Это серьезное изменение сценария, отражающее способ работы Unity.
На самом деле, поскольку Unity API не является потокобезопасным, я пришел к выводу, что нет смысла использовать многопоточный подход.

А теперь ( в 2022 ) делает многопоточный скрипт :dont_know:

ARV писал(а):

uwrtey писал(а):

это Вы про свою терминалку?

угу

тут ? https://cloud.mail.ru/public/4tPD/uyfBDkHnH/
дистриб ?

uwrtey писал(а):тут ?

угу. справку читайте, а то в шоке будете :)))

задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port

Re: задержка в Serial Port