nice_vladi

ОФФТОП. Спасибо за изложение. Что-то встало на свое место в голове. Я просто мимо крокодил)

SetSetText() - очепятка) Отображаемые данные и так меняются примерно раз в секунду. Так что разницы нет( И, на мой взгляд, проще со строго дискретным промежутком времени проверять флаги и по их состоянию обновлять ГУЙ. 100% новая картинка не полностью будет обновлять старую (разная длина выводимых сообщений). Наверное, можно добить пробелами остающееся место, но это мне совсем не нравится, лучше уж дергать одно узкое поле в начале. Штудировал интернеты и книжки различные - все равно не могу понять, какого черта мерцает только первое обновляемое поле?! :smile3046:

У меня реализовано примерно так же. Для каждой вкладки (Tab) создан свой CDialog. И переключение производится ручками - show/hide. Единственное - я не создавал отдельный класс для вкладок. И вкладывая CTabCtrl в один из созданных диалогов наблюдал проблему, описанную в пером посте. Обязательно попробую ваш вариант, может быть, это поможет.

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

Все привет! Очередной вопрос, связанный с Visual Studio и языком C++, в частности. На форме имеется статусбар. В нем несколько полей, которые обновляются в одном таймере. Конструкция типа: void CMain::OnTimer(UINT nIDEvent) { Upd0(var0); Upd1(var1); Upd2(var2); } Где каждая функция обновления что-то вроде: void CMain::Upd0(int var) { CString _str; _str.Format(L"%d", var); status_bar.SetIcon(1, m_ico_ena); status_bar.SetSetText(_str, 1, NULL); } Т.е. обновляется текст и иконка. При обновлении ПЕРВОГО поля (в функции Upd0) на форме это поле мерцает. При обновлении последующих полей мерцания нет. Хочется, что бы мерцания не было и в первом поле. Не могу понять, как это связано. Использую MFC. Спасибо. :smile3046:

Вообще, идея в том, что бы ГЛАВНОМУ автомату никогда не хотелось самому подергать SPI. Он все делает через стоящие ниже по иерархии автоматы. Т.е. каждый автомат выполняет четко свою задачу и не лезет на другие уровни иерархии. Главный - забирает посылку (запрашивает данные, формирует суперкадр). Средний - формирует кадры (откусывает по кадру от суперкадра, сформированного главным). Нижний - рабоает на уровне бит (роняет CS, выставляет клок, данные). При этом каждый из них полностью завершен и очень глуп: Нижний просто передает 1 кадр по SPI. Он не знает, сколько кадров всего, как часто передаются и т.д. Просто получает старт-передает-отдает сигнал завершения передачи. Средний просто управляет первым. Он не знает размер посылки, умеет только забирать кусок и скармливать нижнему. Главный формирует посылку и рулит средним. А если главный автомат в обход среднего и нижнего захочет подергать SPI - это приведет к дикой путанице и усложнению. В идеале - растащить автоматы по разным модулям, что бы в одном модулей было не более 1 автомата. Пусть даже эти модули и будут мизерными по размеру. Взаимодействие можно организовать по флагам-состояниям автоматов. Допустим, главный щелкает из wait->start->wait_end. Здесь состояние start будет командой среднему начать обработку посылки.

Да ну нет же) все нормально завелось. Я думаю, есть возможность как-то более изящно отсчитывать промежутки времени. Т.к при реализации на счетчиках с большой разрядностью съедается много логики (несколько счётчиков+мультиплексирование результатов) Это немного не то. Повысится максимальная частота работы, но количество логики останется тем же (мб немного больше). Немного не понял, можно про захват состояния тамера подробнее? Я представлял себе так: событие А начинаем считать. Событие Б забрали результат, сбросили счётчик. Ну, что-то вроде этого.

Всем привет! Возник такой вопрос: Нужно отмерить промежуток времени от события А до события Б с большой точностью (допустим, с точностью 100 МГц-го клока). Время между событиями составляет 500 000 +- 10 000 тактов 100 МГц. Получается счетчик на 3 байта. Вроде не много, но если надо посчитать несколько таких отрезков времени независимо, да потом как-то обработать данные - выливается в кучу логики. Как можно уменьшить размеры счетчиков? Самое адекватное, что приходит в голову - это завести еще один счетчик, на низкой частоте, допустим, на 1 МГц. Этот счетчик будет отсчитывать основную длительность, и в конце, где примерно ожидается событие - включается первый, на 100 МГц-ах и досчитывает точное время до события. Потом результаты счетчиков суммируются. Но при таком решении все равно нужно тратить место на медленный счетчик, на суммирование и т.д. По моим соображениям выигрыша не будет, либо он будет настолько мал, что не стоит всех этих заморочек. Да и момент запуска/остановки медленного счетчика завязан на клок 1 МГц и даст огромную (по меркам 100 МГц) ошибку.

