"Это точно не холивар?  Ну тогда просто смешно с ваших доводов. ))))))"

У меня НЕТ ДОВОДОВ, ещё раз. Не возбуждайтесь, а лучше приведите пример решения поставленной (или какой подобной) задачи на обоих камнях. Будет строго и по-научному вместо "соплей и слюней" ("убогое")..

Мало ли что на заборе написано. Даже СТМ32Ф10х с его 16-бит СПИ легко переваривает 18-бит СПИ для мелких цветных ТФТ непрерывным потоком, через переупаковку на лету. Может это  Мега сделать? Нет! Нет режима СПИ 16-бит, нет нормальных команд ядра сдвига, убогая работа с 32-бит. Вот для меги и остаётся только ногодрыг, а на большее она и не способна.

Несколько дисплеев, ТФТ и семисегментников, 1-вире, несколько каналов, ИР-датчик и ещё чего нибудь, одновременно, без тормозов. И всё это на копеечном Ф0хх. Главное чтобы таймеров и каналов ДМА хватало, для хардварности решений. Может мега такое сделать, да ещё и на ардуине? )))))))))

Вы явно не читатель. Написал же что для обработки видео - меги НЕ ПРЕДНАЗНАЧЕНЫ .. нет жеж. :)

Ну, сделайте мне SQL-сервер, с мощой хорошего дата-центра для обработки 100 террабайт данных и реакцией на запрос в 0.01сек, да на своем STM32F00 .. что НЕ МОЖЕТ? Ваши "доводы" из этой же оперы. :)

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

Какое видео? Вывод цифра-букафф на ТФТ это есть видео? )))))))))

Для СТМ32 главное правильно распределить задачи по ресурсам, а для меги только долбиться в ногодрыге. Потому что у древней меги нет никаких ресурсов, априори. Понимаете разницу?

Попробую объяснить на пальцах. Семисегментник на восемь цифр цепляем на порт (он 16-бит), как попало в плане сегмент-разряд, маски на BSRR сделают своё атомарное дело, юзаем через таймер и ДМА, хардварно и без прерываний. Нет прерываний, понимаешь ли! 1-вирэ тоже через таймер и ДМА, всё хардварно, по флагу вынимаем значения по каждому каналу. И тоже нет прерываний. ТФТ 320х240 тоже - таймер и ДМА через порт, мелкий ТФТ 9-бит через СПИ и т.д. Ещё остаются ресурсы на ногодрыг, если он нужен и на всякие прерывания, если они нужны. Так понятнее?

TFT-дисплей, вполне себе задача по работе с видео. Напрример такой: https://market.yandex.ru/product/7350918?hid=91052&nid=54539&clid=698, и особенно если надо выводить 25-50 кадров в секунду да с 3D обработкой... ну что вы про "7-сегментник" рассказываете человеку, который в свое время на игрухах "собак ел" и десятками .. я же отписался - "не возбуждайтесь". Спокойствие, только спосойствие. :)

При работе с потоковым выводом прерывания в общем-то и ник чему. Есть буфер, его и гоняем через ДМА. Надо что-то новенькое - кинули данные в буфер, ДМА само отрисует. Ну зачем столько "патетики"? Прерывания - это прерогатива управления железяками. И то, что вы задачами управления не обременены - это видно наглядно. Я это уже и так понял, ещё раз - спокойнее.. да, замечательный камень для своих задач, но никак не умаляет работу с мегами в своем классе задач.

.. и эта, что, дифференциального режиму - точно нет?!? А предусилитель - есть? .. вы как-то не ответили.

Опять вы за своё? В каком классе задач? Нет задач "для Меги или ПИК", есть класс задач для МК.

