И хорошо и плохо одновременно. Показатель того, как мало информации о новых изделиях... И соответственно отставание, которое вероятнее всего уже не наверстать... (или весьма сложно догнать будет) Там только главный даташит "Preliminary" на АVR128 в 619 страничек, не включая еррат и дополнений... А ведь это не единственная новинка... Хорошо в смысле таки продвижения "старых знакомых", пусть даже уже в совершенно незнакомом виде. А вот насчет "единой IDE"... тут уже кто к чему привык. Замена только стиля оформления документации уже штука малоприятная. Потребуется некоторое время для того, чтобы приспособиться.
Воть потому, что не охота вечно бежать и грызу старые компиляторы да замшелые МК. У микрочипа СВОЙ компилятор... Иногда платный... Там разница с GCC достаточно существенная - обусловлена особенностями ПИКовых... У нас по ПИКовым больше информации у КРАМ получить можно.
Последний раз редактировалось BOB51 Ср июн 03, 2020 23:40:03, всего редактировалось 1 раз.
"The AVR128DA28/32/48/64 microcontrollers of the AVR-DA family are using the AVR® CPU with hardware multiplier,running at up to 24 MHz, with 128 KB of Flash, 16 KB of SRAM, and 512B of EEPROM in 28-, 32-, 48- or 64-pinpackages.
МК как МК. Ничего особенного. Тактовая низкая. Памяти относительно не много. Сколько они стоят?
BOB51 писал(а):
Показатель того, как мало информации о новых изделиях
На них нет даташита?
BOB51 писал(а):
Воть потому, что не охота вечно бежать и грызу старые компиляторы да замшелые МК.
Речь не о наличии/отсутствии даташита, а о том, что особо никто просмотром сайтов производителей не занимается. И обзоры новинок АВР МК не наблюдаются. Цена, ежли успели посетить сайт по ссылке, там указана - базовая от производителя. Об осоденностях аппараьной начинки разговор отдельный (ибо до.... страничек). Да и не одна там "новинка" - это всего лишь для примера взято. Кстати... мегой 8 я не увлекаюсь - не слишком удобный кристалл, хотя в любительских конструкциях весьма распиаренный...
Скорее не мода, а черезмерное усложнение периферии... Ядро то осталось прежним, а разбираться с аппаратными вкусностями детально да в полном объёме... Это при нынешнем объёме документации весьма сложно. Вторая причина - изменение структуры сайта производителя и собственно оформления самой документации. Третье - малое распространение на отдельных территориях. Причина слабой востребованности в радиолюбительском обиходе супернашпигованных аппаратной периферией МК также имеет место. Ведь большинство рутинных бытовых задач такого обилия средств не требует. В то же время как минимум необходимо неиспользуемые модули в обязательном порядке корректно отключать при запуске МК. Да и цены ессно повыше. Относительно наиболее удачной концепции ядра... Из имеющихся вариантов я бы отдал предпочтение подвиду PIC24, ёжли бы те МК были "более демократичны" по ценам/доступности. Мурик Я ведь не кристалл atmega328 использую, а ""DIP-микросборку" марки ардуино нано или ардуино про-мини". Это не совсем одно и то же. По сути такое применение равноценно использованию некоего МК с собственным набором команд и собственным компилятором. Также кстати как и применение той же "синей пилюльки" или иных "DIP-микросборок", входящих в комплект, обрабатываемый "arduinoIDE "компилятором"".
Даташит не читал, но судя по описанию, периферия не такая сложная. Бывает сложнее. Но какой смысл в сложной периферии при слабом ядре? Оно не успеет обрабатывать все запросы. Это все равно что в комп поставить мощную видеокарту и самый слабый процессор и 128 МБ ОЗУ. Толку от видеокарты? Непопулярность новых PIC и AVR из-за их слабого 8-ми битного ядра. Сейчас хватает МК с более производительным ядром и периферией и при этом стоимость на уровне и дешевле новых AVR. Кто хочет платить больше, а получать меньше?
BOB51 писал(а):
Ядро то осталось прежним
И это большой минус МК! Представьте что вы из мотоцикла сделали гоночный автомобиль, а двигатель остался тот же. Что получится?
BOB51 писал(а):
Третье - малое распространение на отдельных территориях.
Потому что упустили рынок. На нем появились дешевые производительные МК, а у микрочипа и Atmel таких не оказалось.
BOB51 писал(а):
Причина слабой востребованности в радиолюбительском обиходе супернашпигованных аппаратной периферией МК также имеет место.
Если радиолюбителям нужен мощный МК, они используют STM32. Потому что дешево, много статей, много IDE включая бесплатные. С доставаемостью сложностей нет. Очень дешевый отладчик и многое другое.
BOB51 писал(а):
Ведь большинство рутинных бытовых задач такого обилия средств не требует.
У всех задачи разные. Вот к примеру если нужно решить простую задачу я возьму копеечный (0.30$) STM32, а не PIC или AVR. И многие поступят также. Почему? Во первых лучше хорошо знать МК одного производителя чем посредственно разных. Во вторых, отладка. Она экономит время. В дешевых и простых PIC и AVR ее нет. В третих IDE. Когда есть выбор примерно из 20 IDE подбираешь ту что больше подходит, а не ту что предоставил производительно МК и без альтернатив! Тоже касается компиляторов.
BOB51 писал(а):
В то же время как минимум необходимо неиспользуемые модули в обязательном порядке корректно отключать при запуске МК.
Они при запуске должны быть отключены. Их необходимо включать если используются. Если это не так, то в топку такие МК!
BOB51 писал(а):
Из имеющихся вариантов я бы отдал предпочтение подвиду PIC24, ёжли бы те МК были "более демократичны" по ценам/доступности.
До 32-ух бит не дотягивают, а это влияет на производительность.
BOB51 писал(а):
Я ведь не кристалл atmega328 использую, а ""DIP-микросборку" марки ардуино нано или ардуино про-мини".
В чем разница? Это МК с обвязкой и не более того! Или хотите сказать что ATmega328 в ардуине отличается от оригинальной?
BOB51 писал(а):
По сути такое применение равноценно использованию некоего МК с собственным набором команд и собственным компилятором.
Чего? Хотите скачать что в ардуине не оригинальный ATmega328 и что компилятор на GCC?
Надоело уже повторять - подход к ардуиноподобным с точки зрения используемого МК в корне неверен - мы имеем дело с DIP микросборкой имеющей выводы и определенную в референсе возможность выполнения набора команд. А что там внутри - это уже вторично "черный ящик". Дело пользователя - определить чего необходимо делать внешним выводам платки. При таком подходе каждая платка/платформа всего лишь еще одна разновидность элементной базы. Второй подход - использование платки как уже изготовленного фрагмента конструкции с разработкой программы под конкретный МК, установленный на платке это уже не ардуина, а стандартная работа с обычным МК (минуя стадию первичного монтажа деталюшек). Этот вариант и так в других темах достаточно проработан. И ничем от стандартной работы не отличается. Но то уже не работа под ардуино, а использование заранее собранного фрагмента конструкции будет.
Последний раз редактировалось BOB51 Чт июн 04, 2020 20:28:39, всего редактировалось 1 раз.
Если с чем-то не согласны - конкретизируйте. Я не то что ругаю 8-ми битники. Просто они устарели по сегодняшним меркам. Да, они позволяют решать задачи, но есть МК позволяющие их решить проще и эффективнее.
BOB51 писал(а):
мы имеем дело с DIP микросборкой имеющей выводы и определенную в референсе возможность выполнения набора команд.
Это просто отладочная плата! Набор команд - асм инструкции МК.
BOB51 писал(а):
А что там внутри - это уже вторично "черный ящик".
Это неэффективно. Вы не всможете использовать все возможности ограничиваясь только определенным набором команд когда платформа поддерживает значительно больше! Но дело ваше. Вы себя этим ограничиваете.
самый несчастный человек тот, перед которым бесконечный выбор вариантов. человек, который сам себя ограничил в выборе гораздо ближе к счастью.
если вы этого не понимаете, то уверен, с возрастом это пройдет (или придёт, как посмотреть). но, пытаясь причесать всех своей гребенкой, вы постоянно оказываете медвежью услугу. хотя бы это вы можете понять, что выбор - дело добровольное? любой выбор под давлением - это не выбор, а сдача на милость победителя!
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Я прошел через PIC и AVR. Писал на асме и я четко понимаю все достоинства и недостатки 8-ми битников. Переход на 32-ух битные МК значительно облегчил разработку. Так то я не просто так пишу про ограниченность и про топтание на месте. Нужно двигаться дальше, а не вцепится в МК 20-ти летней давности и отвергать современные.
Никто более навороченное не отвергает - каждому изделию свое применение. Однако не делать же простейшую автоматику на многоядерном процессоре. Насчет ограничений при работе с платками адуринки... Если для решения задачи достаточно имеющегося в "черном ящике" набора средств - то это и будет оптимальным решением. Не хватит имеющегося - тогда и будут рассматриваться иные варианты. На сегодня я еще даже всеми заложенным в ассемблере средствами не пользовался - только из интереса пробы сделал... Смысл доказывать преимущество, если необходимости в его применении еще не возникла? Да и как уже ранее выяснили ардуино IDE все-таки имеет элементы С++... Насчет "те же команды ассемблера"... Дело тут несколько иначе рассматривать надо. Вы ведь сторонник новых подходов, и освоения? В случае с ардуиноподобными к сожалению многие пали жертвой стереотипа. Возможно в немалой степени из-за "двойственности" самой идеи дуинки (недаром это в ее незвании читается). можно с теми платформами по старинке на низкоуровневом программировании работать, а можно и иначе - отбросив начинку и низкоуровневое программирование - принять модель "черного ящика" с системой команд соответствующей референсу IDE. Да, с точки зрения ассемблера или чистого Си в отношении конкретного МК на конкретной платке это значительное ограничение возможностей. Но у нас ведь и подход другой. А значит никаких ограничений относительно "черного ящика" в принципе не наблюдается, как и необходимости знать что у него внутри (и как те потроха настраиваются). Так что без лишнего фанатизма причисляем ардуиноподобные к новому "кубику" в арсенале имеющейся элементной базы. Вопрос где и что из имеющихся ресурсов использовать - решается по мере необходимости.
Однако не делать же простейшую автоматику на многоядерном процессоре.
Многоядерные МК конечно есть, но они пока не перешли в массовый сегмент. Так что подождите немножко.
BOB51 писал(а):
Если для решения задачи достаточно имеющегося в "черном ящике" набора средств - то это и будет оптимальным решением.
Решение может быть оптимальным, а может быть "так что лишь бы работало". На ардуинах обычно получается второе. Чтобы было первое, нужно перейти от функций ардуины к регистрам. Не нужно привыкать к стилю "тяп-ляп и работает". Обычно это крайне не оптимально. Например загляните в библиотеку работы с сервоприводами. Она требует много ресурсов МК. И это вместо того чтобы по нормальному использовать несколько десятков ШИМ в современных МК что вообще не требует участия процессора. Разницу замечаете? С остальными библиотеками также.
BOB51 писал(а):
Смысл доказывать преимущество, если необходимости в его применении еще не возникла?
Не все теоретики. У многих задачи превышают возможности ардуины и начинается былосборка - несколько адруин там где при оптимальном написании кода хватило бы одной.
BOB51 писал(а):
Да и как уже ранее выяснили ардуино IDE все-таки имеет элементы С++
Вообще-то если не знали у ардуины компиль GCC, т. е. язык C/C++.
BOB51 писал(а):
Но у нас ведь и подход другой. А значит никаких ограничений относительно "черного ящика" в принципе не наблюдается, как и необходимости знать что у него внутри
Если писать для ARM или ESP как для AVR, в итоге получим возможности как у авра. Это так к сведению если не знали. Проще вместо ардуины взять современные 32-ух битные МК и они станут универсальным инструментом для решения задач. Т. е. использовать одну мощную платформу по полной, чем несколько на 10%.
Мурик Вот как раз "стандартное" восприятие адуринки как "просто МК на платке" при работе в рамках среды так же как и в рамках стандартного GCC "в чистом виде" и приводит к большинству ошибок. Собственно в состав IDE введены функции использующие аппаратные модули "по собственному усмотрению" авторов IDE. Если в такой ситуации не зная внутреннего обустройства тех настроек гнать привычный для применения в рамках "чистого GCC" код, использующий аппаратные модули по усмотрению автора конкретной конструкции конфликты неизбежны. У большинства пользователей ессно нет необходимого опыта для подобного "глубококопания". Вторая частовстречающаяся ошибка - отсутствие учета специфики схемотехники. Это правда и обычных конструкций сплошь и рядом касается, но в случае "DIP-микросборки" особо заметно. Дополнительные сложности накладывают установленные на многих платках системы распределения питания (особо в случае устаноывки USB-TTL мостов "на борту"). Описаний данных тонкостей найти весьма сложно - приходится собирать из разрозненных источников по крупицам... Тем более, что у каждой из платформ свои нюансы, относящиеся к аппаратной начинке используемых там МК - это на случай, ежли внезапно какой "выпендреж" захочется сотворить за рамками референса. Ежли уж о компиляторах, применяемых в ардуиноIDE вести речь, то высказывание "... BOB51 писал(а): Да и как уже ранее выяснили ардуино IDE все-таки имеет элементы С++ Вообще-то если не знали у ардуины компиль GCC, т. е. язык C/C++.
BOB51 писал(а): Но у нас ведь и подход другой. А значит никаких ограничений относительно "черного ящика" в принципе не наблюдается, как и необходимости знать что у него внутри Если писать для ARM или ESP как для AVR, в итоге получим возможности как у авра. Это так к сведению если не знали. ..." противоречит самому себе - ибо в arduinoIDE для каждого семейства применяется соответствующий компилятор и дополнительные инструменты - т.е. для АРМ платформ используются АРМ компиляторы, для ESP - свои инструпенты (и весьма навороченные). В рамках IDE ВСЕ платформы оцениваются КАК РАЗНОВИДНОСТЬ УСТРОЙСТВА (платформы, DIP-микросборки) семейства АРДУИНО, а не как АВР, АРМ или иные МК в рамках разницы между семействами МК имеющейся. Поэтому де факто во всех случаях мы должны получить результат с ВОЗМОЖНОСТЯМИ КАК У АРДУИНО, а не "как у АВР"или "как у АРМ" или иных МК, в рамках ПЛАТФОРМ использующихся. Это более аналогия универсальной ОС, одинаково работающей на разных ПК, ноутах и прочих устройствах. Кстати... а чего Вы можете высказать насчет моих мыслей по работе с директивами условного ассемблирования (avrasm2/c51asm)? Диапазон видимости, разница между директивами с префиксами в виде точки(.) и слэша(#)? Это начиная отсюда https://radiokot.ru/forum/viewtopic.php ... 3#p3849033 и по https://radiokot.ru/forum/viewtopic.php ... 3#p3849603 включительно? Возможно приходилось встречаться с подобными вопросами при работе под ассемблером с "большими проектами"...
Вот как раз "стандартное" восприятие адуринки как "просто МК на платке" при работе в рамках среды так же как и в рамках стандартного GCC "в чистом виде" и приводит к большинству ошибок.
Все наоборот. Незнание МК и компилятора приводит к ошибкам и не оптимальному коду. Но вы можете верить в свою правоту если хотите, но правы от этого вы не станете.
BOB51 писал(а):
Собственно в состав IDE введены функции использующие аппаратные модули "по собственному усмотрению" авторов IDE.
Куча кривых и не оптимальных функций. Смотрите как устроена функция digitalWrite.
Как считаете не слишком много кода чтобы изменить стояние вывода? По нормальному это требует пары асм инструкций. А код ардиуны потребует на несколько порядков больше! Но вы можете и дальше твердить про "черный ящик" совершенно не представляя какой былокод в нем!
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 20
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения