Есть ли нормальное программное обеспечение для ко-симуляции устройств на МК с периферией (смешанной)?

Полистав форум нашел только Proteus и Vmlab , которые ИМХО больше похожи на средства обучения , чем на серьезное ПО для разработчиков. Кроме того Proteus имеет весьма ограниченный набор моделей МК AVR.

Ктонибудь вообще пользуется косимуляцией или все макеты делают?

Возможно существуют симуляторы с возможностью подключения периферии описанной на Си?


Спасибо за ваше мнение.

В обоих названых вами симуляторах можно создавать компоненты на Си.

Оба ИМХО достаточно серьезны как симуляторы - т.е. для своего этапа разработки устройства. А дальше отладка на макете.

А чего вам в PROTEUS не хватило ? Вы изучили ВСЕ что в нем есть? сомневаюсь ...

А чего вам в PROTEUS не хватило ? Вы изучили ВСЕ что в нем есть? сомневаюсь ...

И правильно сомневаетесь ;-), как только я его поставил у меня сложилось стойкое ощущение что это какая то игрушка. Возможно он и неоправдано.

В обоих названых вами симуляторах можно создавать компоненты на Си.

Про это я знаю, посмотрел документация к DK у Proteus датируется 2003 годом, версия вроде одна из последних.

Все это субьективное мнение.



Сформулирую вопрос по другому. Какие еще есть средства ко-симуляции кроме упомянутых.

Полностью с Вами солидарен. Игрушки это.

defunct

А чем Вы пользуетесь, прототипами? Или может есть более интересное ПО?


Найти хотябы хороший симулятор AVR, в котором есть продвинутые возможности описания поведения периферии (скриптовый язык какой нибудь или что то наподобие), а то как то в AVR Studio кликать двадцать раз на какой нибудь бит надоело.

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

Old1

Да похоже то что нужно, спасибо. IAR имеется сейчас поставлю и посмотрю.

Хотя конечно будем искать, с перламутровыми пуговицами;-).

Я пользуюсь либо реальным железом либо прототипами. Последние для AVR очень просты в изготовлении, т.к. AVR'ы да и подключаемая в большинстве случаев к ним периферия, часто имеются в DIP исполнении, а к DIP корпусам панельки стоят копейки и достать их совсем не проблема, включая ZIF. Т.о. не теряется ни железо, ни время на проектирование платы, ни время на зачастую бесполезную, медленную и недостоверную отладку в симуляторах.

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

Всякое "Интересное" ПО типа протеусов, IMHO только отнимает время на его освоение, а тольку от него, как говориться, что от JTAG-ICE'а в мультипроцессорной системе под управлением одной ОС (что с козла молока). В итоге на освоение "интересного" ПО потребуется больше времени чем на изготовление прототипа, и не факт, что это "интересное" ПО достоверно сымитирует девайс, но имитация будет однозначно медленнее (в разы) чем реальное железо.

PS: Да и психологический фактор важен. Для меня, например, очень важно ВИДЕТЬ результат своего труда, а не какие-то картинки на экране монитора. Реальное железо здорово ускоряет процесс разработки и отладки.

Ну точно вы не знаете средств отладки PROTEUS. Там есть такие прибамбульки которых не видел ни где.




У тех у кого детали под рукой! Интернет всеж доступнее.

defunct при всем уважении к Вам ,Вы явно загнули

1 Половина протеуса посвящена трассировке плат,и как не трудно догадаться входные параметры для этого берутся из самого проекта(и десятка других форматов включая всем любимый PCB).И могу сказать трассировщик вполне не дурен собой.

2 Медленно?Ну тут сказать нечего.

3 Недостоверную?Ровно на столько ,на сколько соотношение клюк\достоверность.Кроме того если к примеру симулятор учитывает около 40 параметров одного транзистора,то врядли человек сможет их учесть у себя в голове ,тем более если транзисторов в схеме с десяток.


Поддерживаю.



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

PS Сильно не бейте ,это мое ИМХО,и могу сказать что Протеус совсем не годится для доводки девайса,
но для начального старта,прогонки алгоритма,или по быстрячку набросать несложный десайс ,вещь не плохая.