И ещё. Что убого в восьмибитках и в ардуино это непредсказуемость и неопределённость. Сможете навскидку, без ковыряния кода и скетчей, сказать, сколько у вас по времени займёт вывод с памяти типа М25Р32 на ТФТ 320х240 в 16-бит цвете картинок, к примеру? В реале? Нет! Не можете! Если есть ещё задачи, то у вас это время ещё и прыгать будет или картинка будет дёргаться. Я смогу, достаточно взять калькулятор и посчитать - ровно столько, сколько нужно для непрерывного чтения этой картинки из СПИ-флэш. Потому что у меня чтение по СПИ и вывод на ТФТ идут одновременно и хардварно!!! Ядро свободно и может заниматься своими делами. А у меги как с этим? Опять всё плохо? )))))))

Блин... вы опять за вывод из памяти на экран. Ну нет в управлении сельсинами у Калибра экрана, ну никакого нет! Вот совсем нет..  и не нужен он мегам. Никакой. :)

А вот "диффернциальный режим" очень даже кстати.. так есть или нету?

Смотрите новые модели Ф3 и Ф4. Там много чего ещё есть. )))))

Я вам просто привёл пример, как на СТМ32 решаются задачи без ногодрыга и занятости ядра, а у вас истерика случилась. )))))))))

Это у которых цена начинается от 1000/шт? Пасибки, я с мегой постою.. :)

Вы точно не читатель. Эти задачи НЕ ДЛЯ мег .. сколько раз вам это надо повторить, чтобы до вас дошло? :)

"Это у которых цена начинается от 1000/шт? Пасибки, я с мегой постою.. :)"

Угу! Мне по деньгам в магазине напротив купить 2-3-4 СТМ32 что купить 1 мегу. Прикольно? ))))))))

"Эти задачи НЕ ДЛЯ мег .. сколько раз вам это надо повторить, чтобы до вас дошло? :)"

Нет задач для мег, нет задач для ПИКов. Не надо придумывать. 1- вирэ не для мег? Семисегментник не для мег? А что тогда для мег? Помигать светодиодом? Для этого есть в продаже мигающие светодиоды! )))))))

"Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) Козьма Прутков, №66. :)

Это да! Валяются где-то несколько мег от старых проектов, всё выбросить жалко.

Ну я прикину без проблем.  Проц 328р.SPI на половине частоты проца 16МГц/8МГц. Соответственно байты получу на 1МГц. Для потоковой организации надо выпихнуть байт за 1мксек, те 16 тактов. Написать код который за 16 тактов: проверит флаг приема, загрузит байт в регистр, выдаст регистр в порт, установит и сбросит сигнал записи, декриментит байтовый счетчик и если не 0 перейдет на начало - реализуемо. Разумеется если си знать и пины не в переменных держать. Получаем поток 1МБ/сек. Наши 320*240*2=150КБ соответственно закинутся на экран за 0,15сек. Загрузка проца 100%. Прерывания вызывают некоторое увеличение времени.

С Вас расчет для STM. Думаю 0.07сек получите. Чисто из условия частоты шины 18МГц (кстати а если проц на 56МГц ну чтоб АЦП по максимуму, то SPI сколько? 14? ;) Т.е выигрывает 2,25 раз. При 0 загрузке проца. Прерывания конечно несколько подгружают.

Теперь ближе к реалиям. Памяти у нас довольно много и для эффективного использования нужна ФС. Будем считать что она у нас организована достаточно быстро, издержки на открытие закрытие файла не определяющие, но ФС с характерными чертами типичными - данны в цепочке блоков, CRC16 в конце блока.

Далее, если мы решили проверять  CRC и оно не совпадает с понравившимся автору STM - про DMA прийдется забыть. Для АВР это чисто програмное, правда влезет ли еще и подсчет на лету CRC в 16 тактов - не уверен не попробовав, возможно тормознет на 5-10%.

