Да, именно в точности для этого. Потому что если например программа принимает данные то нужно иметь возможность посмотреть как они обрабатываются. А реальное устройство не будет ждать пока вы обработку каждого байта по шагам пройдете. В отличие от симулятора, где можно задать подаваемые на вход МК байты и посмотреть как они будут обрабатываться. В том числе и какие-нибудь редкие граничные или вообще "невозможные" значения. У меня к примеру был случай с цифровым токовым датчиком у которого при отсутствии тока изредка проскакивали очень малые но _отрицательные_ значения. И моя программа на этом спотыкалась так как по по логике работы схемы - тока "в другую сторону" просто не могло быть.


Примитивны эти проблемы только для чайников которые не знают что такое переполнение при вычислениях и что такое потеря точности из-за обрезания младших разрядов. Тем более что gcc по сей день не выдает предупреждение если просто например long = int + int. Оно старшие разряды _молча_ обрежет и только потом присвоит. Этой "особенности поведения" лет тридцать.


Да, vmlab это делает. Перевод контроллера в сонное состояние и выход из сна по прерываниям я в нем отлаживал.


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

Естественно, работать с симулятором нужно уметь. Это далеко не просто "нарисовал схему и включил". Например если есть подозрения на некие сбои из-за помех на линии связи с внешним устройством - можно в симуляторе подать контроллеру на вход неправильные данные и посмотреть как он обрабатывает такие ошибочные ситуации. На реальной железке отлаживать обработку ошибок существенно сложнее потому что вы не можете управлять типом возникающих ошибок - они будут случайны. И повторить точно такую же ошибочную ситуация невозможно.


Понимаю,что для профессионала, работающего с микроконтроллерами ежедневно по восем частов - всё мной написанное это мелкая, не стоящая внимания фигня. А вот программисту-любителю,который пишет код для контроллеров далеко не каждый день и не в таких количествах - симулятор очень даже нужен.

Добавлено after 24 minutes 2 seconds:

Это если и возможно то только для профессионалов,причем работающих в крупных и известных компаниях. Любитель может с тем же нулевым результатом обратиться хоть к Богу с молитвой о ниспослании ему нужной спецификации :)


С одной стороны вроде бы и да,с другой - встречал мнение что продолжение выпуска микроконтроллеров avr в течении трех десятков лет во много обязано именно спросу со стороны любителей.
Ибо с "промышленной" точки зрения они и медленнее и дороже чем например те же stm,не говоря о китайских risc.


Вот и я об этом - любителю часто приходится писать свой велосипедный код потому что код из используемых в промышленности библиотек ему никто не даст или запросят совершенно неадекватных денег.


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


Для профессионала - может быть. А вот я,любитель, отлаживал код конечного автомата именно что в vmlab. Можно конечно отлаживаться и методом печати в uart,но у меня бы на такое наверно терпения не хватило бы. За основу своего конечного автомата я брал код,выложенный по той ссылке на easyelectronix. Написать такое совсем полностью с чистого листа - было бы _очень_ долго.


С "средой" ардуино и ее весьма специфическим языком я стараюсь дела не иметь. Максимум что было однажды - это подсмотрел алгоритм как сделано и переписал на Си.


Вот и я о том же. Особенно в случае программистов-любителей.

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

Они сильно устарели. За ту же стоимость можно купить МК с гораздо лучшими характеристиками. Это все равно что если бы вы сейчас купили на 300к первый экземпляр 8086 компа вместо современного игрового.

Это потому что слаще хрена ничего не ели.
Программный симулятор? Зачем когда есть аппаратный отладчик позволяющий вылавливать ошибки выполняя код в МК? Это гораздо лучше ведь программный симулятор многое может не учитывать многие нюансы и он не позволит отладить в реальном железе.

Зачем программный симулятор если есть аппаратный - МК? Это в большинстве AVR он не поддерживается и приходится выкручиваться, а всех без исключения STM32 присутствует модуль отладки к которому подключают ST-Link по 2 проводам и делают с МК что хотят.
Это позволяет выполнить отладку в реальных условиях, а не в "тепличных" в симуляторе.

Зачем он нужен если к STM32 можно подключить аппаратный отладчик и VMlab будет нервно курить в сторонке?! Посмотрите если хотите и скажите все ли из этого поддерживается в программном симуляторе http://purebasic.mybb.ru/viewtopic.php?id=564

