> Зачем мне DMA в микроконтроллере? Затем что попросил его перегнать данные "от забора и до обеда" и пошел заниматься своими делами. Хреново если процессор целиком занят работой с и-фейсом и на остальное времени почти не остается - при таких условиях программирование превращается в кластерфак с кучей нетривиальных моментов которые надо постоянно учитывать. Если уж приличный поток данных - логично зарядить DMA-автомат и уже он дальше будет упираться. Не занимая процессорное ядро.
> Лучше бы АЦП скоростной встроили, а то такое же гумно как и у AVR.
А смысл? До нескольких мегасэмплов - в uC бывает. Надо сильно больше? Берите любой внешний АЦП и хапайте с него данные, лопатой. Если сможете прожевать. Это уже нишевая задача для тех кто готов глубоко сунуться в нетривиальную область - скоростной обработки данных в реальном времени. Там экономия нескольких баксов на внешнем чипе - ни о чем. Btw, микроконтроллеры сами по себе не очень то и заточены на ТАКИЕ вещи - скоростные осциллы обычно хапают данные с скоростного ADC с помощью плисины, если что. А DMA - как раз некая простейшая "generic" подпорка подобного плана, позволяющая разгрузить проц от потоков данных по типовым направлениям без хардкорного программирования плисин. Но при этом о какой-то умной постобработке речь не идет - DMA только гоняет данные.
Цель DMA? Избавить проц от дерганий на каждый вшивый байтик по вон тому интерфейсу и прочая. В обычной interrupt driven модели - проц на большом потоке данных будет телепаться между состояниями (основной поток <-> interrupt) и сохранять контекст и прочая уйму времени, оверхед превысит все разумные рамки, основную часть времени проц будет телепаться между обработчиком и основной программой. Сильно частые прерывания - зло, ибо отнимают время у процессорного ядра на чисто технические операции не ведущие сами по себе к какому либо практически полезному результату (aka реализация логики программы).
> Плохо, но еще хуже когда для элементарной операции нужно перелопатить кучу доки и 100500 регистров.
В минимальном варианте знать надо минимум. То-есть, если вам не надо DMA - никто и не заставит его программить. Хуже когда вы понимаете что вам это очень надо, а его раз и нету. Это залет. Вообще, когда производительности или фич периферии не хватило в эмбедовке - это FAIL. В этом плане атмеги вчистую проcpaли гонку. К тому же 32-битник нормально масштабируется и спокойно относится к набортным паре мегов флеша и 256 кило RAM, etc. Костыли если и есть то минимум. А на 8/16 битных процах все упрется в куцый адрес, появятся костыли с банкированием и прочим. Нейман с линейным универсальным адресным пространством без банков и прочих костылей - это лютый win.
> ИМХО это и есть "уйма долботни на ровном месте".
Можно скопипастить готовые примеры из гугли или использовать либы-прослойки, если уж страшно. Ну да, для мигания светодиодиком - атмега проще. А чуть за пределы этого - тут бывает и что пару дополнительных регистров запрограммить проще чем невъ....ю логику с костылями и проблемами производительности наворачивать. Как раз касается претензий на сколь-нибудь быструю работу с интерфейсами и прочая.
> Здесь преимущество STM32 однозначно, но не так часта она нужна.
Урезать скорость - гoвно вопрос. А если скорости не хватило - это уже просто полное гoвнo. Без вопросов. Современные uC обычно fully static design и нормально относятся к частотам от каких-то килогерц до внушительных десятков, если не сотен, мегагерц.
> Зачем бутлоадер и весь описанный гемморой. У меня большинство программ меньше, чем
> этот бутлоадер будет. Зачем усложнять?
Затем что нормальному человеку свойственно хотеть удобства и универсальности. Таскать железку на программатор для апдейта фирмвари - КАМЕННЫЙ ВЕК. Собственный бутлоадер может получить новую прошивку по произвольному интерфейсу/протоколу/под кастомные требования. Если железка где-то в недрах черти-какой инсталляции, выдирать ее оттуда совершенно не с руки, а так вышло что нашелся какой-то жирный баг - нормальную систему можно отапдейтить, починив баг.
Не говоря о том что требование *кастомного* хардварного программатора под *нестандартный* битовый протокол - не очень удобная штука. Если какой-нибудь там UART и USB достаточно массовые коммуникационные и-фейсы, поэтому встроенный/референсный бут получающий прошивку по этим и-фейсам - весьма удобно. В том плане что не требует никакого особо кастомного хардвара (переходник usb-uart или просто кус провода в usb у разработчика обычно есть).
> Да ладно, не весе так страшно ;) Мне вот нравится через LPT
> шить - схема проще не придумаешь.
Круто, но вот только LPT нет на большинстве современных компьютеров, да и скорость и надежность работы всего этого - ниже всякой критики. У...щные решения из эпохи DOS'а. Есть более человеческие решения типа FTDI2232 и прочих. Но послать байты в UART (что родной писючный, что USBшный) или данные по usb через либу типа libusb - сильно проще и быстрее чем заниматься утонченным кластерфаком с дерганием битиков кастомного последовательного протокола самолично, да еще с писюка.
STM32 в этом плане хорош тем что есть как фабричный лоадер в ROM, так и если он не нравится - можно отказаться от пинка ROM совсем и проц будет сразу с флеша стартовать, так можно свой бут на замену оного в флеше сделать. Если это надо. А если лень - можно предусмотреть старт того который в ROM. Обеспечить состояние пары выводов при ребуте и потом связаться по стандартному UART или USB явно проще чем возиться с кастомным битовым протоколом, где еще куча всяких дурных заморочек.
Если бы атмел не был бакланами - они бы могли шить какой-нибудь референсный лоадер грузящийся с UART/USB в boot область, которая что забавно, в тех же атмегах и вроде даже некторых тиньках есть. Но это не сделали и сие превращается в проблемы юзера, требуя кастомный программатор под кастомный последовательный протокол, не типичный для писючных интерфейсов. Ардуинщики и те кто рядом - на этом нагреваются, прошивая свой лоадер и таки фикся за атмелом упущение. Вот только одно дело если атмел сам запрограммит референсный лоадер в процессе производства и совсем иное - если это какие-то внешние перцы, желающие за эту работу отдельных бабок, при том что чип и так не дешевый.
> Нафиг эти буты - неужели так сложно МК перешить?
Таскаться на программатор - ламерство и каменный век. А опытные специалисты досыта наелись такого "счастья" еще в прошлом веке, добавку просить не будут.
Вообще, представьте себе: все смонтировано, заEMBEDDнуто куда-нибудь в ж.... ну в общем embedded поэтом так и называется, что запихивается туда где не светит солнце, установлено за тридевять земель. И тут вы понимаете что в вашем девайсе - критичный баг. Вы попретесь выколупывать эту атмелку из вон того агрегата у черта на куличиках?!
> Скорость разработки? Пол бакса сэкономишь (и то если повезет), день потеряешь.
С учетом ограничений атмела, большой вопрос кто и что там потеряет и приобретет. Ардуинщики которые рискуют здоровьем всерьез сунуться в область - очень быстро обнаруживают что у ардуины довольно много не самых удобных ограничений и по мере роста аппетита процесс все больше напоминает борьбу с рантаймом для нубов и запрыг по граблям.
> Какому хацкеру нужна ваша непонятная система, неизвестно что передающая и принимающая?
> Хватит элементарного контроля суммы.
А в результате помнится ШКОЛЬНИК разломал кастомный протокол перевода стрелок трамваев и ... сделал пультик. Переключающий стрелки. Закончилось тем что школьник перевел стрелку прямо под трамваем и трамвай сошел с рельс. Тогда школьника конечно изловили, но по хорошему надо бы еще таким разработчикам впаивать за преступную халатность. Все-таки некоторые вещи ДОЛЖНЫ быть адекватно защищены. Не айс, если какой-то школьник может пощелкать стрелками под трамваем только потому что разработчики этой системы посчитали так же как вы.
> Для меня важна цена.
Странно. То с атмелом она вам пофигу, то теперь вот важна. Интересная у вас истина - крутится как флюгер на ветру.
> Поэтому и смотрел в сторону STM32, но скорости для дисплея не хватает.
Сильно зависит от дисплея и STM32. У больших систем с линухом основной плюс - в том что работу с дисплеем за вас на 90% делают другие :)
> Это простой и эффективный контроллер. Термостат - 25 строчек на C, чтение
> температуры через ADC.
Если уж на то пошло, термостаты и без всяких микроконтроллеров сто лет делали. Не, направление мысли мне нравится - "цифровое самообслуживание" в таких вещах это хорошо. но 25 там строчек или 50 - не так уж принципиально на фоне остального времени изготовления этой конструкции, например.
> Проблем с местом не испытываю чего и вам желаю :)
Спасибо, конечно, но микроконтроллеры применяются в уйме мест где место (тавтология) ограничено. Хоть в том же многорежимном фонарике - чисто технически нет места на DIP корпус, например. И таких применений на самом деле много. Маленький девайс можно упаковать в большой корпус, а наоборот - фиг. Поэтому я за миниатюрные чипы.
> Дипы удобны для макетирования, а в для домашних разработок это практически постоянное явление.
Опять же - если мне будет надо, через 2 часа у меня будет лежать на столе кус текстолита, разводящий лапки QFP/QFN на удобное расстояние. Но обычно схемы на небольших uC достаточно тривиальны для того чтобы схема и разводка вышла с 1 раза и смысл этого для меня не совсем очевиден.
> ЛУТом пользуюсь, если макетки не годятся по помехозащищенности или девайс отлажен
> и нужно несколько штук. Для перепрошивки мне проще вытащить МК, чем
> тянуть весь девайс (да и не всегда это возможно) или ноутбук
> (иногда далеко).
Ну понятно - на выходе обычно ссыкотный клубок проводов по принципу тронь-развалится, а проц надо выдергивать. А я не сторонник такого uC-гoвнарства. ИМХО если уж берешься что-то делать - делай на совесть. Не, ардуино и т.п. хороши для обучения ... но провоцируют стремную халтуру от дилетантов.
Вариант для распечатки
