16+
Вторник
18 июня
Вход |Карта сайта |Upload |codebook | PARTS

 О смысле всего сущего 0xFF

 Средства и методы разработки

 Мобильная и беспроводная связь

 Блошиный рынок Объявления

caxapa

Микроконтроллеры ARM 

AVR PIC MSP PLD,FPGA,DSP 

Кибернетика Технологии 

Схемы, платы, компоненты 

Микроконтроллеры PIC

 
Новая темаПравила РегистрацияСтатистика Архив
Вернуться в конференциюТопик полностью
Nikolay_Po  (09.01.2019 00:00) , в ответ на Да нахер этот 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%, включая сбор данных АЦП. Посмотрим, сколько ресурсов потянет индусское приложение измерения отфильтрованного сигнала.
Главная | Карта сайта | О проекте | Проекты | Файлообменник | Регистрация | Вебмастер | RSS
Лето 7527 от сотворения мира. При использовании материалов сайта ссылка на caxapу обязательна.
MMI © MMXIX