Оффтоп: Да, MFC. Вообще, мне больше Qt импонирует) Но досталась поддержка проекта, писанного не мной, писанного кривовато, и писанного в Visual Studio + MFC. Так что деваться некуда, приходится учиться. По делу: Кстати, все-таки выбросил Tab1 из вкладки Tab0 и добавил все вкладки из Tab1 в Tab0. Пояснение прикрепил в виде схемы (Вариант 2 - текущий вариант). Однако Вариант 1 мне нравится больше. Но в таком виде зависание программы, описанное в стартовом сообщении. Решения проблемы так и не нашлось. Буду очень благодарен тому, кто объяснит такое поведение программы :smile3046:

Всем привет! Делаю графическое приложение в Visual Studio 2013. Столкнулся со следующей проблемой: Имеется CTabCtrl (Tab0) в нем расположены три вкладки. В первой из этих вкладок вложен еще один CTabCtrl (Tab1). В остальных - элементы управления. В Tab1 имеются свои 3 вкладки, на которых расположены различные элементы управления, edit и т.д. При взаимодействии с любым из элементов в Tab1 (редактирование, просто клацанье мышкой, т.е. любое взаимодействие) и последующем смене фокуса окна программы (допустим, ЛКМ на рабочий стол) происходит зависание программы. При этом поднимается загрузка процессора, без отжирания памяти. Самым интересным мне показалось, что при взаимодействии с элементами в Tab1 и последующем переключении Tab0 а другую вкладку - все работает нормально. Спасибо! Upd0. Зависание происходит даже без выполнения каких-либо обработчиков элементов на вкладке (создал пустую вкладку, набросал случайных элементов. Даже DDX выбросил) Upd1. Примерно понял, в чем затык. Style вкладок контролбара Tab1 - Child. При смене на другой - зависания нет. Однако, при другом стиле, не происходит встраивания Tab1 в одну из вкладок Tab0, т.е. проблема все еще имеет место быть. Upd2. Сменил style вкладок child -> popup и принудительно указал предком Tab1. Корявое решение, при работе с этими вкладками постоянно теряется фокус окна. Ничего лучше не придумал. Проблема не решена, это временный костыль.

Спасибо. Хочется делать правильно. Отсюда новый вопрос: как сообщить оконному менеджеру о том, что это окно следует обрабатывать с прилипанием к краям (отдать ему эту работу)? И будет ли это платформозависимым?

