ВходНаше всё Теги codebook PARTS Поиск Опросы Закон Вторник
29 сентября
/894606
Топик полностью
Nikolay_Po (09.01.2019 00:00, просмотров: 34) в ответ на Да нахер этот two-speed startup тебе (и другим, кстати) вообще всрался - по ресету/фузам стартуй с того, с чем будешь работать (XT_PLL16), в первых же строках кода переключай OSCCONbits.POST в ÷16, но не жди(!) OSCCONbits.LOCK - - автор: MBedder
Спасибо! Логично и практично! Разница лишь в несколько мА на 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%, включая сбор данных АЦП. Посмотрим, сколько ресурсов потянет индусское приложение измерения отфильтрованного сигнала.
Ответить
Ответы