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

Добрый вечер. Просто часто встречается такое. Напр. при реализации атомарного доступа.
OK!

Эйлер Леонард, Если пишете на сях, то не парьтесь с этим.
В avr/interrupt.h уже есть готовые макросы cli() и sei()
А в util/atomic.h - различные режимы атомарного доступа.
Они сами разворачиваются в запрет-разрешение-восстановление состояния прерываний.

Мангустинов в петиаровом масле не пробовал, это точно. Как-то не задалось у меня с мангустинами…
А пошаговой отладкой пользовался, она ведь есть в симуляторе.
Программа запускается в режиме симулятора. В любом месте программы можно поставить точку старта, а затем шагать. Если интересующее место находится далеко от места старта, можно поставить точку финиша. Тогда одним кликом можно пройти до финиша и затем шагать.
Такая отладка удобна, вопросов нет, но только для процессов внутри МК.
По моим представлениям, это плохо подходит для реальной работы МК с внешними устройствами.
Кроме опасности аварии могут происходить ошибки из-за несоблюдения временных соотношений. Скажем, центральный МК начал обмен с периферийным МК какого-нибудь блока, например, измерителя. Вы шагаете медленно, измеритель не дождался ответа и ушёл.
Центральный МК тоже не получил правильного ответа и выдал сообщение, что измеритель неисправен. Можно впустую потратить много времени на поиски ошибки в измерителе, а она возникла из-за работы вашего отладчика.
В связи с такими проблемами решил, что реализация пошаговой отладки при реальной работе не имеет смысла.
С моим отладчиком тоже возникали такие ошибки, но крайне редко, ведь время задержки – несколько микросекунд. Да и они легко определялись. Запрограммировал с новыми командами отладки – возникла новая ошибка, убрал эти команды, ошибка исчезла. Всё ясно, влез туда, куда не надо.

В новых МК АВР через один вывод программирования МК можно просматривать и изменять SRAM. Тогда можно в интересующем месте выбросить переменную в SRAM, а в свободном окне считать её. Чтобы переменная не затёрлась, придётся, наверно, притормозить МК. Скорее всего, можно сделать вариант без «притормаживания», надо будет разбираться.

У меня программа никакого отношения к алгоритм-билдеру не имеет.
И в ней есть не только логарифм, хотя пока маловато для современной программы. Да и программирование, можно сказать, простое и стандартное, без «стрелочек».



«ПРОГРАММА НЕ РАБОТОСПОСОБНА» - стало быть, нет выброса переменной в дебаггер, это существенная информация.

Насколько понял, в вашем примере все процессы происходят в МК без работы с внешними устройствами. Вообще-то в этом случае удобно использовать симулятор, у меня он тоже есть. Но можно и отладку в реальном времени.
Скажем, в начале каждой записи в EEPROM выбрасывать в дебаггер номер страницы или что ещё есть. Быстро выяснится, что МК зависает при записи последней страницы. Дальше найти ошибку несложно.
Могло случиться, что вы не знаете, отчего зависает МК. Включили – и через некоторое время он завис. Тогда можно расставить несколько команд отладчика по ходу программы. Далее видно, МК точку №4 прошёл, в точку №5 не пришёл, МК завис. Расставили новые команды после точки №4. Несколько итераций – и вы вышли на дефектную команду записи в EEPROM.
Можно сказать, это типовая ошибка, с помощью дебаггера легко отыскивается.

Вы пишите глупости и отчаянные фантазии.
Симуляторы не симулируют работу с флешем.
Симуляторы не симулируют работу с доменом осциллятора, симуляторы не симулируют работу с реальными сигналами на входе АЦП. Есть еще куча вариантов.
Но главное, что отладка через порт не дает отладку в реальном времени.
То есть произвести захват большого массива и неопределенных данных через порт не реально.
А так, только сегодня я за пять минут нашел проблему в слейвном ядре двухядерного dsPIC.
Причем в готовом изделии, где нет никаких свободных портов в этом ядре.

КРАМ, Дайте человеку пофантазировать... Люди делятся на тех, кто ел мангустины и тех , кто картошку хвалит.

