Ну, положим, не совсем фоновый, а поскольку ЦПУ приостанавливается на время передачи, постольку может появиться непредсказуемый джиттер в других местах вашей программы.

Кстати, почему вы говорите, что требуется 2 такта MCLK на сэмпл и что нет джиттера? Перед передачей ДМА синхронизируется за 1-2 такта, передача 2 такта и ожидание после передачи 1 такт. Итого требуется (1..2) + 2 + 1 = 4..5 тактов. Вот вам реальное время передачи и реальный джиттер.

Цитата из доки slau056f:

"The DMA controller requires one or two MCLK clock cycles to synchronize before each single transfer or complete block or burst-block transfer. Each byte/word transfer requires two MCLK cycles after synchronization, and one cycle of wait time after the transfer."

Вот что пишут зарубежные коллеги по поводу 8-ми битности.
8-bit MCUS: It's not the size that's important
Пару цитат:
Насколько я понял из статьи, в ближайшее время особо ничего не поменяется.

P.S. Прошу прощения если ссылка уже была.

Ну если MIP32 M4K содержит 50к гейтов, то Cortex-M0 содержит всего 12к (ядро), что уже совсем не принципиально отличается от 8-битников, а в стоимости кремния - так и вовсе.
В итоге за те же деньги получаем намного больше.
Осталось дать себе труд изучить новое ядро и ...

Из того, что производится в Украине - энергосберегающие лампы, пром. контроллеры, различные таймеры/термостаты/средства защиты, автосигналки (датчики), кассовые аппараты...



Осталось производителям этого самого кремния довести до ума как минимум потребление и я буду серьезно их рассматривать как доступную альтернативу. Т.к. большая часть моих проектов должна потреблять "до 20мА все изделие". А как не беру доку на очередной небольшой ARM, так и возвращаюсь к "отстойным 8-битникам".

У нас тема АВР vs. АРМ,
вот интересно, почему в этой теме так "воинственны" именно те кто за АРМ ?
какое им дело до тех кто сидит на АВР и слезать с них не планирует ?
Вот правда интересно,
у меня проекты и на одних и на других камнях,
и проблемы выбора обычно нет, то есть всегда понятно, здесь применяем АВР(или ПИК) а здесь АРМ без вариантов...
Но почему люди пересевшие на АРМ так "воинственно" его рекламируют ?

З.Ы.
Мнение любителя "контроллеров светодиодов" меня интересует меньше всего...

+1


Ученик должен подобрать инвентарь себе сам. Пусть тренер - мастер спорта, но он никогда не будет навязывать свой инветарь ученикам. Например если речь о теннисе, было бы смешно наблюдать как тренер-левша, навязывает свою ракетку правше.
Вывод - те, кто __воинственно__ рекламирует (как и те кто воинственно защищают) - на мастера не тянут.



А к совету IgorKossak стоит прислушаться обязательно:

И чем больше ядер изучено - тем проще решить проблему выбора...

Вот нафлудили-то,а )))

Ясное дело, что для 8ми битных контроллеров всегда будет работа.
И так-же ясно, что даже там, где было-бы можно применить ARM и даже выиграть в чём-то - привыкшие к AVR люди, не будут этого делать из-за инерционности мышления И в том числе из-за того, что как было уже сказано - как правило работать должно "вчера"

И чё спорить-то........
Да ещё и про bool успели - ну это уж ваще класс

Вообще - мне нравится АВР больше чем АРМ
АРМ воспринемаешь уже как что-то такое более серьёзное...а АВР...АВР это такое: дёшево, сердито и чисто для народа!
И вся эта его неубиваемость по питанию, мощные пины - только прибавляют впечатлений!

P.S. Сохраняю объективность как могу.

И так, ниша АВР уже определена! Малый контроллер для средней сложности задач, с прогнозируемым временем реакции, мощными ногами, хорошей надежностью ну и т.д. А может быть главное " - Я ЕГО ЗНАЮ!"
Что касается АРМов, у них свой круг задач. И все давно поняли что за счет снижения цен на 32-х разрядные ядра, в том числе и не только АРМ но и других ядер, ниша 8-битных процессоров уменьшается.

