WatchCat писал(а):Вообще-то микроконтроллеры семейства AVR продаются в РФ уже как минимум четверть века.
Они сильно устарели.
С точки зрения бизнеса по производству электроники - да, возможно. Хотя регулярно по сей день попадаются в вполне промышленно изготовленных китайских девайсах.
А вот с точки зрения радиолюбителей,точнее программистов-любителей - лучше AVR пока ничего нет. Потому что любителям нужна хорошая поддержка со стороны софта в котором пишется и отлаживается код. А лучшая поддержка пока что именно у AVR. Плюс - множество доступных обучающих материалов и примеров кода.
Есть шанс что со временем место avr займут китайские risc так как благодаря их открытости для них можно написать удобный именно для любителей инструментальный софт. Но это не скоро потому что писать - долго. Для куда более простых avr хороший удобный инструментальный софт написали лет через десять после их появления на рынке(западном). А совсем хорошо стало только где-то к середине двухтысячных.
За ту же стоимость можно купить МК с гораздо лучшими характеристиками.
Вот только для любителя характеристики даже avr в абсолютном большинстве случаев сильно избыточны.
Любителю нужно удобство и понятность,а не мегагерцы и мегабайты.
WatchCat писал(а):Нужна не аппаратная отладка,а хороший симулятор.
Зачем программный симулятор если есть аппаратный - МК?
Одно не заменяет другое. Это _разные_ инструменты. По всей видимости вы - профессионал, регулярно и много пишущий код под микроконтроллеры. И вы просто не сталкиваетесь с теми проблемами с которыми сталкиваются любители,пишущие код не много и далеко не каждый день. Это проблемы больше из области педагогики,а не электроники. Вы просто не делаете тех "глупых" ошибок для отлова которых любителю нужен интерактивный программный симулятор микроконтроллера.
Это позволяет выполнить отладку в реальных условиях, а не в "тепличных" в симуляторе.
А любителю как раз нужны именно "тепличные". Аппаратный отладчик не напишет вам что вы что-то неправильно инициализировали - оно просто не будет работать как надо. А почему - извольте разбираться сами. Вы-то разберетесь,а любитель может потратить много дней из-за какой-нибудь очевидной для вас мелочи.
Тот же vmlab сразу показывает основные параметры настройки периферии после записи данных в конфигурационный регистр. Он же укажет если программист допустил чтение из ячейки памяти которой небыло присвоено никакое значение. И так далее.
Кстати, в VMlab есть возможность отладить USB при реальной связи с компом?
отлаживать usb я просто не пробовал так как использовал готовую отлаженную библиотеку когда мне usb потребовался.
А вот rs232 отлаживал и успешно. Мне потребовалось иметь "консоль", через которую взаимодействовать с программой в контроллере.
Я нашел библиотеку, реализующую такую функциональность,но оказалось что в ней есть ошибки работы с esc-последовательностями. Произошли они от того,что
автор при написании и отладке использовал виндовый эмулятор терминала который в некоторых местах не соответствует классическому vt52. Имея реальный,пусть и очень давний,опыт работы с железными терминалами - я эту причину легко определил.
И вот чтобы это исправить - пришлось разбирать как библиотека обрабатывает получаемые байты. Заодно научился подключать виртуальный ком-порт к симулятору. В линуксе для этого есть модуль "петлевого" последовательного устройства tty0tty. Эдакий виртуальный "нуль-модем". И мне удалось заставить работать конструкцию из vmlab,который официально совместим с Wine,и линуксового терминала minicom,к нему подключенного через это виртуальное устройство. Работало не быстро но _правильно_,что и требовалось.
WatchCat писал(а):В отличие от симулятора, где можно задать подаваемые на вход МК байты и посмотреть как они будут обрабатываться.
Кто мешает отладчиком записать нужные данные в регистр или переменную и посмотреть как программа их обработает?
Мешает
неудобство этого действия - о чем я и говорю. Если байтов несколько штук - это еще как-то приемлимо. А если несколько десятков или даже сотен? Вместо того чтобы подготовить файл из которого они будут скармливаться симулятору - предлагаете каждый вписывать вручную? Может для профессионала это и приемлимо(а может не нужно),а вот для любителя возможность чтения байтов из файла категорически необходима. Причем именно одних и тех же при каждом запуске программы.
WatchCat писал(а):В том числе и какие-нибудь редкие граничные или вообще "невозможные" значения. У меня к примеру был случай с цифровым токовым датчиком у которого при отсутствии тока изредка проскакивали очень малые но _отрицательные_ значения. И моя программа на этом спотыкалась так как по логике работы схемы - тока "в другую сторону" просто не могло быть.
Как вы воспроизвели эту программу в стимуляторе?
Записал то что приходит с датчика, положил это в виде файла и скормил на вход симулируемого контроллера. И скармливал много раз одно и то же пока не понял где глюк. Несколько десятков раз. Ибо даже помыслить не мог что такое может быть. Да и выглядело это как случайные броски тока потому что малое отрицательное значение воспринималось как большое положительное. Я и искал причину бросков. Тоже поначалу был уверен что это помехи в железе.
Кстати, потом столкнулся с тем же самым в серийном промышленном устройстве (контроллере солнечных панелей) который при отсутствии тока с панелей тоже иногда выплёвывал в диагностический порт (modbus) значения с взведенным старшим битом. Если бы до того уже по этим граблям не потоптался - тоже в первую очередь предположил бы что это помехи-наводки на провода от контроллера к массиву солнечных панелей, тем более там с десяток метров по крыше. Ну вот кто мог знать что
у контроллера ток с панелей это _знаковый_ тип? При том что обратного тока там не может быть в принципе. Исправные солнечные панели ток потреблять не умеют потому что они - диоды. Да и схема солнечного контроллера это понижающий импульсный преобразователь через который обратно ток не течет.
Здесь нужен отладчик работающий с реальным железом.
Как раз наоборот - он тут неудобен. Потому что реальное железо будет генерировать
неуправляемый из такого отладчика поток данных. Изменив что-то в программе невозможно повторить ее работу в точно таких же условиях потому что при следующем запуске поток данных будет
другой. А надо - тот же.
Ставим условную точку останова на требуемую переменную и если значение выйдет за допустимые пределы, прога остановится и можно посмотреть что пошло не так.
Для этого надо вообще хотябы предположить что датчик может такое значение выдать. А потом еще и дождаться пока он это сделает. Обратите внимание - не скормить программе заранее известную последовательность значений,заведомо вызывающую сбой,а сидеть и ждать когда же прилетит то что сбой вызывает. А оно может прилетать весьма редко. В результате теряется теряется то,что необходимо для отладки
кода - возможность его запуска в полностью контролируемых и повторяемых условиях. Да, я могу предположить что вы ошибок в коде не делаете (или почти не делаете) поэтому для вас важнее отладка железа. В случае с любителями это не так - железо у них обычно как раз простое,а вот ошибки в коде они делают много и часто. Достаточно не писать код хотябы месяц - и количество именно программистских ошибок сразу сильно растёт потому что различные мелочи быстро забываются.
WatchCat писал(а):Да, vmlab это делает.
И что он показывает сколько жрет МК с каждый момент времени?
Да, прямо так,в милли/микроамперах. Я лично не пытался сравнивать реальное потребление с вычисленным симулятором,хотя читал на форумах что совпадение достаточно хорошее. Мне было достаточно видеть "порядок цифр" чтобы понять уходит контроллер в сонный режим или нет,и если да то в какой и на сколько времени,а таже чем именно пробуждается.
WatchCat писал(а):А вот чтобы отладить реакцию на эти неправильные данные - и нужен симулятор.
Он умеет симулировать различные сбои? Для этого нужно реальное железо работающие в соответствующих условиях, а не "тепличный" симулятор.
Мы с вами о разных сбоях говорим. Вы о железных,а я - о программных. И симулятор как раз позволяет скармливать программе одни и те же данные в процессе поиска что же именно в них вызывает сбой. Поиск того,откуда эти неправильные данные берутся - это _другой_ этап отладки. Обычно уже после того когда проверено что программа способна эти неправильные данные разумно обрабатывать,а не тупо виснуть. И кстати какой-то специальный отладчик тут не особо и нужен - в качестве такового может выступать сам контроллер с уже правильно работающей программой. Она будет писать в куда-нибудь сообщения о появлении неправильных данных,благо с ресурсами нынешних контроллеров avr сделать вывод отладочной информации не проблема хоть через uart хоть на какой-нибудь индикатор. Даже если аппаратный uart занят то "однонаправленный" низкоскоростной последовательный порт можно изобразить из любого свободного пина и этого для вывода отладочной информации достаточно.
Кстати, вы там выше x86 упоминали - так вот,несмотря на наличие в нем всяких отладочных механизмов и существование отладчиков которые их используют - существуют и программные симуляторы типа например qemu, имеющие свою область применения. Когда я в начале 90х зарабатывал кодописательством под защищенный режим дос-экстендера - мне очень сильно не хватало такого qemu. Да, я тогда научился как-то обходиться без него. Можно и сейчас на STM обойтись.
Но хочется удобств, сильно сокращающих непроизводительные затраты времени на поиск "глупых" ошибок,а то и просто опечаток. Для AVR эти удобства есть - поэтому любители пользуются avr,благо что формально более высокая цена не поджимает при использовании единичных экземпляров. Что сотню рублей заплатить,что три - один фиг копейки по сравнению с всеми прочими затратами. А формально различие аж в три раза.
Среди них есть удачные экземпляры, а есть не очень. 
Сплошной ногодрыг! Каменный век короче!