Здравствуйте. Подскажите, пожалуйста, подходит ли книга Джона Мортона Микрроконтроллеры AVR. Вводный курс. для знакомства с программированием Attiny2313 на ассемблере? Может что-то подходит лучше? По моему любительскому опыту выбор первого учебника очень важен. Вот, мне лет 15 тому назад попался самоучитель Заеца по PIC, так ими и пользовался. А теперь приобрел Attiny2313, с более сложным мне не справиться. С какой бы книги начать, чтобы так вот сразу и к делу? Буду благодарен за совет.

sathv, если по tiny2313, то Белов А. В "Микроконтроллеры AVR: от азов программирования до создания практических устройств". Сгодится ли она как учебник не знаю, но примеров по 2313 в книге достаточно, начиная со светодиода и кнопки.

PS освоите тиньку, долго не засиживайтесь на ней, перебирайтесь на atmega8 хотя бы но это моё мнение
PS2 и вряд ли есть единственная книга и чтобы как панацея. Всё равно к разным источникам придётся обращаться.

ATtiny2313(a) - хороший выбор. Наряду с ядром, практически вся периферия адекватно обслуживается
AVR STUDIO 4.19. Рекомендую.

Здравствуйте! Спасибо за советы. Скачал книгу и CD А В Белова. Все слова там по отдельности понятны и AVR Studio похоже на MPLAB, посмотрю, что будет в целом, после изучения))

sathv, для поиграться асмом 4 студии достаточно.... Но если в дальнейшем планируете си - то, как IDE - 4 студия слабовата.
Точнее, редактор там слабоват, многих плюшек нету...
И тогда или студию надо брать постарше, или другую IDE.... (моё личное мнение)

Тут вроде недавно обсуждали про IDE. Уже и не помню когда в них писал что то. Notepad++ под любой язык
Но опять же на любителя переключаться между окнами

Многое зависит и от имеющегося ПК/ОС.
На ХР х32 тот notepad++ не пойдет.
То же касается и более навороченных IDE (avr studio7/microchip studio).
Так что довольствуемся возможным.

У меня Notepad++ на слабеньком нетбуке asus1005pxd под XP прекрасно работает.
Очень невысокие системные требования.

Скрин диспетчера задач с основного компа, под вин11. Потребляет оперативы меньше самого диспетчера. Открыто 4 вкладки.


а это с офф сайта:


PS думаю, что компы с 256 оперативы уже не используются

Многовато у вас в посте эмоций.
Что вам показалось «отчаянной фантазией»?
Я написал, что в симуляторе удобно отлаживать процессы при работе без внешних устройств. Обычно использую для отладки расчёта по формуле.
Где тут глупость, фантазия и тем более отчаянная.
Ваш пример с АЦП не подходит, АЦП связана с внешними сигналами.
Можно ли найти ошибку при работе с симулятором при записи во флеш, это вопрос. Может быть, можно обнаружить ошибку в адресе, не знаю, я пока не использовал симулятор для такой задачи, в АВР есть EEPROM.

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

Для дебаггера не нужен свободный порт, достаточно пары свободных выводов МК. В большинстве случаев достаточно и одного вывода. В принципе, иногда можно работать и при отсутствии свободных выводов, но это проблематичней.
У меня не бывает проблемы со свободными выводами МК. При разработке схемы сразу назначаю пару выводов МК для дебаггера, сигналы вывожу на разъём программатора. Так что просто подключив дебаггер к разъёму в плате, можно сразу проводить программирование и полноценную отладку.
Если отсутствует возможность отладки, то, на мой взгляд, это большей частью проблема начинающих.


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

Я не знаю что вы называете дебаггером, но дебаггер это совокупность аппаратного блока в чипе и внешнего отладчика, действующего через штатный интерфейс программирования/отладки. Например, JTAG/SWD или ICSP.
Отладка через UART дебаггером не является. Это разновидность ногодрыга без возможности прозрачного сканирования памяти и управления исполнением кода из среды разработки.

Зачем весь это геморрой и идиотизм, если есть штатный отладчик? Вам жалко денег на технологическое железо?

