[uquote="КРАМ",url="/forum/viewtopic.php?p=4576952#p4576952"][uquote="AQ29",url="/forum/viewtopic.php?p=4576941#p4576941"]Зачем, ведь есть нормальная лаборатория.[/uquote]
Ну так и работайте в этой лаборатории. Причем тут КБ? КБ - это помещение для конструкторов. Надеюсь вам не нужно объяснять чем отличается конструктор от схемотехника-эмбеддера?[/uquote]
Я уже пояснял. В лаборатории – работа с оборудованием. В КБ – разработка, оформление всяких бумаг, общение с коллегами. Это нормальная организация работы.
Вот интересно, скажем, рядом с вами работает конструктор механик, вы начинаете что-там паять, как он реагирует?
[uquote="КРАМ",url="/forum/viewtopic.php?p=4576952#p4576952"][uquote="AQ29",url="/forum/viewtopic.php?p=4576941#p4576941"]Я пишу о симуляторе, встроенном в программную среду для МК.
Пользоваться таким симулятором очень просто.
Поясню, как он работает.[/uquote]
Это смешно... Вы полагаете, что я не знаю как работает симулятор в среде?
Только проку от такой отладки НОЛЬ. Она если для чего то и нужна, так это для быстрой проверки чистой математики. Если на столе лежит аппаратный дебаггер и схема, то симулятор вообще бестолковая вещь. С реальным железом я даже такие простые вещи смогу во времени посмотреть с реальным тактированием, а не только тупую пошаговую последовательность.
Еще один недостаток симулятора среды - это его крайняя медлительность и пожирание ресурсов при трассировке.[/uquote]
Уже писал, что, похоже, пишем о разных программах. Вы пишите о каких-то «физических моделях внешних полей и механических устройств, трансдьюсерах и т.д.». Какое отношение это имеет к обычному симулятору?
Он просто проходит по ассемблерным командам программы. Откуда «крайняя медлительность и пожирание ресурсов при трассировке»?
Скажем, симулятор проходит ассемблерную команду add. Симулятор должен сложить два байта и установить биты SREG. Где тут «пожирание ресурсов»?
Даже в старой алгоритм билдер (АБ) на древнем компьютере быстро работало.
Ради интереса посмотрел, с какой скоростью симулятор работает на АБ.
Правда, пришлось повспоминать, как там работать. Для удобства запустил программную задержку. Оказалось, симулятор проходил со скоростью около 150 тысяч тактов в секунду. Очень неплохо. Большей частью, на один такт приходиться одна ассемблерная команда.
Сильно сомнительно, что аппаратный дебаггер удобнее.
Скажем, проверка расчёта функции. В симуляторе установил начальную и конечную точки прохода. Затем при каждом проходе задаёшь значение аргумента и жмёшь кнопку Пуск. Обычно, симулятор делает расчёт за доли секунды.
Насколько помню, у меня после отладки в симуляторе эта часть программы всегда исправно работала в реалии.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4576952#p4576952"]А в штатном аппаратном дебаге ничего специально выводить на экран компьютера не требуется.
Просто в окне Watch открывается буфер контролируемых переменных (причем ИМЕНОВАННЫЙ, а не безымянный) и так же точно наблюдается хоть после останова, хоть в динамике. Повторю. Наблюдаются не сами переменные, а их значения защелкнутые в буфер в необходимых сечениях кода. То есть это обычный лог.[/uquote]
Как я понял, необходимые сечения кода – это точки программы. Как вы защёлкиваете интересуемые переменные в необходимых сечениях и как определяете, к каким точкам программы эти значения относятся?
[uquote="КРАМ",url="/forum/viewtopic.php?p=4576952#p4576952"]Вы, милейший, изобрели деревянный велосипед с квадратными колесами. Почитайте что нибудь про JTAG и вы обнаружите, что он примерно так и работает, только без "модернизированного SPI"...
[/uquote]
Очевидно, что я не изобретал SPI, а просто использовал его для своих целей.
Изобретение – это несколько другое.
.
