Определился с пресетами - будут сохраняться (и восстанавливаться при вызове пресета) частота RX, мода, sideband, настройки фильтра. На каждый диапазон (включая "дикую зону" Gen) по 4 ячейки пресетов. Больше половины кода уже написал и протестировал. Я таки переплюнул "Тюльпан" )).
Окончательно убедился, что компилятор в Eclipse частенько мухлюет с конструкцией switсh(). Раньше списывал на свою тупость и, тяжко вздыхая, переписывал на громоздкое if()/else if()... А вот сегодня конкретно поймал негодяя за руку. Если кто балуется с исходным кодом прошивки, мотайте на ус )).
Последний раз редактировалось satory; 02.04.2020 в 03:28.
Глюк не регулярный, закономерностей еще не выявил. Куча переключателей работают как часы, а иной раз то case пропускает, совсем игнорирует, то при выполнении условия срабатывает следующий по порядку case, что ни в какие ворота не лезет. В одном случае switch не работал вообще, не срабатывало ни одно условие. Сегодня же поймал баг в переключателе, который торчит в исходниках со времен царя Гороха. Я добавил в переключателе, выдающем на гора строку-название моды, лишь присваивание [txt = "LSB";] для SSB с нижней полосой. И вот этот, пустой ранее, case не срабатывает. Контролька показала, что на вход DEMOD_LSB исправно подается. Потом пошли чудеса. В порядке бреда поменял местами case's LSB и USB - и нарвался на перескок, срабатывание последующего case CW. Вывод - этот case (LSB) "больной". Он торчит по порядку до ключа "USB". В базовой прошивке для обоих sideband выдается "SSB", т.е. прыжок имеет место быть, и, судя по тому, что после [case DEMOD_LSB:] нет оператора [txt = "SSB";], тот, кто писал код, тоже столкнулся с этим глюком, но оставил все как есть, типа так и надо. Пока поставил после переключателя костыль. Вечером проверю, поможет ли перекомпиляция библиотек. Но чуйка подсказывает, что не поможет.
Последний раз редактировалось satory; 02.04.2020 в 09:38.
Можно ссылку на место в вашем исходнике? У меня компилер как-то абсолютно предсказуемо работает...
Привожу для текущей прошивки UHSDR 2.11.79 (я сейчас на работе), исходники можно качнуть на гитхабе, https://github.com/df8oe/UHSDR. Речь шла о функции UiDriver_DisplayModu lationType(), HSDR-active-devel\mchf-eclipse\drivers\ui\u i_driver.c, строка 4489.
На самом деле глюк, о котором знаешь, и который можно обойти, сильно не напрягает. Просто вводя новый switch() в код, нужно не спеша протестировать его работу, и если глючит, переписать на if()... Я никуда не тороплюсь, спешка - верная дорожка к трудно вылавливаемым косякам в коде.
Последний раз редактировалось satory; 02.04.2020 в 17:55.
Пока шел с работы домой, сообразил, что надо в проблемном case поставить break. И заработало, как надо. Но. Глюк все равно налицо - последующие case должны таки делать проверку на соответствие условию. Или это зависит от конкретной реализации языка, то бишь компилятора?
Закончил с пресетами. Наш "малыш" становится совсем взрослым )). Но работы над прошивкой еще много. Если на работе таки выгонят в карантин, работа над кодом значительно ускорится.
Спасибо от UR7FM
Спасибо Тюльпану, нашел аудиокодек CS4272 с заявленным ДД АЦП 114 дБ. Дороговат, но оно того стоит. Еще поборемся с KX3 )). Победить, конечно, не получится, но это будет уже совсем другая весовая категория трансивера. Если удастся вытянуть 96-98 дБ по забитию хотя бы при разносе 20 кГц (без преампа), я буду молодец (больше буду вытягивать уже в mcHF-Axis в формате DDC/DAC). И еще реально замаячила панорама в 96 кГц. Это будет уже далеко не старая добрая монка )). Если STM32F4 не потянет, засобачу F7, хотя это тоже поднимет себестоимость. А кто сказал, что будет легко? Сразу настроение поднялось, еще раз спасибо Тюльпану!
Последний раз редактировалось satory; 03.04.2020 в 14:38.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)