ЗЫЫ У меня была ситуация ,когда пришлось 2 недели ждать заказную деталь,пока дожидался я уже
на 90% написал под нее прогу,осталось только более точно отладить в самом железе в реальном времени.

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

2 bodja74:
Не воспринимайте это как нечто безапелляционное, но...
Из чего состоит программа для AVR:
1.Работа со внутренней периферией (SPI,I2C)
2.Работа с внешней периферией (AT45, AT24, часы, индикаторы)
3.Собсно логика программы.
Что мы имеем в итоге - после непродолжительной работы с AVR, быстро нарабатывается комплект библиотек для пункта(1) и частично(2).Основная логика программы пишется, как правило на обычном платформенно-независимом С и вполне может быть отлажена просто на РС. Таким образом, узким местом остается написание библиотечки под какую-то узкоспециальную периферию - обычно АЦП, ЦАП, кодеки, итд.
Как пример - на неделе мне позвонил человек с достаточно сложным заказом. Я оценил возможности и назвал срок - 3 дня.
День первый - сборка макетки, компиляция скелета из таймера, УАРТа, SPI, ШИМ (надерганы из старых разработок). Проверка работоспособности макетки с этим кодом.
День второй - написание кода специфичного для проекта.
День третий - отладка (все внешние коммуникации работают, все пайки проверены, дамп любого буффера выбрасывается а УАРТ по команде), т.е. занимаюсь именно основной, принципиальной логикой.
Если бы я начинал с симулятора - два дня было бы потрачено только на написание адекватной модели.

Можно посимулировать состояние портов в самом AVR Studio (меню Debug->AVR Simulator Options->Stimuli and Logging, пункт становится доступен в режиме прогона - Run), БЫСТРО и ПРОСТО можно задавать внешние сигналы на ноги портов в нужные моменты времени, а также писать в лог. Что касается ко-симуляции (особенно в смешанных аналого-цифровых схемах), то позвольте выразить сомнение в целесообразности такой работы (если, конечно эта работа не является самоцелью, а вам надо реальный результат). МОДЕЛЬ всегда останентся только МОДЕЛЬЮ, а не реальным объектом. Будь в ней 40 параметров или 140 (что не всегда лучше), это лишь приближение с определенной точностью к моделируемому объекту. Одно неловкое движение (неточность в параметрах или невозможность их учета) и процесс пошел не туда Все напряги и потеря времени зря...
А макетирование даст максимально близкий результат с минимальными затратами времени (это касается только обсуждаемой области - AVR и периферия, в общем случае не всегда так).

А теперь прикинте какой % радиолюбителей может иметь все детали для пайки устройства на 3-й день ! У какого % радиолюбителей есть приборы те что существуют виртуально в симуляторе.

В принципе, на вопрос топика ответ дан - представлены разные мнения и точки зрения, человек наверно сможет определится стоит ли ему потратить 30 Мб трафика и немного времени.

В принципе, на вопрос топика ответ дан - представлены разные мнения и точки зрения, человек наверно сможет определится стоит ли ему потратить 30 Мб трафика и немного времени.

Не так уж и немного времени. Модели нужного мне МК нет ни в протеусе ни в вмлабе. Если бы модели постовлялись бы с сырцами, то создание из tiny15 tiny26 не заняло бы много времени, а так.

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

2beer_warrior

Вынужден с Вами согласится,я так приблизительно и поступаю (т.к. пишу на асме) если нет такого вида контроллера на протеусе,поэтому мне легко сравнивать работу с ним и без него.

2ksv198

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

Можете отработать алгоритм в ПРОТЕУСе на имеющемся контроллере.

А чтоб мощное устройство не выгорело, первое включение делайте через токоограничивающий балласт гарантирующий отсутствие "убивающего" тока. Постепенно снижайте сопротивление балласта по мере отладки.

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

Не знаю как у Вас обстоят дела, но в Киеве каких-либо затруднений с покупкой комплектовки нет. Есть конторы в которых всегда есть все, что требуется для создания макетов, в крайнем случае покупается аналог. Да и после изготовления десятка-двух таких макетов в ящиках стола валяется уже столько хлама, что как правило и ездить никуда не приходится.
Специализированные детали типа ethernet и радио трансиверов, привозят максмум за 2 недели, но всегда можно купить с запасом, и применять одно и тоже железо в дальнейших разработках.

