>> AVR, как и мк в целом, нишевый продукт. Со своими обязанностями он
>> справляется хорошо. Каких новшеств вы ждете от мк?
> Ну вот например, у STM32 много таймеров. Некоторые из них - навороченные.У avr тоже обычно 3-4 таймера + PWM.
> Скажем под "motor control", или подобные применения. Они могут много чего.
> Ну там генерить 3 фазы. И/или вставлять "dead time". Совсем уж
> софтварно dead time силовой электронике не хотелось бы формировать. А еще
> оно просто быть "просто пачкой PWMов". А то и просто отдельным
> таймером, если все это не надо.
Не совсем в курсе, но вроде atmega128 может что-то подобное. Да и для таких задач должны быть специализированные контроллеры.
>> Для чего они нужны? Какие реальные задачи вы не можете решить на avr?
> Любые, требующие сколь-нибудь заметных объемов вычислений или передачи данных.
Реально таких задач не так уж много, поэтому и жив avr.
>> Мне нравится в avr простота, я могу в несколько десятков строк сделать
> Я бы не стал рассказывать что софтварный уарт - проще железного.
Вам мой софтварный уарт по ночам наверное снится ;)
Раз уж вам так про uart поговорить хочется - сколько строк нужно для stm32 чтобы отослать один байт по uart. Для avr - 6 строк (включая инициализацию) без библиотек.
>> то, на что у меня бы ушло сотни строк (+библиотеки) на RBPi/linux.
> Если уж библиотеки, там пожалуй строк будет поменьше - за счет выноса
> сложных дел на либу :)
Сколько нужно строк, чтобы просто мигать лампочкой на RBPi?
>> ли я в рамки жесткого realtime.
> Пи явно не для жесткого реалтайма. Хоть с либами, хоть без. Это
> апликушный проц, а не микроконтроллер.
Естественно, я сугубо про avr говорил. Упаси бог считать такты после дизассемблинга программы, библиотек и ОС на RBPi, там наверное жизни не хватит :)