Gtlab Forum
Тематический => Негитарная электроника => Тема начата: OldMike от Апреля 30, 2014, 09:10:24 pm
-
Всем привет.
Столкнулся с траблом: мне желательно шить 16F876A внутрисхемно (задалбывает раз по 30 в день тягать проц из панельки в программатор и обратно... Программатор ProPIC2 самодельный (сразу спасибо за совет приобрести PicKit :), но пока не хочу), прога WinPic800. Сделал ему дополнительный разъем, прицепил жгут до дивайса. Слегка умощнил ключ, коммутирующий Vdd (а еще убрал электролит из цепи питания, осталась керамика 2х0,1 мкФ), сигнал Clck тоже буферизировал - чтобы тянуло повышенную нагрузку (соответствующие выводы ПИКа настроены на вывод в схеме и нагружены на пару микросхем серии 74HC574, питание которых идет параллельно процу).
И вот чего получается - ставлю туда 873А - программатор его спокойно шьет прямо в схеме (причем - можно даже не выключать статического питания схемы, по завершении прошивки сразу автоматом запускается - красота!)
А вот 876А он так шить не хочет.... Отдельно в программатре - пожалуйста, а в схеме - ошибка... Причем - если включено статическое питание схемы - ошибка практически всегда, при отключенном питании - один раз из 20 может записаться...
Внимание - вопрос :) :
Кто нибудь подскажет - в чем отличие программирования этих процов и как на 876А получить тот же результат? Какой из 3х сигналов (Vdd,Clock,Data) неправильный (Vpp развязан диодом)?
Конечно - теоретически можно в схему вставить полноценные ключи, отсекающие проц от остальной схемы - но у меня печатка заводского изготовления, да и не хочу схему в полтора раза усложнять...
PS А достаточно ли просто диода по выводу MCLR (диод подает на него 5В Vdd, если нет Vpp)? Или там еще в обязон резистор нужен, чтоб он мог при включенном питании ресетнуться на старте?
И обязательно ли имульсное питание при программировании? 16F84 прекрасно прошивался при постоянном питании, да и 873 шьется...
Ниче не понимаю..... :)
-
Сам спросил - сам и отвечаю! :) (Может кому пригодится:))
Дело было в сигнале сброса/MCLR, он же Vpp. Он перед началом цикла программирования должен быть в 0.
Но - почему же с 873 это все работало?
И второе - теперь для включения схемы в нормальную работу мне с 876 нужно отключать от платы разъем программатора (огород-то городился из-за переподключений при отладке, чтоб ничего не переподключать...) - чтобы сброс освободить... А вот с 873 все работало и без сброса...
И шо таки делать? :)
-
И шо таки делать?
Ну тумблер же в цепь сброса у программатора, просто разрывать сигнал MCLR. Щелк, прошили, щелк, работаете, и так далее.
А вообще давно пора завязать с этим старьем.
-
С каким именно?
А тумблер - это канеш выход, но как-то неэстетично...
-
С каким именно?
Да что c PIC'ами, что с AVR'ами во всех случаях, когда нужно больше 8 ног.
-
Извини, я ретроград...:)
Мне ПИКи искренне нравятся...
Там, где их возможностей достаточно...
-
Извини, я ретроград...:)
Мне ПИКи искренне нравятся...
Там, где их возможностей достаточно...
Та дело даже не в ретроградности. Сегодняшние реалии таковы, что при количестве ног более 8 за 1$ Вы получаете полноценный 32хбитный микроконтроллер с объемом FLASH/RAM чуть ли не в 10 раз больше, в 10 раз более быстродействующий (при том же потреблении), чем за $2..3 - 8битку с крохотным флешом, ОЗУ и производительностью.
-
Та дело даже не в ретроградности. Сегодняшние реалии таковы, что при количестве ног более 8 за 1$ Вы получаете полноценный 32хбитный микроконтроллер с объемом FLASH/RAM чуть ли не в 10 раз больше, в 10 раз более быстродействующий (при том же потреблении), чем за $2..3 - 8битку с крохотным флешом, ОЗУ и производительностью.
Миша не умеет писать на С, он пишет на ассемблере, поэтому переход на другой кор для него представляет трудности.
Давно его пинаю на предмет изучения С, пока безуспешно.
-
Миша не умеет писать на С, он пишет на ассемблере, поэтому переход на другой кор для него представляет трудности.
Ах вот оно что. Надо учиться, там никаких сложностей.
-
тяжело перелазить, все сайты по ARM начинаются с фразы "а теперь заказываем демо плату", и нет такого, что берем 6 проводков, прошиваем, мигаем светодиодиками.
на пиках с этим тоже не особо, но есть маны, что берем пикит и втыкаем туда-то, а у ARM я (неспеша, правда) через год только раскопал, что STM32F103 у которых есть нативное USB не шьются по нему, и нужен свой программатор.
Так же, нативной среды тоже нет. Смотрю как баран на кеил и иар.
-
Денис, а в чем проблема, JTAG программатор это несколько деталей на LPT port.
-
тяжело перелазить, все сайты по ARM начинаются с фразы "а теперь заказываем демо плату", и нет такого, что берем 6 проводков, прошиваем, мигаем светодиодиками.
Не читайте всякие сайты. Например, для прошивания LPC достаточно последовательного порта и двух сигналов (сброс и инициализация загрузчика). У меня валялся USB-to-COM на FT232, я от него преобразователь уровней отрезал и спокойно шью. Его же не снимая с разъема для программирования использую как отладочную консоль.
на пиках с этим тоже не особо, но есть маны, что берем пикит и втыкаем туда-то, а у ARM я (неспеша, правда) через год только раскопал, что STM32F103 у которых есть нативное USB не шьются по нему, и нужен свой программатор.
Так же, нативной среды тоже нет. Смотрю как баран на кеил и иар.
А что значит "нативная" среда в применении к ARM? Ядро везде одинаковое, периферия разная - так то дело пятое. Берете IAR и в путь. Например, помахать лапкой PORT0.5 на LPC17xx будет примерно так
#include <NXP/iolpc1768.h>
void main(void)
{
FIO0DIR=1UL<<5;
for(;;)
{
FIO0SET=1UL<<5;
FIO0CLR=1UL<<5;
}
}
Ну а дальше причесываете - включаете ускоритель доступа к FLASH, включаете PLL, включаете тактирование от PLL, переключаете тактирование периферии, подаете на нее питание (на нужную), инициализируете, и так далее.
-
KMG, RST7
я чайник, и от имени других чайников повторюсь, нет доступной информации.
Про AVR есть миллиард сайтов, для начинающих, для чайников, для ламеров, для полных идиотов и даже для олигофренов.
И продаются они в любом магазине, в котором есть панельки для микросхем. Есть панельки, значит тини13 или мега8 лежат рядом.
АРМ в том же ДЦ2 доступней не стали, разве что знатоки могут купить STM32F405 в ИТИСе, а LPC в DIP корпусе - фантастика.
подобия ардуин под ARM тоже не сахар, leaflabs maple - :facepalm:
jtag на 6 проводках мне не попадался, а попадется попробуй угадай с чем его готовить.
вот народ и сидит на чем привык. Мне вот лень прицеплять внешнее ОЗУ к аврке и дспику, вот c такойто матерью ползу вперед
-
Кстати, о дешевых отладочниках для ARM.
http://www.embeddedartists.com/products/lpcxpresso/lpc1769_xpr.php
20 евро. Плюс отпиливаете от него половину и получаете JTAG.
-
я заказал j-Link и ST-link. Понятия не имею, что это, придется разбираться в бою.
Платка с LPC занятная, еще IDE какой-то дают и SDK, хоть понятно от чего танцевать.
Кстати, несмотря на одинаковые ядра, кто-то из производителей дает вспомогательный софт, вроде pin-configurator'ов , а кто-то делает вид, что они не нужны.
-
Кстати, несмотря на одинаковые ядра, кто-то из производителей дает вспомогательный софт, вроде pin-configurator'ов , а кто-то делает вид, что они не нужны.
Никогда не пользуйтесь никакими такими генераторами кода, пишите все сами.
-
Никогда не пользуйтесь никакими такими генераторами кода, пишите все сами.
Rst7, попробуй сконфигурить маппинг IO для i.MX51 по даташиту. Там на один пин может быть смаппен один из нескольких модулей, причем возможны конфликтные ситуации.
Родной IomuxTool от Freescale позволяет избежать головной боли.
(https://guitartonelab.ru/proxy.php?request=http%3A%2F%2Fs9.postimg.org%2Fu0h72uydn%2Fiomux.jpg&hash=65d656c6982e514abcbcdcd7cf48e95a164916b0) (http://s9.postimg.org/g6sudt5sf/iomux.jpg)
-
Rst7, попробуй сконфигурить маппинг IO для i.MX51 по даташиту. Там на один пин может быть смаппен один из нескольких модулей, причем возможны конфликтные ситуации.
Та ну щас такое во всех камнях. В LPC, например, 4 разных функции на каждом выводе доступны. И ничего. Все равно сначала надо распланировать, что и где на каком выводе будет. А уже по этому плану руками вся конфигурация выписывается аж бегом.
-
В данном проекте 269 IO и без тулзы отследить возможные конфликты вручную весьма затруднительно.
-
В данном проекте 269 IO и без тулзы отследить возможные конфликты вручную весьма затруднительно.
Та и это не беда. Их же не по пять раз на дню переконфигурировать надо. Один раз при первой итерации и подправить на второй. Так что экономия часа/двух времени не стоит возможных проблем, если вдруг софтина сгенерит неправильную конфигурацию.
На самом деле основной вопрос в том, что начинающие привыкают сразу пользоваться всякими генераторами кода совершенно не вникая в сущность процесса. И даже три ножки не могут потом самостоятельно окучить. Опять же, в случае перехода на другую архитектуру (по различным причинам) сразу начинают искать волшебную тулзу с кнопочкой "сделать 3.14здато". Ну и метод ставить во главу угла при выборе архитектуры наличие волшебного софта, который все сделает за тебя, порочен по самое не могу.
-
На самом деле основной вопрос в том, что начинающие привыкают сразу пользоваться всякими генераторами кода совершенно не вникая в сущность процесса. И даже три ножки не могут потом самостоятельно окучить. Опять же, в случае перехода на другую архитектуру (по различным причинам) сразу начинают искать волшебную тулзу с кнопочкой "сделать 3.14здато". Ну и метод ставить во главу угла при выборе архитектуры наличие волшебного софта, который все сделает за тебя, порочен по самое не могу.
С этим полностью согласен.
Та и это не беда. Их же не по пять раз на дню переконфигурировать надо. Один раз при первой итерации и подправить на второй. Так что экономия часа/двух времени не стоит возможных проблем, если вдруг софтина сгенерит неправильную конфигурацию.
Во первых эта софтина от самого производителя чипа а не third party. Во вторых в этом чипе уж очень "не ортогональный" muxing с кучей перекрестных завязок. Ну и в третьих это не генератор кода, а хелповник по выбору конфигураций с проверкой конфликтов.
-
По AVR у меня не все и не сразу получалось, по этому сравнивал свой скелет с тем, что выдавал один из компиляторов (Codevision AVR, кажется) и гонял в протеусе (эмулятор там так себе). По этому, когда есть вспомогательный софт - это плюс.
-
По AVR у меня не все и не сразу получалось
Для AVR существует уникальный Algorithm Builder fo AVR - по возможностям аналогичен ассемблеру (то есть, наиболее эффективный объектный код), но благодаря наглядной визуальной алгоритмической структуре очень удобен для прикладного программирования и по эффективности приближается к ЯВУ.
Во всяком случае раз в пять эффективней АСМ по трудозатратам.
Для мелких процев (с ограниченными ресурсами, недостаточными для Си) - это вообще идеальный инструмент.
Для ПИКов аналога не существует - потому в нашем применении (примочкостроени) связка AVR+AB+PROTEUS оказывается вне конкуренции.
При этом, обладая собственным отличным отладчиком, АБ готовит работоспособный код, который в протеусе дошлифовывается в совокупности со всей обвязкой (аналоговой и цифровой).
-
"...Опять же, в случае перехода на другую архитектуру (по различным причинам) сразу начинают искать волшебную тулзу с кнопочкой "сделать 3.14здато". Ну и метод ставить во главу угла при выборе архитектуры наличие волшебного софта, который все сделает за тебя, порочен по самое не могу. "
Справедливо, отчасти. Но опять возвращаемся к широкому шаганию и порванным штанам. В наше время мало кто будет париться месяцы от покупки stm32 до осознанного дерганья лапкой. А пропасть между МК и демо платой тем временем не заполнена.
Что до алгоритм билдера, помню у кого-то из форумчан он синтезатор частоты применительно к тактированию BBD на таймерах делал, это мягко говоря, ахтунг.
-
В наше время мало кто будет париться месяцы от покупки stm32 до осознанного дерганья лапкой.
Я не очень понимаю, зачем и над чем там месяцами париться?
-
Потому, что нет пошагового мануала для чайников, а самому инфу по крупицам добывать - уходит много времени.
1) подбрасывать монетку какую семью и кого из семьи брать. Потом посмотреть список доступных МК в магазинах и передумать. Потом выясняется, что проще и дешевле купить на алиэкспрессе и снова переиграть выбор.
2) ломать голову как набросать макетку.
3) найти как шить и чем (софт и хард).
4) раскидать питание и земли. И кварц. И найти пины для прошивки. Т.е. примитивный демо борд своими руками.
5) найти в чем программировать. Всегда найдется тот, кто скажет что в такой-то среде и так программы писать и отлаживать нельзя, ищи что-то более современное.
Вот краткий перечень вопросов, который надо перед собой ставить, а потом со скрипом решать.
и этого перечня, как бы нигде нет.
А для авр подобное укладывалось в одну-две статьи на сайте и считалось само собой разумеющимся.
-
Потому, что нет пошагового мануала для чайников, а самому инфу по крупицам добывать - уходит много времени.
Да вся эта инфа есть в даташите на выбранный камень. Иногда это два документа - даташит и User Manual. И уж плававши один раз, например, с AVR, не представляет никакого труда разобраться с другим камнем, пофиг какой архитектуры там CPU.
Единственная тонкость - это особенности архитектуры самого CPU. Которые с одной стороны нивелируются тем, что надо работать, например, на Си, а с другой стороны надо отдавать себе отчет о чреватости применения, скажем, типа char для регистровой переменной на 32хбитной архитектуре. Пожалуй, вдумчивое применение типов uint_fast8_t вместо char (и аналогичные для других размеров) - это признак человека, который в курсе дела.
-
dsPIC33 пошел бодрее, чем ARM. До него пики в глаза не видел. и это при том, что он дурацкий и мануал специфичный (дурацкий) и в рунете инфы ноль. По ARM инфы больше, но ... в общем, второй круг.
di:halt пытается двигать ARM, но все опять завязано на специфике его демо борды, что без запаха флюса немного не то (есть тот же maple mini за $14)
uint_fast8_t - вроде как, аналогичный тип был у AVR дабы работать с регистром, а не ОЗУ
-
uint_fast8_t может быть и 8 и 16 и 32 и 64 бита, в зависимости от того какая разрядность работает быстрее для данной архтектуры
-
dsPIC33 пошел бодрее
Не надо это говно использовать. ARM, в некоторых случая (многие SoC) MIPS - выбор профессионалов. Остальное - не надо.
-
"весь регистр общего назначения, минимум 8 бит" я бы сказал.
Но до этого, надо решить кучу задач с проводками и софтом.
-
Но до этого, надо решить кучу задач с проводками и софтом.
Да не нужно ничего решать. 20 евро для быстрого старта (см. ссылку выше). И лучше IAR, чем местная среда.
Как наиграетесь - можно уже и самому на плату процессор ставить.
-
у dsPIC пока есть сильный козырь - 16бит ЦАП в 2-4 канала.
Что делает его весьма годным для LFO хорусов/тремоло/фэйзеров/прочей модуляции.
Вроде, у старших STM есть 12 бит ЦАПы, но у dsPIC это добро лет 6.
За IAR спасибо, приедут программаторы, сяду колхозить цветомузыку.
-
у dsPIC пока есть сильный козырь - 16бит ЦАП в 2-4 канала.
Зачем Вам там 16 бит-то? Точнее, зачем делать LFO на процессоре, а потом, если я правильно понимаю, ставить аналоговый VCO, если проще делать сразу все управление на процессоре?
-
Если поставить на выходе LFO оптопару - получается оптическое тремоло.
Используя ресурсы МК, можно сделать без проблем tap tempo, что очень популярно, когда примочек целый зоопарк. Так же, имея LFO легко делается фэйзер и прочая модуляция.
VCO есть только в хорусах-флэнжерах. Лет 6-7 назад я очень хотел хорус с регулируемыми нижним и верхним порогом задержки, вместо LFO и VCO влепил tiny3. Но тогда не хватило знаний и навыков, юношеский максимализм мешал начать хотя бы с меги, а не тиньки. Но, оно работало, хотя и криво.
VCO все же лучше делать на PLL типа 4046,4047 - стабильность повыше чем у DDS, да и с сигналом LFO можно делать что угодно.
В общем, потом обрезал хорусу "LFO" и добавил тап, вышел аналоговый дилей с тапом, он есть тут, на gtlab.
Подитожу, что
1) LFO на МК - это тап, много волн (синус, треугольник, меандр,пилы), и это модификация готовых примочек на раз-два.
8 бит маловато, 12 бит - нормально, 16 бит - отлично.
2) LFO+VCO для управления BBD - возможно, но геморройно. Программировать примочкостроители у нас очень не любят (Своего никто не пишет, есть один проект LFO на PIC, 8 бит ШИМ, который все используют).
3) STM32 - зверь-машина, думаю, что на нем можно и BBD эмулировать, причем сразу 2 штуки, и рулить чем угодно и шим бит на 12-14 сделать легко, смешав 2 ШИМ канала через 0.1% резисторы или использовав штатные ЦАП. По этому я навострил лыжи в сторону ARM (одна из причин).
-
3) STM32 - зверь-машина, думаю, что на нем можно и BBD эмулировать, причем сразу 2 штуки, и рулить чем угодно и шим бит на 12-14 сделать легко, смешав 2 ШИМ канала через 0.1% резисторы или использовав штатные ЦАП. По этому я навострил лыжи в сторону ARM (одна из причин).
Я Вам шепну по секрету, что не надо мешать два канала ШИМ. Достаточно дизеринга (или сигма-дельта, лучше второго порядка). Заводите ШИМ, скажем, как 32МГц/256=125кГц, при сигма-дельта второго порядка будете иметь на верхней частоте (20кГц) соотношение сигнал/шум порядка 48дБ(за счет 8 бит ШИМа)+32дБ(за счет передискретизации в сигма-дельта)=80дБ. Хватит за глаза, я считаю. Это, кстати, на порядок лучше теоретической точности в 0.1% при суммировании двух каналов ШИМ.
Ну а расчитать новое значение семпла раз в 8мкс - это как два пальца.
-
Сигма-дельта, это очень здравая мысль, но, так понимаю, это дополнительный обвес, и далеко не фильтр на одном опере.
Была мысль сделать искусственные 12 бит ШИМ (видимо, один из подвидов дитеринга), когда 8 бит таймеру подсовываются каждые 256 тиков определенные байты, чтобы усредненный диапазон был 0-4095 , ~72дБ .
По идее, для LFO хватит (там 60-100Гц - верхний предел, вторым порядком проутюжить и будет толк), но фильтр второго порядка - это все равно обвес, пускай и один опер.
А у dsPIC - ничего не надо. Запулил слово (если лень DMA пользоваться) и все. Главное об стабилизатор на 3.3В не обжечься.
Немцы на них VA синтезаторы делают.
-
Сигма-дельта, это очень здравая мысль, но, так понимаю, это дополнительный обвес, и далеко не фильтр на одном опере.
Так ШИМ-то тоже нужно фильтровать. Просто там практически бесплатно можно расширить ДД за счет сигма-дельта преобразования.
А у dsPIC - ничего не надо. Запулил слово (если лень DMA пользоваться) и все.
Я боюсь, что качество встроенных ЦАПов Вас крепко разочарует.
-
dsPIC как ЦАП вполне ничего, та же дельта-сигма. Делал LFOшку на нем года три назад (угораздило на ассемблере, си был платный и кряка небыло).
Просто, хочется не хуже того, но без недостатков присущих дспикам.
А недостатки Вы знаете: потребляет много, хранение данных один сегмент в 16кб (если данных больше, то только в программе их держать, через загрузку регистров), трудно достать, богатая эррата, бесперспективняк устроиться даже прокладкой между stackoverflow.com и менеджером, потому что PIC говнокодеры никому не нужны, а stackoverflow по заданной теме - пуст, и т.п.
Но гранит ARM пока не сильно слаще.
-
Прикидывал по сигма-дельта модуляторам на досуге.
Для 12 бит нужен отрезок в 4096 тактов. Для частоты дискретизации 48кГц, без оверсэмплинга, надо 196 608 000 тактов в секунду. Чего обычный stm с 72МГц тактовой явно не потянет.
Разве что, stm405/407 с его 168МГц тактовой частоты чего-то сможет.
Для 12 бит при 72МГц тактовой можно получить теоритическую частоту дискретизации 17.5кГц, что не так уж и много.
Выходит, что идея смешивания 2х 8битных ШИМ каналов не так уж и плоха. Можно попробовать слукавить и применить автокалибровку, заведя фильтрованную сумму ШИМ на АЦП.
Суммарный сигнал (пускай и 12 бит, 8+4) у нас условно состоит из "старшего байта", от которого нам нужен младший бит (или два). И "младшего байта", от которого нас интересует старший бит, или два.
При пуске устройства проводится автокалибровка.
Суммарный сигнал, допустим, усиливаем в 256 раз и заводим на АЦП.
Ставим младший бит старшего байта в "1", измеряем.
Ставим старший бит младшего байта, измеряем. Проверяем на соотношение 1:2. При необходимости, корректируем остальные биты младшего байта, благо на дробную часть остается еще 4 бита. (старший бит тоже придется корректировать, мы не знаем, куда сопротивления микшера уведет).
Подозреваю, что трусы через голову, но может и заработать. Тем более, дабы не возиться с совсем крохотными величинами, можно обыгрывать не 8+4, а 7+5 (что уже логичнее) или 6+6 бит (запас на дробь меньше, но можно и дитерингом обыграть или еще как, ибо остается запас для oversampling'a) или задействовать большее число ШИМ каналов, 3, или 4.
Теоретический итог:
при тактовой 72МГц, ШИМ8 бит даст частоту дискретизации 281,25кГц.
Из расчета оверсемплинга 6х, частота дискретизации будет 46,875 кГц. С дитерингом особо не разгонишься, но скромный запас имеется.
Из затрат - один-два ОУ и стабилитрон, чтобы вход АЦП не сжечь.
-
Прикидывал по сигма-дельта модуляторам на досуге.
Зачем это все? Считаем еще раз.
Пусть тактовая частота процессора 72МГц. Для удобства заводим ШИМ 8 бит. Период его будет 280кГц. На прерывание от переполнения вешаем следующую процедуру:
{
static int i1; //первый интегратор
static int i2; //второй интегратор
extern volatile int sample; //Входной семпл
int s=i2&0xFF0000; //Псевдовыход ШИМ'а
i2+=i1-s; //Обновление второго интегратора
i1+=sample-s; //Обновление первого интегратора
PWM=s>>16; //Выдача нового значения ШИМ, возможно тут надо перейти из signed в unsigned
}
На вход (т.е. в переменную sample) кормим 24хбитные значения семплов.
Этот код - сигма-дельта второго порядка, для него характерен спад шума со скоростью 12дБ/октава, т.е. для верхней частоты, скажем в 20кГц шум будет снижен на 12*log2(280кГц/20кГц)=46дБ.
Ну и сам ШИМ, т.к. он 8 бит, имеет шум квантования -6*8=-48дБ. Итого, на частоте 20кГц шумы квантования не превысят -48-46дБ=-92дБ, что соответствует АЦП в 15 бит.
Осталось только отфильтровать до вменяемых значений собственно ШИМ (если это актуально). Скажем так, LPF четвертого порядка будет вполне адекватен.
-
Справедливости ради надо отметить, что можно было бы еще сделать честный оверсемплинг, а не просто укладывать в переменную sample отсчеты с частотой дискретизации собственно аудиопотока, но это уже от лукавого, как по мне, все равно никто не услышит, если никому не говорить ;)
-
У меня пока в голове не укладывается, если оно заработает, тогда восторг!
Почему же многочисленные юзеры tiny25/45/85 так не сделали? Там же PLLка и ШИМ может работать на 64МГц, и можно много чего творить в 8 ног МК + 8 ног ОУ фильтра!
-
У меня пока в голове не укладывается, если оно заработает, тогда восторг!
Почему же многочисленные юзеры tiny25/45/85 так не сделали? Там же PLLка и ШИМ может работать на 64МГц, и можно много чего творить в 8 ног МК + 8 ног ОУ фильтра!
Ну так это вопросы к "многочисленным юзерам". Я примерно так в цифровом беспроводном мониторинге аудиопоток 2*16бит*48кГц проигрываю с радиоканала при помощи ATTiny261. Причем, ШИМ работает прямо на наушники, в одном комплекте получается усилитель класса D. Там, конечно, все впритык по производительности получается, ручная работа на ассемблере практически. Потому как поток еще и упаковывается (иначе он не лезет в двухмегабитный радиоканал).
-
Нашел наконец вводные по stm32: http://habrahabr.ru/post/125994/
Разве, что автор написал JTAG , а на деле использует SWD, но хоть какие-то разъяснения есть.
-
чего-то не завелся у меня примерчик (сигма-дельта второго порядка, который). в 1 бит оно жужжит, но по качеству очень прилично проигрывает обычному 8 бит ШИМ.
int s=i2&0xFF0000; //Псевдовыход ШИМ'аЕсли у нас знаковый тип, то получается &0x00FF0000 сразу откусывает старший байт, со знаком, если число отрицательное.
Попутно был найден OnePageStory.pdf
c примером:
double u, v=0, x1=0, x2=0;
while( cin >> u ){
x1 += u - v;
x2 += x1 - v;
v = x2<0?-1:1;
cout << v << endl;
}
-
Если у нас знаковый тип, то получается &0x00FF0000 сразу откусывает старший байт, со знаком, если число отрицательное.
Семплы на входе должны быть 24хбитные без знака.
-
Более того, оно не в 1 бит жужжит.
-
я пробовал со знаковыми и беззнаковыми сэмплами.
пока наколхозил первый порядок. 24 бит на входе, но знаковых (wav файлы >8 бит знаковые по умолчанию)
i1+=sample;
s=i1&0xffff0000;
i1-=s;
TIM_SetCompare1(TIM3, (s>>16)+128);
-
Понял, была проверка на внимательность.
Поменял строки подсчета интеграторов в Вашей программе согласно алгоритму из PDFки и все заработало.
x1 += u - v;
x2 += x1 - v;
-
Понял, была проверка на внимательность.
Там еще много маленьких тонкостей, например, с возможным переполнением интеграторов.
-
в шоке просто-4 раза прочитал-понял мало
чуствую себя полным папуасом
пардон за офтоп
-
в шоке просто-4 раза прочитал-понял мало
чуствую себя полным папуасом
Всегда удивляюсь, зачем люди себя насилуют прочтением непоятного и им ненужного? Видимо какая-то потребность в организме уменьшить самооценку... :-?
-
Вот и тонкости алгоритма всплыли:
Это синус по табличке, 8 младших бит, если в 16 битной терминологии. Фильтровано 4м порядком, ну и первым для сравнения.
(https://guitartonelab.ru/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FGecD6as.jpg&hash=3f1f1eeb66da5d0a3e37556f777846208d25c554)
-
Какое-то вообще странноватое поведение. Сверху сатурация, внизу - явно переполнение, но ведь есть еще 8 бит запаса (я ж правильно понял?).
Весь алгоритм в студию, разберемся.
-
вот выводится табличка синуса 8 бит , просто сдвинутая на 16 бит влево. Т.е. чистый ШИМ 8 бит
(https://guitartonelab.ru/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FyRRpPbJ.jpg&hash=68d03c0117f56bee2afadb15dbd3e97e45e2d75c)
Вот таблица сдвинутая на 8 бит. Т.е. младшие 8 бит в случае 16 битного звукового диапазона, или средние 8 бит 24 битного.
(https://guitartonelab.ru/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FCsqNeJb.jpg&hash=cb3dd1b4fc64dc4bd6920511451448a0a00e465b)
как-то не выглядит амплитуда в 256 раз меньше верхнего случая.
Обработчик прерывания
void TIM3_IRQHandler(void)
{
volatile static u32 RRR;
static unsigned int sample;
static int i1=0; //первый интегратор
static int i2=0; //второй интегратор
int s; //Псевдовыход ШИМ'а
TIM_ClearITPendingBit(TIM3, TIM_IT_Update);
RRR+=idRRR; // DDS
sample=( (wave_tab[RRR>>23])<<8 ); // x256
//sample=( (wave_tab[RRR>>23])<<16 ); // x65536
s=i2 & 0xFF0000; //Псевдовыход ШИМ'а
i1+=sample-s; //Обновление первого интегратора
i2+=i1-s; //Обновление второго интегратора
TIM_SetCompare1(TIM3, (s>>16) ); // - дельта сигма
}
обычный DDS, таблица синуса беззнаковая, 8 бит, размером 512 элементов.
Т.е. изысков никаких совсем.
-
По правильному надо сделать вот что.
Вот этот крайне упрощенный вариант
s=i2 & 0xFF0000;
заменить на правильный
if (i2<0)
{
s=0;
}
else
{
if (i2>0xFF0000L)
{
s=0xFF0000;
}
else
{
s=i2&0xFF0000;
}
}
Более того, я рекомендую для начальных тестов работать в середине диапазона, т.е. так
sample=( (wave_tab[RRR>>23])<<8 )+0x7F8000UL;
Потом будете разбираться с переполнениями и прочим.
-
В свое оправдание могу сказать, что самое первое фото снято в середине диапазона, т.к. ОУ был под подозрением и было интересно, кто врет.
-
мде, очередной раз мог бы и сам догадаться.
Стало прилично лучше.
Сигнал 10Гц, фильтр 4го порядка на 100Гц, на 2кГц дает ослабление 90дБ. Видимо, начинаются переполнения.
(https://guitartonelab.ru/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F8P0rHIg.jpg&hash=aa146c8364559a8668f9d2ed723a8efbb802e7de)
-
И главное, забыл сказать спасибо за интересный алгоритм и подсказки.
А то хотелось в лоб упростить себе жизнь, сделать ШИМ 12 бит через 16х8бит и раскидать равномерно по 16 периодам отображаемую величину, дабы вывести шум в область ВЧ.
Частота дискретизации около 17кГц получается.
-
Сигнал 10Гц, фильтр 4го порядка на 100Гц, на 2кГц дает ослабление 90дБ. Видимо, начинаются переполнения.
Погодите, это ж у вас желтый - первый порядок фильтрации, а красный - четвертый, так? Там, видимо, помеха пролезает, это непохоже на переполнения.
-
там что-то более интересное, чем просто помеха.
вот младшие 8 бит сдвинутые влево еще на 4 бита, т.е. немного усиленные.
Смещение "постоянкой" форму не меняет.
(https://guitartonelab.ru/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FfLILlwm.jpg&hash=cd8ba38adfa910e32ace3cbe3a18c627d0c9be7c)
Желтый - первого порядка, пассивный RC 10K+10n , на него действительно помехи действуют.
-
Судя по всему, у Вас на фильтре есть резонанс на характеристике. Иногда в этот резонанс попадают субгармоники модулятора. Проверьте АЧХ фильтра.
-
Выбор алгоритма тоже влияет.
Вот 12 бит ШИМ (младшие 8 бит из 12, т.е. как тест выше). Видно, что тот же фильтр 4-го порядка справляется лучше, хотя частота дискретизации всего 17кГц, а не 270.
В то же время, заметно, что RC цепочке приходится гораздо сложнее.
(https://guitartonelab.ru/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FUwyiZef.jpg&hash=f08921b820fb5b0c011a3196a2c4b031f3b110a8)
-
сделал 12 бит ШИМ фрагментами по 8 бит, шум получился такой же сильный, как на комбинированном дельта-сигма + ШИМ 8 бит.
Явно фильтр чудит.
Фильтр прикидывал в фильтр лабе, Саллен-Кей 4го порядка , питание 5 вольт, опер - TS921
(https://guitartonelab.ru/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FZEClhDJ.jpg&hash=81fd63a672427d1e9fbc4c92ecd5ca1c133bf0bb)
-
Фильтр прикидывал в фильтр лабе, Саллен-Кей 4го порядка , питание 5 вольт, опер - TS921
Вы бы его АЧХ проверили в железе. Возможно, велик разброс номиналов.
-
Я пока решил числом брать. Сделал макетку фильтра 4го порядка с панельками под элементы.
Бессель и Баттлворд уже намакечены, результат идентичный.
Просто, задумка немного теряет смысл, если ювелирно подбирать параметры фильтров.