Вот странная фигня выходит....
Те, кто пробовали мангустин, жаренный на петиаровом масле, утверждают, что это вкусный десерт.
А те, кто не пробовал - говорят, фигня эти ваши мангустины... Не нужны они нам, вот у нас есть вареная картоха - и она нажористая....
Хотя вареная картоха ни разу не десерт.
Как говорил МихалМихалыч - Давайте спорить о вкусе устриц и кокосовых орехов с теми кто их ел. Прошу прощения за оффтоп.
Оба способа отладки - и внутрисхемная, и вывод отладочной информации в порт - имеют место быть.
Но они не заменяют друг друга. Скорее всего, дополняют и могут применяться в разных случаях.
Просто в большинстве случаев внутрисхемная отладка удобнее и информативнее.
Но к сожалению, в модный современный алгоритм-билдер внутрисхемную отладку, увы, не завезли... Только команду логарифма....
И, кстати, название современной программы для написания программ на ассемблере для AVR нам так и не сказали....
[uquote="Эйлер Леонард",url="/forum/viewtopic.php?p=4508295#p4508295"]Добрый вечер. Часто в исходниках на __asm__ __volatile__("" ::: "memory");
С первой понятно - пропуск такта, нет операции. А вторая ?[/uquote]
Запрет на переупорядочивания памяти компилятором при оптимизации. Иными словами некий барьер, благодаря которому вы можете задать последовательность компилятору при обращения к памяти.
Эйлер Леонард, Если пишете на сях, то не парьтесь с этим.
В avr/interrupt.h уже есть готовые макросы cli() и sei()
А в util/atomic.h - различные режимы атомарного доступа.
Они сами разворачиваются в запрет-разрешение-восстановление состояния прерываний.
[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4509720#p4509720"]Вот странная фигня выходит....
Те, кто пробовали мангустин, жаренный на петиаровом масле, утверждают, что это вкусный десерт.
А те, кто не пробовал - говорят, фигня эти ваши мангустины... Не нужны они нам, вот у нас есть вареная картоха - и она нажористая....
Хотя вареная картоха ни разу не десерт.
Как говорил МихалМихалыч - Давайте спорить о вкусе устриц и кокосовых орехов с теми кто их ел. Прошу прощения за оффтоп.
Оба способа отладки - и внутрисхемная, и вывод отладочной информации в порт - имеют место быть.
Но они не заменяют друг друга. Скорее всего, дополняют и могут применяться в разных случаях.
Просто в большинстве случаев внутрисхемная отладка удобнее и информативнее.
Но к сожалению, в модный современный алгоритм-билдер внутрисхемную отладку, увы, не завезли... Только команду логарифма....
И, кстати, название современной программы для написания программ на ассемблере для AVR нам так и не сказали....[/uquote]
Мангустинов в петиаровом масле не пробовал, это точно. Как-то не задалось у меня с мангустинами…
А пошаговой отладкой пользовался, она ведь есть в симуляторе.
Программа запускается в режиме симулятора. В любом месте программы можно поставить точку старта, а затем шагать. Если интересующее место находится далеко от места старта, можно поставить точку финиша. Тогда одним кликом можно пройти до финиша и затем шагать.
Такая отладка удобна, вопросов нет, но только для процессов внутри МК.
По моим представлениям, это плохо подходит для реальной работы МК с внешними устройствами.
Кроме опасности аварии могут происходить ошибки из-за несоблюдения временных соотношений. Скажем, центральный МК начал обмен с периферийным МК какого-нибудь блока, например, измерителя. Вы шагаете медленно, измеритель не дождался ответа и ушёл.
Центральный МК тоже не получил правильного ответа и выдал сообщение, что измеритель неисправен. Можно впустую потратить много времени на поиски ошибки в измерителе, а она возникла из-за работы вашего отладчика.
В связи с такими проблемами решил, что реализация пошаговой отладки при реальной работе не имеет смысла.
С моим отладчиком тоже возникали такие ошибки, но крайне редко, ведь время задержки – несколько микросекунд. Да и они легко определялись. Запрограммировал с новыми командами отладки – возникла новая ошибка, убрал эти команды, ошибка исчезла. Всё ясно, влез туда, куда не надо.
В новых МК АВР через один вывод программирования МК можно просматривать и изменять SRAM. Тогда можно в интересующем месте выбросить переменную в SRAM, а в свободном окне считать её. Чтобы переменная не затёрлась, придётся, наверно, притормозить МК. Скорее всего, можно сделать вариант без «притормаживания», надо будет разбираться.
У меня программа никакого отношения к алгоритм-билдеру не имеет.
И в ней есть не только логарифм, хотя пока маловато для современной программы. Да и программирование, можно сказать, простое и стандартное, без «стрелочек».
[uquote="КРАМ",url="/forum/viewtopic.php?p=4509510#p4509510"]Приведу пример.
Пусть не про AVR, но это не существенно.
В ARM-ах нет EEPROM-а. Его эмулируют в программном флеше…
Сделать это через порт, сами понимаете, принципиально невозможно, ибо ПРОГРАММА НЕ РАБОТОСПОСОБНА.[/uquote]
«ПРОГРАММА НЕ РАБОТОСПОСОБНА» - стало быть, нет выброса переменной в дебаггер, это существенная информация.
Насколько понял, в вашем примере все процессы происходят в МК без работы с внешними устройствами. Вообще-то в этом случае удобно использовать симулятор, у меня он тоже есть. Но можно и отладку в реальном времени.
Скажем, в начале каждой записи в EEPROM выбрасывать в дебаггер номер страницы или что ещё есть. Быстро выяснится, что МК зависает при записи последней страницы. Дальше найти ошибку несложно.
Могло случиться, что вы не знаете, отчего зависает МК. Включили – и через некоторое время он завис. Тогда можно расставить несколько команд отладчика по ходу программы. Далее видно, МК точку №4 прошёл, в точку №5 не пришёл, МК завис. Расставили новые команды после точки №4. Несколько итераций – и вы вышли на дефектную команду записи в EEPROM.
Можно сказать, это типовая ошибка, с помощью дебаггера легко отыскивается.
Вы пишите глупости и отчаянные фантазии.
Симуляторы не симулируют работу с флешем.
Симуляторы не симулируют работу с доменом осциллятора, симуляторы не симулируют работу с реальными сигналами на входе АЦП. Есть еще куча вариантов.
Но главное, что отладка через порт не дает отладку в реальном времени.
То есть произвести захват большого массива и неопределенных данных через порт не реально.
А так, только сегодня я за пять минут нашел проблему в слейвном ядре двухядерного dsPIC.
Причем в готовом изделии, где нет никаких свободных портов в этом ядре.
Здравствуйте. Подскажите, пожалуйста, подходит ли книга Джона Мортона Микрроконтроллеры AVR. Вводный курс. для знакомства с программированием Attiny2313 на ассемблере? Может что-то подходит лучше? По моему любительскому опыту выбор первого учебника очень важен. Вот, мне лет 15 тому назад попался самоучитель Заеца по PIC, так ими и пользовался. А теперь приобрел Attiny2313, с более сложным мне не справиться. С какой бы книги начать, чтобы так вот сразу и к делу? Буду благодарен за совет.
sathv писал(а): для знакомства с программированием Attiny2313 на ассемблере?
sathv, если по tiny2313, то Белов А. В "Микроконтроллеры AVR: от азов программирования до создания практических устройств". Сгодится ли она как учебник не знаю, но примеров по 2313 в книге достаточно, начиная со светодиода и кнопки.
PS освоите тиньку, долго не засиживайтесь на ней, перебирайтесь на atmega8 хотя бы но это моё мнение
PS2 и вряд ли есть единственная книга и чтобы как панацея. Всё равно к разным источникам придётся обращаться.
Здравствуйте! Спасибо за советы. Скачал книгу и CD А В Белова. Все слова там по отдельности понятны и AVR Studio похоже на MPLAB, посмотрю, что будет в целом, после изучения))
sathv, для поиграться асмом 4 студии достаточно.... Но если в дальнейшем планируете си - то, как IDE - 4 студия слабовата.
Точнее, редактор там слабоват, многих плюшек нету...
И тогда или студию надо брать постарше, или другую IDE.... (моё личное мнение)
Тут вроде недавно обсуждали про IDE. Уже и не помню когда в них писал что то. Notepad++ под любой язык
Но опять же на любителя переключаться между окнами
Многое зависит и от имеющегося ПК/ОС.
На ХР х32 тот notepad++ не пойдет.
То же касается и более навороченных IDE (avr studio7/microchip studio).
Так что довольствуемся возможным.
У меня Notepad++ на слабеньком нетбуке asus1005pxd под XP прекрасно работает.
Очень невысокие системные требования.
Скрин диспетчера задач с основного компа, под вин11. Потребляет оперативы меньше самого диспетчера. Открыто 4 вкладки.
а это с офф сайта:
Основанный на мощном компоненте редактирования Scintilla , Notepad++ написан на C++ и использует чистый Win32 API и STL, что обеспечивает более высокую скорость выполнения и меньший размер программы.
PS думаю, что компы с 256 оперативы уже не используются
[uquote="КРАМ",url="/forum/viewtopic.php?p=4514956#p4514956"]Вы пишите глупости и отчаянные фантазии.
Симуляторы не симулируют работу с флешем.
Симуляторы не симулируют работу с доменом осциллятора, симуляторы не симулируют работу с реальными сигналами на входе АЦП. Есть еще куча вариантов.
Но главное, что отладка через порт не дает отладку в реальном времени.
То есть произвести захват большого массива и неопределенных данных через порт не реально.
А так, только сегодня я за пять минут нашел проблему в слейвном ядре двухядерного dsPIC.
Причем в готовом изделии, где нет никаких свободных портов в этом ядре.[/uquote]
Многовато у вас в посте эмоций.
Что вам показалось «отчаянной фантазией»?
Я написал, что в симуляторе удобно отлаживать процессы при работе без внешних устройств. Обычно использую для отладки расчёта по формуле.
Где тут глупость, фантазия и тем более отчаянная.
Ваш пример с АЦП не подходит, АЦП связана с внешними сигналами.
Можно ли найти ошибку при работе с симулятором при записи во флеш, это вопрос. Может быть, можно обнаружить ошибку в адресе, не знаю, я пока не использовал симулятор для такой задачи, в АВР есть EEPROM.
Давно использую дебаггер для отладки МК при реальной работе, это основной инструмент, а вы пишите, что это нереально.
В некоторых задачах изредка бывают проблемы, но, обычно, можно найти обходные варианты, я об этом писал.
Для дебаггера не нужен свободный порт, достаточно пары свободных выводов МК. В большинстве случаев достаточно и одного вывода. В принципе, иногда можно работать и при отсутствии свободных выводов, но это проблематичней.
У меня не бывает проблемы со свободными выводами МК. При разработке схемы сразу назначаю пару выводов МК для дебаггера, сигналы вывожу на разъём программатора. Так что просто подключив дебаггер к разъёму в плате, можно сразу проводить программирование и полноценную отладку.
Если отсутствует возможность отладки, то, на мой взгляд, это большей частью проблема начинающих.
[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4514966#p4514966"]КРАМ, Дайте человеку пофантазировать... Люди делятся на тех, кто ел мангустины и тех , кто картошку хвалит.[/uquote]
Неясно, что вам показалось фантазией. Если работа с симулятором, так он есть даже в старенькой программе АБ.
Возможно, дебаггер вам показался фантастичным, что-то типа мангустина, а для меня это обычное устройство, рабочая лошадка.
[uquote="AQ29",url="/forum/viewtopic.php?p=4517061#p4517061"]Давно использую дебаггер для отладки МК при реальной работе, это основной инструмент, а вы пишите, что это нереально.[/uquote]
Я не знаю что вы называете дебаггером, но дебаггер это совокупность аппаратного блока в чипе и внешнего отладчика, действующего через штатный интерфейс программирования/отладки. Например, JTAG/SWD или ICSP.
Отладка через UART дебаггером не является. Это разновидность ногодрыга без возможности прозрачного сканирования памяти и управления исполнением кода из среды разработки.
[uquote="AQ29",url="/forum/viewtopic.php?p=4517061#p4517061"]В некоторых задачах изредка бывают проблемы, но, обычно, можно найти обходные варианты, я об этом писал.[/uquote]
Зачем весь это геморрой и идиотизм, если есть штатный отладчик? Вам жалко денег на технологическое железо?
[uquote="AQ29",url="/forum/viewtopic.php?p=4517061#p4517061"]Ваш пример с АЦП не подходит, АЦП связана с внешними сигналами.[/uquote]
Прикольно...
Это почему не подходит?
Типичный пример, когда симулятор не пригоден. Любой входной сигнал для симуляции является грубым костылем.
Поэтому штатный дебаггер позволяет не использовать симуляторы. Тем более, что симулятор является самостоятельным продуктом со своей эрратой не совместимой с эрратой реального чипа.
но это моё мнение 
Вам жалко денег на технологическое железо?