Ну во-первых мы говорим не о ЛЮБИТЕЛЯХ. У любителей как правило нет основного ограничения профессионала - жестких сроков.

Во-вторых, в чем и состоит суть моего поста, на стандартные устройства МК и торжественный комплект SPI/I2C устройств имеются стандартные наработки.
Сам я готовыми либами не пользуюсь - все написано под себя, в одном стиле, с возможностью гибкого конфигурирования под любую задачу, кучей флажков, стеков и буферов. Без малого операционная система.(Сейчас кстати все это хозяйство потихоньку перевожу на С++, хочу все иметь в виде иерархии классов с перегружаемыми функциями).
В любом случае либу симулировать не надо. Вот где надо приложить труд, это именно что-то очень специальное, например поверх SPI положить систему регистров, какого-то специального АЦП.Или какой-нибудь обмен по хитрому протоколу. Но именно в этом случае, модель получается достаточно громоздкой, отнимает много времени и не застрахована от ошибок. Это при том, что как правило этот хитрый интерфейс это всего лишь 15-20% общей функциональности и при работающем всем остальном, легко отлаживается в лоб, на железе.

Интересно где именно загнул? ;> То что я не использую симуляторы - чистая правда.
То, что AVR'ы и периферия к ним часто бывают в DIP исполнении - факт.
То, что панельки для DIP копеечные и их легко достать (в сравниниее например с сокетом для PQFP208) - тоже факт.
То, что отладка на симуляторах медленная и требует действий, которые иногда абсолютно не нужны - тоже факт. Симуляторы тормозят в сравнении с реальным железом - очередной факт.

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

Касательно протеуса с настройками 40ка параметров одного транзистора, не находите ли Вы, что подбор этих 40ка параметров это просто трата времени, т.к. подобранный в модели транзистор может не существовать в природе. Не проще ли впаять сразу реальный транзистор и посмотреть как он будет себя вести.

Ну а насчет составления схем выходом в PCAD'овом формате, мне это тоже как-то фиолетово, т.к. проектированием ПП я не занимаюсь, а доверяю это дело более опытным людям которые профессионально работают с PCAD. Простенькие же девайсы (до 5 микросхем на плате) иногда для ускорения процесса разработки рисуются без составления принципиальных схем, прямо с даташитов.

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


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


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

Станистлавский из гроба: "НЕ ВЕРЮ !" а чувачок из трех мушкетеров: "АДРЭС Сэстра, АДРЭС !"

Их право говорить все, что угодно.
Мне те что с того?

2defunkt

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

Насчет транзисторов,здесь все наоборот,берется готовая модель с подходящими параметрами,если таковой нет,подставляются значения из даташита.

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

ЗЫ Сделал вывод: у каждого свои пути и способы достижения цели.

Спасибо всем, Ваши мнения мне очень помогли.

Выводы сделал следующие, по возможности использовать прототипы, но всеже потихоньку читаю ИАРовский мануал о С-SPY, и возможно попробую Proteus если попадется проект на МК с существующей моделью. Разработка модели необходимого МК ИМХО гораздо более трудозатратна чем создание прототипа, по крайней мере для тех устройств которыми я сейчас занимаюсь.

Извините, но причем тут амбиции? Здравый смысл и время для меня важнее.
Аналогично, использую много разных полезных программ, однако proteus и vmlab к полезным для себя причислить не могу, также как и ELab-Pascal, ICC, CVAVR и прочее студенческое ПО..

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


Что-то не могу такого вспомнить, по крайней мере относительно МК.. Быть может потому, что перед тем как начать работу с МК изучил отдельно программирование на PC, и отдельно документацию на МК.. А с МК работал уже непосредственно "в железе".

абсолютно верно.



PROTEUS лучше попробовать на нескольких из 200 примеров идущих с ним в инсталяции.



И практически бессмыслена если вы не собираетесь ее продавать. Ведь модель мало создать ее еще и протестировать нужно и убедится что она правильная.