Прикольно...
Это почему не подходит?
Типичный пример, когда симулятор не пригоден. Любой входной сигнал для симуляции является грубым костылем.
Поэтому штатный дебаггер позволяет не использовать симуляторы. Тем более, что симулятор является самостоятельным продуктом со своей эрратой не совместимой с эрратой реального чипа.

внимательно слежу за темой, сорри за оффтоп конечно, но про "эррату" я прям загуглил..

отладка ну никак для темы про ассемблер не подходит, не оффтопьте, пожалуйста!

Дебаггером назвал соединение программатора и отладчика. Дебаггер, скорее всего, общий термин, для него не обязательно наличие аппаратного блока в чипе.
Отладку делаю не через USART, а через пару свободных выводов МК, я об этом писал, передача типа SPI.
USART плохо подходит для отладки. Был вариант, когда в дебаггере был установлен маленький МК для приёма данных через USART, но из-за известных недостатков такой отладки этот вариант не пошёл.
Отладка – это тоже общий термин, для отладки не обязательно «прозрачное сканирование памяти и управление исполнением кода из среды разработки».

Отладчик типа JTAG плохо подходит для МК АВР. Во-первых, не у всех МК есть JTAG, а мой дебаггер работает со всеми. Во-вторых, JTAG использует 4 вывода МК, а дебаггер, фактически, один вывод. Это существенное преимущество.
К тому же цена дебаггера может быть очень небольшой.
Посмотрел на Алиэкспресс, сейчас цена программатора менее 200 рублей, для отладчика добавляется, фактически, несколько микросхем средней интеграции.

Я же ранее писал, что симулятор удобно использовать при работе без внешних устройств. АЦП связан с внешними устройствами, поэтому ваш пример не подходит.
Возможно, в вашем примере с флешем в симуляторе можно было бы обнаружить ошибку при записи адреса. Насколько реально, не знаю, поэтому написал обтекаемую фразу, что при отладке без внешних устройств удобно использовать симулятор. Что в этой фразе показалось «отчаянной фантазией» - неясно.
Почему симулятор обязательно является самостоятельным продуктом?
Даже в программе АБ симулятор встроен в среду.
Для меня обычный алгоритм отладки такой:
процессы без внешних устройств – на симуляторе,
при реальной работе – с помощью дебаггера и прочих устройств.
Что за эррата в симуляторе – без понятия, до сих пор обходился без неё.

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

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

Я это и не утверждал. Для отладки не обязательно. Для дебаггера - обязательно.

Это вообще не преимущество. Просто потому, что есть МК без внутреннего блока отладки. Это малоногие чипы. Но на них редко возникают проблемы требующие отладки более, чем ногодрыгом.
Штатный аппаратный дебаггер использует те ноги, через которые МК программируется в обычном режиме (не через бут). Поэтому никакие лишние ноги он не задействует. Использовать ноги МК впритык так, что требуется занять и ноги программирования - очень плохая привычка. Если нужна миниатюрность, то проще сменить тип корпуса. Например заменить SOIC на MSOP/DFN или TQFP на QFN.
Это как раз про жаренную картошку.
Экономить на инструменте конечно можно, но вряд ли стоит это рекламировать. Если нет денег, то причем тут удобство? Отлаживать можно и без каких либо внешних инструментов. Тупо на светодиодах.
Если неясно, повторю еще раз. Смотреть в симуляторе почти нечего. Если только учиться азам, разглядывая как работают инструкции.
Весь смысл применения МК - его взаимодействие с внешней аппаратурой. То есть нужен не просто симулятор, а схемотехнический симулятор типа Протеуса. Но Протеус имеет ограниченное количество моделей МК, я уже не говорю об остальном. Порой симулировать радиотехническую часть схемы на три порядка сложнее, чем написать код. Ведь не всегда известны паразитные параметры реальной схемы...

Такая же, как и в МК. Не симулируются некоторые функции периферии, а равно целые модули, либо симулируются с ошибками. Не симулируется ЭРРАТА РЕАЛЬНОГО ЧИПА.
Ведь код симулятора, так же как и код МК (имеется ввиду не программа, а код топологии - ее пишут так же, как и код CPLD или FPGA) пишут люди. А они могут ошибаться. И ведь ошибаются, что характерно...