Если мы игнорируем CRC, то для проца 328р - пару веток кода. Для STM - реальная специфика не даст работать DMA на полную катушку. Его постоянно прийдется останавливать, пропускать CRC, читат системную таблицу, начинать новый блок. А это загрузит проц. И фрагментирует свободное время, что затруднит или сделает невозможным  его использование. Выбрать с лету тут верный подход я не берусь. Если ssss не забросит тему и распишет как на STM  реализовать лучше,  возможно получим уточненную оценку. Если нет - я позже попробую оценить, но и так видно что по скорости при идеальном выиграше в 2,25 раз при приближении к реальности хороше если 1,5раз будет.

Гы! Понесли ботинки Митю! )))))))

Странная у вас математика. На СТМ32 будет в 3 с лишним раза быстрее чем на меге. И это при загрузке меги в 100%, а СТМ32 - 0%. ))))))))

КРК появилась откуда-то. Можно подумать, что КРК на меге посчитается быстрее. В общем приплелось что попало, лишь бы не упасть лицом меги в грязь и дотянуть до эфемерных "1,5 раза". ))))))))

Почему в 3 с лишним. Как считали? Какая частота SPI?

 CRC применяется в ФС для контроля целостности данных. Для подсчета CRC прийдется отказатся от DMA. Шо не так? 

Похоже ssss решил соскочить с темы, как обычно - сразу  "возму калькулятор, серезный проект"...  А потом только "Гы"...

Logik, вы, похоже опять семимильными шагами понеслись к своему конфузу. Гражданин со свистящей фамилией уже несколько лет состоит в секте себе подобных и занимаются они на нескольких фоумах тем, что славят STM32 и хаят все остальное. Зачем они это делают понять сложно, но поступки сектантов часто объяснения вообще не имеют. Хрен бы с ними с сектантами, но за эти годы они отшлифовали свой пропагандистский потенциал и закалились в десятках холиваров mega vs stm. У свистящего в рукаве сотни примеров с уже доказанным и обсосанным десятки раз со всех сторон тотальным доминированием stm32 (что и на самом деле правда), где stm32 заранее поставлен в более выигрышные условия.

  Интересно, а STM шисти пиновые бывают? Мне вот для одной работы attiny10 в самый раз. А что есть самого мелкого у STM?

Самое маленькое -- TSSOP20. QFN еще есть, но паять менее удобно. Ну и назначение у стм все-таки не простейшие автоматы на них ваять.

Спасибо за предупреждение, про секту слышал, а списка участников не видел, кто в ней узнаю эксперементально. Я пожалуй продолжу ;)

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

ИМХО, очень похоже на правду. Ну .. мне такая категория "специалистов" хорошо известна (сам когда-то учил) .. продаваны это. Поэтому, заготовок полно, но "шаг влево-вправо" от методички .. ни-ни. :)

Та ладно... Знание референса ещё никому не вредило... это не сложно... )))))))))

Вот же ж, обломал веселье. ))))))))

Дык, можем и СТМ8 поставить в выигрышные условия... легко! На самом деле всё проще - новые камни есть новые камни. Они никак не могут быть хуже старых, по определению. СТМ32 и взлетел на наилучшем соотношении цена-периферия-ядро-производительность. Я не вижу преимуществ меги перед СТМ32, ни в чём. И это действительно всё уже давно обхоливарено.

Смешно читать такое, но пусть. )))))

Сами хоть без методички пробовали? Ну там типа удивить самого себя? Сделать то, что другие считали невозможным? Попробуйте, а вдруг поймёте о чём речь.

Знакомые мантры. Как немыслимое достижение подносится знакомство с одним единственным источником технической документации. Добро бы сами наизусть знали, так нет, путаетесь постоянно.

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

Когда одни ищут возможности, другие ищут причины.

Я вот как раз и пилю сейчас логгер на stm8, который прежде обкатал на ардуине. Вы как раз об этом сюда цитатку с "другого форума" неизвестно зачем приперли. Я говорю о предмете на основе свего конкретного опыта, а вы про немыслимые мега-проекты в вакууме все больше.

