Nikolay_Po (09.01.2019 00:00, просмотров: 372) ответил MBedder на Да нахер этот two-speed startup тебе (и другим, кстати) вообще всрался - по ресету/фузам стартуй с того, с чем будешь работать (XT_PLL16), в первых же строках кода переключай OSCCONbits.POST в ÷16, но не жди(!) OSCCONbits.LOCK -
Спасибо! Логично и практично! Разница лишь в несколько мА на PLL будет. Сам не догадался бы!
У этого контроллера, кстати, занятная эррата есть: предлагают в OscillatorFail trap поставить return после сброса бита OSCFAIL, если бит CF в OSCCON (настоящий сбой) не встал. Дескать, PLL lock иногда самопроизвольно падает и вылетает в OscillatorFail-ловушку, хотя сама ФАПЧ работает нормально.
-=-
Проблемы начались с того, что не получалось заставить контроллер просто работать на PLLx16. Перешёл на запуск с FRC, потом PLL x16 - полегчало. Добавил workaround. Возможно, при старте он просто всегда в hard fault по OscillatorFail уходил, пока ФАПЧ "колбасило". А там заглушка стояла, while(1);.
Не проверял, может, с вокэраундом и заработает PLLx16 сразу?
Жрёт всё равно много. Пока отлаживаем код, почти наверняка удастся ужаться на PLLx8, а то и на PLLx4. FIRdecimate() замечательная вещь! Рассчитывал на 50% загрузки камня фильтрацией, а после подгонки частоты выборки и прореживания под задачу, нагрузка упала до 4%, включая сбор данных АЦП. Посмотрим, сколько ресурсов потянет индусское приложение измерения отфильтрованного сигнала.