GK
Просто все данные куда-то считывать, а потом уже отдельным потоком из разбирать
Size: a a a
2021 February 25
A
Может, есть смысл делать пост-обработку?
так она присутствует, но простенькая: сверяется первый и последний байты (ключи)
GK
так она присутствует, но простенькая: сверяется первый и последний байты (ключи)
Я имею в виду, не завязываться вообще на компорт и его прерывания
GK
Пусть себе идут данные колбасой, а в отдельном потоке уже читать их и ключи проверять
A
Я имею в виду, не завязываться вообще на компорт и его прерывания
хм.
сложна.
идея здравая, если осилю то почему бы и да
сложна.
идея здравая, если осилю то почему бы и да
h
RS
А лучше по размеру буфера, не больше
A
hardegor
а почему 128? сделай 1024
мне так много не нужно. мне всего 15 интов и 15 флоатов нужно передавать. важно успеть их обрабатывать не реже , чем каждые 10мс
A
как бы можно и мильён байтов передавать, но кампуктер по моему и так сильно напрягается от этого кьюта - не успевает вовремя получить данные.
а скорость юарта тоже сильно задирать не хочется - пол мб по моему и так много для китайского свистка и одного проводка пол метрового
а скорость юарта тоже сильно задирать не хочется - пол мб по моему и так много для китайского свистка и одного проводка пол метрового
TK
Можно за раз несколько пачек по 128 пересылать, а на приёмной стороне уже разбирать
A
нужно не за раз.
период дискретности системы 8-10 мс. мне нужно с этой системы снять данный на ходу, на каждом шаге регулирования одни и те же параметры.
период дискретности системы 8-10 мс. мне нужно с этой системы снять данный на ходу, на каждом шаге регулирования одни и те же параметры.
A
можно конечно буфер в мк реализовать и передавать огромную пачку раз в N секунд например, но хотелось бы отрисовывать всё на ходу.
TK
Если такие периоды то надо по возможности все реакции переместить в эмбеддед, а в пк оставить медленное
A
Если такие периоды то надо по возможности все реакции переместить в эмбеддед, а в пк оставить медленное
согласен. теперь и сам это понял. раньше просто не сталкивался с такими мелкими периодами, потому и решил писать тупо в лоб.
VK
как сделано сейчас:
по сигналу readyRead останавливаю таймер, проверяю сколько байт пришло (available) , если их 128 то получаю и обрабатываю. после обработки запускаю таймер.
если их не 128, то запускаю таймер.
по прерыванию таймера чищу буфер ком порта (read all) и запускаю таймер снова
по сигналу readyRead останавливаю таймер, проверяю сколько байт пришло (available) , если их 128 то получаю и обрабатываю. после обработки запускаю таймер.
если их не 128, то запускаю таймер.
по прерыванию таймера чищу буфер ком порта (read all) и запускаю таймер снова
Забирайте данные всегда по сигналу, таймауты в десктопе это моветон отчасти.
VK
Собирать в Лок фри очередь все и из нее в отдельном потоке выбирать на обработку данные
VK
std:: atomic_bool посмотреть например зачем может быть использован тут
VK
Тем более что в кьют очень приятная многопоточность
A
лол, короче нашел относительно рабочий костыль:
в диспетчере повысить приоритет процесса до "реального времени" 😆😆👍
ошибки случаются, но крайне редко
в диспетчере повысить приоритет процесса до "реального времени" 😆😆👍
ошибки случаются, но крайне редко
A
Тем более что в кьют очень приятная многопоточность
блин, звучит это всё круто, но я не дорос ни до ооп ни до кьюта, боюсь если счас начну вникать в глубины, то убью кучу времени.
обычно моих знаний более чем хватало на простые терминалки/контрол панели/плоттери и т.д. но не на таких частотах.
а счас понадобилось быстрый плоттер набросать - вот и уперёрся в эти проблемы.
на данном этапе решу костылями, т.к. нужно быстро и "на один раз" , а в дальнейшем буду осваивать все эти потоки и т.д.
обычно моих знаний более чем хватало на простые терминалки/контрол панели/плоттери и т.д. но не на таких частотах.
а счас понадобилось быстрый плоттер набросать - вот и уперёрся в эти проблемы.
на данном этапе решу костылями, т.к. нужно быстро и "на один раз" , а в дальнейшем буду осваивать все эти потоки и т.д.