Сильно спорное утверждение в условиях тотальной копроэкономики. Я бы даже сказал некий "сигнальчик" к насторожиться. Спасибо. :)

Поставлю эту фразу под сомнение. Да, есть аппаратные функции, да тактовая кратно выше и т.д. Но! В реальной работе НЕТ бесконечных ЧИСТЫХ задач в виде "только ногодрыг", "сплошное деление", "вечная передача одного байта по SPI" и т.д. Такие вот "очищенные" типа задачи - и есть те самые "выгодные условия" в разного рода холиварах.

В действительности, передача по ДМА всегда сопровождается операциями по настройке и подготовке буфера передачи .. передать 100500байт .. их надо ещё и подготовить, считать, да порциями; проверить CRC ответиться и не один раз .. т .д. И, как показывают те же интеловские чудо-камни .. увы и ах. При гигагерцах тактовой однако задачи 3D отрисовок делают на специальных видео камнях .. как ни странно.

То же самое и здесь: какое преимущество или отставание покажет Мега или СТМ - сильно зависит от специфики объемов, источников и потребителей этой передачи. Тут специфирован только экран. Даже для 320х240 это под 150кбайт .. и? Где мега возьмет их? А озвученный вначале топа СТМ? Если гнать 0х00, то разница скоростей будет ровно та, что определена разницей тактирования интерфейсов .. а если это динамически формируемая картинка, то без указания источника - разговор пустой.

Ну и ещё одно замечание: "кратно большая моща" .. это в общем-то переход с разряжности 8/16 на 32. Этот переход всегда сопровождается ростом потребляемой памяти. И именно поэтому, этот момент так сильно возбуждает всех продаванов.

Отличить продавана от спеца на самом деле легко: второй всегда пляшет от задачи "камень выбирается по задаче", а первый всегда рекламирует только то, что продает "есть моя няшка, остальное дерьмо". :)

Да, и упс .. дифф. режим АЦП вменяемо нашел только в линейке F7 .. это даже не смешно. То есть, кроме задач отрисовки на TFT и пения гимнов через DAC, этот камень мало на что заточен.. ;)

Следуя вашей логике, мега вообще ни на что не способна, т.к. она на порядок слабее СТМ32. Особенно радует ваш вывод, который ни на чём не основывается. А может вы слегка загнули? Или вы просто поёте то, что вам нравится?

Ну, что вы .. по сравнению с вами, я просто скромно ретранслировал ВАШИ ДОВОДЫ .. вы просто не замечаете насколько смешно они смотрятся .. :)

По вашему хардварный 1-вирэ это смешно? Или хардварное управление WG12864? Как тогда выглядит ногодрыг меги, архиубого? ))))))

Вот картинка 1-вирэ. Это даже не СТМ32, это СТМ8. И это не хардварное, это полухардварное решение на прерываниях. Как видно, майн коротко прерывается и спокойно продолжает выполнять свою работу. Что может предложить мега? Ногодрыг и и задержки с 100% торможением ядра? Замечательный результат! )))))))))))

Ну, какбэ, мега предлагала делать это через UART полностью хардверно, когда никаких stm8 еще и в проекте не было.

Во-первых, это не мега предложила, а Даллас. Во-вторых, на это счастье есть два горя - у меги всего один ЮАРТ, который где-то нужен и пины ЮАРТа могут быть задействованы под что-то другое. В общем - опять всё плохо и безобразно.

Бредишь? У меги четыре аппаратных UART. Если под мегой подразумевается Arduino Mega, конечно. Если же просто атмега - тогда звиняй, суслики бывают разные, надо уточнять, о чём пишешь.

4 USART, а не UART ваще-то .. это в Ардуино забыли SLK поразводить на пины. Допаиваются при необходимости.. Да, и аппаратный SPI там тоже есть и вполне себе отдельный. :)