Мне приходилось отлаживать USB и проблем не было. Главное чтобы USB полностью инициализировался и хост получил дскрипторы, а дальше отладка не мешает и можно останавливать в любой момент.
Кстати, в VMlab есть возможность отладить USB при реальной связи с компом?

Кто мешает отладчиком записать нужные данные в регистр или переменную и посмотреть как программа их обработает?

Как вы воспроизвели эту программу в стимуляторе? Здесь нужен отладчик работающий с реальным железом. Ставим условную точку останова на требуемую переменную и если значение выйдет за допустимые пределы, прога остановится и можно посмотреть что пошло не так.

И что он показывает сколько жрет МК с каждый момент времени?

Он умеет симулировать различные сбои? Для этого нужно реальное железо работающие в соответствующих условиях, а не "тепличный" симулятор.

зачем vmlab...

Proteus 8 Professional есть))

а для особо любознательных есть AVRStudio )) смотрим как выполняются машинные инструкции...

достаточно.


вместо I2C есть TWI... или как его там)) никада им не пользовался.
в крайнем случае любой интерфейс легко делается программно...


единственное чего нет у AVR - встроенного интернета...

приходится изобретать самому...

Спойлер

всё остальное для жизни у AVR есть))

Жить можно бедно, а можно богато!
У AVR почти ничего нет (бомжо-периферия, регистры в перемешку и не в одном адресном пространстве с памятью и др.), это нищенская, бедная жизнь! Сплошной ногодрыг! Каменный век короче!

А сколько у вас объезженных коней в вакууме?
Ведь это - то же самое. Зачем "детально и со всеми узлами"???

PS: Ежли что - за несколько десятилетий практики в embedded и более десятка использованных ядер МК (именно ядер(CPU), самих МК - гораздо больше), полностью, "от корки до корки" не изучал не один МК. Всегда изучаю только то, что нужно. И это никак не мешает мне реализовывать работающие проекты на них.
Никогда не понимал - к чему эти плачи о "тысячах страниц мануалов", которые нужно прочитать, чтобы начать программировать МК??? Не нужно читать тысячи. Читать нужно только те разделы документации, которые нужны.

Добавлено after 14 minutes 3 seconds:
Не нужен. На всяких AVR-ах - симуляторы от бедности. Потому как нету нормального аппаратного отладчика. На ARM-ах он есть. Потому симулятор никакой им не нужен.

Симулятор - это тупиковый путь. Почему? Потому как увеличивает затраты на вывод на рынок нового МК и снижает скорость вывода (нужно ведь время на его написание). Также - где вы видели программы без багов?? Думаете - ваш симулятор будет правильно симулировать всю периферию МК? святая наивность! Если даже контроллеры не делают без багов. А сложные контроллеры - так там багов вагон. И симулятор добавит к ним ещё своих. И как будете гадать - где баг вашей программы, контроллера или симулятора? И кроме того - баги контроллера, описанные в errata, симулятор тоже должен симулировать. А если в новой ревизии МК баг исправили - то и это симулятор тоже должен учесть. Иначе - ваша программа, отлаженная в симуляторе, в реальном МК работать не будет.
Всё это делает практически бесполезными симуляторы на серьёзных МК. Для всяких простейших, типа AVR, они ещё может быть более-менее. И то - больше от бедности (отсутствия нормального аппаратного отладочного интерфейса).
Это уж не говоря о том, что для симулятора нужно ещё и окружение МК как-то симулировать.

а есть альтернатива ?

Понеслось!

У каждого свой взгляд и подход.
Однако есть разница между рекомендациями и настоятельно-агрессивными требованиями.

Толку от философии - дайте в качестве демонстрации преимуществ топикстартеру собственное готовое решение - вот и поглядим, что в данном случае лучше и эффективнее.

Ну, это тоже ничего не докажет. Поскольку, зависит и от задачи, и кто какими мк пользуется.

Для ТС и в с такой задачей и так понятно - Ардуино - лучшее решение. (Это притом, что я не люблю Ардуино)

С точки зрения бизнеса по производству электроники - да, возможно. Хотя регулярно по сей день попадаются в вполне промышленно изготовленных китайских девайсах.
А вот с точки зрения радиолюбителей,точнее программистов-любителей - лучше AVR пока ничего нет. Потому что любителям нужна хорошая поддержка со стороны софта в котором пишется и отлаживается код. А лучшая поддержка пока что именно у AVR. Плюс - множество доступных обучающих материалов и примеров кода.
Есть шанс что со временем место avr займут китайские risc так как благодаря их открытости для них можно написать удобный именно для любителей инструментальный софт. Но это не скоро потому что писать - долго. Для куда более простых avr хороший удобный инструментальный софт написали лет через десять после их появления на рынке(западном). А совсем хорошо стало только где-то к середине двухтысячных.


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