Поверхностно были затронуты проблемы конкуренции электронных изделий производимых Нашими компаниями с китайскими. Полагаю, что данному вопросу и тебуется уделить основное внимание в нашей дискусии!!! Уверен что практически всЁ, что можно реализовать на Мегах можно реализовать на Хольтеках которые будут дешевле, даже если их взять две штуки вместо одной!!!
Отсюда следует несколько неожиданный для многих вывод, что речь должна идти в первую очередь о конкурентно способности специалистов- разработчиков!!! Идея проста - сокращение рабочего времени тех самых разработчиков пулучающих между прочим зарплату (думаю 3000$ в месяц -подойдет ) и как результат, за то же время реализации нескольки проектов.
В даном контексте хочу рассказать про семинар MAtlab, где своим мастерством американцы просто упивались. Чувак взял стенд содержащий небольшой движок с двумя инерционными нагрузками соединенными пружинной связью. За полчаса он набросал в матлабе алгоритм управления (идентификация частотной характеристики всей этой приблуды, параметрический синтез регулятора), тут же, не парясь, загрузил автоматически сгенерированный код в борду на базе TMS320_28335, далее еще чуть чуть подогнал и все!!! При зарплате в месяц 10000$ дополнительные расходы составляют 25$ за полчаса!!! А теперь посчитайте сколько ему надо заплатить если все это он будет писать на Хольтек на ассемблере??? Ха-ха! А в это время его девайс работает, а я, будь я его работодателем, получаю прибыль!!! Вот вам в действии быстрый вывод изделия на рынок и возможность дальнейшего совершенствования в предполагаемый период. И вот основные преимущества которые обеспечивает использование мощных процессоров с возможностью, быстрой и по-возможности автоматизированной генерации кода (например средствами MAtlab или Labview), или епе минимум использованием предметно специализированных asm-оптимизированных библиотек.

Поэтому, может этот посыл будет неоднозначно воспринят сообществом, но я скажу:
- Не стоит ломать копья по поводу оптимизации кода для 8-битных процессоров, что точно также является хвастовством по использованию ассемблера вместо С.
Ни кто не говорит что плохо написанная программа не хуже хорошо написанной. Конечно хуже. Но для того и существуют специалисты-программисты (не особо сильных, например, в электроприводах, что вполне естественно , гигантов мысли в рассчет не берем), которые могут оптимизировать код, в то время пока электропривод уже продается и приносит ожидаемую прибыль. А основное внимание надо уделить возможностям сокращения времени реализации проекта. Если на МЕГЕ легче поднять проект пожалуйста, если на АРМ- пожалуйста.

Можно сравнить переход от AVR к ARM как переход с чисто процедурного языка C на объектно-ориентированный C++ и C#.
Си знают все, его отлично хватает на простые задачи в проекты до нескольких тысяч строк кода. Но чтобы перейти к более крупным системам также требуется перенастроить свое мышление в сторону бОльших абстракций. Вот тут то и начинается проблема, надо понимать классы (современная периферия типа контроллера SDRAM или TFT), правильно использовать исключения (линуксовые отладчики, JTAGи).
Конечно, остаются всегда задачи, где С++ (как и ARM) использовать не имеет смысла, лишний оверхед никчему. Но и зависать на одной технологии тоже не стоит. Пока вы ее вздрючиваете по полной и выжимаете все соки из AVR, ваш конкурент поставит ARM в котором все уже есть (TFT, Ethernet, USB), легким движением руки запустит проект. И проект этот у него стоить будет даже дешевле вашего, потому что он делал его не год как вы а месяц и здорово сэкономил на зарплате.

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

Понимаете, мыслите вы правильно, только это "буржуинский" подход, у нас он тут не годится Никто не будет экономить время разработчика у которого зарплата 300 - 400 баксов, это просто не имеет смысла, поскольку директор на большую сумму тратит на бензин в месяц Поэтому делаться будет на том камне который хорошо знает разработчик, а разработчик будет сидеть на этом камне до последнего пока уж совсем не припечет.

А потом этого грамотея на объект отправить, в поле, пусть гайки покрутит при температуре, пусть даже -20, посмотрим, как он запоет. Или в море, на корабль, пусть в ЦПУ под рев машины быстренько свой красивый алгоритм допиливает до рабочего состояния.

Таких кабинетных разработчиков мы видали вагон и на бую их всех вертели. Причем без разницы, что там за камень - AVR, ARM, TMS, да хоть рассыпуха.

Точка.

А Вы, как работодатель, "в даном контексте" готовы платить большие тыщи баксов за лицензионный MAtlab, компиляторы C++ и прочие САПР'ы? Чудес не бывает..

Выскажу своё мнение. Чуствую, что заклюют, но не могу сдержаться.

Гигантоманы, это - вам:

1. В конечном счёте любая задача сводится к "морганию светодиодами".
2. Ассемблер сложен только для тех, кто не может упорядочить задачу в голове.
3. Основное время уходит не на написание программы, а на размышления, как это сделать.

Результаты работы по принципу "сделать бапки побыстрей" всем хорошо известны: заходишь в магазин - всего много, а купить нечего.
Неужели кто-то действительно думает, что собрав в кучу множество чужих программ и кое как их упорядочив, можно получить надёжно работающую вещь?

Переходите сразу на атом, чего мелочиться!

Безусловно. И еще забыли немаловажный пункт - время на испытания/тестирование (в широком смысле, с написанием софта для тестов, с изготовлением имитаторов объекта и т.д.).



Ага. А электроника - наука о контактах