Чем можно заменить Proteus?

А чем бы заменить Протеус? Он блин, платный, но покупать неохота, ломать - тоже. Как мне быть?

0

Сообщение от ptoop Сибулировать голый МК, глядя что на пинах, повторюсь, можно и в студии. Даже в голове, если алгоритмы не сложные.

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

0

Вы перевариваете только часть данной вам информации или целиком ???

Ваши слова:

МК вообще рекомендуется отлаживать исключительно в "цифровом" режиме. Многие модели имеет этот режим.

Какую часть я не переварил?

Ладно, закончим этот спор. А то уже перебор получается.

А вот если у вас пара сотен переменных, состояние которых зависит от состояния входов-выходов МК, то довольно затруднительно и затратно по времени все эти флажочки выставлять вручную, соблюдая логику работы программы.

Вот тут она отлично отлаживается в железе по мере написания (логически законченными кусками)

0

А вот если у вас пара сотен переменных, состояние которых зависит от состояния входов-выходов МК

Такие вещи отлаживаются по кускам обычно.

0

Сообщение от ptoop А вот если у вас пара сотен переменных, состояние которых зависит от состояния входов-выходов МК, то довольно затруднительно и затратно по времени все эти флажочки выставлять вручную, соблюдая логику работы программы.

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

Или еще одно соображение. Часто отладки требуют схемы, сигналы в которых носят труднопредсказуемый характер. Например, УЗ локатор, в котором форма эха весьма сильно зависит от окружающей обстановки. И как такой сигнал сформировать в Протеусе? Или акустические датчики всякие. А также пиродатчики, металлоискатели, ридеры RF - карт, и многое другое... Да хотя бы сигнал с приемника брелка 315 - 433 МГц на сверхрегенераторе. Там такое творится...

Вот и получается, что для симулятора надо, чтобы все было уже известно. Но если все уже известно, нафига тогда вообще симулировать?
Что я давно уже понял, (в отличие от некоторых)...

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

Последний аргумент - проект Proteus, издох бы, если не было бы покупателей/потребителей ( дебилов в жизни мало, как не крути).

0

Сообщение от SWK При сложных схемах отладка в симуляторах теряет смысл, там как раз надо вручную иммитировать события, выставлять всякие флажочки, а они могут в реальной разработке иметь критический по времени характер... В железе же как раз все работает в реальном времени, с реальными сигналами.

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

Сообщение от SWK Но если все уже известно, нафига тогда вообще симулировать?

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

0

бывают такие случаи, которые в железе запаришься ждать!

Их нельзя имитировать на макетке?

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

Почему нельзя ввод-вывод отладить в железе, а потом заниматься алгоритмом?

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

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

Отладочного кода будет минимум, поверьте. Необходиния среда разработки при этом - блокнот!

0

И? За симуляторы или нет?

0

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

0

И? За симуляторы или нет?

В меру :) В мааааленькую такую меру.
Лично для меня - чисто аналоговые куски либо с индуктивностями, емкостями, фильтрами, и прочими нелинейностями, либо что-то громоздкое на ОУ.

0

Сообщение от ptoop Их нельзя имитировать на макетке?

да конечно можно, о чем речь! подать с генератора сигнал килогерц 5 например... только ВНЕЗАПНО генератора-то нет! как и осцилла с бесконечной памятью и цифрового анализатора. не у каждого дома лаборатория (да и на работе). а уж при зависании в железе вы проц точно не остановите и не увидите, что где почему (без джитага, который тоже есть не всегда).

Сообщение от ptoop Почему нельзя ввод-вывод отладить в железе, а потом заниматься алгоритмом?

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

и вообще, отладка алгоритма отдельно от ввода-вывода - это ли не симуляция, а?

Сообщение от ptoop Отладочного кода будет минимум, поверьте.

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

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

вот это +100500, когда-то это я уже говорил.

0

Сообщение от ptoop И? За симуляторы или нет?

В меру :) В мааааленькую такую меру.
Лично для меня - чисто аналоговые куски либо с индуктивностями, емкостями, фильтрами, и прочими нелинейностями, либо что-то громоздкое на ОУ.

А в это не верю, цифра проще и точнее симулируется.

0

на любом форуме по силовой электронике, например, люди даже не начинают обсуждение чего-то без модели в LTSpice. Я считаю, что симуляторы нужны и полезны.

0

Ymk

только ВНЕЗАПНО генератора-то нет! как и осцилла с бесконечной памятью и цифрового анализатора. не у каждого дома лаборатория (да и на работе).

Так всё равно устройство после сборки проверять, значит эти сигналы полюбому должны быть!

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

Протеус тут поможет? Я не утверждаю, просто сомневаюсь в этом...

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

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

kyr_tt

А в это не верю, цифра проще и точнее симулируется.

Разумеется, я с этим не спорю. Поэтому симулировать её смысла не вижу :)

0

Сообщение от ptoop Так всё равно устройство после сборки проверять, значит эти сигналы полюбому должны быть!

есть-то они есть, но например нужно разогреть термопары до 1200 градусов + ввести в нужный режим остальные датчики - хрен проверишь! а в протеусе взял и сгенерил, хоть 10 разных генераторов поставил.

Сообщение от ptoop Протеус тут поможет? Я не утверждаю, просто сомневаюсь в этом...

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

т.о. получается протеус - замена большой лаборатории с кучей инструментов + возможность макетирования + удобство при отладке интерфейсов. что я еще забыл?

0

что я еще забыл?

Карты и женщины :)

0

Спасибо всем, я получил ответ на вопрос, но никак не ожидал, что Протеус вызовет такую бурную дискуссию. Он, оказывается, может и платы разводить. Так что для себя я сделал вывод, что как минимум, ознакомиться с ним будет нелишним.

0

Сообщение от yors но никак не ожидал, что Протеус вызовет такую бурную дискуссию

Ничего, скоро кто-нибудь скажет, что при СССР протеусов не было и начнется новый срач:))

0

пара строк все решает при нахождении места зависания по светодиодику

Гхм. программа обвешивается дебаг макросами, сбрасывающими в буфер коды прохождения пути программы. Как только буффер переполняется, то прога стопается и все сливается через терминалку. Сидишь и разглядываешь логи движения по коду. Где то виснет? Методом деления пополам/пополам/пополам по логу легко найти участок где возникает бага. Ну а дальше светодиодики или осцил в руки и находим конкретную точку. У меня на поиск самой хитрой баги редко уходило больше часа.

0