Одно не заменяет другое. Это _разные_ инструменты. По всей видимости вы - профессионал, регулярно и много пишущий код под микроконтроллеры. И вы просто не сталкиваетесь с теми проблемами с которыми сталкиваются любители,пишущие код не много и далеко не каждый день. Это проблемы больше из области педагогики,а не электроники. Вы просто не делаете тех "глупых" ошибок для отлова которых любителю нужен интерактивный программный симулятор микроконтроллера.


А любителю как раз нужны именно "тепличные". Аппаратный отладчик не напишет вам что вы что-то неправильно инициализировали - оно просто не будет работать как надо. А почему - извольте разбираться сами. Вы-то разберетесь,а любитель может потратить много дней из-за какой-нибудь очевидной для вас мелочи.
Тот же vmlab сразу показывает основные параметры настройки периферии после записи данных в конфигурационный регистр. Он же укажет если программист допустил чтение из ячейки памяти которой небыло присвоено никакое значение. И так далее.


отлаживать usb я просто не пробовал так как использовал готовую отлаженную библиотеку когда мне usb потребовался.
А вот rs232 отлаживал и успешно. Мне потребовалось иметь "консоль", через которую взаимодействовать с программой в контроллере.
Я нашел библиотеку, реализующую такую функциональность,но оказалось что в ней есть ошибки работы с esc-последовательностями. Произошли они от того,что
автор при написании и отладке использовал виндовый эмулятор терминала который в некоторых местах не соответствует классическому vt52. Имея реальный,пусть и очень давний,опыт работы с железными терминалами - я эту причину легко определил.
И вот чтобы это исправить - пришлось разбирать как библиотека обрабатывает получаемые байты. Заодно научился подключать виртуальный ком-порт к симулятору. В линуксе для этого есть модуль "петлевого" последовательного устройства tty0tty. Эдакий виртуальный "нуль-модем". И мне удалось заставить работать конструкцию из vmlab,который официально совместим с Wine,и линуксового терминала minicom,к нему подключенного через это виртуальное устройство. Работало не быстро но _правильно_,что и требовалось.


Мешает неудобство этого действия - о чем я и говорю. Если байтов несколько штук - это еще как-то приемлимо. А если несколько десятков или даже сотен? Вместо того чтобы подготовить файл из которого они будут скармливаться симулятору - предлагаете каждый вписывать вручную? Может для профессионала это и приемлимо(а может не нужно),а вот для любителя возможность чтения байтов из файла категорически необходима. Причем именно одних и тех же при каждом запуске программы.


Записал то что приходит с датчика, положил это в виде файла и скормил на вход симулируемого контроллера. И скармливал много раз одно и то же пока не понял где глюк. Несколько десятков раз. Ибо даже помыслить не мог что такое может быть. Да и выглядело это как случайные броски тока потому что малое отрицательное значение воспринималось как большое положительное. Я и искал причину бросков. Тоже поначалу был уверен что это помехи в железе.
Кстати, потом столкнулся с тем же самым в серийном промышленном устройстве (контроллере солнечных панелей) который при отсутствии тока с панелей тоже иногда выплёвывал в диагностический порт (modbus) значения с взведенным старшим битом. Если бы до того уже по этим граблям не потоптался - тоже в первую очередь предположил бы что это помехи-наводки на провода от контроллера к массиву солнечных панелей, тем более там с десяток метров по крыше. Ну вот кто мог знать что
у контроллера ток с панелей это _знаковый_ тип? При том что обратного тока там не может быть в принципе. Исправные солнечные панели ток потреблять не умеют потому что они - диоды. Да и схема солнечного контроллера это понижающий импульсный преобразователь через который обратно ток не течет.


Как раз наоборот - он тут неудобен. Потому что реальное железо будет генерировать неуправляемый из такого отладчика поток данных. Изменив что-то в программе невозможно повторить ее работу в точно таких же условиях потому что при следующем запуске поток данных будет другой. А надо - тот же.