P.S. посмтрел даташит по SPI Меги .. ну и? F/2 на 16Мгц обеспечивает скорость передачи в 1 мегабайт/сек и при заранее подготовленном буфере в обработчике прерывания потребуется 3 команды из 16 возможных для 1мксек: загрузить байт в регистр (Z+), загнать его в SPI и выйти из прерывания. Это занимает 7 тактов из 16, то есть менее 50% процессорного времени.

P.P.S. А xmega на своих 32 мгц и f/2 вполне обеспечит и 4 метра/сек и CRC она аппаратно считать умеет и 2 канала DMA имеет  и много чего иного .. :)

Да упаси господи! За это деньги можно купить две 071-х с 4 ЮАРТ или почти две 091-х с восемью ЮАРТ! ))))))))

Остальное приложится как бесплатный бонус. )))))))))

по поиску arduino vs stm32 наверно все смотрели тест сравнение с TFT LCD SPI в ютубе https://www.youtube.com/watch?v=4tHqjNFzVtg  ? . Тамже как то видел и такой же тест на камне esp8266 , тож довольно таки шустро https://www.youtube.com/watch?v=3t1OYnYHo9k , кажись ещё быстрее чем STM32 . И что-то esp8266 и Teensy 3.2 уделывает  (Teensy 3.2 построена на 32-разрядном ARM-процессоре Cypress MK20DX256 с ядром Cortex-M4, частотой 72 МГц, 64 кБ оперативной памяти и 256 кБ энергонезависимой Flash-памяти)  https://www.youtube.com/watch?v=cZk3LW8bS70 .  

//ради быстрого вывода на дисп и прикупил себе попробовать STM32 и ESP-12.

чтобы приводить тесты, надо выдавать исходники, дабы можно было понять что и как написано. А так ..

Я и ещё медленнее написать могу, и чё? :)

Допускаю, что конкретно Вы - можете, но алиэкспресс утверждает что это НЕ ТАК: http://ru.aliexpress.com/item/STM32F071CBT6-IC-MCU-32BIT-128K-FLASH-48LQFP-32F071-STM32F071-3pcs/32478656423.html .. даже и подороже меги2560 выходит, однако. :)

А это цена на xmega при тех же условиях поиска http://ru.aliexpress.com/item/ATXMEGA128A1-AU/32432065375.html, однако..

Можно подумать, что у СТМ32 нет аппаратного КРК и нет ДМА. Смешно!

Можно подумать, что у меня опыт в продажах побольше вашего .. ;)

Можете и не думать. Брать мегу2560 для 1- вирэ не слишком ли жирно? )))))))))

Я справлюсь с 1-вирэ в несколько каналов (полухардварно) на полукопеечном СТМ8С003, даже если ЮАРТ будет занят. Ещё ИР-датчик прицеплю и семисегментник. Ну или вместо ИР-датчика несколько полухардварных ЮАРТов. Расставил приоритеты прерываний и всё летает и шевелится. ))))))))))

Да справляйтесь сколько вам влезет! Можете даже через микрофон самостоятельно в SPI попищать .. расставьте приоритеты и "вперед". :)

Я к тому, что ВСЕ ВАШИ АРГУМЕНТЫ - сдулись. А вот на мои вопросы, Вы ОТВЕТИТЬ НЕ СМОГЛИ и "замяли для ясности" .. в общем, слив засчитан. Не умеете вы оппонента троллить и товар пгодавать .. не так надо было .. :)

Какие именно, по пунктам. А то ваше "все" это "ни о чём". )))))

А как вам такой аргумент. Сможете на меге сделать частотомер с reciprocal counter, с верхней частотой измерения этак МГЦ под 80, для начала? Без внешних навесов, чисто МК? Ась? СТМ8 может, СТМ32 может и поболее. А как дела с этим у меги? )))))))

А частотомер канала на три-четыре, пусть даже с прямым счётом, мега смогёт? )))))))

