Опубликованы материалы вебинара, посвященного пленочным конденсаторам компании Hongfa, на котором была представлена текущая линейка и модельный ряд продукции этого направления, включая новые, недавно вышедшие серии.
На вебинаре были приведены актуальные примеры применения пленочных конденсаторов Hongfa в источниках питания, зарядных станциях для электротранспорта, преобразователях частоты, фотоэлектрических преобразователях и ветрогенераторах.
Вообще то мы отклонились от темы отладки))) Чтоб вернуться к ней, напомню один старый метод оценки производительности и загруженности МК.
МК - не ПК и там нет диспетчера, в котором можно увидеть загрузку процессора.
Я использую для написания программ 2 подхода: 1. событийная модель с диспетчером заданий 2. суперцикл
В обоих случаях у меня в программе используется так называемый системный таймер. Это может быть отдельный таймер, предусмотренный архитектурой МК, либо я выделяю какой то из таймеров общего назначения. В подавляющем большинстве случаев я таймер настраиваю на 1 мс. И уже все процессы привязываются к этим таймингам. Включая программные таймеры. В случае суперцикла выполняются все предусмотренный задачи и потом суперцикл ожидает следующего тика системного таймера. В случае событийной модели выполняются все задачи из очереди и потом, когда задачи в очереди исчерпались, диспетчер постоянно дергает специально выделенную задачу void idle(void).
И если выделить какой то GPIO, то его можно поднимать в единичку в цикле ожидания и класть в нолик при выполнении задач. В случае суперцикла пин поднимается в единичку перед началом ожидания следующего тика системного таймера и сбрасывется в 0 при наступлении этого тика. В случае диспетчера - в задаче idle пин поднимается в 1, а диспетчер сбрасывает пин в 0 при вызове любой задачи, кроме idle.
Таким образом, можно осциллографом либо лог.анализатором смотреть, что именно делает наш МК - простаивает (1) или что то делает (0). И оценить, насколько нам хватает ресурсов МК, есть ли какие то долгоиграющие задачи, которые надо разделить на более мелкие составляющие...
Аналогично можно отслеживать выполнение отдельных задач. Например, есть какой то обработчик прерывания таймерный, который должен успевать между своими вызовами выполнить свою задачу и чтоб еще осталось какое то время для основной задачи.
Denis82, Если за платами будете ездить на танке - то вам только ЛУТ и останется, в конце концов.
Компания Hongfa - один из лидеров азиатского рынка пленочных конденсаторов с полным циклом производства. Она выпускает пять серий помехоподавляющих конденсаторов этого типа как для бытовой, так и для трехфазной промышленной сети, а также для автомобильного применения. Продукция компании по ассортименту, параметрам и количеству серий конденсаторов ЭМП не уступает другим крупным производителям этого сегмента и может легко заменить ассортимент ушедших из РФ брендов.
Да, так же делаю. Кучка импульсов одного процесса должны уложиться между импульсами другого - визуально такое удобнее оценивается, чем что-то считать. Особенно, когда границы дозволенного как раз и определяются внешним тактированием.
Martian, ну идея не моя, подсмотрела когда то на изиэлектрониксе, кажется... Просто тема касается отладки, а скатились в обсуждение чего угодно. Вот и решила написать про один из способов отладки. Еще при наличии ЦАП в МК можно разные процессы выводить разными уровнями. Но тогда нужен аналоговый анализатор либо осцилл. Либо задействовать несколько GPIO - и на них выводить разные процессы. У меня зачастую какие то идеи и фрагменты кода обкатываются на беспаечной макетке с использованием всяких отладочных плат, типа той же ардуины. А на этих платах зачастую какой то GPIO выводят на светодиод. Вот его и использую, как вот такой флаговый. Тем паче, у некоторых семейств этот пин GPIO несколько кастрирован и его не всегда получается использовать как порт с нормальной нагрузкой или скоростью (РС13-РС15). А потом, когда уже проблемные вопросы решены - уже идет перенос разработки на плату устройства и рутинное написание полной программы.
В Cube IDE в отладке переменные, регистры, память в реальном времени. Если нужно посмотреть быстрые процессы, то заполняю инфой свободное ОЗУ и в точке останова неспешно изучаю.
linkov1959, так CubeIDE - это почти та же Atollic TrueStudio, которая сделана на движке Eclipse. И там инструментов по отладке вагон и тележка. И отладка в ней - это как раз внутрисхемная* отладка, про которую КРАМ говорит. Но если вы говорите про отладочный код и массив в памяти, то можно рассмотреть вопрос отладочного вывода - быстрые процессы иногда проще отслеживать лог.анализаторорм, делая дебаг.вывод через GPIO - чисто из-за того, что на компе памяти больше, чем в МК и лог.анализатор имеет большую частоту дискретизации. Либо через быстрый UART. Т.е. просто можно снять бОльший объем данных и потом их изучать неспешно. Но с другой стороны, метод "сложить в память" и посмотреть отладчиком - дополнительно не требует ничего, кроме наличия ST-Link'а и студии - и это тоже плюс внутрисхемной отладки.
А когда есть Атмега8 и нет в наличии инструментов для внутрисхемной отладки - то вот приходится извращаться, как AQ29, "изобретением" всяких софтовых логгеров по двум проводкам. Но вот данной темы не было бы, если бы двухпроводковая софтовая отладка не преподносилась как единственно истинная и расово верная. Но, как ранее говорилось - инструментов для отладки много. И в разных случаях это могут быть разные инструменты. Вон в ардуине консольный вывод - вообще единственный инструмент "из коробки" для большинства МК. И это не внутрисхемный, ибо printf и его вывод в uart - это программные сущности.
* под внутрисхемной отладкой я имею ввиду аппаратное устройство с программной поддержкой на ПК, не требующее изменения прошивки МК и позволяющее прозрачно для прошивки заглянуть в МК как в реалтайме, так и при останове.
Martian, так LGBT - не совсем AVR, а просто что то почти совместимое. Хотя в некоторых случаях это более вкусные камешки. Но я тоже разбалована TrueSTUDIO )))))))))))))))))))))))))))))))))))))
Ну, я при их выборе ориентировался на то, что, наверное, предпочтёт сейчас купить большинство любителей Ардуино из доступного на Али. Эти оказались самыми дешёвыми. На всякий случай взял более дорогой вариант с Tiny88, которая внезапно заявила, что она Digispark Serial.print выдал ахинею, потом ничего не выдал, а потом с ним обычный блинк завис. Без него не висит. Красота... Светодиодик, как отладчик, пока победил
Ну так и работайте в этой лаборатории. Причем тут КБ? КБ - это помещение для конструкторов. Надеюсь вам не нужно объяснять чем отличается конструктор от схемотехника-эмбеддера?
Я уже пояснял. В лаборатории – работа с оборудованием. В КБ – разработка, оформление всяких бумаг, общение с коллегами. Это нормальная организация работы. Вот интересно, скажем, рядом с вами работает конструктор механик, вы начинаете что-там паять, как он реагирует?
Я пишу о симуляторе, встроенном в программную среду для МК. Пользоваться таким симулятором очень просто. Поясню, как он работает.
Это смешно... Вы полагаете, что я не знаю как работает симулятор в среде? Только проку от такой отладки НОЛЬ. Она если для чего то и нужна, так это для быстрой проверки чистой математики. Если на столе лежит аппаратный дебаггер и схема, то симулятор вообще бестолковая вещь. С реальным железом я даже такие простые вещи смогу во времени посмотреть с реальным тактированием, а не только тупую пошаговую последовательность. Еще один недостаток симулятора среды - это его крайняя медлительность и пожирание ресурсов при трассировке.
Уже писал, что, похоже, пишем о разных программах. Вы пишите о каких-то «физических моделях внешних полей и механических устройств, трансдьюсерах и т.д.». Какое отношение это имеет к обычному симулятору? Он просто проходит по ассемблерным командам программы. Откуда «крайняя медлительность и пожирание ресурсов при трассировке»? Скажем, симулятор проходит ассемблерную команду add. Симулятор должен сложить два байта и установить биты SREG. Где тут «пожирание ресурсов»? Даже в старой алгоритм билдер (АБ) на древнем компьютере быстро работало. Ради интереса посмотрел, с какой скоростью симулятор работает на АБ. Правда, пришлось повспоминать, как там работать. Для удобства запустил программную задержку. Оказалось, симулятор проходил со скоростью около 150 тысяч тактов в секунду. Очень неплохо. Большей частью, на один такт приходиться одна ассемблерная команда. Сильно сомнительно, что аппаратный дебаггер удобнее. Скажем, проверка расчёта функции. В симуляторе установил начальную и конечную точки прохода. Затем при каждом проходе задаёшь значение аргумента и жмёшь кнопку Пуск. Обычно, симулятор делает расчёт за доли секунды. Насколько помню, у меня после отладки в симуляторе эта часть программы всегда исправно работала в реалии.
А в штатном аппаратном дебаге ничего специально выводить на экран компьютера не требуется. Просто в окне Watch открывается буфер контролируемых переменных (причем ИМЕНОВАННЫЙ, а не безымянный) и так же точно наблюдается хоть после останова, хоть в динамике. Повторю. Наблюдаются не сами переменные, а их значения защелкнутые в буфер в необходимых сечениях кода. То есть это обычный лог.
Как я понял, необходимые сечения кода – это точки программы. Как вы защёлкиваете интересуемые переменные в необходимых сечениях и как определяете, к каким точкам программы эти значения относятся?
Вы, милейший, изобрели деревянный велосипед с квадратными колесами. Почитайте что нибудь про JTAG и вы обнаружите, что он примерно так и работает, только без "модернизированного SPI"...
Очевидно, что я не изобретал SPI, а просто использовал его для своих целей. Изобретение – это несколько другое.
Оказалось, симулятор проходил со скоростью около 150 тысяч тактов в секунду. Очень неплохо. Большей частью, на один такт приходиться одна ассемблерная команда. Сильно сомнительно, что аппаратный дебаггер удобнее. Скажем, проверка расчёта функции. В симуляторе установил начальную и конечную точки прохода. Затем при каждом проходе задаёшь значение аргумента и жмёшь кнопку Пуск. Обычно, симулятор делает расчёт за доли секунды. Насколько помню, у меня после отладки в симуляторе эта часть программы всегда исправно работала в реалии.
Аппаратный дебаггер работает точно так же и учитывает все эрраты чипа. В отличии от... Процесс работы ничем от симулятора не отличается. Те же начальная и конечная точка.... Я это делаю регулярно, проверяя арифметику кода.
Как я понял, необходимые сечения кода – это точки программы. Как вы защёлкиваете интересуемые переменные в необходимых сечениях и как определяете, к каким точкам программы эти значения относятся?
Можно в едином логе писать название точки в виде номера (например один байт номер, а следующий данные), можно вести разные логи для каждой точки. В чем проблема?
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 11
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