Для этого надо вообще хотябы предположить что датчик может такое значение выдать. А потом еще и дождаться пока он это сделает. Обратите внимание - не скормить программе заранее известную последовательность значений,заведомо вызывающую сбой,а сидеть и ждать когда же прилетит то что сбой вызывает. А оно может прилетать весьма редко. В результате теряется теряется то,что необходимо для отладки кода - возможность его запуска в полностью контролируемых и повторяемых условиях. Да, я могу предположить что вы ошибок в коде не делаете (или почти не делаете) поэтому для вас важнее отладка железа. В случае с любителями это не так - железо у них обычно как раз простое,а вот ошибки в коде они делают много и часто. Достаточно не писать код хотябы месяц - и количество именно программистских ошибок сразу сильно растёт потому что различные мелочи быстро забываются.


Да, прямо так,в милли/микроамперах. Я лично не пытался сравнивать реальное потребление с вычисленным симулятором,хотя читал на форумах что совпадение достаточно хорошее. Мне было достаточно видеть "порядок цифр" чтобы понять уходит контроллер в сонный режим или нет,и если да то в какой и на сколько времени,а таже чем именно пробуждается.


Мы с вами о разных сбоях говорим. Вы о железных,а я - о программных. И симулятор как раз позволяет скармливать программе одни и те же данные в процессе поиска что же именно в них вызывает сбой. Поиск того,откуда эти неправильные данные берутся - это _другой_ этап отладки. Обычно уже после того когда проверено что программа способна эти неправильные данные разумно обрабатывать,а не тупо виснуть. И кстати какой-то специальный отладчик тут не особо и нужен - в качестве такового может выступать сам контроллер с уже правильно работающей программой. Она будет писать в куда-нибудь сообщения о появлении неправильных данных,благо с ресурсами нынешних контроллеров avr сделать вывод отладочной информации не проблема хоть через uart хоть на какой-нибудь индикатор. Даже если аппаратный uart занят то "однонаправленный" низкоскоростной последовательный порт можно изобразить из любого свободного пина и этого для вывода отладочной информации достаточно.

Кстати, вы там выше x86 упоминали - так вот,несмотря на наличие в нем всяких отладочных механизмов и существование отладчиков которые их используют - существуют и программные симуляторы типа например qemu, имеющие свою область применения. Когда я в начале 90х зарабатывал кодописательством под защищенный режим дос-экстендера - мне очень сильно не хватало такого qemu. Да, я тогда научился как-то обходиться без него. Можно и сейчас на STM обойтись.
Но хочется удобств, сильно сокращающих непроизводительные затраты времени на поиск "глупых" ошибок,а то и просто опечаток. Для AVR эти удобства есть - поэтому любители пользуются avr,благо что формально более высокая цена не поджимает при использовании единичных экземпляров. Что сотню рублей заплатить,что три - один фиг копейки по сравнению с всеми прочими затратами. А формально различие аж в три раза.

не нужен.
Вы просто не пробовали работать без него.

Симулятор может помочь в двух случаях: изучить архитектуру и отладить какой-то алгоритм, чистой математики, то есть, оба случая не должны зависеть от внешней среды.
И всё. А, ну ещё он позволяет не сжечь порт, ага. Это очень полезно, порт будет выжжен чуть позже, когда уже под симуляторное решение будет сделана плата, а потом выяснится, что программно это не исправить.

Реальное поведение в симуляторе недоступно, что спорить-то?

"В протеусе всё работает, а на плате нет" - классика от именно любителей, которые любят симуляторы.

Добавлено after 4 minutes 43 seconds:
это совершенно другое.

А впрочем, радиолюбитель - хозяин-барин. При существовании бесплатного или недорогого ПО и оборудования, многие до сих пор стенают, что у них только ВинХР и поэтому современные программки невозможно использовать, что у них СпринтЛайоут и им нафиг не надо сквозное проектирование, и т.д и т.п.
Поэтому, можно программку сначала написать на листочке. Потом переписать в блокнот. Потом перекопировать в симулятор. Потом собрать отладку и один фиг работать там.
Никто не запрещает, а комсомольцев даже поощряют выбирать более тернистые пути.