Меге разве не надо делать то же самое? Плюс, меге придтся по байтику толкать это дело в SPI, от чего микроконтроллеры с DMA освобождены по определению. Как раз DMA тут обеспечивает, что пока идет передача, процесоор может спокойно заниматься всеми необходимыми манипуляциями с буфером. Насчет затрат по обслуживанию DMA-передач тоже не стоит сгущать краски. Это несколько команд, что на общем фоне погоды совсем не делает.

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

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

Мы уже говорили на этот счет. Значительному росту взяться неоткуда. У stm32 существуют отдельные команды для оперирования данными разной разрядности.

Да что вы вцепились в этот дифф. режим? Не так много задач, где он может быть восстребован. А если перечислять уникальные фичи, то STM32 просто затмит атмегу.

Поймите простую вещь -- не нужно противпоставлять эти МК "в лоб". В cиловой схватке преимущество на стороне STM32. Однако, существует широкий спектр задач, которые могут быть решены проще, быстрее, удобнее на атмеге, чем на stm32.

Недавний пример из моей практики. Делал несложное устройство, управляемое по радио. Слушает эфир, при обнаружении определенной последовательности данных, осуществляет управление нагрузкой. Устройство коммутации нагрузки готовое, логика в силовой части -- пятивольтовая, основное питание, соответственно, тоже. Прелести STM32 на этой задаче немного потускнели из-за необходимости трехвольтового питания и преобразования уровней. Шансы у STM8S и атмеги, напротив, возросли. На этом этапе выбор начал склоняться в пользу атмеги уже потому, что для нее лучший набор средств разработки, больше готовых полуфабрикатов и похожих решений. Писать код для меги проще.

Новоприбывший сектант тут намедни хвалил stm8 и, как водится, вещал штампами. Типо, только stm32 и stm8 достойны внимания, а кто отрицает это, тот лох и придумывает отмазки. Я уже тогда хотел возразить ему, что в первую очередь лох тот, кто кроме пары шаблонных фраз ничего вымолвить не может, но сдержался. Теперь я все-таки разовью тему, почему STM8 не прошел и никак не мог пройти по условию конкретно моей задачи.

В отличие от STM32 и амтеги, STM8, неизвестно с какого перепугу, имеет иной порядок представления последовательности байтов. Атмега и STM32 оперируют порядком от младшего к младшему (little-endian), а STM8, наоборот, от старшего к младшему (big-endian). Это может и не было бы проблемой, если бы не одно "но": данные в эфире у меня передаются в виде упакованных записей и границы битовых полей не совпадают с границами байтов. Просто поменять местами байты на приемной стороне не выйдет -- ломается структура битовых полей. И не просто битовых полей, а мешанины из знаковых и беззнаковых значений. Нет, все можно переконвертировать, вытащить ручками по одному биту, восстановить знаковость и т.д. Не сомневаюсь, что члены секты так бы и сделали (особенно в случае воображаемого решения этой задачи). Только для меня служение их божеству не является основным смыслом жизни, задача у меня была не воображаемая, а реальная, поэтому я просто выбрал атмегу, где никакой лишней возни (а она грозила подзатянуться) просто не требуется. Я тупо взял все описания структур из кода передатчика (STM32) и перенес их без единой правки в код приемника (Atmega8) и получил доступ к нужным данным немедленно.

Какую мораль можно вынести из всей этой реальной (подчеркиваю) истории? Хороший процессор STM32 ? Не то слово, процессор отличный. А STM8 ? И STM8 очень даже неплох. А что ж тогда в дело пошла атмега, которая дервняя, примитивная и вообще плохо смотрится на фоне этих первых двух? Да просто она намного лучше подходит для решения этой конкретной задачи и требует меньших усилий в рализации нужного функционала. Вот и вся мораль.

ssss, утихомирьтесь уже. Под каждую задачу - свой МК, в этом я согласен с Arhat109-2.