16F876A отличия прошивки?

[KMG]

На самом деле основной вопрос в том, что начинающие привыкают сразу пользоваться всякими генераторами кода совершенно не вникая в сущность процесса. И даже три ножки не могут потом самостоятельно окучить. Опять же, в случае перехода на другую архитектуру (по различным причинам) сразу начинают искать волшебную тулзу с кнопочкой "сделать 3.14здато". Ну и метод ставить во главу угла при выборе архитектуры наличие волшебного софта, который все сделает за тебя, порочен по самое не могу.

С этим полностью согласен.

Та и это не беда. Их же не по пять раз на дню переконфигурировать надо. Один раз при первой итерации и подправить на второй. Так что экономия часа/двух времени не стоит возможных проблем, если вдруг софтина сгенерит неправильную конфигурацию.

Во первых эта софтина от самого производителя чипа а не third party. Во вторых в этом чипе уж очень "не ортогональный" muxing с кучей перекрестных завязок. Ну и в третьих это не генератор кода, а хелповник по выбору конфигураций с проверкой конфликтов.

[research]

По AVR у меня не все и не сразу получалось, по этому сравнивал свой скелет с тем, что выдавал один из компиляторов (Codevision AVR, кажется) и гонял в протеусе (эмулятор там так себе). По этому, когда есть вспомогательный софт - это плюс.

[Peratron]

По AVR у меня не все и не сразу получалось

Для AVR существует уникальный Algorithm Builder fo AVR - по возможностям аналогичен ассемблеру (то есть, наиболее эффективный объектный код), но благодаря наглядной визуальной алгоритмической структуре очень удобен для прикладного программирования и по эффективности приближается к ЯВУ.
Во всяком случае раз в пять эффективней АСМ по трудозатратам.

Для мелких процев (с ограниченными ресурсами, недостаточными для Си) - это вообще идеальный инструмент.

Для ПИКов аналога не существует - потому в нашем применении (примочкостроени) связка AVR+AB+PROTEUS оказывается вне конкуренции.

При этом, обладая собственным отличным отладчиком, АБ готовит работоспособный код, который в протеусе дошлифовывается в совокупности со всей обвязкой (аналоговой и цифровой).

[research]

"...Опять же, в случае перехода на другую архитектуру (по различным причинам) сразу начинают искать волшебную тулзу с кнопочкой "сделать 3.14здато". Ну и метод ставить во главу угла при выборе архитектуры наличие волшебного софта, который все сделает за тебя, порочен по самое не могу. "

Справедливо, отчасти. Но опять возвращаемся к широкому шаганию и порванным штанам. В наше время мало кто будет париться месяцы от покупки stm32 до осознанного дерганья лапкой. А пропасть между МК и демо платой тем временем не заполнена.

Что до алгоритм билдера, помню у кого-то из форумчан он синтезатор частоты  применительно к тактированию BBD на таймерах делал, это мягко говоря, ахтунг.

[Rst7]

В наше время мало кто будет париться месяцы от покупки stm32 до осознанного дерганья лапкой.

Я не очень понимаю, зачем и над чем там месяцами париться?

[research]

Потому, что нет пошагового мануала для чайников, а самому инфу по крупицам добывать - уходит много времени.

1) подбрасывать монетку какую семью и  кого из семьи брать. Потом посмотреть список доступных МК в магазинах и передумать. Потом выясняется, что проще и дешевле купить на алиэкспрессе и снова переиграть выбор.
2) ломать голову как набросать макетку.
3) найти как шить и чем (софт и хард).
4) раскидать питание и земли. И кварц. И найти пины для прошивки. Т.е. примитивный демо борд своими руками.
5) найти в чем программировать. Всегда найдется тот, кто скажет что в такой-то среде и так программы писать и отлаживать нельзя, ищи что-то более современное.

Вот краткий перечень вопросов, который надо перед собой ставить, а потом со скрипом решать.

и этого перечня, как бы нигде нет.
А для авр подобное укладывалось в одну-две статьи на сайте и считалось само собой разумеющимся.

[Rst7]

Потому, что нет пошагового мануала для чайников, а самому инфу по крупицам добывать - уходит много времени.

Да вся эта инфа есть в даташите на выбранный камень. Иногда это два документа - даташит и User Manual. И уж плававши один раз, например, с AVR, не представляет никакого труда разобраться с другим камнем, пофиг какой архитектуры там CPU.

Единственная тонкость - это особенности архитектуры самого CPU. Которые с одной стороны нивелируются тем, что надо работать, например, на Си, а с другой стороны надо отдавать себе отчет о чреватости применения, скажем, типа char для регистровой переменной на 32хбитной архитектуре. Пожалуй, вдумчивое применение типов uint_fast8_t вместо char (и аналогичные для других размеров) - это признак человека, который в курсе дела.

[research]

dsPIC33 пошел бодрее, чем ARM. До него пики в глаза не видел. и это при том, что он дурацкий и мануал специфичный (дурацкий) и в рунете инфы ноль. По ARM инфы больше, но ... в общем, второй круг.