В зависимости от задач есть и разные подходы к работе с МК.
Один вариант детально (по максимуму) использовать встроенные аппаратные модули, другой - работать с платкой как с "черным ящиком", используя предоставленные разработчиком IDE методы("рамки референса").
Первый - обычно применяется радиолюбителями еще со времен ассемблера.
Второй более соответствует созданию программ а ПК, когда внутренняя начинка нас мало интересует (а порой и совсем неизвестна).
А теми "внутренностями" интересуются чаще только разработчики материнок ПК, но не устройств, в которых комплект ПК используется.
Со времени, когда аппаратная начинка МК стала приближаться по уровню к начинке материнок "больших ПК" ("система на кристалле") стали востребованы и средства работ с подобными устройствами.
Ардуино как раз и является "переходным вариантом", где возможно применение и одного и другого варианта работ.

Насчет "старых программ" (и железяк)...
Все определяется необходимой самодостаточностью.
Сторонники "покупай-покупай" порой следуют не реально необходимому, а навязанной коммерческой стратегии других лиц.
Не стоит забывать о правилах коммерции (чтоб видеть происходящее на рынках предложений товаров и услуг).
В то же время необходимо следить за прогрессом, дабы не пропустить концептуальных новинок. При том не забывая, что для практики в большинстве случаев от тех новинок вполне можно отказаться, предоставив их реализацию соответствующим проф предприятиям/НИИ.
Это уже раздел обоснования ремонтопригодности и возможностей ручной сборки/реализации в любительских условиях.
Держать дома лабораторию профессионального уровня ради одной-двух самоделок в год...
Разве что для миллионера на пенсии позволительно.
И то... неровен час такого "неадеквата" или в психушку или еще куда соседи посодействуют направить... (а вдруг он "вредит обчеству")

работать с платкой как с "черным ящиком" можно только на многоядерных процессорах... с управлением потоками... ))

там скорость выполнения инструкций большая... тактовая гигагерцы... можно всё делать параллельно...))

и т.д.

работать с простым МК как с "черным ящиком"... нет никакого смысла... скорость будет никакая))

В данном случае (ардуино) как раз стандартно так и используется.
К примеру таймеры и АЦП задействованы системой референса.
В то же время для желающих доступно и прямое управление аппаратными ресурсами, как в "классическом подходе".
Собственно работая "в рамках референса" мы используем своеобразный вариант "операционной системы" со скрытыми от прямого управления пользователем аппаратными ресурсами МК.
Последнее время для платформ стали закладывать и расширенные возможности доступа к аппаратным ресурсам АВР - приближение к "стандартному" подходу при настройках аппаратных модулей.
Тут уж кому что удобнее - от одной крайности ло другой или все вместе перемешать.

О, "референса"! Твоё любимое слово.)))
А главный принцип Ардуино - простота.

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

А зачем вам много? Один STM32 начального уровня, типа STM32G0, заменяет любой AVR, т.к. там корпуса от 8 до 100 пинов, USB, CAN, 144KB RAM и т.д., при, естественно, одинаковой периферии.

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

Едва ли. Использую несколько видов (AVR, PIC, STM32, CH32 ...). У каждого есть свои преимущества и недостатки, каждый из них предназначен для определенного применения.

У нас есть поговорка: (+ транслейт): "Каждая лягушка знает свое болото".

фото из интернета:

Не нужно даже PIC/CH32 добавлять, хватает достаточно сильно непохожих друг на друга серий STM32, но тогда мы как раз придем к тому, что придется писать много разных либ, а я говорю о том, что можно взять одну, достаточно простую и дешевую серию STM32, которая функционально заменяет любой AVR. Акцент на простоте, для многих и один STM32 уже слишком сложно )

Добавлено after 9 minutes 3 seconds:

Ваша котуинка писалась для AVR, PIC, x51... На ассме, разных ассмах, на С, потом ардуино добавилось и везде все фактически в виде набросков. Самый простой способ топтаться на месте - это рассредоточить внимание и по кругу проделывать одну и ту же работу для разных архитектур... Сколько у вас в среднем за год законченных проектов? Если судить по форуму, то меньше одного, следовательно цена вообще не имеет значения и я абсолютно уверен, что среди них практически нет таких которые проблематично реализовать на ARM.


Топикпастер, возможно, ни на чем кроме ардуино и не сможет ничего написать, для таких ардуино и создавалось.

Добавлено after 9 minutes 3 seconds:

Топикпастер, возможно, ни на чем кроме ардуино и не сможет ничего написать, для таких ардуино и создавалось.[/uquote]


Не! Таким как топикстатртер было бы лучше, если написание машинных кодов для чего угодно- взял на себя ИИ.
Дал задание, залил код и вуаля. А так да... Ардуино- все что сможем...