Версия для печати темы

Автор: MishaUA 30.9.2017, 20:11

Недавно создавал тему, в которой писал о подключении матричного индикатора.
Суть в том, что отрисовка должна происходить очень быстро, я ещё сделал в отдельном потоке (QThread в run), задержка там только одна на 50мкс, т.е., процесс потребляет довольно много процессорного времени, а конкретно - ~86% (проц 4 ядерный), это при QApplication, а с QCoreApplication было почему-то 100%, хоть в теории, QApplication потребляет больше ресурсов.
Отрисовка изначально происходит нормально, но периодически (раз в пару мин) экран начинает мерцать, при этом нагрузка на том ядре падает примерно до 40% и через 2-5 сек мерцать перестает и до >80% нагружается совершенно другое ядро. Походу, процесс каким-то образом перепрыгнул на другое ядро.
процесс запускаю как QThread::HighestPriority, а саму прогу с опцией nice --20 (хоть реально большой приоритет нужен не всей программе, а только одному процессу).
Так же, мерцать всегда начинает когда захожу по ssh и логинюсь.

Можно ли как-то сделать этот процесс со "сверхвысоким" приоритетом?
Спасибо!

Автор: Iron Bug 30.9.2017, 21:43

есть сильное ощущение, что ты там что-то принципиально не то делаешь. как ты умудрился выводом в матрицу загрузить 4 ядра проца на 1.6GHz? и чем выше приоритет твоего жручего процесса - тем больше будет тормозить графика, ясное дело. все жручие вычисления всегда делают в бэкграунде.

Автор: MishaUA 30.9.2017, 22:22

Так я и не говорил, что грузит все ядра, грузит только одно ядро, остальные почти не нагружены

Автор: Iron Bug 1.10.2017, 17:45

да даже одно ядро такой задачей загрузить - это надо как-то извратиться сильно.

Автор: MishaUA 2.10.2017, 10:07

При том, что в потоке постоянно крутится цикл с единственной задержкой в 50 микросекунд, это вполне нормально

Автор: Iron Bug 2.10.2017, 20:35

нет, постоянно крутящийся цикл с задержкой в 50 us - это ненормально. тем более, что не всякий таймер строго даёт те 50 us. и тем более, что с такой скоростью что-то перерисовывать однозначно не нужно: развёртка экрана реже в 400 раз делается.

Автор: MishaUA 4.10.2017, 15:58

Вся матрица разделена на 16 частей и включенной может быть только одна с его частей, для нормального отражения надо поочередно отображать эти части с большой скоростью, вот интервал между отражениями - 50мкс. Условно говоря, экран обновляется подлостью 1000/(0,5*16)=125 раз в секунду.

Автор: Iron Bug 4.10.2017, 21:08

Цитата(MishaUA @ 4.10.2017, 17:58)

Автор: MishaUA 5.10.2017, 11:31

даже при задержке 100, и 200 мкс матрица периодически начинает мерцать. Тут очень важно чтобы интервалы обновления были ровными. Если какой-то ряд пикселей горит дольше, то получается сильно заметное мерцание.

Автор: Алексей1153 6.10.2017, 9:12

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

всё дело в подходе

Автор: MishaUA 6.10.2017, 9:46

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

Автор: Iron Bug 6.10.2017, 20:44

то есть, у тебя нет GPU, а CPU выводит графику напрямую? как раньше в DOS? ну так тогда там ещё медленнее отрисовка происходит.

Автор: MishaUA 6.10.2017, 20:50

Да, так и есть, графику выводит CPU и потоку, который выводит графику, надо дать максимальный приоритет.

Автор: Iron Bug 6.10.2017, 23:02

да, но тогда все расчёты надо из этого потока убирать.

Автор: MishaUA 7.10.2017, 14:27

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

Автор: MishaUA 9.10.2017, 15:43

В общем, в процессе экспериментов оказалось, что мерцание проявляется из-за того, что задержка (usleep(50)) иногда выполняется дольше, чем нужно.

Автор: MishaUA 12.10.2017, 14:34

заменил usleep нопами, теперь работает как надо))).
Конечно, ядро загружено на 100%, но есть ещё 3.

Автор: Iron Bug 12.10.2017, 21:21

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

Автор: MishaUA 12.10.2017, 22:32

А как система может знать, как часто надо обновлять сегменты индикатора для нормальной отрисовки?

Автор: Алексей1153 13.10.2017, 9:12

MishaUA, рисуется кадр - столько времени, сколько он рисуется. Показывается. Рисуется второй кадр (первый кадр в это время висит на экране и не шевелится. Нарисовался второй - делаешь своп с первым . И так по кругу

Автор: MishaUA 13.10.2017, 11:43

Кадр не может полностью за раз отрисоваться, одновременно может отображаться только шестнадцатая часть. Для нормального отображения эти 16 частей надо быстро по очереди переключаться. По аналогии с обычным сегментным индикатором.

Автор: Алексей1153 14.10.2017, 7:56

MishaUA, значит, это недостаток железяки.


Нужно сделать возможность закачивать весь кадр в память железяки, а уж железяка пусть переключает кусками по 1/16 - она сможет это делать быстро

Автор: MishaUA 24.10.2017, 14:44

В таком случае надо было бы делать контроллер на каком-то микроконтроллере. Для единичной задачи это не рентабельно.