di:halt пытается двигать ARM, но все опять завязано на специфике его демо борды, что без запаха флюса немного не то (есть тот же maple mini за $14)

uint_fast8_t  - вроде как, аналогичный тип был у AVR дабы работать с регистром, а не ОЗУ

[KMG]

uint_fast8_t может быть и 8 и 16 и 32 и 64 бита, в зависимости от того какая разрядность работает быстрее для данной архтектуры

[Rst7]

dsPIC33 пошел бодрее

Не надо это говно использовать. ARM, в некоторых случая (многие SoC) MIPS - выбор профессионалов. Остальное - не надо.

[research]

"весь регистр общего назначения, минимум 8 бит" я бы сказал.
Но до этого, надо решить кучу задач с проводками и софтом.

[Rst7]

Но до этого, надо решить кучу задач с проводками и софтом.

Да не нужно ничего решать. 20 евро для быстрого старта (см. ссылку выше). И лучше IAR, чем местная среда.

Как наиграетесь - можно уже и самому на плату процессор ставить.

[research]

у dsPIC пока есть сильный козырь - 16бит ЦАП в 2-4 канала.
Что делает его весьма годным для LFO хорусов/тремоло/фэйзеров/прочей модуляции.

Вроде, у старших STM есть 12 бит ЦАПы, но у dsPIC это добро лет 6.

За IAR спасибо, приедут программаторы, сяду колхозить цветомузыку.

[Rst7]

у dsPIC пока есть сильный козырь - 16бит ЦАП в 2-4 канала.

Зачем Вам там 16 бит-то? Точнее, зачем делать LFO на процессоре, а потом, если я правильно понимаю, ставить аналоговый VCO, если проще делать сразу все управление на процессоре?

[research]

Если поставить на выходе 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 (одна из причин).

[Rst7]

3) STM32 - зверь-машина, думаю, что на нем можно и BBD эмулировать, причем сразу 2 штуки, и рулить чем угодно и шим бит на 12-14 сделать легко, смешав 2 ШИМ канала через 0.1% резисторы или использовав штатные ЦАП. По этому я навострил лыжи в сторону ARM (одна из причин).

Я Вам шепну по секрету, что не надо мешать два канала ШИМ. Достаточно дизеринга (или сигма-дельта, лучше второго порядка). Заводите ШИМ, скажем, как 32МГц/256=125кГц, при сигма-дельта второго порядка будете иметь на верхней частоте (20кГц) соотношение сигнал/шум порядка 48дБ(за счет 8 бит ШИМа)+32дБ(за счет передискретизации в сигма-дельта)=80дБ. Хватит за глаза, я считаю. Это, кстати, на порядок лучше теоретической точности в 0.1% при суммировании двух каналов ШИМ.

Ну а расчитать новое значение семпла раз в 8мкс - это как два пальца.

[research]

Сигма-дельта, это очень здравая мысль, но, так понимаю, это дополнительный обвес, и далеко не фильтр на одном опере.

Была мысль сделать искусственные 12 бит ШИМ (видимо, один из подвидов дитеринга), когда 8 бит таймеру подсовываются каждые 256 тиков определенные байты, чтобы усредненный диапазон был 0-4095 , ~72дБ .
По идее, для LFO хватит (там 60-100Гц - верхний предел, вторым порядком проутюжить и будет толк), но фильтр второго порядка - это все равно обвес, пускай и один опер.
А у dsPIC - ничего не надо. Запулил слово (если лень DMA пользоваться) и все. Главное об стабилизатор на 3.3В не обжечься.
Немцы на них VA синтезаторы делают.

[Rst7]

Сигма-дельта, это очень здравая мысль, но, так понимаю, это дополнительный обвес, и далеко не фильтр на одном опере.

Так ШИМ-то тоже нужно фильтровать. Просто там практически бесплатно можно расширить ДД за счет сигма-дельта преобразования.

А у dsPIC - ничего не надо. Запулил слово (если лень DMA пользоваться) и все.

Я боюсь, что качество встроенных ЦАПов Вас крепко разочарует.

[research]

dsPIC как ЦАП вполне ничего, та же дельта-сигма. Делал LFOшку на нем года три назад (угораздило на ассемблере, си был платный и кряка небыло).

Просто, хочется не хуже того, но без недостатков присущих дспикам.
А недостатки Вы знаете: потребляет много, хранение данных один сегмент в 16кб (если данных больше, то только в программе их держать, через загрузку регистров), трудно достать, богатая эррата, бесперспективняк устроиться даже прокладкой между stackoverflow.com и менеджером, потому что PIC говнокодеры никому не нужны, а stackoverflow по заданной теме - пуст, и т.п.

Но гранит ARM пока не сильно слаще.

[research]

Прикидывал по сигма-дельта модуляторам на досуге.
Для 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 кГц. С дитерингом особо не разгонишься, но скромный запас имеется.
Из затрат - один-два ОУ и стабилитрон, чтобы вход АЦП не сжечь.