Всем привет. Вопрос простой: как реализовать прилипание к краям экрана основного виджета (QMainWindow) в Qt Creator? Либо каким образом можно сделать прилипание? Может быть, главная форма не имеет такой возможности? Поиски в интернатах и книжках не привели к успеху((( Qt Creator 4.0.2 Windows 7

Почему так? Как было сказано выше, компаратору нет разницы, какие данные у него на входе. Нули-не нули, он все равно будет их сравнивать, так же, как и полноценные данные. Ну и с точки зрения наглядности - гораздо понятнее событие, которое происходит через Н тактов (запись cnt == N), чем событие, которое происходит, когда счетчик в 0( cnt == 0, а инициализация где-то в другой части модуля, например). Хотя тут уже вопрос привычки, я думаю.

А установка регистра счетчика в какую-то начальную величину не будет занимать логику? Т.е., получается, при счете до нуля мы тратим логику на инициализацию счетчика, а при счете до константы тратим логику на сравнение значения счетчика с константой, я правильно понимаю?

Добрый день! Интересно, почему часто применяется отсчет счетчиком до нуля и загрузка в него каких-то начальных значений. Почему просто не обнулять счетчик и не считать до требуемой величины? Например: reg [7:0] cnt; always@(posedge iclk) begin if (rst) cnt <= '0; else if (~&cnt) cnt <= cnt + 1'b1; end always_comb begin strb0 = cnt == 10; strb1 = cnt == 12; ... end Стробы strb0,1... можно использовать для переход МКС. Rst = strb0||strb1... ну или в состояниях МКС описать. На мой взгляд, гораздо логичнее выглядит. Отсчет от Н до нуля - это вопрос предпочтений? Или есть какое-то обоснование, почему так лучше?

Да, обеспечивается. Но при обращении "сверху вниз". Допустим, из основного окна интерфейса в дочерние, создаваемые в нем. Мне же нужно наоборот, ходить "снизу вверх". Допустим, из созданных вкладок интерфейса в их "создателя", основное окно. Имел опыт работы с Qt - там применялись сигнал-слоты. В Visual studio нашел подобное решение - это __event. Пользуюсь ими. Но в процессе поиска (до того, как обнаружил ивенты) пытался как-то по-другому достигнуть результата. Тут и начали возникать вопросы с указателями на функции.

Всем привет. Начал осваивать С++ и в один прекрасный момент подумал, что было бы не плохо вызывать функции по указателям на них. Никаких ивентов и тому подобных вещей. При инициализации передал указатель на функцию создаваемому классу - и пожалуйста, он ею щелкает, когда душе угодно. Допустим, что-то на GUI обновляет. НО! В какой-то момент я задумался о целесообразности применения, да и вообще корректности использования. Приведу пример: есть такая вещь, как goto: Но ее применять не рекомендуется, потому-что - потому-что. Есть ли какие-то подобные рекомендации по применению указателей на функции? Ну и вообще, подводные камни, так называемые. Visual Studio 2013 Спасибо!

В очередной раз перезагружая компьютер решил написать сюда этот пост. Интересный баг - в окне отладки (Signaltap) при копировании сигналов перетягиванием (с зажатым ctrl) получаю зависание винды. После вышеописанных действий система ни на что не реагирует, вплоть до принудительной перезагрузки. Самое печальное, что такая ситуация возникает, когда хочешь выделить несколько сигналов в сигналтапе (зажимаешь ctrl + клики по сигналам). И иногда, случайно, сдвигаешь мышь - отпускаешь ЛКМ - перезагружаешь комп. :smile3046: Интересно, это имело место у кого-то еще, или что-то с моим квартусом? Система Windows 7, 64 bit.

День добрый! Сверху все верно написали) Либо assign, либо always - одно с другим не смешивается. Хотелось вставить пять копеек по поводу написания. Вообще не понимаю такие "однострочные" конструкции. Конечно, дело привычки, но assign selected_porog = mode_simple ? porog_simple : mode_manual ? {1'b0,external_porog,1'b0}: mode_range?porog_range:{DATA_WIDTH{1'b1}}; строка такого вида заставляет капать кровь из глаз... Я бы сделал подобным образом: always_comb begin if (mode_simple) selected_porog = porog_simple; else if (mode_manual) selected_porog = {1'b0,external_porog,1'b0}; else if (mode_range) selected_porog = porog_range; else selected_porog = '1; end Ну или как-то разложил на несколько строк вашу строку. Или добавил бы кучу скобочек, как минимум B)

В течении дня попробую обязательно. Спасибо! Да, я с каждым днем все больше и больше нюансов в использовании quartus'a замечаю. Что-то стараюсь записывать, что-то запоминать. Сейчас добрался до директив компилятора, осваиваю потихоньку)

А смысл? Все равно же регистры и веревки, которые хочешь посмотреть нужно объявлять портами и затем делать их виртуальными. Да, я знаю. Но дело в том, при добавлении через этот пресет, либо через "all entries" некоторые регистры не отображаются в окне сигналтапа. По-видимому, quartus их сокращает или сливает с другими. Я хочу как-то запретить ему это делать. Но директивы, о которых писал выше, не помогают. Возможно, я как-то не правильно их записываю в код. Например: reg [1:0] cnt/*keep synthesis*/; или reg [1:0] cnt(*noprune*); Или же нужно еще что-то в настройках quartus подкрутить. Это не слишком нужная и необходимая вещь. Можно и порты описывать. Но хочется красоты и изящества :yeah:

Вопрос такой: можно ли каким-то образом вытащить в отладку сигналы модулей, не объявляя их выходными портами? Директивы keep synthesis и noprune не помогают - сигналы в signaltap не отображаются. Сейчас, для того, что бы посмотреть, допустим, какой-то счетчик в своем модуле я объявляю этот регистр как выходной, описываю порт. Затем тяну его в signaltap. Но это как-то некрасиво и неудобно. Quartus 13-16, Verilog.

Боюсь показаться нубом, но термин "шумоподобный сигнал" не подходит? Т.е. сигнал с размазанным спектром, находящийся в одном уровне с шумами.

Итак, немного подновлю тему. Демаппер пытался собрать по образу и подобию, найденному в буржуйской статье и тому подобных: https://www.radioeng.cz/fulltexts/2014/14_01_0399_0404.pdf Собрал модель в матлабе, но попробовал реализовать - столкнулся с проблемой из первого поста + сожрало чересчур много ресурсов ПЛИС. Пришел к следующему решению (глупо, "в лоб"): На входе в модуль расчета метрик повернутое созвездие комплексным умножением доворачиваю на градус, соответствующий модуляции. Затем провожу расчет для обычного созвездия, на основе предварительно рассчитанных метрик, сложенных в память. По моим соображениям, такой вариант допустим: задержки квадратур уже скомпенсированы, и имеется просто созвездие, для которого нужно посчитать метрики LLR. Конечно, съедаются DSP ячейки, однако в остальном такой вариант гораздо менее требователен к ресурсам. Теперь будут попытки запустить всю эту систему и оценить выигрыш, который, возможно, получится при применении такого созвездия. Декодер, вроде бы, нормально завелся. Однако каких-то испытаний по помехоустойчивости еще не проводилось. Выигрыш по SNR будет сравниваться с обычным созвездием ну и, конечно, с волшебными 7 дБ, которые описаны в различных источниках.

Да я понимаю это) Просто таки дошли руки поставить Questy, давно хотел пощупать. В общем, мой последний пост можно считать подведением итогов всей темы.